Right now I'm running Debian 6.0.4 on a laptop, but I've had a similar situation after compiling my own kernel, and trying to run a modified fedora on a desktop. I suspect this might be a software question too, but it seemed more hardware related so I'm posting here.

Here is the situation:

After installing a new version of linux, or compiling a new kernel, some piece of hardware will no longer work. The usual victims are network devices or sound devices.

Just about all the forums I look into talk about how network manager should solve the problem or that the wrong kernel module is loaded. In the case of sound, this is replaced with alsa. However, in nearly every suggestion, they assume that /sys/class/*/ is correctly populated (/sys/class/net/ for network /sys/class/sound/ for sound). However in these cases, it hasn't been populated.

It seems like these types of devices need to be in placed in /sys/class/*/ before udev is capable of loading the correct kernel module, and alsa or network manager enabling settings before that device is usable. However in each case I've encountered, this isn't happening.

Additionally, I found out that for instance, all pci devices are inside /sys/devices/pci0000:00. In each case, if I do lscpi, I find an entry for the victim, and a subsequent entry somewhere in /sys/devices/pci0000:00. So it seems like the kernel knows the device exists, it's just not loading the correct data for udev to fill the correct slots in /sys/class. Example:

$ lspci | grep Audio
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)

Yet, /dev/sound and /sys/class/sound/ is unpopulated.

The only conclusion that I can come too is that some portion of the kernel managing these devices has a bug for my particular device at that particular version which is unfortunate because the only solution would be to test kernels until you find one that works for all your peripherals. But this is dissapointing because I thought that linux had pretty much solved these types of problems at least for hardware which is > 2 years old.

I should say that I've constructed the above picture from reading various sources about sysfs and udev, however I haven't found a comprehensive picture detailing exactly what happens when a kernel boots to find these devices. So I'm also looking for links to learn more about this process so I'm not as mystified in the future.

So, the TL;DR is, various devices work previously. A new kernel is installed and the proper device info isn't in /sys/class/*/. and hence the device is not accessable. However, the kernel knows the device exists because there is an entry in /sys/devices/pci0000:00 for instance. Do I have the picture incorrect?

The ordinary mortal doesn't have to concern himself with the innards of /sys unless told to by some writer of buggy software.

The process usually is: Software for windows is written from day 1. Depending on company policy, software is available on linux from day 1(e.g. ATI), or the bastards sue you if you try to do anything with 'their' toy, even though you bought it(e.g. Sony)

An open source project will write OSS software with suckers(like me!) who bought the thing without checking support as their testers. Sometimes companies support them with programmers, or data sheets (under confidentiality agreements).

As for your issue, I had it with the RS690 chip in this box. The pci id 1002:791f was not in the software, so nothing happened. A quick patch was written, and that got sorted. Now there's a line in the code
case 1002:791f <do stuff>
and it is recognized.

but I still have
1002:7914 which is unrecognized!

Well.. I understand that at a certain point code has to be written to recognize new hardware either from the beginner or added latter, however my question is regarding hardware which people have claimed to work for a particular kernel and distribution version, and I find that the kernel is not properly detecting that piece of hardware.

For instance, I have an ar9285 wireless card for my laptop. This worked fine while I was using debian 6.0.4, and when I tried to compile my own kernel (3.2.8) I made sure that the correct wireless drivers (ath9k, ath, mac80211, etc...) were compiled to work with this card. However the kernel upon booting did not properly detect that wireless card.

In essence, I'm looking to understand the process on boot for hardware devices to be come 'available' to the user so that I may understand better when a piece of hardware doesn't work for me, whether it's my fault (I didn't compile the correct module or do the right configuration etc...) or the kernel is simply incapable of detecting my hardware and needs a patch of some sort (The case you mentioned).

I got the feeling that the best place to look for clues about this question would be when the kernel populates sysfs, so I'm trying to find a log of some sort which can tell me this information.

is the pci id of your chip in the code?

I guess a look into the output of dmesg might give you some clues how hardware comes into the kernel. It's really dull to read but you know that you found what you were looking for when you see it.

Just cause lspci lists your hardware it does not mean it will work. Kernel modules, firmware all count into it. I'd say like buisness_kid said if the number is known then you'll see it. If there is a kernel module the kernel knows about it. If you also have the firmware (if needed) than you are happy.

Also in case of rolling your own kernel you have to make sure that you include all the subsystems.