From: Matthias Kaehlcke <mka@chromium.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
Date: Wed, 3 Jul 2019 15:56:48 -0700 [thread overview]
Message-ID: <20190703225648.GK250418@google.com> (raw)
In-Reply-To: <3e47639a-bbbb-f438-bc66-a29423090e95@gmail.com>
On Wed, Jul 03, 2019 at 11:27:41PM +0200, Heiner Kallweit wrote:
> On 03.07.2019 23:24, Matthias Kaehlcke wrote:
> > On Wed, Jul 03, 2019 at 11:01:09PM +0200, Heiner Kallweit wrote:
> >> On 03.07.2019 22:36, Matthias Kaehlcke wrote:
> >>> On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote:
> >>>> On 03.07.2019 21:37, Matthias Kaehlcke wrote:
> >>>>> The RTL8211E has extension pages, which can be accessed after
> >>>>> selecting a page through a custom method. Add a function to
> >>>>> modify bits in a register of an extension page and a helper for
> >>>>> selecting an ext page.
> >>>>>
> >>>>> rtl8211e_modify_ext_paged() is inspired by its counterpart
> >>>>> phy_modify_paged().
> >>>>>
> >>>>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >>>>> ---
> >>>>> Changes in v2:
> >>>>> - assign .read/write_page handlers for RTL8211E
> >>>>
> >>>> Maybe this was planned, but it's not part of the patch.
> >>>
> >>> Oops, it was definitely there when I tested ... I guess this got
> >>> somehow lost when changing the patch order and resolving minor
> >>> conflicts, seems like I only build tested after that :/
> >>>
> >> RTL8211E also supports normal pages (reg 0x1f = page).
> >> See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network
> >> chip has an integrated RTL8211E PHY. There settings on page 3 and 5
> >> are done.
> >> Therefore I would prefer to use .read/write_page for normal paging
> >> in all Realtek PHY drivers. Means the code here would remain as it
> >> is and just the changelog would need to be fixed.
> >
> > Do I understand correctly that you suggest an additional patch that
> > assigns .read/write_page() for all entries of realtek_drvs?
> >
>
> No, basically all the Realtek PHY drivers use the following already:
> .read_page = rtl821x_read_page,
> .write_page = rtl821x_write_page,
> What I mean is that this should stay as it is, and not be overwritten
> with the extended paging.
I now see the source of our/my misunderstanding. I'm working on a 4.19
kernel, which doesn't have your recent patch:
commit daf3ddbe11a2ff74c95bc814df8e5fe3201b4cb5
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri May 10 22:11:26 2019 +0200
net: phy: realtek: add missing page operations
That's what I intended to do for RTL8211E, no need to overwrite it
with the extended paging.
Thanks
Matthias
next prev parent reply other threads:[~2019-07-03 22:56 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 19:37 [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs Matthias Kaehlcke
2019-07-03 19:37 ` [PATCH v2 2/7] net: phy: realtek: Allow disabling RTL8211E EEE LED mode Matthias Kaehlcke
2019-07-03 20:09 ` Heiner Kallweit
2019-07-03 20:32 ` Matthias Kaehlcke
2019-07-03 19:37 ` [PATCH v2 3/7] dt-bindings: net: realtek: Add property to enable SSC Matthias Kaehlcke
2019-07-03 19:37 ` [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages Matthias Kaehlcke
2019-07-03 20:12 ` Heiner Kallweit
2019-07-03 20:36 ` Matthias Kaehlcke
2019-07-03 21:01 ` Heiner Kallweit
2019-07-03 21:24 ` Matthias Kaehlcke
2019-07-03 21:27 ` Heiner Kallweit
2019-07-03 22:56 ` Matthias Kaehlcke [this message]
2019-07-03 19:37 ` [PATCH v2 5/7] net: phy: realtek: Support SSC for the RTL8211E Matthias Kaehlcke
2019-07-03 19:37 ` [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode Matthias Kaehlcke
2019-07-03 20:07 ` Andrew Lunn
2019-07-03 20:13 ` Heiner Kallweit
2019-07-03 20:22 ` Heiner Kallweit
2019-07-03 21:37 ` Florian Fainelli
2019-07-03 23:23 ` Matthias Kaehlcke
2019-07-10 15:55 ` Rob Herring
2019-07-10 16:28 ` Florian Fainelli
2019-07-12 17:28 ` Matthias Kaehlcke
2019-07-12 17:20 ` Matthias Kaehlcke
2019-07-22 17:14 ` Matthias Kaehlcke
2019-07-22 19:01 ` Andrew Lunn
2019-07-22 19:14 ` Matthias Kaehlcke
2019-07-22 19:38 ` Andrew Lunn
2019-07-03 19:37 ` [PATCH v2 7/7] net: phy: realtek: configure RTL8211E LEDs Matthias Kaehlcke
2019-07-03 20:10 ` Andrew Lunn
2019-07-03 20:43 ` Matthias Kaehlcke
2019-07-03 20:28 ` Heiner Kallweit
2019-07-03 20:45 ` Matthias Kaehlcke
2019-07-03 20:21 ` [PATCH v2 1/7] dt-bindings: net: Add bindings for Realtek PHYs David Miller
2019-07-03 21:11 ` Rob Herring
2019-07-03 21:33 ` Andrew Lunn
2019-07-03 22:08 ` Matthias Kaehlcke
2019-07-05 16:18 ` Rob Herring
2019-07-05 16:17 ` Rob Herring
2019-07-05 16:29 ` Andrew Lunn
2019-07-05 17:07 ` Rob Herring
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=20190703225648.GK250418@google.com \
--to=mka@chromium.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).