net vs net-next conflicts while cross merging

net vs net-next conflicts while cross merging

[Paolo Abeni]

Hi,

I just cross-merged net into net-next for the 6.13 PR. There was 2
conflicts:

include/linux/phy.h
41ffcd95015f net: phy: fix phylib's dual eee_enabled
21aa69e708b net: phy: convert eee_broken_modes to a linkmode bitmap

drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
2160428bcb20 net: txgbe: fix null pointer to pcs
2160428bcb20 net: txgbe: remove GPIO interrupt controller

@Russel, @Jiawen: could you please double check that the resolution is
correct?

I solved the phy.h conflict as reported here:
https://lore.kernel.org/all/20241118135512.1039208b@canb.auug.org.au/

Thanks!

Paolo

Re: net vs net-next conflicts while cross merging

[Russell King (Oracle)]

On Tue, Nov 19, 2024 at 02:15:07PM +0100, Paolo Abeni wrote:
> @Russel, @Jiawen: could you please double check that the resolution is
> correct?

Will do, but... Linus has recently been ranting to Andrew about latin-1
vs UTF-8 messing up the spelling of people's names. I find this
somewhat hypocritical. Each time I see this kind of thing, it makes me
sick.

As someone who's name regularly gets mis-spelled (for god knows what
reason...)

Either we care about correct spelling of people's names, or we don't.
If we do, then more effort needs to be made to spell my name correctly.
If we don't, then I'll stop complaining. However, we can't have "we
must spell non-latin-1 names correctly" but then go and consistently mis-
spell other people's names and not bat an eye.

I'm asking for equality please.

(And yes, my name does and has been mis-spelled in commits merged into
the kernel.)

> I solved the phy.h conflict as reported here:
> https://lore.kernel.org/all/20241118135512.1039208b@canb.auug.org.au/

Looks fine to me.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

RE: net vs net-next conflicts while cross merging

[Jiawen Wu]

On Tue, No 19, 2024 9:15 PM, Paolo Abeni wrote:
> Hi,
> 
> I just cross-merged net into net-next for the 6.13 PR. There was 2
> conflicts:
> 
> include/linux/phy.h
> 41ffcd95015f net: phy: fix phylib's dual eee_enabled
> 21aa69e708b net: phy: convert eee_broken_modes to a linkmode bitmap
> 
> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
> 2160428bcb20 net: txgbe: fix null pointer to pcs
> 2160428bcb20 net: txgbe: remove GPIO interrupt controller

Hi,

I don't find what's the conflict here. Do you mean these two:

2160428bcb20 ("net: txgbe: fix null pointer to pcs")
155c499ffd1d ("net: wangxun: txgbe: use phylink_pcs internally")

If this is the case, it should be resolved as follow:

static struct phylink_pcs *txgbe_phylink_mac_select(struct phylink_config *config,
						    phy_interface_t interface)
{
	struct wx *wx = phylink_to_wx(config);
	struct txgbe *txgbe = wx->priv;

	if (wx->media_type != sp_media_copper)
		return txgbe->pcs;

	return NULL;
}

Thanks!
 

Re: net vs net-next conflicts while cross merging

[Paolo Abeni]

On 11/20/24 09:28, Jiawen Wu wrote:
> On Tue, No 19, 2024 9:15 PM, Paolo Abeni wrote:
>> I just cross-merged net into net-next for the 6.13 PR. There was 2
>> conflicts:
>>
>> include/linux/phy.h
>> 41ffcd95015f net: phy: fix phylib's dual eee_enabled
>> 21aa69e708b net: phy: convert eee_broken_modes to a linkmode bitmap
>>
>> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
>> 2160428bcb20 net: txgbe: fix null pointer to pcs
>> 2160428bcb20 net: txgbe: remove GPIO interrupt controller
> 
> I don't find what's the conflict here. Do you mean these two:
> 
> 2160428bcb20 ("net: txgbe: fix null pointer to pcs")
> 155c499ffd1d ("net: wangxun: txgbe: use phylink_pcs internally")

Yep, the latter one.

> If this is the case, it should be resolved as follow:
> 
> static struct phylink_pcs *txgbe_phylink_mac_select(struct phylink_config *config,
> 						    phy_interface_t interface)
> {
> 	struct wx *wx = phylink_to_wx(config);
> 	struct txgbe *txgbe = wx->priv;
> 
> 	if (wx->media_type != sp_media_copper)
> 		return txgbe->pcs;
> 
> 	return NULL;
> }

Ok, so it looks like the current net-next code is correct.

Thanks,

Paolo