lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241213151710.805485-1-trintaeoitogc@gmail.com>
Date: Fri, 13 Dec 2024 12:17:10 -0300
From: Guilherme Giacomo Simoes <trintaeoitogc@...il.com>
To: helgaas@...nel.org
Cc: bhelgaas@...gle.com,
	linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org,
	namcao@...utronix.de,
	ngn@....tf,
	scott@...teful.org,
	trintaeoitogc@...il.com
Subject: Re: [RESEND PATCH] PCI: remove already resolved TODO

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 crate 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?

> In
> https://lore.kernel.org/r/20241014131917.324667-1-trintaeoitogc@gmail.com,
> you capitalized your names.  What's your preference?  I'd like to use
> your name correctly and consistently.
I make mistake, sorry for this. In the next commit I will send with my name
capitalized. 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ