On Wed, Jul 31, 2013 at 05:29:40PM -0600, Stephen Warren wrote: > On 07/31/2013 04:20 PM, Sergei Shtylyov wrote: > > On 08/01/2013 02:06 AM, Stephen Warren wrote: > ... > >>> That's really horrible design. > >> > >> Yup. Both USB PHY and EHCI controller registers really are interleaved > >> in one range. > > > > But the standard EHCI register space has no holes IIRC, so they can't > > be really that much interleaved as you're describing (unless you have > > some non-standard registers of course)... > > Yes, there are certainly non-standard registers. > > ... > >>> Don't they cause numerous resource conflicts while device nodes > >>> being > >>> instantiated as the platform devices? > > > >> No; the driver knows that the HW is screwy and there's lots of > >> register-range sharing going on, so it simply maps the registers, rather > >> than reserving the physical address range and mapping it. > > > > Yes, it's clear that the driver should take special measures, I was > > asking about the platform device creation phase. What do you see in > > /proc/iomem? > > The drivers don't request the memory region since doing so would cause > conflicts. Hence, the regions don't show up in /proc/iomem. > > This actually isn't that uncommon for DT-based drivers anyway; many use > e.g. of_iomap() which IIRC just looks up the resource and maps it > without registering the usage. Not being uncommon isn't a good argument. The problem with doing this is that it sets a bad example and makes it easier for others to do the same thing. I can see that for some drivers providing a proper abstraction or encapsulation might be more complicated than necessary. But I've also seen this kind of shortcut taken quite often lately and especially often in DT-based drivers. Am I the only one concerned about this development? Thierry
Attachment:
pgpgfc7qZ_bD9.pgp
Description: PGP signature
