Pull ARM SoC platform updates from Olof Johansson:
"SoC changes, a substantial part of this is cleanup of some of the
older platforms that used to have a bunch of board files.
In particular:
- Remove non-DT i.MX platforms that haven't seen activity in years,
it's time to remove them.
- A bunch of cleanup and removal of platform data for TI/OMAP
platforms, moving over to genpd for power/reset control (yay!)
- Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
closer to multiplatform support (not quite there yet, but getting
close).
There are a few other changes too, smaller fixlets, etc. For new
platform support, the primary ones are:
- New SoC: Hisilicon SD5203, ARM926EJ-S platform.
- Cpufreq support for i.MX7ULP"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits)
ARM: mstar: Select MStar intc
ARM: stm32: Replace HTTP links with HTTPS ones
ARM: debug: add UART early console support for SD5203
ARM: hisi: add support for SD5203 SoC
ARM: omap3: enable off mode automatically
clk: imx: imx35: Remove mx35_clocks_init()
clk: imx: imx31: Remove mx31_clocks_init()
clk: imx: imx27: Remove mx27_clocks_init()
ARM: imx: Remove unused definitions
ARM: imx35: Retrieve the IIM base address from devicetree
ARM: imx3: Retrieve the AVIC base address from devicetree
ARM: imx3: Retrieve the CCM base address from devicetree
ARM: imx31: Retrieve the IIM base address from devicetree
ARM: imx27: Retrieve the CCM base address from devicetree
ARM: imx27: Retrieve the SYSCTRL base address from devicetree
ARM: s3c64xx: bring back notes from removed debug-macro.S
ARM: s3c24xx: fix Wunused-variable warning on !MMU
ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
MAINTAINERS: mark linux-samsung-soc list non-moderated
ARM: imx: Remove remnant board file support pieces
...
Pull driver core updates from Greg KH:
"Here is the "big" set of driver core patches for 5.10-rc1
They include a lot of different things, all related to the driver core
and/or some driver logic:
- sysfs common write functions to make it easier to audit sysfs
attributes
- device connection cleanups and fixes
- devm helpers for a few functions
- NOIO allocations for when devices are being removed
- minor cleanups and fixes
All have been in linux-next for a while with no reported issues"
* tag 'driver-core-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (31 commits)
regmap: debugfs: use semicolons rather than commas to separate statements
platform/x86: intel_pmc_core: do not create a static struct device
drivers core: node: Use a more typical macro definition style for ACCESS_ATTR
drivers core: Use sysfs_emit for shared_cpu_map_show and shared_cpu_list_show
mm: and drivers core: Convert hugetlb_report_node_meminfo to sysfs_emit
drivers core: Miscellaneous changes for sysfs_emit
drivers core: Reindent a couple uses around sysfs_emit
drivers core: Remove strcat uses around sysfs_emit and neaten
drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
dyndbg: use keyword, arg varnames for query term pairs
driver core: force NOIO allocations during unplug
platform_device: switch to simpler IDA interface
driver core: platform: Document return type of more functions
Revert "driver core: Annotate dev_err_probe() with __must_check"
Revert "test_firmware: Test platform fw loading on non-EFI systems"
iio: adc: xilinx-xadc: use devm_krealloc()
hwmon: pmbus: use more devres helpers
devres: provide devm_krealloc()
syscore: Use pm_pr_dbg() for syscore_{suspend,resume}()
...
Problem:
We use voltage dividers so that the voltage presented at the voltage
sense pins is confusing. We might need to convert these readings to more
meaningful readings given the voltage divider.
Solution:
Read the voltage divider resistance from dts and convert the voltage
reading to a more meaningful reading.
Testing:
max20730 with voltage divider
Signed-off-by: Chu Lin <linchuyuan@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20201004031445.2321090-3-linchuyuan@google.com
[groeck: Return -EINVAL instead of -ENODEV on bad deevicetree data]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The max34* family have the IOUT_OC_WARN_LIMIT and IOUT_OC_CRIT_LIMIT
registers swapped.
Cc: stable@vger.kernel.org
Signed-off-by: Steve Foreman <foremans@google.com>
[groeck: Updated subject, use C comment style, tab after defines]
[groeck: Added missing break; statements (by alexandru.ardelean@analog.com)]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If the PVT sensor is suddenly powered down while a caller is waiting for
the conversion completion, the request won't be finished and the task will
hang up on this procedure until the power is back up again. Let's call the
wait_for_completion_timeout() method instead to prevent that. The cached
timeout is exactly what we need to predict for how long conversion could
normally last.
Fixes: 87976ce282 ("hwmon: Add Baikal-T1 PVT sensor driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920110924.19741-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Instead of converting the update timeout data to the milliseconds each
time on the read procedure let's preserve the currently set timeout in the
dedicated driver private data cache. The cached value will be then used in
the timeout read method and in the alarm-less data conversion to prevent
the caller task hanging up in case if the PVT sensor is suddenly powered
down.
Fixes: 87976ce282 ("hwmon: Add Baikal-T1 PVT sensor driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920110924.19741-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Baikal-T1 PVT sensor has got a dedicated power supply domain (feed up by
the external GPVT/VPVT_18 pins). In case if it isn't powered up, the
registers will be accessible, but the sensor conversion just won't happen.
Due to that an attempt to read data from any PVT sensor will cause the
task hanging up. For instance that will happen if XP11 jumper isn't
installed on the Baikal-T1-based BFK3.1 board. Let's at least test whether
the conversion work on the device probe procedure. By doing so will make
sure that the PVT sensor is powered up at least at boot time.
Fixes: 87976ce282 ("hwmon: Add Baikal-T1 PVT sensor driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920110924.19741-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This patch adds hwmon functionality for Intel MAX 10 BMC chip. This BMC
chip connects to a set of sensor chips to monitor current, voltage,
thermal and power of different components on board. The BMC firmware is
responsible for sensor data sampling and recording in shared registers.
Host driver reads the sensor data from these shared registers and
exposes them to users as hwmon interfaces.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/1600669071-26235-3-git-send-email-yilun.xu@intel.com
[groeck: Adjusted subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for mp295 device from Monolithic Power Systems, Inc. (MPS)
vendor. This is a dual-loop, digital, multi-phase controller.
This device:
- Supports two power rail.
- Provides 8 pulse-width modulations (PWMs), and can be configured up
to 8-phase operation for rail 1 and up to 4-phase operation for rail
2.
- Supports two pages 0 and 1 for telemetry and also pages 2 and 3 for
configuration.
- Can configured VOUT readout in direct or VID format and allows
setting of different formats on rails 1 and 2. For VID the following
protocols are available: VR13 mode with 5-mV DAC; VR13 mode with
10-mV DAC, IMVP9 mode with 5-mV DAC.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20200926204957.10268-2-vadimp@nvidia.com
[groeck: Cleaned up a couple of error returns; fixed up API changes]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
On a system with course grain resolution of energy unit (milli J) the
accumulation thread can be executed less frequently than on the system
with fine grain resolution(micro J).
This patch sets the accumulation thread interval to an optimum value
calculated based on the (energy unit) resolution supported by the
hardware (assuming a peak wattage of 240W).
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
Link: https://lore.kernel.org/r/20200929105322.8919-3-nchatrad@amd.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
0-day rightfully complains about a sometimes uninitialized variable
in pmbus_get_boolean().
drivers/hwmon/pmbus/pmbus_core.c:903:13: warning:
variable 'ret' is used uninitialized whenever 'if' condition is true
} else if (!s1 || !s2) {
While that is technically true, it won't be hit in the field since the
condition indicates a programming error. Move the check of that condition
into the code generating the attribute entry, and refuse generating the
attribute if the condition is true. Swap the condition check in
pmbus_get_boolean() to ensure that static analyzers don't get a hiccup
(because we check if s1 and s2 are NULL, static analyzers may believe
that they can be NULL independently of each other).
Reported-by: kernel test robot <lkp@intel.com>
Cc: Alex Qiu <xqiu@google.com>
Reviewed-by: Alex Qiu <xqiu@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Enable runtime debug control of whether the PEC byte is exchanged with
the PMBus device.
Some manufacturers have asked for the PEC to be disabled as part of
debugging driver communication issues with devices.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20200910021106.2958382-1-andrew@aj.id.au
[groeck: Replace %1llu with %llu]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Caching register values can be very expensive for PMBus chips. Some
modern chips may have 10 or more pages, with several sensors supported
per page. For example, MAX16601 creates more than 90 sysfs attributes.
Register caching for such chips is time consuming, especially if only a
few attributes are read on a regular basis. For MAX16601, it was observed
that it can take up to two seconds to read all attributes on a slow I2C
bus. In this situation, register caching results in the opposite of its
intention: It increases the number of I2C operations, in some cases
substantially, and it results in large latency when trying to access
individual sensor data.
Drop all register caching to solve the problem. Since it is no longer
necessary, drop status register mapping as part of the change, and specify
status registers directly.
Cc: Alex Qiu <xqiu@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Alex Qiu <xqiu@google.com>
Tested-by: Alex Qiu <xqiu@google.com>
Link: https://lore.kernel.org/r/20200904163314.259087-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The debugfs code was intended to aid figuring out functionality
of undocumented registers. Turns out that wasn't very helpful,
since register locations change too much between AMD chip revisions,
and the data isn't really valuable for chips where it isn't already
supported. On top of that, its existence has been used as argument
for providing pseudo-API debugfs functions in other drivers.
So let's just take it out.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use the nvmem kernel api to expose the black box
chip functionality to userspace.
Using this feature, the device is capable of recording
to nonvolatile flash memory the vital data about the
system status that caused the system to perform a
black box write.
A blackbox is 64 bytes of data containing all the
status registers, last two states of the sequencer,
timestamp and counters. The mapping of this data is
described in the adm1266 datasheet.
On power-up the driver sets the unix time to
the adm1266 using the SET_RTC command. This value
is incremented by an internal clock and it is used
as timestamp for the black box feature.
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Link: https://lore.kernel.org/r/20200812142055.9213-6-alexandru.tachici@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200821160035.590142-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200821160159.591293-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200821160231.592571-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Many hwmon drivers don't use the id information provided by the old
i2c probe function, and the remainder can easily be adapted to the new
form ("probe_new") by calling i2c_match_id explicitly.
This avoids scanning the identifier tables during probes.
Drivers which didn't use the id are converted as-is; drivers which did
are modified to call i2c_match_id() with the same level of
error-handling (if any) as before.
This patch wraps up the transition for hwmon, with four stragglers not
included in the previous large patch.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200821160354.594715-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Many hwmon drivers don't use the id information provided by the old
i2c probe function, and the remainder can easily be adapted to the new
form ("probe_new") by calling i2c_match_id explicitly.
This avoids scanning the identifier tables during probes.
Drivers which didn't use the id are converted as-is; drivers which did
are modified as follows:
* if the information in i2c_client is sufficient, that's used instead
(client->name);
* anything else is handled by calling i2c_match_id() with the same
level of error-handling (if any) as before.
A few drivers aren't included in this patch because they have a
different set of maintainers. They will be covered by other patches.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200813160222.1503401-1-steve@sk2.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>