Re: [PATCH 0/4] Drop legacy support for omap3517

From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: "Pali Rohár" <pali.rohar@gmail.com>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Aaro Koskinen" <aaro.koskinen@iki.fi>,
	"Tony Lindgren" <tony@atomide.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Pavel Machek" <pavel@ucw.cz>,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH 0/4] Drop legacy support for omap3517
Date: Mon, 26 Jan 2015 11:16:58 +0100	[thread overview]
Message-ID: <3668717.H6LOeCvYZ4@wuerfel> (raw)
In-Reply-To: <201501242314.58201@pali>

On Saturday 24 January 2015 23:14:58 Pali Rohár wrote:
> On Saturday 24 January 2015 23:08:00 Arnd Bergmann wrote:
> > On Saturday 24 January 2015 13:00:00 Pali Rohár wrote:
> > > Another regression for DT setup (which does not occur for
> > > board code):
> > > 
> > > omap_hsmmc driver does not export slot_name sysfs entry
> > > because it not supported by DT yet. Entry slot_name is used
> > > by userspace application to determinate if mmc block device
> > > is internal eMMC memory or external uSD card. So support
> > > for this property also in DT is needed.
> > 
> > > Here is simple patch which fix this problem:
> > The sysfs file only exists for the two OMAP drivers, and the
> > naming is used only by board-n8x0, board-rx51 and
> > board-omap3logic.
> > 
> > It may be better to add a board-specific hack for these to
> > keep the existing user space working but not spread the use
> > of this file anywhere else.
> 
> Why? omap_hsmmc.c has already support for slot_name sysfs entry, 
> just it is not filled from DT data (only from platform_data)...

It's a highly nonstandard interface, none of the other controllers
support it, and even changing the the other omap machines to use
the same strings might break existing user space that might rely
on whatever gets printed in those properties today.

We should limit the use of those strings to the boards that
are known to run software that requires them to avoid regressions.
We could also define a standard way of finding out whether an
mmc device is removable. We already have the MMC_CAP_NONREMOVABLE
flag in the kernel and could have a read-only boolean attribute
in sysfs for it.

Putting a "name" property into DT because some random user space
requires a particular name to show up in sysfs however does not
seem a legitimate hardware description.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html