Hello, On 12/10/2016 15:34:46 CEST, Kalle Valo wrote: > "Vittorio Gambaletta (VittGam)" <linux-wirel...@vittgam.net> writes: > >> Hello, >> >> On 04/10/2016 17:46:44 CEST, Kalle Valo wrote: >>> "Vittorio Gambaletta (VittGam)" <linux-wirel...@vittgam.net> writes: >>> >>>> If generic entries are positioned above specific ones, then the >>>> former will be matched first and used instead of the latter. >>>> >>>> Cc: <linux-wirel...@vger.kernel.org> >>>> Cc: <ath9k-de...@qca.qualcomm.com> >>>> Cc: <ath9k-devel@lists.ath9k.org> >>>> Cc: <sta...@vger.kernel.org> >>>> Signed-off-by: Vittorio Gambaletta <linuxb...@vittgam.net> >>> >>> Why? What kind of bug you are fixing? You are not really describing the >>> problem you are trying fix. >> >> The active_high LED of my Wistron DNMA-92 is still being recognized as >> active_low on 4.7.6 mainline. > > This kind of information is important, always add that to the commit log > so that we don't need to guess.
Okay, sorry about missing that before. >> When I was preparing my former patch to fix that, I initially added the >> PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section >> for 0x0029; but then I moved the former below the latter after seeing >> how 0x002A sections were sorted in the file. >> >> I must have somehow messed up with testing, because I tested the final >> version of that patch before sending it, and it was apparently working; >> but now it is not working on 4.7.6 mainline. >> >> With this patch, 0x0029/0x2096 has finally got active_high LED on >> 4.7.6. > > I'm confused, are you now saying that this patch doesn't work? No: the previous patch (which is already merged and added the LED driver_data for my card) doesn't work. This one does work. >> So, after seeing that the rest of the file is sorted this way (generic >> section after the specific ones), I concluded that the 0x002A sorting >> was wrong in the first place, and so is 0x0029. Then I sent this patch >> to fix this. > > I can't see how changing the order in ath_pci_id_table[] would make any > difference in functionality, but I might be missing something. It does: I've looked through the relevant code, and found that PCI device matching from that table is done sequentially in pci_match_id() from drivers/pci/pci-driver.c. So if a generic PCI_VDEVICE entry (that has both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will match first and will be used. >>> And your email headers look weird: >>> >>> To: <kv...@codeaurora.org> >>> Cc: <linux-wirel...@vger.kernel.org> >>> Cc: <ath9k-de...@qca.qualcomm.com> >>> Cc: <ath9k-de...@venema.h4ckr.net> >>> Cc: <sta...@vger.kernel.org> >>> Date: Mon, 3 Oct 2016 12:00:56 +0200 >>> >>> What software are you using to send this? Only one CC header is valid >>> according to the spec (thanks to Luca for checking) even though mailers >>> seem to handle multiple CC headers. But for example my patchwork script >>> fails with this and uses only the first CC header. >> >> Sorry about this, I used a custom mailer to send the patch since I was >> having problems with git-send-email... > > Ok, that explains it. _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
