linux-kernel - Re: [PATCH 2/2] mfd: axp20x: use correct platform device id for many PEK

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2017 10:49:11 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Quentin Schulz <quentin.schulz@...e-electrons.com>
Cc:     dmitry.torokhov@...il.com, wens@...e.org, hdegoede@...hat.com,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        thomas.petazzoni@...e-electrons.com,
        maxime.ripard@...e-electrons.com
Subject: Re: [PATCH 2/2] mfd: axp20x: use correct platform device id for many
 PEK

On Tue, 18 Jul 2017, Quentin Schulz wrote:

> Hi Lee,
> 
> On 18/07/2017 09:19, Lee Jones wrote:
> > On Mon, 17 Jul 2017, Quentin Schulz wrote:
> > 
> >> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> >> AXP809 and AXP813 PEK have different values for startup time bits from
> >> the AXP20X, let's use the platform device id with the correct values.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@...e-electrons.com>
> >> ---
> >>  drivers/mfd/axp20x.c | 12 ++++++------
> >>  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > Patch is find, but are these names reference from platform data
> > anywhere i.e. are we going to break anything by applying it?
> > 
> 
> I don't really understand what you're asking.

Yes, I guess that was a little Fringlish, apologies for my haste.

> We need the first patch of this patch series to be applied before the
> second patch or axp20x-pek driver wouldn't be probed anymore.
> 
> There is no Device Tree declaring axp20x-pek and there is no support for
> Device Tree probing in the driver.
> 
> I don't see how I could break anything with these patches. Could you
> explain with an abstract example, please? I might not break anything
> here but it's better to know now what I could have broken in another
> situation/with another patch series so I won't make that mistake in the
> future.
> 
> Oh, but this patch series would change the name of the directory exposed
> in sysfs (/sys/bus/platform/devices/axp221-pek/*). Is that what you were
> afraid of?

I'm worried about any breakage in terms of name referencing.

If this driver is DT only, then the concern is less, but in the olden
days, we used to conduct device/driver binding using the name.  Ergo,
if you change the name in the driver without updating the device
registration, we would not bind and .probe() would not be called.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog