On Sun, May 20, 2012 at 2:21 AM, Mark Brown <[email protected]> wrote: > On Fri, May 18, 2012 at 03:03:31PM +0530, Thomas Abraham wrote: > >> - s3c64xx_spi0_set_platdata(&s3c64xx_spi0_pdata, 0, 1); >> + s3c64xx_spi0_set_platdata("s3c6410-spi", NULL, 0, 1); > > ... > >> + pd.src_clk_nr = src_clk_nr; >> + pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio; >> + s3c64xx_device_spi0.name = dev_name; > > This looks *really* strange. Why do we need to pass in a name to set in > s3c64xx_device_spi0's name, why would we want to use a different name? > This dev_name also isn't equivalent to dev_name() which makes matters > more confusing than they need to be. > > There was similar code for the I2C controllers which caused some really > hard to debug brittleness.
Looks like they use the name as the magic string to pick initialization data. I wonder if it makes more sense to keep the platform_data still around, and just fill it in with the table (from patch "spi: s3c64xx: move controller information into driver data") based on the OF compatible field for the device-tree probe case, instead of trying to overload and having to change the name in this way. -Olof ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
