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;
From:   "Gervais, Francois" <FGervais@distech-controls.com>
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
CC:     "linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Michael McCormick <michael.mccormick@enatel.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] rtc: pcf85063: add integrity check
Thread-Topic: [PATCH 1/1] rtc: pcf85063: add integrity check
Thread-Index: AQHXFp722WysSQ6OikqG5IlMHahVT6q37BqAgAR8yVyAACw8AIAF5Ri8
Date:   Fri, 23 Apr 2021 15:21:33 +0000
Message-ID: <SN6PR01MB4269E5EDFCAAA1308AF3EE10F3459@SN6PR01MB4269.prod.exchangelabs.com>
References: <20210311174940.23072-1-fgervais@distech-controls.com>
 <YHoKQ9qtupDhXVm3@piout.net>
 <SN6PR01MB4269E7C0A5B2069F96384A6BF3499@SN6PR01MB4269.prod.exchangelabs.com>,<YH3zCjPBk/aRn/jg@piout.net>
In-Reply-To: <YH3zCjPBk/aRn/jg@piout.net>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3013921b-0813-4c7a-4bbd-08d9066b7a40
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2021 15:21:33.1167
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: caadbe96-024e-4f67-82ec-fb28ff53d16d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VYBWgfv+/BZl9qO3ZkZNG0bw+/L6C+57sXPJ/HDe7B1bIFz9XzOqDyYx5P3T3AGviJMtjjEP91gCSXjRczr9Vw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR01MB6608
X-Proofpoint-GUID: bM1F8DHL60tsEUAEvyNIpJfU39o3gLKS
X-Proofpoint-ORIG-GUID: bM1F8DHL60tsEUAEvyNIpJfU39o3gLKS
X-Proofpoint-Processed: True
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501
 phishscore=0 clxscore=1015 bulkscore=0 malwarescore=0 spamscore=0
 mlxlogscore=999 adultscore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2104230099
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>>> I'm not sure I get the use case because PCF85063_REG_CTRL2 should be=0A=
>>> initialized properly after the driver is probed anyway. The other two=
=0A=
>>> can be set from userspace once it detects the oscillator failure which=
=0A=
>>> would be better at deciding the policy anyway.=0A=
>> =0A=
>> Thank you for the feedback I think I understand now.=0A=
>> =0A=
>> We saw the reported problem on devices running kernel v5.4 which doesn't=
=0A=
>> have the common clock framework support and so PCF85063_REG_CTRL2=0A=
>> clkout was not initialized by the kernel and left at hardware default.=
=0A=
>> =0A=
>> I guess with CCF support, if PCF85063_REG_CTRL2 gets corrupted on=0A=
>> power application, on driver probe the clkout value will be set to 0b000=
=0A=
>> or some known default.=0A=
>> =0A=
>> I'm not familiar the CCF, do you know if it's the case that default valu=
es=0A=
>> will be set on boot?=0A=
>=0A=
> The CCF will disable any clocks that are not used on boot so the clock=0A=
> will be either used and configured or not used and disabled.=0A=
=0A=
I see now, thank you for the feedback.=0A=
=0A=
I changed the patch status to "Not Applicable" and archived it.=