[PATCH v2] soc: add aspeed folder and misc drivers

[Olof Johansson]

On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <venture at google.com> wrote:
>
> On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof at lixom.net> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof at lixom.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 at google.com> wrote:
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture at google.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 at google.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 at linuxfoundation.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 at kernel.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 at kernel.org, we let them go in through platform
maintainers who then send it on to us.

> >
> > 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?


-Olof