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 9:05 AM, Kevin Cernekee <cernekee@xxxxxxxxx> 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?  Maybe there is a trick to making them coexist?

No, but I think you can do dynamic minor numbers. I seem to recall
this coming up with the Samsung UARTs a while back.

Rob

> What I found is that everything worked fine on a system with
> bcm63xx_uart hardware until I enabled the 8250 driver in .config.  At
> that point the drivers clashed and I had no serial output
> post-bootconsole.  It didn't even get to userland before it failed.
> There are no DT entries mentioning 8250; the mere presence of the 8250
> driver killed my console.
>
> If this behavior is unexpected I can keep digging to find out what went wrong.
>
>> Or if you
>> just need to know which dev node is h/w uart X, you can get that from
>> sysfs.
>
> Right - I use busybox cttyhack in the init scripts to figure out the
> console name, so the same rootfs image can be used for both ttyS0 and
> ttyBCM0:
>
> # Put a shell on the serial port
> ::respawn:/bin/cttyhack /bin/sh -l
--
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