From: <Conor.Dooley@microchip.com>
To: <michael@walle.cc>, <padmarao.b@gmail.com>
Cc: <anup.patel@wdc.com>, <atish.patra@wdc.com>, <bmeng.cn@gmail.com>,
<Cyril.Jean@microchip.com>, <Daire.McNamara@microchip.com>,
<hs@denx.de>, <Ivan.Griffin@microchip.com>,
<Lewis.Hanly@microchip.com>, <Padmarao.Begari@microchip.com>,
<rick@andestech.com>, <u-boot@lists.denx.de>,
<Valentina.FernandezAlanis@microchip.com>
Subject: Re: [PATCH v1 4/5] net: macb: Compatible as per device tree
Date: Thu, 11 Nov 2021 13:20:44 +0000 [thread overview]
Message-ID: <0b24bb1c-3365-2ccc-2030-e3501578fe1b@microchip.com> (raw)
In-Reply-To: <20211111125441.3344243-1-michael@walle.cc>
On 11/11/2021 12:54, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>>> If Linux driver does not need to be updated to support MPFS macb using
>>> existing compatible string but U-Boot driver has to, something is
>>> wrong on the U-Boot macb driver side.
>>>
>>> Would you please reconsider the whole changes?
>>>
>> We submitted patches(v1, v2) last year for the U-Boot MACB update for
>> 64-bit DMA access same like Linux MACB driver using "#ifdef
>> CONFIG_DMA_ADDR_T_64BIT" but one of the reviewer wanted to check 64-bit DMA
>> support at runtime instead of #ifdef and we updated the macb driver based
>> on the design config debug6 register of MACB hardware which supports 32-bit
>> or 64-bit DMA in patch(v3) but the SiFive FU540 MACB didn't work then the
>> reviewer suggested use compatible string instead of design config register
>> and updated same in patch(v4), these changes were tested and acknowledged
>> them at Patch v6.
>
> I agree with Bin here. You shouldn't introduce a new compatible just for
> u-boot. If you need one, please to it first in linux and get an ACK there.
> Or at least there should be patches for it pending in linux and it should
> be likely, that they will be accepted.
>
> Please work towards having one binding for u-boot and linux.
>
> -michael
>
I think the point that Padmarao is trying to make is that we don't need
a new compatible for 64-bit DMA in the linux macb driver - we just use
"cdns,macb" and enable CONFIG_ARCH_DMA_ADDR_T_64BIT. Padmarao previously
submitted patches which would have introduced the same behaviour to
u-boot, but after review was told to implement it using a compatible
string specific to our board rather than copying the linux approach.
Introducing that compatible string in linux would just be creating a
superfluous binding, no?
Conor.
next prev parent reply other threads:[~2021-11-11 16:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-22 8:56 [PATCH v1 0/5] Update Microchip PolarFire SoC support Padmarao Begari
2021-10-22 8:56 ` [PATCH v1 1/5] riscv: dts: Split Microchip device tree Padmarao Begari
2021-11-01 8:34 ` Leo Liang
2021-11-01 8:41 ` Bin Meng
2021-11-02 9:52 ` Padmarao Begari
2021-10-22 8:56 ` [PATCH v1 2/5] riscv: Update Microchip MPFS Icicle Kit support Padmarao Begari
2021-11-01 8:36 ` Leo Liang
2021-11-01 8:43 ` Bin Meng
2021-11-02 10:38 ` Padmarao Begari
2021-10-22 8:56 ` [PATCH v1 3/5] i2c: Add Microchip PolarFire SoC I2C driver Padmarao Begari
2021-11-01 8:53 ` Leo Liang
2021-10-22 8:56 ` [PATCH v1 4/5] net: macb: Compatible as per device tree Padmarao Begari
2021-11-01 8:30 ` Leo Liang
2021-11-01 8:44 ` Bin Meng
2021-11-02 11:03 ` Padmarao Begari
2021-11-02 12:45 ` Bin Meng
2021-11-03 11:47 ` Padmarao Begari
2021-11-03 13:10 ` Padmarao Begari
2021-11-11 8:07 ` Bin Meng
2021-11-11 9:06 ` Padmarao Begari
2021-11-11 12:54 ` Michael Walle
2021-11-11 13:17 ` Ivan.Griffin
2021-11-12 1:28 ` Bin Meng
2021-11-12 9:36 ` Padmarao Begari
2021-11-11 13:20 ` Conor.Dooley [this message]
2021-11-11 9:41 ` macb clock handling (Was: [PATCH v1 4/5] net: macb: Compatible as per device tree) Heiko Stübner
2021-11-25 19:32 ` Heiko Stübner
2021-10-22 8:56 ` [PATCH v1 5/5] doc: board: Update Microchip MPFS Icicle Kit doc Padmarao Begari
2021-11-01 8:33 ` Leo Liang
2021-11-01 8:46 ` Bin Meng
2021-11-02 11:04 ` Padmarao Begari
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=0b24bb1c-3365-2ccc-2030-e3501578fe1b@microchip.com \
--to=conor.dooley@microchip.com \
--cc=Cyril.Jean@microchip.com \
--cc=Daire.McNamara@microchip.com \
--cc=Ivan.Griffin@microchip.com \
--cc=Lewis.Hanly@microchip.com \
--cc=Padmarao.Begari@microchip.com \
--cc=Valentina.FernandezAlanis@microchip.com \
--cc=anup.patel@wdc.com \
--cc=atish.patra@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=hs@denx.de \
--cc=michael@walle.cc \
--cc=padmarao.b@gmail.com \
--cc=rick@andestech.com \
--cc=u-boot@lists.denx.de \
/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