Received-SPF: pass (google.com: domain of linux-kernel+bounces-120746-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240324150107.976025-1-hpa@redhat.com> <20240324150107.976025-2-hpa@redhat.com>
 <CAHp75Ve5201KNdjvDZYq_unHTKp9wZXPWZXDgStP8y+XjtnWWg@mail.gmail.com>
 <CAEth8oG7_qFuUrL+kX3ezNatWqKPqT-qiaO5NGY-N3F3ufQL9w@mail.gmail.com>
 <CAHp75VdQtmT0G1dFhdY7TrcBj2W6GhOaVv90_T1e3MdEtiduQQ@mail.gmail.com> <58014ecc-4353-494d-acfb-767e9c977abe@redhat.com>
In-Reply-To: <58014ecc-4353-494d-acfb-767e9c977abe@redhat.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Wed, 27 Mar 2024 13:21:48 +0200
Message-ID: <CAHp75VfFLu4Nhd0hWVY_q=BgOLCFCxWQqMzdv61WkroQUJR0Ww@mail.gmail.com>
Subject: Re: [PATCH v5 RESEND 1/6] platform: x86-android-tablets: other: Add
 swnode for Xiaomi pad2 indicator LED
To: Hans de Goede <hdegoede@redhat.com>
Cc: Kate Hsuan <hpa@redhat.com>, Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>, 
	linux-leds@vger.kernel.org, platform-driver-x86@vger.kernel.org, 
	=?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>, 
	=?UTF-8?Q?Andr=C3=A9_Apitzsch?= <git@apitzsch.eu>, 
	linux-kernel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>, linux-pm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 27, 2024 at 1:18=E2=80=AFPM Hans de Goede <hdegoede@redhat.com>=
 wrote:
> On 3/27/24 12:05 PM, Andy Shevchenko wrote:
> > On Wed, Mar 27, 2024 at 9:58=E2=80=AFAM Kate Hsuan <hpa@redhat.com> wro=
te:
> >> On Mon, Mar 25, 2024 at 3:30=E2=80=AFAM Andy Shevchenko
> >> <andy.shevchenko@gmail.com> wrote:
> >>> On Sun, Mar 24, 2024 at 5:02=E2=80=AFPM Kate Hsuan <hpa@redhat.com> w=
rote:

..

> >>>> +static int __init xiaomi_mipad2_init(void)
> >>>> +{
> >>>> +       return software_node_register_node_group(ktd2026_node_group)=
;
> >>>> +}
> >>>> +
> >>>> +static void xiaomi_mipad2_exit(void)
> >>>
> >>> __exit ?
> >> No need.
> >> x86-andriod-tablet is based on platform_driver and platform_device so
> >> it doesn't need __exit.
> >>
> >> I put __exit and the compiler complained about the warning.
> >> =3D=3D=3D
> >> WARNING: modpost:
> >> drivers/platform/x86/x86-android-tablets/x86-android-tablets: section
> >> mismatch in reference: xiaomi_mipad2_info+0x50 (section: .init.rodata)
> >> -> xiaomi_mipad2_exit (section: .exit.text)
> >> =3D=3D=3D
> >
> > This is interesting. Why then do we call them symmetrically?
> >
> > Hans, do we need to have anything here been amended?
>
> No this is all as expected.
>
> The platform driver's probe() function can be __init because
> the platform device is registered with the special:
> platform_create_bundle() function which takes a probe() function
> and the actual "struct platform_driver" does not have .probe
> set at all.
>
> Since we need to do manual cleanup on remove() however we need
> a remove() callback and that does sit in the struct platform_driver
> and since remove() can normally also be called on manual unbind
> of the driver through sysfs it cannot be in the __exit section.
>
> I say normally because IIRC platform_create_bundle() disables
> manual unbinding but the section checking code does not know this,
> all it sees is that the "struct platform_driver" is not __exit
> and that it references the remove() callback and therefor the
> remove() callback itself cannot be __exit.

Thank you for the detailed explanation!

--=20
With Best Regards,
Andy Shevchenko