Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"

PATCH In review Thomas Bächler 5 participants 10 messages Mar 5, 2014 – Mar 18, 2014 Bluetooth drivers

Share & tools

Thomas Bächler

author

2014-03-05 11:59 UTC #0 lore raw

PATCH 1/1 Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"

Adding the devname:vhci alias and thus adding a static /dev/vhci device node only works when assigning a fixed major/minor number. However, the code currently uses a dynamically assigned minor number. It is therefore impossible to create a static device and to autoload the module when accessing it.

Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.

This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.

---
 drivers/bluetooth/hci_vhci.c | 1 -
 1 file changed, 1 deletion(-)

drivers/bluetooth/hci_vhci.c +0 -1

index 1ef6990..cf05d70 100644
@@ -384,4 +384,3 @@ MODULE_AUTHOR("Marcel Holtmann <[email protected]>");
 MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
 MODULE_VERSION(VERSION);
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("devname:vhci");

Signature · 1 line

1.9.0

Josh Boyer

2014-03-05 15:28 UTC #1 lore raw

On Wed, Mar 5, 2014 at 6:59 AM, Thomas B=E4chler <[email protected]> wro= te:

Quoted 1 line

Adding the devname:vhci alias and thus adding a static /dev/vhci device n=

ode

Quoted 2 lines

only works when assigning a fixed major/minor number. However, the code currently uses a dynamically assigned minor number. It is therefore impos=

sible

Quoted 4 lines

to create a static device and to autoload the module when accessing it.
Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and =

minor information. Ignoring.

Quoted 2 lines

This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.

We've had several reports of this in Fedora as well. I hadn't gotten around to digging into it yet, so thanks for bringing this up Thomas.

josh

drivers/bluetooth/hci_vhci.c MODULE_AUTHOR("Marcel Holtmann <[email protected]>"=

Quoted 9 lines

---
 drivers/bluetooth/hci_vhci.c | 1 -
 1 file changed, 1 deletion(-)

drivers/bluetooth/hci_vhci.c +0 -0

index 1ef6990..cf05d70 100644
@@ -384,4 +384,3 @@ MODULE_AUTHOR("Marcel Holtmann <[email protected]>"=

);

Quoted 9 lines

drivers/bluetooth/hci_vhci.c +0 -2
 MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
 MODULE_VERSION(VERSION);
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("devname:vhci");
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=

Quoted 3 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Johan Hedberg

2014-03-05 16:11 UTC #2 lore raw

Hi,

Quoted 6 lines · Josh Boyer

Quoted 5 lines · Thomas Bächler
Adding the devname:vhci alias and thus adding a static /dev/vhci device node only works when assigning a fixed major/minor number. However, the code currently uses a dynamically assigned minor number. It is therefore impossible to create a static device and to autoload the module when accessing it.

Quoted 7 lines

Quoted 4 lines
Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
We've had several reports of this in Fedora as well. I hadn't gotten around to digging into it yet, so thanks for bringing this up Thomas.

How does this relate to the "Bluetooth: allocate static minor for vhci" patch that we have in the bluetooth-next tree (also in wireless-next, going to the 3.15 kernel). It's commit b075dd40c95d11c2c8690f6c4d6232fc.

Johan

Marcel Holtmann

maintainer

2014-03-05 16:46 UTC #3 lore raw

In reply to Thomas Bächler

Hi Thomas,

Quoted 9 lines

Adding the devname:vhci alias and thus adding a static /dev/vhci device node only works when assigning a fixed major/minor number. However, the code currently uses a dynamically assigned minor number. It is therefore impossible to create a static device and to autoload the module when accessing it.
Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.

NAK. We allocated a static minor for this.

Regards

Marcel

Josh Boyer

2014-03-05 17:50 UTC #4 lore raw

Quoted 7 lines · Marcel Holtmann

Hi Thomas,
Quoted 5 lines
Adding the devname:vhci alias and thus adding a static /dev/vhci device node only works when assigning a fixed major/minor number. However, the code currently uses a dynamically assigned minor number. It is therefore impossible to create a static device and to autoload the module when accessing it.

Quoted 6 lines

Quoted 4 lines
Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.

Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, correct? Why isn't that headed into 3.14 right now, and CC'd to stable? Currently you have a somewhat broken driver in 3.13 and 3.14-rcX that seems to have a pretty clear fix.

josh

Marcel Holtmann

maintainer

2014-03-05 18:36 UTC #5 lore raw

Hi Josh,

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Adding the devname:vhci alias and thus adding a static /dev/vhci device node only works when assigning a fixed major/minor number. However, the code currently uses a dynamically assigned minor number. It is therefore impossible to create a static device and to autoload the module when accessing it.
Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, correct? Why isn't that headed into 3.14 right now, and CC'd to stable? Currently you have a somewhat broken driver in 3.13 and 3.14-rcX that seems to have a pretty clear fix.

somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.

So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).

Regards

Marcel

Thomas Bächler

author

2014-03-05 18:48 UTC #6 lore raw

Am 05.03.2014 19:36, schrieb Marcel Holtmann:

Quoted 6 lines

Quoted 6 lines
Quoted 3 lines
Quoted 1 line
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, correct?

I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or bluetooth-next. This commit should indeed fix the problem. Disregard my patch.

Quoted 5 lines

Why isn't that headed into 3.14 right now, and CC'd to
Quoted 2 lines
stable? Currently you have a somewhat broken driver in 3.13 and 3.14-rcX that seems to have a pretty clear fix.
somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.

It's a regression in my sanity, since numerous users blame all kernel bugs on this error message and I am tired of explaining the situation (problem + error message == problem found *sigh*). I only sent this patch since I hadn't found the correct fix.

Quoted 1 line

So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).

Since b075dd4 will end up in the Linus tree eventually, I have no trouble backporting it myself.

Sorry for the disturbance.

Josh Boyer

2014-03-05 18:53 UTC #7 lore raw

On Wed, Mar 5, 2014 at 1:48 PM, Thomas B=E4chler <[email protected]> wro= te:

Quoted 17 lines

Am 05.03.2014 19:36, schrieb Marcel Holtmann:
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, correct?
I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or bluetooth-next. This commit should indeed fix the problem. Disregard my patch.
Quoted 5 lines
Why isn't that headed into 3.14 right now, and CC'd to
Quoted 2 lines
stable? Currently you have a somewhat broken driver in 3.13 and 3.14-rcX that seems to have a pretty clear fix.
somewhat broken? kmod prints this as an error, but it is not a regressio=

n in user functionality. The driver works just as before. The error message=
can be ignored.

Quoted 5 lines

It's a regression in my sanity, since numerous users blame all kernel bugs on this error message and I am tired of explaining the situation (problem + error message =3D=3D problem found *sigh*). I only sent this patch since I hadn't found the correct fix.

Exactly.

Quoted 1 line

Quoted 1 line
So if anybody feels strongly that the static device node assignment shou=

ld be put into -stable, then I am fine with it. However I do not see this a= s passing requirement for a -stable fix since it is really not affecting an= yone (minus the misleading message from kmod).

Quoted 3 lines

Since b075dd4 will end up in the Linus tree eventually, I have no trouble backporting it myself.

I don't have any difficulty doing that either, but if it was in stable every distro getting bugs about it wouldn't have to carry the fix on their own.

josh

Marcel Holtmann

maintainer

2014-03-05 19:02 UTC #8 lore raw

Hi Josh,

Quoted 24 lines

Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, correct?
I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or bluetooth-next. This commit should indeed fix the problem. Disregard my patch.
Quoted 4 lines
Why isn't that headed into 3.14 right now, and CC'd to
Quoted 2 lines
stable? Currently you have a somewhat broken driver in 3.13 and 3.14-rcX that seems to have a pretty clear fix.
Quoted 6 lines
Quoted 1 line
somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
It's a regression in my sanity, since numerous users blame all kernel bugs on this error message and I am tired of explaining the situation (problem + error message == problem found *sigh*). I only sent this patch since I hadn't found the correct fix.
Exactly.

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
Since b075dd4 will end up in the Linus tree eventually, I have no trouble backporting it myself.
I don't have any difficulty doing that either, but if it was in stable every distro getting bugs about it wouldn't have to carry the fix on their own.

the patch is currently in wireless-next and will eventually end up in net-next. Maybe it is better to have it cherry picked once it reaches net-next.

Regards

Marcel

Lucas De Marchi

2014-03-18 11:34 UTC #9 lore raw

In reply to Thomas Bächler

Hi Thomas

Quoted 17 lines · On Wed, Mar 5, 2014 at 3:48 PM, Thomas B=C3=A4chler <[email protected]> =…

Am 05.03.2014 19:36, schrieb Marcel Holtmann:
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, correct?
I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or bluetooth-next. This commit should indeed fix the problem. Disregard my patch.
Quoted 5 lines
Why isn't that headed into 3.14 right now, and CC'd to
Quoted 2 lines
stable? Currently you have a somewhat broken driver in 3.13 and 3.14-rcX that seems to have a pretty clear fix.
somewhat broken? kmod prints this as an error, but it is not a regressio=

n in user functionality. The driver works just as before. The error message=
can be ignored.

Quoted 5 lines

It's a regression in my sanity, since numerous users blame all kernel bugs on this error message and I am tired of explaining the situation (problem + error message =3D=3D problem found *sigh*). I only sent this patch since I hadn't found the correct fix.

Feel free to CC kmod mailing list in these cases ([email protected]). We've added this message to kmod exactly to catch problems like this and help people doing the drivers. Once I found out the problem with vhci I sent the patch to fix it, which is heading to Linus tree.

--=20
Lucas De Marchi