On Wed, Nov 26, 2014 at 2:34 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > On 11/26/2014 08:33 AM, Grant Likely wrote: >> On Tue, 25 Nov 2014 15:37:16 -0800 >> , Kevin Cernekee <cernekee@xxxxxxxxx> >> wrote: >>> On Tue, Nov 25, 2014 at 12:34 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>>> On Wed, Nov 12, 2014 at 12:53:58PM -0800, Kevin Cernekee wrote: >>>>> From: Tushar Behera <tushar.behera@xxxxxxxxxx> >>>> >>>> This email bounces, so I'm going to have to reject this patch. I can't >>>> accept a patch from a "fake" person, let alone something that touches >>>> core code like this. >>>> >>>> Sorry, I can't accept anything in this series then. >>> >>> Oops, guess I probably should have updated his address after the V1 >>> emails bounced... >>> >>> Before I send a new version, what do you think about the overall >>> approach? Should we try to make serial8250 coexist with the other >>> "ttyS / major 4 / minor 64" drivers (possibly at the expense of >>> compatibility) or is it better to start with a simpler, cleaner driver >>> like serial/pxa? >> >> Co-existing really needs to be fixed. > > What are the requirements for co-existence? > Is it sufficient to provide 1st come-1st served minor allocation? Should be sufficient. Basically, if the hardware doesn't exist, the driver shouldn't be trying to grab the minor numbers. Also, on hardware where both exists, there should be some sane fallback so that all UARTs get assigned numbers. On DT systems we can also use /aliases to ensure consistent assignment of numbers. g.
