Re: [PATCH 2/2] tty: serial: bcm63xx: Allow device nodes to be renamed to /dev/ttyBCM*

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, Nov 10, 2014 at 10:30 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Nov 10, 2014 at 07:05:14AM -0800, Kevin Cernekee wrote:
>> On Mon, Nov 10, 2014 at 6:25 AM, Rob Herring <robh@xxxxxxxxxx> wrote:
>> > On Sun, Nov 9, 2014 at 2:55 AM, Kevin Cernekee <cernekee@xxxxxxxxx> wrote:
>> >> By default, bcm63xx_uart.c uses the standard 8250 device naming and
>> >> major/minor numbers.  There are at least two situations where this could
>> >> be a problem:
>> >>
>> >> 1) Multiplatform kernels that need to support some chips that have 8250
>> >> UARTs and other chips that have bcm63xx UARTs.
>> >>
>> >> 2) Some older chips like BCM7125 have a mix of both UART types.
>> >>
>> >> Add a new Kconfig option to tell the driver whether to register itself
>> >> as ttyS or ttyBCM.  By default it will retain the existing "ttyS"
>> >> behavior to avoid surprises.
>> >
>> > While I understand the desire to have stable names, this is the
>> > opposite direction we want to go. Per platform tty names complicates
>> > having a generic userspace. It is not so bad since most ARM platforms
>> > use ttyS or ttyAMA, but just think what the kernel and userspace side
>> > would look like if every single platform did this. We can't change
>> > everything to ttyS because the other names are already an ABI.
>> >
>> > This can be solved with a udev rule to create sym links.
>>
>> Is it safe to register two console drivers named "ttyS" with the same
>> major/minor numbers?
>
> Not at all, think about what you are asking for here.
>
> Is the kernel allowed to register two block devices with the same
> major/minor numbers?

So, is there a recommended solution for building a multiplatform
kernel that includes more than one serial driver that wants to claim
major 4, minor 64?  Let's start with the easy case (#1 from above):
only one of the drivers actually has a DT entry and gets probed.

Browsing around drivers/tty/serial I identified several other drivers
that use 4/64: apbuart, dz, ip22zilog, m32r_sio, mcf, mrst_max3110,
pxa, sunhv, zs.  Unfortunately none of these seem to be built as part
of ARM's MULTI_V7 kernel.

My other idea was to keep using "ttyS" for bcm63xx_uart, but remove
the major/minor numbers from the driver code so the kernel
auto-assigns them.  In this case I also need to set
CONFIG_SERIAL_8250_RUNTIME_UARTS=0 to prevent the 8250 driver from
creating ttyS[0-3] on its own, and then I'll need to retest the 8250
based platform to make sure it didn't break.  Does that sound
plausible?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux