Normally firmware messages are printed with debugging enabled only. It's
a good idea as firmware may print a lot of messages that normal users
don't need to care about.
However, on firmware crash, it may be very helpful to log all recent
messages. There is almost always a backtrace available as well as rought
info on the latest actions/state.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This includes bus reset & reloading a firmware. It should be sufficient
for a user space to (setup and) use a wireless device again.
Support for reset on USB & SDIO can be added later.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This improves handling PCIe firmware halts by printing a clear error
message and replaces a similar code in the SDIO bus support.
It will also allow further improvements like trying to recover from a
firmware crash.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called
once only during the probe. It's safe to assume provided array is clear.
Further brcmfmac improvements may require calling it multiple times
though. This patch allows it by fixing invalid firmware paths like:
brcm/brcmfmac4366c-pcie.binbrcm/brcmfmac4366c-pcie.bin
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Renaming a netdev-trigger-tracked interface was resulting in an
unbalanced dev_hold().
Example:
> iw phy phy0 interface add foo type __ap
> echo netdev > trigger
> echo foo > device_name
> ip link set foo name bar
> iw dev bar del
[ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1
[ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1
[ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1
Above problem was caused by trigger checking a dev->name which obviously
changes after renaming an interface. It meant missing all further events
including the NETDEV_UNREGISTER which is required for calling dev_put().
This change fixes that by:
1) Comparing device struct *address* for notification-filtering purposes
2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change)
Fixes: 06f502f57d ("leds: trigger: Introduce a NETDEV trigger")
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>
Firmware may report general errors using a special message type. Add
basic support for it by simply decoding & printing an error number.
A sample situation in which firmware reports a buf error:
CONSOLE: 027084.733 no host response IOCTL buffer available..so fail the request
will now produce a "Firmware reported general error: 9" on the host.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This updates host struct to match the in-firmawre definition. It's a
cosmetic change as it only applies to the reserved struct space.
Fixes: c988b78244 ("brcmfmac: print firmware reported ring status errors")
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
While experimenting with firmware loading I ended up in a state of
firmware reporting shared RAM address 0x04000001. It was causing:
[ 94.448015] Unable to handle kernel paging request at virtual address cd680001
due to reading out of the mapped memory.
This patch adds some basic validation to avoid kernel crashes due to the
unexpected firmware behavior.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This recently added macro provides more meaningful error messages thanks
to identifying a specific wiphy. It's especially important on systems
with few cards supported by the same (brcmfmac) driver.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This macro will be used in more places not just the cfg80211.c. It makes
sense to pass some common struct to it as "struct wiphy" is mostly
referenced in cfg80211 code only.
A very common one (used above the bus abstraction layer) is struct
brcmf_pub. Many functions already keep reference to it which will make
using bphy_err() simpler. It should also allow extending that macro's
logic if it's ever needed.
This improves code recently added in the commit 3ef005b82e ("brcmfmac:
add bphy_err() and use it in the cfg80211.c").
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
So far 160 MHz channels were treated as 20 MHz ones which was breaking
support for 40/80 MHz due to the brcmf_construct_chaninfo() logic and
its assumptions.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
1) Use switch to simplify/improve the code & avoid some duplication
2) Add warning for unsupported values
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Firmware is capable of reporting ring status. It's used e.g. to signal
some problem with a specific ring setup. This patch adds support for
printing ring & error number which may be useful for debugging setup
issues.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
So far there were two monitor frame formats:
1) 802.11 frames (with frame (sub)type & all addresses)
2) 802.11 frames with the radiotap header
Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in
discovering a new format being used. It seems (almost?) identical to the
one known from ucode used in SoftMAC devices which is most likely the
same codebase anyway.
While new firmwares will /announce/ radiotap header support using the
"rtap" fw capability string it seems no string was added for the new
ucode header format.
All above means that:
1) We need new format support when dealing with a received frame
2) A new feature bit & mapping quirks have to be added manually
As for now only an empty radiotap is being created. Adding support for
extracting some info (band, channel, signal, etc.) is planned for the
future.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This new macro uses wiphy_err() which:
1) Should be the best choice with wiphy already created
2) Uses dev_err() which allows identifying error-affected device
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This enables dev_err() usage (instead of pr_err()) in the __brcmf_err().
It makes error messages more meaningful and is important for debugging
errors/bugs on systems with multiple brcmfmac supported devices.
All bus files should follow & get updated similarly (soon).
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
So far __brcmf_err() was using pr_err() which didn't allow identifying
device that was affected by an error. It's crucial for systems with more
than 1 device supported by brcmfmac (a common case for home routers).
This change allows passing struct brcmf_bus to the __brcmf_err(). That
struct has been agreed to be the most common one. It allows accessing
struct device easily & using dev_err() printing helper.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This fixes printing clock names in cases like:
[ 5.352311] [drm] DM_PPLIB: values for Invalid clock
[ 5.352313] [drm] DM_PPLIB: 400000 in kHz
[ 5.352313] [drm] DM_PPLIB: 933000 in kHz
[ 5.352314] [drm] DM_PPLIB: 1067000 in kHz
[ 5.352315] [drm] DM_PPLIB: 1200000 in kHz
[ 5.352317] [drm] DM_PPLIB: values for Invalid clock
[ 5.352318] [drm] DM_PPLIB: 300000 in kHz
[ 5.352318] [drm] DM_PPLIB: 600000 in kHz
[ 5.352319] [drm] DM_PPLIB: 626000 in kHz
[ 5.352320] [drm] DM_PPLIB: 654000 in kHz
(source: HP EliteBook 745 G5 w. RAVEN 0x1002:0x15DD 0x103C:0x83D5 0xD1)
On my system above "Invalid" names got replaced by "F" and "DCF".
The same problem was occurring on Huawei Matebook D with just 667000 kHz
instead of 400000 kHz.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Accessing struct device is pretty useful/common so having a direct
pointer:
1) Simplifies some code
2) Makes bcma_bus_get_host_dev() unneeded
3) Allows further improvements like using dev_* printing helpers
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Documentation has been recently updated specifying that pinctrl should
be subnode of the CRU "syscon". Support that by using parent node for
regmap and reading "offset" property from the DT.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
As pointed by Rob, CRU is a kind of block that can't be guaranteed to
have everything exposed as subnodes. It's a set of various registers
that aren't tied to any single device. It could be described much more
accurately as MFD (Multi-Function Device).
Some hardware blocks may indeed want to access a register or two of the
CRU which requires describing it as the "syscon".
While at it replace exmple node name with the standard "pinctrl" (also
pointed out by Rob).
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
When checking for alignment mtd should check absolute offsets. It's
important for subpartitions as it doesn't make sense to check their
relative addresses.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
When allocating a new partition mtd subsystem runs internal tests in the
allocate_partition(). They may result in modifying specified flags (e.g.
dropping some /features/ like write access).
Those constraints don't have to be necessary true for subpartitions. It
may happen parent partition isn't block aligned (effectively disabling
write access) while subpartition may fit blocks nicely. In such case all
checks should be run again (starting with original flags value).
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This describes hardware & will allow referencing pin functions. The
first usage is UART1 which allows supporting devices using it.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.
This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.
Signed-off-by: Rafał Miłecki <[email protected]>
Cc: [email protected]
Signed-off-by: Kalle Valo <[email protected]>
On one of my devices I got WARNINGs when brcmfmac tried to decode
chanspec. I couldn't tell if it was some unsupported format or just a
malformed value passed by a firmware.
Print chanspec value so it's possible to debug a possible problem.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Previous commit /adding/ support for 160 MHz chanspecs was incomplete.
It didn't set bandwidth info and didn't extract control channel info. As
the result it was also using uninitialized "sb" var.
This change has been tested for two chanspecs found to be reported by
some devices/firmwares:
1) 60/160 (0xee32)
Before: chnum:50 control_ch_num:36
After: chnum:50 control_ch_num:60
2) 120/160 (0xed72)
Before: chnum:114 control_ch_num:100
After: chnum:114 control_ch_num:120
Fixes: 330994e8e8 ("brcmfmac: fix for proper support of 160MHz bandwidth")
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This matches licensing used by most of BCM5301X files and is preferred as:
1) GPL 2.0+ makes it clearly compatible with Linux kernel
2) MIT is also permissive but preferred over ISC
This file has been developed by me & once modified by Rob dropping a
single leading zero in an UART address.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This matches licensing used by most of BCM5301X files and is preferred as:
1) GPL 2.0+ makes it clearly compatible with Linux kernel
2) MIT is also permissive but preferred over ISC
This file was fully developed by me.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This matches licensing used by other BCM5301X files and is preferred as:
1) GPL 2.0+ makes it clearly compatible with Linux kernel
2) MIT is also permissive but preferred over ISC
This file has been developed by me & once modified by Vivek.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Vivek Unune <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This matches licensing used by other BCM5301X files and is preferred as:
1) GPL 2.0+ makes it clearly compatible with Linux kernel
2) MIT is also permissive but preferred over ISC
Both files were fully developed by me. Commits touching them were signed
by Florian and Hauke due to submitting process only.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Broadcom SoC pins are controlled using CRU ("Clock and Reset Unit" or
"Central Resource Unit") registers. There are more CRU registers and
functions so CRU should be represented as a separated block in DT.
Moreover CRU is a sub-block of DMU ("Device Management Unit") so that
one should also get its own node.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Fix up a compiler error on 64bit architectures where pointers
and integers differ in size.
Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Fixing/optimizing bcm_qspi_bspi_read() performance introduced two
changes:
1) It added a loop to read all requested data using multiple BSPI ops.
2) It bumped max size of a single BSPI block request from 256 to 512 B.
The later change resulted in occasional BSPI timeouts causing a
regression.
For some unknown reason hardware doesn't always handle reads as expected
when using 512 B chunks. In such cases it may happen that BSPI returns
amount of requested bytes without the last 1-3 ones. It provides the
remaining bytes later but doesn't raise an interrupt until another LR
start.
Switching back to 256 B reads fixes that problem and regression.
Fixes: 345309fa7c ("spi: bcm-qspi: Fix bcm_qspi_bspi_read() performance")
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
During implementation of the new API bcm_qspi_bspi_set_flex_mode() has
been modified breaking calculation of address length. An unnecessary
multiplication was added breaking flash reads.
Fixes: 5f195ee7d8 ("spi: bcm-qspi: Implement the spi_mem interface")
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
This driver provides support for Northstar mux controller. It differs
from Northstar Plus one so a new binding and driver were needed.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Northstar has mux controller just like Northstar Plus and Northstar2.
It's a bit different though (different registers & pins) so it requires
its own binding.
It's needed to allow other block bindings specify required mux setup.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Most devices use Broadcom standard partitions which allows them to be
described with the "brcm,bcm947xx-cfe-partitions". Exceptions are:
1) TP-LINK devices which use "os-image" partition with TRX containing
kernel only + separated rootfs partition.
2) Asus RT-AC87U with custom "asus" partition.
This commit also removes undocumented and unsupported linux,part-probe
binding which got accidentally upstreamed while describing SPI
controller.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This driver doesn't specify parsers so it can use that little helper.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Most firmwares support monitor interface but only the latest ones
/announce/ it with a "monitor" flag in the "cap" iovar. There isn't any
reliable detection method for older firmwares (BRCMF_C_MONITOR was tried
but "it only indicates the core part of the stack supports").
Similarly support for tagging monitor frames and building radiotap
headers can't be reliably detected for all firmwares.
This commit adds table that allows mapping features to firmware version.
It adds mappings for 43602a1 and 4366b1 firmwares from
linux-firmware.git. Both were confirmed to be passing monitor frames.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This reverts commit 2a027b47db ("MIPS: BCM47XX: Enable 74K Core
ExternalSync for PCIe erratum").
Enabling ExternalSync caused a regression for BCM4718A1 (used e.g. in
Netgear E3000 and ASUS RT-N16): it simply hangs during PCIe
initialization. It's likely that BCM4717A1 is also affected.
I didn't notice that earlier as the only BCM47XX devices with PCIe I
own are:
1) BCM4706 with 2 x 14e4:4331
2) BCM4706 with 14e4:4360 and 14e4:4331
it appears that BCM4706 is unaffected.
While BCM5300X-ES300-RDS.pdf seems to document that erratum and its
workarounds (according to quotes provided by Tokunori) it seems not even
Broadcom follows them.
According to the provided info Broadcom should define CONF7_ES in their
SDK's mipsinc.h and implement workaround in the si_mips_init(). Checking
both didn't reveal such code. It *could* mean Broadcom also had some
problems with the given workaround.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Paul Burton <[email protected]>
Reported-by: Michael Marley <[email protected]>
Patchwork: https://patchwork.linux-mips.org/patch/20032/
URL: https://bugs.openwrt.org/index.php?do=details&task_id=1688
Cc: Tokunori Ikegami <[email protected]>
Cc: Hauke Mehrtens <[email protected]>
Cc: Chris Packham <[email protected]>
Cc: James Hogan <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
NVRAM is designed to work with Broadcom's SDK Linux kernel which fakes
PCI domain 0 for all internal MMIO devices. Since official Linux kernel
uses platform devices for that purpose there is a mismatch in numbering
PCI domains.
There used to be a fix for that problem but it was accidentally dropped
during the last firmware loading rework. That resulted in brcmfmac not
being able to extract device specific NVRAM content and all kind of
calibration problems.
Reported-by: Aditya Xavier <[email protected]>
Fixes: 2baa3aaee2 ("brcmfmac: introduce brcmf_fw_alloc_request() function")
Cc: [email protected] # v4.17+
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
So far only flash devices could be described in DT regarding partitions
parsing. That could be done with "partitions" subnode and a proper
"compatible" string.
Some devices may use hierarchical (multi-level) layouts and may mix used
layouts (fixed and dynamic). Describing that in DT is done by specifying
"compatible" for DT-represented partition plus optionally more
properties and/or subnodes.
To support such layouts each DT partition has to be checked for
additional description.
Please note this implementation will work in parallel with support for
partition type specified for non-DT setups. That already works since
commit 1a0915be19 ("mtd: partitions: add support for partition
parsers").
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Documentation was already saying that fixed and dynamic partitioning can
be mixed but was missing a clear description and examples. This commit
adds a proper documentation of how descriptions can be nested and how
layouts can be mixed.
This addition is important for partitions that contain subpartitions.
In such cases partitions have to be properly described in order to let
system handle them correctly.
Depending on situation, nesting descriptions may provide more accurate
logic/structure and/or allow mixing partitioning types (various
"compatible" values).
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This driver doesn't specify parsers so it can use that little helper.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
If driver doesn't specify parsers it can use that little helper.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
This driver doesn't specify parsers so it can use that little helper.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
If driver doesn't specify parsers it can use that little helper.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This enables some features implemented in mtd subsystem like reading
label and partitioning info from DT.
Reported-by: Timothy Pearson <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
It's a standard ARM architected timer that was simply missed when
initially adding this .dtsi file.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This allows using TRX parser to find TRX partitions on flash device
described in DT using a proper binding. It's useful for devices storing
firmware on a separated flash and having rootfs partition in it.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Broadcom based home router devices use TRX firmware format. It's a
container that can hold few partitions. If operating system is expected
to access them it has to understand that format and parse flash data
accordingly.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
That struct is used when querying firmware for the STA. It seem is has
been changing during the time. Luckily its format seems to be backward
compatible starting with v2 (the only breakage was v1 -> v2).
The version that was supported by brcmfmac so far was v4. It was what
43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 accordingly)
were using. It also seems to be used by early 4366c0 firmwares
(10.10.69.6908 and 10.10.69.69017).
The problem appears when switching to the 10.10.122.20 firmware. It uses
v5 and instead of falling back to v4 when submitted buffer isn't big
enough it fallbacks to the v3.
To receive all v4 specific info with the newest firmware we have to
submit a struct (buffer) that matches v5.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
That struct is passed by a firmware when querying for STA info. Flags
are used to indicate what info could be obtained.
These new defines may allow passing more info to the cfg80211 in the
future. They had been obtained from Broadcom's SDK file wlioctl_defs.h
used by DD-WRT.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.
As not every firmware generates radiotap header this commit introduces
BRCMF_FEAT_MONITOR_FMT_RADIOTAP flag. It has to be has based on firmware
capabilities. If not present brcmf_netif_mon_rx() will assume packet is
a raw 802.11 frame and will prepend it with an empty radiotap header.
This new code is limited to the msgbuf protocol at this point. Adding
support for SDIO/USB devices will require some extra work (possibly a
new firmware release).
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Depending on used build-time options some firmwares may already include
radiotap header in passed monitor frames. Add a new feature flag to
store info about it. It's needed for proper handling of received frames
before passing them up.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Many/most of firmwares support creating monitor interface but only the
most recent ones explicitly /announce/ it using a "monitor" entry in the
list of capabilities.
Check for that entry and store internally info about monitor mode
support using a new feature flag. Once we sort out all details of
handling monitor interface it will be used when reporting available
interfaces to the cfg80211.
Later some fallback detecion method may be added for older firmwares.
For now just stick to the "monitor" capability which should be 100%
reliable.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This allows using bcm47xxpart parser to find partitions on flash
described in DT using the "brcm,bcm947xx-cfe-partitions" compatible
property. It means this parser doesn't have to be explicitly selected by
a flash driver anymore. It can be used e.g. together with a generic
m25p80 / spi-nor if device is just properly described.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Broadcom based home router devices use partitions which have to be
discovered in a specific way. They are not fixed and there is not any
standard partition table. This commit adds and describes a new custom
binding for such devices.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This allows reading all capabilities as reported by a firmware. They are
printed using native (raw) names, just like developers like it the most.
It's how firmware reports support for various features, e.g. supported
modes, supported standards, power saving details, max BSS-es.
Access to all that info is useful for trying new firmwares, comparing
them and debugging features AKA bugs.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
brcmfmac is a FullMAC driver and it implements/uses cfg80211 interface
for stations management. At the same time it doesn't receive or pass up
management frames.
This flag indicates that authenticator doesn't have to subscribe to or
handle management frames. Some authenticators (e.g. hostapd) were
working with brcmfmac thanks to some extra assumptions. This commit
clears up the situation.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported
symbols pcibios_enable_device and register_pci_controller. This code is
supposed to be compiled only with ssb builtin.
This fixes:
ERROR: "pcibios_enable_device" [drivers/ssb/ssb.ko] undefined!
ERROR: "register_pci_controller" [drivers/ssb/ssb.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
Reported-by: Matt Redfearn <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Larry Finger <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This reverts commit 882164a4a9.
Above commit added "SSB = y" dependency to the wrong symbol
SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from being
selected when needed. PCI core driver for core running in clienthost
mode is important for bus initialization. It's perfectly valid scenario
to have ssb built as module and use it with buses on PCI cards.
This fixes regression that affected all *module* users with PCI cards.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1572349
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Used buffer wasn't big enough to hold whole strings. Example output of
this function is:
[ 0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3 4 5 6 D I
[ 0.180948] bcma: bus0: core 0x0812, irq: 2(S) 3* 4 5 6 D I
[ 0.180998] bcma: bus0: core 0x082d, irq: 2(S) 3 4* 5 6 D I
[ 0.181046] bcma: bus0: core 0x082c, irq: 2(S) 3 4 5 6 D I*
which means we need to store up to 24 chars.
Fixes: 758f7e0606 ("bcma: Use bcma_debug and not pr_cont in MIPS driver")
Signed-off-by: Rafał Miłecki <[email protected]>
Cc: [email protected] # v4.15+
Signed-off-by: Kalle Valo <[email protected]>
When bcm47xxpart finds a TRX partition (container) it's supposed to jump
to the end of it and keep looking for more partitions. TRX and its
subpartitions are handled by a separate parser.
The problem with old code was relying on the length specified in a TRX
header. That isn't reliable as TRX is commonly modified to have checksum
cover only non-changing subpartitions. Otherwise modifying e.g. a rootfs
would result in CRC32 mismatch and bootloader refusing to boot a
firmware.
Fix it by trying better to figure out a real TRX size. We can securely
assume that TRX has to cover all subpartitions and the last one is at
least of a block size in size. Then compare it with a length field.
This makes code more optimal & reliable thanks to skipping data that
shouldn't be parsed.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This new syntax is slightly better designed & uses "compatible" string.
For details see Documentation/devicetree/bindings/mtd/partition.txt .
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
I accidentally sent an early version of patch removing spi-bcm53xx
driver which got rid of .c and .h files *only*. I amended local commit
but forgot to re-format the patch.
This commit removes leftovers of dropped driver.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
This matches licensing used by other BCM5301X files and is preferred as:
1) GPL 2.0+ makes is clearly compatible with Linux kernel
2) MIT is also permissive but preferred over ISC
This file were created and ever touched by a group of three people only:
Álvaro, Hauke and me.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Hauke Mehrtens <[email protected]>
Acked-by: Álvaro Fernández Rojas <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This driver was added by commit 0fc6a323e1 ("spi: bcm53xx: driver for
SPI controller on Broadcom bcma SoC") back in 2014. It was needed to
provide a minimal support for SPI controller on BCM5301X (AKA Northstar)
devices.
An alternative driver was added by Kamal in commit fa236a7ef2 ("spi:
bcm-qspi: Add Broadcom MSPI driver") 2 years later. It supports the same
hardware but for some reason a new driver has been developed for it.
At this point the new driver supports: more modes, setting a speed,
setting bits per word and uses IRQs instead of polling. DTS file for
BCM5301X has also been updated in the commit 1c8f406507 ("ARM: dts:
BCM5301X: convert to iProc QSPI") - over a year ago.
That explained I see no reason to keep the old driver alive.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
This matches licensing used by other BCM5301X files and is preferred as:
1) GPL 2.0+ makes is clearly compatible with Linux kernel
2) MIT is also permissive but preferred over ISC
These files were created and ever touched by a group of four people
only: Felix, INAGAKI, Hauke and me.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Felix Fietkau <[email protected]>
Acked-by: INAGAKI Hiroshi <[email protected]>
Acked-by: Hauke Mehrtens <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This commit slightly simplifies the code. Every parse_mtd_partitions()
caller (out of two existing ones) had to add partitions & cleanup parser
on its own. This moves that responsibility into the function.
That change also allows dropping struct mtd_partitions argument.
There is one minor behavior change caused by this cleanup. If
parse_mtd_partitions() fails to add partitions (add_mtd_partitions()
return an error) then mtd_device_parse_register() will still try to
add (register) fallback partitions. It's a real corner case affecting
one of uncommon error paths and shouldn't cause any harm.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
These files were created and ever touched by a group of three people
only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC.
Introducing and discussing SPDX-License-Identifier resulted in a
conclusion that ISC is a not recommended license (see also a
license-rules.rst). Moveover an old e-mail from Alan Cox was pointed
which explained that dual licensing is a safer solution than depending
on a common compatibility belief.
This commit switches most of BCM5301X DTS files to dual licensing using:
1) GPL 2.0+ to make sure they are compatible with Linux kernel
2) MIT to allow sharing with more permissive projects
Both licenses belong to the preferred ones (see LICENSES/preferred/).
An attempt to relicense remaining files will be made separately and will
require approve from more/other developers.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Hauke Mehrtens <[email protected]>
Acked-by: Dan Haab <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This adds support for detecting this model board and registers some LEDs
and buttons.
There are two uncommon things regarding this device:
1) It can use two different "board_id" ID values.
Unit I have uses "U12H139T00_NETGEAR" value. This magic is also used
in firmware file header. There are two reports (one from an OpenWrt
user) of a different "U12H139T50_NETGEAR" magic though.
2) Power LEDs share GPIOs with buttons.
Amber one seems to share GPIO 2 with WPS button and green one seems
to share GPIO 3 with reset button. It remains unknown how to support
them and handle buttons at the same time. For that reason they aren't
added to the list of supported LEDs.
Signed-off-by: Rafał Miłecki <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Hauke Mehrtens <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/19004/
Signed-off-by: James Hogan <[email protected]>
This new syntax is slightly better designed & uses "compatible" string.
For details see Documentation/devicetree/bindings/mtd/partition.txt .
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
In the commit 2c77c57d22 ("mtd: move code adding master MTD out of
mtd_add_device_partitions()") behavior of mtd_device_parse_register()
has very slightly changed. It's a pretty non-significant order change
to match updated function behavior.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Richard Weinberger <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This allows using this parser with any flash driver that takes care of
setting of_node (using mtd_set_of_node helper) correctly. Up to now
support for "fixed-partitions" DT compatibility string was working only
with flash drivers that were specifying "ofpart" (manually or by letting
mtd use the default set of parsers).
This matches existing bindings documentation.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Tested-by: Brian Norris <[email protected]>
Reviewed-by: Richard Weinberger <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Type "ofpart" means that OF should be used to get partitioning info and
this driver supports "fixed-partitions" binding only. Renaming it should
lead to less confusion especially when parsers for new compatibility
strings start to appear.
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Richard Weinberger <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
In order to properly support compatibility strings as described in the
bindings/mtd/partition.txt "ofpart" type should be treated as an
indication for looking into OF. MTD should check "compatible" property
and search for a matching parser rather than blindly trying the one
supporting "fixed-partitions".
It also means that existing "fixed-partitions" parser should get renamed
to use a more meaningful name.
This commit achievies that aim by introducing a new mtd_part_of_parse().
It works by looking for a matching parser for every string in the
"compatibility" property (starting with the most specific one).
Please note that driver-specified parsers still take a precedence. It's
assumed that driver providing a parser type has a good reason for that
(e.g. having platform data with device-specific info). Also doing
otherwise could break existing setups. The same applies to using default
parsers (including "cmdlinepart") as some overwrite DT data with cmdline
argument.
Partition parsers can now provide an of_match_table to enable
flash<-->parser matching via device tree as documented in the
mtd/partition.txt.
This support is currently limited to built-in parsers as it uses
request_module() and friends. This should be sufficient for most cases
though as compiling parsers as modules isn't a common choice.
Signed-off-by: Brian Norris <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Tested-by: Peter Rosin <[email protected]>
Reviewed-by: Richard Weinberger <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in discovering
support for IAPP in Broadcom's firmwares.
Older firmwares were only generating 802.11f frames. Newer ones like:
1) 10.10 (TOB) (r663589)
2) 10.10.122.20 (r683106)
for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames
in the Tx path by performing a STA disassociation.
This obsoleted standard and its implementation is something that:
1) Most people don't need / want to use
2) Can allow local DoS attacks
3) Breaks AP interfaces in some specific bridge setups
To solve issues it can cause this commit modifies brcmfmac to drop IAPP
packets. If affects:
1) Rx path: driver won't be sending these unwanted packets up.
2) Tx path: driver will reject packets that would trigger STA
disassociation perfromed by a firmware (possible local DoS attack).
It appears there are some Broadcom's clients/users who care about this
feature despite the drawbacks. They can switch it on using a new module
param.
This change results in only two more comparisons (check for module param
and check for Ethernet packet length) for 99.9% of packets. Its overhead
should be very minimal.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
This simplifies code a bit by:
1) Avoiding an extra (tiny) function
2) Checking for amount of parsed (found) partitions just once
3) Avoiding clearing/filling struct mtd_partitions manually
With this commit proper functions are called directly from the
mtd_device_parse_register(). It doesn't need to use minor tricks like
memsetting struct to 0 to trigger an expected
mtd_add_device_partitions() behavior.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This change is a small cleanup of mtd_device_parse_register(). When
using MTD_PARTITIONED_MASTER it makes sure a master MTD is registered
before dealing with partitions. The advantage of this is not mixing
code handling master MTD with code handling partitions.
This commit doesn't change any behavior except from a slightly different
failure code path. The new code may need to call del_mtd_device when
something goes wrong.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
This commit makes transfer function use spi_transfer_is_last to
determine if currently processed transfer is the last one. Thanks to
that we finally set hardware registers properly and it makes controller
behave the way it's expected to.
This allows simplifying read function which can now simply start reading
from the slot 0 instead of the last saved offset. It has been
successfully tested using spi_write_then_read.
Moreover this change fixes handling messages with two writing transfers.
It's important for SPI flash devices as their drivers commonly use one
transfer for a command and another one for data.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Using bcma_debug gives a device-specific prefix for messages and pr_cont
is a common helper for continuing a line.
Signed-off-by: Rafał Miłecki <[email protected]>
Acked-By: Hauke Mehrtens <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
There are 4 very similar PHYs:
0x600d84a1: BCM54210E (rev B0)
0x600d84a2: BCM54210E (rev B1)
0x600d84a5: B50212E (rev B0)
0x600d84a6: B50212E (rev B1)
that need setting master mode manually. It's because they run in slave
mode by default with Automatic Slave/Master configuration disabled which
can lead to unreliable connection with massive ping loss.
So far it was reported for a board with BCM47189 SoC and B50212E B1 PHY
connected to the bgmac supported ethernet device. Telling PHY driver to
setup PHY properly solves this issue.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
This info can be used by operating system to setup LED behavior.
Reported-by: Dan Haab <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This uses trigger-sources documented in commit 80dc6e1cd8 ("dt-bindings:
leds: document new trigger-sources property") to specify USB ports. Such an
information can be used by operating system to setup LEDs behavior.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
This uses trigger-sources documented in commit 80dc6e1cd8 ("dt-bindings:
leds: document new trigger-sources property") to specify USB ports. Such an
information can be used by operating system to setup LEDs behavior.
I updated dts files for 7 devices I own and I was able to test.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Northstar has 3 controllers: OHCI and EHCI (each with 2 ports) and XHCI
(with just 1 port). Describe them in the DT. In future this will allow
to reference them as trigger sources.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
So far Linux supported only two levels of MTD devices so we didn't need
a very precise description for this sysfs file. With commit
97519dc52b ("mtd: partitions: add support for subpartitions") there
is support for a tree structure so we should have more precise
description. Using "parent" and "flash device" makes it more accurate.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
This uses DT info to read relation description of LEDs and USB ports. If
DT has properly described LEDs, trigger will know when to turn them on.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Some LEDs can be related to a specific device(s) described in the DT.
This property allows specifying such relations. E.g. USB LED should
usually be used to indicate some USB port(s) state.
Please note this binding is designed to be generic and not influenced by
any operating system design. Linux developers may find "trigger" part a
bit confusing since in Linux triggers are separated drivers. It
shouldn't define the binding though (we shouldn't add an extra level of
indirection).
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This fixes following warning:
include/linux/kern_levels.h:4:18: warning: format '%X' expects argument of type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned int}' [-Wformat=]
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
This makes TRX parsing code reusable with other platforms and parsers.
Please note this patch doesn't really change anything in the existing
code, just moves it. There is still some place for improvement (e.g.
working on non-hacky method of checking rootfs format) but it's not
really a subject of this change.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Rafał Miłecki