Avoid duplicating code by moving the calls to spi_nor_write_enable() and
spi_nor_wait_till_ready() inside the Write Status Register methods.
Move spi_nor_write_sr() to avoid forward declaration of
spi_nor_wait_till_ready().
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
spi_nor_clear_sr() and spi_nor_clear_fsr() are called just in case
of errors. The callers didn't check their return value, make them
of type void.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Rename 'sst_write_err' label to 'out' as it is no longer generic for
all the errors in the sst_write() method, and may introduce confusion.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
What most users care about is "my dev is not working properly".
All low level information should be discovered when activating
the debug traces.
Keep error messages just for the following cases:
- when the SR/FSR report program or erase fails, or attempts of
modifying a protected sector,
- when the JEDEC ID is not recognized,
- when the resume() call fails,
- when the spi_nor_check() fails.
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
The newly introduced Energy Model framework manages power cost tables in
a generic way. Moreover, it supports several types of models since the
tables can come from DT or firmware (through SCMI) for example. On the
other hand, the cpu_cooling subsystem manages its own power cost tables
using only DT data.
In order to avoid the duplication of data in the kernel, and in order to
enable IPA with EMs coming from more than just DT, remove the private
tables from cpu_cooling.c and migrate it to using the centralized EM
framework. Doing so should have no visible functional impact for
existing users of IPA since:
- recent extenstions to the the PM_OPP infrastructure enable the
registration of EMs in PM_EM using the DT property used by IPA;
- the existing upstream cpufreq drivers marked with the
'CPUFREQ_IS_COOLING_DEV' flag all use the aforementioned PM_OPP
infrastructure, which means they all support PM_EM. The only two
exceptions are qoriq-cpufreq which doesn't in fact use an EM and
scmi-cpufreq which doesn't use DT for power costs.
For existing users of cpu_cooling, PM_EM tables will contain the exact
same power values that IPA used to compute on its own until now. The
only new dependency for them is to compile in CONFIG_ENERGY_MODEL.
The case where the thermal subsystem is used without an Energy Model
(cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
frequency table which is already a dependency for cpu_cooling.c anyway.
Since the thermal framework expects the cooling states in a particular
order, bail out whenever the CPUFreq table is unsorted, since that is
fairly uncommon in general, and there are currently no users of
cpu_cooling for this use-case.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191030151451.7961-5-qperret@google.com
The structs representing capacity states and performance domains of an
Energy Model are currently only defined for CONFIG_ENERGY_MODEL=y. That
makes it hard for code outside PM_EM to manipulate those structures
without a lot of ifdefery or stubbed accessors.
So, move the declaration of the two structs outside of the
CONFIG_ENERGY_MODEL ifdef. The client code (e.g. EAS or thermal) always
checks the return of em_cpu_get() before using it, so the exising code
is still safe to use as-is.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191030151451.7961-3-qperret@google.com
The recently introduced Energy Model (EM) framework manages power cost
tables for the CPUs of the system. Its only user right now is the
scheduler, in the context of Energy Aware Scheduling (EAS).
However, the EM framework also offers a generic infrastructure that
could replace subsystem-specific implementations of the same concepts,
as this is the case in the thermal framework.
So, in order to prepare the migration of the thermal subsystem to use
the EM framework, enable it in the default arm64 defconfig, which is the
most commonly used architecture for IPA. This will also compile-in all
of the EAS code, although it won't be enabled by default -- EAS requires
to use the 'schedutil' CPUFreq governor while arm64 defaults to
'performance'.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191030151451.7961-2-qperret@google.com
Currently a multiply operation is being performed on two int values
and the result is being assigned to a u64, presumably because the
end result is expected to be probably larger than an int. However,
because the multiply is an int multiply one can get overflow. Avoid
the overflow by casting degc to a u64 to force a u64 multiply.
Also use div_u64 for the divide as suggested by Daniel Lezcano.
Addresses-Coverity: ("Unintentional integer overflow")
Fixes: fbfe1a042cfd ("drivers: thermal: tsens: Add interrupt support")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Link: https://lore.kernel.org/r/20191101100035.25502-1-colin.king@canonical.com
Amlogic G12A and G12B SoCs integrate two thermal sensors
with the same design. One is located close to the DDR controller
and the other one is located close to the PLLs (between the CPU and GPU).
The calibration data for each of the thermal sensors instance is stored
in a different location within the AO region.
Implement reading the temperature from each thermal sensor.
The IP block has more functionality, which may be added to this driver
in the future:
- chip reset when the temperature exceeds a configurable threshold
- up to four interrupts when the temperature has risen above a
configurable threshold
- up to four interrupts when the temperature has fallen below a
configurable threshold
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191004090114.30694-3-glaroque@baylibre.com
Depending on the IP version, TSENS supports upper, lower and critical
threshold interrupts. We only add support for upper and lower threshold
interrupts for now.
TSENSv2 has an irq [status|clear|mask] bit tuple for each sensor while
earlier versions only have a single bit per sensor to denote status and
clear. These differences are handled transparently by the interrupt
handler. At each interrupt, we reprogram the new upper and lower threshold
in the .set_trip callback.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/7508ba143f144407e5dd546107ddae65c380a76f.1572526427.git.amit.kucheria@linaro.org
There are two fields - id and hw_id - to track what sensor an action was
to performed on. This was because the sensors connected to a TSENS IP
might not be contiguous i.e. 1, 2, 4, 5 with 3 being skipped.
This causes confusion in the code which uses hw_id sometimes and id
other times (tsens_get_temp, tsens_get_trend).
Switch to only using the hw_id field to track the physical ID of the
sensor. When we iterate through all the sensors connected to an IP
block, we use an index i to loop through the list of sensors, and then
return the actual hw_id that is registered on that index.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/30206cd47d303d2dcaef87f4e3c7173481a0bddd.1572526427.git.amit.kucheria@linaro.org
I forgot to change last_packets field in struct net_rate_estimator.
Without this fix, rate estimators would misbehave after more
than 2^32 packets have been sent.
Another solution would be to be careful and only use the
32 least significant bits of packets counters, but we have
a hole in net_rate_estimator structure and this looks
easier to read/maintain.
Fixes: d0083d98f6 ("net_sched: extend packet counter to 64bit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
phylink_set_port_modes will be compiled if CONFIG_PHYLINK enabled,
dpaa2_mac_validate will be compiled if CONFIG_FSL_DPAA2_ETH enabled,
it should select CONFIG_PHYLINK when dpaa2_mac_validate call
phylink_set_port_modes
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.o: In function `dpaa2_mac_validate':
dpaa2-mac.c:(.text+0x3a1): undefined reference to `phylink_set_port_modes'
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.o: In function `dpaa2_mac_connect':
dpaa2-mac.c:(.text+0x91a): undefined reference to `phylink_create'
dpaa2-mac.c:(.text+0x94e): undefined reference to `phylink_of_phy_connect'
dpaa2-mac.c:(.text+0x97f): undefined reference to `phylink_destroy'
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.o: In function `dpaa2_mac_disconnect':
dpaa2-mac.c:(.text+0xa9f): undefined reference to `phylink_disconnect_phy'
dpaa2-mac.c:(.text+0xab0): undefined reference to `phylink_destroy'
make: *** [vmlinux] Error 1
Fixes: 7194792308 ("dpaa2-eth: add MAC/PHY support through phylink")
Signed-off-by: Chenwandun <chenwandun@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The variable nfcid_skb is not changed in the callee nfc_hci_get_param()
if error occurs. Consequently, the freed variable nfcid_skb will be
freed again, resulting in a double free bug. Set nfcid_skb to NULL after
releasing it to fix the bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since old firmware does not support HCLGE_OPC_PF_RST_DONE, it will
return -EOPNOTSUPP to the driver when received this command. So
for this case, it should just print a warning and return success
to the caller.
Fixes: 72e2fb0799 ("net: hns3: clear reset interrupt status in hclge_irq_handle()")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Kirsher says:
====================
100GbE Intel Wired LAN Driver Updates 2019-11-06
This series contains updates to ice driver only.
Scott adds ethtool -m support so that we can read eeprom data on SFP/OSFP
modules.
Anirudh updates the return value to properly reflect when SRIOV is not
supported.
Md Fahad updates the driver to handle a change in the NVM, where the
boot configuration section was moved to the Preserved Field Area (PFA)
of the NVM.
Paul resolves an issue when DCBx requests non-contiguous TCs, transmit
hangs could occur, so configure a default traffic class (TC0) in these
cases to prevent traffic hangs. Adds a print statement to notify the
user when unsupported modules are inserted.
Bruce fixes up the driver unload code flow to ensure we do not clear the
interrupt scheme until the reset is complete, otherwise a hardware error
may occur.
Dave updates the DCB initialization to set is_sw_lldp boolean when the
firmware has been detected to be in an untenable state. This will
ensure that the firmware is in a known state.
Michal saves off the PCI state and I/O BARs address after PCI bus reset
so that after the reset, device registers can be read. Also adds a NULL
pointer check to prevent a potential kernel panic.
Mitch resolves an issue where VF's on PF's other than 0 were not seeing
resets by using the per-PF VF ID instead of the absolute VF ID.
Krzysztof does some code cleanup to remove a unneeded wrapper and
reduces the code complexity.
Brett reduces confusion by changing the name of ice_vc_dis_vf() to
ice_vc_reset_vf() to better describe what the function is actually
doing.
v2: dropped patch 3 "ice: Add support for FW recovery mode detection"
from the origin al series, while Ani makes changes based on
community feedback to implement devlink into the changes.
v3: dropped patch 1 "ice: implement set_eeprom functionality" due to a
bug found and additional changes will be needed when Ani implements
devlink in the driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
mv88e6xxx_g2_atu_stats_get() takes two parameters. Make the stub
function also take two, otherwise we get compile errors.
Fixes: c5f299d592 ("net: dsa: mv88e6xxx: global1_atu: Add helper for get next")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Walle says:
====================
net: phy: at803x device tree binding
Adds a device tree binding to configure the clock and the RGMII voltage.
Changes since v1:
- rebased to latest net-next
- renamed "Atheros" to "Qualcomm Atheros"
- add a new patch to remove config_init() from AR9331
Changes since the RFC:
- renamed the Kconfig entry to "Qualcomm Atheros.." and reordered the
item
- renamed the prefix from atheros to qca
- use the correct name AR803x (instead of AT803x) in new files and
dt-bindings.
- listed the PHY maintainers in the new schema. Hopefully, thats ok.
- fixed a typo in the bindings schema
- run dtb_checks and dt_binding_check and fixed the schema
- dropped the rgmii-io-1v8 property; instead provide two regulators vddh
and vddio, add one consumer vddio-supply
- fix the clock settings for the AR8030/AR8035
- only the AR8031 supports chaning the LDO and the PLL mode in software.
Check if we have the correct PHY.
- new patch to mention the AR8033 which is the same as the AR8031 just
without PTP support
- new patch which corrects any displayed PHY names and comments. Be
consistent.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
According to its datasheet, the internal PHY doesn't have debug
registers nor MMDs. Since config_init() only configures delays and
clocks and so on in these registers it won't be needed on this PHY.
Remove it.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix at least the displayed strings. The actual name of the chip is
AR803x.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The AR8033 is the AR8031 without PTP support. All other registers are
the same. Unfortunately, they share the same PHY ID. Therefore, we
cannot distinguish between the one with PTP support and the one without.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for configuring the CLK_25M pin as well as the RGMII I/O
voltage by the device tree.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
