mtdpart: memory accessor interface for MTD layer
in [Kernel]
|
Prev: [PATCH v3] firewire: cdev: check write quadlet request length to avoid buffer overflow
Next: [PATCH V4 0/5] Add MMC erase and secure erase V4
From: David Brownell on 7 Jul 2010 07:10 > > > This patch adds two new members to the > mtd_partition structure, > > > a function handler which will be > > > called during setup of the > > > partition and an argument to be passed to this > setup function. > > > > Ick. > > > > I don't mind providing the mtd_macc_{read,write} > helper functions, > > although they should work on generic MTD > > >devices not just on partitions. > > But do we really have to do the callout to > > arbitrary functions from > > _within_ the core MTD code... why can't we > > do that in the board driver? I think the short answer is that the callout is what provides the board drivers enough information to make the correct calls. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on 8 Jul 2010 12:10 > > I think the short answer is that the callout is > > what provides the board drivers enough information > > to make the correct calls. > > > > If you agree to what the patch is doing, then can you Ack it? Iff it's resent; it's not in my mbox any more. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Woodhouse on 4 Aug 2010 06:20 On Wed, 2010-07-07 at 04:08 -0700, David Brownell wrote: > > I think the short answer is that the callout is > what provides the board drivers enough information > to make the correct calls. I don't see how. The only information it passes to the callout is the information it was already *given* in the partition structure. I'm more inclined to believe Sudhakar's claim that you'll get an 'initialization sequence problem', although I'm not sure I believe it can't be solved in a better way than this. I'm also unhappy that it only works on partitioned devices -- that seems wrong. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on 4 Aug 2010 06:40 --- On Wed, 8/4/10, David Woodhouse <dwmw2(a)infradead.org> wrote: > On Wed, 2010-07-07 at 04:08 -0700, > David Brownell wrote: > > > > I think the short answer is that the callout is > > what provides the board drivers enough information > > to make the correct calls. EMPHASIS ON "CORRECT" ... > I don't see how. > > The only information it passes to the callout is the > information it was > already *given* in the partition structure. There can be multiple such structures, each of which describes different data to be extracted from different persistent media contexts. Examples: one context holds one MAC address (and another, a different one) ... another might embed calibration data; another, serial numbers; etc. Pass the wrong context around, you've trashed all the data instead of getting it right. > I'm more inclined to believe Sudhakar's claim that you'll > get an > 'initialization sequence problem', although I'm not sure I > believe it > can't be solved in a better way than this. "Initialization sequence" is a grab-bag category that covers most init issues. Point is to ensure that enough of the right context information is available to initialize correctly. So the right data is extracted and passed on. > > I'm also unhappy that it only works on partitioned devices > -- that seems wrong. Very different issue. Seems easily fixable if needed. Agreed that e.g. EEPROMS won't often be partitioned (unlike flash). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Woodhouse on 4 Aug 2010 07:10
On Wed, 2010-08-04 at 03:31 -0700, David Brownell wrote: > Point is to ensure that enough of the right context > information is available to initialize correctly. > So the right data is extracted and passed on. Forgive me if I'm being dim (and in particular, please forgive me if I'm going over something that was already discussed; I know it's been a while). But I don't see why it needs to be passed through the core MTD code. To take the simple case of an unpartitioned MTD device -- why can't the map driver (or whatever) just call the maccessor setup function for itself, directly, right after calling add_mtd_device() with its newly-probed MTD device? And for partitions, why can't it do the same, on the appropriate partition. OK, the answer to the latter question is that you don't actually *have* the pointers to each partition you register. But that's easily fixed. If we make add_mtd_partitions() take an extra 'struct mtd_info **' argument and put pointers to the slave mtd 'devices' into that, it means that your board driver *can* reliably get the mtd pointer for the fourth partition, or whatever it needs. And can then just do the memory accessor setup for itself. Isn't that enough? -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |