linux-kernel - Re: [PATCH net-next v3 1/3] phy: open_alliance_helpers: Add defines for link quality metrics

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: <Zs6spnCAPsTmUfrL@pengutronix.de>
Date: Wed, 28 Aug 2024 06:50:46 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
	Russell King <linux@...linux.org.uk>, linux-kernel@...r.kernel.org,
	Eric Dumazet <edumazet@...gle.com>, kernel@...gutronix.de,
	Paolo Abeni <pabeni@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v3 1/3] phy: open_alliance_helpers: Add defines
 for link quality metrics

On Tue, Aug 27, 2024 at 11:33:00AM -0700, Jakub Kicinski wrote:
> On Tue, 27 Aug 2024 06:51:27 +0200 Oleksij Rempel wrote:
> > I completely agree with you, but I currently don't have additional
> > budget for this project.
> 
> Is this a legit reason not to do something relatively simple?

Due to the nature of my work in a consulting company, my time is scheduled
across multiple customers. For the 10BaseT1 PHY, I had 2 days budgeted left,
which allowed me to implement some extra diagnostics. This was simple,
predictable, and within the scope of the original task.

However, now that the budget for this task and customer has been used up, any
additional work would require a full process:
- I would need to sell the idea to the customer.
- The new task would need to be prioritized.
- It would then be scheduled, which could happen this year, next year, or
  possibly never.

A similar situation occurred with the EEE implementation. I started with a
simple fix for Atheros PHY's SmartEEE, but it led to reworking the entire EEE
infrastructure in the kernel. Once the budget was exhausted, I couldn’t
continue with SmartEEE for Atheros PHYs. These are the risks inherent to
consulting work. I still see it as not wasted time, because we have a better
EEE infrastructure now.

Considering that you've requested a change to the uAPI, the work has now become
more predictable. I can plan for it within the task and update the required
time budget accordingly. However, it's worth noting that while this work is
manageable, the time spent on this particular task could be seen as somewhat
wasted from a budget perspective, as it wasn't part of the original scope.

> Especially that we're talking about uAPI, once we go down
> the string path I presume they will stick around forever.

Yes, I agree with it. I just needed this feedback as early as possible.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |