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

Peter Hurley peter at hurleysoftware.com
Mon Nov 16 13:18:19 PST 2015


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



More information about the linux-arm-kernel mailing list