linux-kernel - Re: [PATCH v11 2/2] misc: Add iop driver for Sunplus SP7021

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: <CAK8P3a2K+TTP3a_jNsPi6Ea+8THrM31ecO_=bNEFqPP+XZCd9w@mail.gmail.com>
Date:   Tue, 15 Mar 2022 10:22:45 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Tony Huang 黃懷厚 <tony.huang@...plus.com>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Tony Huang <tonyhuang.sunplus@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "derek.kiernan@...inx.com" <derek.kiernan@...inx.com>,
        "dragan.cvetic@...inx.com" <dragan.cvetic@...inx.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Wells Lu 呂芳騰 <wells.lu@...plus.com>
Subject: Re: [PATCH v11 2/2] misc: Add iop driver for Sunplus SP7021

On Tue, Mar 15, 2022 at 9:24 AM Tony Huang 黃懷厚 <tony.huang@...plus.com> wrote:
> > >>>> On 12/03/2022 17:16, Tony Huang wrote:

(note: please use normal quoting style, only quote the parts of the message
 that you actually reply to, reave the attributoons in place, etc)

> > > Can I put sp_iop_poweroff() here for now?
> > > When power off device driver is added in /driver/power/reset is complete,
> > we will move to it.
> >
> > Not really, because misc drivers is not a place for power off drivers.
> > The driver here looks now like responsible only for system power management
> > of a SoC, so most likely drivers/soc. However it has even less sense to add
> > some feature here and immediately move it somewhere more appropriate
> > (instead just add it to the appropriate place).
> >
> > Your moving of parts of it to drivers/power/reset is now confusing. What will
> > be left here? Please send entire set not just pieces.
> >
>
> I may not fully understand your requirements.
> You: What is your plan for this driver?
> < ----- reset driver? Misc driver?
> You: However keeping all in the same place would be ok, if you do not plan to add any more features.
> This would mean the driver will handle *only* reset and FW loading.
> < ------         Because system does not have a power off device driver.
>         sp_iop_poweroff() can be placed in iop driver?

It really depends on where you want this driver to head. If you don't
have any plans to add features beyond poweroff, having the whole
thing in drivers/power/reset/ is the easiest way. If you do have plans
to add other features, then explain exactly what those features are,
which subsystems they go into, and why you haven't already
implemented them in the previous 11 versions.

The common bits of the driver can go into drivers/soc or drivers/mfd,
partly depending on what abstraction you use between this
driver and its clients, so it's important to figure out the correct
abstraction layer first, and then decide where it should go.

One common way to do it is to use the multi-function-device
abstraction to automatically create child devices from the
hardware device node. Another option is to have high-level
functions exported from a soc driver. Or you could just have
a 'regmap' exposed from a 'syscon' driver to provide
individual registers to devices. Which one of those is best
for your system mostly depends on how you end up using
it, and we have no idea until you have more than one leaf
driver on it. The poweroff driver is not a great example either,
because it does not have an interesting interface and just
comes down to a single function call.

      Arnd