Add support for Rivet Networks Killer Wireless-AC 1550 chipset,
which is using the Intel Wireless-AC 9260 chip
Signed-off-by: Izzy Kulbe <[email protected]>
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 56fc28750a41..62ab4790687c 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -543,6 +543,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x2526, 0x1210, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg_soc)},
+ {IWL_PCI_DEVICE(0x2526, 0x1550, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)},
{IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)},
--
2.16.2
On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> > > Izzy Kulbe <[email protected]> writes:
> > >
> > > > nvm the last message, attached the wrong file using the 9270
> > > > instead of the 9260 firmware, which obviously wouldn't work.
> > > > Here's the working patch:
> > > >
> > > >
> > > > Add support for Rivet Networks Killer Wireless-AC 1550
> > > > chipset,
> > > > which is using the Intel Wireless-AC 9260 chip
> > > >
> > > > Signed-off-by: Izzy Kulbe <[email protected]>
> > > >
> > > > ---
> > >
> > > You should put the comment "nvm the last message..." under the "-
> > > --
> > > "
> > > line so that git-am can ignore it.
> >
> > Sorry, still new to the whole process. should i just resend
> > that message with the proper order?
>
> Wait a bit. This ID looks strange, someone else reported this
> already
> and it looked strange, with an incorrect subsystem vendor ID.
>
> Can you run lspci like this and let us know the results?
>
> lspci -nv -s 3b:00.0
Sorry, please substitute the 3b:00.0 with the correct PCI slot in your
system. If you're not sure, remove the '-s 3b:00.0' entirely so we'll
get the results for all devices.
--
Luca.
On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> On Tue, 2018-03-27 at 14:48 +0300, Kalle Valo wrote:
> > Izzy Kulbe <[email protected]> writes:
> >
> > > nvm the last message, attached the wrong file using the 9270
> > > instead of the 9260 firmware, which obviously wouldn't work.
> > > Here's the working patch:
> > >
> > >
> > > Add support for Rivet Networks Killer Wireless-AC 1550 chipset,
> > > which is using the Intel Wireless-AC 9260 chip
> > >
> > > Signed-off-by: Izzy Kulbe <[email protected]>
> > >
> > > ---
> >
> > You should put the comment "nvm the last message..." under the "---
> > "
> > line so that git-am can ignore it.
>
> Sorry, still new to the whole process. should i just resend
> that message with the proper order?
Wait a bit. This ID looks strange, someone else reported this already
and it looked strange, with an incorrect subsystem vendor ID.
Can you run lspci like this and let us know the results?
lspci -nv -s 3b:00.0
--
Cheers,
Luca.
On Tue, 2018-03-27 at 15:38 +0300, Luciano Coelho wrote:
> On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> > On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > Wait a bit. This ID looks strange, someone else reported this
> > already
> > and it looked strange, with an incorrect subsystem vendor ID.
> >
> > Can you run lspci like this and let us know the results?
> > weird
> > lspci -nv -s 3b:00.0
>
> Sorry, please substitute the 3b:00.0 with the correct PCI slot in your
> system. If you're not sure, remove the '-s 3b:00.0' entirely so we'll
> get the results for all devices.
>
> --
> Luca.
The subsystem device in lspci itself reports "Bigfoot Networks,
Inc. Wireless-AC 9260" instead of when lookup is enabled. AFAIR this
was a company that was bought by Qualcomm? So not Rivet/Killer.
Here's the lspci output:
root@dokidoki $> # lspci-nv -s 04:00.0
04:00.0 0280: 8086:2526 (rev 29)
Subsystem: 1a56:1550
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at d3d00000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
On Tue, 2018-03-27 at 14:48 +0200, Izzy Kulbe wrote:
> On Tue, 2018-03-27 at 15:38 +0300, Luciano Coelho wrote:
> > On Tue, 2018-03-27 at 15:37 +0300, Luciano Coelho wrote:
> > > On Tue, 2018-03-27 at 14:03 +0200, Izzy Kulbe wrote:
> > > Wait a bit. This ID looks strange, someone else reported this
> > > already
> > > and it looked strange, with an incorrect subsystem vendor ID.
> > >
> > > Can you run lspci like this and let us know the results?
> > > weird
> > > lspci -nv -s 3b:00.0
> >
> > Sorry, please substitute the 3b:00.0 with the correct PCI slot in
> > your
> > system. If you're not sure, remove the '-s 3b:00.0' entirely so
> > we'll
> > get the results for all devices.
> >
> > --
> > Luca.
>
> The subsystem device in lspci itself reports "Bigfoot Networks,
> Inc. Wireless-AC 9260" instead of when lookup is enabled. AFAIR this
> was a company that was bought by Qualcomm? So not Rivet/Killer.
>
> Here's the lspci output:
>
> root@dokidoki $> # lspci-nv -s 04:00.0
> 04:00.0 0280: 8086:2526 (rev 29)
> Subsystem: 1a56:1550
> Flags: bus master, fast devsel, latency 0, IRQ 17
> Memory at d3d00000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [c8] Power Management version 3
> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [40] Express Endpoint, MSI 00
> Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [14c] Latency Tolerance Reporting
> Capabilities: [154] L1 PM Substates
> Kernel driver in use: iwlwifi
> Kernel modules: iwlwifi
Thanks!
Yeah, this looks wrong and the same as someone else reported. :(
This value is coming from the OTP in the NIC and seems to be wrong. I
have to contact our engineer who is responsible for the OTP data. I'll
let you know once I get back some more information.
--
Cheers,
Luca.