From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96CADC47082 for ; Mon, 31 May 2021 12:00:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4C854611CA for ; Mon, 31 May 2021 12:00:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C854611CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nxp.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mnMh7TjwzoCDaUoYAVomh9qdIO86d7TFIGUvxZ+yKS8=; b=KhaVtmRtLICe/c 1YMvQczBa5aUgYmlUaAgSWZboYoQ0yYq5eQTTJRRdFP7XuAPE9TmWllkQvqYwBJa0iHiXwQIzNM36 EG48Cq8/82/quX/BscxZ/ubOY/UJEVy0SN0BSegej0xnZSWppK/TNN+FuqpkqzAJwTGCNWD4/OAk9 5B2NUN1KkSdW1ezj7pK6RgNGKLoBz1ZN/jm0se2Li80gyDVv0Ol2VadXa5gOpPF1VNz9Ri1yUTmYG tmlqEmOIKmCxbwLSYp6n4gZMIA3u7HArsOl5QjcAlqZv6MIVjan16UGqskuxCgp8NurrmDx1TeklL tTsDEBHi6RwA8+UhB1wQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lngZP-00C39L-3t; Mon, 31 May 2021 11:58:59 +0000 Received: from mail-vi1eur05on2068.outbound.protection.outlook.com ([40.107.21.68] helo=EUR05-VI1-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lngZJ-00C37G-UB for linux-arm-kernel@lists.infradead.org; Mon, 31 May 2021 11:58:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A1PqCc4jFf3q/n1hRoS1l30tcPPS4blccVg1stJ1JpONx/5KQzsOHyhZMPU+XGE/Jr5Q0XrAvbo2BByn+y7dgmtIj39Rttn/T6pCVBa3bWNQQLdDY/kuBM/TWUGXTh3MxB6EixYP8X2s5h4lh8qYZ8L9Q+MC/UJBPINH1VPO85x2BrHiiuKyH5+AqSabwOXAtg82GdY3bsthkXGT69AB5C0BYhfNoc/j0QjDCyN/RtoyCjHpJP/Uyqz4c6UCeL9GiauzfT/vgW9PemKEzqipFHZf8CZ3U3tJqbH3znDh8+wnD/wSaDTqByxk+dHZ5bRSqxMJEKaNQh0ebGID3PEWnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9zWu/QKMwxPBQ1OloS7nwz8MwAncrCVXGWggIOnosP8=; b=cIw+SoAOVvKlfu4iC1+3jMg21ynQBwdORbr3sA/9pChjgpTxLSR3DggS5Wr6nDGg1XGBahwWN/sCChT+59a3C+2lXbGCceLBkiMeGje+zEux4N98RguCPwKM34kINlvD1dVxBPGL1JkFwTJv1rUSxx4rt3j4/vMvlT/ZKKzhkzLw1bdQ95/NFQZwvXprH0imaMQT6rjJGrp5cSA3TFAVQdkQXjgb9DeCdqa+272b0mVQUZqVuE2o0C/mQGBUbW9vwM4zTQvrM4gYhAd6654/2gzOwlAtMgxUCDRUGZfAJOAMgbNlr4ReIMqHaFb1Gj1rW+lMV6yHFZM/iH6E8SRW/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9zWu/QKMwxPBQ1OloS7nwz8MwAncrCVXGWggIOnosP8=; b=V3P2cPVJLDjdRRx7Fcolzb+/G8gSCf+LsNxb8NFoJp0nS4mB/AiJckLk8hn13Hk0gdz5/PkGHMYj5+2T1DovHbkMTpuh0ZArM8wJwzyeP/sf9H7Bfan7LEqMKjNrdpasrS1UatSz/KT+U4qYA9OpmF+1nC0KxFS8NtXuTSpEQa4= Received: from VI1PR04MB5935.eurprd04.prod.outlook.com (2603:10a6:803:e9::17) by VI1PR04MB6783.eurprd04.prod.outlook.com (2603:10a6:803:130::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21; Mon, 31 May 2021 11:58:49 +0000 Received: from VI1PR04MB5935.eurprd04.prod.outlook.com ([fe80::453c:f24d:af8e:f194]) by VI1PR04MB5935.eurprd04.prod.outlook.com ([fe80::453c:f24d:af8e:f194%7]) with mapi id 15.20.4173.030; Mon, 31 May 2021 11:58:48 +0000 From: Jun Li To: Heikki Krogerus CC: "robh+dt@kernel.org" , "shawnguo@kernel.org" , "gregkh@linuxfoundation.org" , "linux@roeck-us.net" , "linux-usb@vger.kernel.org" , dl-linux-imx , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "peda@axentia.se" , Hans de Goede Subject: RE: [PATCH 3/4] usb: typec: add typec orientation switch support via mux controller Thread-Topic: [PATCH 3/4] usb: typec: add typec orientation switch support via mux controller Thread-Index: AQHXTIEKNobfiQu7YEKZBxd9HIlDqqrsT64AgAFQdoCAA4FacIAEZREAgAALynA= Date: Mon, 31 May 2021 11:58:48 +0000 Message-ID: References: <1621408490-23811-1-git-send-email-jun.li@nxp.com> <1621408490-23811-4-git-send-email-jun.li@nxp.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: linux.intel.com; dkim=none (message not signed) header.d=none;linux.intel.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca827f4f-b7f5-4f3e-811c-08d9242b7376 x-ms-traffictypediagnostic: VI1PR04MB6783: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u4dJvtxbjVtcq4IvENcTdqfdZhpkp7yFWI0+O8aqhNQKWCImea5kyACviqRgy1bEjN0LYHkFfetWeuGq6w4cOIVCA+V+ygSHE5UZgla6MfyGahHx+iGhWNhNIVBzRe/jzL+aAEdyPviGGqGejWE1QkQMKZr8dApXPIRFkaT/2dqSKUE0dBF/CE/1ZoudL9+aLA2Kbl4fwXm+R+dgWbKKbzP5kbnV2LG34M2n7iis32OjvNZs7XBhpUdH+7LhsebKGxfIK7Z92eRl26DBSkoeLkWpSoPzKrf+9Qgd967vfeBFxR6LBP0tUsvJFIcTPEfR4kBJwi+PR8pX6ovP1HFSd9kqDT+tQgKA9Uyj3KsvvG9rfes7mexZb7Q4ooJdtOP4B3H+UCs6dFMJxaE/t6uV+w713TPLfph+G7QJbkrTXsJ50ul9OsD3zoztmsUBnRO5/OepiygZ3bB2OyZXJQD0WUznmD2EvF4/bOq/+g/YHLJt3hQK+0eQ1nYEWK3El2ur2sxq7nFVKOlCht9t3FkGTAYNsyMADllBd7vcY/vqKVli+1XiKuXZpuzTMJP+UGWX61F9CuMyj/rKSLvYfDIRGBl9VKXVHGs8De9F5C2vBNg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5935.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(376002)(396003)(39850400004)(53546011)(54906003)(7416002)(8936002)(76116006)(478600001)(64756008)(66476007)(66446008)(66556008)(2906002)(86362001)(8676002)(6506007)(71200400001)(316002)(122000001)(66946007)(4326008)(5660300002)(55016002)(26005)(44832011)(9686003)(6916009)(83380400001)(33656002)(186003)(7696005)(38100700002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?RmsR6Ph3XrwOACA7Djm2TwIGCHAw7+QBd6TQG4wqs3PGRRg9rhpuFckd/MJz?= =?us-ascii?Q?LUtep8lJyTBEUYQ6ulBOavmbLQPDTuNh5vairZyJqwpC0s6QAhVKRTIkvYYh?= =?us-ascii?Q?Ul98nV8eDQGrzNGZmiSNyDr2+nhs/xMzkRHuSHYVQVl1wpcG5Z0i/dnJaxZg?= =?us-ascii?Q?a7LWASlC+xHsB7P54b1vgZ6ZWB3wOZveSggxLYvmDmunZ/l7cajAGOvF0oEe?= =?us-ascii?Q?nzTOTZdP9eWTCMpUd5ctLZbnEVcRBB1hGACPDNYldMCNtO7s2aukuqAZgrC4?= =?us-ascii?Q?Ft+sH3lkxLezjRW7/tva4FW+PCAdJBEpcO00fIa23xh9rDbcAOGpUMt6XwlH?= =?us-ascii?Q?Rv03DnJo0DCssOmbA/FBO0Q+ryskYR2QH/xpe90aHEdltpi/NK56AokCgHH6?= =?us-ascii?Q?BeTySXvGCCD1Exb9X59vVGqczirSq77r/MJENjEk9AsxvCL5pwXSrFtdc3QK?= =?us-ascii?Q?xDS+5WGRg+e+7E6t5eRRf0RRwrA6y7rPW8E43pSnphmdCufYtmZsuCoi6yVx?= =?us-ascii?Q?iiPoriiW5DXYhwn4eM1Nwi6AHsAydu5/TKyzHTj4vSPJUJzY5lP0KYtqPn0S?= =?us-ascii?Q?NZ97gyvXS2gYNVHLrN4+rXUZ3D3HW/pBJP/NzrZ+mm7zYfuPK9HGrzCBrP6N?= =?us-ascii?Q?GjpEpZmWSjvBfCxfGqow0lh6TXsq8Bzm20LfQKUqvkUQf6ntpCet6LMeaCok?= =?us-ascii?Q?XKeKEeD3cMw7YnCBRdfWHBoPNyzjJjPauVMkUOkAcaK4rghyKadUWbzfZEBF?= =?us-ascii?Q?KOdj/BqK7t/KWTyiROj1R1qNUtUWR0qTg/0gOuF0ZHoEFy6GWSBDBfT4eg2y?= =?us-ascii?Q?onSum2/cJkpPCmoI4Beritkia6IIIAem0niHe/9x/2dwxrQaJT6w8eFI692m?= =?us-ascii?Q?jfsRx5EZWShf7aWdAz5saOCWDWwWD14tIetaylWFc81C/brjLDLYtsN2S9lE?= =?us-ascii?Q?SkgRET5twc2LC6ZbQNNnkMaJIfdjI6vrWQQqfbZZljTAUvUgbhBhyYYLYSe4?= =?us-ascii?Q?I+g7fpxl0+vkwBw6Edtsi/sMQcykMmKKwz40LZK8nCKotlkhpFr0wL+WwQnj?= =?us-ascii?Q?cBV0SuxKhNkVB5do0wdKJyaZLsjBrzKnc8m+CMZbp1yY2D80vFZrb+aArHlE?= =?us-ascii?Q?5AoxFfaG5JOyexpOFwyE0yyUJ/5ubSM9CIbWNzMEkubCSjYPIHjaMInXIHw/?= =?us-ascii?Q?dA9sI7ZTSTI6WH06Klb7Wrl1LSF3iusun0DV9bo2plvKvWZmRJb1LxJ+lEwB?= =?us-ascii?Q?IFUKkwi5U0pIS8YmaClfM4raaUQNoFjgrfXgJEbw7wSRdbnYMI6R/bEwy4LK?= =?us-ascii?Q?6T9Zdz50AtCdHa5OfpvQ/tyd?= MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5935.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca827f4f-b7f5-4f3e-811c-08d9242b7376 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 11:58:48.7266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y1VC5qJad7ZCz7xG2RbQzOeXVxUu+yWaImZI6deZyYPMB/RG00y37vGfYyUkrVnM X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB6783 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210531_045854_007955_11426ED2 X-CRM114-Status: GOOD ( 59.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > -----Original Message----- > From: Heikki Krogerus > Sent: Wednesday, May 26, 2021 5:16 PM > To: Jun Li > Cc: robh+dt@kernel.org; shawnguo@kernel.org; gregkh@linuxfoundation.org; > linux@roeck-us.net; linux-usb@vger.kernel.org; dl-linux-imx > ; devicetree@vger.kernel.org; > linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH 3/4] usb: typec: add typec orientation switch support > via mux controller > > On Tue, May 25, 2021 at 11:46:18AM +0000, Jun Li wrote: > > Hi Heikki, > > > > > -----Original Message----- > > > From: Heikki Krogerus > > > Sent: Friday, May 21, 2021 4:38 PM > > > To: Jun Li > > > Cc: robh+dt@kernel.org; shawnguo@kernel.org; > > > gregkh@linuxfoundation.org; linux@roeck-us.net; > > > linux-usb@vger.kernel.org; dl-linux-imx ; > > > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org > > > Subject: Re: [PATCH 3/4] usb: typec: add typec orientation switch > > > support via mux controller > > > > > > Hi, > > > > > > On Thu, May 20, 2021 at 03:33:36PM +0300, Heikki Krogerus wrote: > > > > Why not just do that inside fwnode_typec_switch_get() and handle > > > > the whole thing in drivers/usb/typec/mux.c (or in its own file if > > > > you prefer)? > > > > > > > > You'll just need to register a "wrapper" Type-C switch object for > > > > the OF mux controller, but that should not be a problem. That way > > > > you don't need to export any new functions, touch this file or > > > > anything else. > > > > > > I wrote a bit of code just to see how that would look. I'm attaching > > > you the hack I made. I guess something like that would not be too bad. > > > A wrapper is probable always a bit clumsy, but I'm not sure that in > > > this case it's a huge problem. Of course if there are any better > > > ideas, let's here them :-) > > > > Thanks for your patch, I am pasting the patch as below. > > > > seems we need consider more than that. > > > > diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile > > index a0adb8947a301..d85231b2fe10b 100644 > > --- a/drivers/usb/typec/Makefile > > +++ b/drivers/usb/typec/Makefile > > @@ -1,6 +1,7 @@ > > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_TYPEC) += typec.o > > typec-y := class.o mux.o bus.o port-mapper.o > > +typec-$(MULTIPLEXER) += of_mux.o > > obj-$(CONFIG_TYPEC) += altmodes/ > > obj-$(CONFIG_TYPEC_TCPM) += tcpm/ > > obj-$(CONFIG_TYPEC_UCSI) += ucsi/ > > diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c index > > 9da22ae3006c9..282622276d97b 100644 > > --- a/drivers/usb/typec/mux.c > > +++ b/drivers/usb/typec/mux.c > > @@ -63,6 +63,9 @@ struct typec_switch *fwnode_typec_switch_get(struct > > fwnode_handle *fwnode) > > > > sw = fwnode_connection_find_match(fwnode, "orientation-switch", NULL, > > typec_switch_match); > > + if (!sw) > > + sw = of_switch_register(fwnode); > > + > > > > How to support multiple typec_switch_get() for of_mux case? > > the second call to fwnode_typec_switch_get() will get the switch via > > fwnode_connection_find_match()? This means we still need a property > > "orientation-switch" for mux controller node, this seems not the > > expected way for a mux consumer, even with this property, we will get > > a EPROBE_DEFER for the first call. > > > > If we use mux_control_get() for multiple caller/consumer, then we need > > some other device as input. > > > > typec_switch object looks to me is a provider, if we create and > > maintain it in consumer side, I have not come out a better way:-). > > Sorry, but can we rewind a bit: Why can't you just register the orientation > switch from your mux driver and be done with it? You should then be able > to use OF graph, and no special bindings should be needed, no? So we still need a special property for OF graph per discussion on another thread(use device type other than device name for match), and this has to be a mux controller core binding for possible different mux chips (GPIO/MMIO...), register a typec switch if this property exist, but this is the user specific thing from mux controller point view, I feed this is again against DT binding's expectation. > > If you want to reuse a mux-controller driver, then you do need to modify > it (but only a little), and what ever mux-controller specific bindings there > are, you will not use those when the mux supplies the orientation switching > function, instead you'll use the OF graph for that. But surely that is not > a problem? > > The mux-controller framework expects the "consumers" of the muxes to > understand the final function that the mux is used for. The Type-C "mux" > framework (I should not even talk about muxes with those) works the other > way around. Fully agree. > The driver for the component that supplies the orientation switch > function must understand that it is handling that function, and there is > a good reason for doing it that way with the USB Type-C switches. I understand yes if the switch is only part function of the driver. > The > orientation switch for example quite simply is _not_ always a mux. In fact, > it's seems to be rarely a mux these days. With USB4 for example the orientation > is handled almost always by the first on-board retimer. If the mux is only part function of a new driver, use the tyepc "mux" framework and create new binding for the new driver is fine. But if the typec switch control need a dedicated driver to handle, on DT platforms, now mux-controller is the only proposed way to go from binding point view. I am not sure if my case is a normal HW design, but I guess I should not the only user of this kind of situation. > > There are actually also some technical reasons why Hans failed to get the > mux-controller thing to work, which is the original reason why we introduced > the dedicated framework for the Type-C "muxes" (I really should stop talking > about muxes), but I don't remember what was the reason. I checked the patches Hans did, that was mainly to address non-DT platform, I don't see a clear reason why it can't fit DT platform, maybe I missed something. +Hans, It would be great if you can comment on this, thanks. > > In any case, to summarise: the orientation switch is a function. A mux is > a device that can supply that function, and if it does, then the driver for > it really needs to register the dedicated orientation switch. Understand your point, if register the dedicated orientation switch is a must, I feel using general mux control can't make much sense. Thanks Li Jun > > thanks, > > -- > heikki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel