| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
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
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
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
...
|
|
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 <keithshort@chromium.org>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20201106020305.767202-1-pmalani@chromium.org
|
|
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 <sjg@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20201204193540.3047030-3-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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 <sjg@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
cable support
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 <utkarsh.h.patel@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
--
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 <gregkh@linuxfoundation.org>
|
|
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 <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201029222738.482366-8-pmalani@chromium.org
|
|
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 <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201029222738.482366-7-pmalani@chromium.org
|
|
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 <lkp@intel.com>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20201029222738.482366-6-pmalani@chromium.org
|
|
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 <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20201029222738.482366-4-pmalani@chromium.org
|
|
The cros_unregister_ports() function can be called in situations where
the partner has not been registered yet, and so its related data
structures would not have been initialized. Calling
cros_typec_remove_partner() in such a situation can lead to null pointer
dereferences. So, only call cros_typec_remove_partner() if there is a
valid registered partner pointer.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20201029222738.482366-3-pmalani@chromium.org
|
|
Move the cros_typec_set_port_params_v0/v1() functions closer to the
place where they are called, cros_typec_port_update().
While we are performing the relocation, also move cros_typec_get_mux_info()
closer to its call-site.
No functional changes are introduced by this commit.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20201029222738.482366-2-pmalani@chromium.org
|
|
The EC sends an RTC host event when the RTC fires, but we don't need to
treat that as a wakeup event here. The RTC class already properly
handles activating and deactivating a wakeup source in rtc_update_irq()
by calling pm_stay_awake() at the start of processing and pm_relax()
once all expired RTC timers have been processed. This reduces one wakeup
increment but not much else. I noticed this while debugging RTC wakeups
and how they always incremented the wakeup count by two instead of one
because this is duplicated.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: <linux-rtc@vger.kernel.org>
Link: https://lore.kernel.org/r/20201030232523.2654478-1-swboyd@chromium.org
|
|
Use kobj_to_dev() instead of container_of().
Signed-off-by: Wang Qing <wangqing@vivo.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Since cros_ec_cmd_xfer_status() now returns Linux error codes and all
other files use that command, remove the now-unused function
cros_ec_cmd_xfer().
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Since all the other call-sites of cros_ec_cmd_xfer() have been converted
to use cros_ec_cmd_xfer_status() instead, update the remaining
call-sites to prepare for the merge of cros_ec_cmd_xfer() into
cros_ec_cmd_xfer_status().
As part of this update, change the error handling inside
cros_ec_get_sensor_count() such that the legacy LPC interface is tried
on all error values, not just when msg->result != EC_RESULT_SUCCESS.
Note that there is a slight change in API in cros_ec_get_sensor_count():
it will return a negative number of sensors when there are no sensors
on arm platform when MOTIONSENSE_CMD_DUMP is not supported (typical for
sensorless chromebook) instead of 0. However, this is not a problem when
probing the EC as we ignore errors only looking for cros_ec_get_sensor_count()
returning a positive number of sensors.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
The MFD_CROS_EC config was a transitional Kconfig option to not break
current defconfigs in the kernel. Now, this is not required anymore
because all the defconfigs have been removed this option and migrated to
enable the CrOS EC parts individually.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
|
|
By default, the lightbar commands are set to the biggest lightbar command
and response. That length is greater than 128 bytes and may not work on
all machines. But all EC are probed for lightbar by sending a get version
request. Set that request size precisely.
Before the command would be:
cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194, insize: 128, result: 0
Afer:
cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1, insize: 8, result: 0
Fixes: a841178445bb7 ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
In ftrace, add more fields to the cros_ec command event:
- Add size of commands to check if they are properly set.
- Add offset (in case an EC is cascaded being another EC),
to allow proper command output
With:
echo 1 > events/cros_ec/cros_ec_cmd/enable
We now have (on samus)
Invalid command for the sensor stack:
ectool-6942 [002] .... 3082.783116: cros_ec_request_done: version: 3,
offset: 0, command: EC_CMD_MOTION_SENSE_CMD, outsize: 2, insize: 19,
ec result: EC_RES_INVALID_PARAM, retval: 0
Powerd accessing PD EC being the main EC:
powerd-1272 [002] .... 40.644026: cros_ec_request_done: version: 0,
offset: 1, command: EC_CMD_USB_PD_POWER_INFO, outsize: 1, insize: 16,
ec result: EC_RES_SUCCESS, retval: 16
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
As per USB Type-C Spec R2.0 section 4.5.1.2 (Connecting Sources and Sinks)
and section 4.5.2.2 (Connection State Machine Requirements), the typical
flow for configuring a device connected to a typeC port is as below:
1. Source/sink detection
2. Orientation
3. Data role
4. VCONN
5. VBUS (USB Type-C currents)
6. The connector is now configured. We can start the PD communication
that should lead into configuration of the mux if we enter a mode.
But in existing code data role was set after the connector and mux are
already configured. So fix this by following the spec to set the data
role before the connector and mux are configured.
Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Reviewed-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
On disconnect port partner is removed and usb role is set to NONE.
But then in cros_typec_port_update() the role is set again.
Avoid this by moving usb_role_switch_set_role() to
cros_typec_configure_mux().
Suggested-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
usb_role_switch_set_role() has the second argument as enum for usb_role.
Currently depending upon the data role i.e. UFP(0) or DFP(1) is sent.
This eventually translates to USB_ROLE_NONE in case of UFP and
USB_ROLE_DEVICE in case of DFP. Correct this by sending correct enum
values as USB_ROLE_DEVICE in case of UFP and USB_ROLE_HOST in case of
DFP.
Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Cc: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
With USB4 mode the mux driver needs the Enter_USB Data
Object (EUDO) that was used when the USB mode was entered.
Though the object is not available in the driver, it is
possible to construct it from the information we have.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
The EC reports a variety of error codes. Most of those, with the exception
of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual
EC error code gets lost. Introduce cros_ec_map_error() to map EC error
codes to Linux error codes, and use it in cros_ec_cmd_xfer_status() to
report more meaningful errors to the caller. With this change, callers of
cros_ec_cmd_xfer_status() can implement a more distinguished action without
having to rely on the EC error code. At the same time, debugging is improved
in situations where the Linux error code is reported to userspace and/or in
the kernel log.
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
-ENOTSUPP is not a SUSV4 error code and should not be used. Use
-ENOPROTOOPT instead to report EC_RES_INVALID_VERSION responses
from the EC. This matches match the NFS response for unsupported
protocol versions.
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Since commit c5cd2b47b203 ("platform/chrome: cros_ec_proto: Report command
not supported") we can no longer assume that cros_ec_cmd_xfer_status()
reports -EPROTO for all errors returned by the EC itself. A follow-up
patch will change cros_ec_cmd_xfer_status() to report additional errors
reported by the EC as distinguished Linux error codes.
Prepare for this change by always reporting both the Linux error code
and the EC error code in sysfs attributes.
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Since commit c5cd2b47b203 ("platform/chrome: cros_ec_proto: Report command
not supported") we can no longer assume that cros_ec_cmd_xfer_status()
reports -EPROTO for all errors returned by the EC itself. A follow-up
patch will change cros_ec_cmd_xfer_status() to report additional errors
reported by the EC as distinguished Linux error codes.
Handle this change by no longer assuming that -EPROTO is used to report
all errors returned by the EC itself. Since errors reported by the EC are
already reported in text form through sysfs attributes, extend this form
of error reporting to all errors reported by cros_ec_cmd_xfer_status().
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Cc: Prashant Malani <pmalani@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"cros_ec_typec:
- Add support for switch control and alternate modes to the Chrome EC
Type C port driver
- Add basic suspend/resume support
sensorhub:
- Fix timestamp overflow issue
- Fix legacy timestamp spreading on Nami systems
cros_ec_proto:
- After removing all users of, stop exporting cros_ec_cmd_xfer
- Check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK and ignore
wakeups on old ECs
misc:
- Documentation warning cleanup
- Fix double unlock issue in ishtp"
* tag 'tag-chrome-platform-for-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: (21 commits)
platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK
platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs
platform/chrome: cros_ec_sensorhub: Simplify legacy timestamp spreading
platform/chrome: cros_ec_proto: Do not export cros_ec_cmd_xfer()
platform/chrome: cros_ec_typec: Unregister partner on error
platform/chrome: cros_ec_sensorhub: Fix EC timestamp overflow
platform/chrome: cros_ec_typec: Add PM support
platform/chrome: cros_ec_typec: Use workqueue for port update
platform/chrome: cros_ec_typec: Add a dependency on USB_ROLE_SWITCH
platform/chrome: cros_ec_ishtp: Fix a double-unlock issue
platform/chrome: cros_ec_rpmsg: Document missing struct parameters
platform/chrome: cros_ec_spi: Document missing function parameters
platform/chrome: cros_ec_typec: Add TBT compat support
platform/chrome: cros_ec: Add TBT pd_ctrl fields
platform/chrome: cros_ec_typec: Make configure_mux static
platform/chrome: cros_ec_typec: Support DP alt mode
platform/chrome: cros_ec_typec: Add USB mux control
platform/chrome: cros_ec_typec: Register PD CTRL cmd v2
platform/chrome: cros_ec: Update mux state bits
platform/chrome: cros_ec_typec: Register Type C switches
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull sched/fifo updates from Ingo Molnar:
"This adds the sched_set_fifo*() encapsulation APIs to remove static
priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low'
priority level, plus sched_set_normal() to set the policy back to
non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in
a separate tree"
* tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits)
sched,tracing: Convert to sched_set_fifo()
sched: Remove sched_set_*() return value
sched: Remove sched_setscheduler*() EXPORTs
sched,psi: Convert to sched_set_fifo_low()
sched,rcutorture: Convert to sched_set_fifo_low()
sched,rcuperf: Convert to sched_set_fifo_low()
sched,locktorture: Convert to sched_set_fifo()
sched,irq: Convert to sched_set_fifo()
sched,watchdog: Convert to sched_set_fifo()
sched,serial: Convert to sched_set_fifo()
sched,powerclamp: Convert to sched_set_fifo()
sched,ion: Convert to sched_set_normal()
sched,powercap: Convert to sched_set_fifo*()
sched,spi: Convert to sched_set_fifo*()
sched,mmc: Convert to sched_set_fifo*()
sched,ivtv: Convert to sched_set_fifo*()
sched,drm/scheduler: Convert to sched_set_fifo*()
sched,msm: Convert to sched_set_fifo*()
sched,psci: Convert to sched_set_fifo*()
sched,drbd: Convert to sched_set_fifo*()
...
|
|
EC_CMD_HOST_EVENT_GET_WAKE_MASK
As with cros_ec_cmd_xfer_status(), etc., it's not enough to simply check
for the return status of send_command() -- that only covers transport or
other similarly-fatal errors. One must also check the ->result field, to
see whether the command really succeeded. If not, we can't use the data
it returns.
The caller of cros_ec_get_host_event_wake_mask() ignores this, and so
for example, on EC's where the command is not implemented, we're using
junk (or in practice, all zeros) for our wake-mask. We should be using a
non-zero default (currently, it's supposed to be all-1's).
Fix this by checking the ->result field and returning -EPROTO for
errors.
I might label this as fixing commit 29d99b966d60 ("cros_ec: Don't signal
wake event for non-wake host events"), except that this fix alone
actually may make things worse, as it now allows for a lot more spurious
wakeups. The patch "platform/chrome: cros_ec_proto: ignore battery/AC
wakeups on old ECs" helps to mitigate this.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
ECs that don't implement EC_CMD_HOST_EVENT_GET_WAKE_MASK should still
have some reasonable default mask -- otherwise, they'll treat a variety
of EC signals as spurious wakeups. Battery and AC events can be
especially common, for devices that have been sitting at full charge
plugged into AC for a long time, as they may cycle their charging off
and on, or their battery may start reporting failures as it ages.
Treating these as wakeups does not serve a useful purpose, and is
instead often counterproductive. And indeed, later ECs (that implement
the mask) don't include these events in their wake-mask.
Note that this patch doesn't do anything without the subsequent patch
("platform/chrome: cros_ec_proto: check for missing
EC_CMD_HOST_EVENT_GET_WAKE_MASK"), because
cros_ec_get_host_event_wake_mask() currently does not return an error if
EC_CMD_HOST_EVENT_GET_WAKE_MASK is not implemented.
Some additional notes:
While the EC typically knows not to wake the CPU for these unimportant
events once the CPU reaches a sleep state, it doesn't really have a way
to know that the CPU is "almost" asleep, unless it has support for
EC_CMD_HOST_SLEEP_EVENT. Alas, these older ECs do not support that
command either, so this solution is not 100% complete.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
On some machines (nami), interrupt latency cause samples to appear
to be from the future and are pegged to the current time.
We would see samples with this pattern:
[t, t + ~5ms, t + ~10ms, t + ~10ms + 100us, t + ~10ms + 200us],
(current now) (current now)
(t is the last timestamp time)
Last 2 samples would be barely spread, causing applications to
complain.
We now spread the entire sequence. This is not great: in the example
the sensor was supposed to send samples every 5ms, it now appears to
send one every 2.5ms, but it is slightly closer to reality:
sampling time in the example above
At sensor level
1 2 3 4 5
+-----5ms-----+-----5ms-----+-----5ms-----+----5ms-----+---> t
Before, at host level
1 2 3 4 5
--interrupt delay------+-----5ms-----+-----5ms-----+-+-+---> t
Afer, at host level
1 2 3 4 5
--interrupt delay------+-2.5ms-+-2.5ms-+-2.5ms-+-2.5ms-+---> t
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Now that all the remaining users of cros_ec_cmd_xfer() has been removed,
make this function private to the cros_ec_proto module.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
When port update is called during probe(), any error with setting the
Type C muxes results in an errno being returned to probe(), which promptly
returns that itself. Ensure that we unregister any registered partners
when doing so, to prevent orphaned partners on the Type C connector
class framework.
Move the cros_typec_add_partner() and cros_typec_remove_partner() code
together to higher up in the file, so that they are together, and we can
call cros_typec_remove_partner() from cros_unregister_ports().
Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
EC is using 32 bit timestamps (us), and before converting it to 64bit
they were not casted, so it would overflow every 4s.
Regular overflow every ~70 minutes was not taken into account either.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Define basic suspend resume functions for cros-ec-typec. On suspend, we
simply ensure that any pending port update work is completed, and on
resume, we re-poll the port state to account for any
changes/disconnections that might have occurred during suspend.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Use a work queue to call the port update routines, instead of doing it
directly in the PD notifier callback. This will prevent other drivers
with PD notifier callbacks from being blocked on the port update routine
completing.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
As reported by the kernel test robot the cros_ec_typec driver fails to
build if the USB_ROLE_SWITCH is not selected, to fix that, add a
dependency on that symbol. This fixes the following build error:
drivers/platform/chrome/cros_ec_typec.c:133: undefined reference to `usb_role_switch_put'
ld: drivers/platform/chrome/cros_ec_typec.o: in function `cros_typec_get_switch_handles':
drivers/platform/chrome/cros_ec_typec.c:108: undefined reference to `fwnode_usb_role_switch_get'
ld: drivers/platform/chrome/cros_ec_typec.c:117: undefined reference to `usb_role_switch_put'
Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
In function cros_ec_ishtp_probe(), "up_write" is already called
before function "cros_ec_dev_init". But "up_write" will be called
again after the calling of the function "cros_ec_dev_init" failed.
Thus add a call of the function “down_write” in this if branch
for the completion of the exception handling.
Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Tested-by: Mathew King <mathewk@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Kerneldoc expects all kernel structure member to be documented.
Fixes the following W=1 level warnings:
cros_ec_rpmsg.c:49: warning: Function parameter or member 'ept' not described in 'cros_ec_rpmsg'
cros_ec_rpmsg.c:49: warning: Function parameter or member 'has_pending_host_event' not described in 'cros_ec_rpmsg'
cros_ec_rpmsg.c:49: warning: Function parameter or member 'probe_done' not described in 'cros_ec_rpmsg'
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
|
|
Kerneldoc expects all kernel function members to be documented.
Fixes the following W=1 level warnings:
cros_ec_spi.c:153: warning: Function parameter or member 'ec_dev' not described in 'receive_n_bytes'
cros_ec_spi.c:153: warning: Function parameter or member 'buf' not described in 'receive_n_bytes'
cros_ec_spi.c:153: warning: Function parameter or member 'n' not described in 'receive_n_bytes'
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
|
|
Add mux control support for Thunderbolt compatibility mode.
Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Co-developed-by: Azhar Shaikh <azhar.shaikh@intel.com>
Co-developed-by: Casey Bowman <casey.g.bowman@intel.com>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Since cros_typec_configure_mux() is only used in cros-ec-typec,
it should be marked static.
Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Handle Chrome EC mux events to configure on-board muxes correctly while
entering DP alternate mode. Since we don't surface SVID and VDO
information regarding the DP alternate mode, configure the Type C
muxes directly from the port driver. Later, when mode discovery
information is correctly surfaced to the driver, we can register the DP
alternate mode driver and let it handle the mux configuration.
Also, modify the struct_typec_state state management to account for the
addition of DP alternate mode.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Add support to configure various Type C switches appropriately using the
Type C connector class API, when the Chrome OS EC informs the AP that
the USB operating mode has been entered.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Recognize EC_CMD_USB_PD_CONTROL command version 2. This is necessary in
order to process Type C mux information (like DP alt mode pin
configuration), which is needed by the Type C Connector class API to
configure the Type C muxes correctly
While we are here, rename the struct member storing this version number
from cmd_ver to pd_ctrl_ver, which more accurately reflects what is
being stored.
Also, slightly change the logic for calling
cros_typec_set_port_params_*(). Now, v0 is called when pd_ctrl_ver is 0,
and v1 is called otherwise.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Register Type C mux and switch handles, when provided via firmware
bindings. These will allow the cros-ec-typec driver, and also alternate
mode drivers to configure connected Muxes correctly, according to PD
information retrieved from the Chrome OS EC.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
When EC does not support uptime command (EC_CMD_GET_UPTIME_INFO),
do not create the uptime sysfs entry point.
User space application will not probe the file needlessly.
The EC console log will not contain EC_CMD_GET_UPTIME_INFO anymore.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Pi-Hsun Shih <pihsun@chromium.org>:
Add support for controlling voltage regulator that is connected and
controlled by ChromeOS EC. Kernel controls these regulators through
newly added EC host commands.
Changes from v5:
* Move new host command to a separate patch.
* Use devm_regulator_register.
* Address review comments.
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Fix dt bindings file name.
* Remove check around CONFIG_OF in driver.
* Add new host commands to cros_ec_trace.
* Address review comments.
Changes from v2:
* Add 'depends on OF' to Kconfig.
* Add Kconfig description about compiling as module.
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Change license for dt binding according to checkpatch.pl.
* Address comments on code styles.
Pi-Hsun Shih (3):
dt-bindings: regulator: Add DT binding for cros-ec-regulator
platform/chrome: cros_ec: Add command for regulator control.
regulator: Add driver for cros-ec-regulator
.../regulator/google,cros-ec-regulator.yaml | 51 ++++
drivers/platform/chrome/cros_ec_trace.c | 5 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/cros-ec-regulator.c | 257 ++++++++++++++++++
.../linux/platform_data/cros_ec_commands.h | 82 ++++++
6 files changed, 406 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
create mode 100644 drivers/regulator/cros-ec-regulator.c
base-commit: b791d1bdf9212d944d749a5c7ff6febdba241771
--
2.27.0.290.gba653c62da-goog
|
|
Add host commands for voltage regulator control through ChromeOS EC.
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200612040526.192878-3-pihsun@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
