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: <20131219204452.GA13301@kroah.com>
Date:	Thu, 19 Dec 2013 12:44:52 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Scott Wood <scottwood@...escale.com>
Cc:	Kim Phillips <kim.phillips@...aro.org>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	R65777@...escale.com, B07421@...escale.com, B08248@...escale.com,
	christoffer.dall@...aro.org, alex.williamson@...hat.com,
	a.motakis@...tualopensystems.com, agraf@...e.de,
	B16395@...escale.com
Subject: Re: [REPOST][PATCH 2/2] driver core: platform: allow platform
 drivers to bind to any device

On Thu, Dec 19, 2013 at 02:29:21PM -0600, Scott Wood wrote:
> On Wed, 2013-12-18 at 17:03 -0800, Greg Kroah-Hartman wrote:
> > On Tue, Dec 03, 2013 at 12:34:54PM +0000, Kim Phillips wrote:
> > > Platform drivers such as the vfio-platform "meta-" driver [1]
> > > should be allowed to specify that they can bind to any device,
> > > much like PCI drivers can with PCI_ANY_ID.
> > > 
> > > Currently, binding platform drivers to devices depends on:
> > > 
> > > - a string match in the device node's compatible entry (OF)
> > > - a string match in the ACPI id list (ACPI)
> > > - a string match in the id_table (platform data)
> > > - a string match on the driver name (fall-back)
> > > 
> > > none of which allow for the notion of "match any."
> > > 
> > > This patch adds the notion by adding a "match any device" boolean to
> > > struct platform_driver, for drivers to be able to set and thus not cause
> > > platform_match() to fail when a bind is requested.
> > > 
> > > [1] http://www.spinics.net/lists/kvm/msg96701.html
> > > 
> > > Signed-off-by: Kim Phillips <kim.phillips@...aro.org>
> > > ---
> > > rebased onto 3.13-rc2, and reposted from first submission which
> > > received no comments:
> > > 
> > > https://lkml.org/lkml/2013/10/11/48
> > > 
> > >  drivers/base/platform.c         | 4 ++++
> > >  include/linux/platform_device.h | 1 +
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > index 3a94b79..78a5b62 100644
> > > --- a/drivers/base/platform.c
> > > +++ b/drivers/base/platform.c
> > > @@ -736,6 +736,10 @@ static int platform_match(struct device *dev, struct device_driver *drv)
> > >  	struct platform_device *pdev = to_platform_device(dev);
> > >  	struct platform_driver *pdrv = to_platform_driver(drv);
> > >  
> > > +	/* the driver matches any device */
> > > +	if (pdrv->match_any_dev)
> > > +		return 1;
> > 
> > This breaks userspace in that it will never know to load the module that
> > can "bind to anything".
> > 
> > You need a way to encode this in the platform device id that can be a
> > wildcard type of thing, so that userspace can know about this.
> 
> How is userspace broken?  vfio platform is a new thing; there's nothing
> existing to break.  I don't see how automatic module loading makes sense
> for it.  Whether the module needs to be loaded depends on the user's
> intentions, not based on what hardware you have.

As your driver is saying it can "match any device", you need to tell
userspace that, which you aren't doing here.  That's what the ids that
are exported to userspace do, please add some for platform devices to
allow this to work properly, like almost all other busses have.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ