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

[Patrick Venture]

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.

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

>
>
> -Olof