Before creating a new devfreq device devfreq_add_device() checks
if there is already a devfreq dev associated with the requesting
device (parent). If that's the case the function rejects to create
another devfreq dev for that parent and logs an error. The error
message is very unspecific, make it a bit more explicit.
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: MyungJoo Ham <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>
Add curly braces to an 'else' branch in pwm_backlight_update_status()
to match the corresponding 'if' branch.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
pwm_backlight_probe() re-assigns pb->levels for every brightness
level. This is not needed and was likely not intended, since
neither side of the assignment changes during the loop. Assign
the field only once.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Use interpolated brightness tables (added by commit 573fe6d1c2
("backlight: pwm_bl: Linear interpolation between
brightness-levels") for veyron, instead of specifying every single
step. Some devices/panels have intervals that are smaller than
the specified 'num-interpolated-steps', the driver interprets
these intervals as a single step.
Another option would be to switch to a perceptual brightness curve
(CIE 1931), with the caveat that it would change the behavior of
the backlight. Also the concept of a minimum brightness level is
currently not supported for CIE 1931 curves.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Link: https://lore.kernel.org/r/20191003094137.v2.1.Ic9fd698810ea569c465350154da40b85d24f805b@changeid
Signed-off-by: Heiko Stuebner <[email protected]>
The DDC/CI protocol involves sending a multi-byte request to the
display via I2C, which is typically followed by a multi-byte
response. The internal I2C controller only allows single byte
reads/writes or reads of 8 sequential bytes, hence DDC/CI is not
supported when the internal I2C controller is used. The I2C
transfers complete without errors, however the data in the response
is garbage. Abort transfers to/from slave address 0x37 (DDC) with
-EOPNOTSUPP, to make it evident that the communication is failing.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002124354.v2.1.I709dfec496f5f0b44a7b61dcd4937924da8d8382@changeid
To improve code quality, let's move the code that gets pending SDIO IRQs
from process_sdio_pending_irqs() into a dedicated function.
Signed-off-by: Matthias Kaehlcke <[email protected]>
[Ulf: Converted function into static]
Tested-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
The qca_data structure is allocated with kzalloc() and hence
zero-initialized. Remove a bunch of unnecessary explicit
initializations of struct members to zero.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Check if a brightness curve specified in the device tree is linear or
not and set the corresponding property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
To determine if a curve is linear it is compared to a interpolated linear
curve between min and max brightness. The curve is considered linear if
no value deviates more than +/-5% of ${brightness_range} from their
interpolated value.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type to non-linear. This makes the scale type
available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Tested-by: Enric Balletbo i Serra <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Backlight brightness curves can have different shapes. The two main
types are linear and non-linear curves. The human eye doesn't
perceive linearly increasing/decreasing brightness as linear (see
also 88ba95bedb "backlight: pwm_bl: Compute brightness of LED
linearly to human eye"), hence many backlights use non-linear (often
logarithmic) brightness curves. The type of curve currently is opaque
to userspace, so userspace often uses more or less reliable heuristics
(like the number of brightness levels) to decide whether to treat a
backlight device as linear or non-linear.
Export the type of the brightness curve via the new sysfs attribute
'scale'. The value of the attribute can be 'linear', 'non-linear' or
'unknown'. For devices that don't provide information about the scale
of their brightness curve the value of the 'scale' attribute is 'unknown'.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Add an entry for the stable backlight sysfs ABI to the MAINTAINERS
file.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Add dynamic power coefficients for the Silver and Gold CPU cores of
the Qualcomm SDM845.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Amit Kucheria <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
The opcode of the command injected by commit 32646db8cc ("Bluetooth:
btqca: inject command complete event during fw download") uses the CPU
byte format, however it should always be little endian. In practice it
shouldn't really matter, since all we need is an opcode != 0, but still
let's do things correctly and keep sparse happy.
Fixes: 32646db8cc ("Bluetooth: btqca: inject command complete event during fw download")
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
On WCN3990 downloading the NVM sometimes fails with a "TLV response
size mismatch" error:
[ 174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
[ 174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch
It seems the controller needs a short time after downloading the
firmware before it is ready for the NVM. A delay as short as 1 ms
seems sufficient, make it 10 ms just in case. No event is received
during the delay, hence we don't just silently drop an extra event.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
This is like commit 0ca87bd5ba ("ARM: dts: rockchip: Add pin names
for rk3288-veyron-jerry") and other similar commits, but for the
veyron fievel board (and tiger, which includes the fievel .dtsi).
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Fix/improve a few things for veyron fievel/tiger:
- move 'vccsys' regulator from tiger to fievel, both boards
have it (and tiger includes the fievel .dtsi)
- move 'ext_gmac' node below regulators
- fix GPIO ids of vcc5_host1 and vcc5_host2 regulators
- remove reset configuration from 'gmac' node, this is already done
in rk3288.dtsi
- fixed style issues of some multi-line comments
- switch 'vcc18_lcdt', 'vdd10_lcd' and 'vcc33_ccd' regulators off
during suspend
- no pull-up on the Bluetooth wake-up pin, there is an external
pull-up. The signal is active low, add the 'bt_host_wake_l'
pinctrl config
- move BC 1.2 pins up in the pinctrl config to keep 'wake only' pins
separate
- add BC 1.2 pins to sleep config
Fixes: 0067692b66 ("ARM: dts: rockchip: add veyron-fievel board")
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Also known as the AOpen Chromebase Mini.
tiger and fievel are share the same board, tiger has a display and
touchscreen, fievel not. Use the fievel .dts as base and add the
extra bits.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Fievel is a Chromebox and Tiger a Chromebase with a 10" display and
touchscreen. Tiger and Fievel are based on the same board.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
veyron jaq, jerry, minnie and speedy have mostly redundant regulator
and pinctrl configurations for the panel/backlight. Consolidate these
pieces in the eDP .dtsi.
Also change the default power supply for the panel to
'panel_regulator', instead of overriding it in all the board files.
pinky is the only device that uses 'vcc33_lcd' (the prior default),
so overwrite it in this case. pinky doesn't have a complete display
configuration, to keep things as they were delete the common nodes
that didn't exist previously in pinky's board file.
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The chromebook .dtsi file contains common settings for veyron
Chromebooks with eDP displays. Some veyron devices with a display
aren't Chromebooks (e.g. 'tiger' aka 'AOpen Chromebase Mini'), move
display related bits from the chromebook .dtsi into a separate file
to avoid redundant DT settings.
The new file is included from the chromebook .dtsi and can be
included by non-Chromebook devices with a display.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The downstream Chrome OS 3.14 kernel for jerry limits WiFi TX power
through calibration data in the device tree [1]. Add a DT node for
the WiFi chip and use the downstream calibration data.
Not all calibration data entries have the length specified in the
binding (Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt),
however this is the data used by the downstream ('official') kernel
and the binding mentions that "the length can vary between hw
versions".
[1] https://crrev.com/c/271237
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Firmware download to the WCN3990 often fails with a 'TLV response size
mismatch' error:
[ 133.064659] Bluetooth: hci0: setting up wcn3990
[ 133.489150] Bluetooth: hci0: QCA controller version 0x02140201
[ 133.495245] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
[ 133.507214] Bluetooth: hci0: QCA TLV response size mismatch
[ 133.513265] Bluetooth: hci0: QCA Failed to download patch (-84)
This is caused by a vendor event that corresponds to an earlier command
to change the baudrate. The event is not processed in the context of the
baudrate change and is later interpreted as response to the firmware
download command (which is also a vendor command), but the driver detects
that the event doesn't have the expected amount of associated data.
More details:
For the WCN3990 the vendor command for a baudrate change isn't sent as
synchronous HCI command, because the controller sends the corresponding
vendor event with the new baudrate. The event is received and decoded
after the baudrate change of the host port.
Identify the 'unused' event when it is received and don't add it to
the queue of RX frames.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
With commit 88ba95bedb ("backlight: pwm_bl: Compute brightness of
LED linearly to human eye") the number of set bits (aka hweight())
in the PWM period is used in the heuristic to determine the number
of brightness levels, when the brightness table isn't specified in
the DT. The number of set bits doesn't provide a reliable clue about
the length of the period, instead change the heuristic to:
nlevels = period / fls(period)
Also limit the maximum number of brightness levels to 4096 to avoid
excessively large tables.
With this the number of levels increases monotonically with the PWM
period, until the maximum of 4096 levels is reached:
period (ns) # levels
100 16
500 62
1000 111
5000 416
10000 769
50000 3333
100000 4096
Fixes: 88ba95bedb ("backlight: pwm_bl: Compute brightness of LED linearly to human eye")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Tested-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
This reverts commit 288ceb85b5.
The commit assumes that the minnie panel is a AUO B101EAN01.1 (LVDS
interface), however it is a AUO B101EAN01.8 (eDP interface). The eDP
panel doesn't need the 200 ms delay.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
empty_child_inc/dec() use the ternary operator for conditional
operations. The conditions involve the post/pre in/decrement
operator and the operation is only performed when the condition
is *not* true. This is hard to parse for humans, use a regular
'if' construct instead and perform the in/decrement separately.
This also fixes two warnings that are emitted about the value
of the ternary expression being unused, when building the kernel
with clang + "kbuild: Remove unnecessary -Wno-unused-value"
(https://lore.kernel.org/patchwork/patch/1089869/):
CC net/ipv4/fib_trie.o
net/ipv4/fib_trie.c:351:2: error: expression result unused [-Werror,-Wunused-value]
++tn_info(n)->empty_children ? : ++tn_info(n)->full_children;
Fixes: 95f60ea3e9 ("fib_trie: Add collapse() and should_collapse() to resize")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Acked-by: Alexander Duyck <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
With a single device DT overrides can become messy, especially when
keys are added or removed. Multiple devices also allow to
enable/disable wakeup per key/group.
Signed-off-by: Matthias Kaehlcke <[email protected]>
[used actual switch+event constants in new lid-switch entry]
Signed-off-by: Heiko Stuebner <[email protected]>
mickey crams a lot of hardware into a tiny package, which requires
more aggressive thermal throttling than for devices with a larger
footprint. Configure the GPU thermal zone to throttle the GPU
progressively at temperatures >= 60°C. Heat dissipated by the
CPUs also affects the GPU temperature, hence we cap the CPU
frequency to 1.4 GHz for temperatures above 65°C. Further throttling
of the CPUs may be performed by the CPU thermal zone.
The configuration matches that of the downstream Chrome OS 3.14
kernel, the 'official' kernel for mickey.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU
frequency on veyron mickey to 400 MHz for CPU temperatures >= 65°C
and to 300 MHz for CPU temperatures >= 85°C.
This matches the configuration of the downstream Chrome OS 3.14 kernel,
the 'official' kernel for mickey.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The NPLL is the only safe way to generate 500 MHz for the GPU. The
downstream Chrome OS 3.14 kernel ('official' kernel for veyron
devices) re-purposes NPLL to HDMI and hence disables the OPP for
the GPU (see https://crrev.com/c/1574579). Disable it here as well
to keep in sync and avoid problems in case someone decides to
re-purpose NPLL.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
[moved from veyron to general rk3288, as tying up the NPLL for a
not-that-helpful opp (not really fast but will still generate
quite a bit of heat) doesn't make so much sense when it will
keep us from supporting other display modes in the future]
Signed-off-by: Heiko Stuebner <[email protected]>
Currently the CPUs are used as cooling devices of the rk3288 GPU
thermal zone. The CPUs are also configured as cooling devices in the
CPU thermal zone, which indirectly helps with cooling the GPU thermal
zone, since the CPU and GPU temperatures are correlated on the rk3288.
Configure the ARM Mali Midgard GPU as cooling device for the GPU
thermal zone instead of the CPUs.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The Mali GPU of the rk3288 can be used as cooling device, add
a #cooling-cells entry for it.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Raise the temperature of the GPU thermal trip point for speedy
to 80°C. This is the value used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for speedy.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The values match those used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for veyron devices. Keep the critical
trip point for speedy at 90°C as in the downstream configuration.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
This value matches what is used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for veyron devices. Keep the temperature
for 'speedy' at 90°C, as in the downstream kernel.
Increase the temperature for a hardware shutdown to 125°C, which
matches the downstream configuration and gives the system a chance
to shut down orderly at the criticial trip point.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The CPU load values passed to the thermal_power_cpu_get_power
tracepoint are zero for all CPUs, unless, unless the
thermal_power_cpu_limit tracepoint is enabled too:
irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
vs
irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
cpus=0000000f freq=408000 cdev_state=10 power=416
There seems to be no good reason for omitting the CPU load information
depending on another tracepoint. My guess is that the intention was to
check whether thermal_power_cpu_get_power is (still) enabled, however
'load_cpu != NULL' already indicates that it was at least enabled when
cpufreq_get_requested_power() was entered, there seems little gain
from omitting the assignment if the tracepoint was just disabled, so
just remove the check.
Fixes: 6828a4711f ("thermal: add trace events to the power allocator governor")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Daniel Lezcano <[email protected]>
Acked-by: Javi Merino <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Eduardo Valentin <[email protected]>
Rename STATE_IN_BAND_SLEEP_ENABLED to QCA_IBS_ENABLED. The constant
represents a flag (multiple flags can be set at once), not a unique
state of the controller or driver.
Also make the flag an enum value instead of a pre-processor constant
(more flags will be added to the enum group by another patch).
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Add 'xo_board' as ref clock for the DSI PHY, it was previously
hardcoded in the PLL 'driver' for the 28nm 8960 PHY.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
qca_set_baudrate() calls serdev_device_wait_until_sent() assuming that
the HCI is always associated with a serdev device. This isn't true for
ROME controllers instantiated through ldisc, where the call causes a
crash due to a NULL pointer dereferentiation. Only call the function
when we have a serdev device. The timeout for ROME devices at the end
of qca_set_baudrate() is long enough to be reasonably sure that the
command was sent.
Fixes: fa9ad876b8 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
Reported-by: Balakrishna Godavarthi <[email protected]>
Reported-by: Rocky Liao <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Rocky Liao <[email protected]>
Tested-by: Rocky Liao <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Specify the relative CPU capacity of all SDM845 AP cores.
The values were provided by Qualcomm engineers.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Rajendra Nayak <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
The 8 CPU cores of the SDM845 are organized in two clusters of 4 big
("gold") and 4 little ("silver") cores. Add a cpu-map node to the DT
that describes this topology.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
Add 'bi_tcxo' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 10nm PHY.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
Add 'xo_board' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 28nm PHY.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
The temperature information from the temp-alarm block itself is very
coarse ("temperature is above/below trip points"). Provide the driver
with the die temperature channel of the ADC on the PMIC for more precise
readings.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
Many functions obtain a 'struct qca_serdev' only to read the btsoc_type
field. Add a helper function that encapsulates this.
This also fixes crashes observed on platforms with ROME controllers
that are instantiated through ldisc and not as serdev clients. The
crashes are caused by NULL pointer dereferentiations, which stem from
the driver's assumption that a QCA HCI device is always associated with
a serdev device.
Fixes: fa9ad876b8 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
Reported-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
The value was determined with the following method:
- take CPUs 1-3 offline
- for each OPP
- set cpufreq min and max freq to OPP freq
- start dhrystone benchmark
- measure CPU power consumption during 10s
- calculate Cx for OPPx
- Cx = (Px - P1) / (Vx²fx - V1²f1) [1]
using the following units: mW / Ghz / V [2]
- C = avg(C2, ..., Cn)
[1] see commit 4daa001a17 ("arm64: dts: juno: Add cpu
dynamic-power-coefficient information")
[2] https://patchwork.kernel.org/patch/10493615/#22158551
FTR, these are the values for the different OPPs:
freq (kHz) mV Px (mW) Cx
126000 900 39
216000 900 66 370
312000 900 95 372
408000 900 122 363
600000 900 177 359
696000 950 230 363
816000 1000 297 361
1008000 1050 404 362
1200000 1100 528 362
1416000 1200 770 377
1512000 1300 984 385
1608000 1350 1156 394
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The USB PHY clock can be configured as (grand) parent of uart0_sclk and
sclk_gpu. It has been observed that UART0 doesn't work reliably in high
speed mode with the PHY clock as input when certain USB devices are
plugged to the USB HOST1 port (see https://crrev.com/c/320543).
Prefix the name of the PHY clock with a '.' in the non-USB muxes to
effectively remove the clock as input from these muxes.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the
Bluetooth/WiFi module. On devices with a Broadcom module the signal
needs to be asserted to use Bluetooth.
Note that BT_ENABLE_L is a misnomer in the schematics, the signal
actually is active-high.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Some veyron devices have a Bluetooth controller connected on UART0.
The UART needs to operate at a high speed, however setting the clock
rate at initialization has no practical effect. During initialization
user space adjusts the UART baudrate multiple times, which ends up
changing the SCLK rate. After a successful initiatalization the clk
is running at the desired speed (48MHz).
Remove the unnecessary clock rate configuration from the DT.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
The arm64 config selects MULTI_IRQ_HANDLER, which was renamed to
GENERIC_IRQ_MULTI_HANDLER by commit 4c301f9b6a ("ARM: Convert
to GENERIC_IRQ_MULTI_HANDLER"). The 'new' option is already
selected, so just remove the obsolete entry.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
The clang option -Oz enables *aggressive* optimization for size,
which doesn't necessarily result in smaller images, but can have
negative impact on performance. Switch back to the less aggressive
-Os.
This reverts commit 6748cb3c29.
Suggested-by: Peter Zijlstra <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
The current 300ms delay after a baudrate change is extremely long.
For WCN3990 it is sufficient to wait 10ms after the baudrate change
request has been sent over the wire.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
During initialization the power-on pulse is currently sent inmediately
after the prior power-off pulse. With this initialization often fails
at boot time:
[ 15.205224] Bluetooth: hci0: setting up wcn3990
[ 17.341062] Bluetooth: hci0: command 0xfc00 tx timeout
[ 22.101453] ERROR: Bluetooth initialization failed
[ 25.337740] Bluetooth: hci0: Reading QCA version information failed (-110)
After a power-off pulse wait 10ms to give the controller time to power
off. Remove the previous short settling delay, it isn't needed anymore.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
After sending a power on pulse the driver has a delay of 100ms
to allow the host controller to boot. Move the delay into
qca_send_power_pulse(), since it is directly related with the
power-on pulse.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
There are only two types of power pulses 'on' or 'off', pass a boolean
instead of the power pulse 'command'.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
the public Bluetooth address from the firmware node property
'local-bd-address'. If quirk is set and the property does not exist
or is invalid the controller is marked as unconfigured.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Balakrishna Godavarthi <[email protected]>
Tested-by: Balakrishna Godavarthi <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
When a CPU is unplugged the kernel threads of this CPU are parked (see
smpboot_park_threads()). kthread_park() is used to mark each thread as
parked and wake it up, so it can complete the process of parking itselfs
(see smpboot_thread_fn()).
If local softirqs are pending on interrupt exit invoke_softirq() is called
to process the softirqs, however it skips processing when the softirq
kernel thread of the local CPU is scheduled to run. The softirq kthread is
one of the threads that is parked when a CPU is unplugged. Parking the
kthread wakes it up, however only to complete the parking process, not to
process the pending softirqs. Hence processing of softirqs at the end of an
interrupt is skipped, but not done elsewhere, which can result in warnings
about pending softirqs when a CPU is unplugged:
/sys/devices/system/cpu # echo 0 > cpu4/online
[ ... ] NOHZ: local_softirq_pending 02
[ ... ] NOHZ: local_softirq_pending 202
[ ... ] CPU4: shutdown
[ ... ] psci: CPU4 killed.
Don't skip processing of softirqs at the end of an interrupt when the
softirq thread of the CPU is parking.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: "Paul E . McKenney" <[email protected]>
Cc: Sebastian Andrzej Siewior <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Stephen Boyd <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
kthread_should_park() is used to check if the calling kthread ('current')
should park, but there is no function to check whether an arbitrary kthread
should be parked. The latter is required to plug a CPU hotplug race vs. a
parking ksoftirqd thread.
The new __kthread_should_park() receives a task_struct as parameter to
check if the corresponding kernel thread should be parked.
Call __kthread_should_park() from kthread_should_park() to avoid code
duplication.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: "Paul E . McKenney" <[email protected]>
Cc: Sebastian Andrzej Siewior <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Stephen Boyd <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Try and register an Energy Model from qcom-cpufreq-hw to allow
interested sub-systems like the task scheduler to use the provided
information.
Signed-off-by: Matthias Kaehlcke <[email protected]>
[ Viresh: Rebased over cpufreq related changes ]
Signed-off-by: Viresh Kumar <[email protected]>
Try and register an Energy Model from mediatek-cpufreq to allow
interested subsystems like the task scheduler to use the provided
information.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
With commit e163376220 ("Bluetooth: Handle bt_accept_enqueue() socket
atomically") lock_sock[_nested]() is used to acquire the socket lock
before manipulating the socket. lock_sock[_nested]() may block, which
is problematic since bt_accept_enqueue() can be called in bottom half
context (e.g. from rfcomm_connect_ind()):
[<ffffff80080d81ec>] __might_sleep+0x4c/0x80
[<ffffff800876c7b0>] lock_sock_nested+0x24/0x58
[<ffffff8000d7c27c>] bt_accept_enqueue+0x48/0xd4 [bluetooth]
[<ffffff8000e67d8c>] rfcomm_connect_ind+0x190/0x218 [rfcomm]
Add a parameter to bt_accept_enqueue() to indicate whether the
function is called from BH context, and acquire the socket lock
with bh_lock_sock_nested() if that's the case.
Also adapt all callers of bt_accept_enqueue() to pass the new
parameter:
- l2cap_sock_new_connection_cb()
- uses lock_sock() to lock the parent socket => process context
- rfcomm_connect_ind()
- acquires the parent socket lock with bh_lock_sock() => BH
context
- __sco_chan_add()
- called from sco_chan_add(), which is called from sco_connect().
parent is NULL, hence bt_accept_enqueue() isn't called in this
code path and we can ignore it
- also called from sco_conn_ready(). uses bh_lock_sock() to acquire
the parent lock => BH context
Fixes: e163376220 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: [email protected]
The geni set/get_mctrl() functions currently do nothing unless
hardware flow control is enabled. Remove this arbitrary limitation.
Suggested-by: Johan Hovold <[email protected]>
Fixes: 8a8a66a1a1 ("tty: serial: qcom_geni_serial: Add support for flow control")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Before commit a1fee899e5 ("tty: serial: qcom_geni_serial: Fix
softlock") the size of TX transfers was limited to the TX FIFO size,
and wrap arounds of the UART circular buffer were split into two
transfers. With the commit wrap around are allowed within a transfer.
The TX FIFO of the geni serial port uses a word size of 4 bytes. In
case of a circular buffer wrap within a transfer the driver currently
may write an incomplete word to the FIFO, with some bytes containing
data from the circular buffer and others being zero. Since the
transfer isn't completed yet the zero bytes are sent as if they were
actual data.
Handle wrap arounds of the TX buffer properly and ensure that words
written to the TX FIFO always contain valid data (unless the transfer
is completed).
Fixes: a1fee899e5 ("tty: serial: qcom_geni_serial: Fix softlock")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Evan Green <[email protected]>
Tested-by: Ryan Case <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This adds nodes for all possible UARTs to sdm845.dtsi. By default
only configure the RX/TX lines with pinctrl. Boards that use UARTs
with flow control can overwrite the configuration in the
<board>.dtsi.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
sysrq_handle_crash() currently forces a crash by dereferencing a
NULL pointer, which is undefined behavior in C. Just call panic()
instead, which is simpler and doesn't depend on compiler specific
handling of the undefined behavior.
Remove the comment on why the RCU lock needs to be released, it isn't
accurate anymore since the crash now isn't handled by the page fault
handler (for reference: the comment was added by commit 984cf355ae
("sysrq: Fix warning in sysrq generated crash.")). Releasing the lock
is still good practice though.
Suggested-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The node has a reg property, therefore its name should include a unit
address. Also change the name from 'usb_id_nopull' to 'adc-chan', which
is the preferred name for ADC channel nodes.
Include headers for constants used in the example.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
Currently update_devfreq() is only visible to devfreq governors outside
of devfreq.c. Make it public to allow drivers that adjust devfreq policies
to cause a re-evaluation of the frequency after a policy change.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: MyungJoo Ham <[email protected]>
Several governors use the user space limits df->min/max_freq to adjust
the target frequency. This is not necessary, since update_devfreq()
already takes care of this. Instead the governor can request the available
min/max frequency by setting the target frequency to DEVFREQ_MIN/MAX_FREQ
and let update_devfreq() take care of any adjustments.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: MyungJoo Ham <[email protected]>
Commit ab8f58ad72 ("PM / devfreq: Set min/max_freq when adding the
devfreq device") initializes df->min/max_freq with the min/max OPP when
the device is added. Later commit f1d981eaec ("PM / devfreq: Use the
available min/max frequency") adds df->scaling_min/max_freq and the
following to the frequency adjustment code:
max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
With the current handling of min/max_freq this is incorrect:
Even though df->max_freq is now initialized to a value != 0 user space
can still set it to 0, in this case max_freq would be 0 instead of
df->scaling_max_freq as intended. In consequence the frequency adjustment
is not performed:
if (max_freq && freq > max_freq) {
freq = max_freq;
To fix this set df->min/max freq to the min/max OPP in max/max_freq_store,
when the user passes a value of 0. This also prevents df->max_freq from
being set below the min OPP when df->min_freq is 0, and similar for
min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the
checks for this case can be removed.
Fixes: f1d981eaec ("PM / devfreq: Use the available min/max frequency")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: MyungJoo Ham <[email protected]>
The symbols 'dummy_dma_ops' is declared with different data types by
sound/soc/soc-utils.c and arch/arm64/include/asm/dma-mapping.h. This
leads to conflicts when soc-utils.c (indirectly) includes dma-mapping.h:
sound/soc/soc-utils.c:282:33: error: conflicting types for 'dummy_dma_ops'
static const struct snd_pcm_ops dummy_dma_ops = {
^
...
arch/arm64/include/asm/dma-mapping.h:27:33: note: previous declaration of 'dummy_dma_ops' was here
extern const struct dma_map_ops dummy_dma_ops;
^
Rename the symbol in soc-utils.c to 'snd_dummy_dma_ops' to avoid the
conflict.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
The thermal zone uses spmi-temp-alarm as sensor, the trip points
correspond to the PMIC thermal stages 1 and 2. The critical trip
point at 125°C disables the partial PMIC shutdown at stage 2.
Without an IIO input the sensor only reports a limited number of
temperatures:
- 37°C for temperatures below 105°C
- 107°C for temperatures >= 105°C and < 125°C
- 127°C for temperatures >= 125°C
(the numbers correspond to a stage 1 threshold of 105°C)
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
This adds the spmi-temp-alarm node to pm8998 based on the examples in the
bindings.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
The documentation claims that the 'reg' property consists of two values,
the SPMI address and the length of the controller's registers. However
the SPMI bus to which it is added specifies "#size-cells = <0>;". Remove
the controller register length from the documentation of the field and the
example.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
This adds the display clock controller node to sdm845 based on the
examples in the bindings.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
This adds the adc node to pm8998 based on the examples in the
bindings. It also fixes the order of the included headers.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
'reg' property consists of two values, the SPMI address and the length
of the controller's registers. However the SPMI bus to which it is added
specifies "#size-cells = <0>;". Remove the controller register length
from the documentation of the field and the example.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Andy Gross <[email protected]>
The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
'reg' property consists of two values, the SPMI address and the length
of the controller's registers. However the SPMI bus to which it is added
specifies "#size-cells = <0>;". Remove the controller register length
from the documentation of the field and the example.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
The driver only defines a subset of all possible ADC channels. Channel
numbers read from the device tree are accepted as long as they don't
exceed a max value, even when no channel definition exists. Add a
check to abort initialization in this case.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
There are three thermal stages defined in the PMIC:
stage 1: warning
stage 2: system should shut down
stage 3: emergency shut down
By default the PMIC assumes that the OS isn't doing anything and thus
at stage 2 it does a partial PMIC shutdown and at stage 3 it kills
all power. When switching between thermal stages the PMIC generates an
interrupt which is handled by the driver. The partial PMIC shutdown at
stage 2 can be disabled by software, which allows the OS to initiate a
shutdown at stage 2 with a thermal zone configured accordingly.
If a critical trip point is configured in the thermal zone the driver
adjusts the stage 1-3 temperature thresholds to (closely) match the
critical temperature with a stage 2 threshold (125/130/135/140 °C).
If a suitable match is found the partial shutdown at stage 2 is
disabled. If for some reason the system doesn't shutdown at stage 2
the emergency shutdown at stage 3 kicks in.
The partial shutdown at stage 2 remains enabled in these cases:
- no critical trip point defined
- the temperature of the critical trip point is < 125°C
- the temperature of the critical trip point is > 140°C and no
ADC channel is configured (thus the OS is not notified when the critical
temperature is reached)
Suggested-by: Douglas Anderson <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Eduardo Valentin <[email protected]>
The current example for a thermal zone isn't very useful as reference
since it would result in a hardware shutdown at 145°C, instead of
allowing the system to try to shutdown gracefully. Without an ADC
channel a maximum of two trip points is useful in practice for this
sensor, with temperatures corresponding to the stage 1 and stage 2
'hardware trip points'. A critical trip point at stage 2 may allow the
system to shutdown before a hardware shutdown at stage 3 kicks in. It
should be noted though that by default the chip performs a 'partial
shutdown' when the temperature reaches stage 2, which may prevent an
orderly shutdown. The 'partial shutdown' can be disabled by software.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Eduardo Valentin <[email protected]>
The documentation claims that the 'reg' property consists of two values,
the SPMI address and the length of the controller's registers. However
the SPMI bus to which it is added specifies "#size-cells = <0>;". Remove
the controller register length from the documentation of the field and the
example.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Eduardo Valentin <[email protected]>
Add ADC5_AMUX_THM2_100K_PU and ADC5_AMUX_THM4_100K_PU to the list of
rev2 ADC channels.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
The driver expects to find the device id in rt5677_of_match.data, however
it is currently assigned to rt5677_of_match.type. Fix this.
The problem was found with the help of clang:
sound/soc/codecs/rt5677.c:5010:36: warning: expression which evaluates to
zero treated as a null pointer constant of type 'const void *'
[-Wnon-literal-null-conversion]
{ .compatible = "realtek,rt5677", RT5677 },
^~~~~~
Fixes: ddc9e69b9d ("ASoC: rt5677: Hide platform data in the module sources")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Commit ab8f58ad72 ("PM / devfreq: Set min/max_freq when adding
the devfreq device") introduced the initialization of the user
limits min/max_freq from the lowest/highest available OPPs. Later
commit f1d981eaec ("PM / devfreq: Use the available min/max
frequency") added scaling_min/max_freq, which actually represent
the frequencies of the lowest/highest available OPP. scaling_min/
max_freq are initialized with the values from min/max_freq, which
is totally correct in the context, but a bit awkward to read.
Swap the initialization and assign scaling_min/max_freq with the
OPP freqs and then the user limts min/max_freq with scaling_min/
max_freq.
Needless to say that this change is a NOP, intended to improve
readability.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Signed-off-by: MyungJoo Ham <[email protected]>
Commit 39bf4de89f ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enabled some additional clang-only warnings, as a
result building i915 with clang currently is extremely noisy. For now
also disable the clang warnings sign-compare, sometimes-uninitialized,
unneeded-internal-declaration and initializer-overrides. If desired
they can be re-enabled after the code has been fixed.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The type 'enum kvm_reg_ex' is an extension of 'enum kvm_reg', however
the extension is only semantical and the compiler doesn't know about the
relationship between the two types. In kvm_pdptr_read() a value of the
extended type is passed to kvm_x86_ops->cache_reg(), which expects a
value of the base type. Clang raises the following warning about the
type mismatch:
arch/x86/kvm/kvm_cache_regs.h:44:32: warning: implicit conversion from
enumeration type 'enum kvm_reg_ex' to different enumeration type
'enum kvm_reg' [-Wenum-conversion]
kvm_x86_ops->cache_reg(vcpu, VCPU_EXREG_PDPTR);
Cast VCPU_EXREG_PDPTR to 'enum kvm_reg' to make the compiler happy.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
The util mkregtable includes a copy of the kernel API for linked lists,
only a small subset of it is used. Delete the unused functions and macros.
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
is assigned to itself in an if ... else statement, apparently only to
document that the branch condition is handled and that a previously read
value should be returned unmodified. The self-assignment causes clang to
raise the following warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
error: explicitly assigning value of variable of type 'u32'
(aka 'unsigned int') to itself [-Werror,-Wself-assign]
writeVal = writeVal;
Delete the branch with the self-assignment.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Larry Finger <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.
Reported-by: Guenter Roeck <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Matthias Kaehlcke