Re: [BUG report]: serial8250 unbind/bind failture

Re: [BUG report]: serial8250 unbind/bind failture

[gregkh]

On Mon, Dec 20, 2021 at 09:54:41AM +0000, Miao, Jun wrote:
> [Hardware]
> Intel Corporation Alder Lake Client Platform/AlderLake-M LP5 RVP, BIOS ADLPFWI1.R00.2265.A01.2107010436 07/01/2021
> About x86 old UART, not the PNP device.
> 
> [how to reproduce]
> root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > unbind
> root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > bind

After you unbound, this device is gone, so how does this path still
work?

> [What`s my Confusion]
> After the unbind and bind the serial8250_probe cannot register ttyS0.

Then do not do that :)

> And there is not dmesg like this: "serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A".
> 
> Any one have some advice about 8250 serial ?  It is a common operation if we believe that the old UART which don`t support like this unbind. Or we ignore about this really bug before?

What are you trying to do here exactly?  Why are you wanting to unbind
the driver from this device?  Why do you then want to bind it again?
What problem are you trying to solve by doing this?

thanks,

greg k-h

Re: [BUG report]: serial8250 unbind/bind failture

[Jun Miao]

On 2021/12/20 17:57, gregkh@linuxfoundation.org wrote:
> On Mon, Dec 20, 2021 at 09:54:41AM +0000, Miao, Jun wrote:
>> [Hardware]
>> Intel Corporation Alder Lake Client Platform/AlderLake-M LP5 RVP, BIOS ADLPFWI1.R00.2265.A01.2107010436 07/01/2021
>> About x86 old UART, not the PNP device.
>>
>> [how to reproduce]
>> root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > unbind
>> root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > bind
> After you unbound, this device is gone, so how does this path still
> work?
>
>> [What`s my Confusion]
>> After the unbind and bind the serial8250_probe cannot register ttyS0.
> Then do not do that :)

Hi maintainer,

Thanks your reply so quickly.

You mean, this operation is useless and should don`t do that.

But , if this is a PNP device,  it can probe successfully after unbind/bind.

>
>> And there is not dmesg like this: "serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A".
>>
>> Any one have some advice about 8250 serial ?  It is a common operation if we believe that the old UART which don`t support like this unbind. Or we ignore about this really bug before?
> What are you trying to do here exactly?  Why are you wanting to unbind
> the driver from this device?  Why do you then want to bind it again?
> What problem are you trying to solve by doing this?
>
> thanks,
>
> greg k-h

There is a testcase to test UART by unbind/bind.   i want to support it 
on old uart  of serial8250 .

Re: [BUG report]: serial8250 unbind/bind failture

[gregkh]

On Mon, Dec 20, 2021 at 09:08:19PM +0800, Jun Miao wrote:
> 
> On 2021/12/20 17:57, gregkh@linuxfoundation.org wrote:
> > On Mon, Dec 20, 2021 at 09:54:41AM +0000, Miao, Jun wrote:
> > > [Hardware]
> > > Intel Corporation Alder Lake Client Platform/AlderLake-M LP5 RVP, BIOS ADLPFWI1.R00.2265.A01.2107010436 07/01/2021
> > > About x86 old UART, not the PNP device.
> > > 
> > > [how to reproduce]
> > > root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > unbind
> > > root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > bind
> > After you unbound, this device is gone, so how does this path still
> > work?
> > 
> > > [What`s my Confusion]
> > > After the unbind and bind the serial8250_probe cannot register ttyS0.
> > Then do not do that :)
> 
> Hi maintainer,
> 
> Thanks your reply so quickly.
> 
> You mean, this operation is useless and should don`t do that.

Why do you think it is useful?

> But , if this is a PNP device,  it can probe successfully after unbind/bind.

Is that possible?  If so, how?  Has it ever worked before?  Who requires
this to work?  Does this bus and hardware support this type of
functionality for this hardware device?

> > > And there is not dmesg like this: "serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A".
> > > 
> > > Any one have some advice about 8250 serial ?  It is a common operation if we believe that the old UART which don`t support like this unbind. Or we ignore about this really bug before?
> > What are you trying to do here exactly?  Why are you wanting to unbind
> > the driver from this device?  Why do you then want to bind it again?
> > What problem are you trying to solve by doing this?
> > 
> > thanks,
> > 
> > greg k-h
> 
> There is a testcase to test UART by unbind/bind.   i want to support it on
> old uart  of serial8250 .

Who created this test case and what were they expecting to have happen?
What are they thinking this test case should be doing?  Is this a new
functionality that they need Linux to support?  If so, then new code
probably has to be written :)

bind/unbind is a "best effort" type of thing, not all busses and
hardware types support this at all.

thanks,

greg k-h

Re: [BUG report]: serial8250 unbind/bind failture

[andriy.shevchenko]

On Mon, Dec 20, 2021 at 09:08:19PM +0800, Jun Miao wrote:
> On 2021/12/20 17:57, gregkh@linuxfoundation.org wrote:
> > On Mon, Dec 20, 2021 at 09:54:41AM +0000, Miao, Jun wrote:
> > > [Hardware]
> > > Intel Corporation Alder Lake Client Platform/AlderLake-M LP5 RVP, BIOS ADLPFWI1.R00.2265.A01.2107010436 07/01/2021
> > > About x86 old UART, not the PNP device.
> > > 
> > > [how to reproduce]
> > > root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > unbind
> > > root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > bind
> > After you unbound, this device is gone, so how does this path still
> > work?
> > 
> > > [What`s my Confusion]
> > > After the unbind and bind the serial8250_probe cannot register ttyS0.
> > Then do not do that :)
> 
> Hi maintainer,
> 
> Thanks your reply so quickly.
> 
> You mean, this operation is useless and should don`t do that.
> 
> But , if this is a PNP device,  it can probe successfully after unbind/bind.
> 
> > 
> > > And there is not dmesg like this: "serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A".
> > > 
> > > Any one have some advice about 8250 serial ?  It is a common operation if we believe that the old UART which don`t support like this unbind. Or we ignore about this really bug before?
> > What are you trying to do here exactly?  Why are you wanting to unbind
> > the driver from this device?  Why do you then want to bind it again?
> > What problem are you trying to solve by doing this?

> There is a testcase to test UART by unbind/bind.   i want to support it on
> old uart  of serial8250 .

It's fine to perform such test case (and I have done myself many times similar
operations, but not against PNP UART). Anyway as Greg told you the device is gone
I'm not sure if there is any kernel version which ever worked with what you are
suggesting. What you need is to find a device in the sysfs which corresponds your
PNP UART and perform this against that device.

I have my examples in the script for non-PNP ones:

rebind() {
        local drvdir="/sys/bus/$1/drivers/$2"
        local devdir="/sys/bus/$1/devices/$3"
        [ -d "$drvdir" -a -d "$devdir" ] || return
        echo "$3" > "$drvdir/unbind"
        echo "$3" > "$drvdir/bind"
}

rebind platform 'dw-apb-uart'   '80860F0A:00'   # BYT ttyS1 (ACPI)
rebind platform 'dw-apb-uart'   '8086228A:00'   # BSW ttyS1 (ACPI)
rebind pci      '8250_mid'      '0000:00:04.2'  # Edison ttyS1
rebind pci      'intel-lpss'    '0000:00:18.1'  # BXT LH ttyS1
rebind pci      'intel-lpss'    '0000:00:1e.0'  # SKL ttyS1
rebind pci      '8250_lpss'     '0000:00:1e.3'  # BSW ttyS1 (PCI)

-- 
With Best Regards,
Andy Shevchenko

Re: [BUG report]: serial8250 unbind/bind failture

[andriy.shevchenko]

On Mon, Dec 20, 2021 at 11:47:14AM +0000, Miao, Jun wrote:
> 发件人: andriy.shevchenko@linux.intel.com <andriy.shevchenko@linux.intel.com>
> 发送时间: 星期一, 十二月 20, 2021 6:46 下午
> On Mon, Dec 20, 2021 at 09:08:19PM +0800, Jun Miao wrote:
> > On 2021/12/20 17:57, gregkh@linuxfoundation.org wrote:
> > > On Mon, Dec 20, 2021 at 09:54:41AM +0000, Miao, Jun wrote:
> > > > [Hardware]
> > > > Intel Corporation Alder Lake Client Platform/AlderLake-M LP5 RVP, BIOS ADLPFWI1.R00.2265.A01.2107010436 07/01/2021
> > > > About x86 old UART, not the PNP device.
> > > >
> > > > [how to reproduce]
> > > > root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > unbind
> > > > root@ALD-M:/sys/devices/platform/serial8250/tty/ttyS0/device/driver# echo -n "serial8250" > bind
> > > After you unbound, this device is gone, so how does this path still
> > > work?
> > >
> > > > [What`s my Confusion]
> > > > After the unbind and bind the serial8250_probe cannot register ttyS0.
> > > Then do not do that :)
> >
> > Hi maintainer,
> >
> > Thanks your reply so quickly.
> >
> > You mean, this operation is useless and should don`t do that.
> >
> > But , if this is a PNP device,  it can probe successfully after unbind/bind.
> >
> > >
> > > > And there is not dmesg like this: "serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A".
> > > >
> > > > Any one have some advice about 8250 serial ?  It is a common operation if we believe that the old UART which don`t support like this unbind. Or we ignore about this really bug before?
> > > What are you trying to do here exactly?  Why are you wanting to unbind
> > > the driver from this device?  Why do you then want to bind it again?
> > > What problem are you trying to solve by doing this?
> 
> > There is a testcase to test UART by unbind/bind.   i want to support it on
> > old uart  of serial8250 .
> 
> It's fine to perform such test case (and I have done myself many times similar
> operations, but not against PNP UART). Anyway as Greg told you the device is gone
> I'm not sure if there is any kernel version which ever worked with what you are
> suggesting. What you need is to find a device in the sysfs which corresponds your
> PNP UART and perform this against that device.
> 
> I have my examples in the script for non-PNP ones:
> 
> rebind() {
>         local drvdir="/sys/bus/$1/drivers/$2"
>         local devdir="/sys/bus/$1/devices/$3"
>         [ -d "$drvdir" -a -d "$devdir" ] || return
>         echo "$3" > "$drvdir/unbind"
>         echo "$3" > "$drvdir/bind"
> }
> 
> rebind platform 'dw-apb-uart'   '80860F0A:00'   # BYT ttyS1 (ACPI)
> rebind platform 'dw-apb-uart'   '8086228A:00'   # BSW ttyS1 (ACPI)
> rebind pci      '8250_mid'      '0000:00:04.2'  # Edison ttyS1
> rebind pci      'intel-lpss'    '0000:00:18.1'  # BXT LH ttyS1
> rebind pci      'intel-lpss'    '0000:00:1e.0'  # SKL ttyS1
> rebind pci      '8250_lpss'     '0000:00:1e.3'  # BSW ttyS1 (PCI)

> Thanks Andy
> No-pop is not pci,  is only for the old serial8250 PORT ID:0x3F8, which will bind failed.

Yes, I'm aware about that. Please, read carefully what is written above.
It's not a twitter post, it will require more effort to be made to go
through.

-- 
With Best Regards,
Andy Shevchenko