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;
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e
Mime-Version: 1.0
Message-Id: <c79e93c3-1678-412f-87c5-2b757d806574@www.fastmail.com>
In-Reply-To: <HK0PR06MB27861518CA84A9DC8D204AC1B28F9@HK0PR06MB2786.apcprd06.prod.outlook.com>
References: <20210922103116.30652-1-chin-ting_kuo@aspeedtech.com>
 <20210922103116.30652-5-chin-ting_kuo@aspeedtech.com>
 <5a235916-f250-48ac-b931-6ec2c5c2ea5d@www.fastmail.com>
 <HK0PR06MB27861518CA84A9DC8D204AC1B28F9@HK0PR06MB2786.apcprd06.prod.outlook.com>
Date:   Mon, 08 Nov 2021 10:51:48 +1030
From:   "Andrew Jeffery" <andrew@aj.id.au>
To:     "Chin-Ting Kuo" <chin-ting_kuo@aspeedtech.com>,
        "Rob Herring" <robh+dt@kernel.org>,
        "Joel Stanley" <joel@jms.id.au>,
        "Ulf Hansson" <ulf.hansson@linaro.org>
Cc:     BMC-SW <BMC-SW@aspeedtech.com>,
        "Steven Lee" <steven_lee@aspeedtech.com>,
        "Michael Turquette" <mturquette@baylibre.com>,
        "Stephen Boyd" <sboyd@kernel.org>,
        "Adrian Hunter" <adrian.hunter@intel.com>,
        "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
        "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
        linux-mmc <linux-mmc@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Subject: Re: [PATCH 04/10] mmc: Add invert flag for clock phase signedness
Content-Type: text/plain
Precedence: bulk

On Sat, 6 Nov 2021, at 20:32, Chin-Ting Kuo wrote:
> Hi Andrew,
>>> > -	rc = device_property_read_u32_array(dev, prop, degrees, 2);
>> > +	rc = device_property_read_u32_array(dev, prop, degrees, 4);
>> >  	phase->valid = !rc;
>> >  	if (phase->valid) {
>> > -		phase->in_deg = degrees[0];
>> > -		phase->out_deg = degrees[1];
>> > +		phase->inv_in_deg = degrees[0] ? true : false;
>> > +		phase->in_deg = degrees[1];
>> > +		phase->inv_out_deg = degrees[2] ? true : false;
>> > +		phase->out_deg = degrees[3];
>> 
>> This fundamentally breaks any in-tree users. We can't do this.
>> 
>> In terms of the binding, if negative phase values are something we must do,
>> we can just extend the value range to include [-359, -1] right?
>
> Yes, agree it and I tried it before. But, it seems that the device tree 
> doesn't support
> negative value with "-" prefixed and there is no device tree related 
> API used to get
> the negative value from .dts. Thus, I tried to add an additional flag 
> to present
> negative value.
>

Hmm. Still, I don't think we can break the binding this way.

Rob, Ulf, Adrian: What are your thoughts on handling phase offsets in 
[-360, 360] in the binding? Do we append the flag field? Add a separate 
property? I don't think interleaving the flags is desirable, though 
interested in your thoughts.

Andrew