From: Heiner Kallweit <hkallweit1@gmail.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Niklas Cassel <cassel@kernel.org>
Cc: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>,
nic_swsd@realtek.com, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH] r8169: do not call rtl8169_down() twice on shutdown
Date: Fri, 18 Apr 2025 23:52:19 +0200 [thread overview]
Message-ID: <74a498d0-343f-46f1-ad95-2651d960d657@gmail.com> (raw)
In-Reply-To: <jikqc7fz4nmwd3ol4f2uazcjc3zgtbtzcrudhsccmvfm3pjbfk@mkcj6gnkrljj>
On 18.04.2025 19:19, Manivannan Sadhasivam wrote:
> On Wed, Apr 16, 2025 at 06:03:36PM +0200, Niklas Cassel wrote:
>> Hello Krishna Chaitanya,
>>
>> On Wed, Apr 16, 2025 at 09:15:19PM +0530, Krishna Chaitanya Chundru wrote:
>>> On 4/16/2025 7:43 PM, Niklas Cassel wrote:
>>>>
>>>> So perhaps we should hold off with this patch.
>>>>
>>> I disagree on this, it might be causing issue with net driver, but we
>>> might face some other issues as explained above if we don't call
>>> pci_stop_root_bus().
>>
>> When I wrote hold off with this patch, I meant the patch in $subject,
>> not your patch.
>>
>>
>> When it comes to your patch, I think that the commit log needs to explain
>> why it is so special.
>>
>> Because AFAICT, all other PCIe controller drivers call pci_stop_root_bus()
>> in the .remove() callback, not in the .shutdown() callback.
>>
>
> And this driver is special because, it has no 'remove()' callback as it
> implements an irqchip controller. So we have to shutdown the devices cleanly in
> the 'shutdown' callback.
>
Doing proper cleanup in a first place is responsibility of the respective bus
devices (in their shutdown() callback).
Calling pci_stop_root_bus() in the pci controllers shutdown() causes the bus
devices to be removed, hence their remove() is called. Typically devices
don't expect that remove() is called after shutdown(). This may cause issues
if e.g. shutdown() sets a device to D3cold. remove() won't expect that device
is inaccessible.
Another issue is with devices being wake-up sources. If wake-up is enabled,
then devices configure the wake-up in their shutdown() callback. Calling
remove() afterwards may reverse parts of the wake-up configuration.
And I'd expect that most wakeup-capable device disable wakeup in the
remove() callback. So there's a good chance that the proposed change breaks
wake-up.
There maybe other side effects I'm not aware of.
IMO a controller drivers shutdown() shall focus on cleanup up its own resources.
> Also do note that the driver core will not call the 'remove()' callback unless
> the driver as a module is unloaded during poweroff/reboot scenarios. So the
> controller drivers need to properly power down the devices in their 'shutdown()'
> callback IMO.
>
>> Doing things differently from all other PCIe controller drivers is usually
>> a red flag.
>>
>
> Yes, even if it is the right thing to do ;) But I agree that the commit message
> needs some improvement.
>
> - Mani
>
next prev parent reply other threads:[~2025-04-18 21:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 9:53 [PATCH] r8169: do not call rtl8169_down() twice on shutdown Niklas Cassel
2025-04-15 18:48 ` Heiner Kallweit
2025-04-16 14:13 ` Niklas Cassel
2025-04-16 15:45 ` Krishna Chaitanya Chundru
2025-04-16 16:03 ` Niklas Cassel
2025-04-16 17:15 ` Krishna Chaitanya Chundru
2025-04-18 17:19 ` Manivannan Sadhasivam
2025-04-18 21:52 ` Heiner Kallweit [this message]
2025-04-19 10:18 ` Heiner Kallweit
2025-04-19 23:18 ` Krishna Chaitanya Chundru
2025-04-20 6:25 ` Heiner Kallweit
2025-04-23 17:39 ` Bjorn Helgaas
2025-04-23 17:50 ` Manivannan Sadhasivam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74a498d0-343f-46f1-ad95-2651d960d657@gmail.com \
--to=hkallweit1@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=cassel@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kuba@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).