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). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
