[bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Dongdong Liu]

Hi all:

The bug is recorded in https://bugs.linaro.org/show_bug.cgi?id=2292.

"PNP0C02" attached two modules drivers/pnp/system.c and drivers/net/fjes/fjes_main.c .
"fjes" driver lead to the call trace.

system.c:
static const struct pnp_device_id pnp_dev_table[] = {
         /* General ID for reserving resources */
         {"PNP0c02", 0},
         /* memory controller */
         {"PNP0c01", 0},
         {"", 0}
};

jes_main.c:
static const struct acpi_device_id fjes_acpi_ids[] = {
         {"PNP0C02", 0},
         {"", 0},
};

Both of the modules use id "PNP0C02" (case insensitive),

I used "PNP0C02" to mark motherboard reserved resource as below in UEFI.
Device (RES1)
{
	Name (_HID, "HISI0081") // HiSi PCIe RC config baseaddress
	Name (_CID, "PNP0C02") // Motherboard reserved resource
		Name (_CRS, ResourceTemplate (){
			Memory32Fixed (ReadWrite, 0xb0080000 , 0x10000)
		})
}

I think that "PNP0C02" should be used to mark any motherboard reserved resource and not a specific network driver.
It seems like a bug in the "fjes" driver.

Thanks

Dongdong

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Gabriele Paoloni]

Hi Dongdong

Thanks for flagging this

+to: Taku Izumi <izumi.taku@jp.fujitsu.com>

Gab

> -----Original Message-----
> From: linuxarm-bounces@huawei.com [mailto:linuxarm-bounces@huawei.com]
> On Behalf Of Dongdong Liu
> Sent: 03 June 2016 10:38
> To: netdev@vger.kernel.org
> Cc: Linuxarm
> Subject: [bug discuss] fjes driver call trace warning, "PNP0C02" used
> in fjes seems like a bug,
> 
> Hi all:
> 
> The bug is recorded in https://bugs.linaro.org/show_bug.cgi?id=2292.
> 
> "PNP0C02" attached two modules drivers/pnp/system.c and
> drivers/net/fjes/fjes_main.c .
> "fjes" driver lead to the call trace.
> 
> system.c:
> static const struct pnp_device_id pnp_dev_table[] = {
>          /* General ID for reserving resources */
>          {"PNP0c02", 0},
>          /* memory controller */
>          {"PNP0c01", 0},
>          {"", 0}
> };
> 
> jes_main.c:
> static const struct acpi_device_id fjes_acpi_ids[] = {
>          {"PNP0C02", 0},
>          {"", 0},
> };
> 
> Both of the modules use id "PNP0C02" (case insensitive),
> 
> I used "PNP0C02" to mark motherboard reserved resource as below in
> UEFI.
> Device (RES1)
> {
> 	Name (_HID, "HISI0081") // HiSi PCIe RC config baseaddress
> 	Name (_CID, "PNP0C02") // Motherboard reserved resource
> 		Name (_CRS, ResourceTemplate (){
> 			Memory32Fixed (ReadWrite, 0xb0080000 , 0x10000)
> 		})
> }
> 
> I think that "PNP0C02" should be used to mark any motherboard reserved
> resource and not a specific network driver.
> It seems like a bug in the "fjes" driver.
> 
> Thanks
> 
> Dongdong
> 
> 
> 
> 
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Re: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Hanjun Guo]

On 2016/6/3 17:58, Gabriele Paoloni wrote:
> Hi Dongdong
>
> Thanks for flagging this
>
> +to: Taku Izumi <izumi.taku@jp.fujitsu.com>
>
> Gab
>
>> -----Original Message-----
>> From: linuxarm-bounces@huawei.com [mailto:linuxarm-bounces@huawei.com]
>> On Behalf Of Dongdong Liu
>> Sent: 03 June 2016 10:38
>> To: netdev@vger.kernel.org
>> Cc: Linuxarm
>> Subject: [bug discuss] fjes driver call trace warning, "PNP0C02" used
>> in fjes seems like a bug,
>>
>> Hi all:
>>
>> The bug is recorded in https://bugs.linaro.org/show_bug.cgi?id=2292.
>>
>> "PNP0C02" attached two modules drivers/pnp/system.c and
>> drivers/net/fjes/fjes_main.c .
>> "fjes" driver lead to the call trace.
>>
>> system.c:
>> static const struct pnp_device_id pnp_dev_table[] = {
>>          /* General ID for reserving resources */
>>          {"PNP0c02", 0},
>>          /* memory controller */
>>          {"PNP0c01", 0},
>>          {"", 0}
>> };
>>
>> jes_main.c:
>> static const struct acpi_device_id fjes_acpi_ids[] = {
>>          {"PNP0C02", 0},
>>          {"", 0},
>> };
>>
>> Both of the modules use id "PNP0C02" (case insensitive),
>>
>> I used "PNP0C02" to mark motherboard reserved resource as below in
>> UEFI.
>> Device (RES1)
>> {
>> 	Name (_HID, "HISI0081") // HiSi PCIe RC config baseaddress
>> 	Name (_CID, "PNP0C02") // Motherboard reserved resource
>> 		Name (_CRS, ResourceTemplate (){
>> 			Memory32Fixed (ReadWrite, 0xb0080000 , 0x10000)
>> 		})
>> }
>>
>> I think that "PNP0C02" should be used to mark any motherboard reserved
>> resource and not a specific network driver.
>> It seems like a bug in the "fjes" driver.

I agree,  PNP0C02 is not a valid ACPI device HID but only for reserved resources.

Thanks
Hanjun

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Izumi, Taku]

Dear Liu,

> -----Original Message-----
> From: Gabriele Paoloni [mailto:gabriele.paoloni@huawei.com]
> Sent: Friday, June 03, 2016 6:59 PM
> To: liudongdong (C); Izumi, Taku/泉 拓
> Cc: Linuxarm; netdev@vger.kernel.org
> Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,
> 
> Hi Dongdong
> 
> Thanks for flagging this
> 
> +to: Taku Izumi <izumi.taku@jp.fujitsu.com>
> 
> Gab
> 
> > -----Original Message-----
> > From: linuxarm-bounces@huawei.com [mailto:linuxarm-bounces@huawei.com]
> > On Behalf Of Dongdong Liu
> > Sent: 03 June 2016 10:38
> > To: netdev@vger.kernel.org
> > Cc: Linuxarm
> > Subject: [bug discuss] fjes driver call trace warning, "PNP0C02" used
> > in fjes seems like a bug,
> >
> > Hi all:
> >
> > The bug is recorded in https://bugs.linaro.org/show_bug.cgi?id=2292.
> >
> > "PNP0C02" attached two modules drivers/pnp/system.c and
> > drivers/net/fjes/fjes_main.c .
> > "fjes" driver lead to the call trace.
> >
> > system.c:
> > static const struct pnp_device_id pnp_dev_table[] = {
> >          /* General ID for reserving resources */
> >          {"PNP0c02", 0},
> >          /* memory controller */
> >          {"PNP0c01", 0},
> >          {"", 0}
> > };
> >
> > jes_main.c:
> > static const struct acpi_device_id fjes_acpi_ids[] = {
> >          {"PNP0C02", 0},
> >          {"", 0},
> > };
> >
> > Both of the modules use id "PNP0C02" (case insensitive),
> >
> > I used "PNP0C02" to mark motherboard reserved resource as below in
> > UEFI.
> > Device (RES1)
> > {
> > 	Name (_HID, "HISI0081") // HiSi PCIe RC config baseaddress
> > 	Name (_CID, "PNP0C02") // Motherboard reserved resource
> > 		Name (_CRS, ResourceTemplate (){
> > 			Memory32Fixed (ReadWrite, 0xb0080000 , 0x10000)
> > 		})
> > }
> >
> > I think that "PNP0C02" should be used to mark any motherboard reserved
> > resource and not a specific network driver.
> > It seems like a bug in the "fjes" driver.

  Extended Socket network device is a shared memory based high-speed
  network interface between Extended Partitions of PRIMEQUEST 2000 E2
  series. To check if firmware supports Extended Socket network device,
  we take use of  "PCP0C02" device and special strings in DSDT.

  "fjes" is not only "platform device driver (mainly act as network
   driver" but also "acpi driver" . If "PCP0C02" found and it is for 
   Extended Socket network device, platform_device will be created. 
  
  Sincerely,
  Taku Izumi

> >
> > Thanks
> >
> > Dongdong
> >
> >
> >
> >
> > _______________________________________________
> > linuxarm mailing list
> > linuxarm@huawei.com
> > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Gabriele Paoloni]

Hi Taku Izumi

> -----Original Message-----
> From: Izumi, Taku [mailto:izumi.taku@jp.fujitsu.com]
> Sent: 06 June 2016 10:34
> To: Gabriele Paoloni; liudongdong (C)
> Cc: Linuxarm; netdev@vger.kernel.org
> Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02"
> used in fjes seems like a bug,
> 
> Dear Liu,
> 
> > -----Original Message-----
> > From: Gabriele Paoloni [mailto:gabriele.paoloni@huawei.com]
> > Sent: Friday, June 03, 2016 6:59 PM
> > To: liudongdong (C); Izumi, Taku/泉 拓
> > Cc: Linuxarm; netdev@vger.kernel.org
> > Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02"
> used in fjes seems like a bug,
> >
> > Hi Dongdong
> >
> > Thanks for flagging this
> >
> > +to: Taku Izumi <izumi.taku@jp.fujitsu.com>
> >
> > Gab
> >
> > > -----Original Message-----
> > > From: linuxarm-bounces@huawei.com [mailto:linuxarm-
> bounces@huawei.com]
> > > On Behalf Of Dongdong Liu
> > > Sent: 03 June 2016 10:38
> > > To: netdev@vger.kernel.org
> > > Cc: Linuxarm
> > > Subject: [bug discuss] fjes driver call trace warning, "PNP0C02"
> used
> > > in fjes seems like a bug,
> > >
> > > Hi all:
> > >
> > > The bug is recorded in https://bugs.linaro.org/show_bug.cgi?id=2292.
> > >
> > > "PNP0C02" attached two modules drivers/pnp/system.c and
> > > drivers/net/fjes/fjes_main.c .
> > > "fjes" driver lead to the call trace.
> > >
> > > system.c:
> > > static const struct pnp_device_id pnp_dev_table[] = {
> > >          /* General ID for reserving resources */
> > >          {"PNP0c02", 0},
> > >          /* memory controller */
> > >          {"PNP0c01", 0},
> > >          {"", 0}
> > > };
> > >
> > > jes_main.c:
> > > static const struct acpi_device_id fjes_acpi_ids[] = {
> > >          {"PNP0C02", 0},
> > >          {"", 0},
> > > };
> > >
> > > Both of the modules use id "PNP0C02" (case insensitive),
> > >
> > > I used "PNP0C02" to mark motherboard reserved resource as below in
> > > UEFI.
> > > Device (RES1)
> > > {
> > > 	Name (_HID, "HISI0081") // HiSi PCIe RC config baseaddress
> > > 	Name (_CID, "PNP0C02") // Motherboard reserved resource
> > > 		Name (_CRS, ResourceTemplate (){
> > > 			Memory32Fixed (ReadWrite, 0xb0080000 , 0x10000)
> > > 		})
> > > }
> > >
> > > I think that "PNP0C02" should be used to mark any motherboard
> reserved
> > > resource and not a specific network driver.
> > > It seems like a bug in the "fjes" driver.
> 
>   Extended Socket network device is a shared memory based high-speed
>   network interface between Extended Partitions of PRIMEQUEST 2000 E2
>   series. To check if firmware supports Extended Socket network device,
>   we take use of  "PCP0C02" device and special strings in DSDT.
> 
>   "fjes" is not only "platform device driver (mainly act as network
>    driver" but also "acpi driver" . If "PCP0C02" found and it is for
>    Extended Socket network device, platform_device will be created.

>From my understanding PNP0C02 is not a valid ACPI device HID but it is
to be used only to reserve motherboard resources.

Can you please explain your identifier choice?

Thanks

Gab

> 
>   Sincerely,
>   Taku Izumi
> 
> > >
> > > Thanks
> > >
> > > Dongdong
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > linuxarm mailing list
> > > linuxarm@huawei.com
> > > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Izumi, Taku]

Dear Gab,

> > > > I think that "PNP0C02" should be used to mark any motherboard
> > reserved
> > > > resource and not a specific network driver.
> > > > It seems like a bug in the "fjes" driver.
> >
> >   Extended Socket network device is a shared memory based high-speed
> >   network interface between Extended Partitions of PRIMEQUEST 2000 E2
> >   series. To check if firmware supports Extended Socket network device,
> >   we take use of  "PCP0C02" device and special strings in DSDT.
> >
> >   "fjes" is not only "platform device driver (mainly act as network
> >    driver" but also "acpi driver" . If "PCP0C02" found and it is for
> >    Extended Socket network device, platform_device will be created.
> 
> From my understanding PNP0C02 is not a valid ACPI device HID but it is
> to be used only to reserve motherboard resources.
> 
> Can you please explain your identifier choice?

   Sorry for late.

   Extended Socket network device is not a physical device. This is a
   kind of virtual device in memory region which firmware provides.  
   This driver retrieves resource information 
   (memory reagion address firmware provides and so on)
   via PNP0C02. This resource is firmware reserved resources so we use
   PNP0C02.

   Sincerely,
   Taku Izumi

> 
> Gab
> 
> >
> >   Sincerely,
> >   Taku Izumi
> >
> > > >
> > > > Thanks
> > > >
> > > > Dongdong
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > linuxarm mailing list
> > > > linuxarm@huawei.com
> > > > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Gabriele Paoloni]

+TO: David Miller
+CC: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: Izumi, Taku [mailto:izumi.taku@jp.fujitsu.com]
> Sent: 08 June 2016 03:27
> To: Gabriele Paoloni; liudongdong (C)
> Cc: Linuxarm; netdev@vger.kernel.org
> Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02"
> used in fjes seems like a bug,
> 
> Dear Gab,
> 
> > > > > I think that "PNP0C02" should be used to mark any motherboard
> > > reserved
> > > > > resource and not a specific network driver.
> > > > > It seems like a bug in the "fjes" driver.
> > >
> > >   Extended Socket network device is a shared memory based high-
> speed
> > >   network interface between Extended Partitions of PRIMEQUEST 2000
> E2
> > >   series. To check if firmware supports Extended Socket network
> device,
> > >   we take use of  "PCP0C02" device and special strings in DSDT.
> > >
> > >   "fjes" is not only "platform device driver (mainly act as network
> > >    driver" but also "acpi driver" . If "PCP0C02" found and it is
> for
> > >    Extended Socket network device, platform_device will be created.
> >
> > From my understanding PNP0C02 is not a valid ACPI device HID but it
> is
> > to be used only to reserve motherboard resources.
> >
> > Can you please explain your identifier choice?
> 
>    Sorry for late.
> 
>    Extended Socket network device is not a physical device. This is a
>    kind of virtual device in memory region which firmware provides.

>From a SW perspective it like an acpi driver that uses "PNP0C02"
as driver ids to perform the driver match in the ACPI table.

>From my understanding this is wrong in principle because that identifier
must be used to reserve motherboard resources (see par 4.1.2 of the PCI
Firmware Specifications v3.2)

Therefore such identifier it is used from
http://lxr.free-electrons.com/source/drivers/pnp/system.c
to reserve such resources.

Basically your driver is breaking any other device that
needs to reserve motherboard resources through system.c
driver.

@David Miller, what is your opinion about this?
I think this driver should be reverted...

Thanks

Gab
 

>    This driver retrieves resource information
>    (memory reagion address firmware provides and so on)
>    via PNP0C02. This resource is firmware reserved resources so we use
>    PNP0C02.
> 
>    Sincerely,
>    Taku Izumi
> 
> >
> > Gab
> >
> > >
> > >   Sincerely,
> > >   Taku Izumi
> > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > Dongdong
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > linuxarm mailing list
> > > > > linuxarm@huawei.com
> > > > > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

[Izumi, Taku]

Dear Gao,

> From a SW perspective it like an acpi driver that uses "PNP0C02"
> as driver ids to perform the driver match in the ACPI table.
> 
> From my understanding this is wrong in principle because that identifier
> must be used to reserve motherboard resources (see par 4.1.2 of the PCI
> Firmware Specifications v3.2)
> 
> Therefore such identifier it is used from
> http://lxr.free-electrons.com/source/drivers/pnp/system.c
> to reserve such resources.
> 
> Basically your driver is breaking any other device that
> needs to reserve motherboard resources through system.c
> driver.
> 
> @David Miller, what is your opinion about this?
> I think this driver should be reverted...

 I'm willing to revise my driver if it's something wrong.
 I can't reproduce this problem. Could you please show me how to reproduce problem ?

 Sincerely,
 Taku Izumi