Skip to contentSkip to conversation

Getting make net/built-in.o Error with 2.6.21.1 Build

DISCUSSION Chris Bergeron 4 participants 8 messages May 7, 2007 – May 8, 2007

Subsystems (4)
Networking Network drivers Bluetooth drivers Bluetooth
lore
Share & tools
lore

Chris Bergeron

author
#0 lore raw

On trying to build a 2.6.21.1 kernel using the configuration at http://pcburn.com/files/kernel/breaks.2.6.21.1.config I'm getting the following error with Networking Support -> Bluetooth Subsystem Support -> HIDP protocol support set to built-in:

 CC      init/version.o
 LD      init/built-in.o
 LD      .tmp_vmlinux1

net/built-in.o: In function `hidp_add_connection':
(.text+0x8bb08): undefined reference to `hid_ff_init'
make: *** [.tmp_vmlinux1] Error 1

Works with that option turned off. Also, the GCC version I'm using is the current Debian Etch release: gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). I also tried it with gcc (GCC) 3.4.6 (Debian 3.4.6-5) for the same result.

I don't need to build that, so I simply unset it. If this is at all useful and you need something else just CC: me in the reply.

Thanks,
-- Chris

#1 lore raw
Quoted 11 lines · Chris Bergeron

On trying to build a 2.6.21.1 kernel using the configuration at
http://pcburn.com/files/kernel/breaks.2.6.21.1.config I'm getting the following error with Networking Support -> Bluetooth Subsystem Support -> HIDP protocol support set to built-in:

  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1

net/built-in.o: In function `hidp_add_connection':
(.text+0x8bb08): undefined reference to `hid_ff_init'
make: *** [.tmp_vmlinux1] Error 1

You've got CONFIG_BT_HIDP=y there but CONFIG_USB_HID=m. The trivial patch below solves it. To test, you can just "make oldconfig" on the same .config that broke above and then proceed to make bzImage.

Satyam

---

Make CONFIG_BT_HIDP depend on CONFIG_USB_HID and CONFIG_HID_FF.

Signed-off-by Satyam Sharma <[email protected]>

---

 net/bluetooth/hidp/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

---

net/bluetooth/hidp/Kconfig +1 -1
diff -ruNp a/net/bluetooth/hidp/Kconfig b/net/bluetooth/hidp/Kconfig
@@ -1,6 +1,6 @@
 config BT_HIDP
 	tristate "HIDP protocol support"
-	depends on BT && BT_L2CAP && INPUT
+	depends on BT && BT_L2CAP && INPUT && USB_HID && HID_FF
 	select HID
 	help
 	  HIDP (Human Interface Device Protocol) is a transport layer

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

#2 lore raw
Quoted 9 lines · Satyam Sharma
Quoted 6 lines
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1

net/built-in.o: In function `hidp_add_connection':
(.text+0x8bb08): undefined reference to `hid_ff_init'
make: *** [.tmp_vmlinux1] Error 1

You've got CONFIG_BT_HIDP=y there but CONFIG_USB_HID=m. The trivial patch below solves it. To test, you can just "make oldconfig" on the same .config that broke above and then proceed to make bzImage.

I'd say we need a different fix here. First, the question is whether there are any force-feedback devices, supported by USBHID force-feedback layer, which have a bluetooth version?

If there are none of them, we could just drop the FF initialization completely for now.

On the other hand if there are such devices, just calling hid_ff_init() is presently not enough anyway, as the force feedback drivers for HID devices are currently USB-transport specific.

Signature · 1 line
Jiri Kosina
#3 lore raw

Hi Jiri,

Quoted 16 lines · Jiri Kosina
Quoted 9 lines · Satyam Sharma
Quoted 6 lines
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1

net/built-in.o: In function `hidp_add_connection':
(.text+0x8bb08): undefined reference to `hid_ff_init'
make: *** [.tmp_vmlinux1] Error 1

You've got CONFIG_BT_HIDP=y there but CONFIG_USB_HID=m. The trivial patch below solves it. To test, you can just "make oldconfig" on the same .config that broke above and then proceed to make bzImage.

I'd say we need a different fix here. First, the question is whether there are any force-feedback devices, supported by USBHID force-feedback layer, which have a bluetooth version?

Quoted 6 lines

If there are none of them, we could just drop the FF initialization completely for now.

On the other hand if there are such devices, just calling hid_ff_init() is presently not enough anyway, as the force feedback drivers for HID devices are currently USB-transport specific.

Sure, my aim here was to only solve the _build breakage_ by fixing the Kconfig for this module (that used code from another kernel module without listing it in its dependencies). If, as you say, the real solution is that we should actually be taking out the offending call to the other module itself, then please go ahead -- I don't know much about the Bluetooth / HIDP subsytem anyway.

Thanks,
Satyam

#4 lore raw
Quoted 6 lines · Satyam Sharma

Sure, my aim here was to only solve the _build breakage_ by fixing the Kconfig for this module (that used code from another kernel module without listing it in its dependencies). If, as you say, the real solution is that we should actually be taking out the offending call to the other module itself, then please go ahead -- I don't know much about the Bluetooth / HIDP subsytem anyway.

Converting the hid-ff drivers to be also transport-independent is on my TODO list, but it didn't happen yet.

Marcel - are you aware of any devices currently supported by USB HID force-feedback code, which have a bluetooth version, please?

I'd propose the patch below, until I make the usbhid force-feedback code transport independent. Thanks.

From: Jiri Kosina <[email protected]>

[Bluetooth] HIDP - don't initialize force feedback

The current implementation of force feedback for HID devices is USB-transport only and therefore calling hid_ff_init() from hidp code is not going to work (plus it creates unwanted dependency of hidp on usbhid). Remove the hid_ff_init() until either the hid-ff is made transport-independent, or at least support for bluetooth transport is added.

Signed-off-by Jiri Kosina <[email protected]>
net/bluetooth/hidp/core.c +1 -3
index d342e89..3e77e81 100644
@@ -737,10 +737,8 @@ static inline void hidp_setup_hid(struct
 	list_for_each_entry(report, &hid->report_enum[HID_FEATURE_REPORT].report_list, list)
 		hidp_send_report(session, report);
 
-	if (hidinput_connect(hid) == 0) {
+	if (hidinput_connect(hid) == 0)
 		hid->claimed |= HID_CLAIMED_INPUT;
-		hid_ff_init(hid);
-	}
 }
 
 int hidp_add_connection(struct hidp_connadd_req *req, struct socket *ctrl_sock, struct socket *intr_sock)
maintainer
#5 lore raw

Hi Jiri,

Quoted 7 lines
Quoted 6 lines

Sure, my aim here was to only solve the _build breakage_ by fixing the Kconfig for this module (that used code from another kernel module without listing it in its dependencies). If, as you say, the real solution is that we should actually be taking out the offending call to the other module itself, then please go ahead -- I don't know much about the Bluetooth / HIDP subsytem anyway.

Quoted 5 lines

Converting the hid-ff drivers to be also transport-independent is on my TODO list, but it didn't happen yet.

Marcel - are you aware of any devices currently supported by USB HID force-feedback code, which have a bluetooth version, please?

I haven't looked at all details for the PS3 controller, but that might be the first one. In theory they can and at some point they will enter the market.

Quoted 9 lines

I'd propose the patch below, until I make the usbhid force-feedback code transport independent. Thanks.

From: Jiri Kosina <[email protected]>

[Bluetooth] HIDP - don't initialize force feedback

Quoted 8 lines

The current implementation of force feedback for HID devices is USB-transport only and therefore calling hid_ff_init() from hidp code is not going to work (plus it creates unwanted dependency of hidp on usbhid). Remove the hid_ff_init() until either the hid-ff is made transport-independent, or at least support for bluetooth transport is added.

Signed-off-by Jiri Kosina <[email protected]>
Signed-off-by Marcel Holtmann <[email protected]>

Under the condition that you remember to put it back once a generic FF exists.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#6 lore raw
Quoted 5 lines · Marcel Holtmann
Quoted 2 lines

Marcel - are you aware of any devices currently supported by USB HID force-feedback code, which have a bluetooth version, please?

I haven't looked at all details for the PS3 controller, but that might be the first one. In theory they can and at some point they will enter the market.

You are right, PS3 controller is going to be shipped in both variants. On the other hand it is perfectly possible that we will need special force-feedback driver for it anyway.

BTW when talking about this - we already have PS3 quirk present in usb hid (extra control URB is required to make it operational), probably something similar will be needed for BT version too.

Quoted 9 lines
Quoted 9 lines

From: Jiri Kosina <[email protected]>
[Bluetooth] HIDP - don't initialize force feedback
The current implementation of force feedback for HID devices is USB-transport only and therefore calling hid_ff_init() from hidp code is not going to work (plus it creates unwanted dependency of hidp on usbhid). Remove the hid_ff_init() until either the hid-ff is made transport-independent, or at least support for bluetooth transport is added.

Signed-off-by Jiri Kosina <[email protected]>
Quoted 3 lines
Signed-off-by Marcel Holtmann <[email protected]>

Under the condition that you remember to put it back once a generic FF exists.

Sure. I will take this through my tree then, thanks.

Signature · 1 line
Jiri Kosina
maintainer
#7 lore raw

Hi Jiri,

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

Marcel - are you aware of any devices currently supported by USB HID force-feedback code, which have a bluetooth version, please?

I haven't looked at all details for the PS3 controller, but that might be the first one. In theory they can and at some point they will enter the market.

Quoted 7 lines

You are right, PS3 controller is going to be shipped in both variants. On the other hand it is perfectly possible that we will need special force-feedback driver for it anyway.

BTW when talking about this - we already have PS3 quirk present in usb hid (extra control URB is required to make it operational), probably something similar will be needed for BT version too.

I know, but we do that in user space before we hand over the control to the kernel. It is simpler, because it is on the control channel and that part is not nicely integrated into the HID subsystem to be used by the transport layers right now. At least as far as I can tell.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel