linux-kernel - Re: [PATCH] firmware: vpd: Add an interface to read VPD value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAFv8NwKH5rX2cdfbK1XJxUJFU3uo0K4UowUM3Z7447Qoz_y8bA@mail.gmail.com>
Date:   Mon, 14 Oct 2019 11:21:04 +0800
From:   Cheng-yi Chiang <cychiang@...omium.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Tzung-Bi Shih <tzungbi@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ALSA development <alsa-devel@...a-project.org>,
        Hung-Te Lin <hungte@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sean Paul <seanpaul@...omium.org>,
        Mark Brown <broonie@...nel.org>,
        Dylan Reid <dgreid@...omium.org>,
        Tzung-Bi Shih <tzungbi@...omium.org>
Subject: Re: [PATCH] firmware: vpd: Add an interface to read VPD value

On Wed, Oct 9, 2019 at 10:05 PM Srinivas Kandagatla
<srinivas.kandagatla@...aro.org> wrote:
>
>
>
> On 08/10/2019 16:14, Stephen Boyd wrote:
> >> 3) As my use case does not use device tree, it is hard for ASoC
> >> machine to access nvmem device. I am wondering if I can use
> >> nvm_cell_lookup so machine driver can find the nvmem device using a
> >> con_id. But currently the cell lookup API requires a matched device,
> >> which does not fit my usage because there will be different machine
> >> drivers requesting the value.
> >> I think I can still workaround this by adding the lookup table in
> >> machine driver. This would seem to be a bit weird because I found that
> >> most lookup table is added in provider side, not consumer side. Not
> >> sure if this is logically correct.
> > Maybe Srini has some input here. It looks like your main concern is
> > consumer to provider mapping?
> >
>
> In non-DT setup, there are various ways to lookup nvmem provider.
>
> 1> nvmem_device_get()/put() using provider devid/name. I think you
> should be able to use this in your case.
> 2> nvmem_register_notifier() which notifies when nvmem provider is added
> to system.
> 3> nvmem_device_find() with own match function this will be merged in
> next window (https://lkml.org/lkml/2019/10/3/215)
>
>
> If none of these are of any help, could explain what exactly are you
> looking for w.r.t nvmem to be able to move to what Stephen Boyd suggested?
>
> --srini
>

Hi Stephen, Mark and Srinivas,
Thank you all for the suggestions.
In my non-DT setup, I have been working on coreboot changes to prepare
data in _DSD following suggestion in
https://patchwork.kernel.org/patch/11179237
The basic idea is that codec driver should just get data it needs from
device property.
The coreboot approach works in my local setup, but I have not sent the
change to coreboot upstream yet.
If that path work, then the change needed in kernel will be much simpler.

In the future, there might be DT setup use case, and I think it should
be doable for VPD to register a nvmem device, and let codec driver
gets the property.
But I would drop this path for now.
Thanks!