Re: [PATCH net-next 1/4] mlx4/mlx5: {mlx4,mlx5e}_en_get_module_info cleanup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/15/24 04:21, Krzysztof Olędzki wrote:
On 14.09.2024 at 01:21, Simon Horman wrote:
On Fri, Sep 13, 2024 at 07:48:08PM -0700, Jakub Kicinski wrote:
On Fri, 13 Sep 2024 19:12:01 -0700 Krzysztof Olędzki wrote:
On 13.09.2024 at 13:55, Jakub Kicinski wrote:
On Wed, 11 Sep 2024 23:38:45 -0700 Krzysztof Olędzki wrote:
Use SFF8024 constants defined in linux/sfp.h instead of private ones.

Make mlx4_en_get_module_info() and mlx5e_get_module_info() to look
as close as possible to each other.

Simplify the logic for selecting SFF_8436 vs SFF_8636.

Minor process suggestion, I think you may be sending the patches one by
one. It's best to format them into a new directory and send all at once
with git send-email. Add a cover letter, too.

Thanks, yes, will do for v2. I assume this needs to wait for about
two weeks for net-next to re-open?

The cleanups - yes, but if patch 3 works you should make it independent
and send as a fix (and trees never close for fixes).

Hi Krzysztof,

Just to expand on what Jakub wrote a little. In general fixes should have a
Fixes tag and be targeted at the net tree.

	Subject: [PATCH net] ...

Link: https://docs.kernel.org/process/maintainer-netdev.html

Yes, thank you Simon for the additional feedback.

I initially targeted net-next following Ido's request:
  https://lore.kernel.org/netdev/Ztna8O1ZGUc4kvKJ@xxxxxxxxxxxxxxxx/

If we all believe "net" is the right target, I'm more than happy to update it and re-send that single
patch now. Should I mark it as "v2" even if no difference because of the tree change?

yes, additionally please provide a changelog, which will say "retarget
to -net" and it's most welcomed if you also provide links to past
discussions


Also, I did include Fixes in that patch:
  Fixes: f5826c8c9d57 ("net/mlx4_en: Fix wrong return value on ioctl EEPROM query failure")
  Fixes: 32a173c7f9e9 ("net/mlx4_core: Introduce mlx4_get_module_info for cable module info reading")

those two fixes tags are correct picks for your two changes, but I think
that it could be combined into one place, I will reply in the current
"patch 3" thread (now you see why it's beneficial to send whole series
together :))


See: https://lore.kernel.org/netdev/2aa0787e-a148-456e-b1b5-8f1e9785ed04@xxxxxx/

Thanks,
  Krzysztof






[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux