[GIT PULL] chrome-platform changes for v5.12
Hi Linus, The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.12 for you to fetch changes up to a59e12218c4f5498d5669a0ee0c725101ca89d52: platform/chrome: cros_ec_typec: Flush pending work (2021-02-11 13:18:46 -0800) chrome platform changes for 5.12 Lots of changes to the cros_ec_typec driver for 5.12. A portion of this this set of cros_ec_typec driver's changes (up to 8553a979fcd0 platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC) was merged through GregKH's USB tree in immutable branch tag-ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12 in order to satisfy cros_ec_typec driver and typec connector class subsystem dependencies of subsequent changes. Please see greg's usb-5.12-rc1. cros_ec_typec: * Registration of cable plug information * Support for SOP' plug registration and altmodes * Support for reporting number of altmodes supported by partners and plugs * Send mux configuration ack to EC via a new host command * Support mux control with no port partner present * Decouple cable removal from partner removal cros_ec misc: * Fix some event masking in cros_ec_proto. * Gwendal reworked cros_ec's top and bottom half for consistency in ishtp and rpmsg * Constify static attribute_group structs Evan Benn (2): platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT platform/chrome: cros_ec_proto: Add LID and BATTERY to default mask Gwendal Grignou (2): platform/chrome: cros_ec: Call interrupt bottom half in ISH or RPMSG mode platform/chrome: cros_ec: Call interrupt bottom half at probe time Pi-Hsun Shih (2): platform/chrome: cros_ec_commands: Add host command to keep AP off after EC reset. platform/chrome: cros_ec_sysfs: Add cold-ap-off to sysfs reboot. Prashant Malani (10): platform/chrome: cros_ec_typec: Make disc_done flag partner-only platform/chrome: cros_ec_typec: Factor out PD identity parsing platform/chrome: cros_ec_typec: Rename discovery struct platform/chrome: cros_ec_typec: Register cable platform/chrome: cros_ec_typec: Store cable plug type platform/chrome: cros_ec_typec: Set partner num_altmodes platform/chrome: cros_ec_typec: Register SOP' cable plug platform/chrome: cros_ec_typec: Register plug altmodes platform/chrome: cros_ec_typec: Decouple partner removal platform/chrome: cros_ec_typec: Flush pending work Rajmohan Mani (2): platform/chrome: cros_ec_typec: Skip port partner check in configure_mux() platform/chrome: cros_ec_types: Support disconnect events without partners Rikard Falkeborn (1): platform/chrome: Constify static attribute_group structs Utkarsh Patel (2): platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported() platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC drivers/platform/chrome/cros_ec.c | 33 ++- drivers/platform/chrome/cros_ec.h | 4 +- drivers/platform/chrome/cros_ec_ishtp.c| 6 +- drivers/platform/chrome/cros_ec_lightbar.c | 2 +- drivers/platform/chrome/cros_ec_proto.c| 12 +- drivers/platform/chrome/cros_ec_rpmsg.c| 6 +- drivers/platform/chrome/cros_ec_sysfs.c| 5 +- drivers/platform/chrome/cros_ec_typec.c| 278 - drivers/platform/chrome/cros_ec_vbc.c | 2 +- drivers/platform/chrome/wilco_ec/sysfs.c | 2 +- include/linux/platform_data/cros_ec_commands.h | 18 ++ 11 files changed, 289 insertions(+), 79 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] platform/chrome: cros_ec_typec: Flush pending work
On Thu, 11 Feb 2021 11:32:21 -0800, Prashant Malani wrote: > When a PD notifier event arrives, a new work event won't be enqueued if > the current one hasn't completed. This could lead to dropped events. > > So, flush any pending work before scheduling the new instance. Applied, thanks! [1/1] platform/chrome: cros_ec_typec: Flush pending work commit: a59e12218c4f5498d5669a0ee0c725101ca89d52 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH 0/2] Add support for Type-C mux events without port partners
Hi Rajmohan, On Fri, 5 Feb 2021 11:51:11 -0800, Rajmohan Mani wrote: > There are cases, where support for Type-C mux events is needed, that > does not have port partners. > Enabling communication to a retimer connected to an USB4 port, when > no devices are attached, is a case that requires support for handling > Type-C mux events without port partners. > > The following patches[1] are needed on top of the mainline kernel to be > able to verify these patches. > > [...] Applied, thanks! [1/2] platform/chrome: cros_ec_typec: Skip port partner check in configure_mux() commit: 38f56061c892c237ad4ee733cf3981a84f6b6aea [2/2] platform/chrome: cros_ec_types: Support disconnect events without partners commit: b4b06c97729547d03a8f49c6774c8bd69150ea4d Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[GIT PULL] Fix for cros_ec_typec for USB for v5.12 merge window
Hi Greg, I found a bug in the typec driver you pulled earlier this week and Prashant developed a fix. The following changes since commit 64eaa0fa66ac55965f793a8b65730299854e55cd: platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision (2021-02-02 19:42:52 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-ib-usb-typec-chrome-platform-cros-ec-typec-clear-pd-discovery-events-for-5.12 for you to fetch changes up to c8ec21c6d25c2a8895614ea38575dadb8570c2f9: platform/chrome: cros_ec_typec: Clear Type C disc events (2021-02-04 10:29:30 -0800) clear-pd-discovery-events This pair of patches fixes an issue where cros_ec_typec creates stale cable nodes on detach because of uncleared pd discovery status events. Prashant Malani (2): platform/chrome: cros_ec: Import Type C control command platform/chrome: cros_ec_typec: Clear Type C disc events drivers/platform/chrome/cros_ec_typec.c| 29 +++--- include/linux/platform_data/cros_ec_commands.h | 26 +++ 2 files changed, 52 insertions(+), 3 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2 1/2] platform/chrome: cros_ec: Import Type C control command
Hi Prashant, On Tue, 2 Feb 2021 18:15:37 -0800, Prashant Malani wrote: > This command is used to communicate with the Chrome Embedded Controller > (EC) regarding USB Type C events and state. > > These header updates are included in the latest Chrome OS EC headers [1] > > [1] > https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h Applied, thanks! [1/2] platform/chrome: cros_ec: Import Type C control command commit: b64afd949ee3a61e180813859b50aced26023c55 [2/2] platform/chrome: cros_ec_typec: Clear Type C disc events commit: c8ec21c6d25c2a8895614ea38575dadb8570c2f9 I rebased these changes so that it clears a merge conflict with changes in greg's usb-next branch. These two are in the chrome-platform repo as: https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/log/?h=cros_ec_typec-clear-pd-discovery-events-after-handled I will send a PR to Greg for these too. Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2 1/2] platform/chrome: cros_ec: Import Type C control command
Hi Prashant, On Tue, 2 Feb 2021 18:15:37 -0800, Prashant Malani wrote: > This command is used to communicate with the Chrome Embedded Controller > (EC) regarding USB Type C events and state. > > These header updates are included in the latest Chrome OS EC headers [1] > > [1] > https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h Applied, thanks! [1/2] platform/chrome: cros_ec: Import Type C control command commit: 3ec28d3673362076444e290bdb0d94ec6432dc09 [2/2] platform/chrome: cros_ec_typec: Clear Type C disc events commit: d521119c8b0d70b91971d632430ec1143e5d2e26 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] platform/chrome: cros_ec_typec: Decouple partner removal
Hi Prashant, On Tue, 2 Feb 2021 14:40:01 -0800, Prashant Malani wrote: > Currently, we return if there is no partner present when > !PD_CTRL_RESP_ENABLED_CONNECTED, without proceeding further. This ties > partner removal to cable removal, whereas the two should be independent. > > Update the check to remove a partner if one was registered, but continue > after that instead of returning. Applied to for-kernelci, thanks! [1/1] platform/chrome: cros_ec_typec: Decouple partner removal commit: d9f12f9e6c3695c32e681e9d266c4dc1c9016f66 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v5 2/8] usb: pd: Update VDO definitions
| ((usbss) & 0x7)) > + > +/* USB Highest Speed */ > +#define CABLE_USB2_ONLY0 > +#define CABLE_USB32_GEN1 1 > +#define CABLE_USB32_4_GEN2 2 > +#define CABLE_USB4_GEN33 > + > +#define VDO_PCABLE(hw, fw, ver, conn, lat, term, vbm, cur, spd) > \ > + (((hw) & 0xf) << 28 | ((fw) & 0xf) << 24 | ((ver) & 0x7) << 21 > \ > +| ((conn) & 0x3) << 18 | ((lat) & 0xf) << 13 | ((term) & 0x3) << 11 > \ > +| ((vbm) & 0x3) << 9 | ((cur) & 0x3) << 5 | ((spd) & 0x7)) > +#define VDO_ACABLE1(hw, fw, ver, conn, lat, term, vbm, sbu, sbut, cur, vbt, > sopp, spd) \ > + (((hw) & 0xf) << 28 | ((fw) & 0xf) << 24 | ((ver) & 0x7) << 21 > \ > +| ((conn) & 0x3) << 18 | ((lat) & 0xf) << 13 | ((term) & 0x3) << 11 > \ > +| ((vbm) & 0x3) << 9 | (sbu) << 8 | (sbut) << 7 | ((cur) & 0x3) << 5 > \ > +| (vbt) << 4 | (sopp) << 3 | ((spd) & 0x7)) > + > #define VDO_TYPEC_CABLE_TYPE(vdo) (((vdo) >> 18) & 0x3) > > /* > - * AMA VDO > + * Active Cable VDO 2 > * - > - * <31:28> :: Cable HW version > - * <27:24> :: Cable FW version > - * <23:12> :: Reserved, Shall be set to zero > - * <11>:: SSTX1 Directionality support (0b == fixed, 1b == cfgable) > - * <10>:: SSTX2 Directionality support > - * <9> :: SSRX1 Directionality support > - * <8> :: SSRX2 Directionality support > - * <7:5> :: Vconn power > - * <4> :: Vconn power required > - * <3> :: Vbus power required > - * <2:0> :: USB SS Signaling support > + * <31:24> :: Maximum operating temperature > + * <23:16> :: Shutdown temperature > + * <15>:: Reserved, Shall be set to zero > + * <14:12> :: U3/CLd power > + * <11>:: U3 to U0 transition mode (0b == direct, 1b == through U3S) > + * <10>:: Physical connection (0b == copper, 1b == optical) > + * <9> :: Active element (0b == redriver, 1b == retimer) > + * <8> :: USB4 supported (0b == yes, 1b == no) > + * <7:6> :: USB2 hub hops consumed > + * <5> :: USB2 supported (0b == yes, 1b == no) > + * <4> :: USB3.2 supported (0b == yes, 1b == no) > + * <3> :: USB lanes supported (0b == one lane, 1b == two lanes) > + * <2> :: Optically isolated active cable (0b == no, 1b == yes) > + * <1> :: Reserved, Shall be set to zero > + * <0> :: USB gen (0b == gen1, 1b == gen2+) > */ > -#define VDO_AMA(hw, fw, tx1d, tx2d, rx1d, rx2d, vcpwr, vcr, vbr, usbss) \ > - (((hw) & 0x7) << 28 | ((fw) & 0x7) << 24\ > -| (tx1d) << 11 | (tx2d) << 10 | (rx1d) << 9 | (rx2d) << 8 \ > -| ((vcpwr) & 0x7) << 5 | (vcr) << 4 | (vbr) << 3 \ > -| ((usbss) & 0x7)) > - > -#define PD_VDO_AMA_VCONN_REQ(vdo) (((vdo) >> 4) & 1) > -#define PD_VDO_AMA_VBUS_REQ(vdo) (((vdo) >> 3) & 1) > +/* U3/CLd Power*/ > +#define ACAB2_U3_CLD_10MW_PLUS 0 > +#define ACAB2_U3_CLD_10MW 1 > +#define ACAB2_U3_CLD_5MW 2 > +#define ACAB2_U3_CLD_1MW 3 > +#define ACAB2_U3_CLD_500UW 4 > +#define ACAB2_U3_CLD_200UW 5 > +#define ACAB2_U3_CLD_50UW 6 > + > +/* Other Active Cable VDO 2 Fields */ > +#define ACAB2_U3U0_DIRECT 0 > +#define ACAB2_U3U0_U3S 1 > +#define ACAB2_PHY_COPPER 0 > +#define ACAB2_PHY_OPTICAL 1 > +#define ACAB2_REDRIVER 0 > +#define ACAB2_RETIMER 1 > +#define ACAB2_USB4_SUPP0 > +#define ACAB2_USB4_NOT_SUPP1 > +#define ACAB2_USB2_SUPP0 > +#define ACAB2_USB2_NOT_SUPP1 > +#define ACAB2_USB32_SUPP 0 > +#define ACAB2_USB32_NOT_SUPP 1 > +#define ACAB2_LANES_ONE0 > +#define ACAB2_LANES_TWO1 > +#define ACAB2_OPT_ISO_NO 0 > +#define ACAB2_OPT_ISO_YES 1 > +#define ACAB2_GEN_10 > +#define ACAB2_GEN_2_PLUS 1 > + > +#define VDO_ACABLE2(mtemp, stemp, u3p, trans, phy, ele, u4, hops, u2, u32, > lane, iso, gen) \ > + (((mtemp) & 0xff) << 24 | ((stemp) & 0xff) << 16 | ((u3p) & 0x7) << > 12 \ > +| (trans) << 11 | (phy) << 10 | (ele) << 9 | (u4) << 8 > \ > +| ((hops) & 0x3) << 6 | (u2) << 5 | (u32) << 4 | (lane) << 3 > \ > +| (iso) << 2 | (gen)) > > -#define AMA_VCONN_PWR_1W 0 > -#define AMA_VCONN_PWR_1W5 1 > -#define AMA_VCONN_PWR_2W 2 > -#define AMA_VCONN_PWR_3W 3 > -#define AMA_VCONN_PWR_4W 4 > -#define AMA_VCONN_PWR_5W 5 > -#define AMA_VCONN_PWR_6W 6 > -#define AMA_USBSS_U2_ONLY 0 > -#define AMA_USBSS_U31_GEN1 1 > -#define AMA_USBSS_U31_GEN2 2 > -#define AMA_USBSS_BBONLY 3 > +/* > + * VPD VDO > + * - > + * <31:28> :: HW version > + * <27:24> :: FW version > + * <23:21> :: VDO version > + * <20:17> :: Reserved, Shall be set to zero > + * <16:15> :: Maximum Vbus voltage (00b == 20V, 01b == 30V, 10b == 40V, 11b > == 50V) > + * <14>:: Charge through current support (0b == 3A, 1b == 5A) > + * <13>:: Reserved, Shall be set to zero > + * <12:7> :: Vbus impedance > + * <6:1> :: Ground impedance > + * <0> :: Charge through support (0b == no, 1b == yes) > + */ > +#define VPD_VDO_VER1_0 0 > +#define VPD_MAX_VBUS_20V 0 > +#define VPD_MAX_VBUS_30V 1 > +#define VPD_MAX_VBUS_40V 2 > +#define VPD_MAX_VBUS_50V 3 > +#define VPDCT_CURR_3A 0 > +#define VPDCT_CURR_5A 1 > +#define VPDCT_NOT_SUPP 0 > +#define VPDCT_SUPP 1 > + > +#define VDO_VPD(hw, fw, ver, vbm, curr, vbi, gi, ct) \ > + (((hw) & 0xf) << 28 | ((fw) & 0xf) << 24 | ((ver) & 0x7) << 21 \ > +| ((vbm) & 0x3) << 15 | (curr) << 14 | ((vbi) & 0x3f) << 7 \ > +| ((gi) & 0x3f) << 1 | (ct)) > > /* > * SVDM Discover SVIDs request -> response > -- > 2.30.0.365.g02bc693789-goog > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org
Re: linux-next: build warning after merge of the usb tree
Hi,
On Wed, Feb 03, 2021 at 04:13:00PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the usb tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/usb/typec/class.c: In function 'typec_partner_set_pd_revision':
> drivers/usb/typec/class.c:763:6: warning: unused variable 'ret'
> [-Wunused-variable]
> 763 | int ret;
> | ^~~
>
> Introduced by commit
>
> 29b01295a829 ("usb: typec: Add typec_partner_set_pd_revision")
>
Will be fixed by
https://lore.kernel.org/r/20210202095512.761214-1-kyle...@google.com,
already in Greg's usb-testing.
Thanks Kyle for the quick fix yesterday.
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2] platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision
On Tue, Feb 02, 2021 at 07:30:06PM +0100, Greg KH wrote:
> On Tue, Feb 02, 2021 at 09:52:13AM -0800, Benson Leung wrote:
> > Hi Greg,
> >
> > On Tue, Feb 2, 2021 at 9:02 AM Greg KH wrote:
> > >
> > > On Tue, Feb 02, 2021 at 08:45:31AM -0800, Benson Leung wrote:
> > > > typec_partner_set_pd_revision returns void now.
> > > >
> > > > Fixes: cefc011f8daf ("platform/chrome: cros_ec_typec: Set Partner PD
> > > > revision from status")
> > > > Signed-off-by: Benson Leung
> > > > ---
> > > > drivers/platform/chrome/cros_ec_typec.c | 6 +-
> > > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > What changed from "v1"?
> > >
> >
> > Just the "Fixes" line in the commit message.
>
> That should always go below the --- line, remember, some of us deal with
> hundreds of patches a day :)
>
> I'll go take this...
Thanks so much, Greg!
Benson
>
> thanks,
>
> greg k-h
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2] platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision
Hi Greg,
On Tue, Feb 2, 2021 at 9:02 AM Greg KH wrote:
>
> On Tue, Feb 02, 2021 at 08:45:31AM -0800, Benson Leung wrote:
> > typec_partner_set_pd_revision returns void now.
> >
> > Fixes: cefc011f8daf ("platform/chrome: cros_ec_typec: Set Partner PD
> > revision from status")
> > Signed-off-by: Benson Leung
> > ---
> > drivers/platform/chrome/cros_ec_typec.c | 6 +-
> > 1 file changed, 1 insertion(+), 5 deletions(-)
>
> What changed from "v1"?
>
Just the "Fixes" line in the commit message.
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
Re: [PATCH] platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision
On Tue, Feb 02, 2021 at 05:37:36PM +0100, Greg KH wrote: > On Tue, Feb 02, 2021 at 08:32:48AM -0800, Benson Leung wrote: > > typec_partner_set_pd_revision returns void now. > > > > Fixes: cefc011f8daf platform/chrome: cros_ec_typec: Set Partner PD revision > > from status > > Can you please use the documented format for the Fixes: tag (and for the > use of any git id in the kernel changelog)? D'oh. Thanks. I set up my pretty=fuller now. Benson > > If anyone were to commit this change, you would get a nasty-gram email > from linux-next :) > > thanks, > > greg k-h -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH v2] platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision
typec_partner_set_pd_revision returns void now.
Fixes: cefc011f8daf ("platform/chrome: cros_ec_typec: Set Partner PD revision
from status")
Signed-off-by: Benson Leung
---
drivers/platform/chrome/cros_ec_typec.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index a7778258d0a0..7b93dfd02999 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -842,11 +842,7 @@ static int cros_typec_handle_sop_disc(struct
cros_typec_data *typec, int port_nu
goto disc_exit;
}
- ret = typec_partner_set_pd_revision(port->partner, pd_revision);
- if (ret < 0) {
- dev_err(typec->dev, "Failed to update partner PD revision,
port: %d\n", port_num);
- goto disc_exit;
- }
+ typec_partner_set_pd_revision(port->partner, pd_revision);
memset(sop_disc, 0, EC_PROTO2_MAX_RESPONSE_SIZE);
ret = cros_typec_ec_command(typec, 0, EC_CMD_TYPEC_DISCOVERY, ,
sizeof(req),
--
2.30.0.365.g02bc693789-goog
Re: [PATCH] platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision
Hi Greg,
On Tue, Feb 02, 2021 at 08:32:48AM -0800, Benson Leung wrote:
> typec_partner_set_pd_revision returns void now.
>
> Fixes: cefc011f8daf platform/chrome: cros_ec_typec: Set Partner PD revision
> from status
> Signed-off-by: Benson Leung
This one needs to be taken too after Kyle's fix earlier this morning.
Thanks,
Benson
> ---
> drivers/platform/chrome/cros_ec_typec.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_ec_typec.c
> index a7778258d0a0..7b93dfd02999 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -842,11 +842,7 @@ static int cros_typec_handle_sop_disc(struct
> cros_typec_data *typec, int port_nu
> goto disc_exit;
> }
>
> - ret = typec_partner_set_pd_revision(port->partner, pd_revision);
> - if (ret < 0) {
> - dev_err(typec->dev, "Failed to update partner PD revision,
> port: %d\n", port_num);
> - goto disc_exit;
> - }
> + typec_partner_set_pd_revision(port->partner, pd_revision);
>
> memset(sop_disc, 0, EC_PROTO2_MAX_RESPONSE_SIZE);
> ret = cros_typec_ec_command(typec, 0, EC_CMD_TYPEC_DISCOVERY, ,
> sizeof(req),
> --
> 2.30.0.365.g02bc693789-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[PATCH] platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revision
typec_partner_set_pd_revision returns void now.
Fixes: cefc011f8daf platform/chrome: cros_ec_typec: Set Partner PD revision
from status
Signed-off-by: Benson Leung
---
drivers/platform/chrome/cros_ec_typec.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index a7778258d0a0..7b93dfd02999 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -842,11 +842,7 @@ static int cros_typec_handle_sop_disc(struct
cros_typec_data *typec, int port_nu
goto disc_exit;
}
- ret = typec_partner_set_pd_revision(port->partner, pd_revision);
- if (ret < 0) {
- dev_err(typec->dev, "Failed to update partner PD revision,
port: %d\n", port_num);
- goto disc_exit;
- }
+ typec_partner_set_pd_revision(port->partner, pd_revision);
memset(sop_disc, 0, EC_PROTO2_MAX_RESPONSE_SIZE);
ret = cros_typec_ec_command(typec, 0, EC_CMD_TYPEC_DISCOVERY, ,
sizeof(req),
--
2.30.0.365.g02bc693789-goog
Re: [PATCH] usb: typec: Return void in typec_partner_set_pd_revision
On Tue, Feb 02, 2021 at 04:09:13PM +0100, Greg KH wrote:
> On Tue, Feb 02, 2021 at 07:02:52AM -0800, Benson Leung wrote:
> > Hi Kyle,
> >
> > On Tue, Feb 02, 2021 at 05:55:12PM +0800, Kyle Tso wrote:
> > > typec_partner_set_pd_revision doesn't need any return value.
> > >
> > > Fixes: 29b01295a829 ("usb: typec: Add typec_partner_set_pd_revision")
> > > Signed-off-by: Kyle Tso
> >
> > Review tags for
>
> What does that mean?
>
> Please respond with a line that I can use...
>
Reviewed-by: Benson Leung
Sorry.
Benson
> thanks,
>
> greg k-h
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] usb: typec: Return void in typec_partner_set_pd_revision
Hi Kyle,
On Tue, Feb 02, 2021 at 05:55:12PM +0800, Kyle Tso wrote:
> typec_partner_set_pd_revision doesn't need any return value.
>
> Fixes: 29b01295a829 ("usb: typec: Add typec_partner_set_pd_revision")
> Signed-off-by: Kyle Tso
Review tags for
Thanks for the quick fix!
Thanks,
Benson
> ---
> drivers/usb/typec/class.c | 10 ++
> include/linux/usb/typec.h | 2 +-
> 2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index b6ceab3dc16b..a7d1bc83c2d4 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -755,15 +755,11 @@ EXPORT_SYMBOL_GPL(typec_partner_set_identity);
> *
> * This routine is used to report that the PD revision of the port partner
> has
> * become available.
> - *
> - * Returns 0 on success or negative error number on failure.
> */
> -int typec_partner_set_pd_revision(struct typec_partner *partner, u16
> pd_revision)
> +void typec_partner_set_pd_revision(struct typec_partner *partner, u16
> pd_revision)
> {
> - int ret;
> -
> if (partner->pd_revision == pd_revision)
> - return 0;
> + return;
>
> partner->pd_revision = pd_revision;
> sysfs_notify(>dev.kobj, NULL, "usb_power_delivery_revision");
> @@ -773,8 +769,6 @@ int typec_partner_set_pd_revision(struct typec_partner
> *partner, u16 pd_revision
>"supports_usb_power_delivery");
> }
> kobject_uevent(>dev.kobj, KOBJ_CHANGE);
> -
> - return 0;
> }
> EXPORT_SYMBOL_GPL(typec_partner_set_pd_revision);
>
> diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
> index 4946eca742d5..a94df82ab62f 100644
> --- a/include/linux/usb/typec.h
> +++ b/include/linux/usb/typec.h
> @@ -126,7 +126,7 @@ struct typec_altmode_desc {
> enum typec_port_dataroles;
> };
>
> -int typec_partner_set_pd_revision(struct typec_partner *partner, u16
> pd_revision);
> +void typec_partner_set_pd_revision(struct typec_partner *partner, u16
> pd_revision);
> int typec_partner_set_num_altmodes(struct typec_partner *partner, int
> num_altmodes);
> struct typec_altmode
> *typec_partner_register_altmode(struct typec_partner *partner,
> --
> 2.30.0.365.g02bc693789-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] Immutable Branch between platform/chrome and USB for v5.12 merge window
Hi Greg, The following changes since commit 29b01295a829fba7399ee84afff4e64660e49f04: usb: typec: Add typec_partner_set_pd_revision (2021-02-01 15:31:34 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12 for you to fetch changes up to 0371616d8bef6926e9aa05757f35b901268d3724: platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected (2021-02-01 23:49:54 -0800) cros-ec-typec changes for usb for v5.12 Chrome OS EC Type-C driver features implemented this round: * Registration of cable plug information * Support for SOP' plug registration and altmodes * Support for reporting number of altmodes supported by partners and plugs * Send mux configuration ack to EC via a new host command * Reporting SOP' and Partner PD revisions Benson Leung (4): Merge remote-tracking branch 'origin/cros-ec-typec-for-5.12' into ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12 platform/chrome: cros_ec_typec: Report SOP' PD revision from status platform/chrome: cros_ec_typec: Set Partner PD revision from status platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected Prashant Malani (8): platform/chrome: cros_ec_typec: Make disc_done flag partner-only platform/chrome: cros_ec_typec: Factor out PD identity parsing platform/chrome: cros_ec_typec: Rename discovery struct platform/chrome: cros_ec_typec: Register cable platform/chrome: cros_ec_typec: Store cable plug type platform/chrome: cros_ec_typec: Set partner num_altmodes platform/chrome: cros_ec_typec: Register SOP' cable plug platform/chrome: cros_ec_typec: Register plug altmodes Utkarsh Patel (2): platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported() platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC drivers/platform/chrome/cros_ec_typec.c| 269 + include/linux/platform_data/cros_ec_commands.h | 17 ++ 2 files changed, 243 insertions(+), 43 deletions(-) Thanks so much! Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH 0/6] usb: typec: and platform/chrome: Add PD revision numbers
Hi Greg, On Mon, Feb 01, 2021 at 03:32:47PM +0100, Greg KH wrote: > On Thu, Jan 28, 2021 at 10:14:00PM -0800, Benson Leung wrote: > > USB Power Delivery has a 3 entity handshake (port, cable, partner), and as > > of USB PD R3.0, each entity may independently support either Revision 2 or > > Revision 3 signaling and protocol. In order for userspace and the kernel > > to properly process the data objects received from a particular SOP*, we > > must know to which revision of the spec each conforms. > > > > This series adds individual version numbers for the partner and the cable, > > and exposes them in the appropriate sysfs in /sys/class/typec. > > > > I provide as a first implementation of this, platform/chrome's cros_ec_typec > > driver, whose underlying status messages convey the SOP and SOP' revisions > > already. > > I've taken the first 3 patches in my tree now, but the last 3 (for the > chrome_ec_typec.c driver), they do not apply at all. > Ah, that's because we have some other changes for the cros_ec_typec.c driver already in platform/chrome for our 5.12 branch. For 5.12, the changes for cros_ec_typec driver is pretty well contained, although there is some dependence on typec subsystem changes now. If I send you a pull request containing all of the changes for this driver we have already merged, plus these last three that depend on both of our trees would you merge it through usb for 5.12? Thanks, Benson > thanks, > > greg k-h -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH 4/6] platform/chrome: cros_ec_typec: Report SOP' PD revision from status
cros_typec_handle_sop_prime_disc now takes the PD revision provided
by the EC_CMD_TYPEC_STATUS command response for the SOP'.
Attach the properly formatted pd_revision to the cable desc before
registering the cable.
Signed-off-by: Benson Leung
---
drivers/platform/chrome/cros_ec_typec.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index e724a5eaef1c..30600e9454e1 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -748,7 +748,7 @@ static void cros_typec_parse_pd_identity(struct
usb_pd_identity *id,
id->vdo[i - 3] = disc->discovery_vdo[i];
}
-static int cros_typec_handle_sop_prime_disc(struct cros_typec_data *typec, int
port_num)
+static int cros_typec_handle_sop_prime_disc(struct cros_typec_data *typec, int
port_num, u16 pd_revision)
{
struct cros_typec_port *port = typec->ports[port_num];
struct ec_response_typec_discovery *disc = port->disc_data;
@@ -794,6 +794,7 @@ static int cros_typec_handle_sop_prime_disc(struct
cros_typec_data *typec, int p
}
c_desc.identity = >c_identity;
+ c_desc.pd_revision = pd_revision;
port->cable = typec_register_cable(port->port, _desc);
if (IS_ERR(port->cable)) {
@@ -893,7 +894,11 @@ static void cros_typec_handle_status(struct
cros_typec_data *typec, int port_num
if (resp.events & PD_STATUS_EVENT_SOP_PRIME_DISC_DONE &&
!typec->ports[port_num]->sop_prime_disc_done) {
- ret = cros_typec_handle_sop_prime_disc(typec, port_num);
+ u16 sop_prime_revision;
+
+ /* Convert BCD to the format preferred by the TypeC framework */
+ sop_prime_revision = (le16_to_cpu(resp.sop_prime_revision) &
0xff00) >> 4;
+ ret = cros_typec_handle_sop_prime_disc(typec, port_num,
sop_prime_revision);
if (ret < 0)
dev_err(typec->dev, "Couldn't parse SOP' Disc data,
port: %d\n", port_num);
else
--
2.30.0.365.g02bc693789-goog
[PATCH 1/6] usb: typec: Standardize PD Revision format with Type-C Revision
The Type-C Revision was in a specific BCD format "0120H" for 1.2.
USB PD revision numbers follow a similar pattern with "0300H" for 3.0.
Standardizes the sysfs format for usb_power_delivery_revision
to align with the BCD format used for usb_typec_revision.
Example values:
- "2.0": USB Power Delivery Release 2.0
- "3.0": USB Power Delivery Release 3.0
- "3.1": USB Power Delivery Release 3.1
Signed-off-by: Benson Leung
---
Documentation/ABI/testing/sysfs-class-typec | 7 ++-
drivers/usb/typec/class.c | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index 8eab41e79ce6..b61480535fdc 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -105,7 +105,12 @@ Date: April 2017
Contact: Heikki Krogerus
Description:
Revision number of the supported USB Power Delivery
- specification, or 0 when USB Power Delivery is not supported.
+ specification, or 0.0 when USB Power Delivery is not supported.
+
+ Example values:
+ - "2.0": USB Power Delivery Release 2.0
+ - "3.0": USB Power Delivery Release 3.0
+ - "3.1": USB Power Delivery Release 3.1
What: /sys/class/typec//usb_typec_revision
Date: April 2017
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 8f77669f9cf4..4f60ee7ba76a 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -1500,8 +1500,9 @@ static ssize_t usb_power_delivery_revision_show(struct
device *dev,
char *buf)
{
struct typec_port *p = to_typec_port(dev);
+ u16 rev = p->cap->pd_revision;
- return sprintf(buf, "%d\n", (p->cap->pd_revision >> 8) & 0xff);
+ return sprintf(buf, "%d.%d\n", (rev >> 8) & 0xff, (rev >> 4) & 0xf);
}
static DEVICE_ATTR_RO(usb_power_delivery_revision);
--
2.30.0.365.g02bc693789-goog
[PATCH 6/6] platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected
When SOP Discovery is done, set the opmode to PD if status indicates SOP is connected. SOP connected indicates a PD contract is in place, and is a solid indication we have transitioned to PD power negotiation, either as source or sink. Signed-off-by: Benson Leung --- drivers/platform/chrome/cros_ec_typec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c index 6bc6fafd54a4..a7778258d0a0 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -900,6 +900,9 @@ static void cros_typec_handle_status(struct cros_typec_data *typec, int port_num dev_err(typec->dev, "Couldn't parse SOP Disc data, port: %d\n", port_num); else typec->ports[port_num]->sop_disc_done = true; + + if (resp.sop_connected) + typec_set_pwr_opmode(typec->ports[port_num]->port, TYPEC_PWR_MODE_PD); } if (resp.events & PD_STATUS_EVENT_SOP_PRIME_DISC_DONE && -- 2.30.0.365.g02bc693789-goog
[PATCH 2/6] usb: typec: Provide PD Specification Revision for cable and partner
The USB Power Delivery specification Section 6.2.1.1.5 outlines
revision backward compatibility requirements starting from Revision 3.0.
The Port, the Cable Plug, and the Port Partner may support either
revision 2 or revision 3 independently, and communication between ports,
partners, and cables of different revisions are allowed under rules
that the parties agree to communicate between each other using the
lowest common operating revision.
This may mean that Port-to-Partner operating revision comms may be
different than Port-to-CablePlug operating revision comms. For example,
it is possible for a R3.0 port to communicate with a R3.0 partner
using R3.0 messages, while the R3.0 port (in the same session) must
communicate with the R2.0 cable using R2.0 messages only.
Introduce individual revision number properties for cable
and port partner so that the port can track them independently.
Signed-off-by: Benson Leung
---
Documentation/ABI/testing/sysfs-class-typec | 13 +
drivers/usb/typec/class.c | 30 ++---
include/linux/usb/typec.h | 10 +++
3 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index b61480535fdc..40122d915ae1 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -112,6 +112,19 @@ Description:
- "3.0": USB Power Delivery Release 3.0
- "3.1": USB Power Delivery Release 3.1
+What:
/sys/class/typec/-{partner|cable}/usb_power_delivery_revision
+Date: January 2021
+Contact: Benson Leung
+Description:
+ Revision number of the supported USB Power Delivery
+ specification of the port partner or cable, or 0.0 when USB
+ Power Delivery is not supported.
+
+ Example values:
+ - "2.0": USB Power Delivery Release 2.0
+ - "3.0": USB Power Delivery Release 3.0
+ - "3.1": USB Power Delivery Release 3.1
+
What: /sys/class/typec//usb_typec_revision
Date: April 2017
Contact: Heikki Krogerus
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 4f60ee7ba76a..b5241f4756c2 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -27,6 +27,7 @@ struct typec_cable {
enum typec_plug_typetype;
struct usb_pd_identity *identity;
unsigned intactive:1;
+ u16 pd_revision; /* 0300H = "3.0" */
};
struct typec_partner {
@@ -36,6 +37,7 @@ struct typec_partner {
enum typec_accessoryaccessory;
struct ida mode_ids;
int num_altmodes;
+ u16 pd_revision; /* 0300H = "3.0" */
};
struct typec_port {
@@ -264,6 +266,11 @@ type_show(struct device *dev, struct device_attribute
*attr, char *buf)
}
static DEVICE_ATTR_RO(type);
+static ssize_t usb_power_delivery_revision_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static DEVICE_ATTR_RO(usb_power_delivery_revision);
+
/* - */
/* Alternate Modes */
@@ -680,6 +687,7 @@ static struct attribute *typec_partner_attrs[] = {
_attr_supports_usb_power_delivery.attr,
_attr_number_of_alternate_modes.attr,
_attr_type.attr,
+ _attr_usb_power_delivery_revision.attr,
NULL
};
@@ -815,6 +823,7 @@ struct typec_partner *typec_register_partner(struct
typec_port *port,
partner->usb_pd = desc->usb_pd;
partner->accessory = desc->accessory;
partner->num_altmodes = -1;
+ partner->pd_revision = desc->pd_revision;
if (desc->identity) {
/*
@@ -1028,6 +1037,7 @@ static DEVICE_ATTR_RO(plug_type);
static struct attribute *typec_cable_attrs[] = {
_attr_type.attr,
_attr_plug_type.attr,
+ _attr_usb_power_delivery_revision.attr,
NULL
};
ATTRIBUTE_GROUPS(typec_cable);
@@ -1130,6 +1140,7 @@ struct typec_cable *typec_register_cable(struct
typec_port *port,
cable->type = desc->type;
cable->active = desc->active;
+ cable->pd_revision = desc->pd_revision;
if (desc->identity) {
/*
@@ -1499,12 +1510,23 @@ static ssize_t usb_power_delivery_revision_show(struct
device *dev,
struct device_attribute *attr,
char *buf)
{
- struct typec_port *p = to_typec_port(dev);
- u16 rev = p-&
[PATCH 5/6] platform/chrome: cros_ec_typec: Set Partner PD revision from status
Status provides sop_revision. Process it, and set it using the new
setter in the typec class.
Signed-off-by: Benson Leung
---
drivers/platform/chrome/cros_ec_typec.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 30600e9454e1..6bc6fafd54a4 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -824,7 +824,7 @@ static int cros_typec_handle_sop_prime_disc(struct
cros_typec_data *typec, int p
return ret;
}
-static int cros_typec_handle_sop_disc(struct cros_typec_data *typec, int
port_num)
+static int cros_typec_handle_sop_disc(struct cros_typec_data *typec, int
port_num, u16 pd_revision)
{
struct cros_typec_port *port = typec->ports[port_num];
struct ec_response_typec_discovery *sop_disc = port->disc_data;
@@ -842,6 +842,12 @@ static int cros_typec_handle_sop_disc(struct
cros_typec_data *typec, int port_nu
goto disc_exit;
}
+ ret = typec_partner_set_pd_revision(port->partner, pd_revision);
+ if (ret < 0) {
+ dev_err(typec->dev, "Failed to update partner PD revision,
port: %d\n", port_num);
+ goto disc_exit;
+ }
+
memset(sop_disc, 0, EC_PROTO2_MAX_RESPONSE_SIZE);
ret = cros_typec_ec_command(typec, 0, EC_CMD_TYPEC_DISCOVERY, ,
sizeof(req),
sop_disc, EC_PROTO2_MAX_RESPONSE_SIZE);
@@ -885,7 +891,11 @@ static void cros_typec_handle_status(struct
cros_typec_data *typec, int port_num
/* Handle any events appropriately. */
if (resp.events & PD_STATUS_EVENT_SOP_DISC_DONE &&
!typec->ports[port_num]->sop_disc_done) {
- ret = cros_typec_handle_sop_disc(typec, port_num);
+ u16 sop_revision;
+
+ /* Convert BCD to the format preferred by the TypeC framework */
+ sop_revision = (le16_to_cpu(resp.sop_revision) & 0xff00) >> 4;
+ ret = cros_typec_handle_sop_disc(typec, port_num, sop_revision);
if (ret < 0)
dev_err(typec->dev, "Couldn't parse SOP Disc data,
port: %d\n", port_num);
else
--
2.30.0.365.g02bc693789-goog
[PATCH 3/6] usb: typec: Add typec_partner_set_pd_revision
The partner's PD revision may be resolved later than the port partner
registration since the port partner creation may take place once
Type-C detects the port has changed state, but before PD communication is
completed.
Add a setter so that the partner's PD revision can be attached to it once
it becomes available.
If the revision is set to a valid version (not 0), the setter will also
refresh the partner's usb_pd flag and notify on "supports_usb_power_delivery"
sysfs property as well.
Signed-off-by: Benson Leung
---
drivers/usb/typec/class.c | 30 ++
include/linux/usb/typec.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index b5241f4756c2..b6ceab3dc16b 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -748,6 +748,36 @@ int typec_partner_set_identity(struct typec_partner
*partner)
}
EXPORT_SYMBOL_GPL(typec_partner_set_identity);
+/**
+ * typec_partner_set_pd_revision - Set the PD revision supported by the partner
+ * @partner: The partner to be updated.
+ * @pd_revision: USB Power Delivery Specification Revision supported by
partner
+ *
+ * This routine is used to report that the PD revision of the port partner has
+ * become available.
+ *
+ * Returns 0 on success or negative error number on failure.
+ */
+int typec_partner_set_pd_revision(struct typec_partner *partner, u16
pd_revision)
+{
+ int ret;
+
+ if (partner->pd_revision == pd_revision)
+ return 0;
+
+ partner->pd_revision = pd_revision;
+ sysfs_notify(>dev.kobj, NULL, "usb_power_delivery_revision");
+ if (pd_revision != 0 && !partner->usb_pd) {
+ partner->usb_pd = 1;
+ sysfs_notify(>dev.kobj, NULL,
+"supports_usb_power_delivery");
+ }
+ kobject_uevent(>dev.kobj, KOBJ_CHANGE);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(typec_partner_set_pd_revision);
+
/**
* typec_partner_set_num_altmodes - Set the number of available partner
altmodes
* @partner: The partner to be updated.
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 42c6b7c07a99..4946eca742d5 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -126,6 +126,7 @@ struct typec_altmode_desc {
enum typec_port_dataroles;
};
+int typec_partner_set_pd_revision(struct typec_partner *partner, u16
pd_revision);
int typec_partner_set_num_altmodes(struct typec_partner *partner, int
num_altmodes);
struct typec_altmode
*typec_partner_register_altmode(struct typec_partner *partner,
--
2.30.0.365.g02bc693789-goog
[PATCH 0/6] usb: typec: and platform/chrome: Add PD revision numbers
USB Power Delivery has a 3 entity handshake (port, cable, partner), and as of USB PD R3.0, each entity may independently support either Revision 2 or Revision 3 signaling and protocol. In order for userspace and the kernel to properly process the data objects received from a particular SOP*, we must know to which revision of the spec each conforms. This series adds individual version numbers for the partner and the cable, and exposes them in the appropriate sysfs in /sys/class/typec. I provide as a first implementation of this, platform/chrome's cros_ec_typec driver, whose underlying status messages convey the SOP and SOP' revisions already. Thanks, Benson Benson Leung (6): usb: typec: Standardize PD Revision format with Type-C Revision usb: typec: Provide PD Specification Revision for cable and partner usb: typec: Add typec_partner_set_pd_revision platform/chrome: cros_ec_typec: Report SOP' PD revision from status platform/chrome: cros_ec_typec: Set Partner PD revision from status platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected Documentation/ABI/testing/sysfs-class-typec | 20 ++- drivers/platform/chrome/cros_ec_typec.c | 26 +++-- drivers/usb/typec/class.c | 59 +++-- include/linux/usb/typec.h | 11 4 files changed, 108 insertions(+), 8 deletions(-) -- 2.30.0.365.g02bc693789-goog
Re: [PATCH v2 1/2] power: supply: PCHG: Peripheral device charger
>num_registered_psy++] = port;
> + }
> +
> + if (!charger->num_registered_psy)
> + return -ENODEV;
> +
> + nb = >notifier;
> + nb->notifier_call = cros_ec_notify;
> + ret = blocking_notifier_chain_register(_dev->ec_dev->event_notifier,
> +nb);
> + if (ret < 0)
> + dev_err(dev, "Failed to register notifier (err:%d)\n", ret);
> +
> + return 0;
> +}
> +
> +static struct platform_driver cros_pchg_driver = {
> + .driver = {
> + .name = DRV_NAME,
> + },
> + .probe = cros_pchg_probe
> +};
> +
> +module_platform_driver(cros_pchg_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ChromeOS EC peripheral device charger");
> +MODULE_ALIAS("platform:" DRV_NAME);
> diff --git a/include/linux/platform_data/cros_ec_commands.h
> b/include/linux/platform_data/cros_ec_commands.h
> index 58495127dfa656..c0f0a032c8beb6 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -4225,6 +4225,7 @@ enum ec_device_event {
> EC_DEVICE_EVENT_TRACKPAD,
> EC_DEVICE_EVENT_DSP,
> EC_DEVICE_EVENT_WIFI,
> + EC_DEVICE_EVENT_WLC,
> };
>
> enum ec_device_event_param {
> @@ -5456,6 +5457,53 @@ struct ec_response_rollback_info {
> /* Issue AP reset */
> #define EC_CMD_AP_RESET 0x0125
>
> +/**
> + * Get the number of peripheral charge ports
> + */
> +#define EC_CMD_PCHG_COUNT 0x0134
> +
> +#define EC_PCHG_MAX_PORTS 8
> +
> +struct ec_response_pchg_count {
> + uint8_t port_count;
> +} __ec_align1;
> +
> +/**
> + * Get the status of a peripheral charge port
> + */
> +#define EC_CMD_PCHG 0x0135
> +
> +struct ec_params_pchg {
> + uint8_t port;
> +} __ec_align1;
> +
> +struct ec_response_pchg {
> + uint32_t error; /* enum pchg_error */
> + uint8_t state; /* enum pchg_state state */
> + uint8_t battery_percentage;
> +} __ec_align2;
> +
> +enum pchg_state {
> + /* Charger is reset and not initialized. */
> + PCHG_STATE_RESET = 0,
> + /* Charger is initialized or disabled. */
> + PCHG_STATE_INITIALIZED,
> + /* Charger is enabled and ready to detect a device. */
> + PCHG_STATE_ENABLED,
> + /* Device is detected in proximity. */
> + PCHG_STATE_DETECTED,
> + /* Device is being charged. */
> + PCHG_STATE_CHARGING,
> +};
> +
> +#define EC_PCHG_STATE_TEXT { \
> + [PCHG_STATE_RESET] = "RESET", \
> + [PCHG_STATE_INITIALIZED] = "INITIALIZED", \
> + [PCHG_STATE_ENABLED] = "ENABLED", \
> + [PCHG_STATE_DETECTED] = "DETECTED", \
> + [PCHG_STATE_CHARGING] = "CHARGING", \
> + }
> +
>
> /*/
> /* Locate peripheral chips
> *
> --
> 2.29.2.684.gfbc64c5ab5-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH 2/2] platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC
*/
> + EC_FEATURE_TYPEC_REQUIRE_AP_MODE_ENTRY = 42,
> + /*
> + * The EC will wait for an acknowledge from the AP after setting the
> + * mux.
> + */
> + EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK = 43,
> };
>
> #define EC_FEATURE_MASK_0(event_code) BIT(event_code % 32)
> @@ -6054,6 +6064,13 @@ struct ec_params_charger_control {
> uint8_t allow_charging;
> } __ec_align_size1;
>
> +/* Get ACK from the USB-C SS muxes */
> +#define EC_CMD_USB_PD_MUX_ACK 0x0603
> +
> +struct ec_params_usb_pd_mux_ack {
> + uint8_t port; /* USB-C port number */
> +} __ec_align1;
> +
>
> /*/
> /*
> * Reserve a range of host commands for board-specific, experimental, or
> --
> 2.25.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH 2/2] platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC
Hi Prashant and Utkarash, On Mon, Dec 21, 2020 at 04:45:38PM -0800, Prashant Malani wrote: > Hi Utkarsh, > > On Wed, Dec 09, 2020 at 10:09:03PM -0800, Utkarsh Patel wrote: > > In some corner cases downgrade of the superspeed typec device(e.g. Dell > > typec Dock, apple dongle) was seen because before the SOC mux configuration > > finishes, EC starts configuring the next mux state. > > > > With this change, once the SOC mux is configured, kernel will send an > > acknowledgment to EC via Host command EC_CMD_USB_PD_MUX_ACK [1]. > > After sending the host event EC will wait for the acknowledgment from > > kernel before starting the PD negotiation for the next mux state. This > > helps to have a framework to build better error handling along with the > > synchronization of timing sensitive mux states. > > > > This change also brings in corresponding EC header updates from the EC code > > base [1]. > > > > [1]: > > https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h > > > > Signed-off-by: Utkarsh Patel > > I'm not sure what the maintainers' preference is for the header (same > patch or separate patch). FWIW: > > Reviewed-by: Prashant Malani I asked Gwendal to look over this change. It looks good to him, so I've gone ahead and merged it. At some point we have to completely sync ec_commands.h, but the change here is well contained, so it minimally adds to the delta between the EC codebase's header and the kernel's. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH 0/2] Send acknowledgment to ec from cors_ec_typec
Hi Utkarsh, On Wed, 9 Dec 2020 22:09:01 -0800, Utkarsh Patel wrote: > This adds mechanism of sending mux configuration acknowledgment from kernel > to EC. It also modifies cros_typec_cmds_supported() to support multiple > feature flags. > > Utkarsh Patel (2): > platform/chrome: cros_ec_typec: Parameterize > cros_typec_cmds_supported() > platform/chrome: cros_ec_typec: Send mux configuration acknowledgment > to EC > > [...] Applied, thanks! [1/2] platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported() commit: ba8ce515454e1fc5e73ff8989c18c596a3449fef [2/2] platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC commit: 8553a979fcd03448a4096c7d431b7ee1a52bfca3 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v3 00/11] chrome/platform: cros_ec_typec: Register cables, partner altmodes and plug altmodes
Hi Prashant,
On Mon, 16 Nov 2020 12:11:36 -0800, Prashant Malani wrote:
> This patch series adds support for the following bits of functionality,
> parsing USB Type C Power Delivery information from the Chrome Embedded
> Controller
> and using the Type C connector class:
> - Register cable objects (including plug type).
> - Register "number of altmodes" attribute for partners.
> - Register altmodes and "number of altmodes" attribute for cable plugs.
>
> [...]
Applied 4 through 11 of this series, staged for chrome-platform-5.12, thanks!
[04/11] platform/chrome: cros_ec_typec: Make disc_done flag partner-only
(no commit info)
[05/11] platform/chrome: cros_ec_typec: Factor out PD identity parsing
(no commit info)
[06/11] platform/chrome: cros_ec_typec: Rename discovery struct
(no commit info)
[07/11] platform/chrome: cros_ec_typec: Register cable
(no commit info)
[08/11] platform/chrome: cros_ec_typec: Store cable plug type
(no commit info)
[09/11] platform/chrome: cros_ec_typec: Set partner num_altmodes
(no commit info)
[10/11] platform/chrome: cros_ec_typec: Register SOP' cable plug
(no commit info)
[11/11] platform/chrome: cros_ec_typec: Register plug altmodes
(no commit info)
Best regards,
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] chrome-platform changes for v5.11
Hi Linus, The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.11 for you to fetch changes up to 6ae9b5ffcaeba64c290dfb8bd7b0194b1fdf0c92: platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags (2020-12-10 13:05:16 -0800) chrome platform changes for 5.11 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 Prashant Malani (8): platform/chrome: cros_ec_typec: Relocate set_port_params_v*() functions platform/chrome: cros_ec_typec: Fix remove partner logic platform/chrome: cros_ec_typec: Clear partner identity on device removal platform/chrome: cros_ec: Import Type C host commands platform/chrome: cros_ec_typec: Introduce TYPEC_STATUS platform/chrome: cros_ec_typec: Parse partner PD ID VDOs platform/chrome: cros_ec_typec: Register partner altmodes platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags Stephen Boyd (1): platform/chrome: Don't treat RTC events as wakeup sources drivers/platform/chrome/cros_ec_proto.c| 14 +- drivers/platform/chrome/cros_ec_typec.c| 336 +++-- include/linux/platform_data/cros_ec_commands.h | 155 3 files changed, 427 insertions(+), 78 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2] usb: typec: Add class for plug alt mode device
Hi Prashant,
On Thu, Dec 10, 2020 at 01:16:54PM -0800, Prashant Malani wrote:
> 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.
>
> Signed-off-by: Prashant Malani
> Cc: Heikki Krogerus
Reviewed-by: Benson Leung
> ---
>
> Changes in v2:
> - Changed code to set the class member instead of bus.
> - Removed the alteration to typec_bus.rst since it's not longer
> required.
> - Updated the commit message and subject to reflect the change in code.
>
> v1:
> https://lore.kernel.org/linux-usb/20201203030846.51669-1-pmal...@chromium.org/
>
> drivers/usb/typec/class.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 35eec707cb51..29d05b45cc9d 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -482,6 +482,10 @@ typec_register_altmode(struct device *parent,
> if (is_typec_partner(parent))
> alt->adev.dev.bus = _bus;
>
> + /* Plug alt modes need a class to generate udev events. */
> + if (is_typec_plug(parent))
> + alt->adev.dev.class = typec_class;
> +
> ret = device_register(>adev.dev);
> if (ret) {
> dev_err(parent, "failed to register alternate mode (%d)\n",
> --
> 2.29.2.576.ga3fc446d84-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags
On Thu, 5 Nov 2020 18:03:05 -0800, Prashant Malani wrote: > 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. Applied, thanks! [1/1] platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags commit: 6ae9b5ffcaeba64c290dfb8bd7b0194b1fdf0c92 Best regards, -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [RFC PATCH 2/3] usb: typec: Add product_type sysfs attribute file for partners and cables
struct attribute *attr, int n)
> +{
> + if (attr == _attr_product_type.attr)
> + if (!get_pd_identity(kobj_to_dev(kobj)))
> + return 0;
> +
> + return attr->mode;
> }
>
> /* -
> */
> @@ -534,10 +621,20 @@ static DEVICE_ATTR_RO(supports_usb_power_delivery);
>
> static struct attribute *typec_partner_attrs[] = {
> _attr_accessory_mode.attr,
> + _attr_product_type.attr,
> _attr_supports_usb_power_delivery.attr,
> NULL
> };
> -ATTRIBUTE_GROUPS(typec_partner);
> +
> +static struct attribute_group typec_partner_group = {
> + .is_visible = typec_product_type_attr_is_visible,
> + .attrs = typec_partner_attrs,
> +};
> +
> +static const struct attribute_group *typec_partner_groups[] = {
> + _partner_group,
> + NULL
> +};
>
> static void typec_partner_release(struct device *dev)
> {
> @@ -773,9 +870,19 @@ static DEVICE_ATTR_RO(plug_type);
> static struct attribute *typec_cable_attrs[] = {
> _attr_type.attr,
> _attr_plug_type.attr,
> + _attr_product_type.attr,
> + NULL
> +};
> +
> +static struct attribute_group typec_cable_group = {
> + .is_visible = typec_product_type_attr_is_visible,
> + .attrs = typec_cable_attrs,
> +};
> +
> +static const struct attribute_group *typec_cable_groups[] = {
> + _cable_group,
> NULL
> };
> -ATTRIBUTE_GROUPS(typec_cable);
>
> static void typec_cable_release(struct device *dev)
> {
> @@ -1352,6 +1459,11 @@ const struct device_type typec_port_dev_type = {
> /* --- */
> /* Driver callbacks to report role updates */
>
> +static int partner_match(struct device *dev, void *data)
> +{
> + return is_typec_partner(dev);
> +}
> +
> /**
> * typec_set_data_role - Report data role change
> * @port: The USB Type-C Port where the role was changed
> @@ -1361,12 +1473,23 @@ const struct device_type typec_port_dev_type = {
> */
> void typec_set_data_role(struct typec_port *port, enum typec_data_role role)
> {
> + struct device *partner_dev;
> +
> if (port->data_role == role)
> return;
>
> port->data_role = role;
> sysfs_notify(>dev.kobj, NULL, "data_role");
> kobject_uevent(>dev.kobj, KOBJ_CHANGE);
> +
> + partner_dev = device_find_child(>dev, NULL, partner_match);
> + if (!partner_dev)
> + return;
> +
> + if (to_typec_partner(partner_dev)->identity)
> + typec_product_type_notify(partner_dev);
> +
> + put_device(partner_dev);
> }
> EXPORT_SYMBOL_GPL(typec_set_data_role);
>
> @@ -1407,11 +1530,6 @@ void typec_set_vconn_role(struct typec_port *port,
> enum typec_role role)
> }
> EXPORT_SYMBOL_GPL(typec_set_vconn_role);
>
> -static int partner_match(struct device *dev, void *data)
> -{
> - return is_typec_partner(dev);
> -}
> -
> /**
> * typec_set_pwr_opmode - Report changed power operation mode
> * @port: The USB Type-C Port where the mode was changed
> --
> 2.29.2
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2 5/6] usb: pd: Add captive Type C cable type
Hi Prashant, On Fri, Nov 06, 2020 at 10:41:08AM -0800, Prashant Malani wrote: > The USB Power Delivery Specification R3.0 adds a captive cable type > to the "USB Type-C plug to USB Type-C/Captive" field (Bits 19-18, > Passive/Active Cable VDO, Table 6-38 & 6-39). > > Add the corresponding definition to the Cable VDO header. Also add a > helper macro to get the Type C cable connector type, when provided > the cable VDO. > > Cc: Heikki Krogerus > Signed-off-by: Prashant Malani Reviewed-by: Benson Leung Looks good, to modify the Cable VDO decoding to bring it up to date to PD 3.0. I should also note that the ID Header VDO also has a new field (that I added to the PD spec) that marks whether or not SOP/SOP' is a captive plug versus a receptacle as well. Nothing depends on it yet, but we should keep this in mind for future changes to the connector class. Thanks, Benson > --- > > Changes in v2: > - No changes. > > include/linux/usb/pd_vdo.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/usb/pd_vdo.h b/include/linux/usb/pd_vdo.h > index 68bdc4e2f5a9..8c5cb5830754 100644 > --- a/include/linux/usb/pd_vdo.h > +++ b/include/linux/usb/pd_vdo.h > @@ -177,7 +177,7 @@ > * <31:28> :: Cable HW version > * <27:24> :: Cable FW version > * <23:20> :: Reserved, Shall be set to zero > - * <19:18> :: type-C to Type-A/B/C (00b == A, 01 == B, 10 == C) > + * <19:18> :: type-C to Type-A/B/C/Captive (00b == A, 01 == B, 10 == C, 11 > == Captive) > * <17>:: Type-C to Plug/Receptacle (0b == plug, 1b == receptacle) > * <16:13> :: cable latency (0001 == <10ns(~1m length)) > * <12:11> :: cable termination type (11b == both ends active VCONN req) > @@ -193,6 +193,7 @@ > #define CABLE_ATYPE 0 > #define CABLE_BTYPE 1 > #define CABLE_CTYPE 2 > +#define CABLE_CAPTIVE3 > #define CABLE_PLUG 0 > #define CABLE_RECEPTACLE 1 > #define CABLE_CURR_1A5 0 > @@ -208,6 +209,7 @@ >| (tx1d) << 10 | (tx2d) << 9 | (rx1d) << 8 | (rx2d) << 7 \ >| ((cur) & 0x3) << 5 | (vps) << 4 | (sopp) << 3\ >| ((usbss) & 0x7)) > +#define VDO_TYPEC_CABLE_TYPE(vdo)(((vdo) >> 18) & 0x3) > > /* > * AMA VDO > -- > 2.29.1.341.ge80a0c044ae-goog > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH 07/20] input: keyboard: cros_ec_keyb: Struct headers should start with 'struct '
Hi Lee,
On Wed, Nov 04, 2020 at 04:24:14PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/keyboard/cros_ec_keyb.c:72: warning: cannot understand
> function prototype: 'struct cros_ec_bs_map '
>
> Cc: Dmitry Torokhov
> Cc: Benson Leung
> Cc: Enric Balletbo i Serra
> Cc: Guenter Roeck
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
Reviewed-by: Benson Leung
> ---
> drivers/input/keyboard/cros_ec_keyb.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c
> b/drivers/input/keyboard/cros_ec_keyb.c
> index 15d17c7170816..fce0c839e1430 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -58,10 +58,9 @@ struct cros_ec_keyb {
> struct notifier_block notifier;
> };
>
> -
> /**
> - * cros_ec_bs_map - Struct mapping Linux keycodes to EC button/switch bitmap
> - * #defines
> + * struct cros_ec_bs_map - Struct mapping Linux keycodes to EC button/switch
> + * bitmap #defines
> *
> * @ev_type: The type of the input event to generate (e.g., EV_KEY).
> * @code: A linux keycode
> --
> 2.25.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH 02/20] input: mouse: cyapa: Fix misnaming of 'cyapa_i2c_write's 'reg' param
Hi Lee, On Wed, Nov 04, 2020 at 04:24:09PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/input/mouse/cyapa.c:130: warning: Function parameter or member 'reg' > not described in 'cyapa_i2c_write' > drivers/input/mouse/cyapa.c:130: warning: Excess function parameter 'ret' > description in 'cyapa_i2c_write' > > Cc: Dmitry Torokhov > Cc: Henrik Rydberg > Cc: Dudley Du > Cc: Daniel Kurtz > Cc: Benson Leung > Cc: linux-in...@vger.kernel.org > Signed-off-by: Lee Jones Reviewed-by: Benson Leung > --- > drivers/input/mouse/cyapa.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c > index c675f156948b5..dacf7c0e43f98 100644 > --- a/drivers/input/mouse/cyapa.c > +++ b/drivers/input/mouse/cyapa.c > @@ -119,7 +119,7 @@ static ssize_t cyapa_i2c_read(struct cyapa *cyapa, u8 > reg, size_t len, > /** > * cyapa_i2c_write - Execute i2c block data write operation > * @cyapa: Handle to this driver > - * @ret: Offset of the data to written in the register map > + * @reg: Offset of the data to written in the register map > * @len: number of bytes to write > * @values: Data to be written > * > -- > 2.25.1 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH] typec: Provide USB PD Specification Revision for cable and partner
The USB Power Delivery specification Section 6.2.1.1.5 outlines
revision backward compatibility requirements starting from Revision 3.0.
The Port, the Cable Plug, and the Port Partner may support either revision
2 or revision 3 individually, and communication between ports, partners,
and cables of different revisions are allowed under rules that the parties
agree to communicate between each other using the lowest common operating
revision.
This may mean that Port-to-Port operating revision comms may be different
than Port-to-CablePlug operating revision comms. For example, it is
possible for a R3.0 port to communicate with a R3.0 cable using R3.0
messages, while the R3.0 port (in the same session) must communicate with
a R2.0 partner using PD R2.0 messages only.
This change will introduce individual revision number tracking for cable
and port partner so that the port can track them independently.
This will also enable future changes which change cable identifier
decoding and visible sysfs nodes based on revision 2 or 3.
Signed-off-by: Benson Leung
---
Documentation/ABI/testing/sysfs-class-typec | 8 +
drivers/usb/typec/class.c | 38 +++--
include/linux/usb/typec.h | 10 ++
3 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-typec
b/Documentation/ABI/testing/sysfs-class-typec
index b834671522d6..740b226bb80e 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -102,6 +102,14 @@ Description:
Revision number of the supported USB Power Delivery
specification, or 0 when USB Power Delivery is not supported.
+What:
/sys/class/typec/-{partner|cable}/usb_power_delivery_revision
+Date: October 2020
+Contact: Benson Leung
+Description:
+ Revision number of the supported USB Power Delivery
+ specification of the port partner or cable, or 0 when USB Power
+ Delivery is not supported.
+
What: /sys/class/typec//usb_typec_revision
Date: April 2017
Contact: Heikki Krogerus
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 35eec707cb51..abae4cbe66d5 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -25,6 +25,7 @@ struct typec_cable {
enum typec_plug_typetype;
struct usb_pd_identity *identity;
unsigned intactive:1;
+ u16 pd_revision; /* 0300H = "3.0" */
};
struct typec_partner {
@@ -33,6 +34,7 @@ struct typec_partner {
struct usb_pd_identity *identity;
enum typec_accessoryaccessory;
struct ida mode_ids;
+ u16 pd_revision; /* 0300H = "3.0" */
};
struct typec_port {
@@ -146,6 +148,28 @@ static void typec_report_identity(struct device *dev)
sysfs_notify(>kobj, "identity", "product");
}
+static ssize_t usb_power_delivery_revision_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ if (is_typec_partner(dev)) {
+ struct typec_partner *partner = to_typec_partner(dev);
+
+ return sprintf(buf, "%d\n", (partner->pd_revision >> 8) & 0xff);
+ } else if (is_typec_cable(dev)) {
+ struct typec_cable *cable = to_typec_cable(dev);
+
+ return sprintf(buf, "%d\n", (cable->pd_revision >> 8) & 0xff);
+ } else if (is_typec_port(dev)) {
+ struct typec_port *p = to_typec_port(dev);
+
+ return sprintf(buf, "%d\n", (p->cap->pd_revision >> 8) & 0xff);
+ }
+}
+static DEVICE_ATTR_RO(usb_power_delivery_revision);
+
+
+
/* - */
/* Alternate Modes */
@@ -535,6 +559,7 @@ static DEVICE_ATTR_RO(supports_usb_power_delivery);
static struct attribute *typec_partner_attrs[] = {
_attr_accessory_mode.attr,
_attr_supports_usb_power_delivery.attr,
+ _attr_usb_power_delivery_revision.attr,
NULL
};
ATTRIBUTE_GROUPS(typec_partner);
@@ -612,6 +637,7 @@ struct typec_partner *typec_register_partner(struct
typec_port *port,
ida_init(>mode_ids);
partner->usb_pd = desc->usb_pd;
partner->accessory = desc->accessory;
+ partner->pd_revision = desc->pd_revision;
if (desc->identity) {
/*
@@ -773,6 +799,7 @@ static DEVICE_ATTR_RO(plug_type);
static struct attribute *typec_cable_attrs[] = {
_attr_type.attr,
_attr_plug_type.attr,
+ _attr_usb_power_delivery_revision.a
Re: [PATCH v2] usb: typec: Expose Product Type VDOs via sysfs
Hi Heikki, On Thu, Oct 22, 2020 at 5:43 AM Heikki Krogerus wrote: > > On Thu, Oct 22, 2020 at 12:25:07AM -0700, Prashant Malani wrote: > > Hi Greg, > > > > On Thu, Oct 22, 2020 at 12:17 AM Greg KH wrote: > > > > > > > > > +What: > > > > > > /sys/class/typec/-partner/identity/product_type_vdo > > > > > > +Date:October 2020 > > > > > > +Contact: Prashant Malani > > > > > > +Description: > > > > > > + Product Type VDOs part of Discover Identity command > > > > > > result. 3 values > > > > > > + are displayed (for the 3 possible Product Type VDOs), > > > > > > one per line. > > > > > > > > > > sysfs is "one value per file", not "one value per line". This is not > > > > > ok. > > > > > > > > I see. Would listing these out as three separate vdos (i.e vdo0, vdo1, > > > > vdo2) be better? > > > > > > Given that your current implementation is not acceptable, something has > > > to change :) > > > > Got it. I'd like to see if Heikki has any suggestions on naming these > > entries better. > > Why not have product type specific attribute files? > > So if the partner is UFP, then we expose ufp1 and ufp2 files that > return the UFP1 and UFP2 VDO values and hide the other files: > > % ls /sys/class/typec/port0-partner/identity/ > id_header cert_stat product ufp1 ufp2 > > If the partner is DFP, then you expose the dfp file and hide > everything else: > > % ls /sys/class/typec/port0-partner/identity/ > id_header cert_stat product dfp > > And so on. I would caution against any decoding of the VDO contents in the kernel and making assumptions about the # or the names of these three individual objects. Since PD 2.0 through PD 3.0, and PD 3.0's different subrevisions (1.0, 1.3, 2.0), the # of VDOs that have been supported has changed in the various spec versions. PD R3.0 V2.0 actually added extra objects here (UFP VDO1 UFP VDO2, DFP VDO), but thanks to some troublemaker (me, actually...), the PD spec's next version deprecates and deletes two of them (the AMA VDO and the UFP VDO2 are gone, thanks to an ECR I put into USB PD). (If you've got USB PD working group access, the two ECRs in question are: https://groups.usb.org/wg/powerdelivery/document/11007 and https://groups.usb.org/wg/powerdelivery/document/10967). Since the different spec versions need to all be supported (since the firmware of PD devices are baked for a particular version of the PD spec at the time they are released and don't change in practice), the software on USB PD hosts should provide these objects up to the next layer without adding any extra decoding, and the upper layer (userspace) can figure out the specifics based on comparing different revision and version fields to figure out what vdo1, vdo2, and vdo3 are. Anyway, hope this helps, and sorry in advance for making this section of the PD spec more complicated to handle over time... Benson > > thanks, > > -- > heikki -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org
[GIT PULL] chrome-platform changes for v5.10
Hello Linus, The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.10 for you to fetch changes up to 3e98fd6d816cd82f529345870efd435f06e02803: ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA (2020-10-01 18:33:01 +0200) chrome platform changes for 5.10 cros-ec: * Error code cleanup across cros-ec by Guenter. * Remove cros_ec_cmd_xfer in favor of cros_ec_cmd_xfer_status. cros_ec_typec: * Landed initial USB4 support in typec connector class driver for cros_ec. * Role switch bugfix on disconnect, and reordering configuration steps. cros_ec_lightbar: * Fix buffer outsize and result for get_lightbar_version. misc: * Remove config MFD_CROS_EC, now that transition from MFD is complete. * Enable KEY_LEFTMETA in new location on arm based cros-ec-keyboard keymap. Azhar Shaikh (3): platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role() platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect platform/chrome: cros_ec_typec: Re-order connector configuration steps Enric Balletbo i Serra (1): platform/chrome: Kconfig: Remove the transitional MFD_CROS_EC config Guenter Roeck (7): iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status platform/chrome: cros_ec_sysfs: Report range of error codes from EC pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes pwm: cros-ec: Simplify EC error handling Gwendal Grignou (2): platform/chrome: cros_ec_trace: Add fields to command traces platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command Heikki Krogerus (1): platform/chrome: cros_ec_typec: USB4 support Prashant Malani (2): platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer() Stephen Boyd (1): ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA Wang Qing (1): platform/chrome: Use kobj_to_dev() instead of container_of() arch/arm/boot/dts/cros-ec-keyboard.dtsi| 1 + .../iio/common/cros_ec_sensors/cros_ec_sensors.c | 2 +- drivers/input/keyboard/cros_ec_keyb.c | 2 +- drivers/platform/chrome/Kconfig| 10 -- drivers/platform/chrome/cros_ec_lightbar.c | 12 +-- drivers/platform/chrome/cros_ec_proto.c| 106 +++-- drivers/platform/chrome/cros_ec_sysfs.c| 26 ++--- drivers/platform/chrome/cros_ec_trace.h| 27 -- drivers/platform/chrome/cros_ec_typec.c| 42 +++- drivers/platform/chrome/cros_ec_vbc.c | 4 +- drivers/pwm/pwm-cros-ec.c | 37 --- 11 files changed, 154 insertions(+), 115 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] usb: typec: Expose Product Type VDOs via sysfs
Hi Prashant,
On Wed, Oct 21, 2020 at 02:18:02PM -0700, Prashant Malani wrote:
> A PD-capable device can return up to 3 Product Type VDOs as part of its
> DiscoverIdentity Response (USB PD Spec, Rev 3.0, Version 2.0, Section
> 6.4.4.3.1). Add a sysfs attribute to expose these to userspace.
>
> Cc: Benson Leung
> Cc: Heikki Krogerus
> Signed-off-by: Prashant Malani
Reviewed-by: Benson Leung
> ---
> drivers/usb/typec/class.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 35eec707cb51..e6abb0dee9fa 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -122,10 +122,20 @@ static ssize_t product_show(struct device *dev, struct
> device_attribute *attr,
> }
> static DEVICE_ATTR_RO(product);
>
> +static ssize_t product_type_vdo_show(struct device *dev, struct
> device_attribute *attr,
> + char *buf)
> +{
> + struct usb_pd_identity *id = get_pd_identity(dev);
> +
> + return sprintf(buf, "0x%08x\n0x%08x\n0x%08x\n", id->vdo[0], id->vdo[1],
> id->vdo[2]);
> +}
> +static DEVICE_ATTR_RO(product_type_vdo);
> +
> static struct attribute *usb_pd_id_attrs[] = {
> _attr_id_header.attr,
> _attr_cert_stat.attr,
> _attr_product.attr,
> + _attr_product_type_vdo.attr,
> NULL
> };
>
> --
> 2.29.0.rc1.297.gfa9743e501-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] chrome-platform changes for v5.9
Hello Linus, The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.9 for you to fetch changes up to fc8cacf3fc68664e30a6df2b361ae05b9769585e: platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK (2020-07-31 12:56:36 +0200) chrome platform changes for 5.9 * 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 Brian Norris (2): platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK Enric Balletbo i Serra (4): platform/chrome: cros_ec_spi: Document missing function parameters platform/chrome: cros_ec_rpmsg: Document missing struct parameters platform/chrome: cros_ec_typec: Add a dependency on USB_ROLE_SWITCH platform/chrome: cros_ec_proto: Do not export cros_ec_cmd_xfer() Gwendal Grignou (3): platform/chrome: cros_ec_debugfs: Control uptime information request platform/chrome: cros_ec_sensorhub: Fix EC timestamp overflow platform/chrome: cros_ec_sensorhub: Simplify legacy timestamp spreading Prashant Malani (11): platform/chrome: cros_ec_typec: Register Type C switches platform/chrome: cros_ec: Update mux state bits platform/chrome: cros_ec_typec: Register PD CTRL cmd v2 platform/chrome: cros_ec_typec: Add USB mux control platform/chrome: cros_ec_typec: Support DP alt mode platform/chrome: cros_ec_typec: Make configure_mux static platform/chrome: cros_ec: Add TBT pd_ctrl fields platform/chrome: cros_ec_typec: Add TBT compat support platform/chrome: cros_ec_typec: Use workqueue for port update platform/chrome: cros_ec_typec: Add PM support platform/chrome: cros_ec_typec: Unregister partner on error Qiushi Wu (1): platform/chrome: cros_ec_ishtp: Fix a double-unlock issue drivers/platform/chrome/Kconfig | 1 + drivers/platform/chrome/cros_ec_debugfs.c| 24 +- drivers/platform/chrome/cros_ec_ishtp.c | 4 +- drivers/platform/chrome/cros_ec_proto.c | 42 ++- drivers/platform/chrome/cros_ec_rpmsg.c | 3 + drivers/platform/chrome/cros_ec_sensorhub_ring.c | 98 ++ drivers/platform/chrome/cros_ec_spi.c| 4 + drivers/platform/chrome/cros_ec_typec.c | 399 --- include/linux/platform_data/cros_ec_commands.h | 33 +- include/linux/platform_data/cros_ec_proto.h | 3 - 10 files changed, 483 insertions(+), 128 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[GIT PULL] chrome-platform changes for v5.8
Hi Linus, The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.8 for you to fetch changes up to bbb7ad49b8350b79261ce087c8e101d92f15533d: platform/chrome: cros_usbpd_logger: Add __printf annotation to append_str() (2020-05-04 14:02:01 -0700) chrome platform changes for 5.8 * cros_ec_typec - Add notifier for update, and register port partner * Sensors/iio: - Fixes to cros_ec_sensorhub around allocation of resources, and send_sample. * Wilco EC - Fix to output format of h1_gpio * Misc - Misc fixes to appease kernel-doc and other warnings. - Set user space log size in chromeos_pstore Benson Leung (1): Merge remote-tracking branch 'origin/chrome-platform-5.7-fixes' into for-kernelci Bernardo Perez Priego (1): platform/chrome: wilco_ec: Provide correct output format to 'h1_gpio' file Christophe JAILLET (1): platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages Dan Carpenter (1): platform/chrome: cros_ec_sensorhub: Off by one in cros_sensorhub_send_sample() Enric Balletbo i Serra (3): Merge remote-tracking branch 'origin/chrome-platform-5.7-fixes' into for-kernelci platform/chrome: cros_ec_i2c: Appease the kernel-doc deity platform/chrome: cros_usbpd_logger: Add __printf annotation to append_str() Gwendal Grignou (1): platform/chrome: cros_ec_sensorhub: Allocate sensorhub resource before claiming sensors Jett Rink (2): platform/chrome: cros_ec_ishtp: skip old cros_ec responses platform/chrome: cros_ec_ishtp: free ishtp buffer before sending event Prashant Malani (4): platform/chrome: cros_ec_typec: Use notifier for updates platform/chrome: cros_ec_typec: Add struct for port data platform/chrome: cros_ec_typec: Register port partner platform/chrome: typec: Fix ret value check error Sarthak Kukreti (1): platform/chrome: chromeos_pstore: set user space log size drivers/platform/chrome/Kconfig | 1 + drivers/platform/chrome/chromeos_pstore.c| 1 + drivers/platform/chrome/cros_ec_i2c.c| 2 +- drivers/platform/chrome/cros_ec_ishtp.c | 45 ++--- drivers/platform/chrome/cros_ec_sensorhub.c | 80 --- drivers/platform/chrome/cros_ec_sensorhub_ring.c | 81 +-- drivers/platform/chrome/cros_ec_typec.c | 119 +++ drivers/platform/chrome/cros_usbpd_logger.c | 1 + drivers/platform/chrome/wilco_ec/debugfs.c | 7 +- include/linux/platform_data/cros_ec_sensorhub.h | 1 + 10 files changed, 242 insertions(+), 96 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] usb: typec: mux: intel: Fix DP_HPD_LVL bit field
Hi Prashant,
On Sun, May 10, 2020 at 01:31:43PM -0700, Prashant Malani wrote:
> According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
> 0.6, the PMC HPD request LVL bit field is bit 5.
> Fix the definition here to match the programming guide.
>
> Since this bit field is changing, explicitly define a field for the
> HPD_HIGH mode data bit.
>
> Signed-off-by: Prashant Malani
> Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
Reviewed-by: Benson Leung
> ---
> drivers/usb/typec/mux/intel_pmc_mux.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c
> b/drivers/usb/typec/mux/intel_pmc_mux.c
> index 67c5139cfa0d..15074aec94eb 100644
> --- a/drivers/usb/typec/mux/intel_pmc_mux.c
> +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
> @@ -63,6 +63,7 @@ enum {
> #define PMC_USB_ALTMODE_DP_MODE_SHIFT8
>
> /* TBT specific Mode Data bits */
> +#define PMC_USB_ALTMODE_HPD_HIGH BIT(14)
> #define PMC_USB_ALTMODE_TBT_TYPE BIT(17)
> #define PMC_USB_ALTMODE_CABLE_TYPE BIT(18)
> #define PMC_USB_ALTMODE_ACTIVE_LINK BIT(20)
> @@ -75,7 +76,7 @@ enum {
>
> /* Display HPD Request bits */
> #define PMC_USB_DP_HPD_IRQ BIT(5)
> -#define PMC_USB_DP_HPD_LVL BIT(6)
> +#define PMC_USB_DP_HPD_LVL BIT(4)
>
> struct pmc_usb;
>
> @@ -158,8 +159,7 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct
> typec_mux_state *state)
>PMC_USB_ALTMODE_DP_MODE_SHIFT;
>
> if (data->status & DP_STATUS_HPD_STATE)
> - req.mode_data |= PMC_USB_DP_HPD_LVL <<
> - PMC_USB_ALTMODE_DP_MODE_SHIFT;
> + req.mode_data |= PMC_USB_ALTMODE_HPD_HIGH;
>
> return pmc_usb_command(port, (void *), sizeof(req));
> }
> --
> 2.26.2.645.ge9eca65c58-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] chrome-platform fixes for v5.7-rc5
Hi Linus, The following changes since commit 538b8471fee89eaf18f6bfbbc0576473f952b83e: platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages (2020-04-13 16:31:33 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-fixes-for-v5.7-rc5 for you to fetch changes up to b31d1d2b1c3a8452f425b09ebd374ecd3ddd5179: platform/chrome: cros_ec_sensorhub: Allocate sensorhub resource before claiming sensors (2020-04-29 23:17:45 +0200) chrome-platform fixes for v5.7-rc5 Fix a resource allocation issue in cros_ec_sensorhub.c. Gwendal Grignou (1): platform/chrome: cros_ec_sensorhub: Allocate sensorhub resource before claiming sensors drivers/platform/chrome/cros_ec_sensorhub.c | 80 ++-- drivers/platform/chrome/cros_ec_sensorhub_ring.c | 73 + include/linux/platform_data/cros_ec_sensorhub.h | 1 + 3 files changed, 93 insertions(+), 61 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH 1/2] dt-bindings: chrome: Add cros-ec-typec mux props
Hi Prashant,
On Wed, Apr 22, 2020 at 03:22:39PM -0700, Prashant Malani wrote:
> Add properties for mode, orientation and USB data role switches for
> Type C connectors. When available, these will allow the Type C connector
> class port driver to configure the various switches according to USB PD
> information (like orientation, alt mode etc.) provided by the Chrome OS
> EC controller.
>
> Signed-off-by: Prashant Malani
Acked-By: Benson Leung
Thanks,
Benson
> ---
> .../bindings/chrome/google,cros-ec-typec.yaml | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> index 6d7396ab8bee..b5814640aa32 100644
> --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> @@ -21,7 +21,21 @@ properties:
> const: google,cros-ec-typec
>
>connector:
> -$ref: /schemas/connector/usb-connector.yaml#
> +allOf:
> + - $ref: /schemas/connector/usb-connector.yaml#
> + - type: object
> +properties:
> + mode-switch:
> +description: Reference to a DT node for the USB Type C
> Multiplexer
> + controlling the data lines routing for this connector.
> +
> + orientation-switch:
> +description: Reference to a DT node for the USB Type C
> orientation
> + switch for this connector.
> +
> + usb-role-switch:
> +description: Reference to a DT node for the USB Data role switch
> + for this connector.
>
> required:
>- compatible
> @@ -49,6 +63,17 @@ examples:
> data-role = "dual";
> try-power-role = "source";
>};
> +
> + connector@1 {
> +compatible = "usb-c-connector";
> +reg = <1>;
> +power-role = "dual";
> +data-role = "host";
> +try-power-role = "source";
> + mode-switch = <_mux>;
> +orientation-switch = <_orientation_switch>;
> +usb-role-switch = <_mux>;
> + };
> };
>};
> };
> --
> 2.26.1.301.g55bc3eb7cb9-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] platform/chrome: cros_usbpd_logger: Add __printf annotation to append_str()
Hi Enric,
On Tue, Apr 14, 2020 at 10:12:39PM +0200, Enric Balletbo i Serra wrote:
> This allows the compiler to verify the format strings vs the types of
> the arguments. Also, silence the warning (triggered by W=1):
>
> cros_usbpd_logger.c:55:2: warning: function ‘append_str’ might be a
> candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
>
> Signed-off-by: Enric Balletbo i Serra
Applied for chrome-platform-5.8. You'll find it in the for-kernelci branch
very shortly.
Benson
> ---
>
> drivers/platform/chrome/cros_usbpd_logger.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/platform/chrome/cros_usbpd_logger.c
> b/drivers/platform/chrome/cros_usbpd_logger.c
> index 7de3ea75ef46..d16931203d82 100644
> --- a/drivers/platform/chrome/cros_usbpd_logger.c
> +++ b/drivers/platform/chrome/cros_usbpd_logger.c
> @@ -46,6 +46,7 @@ static const char * const fault_names[] = {
> "---", "OCP", "fast OCP", "OVP", "Discharge"
> };
>
> +__printf(3, 4)
> static int append_str(char *buf, int pos, const char *fmt, ...)
> {
> va_list args;
> --
> 2.25.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] platform/chrome: cros_ec_i2c: Appease the kernel-doc deity
Hi Enric, On Tue, Apr 14, 2020 at 10:13:13PM +0200, Enric Balletbo i Serra wrote: > Replace a comment starting with /** by simply /* to avoid having > it interpreted as a kernel-doc comment. > > Signed-off-by: Enric Balletbo i Serra Applied for chrome-platform-5.8. You'll find it in the for-kernelci branch very shortly. Thanks, Benson > --- > > drivers/platform/chrome/cros_ec_i2c.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/chrome/cros_ec_i2c.c > b/drivers/platform/chrome/cros_ec_i2c.c > index 6119eccd8a18..30c8938c27d5 100644 > --- a/drivers/platform/chrome/cros_ec_i2c.c > +++ b/drivers/platform/chrome/cros_ec_i2c.c > @@ -16,7 +16,7 @@ > > #include "cros_ec.h" > > -/** > +/* > * Request format for protocol v3 > * byte 00xda (EC_COMMAND_PROTOCOL_3) > * byte 1-8 struct ec_host_request > -- > 2.25.1 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH -next] platform/chrome: wilco_ec: Use kmemdup in enqueue_events()
Hey Nick, On Fri, Jun 21, 2019 at 7:51 AM Nick Crews wrote: > > Thanks Yue, looks good to me. > > Nick > > On Fri, Jun 21, 2019 at 7:59 AM YueHaibing wrote: > > > > Use kmemdup rather than duplicating its implementation > > > > Signed-off-by: YueHaibing > > --- > > drivers/platform/chrome/wilco_ec/event.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/platform/chrome/wilco_ec/event.c > > b/drivers/platform/chrome/wilco_ec/event.c > > index c975b76e6255..70156e75047e 100644 > > --- a/drivers/platform/chrome/wilco_ec/event.c > > +++ b/drivers/platform/chrome/wilco_ec/event.c > > @@ -248,10 +248,9 @@ static int enqueue_events(struct acpi_device *adev, > > const u8 *buf, u32 length) > > offset += event_size; > > > > /* Copy event into the queue */ > > - queue_event = kzalloc(event_size, GFP_KERNEL); > > + queue_event = kmemdup(event, event_size, GFP_KERNEL); > > if (!queue_event) > > return -ENOMEM; > > - memcpy(queue_event, event, event_size); > > event_queue_push(dev_data->events, queue_event); > > } > > > > > > Looks like this was already incorporated into your commit, platform/chrome: wilco_ec: Use kmemdup in enqueue_events(). Thanks! Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org
Re: [PATCH v5] platform/chrome: wilco_ec: Add debugfs test_event file
Hi Daniel,
On Tue, Sep 24, 2019 at 02:37:16PM -0600, Daniel Campello wrote:
> This change introduces a new debugfs file 'test_event' that when written
> to causes the EC to generate a test event.
> This adds a second sub cmd for the test event, and pulls out send_ec_cmd
> to be a common helper between h1_gpio_get and test_event_set.
>
> Signed-off-by: Daniel Campello
LGTM.
Reviewed-by: Benson Leung
Merge window is open right now for v5.4, so we can't quite merge this change
for chrome-platform-5.5 yet.
Enric, can you queue this for the next branch if you have no objections?
Thanks,
Benson
> ---
> Changes for v2:
> - Cleaned up and added comments.
> - Renamed and updated function signature from write_to_mailbox to
> send_ec_cmd.
> Changes for v3:
> - Switched NULL format string to empty format string
> - Renamed val parameter on send_ec_cmd to out_val
> Changes for v4:
> - Provided a format string to avoid -Wformat-zero-length warning
> Changes for v5:
> - Updated commit message to include more implementation details
> - Restored removed empty line between functions
>
> drivers/platform/chrome/wilco_ec/debugfs.c | 47 +-
> 1 file changed, 37 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c
> b/drivers/platform/chrome/wilco_ec/debugfs.c
> index 8d65a1e2f1a3..df5a5f6c3ec6 100644
> --- a/drivers/platform/chrome/wilco_ec/debugfs.c
> +++ b/drivers/platform/chrome/wilco_ec/debugfs.c
> @@ -160,29 +160,29 @@ static const struct file_operations fops_raw = {
>
> #define CMD_KB_CHROME0x88
> #define SUB_CMD_H1_GPIO 0x0A
> +#define SUB_CMD_TEST_EVENT 0x0B
>
> -struct h1_gpio_status_request {
> +struct ec_request {
> u8 cmd; /* Always CMD_KB_CHROME */
> u8 reserved;
> - u8 sub_cmd; /* Always SUB_CMD_H1_GPIO */
> + u8 sub_cmd;
> } __packed;
>
> -struct hi_gpio_status_response {
> +struct ec_response {
> u8 status; /* 0 if allowed */
> - u8 val; /* BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL */
> + u8 val;
> } __packed;
>
> -static int h1_gpio_get(void *arg, u64 *val)
> +static int send_ec_cmd(struct wilco_ec_device *ec, u8 sub_cmd, u8 *out_val)
> {
> - struct wilco_ec_device *ec = arg;
> - struct h1_gpio_status_request rq;
> - struct hi_gpio_status_response rs;
> + struct ec_request rq;
> + struct ec_response rs;
> struct wilco_ec_message msg;
> int ret;
>
> memset(, 0, sizeof(rq));
> rq.cmd = CMD_KB_CHROME;
> - rq.sub_cmd = SUB_CMD_H1_GPIO;
> + rq.sub_cmd = sub_cmd;
>
> memset(, 0, sizeof(msg));
> msg.type = WILCO_EC_MSG_LEGACY;
> @@ -196,13 +196,38 @@ static int h1_gpio_get(void *arg, u64 *val)
> if (rs.status)
> return -EIO;
>
> - *val = rs.val;
> + *out_val = rs.val;
>
> return 0;
> }
>
> +/**
> + * h1_gpio_get() - Gets h1 gpio status.
> + * @arg: The wilco EC device.
> + * @val: BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL
> + */
> +static int h1_gpio_get(void *arg, u64 *val)
> +{
> + return send_ec_cmd(arg, SUB_CMD_H1_GPIO, (u8 *)val);
> +}
> +
> DEFINE_DEBUGFS_ATTRIBUTE(fops_h1_gpio, h1_gpio_get, NULL, "0x%02llx\n");
>
> +/**
> + * test_event_set() - Sends command to EC to cause an EC test event.
> + * @arg: The wilco EC device.
> + * @val: unused.
> + */
> +static int test_event_set(void *arg, u64 val)
> +{
> + u8 ret;
> +
> + return send_ec_cmd(arg, SUB_CMD_TEST_EVENT, );
> +}
> +
> +/* Format is unused since it is only required for get method which is NULL */
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_test_event, NULL, test_event_set, "%llu\n");
> +
> /**
> * wilco_ec_debugfs_probe() - Create the debugfs node
> * @pdev: The platform device, probably created in core.c
> @@ -226,6 +251,8 @@ static int wilco_ec_debugfs_probe(struct platform_device
> *pdev)
> debugfs_create_file("raw", 0644, debug_info->dir, NULL, _raw);
> debugfs_create_file("h1_gpio", 0444, debug_info->dir, ec,
> _h1_gpio);
> + debugfs_create_file("test_event", 0200, debug_info->dir, ec,
> + _test_event);
>
> return 0;
> }
> --
> 2.23.0.351.gc4317032e6-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v4] platform/chrome: wilco_ec: Add debugfs test_event file
Hi Daniel,
Thanks for sending this.
On Wed, Sep 18, 2019 at 02:43:16PM -0600, Daniel Campello wrote:
> This change introduces a new debugfs file 'test_event' that when written
> to causes the EC to generate a test event.
Please mention that this adds a second sub cmd for the test event, and
pulls out send_ec_cmd to be a common helper between h1_gpio_get and
test_event_set.
>
> Signed-off-by: Daniel Campello
> ---
> Changes for v2:
> - Cleaned up and added comments.
> - Renamed and updated function signature from write_to_mailbox to
> send_ec_cmd.
> Changes for v3:
> - Switched NULL format string to empty format string
> - Renamed val parameter on send_ec_cmd to out_val
> Changes for v4:
> - Provided a format string to avoid -Wformat-zero-length warning
>
> drivers/platform/chrome/wilco_ec/debugfs.c | 46 +-
> 1 file changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c
> b/drivers/platform/chrome/wilco_ec/debugfs.c
> index 8d65a1e2f1a3..ba86c38421ff 100644
> --- a/drivers/platform/chrome/wilco_ec/debugfs.c
> +++ b/drivers/platform/chrome/wilco_ec/debugfs.c
> @@ -160,29 +160,29 @@ static const struct file_operations fops_raw = {
>
> #define CMD_KB_CHROME0x88
> #define SUB_CMD_H1_GPIO 0x0A
> +#define SUB_CMD_TEST_EVENT 0x0B
>
> -struct h1_gpio_status_request {
> +struct ec_request {
> u8 cmd; /* Always CMD_KB_CHROME */
> u8 reserved;
> - u8 sub_cmd; /* Always SUB_CMD_H1_GPIO */
> + u8 sub_cmd;
> } __packed;
>
> -struct hi_gpio_status_response {
> +struct ec_response {
> u8 status; /* 0 if allowed */
> - u8 val; /* BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL */
> + u8 val;
> } __packed;
>
> -static int h1_gpio_get(void *arg, u64 *val)
> +static int send_ec_cmd(struct wilco_ec_device *ec, u8 sub_cmd, u8 *out_val)
> {
> - struct wilco_ec_device *ec = arg;
> - struct h1_gpio_status_request rq;
> - struct hi_gpio_status_response rs;
> + struct ec_request rq;
> + struct ec_response rs;
> struct wilco_ec_message msg;
> int ret;
>
> memset(, 0, sizeof(rq));
> rq.cmd = CMD_KB_CHROME;
> - rq.sub_cmd = SUB_CMD_H1_GPIO;
> + rq.sub_cmd = sub_cmd;
>
> memset(, 0, sizeof(msg));
> msg.type = WILCO_EC_MSG_LEGACY;
> @@ -196,13 +196,37 @@ static int h1_gpio_get(void *arg, u64 *val)
> if (rs.status)
> return -EIO;
>
> - *val = rs.val;
> + *out_val = rs.val;
>
> return 0;
> }
> +/**
Minor nit. Add one line of whitespace before this comment start.
> + * h1_gpio_get() - Gets h1 gpio status.
> + * @arg: The wilco EC device.
> + * @val: BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL
> + */
> +static int h1_gpio_get(void *arg, u64 *val)
> +{
> + return send_ec_cmd(arg, SUB_CMD_H1_GPIO, (u8 *)val);
> +}
>
> DEFINE_DEBUGFS_ATTRIBUTE(fops_h1_gpio, h1_gpio_get, NULL, "0x%02llx\n");
>
> +/**
> + * test_event_set() - Sends command to EC to cause an EC test event.
> + * @arg: The wilco EC device.
> + * @val: unused.
> + */
> +static int test_event_set(void *arg, u64 val)
> +{
> + u8 ret;
> +
> + return send_ec_cmd(arg, SUB_CMD_TEST_EVENT, );
> +}
> +
> +/* Format is unused since it is only required for get method which is NULL */
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_test_event, NULL, test_event_set, "%llu\n");
> +
> /**
> * wilco_ec_debugfs_probe() - Create the debugfs node
> * @pdev: The platform device, probably created in core.c
> @@ -226,6 +250,8 @@ static int wilco_ec_debugfs_probe(struct platform_device
> *pdev)
> debugfs_create_file("raw", 0644, debug_info->dir, NULL, _raw);
> debugfs_create_file("h1_gpio", 0444, debug_info->dir, ec,
> _h1_gpio);
> + debugfs_create_file("test_event", 0200, debug_info->dir, ec,
> + _test_event);
>
> return 0;
> }
> --
> 2.23.0.237.gc6a4ce50a0-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] chrome-platform changes for v5.4
Hi Linus,
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
tags/tag-chrome-platform-for-v5.4
for you to fetch changes up to 4c1fde5077dcad1a2a10a6a0883c8f94326c4971:
platform/chrome: cros_usbpd_logger: null check create_singlethread_workqueue
(2019-09-12 16:20:54 +0200)
chrome platform changes for v5.4
* CrOS EC / MFD Migration
- Move cros_ec core driver from mfd into chrome platform.
* Wilco EC:
- Add batt_ppid_info command to Wilco telemetry driver.
* CrOS EC:
- cros_ec_rpmsg : Add support to inform EC of suspend/resume status
- cros_ec_rpmsg : Fix race condition on probe failed
- cros_ec_chardev : Add a poll handler to receive MKBP events
* Misc:
- bugfixes in cros_usbpd_logger and cros_ec_ishtp
Benson Leung (1):
Merge tag 'tag-chrome-platform-fixes-for-v5.3-rc6' into for-next
Enric Balletbo i Serra (12):
mfd / platform: cros_ec: Handle chained ECs as platform devices
mfd / platform: cros_ec: Move cros-ec core driver out from MFD
mfd / platform: cros_ec: Miscellaneous character device to talk with the
EC
mfd: cros_ec: Switch to use the new cros-ec-chardev driver
mfd / platform: cros_ec: Rename config to a better name
mfd / platform: cros_ec: Reorganize platform and mfd includes
mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper
mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs
mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC
subdevices
mfd: cros_ec: Use mfd_add_hotplug_devices() helper
Merge tag
'ib-mfd-extcon-hid-i2c-iio-input-media-chrome-power-pwm-rtc-sound-v5.4' into
chrome-platform/for-next
platform/chrome: cros_ec_chardev: Add a poll handler to receive MKBP
events
Hyungwoo Yang (1):
platform/chrome: cros_ec_ishtp: fix crash during suspend
Navid Emamdoost (1):
platform/chrome: cros_usbpd_logger: null check
create_singlethread_workqueue
Nick Crews (1):
platform/chrome: wilco_ec: Add batt_ppid_info command to telemetry driver
Pi-Hsun Shih (1):
platform/chrome: cros_ec_rpmsg: Fix race with host command when probe
failed
Ravi Chandra Sadineni (1):
platform/chrome: chromeos_tbmc: Report wake events
Wolfram Sang (1):
platform/chrome: chromeos_laptop: drop checks of NULL-safe functions
Yilun Lin (1):
platform/chrome: cros_ec_rpmsg: Add host command AP sleep state support
drivers/extcon/Kconfig | 2 +-
drivers/extcon/extcon-usbc-cros-ec.c | 3 +-
drivers/hid/Kconfig| 2 +-
drivers/hid/hid-google-hammer.c| 4 +-
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 4 +-
drivers/iio/accel/cros_ec_accel_legacy.c | 3 +-
drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
.../iio/common/cros_ec_sensors/cros_ec_lid_angle.c | 3 +-
.../iio/common/cros_ec_sensors/cros_ec_sensors.c | 3 +-
.../common/cros_ec_sensors/cros_ec_sensors_core.c | 3 +-
drivers/iio/light/cros_ec_light_prox.c | 3 +-
drivers/iio/pressure/cros_ec_baro.c| 3 +-
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/keyboard/cros_ec_keyb.c | 4 +-
drivers/media/platform/Kconfig | 3 +-
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 5 +-
drivers/mfd/Kconfig| 26 +-
drivers/mfd/Makefile | 4 +-
drivers/mfd/cros_ec_dev.c | 463 ++---
drivers/platform/chrome/Kconfig| 60 ++-
drivers/platform/chrome/Makefile | 2 +
drivers/platform/chrome/chromeos_laptop.c | 10 +-
drivers/platform/chrome/chromeos_tbmc.c| 2 +
drivers/{mfd => platform/chrome}/cros_ec.c | 64 +--
drivers/platform/chrome/cros_ec_chardev.c | 419 +++
drivers/platform/chrome/cros_ec_debugfs.c | 3 +-
drivers/platform/chrome/cros_ec_i2c.c | 12 +-
drivers/platform/chrome/cros_ec_ishtp.c| 9 +-
drivers/platform/chrome/cros_ec_lightbar.c | 3 +-
drivers/platform/chrome/cros_ec_lpc.c | 7 +-
drivers/platform/chrome/cros_ec_proto.c| 3 +-
drivers/platform/chrome/cros_ec_rpmsg.c| 57 ++-
drivers/platform/chrome/cros_ec_spi.c | 12 +-
drivers/platform/chrome/cros_ec_sysfs.c| 3 +-
drivers/platform/chrome/cros_ec_trace.c| 2 +-
drivers/platform/chr
[GIT PULL] chrome-platform fixes for v5.3-rc6
Hi Linus, The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-fixes-for-v5.3-rc6 for you to fetch changes up to 9cdde85804833af77c6afbf7c53f0d959c42eb9f: platform/chrome: cros_ec_ishtp: fix crash during suspend (2019-07-29 13:18:45 +0200) chrome-platform fixes for v5.3-rc6 Fixes: 1. platform/chrome: cros_ec_ishtp: fix crash during suspend - Fixes a kernel crash during suspend/resume of cros_ec_ishtp Hyungwoo Yang (1): platform/chrome: cros_ec_ishtp: fix crash during suspend drivers/platform/chrome/cros_ec_ishtp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] iio: cros_ec_accel_legacy: Always release lock when returning from _read()
Hi Matthias,
On Mon, Jul 15, 2019 at 12:10:17PM -0700, Matthias Kaehlcke wrote:
> Before doing any actual work cros_ec_accel_legacy_read() acquires
> a mutex, which is released at the end of the function. However for
> 'calibbias' channels the function returns directly, without releasing
> the lock. The next attempt to acquire the lock blocks forever. Instead
> of an explicit return statement use the common return path, which
> releases the lock.
>
> Fixes: 11b86c7004ef1 ("platform/chrome: Add cros_ec_accel_legacy driver")
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/iio/accel/cros_ec_accel_legacy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
> b/drivers/iio/accel/cros_ec_accel_legacy.c
> index 46bb2e421bb9..27ca4a64dddf 100644
> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> @@ -206,7 +206,8 @@ static int cros_ec_accel_legacy_read(struct iio_dev
> *indio_dev,
> case IIO_CHAN_INFO_CALIBBIAS:
> /* Calibration not supported. */
> *val = 0;
> - return IIO_VAL_INT;
> + ret = IIO_VAL_INT;
> + break;
The value of ret is not used below this. It seems to be only used in
case IIO_CHAN_INFO_RAW. In fact, with your change,
there's no return value at all and we just reach the end of
cros_ec_accel_legacy_read.
> default:
> return -EINVAL;
> }
> --
> 2.22.0.510.g264f2c817a-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] chrome-platform changes for v5.3
|2 +- drivers/mfd/cros_ec.c |6 +- drivers/platform/chrome/Kconfig| 42 +- drivers/platform/chrome/Makefile |4 +- drivers/platform/chrome/cros_ec_debugfs.c | 48 +- drivers/platform/chrome/cros_ec_ishtp.c| 763 drivers/platform/chrome/cros_ec_lightbar.c |6 +- drivers/platform/chrome/cros_ec_lpc.c | 165 +- drivers/platform/chrome/cros_ec_lpc_mec.c | 14 +- drivers/platform/chrome/cros_ec_lpc_reg.c | 101 - drivers/platform/chrome/cros_ec_lpc_reg.h | 45 - drivers/platform/chrome/cros_ec_spi.c | 68 +- drivers/platform/chrome/cros_ec_sysfs.c|2 +- drivers/platform/chrome/cros_ec_vbc.c |2 +- drivers/platform/chrome/wilco_ec/Kconfig | 18 +- drivers/platform/chrome/wilco_ec/Makefile |6 +- drivers/platform/chrome/wilco_ec/core.c| 26 +- drivers/platform/chrome/wilco_ec/debugfs.c | 12 +- drivers/platform/chrome/wilco_ec/event.c | 581 drivers/platform/chrome/wilco_ec/mailbox.c | 21 +- drivers/platform/chrome/wilco_ec/properties.c | 132 + drivers/platform/chrome/wilco_ec/sysfs.c | 156 + drivers/platform/chrome/wilco_ec/telemetry.c | 450 +++ drivers/spi/spi.c | 36 +- include/linux/mfd/cros_ec.h|1 + include/linux/mfd/cros_ec_commands.h | 3658 include/linux/platform_data/wilco-ec.h | 94 +- include/linux/spi/spi.h|2 + sound/soc/codecs/cros_ec_codec.c |8 +- 35 files changed, 5698 insertions(+), 1032 deletions(-) create mode 100644 Documentation/ABI/testing/debugfs-cros-ec create mode 100644 Documentation/ABI/testing/sysfs-platform-wilco-ec create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c delete mode 100644 drivers/platform/chrome/cros_ec_lpc_reg.c delete mode 100644 drivers/platform/chrome/cros_ec_lpc_reg.h create mode 100644 drivers/platform/chrome/wilco_ec/event.c create mode 100644 drivers/platform/chrome/wilco_ec/properties.c create mode 100644 drivers/platform/chrome/wilco_ec/sysfs.c create mode 100644 drivers/platform/chrome/wilco_ec/telemetry.c -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH][next] platform/chrome: wilco_ec: fix null pointer dereference on failed kzalloc
Hi Colin,
On Tue, Jun 18, 2019 at 04:39:24PM +0100, Colin King wrote:
> From: Colin Ian King
>
> If the kzalloc of the entries queue q fails a null pointer dereference
> occurs when accessing q->capacity and q->lock. Add a kzalloc failure
> check and handle the null return case in the calling function
> event_device_add.
>
> Addresses-Coverity: ("Dereference null return")
> Fixes: 75589e37d1dc ("platform/chrome: wilco_ec: Add circular buffer as event
> queue")
> Signed-off-by: Colin Ian King
Applied. Thanks.
Benson
> ---
> drivers/platform/chrome/wilco_ec/event.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/chrome/wilco_ec/event.c
> b/drivers/platform/chrome/wilco_ec/event.c
> index c975b76e6255..e251a989b152 100644
> --- a/drivers/platform/chrome/wilco_ec/event.c
> +++ b/drivers/platform/chrome/wilco_ec/event.c
> @@ -112,8 +112,11 @@ module_param(queue_size, int, 0644);
> static struct ec_event_queue *event_queue_new(int capacity)
> {
> size_t entries_size = sizeof(struct ec_event *) * capacity;
> - struct ec_event_queue *q = kzalloc(sizeof(*q) + entries_size,
> -GFP_KERNEL);
> + struct ec_event_queue *q;
> +
> + q = kzalloc(sizeof(*q) + entries_size, GFP_KERNEL);
> + if (!q)
> + return NULL;
>
> q->capacity = capacity;
> spin_lock_init(>lock);
> @@ -474,6 +477,11 @@ static int event_device_add(struct acpi_device *adev)
> /* Initialize the device data. */
> adev->driver_data = dev_data;
> dev_data->events = event_queue_new(queue_size);
> + if (!dev_data->events) {
> + kfree(dev_data);
> + error = -ENOMEM;
> + goto free_minor;
> + }
> init_waitqueue_head(_data->wq);
> dev_data->exist = true;
> atomic_set(_data->available, 1);
> --
> 2.20.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH][next] platform/chrome: wilco_ec: fix null pointer dereference on failed kzalloc
Hi Nick, On Tue, Jun 18, 2019 at 11:15:03AM -0600, Nick Crews wrote: > Thanks Colin, good catch. > > Enric, could you squash this into the real commit? I've applied this to for-next and for-kernelci in chrome-platform. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: linux-next: Signed-off-by missing for commits in the chrome-platform tree
Hi Stephen,
On Tue, Jun 18, 2019 at 07:46:07AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> 0ac39915c00e ("mfd: cros_ec: Update I2S API")
> 273e4a83784f ("mfd: cros_ec: Add Management API entry points")
> 5fb684b28ddf ("mfd: cros_ec: Add SKU ID and Secure storage API")
> fa1edb8224c9 ("mfd: cros_ec: Add API for rwsig")
> a5a60125c987 ("mfd: cros_ec: Add API for Fingerprint support")
> ff5599529a19 ("mfd: cros_ec: Add API for Touchpad support")
> a97c5892c8cf ("mfd: cros_ec: Add API for EC-EC communication")
> 381041521d3a ("mfd: cros_ec: Add I2C passthru protection API")
> d18e0cde8705 ("mfd: cros_ec: Add Smart Battery Firmware update API")
> e4de049a3892 ("mfd: cros_ec: Add Hibernate API")
> 44f251dc6e69 ("mfd: cros_ec: Add API for keyboard testing")
> 03dc9f7cdc8a ("mfd: cros_ec: Complete Power and USB PD API")
> a704e1450f07 ("mfd: cros_ec: Fix temperature API")
> fa5a714e9d54 ("mfd: cros_ec: Add fingerprint API")
> cbc1d3b7c5a4 ("mfd: cros_ec: Fix event processing API")
> b841c3496d0d ("mfd: cros_ec: Complete MEMS sensor API")
> b4e686e9eecd ("mfd: cros_ec: Add EC transport protocol v4")
> 743875b6af81 ("mfd: cros_ec: Expand hash API")
> 051cf1f83491 ("mfd: cros_ec: Add lightbar v2 API")
> b1bd73c9e90f ("mfd: cros_ec: Add PWM_SET_DUTY API")
> 998b37cad349 ("mfd: cros_ec: Add Flash V2 commands API")
> d8064663d3c4 ("mfd: cros_ec: Remove zero-size structs")
> 036957c19978 ("mfd: cros_ec: move HDMI CEC API definition")
> 0ee2b17ec310 ("mfd: cros_ec: Update ACPI interface definition")
> 6f6db199e544 ("mfd: cros_ec: use BIT macro")
> a5f0ac50978b ("mfd: cros_ec: Define commands as 4-digit UPPER CASE hex
> values")
> de18e8beadcc ("mfd: cros_ec: add ec_align macros")
> bf96c5f1276c ("mfd: cros_ec: set comments properly")
> 6b854d5fbda9 ("mfd: cros_ec: Zero BUILD_ macro")
> 5a0d32c91830 ("mfd: cros_ec: Update license term")
>
> are missing a Signed-off-by from their committer.
>
> These were all rebased.
>
Yup, Enric and I caught this this morning. You're right, this was an inadvertent
rebase. We'll fix the for-next branch for tomorrow.
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
Hi Ting, On Fri, Jun 14, 2019 at 02:54:38PM +0800, Ting Shen wrote: > http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to > the event_type field, the receiver side should mask out this extra bit when > processing the event. > > Signed-off-by: Ting Shen > Reviewed-by: Benson Leung Looks good for chrome-platform, once ib-mfd-cros-v5.3 is merged. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
Hi Dmitry, On Fri, Jun 14, 2019 at 11:55:33AM -0700, Dmitry Torokhov wrote: > On Fri, Jun 14, 2019 at 11:27:03AM -0700, Enrico Granata wrote: > > On Thu, Jun 13, 2019 at 11:54 PM Ting Shen wrote: > > > > > > http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to > > > the event_type field, the receiver side should mask out this extra bit > > > when > > > processing the event. > > > > > > Signed-off-by: Ting Shen > > > > Reviewed-by: Enrico Granata > > EC_MKBP_EVENT_TYPE_MASK is not in Linus' tree. It would be better to > merge this path through whatever tree that is bringing in that > definition. > > Acked-by: Dmitry Torokhov Yup, this looks like it's coming in through Lee's MFD tree, a series from Gwendal to update cros_ec_commands.h. 784dd15c930f mfd: cros_ec: Fix event processing API That commit is in the immutable branch for v5.3 here: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-cros-v5.3 I'd recommend the chrome-platform tree since we'll be pulling in that IB too for some other refactoring Enric is working on. Thanks, Benson > > Thanks. > > -- > Dmitry -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v9 5/7] dt-bindings: Add binding for cros-ec-rpmsg.
On Fri, May 31, 2019 at 03:38:46PM +0800, Pi-Hsun Shih wrote: > Add a DT binding documentation for ChromeOS EC driver over rpmsg. > > Signed-off-by: Pi-Hsun Shih > Acked-by: Rob Herring Reviewed-by: Benson Leung > > --- > Changes from v8, v7, v6: > - No change. > > Changes from v5: > - New patch. > --- > Documentation/devicetree/bindings/mfd/cros-ec.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt > b/Documentation/devicetree/bindings/mfd/cros-ec.txt > index 6245c9b1a68b..4860eabd0f72 100644 > --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt > +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt > @@ -3,7 +3,7 @@ ChromeOS Embedded Controller > Google's ChromeOS EC is a Cortex-M device which talks to the AP and > implements various function such as keyboard and battery charging. > > -The EC can be connect through various means (I2C, SPI, LPC) and the > +The EC can be connect through various means (I2C, SPI, LPC, RPMSG) and the > compatible string used depends on the interface. Each connection method has > its own driver which connects to the top level interface-agnostic EC driver. > Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to > @@ -17,6 +17,9 @@ Required properties (SPI): > - compatible: "google,cros-ec-spi" > - reg: SPI chip select > > +Required properties (RPMSG): > +- compatible: "google,cros-ec-rpmsg" > + > Optional properties (SPI): > - google,cros-ec-spi-pre-delay: Some implementations of the EC need a little > time to wake up from sleep before they can receive SPI transfers at a high > -- > 2.22.0.rc1.257.g3120a18244-goog > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v9 6/7] mfd: cros_ec: differentiate SCP from EC by feature bit.
On Fri, May 31, 2019 at 03:38:47PM +0800, Pi-Hsun Shih wrote:
> System Companion Processor (SCP) is Cortex M4 co-processor on some
> MediaTek platform that can run EC-style firmware. Since a SCP and EC
> would both exist on a system, and use the cros_ec_dev driver, we need to
> differentiate between them for the userspace, or they would both be
> registered at /dev/cros_ec, causing a conflict.
>
> Signed-off-by: Pi-Hsun Shih
Reviewed-by: Benson Leung
>
> ---
> Changes from v8:
> - No change.
>
> Changes from v7:
> - Address comments in v7.
> - Rebase the series onto https://lore.kernel.org/patchwork/patch/1059196/.
>
> Changes from v6, v5, v4, v3, v2:
> - No change.
>
> Changes from v1:
> - New patch extracted from Patch 5.
> ---
> drivers/mfd/cros_ec_dev.c| 10 ++
> include/linux/mfd/cros_ec.h | 1 +
> include/linux/mfd/cros_ec_commands.h | 2 +-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index a5391f96eafd..66107de3dbce 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -440,6 +440,16 @@ static int ec_device_probe(struct platform_device *pdev)
> ec_platform->ec_name = CROS_EC_DEV_TP_NAME;
> }
>
> + /* Check whether this is actually a SCP rather than an EC. */
> + if (cros_ec_check_features(ec, EC_FEATURE_SCP)) {
> + dev_info(dev, "CrOS SCP MCU detected.\n");
> + /*
> + * Help userspace differentiating ECs from SCP,
> + * regardless of the probing order.
> + */
> + ec_platform->ec_name = CROS_EC_DEV_SCP_NAME;
> + }
> +
> /*
>* Add the class device
>* Link to the character device for creating the /dev entry
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index cfa78bb4990f..751cb3756d49 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -27,6 +27,7 @@
> #define CROS_EC_DEV_PD_NAME "cros_pd"
> #define CROS_EC_DEV_TP_NAME "cros_tp"
> #define CROS_EC_DEV_ISH_NAME "cros_ish"
> +#define CROS_EC_DEV_SCP_NAME "cros_scp"
>
> /*
> * The EC is unresponsive for a time after a reboot command. Add a
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index dcec96f01879..8b578b4c1ec7 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -884,7 +884,7 @@ enum ec_feature_code {
> EC_FEATURE_REFINED_TABLET_MODE_HYSTERESIS = 37,
> /* EC supports audio codec. */
> EC_FEATURE_AUDIO_CODEC = 38,
> - /* EC Supports SCP. */
> + /* The MCU is a System Companion Processor (SCP). */
> EC_FEATURE_SCP = 39,
> /* The MCU is an Integrated Sensor Hub */
> EC_FEATURE_ISH = 40,
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2 -next] platform/chrome: cros_ec: Make some symbols static
Hello YueHaibing,
On Thu, May 30, 2019 at 04:49:32PM +0800, YueHaibing wrote:
> Fix sparse warning:
>
> drivers/platform/chrome/cros_ec_debugfs.c:256:30: warning: symbol
> 'cros_ec_console_log_fops' was not declared. Should it be static?
> drivers/platform/chrome/cros_ec_debugfs.c:265:30: warning: symbol
> 'cros_ec_pdinfo_fops' was not declared. Should it be static?
> drivers/platform/chrome/cros_ec_lightbar.c:550:24: warning: symbol
> 'cros_ec_lightbar_attr_group' was not declared. Should it be static?
> drivers/platform/chrome/cros_ec_sysfs.c:338:24: warning: symbol
> 'cros_ec_attr_group' was not declared. Should it be static?
> drivers/platform/chrome/cros_ec_vbc.c:104:24: warning: symbol
> 'cros_ec_vbc_attr_group' was not declared. Should it be static?
> drivers/platform/chrome/cros_ec_lpc.c:408:25: warning: symbol
> 'cros_ec_lpc_pm_ops' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Reviewed-by: Benson Leung
> ---
> v2: fix patch title
> ---
> drivers/platform/chrome/cros_ec_debugfs.c | 4 ++--
> drivers/platform/chrome/cros_ec_lightbar.c | 2 +-
> drivers/platform/chrome/cros_ec_lpc.c | 2 +-
> drivers/platform/chrome/cros_ec_sysfs.c| 2 +-
> drivers/platform/chrome/cros_ec_vbc.c | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c
> b/drivers/platform/chrome/cros_ec_debugfs.c
> index 4c2a27f6a6d0..4578eb3e0731 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -241,7 +241,7 @@ static ssize_t cros_ec_pdinfo_read(struct file *file,
> read_buf, p - read_buf);
> }
>
> -const struct file_operations cros_ec_console_log_fops = {
> +static const struct file_operations cros_ec_console_log_fops = {
> .owner = THIS_MODULE,
> .open = cros_ec_console_log_open,
> .read = cros_ec_console_log_read,
> @@ -250,7 +250,7 @@ const struct file_operations cros_ec_console_log_fops = {
> .release = cros_ec_console_log_release,
> };
>
> -const struct file_operations cros_ec_pdinfo_fops = {
> +static const struct file_operations cros_ec_pdinfo_fops = {
> .owner = THIS_MODULE,
> .open = simple_open,
> .read = cros_ec_pdinfo_read,
> diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
> b/drivers/platform/chrome/cros_ec_lightbar.c
> index d30a6650b0b5..23a82ee4c785 100644
> --- a/drivers/platform/chrome/cros_ec_lightbar.c
> +++ b/drivers/platform/chrome/cros_ec_lightbar.c
> @@ -547,7 +547,7 @@ static struct attribute *__lb_cmds_attrs[] = {
> NULL,
> };
>
> -struct attribute_group cros_ec_lightbar_attr_group = {
> +static struct attribute_group cros_ec_lightbar_attr_group = {
> .name = "lightbar",
> .attrs = __lb_cmds_attrs,
> };
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c
> b/drivers/platform/chrome/cros_ec_lpc.c
> index c9c240fbe7c6..aaa21803633a 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -405,7 +405,7 @@ static int cros_ec_lpc_resume(struct device *dev)
> }
> #endif
>
> -const struct dev_pm_ops cros_ec_lpc_pm_ops = {
> +static const struct dev_pm_ops cros_ec_lpc_pm_ops = {
> SET_LATE_SYSTEM_SLEEP_PM_OPS(cros_ec_lpc_suspend, cros_ec_lpc_resume)
> };
>
> diff --git a/drivers/platform/chrome/cros_ec_sysfs.c
> b/drivers/platform/chrome/cros_ec_sysfs.c
> index fe0b7614ae1b..3edb237bf8ed 100644
> --- a/drivers/platform/chrome/cros_ec_sysfs.c
> +++ b/drivers/platform/chrome/cros_ec_sysfs.c
> @@ -335,7 +335,7 @@ static umode_t cros_ec_ctrl_visible(struct kobject *kobj,
> return a->mode;
> }
>
> -struct attribute_group cros_ec_attr_group = {
> +static struct attribute_group cros_ec_attr_group = {
> .attrs = __ec_attrs,
> .is_visible = cros_ec_ctrl_visible,
> };
> diff --git a/drivers/platform/chrome/cros_ec_vbc.c
> b/drivers/platform/chrome/cros_ec_vbc.c
> index 8392a1ec33a7..2aaefed87eb4 100644
> --- a/drivers/platform/chrome/cros_ec_vbc.c
> +++ b/drivers/platform/chrome/cros_ec_vbc.c
> @@ -101,7 +101,7 @@ static struct bin_attribute *cros_ec_vbc_bin_attrs[] = {
> NULL
> };
>
> -struct attribute_group cros_ec_vbc_attr_group = {
> +static struct attribute_group cros_ec_vbc_attr_group = {
> .name = "vbc",
> .bin_attrs = cros_ec_vbc_bin_attrs,
> };
> --
> 2.17.1
>
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v4 1/2] power: supply: add input power and voltage limit properties
Hi Enric, On Tue, May 07, 2019 at 11:52:47AM +0200, Enric Balletbo i Serra wrote: > For thermal management strategy you might be interested on limit the > input power for a power supply. We already have current limit but > basically what we probably want is to limit power. So, introduce the > input_power_limit property. > > Although the common use case is limit the input power, in some > specific cases it is the voltage that is problematic (i.e some regulators > have different efficiencies at higher voltage resulting in more heat). > So introduce also the input_voltage_limit property. > > This happens in one Chromebook and is used on the Pixel C's thermal > management strategy to effectively limit the input power to 5V 3A when > the screen is on. When the screen is on, the display, the CPU, and the GPU > all contribute more heat to the system than while the screen is off, and > we made a tradeoff to throttle the charger in order to give more of the > thermal budget to those other components. > > So there's nothing fundamentally broken about the hardware that would > cause the Pixel C to malfunction if we were charging at 9V or 12V instead > of 5V when the screen is on, i.e. if userspace doesn't change this. > > What would happen is that you wouldn't meet Google's skin temperature > targets on the system if the charger was allowed to run at 9V or 12V with > the screen on. > > For folks hacking on Pixel Cs (which is now outside of Google's official > support window for Android) and customizing their own kernel and userspace > this would be acceptable, but we wanted to expose this feature in the > power supply properties because the feature does exist in the Emedded > Controller firmware of the Pixel C and all of Google's Chromebooks with > USB-C made since 2015 in case someone running an up to date kernel wanted > to limit the charging power for thermal or other reasons. > > This patch exposes a new property, similar to input current limit, to > re-configure the maximum voltage from the external supply at runtime > based on system-level knowledge or user input. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Guenter Roeck > Acked-by: Adam Thomson Reviewed-by: Benson Leung > --- > > Changes in v4: > - Add also input_power_limit. > > Changes in v3: > - Improve commit log and documentation with Benson comments. > > Changes in v2: > - Document the new property in ABI/testing/sysfs-class-power. > - Add the Reviewed-by Guenter Roeck tag. > > Documentation/ABI/testing/sysfs-class-power | 32 + > Documentation/power/power_supply_class.txt | 4 +++ > drivers/power/supply/power_supply_sysfs.c | 2 ++ > include/linux/power_supply.h| 2 ++ > 4 files changed, 40 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-class-power > b/Documentation/ABI/testing/sysfs-class-power > index 5e23e22dce1b..962a27a1daf8 100644 > --- a/Documentation/ABI/testing/sysfs-class-power > +++ b/Documentation/ABI/testing/sysfs-class-power > @@ -331,10 +331,42 @@ Description: > supply. Normally this is configured based on the type of > connection made (e.g. A configured SDP should output a maximum > of 500mA so the input current limit is set to the same value). > + Use preferably input_power_limit, and for problems that can be > + solved using power limit use input_current_limit. > > Access: Read, Write > Valid values: Represented in microamps > > +What: > /sys/class/power_supply//input_voltage_limit > +Date:May 2019 > +Contact: linux...@vger.kernel.org > +Description: > + This entry configures the incoming VBUS voltage limit currently > + set in the supply. Normally this is configured based on > + system-level knowledge or user input (e.g. This is part of the > + Pixel C's thermal management strategy to effectively limit the > + input power to 5V when the screen is on to meet Google's skin > + temperature targets). Note that this feature should not be > + used for safety critical things. > + Use preferably input_power_limit, and for problems that can be > + solved using power limit use input_voltage_limit. > + > + Access: Read, Write > + Valid values: Represented in microvolts > + > +What:/sys/class/power_supply//input_power_limit > +Date:May 2019 > +Contact: linux...@vger.kernel.org > +Description: > + This entry configures the incoming power limit currently set > +
Re: [PATCH 1/3] iio: common: cros_ec_sensors: support protocol v3 message
ice
> *pdev,
>
> mutex_init(>cmd_lock);
>
> + /* determine what version of MOTIONSENSE CMD EC has */
> + ret = cros_ec_get_host_cmd_version_mask(state->ec,
> + ec->cmd_offset,
> + EC_CMD_MOTION_SENSE_CMD,
> + _mask);
> + if (ret < 0 || ver_mask == 0)
> + return -ENODEV;
> +
> /* Set up the host command structure. */
> - state->msg->version = 2;
> + state->msg->version = fls(ver_mask) - 1;
> state->msg->command = EC_CMD_MOTION_SENSE_CMD + ec->cmd_offset;
> state->msg->outsize = sizeof(struct ec_params_motion_sense);
>
> @@ -66,6 +148,20 @@ int cros_ec_sensors_core_init(struct platform_device
> *pdev,
> }
> state->type = state->resp->info.type;
> state->loc = state->resp->info.location;
> + if (state->msg->version < 3) {
> + get_default_min_max_freq_and_fifo_size(
> + state->resp->info.type,
> + >min_freq,
> + >max_freq,
> + >fifo_max_event_count);
> + } else {
> + state->min_freq =
> + state->resp->info_3.min_frequency;
> + state->max_freq =
> + state->resp->info_3.max_frequency;
> + state->fifo_max_event_count =
> + state->resp->info_3.fifo_max_event_count;
> + }
> }
>
> return 0;
> diff --git a/include/linux/iio/common/cros_ec_sensors_core.h
> b/include/linux/iio/common/cros_ec_sensors_core.h
> index ce16445411ac..4742a9637a85 100644
> --- a/include/linux/iio/common/cros_ec_sensors_core.h
> +++ b/include/linux/iio/common/cros_ec_sensors_core.h
> @@ -78,6 +78,13 @@ struct cros_ec_sensors_core_state {
> unsigned long scan_mask, s16 *data);
>
> int curr_sampl_freq;
> +
> + /* Min and Max Sampling Frequency in mHz */
> + u32 min_freq;
> + u32 max_freq;
> +
> + /* event fifo size represented in number of events */
> + u32 fifo_max_event_count;
> };
>
> /**
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index dcec96f01879..27d71cbf22f1 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -1744,6 +1744,27 @@ struct ec_response_motion_sense {
> uint8_t chip;
> } info;
>
> + /* Used for MOTIONSENSE_CMD_INFO version 3 */
> + struct __ec_todo_unpacked {
> + /* Should be element of enum motionsensor_type. */
> + uint8_t type;
> +
> + /* Should be element of enum motionsensor_location. */
> + uint8_t location;
> +
> + /* Should be element of enum motionsensor_chip. */
> + uint8_t chip;
> +
> + /* Minimum sensor sampling frequency */
> + uint32_t min_frequency;
> +
> + /* Maximum sensor sampling frequency */
> + uint32_t max_frequency;
> +
> + /* Max number of sensor events that could be in fifo */
> + uint32_t fifo_max_event_count;
> + } info_3;
> +
> /* Used for MOTIONSENSE_CMD_DATA */
> struct ec_response_motion_sensor_data data;
>
> --
> 2.20.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v3 00/30] Update cros_ec_commands.h
Hi Lee, On Sat, May 18, 2019 at 07:39:49AM +0100, Lee Jones wrote: > On Fri, 17 May 2019, Gwendal Grignou wrote: > > > Lee, > > > > I verified and merged the changes on the kernels (3.18, 4.4 and 4.14) > > used on chromebook using a squashed version of these patches. > > (crrev.com/c/1583322, crrev.com/c/1583385, crrev.com/c/1583321 > > respectively) > > Please let me know if you have any questions. > > Is no one else from Chromium going to review? > > These seem like quite important changes. > I've gone ahead and acked the whole series. Enric and I are OK with this going in for 5.3, and as Gwendal mentioned, he's landed these changes into our production kernels for Chrome OS as well, so this is what we want to sync on. Let me know if you have any other concerns. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[GIT PULL] chrome-platform changes for v5.2
Hello Linus, The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00: Linux 5.1-rc2 (2019-03-24 14:02:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.2 for you to fetch changes up to 58a2109f6eb46b2952e2ce3fe776ce02c0c540dd: platform/chrome: cros_ec_proto: Add trace event to trace EC commands (2019-04-17 10:29:34 +0200) chrome platform changes for v5.2 CrOS EC: - Add EC host command support using rpmsg - Add new CrOS USB PD logging driver - Transfer spi messages at high priority - Add support to trace CrOS EC commands - Minor fixes and cleanups in protocol and debugfs Wilco EC: - Standardize Wilco EC mailbox interface - Add h1_gpio status to debugfs Douglas Anderson (1): platform/chrome: cros_ec_spi: Transfer messages at high priority Enric Balletbo i Serra (3): platform/chrome: cros_ec_debugfs: Remove dev_warn when console log is not supported platform/chrome: cros_ec_debugfs: no need to check return value of debugfs_create functions platform/chrome: cros_ec_debugfs: Use cros_ec_cmd_xfer_status helper Enrico Granata (1): platform/chrome: cros_ec_proto: check for NULL transfer function Guenter Roeck (1): platform/chrome: Add CrOS USB PD logging driver Nick Crews (2): platform/chrome: wilco_ec: Standardize mailbox interface platform/chrome: wilco_ec: Add h1_gpio status to debugfs Pi-Hsun Shih (1): platform/chrome: cros_ec: Add EC host command support using rpmsg Raul E Rangel (1): platform/chrome: cros_ec_proto: Add trace event to trace EC commands Documentation/ABI/testing/debugfs-wilco-ec | 45 +++-- drivers/platform/chrome/Kconfig | 24 +++ drivers/platform/chrome/Makefile| 7 +- drivers/platform/chrome/cros_ec_debugfs.c | 74 ++-- drivers/platform/chrome/cros_ec_proto.c | 15 ++ drivers/platform/chrome/cros_ec_rpmsg.c | 258 +++ drivers/platform/chrome/cros_ec_spi.c | 80 - drivers/platform/chrome/cros_ec_trace.c | 124 + drivers/platform/chrome/cros_ec_trace.h | 51 ++ drivers/platform/chrome/cros_usbpd_logger.c | 262 drivers/platform/chrome/wilco_ec/debugfs.c | 89 ++ drivers/platform/chrome/wilco_ec/mailbox.c | 53 +++--- drivers/rtc/rtc-wilco-ec.c | 63 --- include/linux/platform_data/wilco-ec.h | 22 +-- 14 files changed, 984 insertions(+), 183 deletions(-) create mode 100644 drivers/platform/chrome/cros_ec_rpmsg.c create mode 100644 drivers/platform/chrome/cros_ec_trace.c create mode 100644 drivers/platform/chrome/cros_ec_trace.h create mode 100644 drivers/platform/chrome/cros_usbpd_logger.c Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] platform/chrome: cros_ec_spi: Always add of_match_table
Hi Evan, On Thu, May 09, 2019 at 11:17:50AM -0700, Evan Green wrote: > The Chrome OS EC driver attaches to devices using the of_match_table > even when ACPI is the underlying firmware. It does this using the > magic PRP0001 ACPI HID, which tells ACPI to go find an OF compatible > string under the hood and match on that. > > The cros_ec_spi driver needs to provide the of_match_table regardless > of whether CONFIG_OF is enabled or not, since the table is used by > ACPI for PRP0001 devices. > > Signed-off-by: Evan Green Looks good to me. Reviewed-by: Benson Leung I'll leave this to Enric to merge to our for-next. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v3 4/4] mfd: cros_ec: instantiate properly CrOS Touchpad MCU device
Hi Enric,
On Mon, Apr 08, 2019 at 11:41:41AM +0200, Enric Balletbo i Serra wrote:
> Support Touchpad MCU as a special of CrOS EC devices. The current
> Touchpad MCU is used on Eve Chromebook and used the same protocol as
> other CrOS EC devices.
>
> When a MCU has touchpad support (aka EC_FEATURE_TOUCHPAD), it is
> instantiated as a special CrOS EC device with device name 'cros_tp'. So
> regardless of the probing order between the actual cros_ec and cros_tp,
> the userspace and other kernel drivers should not confuse them.
>
> Signed-off-by: Wei-Ning Huang
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Benson Leung
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/mfd/cros_ec_dev.c | 10 ++
> include/linux/mfd/cros_ec.h | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 79746e817cdb..be827910e9d0 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -659,6 +659,16 @@ static int ec_device_probe(struct platform_device *pdev)
> ec_platform->ec_name = CROS_EC_DEV_ISH_NAME;
> }
>
> + /* Check whether this is actually a Touchpad MCU rather than an EC */
> + if (cros_ec_check_features(ec, EC_FEATURE_TOUCHPAD)) {
> + dev_info(dev, "CrOS Touchpad MCU detected.\n");
> + /*
> + * Help userspace differentiating ECs from TP MCU,
> + * regardless of the probing order.
> + */
> + ec_platform->ec_name = CROS_EC_DEV_TP_NAME;
> + }
> +
> /*
>* Add the class device
>* Link to the character device for creating the /dev entry
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index b393bd4e4b73..981381fbb3fd 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -26,6 +26,7 @@
> #define CROS_EC_DEV_FP_NAME "cros_fp"
> #define CROS_EC_DEV_ISH_NAME "cros_ish"
> #define CROS_EC_DEV_PD_NAME "cros_pd"
> +#define CROS_EC_DEV_TP_NAME "cros_tp"
>
> /*
> * The EC is unresponsive for a time after a reboot command. Add a
> --
> 2.20.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v3 3/4] mfd: cros_ec: instantiate properly CrOS FP MCU device
Hi Enric,
On Mon, Apr 08, 2019 at 11:41:40AM +0200, Enric Balletbo i Serra wrote:
> Support Fingerprint MCU as a special of CrOS EC devices. The current FP
> MCU uses the same EC SPI protocol v3 as other CrOS EC devices on a SPI
> bus.
>
> When a MCU has fingerprint support (aka EC_FEATURE_FINGERPRINT), it is
> instantiated as a special CrOS EC device with device name 'cros_fp'. So
> regardless of the probing order between the actual cros_ec and cros_fp,
> the userspace and other kernel drivers should not confuse them.
>
> Signed-off-by: Vincent Palatin
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Benson Leung
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/mfd/cros_ec_dev.c | 10 ++
> include/linux/mfd/cros_ec.h | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 1daccd4e05a3..79746e817cdb 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -636,6 +636,16 @@ static int ec_device_probe(struct platform_device *pdev)
> device_initialize(>class_dev);
> cdev_init(>cdev, );
>
> + /* Check whether this is actually a Fingerprint MCU rather than an EC */
> + if (cros_ec_check_features(ec, EC_FEATURE_FINGERPRINT)) {
> + dev_info(dev, "CrOS Fingerprint MCU detected.\n");
> + /*
> + * Help userspace differentiating ECs from FP MCU,
> + * regardless of the probing order.
> + */
> + ec_platform->ec_name = CROS_EC_DEV_FP_NAME;
> + }
> +
> /*
>* Check whether this is actually an Integrated Sensor Hub (ISH)
>* rather than an EC.
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index ce50628aa5e7..b393bd4e4b73 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -23,6 +23,7 @@
> #include
>
> #define CROS_EC_DEV_NAME "cros_ec"
> +#define CROS_EC_DEV_FP_NAME "cros_fp"
> #define CROS_EC_DEV_ISH_NAME "cros_ish"
> #define CROS_EC_DEV_PD_NAME "cros_pd"
>
> --
> 2.20.1
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] mfd: cros_ec: Only register a positive IRQ number
Hi Enrico,
On Thu, Mar 21, 2019 at 02:03:47PM -0700, egran...@chromium.org wrote:
> From: Enrico Granata
>
> Add a layer of sanity checking to cros_ec_register against attempting to
> register IRQ values that are not strictly greater than 0.
>
> Signed-off-by: Enrico Granata
Acked-By: Benson Leung
> ---
> drivers/mfd/cros_ec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 6acfe036d5222..ff8984a2b8c21 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -118,7 +118,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> return err;
> }
>
> - if (ec_dev->irq) {
> + if (ec_dev->irq > 0) {
> err = devm_request_threaded_irq(dev, ec_dev->irq, NULL,
> ec_irq_thread, IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> "chromeos-ec", ec_dev);
> --
> 2.21.0.225.g810b269d1ac-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [BUG] cros_ec_debugfs causes a WARNING trace during suspend on ASUS C201
Hi Guenter, Urja, On Tue, Mar 19, 2019 at 06:37:08AM -0700, Guenter Roeck wrote: > Hi, > > On Tue, Mar 19, 2019 at 3:37 AM Urja Rannikko wrote: > > > > Hi, > > > > I was testing 5.1-rc1 on my C201 when i found this, dmesg of a > > suspend/resume attached. > > > > Based on a quick look at the code it looks like the reason is that the > > suspend and resume calls try to cancel/schedule log_poll_work > > unconditionally but this device doesnt support reading the console log > > so the delayed work struct was never initialized. > > > > Thanks a lot for the note. I'll send a fix later today. > > Guenter > Thanks for the report and quick fix. Guenter's fix has been merged and should be in 5.1-rc2 when Linus cuts it. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[GIT PULL] chrome platform fixes for v5.1-rc2
Hi Linus, The following changes since commit 2794449576a6024e203eca5cc2c1a3ae33102b8e: platform/chrome: fix wilco-ec dependencies (2019-03-05 11:35:46 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-fixes-for-v5.1-rc2 for you to fetch changes up to 57aeef7f7a6848024b92c32bf23e8c85a8ac896d: platform/chrome: cros_ec_debugfs: cancel/schedule logging work only if supported (2019-03-19 11:00:30 -0700) Chrome Platform fixes for v5.1-rc2 Two fixes: 1. platform/chrome: Fix locking pattern in wilco_ec_mailbox() - Closes a potential race condition in the new wilco_ec driver. 2. platform/chrome: cros_ec_debugfs: cancel/schedule logging work only if supported - Fixes a warning in cros_ec_debugfs on systems that do not support console logging, such as the Asus C201. Guenter Roeck (1): platform/chrome: cros_ec_debugfs: cancel/schedule logging work only if supported Nick Crews (1): platform/chrome: Fix locking pattern in wilco_ec_mailbox() drivers/platform/chrome/cros_ec_debugfs.c | 10 +++--- drivers/platform/chrome/wilco_ec/mailbox.c | 2 +- 2 files changed, 8 insertions(+), 4 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] platform/chrome: cros_ec_debugfs: cancel/schedule logging work only if supported
Hi Guenter,
On Tue, Mar 19, 2019 at 09:32:36AM -0700, Guenter Roeck wrote:
> The following traceback was reported on ASUS C201, which does not support
> console logging.
>
> [ cut here ]
> WARNING: CPU: 2 PID: 361 at kernel/workqueue.c:3030 __flush_work+0x38/0x154
> Modules linked in: snd_soc_hdmi_codec cros_ec_debugfs cros_ec_sysfs uvcvideo
> dw_hdmi_cec dw_hdmi_i2s_audio videobuf2_vmalloc cfg80211 gpio_charger
> rk_crypto rfkill videobuf2_memops videobuf2_v4l2 des_generic videobuf2_common
> ofpart m25p80 spi_nor tpm_i2c_infineon sbs_battery mtd tpm joydev cros_ec_dev
> coreboot_table evdev mousedev ip_tables x_tables [last unloaded: brcmutil]
> CPU: 2 PID: 361 Comm: systemd-sleep Not tainted 5.1.0-rc1-1-ARCH+ #1
> Hardware name: Rockchip (Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> [] (dump_stack) from [] (__warn+0xd0/0xec)
> [] (__warn) from [] (warn_slowpath_null+0x38/0x44)
> [] (warn_slowpath_null) from [] (__flush_work+0x38/0x154)
> [] (__flush_work) from []
> (__cancel_work_timer+0x114/0x1a4)
> [] (__cancel_work_timer) from []
> (cros_ec_debugfs_suspend+0x14/0x1c [cros_ec_debugfs])
> [] (cros_ec_debugfs_suspend [cros_ec_debugfs]) from []
> (dpm_run_callback+0x64/0xcc)
> [] (dpm_run_callback) from []
> (__device_suspend+0x174/0x3a8)
> [] (__device_suspend) from [] (dpm_suspend+0x174/0x1e0)
> [] (dpm_suspend) from []
> (suspend_devices_and_enter+0x6c/0x50c)
> [] (suspend_devices_and_enter) from []
> (pm_suspend+0x20c/0x274)
> [] (pm_suspend) from [] (state_store+0x54/0x88)
> [] (state_store) from [] (kernfs_fop_write+0x114/0x180)
> [] (kernfs_fop_write) from [] (__vfs_write+0x1c/0x154)
> [] (__vfs_write) from [] (vfs_write+0xb8/0x198)
> [] (vfs_write) from [] (ksys_write+0x3c/0x74)
> [] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)
> Exception stack(0xe9365fa8 to 0xe9365ff0)
> 5fa0: 0004 beef8b28 0004 beef8b28 0004
> 5fc0: 0004 beef8b28 02319170 0004 beef8b28 0004 b6f3d900 beef8b74
> 5fe0: 006c beef8a98 b6c0adac b6c66534
> ---[ end trace f4ee5df14e8ea0ec ]---
>
> If console logging is not supported, the work structure is never
> initialized, resulting in the traceback. Calling cancel/schedule functions
> conditionally fixes the problem.
>
> While at it, also fix error handling in the probe function.
>
> Reported-by: Urja Rannikko
> Cc: Urja Rannikko
> Fixes: 6fce0a2cf5a05 ("mfd / platform: cros_ec: Move debugfs attributes to
> its own driver")
> Signed-off-by: Guenter Roeck
Looks good. Applied to 5.1-fixes.
Thanks for the quick fix.
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] rtc: cros-ec: Fail suspend/resume if wake IRQ can't be configured
Hi Stephen, On Fri, Mar 15, 2019 at 11:51:12AM -0700, Stephen Boyd wrote: > If we encounter a failure during suspend where this RTC was programmed > to wakeup the system from suspend, but that wakeup couldn't be > configured because the system didn't support wakeup interrupts, we'll > run into the following warning: > > Unbalanced IRQ 166 wake disable > WARNING: CPU: 7 PID: 3071 at kernel/irq/manage.c:669 > irq_set_irq_wake+0x108/0x278 > > This happens because the suspend process isn't aborted when the RTC > fails to configure the wakeup IRQ. Instead, we continue suspending the > system and then another suspend callback fails the suspend process and > "unwinds" the previously suspended drivers by calling their resume > callbacks. When we get back to resuming this RTC driver, we'll call > disable_irq_wake() on an IRQ that hasn't been configured for wake. > > Let's just fail suspend/resume here if we can't configure the system to > wake and the user has chosen to wakeup with this device. This fixes this > warning and makes the code more robust in case there are systems out > there that can't wakeup from suspend on this line but the user has > chosen to do so. > > Cc: Enric Balletbo i Serra > Cc: Evan Green > Cc: Benson Leung > Cc: Guenter Roeck > Signed-off-by: Stephen Boyd Acked-By: Benson Leung -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [GIT PULL] chrome-platform updates for v5.1
Hi Linus, On Tue, Mar 12, 2019 at 09:56:18AM -0700, Linus Torvalds wrote: > On Mon, Mar 11, 2019 at 9:39 PM Benson Leung wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git > > tags/tag-chrome-platform-for-v5.1 > > No diffstat in the pull request? And the shortlog looks truncated too, > with Nick Crews being reported as having four commits, but only two > visible. > > (And yes, there are four commits in the pull itself). > > Finally, you say: > > > 2. Cleanup series between mfd and chrome/platform, moving > >cros-ec attributes from mfd/cros_ec_dev to sub-drivers in > > platform/chrome. > > which I don't see at all in that pull. But that turns out to be > because it already came through the mfd tree. > > Things look otherwise sane and I did the pull, but please fix your > script and/or workflow. The "it already came through the mfd tree" > issue is fine, but diffstat and truncated shortlog is bad. > Sorry about that. There was definitely a workflow issue this time around. I'll nail down what happened. Here is the full pull-request sans-truncation for posterity. The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd: Linux 5.0-rc3 (2019-01-21 13:14:44 +1300) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.1 for you to fetch changes up to 2794449576a6024e203eca5cc2c1a3ae33102b8e: platform/chrome: fix wilco-ec dependencies (2019-03-05 11:35:46 +0100) chrome platform changes for v5.1 1. SPDX identifier cleanup for platform/chrome 2. Cleanup series between mfd and chrome/platform, moving cros-ec attributes from mfd/cros_ec_dev to sub-drivers in platform/chrome. 3. Wilco EC driver 4. Maintainership change to new group repository. Arnd Bergmann (1): platform/chrome: fix wilco-ec dependencies Enric Balletbo i Serra (20): mfd / platform: cros_ec: Use devm_mfd_add_devices mfd / platform: cros_ec: Move lightbar attributes to its own driver mfd / platform: cros_ec: Move vbc attributes to its own driver mfd / platform: cros_ec: Move debugfs attributes to its own driver mfd / platform: cros_ec: Move device sysfs attributes to its own driver mfd / platform: cros_ec_vbc: Instantiate only if the EC has a VBC NVRAM platform/chrome: cros_ec_lightbar: Instantiate only if the EC has a lightbar platform/chrome: cromeos_pstore: switch to SPDX identifier platform/chrome: cros_ec_debugfs: switch to SPDX identifier platform/chrome: cros_ec_lightbar: switch to SPDX identifier platform/chrome: cros_ec_sysfs: switch to SPDX identifier platform/chrome: cros_ec_vbc: switch to SPDX identifier platform/chrome: cros_ec_i2c: switch to SPDX identifier platform/chrome: cros_ec_lpc: switch to SPDX identifier platform/chrome: cros_ec_proto: switch to SPDX identifier platform/chrome: cros_ec_spi: switch to SPDX identifier platform/chrome: cros_kbd_led_backlight: switch to SPDX identifier platform/chrome: cros_ec_lightbar: remove pr_fmt() define platform/chrome: cros_ec_sysfs: remove pr_fmt() define MAINTAINERS: chrome-platform: change the git tree to a chrome-platform group git tree Nick Crews (4): platform/chrome: cros_ec: Remove cros_ec dependency in lpc_mec platform/chrome: Add new driver for Wilco EC platform/chrome: wilco_ec: Add support for raw commands in debugfs platform/chrome: wilco_ec: Add RTC driver Documentation/ABI/testing/debugfs-wilco-ec | 23 ++ Documentation/ABI/testing/sysfs-class-chromeos | 32 +++ .../sysfs-class-chromeos-driver-cros-ec-lightbar | 74 +++ .../sysfs-class-chromeos-driver-cros-ec-vbc| 6 + MAINTAINERS| 2 +- drivers/mfd/Kconfig| 1 - drivers/mfd/cros_ec.c | 14 +- drivers/mfd/cros_ec_dev.c | 89 +++- drivers/mfd/cros_ec_dev.h | 6 - drivers/platform/chrome/Kconfig| 49 - drivers/platform/chrome/Makefile | 9 +- drivers/platform/chrome/chromeos_pstore.c | 17 +- drivers/platform/chrome/cros_ec_debugfs.c | 84 drivers/platform/chrome/cros_ec_i2c.c | 32 +-- drivers/platform/chrome/cros_ec_lightbar.c | 150 +++-- drivers/platform/chrome/cros_ec_lpc.c | 38 ++-- drivers/platform/chrome/cros_ec_lpc_mec.c | 78 --- drivers/platform/chrome/cros_ec_lpc_mec.h | 63 +++--- drivers/platform/chrome/cros_ec_lpc_reg.c
[GIT PULL] chrome-platform updates for v5.1
Hi Linus, The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd: Linux 5.0-rc3 (2019-01-21 13:14:44 +1300) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.1 for you to fetch changes up to 2794449576a6024e203eca5cc2c1a3ae33102b8e: platform/chrome: fix wilco-ec dependencies (2019-03-05 11:35:46 +0100) chrome platform changes for v5.1 1. SPDX identifier cleanup for platform/chrome 2. Cleanup series between mfd and chrome/platform, moving cros-ec attributes from mfd/cros_ec_dev to sub-drivers in platform/chrome. 3. Wilco EC driver 4. Maintainership change to new group repository. Arnd Bergmann (1): platform/chrome: fix wilco-ec dependencies Enric Balletbo i Serra (20): mfd / platform: cros_ec: Use devm_mfd_add_devices mfd / platform: cros_ec: Move lightbar attributes to its own driver mfd / platform: cros_ec: Move vbc attributes to its own driver mfd / platform: cros_ec: Move debugfs attributes to its own driver mfd / platform: cros_ec: Move device sysfs attributes to its own driver mfd / platform: cros_ec_vbc: Instantiate only if the EC has a VBC NVRAM platform/chrome: cros_ec_lightbar: Instantiate only if the EC has a lightbar platform/chrome: cromeos_pstore: switch to SPDX identifier platform/chrome: cros_ec_debugfs: switch to SPDX identifier platform/chrome: cros_ec_lightbar: switch to SPDX identifier platform/chrome: cros_ec_sysfs: switch to SPDX identifier platform/chrome: cros_ec_vbc: switch to SPDX identifier platform/chrome: cros_ec_i2c: switch to SPDX identifier platform/chrome: cros_ec_lpc: switch to SPDX identifier platform/chrome: cros_ec_proto: switch to SPDX identifier platform/chrome: cros_ec_spi: switch to SPDX identifier platform/chrome: cros_kbd_led_backlight: switch to SPDX identifier platform/chrome: cros_ec_lightbar: remove pr_fmt() define platform/chrome: cros_ec_sysfs: remove pr_fmt() define MAINTAINERS: chrome-platform: change the git tree to a chrome-platform group git tree Nick Crews (4): platform/chrome: cros_ec: Remove cros_ec dependency in lpc_mec platform/chrome: Add new driver for Wilco EC Thank you, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [GIT PULL] Immutable branch between MFD and Platform due for the v5.1 merge window
Hi Lee, On Fri, Feb 01, 2019 at 08:19:38AM +, Lee Jones wrote: > Enjoy! > > The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd: > > Linux 5.0-rc3 (2019-01-21 13:14:44 +1300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > ib-mfd-platform-v5.1 > > for you to fetch changes up to fd68bd0f5d4c2090c95f84e27b05d0836bcd6c0c: > > platform/chrome: cros_ec_lightbar: Instantiate only if the EC has a > lightbar (2019-02-01 08:09:27 +) > Looks good. Applied to chrome-platform-5.1. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2] mfd: cros_ec_dev: Return number of bytes read with CROS_EC_DEV_IOCRDMEM
On Wed, Feb 06, 2019 at 06:39:59PM +0100, Enric Balletbo i Serra wrote: > From: Guenter Roeck > > While ioctls normally return a negative error or 0 on success, this is not > the case for CROS_EC_DEV_IOCXCMD in the cros_ec driver, which returns the > number of bytes read instead. However, CROS_EC_DEV_IOCRDMEM in the same > driver does not return the number of byte read on success. This is both > inconsistent and problematic, since the amount of returned data can be > dynamic. Have it return the number of data bytes for consistency. > > Signed-off-by: Guenter Roeck > Signed-off-by: Enric Balletbo i Serra Reviewed-by: Benson Leung > --- > Hi, > > This patch was send long time ago and never landed to mainline [1]. This > is a second attempt. Originally was made to apply on platform/chrome but > after the recent changes we did it should go now throught the MFD > subsystem. Without this patch userspace tools like ectool doesn't work > as expected. > > Best regards, > Enric > > [1] https://lore.kernel.org/patchwork/patch/665211/ > > Changes in v2: > - Adapt and rebase to current mainline. > > drivers/mfd/cros_ec_dev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c > index ed809fc97df8..d275deaecb12 100644 > --- a/drivers/mfd/cros_ec_dev.c > +++ b/drivers/mfd/cros_ec_dev.c > @@ -224,7 +224,7 @@ static long ec_device_ioctl_readmem(struct cros_ec_dev > *ec, void __user *arg) > if (copy_to_user((void __user *)arg, _mem, sizeof(s_mem))) > return -EFAULT; > > - return 0; > + return num; > } > > static long ec_device_ioctl(struct file *filp, unsigned int cmd, > -- > 2.20.1 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: chrome-platform: change the git tree to a chrome-platform group git tree
Hi Enric, On Fri, Feb 01, 2019 at 10:41:33AM +0100, Enric Balletbo i Serra wrote: > Update the git tree URL for Chrome Platform drivers to point to a Chrome > Platform Group managed URL. > > Signed-off-by: Enric Balletbo i Serra Looks good to me. Applied to our chrome-platform-5.1 branch. > --- > > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 51029a425dbe..a3c8b094228c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3675,7 +3675,7 @@ CHROME HARDWARE PLATFORM SUPPORT > M: Benson Leung > M: Enric Balletbo i Serra > S: Maintained > -T: git > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > +T: git > git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git > F: drivers/platform/chrome/ > > CHROMEOS EC SUBDRIVERS > -- > 2.20.1 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[GIT PULL] chrome-platform updates for v4.21
Hi Linus,
Happy new year. Sorry for the late in the window pull request, but here are
the updates for chrome-platform.
Mainly a maintainership change, and a pair of patches from Brian to fixup
wakeup handling for one kind of EC event.
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
tags/tag-chrome-platform-for-v4.21
for you to fetch changes up to cdd6a4a0e2ec590c30ad0e965fa08bf37461cadb:
MAINTAINERS: add maintainers for ChromeOS EC sub-drivers (2019-01-03 12:26:43
-0800)
chrome platform changes for v4.21
Changes for EC_MKBP_EVENT_SENSOR_FIFO handling.
Also, maintainership changes. Olofj out, Enric balletbo in.
Benson Leung (1):
MAINTAINERS: platform/chrome: Add Enric as a maintainer
Brian Norris (2):
platform/chrome: straighten out cros_ec_get_{next,host}_event() error
codes
platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup
Enric Balletbo i Serra (1):
MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
Olof Johansson (1):
MAINTAINERS: platform/chrome: remove myself as maintainer
MAINTAINERS | 11 ++-
drivers/platform/chrome/cros_ec_proto.c | 22 +-
include/linux/mfd/cros_ec.h | 6 --
3 files changed, 31 insertions(+), 8 deletions(-)
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
On Tue, Dec 11, 2018 at 08:09:52PM +0100, Enric Balletbo i Serra wrote: > There are multiple ChromeOS EC sub-drivers spread in different > subsystems, as all of them are related to the Chrome stuff add > Benson and myself as a maintainers for all these sub-drivers. > > Signed-off-by: Enric Balletbo i Serra Signed-off-by: Benson Leung Thanks for sending this, Enric. > --- > > Changes in v2: > - Fix typo in Benson email address. > > MAINTAINERS | 24 > 1 file changed, 24 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a24129b0b043..bbe7180e2851 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3625,6 +3625,30 @@ S: Maintained > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > F: drivers/platform/chrome/ > > +CHROMEOS EC SUBDRIVERS > +M: Benson Leung > +M: Enric Balletbo i Serra > +S: Maintained > +F: Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.txt > +F: Documentation/devicetree/bindings/input/cros-ec-keyb.txt > +F: Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt > +F: Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt > +F: Documentation/devicetree/bindings/mfd/cros-ec.txt > +F: Documentation/ABI/testing/sysfs-bus-iio-cros-ec > +F: drivers/extcon/extcon-usbc-cros-ec.c > +F: drivers/i2c/busses/i2c-cros-ec-tunnel.c > +F: drivers/iio/accel/cros_ec* > +F: drivers/iio/common/cros_ec_sensors/ > +F: drivers/iio/light/cros_ec* > +F: drivers/iio/pressure/cros_ec* > +F: drivers/input/keyboard/cros_ec* > +F: drivers/mfd/cros_ec* > +F: drivers/power/supply/cros_usbpd-charger.c > +F: drivers/pwm/pwm-cros-ec.c > +F: drivers/rtc/rtc-cros-ec.c > +F: include/linux/iio/common/cros_ec_sensors_core.h > +F: include/linux/mfd/cros_ec* > + > CIRRUS LOGIC AUDIO CODEC DRIVERS > M: Brian Austin > M: Paul Handrigan > -- > 2.19.2 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
[PATCH 1/1] MAINTAINERS: platform/chrome: Add Enric as a maintainer
Enric has volunteered to help me with maintaining chrome-platform as we change the development model toward strictly upstream-first for any chrome-platform and cros_ec driver. Signed-off-by: Benson Leung Signed-off-by: Enric Balletbo i Serra --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index a31c3a833763..8293efb566d6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3549,6 +3549,7 @@ F:drivers/input/touchscreen/chipone_icn8505.c CHROME HARDWARE PLATFORM SUPPORT M: Benson Leung +M: Enric Balletbo i Serra S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git F: drivers/platform/chrome/ -- 2.20.0.rc1.387.gf8505762e3-goog
[PATCH 1/1] MAINTAINERS: platform/chrome: Add Enric as a maintainer
Enric has volunteered to help me with maintaining chrome-platform as we change the development model toward strictly upstream-first for any chrome-platform and cros_ec driver. Signed-off-by: Benson Leung Signed-off-by: Enric Balletbo i Serra --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index a31c3a833763..8293efb566d6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3549,6 +3549,7 @@ F:drivers/input/touchscreen/chipone_icn8505.c CHROME HARDWARE PLATFORM SUPPORT M: Benson Leung +M: Enric Balletbo i Serra S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git F: drivers/platform/chrome/ -- 2.20.0.rc1.387.gf8505762e3-goog
Re: [PATCH] MAINTAINERS: platform/chrome: remove myself as maintainer
Hi Olof, On Mon, Nov 26, 2018 at 11:42:59AM -0800, Olof Johansson wrote: > Benson has been maintaining this together with the rest of the kernel > team for a while now, so remove myself from the entry. > It was a pleasure to work with you Olof. Good luck on your next things. :) Enric at Collabora has expressed interest in helping maintain this and help me institute an upstream-first policy for chrome-platform and the other sub drivers. > Signed-off-by: Olof Johansson Applied for v4.21. :) > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b5a72848a3af..57764aa57437 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3547,7 +3547,6 @@ F: drivers/input/touchscreen/chipone_icn8505.c > > CHROME HARDWARE PLATFORM SUPPORT > M: Benson Leung > -M: Olof Johansson > S: Maintained > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > F: drivers/platform/chrome/ > -- > 2.11.0 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: platform/chrome: remove myself as maintainer
Hi Olof, On Mon, Nov 26, 2018 at 11:42:59AM -0800, Olof Johansson wrote: > Benson has been maintaining this together with the rest of the kernel > team for a while now, so remove myself from the entry. > It was a pleasure to work with you Olof. Good luck on your next things. :) Enric at Collabora has expressed interest in helping maintain this and help me institute an upstream-first policy for chrome-platform and the other sub drivers. > Signed-off-by: Olof Johansson Applied for v4.21. :) > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b5a72848a3af..57764aa57437 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3547,7 +3547,6 @@ F: drivers/input/touchscreen/chipone_icn8505.c > > CHROME HARDWARE PLATFORM SUPPORT > M: Benson Leung > -M: Olof Johansson > S: Maintained > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > F: drivers/platform/chrome/ > -- > 2.11.0 > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2 1/2] power: supply: add input voltage limit property.
Hi Pavel, On Sat, Dec 01, 2018 at 04:09:34PM +0100, Pavel Machek wrote: > > I think that handle this via dt / ACPI is not possible for our use case. It > > can > > be a hardware bug or a hardware/user constrain, let me try to explain better > > with an example. > > > > On Pixel C's devices, userspace uses this to set a USB input limit of 5V > > when > > the screen is on for thermal reasons, but those go away when the screen is > > off/system is sleeping, so we allow 9V and 12V levels when sleeping. > > So, on pixel C, what happens if userland ignores the constraint, keeps > display on and sets charger to 12V? I was the software tech lead for the Google Pixel C and was involved in this particular code change in 2015 before the release of the product. So there's nothing fundamentally broken about the hardware that would cause the Pixel C to malfunction if we were charging at 9V or 12V instead of 5V when the screen is on, ie if userspace doesn't change this. This is part of the Pixel C's thermal management strategy to effectively limit the input power to 5V 3A when the screen is on. When the screen is on, the display, the CPU, and the GPU all contribute more heat to the system than while the screen is off, and we made a tradeoff to throttle the charger in order to give more of the thermal budget to those other components. What would happen is that you wouldn't meet Google's skin temperature targets on the system if the charger was allowed to run at 9V or 12V with the screen on. For folks hacking on Pixel Cs (which is now outside of Google's official support window for Android) and customizing their own kernel and userspace this would be acceptable, but we wanted to expose this feature in the power supply properties because the feature does exist in the Emedded Controller firmware of the Pixel C and all of Google's Chromebooks with USB-C made since 2015 in case someone running an up to date kernel wanted to limit the charging power for thermal or other reasons. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2 1/2] power: supply: add input voltage limit property.
Hi Pavel, On Sat, Dec 01, 2018 at 04:09:34PM +0100, Pavel Machek wrote: > > I think that handle this via dt / ACPI is not possible for our use case. It > > can > > be a hardware bug or a hardware/user constrain, let me try to explain better > > with an example. > > > > On Pixel C's devices, userspace uses this to set a USB input limit of 5V > > when > > the screen is on for thermal reasons, but those go away when the screen is > > off/system is sleeping, so we allow 9V and 12V levels when sleeping. > > So, on pixel C, what happens if userland ignores the constraint, keeps > display on and sets charger to 12V? I was the software tech lead for the Google Pixel C and was involved in this particular code change in 2015 before the release of the product. So there's nothing fundamentally broken about the hardware that would cause the Pixel C to malfunction if we were charging at 9V or 12V instead of 5V when the screen is on, ie if userspace doesn't change this. This is part of the Pixel C's thermal management strategy to effectively limit the input power to 5V 3A when the screen is on. When the screen is on, the display, the CPU, and the GPU all contribute more heat to the system than while the screen is off, and we made a tradeoff to throttle the charger in order to give more of the thermal budget to those other components. What would happen is that you wouldn't meet Google's skin temperature targets on the system if the charger was allowed to run at 9V or 12V with the screen on. For folks hacking on Pixel Cs (which is now outside of Google's official support window for Android) and customizing their own kernel and userspace this would be acceptable, but we wanted to expose this feature in the power supply properties because the feature does exist in the Emedded Controller firmware of the Pixel C and all of Google's Chromebooks with USB-C made since 2015 in case someone running an up to date kernel wanted to limit the charging power for thermal or other reasons. Thanks, Benson -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH v2 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup
Hi Brian,
On Wed, Nov 07, 2018 at 06:49:39PM -0800, Brian Norris wrote:
> EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of
> reasons, and there are very few cases in which they should be treated as
> wakeup interrupts (particularly, when a certain
> MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the
> mainline cros_ec_sensor driver yet). Most of the time, they are benign
> sensor readings. In any case, the top-level cros_ec device doesn't know
> enough to determine that they should wake the system, and so it should
> not report the event. This would be the job of the cros_ec_sensors
> driver to parse.
>
> This patch adds checks to cros_ec_get_next_event() such that it doesn't
> signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO.
>
> This patch is particularly relevant on devices like Scarlet (Rockchip
> RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware
> reports sensor events much more frequently. This was causing
> /sys/power/wakeup_count to increase very frequently, often needlessly
> interrupting our ability to suspend the system.
>
> Signed-off-by: Brian Norris
Applied. Thanks!
Benson
> ---
> v1 -> v2:
> * no change
> ---
> drivers/platform/chrome/cros_ec_proto.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index fff67b389c87..cc7baf0ecb3c 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -575,6 +575,7 @@ static int get_keyboard_state_event(struct cros_ec_device
> *ec_dev)
>
> int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event)
> {
> + u8 event_type;
> u32 host_event;
> int ret;
>
> @@ -594,11 +595,22 @@ int cros_ec_get_next_event(struct cros_ec_device
> *ec_dev, bool *wake_event)
> return ret;
>
> if (wake_event) {
> + event_type = ec_dev->event_data.event_type;
> host_event = cros_ec_get_host_event(ec_dev);
>
> - /* Consider non-host_event as wake event */
> - *wake_event = !host_event ||
> - !!(host_event & ec_dev->host_event_wake_mask);
> + /*
> + * Sensor events need to be parsed by the sensor sub-device.
> + * Defer them, and don't report the wakeup here.
> + */
> + if (event_type == EC_MKBP_EVENT_SENSOR_FIFO)
> + *wake_event = false;
> + /* Masked host-events should not count as wake events. */
> + else if (host_event &&
> + !(host_event & ec_dev->host_event_wake_mask))
> + *wake_event = false;
> + /* Consider all other events as wake events. */
> + else
> + *wake_event = true;
> }
>
> return ret;
> --
> 2.19.1.930.g4563a0d9d0-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup
Hi Brian,
On Wed, Nov 07, 2018 at 06:49:39PM -0800, Brian Norris wrote:
> EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of
> reasons, and there are very few cases in which they should be treated as
> wakeup interrupts (particularly, when a certain
> MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the
> mainline cros_ec_sensor driver yet). Most of the time, they are benign
> sensor readings. In any case, the top-level cros_ec device doesn't know
> enough to determine that they should wake the system, and so it should
> not report the event. This would be the job of the cros_ec_sensors
> driver to parse.
>
> This patch adds checks to cros_ec_get_next_event() such that it doesn't
> signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO.
>
> This patch is particularly relevant on devices like Scarlet (Rockchip
> RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware
> reports sensor events much more frequently. This was causing
> /sys/power/wakeup_count to increase very frequently, often needlessly
> interrupting our ability to suspend the system.
>
> Signed-off-by: Brian Norris
Applied. Thanks!
Benson
> ---
> v1 -> v2:
> * no change
> ---
> drivers/platform/chrome/cros_ec_proto.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index fff67b389c87..cc7baf0ecb3c 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -575,6 +575,7 @@ static int get_keyboard_state_event(struct cros_ec_device
> *ec_dev)
>
> int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event)
> {
> + u8 event_type;
> u32 host_event;
> int ret;
>
> @@ -594,11 +595,22 @@ int cros_ec_get_next_event(struct cros_ec_device
> *ec_dev, bool *wake_event)
> return ret;
>
> if (wake_event) {
> + event_type = ec_dev->event_data.event_type;
> host_event = cros_ec_get_host_event(ec_dev);
>
> - /* Consider non-host_event as wake event */
> - *wake_event = !host_event ||
> - !!(host_event & ec_dev->host_event_wake_mask);
> + /*
> + * Sensor events need to be parsed by the sensor sub-device.
> + * Defer them, and don't report the wakeup here.
> + */
> + if (event_type == EC_MKBP_EVENT_SENSOR_FIFO)
> + *wake_event = false;
> + /* Masked host-events should not count as wake events. */
> + else if (host_event &&
> + !(host_event & ec_dev->host_event_wake_mask))
> + *wake_event = false;
> + /* Consider all other events as wake events. */
> + else
> + *wake_event = true;
> }
>
> return ret;
> --
> 2.19.1.930.g4563a0d9d0-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes
Hi Brian,
On Wed, Nov 07, 2018 at 06:49:38PM -0800, Brian Norris wrote:
> cros_ec_get_next_event() is documented to return 0 for success and
> negative for errors. It currently returns negative for some errors, and
> non-negative (number of bytes received) for success (including some "no
> data available" responses as zero). This mostly works out OK, because the
> callers were more or less ignoring the documentation, and only treating
> positive values as success (and indepdently checking the modification of
> 'wakeup').
>
> Let's button this up by avoiding pretending to handle event/wakeup
> distinctions when no event info was retrieved (i.e., returned 0 bytes).
> And fix the documentation of cros_ec_get_host_event() and
> cros_ec_get_next_event() to accurately describe their behavior.
>
> Signed-off-by: Brian Norris
Applied.
Thanks,
Benson
> ---
> v1 -> v2:
> * don't make as many changes to the API -- just fix the documentation
>and a few corner cases instead
> ---
> drivers/platform/chrome/cros_ec_proto.c | 4 ++--
> include/linux/mfd/cros_ec.h | 6 --
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index b6fd4838f60f..fff67b389c87 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -580,7 +580,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
> bool *wake_event)
>
> if (!ec_dev->mkbp_event_supported) {
> ret = get_keyboard_state_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
> return ret;
>
> if (wake_event)
> @@ -590,7 +590,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
> bool *wake_event)
> }
>
> ret = get_next_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
> return ret;
>
> if (wake_event) {
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index e44e3ec8a9c7..de8b588c8776 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -317,7 +317,9 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev);
> * @wake_event: Pointer to a bool set to true upon return if the event might
> be
> * treated as a wake event. Ignored if null.
> *
> - * Return: 0 on success or negative error code.
> + * Return: negative error code on errors; 0 for no data; or else number of
> + * bytes received (i.e., an event was retrieved successfully). Event types
> are
> + * written out to @ec_dev->event_data.event_type on success.
> */
> int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
>
> @@ -329,7 +331,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
> bool *wake_event);
> * events raised and call the functions in the ec notifier. This function
> * is a helper to know which events are raised.
> *
> - * Return: 0 on success or negative error code.
> + * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
> */
> u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
>
> --
> 2.19.1.930.g4563a0d9d0-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes
Hi Brian,
On Wed, Nov 07, 2018 at 06:49:38PM -0800, Brian Norris wrote:
> cros_ec_get_next_event() is documented to return 0 for success and
> negative for errors. It currently returns negative for some errors, and
> non-negative (number of bytes received) for success (including some "no
> data available" responses as zero). This mostly works out OK, because the
> callers were more or less ignoring the documentation, and only treating
> positive values as success (and indepdently checking the modification of
> 'wakeup').
>
> Let's button this up by avoiding pretending to handle event/wakeup
> distinctions when no event info was retrieved (i.e., returned 0 bytes).
> And fix the documentation of cros_ec_get_host_event() and
> cros_ec_get_next_event() to accurately describe their behavior.
>
> Signed-off-by: Brian Norris
Applied.
Thanks,
Benson
> ---
> v1 -> v2:
> * don't make as many changes to the API -- just fix the documentation
>and a few corner cases instead
> ---
> drivers/platform/chrome/cros_ec_proto.c | 4 ++--
> include/linux/mfd/cros_ec.h | 6 --
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index b6fd4838f60f..fff67b389c87 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -580,7 +580,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
> bool *wake_event)
>
> if (!ec_dev->mkbp_event_supported) {
> ret = get_keyboard_state_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
> return ret;
>
> if (wake_event)
> @@ -590,7 +590,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
> bool *wake_event)
> }
>
> ret = get_next_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
> return ret;
>
> if (wake_event) {
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index e44e3ec8a9c7..de8b588c8776 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -317,7 +317,9 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev);
> * @wake_event: Pointer to a bool set to true upon return if the event might
> be
> * treated as a wake event. Ignored if null.
> *
> - * Return: 0 on success or negative error code.
> + * Return: negative error code on errors; 0 for no data; or else number of
> + * bytes received (i.e., an event was retrieved successfully). Event types
> are
> + * written out to @ec_dev->event_data.event_type on success.
> */
> int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
>
> @@ -329,7 +331,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
> bool *wake_event);
> * events raised and call the functions in the ec notifier. This function
> * is a helper to know which events are raised.
> *
> - * Return: 0 on success or negative error code.
> + * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
> */
> u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
>
> --
> 2.19.1.930.g4563a0d9d0-goog
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[PATCH] HID: input: Ignore battery reported by Symbol DS4308
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is almost out of power and warn the user that they need to charge
their wired barcode scanner.
Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
Signed-off-by: Benson Leung
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c0d668944dbe..07f6348b9f86 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1043,6 +1043,7 @@
#define USB_VENDOR_ID_SYMBOL 0x05e0
#define USB_DEVICE_ID_SYMBOL_SCANNER_1 0x0800
#define USB_DEVICE_ID_SYMBOL_SCANNER_2 0x1300
+#define USB_DEVICE_ID_SYMBOL_SCANNER_3 0x1200
#define USB_VENDOR_ID_SYNAPTICS0x06cb
#define USB_DEVICE_ID_SYNAPTICS_TP 0x0001
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index a2f74e6adc70..44ea8e7c71a9 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -325,6 +325,9 @@ static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
USB_DEVICE_ID_ELECOM_BM084),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SYMBOL,
+ USB_DEVICE_ID_SYMBOL_SCANNER_3),
+ HID_BATTERY_QUIRK_IGNORE },
{}
};
--
2.19.1.930.g4563a0d9d0-goog
[PATCH] HID: input: Ignore battery reported by Symbol DS4308
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is almost out of power and warn the user that they need to charge
their wired barcode scanner.
Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
Signed-off-by: Benson Leung
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c0d668944dbe..07f6348b9f86 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1043,6 +1043,7 @@
#define USB_VENDOR_ID_SYMBOL 0x05e0
#define USB_DEVICE_ID_SYMBOL_SCANNER_1 0x0800
#define USB_DEVICE_ID_SYMBOL_SCANNER_2 0x1300
+#define USB_DEVICE_ID_SYMBOL_SCANNER_3 0x1200
#define USB_VENDOR_ID_SYNAPTICS0x06cb
#define USB_DEVICE_ID_SYNAPTICS_TP 0x0001
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index a2f74e6adc70..44ea8e7c71a9 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -325,6 +325,9 @@ static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
USB_DEVICE_ID_ELECOM_BM084),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SYMBOL,
+ USB_DEVICE_ID_SYMBOL_SCANNER_3),
+ HID_BATTERY_QUIRK_IGNORE },
{}
};
--
2.19.1.930.g4563a0d9d0-goog
[GIT PULL] chrome-platform updates for v4.20
Hi Linus,
Please take a look at changes for chrome-platform for v4.20.
Note that there is another move from lee's to mine that we did as an IB.
The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21:
Linux 4.19-rc7 (2018-10-07 17:26:02 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
tags/tag-chrome-platform-for-v4.20
for you to fetch changes up to bc3f4b5c60db2a835e68bfdce23b6ae75df7e295:
platform/chrome: chromeos_tbmc - Remove unneeded const (2018-10-09 22:40:12
-0700)
chrome-platform for v4.20
* Move mfd/cros_ec_lpc* includes to drivers/platform from mfd
* Adding a new interrupt path for cros_ec_lpc
Benson Leung (1):
Merge remote-tracking branch
'origin/ib-chrome-platform-mfd-move-cros_ec_lpc' into working-branch-for-4.20
Emil Karlson (1):
mfd: cros-ec: copy the whole event in get_next_event_xfer
Enric Balletbo i Serra (2):
platform/chrome: Move mfd/cros_ec_lpc* includes to drivers/platform.
mfd: cros_ec: Fix and improve kerneldoc comments.
Enrico Granata (1):
platform/chrome: Add a new interrupt path for cros_ec_lpc
Nathan Chancellor (1):
platform/chrome: chromeos_tbmc - Remove unneeded const
drivers/mfd/cros_ec_dev.h | 13 +-
drivers/platform/chrome/chromeos_tbmc.c| 2 +-
drivers/platform/chrome/cros_ec_lpc.c | 18 +-
drivers/platform/chrome/cros_ec_lpc_mec.c | 3 +-
.../platform/chrome}/cros_ec_lpc_mec.h | 6 +-
drivers/platform/chrome/cros_ec_lpc_reg.c | 3 +-
.../platform/chrome}/cros_ec_lpc_reg.h | 6 +-
drivers/platform/chrome/cros_ec_proto.c| 2 +-
include/linux/mfd/cros_ec.h| 214 ---
include/linux/mfd/cros_ec_commands.h | 295 +
10 files changed, 338 insertions(+), 224 deletions(-)
rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_mec.h (96%)
rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_reg.h (94%)
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
[GIT PULL] chrome-platform updates for v4.20
Hi Linus,
Please take a look at changes for chrome-platform for v4.20.
Note that there is another move from lee's to mine that we did as an IB.
The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21:
Linux 4.19-rc7 (2018-10-07 17:26:02 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
tags/tag-chrome-platform-for-v4.20
for you to fetch changes up to bc3f4b5c60db2a835e68bfdce23b6ae75df7e295:
platform/chrome: chromeos_tbmc - Remove unneeded const (2018-10-09 22:40:12
-0700)
chrome-platform for v4.20
* Move mfd/cros_ec_lpc* includes to drivers/platform from mfd
* Adding a new interrupt path for cros_ec_lpc
Benson Leung (1):
Merge remote-tracking branch
'origin/ib-chrome-platform-mfd-move-cros_ec_lpc' into working-branch-for-4.20
Emil Karlson (1):
mfd: cros-ec: copy the whole event in get_next_event_xfer
Enric Balletbo i Serra (2):
platform/chrome: Move mfd/cros_ec_lpc* includes to drivers/platform.
mfd: cros_ec: Fix and improve kerneldoc comments.
Enrico Granata (1):
platform/chrome: Add a new interrupt path for cros_ec_lpc
Nathan Chancellor (1):
platform/chrome: chromeos_tbmc - Remove unneeded const
drivers/mfd/cros_ec_dev.h | 13 +-
drivers/platform/chrome/chromeos_tbmc.c| 2 +-
drivers/platform/chrome/cros_ec_lpc.c | 18 +-
drivers/platform/chrome/cros_ec_lpc_mec.c | 3 +-
.../platform/chrome}/cros_ec_lpc_mec.h | 6 +-
drivers/platform/chrome/cros_ec_lpc_reg.c | 3 +-
.../platform/chrome}/cros_ec_lpc_reg.h | 6 +-
drivers/platform/chrome/cros_ec_proto.c| 2 +-
include/linux/mfd/cros_ec.h| 214 ---
include/linux/mfd/cros_ec_commands.h | 295 +
10 files changed, 338 insertions(+), 224 deletions(-)
rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_mec.h (96%)
rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_reg.h (94%)
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] platform/chrome: chromeos_tbmc - Remove unneeded const
Hi Nathan,
On Mon, Oct 08, 2018 at 03:20:41PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/platform/chrome/chromeos_tbmc.c:102:14: warning: duplicate
> 'const' declaration specifier [-Wduplicate-decl-specifier]
> static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> ^
> ./include/linux/pm.h:365:56: note: expanded from macro
> 'SIMPLE_DEV_PM_OPS'
> #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
>^
> 1 warning generated.
>
> SIMPLE_DEV_PM_OPS is already declared as const, this one is unnecessary
> so remove it.
>
> Signed-off-by: Nathan Chancellor
Applied for 4.20. Thank you.
Benson
> ---
> drivers/platform/chrome/chromeos_tbmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/chrome/chromeos_tbmc.c
> b/drivers/platform/chrome/chromeos_tbmc.c
> index 1e81f8144c0d..ce259ec9f990 100644
> --- a/drivers/platform/chrome/chromeos_tbmc.c
> +++ b/drivers/platform/chrome/chromeos_tbmc.c
> @@ -99,7 +99,7 @@ static const struct acpi_device_id
> chromeos_tbmc_acpi_device_ids[] = {
> };
> MODULE_DEVICE_TABLE(acpi, chromeos_tbmc_acpi_device_ids);
>
> -static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> +static SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> chromeos_tbmc_resume);
>
> static struct acpi_driver chromeos_tbmc_driver = {
> --
> 2.19.0
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] platform/chrome: chromeos_tbmc - Remove unneeded const
Hi Nathan,
On Mon, Oct 08, 2018 at 03:20:41PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/platform/chrome/chromeos_tbmc.c:102:14: warning: duplicate
> 'const' declaration specifier [-Wduplicate-decl-specifier]
> static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> ^
> ./include/linux/pm.h:365:56: note: expanded from macro
> 'SIMPLE_DEV_PM_OPS'
> #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
>^
> 1 warning generated.
>
> SIMPLE_DEV_PM_OPS is already declared as const, this one is unnecessary
> so remove it.
>
> Signed-off-by: Nathan Chancellor
Applied for 4.20. Thank you.
Benson
> ---
> drivers/platform/chrome/chromeos_tbmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/chrome/chromeos_tbmc.c
> b/drivers/platform/chrome/chromeos_tbmc.c
> index 1e81f8144c0d..ce259ec9f990 100644
> --- a/drivers/platform/chrome/chromeos_tbmc.c
> +++ b/drivers/platform/chrome/chromeos_tbmc.c
> @@ -99,7 +99,7 @@ static const struct acpi_device_id
> chromeos_tbmc_acpi_device_ids[] = {
> };
> MODULE_DEVICE_TABLE(acpi, chromeos_tbmc_acpi_device_ids);
>
> -static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> +static SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> chromeos_tbmc_resume);
>
> static struct acpi_driver chromeos_tbmc_driver = {
> --
> 2.19.0
>
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH v3] mfd: cros-ec: copy the whole event in get_next_event_xfer
Hi Emil,
On Wed, Oct 3, 2018 at 11:43 AM Emil Karlson wrote:
>
> Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard events
> be truncated on many chromebooks so that Left and Right keys on Column 12 were
> always 0. Use ret as memcpy len to fix this.
>
> The old code was using ec_dev->event_size, which is the event payload/data
> size
> excluding event_type header, for the length of the memcpy operation. Use ret
> as memcpy length to avoid the off by one and copy the whole msg->data.
>
> Fixes: 57e94c8b974d ("mfd: cros-ec: Increase maximum mkbp event size")
>
> Acked-by: Enric Balletbo i Serra
> Tested-by: Emil Renner Berthing
> Signed-off-by: Emil Karlson
Applied. Sent to Greg for rc8, hopefully.
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
