summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-17USB: cdc-acm: fix rounding error in TIOCSSERIALAnthony Mallet
By default, tty_port_init() initializes those parameters to a multiple of HZ. For instance in line 69 of tty_port.c: port->close_delay = (50 * HZ) / 100; https://github.com/torvalds/linux/blob/master/drivers/tty/tty_port.c#L69 With e.g. CONFIG_HZ = 250 (as this is the case for Ubuntu 18.04 linux-image-4.15.0-37-generic), the default setting for close_delay is thus 125. When ioctl(fd, TIOCGSERIAL, &s) is executed, the setting returned in user space is '12' (125/10). When ioctl(fd, TIOCSSERIAL, &s) is then executed with the same setting '12', the value is interpreted as '120' which is different from the current setting and a EPERM error may be raised by set_serial_info() if !CAP_SYS_ADMIN. https://github.com/torvalds/linux/blob/master/drivers/usb/class/cdc-acm.c#L919 Fixes: ba2d8ce9db0a6 ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312133101.7096-2-anthony.mallet@laas.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-17USB: cdc-acm: fix close_delay and closing_wait units in TIOCSSERIALAnthony Mallet
close_delay and closing_wait are specified in hundredth of a second but stored internally in jiffies. Use the jiffies_to_msecs() and msecs_to_jiffies() functions to convert from each other. Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312133101.7096-1-anthony.mallet@laas.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-17usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adaptersHans de Goede
We have been receiving bug reports that ethernet connections over RTL8153 based ethernet adapters stops working after a while with errors like these showing up in dmesg when the ethernet stops working: [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1 docks and with generic USB to ethernet dongles using the RTL8153 chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to the kernel commandline and all users who have tried this report that this fixes this. Also note that we already have an existing NO_LPM quirk for the RTL8153 used in the Microsoft Surface Dock (where it uses a different usb-id). This commit adds a NO_LPM quirk for the generic Realtek RTL8153 0bda:8153 usb-id, fixing the Tx timeout errors on these devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931 Cc: stable@vger.kernel.org Cc: russianneuromancer@ya.ru Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200313120708.100339-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-17usb: chipidea: udc: fix sleeping function called from invalid contextPeter Chen
The code calls pm_runtime_get_sync with irq disabled, it causes below warning: BUG: sleeping function called from invalid context at wer/runtime.c:1075 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: er/u8:1 CPU: 1 PID: 37 Comm: kworker/u8:1 Not tainted 20200304-00181-gbebfd2a5be98 #1588 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: ci_otg ci_otg_work [<c010e8bd>] (unwind_backtrace) from [<c010a315>] 1/0x14) [<c010a315>] (show_stack) from [<c0987d29>] 5/0x94) [<c0987d29>] (dump_stack) from [<c013e77f>] +0xeb/0x118) [<c013e77f>] (___might_sleep) from [<c052fa1d>] esume+0x75/0x78) [<c052fa1d>] (__pm_runtime_resume) from [<c0627a33>] 0x23/0x74) [<c0627a33>] (ci_udc_pullup) from [<c062fb93>] nect+0x2b/0xcc) [<c062fb93>] (usb_gadget_connect) from [<c062769d>] _connect+0x59/0x104) [<c062769d>] (ci_hdrc_gadget_connect) from [<c062778b>] ssion+0x43/0x48) [<c062778b>] (ci_udc_vbus_session) from [<c062f997>] s_connect+0x17/0x9c) [<c062f997>] (usb_gadget_vbus_connect) from [<c062634d>] bd/0x128) [<c062634d>] (ci_otg_work) from [<c0134719>] rk+0x149/0x404) [<c0134719>] (process_one_work) from [<c0134acb>] 0xf7/0x3bc) [<c0134acb>] (worker_thread) from [<c0139433>] x118) [<c0139433>] (kthread) from [<c01010bd>] (ret_from_fork+0x11/0x34) Tested-by: Dmitry Osipenko <digetx@gmail.com> Cc: <stable@vger.kernel.org> #v5.5 Fixes: 72dc8df7920f ("usb: chipidea: udc: protect usb interrupt enable") Reported-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20200316031034.17847-2-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-17iwlwifi: move AX200 devices to the new tableLuca Coelho
Move the AX200 devices to the new table and add the appropriate cfg struct and strings. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.fdfa5f31b8b1.Idfd28829d9f3820de06d3bba8fa66048b8d0d0b0@changeid
2020-03-17iwlwifi: remove trans entries from COMMON 9260 macroLuca Coelho
These entries are decided at runtime using the new parameters now, so they are not needed in the macro that is reused in the configs. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.3387a6c8fdbe.I98284457f26c5695754964b28f0257a7dc7c6b1c@changeid
2020-03-17iwlwifi: move shared clock entries to new tableLuca Coelho
These devices can now also be fully differentiated by using the new parameters. Move them all to the new table format. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.11c65d195677.I8faf50b325282df4892520a3b21fbdedabbb64f0@changeid
2020-03-17iwlwifi: move pu devices to new tableLuca Coelho
All the pu devices can now be differentiated using the new parameters, so move them all to the new tables accordingly. This also includes removal of a few deprecated IDs and redundant cfg structs. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.e7dc61e665f3.I44dcf9195bb8cc9e8c8e3e87182e9185c819a99d@changeid
2020-03-17iwlwifi: remove 9260 devices with 0x1010 and 0x1210 subsytem IDsLuca Coelho
These devices don't exist anymore, so remove them from the tables. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.fef62aa45887.I302e32b7cfff7da0d920547fae60ad9f2296e052@changeid
2020-03-17iwlwifi: convert the 9260-1x1 device to use the new parametersLuca Coelho
The 9260-1x1 device can be differentiated using the PCI device ID. There is a single occurrence of this device, so continue relying on the device and subsystem device IDs. The name of this device was incorrect, so add a new string specifically for it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.4d74e1be7cac.Id27bd9c878b73cb771691cbe6082fd40e079b44d@changeid
2020-03-17iwlwifi: move TH1 devices to the new tableLuca Coelho
TH1 devices can now be fully differentiated by using the device parameters we have (particularly the RF_TYPE). Start using these parameters instead of hardcoding to specific subsystem device IDs. This also fixes the name of one of the TH1 devices that was erroneously using the 9260 struct and renames 9160 to 9162. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.18d4304b5454.Ib168d186da88393e9ec46f0fca523edb48d9138e@changeid
2020-03-17iwlwifi: map 9461 and 9462 using RF type and RF IDLuca Coelho
These devices can be differentiated depending on the RF type and RF ID. Change them to use these instead of relying on the subsystem device IDs. This also fixes some names that were not including 160MHz (as they should). Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.345de1efb3ec.Ib9221027a955188ea7c1ffca8a45bccd6c1e6a13@changeid
2020-03-17iwlwifi: add Pu/PnJ/Th device values to differentiate themLuca Coelho
Pu, PnJ and Th devices have different combinations of PCI ID, MAC ID and RF IDs. Use these to differentiate them and choose the correct configuration. This also includes a change from using soc cfg's for 0x2526 devices (PnJ/Th), which was incorrect. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.602bb33528cf.I3acacb07c69ed063c7f1ca78f2dce9b7b4ef3946@changeid
2020-03-17iwlwifi: add GNSS differentiation to the device tablesLuca Coelho
Devices that also include a GNSS module have different names, so add a new device option to differentiate them, according to the values we have in the modules section of the subsystem device ID. Additionally, convert the two applicable devices to use this value instead of hardcoded subsystem IDs. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.1f958e558d05.I45492bb57cbbeb4cc0ec84313bade4def7377a27@changeid
2020-03-17iwlwifi: add mac/rf types and 160MHz to the device tablesLuca Coelho
Add MAC ID, RF ID and the bit that tells us whether the device can handle 160MHz bandwidth to the device struct. This allows us to chose the correct structure and string depending on these parameters. Do so for all the 0x2526 devices we already moved to the new table. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.a6bef6ee8fe1.I01f7a6f49aa60d2d61633a8a8b859015681eac5b@changeid
2020-03-17iwlwifi: combine 9260 cfgs that only change namesLuca Coelho
All the 0x2526 devices are now in the new table, so we can start reusing configurations and adding the strings independently to all of them, reusing them when possible. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.88e3d47c42a8.I1bd37ae0d0f9f79732f03badf84d7d063993b73e@changeid
2020-03-17iwlwifi: move the remaining 0x2526 configs to the new tableLuca Coelho
Now that we have the strings separate from the rest, we can move the remaining 0x2526 devices to the new table in preparation to reuse the configs. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.a7998f8d7507.I4be8776edb8c30416efc184c66f11add5eed06de@changeid
2020-03-17bpf, libbpf: Fix ___bpf_kretprobe_args1(x) macro definitionWenbo Zhang
Use PT_REGS_RC instead of PT_REGS_RET to get ret correctly. Fixes: df8ff35311c8 ("libbpf: Merge selftests' bpf_trace_helpers.h into libbpf's bpf_tracing.h") Signed-off-by: Wenbo Zhang <ethercflow@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200315083252.22274-1-ethercflow@gmail.com
2020-03-17selftests/bpf: Reset process and thread affinity after each test/sub-testAndrii Nakryiko
Some tests and sub-tests are setting "custom" thread/process affinity and don't reset it back. Instead of requiring each test to undo all this, ensure that thread affinity is restored by test_progs test runner itself. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200314013932.4035712-3-andriin@fb.com
2020-03-17selftests/bpf: Fix test_progs's parsing of test numbersAndrii Nakryiko
When specifying disjoint set of tests, test_progs doesn't set skipped test's array elements to false. This leads to spurious execution of tests that should have been skipped. Fix it by explicitly initializing them to false. Fixes: 3a516a0a3a7b ("selftests/bpf: add sub-tests support for test_progs") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20200314013932.4035712-2-andriin@fb.com
2020-03-17selftests/bpf: Fix race in tcp_rtt testAndrii Nakryiko
Previous attempt to make tcp_rtt more robust introduced a new race, in which server_done might be set to true before server can actually accept any connection. Fix this by unconditionally waiting for accept(). Given socket is non-blocking, if there are any problems with client side, it should eventually close listening FD and let server thread exit with failure. Fixes: 4cd729fa022c ("selftests/bpf: Make tcp_rtt test more robust to failures") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20200314013932.4035712-1-andriin@fb.com
2020-03-17selftests/bpf: Fix nanosleep for real this timeAndrii Nakryiko
Amazingly, some libc implementations don't call __NR_nanosleep syscall from their nanosleep() APIs. Hammer it down with explicit syscall() call and never get back to it again. Also simplify code for timespec initialization. I verified that nanosleep is called w/ printk and in exactly same Linux image that is used in Travis CI. So it should both sleep and call correct syscall. v1->v2: - math is too hard, fix usec -> nsec convertion (Martin); - test_vmlinux has explicit nanosleep() call, convert that one as well. Fixes: 4e1fd25d19e8 ("selftests/bpf: Fix usleep() implementation") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20200314002743.3782677-1-andriin@fb.com
2020-03-17selftest/bpf: Fix compilation warning in sockmap_parse_prog.cAndrii Nakryiko
Remove unused len variable, which causes compilation warnings. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20200314001834.3727680-1-andriin@fb.com
2020-03-17CIFS: fiemap: do not return EINVAL if get nothingMurphy Zhou
If we call fiemap on a truncated file with none blocks allocated, it makes sense we get nothing from this call. No output means no blocks have been counted, but the call succeeded. It's a valid response. Simple example reproducer: xfs_io -f 'truncate 2M' -c 'fiemap -v' /cifssch/testfile xfs_io: ioctl(FS_IOC_FIEMAP) ["/cifssch/testfile"]: Invalid argument Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> CC: Stable <stable@vger.kernel.org>
2020-03-17CIFS: Increment num_remote_opens stats counter even in case of ↵Shyam Prasad N
smb2_query_dir_first The num_remote_opens counter keeps track of the number of open files which must be maintained by the server at any point. This is a per-tree-connect counter, and the value of this counter gets displayed in the /proc/fs/cifs/Stats output as a following... Open files: 0 total (local), 1 open on server ^^^^^^^^^^^^^^^^ As a thumb-rule, we want to increment this counter for each open/create that we successfully execute on the server. Similarly, we should decrement the counter when we successfully execute a close. In this case, an increment was being missed in case of smb2_query_dir_first, in case of successful open. As a result, we would underflow the counter and we could even see the counter go to negative after sufficient smb2_query_dir_first calls. I tested the stats counter for a bunch of filesystem operations with the fix. And it looks like the counter looks correct to me. I also check if we missed the increments and decrements elsewhere. It does not seem so. Few other cases where an open is done and we don't increment the counter are the compound calls where the corresponding close is also sent in the request. Signed-off-by: Shyam Prasad N <nspmangalore@gmail.com> CC: Stable <stable@vger.kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2020-03-17cifs: potential unintitliazed error code in cifs_getattr()Dan Carpenter
Smatch complains that "rc" could be uninitialized. fs/cifs/inode.c:2206 cifs_getattr() error: uninitialized symbol 'rc'. Changing it to "return 0;" improves readability as well. Fixes: cc1baf98c8f6 ("cifs: do not ignore the SYNC flags in getattr") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Steve French <stfrench@microsoft.com> Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>
2020-03-17ALSA: hda/realtek - Enable the headset of Acer N50-600 with ALC662Jian-Hong Pan
A headset on the desktop like Acer N50-600 does not work, until quirk ALC662_FIXUP_ACER_NITRO_HEADSET_MODE is applied. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200317082806.73194-3-jian-hong@endlessm.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-17ALSA: hda/realtek - Enable headset mic of Acer X2660G with ALC662Jian-Hong Pan
The Acer desktop X2660G with ALC662 can't detect the headset microphone until ALC662_FIXUP_ACER_X2660G_HEADSET_MODE quirk applied. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200317082806.73194-2-jian-hong@endlessm.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-03-17ARM: dts: omap5: Add bus_dma_limit for L3 busRoger Quadros
The L3 interconnect's memory map is from 0x0 to 0xffffffff. Out of this, System memory (SDRAM) can be accessed from 0x80000000 to 0xffffffff (2GB) OMAP5 does support 4GB of SDRAM but upper 2GB can only be accessed by the MPU subsystem. Add the dma-ranges property to reflect the physical address limit of the L3 bus. Cc: stable@kernel.org Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-17ARM: dts: omap4-droid4: Fix lost touchscreen interruptsTony Lindgren
Looks like we can have the maxtouch touchscreen stop producing interrupts if an edge interrupt is lost. This can happen easily when the SoC idles as the gpio controller may not see any state for an edge interrupt if it is briefly triggered when the system is idle. Also it looks like maxtouch stops sending any further interrupts if the interrupt is not handled. And we do have several cases of maxtouch already configured with a level interrupt, so let's do that. With level interrupt the gpio controller has the interrupt state visible after idle. Note that eventually we will probably also be using the Linux generic wakeirq configured for the controller, but that cannot be done until the maxtouch driver supports runtime PM. Cc: maemo-leste@lists.dyne.org Cc: Arthur Demchenkov <spinal.by@gmail.com> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-17mt76: mt7615: introduce mt7663e supportLorenzo Bianconi
Introduce support for mt7663e 802.11ac 2x2:2 chipset to mt7615 driver. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: get rid of sta_rec_wtbl data structureLorenzo Bianconi
Sobstitute sta_rec_wtbl data structure with tlv one Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce set_ba uni commandLorenzo Bianconi
Introduce mt7615_mcu_uni_set_ba routine in order to add support for mt7663e driver Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: add more uni mcu commandsSean Wang
Introduce mt7615_mcu_uni_set_bss, mt7615_mcu_uni_set_dev and mt7615_mcu_uni_set_beacon_offload uni mcu commands. This is a preliminary patch to add mt7663e support Signed-off-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce set_bmc and st_sta for uni commandsLorenzo Bianconi
Introduce mt7615_mcu_uni_set_bmc and mt7615_mcu_uni_set_sta routines for mt7663e commands. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce uni cmd command typesLorenzo Bianconi
Introduce mcu uni command type. Uni commands rely on a stripped verions of mt7615_mcu_txd data strutture. Split mt7615_mcu_txd_common and mt7615_mcu_txd. Uni commands will be use by mt7663e driver Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce mt7615_init_mac_chain routineLorenzo Bianconi
Introduce mt7615_init_mac_chain routine to configure per band mac register since new devices (e.g. mt7663e) do not support dbdc Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce mt7615_eeprom_parse_hw_band_cap routineLorenzo Bianconi
Introduce mt7615_eeprom_parse_hw_band_cap routine in order to configure supported band for mt7663e and mt7622 devices since they do not rely on eeprom data to enable 2GHz/5GHz bands Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: add mt7663e support to mt7615_mcu_set_eepromLorenzo Bianconi
Extend mt7615_mcu_set_eeprom routine in order to be reused adding mt7663e support to mt7615 driver Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: add mt7663e support to mt7615_{driver,firmware}_ownLorenzo Bianconi
Extend mt7615_driver_own and mt7615_firmware_own in order to reuse them adding mt7663e support to mt7615 driver Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: add mt7663e support to mt7615_reg_mapLorenzo Bianconi
Introduce mt7663e support to mt7615_reg_map routine in order to reuse it adding support for mt7663e driver Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce mt7615_register_mapLorenzo Bianconi
In order to reuse mt7615 code adding support for mt7663e driver, introduce mt7615e_reg_map since mt7663e and mt7615 rely on a different base registers definitions. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce MCU_FW_PREFIX for fw mcu commandsLorenzo Bianconi
Currently fw commands rely on negative cmds since they need different mcu msg metadata. Extend this approach introducing MCU_FW_PREFIX. This is a preliminary patch to support new mt7663e firmware commands Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: move more mcu commands in mt7615_mcu_ops data structureLorenzo Bianconi
Move mt7615_mcu_set_beacon_offload, mt7615_mcu_set_dev and mt7615_mcu_set_bss routine in mt7615_mcu_ops data structure. This is a preliminary patch to support mt7663 firmware Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: rework mt7615_mcu_set_bss_info using skb APIsLorenzo Bianconi
Simplify mt7615_mcu_set_bss_info relying on mcu tlv helpers Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: rely on skb API for mt7615_mcu_set_eepromLorenzo Bianconi
Rely on skb API and avoid kmalloc the buffer in mt7615_mcu_set_eeprom routine Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: move mt7615_mcu_set_sta in mt7615_mcu_opsLorenzo Bianconi
Move mt7615_mcu_set_sta for fw version 1 and version 2 in mt7615_mcu_ops data structure. This is a preliminary patch to properly support mt7663e firmware. Rework utility routines to rely on skb APIs for msg parsing Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: move mt7615_mcu_set_bmc to mt7615_mcu_opsLorenzo Bianconi
Move mt7615_mcu_set_bmc for fw version 1 and version 2 in mt7615_mcu_ops data structure. This is a preliminary patch to properly support mt7663e firmware. Rework utility routines to rely on skb APIs for msg parsing Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: add mt7615_mcu_ops data structureLorenzo Bianconi
Introduce mt7615_mcu_ops data structure in order to support multiple mcu ops API. Move mt7615_mcu_set_{tx,rx}_ba to mt7615_mcu_ops differentiating between fw v1 and v2. This is a preliminary patch to properly support mt7663e firmware. Rework utility routines to rely on skb APIs for msg parsing Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2020-03-17mt76: mt7615: introduce mt7615_mcu_send_message routineLorenzo Bianconi
Introduce mt7615_mcu_send_message routine in order to allocate mcu skb out of mcu sending routine. This approach is useful when the mcu message is complicated and it is convenient to rely on skb buffer API Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>