linux-kernel - Re: [patch 2.6.30-rc3] platform_bus: remove "which platform

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: <200904280228.07346.david-b@pacbell.net>
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/