Hi Geert, On Mon, Apr 16, 2012 at 9:42 PM, Geert Uytterhoeven <[email protected]> wrote: > On Mon, Apr 16, 2012 at 09:50, Michael Schmitz > <[email protected]> wrote: >>> | #define rom_out_be16(addr, w) ({u16 __w, __v = (w); __w = ((*(__force >>> volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); }) >>> | #define rom_out_be32(addr, l) ({u32 __w, __v = (l); __w = ((*(__force >>> volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); }) >>> | #define rom_out_le16(addr, w) ({u16 __w, __v = cpu_to_le16(w); __w = >>> ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); }) >>> | #define rom_out_le32(addr, l) ({u32 __w, __v = cpu_to_le32(l); __w = >>> ((*(__force volatile u32 *) ((addr) + 0x10000 + (__v<<1)))); }) >>> >>> The above four also can't work. Remove them? >> >> Probably - not sure what the behavior will be if writing more than one byte >> (might not be safe to use). Using dummies (potentially to generate compiler >> warnings or runtime warnings) might be safer. > > As soon as the value you're writing is bigger than 0x7fff, you'll get out of > the > 64 KiB write window.
That's correct - on the ISA side only eight bits are wired up anyway so ((addr) + 0x10000 + (( __v & 0xFF )<<1)) is making sure we only write what's possible to write. The only side effect of the le[16,32] versions is to put a different byte in the one-byte write aperture. That's purely academic so let's lose it. As Andreas has confirmed, there's no way the adapter hardware could be extended to write full 16 bit words even if the design was changed to use the full data bus width (by using tri-state latches so the same ISA data lines can be wired to both data and address lines of the ROM port, possibly) - since we need the A0 bit as read/write select we only have 15 address bits left for writes. Does this make sense? Either way, we only need byte reads and writes so please remove the rest. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
