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 24123C46467 for ; Mon, 2 Jan 2023 12:11:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232734AbjABMLG (ORCPT ); Mon, 2 Jan 2023 07:11:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232709AbjABMLE (ORCPT ); Mon, 2 Jan 2023 07:11:04 -0500 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EE8F6354 for ; Mon, 2 Jan 2023 04:11:03 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id l29so32626564edj.7 for ; Mon, 02 Jan 2023 04:11:03 -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:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=11NdqoQWvtMGVBH5+YEPkXuBY0lT6IFLrzJv1n1sPnE=; b=AO3QSnKZUCNrin6KCkWVd8Jr2r7Nu/jya+MCUKVa1tD+DS3R5MfhW3456aHMhQtkDQ B7Qn/2IVuIJOUadjcAm8fF1Ye6QqGskK967CV0XcVe56pKe7XiA+p9Mo9+D/mlez+Quc +cszJn/avxfC1ERzeey9Ry1upOtY+I5nfBKehunVnny20UhZ6Dit318Yw4HvTnWJIMsP 2PurGEapYYoEb3eNgQ/qUL6Dxv2KyAKUuNcEvFG0cngKUM2mx17twk0utgOTU5fiVeZJ a9ItXG+gjM/m7D6zdNyoFolrt+btLiuv6hS4sSQOqBeusOP7z5V80gEJPjkq/KykCMRB jC8w== 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:cc: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=11NdqoQWvtMGVBH5+YEPkXuBY0lT6IFLrzJv1n1sPnE=; b=S1pau/uygF1EWJTWy+wsmch67+bCwFIfnX4jBF7+YFaDVTF0etfi7wR+o027fFfyt2 Vj3WAelL/kyutu0d4Am+LdsTKelJChUaTbjM0IguRZOJb7otD1BSHJVJkAkJAP5cdcws iCFEdCh+n0vsuSZOAPwSjCVISrNYjQ9Ln4PV9b82NJSJ/FtT1Rf6IsDkhzW/lb4F0nbl s4P3wCWaBf47hkn/G0zN/9wXf4qaVd2FovUQJvk8iUITavSA/k1yEgWy8uPEl6/F0Nhv oSB5wf/K2HgmXBvHKYTcMYpPb2PVNBz04t+TfIsd/FXko474QIZBFA8xmZF9Gf3IBTSx Ge3w== X-Gm-Message-State: AFqh2krJ5LYxiWhohU7xHiTF06OQ+s2XxesjkDR7GrgtvZO2EkzVBhVA +510cbD5F+J1eOXpWa75PMmxrg== X-Google-Smtp-Source: AMrXdXudBKoxijSiMeNTK/zRwLLjFRAdMIjw+wuQUh3XfFI8ZV6BWdECXCN8vk4IEYwfjIK8Q9wN0g== X-Received: by 2002:a05:6402:1298:b0:461:75f1:9254 with SMTP id w24-20020a056402129800b0046175f19254mr36983003edv.2.1672661461828; Mon, 02 Jan 2023 04:11:01 -0800 (PST) Received: from [192.168.0.104] ([82.77.81.242]) by smtp.gmail.com with ESMTPSA id bc2-20020a056402204200b00467481df198sm12579597edb.48.2023.01.02.04.11.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jan 2023 04:11:01 -0800 (PST) Message-ID: <1ee9cf77-1ca0-6e4e-ba7d-896838bd71de@linaro.org> Date: Mon, 2 Jan 2023 14:11:00 +0200 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 1/8] spi: dt-bindings: Introduce spi-cs-setup-ns property Content-Language: en-US To: Michael Walle Cc: Mark Brown , tudor.ambarus@microchip.com, alexandre.belloni@bootlin.com, claudiu.beznea@microchip.com, devicetree@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org, nicolas.ferre@microchip.com, robh+dt@kernel.org References: <20221117105249.115649-2-tudor.ambarus@microchip.com> <20221118141458.954646-1-michael@walle.cc> <28da9e33-57e8-7ac1-7e6c-13c297a945d6@gmail.com> From: Tudor Ambarus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org On 02.01.2023 13:48, Michael Walle wrote: > Hi, Hi, > > Am 2023-01-02 10:37, schrieb Tudor Ambarus: >> Hi, >> >> On 18.11.2022 17:30, Mark Brown wrote: >>> On Fri, Nov 18, 2022 at 03:14:58PM +0100, Michael Walle wrote: >>>> From: Tudor Ambarus >>> >>>>> +  spi-cs-setup-ns: >>>>> +    description: >>>>> +      Delay in nanosecods to be introduced by the controller after >>>>> CS is >>>>> +      asserted. >>> >>>> Does this need a type as the spi-cs-setup-ns is apparently just >>>> 16bit? At >>>> least the driver uses it that way. >>> >>>> But IMHO this should just be a normal uint32 value to be consistent >>>> with >>>> all the other properties. Also the max value with 16bit will be 'just' >>>> 65us. >>> >>> Making it 32 bit does seem safer.  I've applied the series >> >> Thanks. There are few implications to consider before making this prop a >> u32, and I'd like to check them with you. >> >> struct spi_delay will have to be updated to have a u32 value, now it's a >> u16. This means that we'll have to update spi_delay_to_ns() to either >> return a s64 or to add a u64 *delay parameter to the function so that we >> can still handle the conversions from usecs and the error codes in the >> SPI_DELAY_UNIT_SCK case. Then all its callers have to be updated to >> consider the u64 delay. > > I was talking about the device tree property. Even if the driver continue > to use just 16bit, the DT property could be 32bit IMHO. but then you'll have an implicit cast to u16 at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c#n2314 which will make the u32 dt prop misleading. > > At the moment, the schema says its 32bit (if I'm not mistaken, because > it doesn't have a type), but the driver will parse the property as > 16bit and your device tree also has this /bits/ thingy. So regardless > if the driver is using 16bit or 32bit for the value, there seems to be > a discrepancy between the schema and the devicetree (and driver). okay, thanks for pointing it out. Let's decide how we fix this. > > All other properties are just the regular 32bit values, thus I was > suggesting to change the DT property to 32bit. If we want to change the dt prop to 32bit I think we should also handle the parsed value as u32, not as u16.