On Tue, Mar 15, 2022 at 9:24 AM Tony Huang 黃懷厚 <tony.huang@xxxxxxxxxxx> 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
