[PATCH] tty: serial: msm_serial: Use DT aliases
khilman at kernel.org
Fri Nov 14 09:43:16 PST 2014
Stephen Boyd <sboyd at codeaurora.org> writes:
> On 11/13/2014 04:46 PM, Frank Rowand wrote:
>> On 11/13/2014 11:31 AM, Stephen Boyd wrote:
>>> Sorry, I'm sort of lost. If there are serial aliases in the dts file,
>>> then we should alias all of the serial ports. If there aren't aliases
>>> then we're backwards compatible with the dts we have now and we'll do
>>> dynamic generation. Putting code into the driver to validate that
>>> this is true is not the job of the driver. If anything, it should
>>> validated when the dts file is created. If one day we screw up and
>>> have a dts file with such a bad configuration we'll have to work
>>> around it, but until that day comes I'd rather not think about it.
>> Maybe I did not understand when you said "Perhaps we should use an ida".
>> That sentence led me to think the driver should check for misconfiguration.
>> The case I was trying to handle was if there was at least one serialN
>> alias and at least one UART without an alias. For example, if there
>> are three UARTs (serial_a, serial_b, serial_c, probed in that order)
>> and one alias (serial0 = &serial_c;) then the result would be:
>> serial_a line 0 (from msm_uart_next_id)
>> serial_b line 1 (from msm_uart_next_id)
>> serial_c line 0 (from the alias)
>> Two UARTs probed with line == 0. This is an error.
>> Most of the serial drivers don't check for this type of bad configuration.
>> Some drivers keep a bit map of which lines have been used. I'm not sure
>> what they do in case of a conflict (I did not read to that level of detail).
>> I thought you were suggesting the driver check for the bad configuration,
>> so I was proposing a somewhat simple way of forcing a boot error for the
>> bad configuration.
>> Since you are not suggesting the driver check for the bad configuration,
>> you can ignore my proposal. I agree that it is ok for the driver to
>> expect the board dts to be correct. The problem should be detected by
>> the dts author on first boot as part of normal bring up testing, and
>> then corrected.
> Ah ok. I was just saying we could use an ida instead of an atomic
> increment so that this driver works properly with driver
> binding/unbinding, otherwise the line number keeps increasing and
> quickly goes beyond the static array of ports (which I still don't
> understand why we have at all btw).
Due to the length of the thread, I haven't followed all the details, and
I suspect Greg hasn't either, so I'm not sure if you're discssuing what
the right fix is for what's in -next (still broken, or what should be done
with the device board files.
If the fix from earlier in this thread is still the right one for fixing
-next, could you repost it separately for Greg to queue/squash and for
me to re-test (if needed.)
More information about the linux-arm-kernel