Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
From:   Biju Das <biju.das.jz@bp.renesas.com>
To:     Thomas Gleixner <tglx@linutronix.de>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>
CC:     John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,
        Douglas Anderson <dianders@chromium.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Biju Das <biju.das.au@gmail.com>,
        "linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-renesas-soc@vger.kernel.org" 
        <linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH v2] alarmtimer: Fix rebind failure
Thread-Topic: [PATCH v2] alarmtimer: Fix rebind failure
Thread-Index: AQHZ7SyA4lmrPv0tQ0OIkUBZ8XwsyrBBqzEAgAAC0jCAAAcKAIAAFRaggABTdwCAAIkS4A==
Date:   Tue, 10 Oct 2023 06:18:09 +0000
Message-ID: <TYCPR01MB11269FF2DBFDC96B9C12D2E5E86CDA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
References: <20230922081208.26334-1-biju.das.jz@bp.renesas.com>
 <87il7fq1al.ffs@tglx>
 <TYCPR01MB112697A5D4B57101CDE27C88D86CEA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <87fs2jpznr.ffs@tglx>
 <TYCPR01MB11269C6BF3934F9AAC44F855186CEA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <87bkd7pic3.ffs@tglx>
In-Reply-To: <87bkd7pic3.ffs@tglx>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?TzM7dPAT/OhqEKGbMsRFw8vNVEuvjv1Z5DLo33AIClViAfYgkFCs+2chOWAf?=
 =?us-ascii?Q?ZQKTxBgcvn53YD4pfmPksAWy4jbn+xkpTBDccYIFQI3zzZXueunjOy+2MV1U?=
 =?us-ascii?Q?JAFkCkVJpuSM6cxDErwww0LgOoCMnLK+f8GxAh4Cn6gY/poHui6CRXCN3B04?=
 =?us-ascii?Q?tCC/se/jUIRwgbdV128oR/83hf7OoDqajGNuIDR2okhw5DYueu9h2NPSaIvH?=
 =?us-ascii?Q?Tmg11nRLTF7iTiiN6tXii5tRFtW3c1xl2QmcS1VGxOhQlpB7LT/BoYWV1tyY?=
 =?us-ascii?Q?QGMPo7j+GIga5NNfs4X1JikDkKL3P8DLxPFBWTMRGIUAJGF3wslx9powzZ80?=
 =?us-ascii?Q?5khdIRZWXDD3DlkfbbC3k3NpYbmQ2/WSiPEWMdwYAPWNevMvOnL+U/PzDLoi?=
 =?us-ascii?Q?zrwnytamBftpuh6ea6bVXwbmFO2R5G97hiQtg5FEJNrAep5XNpMMKvaGl2VB?=
 =?us-ascii?Q?r/mubePY0c6Pmwy2sxT2+hfAvr+sWTM0N26pg7gxrbRGDVZGKh1Jn48Dvgcv?=
 =?us-ascii?Q?gF0YmLAfYaO/gKTp/RFkK1tUDs4C7F79KsArus7in9oNylzAILqHBDQIS/36?=
 =?us-ascii?Q?6R5h8PIoDj7XO4LP1I6A/jBMqKohpYTgLuCMAXKJnEOPvDr3xgUvqt8dRVc4?=
 =?us-ascii?Q?6kmEYv8fA578/YGbTZHuMk251daea0opXkrF1BWWBmi9Tbbmxb1pWEFHk/w/?=
 =?us-ascii?Q?nFoILoMRh5SjyoF25yfGmrfN1BGLg3ag5hkZEk+GymQ0Y21zi3R20IaxdKln?=
 =?us-ascii?Q?w9jNRdcsUoMx+mOyiy7dIKgjUNRpAYSiw7ocUKPBd0jwfYw7wSALyzcbcln7?=
 =?us-ascii?Q?KHLgjeTN7vTxjE26vPAZfkjuu55ReG7qlIjRorfxU2PgRr6W3KiTy52Y6BSp?=
 =?us-ascii?Q?o0H8PcxPdOl3EwWMUCZAgiIn9aiDAQceasFWvek59QNJNrUJHRXFcRlJd4j4?=
 =?us-ascii?Q?V31nVz6zZIBoLiqQG7XMuURYsmrHFQ9y7kT+Sj95uBHyvOcuhWzo8Cn7np/T?=
 =?us-ascii?Q?QqDgo/uJSQI9xRYdwPneu2eapjmk0wKoHI4iIqFqWSAS4ObqfG3CE178+Se4?=
 =?us-ascii?Q?ya1Xi3YcY5LOhVOnV63CCOsqiPA6ojfDdfL+WSZdN2915nns8b+k9vrAMLtZ?=
 =?us-ascii?Q?+vR0vXEpCzQ9RPshNsne/9ej+t+APQHWPpp8aU/PQHN79/BJwsTrLe1T8KZX?=
 =?us-ascii?Q?Q52MNMVG9HMfMYuR5le31+f4F3KRoQFeexnpHEkXQE/6cBbcYMy5FbxiyUAi?=
 =?us-ascii?Q?X14BvM7RJwYlpT37HW4pzYleZs4Hkj2KM+EotnbJismM5GQpBNUWY1EyWKXX?=
 =?us-ascii?Q?ARPYjeHiZRonlCo2bTwFIcFbhiXJmZvwdqXdwi6iCOs9ylJLpCgXrabRCFJ3?=
 =?us-ascii?Q?Gif+yqRvfEQyj8I52PGwivqM6PMVm/Gte9KptYsLYhcxKEe9Du2aAkDAhcUn?=
 =?us-ascii?Q?sEIjtU6Xe15uvSlKR9KJ4zfBRd/+VCOUwShyPztNDMrbbeTmRwhMKEjz1EG2?=
 =?us-ascii?Q?FquVLogAJ/6O462XAD+Qw9mW/q3txKcNcQw6q95XSM116hPVJwHLlOjurvio?=
 =?us-ascii?Q?HCfzcAjAy/wrdBzhAF6V2T5h+UKyCYz0mnJPZcMKLUnFq+nGHwGG46W+S8Y2?=
 =?us-ascii?Q?1A=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: bp.renesas.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TYCPR01MB11269.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a3cfba8-1827-4783-24f8-08dbc958acc0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2023 06:18:09.5191
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MKb7BYjb8akUmKOrN/hOFdWsBnj3iMKL9Wi4wpOfgG3380R3w5L/b5muo2jfufBzspuM7cCTQlEHcSrVpprARyP6m6BW9L2jcRqfaBY36o0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSRPR01MB11458
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 09 Oct 2023 23:18:32 -0700 (PDT)
X-Spam-Level: **

Hi Thomas Gleixner,

> Subject: RE: [PATCH v2] alarmtimer: Fix rebind failure
>=20
> On Mon, Oct 09 2023 at 17:02, Biju Das wrote:
> >> On Mon, Oct 09 2023 at 15:30, Biju Das wrote:
> >> > You mean we should update[1] (charger-manager driver)as it is the
> >> > one using alarmtimer_get_rtcdev()??
> >>
> >> # git grep -c alarmtimer_get_rtcdev
> >> drivers/power/supply/charger-manager.c:1
> >> include/linux/alarmtimer.h:2
> >> kernel/time/alarmtimer.c:10
> >
> > kernel/time/alarmtimer.c has alarmtimer_get_rtcdev()check everywhere,
> > that is missing in charger-manager.c. I will add the same, is it ok?
>=20
> The code does in the init function:
>=20
>       if (alarmtimer_get_rtcdev()) {
>          ....
>       }
>=20
> IOW, charger-manager.c expects that alarm is working when
> alarmtimer_get_rtcdev() returns non NULL at init. So ripping the RTC devi=
ce
> out under it is going to result in a disfunctional driver. I'm not
> convinced that you can fix this by sprinkling a ton of checks around the
> code.
>=20
> But that's not the worst of it. The alarmtimer infrastructure is generall=
y
> not designed for device/module removal. Why?
>=20
> The posix timer interface is fundamentally expecting that an armed alarm
> timer is actually functional. The fact that the class interface does not
> have a remove_dev callback is not an oversight and holding a reference on
> the module and a reference on the device is intended to ensure that the
> device cannot vanish.

Thanks for the explanation, I am not aware we should not remove RTC device.=
=20

>=20
> The changelog lacks any form of explanation why this is required and how
> removal of the registered RTC device is actually possible. Neither does i=
t
> provide any analysis why this cannot result in malfunction.

RTC driver is defined as a module, so I was testing
remove/unbind followed by install/bind on RTC driver to check
any resource leakage and found that device is not working properly.

As you mentioned above, we should not remove RTC driver. So I would like to=
 drop this patch.

Is there any place we can document this to avoid another person doing same =
mistake?

Cheers,
Biju