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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 244EBC43217 for ; Tue, 8 Nov 2022 11:30:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233936AbiKHLap (ORCPT ); Tue, 8 Nov 2022 06:30:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233896AbiKHLao (ORCPT ); Tue, 8 Nov 2022 06:30:44 -0500 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAD9710FC0 for ; Tue, 8 Nov 2022 03:30:42 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id d20so20618166ljc.12 for ; Tue, 08 Nov 2022 03:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Df/2yQeWb1d9To2ggEgy9JGgAa1dKPEwPJTnp7RFKKI=; b=EGFgZfWK7iun8X4qrBI1QRrVUzXrZHgr2HFTDssPuXHld6e8Xff5dU+7CK6LgoZcKj VssQGbAgiwR9Gzn3En0qjbNygDiU+SR1mlKF773u8yeQjlcMYsBcBWen7rJGWtLa5Vwe GDDdv0ND0P0qgO4+rk5YfUdGa6HupktHiuwh05B3qfqYD9ew/E7bbwSiOsKESe9ZUo/y u+gGusZQi8Gp2XOH36SN6AATQzDVT3HlIEfFzGpnCuGaHzS1kitrfKBRiliff+su6GC6 7csYZ1r6Ksqe/Vvcf96JWHr3OzVSLAaD94108//PzpeM1OOMi1YEGxVGRg8Hh9BgEsIG mv4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Df/2yQeWb1d9To2ggEgy9JGgAa1dKPEwPJTnp7RFKKI=; b=eYv0c37KeUzrDcUL7Jz3vpSPutV8VZPgkYwRTz59V2d6noQmHRTDQkNIgpUyXOq8uA CTQHDA54Jn6/2GQ0tAvOON09xsTbG+bbC+UzLXRZK5JuFD2Eh8GhZzx7EXiknpMJD9Mw Cu28Lerhwa2F4T+mQAkjZ4sOBPsQlw1CQ9pguAslmDOx6amMi8UTu/3RV3I5RqCrFUX8 qCNX0+QIVp8Fys3Ovg+8ZQP9+T9j5lNhwZjUA+6jMIv14nQnkzqO4KZtkawsn/dRCKdN 6ZNxE0fsA8JYTmd7qjNpPkBhuITpSAMTNMo0DalsI3FkYf8MKmqubCwdbo+aAK8xaO6y hq1Q== X-Gm-Message-State: ACrzQf1uIuqjJ8ncNKLigkgmPmsVqfDuX+XWBURvLfG0L+AHqTG99TyC O8Xsf8eIr6H0Gzp68AP1VJkgEQ== X-Google-Smtp-Source: AMsMyM4e3RprgOpTHPLpEtvIddL3m+QxWSPCTr4lHwgBI3qmC3SEGP42bF556j32ASbvjV3XzlbtRg== X-Received: by 2002:a2e:550:0:b0:277:e8c:a5a4 with SMTP id 77-20020a2e0550000000b002770e8ca5a4mr7011231ljf.311.1667907040968; Tue, 08 Nov 2022 03:30:40 -0800 (PST) Received: from [192.168.0.20] (088156142199.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.199]) by smtp.gmail.com with ESMTPSA id n1-20020ac24901000000b004971a83f839sm1744968lfi.39.2022.11.08.03.30.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 03:30:40 -0800 (PST) Message-ID: Date: Tue, 8 Nov 2022 12:30:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v1 2/7] dt-bindings: usb: hpe,gxp-udc: Add binding for gxp gadget Content-Language: en-US To: "Yu, Richard" , "Verdun, Jean-Marie" , "Hawkins, Nick" , "gregkh@linuxfoundation.org" , "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "linux@armlinux.org.uk" , "balbi@kernel.org" , "linux-usb@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" References: <20221103160625.15574-1-richard.yu@hpe.com> <20221103160625.15574-3-richard.yu@hpe.com> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 07/11/2022 21:16, Yu, Richard wrote: > Hi Mr. Kozlowski, > >>> + >>> + vdevnum: >>> + description: >>> + virtual device number. > >> That's unusual property... Why numbering devices is part of DT (hardware description)? > > In HPE GXP virtual EHCI controller chipset, it can support up to 8 virtual devices(gadgets). Each device/gadget will be represented by a bit in 8 bits register. For example, the interrupt register bit 0 indicates the interrupt from device 0, bit 1 for device 1 ... so on. When a user defines a device/gadget, he/she can define the device number as between 0 and 7. Thus, the driver can look up to the bit position. That is why we have numbering devices as part of DT. Wrap your lines properly, it's impossible to reply in-line to such messages. Then how do you specify two devices? You allow here only one, right? Which bit in which register? Your devices have separate address space, so why they cannot poke the same register, right? Then just always set it to 0... I might miss here something but so far it looks to me like some hacky description matching the driver, not hardware, not existing bindings. > >>> + >>> + fepnum: >>> + description: >>> + number of the flexible end-points this device is needed. > >> Similar question. > > In HPE GXP virtual EHCI Controller chipset, there is a flexible End-Point(EP) pool. Each flexible EP has its own mapping register. The mapping register bit 0 to 3 is for device number (vdevnum) and bit 4 to 7 is for EP number inside the device. The device driver configures the mapping register to assign a flexible EP to a specific device. Here, "fepnum" is the input letting the driver know how many EPs are needed for this device/gadget. Nope. So you create here some weird IDs to poke into syscon register. First, syscon has offset if you need. You could treat it maybe as bits? I don't know... but even then your design is poor - two devices changing the same register. Even though it is sunchronized by regmap, it is conflicting, obfuscated access. Best regards, Krzysztof