Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp324503ybm; Wed, 22 May 2019 03:57:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbEatBeaxwZY3DAALPtEFAZldN5w5sCRctpRQb9eqgdXL9WGxPxEXvzctD+EVtV+G7/dj0 X-Received: by 2002:a65:4006:: with SMTP id f6mr89342366pgp.47.1558522626535; Wed, 22 May 2019 03:57:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558522626; cv=none; d=google.com; s=arc-20160816; b=L2AwA4zf2m8Pac84ASeMwF34h+qrNLl2TxM7MjCTUNHHkEWDikJBdv2Wyxhd9hLbzp dd2Hb1VCwy5pVcG87Ybb5/4APAjNeS4KF2EsJtsFXbgKSdEeridUbMHMlJ2360B6tmER O3uWdxsFZgUof5WLx2cXmcEgVO5Z8lWRUddIu+c6DLJ82nlJiMQVJtKYmFNWARPM4wad 6yfa1WH2kic4sj6bqZfEPxQF3CMpnAaatxGj05I4ecol55kVJgYCURHWoWSsE8j10I/G YewDQvWCWI93qCpbdcXHPwNXlHnG6M2K11SMlU7E05j6Z1ChUeb9SmyHmgZ9G0/hiDlK 4jyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=megNcQ78dH7F5OWFQ88zOgIZTPpIx4cnsx0lTomNSE8=; b=w5JAKI7I08WXc+JK0vbceAu3iaH1A/BdR3X2tR12eyhPVFtNOqzHwRBhlUylHPxiu0 tYbLQDtKPAml6gAHLN+s7SEGA9xwp+ycZMzlHCZ+KgHXRf4IMVDPbtWUPK1O82UZ7V2k De1p3l3fR4SL7ZWhzDhq5LFXcTFCp8OJxz3yUaNfSCe6b7okNxyWx+CsewhS5KyThTWy ua2RJVyjuePfy2+nDEqS5M2ZTfiLl+L/AsgAljv0OZFJPlOZrfaNh8nouZHzww2XAi1X +yOt7l0yECYsQOCtOeHabYhtS41hyAAr/Dj+ppCP3zEygLNbhKqe1xN3PAKTIgB5r068 aftQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4si27432431plm.324.2019.05.22.03.56.51; Wed, 22 May 2019 03:57:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729389AbfEVKyk convert rfc822-to-8bit (ORCPT + 99 others); Wed, 22 May 2019 06:54:40 -0400 Received: from unicorn.mansr.com ([81.2.72.234]:44464 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728925AbfEVKyk (ORCPT ); Wed, 22 May 2019 06:54:40 -0400 Received: by unicorn.mansr.com (Postfix, from userid 51770) id 4946C17102; Wed, 22 May 2019 11:54:38 +0100 (BST) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Marek Szyprowski Cc: linux-usb@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Greg Kroah-Hartman , Bartlomiej Zolnierkiewicz , Markus Reichl , Krzysztof Kozlowski , Peter Chen , Alan Stern , Rob Herring Subject: Re: [PATCH 0/5] Exynos EHCI/OHCI: resolve conflict with the generic USB device bindings References: <20190521115849.9882-1-m.szyprowski@samsung.com> Date: Wed, 22 May 2019 11:54:38 +0100 In-Reply-To: (Marek Szyprowski's message of "Wed, 22 May 2019 08:01:28 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Marek Szyprowski writes: > Hi M?ns > > On 2019-05-21 15:30, M?ns Rullg?rd wrote: >> Marek Szyprowski writes: >>> Dear All, >>> >>> Commit 69bec7259853 ("USB: core: let USB device know device node") added >>> support for attaching devicetree node for USB devices. Those nodes are >>> children of their USB host controller. However Exynos EHCI and OHCI >>> driver bindings already define child-nodes for each physical root hub >>> port and assigns respective PHY controller and parameters to them. This >>> leads to the conflict. A workaround for it has been merged as commit >>> 01d4071486fe ("usb: exynos: add workaround for the USB device bindings >>> conflict"), but it disabled support for USB device binding for Exynos >>> EHCI/OHCI controllers. >>> >>> This patchset tries to resolve this binding conflict by changing Exynos >>> EHCI/OHCI bindings: PHYs are moved from the sub-nodes to a standard array >>> under the 'phys' property. Such solution has been suggested by M?ns >>> Rullg?rd in the following thread: https://lkml.org/lkml/2019/5/13/228 >>> >>> To keep everything working during the transitional time, the changes has >>> been split into 2 steps. First step (patches 1-3) need to be merged before >>> the second one (patches 4-5). Patches from each step can be merged to >>> respective trees without any dependencies - the only requirement is that >>> second step has to be merged after merging all patches from the first one. >>> >>> This patchset has been tested on various Exynos4 boards with different >>> USB host controller configurations (Odroids family: X2, U3, XU3). >>> >>> Best regards >>> Marek Szyprowski >>> Samsung R&D Institute Poland >>> >>> Marek Szyprowski (5): >>> dt-bindings: switch Exynos EHCI/OHCI bindings to use array of generic >>> PHYs >>> ARM: dts: exynos: Add array of generic PHYs to EHCI/OHCI devices >>> usb: exynos: add support for getting PHYs from the standard dt array >>> ARM: dts: exynos: Remove obsolete port sub-nodes from EHCI/OHCI >>> devices >>> usb: exynos: Remove support for legacy PHY bindings >> You could retain compatibility with old devicetrees (which may be >> useful) by using the "phys" property if it exists and falling back >> on the old method if it doesn't. Then you would get this sequence >> of changes: >> >> 1. Update binding definition. >> 2. Support new binding in driver, with fallback to old. >> 3. Switch dts files to new binding. > > This is exactly what I did in this patchset. Until Patch #5 is applied, > Exynos EHCI/OHCI drivers supports both ways of getting PHYs and is fully > compatible with existing DTBs. This last patch should be applied at > least one release later that the first 3 patches to keep everything > working during the -rcX time. I'm suggesting you keep the fallback in the driver. It does no harm, and it's contained in one place. On the dts side, you're adding the new phys property without removing the old-style nodes at first. If you put the driver change first, the dts could be switched to the new style in one patch without a confusing hybrid ever existing. > Compatibility with so called old DTBs is not so important, because there > are no boards with Exynos4 and Exynos5 SoCs, which would not update DTB > together with the kernel zImage. There have been already some > significant compatibility breaks related to those SoCs during last years. You can't possibly know what's out there. Besides, isn't the general policy to not break compatibility without a very good reason? -- M?ns Rullg?rd