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 C0E42C61DA4 for ; Sun, 5 Mar 2023 09:49:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229614AbjCEJtQ (ORCPT ); Sun, 5 Mar 2023 04:49:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjCEJtP (ORCPT ); Sun, 5 Mar 2023 04:49:15 -0500 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 566D8CDD8 for ; Sun, 5 Mar 2023 01:49:13 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id s11so26917886edy.8 for ; Sun, 05 Mar 2023 01:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678009752; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=i1NXWkshbGfkpUPFum76bHknO/vpxYG/pfk6G3wkE88=; b=f28fzSBPdgs5Vsb2eBhafb9P8Iqi42pAXvvHC7L57u9epmuuckD3RLBz/3lG9XnZIw lRCSB1mUeoyoY+ow1Ly0K8DoVHnaGj2t+J97AeLA1OT03/nn+Ddnb4p6YzfPOofKOYPI 7bD8AfVZs1+YrbglfnVA04eIHswEP+EM7XPZlGBnoQbhA3rBDnpq7OfvXIScCwNCNgLz c3DzpW0+VMEzPbI4/HSMK7s9pV/IvSbJY1q0PIE9HXqn/lySdr81a9M6sOD4W51All0p i40QrQmFWlbaAnEpS3T0Jd6MDwxUu21YAIQKCJrv8XeMPeVzbE1Jj7pjWuopBgj+8N3J IamA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678009752; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=i1NXWkshbGfkpUPFum76bHknO/vpxYG/pfk6G3wkE88=; b=rXpuRiMgkBIszYVzMvf6pBxCSErjXqXVHKBPjdtVjSJWJMD0f0oFrpaze4pefBWIKx RKTME+yyvZIdKCRM7vxY5A49iqW0hCTtVL+J/GSassnOVflnDDH1u0bV8n1shFtng93k I9pKp7F+9U+RXRSI5kpbum2rNggYk7rd1Bc7bd5edvyq/eGUTLj2+IG6dkNNn44TxPaN BqGeQfyPf7zyGsMb4wRlh8kiordmZkFiYFmJ7wLsk+vROXyuugW1GCSvF+woDSVcDsxh AJbitU7D27M5F49gMgkF91il+eEY4Fmpcqv25TKz/DbZkRJsoC+xvRi+7mx2Z6aSqUnF q46w== X-Gm-Message-State: AO0yUKVkAugWAQIwf8u99nf6Xs9Qb/oLtA2JR6dZzsFr3jN2X7w6kN3M 5ii+egxsSjyqdYuEFk2pIzw1BoUh2R3oGwziVdQ= X-Google-Smtp-Source: AK7set/RzEpkk4lrGOln6MgcBlaSXb7zQQnXLiHe5Cc4QQ0OSXcLQu4ok9B1u/IwUOSEJ++kxYvapw== X-Received: by 2002:a17:906:178f:b0:878:72d0:2817 with SMTP id t15-20020a170906178f00b0087872d02817mr7044006eje.29.1678009751796; Sun, 05 Mar 2023 01:49:11 -0800 (PST) Received: from ?IPV6:2a02:810d:15c0:828:71e7:13d:1c29:505f? ([2a02:810d:15c0:828:71e7:13d:1c29:505f]) by smtp.gmail.com with ESMTPSA id t16-20020a170906949000b008b30e2a450csm3058517ejx.144.2023.03.05.01.49.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Mar 2023 01:49:11 -0800 (PST) Message-ID: Date: Sun, 5 Mar 2023 10:49:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 To: Ryan Chen , Wolfram Sang Cc: Joel Stanley , Brendan Higgins , Krzysztof Kozlowski , Andrew Jeffery , "devicetree@vger.kernel.org" , Philipp Zabel , Rob Herring , Benjamin Herrenschmidt , "linux-aspeed@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "openbmc@lists.ozlabs.org" , "linux-i2c@vger.kernel.org" References: <20230226031321.3126756-1-ryan_chen@aspeedtech.com> <20230226031321.3126756-2-ryan_chen@aspeedtech.com> <53090449-58c9-bc03-56df-aa8ae93c0c26@linaro.org> Content-Language: en-US From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 04/03/2023 02:33, Ryan Chen wrote: > Hello Krzysztof, > >> -----Original Message----- >> From: Krzysztof Kozlowski >> Sent: Friday, March 3, 2023 6:41 PM >> To: Ryan Chen ; Wolfram Sang >> >> Cc: Joel Stanley ; Brendan Higgins >> ; Krzysztof Kozlowski >> ; Andrew Jeffery ; >> devicetree@vger.kernel.org; Philipp Zabel ; Rob >> Herring ; Benjamin Herrenschmidt >> ; linux-aspeed@lists.ozlabs.org; >> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; >> openbmc@lists.ozlabs.org; linux-i2c@vger.kernel.org >> Subject: Re: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 >> >> On 03/03/2023 11:16, Ryan Chen wrote: >>>>>>>>> aspeed,timout properites: >>>>>>>>> For example I2C controller as slave mode, and suddenly >>>> disconnected. >>>>>>>>> Slave state machine will keep waiting for master clock in for >>>>>>>>> rx/tx >>>>>> transmit. >>>>>>>>> So it need timeout setting to enable timeout unlock controller state. >>>>>>>>> And in another side. In Master side also need avoid suddenly >>>>>>>>> slave >>>>>>>> miss(un-plug), Master will timeout and release the SDA/SCL. >>>>>>>>> >>>>>>>>> Do you mean add those description into ore aspeed,timout >>>>>>>>> properites >>>>>>>> description? >>>>>>>> >>>>>>>> You are describing here one particular feature you want to enable >>>>>>>> in the driver which looks non-scalable and more difficult to >>>> configure/use. >>>>>>>> What I was looking for is to describe the actual configuration >>>>>>>> you have >>>> (e.g. >>>>>>>> multi-master) which leads to enable or disable such feature in >>>>>>>> your >>>>>> hardware. >>>>>>>> Especially that bool value does not scale later to actual timeout >>>>>>>> values in time (ms)... >>>>>>>> >>>>>>>> I don't know I2C that much, but I wonder - why this should be >>>>>>>> specific to Aspeed I2C and no other I2C controllers implement it? >>>>>>>> IOW, this looks quite generic and every I2C controller should >>>>>>>> have it. Adding it specific to Aspeed suggests that either we >>>>>>>> miss a generic property or this should not be in DT at all >>>>>>>> (because no one else has >>>>>> it...). >>>>>>>> >>>>>>>> Also I wonder, why you wouldn't enable timeout always... >>>>>>>> >>>>>>>> +Cc Wolfram, >>>>>>>> Maybe you know whether bool "timeout" property for one controller >>>>>>>> makes sense? Why we do not have it for all controllers? >>>>>>>> >>>>>>> Because, i2c bus didn’t specific timeout. >>>>>>> But SMBus defines a clock low time-out, TIMEOUT of 35 ms. >>>>>>> >>>>>>> It have definition in SMBus specification. >>>>>>> http://smbus.org/specs/SMBus_3_1_20180319.pdf >>>>>>> You can check Page 18, Note3 that have timeout description. >>>>>> >>>>>> Then you have already property for this - "smbus"? >>>>> To be a property "smbus", that would be a big topic, I saw fsl i2c >>>>> also have this. >>>>> https://github.com/torvalds/linux/blob/master/Documentation/devicetr >>>>> ee >>>>> /bindings/i2c/i2c-mpc.yaml#L43-L47 >>>>> So, I just think the "timeout" property. >>>> >>>> Yeah and this is the only place. It also differs because it allows >>>> actual timeout values. >>> Thanks, So can I still keep the property "aspeed,timeout" here? >>> It is the only place. >> >> No, because none of my concerns above are addressed. >> > Thanks, I realize your concerns. > > So, I modify it like i2c-mpc.yaml > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml#L43-L47 > > aspeed,timeout: > $ref: /schemas/types.yaml#/definitions/uint32 > description: | > I2C bus timeout in microseconds > Is this way acceptable? So, let's repeat my last questions: 1. Why you wouldn't enable timeout always... You wrote: > http://smbus.org/specs/SMBus_3_1_20180319.pdf > You can check Page 18, Note3 that have timeout description. which indicates you should always use timeout, doesn't it? 2. Why we do not have it for all controllers with SMBus v3? Why this one is special? Best regards, Krzysztof