Bug 155357

Proposed patch to make smartlink modem configuration work again. The other references to kernel-nongpl seem to be related to avm stuff, where I didn't find the kmp yet. Karsten?

--- src/ids/src/modem.i386
+++ src/ids/src/modem.i386
@@ -50,7 +50,7 @@
 +driver.module.modprobe        slamr
 +baseclass.id          0x102
 +subclass.id           0x04
-+requires              kernel-nongpl|smartlink-softmodem
++requires              smartlink-softmodem|smartlink-softmodem-kmp-default

  vendor.id             pci 0x1131
 &device.id             pci 0x5402

Steffen, is there a way to require a $somepackage-kmp-$flavour package? In the smartlink-softmodem case, we only have -kmp-default, but in other cases we might need to require *-kmp-$flavour.

We do not deliver AVM KMP, so we cannot require it.
Here should be no reference for kernel-nongpl left for AVM in Beta6.

IMHO we should require it -- because, if the users adds a repository by AVM to his installation sources, YaST will automatically install the required packages. IIUC having a non-existant package in the requires, doesn't cause any problems, right Steffen?

Ok, kernel-nongpl has to go. That part is clear.

I'm not sure what to replace it with, however. I wouldn't be surprised if
all requires are ignored currently.

How about smartlink-softmodem-kmp, and yast adds '-<kernel_flavor>'
implicitly?

Klaus (, or whoever else can comment on this)?

Steffen, the requires are used -- I just tested it ;)

That's probably similar to the issue Andreas is working on.

Please see bug 155303. The mechanism will be as follows: KMPs will get all their modaliases (the alias: lines that modinfo reports) exposed at the package level. The package manager will then automatically select all packages that provide support for hardware found in the machine.

Firmware packages that don't have associated KMPs should export the same kind of modaliases. Firmware packages that do have associated KMPs can add a `Supplements: whatever-kmp' to their preamble.

We won't have the modalias mechanism ready in Beta7 in all likelihood, but we should be able to make Beta8.

Created attachment 71353 [details]
overview of hardware dependent packages in hwinfo

Overview of all package deps hwinfo provides.
Long pci/usb id lists are left out.

Andreas, here is the list you asked me for.

Thank you. This bug seems to belongs to Stefan more than to you.

It seems we can detect all those cases based on hardware IDs (usb, pci)? pcsc-towitoko seems to be isa and might be a little funny, but it should work just as well.

The usb/pci identifiers of all the things you didn't list are essential for adding the necessary dependencies in packages. Does `hwinfo --dump-db 1' give all the information that hwinfo knows about, or is the result architecture dependent? If the list is not complete, could you please also attach a complete list?

Created attachment 71389 [details]
complete list

Okay, from comment 12, I have added the appropriate Supplements headers to the 
atmel-firmware, ipw-firmware, smartlink-softmodem, and qlogic-firmware packages. Other than that, there are IDs of AVM hardware in the list which we don't ship anymore. AVM will likely make them available as KMPs, which will automatically handle those packages' dependencies. What remains are the following packages:

ltmodem (ltserial module, Lucent softmodems)
Intel-536ep (Intel softmodem)
Intel-537ep (Intel softmodem)
  These three packages either needs to be converted to KMPs or dropped;
  in either case, dependencies will take care of themselves. We cannot ship
  those packages any longer.

bluez-firmware
  Which hardware / kernel modules does this package belong to? Do we still
  ship that? The spec file refers to Broadcom BCM2033 and AVM.

The pcsc-cyberjack package (with the cyberjack module from the kernel packages) is converted, too. I can't find which module from which package is associatecd with pcsc-towitoko -- any clues?

The remainig packages from Steffen's list (tpctl ,tpconfig, tpb, configure-thinkpad, toshutils, ial, spicctrl) don't have a modalias mapping; we'll have to find some other solution such as HAL.

I think pcsc-towitoko doesn't need any module. I could be wrong, though, as
it's a long time since I added it.

Marian?

The pcsc-towitoko uses serial port (or USB/serial convertor), no extra module is neccessary.

Okay, then we can detect this card with the modalias mechanism.

regarding comment 13:
Yes we can distribute the firmware on all our distributions, this is real firmware running on the adapter CPU, not on the host CPU and we have written agreements from the manufacturers.

For the aliases of both drivers look at the modules bfusb and bcm203x

bfusb: usb:v057Cp2200d*dc*dsc*dp*ic*isc*ip*
bcm203x: usb:v0A5Cp2033d*dc*dsc*dp*ic*isc*ip*

Comment 19: So hwinfo was missing one of the IDs. I've submitted a new version of bluez-firmware, thanks.

This is already fixed.

Ralf just reported that he ran into this with an AVM ISDN controller this weekend. Looking at the hwinfo sources unveiled several references to kernel-nongpl that are still there.

My understanding was that yast would no longer use the 'requires' entries
and so it would not matter to keep them.

Anyway, I've removed references to kernel-nongpl.