> I am not saying that config option is perfect solution. It is at least > aligned with 5 others serial drivers in the tree. And the fact people keep doing hacks jutifies continuing to make a mess. Especialy as in this case it's entirely theoretical. Nobody has produced actual hardware that hits the limit. Nobody has filed a bug, nobody is impacted. Creating extra CONFIG_ entries for junk like this is ridiculous, most of the others at least have the excuse of being old code. Generally it is better to call uart_register_driver from the probe method because that way you don't waste time and memory registering drivers for stuff that isn't even present however if you have no idea how many devices there might be then you still really need to pass a suitable limit and handle it internally dynamically allocating as needed. If someone was hitting this in the real world and you posted a patch that just changed the constant to 8 or 16 or whatever was needed I wouldn't care too much, but adding CONFIG_ entries just makes stuff harder and harder to config and more and more impossible to keep generic. I keep hearing that the ARM folks are trying to get one unified kernel. CONFIG_ options is not how to do that. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
