On Thu, Oct 8, 2009 at 9:10 AM, Anton Vorontsov <avorontsov@xxxxxxxxxxxxx> wrote: > On Thu, Oct 08, 2009 at 08:53:46AM -0600, Grant Likely wrote: > [...] >> Please don't. It is such a small amount of code, > > It's *always* a small amound of code, at a start. Then we get > floppy disk drivers and the tty layer. ;-) Holy straw man argument Batman! But the focus is still on creating pdata. If a translator gets too big, then sure, split it into a separate file. Until then, there I see no good reason to do so now. > > [...] >> Driver writers shouldn't have to >> write anything more than a tiny function to populate pdata from the >> device tree. Managing that pdata instance needs to be done with >> common infrastructure (but I don't have a firm idea about how it >> should look yet). In the mean time I think Wolfram's approach has >> lower impact. > > If I wasn't a PPC/OF guy to some degree, I'd hate PPC/OF people > for bringing arch-specific details into a generic code... :-P No, this goes beyond PPC/OF. The real issue is that it is no longer a safe assumption that pdata will be a static data structure in platform code. The number of possible data sources is going to get larger, not smaller. OF is just one. UEFI is another. Translating that data into pdata will be the problem that comes up over and over again. However, translation code is still driver specific, so it belongs with the driver that it translates code for. So, in my opinion, translation code must: 1. be *tiny* -- should be trivial to add to a driver without impacting common code 2. live with the driver that it translates data for; ideally in the same .c file for drivers that are small. > No matter how small the OF code is, I believe we shouldn't put it > into the generic code. Take a look at mmc_spi case again, it can be > easily extended to any arch, because there is no arch-specific stuff, > but a "get/put" pattern for platform data. I'm not disagreeing with you that the arch specific stuff should be logically separated from the generic code. But I don't agree that it belongs in a separate file. And I also think that the mmc_spi implementation uses too much code. There must be a better way. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
