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]
Date:	Tue, 28 Apr 2009 02:28:07 -0700
From:	David Brownell <david-b@...bell.net>
To:	Greg KH <greg@...ah.com>
Cc:	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2.6.30-rc3] platform_bus:  remove "which platform_data?" confusion

No comment on the bugfix part of $SUBJECT patch?


On Monday 27 April 2009, Greg KH wrote:
> 
> > Those patches seem to support what I think is a misguided
> > notion:  that somehow device.platform_data might move into
> > the platform_device.  The problem with that idea is that it's
> > a general purpose hook, and is used by other busses to provide
> > board-specific configuration data ... not just for platform_bus.
> 
> It is?  What other busses do this?

SPI and I2C come quickly to mind...

Basically, *any* bus that could ever be used on an embedded
system may need platform_data to explain how each discrete
chip has been wired up on that particular board.  Very few
such busses can self-enumerate like PCI or USB.  And most of
the chips sitting on such busses expect to interface to fairly
random external hardware.

And come to think of it, I've seen cases with PCI and USB
where board-specific config data is needed.  PCI doesn't
always wrap it up in some ACPI bytecode, and sometimes USB
devices use "transceiverless link" hookup, so the board
can just hook up using a differential pair.

SDIO/MMC doesn't tend to need it though, even for SDIO
WLAN or MMC/SD storage links (eMMC, CE-ATA, etc).


> And why, can't they use their own bus private data pointers?

ENOPATCH.  ;)

Though ... since devices on *any* bus may need this, I
don't much see the point of modifying every bus like that.

- Dave



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