Hi Michal, On Sun, 2008-05-11 at 16:01 +0200, Michal Simek wrote: > I have started to use uartlite driver which is in Linus tree. > I look at history and differences between my ancient version and new one. > I found one "insensible" commit from Grant with ACK from Josh and John and one > revert of this. > > This commit a15da8eff3627b8368db7f5dd260e5643213d918 (description below) is > trying to fix problem 32bit access to ulite registers. You change 8bit access to > 32bit (and commit 077b50c29a7e8be5812d1156934ea837b712ca6) reverts changes back. > > "Magic offset" is not magic it is normal - because there is normal big endian > mess where readb and writeb read first byte from big endian but uartlite > registers have are on the last byte -> this mean that magical offset +3. > > goto next; > > [POWERPC] Uartlite: Fix reg io to access documented register size > The Uartlite data sheet defines the registers as 32 bit wide. This > patch changes the register access to use 32 bit transfers and eliminates > the magic +3 offset which is currently required to make the device > work. > > [POWERPC] Uartlite: Revert register io access changes > Reverts commit a15da8eff3627b8368db7f5dd260e5643213d918 > This driver is used by devices other than the xilinx opb-uartlite which > depend on bytewise access to the registers. The change to 32 bit access > does not work on these devices. The uartlite register set is 32 bits wide - that's what the datasheet says, and that's how we should interact with it. I really don't understand why this commit was reverted. Who uses the uartlite driver for anything other than the uartlite? Magic +3 offsets anywhere are a bad idea - I agree having addresses like 0x40100003 in the kernel log for base addresses is stupid, but I don't like a +3 offset in the platform code either. Why can't we use the device as documented, with 32 bit wide accesses? Regards, John -- 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
