| Message ID | 20230317185415.2000564-2-colin.foster@in-advantage.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 672faa7bbf6014a301b6edc477918af445c92ce2 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | add support for ocelot external ports | expand |
| Context | Check | Description |
|---|---|---|
| netdev/series_format | success | Posting correctly formatted |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/fixes_present | success | Fixes tag not required for -next series |
| netdev/header_inline | success | No static functions without inline keyword in header files |
| netdev/build_32bit | success | Errors and warnings before: 18 this patch: 18 |
| netdev/cc_maintainers | success | CCed 4 of 4 maintainers |
| netdev/build_clang | success | Errors and warnings before: 18 this patch: 18 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/deprecated_api | success | None detected |
| netdev/check_selftest | success | No net selftest shell script |
| netdev/verify_fixes | success | No Fixes tag |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 18 this patch: 18 |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 21 lines checked |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/source_inline | success | Was 0 now: 0 |
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
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.
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!
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.
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.
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.
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.
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);
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 <colin.foster@in-advantage.com> --- v1 -> v2 * No change --- drivers/phy/mscc/phy-ocelot-serdes.c | 9 +++++++++ 1 file changed, 9 insertions(+)