From: <Parthiban.Veerasooran@microchip.com>
To: <andrew@lunn.ch>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
<corbet@lwn.net>, <Steen.Hegelund@microchip.com>,
<rdunlap@infradead.org>, <horms@kernel.org>,
<casper.casan@gmail.com>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <Horatiu.Vultur@microchip.com>,
<Woojung.Huh@microchip.com>, <Nicolas.Ferre@microchip.com>,
<UNGLinuxDriver@microchip.com>,
<Thorsten.Kummermehr@microchip.com>
Subject: Re: [PATCH net-next v2 3/9] net: ethernet: oa_tc6: implement OA TC6 configuration function
Date: Wed, 25 Oct 2023 12:02:58 +0000 [thread overview]
Message-ID: <97872e83-1490-4f1a-81ff-3f7692571dd1@microchip.com> (raw)
In-Reply-To: <423e0b42-a75e-4104-b445-7d9ff0991acf@lunn.ch>
Hi Andrew,
On 24/10/23 4:28 am, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> + /* Read and configure the IMASK0 register for unmasking the interrupts */
>> + ret = oa_tc6_perform_ctrl(tc6, IMASK0, ®val, 1, false, false);
>> + if (ret)
>> + return ret;
>
> Can you use oa_tc6_read_register() here? I guess the question is, what
> does tc6->protect default to until it is set later in this function?
> So long as it defaults to false, i guess you can use the register
> read/write functions, which are a lot more readable than this generic
> oa_tc6_perform_ctrl().
Yes, I will do that. Also for next two calls as well.
>
>> +
>> + regval &= ~(TXPEM & TXBOEM & TXBUEM & RXBOEM & LOFEM & HDREM);
>> +
>> + ret = oa_tc6_perform_ctrl(tc6, IMASK0, ®val, 1, true, false);
>> + if (ret)
>> + return ret;
>> +
>> + /* Read STDCAP register to get the MAC-PHY standard capabilities */
>> + ret = oa_tc6_perform_ctrl(tc6, STDCAP, ®val, 1, false, false);
>> + if (ret)
>> + return ret;
>> +
>> + mincps = FIELD_GET(MINCPS, regval);
>> + ctc = (regval & CTC) ? true : false;
>> +
>> + regval = 0;
>> + oa_node = of_get_child_by_name(spi->dev.of_node, "oa-tc6");
>> + if (oa_node) {
>> + /* Read OA parameters from DT */
>> + if (of_property_present(oa_node, "oa-cps")) {
>> + ret = of_property_read_u32(oa_node, "oa-cps", &tc6->cps);
>
> If of_property_read_u32() does not find the property, it is documented
> to not touch tc6->cps. So you can set tc6->cps to the default 64,
> before the big if, and skip the of_property_present(). You can then
> probably remove the else at the end as well.
Ah ok, will do that.
>
>> + if (ret < 0)
>> + return ret;
>> + /* Return error if the configured cps is less than the
>> + * minimum cps supported by the MAC-PHY.
>> + */
>> + if (tc6->cps < mincps)
>> + return -ENODEV;
>
> A dev_err() would be nice here to indicate why.
Ok sure.
>
>> + } else {
>> + tc6->cps = 64;
>> + }
>> + if (of_property_present(oa_node, "oa-txcte")) {
>> + /* Return error if the tx cut through mode is configured
>> + * but it is not supported by MAC-PHY.
>> + */
>> + if (ctc)
>> + regval |= TXCTE;
>> + else
>> + return -ENODEV;
>
> and a dev_err() here as well.
Ok sure.
>
>> + }
>> + if (of_property_present(oa_node, "oa-rxcte")) {
>> + /* Return error if the rx cut through mode is configured
>> + * but it is not supported by MAC-PHY.
>> + */
>> + if (ctc)
>> + regval |= RXCTE;
>> + else
>> + return -ENODEV;
>> + }
>
> and another dev_err(). Without these prints, you probably need to
> modify the code to figure out why the probe failed.
Yes I understand. Will do that in the next revision.
>
>> + if (of_property_present(oa_node, "oa-prote")) {
>> + regval |= PROTE;
>> + tc6->prote = true;
>> + }
>> + } else {
>> + tc6->cps = 64;
>> + }
>> +
>> + regval |= FIELD_PREP(CPS, ilog2(tc6->cps) / ilog2(2)) | SYNC;
>> +
>> + return oa_tc6_perform_ctrl(tc6, CONFIG0, ®val, 1, true, false);
>> +}
>> +
>> static int oa_tc6_sw_reset(struct oa_tc6 *tc6)
>> {
>> u32 regval;
>> @@ -310,7 +387,7 @@ EXPORT_SYMBOL_GPL(oa_tc6_read_registers);
>> * Returns pointer reference to the oa_tc6 structure if all the memory
>> * allocation success otherwise NULL.
>> */
>> -struct oa_tc6 *oa_tc6_init(struct spi_device *spi, bool prote)
>> +struct oa_tc6 *oa_tc6_init(struct spi_device *spi)
>
> Was there a reason to have prote initially, and then remove it here?
The reason is, control communication uses "protect". But in the first
patch there was no dt used. Later in this patch, dt used for all the
configuration parameters and this also part of that. That's why removed
and moved this to dt configuration.
What's your opinion? shall I keep as it is like this? or remove the
protect in the first two patches and introduce in this patch?
Best Regards,
Parthiban V
>
> Andrew
next prev parent reply other threads:[~2023-10-25 12:03 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 15:46 [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface Parthiban Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 1/9] net: ethernet: implement OPEN Alliance control transaction interface Parthiban Veerasooran
2023-10-23 21:28 ` Andrew Lunn
2023-10-25 11:16 ` Parthiban.Veerasooran
2023-10-26 19:46 ` Andrew Lunn
2023-10-27 7:15 ` Parthiban.Veerasooran
2023-10-23 23:09 ` kernel test robot
2023-10-25 19:09 ` kernel test robot
2023-10-23 15:46 ` [PATCH net-next v2 2/9] net: ethernet: oa_tc6: implement mac-phy software reset Parthiban Veerasooran
2023-10-23 22:43 ` Andrew Lunn
2023-10-25 11:39 ` Parthiban.Veerasooran
2023-10-26 20:01 ` Andrew Lunn
2023-10-27 7:00 ` Parthiban.Veerasooran
2023-10-25 11:39 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 3/9] net: ethernet: oa_tc6: implement OA TC6 configuration function Parthiban Veerasooran
2023-10-23 22:58 ` Andrew Lunn
2023-10-25 12:02 ` Parthiban.Veerasooran [this message]
2023-10-26 20:06 ` Andrew Lunn
2023-10-27 7:10 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 4/9] dt-bindings: net: add OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface Parthiban Veerasooran
2023-10-23 17:40 ` Rob Herring
2023-10-25 12:28 ` Parthiban.Veerasooran
2023-10-24 0:37 ` Andrew Lunn
2023-10-27 9:12 ` Parthiban.Veerasooran
[not found] ` <d6377de8-603f-4ac1-a691-b79c46a5057b@lunn.ch>
2023-10-30 10:09 ` Parthiban.Veerasooran
2023-10-24 7:44 ` Krzysztof Kozlowski
2023-10-31 12:59 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 5/9] net: ethernet: oa_tc6: implement internal PHY initialization Parthiban Veerasooran
2023-10-24 0:56 ` Andrew Lunn
2023-10-31 4:20 ` Parthiban.Veerasooran
2023-10-31 12:48 ` Andrew Lunn
2023-11-01 4:53 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 6/9] dt-bindings: net: oa-tc6: add PHY register access capability Parthiban Veerasooran
2023-10-24 1:21 ` Andrew Lunn
2023-10-31 4:22 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 7/9] net: ethernet: oa_tc6: implement data transaction interface Parthiban Veerasooran
2023-10-24 2:07 ` Andrew Lunn
2023-10-31 8:26 ` Parthiban.Veerasooran
2023-10-23 15:46 ` [PATCH net-next v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY Parthiban Veerasooran
2023-10-24 2:33 ` Andrew Lunn
2023-10-31 11:04 ` Parthiban.Veerasooran
2023-10-31 12:53 ` Andrew Lunn
2023-11-01 4:51 ` Parthiban.Veerasooran
2023-10-24 11:57 ` Krzysztof Kozlowski
2023-10-31 10:25 ` Parthiban.Veerasooran
2023-11-02 12:20 ` Ramón Nordin Rodriguez
2023-11-02 12:39 ` Andrew Lunn
2023-11-02 13:40 ` Ramón Nordin Rodriguez
2023-11-03 14:59 ` Parthiban.Veerasooran
2023-11-06 8:59 ` Ramón Nordin Rodriguez
2023-10-23 15:46 ` [PATCH net-next v2 9/9] dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY Parthiban Veerasooran
2023-10-23 17:40 ` Rob Herring
2023-10-30 12:41 ` Parthiban.Veerasooran
2023-10-24 8:03 ` Krzysztof Kozlowski
2023-10-30 13:16 ` Parthiban.Veerasooran
2023-10-30 14:45 ` Krzysztof Kozlowski
2023-11-02 13:31 ` Parthiban.Veerasooran
2024-03-24 11:55 ` [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface Benjamin Bigler
2024-03-25 13:24 ` Parthiban.Veerasooran
2024-03-25 14:01 ` Andrew Lunn
2024-03-26 9:43 ` Parthiban.Veerasooran
2024-04-03 21:40 ` Benjamin Bigler
2024-04-08 13:41 ` Parthiban.Veerasooran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97872e83-1490-4f1a-81ff-3f7692571dd1@microchip.com \
--to=parthiban.veerasooran@microchip.com \
--cc=Horatiu.Vultur@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Steen.Hegelund@microchip.com \
--cc=Thorsten.Kummermehr@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=andrew@lunn.ch \
--cc=casper.casan@gmail.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®