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

bug discuss Dongdong Liu 4 participants 8 messages Jun 3, 2016 – Jun 9, 2016

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Dongdong Liu

author

2016-06-03 09:38 UTC #0 lore raw

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

Gabriele Paoloni

2016-06-03 09:59 UTC #1 lore raw

Hi Dongdong

Thanks for flagging this

+to: Taku Izumi <[email protected]>

Gab

Quoted 60 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dongdong Liu
Sent: 03 June 2016 10:38
To: [email protected]
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
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Hanjun Guo

2016-06-06 09:14 UTC #2 lore raw

Quoted 56 lines · Gabriele Paoloni

Hi Dongdong
Thanks for flagging this
+to: Taku Izumi <[email protected]>
Gab
Quoted 48 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dongdong Liu
Sent: 03 June 2016 10:38
To: [email protected]
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

Izumi, Taku

2016-06-06 09:34 UTC #3 lore raw

In reply to Gabriele Paoloni

Dear Liu,

Quoted 7 lines

-----Original Message-----
From: Gabriele Paoloni [mailto:[email protected]]
Sent: Friday, June 03, 2016 6:59 PM
To: liudongdong (C); Izumi, Taku/泉拓
Cc: Linuxarm; [email protected]
Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

Quoted 56 lines

Hi Dongdong
Thanks for flagging this
+to: Taku Izumi <[email protected]>
Gab
Quoted 48 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dongdong Liu
Sent: 03 June 2016 10:38
To: [email protected]
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

Quoted 12 lines

Quoted 12 lines
Thanks
Dongdong
_______________________________________________
linuxarm mailing list
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Gabriele Paoloni

2016-06-06 10:03 UTC #4 lore raw

Hi Taku Izumi

Quoted 83 lines

-----Original Message-----
From: Izumi, Taku [mailto:[email protected]]
Sent: 06 June 2016 10:34
To: Gabriele Paoloni; liudongdong (C)
Cc: Linuxarm; [email protected]
Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,
Dear Liu,
Quoted 6 lines
-----Original Message-----
From: Gabriele Paoloni [mailto:[email protected]]
Sent: Friday, June 03, 2016 6:59 PM
To: liudongdong (C); Izumi, Taku/泉拓
Cc: Linuxarm; [email protected]
Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02"
used in fjes seems like a bug,
Quoted 11 lines
Hi Dongdong
Thanks for flagging this
+to: Taku Izumi <[email protected]>
Gab
Quoted 2 lines
-----Original Message-----
From: [email protected] [mailto:linuxarm-
[email protected]]
Quoted 5 lines
Quoted 5 lines
On Behalf Of Dongdong Liu
Sent: 03 June 2016 10:38
To: [email protected]
Cc: Linuxarm
Subject: [bug discuss] fjes driver call trace warning, "PNP0C02"
used
Quoted 38 lines
Quoted 38 lines
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)
		})
}
Quoted 1 line
Quoted 1 line
I think that "PNP0C02" should be used to mark any motherboard
reserved
Quoted 2 lines
Quoted 2 lines
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.

Quoted 5 lines

"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

Quoted 16 lines

Sincerely,
Taku Izumi
Quoted 12 lines
Quoted 12 lines
Thanks
Dongdong
_______________________________________________
linuxarm mailing list
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Izumi, Taku

2016-06-08 02:27 UTC #5 lore raw

Dear Gab,

Quoted 10 lines

Quoted 10 lines
Quoted 1 line
Quoted 1 line
I think that "PNP0C02" should be used to mark any motherboard
reserved
Quoted 2 lines
Quoted 2 lines
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.

Quoted 8 lines

Quoted 3 lines
"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

Quoted 19 lines

Gab
Quoted 16 lines
Sincerely,
Taku Izumi
Quoted 12 lines
Quoted 12 lines
Thanks
Dongdong
_______________________________________________
linuxarm mailing list
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Gabriele Paoloni

2016-06-08 07:10 UTC #6 lore raw

+TO: David Miller
+CC: [email protected]

Quoted 32 lines

-----Original Message-----
From: Izumi, Taku [mailto:[email protected]]
Sent: 08 June 2016 03:27
To: Gabriele Paoloni; liudongdong (C)
Cc: Linuxarm; [email protected]
Subject: RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,
Dear Gab,
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Quoted 1 line
I think that "PNP0C02" should be used to mark any motherboard
reserved
Quoted 2 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
network interface between Extended Partitions of PRIMEQUEST 2000
E2
Quoted 1 line
Quoted 1 line
series. To check if firmware supports Extended Socket network
device,
Quoted 4 lines
Quoted 4 lines
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
Quoted 3 lines
Quoted 1 line
Extended Socket network device, platform_device will be created.
From my understanding PNP0C02 is not a valid ACPI device HID but it
is
Quoted 2 lines
to be used only to reserve motherboard resources.

Quoted 8 lines

Quoted 1 line
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.

Quoted 1 line

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

Quoted 27 lines

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
Quoted 19 lines
Gab
Quoted 16 lines
Sincerely,
Taku Izumi
Quoted 12 lines
Quoted 12 lines
Thanks
Dongdong
_______________________________________________
linuxarm mailing list
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Izumi, Taku

2016-06-09 08:49 UTC #7 lore raw

Dear Gao,

Quoted 11 lines

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.

Quoted 6 lines

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