Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp825020pxv; Thu, 22 Jul 2021 13:11:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnmPXe+CJkoabIRH5zaJjVDrNKfIJROZhXIPqk+zlkCgAU8eO9Bu7AmngrLm7hN9Y2rvl7 X-Received: by 2002:a17:907:b0d:: with SMTP id h13mr1452355ejl.279.1626984666831; Thu, 22 Jul 2021 13:11:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626984666; cv=none; d=google.com; s=arc-20160816; b=me24wNO5JTCcFNmP6I1hDlLOxt/AP0blZJBQqR5Cx+3CNDGIhCLjfemsuuiT0a5eoi tijl8JgIjMmvVZt0qnLa9tPLPSiZQgBB3DXpeYhgPEmpDlNlVSj9cNkYMnrzPvrlPYu6 kTa8R1SBBNLrjNZX/OwICWbvnrc1ntRi1jUzlUUfgnP149l70zGE7cizrTQYqLuWxzsO qNCtsSKEkOZ6FsZGwdHJv3QGHdpFSj9QzM6W+Tx3Yrw6LbZT9d3onaXe0w7FoptJbfS4 2c1xhDXxaEFCgWnDZQWCeXEnEw4r2/be8T0QrF+apAQLwIQ7NzxwZ4AceM8QfUAihmVB HItg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2N0Vh8zfm8OFgF7fX9h4wweWlSshRiJnnbrmkg/bTGo=; b=U1r2el0AiPBDO6rjkl45iiyFuUBHzkdUBVaN3ItRdzHG0YYBkI7t4md5VySQcrXbN3 vO0R90cSdkBxAlhPYP76MUdAF2QcId6Kg5WGRUdHQ9O0h/lDpjAqy0VvRek2icqVii1f Cp6meDnOdvSKT9w6SXLF0zCB6AonNCcVKs2Z0bSr/Edd8kdwcwTi5hlLId/JdVSTOp6Q KtdtcUbMtcMuiJScM9trYmqk+6cAu9rE7qVp3yIAQ9iSqpnv6Hkf0ud8T//vQ3e7v0Gc lR8Xdq1d0Dr4F2py60iDziwcBusoXw5rVpZoX3snDjBALarJOvrm7sd9x5/qCJKTvGLj 4wPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=spfOXrAO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r26si28563698ejz.423.2021.07.22.13.10.41; Thu, 22 Jul 2021 13:11:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=spfOXrAO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230079AbhGVT2q (ORCPT + 99 others); Thu, 22 Jul 2021 15:28:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229649AbhGVT2q (ORCPT ); Thu, 22 Jul 2021 15:28:46 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92FE2C061575 for ; Thu, 22 Jul 2021 13:09:19 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id u13so10305268lfs.11 for ; Thu, 22 Jul 2021 13:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2N0Vh8zfm8OFgF7fX9h4wweWlSshRiJnnbrmkg/bTGo=; b=spfOXrAO3yPOl1SfcSxOSufKzLyBB/nbchfZXMZ1GO33uesBhvpV0CQWlz/KJ0z77S hE+M4WmjyCuHYzu1/U4M3tLtF4oVUUi1PnnTPo6Ql1TvdZuILFYnW2H0toCRGSRzBnW/ GbnSboReCVeo1/Hj7TBKRN0BtDj8cn+ybDC/DODa4Pij4v9nb3ssAlUg7zEmWoO4QTn6 tQYFlouBoeIu9/X7X4ybiQHIhXy0tYFe9jfGHbAewxUjTtUlIkp22a4osiq1AMnxIp8V sc+WaI/WHkgwDxDcSlYR0GwDPtQhJilhv9OhGd2lqxUwiSvYLGfVezGVz6pZnPk0C2IG sPpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2N0Vh8zfm8OFgF7fX9h4wweWlSshRiJnnbrmkg/bTGo=; b=oQRNukvM+5x+IUYzim+e4kv7nhjluyqCEIVZcUH+k43pphDXshu3MO9QSRsb1FzGK/ gsCEc+Rvko0XdR1qMpYQqvgFfKoLGyhetSzTBWntQXRtAGvQnEJU2uHGRV9ayhoWbcpL regxoS3GD2IY7IFFpWU5SJNen3ksfBP5JeHdrOm9oavujpr1C/HtqDgAaQwgZtT3+DxR ZZAVuaJETd6MarV4HEp1ULcvVeIrbRSNNCaxT30oBfreKq9oZYK1Pu2jNzVOSnHGM36j w5QArqffGxFM8q0S8YGV350oCtrpga+jtA3JuNPLum2WADy9uWOjayzViBTNPjX82RDg sRLA== X-Gm-Message-State: AOAM5309kb1HJDoiyi5Z06hMCq68BgaP+YVLjWUndPzOy+Vpo9zSu/iv kmz0e6aIUZrfQHZx53w42w+m8+wC2HYxDKpjTdfQqg== X-Received: by 2002:ac2:4a66:: with SMTP id q6mr713798lfp.204.1626984557883; Thu, 22 Jul 2021 13:09:17 -0700 (PDT) MIME-Version: 1.0 References: <20210714124807.o22mottsrg3tv6nt@mobilestation> <20210721100220.ddfxwugivsndsedv@mobilestation> <0064cb2c-5ca6-e693-2e89-8f045c8f7502@kernel.org> <20210721112531.xvu6ni5ksaehsrjh@mobilestation> <20210722181221.xh3r5kyu7zlcojjx@mobilestation> In-Reply-To: From: John Stultz Date: Thu, 22 Jul 2021 13:09:05 -0700 Message-ID: Subject: Re: [PATCH 29/29] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name To: Bjorn Andersson Cc: Serge Semin , Krzysztof Kozlowski , Greg Kroah-Hartman , Rob Herring , Felipe Balbi , Florian Fainelli , Andy Gross , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-arm-msm , Linux USB List , lkml , linux-arm-kernel , Amit Pundir Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 22, 2021 at 12:17 PM Bjorn Andersson wrote: > > On Jul 21, 2021, 1:45 PM +0200, Krzysztof Kozlowski wrote: > > > I had impression that kernel defines interfaces which should be used and > > > are stable (e.g. syscalls, sysfs and so on). This case is example of > > > user-space relying on something not being marked as part of ABI. Instead > > > they found something working for them and now it is being used in "we > > > cannot break existing systems". Basically, AOSP unilaterally created a > > > stable ABI and now kernel has to stick to it. > > > > > > Really, all normal systems depend on aliases or names and here we have > > > dependency on device address. I proposed way how AOSP should be fixed. > > > Anything happened? Nope. > > > > First time he sent a possible solution for the problem: > > https://lore.kernel.org/lkml/20201221210423.GA2504@kozik-lap/ > > > > To sum up you could have used one of the more portable approaches > > 1. add an udc alias to the controller and use it then to refer to the > > corresponding USB controller > > Is there such a thing as "UDC alias"? Or are you suggesting that we > should add such feature? > > I think it would be wonderful if we could identify the UDCs on our > boards as "USB1" and "USB2", or "the one and only USB-C connector". But > unless that will fall back to the existing naming it would break John's > _existing_ userspace. Well, I'd not hold up the existing userspace I'm using as sacrosanct (AOSP devices still usually don't have to work cross-kernel versions - devboards being the main exception). I'm fine if we can rework userland as proposed, so that the issues can be avoided, but I honestly don't have enough context to really understand what that looks like (no idea what udc aliases are). And whatever we do, the main constraint is that userland has to be able to work with existing LTS kernels and newer kernels. > > 2. search through DT-nodes looking for a specific compatible/reg > > DT-properties. > > > > We could define that this is the way, but again we didn't yesterday so > your proposal is not backwards compatible. It may be backwards compatible, but I'm still not clear exactly how it would work. I guess if we look through all sys/bus/platform/devices/*/of_node/compatbile strings for the desired "snps,dwc3", then find which of the directories have the desired address in the string? (The suggestion for looking at reg seems better, but I don't get a char value out of the dwc3 of_node/reg file). It seems much more straightforward to do an `ls /sys/class/udc/$GADGET_ADDR.*` But again, if folks decide the names can be rearranged to usb. in the future, that would break too. thanks -john