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

From: Arnd Bergmann <arnd@arndb.de>
To: Joel Stanley <joel@jms.id.au>
Cc: linux-aspeed@lists.ozlabs.org, Andrew Jeffery <andrew@aj.id.au>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	soc@kernel.org, arm-soc <arm@kernel.org>,
	Patrick Venture <venture@google.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] soc: add aspeed folder and misc drivers
Date: Mon, 29 Apr 2019 10:07:28 +0200	[thread overview]
Message-ID: <CAK8P3a3CK4o8KnD6M084ULEmm+6_CtNFqYHjSqE5vp+U9YAmkA@mail.gmail.com> (raw)
In-Reply-To: <CACPK8XemgKvM38wDSUJsXXeK51dwmeUoKWn+e3ZNHd9v5VBZHA@mail.gmail.com>

On Mon, Apr 29, 2019 at 9:49 AM Joel Stanley <joel@jms.id.au> wrote:
>
> On Thu, 25 Apr 2019 at 17:25, Greg KH <gregkh@linuxfoundation.org> 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@google.com> wrote:
> > > >
> > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@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@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.
>
> I was on the fence about this. The downside of moving drivers out of
> drivers/misc is it allows SoCs to hide little drivers away from
> scrutiny, when in fact they could be sharing a common userspace API
> with other BMCs.  (Keep an eye out for the coming Nuvoton "bios post
> code" driver which is very similar to
> drivers/misc/aspeed-lpc-snoop.c).

Things like this should usually find a different home: drivers/misc
tends to be for one-of-a-kind stuff with a user interface, not for things
where you have multiple chips doing the same thing.

If you think there are going to be additional cases where you have
more than one bmc in need of a user interface for the same
functionality, we could introduce a drivers/bmc/ subsystem and
have a set of user interfaces backed by a set of chip specific
drivers.

> However, in the effort to move away from BMC that are full of shell
> scripts that bash on /dev/mem, we are going to see a collection of
> small, very SoC specific, drivers and it doesn't make sense to clutter
> up drivers/misc.
>
> Acked-by: Joel Stanley <joel@jms.id.au>
>
> The p2a driver has been merged by Greg. We should move that one over
> too. Arnd, can you advise Patrick on how to proceed? We could have him
> spin a v3 that includes the p2a driver, but it would depend on Greg's
> char-misc-next branch.

I don't think there is a rush here, so let's do that for the following
merge window.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel