Stephen Boyd <sboyd@xxxxxxxxxxxxxx> 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[1], 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.) Thanks, Kevin [1] http://lists.linaro.org/pipermail/kernel-build-reports/2014-November/006298.html -- 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
