[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241213165642.GA3417770@bhelgaas>
Date: Fri, 13 Dec 2024 10:56:42 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Guilherme Giacomo Simoes <trintaeoitogc@...il.com>
Cc: bhelgaas@...gle.com, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, namcao@...utronix.de, ngn@....tf,
scott@...teful.org
Subject: Re: [RESEND PATCH] PCI: remove already resolved TODO
On Fri, Dec 13, 2024 at 12:17:10PM -0300, Guilherme Giacomo Simoes wrote:
> Bjorn Helgaas <helgaas@...nel.org> wrote:
> > I see a test and call for .get_power() and .set_power(), but no actual
> > implementations, so I think they can be removed as well, can't they?
> > If so, I'll wait for that removal before applying this patch.
>
> You are right. Both only have a check if exist the {g|s}et_power(),
> then this is called.
>
> But, as you already said, seems that really don't have a
> implementations for both. So, I can work on remove this fields an
> tests this.
>
> In the cpci_hotplug.h we can create a `flags` field in
> `cpci_hp_controller_ops` struct, in addition of remove the
> {g|s}et_power(). In the cpci_hotplug_core.c that the
> cpci_hp_controller_ops struct is in use, maybe we can create a
> #define SLOT_ENABLED 0x00000001, and we can do `ops->flags |=
> ENABLED_SLOT` when we need enable the slot in the enable_slot()
> function and `ops->flags &= ~ENABLE_SLOT` in the disable_slot()
> function. In the get_power() function we only need return
> `ops->flags & SLOT_ENABLED`. what do you think?
I don't quite see what you have in mind; a patch would make it clear.
But the cpci hotplug driver is basically dead. I don't think it's
worth doing anything more than the most trivial cleanups to it.
Bjorn
Powered by blists - more mailing lists