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
| ||
|
Message-ID: <Yzwb2e0/CK9QbV0n@google.com> Date: Tue, 4 Oct 2022 12:41:13 +0100 From: Lee Jones <lee@...nel.org> To: Stephen Boyd <swboyd@...omium.org> Cc: Lee Jones <lee.jones@...aro.org>, Satya Priya Kakitapalli <quic_c_skakit@...cinc.com>, Mark Brown <broonie@...nel.org>, Bjorn Andersson <bjorn.andersson@...aro.org>, Rob Herring <robh+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, quic_collinsd@...cinc.com, quic_subbaram@...cinc.com, quic_jprakash@...cinc.com Subject: Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API On Mon, 03 Oct 2022, Stephen Boyd wrote: > Quoting Lee Jones (2022-09-29 11:01:41) > > On Wed, 28 Sep 2022, Stephen Boyd wrote: > > > > > Quoting Lee Jones (2022-09-28 03:20:30) > > > > Wouldn't it make more sense to simply separate the instantiation of > > > > the 2 I2C devices? Similar to what you suggested [0] in v9. That way > > > > they can handle their own resources and we can avoid all of the I2C > > > > dummy / shared Regmap passing faff. > > > > > > > > [0] https://lore.kernel.org/all/CAE-0n53G-atsuwqcgNvi3nvWyiO3P=pSj5zDUMYj0ELVYJE54Q@mail.gmail.com/ > > > > > > > > > > You can continue reading the thread[1]. My understanding is it's one > > > chip that responds on two i2c addresses, thus we don't describe that as > > > two i2c device nodes in DT. Instead we describe one node and use the > > > dummy API to make the second i2c device. > > > > > > [1] https://lore.kernel.org/all/Yk3NkNK3e+fgj4eG@sirena.org.uk/ > > > > As Mark says, it's probably 2 separate dies that have been encased in > > the same IC and are otherwise unconnected. Not sure I understand the > > comment about not requiring another 'struct device'. It will still > > require that whether it's a platform device or an I2C device, right? > > > > Yes a 'struct device' will be required for each i2c address no matter > what happens. > > It is also useful to describe the hardware as one device node in case > there is a shared reset signal or power supply. That allows us to have > one driver probe the DT node and deassert the reset/power the chip on. I > think this device has one reset signal, so we really need to do this and > not treat them as completely independent i2c devices (the 0x8 and 0x9 > addresses). > > Can we move forward with my plan to have another i2c device made for > 'pm8008-regulators' and have that driver be an i2c driver that probes an > i2c device manually created in the pm8008 driver? I think that would > handle the reset ordering problem because the pm8008 driver can deassert > the reset and also handle the regmap passing stuff by letting the i2c > device at 0x9 make its own regmap. Sure, why not. I'm pretty done talking about this now. :) Please work with Satya to cobble something together. -- Lee Jones [李琼斯]
Powered by blists - more mailing lists