On Thu, 7 Feb 2013 10:32:13 +0000, James Hogan <james.hogan@xxxxxxxxxx> wrote: > On 06/02/13 14:28, Grant Likely wrote: > > On Wed, Feb 6, 2013 at 1:32 PM, James Hogan <james.hogan@xxxxxxxxxx> wrote: > >> On 06/02/13 13:11, Grant Likely wrote: > >>> - Resources on platform_devices get registered so they appear in > >>> /proc/iomem and /proc/ioports and so that device drivers get the added > >>> protection of request_region. This will cause breakage on device trees > >>> nodes with partially overlapping memory regions. (ie. 0x100..0x1ff and > >>> 0x180..0x27f). I also have a workaround for this, but I doubt that it > >>> will be necessary. > >> > >> Hi Grant, > >> > >> If I understand you correctly, the non-overlapping memory regions thing > >> could be a problem for me. We have a Meta based SoC that has various SoC > >> registers grouped together for doing GPIOs and Pin control things. I'm > >> still in the process of converting it to device tree, but the way I've > >> been handling it is to provide overlapping registers to both the gpio > >> and pinctl DT nodes. Each GPIO bank's registers are also interleaved > >> with the others, so I've been providing overlapping register ranges > >> (offset by 4 for each bank) to the DT node for each gpio bank too, so > >> each bank can function independently and the driver doesn't have to > >> worry about multiple banks. Does that sound like a reasonable use case? > >> > >> I guess I could cheat with the length, or specify each register in it's > >> own memory resource, but it seems like overkill. > > > > Note that overlapping regions are fine /provided/ that they are the > > same size or one fits nicely inside another. It's partial overlap that > > is a problem > > It still feels a bit artificial to impose that limitation on something > that is supposed to be implementation independent. Having said that it > doesn't particularly bother me having to work around it. I've backed out on this. It broke too much. g. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
