[PATCH 10/12] tty: amba-pl011: add support for 32-bit register access

[peter@hurleysoftware.com (Peter Hurley)]

On 11/16/2015 01:30 PM, Russell King - ARM Linux wrote:
> On Mon, Nov 16, 2015 at 12:25:45PM -0600, Timur Tabi wrote:
>> How is it touching core files?  Granted, we might still need access_32b in
>> vendor_data, but not for SBSA, since SBSA already has a mechanism to
>> determine what 32-bit is needed or not.
>>
>> Then in pl011_probe(), just have:
>>
>> 	uap->port.iotype = vendor->access_32b ? UPIO_MEM32 : 0;
> 
> That fails my sanity filters, sorry.  iotype takes these values, and
> these values only:
> 
> #define UPIO_PORT               (SERIAL_IO_PORT)        /* 8b I/O port access */#define UPIO_HUB6               (SERIAL_IO_HUB6)        /* Hub6 ISA card */
> #define UPIO_MEM                (SERIAL_IO_MEM)         /* 8b MMIO access */
> #define UPIO_MEM32              (SERIAL_IO_MEM32)       /* 32b little endian */
> #define UPIO_AU                 (SERIAL_IO_AU)          /* Au1x00 and RT288x type IO */
> #define UPIO_TSI                (SERIAL_IO_TSI)         /* Tsi108/109 type IO */#define UPIO_MEM32BE            (SERIAL_IO_MEM32BE)     /* 32b big endian */
> 
> These are exposed to userspace, and they have meaning.
> 
> We _could_ augment include/uapi/linux/serial.h and
> include/linux/serial_core.h to add a 16-bit LE MMIO accessor identifier,
> but hacking it by deciding to re-use SERIAL_IO_PORT for something it
> isn't is abhorrent to me.


The UPIO_* comments were added recently.

The proliferation of different bitness and endianness implied that
UPIO_MEM was strictly 8-bit, but that's not true and I'll remove the
UPIO_MEM bitness notation from the header.

The uapi header has no such notation and I think the original value and
meaning of UPIO_MEM used by the pl011 driver should remain.

I see no real issue with using different iotype values to describe
the register access method required when other than what the driver
originally used.

Regards,
Peter Hurley