[PATCH v6 06/24] soc: qcom: cmd-db: adjust probe for U-Boot

[Simon Glass]

Hi Caleb,

On Fri, 19 Jul 2024 at 20:45, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>
>
>
> On 19/07/2024 17:04, Simon Glass wrote:
> > Hi Caleb,
> >
> > On Tue, 16 Jul 2024 at 08:16, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> >>
> >>
> >>
> >> On 16/07/2024 09:04, Simon Glass wrote:
> >>> Hi Caleb,
> >>>
> >>> On Mon, 15 Jul 2024 at 22:42, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 15/07/2024 13:39, Simon Glass wrote:
> >>>>> On Mon, 15 Jul 2024 at 11:08, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> >>>>>>
> >>>>>> Integrate cmd-db into the U-Boot driver model.
> >>>>>>
> >>>>>> This is just a wrapper around an in-memory database, so we just need to
> >>>>>> get the address and validate that cmd-db is there.
> >>>>>>
> >>>>>> Since cmd_db_header will be stored in the .data section we can skip
> >>>>>> bind if it's already set.
> >>>>>>
> >>>>>> Signed-off-by: Caleb Connolly <caleb.connolly at linaro.org>
> >>>>>> ---
> >>>>>> To: Simon Glass <sjg at chromium.org>
> >>>>>> ---
> >>>>>>     drivers/soc/qcom/cmd-db.c | 72 +++++++++++++++--------------------------------
> >>>>>>     include/soc/qcom/cmd-db.h |  3 --
> >>>>>>     2 files changed, 23 insertions(+), 52 deletions(-)
> >>>>>>
> >>>>>
> >>>>> Reviewed-by: Simon Glass <sjg at chromium.org>
> >>>>
> >>>> Thanks
> >>>>>
> >>>>> BTW, this is a MISC driver. Does it implement the read() operation?
> >>>>
> >>>> No, the API (as defined in the header file) takes a string and returns a
> >>>> database entry. cmd-db users don't have an easily available handle to
> >>>> the node / udevice regardless.
> >>>
> >>> OK. The closest thing might be UCLASS_SYSINFO, but it is designed for
> >>> inside U-Boot and uses an int instead of a string for lookup.
> >>
> >> Right, I don't think we'll be able to find a more optimum solution here.
> >
> > OK
> >
> >>>
> >>> Could you use the devicetree for this information? What sort of info is it?
> >>
> >> It maps resource names (e.g. "ldoa1" - the LDO1 regulator on PMIC A) to
> >> the address of the resource on the RPMh co-processor.
> >>
> >> We need to support existing (upstream) devicetree, since this has
> >> already been around for many years.
> >
> > OK., Has this problem been resolved in more recent platforms?
>
> What problem?

Well it sounds like the board is using some sort of firmware service
to obtain configuration when it should be using the devicetree. Is
that right?

Regards,
Simon