Hi > On Oct 29, 2014, at 12:14 , Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Wed, Oct 29, 2014 at 10:40:37AM +0200, Pantelis Antoniou wrote: >> Dynamically inserting spi device nodes requires the use of a single >> device registration method. Rework and export it. >> >> Methods to lookup a device/master using a device node are added >> as well, of_find_spi_master_by_node() & of_find_spi_device_by_node(). > > Why do we need to do this - I would expect that adding nodes would > trigger parsing in the same way we normally do it. Where is the user > and how does it know that it's handling a SPI node? > > This feels like there is an abstraction problem somewhere, whatever code > is supposed to use this is going to need to be taught about each > individual bus which is going to be tedious, I would expect that we'd > have something like the bus being able to provide a callback which will > get invoked whenever a new node appears on the parent node for the bus. > There’s a whole patchset that does exactly this. Look at "OF: spi: Add OF notifier handler” and you’ll where this is used. >> Changes since v1: >> * Brown paper bug with parameter on of_register_spi_device(). > > Don't include noise like this in the changelog, put it after --- like > SubmittingPatches says. Please also try to keep your CC list sane, > CCing random people just means that you're increasing the volume of mail > they have to process. I'm surprised kernel.org accepts so many CCs. > > I have to say I don't recall ever seeing v1... All of them are in the CC list for a reason. Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
