Re: [PATCH 2/4] ns16550: enable Pericom controller support

["Jan Beulich" <JBeulich@suse.com>]

>>> On 11.03.16 at 03:31, <konrad@kernel.org> wrote:
> On Wed, Mar 09, 2016 at 10:01:08AM -0700, Jan Beulich wrote:
>> >>> On 09.03.16 at 17:52, <konrad.wilk@oracle.com> wrote:
>> > On Tue, Mar 08, 2016 at 01:48:05AM -0700, Jan Beulich wrote:
>> >> >>> On 07.03.16 at 23:04, <konrad.wilk@oracle.com> wrote:
>> >> > Hmm, if it was some other PCI based serial card like:
>> >> > 
>> >> > 01:05.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O
>> >> > Controller (rev 01) (prog-if 02 [16550])
>> >> >         Subsystem: LSI Logic / Symbios Logic Device 0001
>> >> >         Flags: medium devsel, IRQ 20
>> >> >         I/O ports at e050 [size=8]
>> >> >         I/O ports at e040 [size=8]
>> >> >         I/O ports at e030 [size=8]
>> >> >         I/O ports at e020 [size=8]
>> >> >         I/O ports at e010 [size=8]
>> >> >         I/O ports at e000 [size=16]
>> >> > 
>> >> > With 'com1=115200,8n1,pci' and 'com2=115200,8n1,pci' then the first loop
>> >> > would find the device. The second loop would decrement idx (1) by 1 and
>> >> > continue.. which would make it go search for another device.
>> >> > 
>> >> > I hadn't tested this patch on the above device but I believe it used
>> >> > to work with the com1 and com2 going throught it - while with the new code
>> >> > it won't?
>> >> 
>> >> That's the !bar0 case, and hence the code in the loop over
>> > 
>> > You mean:
>> > 
>> >        			 param += uart_config[i].param;
>> > +                        if ( !param->bar0 )
>> > +                        {
>> > +                            bar_idx = idx;
>> > +                            port_idx = 0;
>> > +                        }
>> > ?
>> > 
>> > The device in question (NetMos) is not on the uart_config list at all
>> > so we won't get inside this loop.
>> 
>> Well, for devices not on the list it's undetermined anyway whether
>> they would happen to work - we just can't get it right for all possible
>> cases. Someone truly caring about them working should submit a
> 
> Wouldn't your patch cause a regression compared to how it used
> to work in earlier version of Xen?

It would, if you want to call such a regression (as I don't think it
was determined to behave that way). But okay, I'll simply move
the above conditional past the loop, to retain previous behavior.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel