linux/drivers/platform/chrome, branch v5.11

Merge tag 'tag-chrome-platform-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux

2020-12-23T23:06:22Z

Pull chrome platform updates from Benson Leung: "cros_ec_typec: - A series from Prashant for Type-C to implement TYPEC_STATUS, parsing USB PD Partner ID VDOs, and registering partner altmodes. cros_ec misc: - Don't treat RTC events as wakeup sources in cros_ec_proto" * tag 'tag-chrome-platform-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags platform/chrome: cros_ec_typec: Register partner altmodes platform/chrome: cros_ec_typec: Parse partner PD ID VDOs platform/chrome: cros_ec_typec: Introduce TYPEC_STATUS platform/chrome: cros_ec: Import Type C host commands platform/chrome: cros_ec_typec: Clear partner identity on device removal platform/chrome: cros_ec_typec: Fix remove partner logic platform/chrome: cros_ec_typec: Relocate set_port_params_v*() functions platform/chrome: Don't treat RTC events as wakeup sources

Merge tag 'spi-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2020-12-15T23:51:10Z

Pull spi updates from Mark Brown: "The big change this release has been some excellent work from Lukas Wunner which closes a bunch of holes in the cleanup paths for drivers, mainly introduced as a result of devm conversions causing bad interactions with the support SPI has for allocating the bus and driver data together. Together with some of the other work done it feels like we've turned the corner on several long standing pain points with the API. Summary: - Many cleanups around probe/remove and error handling from Lukas Wunner and Uwe Kleine-König, and further fixes around PM from Zhang Qilong. - Provide a mask for which bits of the mode can safely be configured by drivers and use that to fix an issue with the ADS7846 driver. - Documentation of the expected interactions between SPI and GPIO level chip select polarity configuration from H. Nikolaus Schaller, hopefully we're pretty much at the end of sorting out the interactions there. Thanks to Nikolaus, Sven Van Asbroeck and Linus Walleij for this. - DMA support for Allwinner sun6i controllers. - Support for Canaan K210 Designware implementations and Intel Adler Lake" * tag 'spi-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (69 commits) spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors spi: Limit the spi device max speed to controller's max speed spi: spi-geni-qcom: Use the new method of gpio CS control platform/chrome: cros_ec_spi: Drop bits_per_word assignment platform/chrome: cros_ec_spi: Don't overwrite spi::mode spi: dw: Add support for the Canaan K210 SoC SPI spi: dw: Add support for 32-bits max xfer size dt-bindings: spi: dw-apb-ssi: Add Canaan K210 SPI controller spi: Update DT binding docs to support SiFive FU740 SoC spi: atmel-quadspi: Fix use-after-free on unbind spi: npcm-fiu: Disable clock in probe error path spi: ar934x: Don't leak SPI master in probe error path spi: mt7621: Don't leak SPI master in probe error path spi: mt7621: Disable clock in probe error path media: netup_unidvb: Don't leak SPI master in probe error path spi: sc18is602: Don't leak SPI master in probe error path spi: rb4xx: Don't leak SPI master in probe error path spi: gpio: Don't leak SPI master in probe error path spi: spi-mtk-nor: Don't leak SPI master in probe error path spi: mxic: Don't leak SPI master in probe error path ...

platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags

2020-12-10T21:05:16Z

On occasion, the Chrome Embedded Controller (EC) can send a mux configuration which doesn't map to a particular data mode. For instance, dedicated Type C chargers, when connected, may cause only USB_PD_MUX_POLARITY_INVERTED to be set. This is a valid flag combination and should not lead to a driver abort. Modify the mux configuration handling to not return an error when an unrecognized mux flag combination is encountered. Concordantly, make the ensuing print a debug level print so as to not pollute the kernel logs. Cc: Keith Short Signed-off-by: Prashant Malani Acked-by: Heikki Krogerus Signed-off-by: Benson Leung Link: https://lore.kernel.org/r/20201106020305.767202-1-pmalani@chromium.org

platform/chrome: cros_ec_spi: Drop bits_per_word assignment

2020-12-09T16:52:09Z

This is already handed by default in spi_setup() if the bits_per_word is 0, so just drop it to shave off a line. Cc: Simon Glass Cc: Gwendal Grignou Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Acked-by: Enric Balletbo i Serra Cc: Alexandru M Stan Signed-off-by: Stephen Boyd Reviewed-by: Simon Glass Link: https://lore.kernel.org/r/20201204193540.3047030-3-swboyd@chromium.org Signed-off-by: Mark Brown

platform/chrome: cros_ec_spi: Don't overwrite spi::mode

2020-12-09T16:52:08Z

There isn't any need to overwrite the mode here in the driver with what has been detected by the firmware, such as DT or ACPI. In fact, if we use the SPI CS gpio descriptor feature we will overwrite the mode with SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle when the device is probed when it shouldn't change, confusing the driver and making it fail to probe. Drop the assignment and let the spi core take care of it. Fixes: a17d94f0b6e1 ("mfd: Add ChromeOS EC SPI driver") Cc: Simon Glass Cc: Gwendal Grignou Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Acked-by: Enric Balletbo i Serra Cc: Alexandru M Stan Signed-off-by: Stephen Boyd Reviewed-by: Simon Glass Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org Signed-off-by: Mark Brown

platform/chrome: cros_ec_typec: Correct the Thunderbolt rounded/non-rounded cable support

2020-11-18T11:53:45Z

Thunderbolt rounded/non-rounded cable support is two bits value. Correcting it as per the Thunderbolt 3 cable discover mode VDO changes done in the Thunderbolt 3 alternate mode header. Signed-off-by: Utkarsh Patel Reviewed-by: Heikki Krogerus Acked-by: Enric Balletbo i Serra -- Changes in v2: - Removed the fixes tag as there is no functional implication. -- Link: https://lore.kernel.org/r/20201113202503.6559-3-utkarsh.h.patel@intel.com Signed-off-by: Greg Kroah-Hartman

platform/chrome: cros_ec_typec: Register partner altmodes

2020-11-12T20:32:09Z

Use the discovery data from the Chrome EC to register parter altmodes with the Type C Connector Class framework. Also introduce a node struct to keep track of the list of registered alt modes. Signed-off-by: Prashant Malani Signed-off-by: Enric Balletbo i Serra Acked-by: Heikki Krogerus Cc: Heikki Krogerus Link: https://lore.kernel.org/r/20201029222738.482366-8-pmalani@chromium.org

platform/chrome: cros_ec_typec: Parse partner PD ID VDOs

2020-11-12T20:32:09Z

Use EC_CMD_TYPE_DISCOVERY to retrieve and store the discovery data for the port partner. With that data, update the PD Identity VDO values for the partner, which were earlier not initialized. Signed-off-by: Prashant Malani Signed-off-by: Enric Balletbo i Serra Acked-by: Heikki Krogerus Cc: Heikki Krogerus Link: https://lore.kernel.org/r/20201029222738.482366-7-pmalani@chromium.org

platform/chrome: cros_ec_typec: Introduce TYPEC_STATUS

2020-11-12T20:32:09Z

Make a call to the newly introduced EC_CMD_TYPEC_STATUS command. Currently we just check to see if the SOP (port-partner) discovery was done and emit a debug level print for it. Subsequent patches will retrieve and parse the discovery data and fill out the Type C connector class data structures. Also check the EC_FEATURE_TYPEC_CMD feature flag at probe, and only call the new TYPEC_STATUS command if the feature flag is supported. Reported-by: kernel test robot Signed-off-by: Prashant Malani Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20201029222738.482366-6-pmalani@chromium.org

platform/chrome: cros_ec_typec: Clear partner identity on device removal

2020-11-12T20:32:09Z

The partner identity struct isn't reset when a partner is removed, meaning a subsequent partner can inherit an old partner's identity VDOs before discovery is complete. So, clear that struct when a partner removal is detected. Signed-off-by: Prashant Malani Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20201029222738.482366-4-pmalani@chromium.org