The phy-ocelot-serdes module has exclusively been used in a syscon setup,
from an internal CPU. The addition of external control of ocelot switches
via an existing MFD implementation means that syscon is no longer the only
interface that phy-ocelot-serdes will see.
In the MFD configuration, an IORESOURCE_REG resource will exist for the
device. Utilize this resource to be able to function in both syscon and
non-syscon configurations.
Signed-off-by: Colin Foster <[email protected]>
---
v1 -> v2
* No change
---
drivers/phy/mscc/phy-ocelot-serdes.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/phy/mscc/phy-ocelot-serdes.c b/drivers/phy/mscc/phy-ocelot-serdes.c
index 76f596365176..d9443e865a78 100644
--- a/drivers/phy/mscc/phy-ocelot-serdes.c
+++ b/drivers/phy/mscc/phy-ocelot-serdes.c
@@ -494,6 +494,7 @@ static int serdes_probe(struct platform_device *pdev)
{
struct phy_provider *provider;
struct serdes_ctrl *ctrl;
+ struct resource *res;
unsigned int i;
int ret;
@@ -503,6 +504,14 @@ static int serdes_probe(struct platform_device *pdev)
ctrl->dev = &pdev->dev;
ctrl->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
+ if (IS_ERR(ctrl->regs)) {
+ /* Fall back to using IORESOURCE_REG, if possible */
+ res = platform_get_resource(pdev, IORESOURCE_REG, 0);
+ if (res)
+ ctrl->regs = dev_get_regmap(ctrl->dev->parent,
+ res->name);
+ }
+
if (IS_ERR(ctrl->regs))
return PTR_ERR(ctrl->regs);
--
2.25.1
On 17-03-23, 11:54, Colin Foster wrote:
> The phy-ocelot-serdes module has exclusively been used in a syscon setup,
> from an internal CPU. The addition of external control of ocelot switches
> via an existing MFD implementation means that syscon is no longer the only
> interface that phy-ocelot-serdes will see.
>
> In the MFD configuration, an IORESOURCE_REG resource will exist for the
> device. Utilize this resource to be able to function in both syscon and
> non-syscon configurations.
Applied to phy/next, thanks
--
~Vinod
On Mon, Mar 20, 2023 at 02:19:44PM +0530, Vinod Koul wrote:
> On 17-03-23, 11:54, Colin Foster wrote:
> > The phy-ocelot-serdes module has exclusively been used in a syscon setup,
> > from an internal CPU. The addition of external control of ocelot switches
> > via an existing MFD implementation means that syscon is no longer the only
> > interface that phy-ocelot-serdes will see.
> >
> > In the MFD configuration, an IORESOURCE_REG resource will exist for the
> > device. Utilize this resource to be able to function in both syscon and
> > non-syscon configurations.
>
> Applied to phy/next, thanks
Please read the netdev FAQ. Patches sent to netdev contain the tree that
the submitter wishes the patches to be applied to.
As a result, I see davem has just picked up the *entire* series which
means that all patches are in net-next now. net-next is immutable.
In any case, IMHO if this kind of fly-by cherry-picking from patch
series is intended, it should be mentioned during review to give a
chance for other maintainers to respond and give feedback. Not all
submitters will know how individual maintainers work. Not all
maintainers know how other maintainers work.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On 20-03-23, 09:24, Russell King (Oracle) wrote:
> On Mon, Mar 20, 2023 at 02:19:44PM +0530, Vinod Koul wrote:
> > On 17-03-23, 11:54, Colin Foster wrote:
> > > The phy-ocelot-serdes module has exclusively been used in a syscon setup,
> > > from an internal CPU. The addition of external control of ocelot switches
> > > via an existing MFD implementation means that syscon is no longer the only
> > > interface that phy-ocelot-serdes will see.
> > >
> > > In the MFD configuration, an IORESOURCE_REG resource will exist for the
> > > device. Utilize this resource to be able to function in both syscon and
> > > non-syscon configurations.
> >
> > Applied to phy/next, thanks
>
> Please read the netdev FAQ. Patches sent to netdev contain the tree that
> the submitter wishes the patches to be applied to.
>
> As a result, I see davem has just picked up the *entire* series which
> means that all patches are in net-next now. net-next is immutable.
>
> In any case, IMHO if this kind of fly-by cherry-picking from patch
> series is intended, it should be mentioned during review to give a
> chance for other maintainers to respond and give feedback. Not all
> submitters will know how individual maintainers work. Not all
> maintainers know how other maintainers work.
:-(
Just saw the email at similar time around mine! I can skip anything
which is tagged net-dev in future, saves me time from useless endeavours!
--
~Vinod
On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> On Mon, Mar 20, 2023 at 02:19:44PM +0530, Vinod Koul wrote:
> > On 17-03-23, 11:54, Colin Foster wrote:
> > > The phy-ocelot-serdes module has exclusively been used in a syscon setup,
> > > from an internal CPU. The addition of external control of ocelot switches
> > > via an existing MFD implementation means that syscon is no longer the only
> > > interface that phy-ocelot-serdes will see.
> > >
> > > In the MFD configuration, an IORESOURCE_REG resource will exist for the
> > > device. Utilize this resource to be able to function in both syscon and
> > > non-syscon configurations.
> >
> > Applied to phy/next, thanks
>
> Please read the netdev FAQ. Patches sent to netdev contain the tree that
> the submitter wishes the patches to be applied to.
>
> As a result, I see davem has just picked up the *entire* series which
> means that all patches are in net-next now. net-next is immutable.
>
> In any case, IMHO if this kind of fly-by cherry-picking from patch
> series is intended, it should be mentioned during review to give a
> chance for other maintainers to respond and give feedback. Not all
> submitters will know how individual maintainers work. Not all
> maintainers know how other maintainers work.
Once again netdev seems to have applied patches from other subsystems
without review/ack. What makes netdev different to any other kernel
subsystem? What would happen if other random maintainers started
applying netdev patches without appropriate review? I suspect someone
would become understandably grumpy.
--
Lee Jones [李琼斯]
On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
>
> > On Mon, Mar 20, 2023 at 02:19:44PM +0530, Vinod Koul wrote:
> > > On 17-03-23, 11:54, Colin Foster wrote:
> > > > The phy-ocelot-serdes module has exclusively been used in a syscon setup,
> > > > from an internal CPU. The addition of external control of ocelot switches
> > > > via an existing MFD implementation means that syscon is no longer the only
> > > > interface that phy-ocelot-serdes will see.
> > > >
> > > > In the MFD configuration, an IORESOURCE_REG resource will exist for the
> > > > device. Utilize this resource to be able to function in both syscon and
> > > > non-syscon configurations.
> > >
> > > Applied to phy/next, thanks
> >
> > Please read the netdev FAQ. Patches sent to netdev contain the tree that
> > the submitter wishes the patches to be applied to.
> >
> > As a result, I see davem has just picked up the *entire* series which
> > means that all patches are in net-next now. net-next is immutable.
> >
> > In any case, IMHO if this kind of fly-by cherry-picking from patch
> > series is intended, it should be mentioned during review to give a
> > chance for other maintainers to respond and give feedback. Not all
> > submitters will know how individual maintainers work. Not all
> > maintainers know how other maintainers work.
>
> Once again netdev seems to have applied patches from other subsystems
> without review/ack. What makes netdev different to any other kernel
> subsystem? What would happen if other random maintainers started
> applying netdev patches without appropriate review? I suspect someone
> would become understandably grumpy.
Why again are you addressing your whinge to me? I'm not one of the
netdev maintainers, but I've pointed out what happens in netdev
land. However, you seem to *not* want to discuss it directly with
DaveM/Jakub/Paolo - as illustrated again with yet another response
to *me* rather than addressing your concerns *to* the people who
you have an issue with.
This is not communication. Effectively, this is sniping, because
rather than discussing it with the individuals concerned, you are
instead preferring to discuss it with others.
Please stop this.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> >
> > > On Mon, Mar 20, 2023 at 02:19:44PM +0530, Vinod Koul wrote:
> > > > On 17-03-23, 11:54, Colin Foster wrote:
> > > > > The phy-ocelot-serdes module has exclusively been used in a syscon setup,
> > > > > from an internal CPU. The addition of external control of ocelot switches
> > > > > via an existing MFD implementation means that syscon is no longer the only
> > > > > interface that phy-ocelot-serdes will see.
> > > > >
> > > > > In the MFD configuration, an IORESOURCE_REG resource will exist for the
> > > > > device. Utilize this resource to be able to function in both syscon and
> > > > > non-syscon configurations.
> > > >
> > > > Applied to phy/next, thanks
> > >
> > > Please read the netdev FAQ. Patches sent to netdev contain the tree that
> > > the submitter wishes the patches to be applied to.
> > >
> > > As a result, I see davem has just picked up the *entire* series which
> > > means that all patches are in net-next now. net-next is immutable.
> > >
> > > In any case, IMHO if this kind of fly-by cherry-picking from patch
> > > series is intended, it should be mentioned during review to give a
> > > chance for other maintainers to respond and give feedback. Not all
> > > submitters will know how individual maintainers work. Not all
> > > maintainers know how other maintainers work.
> >
> > Once again netdev seems to have applied patches from other subsystems
> > without review/ack. What makes netdev different to any other kernel
> > subsystem? What would happen if other random maintainers started
> > applying netdev patches without appropriate review? I suspect someone
> > would become understandably grumpy.
>
> Why again are you addressing your whinge to me? I'm not one of the
> netdev maintainers, but I've pointed out what happens in netdev
> land. However, you seem to *not* want to discuss it directly with
> DaveM/Jakub/Paolo - as illustrated again with yet another response
> to *me* rather than addressing your concerns *to* the people who
> you have an issue with.
>
> This is not communication. Effectively, this is sniping, because
> rather than discussing it with the individuals concerned, you are
> instead preferring to discuss it with others.
>
> Please stop this.
Read the above paragraph again.
It was an open question, *intentionally* not directed *at* anyone.
You just happen to be the one describing yet another unfortunate
situation. Consider yourself a victim of circumstance and try not to
take any of it personally.
It's the workflow and the assumptions that I'm unhappy about and that I
think should be improved upon. The gripe is not against any one
individual or individuals.
--
Lee Jones [李琼斯]
On Mon, Mar 20, 2023 at 04:41:36PM +0000, Lee Jones wrote:
> On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
>
> > On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> > > Once again netdev seems to have applied patches from other subsystems
> > > without review/ack. What makes netdev different to any other kernel
> > > subsystem? What would happen if other random maintainers started
> > > applying netdev patches without appropriate review? I suspect someone
> > > would become understandably grumpy.
> >
> > Why again are you addressing your whinge to me? I'm not one of the
> > netdev maintainers, but I've pointed out what happens in netdev
> > land. However, you seem to *not* want to discuss it directly with
> > DaveM/Jakub/Paolo - as illustrated again with yet another response
> > to *me* rather than addressing your concerns *to* the people who
> > you have an issue with.
> >
> > This is not communication. Effectively, this is sniping, because
> > rather than discussing it with the individuals concerned, you are
> > instead preferring to discuss it with others.
> >
> > Please stop this.
>
> Read the above paragraph again.
You sent your email _TO_ me, that means you addressed your comments
primarily _to_ me. RFC2822:
The "To:" field contains the address(es) of the primary recipient(s)
of the message.
The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
making a copy on a typewriter using carbon paper) contains the
addresses of others who are to receive the message, though the
content of the message may not be directed at them.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> On Mon, Mar 20, 2023 at 04:41:36PM +0000, Lee Jones wrote:
> > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> >
> > > On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> > > > Once again netdev seems to have applied patches from other subsystems
> > > > without review/ack. What makes netdev different to any other kernel
> > > > subsystem? What would happen if other random maintainers started
> > > > applying netdev patches without appropriate review? I suspect someone
> > > > would become understandably grumpy.
> > >
> > > Why again are you addressing your whinge to me? I'm not one of the
> > > netdev maintainers, but I've pointed out what happens in netdev
> > > land. However, you seem to *not* want to discuss it directly with
> > > DaveM/Jakub/Paolo - as illustrated again with yet another response
> > > to *me* rather than addressing your concerns *to* the people who
> > > you have an issue with.
> > >
> > > This is not communication. Effectively, this is sniping, because
> > > rather than discussing it with the individuals concerned, you are
> > > instead preferring to discuss it with others.
> > >
> > > Please stop this.
> >
> > Read the above paragraph again.
>
> You sent your email _TO_ me, that means you addressed your comments
> primarily _to_ me. RFC2822:
>
> The "To:" field contains the address(es) of the primary recipient(s)
> of the message.
>
> The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
> making a copy on a typewriter using carbon paper) contains the
> addresses of others who are to receive the message, though the
> content of the message may not be directed at them.
You're over-thinking it. I replied to all.
--
Lee Jones [李琼斯]
On Tue, Mar 21, 2023 at 08:26:58AM +0000, Lee Jones wrote:
> On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
>
> > On Mon, Mar 20, 2023 at 04:41:36PM +0000, Lee Jones wrote:
> > > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> > >
> > > > On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> > > > > Once again netdev seems to have applied patches from other subsystems
> > > > > without review/ack. What makes netdev different to any other kernel
> > > > > subsystem? What would happen if other random maintainers started
> > > > > applying netdev patches without appropriate review? I suspect someone
> > > > > would become understandably grumpy.
> > > >
> > > > Why again are you addressing your whinge to me? I'm not one of the
> > > > netdev maintainers, but I've pointed out what happens in netdev
> > > > land. However, you seem to *not* want to discuss it directly with
> > > > DaveM/Jakub/Paolo - as illustrated again with yet another response
> > > > to *me* rather than addressing your concerns *to* the people who
> > > > you have an issue with.
> > > >
> > > > This is not communication. Effectively, this is sniping, because
> > > > rather than discussing it with the individuals concerned, you are
> > > > instead preferring to discuss it with others.
> > > >
> > > > Please stop this.
> > >
> > > Read the above paragraph again.
> >
> > You sent your email _TO_ me, that means you addressed your comments
> > primarily _to_ me. RFC2822:
> >
> > The "To:" field contains the address(es) of the primary recipient(s)
> > of the message.
> >
> > The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
> > making a copy on a typewriter using carbon paper) contains the
> > addresses of others who are to receive the message, though the
> > content of the message may not be directed at them.
>
> You're over-thinking it. I replied to all.
I've been thinking about this entire situation and there's something
that summarises it. Kettle. Pot. Black.
You complain about how netdev is run, but you also complain about how
people interpret your emails.
Sorry, but no. I think you need to be more accomodating towards how
others perceive your emails, especially when there are widespread
accepted conventions. The fact that you are seemingly not even willing
to entertain that someone _might_ interpret your emails according to
standard normals is frankly a problem for you.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Tue, 21 Mar 2023, Russell King (Oracle) wrote:
> On Tue, Mar 21, 2023 at 08:26:58AM +0000, Lee Jones wrote:
> > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> >
> > > On Mon, Mar 20, 2023 at 04:41:36PM +0000, Lee Jones wrote:
> > > > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> > > >
> > > > > On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> > > > > > Once again netdev seems to have applied patches from other subsystems
> > > > > > without review/ack. What makes netdev different to any other kernel
> > > > > > subsystem? What would happen if other random maintainers started
> > > > > > applying netdev patches without appropriate review? I suspect someone
> > > > > > would become understandably grumpy.
> > > > >
> > > > > Why again are you addressing your whinge to me? I'm not one of the
> > > > > netdev maintainers, but I've pointed out what happens in netdev
> > > > > land. However, you seem to *not* want to discuss it directly with
> > > > > DaveM/Jakub/Paolo - as illustrated again with yet another response
> > > > > to *me* rather than addressing your concerns *to* the people who
> > > > > you have an issue with.
> > > > >
> > > > > This is not communication. Effectively, this is sniping, because
> > > > > rather than discussing it with the individuals concerned, you are
> > > > > instead preferring to discuss it with others.
> > > > >
> > > > > Please stop this.
> > > >
> > > > Read the above paragraph again.
> > >
> > > You sent your email _TO_ me, that means you addressed your comments
> > > primarily _to_ me. RFC2822:
> > >
> > > The "To:" field contains the address(es) of the primary recipient(s)
> > > of the message.
> > >
> > > The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
> > > making a copy on a typewriter using carbon paper) contains the
> > > addresses of others who are to receive the message, though the
> > > content of the message may not be directed at them.
> >
> > You're over-thinking it. I replied to all.
>
> I've been thinking about this entire situation and there's something
> that summarises it. Kettle. Pot. Black.
>
> You complain about how netdev is run, but you also complain about how
> people interpret your emails.
>
> Sorry, but no. I think you need to be more accomodating towards how
> others perceive your emails, especially when there are widespread
> accepted conventions. The fact that you are seemingly not even willing
> to entertain that someone _might_ interpret your emails according to
> standard normals is frankly a problem for you.
This conversion has gone completely off-track.
If you wish to continue talking about email headers offline (instead of
filling people's inboxes with unrelated ramblings), you know where to
find me.
--
Lee Jones [李琼斯]
On Tue, Mar 21, 2023 at 11:08:51AM +0000, Lee Jones wrote:
> On Tue, 21 Mar 2023, Russell King (Oracle) wrote:
>
> > On Tue, Mar 21, 2023 at 08:26:58AM +0000, Lee Jones wrote:
> > > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> > >
> > > > On Mon, Mar 20, 2023 at 04:41:36PM +0000, Lee Jones wrote:
> > > > > On Mon, 20 Mar 2023, Russell King (Oracle) wrote:
> > > > >
> > > > > > On Mon, Mar 20, 2023 at 01:34:31PM +0000, Lee Jones wrote:
> > > > > > > Once again netdev seems to have applied patches from other subsystems
> > > > > > > without review/ack. What makes netdev different to any other kernel
> > > > > > > subsystem? What would happen if other random maintainers started
> > > > > > > applying netdev patches without appropriate review? I suspect someone
> > > > > > > would become understandably grumpy.
> > > > > >
> > > > > > Why again are you addressing your whinge to me? I'm not one of the
> > > > > > netdev maintainers, but I've pointed out what happens in netdev
> > > > > > land. However, you seem to *not* want to discuss it directly with
> > > > > > DaveM/Jakub/Paolo - as illustrated again with yet another response
> > > > > > to *me* rather than addressing your concerns *to* the people who
> > > > > > you have an issue with.
> > > > > >
> > > > > > This is not communication. Effectively, this is sniping, because
> > > > > > rather than discussing it with the individuals concerned, you are
> > > > > > instead preferring to discuss it with others.
> > > > > >
> > > > > > Please stop this.
> > > > >
> > > > > Read the above paragraph again.
> > > >
> > > > You sent your email _TO_ me, that means you addressed your comments
> > > > primarily _to_ me. RFC2822:
> > > >
> > > > The "To:" field contains the address(es) of the primary recipient(s)
> > > > of the message.
> > > >
> > > > The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
> > > > making a copy on a typewriter using carbon paper) contains the
> > > > addresses of others who are to receive the message, though the
> > > > content of the message may not be directed at them.
> > >
> > > You're over-thinking it. I replied to all.
> >
> > I've been thinking about this entire situation and there's something
> > that summarises it. Kettle. Pot. Black.
> >
> > You complain about how netdev is run, but you also complain about how
> > people interpret your emails.
> >
> > Sorry, but no. I think you need to be more accomodating towards how
> > others perceive your emails, especially when there are widespread
> > accepted conventions. The fact that you are seemingly not even willing
> > to entertain that someone _might_ interpret your emails according to
> > standard normals is frankly a problem for you.
>
> This conversion has gone completely off-track.
>
> If you wish to continue talking about email headers offline (instead of
> filling people's inboxes with unrelated ramblings), you know where to
> find me.
I would prefer not to. I would much prefer it that if _you_ have a
problem with how netdev operates, that _you_ talk directly _to_ the
netdev maintainers, rather than latching on to one of my emails and
replying to it. That is a reasonable request that _you_ appear to be
completely immune to comprehending, instead wishing to effectively
tell me that I'm wrong to request that - and start this idiotic
thread to debate it.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!