Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I had earlier submitted a patch [1] to remove the hard coded
> major/minor number for Samsung UART driver, but that was rejected
> because of userspace breakage. Without this patch, Samsung UART driver
> can't bind to the hard-coded device node. Changing the default
> major/minor will also not help to fix the objections raised in [1].
> 
> Would you please suggest a way forward?
> 
> [1] https://lkml.org/lkml/2013/12/27/2

The dynamic major/minor is the right patch. If the userspace breaks then
the userspace was broken, but I see no evidence in the discussion that
the userspace broke.

204,64 belongs to Altix so neither of the clashing drivers should use it.
We had a table to stop messes like this, and we have dynamic numbering
to stop the table being needed for the future

           50 = /dev/ttyIOC0              Altix serial card
                    ...
           81 = /dev/ttyIOC31             Altix serial card


Thats what the list says. Samsung should have followed the rules, they
didn't so they get to pick up the pieces. The Amba driver wants moving as
well. It's easy. If you want something to be ABI then make sure you get
it upstream first, if not you get to own all the pain down the line.

Hacking up the core code to paper over this crap is not on. We've been
insisting firmly and robustly for years that people don't keep borrowing
names and numbers they are not allocated, and use dynamic values whenever
possible.

If the hardware isn't present then the driver shouldn't even register
with the tty layer in the first place so it doesn't make any resource
differeneces either for properly written code.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux