summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-12-11i2c: Warn when device removing failsUwe Kleine-König
The driver core ignores the return value of struct bus_type::remove. So warn if there is an error that went unnoticed before and return 0 unconditionally in i2c_device_remove(). This prepares changing struct bus_type::remove to return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [wsa: added a comment and removed unneeded initializtion] Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-12-11irqchip/loongson-htpic: Fix build warningsHuacai Chen
Fix build warnings as below: drivers/irqchip/irq-loongson-htpic.c: In function 'htpic_reg_init': >> drivers/irqchip/irq-loongson-htpic.c:62:12: warning: variable 'val' set but not used [-Wunused-but-set-variable] 62 | uint32_t val; | ^~~ drivers/irqchip/irq-loongson-htpic.c: At top level: >> drivers/irqchip/irq-loongson-htpic.c:84:12: warning: no previous prototype for 'htpic_of_init' [-Wmissing-prototypes] 84 | int __init htpic_of_init(struct device_node *node, struct device_node *parent) | ^~~~~~~~~~~~~ Fixes: a93f1d903fa34fc2c5d9fa450bd ("irqchip: Add driver for Loongson-3 HyperTransport PIC controller") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Huacai Chen <chenhuacai@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1607159744-995-1-git-send-email-chenhuacai@kernel.org
2020-12-11irqchip/gic: Spelling s/REturn/Return/Geert Uytterhoeven
Fix a capitalization typo. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201209101504.2206941-1-geert+renesas@glider.be
2020-12-11dmaengine: bam_dma: fix return of bam_dma_irq()Parth Y Shah
While performing suspend/resume, we were getting below kernel crash. [ 54.541672] [FTS][Info]gesture suspend... [ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed! [ 54.605256] [ 58.345850] irq event 10: bogus return value fffffff3 ...... [ 58.345966] [<ffff0000080830f0>] el1_irq+0xb0/0x124 [ 58.345971] [<ffff000008085360>] arch_cpu_idle+0x10/0x18 [ 58.345975] [<ffff0000081077f4>] do_idle+0x1ac/0x1e0 [ 58.345979] [<ffff0000081079c8>] cpu_startup_entry+0x20/0x28 [ 58.345983] [<ffff000008a80ed0>] rest_init+0xd0/0xdc [ 58.345988] [<ffff0000091c0b48>] start_kernel+0x390/0x3a4 [ 58.345990] handlers: [ 58.345994] [<ffff0000085120d0>] bam_dma_irq The reason for the crash we found is, bam_dma_irq() was returning negative value when the device resumes in some conditions. In addition, the irq handler should have one of the below return values. IRQ_NONE interrupt was not from this device or was not handled IRQ_HANDLED interrupt was handled by this device IRQ_WAKE_THREAD handler requests to wake the handler thread Therefore, to resolve this crash, we have changed the return value to IRQ_NONE. Signed-off-by: Parth Y Shah <sparth1292@gmail.com> Link: https://lore.kernel.org/r/1607322820-7450-1-git-send-email-sparth1292@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: idxd: add IAX configuration support in the IDXD driverDave Jiang
Add support to allow configuration of Intel Analytics Accelerator (IAX) in addition to the Intel Data Streaming Accelerator (DSA). The IAX hardware has the same configuration interface as DSA. The main difference is the type of operations it performs. We can support the DSA and IAX devices on the same driver with some tweaks. IAX has a 64B completion record that needs to be 64B aligned, as opposed to a 32B completion record that is 32B aligned for DSA. IAX also does not support token management. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/160564555488.1834439.4261958859935360473.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: qcom: Fix ADM driver kerneldoc markupJonathan McDowell
Update the kerneldoc function headers to fix build warnings: drivers/dma/qcom/qcom_adm.c:180: warning: Function parameter or member 'chan' not described in 'adm_free_chan' drivers/dma/qcom/qcom_adm.c:190: warning: Function parameter or member 'burst' not described in 'adm_get_blksize' drivers/dma/qcom/qcom_adm.c:466: warning: Function parameter or member 'chan' not described in 'adm_terminate_all' drivers/dma/qcom/qcom_adm.c:466: warning: Excess function parameter 'achan' description in 'adm_terminate_all' drivers/dma/qcom/qcom_adm.c:503: warning: Function parameter or member 'achan' not described in 'adm_start_dma' Signed-off-by: Jonathan McDowell <noodles@earth.li> Link: https://lore.kernel.org/r/20201126184602.GA1008@earth.li Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11regulator: mc13892-regulator: convert comma to semicolonZheng Yongjun
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20201211084510.2264-1-zhengyongjun3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-11regulator: pfuze100: Convert the driver to DT-onlyFabio Estevam
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code by removing the unused non-DT support. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201210212748.5849-1-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-11spi: Limit the spi device max speed to controller's max speedTudor Ambarus
Make sure the max_speed_hz of spi_device does not override the max_speed_hz of controller. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201209173514.93328-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-11thermal/core: Add critical and hot opsDaniel Lezcano
Currently there is no way to the sensors to directly call an ops in interrupt mode without calling thermal_zone_device_update assuming all the trip points are defined. A sensor may want to do something special if a trip point is hot or critical. This patch adds the critical and hot ops to the thermal zone device, so a sensor can directly invoke them or let the thermal framework to call the sensor specific ones. Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20201210121514.25760-2-daniel.lezcano@linaro.org
2020-12-11thermal/core: Emit a warning if the thermal zone is updated without opsDaniel Lezcano
The actual code is silently ignoring a thermal zone update when a driver is requesting it without a get_temp ops set. That looks not correct, as the caller should not have called this function if the thermal zone is unable to read the temperature. That makes the code less robust as the check won't detect the driver is inconsistently using the thermal API and that does not help to improve the framework as these circumvolutions hide the problem at the source. In order to detect the situation when it happens, let's add a warning when the update is requested without the get_temp() ops set. Any warning emitted will have to be fixed at the source of the problem: the caller must not call thermal_zone_device_update if there is not get_temp callback set. Cc: Thara Gopinath <thara.gopinath@linaro.org> Cc: Amit Kucheria <amitk@kernel.org> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20201210121514.25760-1-daniel.lezcano@linaro.org
2020-12-11drm/panfrost: Register devfreq cooling and attempt to add Energy ModelLukasz Luba
Register devfreq cooling device and attempt to register Energy Model. This will add the devfreq device to the Energy Model framework. It will create a dedicated and unified data structures used i.e. in thermal framework. It uses simplified Energy Model, created based on voltage, frequency and DT 'dynamic-power-coefficient'. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210143014.24685-6-lukasz.luba@arm.com
2020-12-11thermal: devfreq_cooling: remove old power model and use EMLukasz Luba
Remove old power model and use new Energy Model to calculate the power budget. It drops static + dynamic power calculations and power table in order to use Energy Model performance domain data. This model should be easy to use and could find more users. It is also less complicated to setup the needed structures. Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210143014.24685-5-lukasz.luba@arm.com
2020-12-11thermal: devfreq_cooling: add new registration functions with Energy ModelLukasz Luba
The Energy Model (EM) framework supports devices such as Devfreq. Create new registration function which automatically register EM for the thermal devfreq_cooling devices. This patch prepares the code for coming changes which are going to replace old power model with the new EM. Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210143014.24685-4-lukasz.luba@arm.com
2020-12-11thermal: devfreq_cooling: use a copy of device statusLukasz Luba
Devfreq cooling needs to now the correct status of the device in order to operate. Devfreq framework can change the device status in the background. To mitigate issues make a copy of the status structure and use it for internal calculations. In addition this patch adds normalization function, which also makes sure that whatever data comes from the device, the load will be in range from 1 to 1024. Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210143014.24685-3-lukasz.luba@arm.com
2020-12-11thermal: devfreq_cooling: change tracing function and argumentsLukasz Luba
Prepare for deleting the static and dynamic power calculation and clean the trace function. These two fields are going to be removed in the next changes. Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> # for tracing code Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210143014.24685-2-lukasz.luba@arm.com
2020-12-11iommu/amd: Add sanity check for interrupt remapping table length macrosSuravee Suthikulpanit
Currently, macros related to the interrupt remapping table length are defined separately. This has resulted in an oversight in which one of the macros were missed when changing the length. To prevent this, redefine the macros to add built-in sanity check. Also, rename macros to use the name of the DTE[IntTabLen] field as specified in the AMD IOMMU specification. There is no functional change. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Will Deacon <will@kernel.org> Cc: Jerry Snitselaar <jsnitsel@redhat.com> Cc: Joerg Roedel <joro@8bytes.org> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20201210162436.126321-1-suravee.suthikulpanit@amd.com Signed-off-by: Will Deacon <will@kernel.org>
2020-12-11usb: typec: tcpm: convert comma to semicolonZheng Yongjun
Replace a comma between expression statements by a semicolon. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20201211085553.2982-1-zhengyongjun3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11crypto: qat - add capability detection logic in qat_4xxxMarco Chiappero
Add logic to detect device capabilities in qat_4xxx driver. Read fuses and build the device capabilities mask. This will enable services and handling specific to QAT 4xxx devices. Co-developed-by: Tomaszx Kowalik <tomaszx.kowalik@intel.com> Signed-off-by: Tomaszx Kowalik <tomaszx.kowalik@intel.com> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-11crypto: qat - add AES-XTS support for QAT GEN4 devicesMarco Chiappero
Add handling of AES-XTS specific to QAT GEN4 devices. Co-developed-by: Tomaszx Kowalik <tomaszx.kowalik@intel.com> Signed-off-by: Tomaszx Kowalik <tomaszx.kowalik@intel.com> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-11crypto: qat - add AES-CTR support for QAT GEN4 devicesMarco Chiappero
Add support for AES-CTR for QAT GEN4 devices. Also, introduce the capability ICP_ACCEL_CAPABILITIES_AES_V2 and the helper macro HW_CAP_AES_V2, which allow to distinguish between different HW generations. Co-developed-by: Tomasz Kowalik <tomaszx.kowalik@intel.com> Signed-off-by: Tomasz Kowalik <tomaszx.kowalik@intel.com> Co-developed-by: Mateusz Polrola <mateuszx.potrola@intel.com> Signed-off-by: Mateusz Polrola <mateuszx.potrola@intel.com> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-11usb: typec: tcpm: Update vbus_vsafe0v on initBadhri Jagan Sridharan
During init, vbus_vsafe0v does not get updated till the first connect as a sink. This causes TCPM to be stuck in SRC_ATTACH_WAIT state while booting with a sink (For instance: a headset) connected. [ 1.429168] Start toggling [ 1.439907] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 1.445242] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 53.358528] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected] [ 53.358564] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] Fix this by updating vbus_vsafe0v based on vbus_present status on boot. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20201211071911.2205197-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11usb: typec: tcpci: Enable bleed discharge when auto discharge is enabledBadhri Jagan Sridharan
Auto discharge circuits kick in only when vbus decays and reaches VBUS_SINK_DISCONNECT_THRESHOLD threshold. Enable bleed discharge to discharge vbus to VBUS_SINK_DISCONNECT_THRESHOLD upon disconnect. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20201211071145.2199997-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11crypto: atmel-i2c - select CONFIG_BITREVERSEArnd Bergmann
The bitreverse helper is almost always built into the kernel, but in a rare randconfig build it is possible to hit a case in which it is a loadable module while the atmel-i2c driver is built-in: arm-linux-gnueabi-ld: drivers/crypto/atmel-i2c.o: in function `atmel_i2c_checksum': atmel-i2c.c:(.text+0xa0): undefined reference to `byte_rev_table' Add one more 'select' statement to prevent this. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-11crypto: hisilicon/trng - replace atomic_add_return()Yejune Deng
a set of atomic_inc_return() looks more neater Signed-off-by: Yejune Deng <yejune.deng@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-11crypto: keembay - Add support for Keem Bay OCS AES/SM4Mike Healy
Add support for the AES/SM4 crypto engine included in the Offload and Crypto Subsystem (OCS) of the Intel Keem Bay SoC, thus enabling hardware-acceleration for the following transformations: - ecb(aes), cbc(aes), ctr(aes), cts(cbc(aes)), gcm(aes) and cbc(aes); supported for 128-bit and 256-bit keys. - ecb(sm4), cbc(sm4), ctr(sm4), cts(cbc(sm4)), gcm(sm4) and cbc(sm4); supported for 128-bit keys. The driver passes crypto manager self-tests, including the extra tests (CRYPTO_MANAGER_EXTRA_TESTS=y). Signed-off-by: Mike Healy <mikex.healy@intel.com> Co-developed-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Acked-by: Mark Gross <mgross@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-11usb: typec: Add class for plug alt mode devicePrashant Malani
Add the Type C class for plug alternate mode devices which are being registered by the Type C connector class. This ensures that udev events get generated when the plug alt modes are registered. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20201210211653.879044-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11USB: typec: tcpci: Add Bleed discharge to POWER_CONTROL definitionBadhri Jagan Sridharan
"Table 4-19. POWER_CONTROL Register Definition" from tcpci spec defines BIT(3) as the control bit for bleed discharge. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Kyle Tso <kyletso@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20201210160521.3417426-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11USB: typec: tcpm: Add a 30ms room for tPSSourceOn in PR_SWAPKyle Tso
TCPM state machine needs 20-25ms to enter the ErrorRecovery state after tPSSourceOn timer timeouts. Change the timer from max 480ms to 450ms to ensure that the timer complies with the Spec. In order to keep the flexibility for other usecases using tPSSourceOn, add another timer only for PR_SWAP. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Kyle Tso <kyletso@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20201210160521.3417426-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11USB: typec: tcpm: Fix PR_SWAP error handlingKyle Tso
PD rev3.0 8.3.3.16.3.6 PE_PRS_SRC_SNK_Wait_Source_on State The Policy Enging Shall transition to the ErrorRecovery state when the PSSourceOnTimer times out ... Cc: Guenter Roeck <linux@roeck-us.net> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Kyle Tso <kyletso@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20201210160521.3417426-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11USB: typec: tcpm: Hard Reset after not receiving a Requestpumahsu
PD 3.0 spec 8.3.3.2.3, A Get_Source_Cap message is sent to a UUT that is in the PE_SRC_Ready state. After sending a Source_Capabilities message, the UUT should then expect a Request message in response. When one is not received, the UUT should timeout to PE_SRC_Hard_Reset. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Badhri Jagan Sridharan <badhri@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: pumahsu <pumahsu@google.com> Signed-off-by: Kyle Tso <kyletso@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20201210160521.3417426-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11ntp: Make the RTC sync offset less obscureThomas Gleixner
The current RTC set_offset_nsec value is not really intuitive to understand. tsched twrite(t2.tv_sec - 1) t2 (seconds increment) The offset is calculated from twrite based on the assumption that t2 - twrite == 1s. That means for the MC146818 RTC the offset needs to be negative so that the write happens 500ms before t2. It's easier to understand when the whole calculation is based on t2. That avoids negative offsets and the meaning is obvious: t2 - twrite: The time defined by the chip when seconds increment after the write. twrite - tsched: The time for the transport to the point where the chip is updated. ==> set_offset_nsec = t2 - tsched ttransport = twrite - tsched tRTCinc = t2 - twrite ==> set_offset_nsec = ttransport + tRTCinc tRTCinc is a chip property and can be obtained from the data sheet. ttransport depends on how the RTC is connected. It is close to 0 for directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the time required to send the update over the bus. This can be estimated or even calibrated, but that's a different problem. Adjust the implementation and update comments accordingly. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de
2020-12-11ntp, rtc: Move rtc_set_ntp_time() to ntp codeThomas Gleixner
rtc_set_ntp_time() is not really RTC functionality as the code is just a user of RTC. Move it into the NTP code which allows further cleanups. Requested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220542.166871172@linutronix.de
2020-12-11rtc: core: Make the sync offset default more realisticThomas Gleixner
The offset which is used to steer the start of an RTC synchronization update via rtc_set_ntp_time() is huge. The math behind this is: tsched twrite(t2.tv_sec - 1) t2 (seconds increment) twrite - tsched is the transport time for the write to hit the device. t2 - twrite depends on the chip and is for most chips one second. The rtc_set_ntp_time() calculation of tsched is: tsched = t2 - 1sec - (t2 - twrite) The default for the sync offset is 500ms which means that twrite - tsched is 500ms assumed that t2 - twrite is one second. This is 0.5 seconds off for RTCs which are directly accessible by IO writes and probably for the majority of i2C/SPI based RTC off by an order of magnitude. Set it to 5ms which should bring it closer to reality. The default can be adjusted by drivers (rtc_cmos does so) and could be adjusted further by a calibration method which is an orthogonal problem. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.960333166@linutronix.de
2020-12-11rtc: cmos: Make rtc_cmos sync offset correctThomas Gleixner
The offset for rtc_cmos must be -500ms to work correctly with the current implementation of rtc_set_ntp_time() due to the following: tsched twrite(t2.tv_sec - 1) t2 (seconds increment) twrite - tsched is the transport time for the write to hit the device, which is negligible for this chip because it's accessed directly. t2 - twrite = 500ms according to the datasheet. But rtc_set_ntp_time() calculation of tsched is: tsched = t2 - 1sec - (t2 - twrite) The default for the sync offset is 500ms which means that the write happens at t2 - 1.5 seconds which is obviously off by a second for this device. Make the offset -500ms so it works correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de
2020-12-11rtc: mc146818: Reduce spinlock section in mc146818_set_time()Thomas Gleixner
No need to hold the lock and disable interrupts for doing math. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.709243630@linutronix.de
2020-12-11rtc: mc146818: Prevent reading garbageThomas Gleixner
The MC146818 driver is prone to read garbage from the RTC. There are several issues all related to the update cycle of the MC146818. The chip increments seconds obviously once per second and indicates that by a bit in a register. The bit goes high 244us before the actual update starts. During the update the readout of the time values is undefined. The code just checks whether the update in progress bit (UIP) is set before reading the clock. If it's set it waits arbitrary 20ms before retrying, which is ample because the maximum update time is ~2ms. But this check does not guarantee that the UIP bit goes high and the actual update happens during the readout. So the following can happen 0.997 UIP = False -> Interrupt/NMI/preemption 0.998 UIP -> True 0.999 Readout <- Undefined To prevent this rework the code so it checks UIP before and after the readout and if set after the readout try again. But that's not enough to cover the following: 0.997 UIP = False Readout seconds -> NMI (or vCPU scheduled out) 0.998 UIP -> True update completes UIP -> False 1.000 Readout minutes,.... UIP check succeeds That can make the readout wrong up to 59 seconds. To prevent this, read the seconds value before the first UIP check, validate it after checking UIP and after reading out the rest. It's amazing that the original i386 code had this actually correct and the generic implementation of the MC146818 driver got it wrong in 2002 and it stayed that way until today. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.594826678@linutronix.de
2020-12-11x86, sched: Calculate frequency invariance for AMD systemsNathan Fontenot
This is the first pass in creating the ability to calculate the frequency invariance on AMD systems. This approach uses the CPPC highest performance and nominal performance values that range from 0 - 255 instead of a high and base frquency. This is because we do not have the ability on AMD to get a highest frequency value. On AMD systems the highest performance and nominal performance vaues do correspond to the highest and base frequencies for the system so using them should produce an appropriate ratio but some tweaking is likely necessary. Due to CPPC being initialized later in boot than when the frequency invariant calculation is currently made, I had to create a callback from the CPPC init code to do the calculation after we have CPPC data. Special thanks to "kernel test robot <lkp@intel.com>" for reporting that compilation of drivers/acpi/cppc_acpi.c is conditional to CONFIG_ACPI_CPPC_LIB, not just CONFIG_ACPI. [ ggherdovich@suse.cz: made safe under CPU hotplug, edited changelog. ] Signed-off-by: Nathan Fontenot <nathan.fontenot@amd.com> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20201112182614.10700-2-ggherdovich@suse.cz
2020-12-11mmc: sdhci-xenon: introduce ACPI supportMarcin Wojtas
Previous patches dropped the strict dependency on the OF_* in the sdhci-xenon driver. As a result the ACPI support can be introduced (except for the XENON_A3700 variant) by adding the necessary ID's in the acpi_match_table. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-5-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-12-11mmc: sdhci-xenon: use clk only with DTMarcin Wojtas
As a preparation for supporting ACPI, modify the driver to use the clk framework only when booting with DT - otherwise rely on the configuration done by firmware. For that purpose introduce also a custom SDHCI get_max_clock callback. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-4-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-12-11mmc: sdhci-xenon: switch to device_* APIMarcin Wojtas
In order to support both ACPI and DT, modify the driver to use device_* routines for obtaining the properties values. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-3-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-12-11mmc: sdhci-xenon: use match data for controllers variantsMarcin Wojtas
As a part of the ACPI support preparation resign from checking compatible strings in the driver. Instead of that use a new enum and assign the values to match data accordingly. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-2-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-12-11Merge tag 'extcon-next-for-5.11' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update for extcon-next v5.11 1. Add new TI TUSB320 USB-C extcon driver - The extcon-usbc-tusb320.c driver for the TI TUSB320 USB Type-C device support the USB Type C connector detection. 2. Rewrite binding document in yaml for extcon-fsa9480.c and add new compatible name of TI TSU6111 device. 3. Fix moalias string of extcon-max77693.c to fix the automated module loading when this driver is compiled as a module. * tag 'extcon-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: max77693: Fix modalias string extcon: fsa9480: Support TI TSU6111 variant extcon: fsa9480: Rewrite bindings in YAML and extend dt-bindings: extcon: add binding for TUSB320 extcon: Add driver for TI TUSB320
2020-12-11Input: new da7280 haptic driverRoy Im
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple mode and integrated waveform memory and wideband support. It communicates via an I2C bus to the device. Signed-off-by: Roy Im <roy.im.opensource@diasemi.com> Reviewed-by: Jes Sorensen <Jes.Sorensen@gmail.com>. Link: https://lore.kernel.org/r/1e293e8c4830b09255af3b7e1721b73afaefdfa3.1606320459.git.Roy.Im@diasemi.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-11extcon: max77693: Fix modalias stringMarek Szyprowski
The platform device driver name is "max77693-muic", so advertise it properly in the modalias string. This fixes automated module loading when this driver is compiled as a module. Fixes: db1b9037424b ("extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-12-11Input: elantech - fix protocol errors for some trackpoints in SMBus modejingle.wu
There are some version of Elan trackpads that send incorrect data when in SMbus mode, unless they are switched to use 0x5f reports instead of standard 0x5e. This patch implements querying device to retrieve chips identifying data, and switching it, when needed to the alternative report. Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw> Link: https://lore.kernel.org/r/20201211071531.32413-1-jingle.wu@emc.com.tw Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-11Input: elan_i2c - add new trackpoint report type 0x5FJingle Wu
The 0x5F is a new trackpoint report type used by some modules. Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw> Link: https://lore.kernel.org/r/20201211071511.32349-1-jingle.wu@emc.com.tw Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-11extcon: fsa9480: Support TI TSU6111 variantLinus Walleij
The Texas Instruments TSU6111 is compatible to the FSA880/FSA9480. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-12-11extcon: Add driver for TI TUSB320Michael Auchter
This patch adds an extcon driver for the TI TUSB320 USB Type-C device. This can be used to detect whether the port is configured as a downstream or upstream facing port. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-12-10Input: elants - document some registers and valuesMichał Mirosław
Add information found in downstream kernels, to make the code less magic. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/728fff020bc92be10d84cc2a7ea8af6fd99af96c.1607669375.git.mirq-linux@rere.qmqm.pl Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
generated by cgit (git 2.34.1) at 2025-09-13 23:13:23 +0000