linux-kernel - Re: [PATCH v4 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-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0cA7iL=ug6hiqWAV1-qFSoCN-R7jrXv0cqByUDJV4x0Q@mail.gmail.com>
Date:   Fri, 17 Dec 2021 09:12:57 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Tony Huang 黃懷厚 <tony.huang@...plus.com>
Cc:     Arnd Bergmann <arnd@...db.de>, DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Derek Kiernan <derek.kiernan@...inx.com>,
        Dragan Cvetic <dragan.cvetic@...inx.com>,
        Rob Herring <robh+dt@...nel.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Wells Lu 呂芳騰 <wells.lu@...plus.com>,
        黃懷厚 <tonyhuang.sunplus@...il.com>
Subject: Re: [PATCH v4 2/2] misc: Add iop driver for Sunplus SP7021

On Fri, Dec 17, 2021 at 3:44 AM Tony Huang 黃懷厚 <tony.huang@...plus.com> wrote:
>
> Dear Arnd:
>
>
>
> On Thu, Dec 16, 2021 at 2:38 AM Tony Huang <tonyhuang.sunplus@...il.com> wrote:
> >>
> >> IOP (IO Processor) embedded inside SP7021 which is used as
> >> Processor for I/O control, RTC wake-up and cooperation with
> >> CPU & PMC in power management purpose.
> >> The IOP core is DQ8051, so also named IOP8051,
> >> it supports dedicated JTAG debug pins which share with SP7021.
> >> In standby mode operation, the power spec reach 400uA.
> >>
> >> Signed-off-by: Tony Huang <tonyhuang.sunplus@...il.com>
> >> ---
> >> Changes in v4:
> >>  - Addressed comments from Arnd Bergmann.
>
> >I don't think you did: I asked you specifically to add code to interact with
> >the existing in-kernel interfaces to use the functionality provided by the
> >device. Pick any (at least two) subsystems and add support, but leave
> >out any custom user space interfaces (miscdevice, debugfs, sysfs, ...)
> >for the moment.
>
>
>
> 1. IOP can run sp_iop_platform_driver_shudown() through the poweroff command
> and the kernel. Perform system power-off actions.

Do you mean that this method a) cleanly shuts down the iop before the
system is powered down, or b) the driver_shutdown() callback is used to
initiate the powerdown of the system itself?

In case of a) I would not count that as exposing functionality, what you do here
is just part of any driver. If instead you are trying to use b), this
is the wrong
way of doing it, see drivers/power/reset/ for examples of how to do it right.

> 2. Wake up the system by relying on the 8051 internal RTC wake-up mechanism
> and external GPIO input signals to wake up.

I think those should be exposed with drivers/rtc for the RTC and drivers/gpio/
for the GPIO driver, and then you can use the device tree to configure which
GPIO to use as a wakeup and how it's connected to the RTC.

> 3.So you ask me to control IOP(8051) through file_operations, not through DEVICE_ATTR

No, neither of them. Use the appropriate drivers/*/ subsystems for any
functionality that has an existing subsystem. If there is something that the iop
does that does not yet have a subsystem, that requires a more thorough design
discussion for creating a new user interface, ideally in a hardware-independent
way. You should not start with that until all the normal features (rtc, wakeup,
suspend, gpio, ...) are supported.

       Arnd