[4.15] Fix outstanding GCC 6.4.0 and GCC 7.3.0 warnings #2417
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Re-expose some dmi APIs for use in VCSM
smsc95xx is adjusting truesize when it shouldn't, and following a recent patch from Eric this is now triggering warnings. This patch stops smsc95xx from changing truesize. Signed-off-by: Steve Glendinning <[email protected]>
Signed-off-by: popcornmix <[email protected]>
Without this patch, removing a device tree overlay can crash here. Signed-off-by: Phil Elwell <[email protected]>
The old arch-specific IRQ macros included a dsb to ensure the write to clear the mailbox interrupt completed before returning from the interrupt. The BCM2836 irqchip driver needs the same precaution to avoid spurious interrupts. Spurious interrupts are still possible for other reasons, though, so trap them early.
Initialise the level for each IRQ to avoid a warning from the arm arch timer code. Signed-off-by: Phil Elwell <[email protected]>
Add a duplicate irq range with an offset on the hwirq's so the driver can detect that enable_fiq() is used. Tested with downstream dwc_otg USB controller driver. Signed-off-by: Noralf Trønnes <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Noralf Trønnes <[email protected]>
The spi-bcm2835 driver automatically uses GPIO chip-selects due to some unreliability of the native ones. In doing so it chooses the same pins as the native chip-selects would use, but the existing code always uses pins 7 and 8, wherever the SPI function is mapped. Search the pinctrl group assigned to the driver for pins that correspond to native chip-selects, and use those for GPIO chip- selects. Signed-off-by: Phil Elwell <[email protected]>
Select software CS in bcm2708_common.dtsi, and disable the automatic conversion in the driver to allow hardware CS to be re-enabled with an overlay. See: raspberrypi#1547 Signed-off-by: Phil Elwell <[email protected]>
Load driver early since at least bcm2708_fb doesn't support deferred probing and even if it did, we don't want the video driver deferred. Support the legacy DMA API which is needed by bcm2708_fb. Don't mask out channel 2. Signed-off-by: Noralf Trønnes <[email protected]>
Without this alias, Device Tree won't cause the driver to be loaded. See: raspberrypi#1510
The Raspberry Pi firmware looks at the RSTS register to know which partition to boot from. The reboot syscall command LINUX_REBOOT_CMD_RESTART2 supports passing in a string argument. Add support for passing in a partition number 0..63 to boot from. Partition 63 is a special partiton indicating halt. If the partition doesn't exist, the firmware falls back to partition 0. Signed-off-by: Noralf Trønnes <[email protected]>
…itical clocks can get enabled early on in the boot process avoiding the risk of disabling a clock, pll_divider or pll when a claiming driver fails to install propperly - maybe it needs to defer. Signed-off-by: Martin Sperl <[email protected]>
Avoids the 0x40000 cycles of warmup again if firmware has already used it
The VPU configures and relies on several PLLs and dividers. Mark all enabled dividers and their PLLs as CRITICAL to prevent the kernel from switching them off. Signed-off-by: Phil Elwell <[email protected]>
The claim-clocks property can be used to prevent PLLs and dividers from being marked as critical. It contains a vector of clock IDs, as defined by dt-bindings/clock/bcm2835.h. Use this mechanism to claim PLLD_DSI0, PLLD_DSI1, PLLH_AUX and PLLH_PIX for the vc4_kms_v3d driver. Signed-off-by: Phil Elwell <[email protected]>
The VPU is responsible for managing the core clock, usually under direction from the bcm2835-cpufreq driver but not via the clk-bcm2835 driver. Since the core frequency can change without warning, it is safer to report the maximum clock rate to users of the core clock - I2C, SPI and the mini UART - to err on the safe side when calculating clock divisors. If the DT node for the clock driver includes a reference to the firmware node, use the firmware API to query the maximum core clock instead of reading the divider registers. Prior to this patch, a "100KHz" I2C bus was sometimes clocked at about 160KHz. In particular, switching to the 4.9 kernel was likely to break SenseHAT usage on a Pi3. Signed-off-by: Phil Elwell <[email protected]>
These divide off of PLLD_PER and are used for the ethernet and wifi PHYs source PLLs. Neither of them is currently represented by a phy device that would grab the clock for us. This keeps other drivers from killing the networking PHYs when they disable their own clocks and trigger PLLD_PER's refcount going to 0. v2: Skip marking as critical if they aren't on at boot. Signed-off-by: Eric Anholt <[email protected]>
At present there is no mechanism to specify driver load order, which can lead to deferrals and repeated retries until successful. Since this situation is expected, reduce the dmesg level to INFO and mention that the operation will be retried. Signed-off-by: Phil Elwell <[email protected]>
Christopher Alexander Tobias Schulze - May 2, 2015, 11:57 a.m. This patch fixes a problem with VFP state save and restore related to exception handling (panic with message "BUG: unsupported FP instruction in kernel mode") present on VFP11 floating point units (as used with ARM1176JZF-S CPUs, e.g. on first generation Raspberry Pi boards). This patch was developed and discussed on raspberrypi#859 A precondition to see the crashes is that floating point exception traps are enabled. In this case, the VFP11 might determine that a FPU operation needs to trap at a point in time when it is not possible to signal this to the ARM11 core any more. The VFP11 will then set the FPEXC.EX bit and store the trapped opcode in FPINST. (In some cases, a second opcode might have been accepted by the VFP11 before the exception was detected and could be reported to the ARM11 - in this case, the VFP11 also sets FPEXC.FP2V and stores the second opcode in FPINST2.) If FPEXC.EX is set, the VFP11 will "bounce" the next FPU opcode issued by the ARM11 CPU, which will be seen by the ARM11 as an undefined opcode trap. The VFP support code examines the FPEXC.EX and FPEXC.FP2V bits to decide what actions to take, i.e., whether to emulate the opcodes found in FPINST and FPINST2, and whether to retry the bounced instruction. If a user space application has left the VFP11 in this "pending trap" state, the next FPU opcode issued to the VFP11 might actually be the VSTMIA operation vfp_save_state() uses to store the FPU registers to memory (in our test cases, when building the signal stack frame). In this case, the kernel crashes as described above. This patch fixes the problem by making sure that vfp_save_state() is always entered with FPEXC.EX cleared. (The current value of FPEXC has already been saved, so this does not corrupt the context. Clearing FPEXC.EX has no effects on FPINST or FPINST2. Also note that many callers already modify FPEXC by setting FPEXC.EN before invoking vfp_save_state().) This patch also addresses a second problem related to FPEXC.EX: After returning from signal handling, the kernel reloads the VFP context from the user mode stack. However, the current code explicitly clears both FPEXC.EX and FPEXC.FP2V during reload. As VFP11 requires these bits to be preserved, this patch disables clearing them for VFP implementations belonging to architecture 1. There should be no negative side effects: the user can set both bits by executing FPU opcodes anyway, and while user code may now place arbitrary values into FPINST and FPINST2 (e.g., non-VFP ARM opcodes) the VFP support code knows which instructions can be emulated, and rejects other opcodes with "unhandled bounce" messages, so there should be no security impact from allowing reloading FPEXC.EX and FPEXC.FP2V. Signed-off-by: Christopher Alexander Tobias Schulze <[email protected]>
This adds a debug module parameter to aid in debugging transfer issues by printing info to the kernel log. When enabled, status values are collected in the interrupt routine and msg info in bcm2835_i2c_start_transfer(). This is done in a way that tries to avoid affecting timing. Having printk in the isr can mask issues. debug values (additive): 1: Print info on error 2: Print info on all transfers 3: Print messages before transfer is started The value can be changed at runtime: /sys/module/i2c_bcm2835/parameters/debug Example output, debug=3: [ 747.114448] bcm2835_i2c_xfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1] [ 747.114463] bcm2835_i2c_xfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1] [ 747.117809] start_transfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1] [ 747.117825] isr: remain=2, status=0x30000055 : TA TXW TXD TXE [i2c1] [ 747.117839] start_transfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1] [ 747.117849] isr: remain=32, status=0xd0000039 : TA RXR TXD RXD [i2c1] [ 747.117861] isr: remain=20, status=0xd0000039 : TA RXR TXD RXD [i2c1] [ 747.117870] isr: remain=8, status=0x32 : DONE TXD RXD [i2c1] Signed-off-by: Noralf Trønnes <[email protected]>
Modify the rotary-encoder overlay to support multiple instances.
SuperAudioBoard support using simple-audio-card driver.
The format change from S24_LE to S24_3LE effectively disables 24-bit mode as S24_3LE isn't supported by bcm2835-i2s. This causes issues with drivers that want to use wm8804 in 24-bit mode. Adding the S32_LE format is also incorrect, according to the datasheet only 16-24 bit formats are supported. Signed-off-by: Matthias Reichl <[email protected]>
Although downstream uses a different MMC/SDHCI driver there is no reason why can't support the upstream as a fallback. See: raspberrypi/firmware#943 Signed-off-by: Phil Elwell <[email protected]>
Add a 'bus' parameter that, if set to a unique, non-zero value, allows multiple i2c-gpio instances to coexist. The chosen value doesn't determine the /dev/i2c-* value, but starting with 1 or 2 and counting upwards seems sensible. N.B. The bus parameter has a default value of zero, so one instance doesn't need to specify a value. Signed-off-by: Phil Elwell <[email protected]>
I2C busses can be assigned specific bus numbers using aliases in Device Tree - string properties where the name is the alias and the value is the path to the node. The current DT parameter mechanism does not allow property names to be derived from a parameter value in any way, so it isn't possible to generate unique or matching aliases for nodes from an overlay that can generate multiple instances, e.g. i2c-gpio. Work around this limitation (at least temporarily) by allowing the i2c adapter number to be initialised from the "reg" property if present. Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
The SC16IS752 is a dual-channel device. The two channels are largely independent, but the IRQ signals are wired together as an open-drain, active low signal which will be driven low while either of the channels requires attention, which can be for significant periods of time until operations complete and the interrupt can be acknowledged. In that respect it is should be treated as a true level-sensitive IRQ. The kernel, however, needs to be able to exit interrupt context in order to use I2C or SPI to access the device registers (which may involve sleeping). Therefore the interrupt needs to be masked out or paused in some way. The usual way to manage sleeping from within an interrupt handler is to use a threaded interrupt handler - a regular interrupt routine does the minimum amount of work needed to triage the interrupt before waking the interrupt service thread. If the threaded IRQ is marked as IRQF_ONESHOT the kernel will automatically mask out the interrupt until the thread runs to completion. The sc16is7xx driver used to use a threaded IRQ, but a patch switched to using a kthread_worker in order to set realtime priorities on the handler thread and for other optimisations. The end result is non-threaded IRQ that schedules some work then returns IRQ_HANDLED, making the kernel think that all IRQ processing has completed. The work-around to prevent a constant stream of interrupts is to mark the interrupt as edge-sensitive rather than level-sensitive, but interpreting an active-low source as a falling-edge source requires care to prevent a total cessation of interrupts. Whereas an edge-triggering source will generate a new edge for every interrupt condition a level-triggering source will keep the signal at the interrupting level until it no longer requires attention; in other words, the host won't see another edge until all interrupt conditions are cleared. It is therefore vital that the interrupt handler does not exit with an outstanding interrupt condition, otherwise the kernel will not receive another interrupt unless some other operation causes the interrupt state on the device to be cleared. The existing sc16is7xx driver has a very simple interrupt "thread" (kthread_work job) that processes interrups on each channel in turn until there are no more. If both channels are active and the first channel starts interrupting while the handler for the second channel is running then it will not be detected and an IRQ stall ensues. This could be handled easily if there was a shared IRQ status register, or a convenient way to determine if the IRQ had been deasserted for any length of time, but both appear to be lacking. Avoid this problem (or at least make it much less likely to happen) by reducing the granularity of per-channel interrupt processing to one condition per iteration, only exiting the overall loop when both channels are no longer interrupting. Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
…aspberrypi#2391) Upstream Linux today does not support the AUX interrupt controller yet. To make sure it can use our device tree, add an overlay that reverts it to something upstream understands again. See: raspberrypi/firmware#943 Signed-off-by: Alexander Graf <[email protected]>
The commit introduce this file (22067e5) seems not to come from upstream as it is missing a real name and SOB line required there.
they are already in bcmrpi_defconfig
Add non-mainline source for rtl8192cu wireless driver as this is widely used. We are currently using https://github.com/pvaret/rtl8192cu-fixes as the upstream for this driver as it is maintained there. Signed-off-by: popcornmix <[email protected]>
Signed-off-by: Giedrius Trainavicius <[email protected]>
MMC/SD interfaces support a DT property (non-removable) that disables
the usual polling required to detect card removal for a configuration
that doesn't have hardware card presence detection. This property is
required for the on-board SDIO WiFi interface, but other uses of the
interface may want the polling to be re-enabled.
'non-removable' is a boolean DT property - true if present, false if
absent - and the overlay mechanism does not allow a property in the
base DTB to be deleted, so if the base DTB has non-removable set
(which is true for all WiFi-equipped Pis) then an overlay cannot
unset it.
Modify the SDIO overlays to work around this problem by disabling
the mmc node and adding a clone to which non-removable may
optionally be added.
N.B. The default state of poll_once is still true, and the overlay
does include a non-removable property, but setting poll_once to false
("off") will remove the property from the overlay before it is applied.
See: raspberrypi#2401
Signed-off-by: Phil Elwell <[email protected]>
Under-voltage due to inadequate power supplies is a recurring problem for new Raspberry Pi users. There are visual indications that an under-voltage situation is occuring like blinking power led and a lightning icon on the desktop (not shown when using the vc4 driver), but for new users it's not obvious that this signifies a critical situation. This patch provides a twofold improvement to the situation: Firstly it logs under-voltage events to the kernel log. This provides information also for headless installations. Secondly it provides a sysfs file to read the value. This improves on 'vcgencmd' by providing change notification. Userspace can poll on the file and be notified of changes to the value. A script can poll the file and use dbus notification to put a windows on the desktop with information about the severity with a recommendation to change the power supply. A link to more information can also be provided. Only changes to the sticky bits are reported (cleared between readings). Signed-off-by: Noralf Trønnes <[email protected]>
This overlay is presented as another example of using the simple card driver. See: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=99784&p=1279490#p1278971 Signed-off-by: Phil Elwell <[email protected]>
...at the request of the author. Signed-off-by: Phil Elwell <[email protected]>
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_rf6052.c: In function ‘PHY_RFShadowRefresh’:
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_rf6052.c:1020:37: warning: iteration 63 invokes undefined behavior [-Waggressive-loop-optimizations]
RF_Shadow[eRFPath][Offset].Value = 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_rf6052.c:1018:3: note: within this loop
for (Offset = 0; Offset <= RF6052_MAX_REG; Offset++)
^~~
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
These warnings appear with GCC 6.4.0 from toolchains.bootlin.com:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c: In function ‘aes_cipher’:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1504:5: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (j = 0; j < 8; j++)
^~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1507:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
payload_index = hdrlen + 8;
^~~~~~~~~~~~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c: In function ‘aes_decipher’:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1878:5: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (j = 0; j < 8; j++)
^~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1881:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
payload_index = hdrlen + 8;
^~~~~~~~~~~~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c:5666:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if( _rtw_memcmp(pwdinfo->rx_prov_disc_info.peerDevAddr, empty_addr, ETH_ALEN) );
^~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c:5667:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
_rtw_memcpy(pwdinfo->rx_prov_disc_info.peerDevAddr, GetAddr2Ptr(pframe), ETH_ALEN);
^~~~~~~~~~~
It appears to be due to tabs versus spaces.
Signed-off-by: Nathan Chancellor <[email protected]>
Compiler used: toolchains.bootlin.com Reference: https://github.com/diederikdehaas/rtl8812AU [@nathanchance: Cherry-picked from 6c19878 and updated message] Signed-off-by: Nathan Chancellor <[email protected]>
These warnings appear with GCC 7.3.0 from toolchains.bootlin.com:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c: In function ‘mgt_dispatcher’:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c:734:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if(check_fwstate(pmlmepriv, WIFI_AP_STATE) == _TRUE)
^
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c:739:3: note: here
case WIFI_ASSOCREQ:
^~~~
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_phycfg.c: In function ‘phy_TxPwrIdxToDbm’:
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_phycfg.c:2365:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
Offset = -8;
~~~~~~~^~~~
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_phycfg.c:2366:2: note: here
default:
^~~~~~~
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/usb/usb_halinit.c: In function ‘GetHwReg8192CU’:
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/usb/usb_halinit.c:5694:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
*((u16 *)(val)) = pHalData->BasicRateSet;
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/usb/usb_halinit.c:5695:3: note: here
case HW_VAR_TXPAUSE:
^~~~
../drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_linux.c: In function ‘set_group_key’:
../drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_linux.c:7383:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
keylen = 16;
~~~~~~~^~~~
../drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_linux.c:7384:3: note: here
default:
^~~~~~~
../drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c: In function ‘set_group_key’:
../drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:822:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
keylen = 16;
~~~~~~~^~~~
../drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:823:3: note: here
default:
^~~~~~~
None of them appear to be a real issue but it is trivial to make the
warnings go away.
Signed-off-by: Nathan Chancellor <[email protected]>
This warning appears with GCC 6.4.0 from toolchains.bootlin.com:
../sound/soc/bcm/allo-piano-dac-plus.c: In function ‘snd_allo_piano_dac_init’:
../sound/soc/bcm/allo-piano-dac-plus.c:711:30: warning: argument to ‘sizeof’ in ‘memset’ call is the same expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(glb_ptr, 0x00, sizeof(glb_ptr));
^
Suggested-by: Phil Elwell <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
This warning appears with GCC 6.4.0 from toolchains.bootlin.com:
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c: In function ‘vchiq_open’:
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1735:7: warning: unused variable ‘ret’ [-Wunused-variable]
int ret;
^~~
This variable's usage was removed by commit 88a1b8a ("staging:
vchiq_arm: Make debugfs failure non-fatal"), making it useless.
Signed-off-by: Nathan Chancellor <[email protected]>
This warning appears with GCC 7.3.0 from toolchains.bootlin.com:
../drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c: In function ‘fiq_fsm_update_hs_isoc’:
../drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c:595:61: warning: statement will never be executed [-Wswitch-unreachable]
st->hctsiz_copy.b.xfersize = nrpackets * st->hcchar_copy.b.mps;
~~~~~~~~~~~~~~~~~^~~~
Signed-off-by: Nathan Chancellor <[email protected]>
|
Rebased and merged offline - thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Same ones as #2413, with a couple of extra commits ported forward from older branches since it appears 724f9c4 overrode the fixes from 39f233b and 801674e in 8f1edbe. I will look into submitting these upstream so you don't have to worry about constantly carrying them forward.