linux-kernel - Re: [PATCH v2] soc: add aspeed folder and misc drivers

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]

Message-ID: <CAO=notw5wcC4ybPhAuwq9n5HCY18Yewt-Wp7nJWP0kaRnOxtwA@mail.gmail.com>
Date:   Mon, 29 Apr 2019 10:22:51 -0700
From:   Patrick Venture <venture@...gle.com>
To:     Olof Johansson <olof@...om.net>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>, Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-aspeed@...ts.ozlabs.org, arm-soc <arm@...nel.org>,
        soc@...nel.org
Subject: Re: [PATCH v2] soc: add aspeed folder and misc drivers

On Mon, Apr 29, 2019 at 10:19 AM Olof Johansson <olof@...om.net> wrote:
>
> On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <venture@...gle.com> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof@...om.net> wrote:
> > >
> > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@...om.net> wrote:
> > > >
> > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@...gle.com> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@...gle.com> wrote:
> > > > > > > >
> > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > > currently present into this folder.  These drivers are not generic part
> > > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > > >
> > > > > > > > Signed-off-by: Patrick Venture <venture@...gle.com>
> > > > > > >
> > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > > >
> > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > > Makefile is followed.
> > > > >
> > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > > maintainers are free to take this.
> > > > >
> > > > > Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > >
> > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > > across, I already applied the first.
> > > >
> > > > Patrick: Follow up with incremental patch in case there's any difference.
> > > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > > you respin patches without following up on the previous version. Thanks!
> > >
> > > Not only that, but subthreads were cc:d to arm@...nel.org and some
> > > were not, so I missed the overnight conversation on the topic.
> > >
> > > If this email thread is any indication of how the code will be
> > > flowing, there's definitely need for more structure. Joel, I'm hoping
> > > you'll coordinate.
> >
> > To be honest, this patchset thread was a bit less clear than anyone
> > prefers.  I use get_maintainers to get the initial list, and so adding
> > arm@ or soc@ per a request tells me that perhaps those should be
> > output via that script.
>
> The tools are working as expected, we normally don't take patches
> directly to arm@...nel.org, we let them go in through platform
> maintainers who then send it on to us.

Thanks for clarifying.

>
> > >
> > > I'm with Arnd on whether the code should be in drivers/soc or not --
> > > most of it likely should not.
> >
> > I think the misc drivers for a SoC that are a single user interface
> > that is focused on the use-case that belongs to that SoC only belong
> > in soc/, while if there is something we can do in common -- different
> > story.  If it makes sense to just have misc/aspeed/ instead of
> > soc/aspeed -- would that align more?
>
> Those views are how the "board file hell" started on 32-bit ARM too,
> so we're definitely hesitant to jump to that conclusion without
> knowing more about what's actually anticipated.
>
>
> Do you happen to have an estimate on what kind of drivers are
> needed/anticipated?

There is a UART routing control driver for ASPEED that spawned my push
to soc/aspeed.  The advice on that thread was to put such drivers
there.  There's likely to be a few more control-focused aspeed
drivers.

For Nuvoton, we definitely expect some similar LPC control drivers.
Possibly an LPC snoop driver, similar to aspeed-lpc-snoop.  This
supports the idea of creating some form of bmc subsystem as suggested
above (or in a different thread).

>
>
> -Olof