Re: [PATCHv5] serial-uartlite: Remove ULITE_NR_PORTS macro

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

 



Hi Johan,

On 15. 11. 19 9:21, Michal Simek wrote:
> Hi Johan,
> 
> On 13. 11. 19 16:38, Johan Hovold wrote:
>> On Wed, Nov 13, 2019 at 12:00:08PM +0000, shubhrajyoti.datta@xxxxxxxxx wrote:
>>> From: Shubhrajyoti Datta <shubhrajyoti.datta@xxxxxxxxxx>
>>>
>>> This patch is removing ULITE_NR_PORTS macro which limits number of
>>> ports which can be used. Every instance is registering own struct
>>> uart_driver with minor number which corresponds to alias ID (or 0 now).
>>> and with 1 uart port. The same alias ID is saved to
>>> tty_driver->name_base which is key field for creating ttyULX name.
>>>
>>> Because name_base and minor number are setup already there is no need to
>>> setup any port->line number because 0 is the right value.
>>>
>>> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xxxxxxxxxx>
>>> Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx>
>>> ---
>>> v4: patch addition
>>> v5: Merge the patch so that all the patches compile
>>
>> Greg, 
>>
>> Please do not merge this. This is a hack which really needs to be
>> reconsidered as I've pointed before
>>
>> 	 https://lkml.kernel.org/r/20190523091839.GC568@localhost
> 
> I think it is quite a good time to start to talk about it.
> Over the time I am aware about only one issue related to one way how to
> handle console which came recently. I was looking at it 2 weeks before
> ELCE but I need to get back on this.
> Anyway I am ready for discussion about it.
> What was said so far is that we shouldn't add Kconfig option for number
> of uarts. We could maybe hardcode any big number in the driver as is
> done for pl011 but still it is limitation and wasting of space for
> allocation structures which none will use.
> Then I have done this concept and it was merged where struct uart_driver
> is allocated for every instance separately and I really tried to get
> feedback on this as we discussed some time ago.
> 
> Anyway we are where we are and if this needs to be fixed then please
> tell me how you think that this should be solved.

any comment?

M



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux