On 1 July 2012 17:40, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Sun, Jul 01, 2012 at 05:28:16PM +0530, Jassi Brar wrote: >> On 1 July 2012 16:29, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: >> > On Sun, Jul 01, 2012 at 12:44:01PM +0200, Alessandro Rubini wrote: >> >> How should I address the problem? (original code, published on >> >> sourceforge was simply replicating a number of amba drivers into pci >> >> drivers, but I don't think massive code duplication is ever sensible, >> >> thus I preferred to reuse the existing drivers). >> > >> > I think the answer is... those primecell drivers need fixing in some way. >> > Re-defining CS, DS and ES in drivers is rather silly given that they're >> > x86 segment register names - so if PL330 can be fixed to make its names >> > more specific, that sorts it out. >> > >> I am OK prefixing the regs with PL330_ or somesuch. >> >> The CS, DS and ES regs were named so as to match exactly the >> terminology of the PL330 manual. So apparently even the ARM Ltd didn't >> imagine ARM and X86 galaxies colliding so soon :) > > Whatever it says in documentation is neither here nor there. We're humans, > we can re-interpret, and we are capable of adding prefixes to names when > they're stupidly chosen. > > Notice how I added MMCI_ and MCI_ to the register definitions for PL180 > for example. I always do that kind of thing as a rule to avoid these kinds > of problems right from the outset, and I don't understand why others don't > do the same. We've been through soo many "this symbol clashes with > something else in the kernel tree" now that we really should be doing this > automatically, and not waiting for the clash to happen. > I fully agree with your point and IIRC I always add some prefix to definitions in header files. Private defines in a .c file, without redundant prefixes, sounded like safe to me at the time, but perhaps I was wrong. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
