RE: [net-next 1/3] net: dsa: optimize tx timestamp request handling
> -Original Message- > From: Vladimir Oltean > Sent: 2021年4月18日 17:19 > To: Y.b. Lu > Cc: net...@vger.kernel.org; Richard Cochran ; > Vladimir Oltean ; David S . Miller > ; Jakub Kicinski ; Jonathan Corbet > ; Kurt Kanzenbach ; Andrew Lunn > ; Vivien Didelot ; Florian > Fainelli ; Claudiu Manoil ; > Alexandre Belloni ; > unglinuxdri...@microchip.com; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling > > On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote: > > Optimization could be done on dsa_skb_tx_timestamp(), and dsa device > > drivers should adapt to it. > > > > - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in > > port_txtstamp, so that most skbs not requiring tx timestamp just return. > > Agree that this is a trivial performance optimization with no downside that we > should be making. > > > - No longer to identify PTP packets, and limit tx timestamping only for PTP > > packets. If device driver likes, let device driver do. > > Agree that DSA has a way too heavy hand in imposing upon the driver which > packets should be timestampable and which ones shouldn't. > > For example, I have a latency measurement tool called isochron which is based > on hardware timestamping of non-PTP packets (in order to not disturb the PTP > state machines): > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fvladimiroltean%2Ftsn-scriptsdata=04%7C01%7Cyangbo.lu%40 > nxp.com%7C3772f63deb6f4491933208d9024af750%7C686ea1d3bc2b4c6fa9 > 2cd99c5c301635%7C0%7C0%7C637543343267914018%7CUnknown%7CTW > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C1000sdata=deOn03j6biPEUwppNkv%2F9if1u5HIdLEtzz > AkWW0p1rc%3Dreserved=0 > > I can't use it on DSA interfaces, for rather artificial reasons. > > > - It is a waste to clone skb directly in dsa_skb_tx_timestamp(). > > For one-step timestamping, a clone is not needed. For any failure of > > port_txtstamp (this may usually happen), the skb clone has to be freed. > > So put skb cloning into port_txtstamp where it really needs. > > Mostly agree. For two-step timestamping, it is an operation which all drivers > need to do, so it is in the common potion. If we want to support one-step, we > need to avoid cloning the PTP packets. > Thanks a lot for your ACK. > > Signed-off-by: Yangbo Lu > > --- > > Documentation/networking/timestamping.rst | 7 +-- > > .../net/dsa/hirschmann/hellcreek_hwtstamp.c | 20 -- > > .../net/dsa/hirschmann/hellcreek_hwtstamp.h | 2 +- > > drivers/net/dsa/mv88e6xxx/hwtstamp.c | 21 > +-- > > drivers/net/dsa/mv88e6xxx/hwtstamp.h | 6 +++--- > > drivers/net/dsa/ocelot/felix.c| 11 ++ > > drivers/net/dsa/sja1105/sja1105_ptp.c | 6 +- > > drivers/net/dsa/sja1105/sja1105_ptp.h | 2 +- > > include/net/dsa.h | 2 +- > > net/dsa/slave.c | 20 +- > > 10 files changed, 57 insertions(+), 40 deletions(-) > > > > diff --git a/Documentation/networking/timestamping.rst > > b/Documentation/networking/timestamping.rst > > index f682e88fa87e..7f04a699a5d1 100644 > > --- a/Documentation/networking/timestamping.rst > > +++ b/Documentation/networking/timestamping.rst > > @@ -635,8 +635,8 @@ in generic code: a BPF classifier > > (``ptp_classify_raw``) is used to identify PTP event messages (any > > other packets, including PTP general messages, are not timestamped), and > provides two hooks to drivers: > > > > -- ``.port_txtstamp()``: The driver is passed a clone of the > > timestampable skb > > - to be transmitted, before actually transmitting it. Typically, a > > switch will > > +- ``.port_txtstamp()``: A clone of the timestampable skb to be > > +transmitted > > + is needed, before actually transmitting it. Typically, a switch > > +will > >have a PTP TX timestamp register (or sometimes a FIFO) where the > timestamp > >becomes available. There may be an IRQ that is raised upon this > timestamp's > >availability, or the driver might have to poll after invoking @@ > > -645,6 +645,9 @@ timestamped), and provides two hooks to drivers: > >later use (when the timestamp becomes available). Each skb is annotated > with > >a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the > > driver's > >job of keeping track of which clo
RE: [net-next 1/3] net: dsa: optimize tx timestamp request handling
> -Original Message- > From: Richard Cochran > Sent: 2021年4月18日 23:06 > To: Y.b. Lu > Cc: net...@vger.kernel.org; Vladimir Oltean ; > David S . Miller ; Jakub Kicinski ; > Jonathan Corbet ; Kurt Kanzenbach ; > Andrew Lunn ; Vivien Didelot ; > Florian Fainelli ; Claudiu Manoil > ; Alexandre Belloni > ; unglinuxdri...@microchip.com; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling > > On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote: > > Optimization could be done on dsa_skb_tx_timestamp(), and dsa device > > drivers should adapt to it. > > > > - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in > > port_txtstamp, so that most skbs not requiring tx timestamp just return. > > > > - No longer to identify PTP packets, and limit tx timestamping only for PTP > > packets. If device driver likes, let device driver do. > > > > - It is a waste to clone skb directly in dsa_skb_tx_timestamp(). > > For one-step timestamping, a clone is not needed. For any failure of > > port_txtstamp (this may usually happen), the skb clone has to be freed. > > So put skb cloning into port_txtstamp where it really needs. > > This patch changes three things ^^^ at once. These are AFAICT independent > changes, and so please break this one patch into three for easier review. Will split it in next version. Thank you. > > Thanks, > Richard
RE: [net-next 1/3] net: dsa: optimize tx timestamp request handling
> -Original Message- > From: Richard Cochran > Sent: 2021年4月18日 23:11 > To: Vladimir Oltean > Cc: Y.b. Lu ; net...@vger.kernel.org; Vladimir Oltean > ; David S . Miller ; Jakub > Kicinski ; Jonathan Corbet ; Kurt > Kanzenbach ; Andrew Lunn ; Vivien > Didelot ; Florian Fainelli ; > Claudiu Manoil ; Alexandre Belloni > ; unglinuxdri...@microchip.com; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling > > On Sun, Apr 18, 2021 at 12:18:42PM +0300, Vladimir Oltean wrote: > > > > How about not passing "clone" back to DSA as an argument by reference, > > but instead require the driver to populate DSA_SKB_CB(skb)->clone if > > it needs to do so? > > > > Also, how about changing the return type to void? Returning true or > > false makes no difference. Thank you. That's good idea. And how about letting driver store the skb clone pointer, or not? I copied my comments in patch #3 here, " Can we totally drop dsa_skb_cb in dsa core? The only usage of it is holding a skb clone pointer, for only felix and sja1105. Actually we can move such pointer in _skb_cb, instead of reserving the space of skb for any drivers." > > +1 > > Thanks, > Richard
RE: [net-next 3/3] net: mscc: ocelot: support PTP Sync one-step timestamping
Hi Vladimir,
> -Original Message-
> From: Vladimir Oltean
> Sent: 2021年4月18日 17:46
> To: Y.b. Lu
> Cc: net...@vger.kernel.org; Richard Cochran ;
> Vladimir Oltean ; David S . Miller
> ; Jakub Kicinski ; Jonathan Corbet
> ; Kurt Kanzenbach ; Andrew Lunn
> ; Vivien Didelot ; Florian
> Fainelli ; Claudiu Manoil ;
> Alexandre Belloni ;
> unglinuxdri...@microchip.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [net-next 3/3] net: mscc: ocelot: support PTP Sync one-step
> timestamping
>
> On Fri, Apr 16, 2021 at 08:36:55PM +0800, Yangbo Lu wrote:
> > Although HWTSTAMP_TX_ONESTEP_SYNC existed in ioctl for hardware
> > timestamp configuration, the PTP Sync one-step timestamping had never
> been supported.
> >
> > This patch is to truely support it.
>
> Actually the ocelot switchdev driver does support one-step timestamping, just
> the felix DSA driver does not.
Actually I don’t think ocelot support one-step timestamping properly.
Without one-step sync packet identification, the one-step timestamping is
applying to all packets requiring timestamp.
The user space PTP stack won't work.
>
> > The hardware timestamp request type is stored in DSA_SKB_CB_PRIV first
> > byte per skb, so that corresponding configuration could be done during
> > transmitting. Non-onestep-Sync packet with one-step timestamp request
> > should fall back to use two-step timestamp.
> >
> > Signed-off-by: Yangbo Lu
> > ---
> > drivers/net/ethernet/mscc/ocelot.c | 57
> ++
> > drivers/net/ethernet/mscc/ocelot_net.c | 5 +--
> > include/soc/mscc/ocelot.h | 1 +
> > net/dsa/tag_ocelot.c | 25 ++-
> > net/dsa/tag_ocelot_8021q.c | 39 +-
> > 5 files changed, 72 insertions(+), 55 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mscc/ocelot.c
> > b/drivers/net/ethernet/mscc/ocelot.c
> > index 541d3b4076be..69d36b6241ff 100644
> > --- a/drivers/net/ethernet/mscc/ocelot.c
> > +++ b/drivers/net/ethernet/mscc/ocelot.c
> > @@ -6,6 +6,7 @@
> > */
> > #include
> > #include
> > +#include
> > #include
> > #include "ocelot.h"
> > #include "ocelot_vcap.h"
> > @@ -546,6 +547,50 @@ static void ocelot_port_add_txtstamp_skb(struct
> ocelot *ocelot, int port,
> > spin_unlock(_port->ts_id_lock);
> > }
> >
> > +bool ocelot_ptp_rew_op(struct sk_buff *skb, struct sk_buff *clone,
> > +u32 *rew_op) {
> > + /* For two-step timestamp, retrieve ptp_cmd in DSA_SKB_CB_PRIV
> > +* and timestamp ID in clone->cb[0].
> > +* For one-step timestamp, retrieve ptp_cmd in DSA_SKB_CB_PRIV.
> > +*/
> > + u8 *ptp_cmd = DSA_SKB_CB_PRIV(skb);
>
> This is fine in the sense that it works, but please consider creating
> something
> similar to sja1105:
>
> struct ocelot_skb_cb {
> u8 ptp_cmd; /* For both one-step and two-step timestamping */
> u8 ts_id; /* Only for two-step timestamping */ };
>
> #define OCELOT_SKB_CB(skb) \
> ((struct ocelot_skb_cb *)DSA_SKB_CB_PRIV(skb))
>
> And then access as OCELOT_SKB_CB(skb)->ptp_cmd,
> OCELOT_SKB_CB(clone)->ts_id.
>
> and put a comment to explain that this is done in order to have common code
> between Felix DSA and Ocelot switchdev. Basically Ocelot will not use the
> first
> 8 bytes of skb->cb, but there's enough space for this to not make any
> difference. The original skb will hold only ptp_cmd, the clone will only hold
> ts_id, but it helps to have the same structure in place.
>
> If you create this ocelot_skb_cb structure, I expect the comment above to be
> fairly redundant, you can consider removing it.
>
You're right to define the structure.
Considering patch #1, move skb cloning to drivers, and populate
DSA_SKB_CB(skb)->clone if needs to do so (per suggestion).
Can we totally drop dsa_skb_cb in dsa core? The only usage of it is holding a
skb clone pointer, for only felix and sja1105.
Actually we can move such pointer in _skb_cb, instead of reserving the
space of skb for any drivers.
Do you think so?
> > +
> > + if (clone) {
> > + *rew_op = *ptp_cmd;
> > + *rew_op |= clone->cb[0] << 3;
> > + } else if (*ptp_cmd) {
> > + *rew_op = *ptp_cmd;
> > + } else {
> > + return false;
> > + }
> > +
> > + return true;
>
> Just make this function return an u32. If the packet isn't PTP, the rew_op
> will
> be 0.
Ok. Thanks.
>
> > +}
> > +EXPORT_SY
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
> -Original Message-
> From: Shawn Guo
> Sent: Monday, November 30, 2020 10:29 PM
> To: Michael Walle
> Cc: Y.b. Lu ; Vladimir Oltean
> ; Leo Li ; Rob Herring
> ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; Adrian Hunter ; Ulf
> Hansson ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Ashish Kumar
> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
>
> On Wed, Nov 25, 2020 at 09:25:23AM +0100, Michael Walle wrote:
> > We are going cirlces here. I guess Shawn (as the soc maintainer) has to
> > step in and decide if a common soc include should contain aliases for
> > nodes which are disabled. That is what it boils down to.
> >
> > All other arguments against having aliases in the common include can be
> > found in this thread.
> >
> > > Distros, bootloaders, and users' cases using fixed index before could
> > > avoid issues, and been used as they were.
> >
> > Nobody argue against having these alias. We are arguing against having
> > them in the common soc include.
>
> 342ab37ecaf8 ("arm64: dts: freescale: use fixed index mmcN for
> layerscape") is dropped from my tree.
Ok, fine. Let me send board dts patches for NXP development boards instead.
Thanks.
>
> Shawn
RE: [PATCH] arm64: dts: freescale: sl28: correct MMC order
> -Original Message-
> From: Michael Walle
> Sent: Wednesday, November 25, 2020 5:21 AM
> To: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: Shawn Guo ; Leo Li ; Rob
> Herring ; Y.b. Lu ; Vladimir
> Oltean ; Michael Walle
> Subject: [PATCH] arm64: dts: freescale: sl28: correct MMC order
>
> Commit 342ab37ecaf8 ("arm64: dts: freescale: use fixed index mmcN for
> layerscape") hardcoded the order of the MMC devices. This doesn't fit
> the sl28 boards, which come with an onboard eMMC. Thus use the more
> natural order for the eMMC and SD card. Use /dev/mmcblk0 for the eMMC
> and /dev/mmcblk1 for the SD card which is removable by the user.
>
> Please note, that the images for this board already use root=UUID=,
> therefore the actual device number doesn't matter for booting.
>
> Signed-off-by: Michael Walle
It's ok for me to re-define mmc alias.
Reviewed-by: Yangbo Lu
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> index fbaecf285d05..6da4a28c4d19 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> @@ -18,6 +18,8 @@
>
> aliases {
> crypto =
> + mmc0 =
> + mmc1 =
> serial0 =
> serial1 =
> serial2 =
> --
> 2.20.1
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Vladimir,
> -Original Message-
> From: Vladimir Oltean
> Sent: Tuesday, November 24, 2020 7:28 PM
> To: Y.b. Lu
> Cc: Michael Walle ; Shawn Guo ;
> Leo Li ; Rob Herring ;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Adrian
> Hunter ; Ulf Hansson ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ashish Kumar
>
> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
>
> On Tue, Nov 24, 2020 at 11:15:19AM +, Y.b. Lu wrote:
> > > > Not matter it's SD card or eMMC card, if it's on esdhc0, use
> /dev/mmcblk0.
> > > > Not matter it's SD card or eMMC card, if it's on esdhc1, use
> /dev/mmcblk1.
> > >
> > > With the note here that you can't actually connect an SD card to eSDHC1,
> > > due to the lack of pins for CD/WP.
> >
> > CD/WP is not essential to support SD card. Both SD/eMMC are supported on
> both eSDHC controllers.
>
> Let's keep that discussion separate. While in theory you might be right,
> I think the real-life complications associated with connecting an eMMC
> to eSDHC0 and an SD card to eSDHC1 will make everyone avoid that. So in
> practice they are still single-purpose.
You may refer to Layerscape QDS boards. 5 types SDHC adapters with PCIe
connecter supporting SD or eMMC could be used on each esdhc interface.
Another reason using default mmc0 for esdhc0 and mmc1 for esdhc1, is because
that's also the order before esdhc driver introducing asynchronous probe.
Distros, bootloaders, and users' cases using fixed index before could avoid
issues, and been used as they were.
Thanks.
>
> > > But it is also natural for a customer to define the indices according to
> > > their schematics and what they use. If, say, there is a board that only
> > > uses eMMC, I would expect that for the lay person, no one would even bat
> > > an eye if that was called /dev/mmcblk0. Whereas, if it was called
> > > /dev/mmcblk1 (and there was no /dev/mmcblk0 in the system), maybe
> you'd
> > > have to come up with some explanations which could be avoided.
> >
> > To make a product friendly to users, it makes sense to define different
> > alias
> for controller in board dts.
> > But it's not the reason to remove the default/natural alias in soc dtsi for
> > two
> controllers.
> > What needs to be done after removing them? Add the same to all other
> board files?
>
> Yes.
> In fact, this is also the reason why we prefer to have:
> /soc {
> esdhc: mmc@214 {
> status = "disabled";
> };
> };
> in fsl-ls1028a.dtsi
> and
> {
> status = "okay";
> };
> in fsl-ls1028a-rdb.dts
> and not the other way around:
>
> /soc {
> esdhc: mmc@214 {
> status = "okay";
> };
> };
> in fsl-ls1028a.dtsi
> and
> {
> status = "disabled";
> };
> in fsl-ls1028a-rdb.dts
>
> So, in line with that, I think that the entity that enables the node
> should also define the alias.
>
> It's weird to use /delete-property/ if it can be avoided.
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Vladimir,
> -Original Message-
> From: Vladimir Oltean
> Sent: Tuesday, November 24, 2020 6:31 PM
> To: Y.b. Lu
> Cc: Michael Walle ; Shawn Guo ;
> Leo Li ; Rob Herring ;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Adrian
> Hunter ; Ulf Hansson ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ashish Kumar
>
> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
>
> Hi Yangbo,
>
> On Tue, Nov 24, 2020 at 09:02:57AM +, Y.b. Lu wrote:
> > > Am 2020-11-24 09:47, schrieb Y.b. Lu:
> > > > Hi Michael,
> > > >> > I don't think it's a problem in board dts to define board specific
> > > >> > thing, like re-defining alias, and disabling any IP it not using.
> > > >>
> > > >> First, why would you put it in the architecture include anyway? That
> > > >> is really board-specific. That is like you would say, we enable all
> > > >> devices and a board could potentially disable it. TBH it seems that
> > > >> this will fit your reference boards and you don't care about the
> > > >> other ones which uses that include.
> > > >
> > > > In soc dtsi, this is giving default alias for two esdhc controllers.
> > > > This is not board specific.
> > > > That's natural esdhc0 is mmc0 and esdhc1 is mmc1.
> > >
> > > How could this be not board specific if there are at least three
> > > different use cases the board can choose from - and needs three
> > > different configurations:
> > >
> > > (1) eMMC at /dev/mmcblk0, SD card at /dev/mmcblk1
> > > (2) SD card at /dev/mmcblk0, eMMC at /dev/mmcblk1
> > > (3) no eMMC at all, SD card at /dev/mmcblk0
> >
> > Not matter it's SD card or eMMC card, if it's on esdhc0, use /dev/mmcblk0.
> > Not matter it's SD card or eMMC card, if it's on esdhc1, use /dev/mmcblk1.
>
> With the note here that you can't actually connect an SD card to eSDHC1,
> due to the lack of pins for CD/WP.
CD/WP is not essential to support SD card. Both SD/eMMC are supported on both
eSDHC controllers.
>
> > It's not related to board and card type, it's only related to esdhc
> > interface in
> use.
>
> I understand the hardware-centric view that you are coming from. It may
> be natural for you that eSDHC0 is for the SD card and eSDHC1 is for eMMC,
> because these are the designations in the SoC.
Right, from hardware-centric view, it's natural esdhc0 interface is mmc0, and
esdhc1 is mmc1.
That's what I explained for why I added the alias in common soc dtsi.
>
> But it is also natural for a customer to define the indices according to
> their schematics and what they use. If, say, there is a board that only
> uses eMMC, I would expect that for the lay person, no one would even bat
> an eye if that was called /dev/mmcblk0. Whereas, if it was called
> /dev/mmcblk1 (and there was no /dev/mmcblk0 in the system), maybe you'd
> have to come up with some explanations which could be avoided.
To make a product friendly to users, it makes sense to define different alias
for controller in board dts.
But it's not the reason to remove the default/natural alias in soc dtsi for two
controllers.
What needs to be done after removing them? Add the same to all other board
files?
This is just my opinion. I don't decide on this:)
>
> I am only a passerby when it comes to the MMC subsystem. But in
> networking/DSA, it is frequent that the board designer comes up with
> their own numbering scheme, which has nothing to do with the numbering
> of the chip. Consider this extreme case from
> arch/arm/boot/dts/ls1021a-tsn.dts:
>
> sja1105: ethernet-switch@1 {
> ports {
> port@0 {
> /* ETH5 written on chassis */
> label = "swp5";
> };
>
> port@1 {
> /* ETH2 written on chassis */
> label = "swp2";
> };
>
> port@2 {
> /* ETH3 written on chassis */
> label = "swp3";
> };
>
> port@3 {
> /* ETH4 written on chassis */
> label = "swp4";
> };
> };
> };
>
> You just have to go along with how the hardware is being used in the
> product. I could have insisted that hardware switch port 0 is named as
> swp0, but that would have not helped anybody.
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Michael, > -Original Message- > From: Michael Walle > Sent: Tuesday, November 24, 2020 5:43 PM > To: Y.b. Lu > Cc: Vladimir Oltean ; Shawn Guo > ; Leo Li ; Rob Herring > ; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Adrian Hunter ; Ulf > Hansson ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Ashish Kumar > Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > controllers use fixed indices > > Am 2020-11-24 10:22, schrieb Y.b. Lu: > > Hi Michael, > > > >> -Original Message- > >> From: Michael Walle > >> Sent: Tuesday, November 24, 2020 5:08 PM > >> To: Y.b. Lu > >> Cc: Vladimir Oltean ; Shawn Guo > >> ; Leo Li ; Rob Herring > >> ; linux-arm-ker...@lists.infradead.org; > >> devicet...@vger.kernel.org; Adrian Hunter ; > >> Ulf > >> Hansson ; linux-...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; Ashish Kumar > >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> controllers use fixed indices > >> > >> Am 2020-11-24 10:02, schrieb Y.b. Lu: > >> > Hi Michael, > >> > > >> >> -Original Message- > >> >> From: Michael Walle > >> >> Sent: Tuesday, November 24, 2020 4:55 PM > >> >> To: Y.b. Lu > >> >> Cc: Vladimir Oltean ; Shawn Guo > >> >> ; Leo Li ; Rob Herring > >> >> ; linux-arm-ker...@lists.infradead.org; > >> >> devicet...@vger.kernel.org; Adrian Hunter ; > >> >> Ulf > >> >> Hansson ; linux-...@vger.kernel.org; > >> >> linux-kernel@vger.kernel.org; Ashish Kumar > >> >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> >> controllers use fixed indices > >> >> > >> >> Am 2020-11-24 09:47, schrieb Y.b. Lu: > >> >> > Hi Michael, > >> >> > > >> >> >> -Original Message- > >> >> >> From: Michael Walle > >> >> >> Sent: Tuesday, November 24, 2020 4:03 PM > >> >> >> To: Y.b. Lu > >> >> >> Cc: Vladimir Oltean ; Shawn Guo > >> >> >> ; Leo Li ; Rob Herring > >> >> >> ; linux-arm-ker...@lists.infradead.org; > >> >> >> devicet...@vger.kernel.org; Adrian Hunter > ; > >> >> >> Ulf > >> >> >> Hansson ; linux-...@vger.kernel.org; > >> >> >> linux-kernel@vger.kernel.org; Ashish Kumar > > >> >> >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD > card > >> >> >> controllers use fixed indices > >> >> >> > >> >> >> Am 2020-11-24 08:41, schrieb Y.b. Lu: > >> >> >> > Hi Vladimir, > >> >> >> > > >> >> >> >> -Original Message- > >> >> >> >> From: Vladimir Oltean > >> >> >> >> Sent: Friday, November 20, 2020 5:30 PM > >> >> >> >> To: Y.b. Lu > >> >> >> >> Cc: Shawn Guo ; Leo Li > >> ; > >> >> Rob > >> >> >> >> Herring ; > linux-arm-ker...@lists.infradead.org; > >> >> >> >> devicet...@vger.kernel.org; Adrian Hunter > >> ; > >> >> >> >> Ulf > >> >> >> >> Hansson ; linux-...@vger.kernel.org; > >> >> >> >> linux-kernel@vger.kernel.org; Ashish Kumar > >> ; > >> >> >> >> Michael Walle > >> >> >> >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD > >> card > >> >> >> >> controllers use fixed indices > >> >> >> >> > >> >> >> >> On Fri, Nov 20, 2020 at 02:04:02AM +, Y.b. Lu wrote: > >> >> >> >> > Hi Vladimir, > >> >> >> >> > > >> >> >> >> > I have already upstreamed a patch for all affected layerscape > >> boards. > >> >> >> >> > > >> >> >> >> > >> >> >> > >> >> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > >> >> >> > >> >> > >> > el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fshawnguo%2
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Michael, > -Original Message- > From: Michael Walle > Sent: Tuesday, November 24, 2020 5:08 PM > To: Y.b. Lu > Cc: Vladimir Oltean ; Shawn Guo > ; Leo Li ; Rob Herring > ; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Adrian Hunter ; Ulf > Hansson ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Ashish Kumar > Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > controllers use fixed indices > > Am 2020-11-24 10:02, schrieb Y.b. Lu: > > Hi Michael, > > > >> -Original Message- > >> From: Michael Walle > >> Sent: Tuesday, November 24, 2020 4:55 PM > >> To: Y.b. Lu > >> Cc: Vladimir Oltean ; Shawn Guo > >> ; Leo Li ; Rob Herring > >> ; linux-arm-ker...@lists.infradead.org; > >> devicet...@vger.kernel.org; Adrian Hunter ; > >> Ulf > >> Hansson ; linux-...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; Ashish Kumar > >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> controllers use fixed indices > >> > >> Am 2020-11-24 09:47, schrieb Y.b. Lu: > >> > Hi Michael, > >> > > >> >> -Original Message- > >> >> From: Michael Walle > >> >> Sent: Tuesday, November 24, 2020 4:03 PM > >> >> To: Y.b. Lu > >> >> Cc: Vladimir Oltean ; Shawn Guo > >> >> ; Leo Li ; Rob Herring > >> >> ; linux-arm-ker...@lists.infradead.org; > >> >> devicet...@vger.kernel.org; Adrian Hunter ; > >> >> Ulf > >> >> Hansson ; linux-...@vger.kernel.org; > >> >> linux-kernel@vger.kernel.org; Ashish Kumar > >> >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> >> controllers use fixed indices > >> >> > >> >> Am 2020-11-24 08:41, schrieb Y.b. Lu: > >> >> > Hi Vladimir, > >> >> > > >> >> >> -Original Message- > >> >> >> From: Vladimir Oltean > >> >> >> Sent: Friday, November 20, 2020 5:30 PM > >> >> >> To: Y.b. Lu > >> >> >> Cc: Shawn Guo ; Leo Li > ; > >> Rob > >> >> >> Herring ; linux-arm-ker...@lists.infradead.org; > >> >> >> devicet...@vger.kernel.org; Adrian Hunter > ; > >> >> >> Ulf > >> >> >> Hansson ; linux-...@vger.kernel.org; > >> >> >> linux-kernel@vger.kernel.org; Ashish Kumar > ; > >> >> >> Michael Walle > >> >> >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD > card > >> >> >> controllers use fixed indices > >> >> >> > >> >> >> On Fri, Nov 20, 2020 at 02:04:02AM +, Y.b. Lu wrote: > >> >> >> > Hi Vladimir, > >> >> >> > > >> >> >> > I have already upstreamed a patch for all affected layerscape > boards. > >> >> >> > > >> >> >> > >> >> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > >> >> > >> > el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fshawnguo%2Flinux.git%2 > >> >> > >> > Fcommit%2Fdata=04%7C01%7Cyangbo.lu%40nxp.com%7C498622ade > >> >> > >> > e704fc0042008d8904f6184%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 > >> >> %7C0%7C637418017917635725%7CUnknown%7CTWFpbGZsb3d8eyJW > Ijoi > >> M > >> >> > >> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > >> >> > >> > sdata=OciS3q%2BmP%2Bz4x1ewPHDigmUkgIZmBgUlRRTm4yaxB7s%3D > >> >> reserved=0? > >> >> >> h=imx/dt64=342ab37ecaf8c1b10dd3ca9a1271db29a6af0705 > >> >> >> > > >> >> >> > Please check whether it works for you. > >> >> >> > >> >> >> Thanks, one can tell that I haven't done my due diligence of checking > >> >> >> Shawn's tree first. I'll cherry-pick that patch and carry on with my > >> >> >> work. > >> >> >> > >> >> >> However, the fact still remains that Michael has expressed his > >> >> >> opinion > >> >> >> regarding mmcblk0 vs mmcblk1. Do you think that we could make > the > >> >> >> aliases
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Michael, > -Original Message- > From: Michael Walle > Sent: Tuesday, November 24, 2020 4:55 PM > To: Y.b. Lu > Cc: Vladimir Oltean ; Shawn Guo > ; Leo Li ; Rob Herring > ; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Adrian Hunter ; Ulf > Hansson ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Ashish Kumar > Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > controllers use fixed indices > > Am 2020-11-24 09:47, schrieb Y.b. Lu: > > Hi Michael, > > > >> -Original Message- > >> From: Michael Walle > >> Sent: Tuesday, November 24, 2020 4:03 PM > >> To: Y.b. Lu > >> Cc: Vladimir Oltean ; Shawn Guo > >> ; Leo Li ; Rob Herring > >> ; linux-arm-ker...@lists.infradead.org; > >> devicet...@vger.kernel.org; Adrian Hunter ; > >> Ulf > >> Hansson ; linux-...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; Ashish Kumar > >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> controllers use fixed indices > >> > >> Am 2020-11-24 08:41, schrieb Y.b. Lu: > >> > Hi Vladimir, > >> > > >> >> -Original Message- > >> >> From: Vladimir Oltean > >> >> Sent: Friday, November 20, 2020 5:30 PM > >> >> To: Y.b. Lu > >> >> Cc: Shawn Guo ; Leo Li ; > Rob > >> >> Herring ; linux-arm-ker...@lists.infradead.org; > >> >> devicet...@vger.kernel.org; Adrian Hunter ; > >> >> Ulf > >> >> Hansson ; linux-...@vger.kernel.org; > >> >> linux-kernel@vger.kernel.org; Ashish Kumar ; > >> >> Michael Walle > >> >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> >> controllers use fixed indices > >> >> > >> >> On Fri, Nov 20, 2020 at 02:04:02AM +, Y.b. Lu wrote: > >> >> > Hi Vladimir, > >> >> > > >> >> > I have already upstreamed a patch for all affected layerscape boards. > >> >> > > >> >> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > >> > el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fshawnguo%2Flinux.git%2 > >> > Fcommit%2Fdata=04%7C01%7Cyangbo.lu%40nxp.com%7C498622ade > >> > e704fc0042008d8904f6184%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 > >> %7C0%7C637418017917635725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > M > >> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > >> > sdata=OciS3q%2BmP%2Bz4x1ewPHDigmUkgIZmBgUlRRTm4yaxB7s%3D > >> reserved=0? > >> >> h=imx/dt64=342ab37ecaf8c1b10dd3ca9a1271db29a6af0705 > >> >> > > >> >> > Please check whether it works for you. > >> >> > >> >> Thanks, one can tell that I haven't done my due diligence of checking > >> >> Shawn's tree first. I'll cherry-pick that patch and carry on with my > >> >> work. > >> >> > >> >> However, the fact still remains that Michael has expressed his opinion > >> >> regarding mmcblk0 vs mmcblk1. Do you think that we could make the > >> >> aliases a per-board option instead of per-SoC? Consider that there > >> >> might > >> >> even be boards that only use SD card. It would be strange for the > >> >> block > >> >> device in that case to be called /dev/mmcblk1. > >> > > >> > I don't think it's a problem in board dts to define board specific > >> > thing, like re-defining alias, and disabling any IP it not using. > >> > >> First, why would you put it in the architecture include anyway? That > >> is really board-specific. That is like you would say, we enable all > >> devices and a board could potentially disable it. TBH it seems that > >> this will fit your reference boards and you don't care about the > >> other ones which uses that include. > > > > In soc dtsi, this is giving default alias for two esdhc controllers. > > This is not board specific. > > That's natural esdhc0 is mmc0 and esdhc1 is mmc1. > > How could this be not board specific if there are at least three > different use cases the board can choose from - and needs three > different configurations: > > (1) eMMC at /dev/mmcblk0, SD card at /dev/mmcblk1 > (2) SD card at /dev/mmcblk0, eMMC at /dev/mmcblk1 > (3) no eMMC at all, SD card at /dev/mmcblk0 Not matter it
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Michael, > -Original Message- > From: Michael Walle > Sent: Tuesday, November 24, 2020 4:03 PM > To: Y.b. Lu > Cc: Vladimir Oltean ; Shawn Guo > ; Leo Li ; Rob Herring > ; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Adrian Hunter ; Ulf > Hansson ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Ashish Kumar > Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > controllers use fixed indices > > Am 2020-11-24 08:41, schrieb Y.b. Lu: > > Hi Vladimir, > > > >> -Original Message- > >> From: Vladimir Oltean > >> Sent: Friday, November 20, 2020 5:30 PM > >> To: Y.b. Lu > >> Cc: Shawn Guo ; Leo Li ; Rob > >> Herring ; linux-arm-ker...@lists.infradead.org; > >> devicet...@vger.kernel.org; Adrian Hunter ; > >> Ulf > >> Hansson ; linux-...@vger.kernel.org; > >> linux-kernel@vger.kernel.org; Ashish Kumar ; > >> Michael Walle > >> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > >> controllers use fixed indices > >> > >> On Fri, Nov 20, 2020 at 02:04:02AM +, Y.b. Lu wrote: > >> > Hi Vladimir, > >> > > >> > I have already upstreamed a patch for all affected layerscape boards. > >> > > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fshawnguo%2Flinux.git%2 > Fcommit%2Fdata=04%7C01%7Cyangbo.lu%40nxp.com%7C498622ade > e704fc0042008d8904f6184%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 > %7C0%7C637418017917635725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > sdata=OciS3q%2BmP%2Bz4x1ewPHDigmUkgIZmBgUlRRTm4yaxB7s%3D > reserved=0? > >> h=imx/dt64=342ab37ecaf8c1b10dd3ca9a1271db29a6af0705 > >> > > >> > Please check whether it works for you. > >> > >> Thanks, one can tell that I haven't done my due diligence of checking > >> Shawn's tree first. I'll cherry-pick that patch and carry on with my > >> work. > >> > >> However, the fact still remains that Michael has expressed his opinion > >> regarding mmcblk0 vs mmcblk1. Do you think that we could make the > >> aliases a per-board option instead of per-SoC? Consider that there > >> might > >> even be boards that only use SD card. It would be strange for the > >> block > >> device in that case to be called /dev/mmcblk1. > > > > I don't think it's a problem in board dts to define board specific > > thing, like re-defining alias, and disabling any IP it not using. > > First, why would you put it in the architecture include anyway? That > is really board-specific. That is like you would say, we enable all > devices and a board could potentially disable it. TBH it seems that > this will fit your reference boards and you don't care about the > other ones which uses that include. In soc dtsi, this is giving default alias for two esdhc controllers. This is not board specific. That's natural esdhc0 is mmc0 and esdhc1 is mmc1. > > And as Vladimir pointed out, what do you do if you just have the eMMC > on the LS1028A. It will be mmcblk1 unless you do something like the > following in the board dts: > > mmc0 = > /delete-property/ mmc1; > > That is really cumbersome, isnt it? The soc dtsi gives default alias to make esdhc0 as mmc0, and esdhc1 as mmc1, the use case just needs to consider which esdhc controller is used. That's fixed index for it. No matter how the board is designed, there are two esdhc controllers in soc. It's probed as mmc0 and mmc1. It's use case that should choose the right mmc device. It is not the dts that should be changed to suit use case. If the board owner insists to change alias to make esdhc1 as mmc0, I think no problem. Just do it in board dts to override the default one. Thanks. > > -michael
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Vladimir, > -Original Message- > From: Vladimir Oltean > Sent: Friday, November 20, 2020 5:30 PM > To: Y.b. Lu > Cc: Shawn Guo ; Leo Li ; Rob > Herring ; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Adrian Hunter ; Ulf > Hansson ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Ashish Kumar ; > Michael Walle > Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card > controllers use fixed indices > > On Fri, Nov 20, 2020 at 02:04:02AM +, Y.b. Lu wrote: > > Hi Vladimir, > > > > I have already upstreamed a patch for all affected layerscape boards. > > > https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/? > h=imx/dt64=342ab37ecaf8c1b10dd3ca9a1271db29a6af0705 > > > > Please check whether it works for you. > > Thanks, one can tell that I haven't done my due diligence of checking > Shawn's tree first. I'll cherry-pick that patch and carry on with my > work. > > However, the fact still remains that Michael has expressed his opinion > regarding mmcblk0 vs mmcblk1. Do you think that we could make the > aliases a per-board option instead of per-SoC? Consider that there might > even be boards that only use SD card. It would be strange for the block > device in that case to be called /dev/mmcblk1. I don't think it's a problem in board dts to define board specific thing, like re-defining alias, and disabling any IP it not using. Thanks.
RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices
Hi Vladimir,
I have already upstreamed a patch for all affected layerscape boards.
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64=342ab37ecaf8c1b10dd3ca9a1271db29a6af0705
Please check whether it works for you.
Thanks.
Best regards,
Yangbo Lu
> -Original Message-
> From: Vladimir Oltean
> Sent: Thursday, November 19, 2020 11:50 PM
> To: Shawn Guo ; Leo Li ; Rob
> Herring ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org
> Cc: Adrian Hunter ; Ulf Hansson
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Ashish Kumar ; Y.b. Lu
> ; Michael Walle
> Subject: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
>
> As the boot order in the kernel continues to change, sometimes it may
> happen that the eSDHC controller mmc@215 (the one for eMMC) gets
> probed before the one at mmc@214 (for external SD cards). The effect
> is that the eMMC controller gets the /dev/mmcblk0 name, and the SD card
> gets /dev/mmcblk1.
>
> Since the introduction of this SoC, that has never happened in practice,
> even though it was never guaranteed in theory. Setting
> "root=/dev/mmcblk0p2" in /proc/cmdline has always caused the kernel to
> use the second partition from the SD card as the rootfs.
>
> Preserve that old behavior by adding some aliases which create naming
> consistency:
> - the SD card controller uses /dev/mmcblk0
> - the eMMC controller uses /dev/mmcblk1
>
> The aliases are parsed by mmc_alloc_host() in drivers/mmc/core/host.c.
>
> Cc: Ashish Kumar
> Cc: Yangbo Lu
> Cc: Michael Walle
> Signed-off-by: Vladimir Oltean
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts | 2 ++
> arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 2 ++
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 2 ++
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> index 8161dd237971..7d292999f8da 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
> @@ -23,6 +23,8 @@ aliases {
> serial2 =
> spi0 =
> spi1 =
> + mmc0 =
> + mmc1 =
> };
>
> buttons0 {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index 13cdc958ba3e..c0786b713791 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -23,6 +23,8 @@ aliases {
> gpio2 =
> serial0 =
> serial1 =
> + mmc0 =
> + mmc1 =
> };
>
> chosen {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index 1efb61cff454..c1d1ba459307 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -19,6 +19,8 @@ aliases {
> crypto =
> serial0 =
> serial1 =
> + mmc0 =
> + mmc1 =
> };
>
> chosen {
> --
> 2.25.1
RE: linux-next: Tree for Sep 21 (drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c)
Hi, > -Original Message- > From: Randy Dunlap > Sent: Monday, September 21, 2020 11:42 PM > To: Stephen Rothwell ; Linux Next Mailing List > > Cc: Linux Kernel Mailing List ; > net...@vger.kernel.org; Y.b. Lu ; Ioana Ciornei > ; Ioana Ciocoi Radulescu > > Subject: Re: linux-next: Tree for Sep 21 > (drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c) > > On 9/21/20 2:24 AM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20200918: > > > > on i386: > > ../drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c: In function > 'dpaa2_eth_ptp_parse': > ../drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:585:13: error: implicit > declaration of function 'ptp_get_msgtype'; did you mean 'get_fs_type'? > [-Werror=implicit-function-declaration] > *msgtype = ptp_get_msgtype(hdr, ptp_class); > ^~~ > get_fs_type I think a stub function is missing in ptp_classify.h. I sent a fix-up patch. https://patchwork.ozlabs.org/project/netdev/patch/20200927080150.8479-1-yangbo...@nxp.com/ Thanks. > > > Full randconfig file is attached. > > > -- > ~Randy > Reported-by: Randy Dunlap
RE: [PATCH 1/6] ptp: add QorIQ PTP support for DPAA2
> -Original Message- > From: Andrew Lunn > Sent: 2019年6月12日 21:11 > To: Y.b. Lu > Cc: net...@vger.kernel.org; David S . Miller ; > Richard Cochran ; Rob Herring > ; Shawn Guo ; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH 1/6] ptp: add QorIQ PTP support for DPAA2 > > > > > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index > > > > 9b8fee5..b1b454f 100644 > > > > --- a/drivers/ptp/Kconfig > > > > +++ b/drivers/ptp/Kconfig > > > > @@ -44,7 +44,7 @@ config PTP_1588_CLOCK_DTE > > > > > > > > config PTP_1588_CLOCK_QORIQ > > > > tristate "Freescale QorIQ 1588 timer as PTP clock" > > > > - depends on GIANFAR || FSL_DPAA_ETH || FSL_ENETC || > FSL_ENETC_VF > > > > + depends on GIANFAR || FSL_DPAA_ETH || FSL_DPAA2_ETH || > > > FSL_ENETC || > > > > +FSL_ENETC_VF > > > > depends on PTP_1588_CLOCK > > > > > > Hi Yangbo > > > > > > Could COMPILE_TEST also be added? > > > > [Y.b. Lu] COMPILE_TEST is usually for other ARCHs build coverage. > > Do you want me to append it after these Ethernet driver dependencies? > > Hii Y.b. Lu > > Normally, drivers like this should be able to compile independent of the MAC > driver. So you should be able to add COMPILE_TEST here. [Y.b. Lu] Thanks Andrew. I had sent out v2 with the change. > > Andrew
RE: [PATCH 1/6] ptp: add QorIQ PTP support for DPAA2
Hi Andrew, > -Original Message- > From: Andrew Lunn > Sent: 2019年6月10日 21:06 > To: Y.b. Lu > Cc: net...@vger.kernel.org; David S . Miller ; > Richard Cochran ; Rob Herring > ; Shawn Guo ; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH 1/6] ptp: add QorIQ PTP support for DPAA2 > > On Mon, Jun 10, 2019 at 11:21:03AM +0800, Yangbo Lu wrote: > > This patch is to add QorIQ PTP support for DPAA2. > > Although dpaa2-ptp.c driver is a fsl_mc_driver which is using MC APIs > > for register accessing, it's same IP block with eTSEC/DPAA/ENETC 1588 > > timer. We will convert to reuse ptp_qoriq driver by using register > > ioremap and dropping related MC APIs. > > > > Signed-off-by: Yangbo Lu > > --- > > drivers/ptp/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index > > 9b8fee5..b1b454f 100644 > > --- a/drivers/ptp/Kconfig > > +++ b/drivers/ptp/Kconfig > > @@ -44,7 +44,7 @@ config PTP_1588_CLOCK_DTE > > > > config PTP_1588_CLOCK_QORIQ > > tristate "Freescale QorIQ 1588 timer as PTP clock" > > - depends on GIANFAR || FSL_DPAA_ETH || FSL_ENETC || FSL_ENETC_VF > > + depends on GIANFAR || FSL_DPAA_ETH || FSL_DPAA2_ETH || > FSL_ENETC || > > +FSL_ENETC_VF > > depends on PTP_1588_CLOCK > > Hi Yangbo > > Could COMPILE_TEST also be added? [Y.b. Lu] COMPILE_TEST is usually for other ARCHs build coverage. Do you want me to append it after these Ethernet driver dependencies? Thanks. > > Thanks > Andrew
RE: [PATCH net-next v2, 0/4] ENETC: support hardware timestamping
> -Original Message- > From: Richard Cochran > Sent: Thursday, May 23, 2019 9:49 PM > To: Y.b. Lu > Cc: net...@vger.kernel.org; David Miller ; Claudiu > Manoil ; Shawn Guo ; Rob > Herring ; Alexandru Marginean > ; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH net-next v2, 0/4] ENETC: support hardware timestamping > > On Thu, May 23, 2019 at 02:33:24AM +, Y.b. Lu wrote: > > This patch-set is to support hardware timestamping for ENETC and also > > to add ENETC 1588 timer device tree node for ls1028a. > > Please, in the future, summarize the changes from the last series in the cover > letter. It helps the reviewers to focus. [Y.b. Lu] Sorry Richard. Will summarize all changes in cover letter in the future, besides change notes on each patch. Thanks. > > Thanks, > Richard
[PATCH net-next v2, 2/4] enetc: add get_ts_info interface for ethtool
This patch is to add get_ts_info interface for ethtool
to support getting timestamping capability.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/net/ethernet/freescale/enetc/enetc.h | 3 ++
.../ethernet/freescale/enetc/enetc_ethtool.c | 31 +++
.../net/ethernet/freescale/enetc/enetc_ptp.c | 5 +++
3 files changed, 39 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h
b/drivers/net/ethernet/freescale/enetc/enetc.h
index 281bb4368b98..ea443268bf70 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -209,6 +209,9 @@ struct enetc_msg_cmd_set_primary_mac {
#define ENETC_CBDR_TIMEOUT 1000 /* usecs */
+/* PTP driver exports */
+extern int enetc_phc_index;
+
/* SI common */
int enetc_pci_probe(struct pci_dev *pdev, const char *name, int sizeof_priv);
void enetc_pci_remove(struct pci_dev *pdev);
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index b9519b6ad727..fcb52efec075 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -555,6 +555,35 @@ static void enetc_get_ringparam(struct net_device *ndev,
}
}
+static int enetc_get_ts_info(struct net_device *ndev,
+struct ethtool_ts_info *info)
+{
+ int *phc_idx;
+
+ phc_idx = symbol_get(enetc_phc_index);
+ if (phc_idx) {
+ info->phc_index = *phc_idx;
+ symbol_put(enetc_phc_index);
+ } else {
+ info->phc_index = -1;
+ }
+
+#ifdef CONFIG_FSL_ENETC_HW_TIMESTAMPING
+ info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+
+ info->tx_types = (1 << HWTSTAMP_TX_OFF) |
+(1 << HWTSTAMP_TX_ON);
+ info->rx_filters = (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_ALL);
+#else
+ info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE;
+#endif
+ return 0;
+}
+
static const struct ethtool_ops enetc_pf_ethtool_ops = {
.get_regs_len = enetc_get_reglen,
.get_regs = enetc_get_regs,
@@ -571,6 +600,7 @@ static const struct ethtool_ops enetc_pf_ethtool_ops = {
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
.get_link = ethtool_op_get_link,
+ .get_ts_info = enetc_get_ts_info,
};
static const struct ethtool_ops enetc_vf_ethtool_ops = {
@@ -586,6 +616,7 @@ static const struct ethtool_ops enetc_vf_ethtool_ops = {
.set_rxfh = enetc_set_rxfh,
.get_ringparam = enetc_get_ringparam,
.get_link = ethtool_op_get_link,
+ .get_ts_info = enetc_get_ts_info,
};
void enetc_set_ethtool_ops(struct net_device *ndev)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
b/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
index 8c1497e7d9c5..2fd2586e42bf 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
@@ -7,6 +7,9 @@
#include "enetc.h"
+int enetc_phc_index = -1;
+EXPORT_SYMBOL(enetc_phc_index);
+
static struct ptp_clock_info enetc_ptp_caps = {
.owner = THIS_MODULE,
.name = "ENETC PTP clock",
@@ -96,6 +99,7 @@ static int enetc_ptp_probe(struct pci_dev *pdev,
if (err)
goto err_no_clock;
+ enetc_phc_index = ptp_qoriq->phc_index;
pci_set_drvdata(pdev, ptp_qoriq);
return 0;
@@ -119,6 +123,7 @@ static void enetc_ptp_remove(struct pci_dev *pdev)
{
struct ptp_qoriq *ptp_qoriq = pci_get_drvdata(pdev);
+ enetc_phc_index = -1;
ptp_qoriq_free(ptp_qoriq);
kfree(ptp_qoriq);
--
2.17.1
[PATCH net-next v2, 3/4] dt-binding: ptp_qoriq: support ENETC PTP compatible
Add a new compatible for ENETC PTP. Signed-off-by: Yangbo Lu --- Changes for v2: - Added this patch. --- Documentation/devicetree/bindings/ptp/ptp-qoriq.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt index 454c937076a2..6ec053449278 100644 --- a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt +++ b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt @@ -4,6 +4,7 @@ General Properties: - compatible Should be "fsl,etsec-ptp" for eTSEC Should be "fsl,fman-ptp-timer" for DPAA FMan +Should be "fsl,enetc-ptp" for ENETC - reg Offset and length of the register set for the device - interrupts There should be at least two interrupts. Some devices have as many as four PTP related interrupts. -- 2.17.1
[PATCH net-next v2, 1/4] enetc: add hardware timestamping support
This patch is to add hardware timestamping support
for ENETC. On Rx, timestamping is enabled for all
frames. On Tx, we only instruct the hardware to
timestamp the frames marked accordingly by the stack.
Because the RX BD ring dynamic allocation has not been
supported and it is too expensive to use extended RX BDs
if timestamping is not used, a Kconfig option is used to
enable extended RX BDs in order to support hardware
timestamping. This option will be removed once RX BD
ring dynamic allocation is implemented.
Signed-off-by: Yangbo Lu
Signed-off-by: Claudiu Manoil
---
Changes for v2:
- Rephrased Kconfig help message.
- Reverse Christmas tree order for variable definitions.
- Dropped goto in enetc_clean_tx_ring().
- Used name enetc_active_offloads instead of enetc_hw_features.
- Fixed up rx tstamp implementation.
- Rephrased commit message and added Claudiu.
---
drivers/net/ethernet/freescale/enetc/Kconfig | 10 ++
drivers/net/ethernet/freescale/enetc/enetc.c | 158 +-
drivers/net/ethernet/freescale/enetc/enetc.h | 12 +-
.../net/ethernet/freescale/enetc/enetc_hw.h | 13 ++
.../net/ethernet/freescale/enetc/enetc_pf.c | 1 +
.../net/ethernet/freescale/enetc/enetc_vf.c | 1 +
6 files changed, 189 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
b/drivers/net/ethernet/freescale/enetc/Kconfig
index 8429f5c1d810..ed0d010c7cf2 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -29,3 +29,13 @@ config FSL_ENETC_PTP_CLOCK
packets using the SO_TIMESTAMPING API.
If compiled as module (M), the module name is fsl-enetc-ptp.
+
+config FSL_ENETC_HW_TIMESTAMPING
+ bool "ENETC hardware timestamping support"
+ depends on FSL_ENETC || FSL_ENETC_VF
+ help
+ Enable hardware timestamping support on the Ethernet packets
+ using the SO_TIMESTAMPING API. Because the RX BD ring dynamic
+ allocation has not been supported and it is too expensive to use
+ extended RX BDs if timestamping is not used, this option enables
+ extended RX BDs in order to support hardware timestamping.
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c
b/drivers/net/ethernet/freescale/enetc/enetc.c
index 491475d87736..d2ace299bed0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -13,7 +13,8 @@
#define ENETC_MAX_SKB_FRAGS13
#define ENETC_TXBDS_MAX_NEEDED ENETC_TXBDS_NEEDED(ENETC_MAX_SKB_FRAGS + 1)
-static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb);
+static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb,
+ int active_offloads);
netdev_tx_t enetc_xmit(struct sk_buff *skb, struct net_device *ndev)
{
@@ -33,7 +34,7 @@ netdev_tx_t enetc_xmit(struct sk_buff *skb, struct net_device
*ndev)
return NETDEV_TX_BUSY;
}
- count = enetc_map_tx_buffs(tx_ring, skb);
+ count = enetc_map_tx_buffs(tx_ring, skb, priv->active_offloads);
if (unlikely(!count))
goto drop_packet_err;
@@ -105,7 +106,8 @@ static void enetc_free_tx_skb(struct enetc_bdr *tx_ring,
}
}
-static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb)
+static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb,
+ int active_offloads)
{
struct enetc_tx_swbd *tx_swbd;
struct skb_frag_struct *frag;
@@ -137,7 +139,10 @@ static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring,
struct sk_buff *skb)
count++;
do_vlan = skb_vlan_tag_present(skb);
- do_tstamp = skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP;
+ do_tstamp = (active_offloads & ENETC_F_TX_TSTAMP) &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP);
+ tx_swbd->do_tstamp = do_tstamp;
+ tx_swbd->check_wb = tx_swbd->do_tstamp;
if (do_vlan || do_tstamp)
flags |= ENETC_TXBD_FLAGS_EX;
@@ -299,24 +304,69 @@ static int enetc_bd_ready_count(struct enetc_bdr
*tx_ring, int ci)
return pi >= ci ? pi - ci : tx_ring->bd_count - ci + pi;
}
+static void enetc_get_tx_tstamp(struct enetc_hw *hw, union enetc_tx_bd *txbd,
+ u64 *tstamp)
+{
+ u32 lo, hi;
+
+ lo = enetc_rd(hw, ENETC_SICTR0);
+ hi = enetc_rd(hw, ENETC_SICTR1);
+ if (lo <= txbd->wb.tstamp)
+ hi -= 1;
+ *tstamp = (u64)hi << 32 | txbd->wb.tstamp;
+}
+
+static void enetc_tstamp_tx(struct sk_buff *skb, u64 tstamp)
+{
+ struct skb_shared_hwtstamps shhwtstamps;
+
+ if (skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS) {
+ memset(, 0, sizeof(shhwtstamps));
+ shhwtstamps.hwtstamp = ns_to_ktime(tstamp);
+ skb_tstamp_tx(skb, );
+
[PATCH net-next v2, 4/4] arm64: dts: fsl: ls1028a: add ENETC 1588 timer node
Add ENETC 1588 timer node which is ENETC PF 4 (Physiscal Function 4).
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Added compatible.
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index b04581249f0b..4cdf84c63320 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -431,6 +431,12 @@
compatible = "fsl,enetc";
reg = <0x000100 0 0 0 0>;
};
+ ethernet@0,4 {
+ compatible = "fsl,enetc-ptp";
+ reg = <0x000400 0 0 0 0>;
+ clocks = < 4 0>;
+ little-endian;
+ };
};
};
};
--
2.17.1
[PATCH net-next v2, 0/4] ENETC: support hardware timestamping
This patch-set is to support hardware timestamping for ENETC and also to add ENETC 1588 timer device tree node for ls1028a. Because the ENETC RX BD ring dynamic allocation has not been supported and it is too expensive to use extended RX BDs if timestamping is not used, a Kconfig option is used to enable extended RX BDs in order to support hardware timestamping. This option will be removed once RX BD ring dynamic allocation is implemented. Yangbo Lu (4): enetc: add hardware timestamping support enetc: add get_ts_info interface for ethtool dt-binding: ptp_qoriq: support ENETC PTP compatible arm64: dts: fsl: ls1028a: add ENETC 1588 timer node .../devicetree/bindings/ptp/ptp-qoriq.txt | 1 + .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 + drivers/net/ethernet/freescale/enetc/Kconfig | 10 ++ drivers/net/ethernet/freescale/enetc/enetc.c | 158 +- drivers/net/ethernet/freescale/enetc/enetc.h | 15 +- .../ethernet/freescale/enetc/enetc_ethtool.c | 31 .../net/ethernet/freescale/enetc/enetc_hw.h | 13 ++ .../net/ethernet/freescale/enetc/enetc_pf.c | 1 + .../net/ethernet/freescale/enetc/enetc_ptp.c | 5 + .../net/ethernet/freescale/enetc/enetc_vf.c | 1 + 10 files changed, 235 insertions(+), 6 deletions(-) -- 2.17.1
RE: [PATCH 1/3] enetc: add hardware timestamping support
Hi,
> -Original Message-
> From: Claudiu Manoil
> Sent: Thursday, May 16, 2019 11:31 PM
> To: Richard Cochran ; Y.b. Lu
>
> Cc: net...@vger.kernel.org; David Miller ; Shawn
> Guo ; Rob Herring ;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 1/3] enetc: add hardware timestamping support
>
>
> >-Original Message-
> >From: Richard Cochran
> >Sent: Thursday, May 16, 2019 5:33 PM
> >To: Y.b. Lu
> >Cc: net...@vger.kernel.org; David Miller ; Claudiu
> >Manoil ; Shawn Guo ;
> Rob
> >Herring ; devicet...@vger.kernel.org; linux-arm-
> >ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> >Subject: Re: [PATCH 1/3] enetc: add hardware timestamping support
> >
> >On Thu, May 16, 2019 at 09:59:08AM +, Y.b. Lu wrote:
> >
> [...]
> >
> >> static bool enetc_clean_tx_ring(struct enetc_bdr *tx_ring, int
> >> napi_budget) {
> >>struct net_device *ndev = tx_ring->ndev;
> >> + struct enetc_ndev_priv *priv = netdev_priv(ndev);
> >>int tx_frm_cnt = 0, tx_byte_cnt = 0;
> >>struct enetc_tx_swbd *tx_swbd;
> >> + union enetc_tx_bd *txbd;
> >> + bool do_tstamp;
> >>int i, bds_to_clean;
> >> + u64 tstamp = 0;
> >
> >Please keep in reverse Christmas tree order as much as possible:
>
> For the xmass tree part, Yangbo, better move the priv and txbd declarations
> inside the scope of the if() {} block where they are actually used, i.e.:
>
> if (unlikely(tx_swbd->check_wb)) {
> struct enetc_ndev_priv *priv = netdev_priv(ndev);
> union enetc_tx_bd *txbd;
> [...]
> }
>
[Y.b. Lu] Will do that.
> >
> > union enetc_tx_bd *txbd;
> > int i, bds_to_clean;
> > bool do_tstamp;
> > u64 tstamp = 0;
> >
> >>i = tx_ring->next_to_clean;
> >>tx_swbd = _ring->tx_swbd[i];
> >>bds_to_clean = enetc_bd_ready_count(tx_ring, i);
> >>
> >> + do_tstamp = false;
> >> +
> >>while (bds_to_clean && tx_frm_cnt < ENETC_DEFAULT_TX_WORK) {
> >>bool is_eof = !!tx_swbd->skb;
> >>
> >> + if (unlikely(tx_swbd->check_wb)) {
> >> + txbd = ENETC_TXBD(*tx_ring, i);
> >> +
> >> + if (!(txbd->flags & ENETC_TXBD_FLAGS_W))
> >> + goto no_wb;
> >> +
> >> + if (tx_swbd->do_tstamp) {
> >> + enetc_get_tx_tstamp(>si->hw, txbd,
> >> + );
> >> + do_tstamp = true;
> >> + }
> >> + }
> >> +no_wb:
> >
> >This goto seems strange and unnecessary. How about this instead?
> >
> > if (txbd->flags & ENETC_TXBD_FLAGS_W &&
> > tx_swbd->do_tstamp) {
> > enetc_get_tx_tstamp(>si->hw, txbd,
> > );
> > do_tstamp = true;
> > }
> >
>
> Absolutely, somehow I missed this. I guess the intention was to be able to
> support multiple
> if() blocks for the writeback case (W flag set) but the code is much better
> off
> without the goto.
[Y.b. Lu] Will use this to support current single tstamp writeback case.
>
> >>enetc_unmap_tx_buff(tx_ring, tx_swbd);
> >>if (is_eof) {
> >> + if (unlikely(do_tstamp)) {
> >> + enetc_tstamp_tx(tx_swbd->skb, tstamp);
> >> + do_tstamp = false;
> >> + }
> >>napi_consume_skb(tx_swbd->skb, napi_budget);
> >>tx_swbd->skb = NULL;
> >>}
> >> @@ -167,6 +169,11 @@ struct enetc_cls_rule {
> >>
> >> #define ENETC_MAX_BDR_INT 2 /* fixed to max # of available cpus */
> >>
> >> +enum enetc_hw_features {
> >
> >This is a poor choice of name. It sounds like it describes HW
> >capabilities, but you use it to track whether a feature is requested at
> >run time.
> >
> >> + ENETC_F_RX_TSTAMP = BIT(0),
> >> + ENETC_F_TX_TSTAMP = BIT(1),
> >> +};
> >> +
> >> struct enetc_ndev_priv {
> >>stru
RE: [EXT] Re: [PATCH 1/3] enetc: add hardware timestamping support
Hi,
> -Original Message-
> From: Richard Cochran
> Sent: Thursday, May 16, 2019 10:33 PM
> To: Y.b. Lu
> Cc: net...@vger.kernel.org; David Miller ; Claudiu
> Manoil ; Shawn Guo ; Rob
> Herring ; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: [EXT] Re: [PATCH 1/3] enetc: add hardware timestamping support
>
>
> On Thu, May 16, 2019 at 09:59:08AM +, Y.b. Lu wrote:
>
> > +config FSL_ENETC_HW_TIMESTAMPING
> > + bool "ENETC hardware timestamping support"
> > + depends on FSL_ENETC || FSL_ENETC_VF
> > + help
> > + Enable hardware timestamping support on the Ethernet packets
> > + using the SO_TIMESTAMPING API. Because the RX BD ring dynamic
> > + allocation hasn't been supported and it's too expensive to use
>
> s/it's/it is/
[Y.b. Lu] Will modify it. BTW, may I know what's the purpose of dropping single
quote character? For searching, script checking, or something else?
If require to not use single quote character, I will also modify some other
places in Kconfig messages.
>
> > + extended RX BDs if timestamping isn't used, the option was used
> > + to control hardware timestamping/extended RX BDs to be enabled
> > + or not.
>
> ..., this option enables extended RX BDs in order to support hardware
> timestamping.
[Y.b. Lu] Will rephrase it.
>
> > static bool enetc_clean_tx_ring(struct enetc_bdr *tx_ring, int
> > napi_budget) {
> > struct net_device *ndev = tx_ring->ndev;
> > + struct enetc_ndev_priv *priv = netdev_priv(ndev);
> > int tx_frm_cnt = 0, tx_byte_cnt = 0;
> > struct enetc_tx_swbd *tx_swbd;
> > + union enetc_tx_bd *txbd;
> > + bool do_tstamp;
> > int i, bds_to_clean;
> > + u64 tstamp = 0;
>
> Please keep in reverse Christmas tree order as much as possible:
>
> union enetc_tx_bd *txbd;
> int i, bds_to_clean;
> bool do_tstamp;
> u64 tstamp = 0;
>
> > i = tx_ring->next_to_clean;
> > tx_swbd = _ring->tx_swbd[i];
> > bds_to_clean = enetc_bd_ready_count(tx_ring, i);
> >
> > + do_tstamp = false;
> > +
> > while (bds_to_clean && tx_frm_cnt < ENETC_DEFAULT_TX_WORK) {
> > bool is_eof = !!tx_swbd->skb;
> >
> > + if (unlikely(tx_swbd->check_wb)) {
> > + txbd = ENETC_TXBD(*tx_ring, i);
> > +
> > + if (!(txbd->flags & ENETC_TXBD_FLAGS_W))
> > + goto no_wb;
> > +
> > + if (tx_swbd->do_tstamp) {
> > + enetc_get_tx_tstamp(>si->hw, txbd,
> > + );
> > + do_tstamp = true;
> > + }
> > + }
> > +no_wb:
>
> This goto seems strange and unnecessary. How about this instead?
>
> if (txbd->flags & ENETC_TXBD_FLAGS_W &&
> tx_swbd->do_tstamp) {
> enetc_get_tx_tstamp(>si->hw, txbd,
> );
> do_tstamp = true;
> }
>
> > enetc_unmap_tx_buff(tx_ring, tx_swbd);
> > if (is_eof) {
> > + if (unlikely(do_tstamp)) {
> > + enetc_tstamp_tx(tx_swbd->skb, tstamp);
> > + do_tstamp = false;
> > + }
> > napi_consume_skb(tx_swbd->skb, napi_budget);
> > tx_swbd->skb = NULL;
> > }
> > @@ -167,6 +169,11 @@ struct enetc_cls_rule {
> >
> > #define ENETC_MAX_BDR_INT2 /* fixed to max # of available cpus */
> >
> > +enum enetc_hw_features {
>
> This is a poor choice of name. It sounds like it describes HW capabilities,
> but
> you use it to track whether a feature is requested at run time.
>
> > + ENETC_F_RX_TSTAMP = BIT(0),
> > + ENETC_F_TX_TSTAMP = BIT(1),
> > +};
> > +
> > struct enetc_ndev_priv {
> > struct net_device *ndev;
> > struct device *dev; /* dma-mapping device */ @@ -178,6 +185,7
> @@
> > struct enetc_ndev_priv {
> > u16 rx_bd_count, tx_bd_count;
> >
> > u16 msg_enable;
> > + int hw_features;
>
> This is also poorly named. How about "tstamp_request" instead?
>
> >
> > struct enetc_bdr *tx_ring[16];
> > struct enetc_bdr *rx_ring[16];
>
> Thanks,
> Richard
RE: [PATCH 1/3] enetc: add hardware timestamping support
> -Original Message- > From: Claudiu Manoil > Sent: Thursday, May 16, 2019 9:31 PM > To: Y.b. Lu ; net...@vger.kernel.org; Richard Cochran > ; David Miller ; Shawn > Guo ; Rob Herring > Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org > Subject: RE: [PATCH 1/3] enetc: add hardware timestamping support > > >-----Original Message- > >From: Y.b. Lu > [...] > >Subject: [PATCH 1/3] enetc: add hardware timestamping support > > > [...] > > Hi Yangbo, > > These enetc patches targeting net-next will have to be rebased on the latest > enetc net.git commits, otherwise there will be some merge conflicts for > enetc.c > and enetc_ethtool.c. > Thanks, > Claudiu > > see > 22fb43f36006 "enetc: Add missing link state info for ethtool" > f4a0be84d73e "enetc: Fix NULL dma address unmap for Tx BD extensions" [Y.b. Lu] Thanks Claudiu. I should have noticed that. Let me send v2 after net-next is open.
RE: [PATCH] soc: fsl: guts: make fsl_guts_get_svr() static
> -Original Message-
> From: Horia Geantă
> Sent: Thursday, February 21, 2019 6:38 PM
> To: Leo Li
> Cc: Y.b. Lu ; linuxppc-...@lists.ozlabs.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] soc: fsl: guts: make fsl_guts_get_svr() static
>
> The export of fsl_guts_get_svr() is a left-over, it's currently used only
> internally
> and users needing SoC information should use the generic soc_device
> infrastructure.
>
[Y.b. Lu] Acked-by: Yangbo Lu
> Signed-off-by: Horia Geantă
> ---
> drivers/soc/fsl/guts.c | 3 +--
> include/linux/fsl/guts.h | 2 --
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c index
> 4f9655087bd7..63f6df86f9e5 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -115,7 +115,7 @@ static const struct fsl_soc_die_attr
> *fsl_soc_die_match(
> return NULL;
> }
>
> -u32 fsl_guts_get_svr(void)
> +static u32 fsl_guts_get_svr(void)
> {
> u32 svr = 0;
>
> @@ -129,7 +129,6 @@ u32 fsl_guts_get_svr(void)
>
> return svr;
> }
> -EXPORT_SYMBOL(fsl_guts_get_svr);
>
> static int fsl_guts_probe(struct platform_device *pdev) { diff --git
> a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h index
> 941b11811f85..1fc0edd71c52 100644
> --- a/include/linux/fsl/guts.h
> +++ b/include/linux/fsl/guts.h
> @@ -135,8 +135,6 @@ struct ccsr_guts {
> u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
> } __attribute__ ((packed));
>
> -u32 fsl_guts_get_svr(void);
> -
> /* Alternate function signal multiplex control */ #define
> MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
>
> --
> 2.16.2
RE: [PATCH 3/3] ptp_qoriq: convert to use module parameters for initialization
Hi Richard, > -Original Message- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Wednesday, August 1, 2018 2:15 PM > To: Y.b. Lu > Cc: net...@vger.kernel.org; Madalin-cristian Bucur > ; Rob Herring ; Shawn Guo > ; David S . Miller ; > devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/3] ptp_qoriq: convert to use module parameters for > initialization > > On Wed, Aug 01, 2018 at 04:36:40AM +, Y.b. Lu wrote: > > > Could I add a function to calculate a set of default register values > > to initialize ptp timer when dts method failed to get required > > properties in driver? > > Yes, it would be ideal if the driver can pick correct values automatically. > > However, the frequency on the FIPER outputs can't be configured > automatically, and we don't have an API for the user to choose this. [Y.b. Lu] Thanks a lot. Just let me send out the v2 patch for your reviewing. > > > I think this will be useful. The ptp timer on new platforms (you may > > see two dts patches in this patchset. Many platforms will be > > affected.) will work without these dts properties. If user want > > specific setting, they can set dts properties. > > Sure. > > Thanks, > Richard
RE: [PATCH 3/3] ptp_qoriq: convert to use module parameters for initialization
Hi Richard, > -Original Message- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Wednesday, August 1, 2018 2:15 PM > To: Y.b. Lu > Cc: net...@vger.kernel.org; Madalin-cristian Bucur > ; Rob Herring ; Shawn Guo > ; David S . Miller ; > devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/3] ptp_qoriq: convert to use module parameters for > initialization > > On Wed, Aug 01, 2018 at 04:36:40AM +, Y.b. Lu wrote: > > > Could I add a function to calculate a set of default register values > > to initialize ptp timer when dts method failed to get required > > properties in driver? > > Yes, it would be ideal if the driver can pick correct values automatically. > > However, the frequency on the FIPER outputs can't be configured > automatically, and we don't have an API for the user to choose this. [Y.b. Lu] Thanks a lot. Just let me send out the v2 patch for your reviewing. > > > I think this will be useful. The ptp timer on new platforms (you may > > see two dts patches in this patchset. Many platforms will be > > affected.) will work without these dts properties. If user want > > specific setting, they can set dts properties. > > Sure. > > Thanks, > Richard
RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
Hi David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, May 29, 2018 11:07 AM > To: Y.b. Lu > Cc: net...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; richardcoch...@gmail.com; Claudiu Manoil > ; robh...@kernel.org > Subject: Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ > PTP clock driver > > From: Yangbo Lu > Date: Fri, 25 May 2018 12:40:38 +0800 > > > Added myself as maintainer for QorIQ PTP clock driver. > > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it > > under QorIQ PTP clock driver. > > > > Signed-off-by: Yangbo Lu > > Because of the dependency on the staging tree changes, this doesn't apply > cleanly to net-next. > > You'll have to figure out how you want to sort this out. [Y.b. Lu] I sent out a v2 MAINTAINERS patch. I think it also makes sense to drop dpaa2 rtc drivers in the entry. Thanks a lot.
RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
Hi David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, May 29, 2018 11:07 AM > To: Y.b. Lu > Cc: net...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; richardcoch...@gmail.com; Claudiu Manoil > ; robh...@kernel.org > Subject: Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ > PTP clock driver > > From: Yangbo Lu > Date: Fri, 25 May 2018 12:40:38 +0800 > > > Added myself as maintainer for QorIQ PTP clock driver. > > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it > > under QorIQ PTP clock driver. > > > > Signed-off-by: Yangbo Lu > > Because of the dependency on the staging tree changes, this doesn't apply > cleanly to net-next. > > You'll have to figure out how you want to sort this out. [Y.b. Lu] I sent out a v2 MAINTAINERS patch. I think it also makes sense to drop dpaa2 rtc drivers in the entry. Thanks a lot.
RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
This patch has a dependency which is now on staging git tree. https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next=7fd899fff5907dbb02089494102ef628988f2330 > -Original Message- > From: Yangbo Lu [mailto:yangbo...@nxp.com] > Sent: Friday, May 25, 2018 12:41 PM > To: net...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Richard Cochran <richardcoch...@gmail.com>; > Claudiu Manoil <claudiu.man...@nxp.com>; Rob Herring <robh...@kernel.org> > Cc: Y.b. Lu <yangbo...@nxp.com> > Subject: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP > clock driver > > Added myself as maintainer for QorIQ PTP clock driver. > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it under > QorIQ PTP clock driver. > > Signed-off-by: Yangbo Lu <yangbo...@nxp.com> > --- > MAINTAINERS | 17 + > 1 files changed, 9 insertions(+), 8 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4b65225..a71d4fa 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4411,12 +4411,6 @@ L: linux-kernel@vger.kernel.org > S: Maintained > F: drivers/staging/fsl-dpaa2/ethsw > > -DPAA2 PTP CLOCK DRIVER > -M: Yangbo Lu <yangbo...@nxp.com> > -L: linux-kernel@vger.kernel.org > -S: Maintained > -F: drivers/staging/fsl-dpaa2/rtc > - > DPT_I2O SCSI RAID DRIVER > M: Adaptec OEM Raid Solutions <aacr...@microsemi.com> > L: linux-s...@vger.kernel.org > @@ -5648,7 +5642,6 @@ M: Claudiu Manoil <claudiu.man...@nxp.com> > L: net...@vger.kernel.org > S: Maintained > F: drivers/net/ethernet/freescale/gianfar* > -X: drivers/net/ethernet/freescale/gianfar_ptp.c > F: Documentation/devicetree/bindings/net/fsl-tsec-phy.txt > > FREESCALE GPMI NAND DRIVER > @@ -5695,6 +5688,15 @@ S: Maintained > F: drivers/net/ethernet/freescale/fman > F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt > > +FREESCALE QORIQ PTP CLOCK DRIVER > +M: Yangbo Lu <yangbo...@nxp.com> > +L: linux-kernel@vger.kernel.org > +S: Maintained > +F: drivers/staging/fsl-dpaa2/rtc > +F: drivers/ptp/ptp_qoriq.c > +F: include/linux/fsl/ptp_qoriq.h > +F: Documentation/devicetree/bindings/ptp/ptp-qoriq.txt > + > FREESCALE QUAD SPI DRIVER > M: Han Xu <han...@nxp.com> > L: linux-...@lists.infradead.org > @@ -11429,7 +11431,6 @@ S:Maintained > W: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fli > nuxptp.sourceforge.net%2F=02%7C01%7Cyangbo.lu%40nxp.com%7Cd7 > 840089f091467d11de08d5c1f9e801%7C686ea1d3bc2b4c6fa92cd99c5c3016 > 35%7C0%7C0%7C636628201433493648=XhJjFQyrROZzMU7zUGsUkA > BjJD%2BJ25q2Jq77vdHoco0%3D=0 > F: Documentation/ABI/testing/sysfs-ptp > F: Documentation/ptp/* > -F: drivers/net/ethernet/freescale/gianfar_ptp.c > F: drivers/net/phy/dp83640* > F: drivers/ptp/* > F: include/linux/ptp_cl* > -- > 1.7.1
RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
This patch has a dependency which is now on staging git tree. https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next=7fd899fff5907dbb02089494102ef628988f2330 > -Original Message- > From: Yangbo Lu [mailto:yangbo...@nxp.com] > Sent: Friday, May 25, 2018 12:41 PM > To: net...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Richard Cochran ; > Claudiu Manoil ; Rob Herring > Cc: Y.b. Lu > Subject: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP > clock driver > > Added myself as maintainer for QorIQ PTP clock driver. > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it under > QorIQ PTP clock driver. > > Signed-off-by: Yangbo Lu > --- > MAINTAINERS | 17 + > 1 files changed, 9 insertions(+), 8 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4b65225..a71d4fa 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4411,12 +4411,6 @@ L: linux-kernel@vger.kernel.org > S: Maintained > F: drivers/staging/fsl-dpaa2/ethsw > > -DPAA2 PTP CLOCK DRIVER > -M: Yangbo Lu > -L: linux-kernel@vger.kernel.org > -S: Maintained > -F: drivers/staging/fsl-dpaa2/rtc > - > DPT_I2O SCSI RAID DRIVER > M: Adaptec OEM Raid Solutions > L: linux-s...@vger.kernel.org > @@ -5648,7 +5642,6 @@ M: Claudiu Manoil > L: net...@vger.kernel.org > S: Maintained > F: drivers/net/ethernet/freescale/gianfar* > -X: drivers/net/ethernet/freescale/gianfar_ptp.c > F: Documentation/devicetree/bindings/net/fsl-tsec-phy.txt > > FREESCALE GPMI NAND DRIVER > @@ -5695,6 +5688,15 @@ S: Maintained > F: drivers/net/ethernet/freescale/fman > F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt > > +FREESCALE QORIQ PTP CLOCK DRIVER > +M: Yangbo Lu > +L: linux-kernel@vger.kernel.org > +S: Maintained > +F: drivers/staging/fsl-dpaa2/rtc > +F: drivers/ptp/ptp_qoriq.c > +F: include/linux/fsl/ptp_qoriq.h > +F: Documentation/devicetree/bindings/ptp/ptp-qoriq.txt > + > FREESCALE QUAD SPI DRIVER > M: Han Xu > L: linux-...@lists.infradead.org > @@ -11429,7 +11431,6 @@ S:Maintained > W: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fli > nuxptp.sourceforge.net%2F=02%7C01%7Cyangbo.lu%40nxp.com%7Cd7 > 840089f091467d11de08d5c1f9e801%7C686ea1d3bc2b4c6fa92cd99c5c3016 > 35%7C0%7C0%7C636628201433493648=XhJjFQyrROZzMU7zUGsUkA > BjJD%2BJ25q2Jq77vdHoco0%3D=0 > F: Documentation/ABI/testing/sysfs-ptp > F: Documentation/ptp/* > -F: drivers/net/ethernet/freescale/gianfar_ptp.c > F: drivers/net/phy/dp83640* > F: drivers/ptp/* > F: include/linux/ptp_cl* > -- > 1.7.1
PTP clock driver for FSL DPAA
Hi Richard, I'm going to make a PTP clock driver patch for FSL DPAA ethernet controller. (drivers/net/ethernet/freescale/dpaa/) Actually the 1588 timer module on FSL DPAA is same with the one on FSL eTSEC in hardware.(whose PTP clock driver is drivers/net/ethernet/freescale/gianfar_ptp.c) So there are two options for me I think. Option #1, just make a dpaa_ptp.c driver which will be almost same with gianfar_ptp.c. Option #2, try to reuse gianfar_ptp.c driver by reworking it as a common driver, renaming it, and putting it to a common place (drivers/ptp/ or still drivers/net/ethernet/freescale/). I'd like to ask your suggestion. Thanks a lot. Best regards, Yangbo Lu
PTP clock driver for FSL DPAA
Hi Richard, I'm going to make a PTP clock driver patch for FSL DPAA ethernet controller. (drivers/net/ethernet/freescale/dpaa/) Actually the 1588 timer module on FSL DPAA is same with the one on FSL eTSEC in hardware.(whose PTP clock driver is drivers/net/ethernet/freescale/gianfar_ptp.c) So there are two options for me I think. Option #1, just make a dpaa_ptp.c driver which will be almost same with gianfar_ptp.c. Option #2, try to reuse gianfar_ptp.c driver by reworking it as a common driver, renaming it, and putting it to a common place (drivers/ptp/ or still drivers/net/ethernet/freescale/). I'd like to ask your suggestion. Thanks a lot. Best regards, Yangbo Lu
RE: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping
Hi Richard, > -Original Message- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Thursday, April 26, 2018 10:33 AM > To: Y.b. Lu <yangbo...@nxp.com> > Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Greg > Kroah-Hartman <gre...@linuxfoundation.org>; dan.carpen...@oracle.com; > Ruxandra Ioana Ciocoi Radulescu <ruxandra.radule...@nxp.com> > Subject: Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware > timestamping > > On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote: > > > +/* PTP nominal frequency 1GHz */ > > +#define DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS 1 > > Nit: Frequency is the inverse of the period. It can be one or the other, not > both. > > Why not call it simply DPAA2_PTP_CLK_PERIOD_NS? [Y.b. Lu] Thanks. Let me use DPAA2_PTP_CLK_PERIOD_NS in next version. > > You haven't implemented the ethtool_get_ts_info() method, but you need to > do so. Show us how the user can related these MAC time stamps to the PHC > device in your other patch series. [Y.b. Lu] I will add patch for ethtool_get_ts_info in next version. Thanks! But I'm not sure whether ethtool should show hw timestamping always ignoring phc enabled or not. Actually the hw timestamping is supported always since ptp clock had been initialized in MC firmware. Let me just send out the patch for reviewing. > > Thanks, > Richard
RE: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping
Hi Richard, > -Original Message- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Thursday, April 26, 2018 10:33 AM > To: Y.b. Lu > Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Greg > Kroah-Hartman ; dan.carpen...@oracle.com; > Ruxandra Ioana Ciocoi Radulescu > Subject: Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware > timestamping > > On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote: > > > +/* PTP nominal frequency 1GHz */ > > +#define DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS 1 > > Nit: Frequency is the inverse of the period. It can be one or the other, not > both. > > Why not call it simply DPAA2_PTP_CLK_PERIOD_NS? [Y.b. Lu] Thanks. Let me use DPAA2_PTP_CLK_PERIOD_NS in next version. > > You haven't implemented the ethtool_get_ts_info() method, but you need to > do so. Show us how the user can related these MAC time stamps to the PHC > device in your other patch series. [Y.b. Lu] I will add patch for ethtool_get_ts_info in next version. Thanks! But I'm not sure whether ethtool should show hw timestamping always ignoring phc enabled or not. Actually the hw timestamping is supported always since ptp clock had been initialized in MC firmware. Let me just send out the patch for reviewing. > > Thanks, > Richard
RE: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping
Hi Dan,
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Wednesday, April 25, 2018 6:04 PM
> To: Y.b. Lu <yangbo...@nxp.com>
> Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Greg
> Kroah-Hartman <gre...@linuxfoundation.org>; Richard Cochran
> <richardcoch...@gmail.com>; Ruxandra Ioana Ciocoi Radulescu
> <ruxandra.radule...@nxp.com>
> Subject: Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware
> timestamping
>
> On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote:
> > @@ -275,6 +278,16 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv
> > *priv,
> >
> > prefetch(skb->data);
> >
> > + /* Get the timestamp value */
> > + if (priv->ts_rx_en) {
> > + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> > + u64 *ns = dpaa2_get_ts(vaddr, false);
> > +
> > + *ns = DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS * le64_to_cpup(ns);
>
> This will cause Sparse endianess warnings.
>
> I don't totally understand why we're writing to *ns. Do we access *ns again
> or not? Either way, this doesn't seem right. In other words, why don't we
> do this:
>
> __le64 *period = dpaa2_get_ts(vaddr, false);
> u64 ns;
>
> ns = DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS *
> le64_to_cpup(period);
> memset(shhwtstamps, 0, sizeof(*shhwtstamps));
> shhwtstamps->hwtstamp = ns_to_ktime(ns);
>
> Then if we need to save a munged *ns then we can do this at the end:
>
> /* we need this because blah blah blah */
> *period = (__le64)ns;
>
[Y.b. Lu] You're right. I will modify the code according to your suggestion.
>
> > + memset(shhwtstamps, 0, sizeof(*shhwtstamps));
> > + shhwtstamps->hwtstamp = ns_to_ktime(*ns);
> > + }
> > +
> > /* Check if we need to validate the L4 csum */
> > if (likely(dpaa2_fd_get_frc(fd) & DPAA2_FD_FRC_FASV)) {
> > status = le32_to_cpu(fas->status);
>
> [ snip ]
>
> > @@ -520,6 +561,19 @@ static void free_tx_fd(const struct dpaa2_eth_priv
> *priv,
> > return;
> > }
> >
> > + /* Get the timestamp value */
> > + if (priv->ts_tx_en && skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
> > + struct skb_shared_hwtstamps shhwtstamps;
> > + u64 *ns;
> > +
> > + memset(, 0, sizeof(shhwtstamps));
> > +
> > + ns = dpaa2_get_ts(skbh, true);
> > + *ns = DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS * le64_to_cpup(ns);
> > + shhwtstamps.hwtstamp = ns_to_ktime(*ns);
> > + skb_tstamp_tx(skb, );
>
> Sparse issues here also.
[Y.b. Lu] Will modify the code according to your suggestion.
>
> > + }
> > +
> > /* Free SGT buffer allocated on tx */
> > if (fd_format != dpaa2_fd_single)
> > skb_free_frag(skbh);
> > @@ -552,6 +606,10 @@ static netdev_tx_t dpaa2_eth_tx(struct sk_buff
> *skb, struct net_device *net_dev)
> > goto err_alloc_headroom;
> > }
> > percpu_extras->tx_reallocs++;
> > +
> > + if (skb->sk)
> > + skb_set_owner_w(ns, skb->sk);
>
> Is this really related? (I have not looked at this code).
[Y.b. Lu] Yes. The skb_tstamp_tx() function will check that.
>
> > +
> > dev_kfree_skb(skb);
> > skb = ns;
> > }
>
> [ snip ]
>
> > @@ -319,6 +351,9 @@ struct dpaa2_eth_priv {
> > u16 bpid;
> > struct iommu_domain *iommu_domain;
> >
> > + bool ts_tx_en; /* Tx timestamping enabled */
> > + bool ts_rx_en; /* Rx timestamping enabled */
>
> These variable names are not great. I wouldn't have understood "ts_"
> without the comment. "tx_" is good. "en" is confusing until you read the
> comment. But really it should just be left out because "enable" is assumed,
> generally. Last week I asked someone to rewrite a patch that had a _disable
> variable because negative variables lead to double negatives which screw with
> my tiny head.
>
> if (blah_disable != 0) {
>
> OH MY BLASTED WORD MY BRIAN ESPLODED!!!1!
>
> So let's just name these "tx_timestamps" or something.
[Y.b. Lu] Ok. Let me use tx_tstamp/rx_tstamp instead. The tstamp is common used
in driver.
>
>
> > +
> > u16 tx_qdid;
> > u16 rx_buf_align;
> > struct fsl_mc_io *mc_io;
>
> regards,
> dan carpenter
RE: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping
Hi Dan,
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Wednesday, April 25, 2018 6:04 PM
> To: Y.b. Lu
> Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Greg
> Kroah-Hartman ; Richard Cochran
> ; Ruxandra Ioana Ciocoi Radulescu
>
> Subject: Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware
> timestamping
>
> On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote:
> > @@ -275,6 +278,16 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv
> > *priv,
> >
> > prefetch(skb->data);
> >
> > + /* Get the timestamp value */
> > + if (priv->ts_rx_en) {
> > + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> > + u64 *ns = dpaa2_get_ts(vaddr, false);
> > +
> > + *ns = DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS * le64_to_cpup(ns);
>
> This will cause Sparse endianess warnings.
>
> I don't totally understand why we're writing to *ns. Do we access *ns again
> or not? Either way, this doesn't seem right. In other words, why don't we
> do this:
>
> __le64 *period = dpaa2_get_ts(vaddr, false);
> u64 ns;
>
> ns = DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS *
> le64_to_cpup(period);
> memset(shhwtstamps, 0, sizeof(*shhwtstamps));
> shhwtstamps->hwtstamp = ns_to_ktime(ns);
>
> Then if we need to save a munged *ns then we can do this at the end:
>
> /* we need this because blah blah blah */
> *period = (__le64)ns;
>
[Y.b. Lu] You're right. I will modify the code according to your suggestion.
>
> > + memset(shhwtstamps, 0, sizeof(*shhwtstamps));
> > + shhwtstamps->hwtstamp = ns_to_ktime(*ns);
> > + }
> > +
> > /* Check if we need to validate the L4 csum */
> > if (likely(dpaa2_fd_get_frc(fd) & DPAA2_FD_FRC_FASV)) {
> > status = le32_to_cpu(fas->status);
>
> [ snip ]
>
> > @@ -520,6 +561,19 @@ static void free_tx_fd(const struct dpaa2_eth_priv
> *priv,
> > return;
> > }
> >
> > + /* Get the timestamp value */
> > + if (priv->ts_tx_en && skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
> > + struct skb_shared_hwtstamps shhwtstamps;
> > + u64 *ns;
> > +
> > + memset(, 0, sizeof(shhwtstamps));
> > +
> > + ns = dpaa2_get_ts(skbh, true);
> > + *ns = DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS * le64_to_cpup(ns);
> > + shhwtstamps.hwtstamp = ns_to_ktime(*ns);
> > + skb_tstamp_tx(skb, );
>
> Sparse issues here also.
[Y.b. Lu] Will modify the code according to your suggestion.
>
> > + }
> > +
> > /* Free SGT buffer allocated on tx */
> > if (fd_format != dpaa2_fd_single)
> > skb_free_frag(skbh);
> > @@ -552,6 +606,10 @@ static netdev_tx_t dpaa2_eth_tx(struct sk_buff
> *skb, struct net_device *net_dev)
> > goto err_alloc_headroom;
> > }
> > percpu_extras->tx_reallocs++;
> > +
> > + if (skb->sk)
> > + skb_set_owner_w(ns, skb->sk);
>
> Is this really related? (I have not looked at this code).
[Y.b. Lu] Yes. The skb_tstamp_tx() function will check that.
>
> > +
> > dev_kfree_skb(skb);
> > skb = ns;
> > }
>
> [ snip ]
>
> > @@ -319,6 +351,9 @@ struct dpaa2_eth_priv {
> > u16 bpid;
> > struct iommu_domain *iommu_domain;
> >
> > + bool ts_tx_en; /* Tx timestamping enabled */
> > + bool ts_rx_en; /* Rx timestamping enabled */
>
> These variable names are not great. I wouldn't have understood "ts_"
> without the comment. "tx_" is good. "en" is confusing until you read the
> comment. But really it should just be left out because "enable" is assumed,
> generally. Last week I asked someone to rewrite a patch that had a _disable
> variable because negative variables lead to double negatives which screw with
> my tiny head.
>
> if (blah_disable != 0) {
>
> OH MY BLASTED WORD MY BRIAN ESPLODED!!!1!
>
> So let's just name these "tx_timestamps" or something.
[Y.b. Lu] Ok. Let me use tx_tstamp/rx_tstamp instead. The tstamp is common used
in driver.
>
>
> > +
> > u16 tx_qdid;
> > u16 rx_buf_align;
> > struct fsl_mc_io *mc_io;
>
> regards,
> dan carpenter
RE: [PATCH] net: gianfar_ptp: move set_fipers() to spinlock protecting area
> -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2018年1月8日 20:54 > To: Y.b. Lu <yangbo...@nxp.com> > Cc: Claudiu Manoil <claudiu.man...@nxp.com>; Richard Cochran > <richardcoch...@gmail.com>; net...@vger.kernel.org; linux-kernel > <linux-kernel@vger.kernel.org> > Subject: Re: [PATCH] net: gianfar_ptp: move set_fipers() to spinlock > protecting > area > > On Mon, Jan 8, 2018 at 8:13 AM, Yangbo Lu <yangbo...@nxp.com> wrote: > > set_fipers() calling should be protected by spinlock. > > This patch is to move set_fipers() to spinlock protecting area in > > ptp_gianfar_adjtime() function. > > It would be nice to explay why. [Y.b. Lu] Sent out v2 patch and explained in commit message :) Thanks. > > Thanks
RE: [PATCH] net: gianfar_ptp: move set_fipers() to spinlock protecting area
> -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2018年1月8日 20:54 > To: Y.b. Lu > Cc: Claudiu Manoil ; Richard Cochran > ; net...@vger.kernel.org; linux-kernel > > Subject: Re: [PATCH] net: gianfar_ptp: move set_fipers() to spinlock > protecting > area > > On Mon, Jan 8, 2018 at 8:13 AM, Yangbo Lu wrote: > > set_fipers() calling should be protected by spinlock. > > This patch is to move set_fipers() to spinlock protecting area in > > ptp_gianfar_adjtime() function. > > It would be nice to explay why. [Y.b. Lu] Sent out v2 patch and explained in commit message :) Thanks. > > Thanks
RE: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1
Hi Shawn, Sorry for bother. I just couldn’t find this patch on your git tree. Could you help to check? Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: 2017年11月30日 8:29 > To: Y.b. Lu <yangbo...@nxp.com> > Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Mark Rutland <mark.rutl...@arm.com>; > Rob Herring <robh...@kernel.org>; Russell King <li...@armlinux.org.uk> > Subject: Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1 > > On Wed, Nov 29, 2017 at 02:54:58PM +0800, Yangbo Lu wrote: > > The timer fixed interval period pulse generator register is used to > > generate periodic pulses. The down count register loads the value > > programmed in the fixed period interval (FIPER). At every tick of the > > timer accumulator overflow, the counter decrements by the value of > > TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down counter > > value reaches zero. It reloads the down counter in the cycle following > > a pulse. To use the TMR_FIPER1 register to generate a 1 PPS event, the > > value > > (10^9 nanoseconds) - TCLK_PERIOD should be programmed. > > It should be 5 not 0 since TCLK_PERIOD is 5. > > > > Signed-off-by: Yangbo Lu <yangbo...@nxp.com> > > > Again, for arm dts, we usually use prefix like 'ARM: dts: ...' > > I fixed it up and applied the patch. > > Shawn > > > --- > > Changes for v2: > > - Added Shawn into cc list. > > --- > > arch/arm/boot/dts/ls1021a.dtsi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/boot/dts/ls1021a.dtsi > > b/arch/arm/boot/dts/ls1021a.dtsi index 64249726b3cb..a861a4b9e319 > > 100644 > > --- a/arch/arm/boot/dts/ls1021a.dtsi > > +++ b/arch/arm/boot/dts/ls1021a.dtsi > > @@ -589,7 +589,7 @@ > > fsl,tclk-period = <5>; > > fsl,tmr-prsc= <2>; > > fsl,tmr-add = <0xaaab>; > > - fsl,tmr-fiper1 = <0>; > > + fsl,tmr-fiper1 = <5>; > > fsl,tmr-fiper2 = <0>; > > fsl,max-adj = <4>; > > }; > > -- > > 2.14.1 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > > > s.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel=02%7C01% > 7 > > > Cyangbo.lu%40nxp.com%7C703a7f8c490745cac3d708d537896a63%7C686ea > 1d3bc2b > > > 4c6fa92cd99c5c301635%7C0%7C0%7C636475985694945094=XLw6lJ > ONCoo2jq > > Hoixb%2BtlYTDcLC4tPbKWT3eQ7RI7c%3D=0
RE: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1
Hi Shawn, Sorry for bother. I just couldn’t find this patch on your git tree. Could you help to check? Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: 2017年11月30日 8:29 > To: Y.b. Lu > Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Mark Rutland ; > Rob Herring ; Russell King > Subject: Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1 > > On Wed, Nov 29, 2017 at 02:54:58PM +0800, Yangbo Lu wrote: > > The timer fixed interval period pulse generator register is used to > > generate periodic pulses. The down count register loads the value > > programmed in the fixed period interval (FIPER). At every tick of the > > timer accumulator overflow, the counter decrements by the value of > > TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down counter > > value reaches zero. It reloads the down counter in the cycle following > > a pulse. To use the TMR_FIPER1 register to generate a 1 PPS event, the > > value > > (10^9 nanoseconds) - TCLK_PERIOD should be programmed. > > It should be 5 not 0 since TCLK_PERIOD is 5. > > > > Signed-off-by: Yangbo Lu > > > Again, for arm dts, we usually use prefix like 'ARM: dts: ...' > > I fixed it up and applied the patch. > > Shawn > > > --- > > Changes for v2: > > - Added Shawn into cc list. > > --- > > arch/arm/boot/dts/ls1021a.dtsi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/boot/dts/ls1021a.dtsi > > b/arch/arm/boot/dts/ls1021a.dtsi index 64249726b3cb..a861a4b9e319 > > 100644 > > --- a/arch/arm/boot/dts/ls1021a.dtsi > > +++ b/arch/arm/boot/dts/ls1021a.dtsi > > @@ -589,7 +589,7 @@ > > fsl,tclk-period = <5>; > > fsl,tmr-prsc= <2>; > > fsl,tmr-add = <0xaaab>; > > - fsl,tmr-fiper1 = <0>; > > + fsl,tmr-fiper1 = <5>; > > fsl,tmr-fiper2 = <0>; > > fsl,max-adj = <4>; > > }; > > -- > > 2.14.1 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > > > s.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel=02%7C01% > 7 > > > Cyangbo.lu%40nxp.com%7C703a7f8c490745cac3d708d537896a63%7C686ea > 1d3bc2b > > > 4c6fa92cd99c5c301635%7C0%7C0%7C636475985694945094=XLw6lJ > ONCoo2jq > > Hoixb%2BtlYTDcLC4tPbKWT3eQ7RI7c%3D=0
RE: [PATCH] arm: dts: ls1021a: fix the value of TMR_FIPER1
Any comments? +Shawn Thanks. -Original Message- From: Yangbo Lu [mailto:yangbo...@nxp.com] Sent: 2017年11月10日 9:59 To: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Rob Herring <robh...@kernel.org>; Mark Rutland <mark.rutl...@arm.com>; Russell King <li...@armlinux.org.uk> Cc: Y.b. Lu <yangbo...@nxp.com> Subject: [PATCH] arm: dts: ls1021a: fix the value of TMR_FIPER1 The timer fixed interval period pulse generator register is used to generate periodic pulses. The down count register loads the value programmed in the fixed period interval (FIPER). At every tick of the timer accumulator overflow, the counter decrements by the value of TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down counter value reaches zero. It reloads the down counter in the cycle following a pulse. To use the TMR_FIPER1 register to generate a 1 PPS event, the value (10^9 nanoseconds) - TCLK_PERIOD should be programmed. It should be 5 not 0 since TCLK_PERIOD is 5. Signed-off-by: Yangbo Lu <yangbo...@nxp.com> --- arch/arm/boot/dts/ls1021a.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index 9319e1f0f1d8..10e536f338f7 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -575,7 +575,7 @@ fsl,tclk-period = <5>; fsl,tmr-prsc= <2>; fsl,tmr-add = <0xaaab>; - fsl,tmr-fiper1 = <0>; + fsl,tmr-fiper1 = <5>; fsl,tmr-fiper2 = <0>; fsl,max-adj = <4>; }; -- 2.14.1
RE: [PATCH] arm: dts: ls1021a: fix the value of TMR_FIPER1
Any comments? +Shawn Thanks. -Original Message- From: Yangbo Lu [mailto:yangbo...@nxp.com] Sent: 2017年11月10日 9:59 To: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Rob Herring ; Mark Rutland ; Russell King Cc: Y.b. Lu Subject: [PATCH] arm: dts: ls1021a: fix the value of TMR_FIPER1 The timer fixed interval period pulse generator register is used to generate periodic pulses. The down count register loads the value programmed in the fixed period interval (FIPER). At every tick of the timer accumulator overflow, the counter decrements by the value of TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down counter value reaches zero. It reloads the down counter in the cycle following a pulse. To use the TMR_FIPER1 register to generate a 1 PPS event, the value (10^9 nanoseconds) - TCLK_PERIOD should be programmed. It should be 5 not 0 since TCLK_PERIOD is 5. Signed-off-by: Yangbo Lu --- arch/arm/boot/dts/ls1021a.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index 9319e1f0f1d8..10e536f338f7 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -575,7 +575,7 @@ fsl,tclk-period = <5>; fsl,tmr-prsc= <2>; fsl,tmr-add = <0xaaab>; - fsl,tmr-fiper1 = <0>; + fsl,tmr-fiper1 = <5>; fsl,tmr-fiper2 = <0>; fsl,max-adj = <4>; }; -- 2.14.1
RE: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Monday, November 14, 2016 11:12 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org; Ulf Hansson; Adrian Hunter; yangbo lu;
> Michael Walle
> Subject: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
>
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()")
> ---
> v3:
> - explain the bits in the comments
> - use bits[19:0] from the original value, all other will be taken from
> the
>fixup value.
>
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index fb71c86..74cf3b1 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,19 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level
> are
> + * not compatible with standard SDHC register. The line signal
> levels
> + * DAT[7:0] are at bits 31:24 and the line signal level is at bit
> 23.
> + * All other bits are the same as in the standard SDHC register.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & 0x000f;
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x0100;
> + return ret;
> + }
> +
[Lu Yangbo-B47093] This is the proper fix.
Acked-by: Yangbo Lu
> ret = value;
> return ret;
> }
> --
> 2.1.4
RE: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Monday, November 14, 2016 11:12 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org; Ulf Hansson; Adrian Hunter; yangbo lu;
> Michael Walle
> Subject: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
>
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()")
> ---
> v3:
> - explain the bits in the comments
> - use bits[19:0] from the original value, all other will be taken from
> the
>fixup value.
>
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index fb71c86..74cf3b1 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,19 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level
> are
> + * not compatible with standard SDHC register. The line signal
> levels
> + * DAT[7:0] are at bits 31:24 and the line signal level is at bit
> 23.
> + * All other bits are the same as in the standard SDHC register.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & 0x000f;
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x0100;
> + return ret;
> + }
> +
[Lu Yangbo-B47093] This is the proper fix.
Acked-by: Yangbo Lu
> ret = value;
> return ret;
> }
> --
> 2.1.4
RE: [PATCH v2] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Saturday, November 12, 2016 12:04 AM
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org; Ulf Hansson; Adrian Hunter; yangbo lu;
> Michael Walle
> Subject: [PATCH v2] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
>
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()")
> ---
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index fb71c86..f9c84bb 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,18 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level is
> + * not compatible with standard SDHC register. Move the
> corresponding
> + * bits around.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & ~0xf800;
[Lu Yangbo-B47093] I think the bits which should be cleaned before following
'|=' are 0x01f0 not 0xf800, right?
:)
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x0100;
> + return ret;
> + }
> +
> ret = value;
> return ret;
> }
> --
> 2.1.4
RE: [PATCH v2] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Saturday, November 12, 2016 12:04 AM
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org; Ulf Hansson; Adrian Hunter; yangbo lu;
> Michael Walle
> Subject: [PATCH v2] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
>
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()")
> ---
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index fb71c86..f9c84bb 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,18 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level is
> + * not compatible with standard SDHC register. Move the
> corresponding
> + * bits around.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & ~0xf800;
[Lu Yangbo-B47093] I think the bits which should be cleaned before following
'|=' are 0x01f0 not 0xf800, right?
:)
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x0100;
> + return ret;
> + }
> +
> ret = value;
> return ret;
> }
> --
> 2.1.4
RE: [v16, 0/7] Fix eSDHC host version register bug
> -Original Message-
> From: Y.B. Lu
> Sent: Thursday, November 10, 2016 12:06 PM
> To: 'Scott Wood'; Ulf Hansson
> Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; io...@lists.linux-foundation.org;
> net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
>
> > -Original Message-
> > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Thursday, November 10, 2016 11:55 AM
> > To: Ulf Hansson; Y.B. Lu
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux- ker...@vger.kernel.org; linux-clk;
> > io...@lists.linux-foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> >
> > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > - i2c-list
> > >
> > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo...@nxp.com> wrote:
> > > >
> > > > This patchset is used to fix a host version register bug in the
> > > > T4240-
> > > > R1.0-R2.0
> > > > eSDHC controller. To match the SoC version and revision, 15
> > > > previous version patchsets had tried many methods but all of them
> > > > were rejected by reviewers.
> > > > Such as
> > > > - dts compatible method
> > > > - syscon method
> > > > - ifdef PPC method
> > > > - GUTS driver getting SVR method Anrd suggested a
> > > > soc_device_match method in v10, and this is the only available
> > > > method left now. This v11 patchset introduces the soc_device_match
> > > > interface in soc driver.
> > > >
> > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > is used to register a soc device which contain soc version and
> > > > revision information.
> > > > The other three patches introduce the soc_device_match method in
> > > > soc driver and apply it on esdhc driver to fix this bug.
> > > >
> > > > ---
> > > > Changes for v15:
> > > > - Dropped patch 'dt: bindings: update Freescale DCFG
> > compatible'
> > > > since the work had been done by below patch on
> > > > ShawnGuo's linux tree.
> > > > 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > compatible for SCFG
> > > > and DCFG'
> > > > - Fixed error code issue in guts driver Changes for v16:
> > > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > include/linux/fsl'
> > > > - Added a bug-fix patch from Geert
> > > > ---
> > > >
> > > > Arnd Bergmann (1):
> > > > base: soc: introduce soc_device_match() interface
> > > >
> > > > Geert Uytterhoeven (1):
> > > > base: soc: Check for NULL SoC device attributes
> > > >
> > > > Yangbo Lu (5):
> > > > ARM64: dts: ls2080a: add device configuration node
> > > > dt: bindings: move guts devicetree doc out of powerpc directory
> > > > soc: fsl: add GUTS driver for QorIQ platforms
> > > > MAINTAINERS: add entry for Freescale SoC drivers
> > > > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > >
> > > > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > > > MAINTAINERS| 11 +-
> > > > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > > > drivers/base/Kconfig | 1 +
> > > > drivers/base/soc.c | 70 ++
> > > > drivers/mmc/host/Kconfig | 1 +
> > > > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > > > drivers/soc/Kconfig| 3 +-
> > > &
RE: [v16, 0/7] Fix eSDHC host version register bug
> -Original Message-
> From: Y.B. Lu
> Sent: Thursday, November 10, 2016 12:06 PM
> To: 'Scott Wood'; Ulf Hansson
> Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; io...@lists.linux-foundation.org;
> net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
>
> > -Original Message-
> > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Thursday, November 10, 2016 11:55 AM
> > To: Ulf Hansson; Y.B. Lu
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux- ker...@vger.kernel.org; linux-clk;
> > io...@lists.linux-foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> >
> > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > - i2c-list
> > >
> > > On 9 November 2016 at 04:14, Yangbo Lu wrote:
> > > >
> > > > This patchset is used to fix a host version register bug in the
> > > > T4240-
> > > > R1.0-R2.0
> > > > eSDHC controller. To match the SoC version and revision, 15
> > > > previous version patchsets had tried many methods but all of them
> > > > were rejected by reviewers.
> > > > Such as
> > > > - dts compatible method
> > > > - syscon method
> > > > - ifdef PPC method
> > > > - GUTS driver getting SVR method Anrd suggested a
> > > > soc_device_match method in v10, and this is the only available
> > > > method left now. This v11 patchset introduces the soc_device_match
> > > > interface in soc driver.
> > > >
> > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > is used to register a soc device which contain soc version and
> > > > revision information.
> > > > The other three patches introduce the soc_device_match method in
> > > > soc driver and apply it on esdhc driver to fix this bug.
> > > >
> > > > ---
> > > > Changes for v15:
> > > > - Dropped patch 'dt: bindings: update Freescale DCFG
> > compatible'
> > > > since the work had been done by below patch on
> > > > ShawnGuo's linux tree.
> > > > 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > compatible for SCFG
> > > > and DCFG'
> > > > - Fixed error code issue in guts driver Changes for v16:
> > > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > include/linux/fsl'
> > > > - Added a bug-fix patch from Geert
> > > > ---
> > > >
> > > > Arnd Bergmann (1):
> > > > base: soc: introduce soc_device_match() interface
> > > >
> > > > Geert Uytterhoeven (1):
> > > > base: soc: Check for NULL SoC device attributes
> > > >
> > > > Yangbo Lu (5):
> > > > ARM64: dts: ls2080a: add device configuration node
> > > > dt: bindings: move guts devicetree doc out of powerpc directory
> > > > soc: fsl: add GUTS driver for QorIQ platforms
> > > > MAINTAINERS: add entry for Freescale SoC drivers
> > > > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > >
> > > > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > > > MAINTAINERS| 11 +-
> > > > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > > > drivers/base/Kconfig | 1 +
> > > > drivers/base/soc.c | 70 ++
> > > > drivers/mmc/host/Kconfig | 1 +
> > > > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > > > drivers/soc/Kconfig| 3 +-
> > > > drivers/soc
RE: [v16, 0/7] Fix eSDHC host version register bug
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Thursday, November 10, 2016 11:55 AM
> To: Ulf Hansson; Y.B. Lu
> Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; io...@lists.linux-foundation.org;
> net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
>
> On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > - i2c-list
> >
> > On 9 November 2016 at 04:14, Yangbo Lu <yangbo...@nxp.com> wrote:
> > >
> > > This patchset is used to fix a host version register bug in the
> > > T4240-
> > > R1.0-R2.0
> > > eSDHC controller. To match the SoC version and revision, 15 previous
> > > version patchsets had tried many methods but all of them were
> > > rejected by reviewers.
> > > Such as
> > > - dts compatible method
> > > - syscon method
> > > - ifdef PPC method
> > > - GUTS driver getting SVR method Anrd suggested a
> > > soc_device_match method in v10, and this is the only available
> > > method left now. This v11 patchset introduces the soc_device_match
> > > interface in soc driver.
> > >
> > > The first four patches of Yangbo are to add the GUTS driver. This is
> > > used to register a soc device which contain soc version and revision
> > > information.
> > > The other three patches introduce the soc_device_match method in soc
> > > driver and apply it on esdhc driver to fix this bug.
> > >
> > > ---
> > > Changes for v15:
> > > - Dropped patch 'dt: bindings: update Freescale DCFG
> compatible'
> > > since the work had been done by below patch on ShawnGuo's
> > > linux tree.
> > > 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible
> > > for SCFG
> > > and DCFG'
> > > - Fixed error code issue in guts driver Changes for v16:
> > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> include/linux/fsl'
> > > - Added a bug-fix patch from Geert
> > > ---
> > >
> > > Arnd Bergmann (1):
> > > base: soc: introduce soc_device_match() interface
> > >
> > > Geert Uytterhoeven (1):
> > > base: soc: Check for NULL SoC device attributes
> > >
> > > Yangbo Lu (5):
> > > ARM64: dts: ls2080a: add device configuration node
> > > dt: bindings: move guts devicetree doc out of powerpc directory
> > > soc: fsl: add GUTS driver for QorIQ platforms
> > > MAINTAINERS: add entry for Freescale SoC drivers
> > > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > >
> > > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > > MAINTAINERS| 11 +-
> > > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > > drivers/base/Kconfig | 1 +
> > > drivers/base/soc.c | 70 ++
> > > drivers/mmc/host/Kconfig | 1 +
> > > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > > drivers/soc/Kconfig| 3 +-
> > > drivers/soc/fsl/Kconfig| 18 ++
> > > drivers/soc/fsl/Makefile | 1 +
> > > drivers/soc/fsl/guts.c | 236
> > > +
> > > include/linux/fsl/guts.h | 125
> > > ++-
> > > include/linux/sys_soc.h| 3 +
> > > 13 files changed, 447 insertions(+), 51 deletions(-)
> > > rename Documentation/devicetree/bindings/{powerpc =>
> > > soc}/fsl/guts.txt
> > > (91%)
> > > create mode 100644 drivers/soc/fsl/Kconfig
> > > create mode 100644 drivers/soc/fsl/guts.c
> > >
> > > --
> > > 2.1.0.27.g96db324
> > >
> > Thanks, applied on my mmc tree for next!
> >
> > I noticed that some DT compatibles weren't documented, according to
> > checkpatch. Please fix that asap!
>
> They are documente
RE: [v16, 0/7] Fix eSDHC host version register bug
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Thursday, November 10, 2016 11:55 AM
> To: Ulf Hansson; Y.B. Lu
> Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; io...@lists.linux-foundation.org;
> net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
>
> On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > - i2c-list
> >
> > On 9 November 2016 at 04:14, Yangbo Lu wrote:
> > >
> > > This patchset is used to fix a host version register bug in the
> > > T4240-
> > > R1.0-R2.0
> > > eSDHC controller. To match the SoC version and revision, 15 previous
> > > version patchsets had tried many methods but all of them were
> > > rejected by reviewers.
> > > Such as
> > > - dts compatible method
> > > - syscon method
> > > - ifdef PPC method
> > > - GUTS driver getting SVR method Anrd suggested a
> > > soc_device_match method in v10, and this is the only available
> > > method left now. This v11 patchset introduces the soc_device_match
> > > interface in soc driver.
> > >
> > > The first four patches of Yangbo are to add the GUTS driver. This is
> > > used to register a soc device which contain soc version and revision
> > > information.
> > > The other three patches introduce the soc_device_match method in soc
> > > driver and apply it on esdhc driver to fix this bug.
> > >
> > > ---
> > > Changes for v15:
> > > - Dropped patch 'dt: bindings: update Freescale DCFG
> compatible'
> > > since the work had been done by below patch on ShawnGuo's
> > > linux tree.
> > > 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible
> > > for SCFG
> > > and DCFG'
> > > - Fixed error code issue in guts driver Changes for v16:
> > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> include/linux/fsl'
> > > - Added a bug-fix patch from Geert
> > > ---
> > >
> > > Arnd Bergmann (1):
> > > base: soc: introduce soc_device_match() interface
> > >
> > > Geert Uytterhoeven (1):
> > > base: soc: Check for NULL SoC device attributes
> > >
> > > Yangbo Lu (5):
> > > ARM64: dts: ls2080a: add device configuration node
> > > dt: bindings: move guts devicetree doc out of powerpc directory
> > > soc: fsl: add GUTS driver for QorIQ platforms
> > > MAINTAINERS: add entry for Freescale SoC drivers
> > > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > >
> > > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > > MAINTAINERS| 11 +-
> > > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > > drivers/base/Kconfig | 1 +
> > > drivers/base/soc.c | 70 ++
> > > drivers/mmc/host/Kconfig | 1 +
> > > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > > drivers/soc/Kconfig| 3 +-
> > > drivers/soc/fsl/Kconfig| 18 ++
> > > drivers/soc/fsl/Makefile | 1 +
> > > drivers/soc/fsl/guts.c | 236
> > > +
> > > include/linux/fsl/guts.h | 125
> > > ++-
> > > include/linux/sys_soc.h| 3 +
> > > 13 files changed, 447 insertions(+), 51 deletions(-)
> > > rename Documentation/devicetree/bindings/{powerpc =>
> > > soc}/fsl/guts.txt
> > > (91%)
> > > create mode 100644 drivers/soc/fsl/Kconfig
> > > create mode 100644 drivers/soc/fsl/guts.c
> > >
> > > --
> > > 2.1.0.27.g96db324
> > >
> > Thanks, applied on my mmc tree for next!
> >
> > I noticed that some DT compatibles weren't documented, according to
> > checkpatch. Please fix that asap!
>
> They are documented, in fsl/guts.txt (the file
RE: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
Hi Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Tuesday, November 08, 2016 5:20 AM > To: Y.B. Lu > Cc: linuxppc-...@lists.ozlabs.org; linux-...@vger.kernel.org; > ulf.hans...@linaro.org; Scott Wood; Mark Rutland; Greg Kroah-Hartman; X.B. > Xie; M.H. Lian; linux-...@vger.kernel.org; linux-...@vger.kernel.org; > Qiang Zhao; Russell King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; > devicet...@vger.kernel.org; Rob Herring; Santosh Shilimkar; linux-arm- > ker...@lists.infradead.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Leo Li; io...@lists.linux-foundation.org; Kumar > Gala > Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl > > On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote: > > > > > > I don't see any of the contents of this header referenced by the soc > > > driver any more. I think you can just drop this patch. > > > > > > > [Lu Yangbo-B47093] This header file was included by guts.c. > > The guts driver used macro SVR_MAJ/SVR_MIN for calculation. > > > > This header file was for powerpc arch before. And this patch is to > > made it as common header file for both ARM and PPC. > > Sooner or later this is needed. > > Let's discuss it once we actually need the header then, ok? [Lu Yangbo-B47093] As I said, this header file was included by guts.c in patch 4. The guts driver used macro SVR_MAJ/SVR_MIN for calculation which were defined in this header file. Did you suggest we dropped this patch and just calculated them in driver? Thanks :) > > Arnd
RE: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
Hi Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Tuesday, November 08, 2016 5:20 AM > To: Y.B. Lu > Cc: linuxppc-...@lists.ozlabs.org; linux-...@vger.kernel.org; > ulf.hans...@linaro.org; Scott Wood; Mark Rutland; Greg Kroah-Hartman; X.B. > Xie; M.H. Lian; linux-...@vger.kernel.org; linux-...@vger.kernel.org; > Qiang Zhao; Russell King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; > devicet...@vger.kernel.org; Rob Herring; Santosh Shilimkar; linux-arm- > ker...@lists.infradead.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Leo Li; io...@lists.linux-foundation.org; Kumar > Gala > Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl > > On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote: > > > > > > I don't see any of the contents of this header referenced by the soc > > > driver any more. I think you can just drop this patch. > > > > > > > [Lu Yangbo-B47093] This header file was included by guts.c. > > The guts driver used macro SVR_MAJ/SVR_MIN for calculation. > > > > This header file was for powerpc arch before. And this patch is to > > made it as common header file for both ARM and PPC. > > Sooner or later this is needed. > > Let's discuss it once we actually need the header then, ok? [Lu Yangbo-B47093] As I said, this header file was included by guts.c in patch 4. The guts driver used macro SVR_MAJ/SVR_MIN for calculation which were defined in this header file. Did you suggest we dropped this patch and just calculated them in driver? Thanks :) > > Arnd
RE: [v15, 0/7] Fix eSDHC host version register bug
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Friday, October 28, 2016 6:54 PM > To: linux-arm-ker...@lists.infradead.org > Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott > Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux- > i...@vger.kernel.org; linux-...@vger.kernel.org; Qiang Zhao; Russell King; > Bhupesh Sharma; Joerg Roedel; Jochen Friedrich; Claudiu Manoil; > devicet...@vger.kernel.org; Rob Herring; Santosh Shilimkar; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li; > io...@lists.linux-foundation.org; Kumar Gala; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [v15, 0/7] Fix eSDHC host version register bug > > On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu wrote: > > This patchset is used to fix a host version register bug in the > > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and > > revision, 10 previous version patchsets had tried many methods but all > of them were rejected by reviewers. > > Such as > > - dts compatible method > > - syscon method > > - ifdef PPC method > > - GUTS driver getting SVR method Anrd suggested a > > soc_device_match method in v10, and this is the only available method > > left now. This v11 patchset introduces the soc_device_match interface > > in soc driver. > > > > The first five patches of Yangbo are to add the GUTS driver. This is > > used to register a soc device which contain soc version and revision > information. > > The other two patches introduce the soc_device_match method in soc > > driver and apply it on esdhc driver to fix this bug. > > > > Looks good overall. With patch 3 dropped (or an explanation why it's > still needed), everything > > Acked-by: Arnd Bergmann <a...@arndb.de> > [Lu Yangbo-B47093] Thank you very much:) See my explaination in patch 3 email. > Arnd
RE: [v15, 0/7] Fix eSDHC host version register bug
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Friday, October 28, 2016 6:54 PM > To: linux-arm-ker...@lists.infradead.org > Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott > Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux- > i...@vger.kernel.org; linux-...@vger.kernel.org; Qiang Zhao; Russell King; > Bhupesh Sharma; Joerg Roedel; Jochen Friedrich; Claudiu Manoil; > devicet...@vger.kernel.org; Rob Herring; Santosh Shilimkar; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li; > io...@lists.linux-foundation.org; Kumar Gala; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [v15, 0/7] Fix eSDHC host version register bug > > On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu wrote: > > This patchset is used to fix a host version register bug in the > > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and > > revision, 10 previous version patchsets had tried many methods but all > of them were rejected by reviewers. > > Such as > > - dts compatible method > > - syscon method > > - ifdef PPC method > > - GUTS driver getting SVR method Anrd suggested a > > soc_device_match method in v10, and this is the only available method > > left now. This v11 patchset introduces the soc_device_match interface > > in soc driver. > > > > The first five patches of Yangbo are to add the GUTS driver. This is > > used to register a soc device which contain soc version and revision > information. > > The other two patches introduce the soc_device_match method in soc > > driver and apply it on esdhc driver to fix this bug. > > > > Looks good overall. With patch 3 dropped (or an explanation why it's > still needed), everything > > Acked-by: Arnd Bergmann > [Lu Yangbo-B47093] Thank you very much:) See my explaination in patch 3 email. > Arnd
RE: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Friday, October 28, 2016 6:53 PM > To: linuxppc-...@lists.ozlabs.org > Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott > Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux- > i...@vger.kernel.org; linux-...@vger.kernel.org; Qiang Zhao; Russell King; > Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicet...@vger.kernel.org; > Rob Herring; Santosh Shilimkar; linux-arm-ker...@lists.infradead.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li; > io...@lists.linux-foundation.org; Kumar Gala > Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl > > On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote: > > Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common > > header file. This SVR numberspace is used on some ARM chips as well > > as PPC, and even to check for a PPC SVR multi-arch drivers would > > otherwise need to ifdef the header inclusion and all references to the > SVR symbols. > > > > > > I don't see any of the contents of this header referenced by the soc > driver any more. I think you can just drop this patch. > [Lu Yangbo-B47093] This header file was included by guts.c. The guts driver used macro SVR_MAJ/SVR_MIN for calculation. This header file was for powerpc arch before. And this patch is to made it as common header file for both ARM and PPC. Sooner or later this is needed. > Arnd
RE: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Friday, October 28, 2016 6:53 PM > To: linuxppc-...@lists.ozlabs.org > Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott > Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux- > i...@vger.kernel.org; linux-...@vger.kernel.org; Qiang Zhao; Russell King; > Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicet...@vger.kernel.org; > Rob Herring; Santosh Shilimkar; linux-arm-ker...@lists.infradead.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li; > io...@lists.linux-foundation.org; Kumar Gala > Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl > > On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote: > > Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common > > header file. This SVR numberspace is used on some ARM chips as well > > as PPC, and even to check for a PPC SVR multi-arch drivers would > > otherwise need to ifdef the header inclusion and all references to the > SVR symbols. > > > > > > I don't see any of the contents of this header referenced by the soc > driver any more. I think you can just drop this patch. > [Lu Yangbo-B47093] This header file was included by guts.c. The guts driver used macro SVR_MAJ/SVR_MIN for calculation. This header file was for powerpc arch before. And this patch is to made it as common header file for both ARM and PPC. Sooner or later this is needed. > Arnd
RE: [v15, 6/7] base: soc: introduce soc_device_match() interface
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, October 28, 2016 6:48 PM
> To: linuxppc-...@lists.ozlabs.org
> Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i...@vger.kernel.org; linux-...@vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicet...@vger.kernel.org;
> Rob Herring; Santosh Shilimkar; linux-arm-ker...@lists.infradead.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li;
> io...@lists.linux-foundation.org; Kumar Gala; Geert Uytterhoeven
> Subject: Re: [v15, 6/7] base: soc: introduce soc_device_match() interface
>
> On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> > +
> > +static int soc_device_match_one(struct device *dev, void *arg) {
> > + struct soc_device *soc_dev = container_of(dev, struct
> soc_device, dev);
> > + const struct soc_device_attribute *match = arg;
> > +
> > + if (match->machine &&
> > + !glob_match(match->machine, soc_dev->attr->machine))
> > + return 0;
> > +
> > + if (match->family &&
> > + !glob_match(match->family, soc_dev->attr->family))
> > + return 0;
> > +
> >
>
> Geert found a bug in my code, and submitted a fix at
> https://patchwork.kernel.org/patch/9361395/
>
> I think you should include that one in your series.
>
[Lu Yangbo-B47093] Ok, no problem. Thanks :)
> Arnd
RE: [v15, 6/7] base: soc: introduce soc_device_match() interface
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, October 28, 2016 6:48 PM
> To: linuxppc-...@lists.ozlabs.org
> Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i...@vger.kernel.org; linux-...@vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicet...@vger.kernel.org;
> Rob Herring; Santosh Shilimkar; linux-arm-ker...@lists.infradead.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li;
> io...@lists.linux-foundation.org; Kumar Gala; Geert Uytterhoeven
> Subject: Re: [v15, 6/7] base: soc: introduce soc_device_match() interface
>
> On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> > +
> > +static int soc_device_match_one(struct device *dev, void *arg) {
> > + struct soc_device *soc_dev = container_of(dev, struct
> soc_device, dev);
> > + const struct soc_device_attribute *match = arg;
> > +
> > + if (match->machine &&
> > + !glob_match(match->machine, soc_dev->attr->machine))
> > + return 0;
> > +
> > + if (match->family &&
> > + !glob_match(match->family, soc_dev->attr->family))
> > + return 0;
> > +
> >
>
> Geert found a bug in my code, and submitted a fix at
> https://patchwork.kernel.org/patch/9361395/
>
> I think you should include that one in your series.
>
[Lu Yangbo-B47093] Ok, no problem. Thanks :)
> Arnd
RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Friday, October 28, 2016 12:46 PM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > + guts->regs = of_iomap(np, 0);
> > + if (!guts->regs)
> > + return -ENOMEM;
> > +
> > + /* Register soc device */
> > + machine = of_flat_dt_get_machine_name();
> > + if (machine)
> > + soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > GFP_KERNEL);
> > +
> > + svr = fsl_guts_get_svr();
> > + soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > + if (soc_die) {
> > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > + "QorIQ %s", soc_die-
> > >die);
> > + } else {
> > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > "QorIQ");
> > + }
> > + soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > + "svr:0x%08x", svr);
> > + soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
> > + SVR_MAJ(svr), SVR_MIN(svr));
> > +
> > + soc_dev = soc_device_register(_dev_attr);
> > + if (IS_ERR(soc_dev))
> > + return PTR_ERR(soc_dev);
>
> ioremap leaks on this error path. Use devm_ioremap_resource().
>
[Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
> -Scott
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Friday, October 28, 2016 12:46 PM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > + guts->regs = of_iomap(np, 0);
> > + if (!guts->regs)
> > + return -ENOMEM;
> > +
> > + /* Register soc device */
> > + machine = of_flat_dt_get_machine_name();
> > + if (machine)
> > + soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > GFP_KERNEL);
> > +
> > + svr = fsl_guts_get_svr();
> > + soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > + if (soc_die) {
> > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > + "QorIQ %s", soc_die-
> > >die);
> > + } else {
> > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > "QorIQ");
> > + }
> > + soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > + "svr:0x%08x", svr);
> > + soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
> > + SVR_MAJ(svr), SVR_MIN(svr));
> > +
> > + soc_dev = soc_device_register(_dev_attr);
> > + if (IS_ERR(soc_dev))
> > + return PTR_ERR(soc_dev);
>
> ioremap leaks on this error path. Use devm_ioremap_resource().
>
[Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
> -Scott
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: Y.B. Lu
> Sent: Friday, October 28, 2016 2:06 PM
> To: Y.B. Lu; 'Scott Wood'; 'linux-...@vger.kernel.org';
> 'ulf.hans...@linaro.org'; 'Arnd Bergmann'
> Cc: 'linuxppc-...@lists.ozlabs.org'; 'devicet...@vger.kernel.org';
> 'linux-arm-ker...@lists.infradead.org'; 'linux-kernel@vger.kernel.org';
> 'linux-...@vger.kernel.org'; 'linux-...@vger.kernel.org';
> 'io...@lists.linux-foundation.org'; 'net...@vger.kernel.org'; 'Greg
> Kroah-Hartman'; 'Mark Rutland'; 'Rob Herring'; 'Russell King'; 'Jochen
> Friedrich'; 'Joerg Roedel'; 'Claudiu Manoil'; 'Bhupesh Sharma'; Qiang
> Zhao; 'Kumar Gala'; 'Santosh Shilimkar'; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> > -Original Message-
> > From: Y.B. Lu
> > Sent: Friday, October 28, 2016 2:00 PM
> > To: 'Scott Wood'; linux-...@vger.kernel.org; ulf.hans...@linaro.org;
> > Arnd Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > Xie; M.H. Lian
> > Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> >
> >
> >
> > > -Original Message-
> > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Friday, October 28, 2016 12:46 PM
> > > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > > Bergmann
> > > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > > Xie; M.H. Lian
> > > Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ
> > > platforms
> > >
> > > On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > > > + guts->regs = of_iomap(np, 0);
> > > > + if (!guts->regs)
> > > > + return -ENOMEM;
> > > > +
> > > > + /* Register soc device */
> > > > + machine = of_flat_dt_get_machine_name();
> > > > + if (machine)
> > > > + soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > > > GFP_KERNEL);
> > > > +
> > > > + svr = fsl_guts_get_svr();
> > > > + soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > > > + if (soc_die) {
> > > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > > + "QorIQ %s",
> > > > soc_die-
> > > > >die);
> > > > + } else {
> > > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > > "QorIQ");
> > > > + }
> > > > + soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > > > + "svr:0x%08x", svr);
> > > > + soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL,
> "%d.%d",
> > > > + SVR_MAJ(svr),
> > > > SVR_MIN(svr));
> > > > +
> > > > + soc_dev = soc_device_register(_dev_attr);
> > > > + if (IS_ERR(soc_dev))
> > > > + return PTR_ERR(soc_dev);
> > >
> > > ioremap leaks on this error path. Use devm_ioremap_resource().
> > >
> >
> > [Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
>
> [Lu Yangbo-B47093] Sorry, used the wrong error code... Will resent it
[Lu Yangbo-B47093] The v15 had been sent. And dropped patch 'dt: bindings:
update Freescale DCFG compatible',
since that work has been done by below patch on ShawnGuo's linux tree.
'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG and DCFG'
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64=981034a2bfcaff5c95dafde24d7abfe7f9025c19
Thanks.
>
> >
> > > -Scott
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > > in the body of a message to majord...@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: Y.B. Lu
> Sent: Friday, October 28, 2016 2:06 PM
> To: Y.B. Lu; 'Scott Wood'; 'linux-...@vger.kernel.org';
> 'ulf.hans...@linaro.org'; 'Arnd Bergmann'
> Cc: 'linuxppc-...@lists.ozlabs.org'; 'devicet...@vger.kernel.org';
> 'linux-arm-ker...@lists.infradead.org'; 'linux-kernel@vger.kernel.org';
> 'linux-...@vger.kernel.org'; 'linux-...@vger.kernel.org';
> 'io...@lists.linux-foundation.org'; 'net...@vger.kernel.org'; 'Greg
> Kroah-Hartman'; 'Mark Rutland'; 'Rob Herring'; 'Russell King'; 'Jochen
> Friedrich'; 'Joerg Roedel'; 'Claudiu Manoil'; 'Bhupesh Sharma'; Qiang
> Zhao; 'Kumar Gala'; 'Santosh Shilimkar'; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> > -Original Message-
> > From: Y.B. Lu
> > Sent: Friday, October 28, 2016 2:00 PM
> > To: 'Scott Wood'; linux-...@vger.kernel.org; ulf.hans...@linaro.org;
> > Arnd Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > Xie; M.H. Lian
> > Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> >
> >
> >
> > > -Original Message-
> > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Friday, October 28, 2016 12:46 PM
> > > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > > Bergmann
> > > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > > Xie; M.H. Lian
> > > Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ
> > > platforms
> > >
> > > On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > > > + guts->regs = of_iomap(np, 0);
> > > > + if (!guts->regs)
> > > > + return -ENOMEM;
> > > > +
> > > > + /* Register soc device */
> > > > + machine = of_flat_dt_get_machine_name();
> > > > + if (machine)
> > > > + soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > > > GFP_KERNEL);
> > > > +
> > > > + svr = fsl_guts_get_svr();
> > > > + soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > > > + if (soc_die) {
> > > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > > + "QorIQ %s",
> > > > soc_die-
> > > > >die);
> > > > + } else {
> > > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > > "QorIQ");
> > > > + }
> > > > + soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > > > + "svr:0x%08x", svr);
> > > > + soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL,
> "%d.%d",
> > > > + SVR_MAJ(svr),
> > > > SVR_MIN(svr));
> > > > +
> > > > + soc_dev = soc_device_register(_dev_attr);
> > > > + if (IS_ERR(soc_dev))
> > > > + return PTR_ERR(soc_dev);
> > >
> > > ioremap leaks on this error path. Use devm_ioremap_resource().
> > >
> >
> > [Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
>
> [Lu Yangbo-B47093] Sorry, used the wrong error code... Will resent it
[Lu Yangbo-B47093] The v15 had been sent. And dropped patch 'dt: bindings:
update Freescale DCFG compatible',
since that work has been done by below patch on ShawnGuo's linux tree.
'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG and DCFG'
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64=981034a2bfcaff5c95dafde24d7abfe7f9025c19
Thanks.
>
> >
> > > -Scott
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > > in the body of a message to majord...@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: Y.B. Lu
> Sent: Friday, October 28, 2016 2:00 PM
> To: 'Scott Wood'; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
>
>
> > -Original Message-
> > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Friday, October 28, 2016 12:46 PM
> > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > Xie; M.H. Lian
> > Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> >
> > On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > > + guts->regs = of_iomap(np, 0);
> > > + if (!guts->regs)
> > > + return -ENOMEM;
> > > +
> > > + /* Register soc device */
> > > + machine = of_flat_dt_get_machine_name();
> > > + if (machine)
> > > + soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > > GFP_KERNEL);
> > > +
> > > + svr = fsl_guts_get_svr();
> > > + soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > > + if (soc_die) {
> > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > + "QorIQ %s", soc_die-
> > > >die);
> > > + } else {
> > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > "QorIQ");
> > > + }
> > > + soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > > + "svr:0x%08x", svr);
> > > + soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
> > > + SVR_MAJ(svr), SVR_MIN(svr));
> > > +
> > > + soc_dev = soc_device_register(_dev_attr);
> > > + if (IS_ERR(soc_dev))
> > > + return PTR_ERR(soc_dev);
> >
> > ioremap leaks on this error path. Use devm_ioremap_resource().
> >
>
> [Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
[Lu Yangbo-B47093] Sorry, used the wrong error code... Will resent it
>
> > -Scott
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: Y.B. Lu
> Sent: Friday, October 28, 2016 2:00 PM
> To: 'Scott Wood'; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: RE: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
>
>
> > -Original Message-
> > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Friday, October 28, 2016 12:46 PM
> > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> > Xie; M.H. Lian
> > Subject: Re: [v13, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> >
> > On Fri, 2016-10-28 at 11:32 +0800, Yangbo Lu wrote:
> > > + guts->regs = of_iomap(np, 0);
> > > + if (!guts->regs)
> > > + return -ENOMEM;
> > > +
> > > + /* Register soc device */
> > > + machine = of_flat_dt_get_machine_name();
> > > + if (machine)
> > > + soc_dev_attr.machine = devm_kstrdup(dev, machine,
> > > GFP_KERNEL);
> > > +
> > > + svr = fsl_guts_get_svr();
> > > + soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> > > + if (soc_die) {
> > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > + "QorIQ %s", soc_die-
> > > >die);
> > > + } else {
> > > + soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> > > "QorIQ");
> > > + }
> > > + soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> > > + "svr:0x%08x", svr);
> > > + soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
> > > + SVR_MAJ(svr), SVR_MIN(svr));
> > > +
> > > + soc_dev = soc_device_register(_dev_attr);
> > > + if (IS_ERR(soc_dev))
> > > + return PTR_ERR(soc_dev);
> >
> > ioremap leaks on this error path. Use devm_ioremap_resource().
> >
>
> [Lu Yangbo-B47093] Ok. I have fixed it in v14. Thanks :)
[Lu Yangbo-B47093] Sorry, used the wrong error code... Will resent it
>
> > -Scott
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
RE: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
Hi Scott,
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Thursday, October 27, 2016 1:06 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new
> > file mode 100644 index 000..b99764c
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,19 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool "Freescale QorIQ GUTS driver"
> > + select SOC_BUS
> > + help
> > + The global utilities block controls power management, I/O device
> > + enabling, power-onreset(POR) configuration monitoring, alternate
> > + function selection for multiplexed signals,and clock control.
> > + This driver is to manage and access global utilities block.
> > + Initially only reading SVR and registering soc device are
> > supported.
> > + Other guts accesses, such as reading RCW, should eventually be
> > moved
> > + into this driver as well.
> > +
> > + If you want GUTS driver support, you should say Y here.
>
> This is user-enablable without dependencies, which means it will break
> some randconfigs. If this is to be enabled via select then remove the
> text after "bool".
[Lu Yangbo-B47093] Will enable it via select and remove text after 'bool'.
>
> > +/* SoC die attribute definition for QorIQ platform */ static const
> > +struct fsl_soc_die_attr fsl_soc_die[] = { #ifdef CONFIG_PPC
> > + /*
> > + * Power Architecture-based SoCs T Series
> > + */
> > +
> > + /* Die: T4240, SoC: T4240/T4160/T4080 */
> > + { .die = "T4240",
> > + .svr = 0x8240,
> > + .mask = 0xfff0,
> > + },
> > + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> > + { .die = "T1040",
> > + .svr = 0x8520,
> > + .mask = 0xfff0,
> > + },
> > + /* Die: T2080, SoC: T2080/T2081 */
> > + { .die = "T2080",
> > + .svr = 0x8530,
> > + .mask = 0xfff0,
> > + },
> > + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> > + { .die = "T1024",
> > + .svr = 0x8540,
> > + .mask = 0xfff0,
> > + },
> > +#endif /* CONFIG_PPC */
> > +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
>
> Will this driver ever be probed on MXC? Why do we need these ifdefs at
> all?
[Lu Yangbo-B47093] Will remove them. In the previous version, we use too many
members for soc definition, so I add #ifdef for ARCH.
CONFIG_ARCH_MXC was for ls1021a.
>
>
> > + /*
> > + * ARM-based SoCs LS Series
> > + */
> > +
> > + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> > + { .die = "LS1043A",
> > + .svr = 0x8792,
> > + .mask = 0x,
> > + },
> > + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> > + { .die = "LS2080A",
> > + .svr = 0x8701,
> > + .mask = 0xff3f,
> > + },
> > + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> > + { .die = "LS1088A",
> > + .svr = 0x8703,
> > + .mask = 0xff3f,
> > + },
> > + /* Die: LS1012A, SoC: LS1012A */
> > + { .die = "LS1012A",
> > + .svr = 0x8704,
> > + .mask = 0x,
> > + },
> > + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> > + { .die = "LS1046A",
> > + .svr = 0x8707,
> > + .mask = 0x,
> > + },
> > + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> > + { .die =
RE: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
Hi Scott,
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Thursday, October 27, 2016 1:06 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: Re: [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Wed, 2016-09-21 at 14:57 +0800, Yangbo Lu wrote:
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new
> > file mode 100644 index 000..b99764c
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,19 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool "Freescale QorIQ GUTS driver"
> > + select SOC_BUS
> > + help
> > + The global utilities block controls power management, I/O device
> > + enabling, power-onreset(POR) configuration monitoring, alternate
> > + function selection for multiplexed signals,and clock control.
> > + This driver is to manage and access global utilities block.
> > + Initially only reading SVR and registering soc device are
> > supported.
> > + Other guts accesses, such as reading RCW, should eventually be
> > moved
> > + into this driver as well.
> > +
> > + If you want GUTS driver support, you should say Y here.
>
> This is user-enablable without dependencies, which means it will break
> some randconfigs. If this is to be enabled via select then remove the
> text after "bool".
[Lu Yangbo-B47093] Will enable it via select and remove text after 'bool'.
>
> > +/* SoC die attribute definition for QorIQ platform */ static const
> > +struct fsl_soc_die_attr fsl_soc_die[] = { #ifdef CONFIG_PPC
> > + /*
> > + * Power Architecture-based SoCs T Series
> > + */
> > +
> > + /* Die: T4240, SoC: T4240/T4160/T4080 */
> > + { .die = "T4240",
> > + .svr = 0x8240,
> > + .mask = 0xfff0,
> > + },
> > + /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
> > + { .die = "T1040",
> > + .svr = 0x8520,
> > + .mask = 0xfff0,
> > + },
> > + /* Die: T2080, SoC: T2080/T2081 */
> > + { .die = "T2080",
> > + .svr = 0x8530,
> > + .mask = 0xfff0,
> > + },
> > + /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
> > + { .die = "T1024",
> > + .svr = 0x8540,
> > + .mask = 0xfff0,
> > + },
> > +#endif /* CONFIG_PPC */
> > +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
>
> Will this driver ever be probed on MXC? Why do we need these ifdefs at
> all?
[Lu Yangbo-B47093] Will remove them. In the previous version, we use too many
members for soc definition, so I add #ifdef for ARCH.
CONFIG_ARCH_MXC was for ls1021a.
>
>
> > + /*
> > + * ARM-based SoCs LS Series
> > + */
> > +
> > + /* Die: LS1043A, SoC: LS1043A/LS1023A */
> > + { .die = "LS1043A",
> > + .svr = 0x8792,
> > + .mask = 0x,
> > + },
> > + /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
> > + { .die = "LS2080A",
> > + .svr = 0x8701,
> > + .mask = 0xff3f,
> > + },
> > + /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
> > + { .die = "LS1088A",
> > + .svr = 0x8703,
> > + .mask = 0xff3f,
> > + },
> > + /* Die: LS1012A, SoC: LS1012A */
> > + { .die = "LS1012A",
> > + .svr = 0x8704,
> > + .mask = 0x,
> > + },
> > + /* Die: LS1046A, SoC: LS1046A/LS1026A */
> > + { .die = "LS1046A",
> > + .svr = 0x8707,
> > + .mask = 0x,
> > + },
> > + /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
> > + { .die =
RE: [v12, 0/8] Fix eSDHC host version register bug
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Tuesday, October 18, 2016 6:48 PM
> To: Y.B. Lu
> Cc: linux-mmc; Scott Wood; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; linux-...@vger.kernel.org;
> io...@lists.linux-foundation.org; net...@vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v12, 0/8] Fix eSDHC host version register bug
>
> On 21 September 2016 at 08:57, Yangbo Lu <yangbo...@nxp.com> wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS| 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++
> > drivers/clk/clk-qoriq.c| 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig| 2 +-
> > drivers/soc/fsl/Kconfig| 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> +
> > include/linux/fsl/guts.h | 125 ++
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h| 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> This looks good to me! I am not sure which tree you want this to be
> picked up through, but unless no other volunteers I can take it through
> my mmc tree.
>
> Although, before considering to apply, I need an ack from Scott/Arnd for
> the guts driver in patch 5/8 and I need an ack from Greg for patch 7/8,
> where the soc_device_match() interface is added (seems like you didn't
> add him on cc/to).
>
[Lu Yangbo-B47093] Thanks a lot for your clarifying, Uffe.
This patchset was based on mmc tree, and needed your picking up.
But I think it needs to be rebased now since I saw qbman driver was in
drivers/soc/fsl/ now.
I will do that after collecting others' ACKs or comments.
Hi Scott and Arnd,
Could I get your ACTs if there're no other changes needed?
Thanks a lot.
> Kind regards
> Uffe
RE: [v12, 0/8] Fix eSDHC host version register bug
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Tuesday, October 18, 2016 6:48 PM
> To: Y.B. Lu
> Cc: linux-mmc; Scott Wood; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; linux-...@vger.kernel.org;
> io...@lists.linux-foundation.org; net...@vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v12, 0/8] Fix eSDHC host version register bug
>
> On 21 September 2016 at 08:57, Yangbo Lu wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS| 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++
> > drivers/clk/clk-qoriq.c| 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig| 2 +-
> > drivers/soc/fsl/Kconfig| 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> +
> > include/linux/fsl/guts.h | 125 ++
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h| 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> This looks good to me! I am not sure which tree you want this to be
> picked up through, but unless no other volunteers I can take it through
> my mmc tree.
>
> Although, before considering to apply, I need an ack from Scott/Arnd for
> the guts driver in patch 5/8 and I need an ack from Greg for patch 7/8,
> where the soc_device_match() interface is added (seems like you didn't
> add him on cc/to).
>
[Lu Yangbo-B47093] Thanks a lot for your clarifying, Uffe.
This patchset was based on mmc tree, and needed your picking up.
But I think it needs to be rebased now since I saw qbman driver was in
drivers/soc/fsl/ now.
I will do that after collecting others' ACKs or comments.
Hi Scott and Arnd,
Could I get your ACTs if there're no other changes needed?
Thanks a lot.
> Kind regards
> Uffe
RE: [v12, 0/8] Fix eSDHC host version register bug
+ Greg
Hi Greg,
I submitted this patchset for a MMC bug fix, and introduce the below patch
which needs your ACK.
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
https://patchwork.kernel.org/patch/9342913/
Could you help to review it and give some comments or ACK.
Thank you very much.
Best regards,
Yangbo Lu
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Tuesday, October 18, 2016 6:48 PM
> To: Y.B. Lu
> Cc: linux-mmc; Scott Wood; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; linux-...@vger.kernel.org;
> io...@lists.linux-foundation.org; net...@vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v12, 0/8] Fix eSDHC host version register bug
>
> On 21 September 2016 at 08:57, Yangbo Lu <yangbo...@nxp.com> wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS| 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++
> > drivers/clk/clk-qoriq.c| 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig| 2 +-
> > drivers/soc/fsl/Kconfig| 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> +
> > include/linux/fsl/guts.h | 125 ++
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h| 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> This looks good to me! I am not sure which tree you want this to be
> picked up through, but unless no other volunteers I can take it through
> my mmc tree.
>
> Although, before considering to apply, I need an ack from Scott/Arnd for
> the guts driver in patch 5/8 and I need an ack from Greg for patch 7/8,
> where the soc_device_match() interface is added (seems like you didn't
> add him on cc/to).
>
> Kind regards
> Uffe
RE: [v12, 0/8] Fix eSDHC host version register bug
+ Greg
Hi Greg,
I submitted this patchset for a MMC bug fix, and introduce the below patch
which needs your ACK.
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
https://patchwork.kernel.org/patch/9342913/
Could you help to review it and give some comments or ACK.
Thank you very much.
Best regards,
Yangbo Lu
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Tuesday, October 18, 2016 6:48 PM
> To: Y.B. Lu
> Cc: linux-mmc; Scott Wood; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; linux-...@vger.kernel.org;
> io...@lists.linux-foundation.org; net...@vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v12, 0/8] Fix eSDHC host version register bug
>
> On 21 September 2016 at 08:57, Yangbo Lu wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS| 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++
> > drivers/clk/clk-qoriq.c| 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig| 2 +-
> > drivers/soc/fsl/Kconfig| 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> +
> > include/linux/fsl/guts.h | 125 ++
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h| 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> This looks good to me! I am not sure which tree you want this to be
> picked up through, but unless no other volunteers I can take it through
> my mmc tree.
>
> Although, before considering to apply, I need an ack from Scott/Arnd for
> the guts driver in patch 5/8 and I need an ack from Greg for patch 7/8,
> where the soc_device_match() interface is added (seems like you didn't
> add him on cc/to).
>
> Kind regards
> Uffe
RE: [v12, 0/8] Fix eSDHC host version register bug
Hi Uffe, Arnd and Scott,
Any comments on this latest patcheset?
Could we consider to merge it if no any other changes needed?
:)
Thanks.
Best regards,
Yangbo Lu
> -Original Message-
> From: Y.B. Lu
> Sent: Monday, September 26, 2016 11:15 AM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: RE: [v12, 0/8] Fix eSDHC host version register bug
>
> Any comments about this version patchset ?
>
> :)
>
>
> > -Original Message-
> > From: Yangbo Lu [mailto:yangbo...@nxp.com]
> > Sent: Wednesday, September 21, 2016 2:57 PM
> > To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood;
> > Arnd Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Mark
> > Rutland; Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel;
> > Claudiu Manoil; Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh
> Shilimkar; Leo Li; X.B. Xie; M.H.
> > Lian; Y.B. Lu
> > Subject: [v12, 0/8] Fix eSDHC host version register bug
> >
> > This patchset is used to fix a host version register bug in the T4240-
> > R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> > previous version patchsets had tried many methods but all of them were
> > rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method
> > Anrd suggested a soc_device_match method in v10, and this is the only
> > available method left now. This v11 patchset introduces the
> > soc_device_match interface in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> > information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS| 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++
> > drivers/clk/clk-qoriq.c| 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig| 2 +-
> > drivers/soc/fsl/Kconfig| 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> > +
> > include/linux/fsl/guts.h | 125 ++
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h| 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
RE: [v12, 0/8] Fix eSDHC host version register bug
Hi Uffe, Arnd and Scott,
Any comments on this latest patcheset?
Could we consider to merge it if no any other changes needed?
:)
Thanks.
Best regards,
Yangbo Lu
> -Original Message-
> From: Y.B. Lu
> Sent: Monday, September 26, 2016 11:15 AM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian
> Subject: RE: [v12, 0/8] Fix eSDHC host version register bug
>
> Any comments about this version patchset ?
>
> :)
>
>
> > -Original Message-
> > From: Yangbo Lu [mailto:yangbo...@nxp.com]
> > Sent: Wednesday, September 21, 2016 2:57 PM
> > To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood;
> > Arnd Bergmann
> > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Mark
> > Rutland; Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel;
> > Claudiu Manoil; Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh
> Shilimkar; Leo Li; X.B. Xie; M.H.
> > Lian; Y.B. Lu
> > Subject: [v12, 0/8] Fix eSDHC host version register bug
> >
> > This patchset is used to fix a host version register bug in the T4240-
> > R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> > previous version patchsets had tried many methods but all of them were
> > rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method
> > Anrd suggested a soc_device_match method in v10, and this is the only
> > available method left now. This v11 patchset introduces the
> > soc_device_match interface in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> > information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS| 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++
> > drivers/clk/clk-qoriq.c| 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig| 2 +-
> > drivers/soc/fsl/Kconfig| 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> > +
> > include/linux/fsl/guts.h | 125 ++
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h| 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
RE: [v12, 0/8] Fix eSDHC host version register bug
Any comments about this version patchset ?
:)
> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
>
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS| 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++
> drivers/clk/clk-qoriq.c| 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig| 2 +-
> drivers/soc/fsl/Kconfig| 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257
> +
> include/linux/fsl/guts.h | 125 ++
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h| 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-) rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
RE: [v12, 0/8] Fix eSDHC host version register bug
Any comments about this version patchset ?
:)
> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
>
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS| 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++
> drivers/clk/clk-qoriq.c| 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig| 2 +-
> drivers/soc/fsl/Kconfig| 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257
> +
> include/linux/fsl/guts.h | 125 ++
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h| 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-) rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
RE: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Tuesday, September 13, 2016 7:25 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Mon, 2016-09-12 at 06:39 +, Y.B. Lu wrote:
> > Hi Scott,
> >
> > Thanks for your review :)
> > See my comment inline.
> >
> > >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Friday, September 09, 2016 11:47 AM
> > > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > > Bergmann
> > > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Mark
> > > Rutland; Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel;
> > > Claudiu Manoil; Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh
> > > Shilimkar; Leo Li; X.B. Xie
> > > Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ
> > > platforms
> > >
> > > On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > > >
> > > > The global utilities block controls power management, I/O device
> > > > enabling, power-onreset(POR) configuration monitoring, alternate
> > > > function selection for multiplexed signals,and clock control.
> > > >
> > > > This patch adds a driver to manage and access global utilities
> block.
> > > > Initially only reading SVR and registering soc device are supported.
> > > > Other guts accesses, such as reading RCW, should eventually be
> > > > moved into this driver as well.
> > > >
> > > > Signed-off-by: Yangbo Lu <yangbo...@nxp.com>
> > > > Signed-off-by: Scott Wood <o...@buserror.net>
> > > Don't put my signoff on patches that I didn't put it on myself.
> > > Definitely don't put mine *after* yours on patches that were last
> > > modified by you.
> > >
> > > If you want to mention that the soc_id encoding was my suggestion,
> > > then do so explicitly.
> > >
> > [Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
> > http://patchwork.ozlabs.org/patch/649211/
> >
> > So, let me just change the order in next version ?
> > Signed-off-by: Scott Wood <o...@buserror.net>
> > Signed-off-by: Yangbo Lu <yangbo...@nxp.com>
>
> No. This isn't my patch so my signoff shouldn't be on it.
[Lu Yangbo-B47093] Ok, will remove it.
>
> > [Lu Yangbo-B47093] It's a good idea to move die into .family I think.
> > In my opinion, it's better to keep svr and name in soc_id just like
> > your suggestion above.
> > >
> > > {
> > > .soc_id = "svr:0x85490010,name:T1023E,",
> > > .family = "QorIQ T1024",
> > > }
> > The user probably don’t like to learn the svr value. What they want is
> > just to match the soc they use.
> > It's convenient to use name+rev for them to match a soc.
>
> What the user should want 99% of the time is to match the die (plus
> revision), not the soc.
>
> > Regarding shrinking the table, I think it's hard to use svr+mask.
> > Because I find many platforms use different masks.
> > We couldn’t know the mask according svr value.
>
> The mask would be part of the table:
>
> {
> {
> .die = "T1024",
> .svr = 0x8540,
> .mask = 0xfff0,
> },
> {
> .die = "T1040",
> .svr = 0x8520,
> .mask = 0xfff0,
> },
> {
> .die = "LS1088A",
> .svr = 0x8703,
> .mask = 0x,
> },
> ...
> }
>
> There's a small risk that we get the mask wrong and a different die
RE: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Scott Wood
> Sent: Tuesday, September 13, 2016 7:25 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Mon, 2016-09-12 at 06:39 +, Y.B. Lu wrote:
> > Hi Scott,
> >
> > Thanks for your review :)
> > See my comment inline.
> >
> > >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Friday, September 09, 2016 11:47 AM
> > > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> > > Bergmann
> > > Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org;
> > > linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux- c...@vger.kernel.org; linux-...@vger.kernel.org;
> > > iommu@lists.linux- foundation.org; net...@vger.kernel.org; Mark
> > > Rutland; Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel;
> > > Claudiu Manoil; Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh
> > > Shilimkar; Leo Li; X.B. Xie
> > > Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ
> > > platforms
> > >
> > > On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > > >
> > > > The global utilities block controls power management, I/O device
> > > > enabling, power-onreset(POR) configuration monitoring, alternate
> > > > function selection for multiplexed signals,and clock control.
> > > >
> > > > This patch adds a driver to manage and access global utilities
> block.
> > > > Initially only reading SVR and registering soc device are supported.
> > > > Other guts accesses, such as reading RCW, should eventually be
> > > > moved into this driver as well.
> > > >
> > > > Signed-off-by: Yangbo Lu
> > > > Signed-off-by: Scott Wood
> > > Don't put my signoff on patches that I didn't put it on myself.
> > > Definitely don't put mine *after* yours on patches that were last
> > > modified by you.
> > >
> > > If you want to mention that the soc_id encoding was my suggestion,
> > > then do so explicitly.
> > >
> > [Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
> > http://patchwork.ozlabs.org/patch/649211/
> >
> > So, let me just change the order in next version ?
> > Signed-off-by: Scott Wood
> > Signed-off-by: Yangbo Lu
>
> No. This isn't my patch so my signoff shouldn't be on it.
[Lu Yangbo-B47093] Ok, will remove it.
>
> > [Lu Yangbo-B47093] It's a good idea to move die into .family I think.
> > In my opinion, it's better to keep svr and name in soc_id just like
> > your suggestion above.
> > >
> > > {
> > > .soc_id = "svr:0x85490010,name:T1023E,",
> > > .family = "QorIQ T1024",
> > > }
> > The user probably don’t like to learn the svr value. What they want is
> > just to match the soc they use.
> > It's convenient to use name+rev for them to match a soc.
>
> What the user should want 99% of the time is to match the die (plus
> revision), not the soc.
>
> > Regarding shrinking the table, I think it's hard to use svr+mask.
> > Because I find many platforms use different masks.
> > We couldn’t know the mask according svr value.
>
> The mask would be part of the table:
>
> {
> {
> .die = "T1024",
> .svr = 0x8540,
> .mask = 0xfff0,
> },
> {
> .die = "T1040",
> .svr = 0x8520,
> .mask = 0xfff0,
> },
> {
> .die = "LS1088A",
> .svr = 0x8703,
> .mask = 0x,
> },
> ...
> }
>
> There's a small risk that we get the mask wrong and a different die is
> created that matches an existing table, but it doesn't seem too likely,
> and can e
RE: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
Hi Scott,
Thanks for your review :)
See my comment inline.
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Friday, September 09, 2016 11:47 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds a driver to manage and access global utilities block.
> > Initially only reading SVR and registering soc device are supported.
> > Other guts accesses, such as reading RCW, should eventually be moved
> > into this driver as well.
> >
> > Signed-off-by: Yangbo Lu <yangbo...@nxp.com>
> > Signed-off-by: Scott Wood <o...@buserror.net>
>
> Don't put my signoff on patches that I didn't put it on
> myself. Definitely don't put mine *after* yours on patches that were
> last modified by you.
>
> If you want to mention that the soc_id encoding was my suggestion, then
> do so explicitly.
>
[Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
http://patchwork.ozlabs.org/patch/649211/
So, let me just change the order in next version ?
Signed-off-by: Scott Wood <o...@buserror.net>
Signed-off-by: Yangbo Lu <yangbo...@nxp.com>
> > +/* SoC attribute definition for QorIQ platform */ static const struct
> > +soc_device_attribute qoriq_soc[] = { #ifdef CONFIG_PPC
> > + /*
> > + * Power Architecture-based SoCs T Series
> > + */
> > +
> > + /* SoC: T1024/T1014/T1023/T1013 Rev: 1.0 */
> > + { .soc_id = "svr:0x85400010,name:T1024,die:T1024",
> > + .revision = "1.0",
> > + },
> > + { .soc_id = "svr:0x85480010,name:T1024E,die:T1024",
> > + .revision = "1.0",
> > + },
>
> Revision could be computed from the low 8 bits of SVR (just as you do for
> unknown SVRs).
>
[Lu Yangbo-B47093] Yes, you're right. Will remove it here.
> We could move the die name into .family:
>
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
>
> I see you dropped svre (and the trailing comma), though I guess the vast
> majority of potential users will be looking at .family. In which case do
> we even need name? If we just make the soc_id be "svr:0x" then
> we could shrink the table to an svr+mask that identifies each die. I'd
> still want to keep the "svr:" even if we're giving up on the general
> tagging system, to make it clear what the number refers to, and to
> provide some defense against users who match only against soc_id rather
> than soc_id+family. Or we could go further and format soc_id as "QorIQ
> SVR 0x" so that soc_id-only matches are fully acceptable rather
> than just less dangerous.
[Lu Yangbo-B47093] It's a good idea to move die into .family I think.
In my opinion, it's better to keep svr and name in soc_id just like your
suggestion above.
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
The user probably don’t like to learn the svr value. What they want is just to
match the soc they use.
It's convenient to use name+rev for them to match a soc.
Regarding shrinking the table, I think it's hard to use svr+mask. Because I
find many platforms use different masks.
We couldn’t know the mask according svr value.
>
> > +static const struct soc_device_attribute *fsl_soc_device_match(
> > + unsigned int svr, const struct soc_device_attribute *matches) {
> > + char svr_match[50];
> > + int n;
> > +
> > + n = sprintf(svr_match, "*%08x*", svr);
>
> n = sprintf(svr_match, "svr:0x%08x,*", svr);
>
> (according to the current encoding)
>
[Lu Yangbo-B47093] Ok. Will do that.
> > +
> > + do {
> > + if (!matches->soc_id)
> > + ret
RE: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
Hi Scott,
Thanks for your review :)
See my comment inline.
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Friday, September 09, 2016 11:47 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds a driver to manage and access global utilities block.
> > Initially only reading SVR and registering soc device are supported.
> > Other guts accesses, such as reading RCW, should eventually be moved
> > into this driver as well.
> >
> > Signed-off-by: Yangbo Lu
> > Signed-off-by: Scott Wood
>
> Don't put my signoff on patches that I didn't put it on
> myself. Definitely don't put mine *after* yours on patches that were
> last modified by you.
>
> If you want to mention that the soc_id encoding was my suggestion, then
> do so explicitly.
>
[Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
http://patchwork.ozlabs.org/patch/649211/
So, let me just change the order in next version ?
Signed-off-by: Scott Wood
Signed-off-by: Yangbo Lu
> > +/* SoC attribute definition for QorIQ platform */ static const struct
> > +soc_device_attribute qoriq_soc[] = { #ifdef CONFIG_PPC
> > + /*
> > + * Power Architecture-based SoCs T Series
> > + */
> > +
> > + /* SoC: T1024/T1014/T1023/T1013 Rev: 1.0 */
> > + { .soc_id = "svr:0x85400010,name:T1024,die:T1024",
> > + .revision = "1.0",
> > + },
> > + { .soc_id = "svr:0x85480010,name:T1024E,die:T1024",
> > + .revision = "1.0",
> > + },
>
> Revision could be computed from the low 8 bits of SVR (just as you do for
> unknown SVRs).
>
[Lu Yangbo-B47093] Yes, you're right. Will remove it here.
> We could move the die name into .family:
>
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
>
> I see you dropped svre (and the trailing comma), though I guess the vast
> majority of potential users will be looking at .family. In which case do
> we even need name? If we just make the soc_id be "svr:0x" then
> we could shrink the table to an svr+mask that identifies each die. I'd
> still want to keep the "svr:" even if we're giving up on the general
> tagging system, to make it clear what the number refers to, and to
> provide some defense against users who match only against soc_id rather
> than soc_id+family. Or we could go further and format soc_id as "QorIQ
> SVR 0x" so that soc_id-only matches are fully acceptable rather
> than just less dangerous.
[Lu Yangbo-B47093] It's a good idea to move die into .family I think.
In my opinion, it's better to keep svr and name in soc_id just like your
suggestion above.
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
The user probably don’t like to learn the svr value. What they want is just to
match the soc they use.
It's convenient to use name+rev for them to match a soc.
Regarding shrinking the table, I think it's hard to use svr+mask. Because I
find many platforms use different masks.
We couldn’t know the mask according svr value.
>
> > +static const struct soc_device_attribute *fsl_soc_device_match(
> > + unsigned int svr, const struct soc_device_attribute *matches) {
> > + char svr_match[50];
> > + int n;
> > +
> > + n = sprintf(svr_match, "*%08x*", svr);
>
> n = sprintf(svr_match, "svr:0x%08x,*", svr);
>
> (according to the current encoding)
>
[Lu Yangbo-B47093] Ok. Will do that.
> > +
> > + do {
> > + if (!matches->soc_id)
> > + return NULL;
> > + if (glob_match(svr_match, matches->soc_id))
> > + break;
RE: [v11, 7/8] base: soc: introduce soc_device_match() interface
Hi Anrd and Uffe,
Thank you for your comment.
Please see my comment inline.
Best regards,
Yangbo Lu
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, September 06, 2016 8:46 PM
> To: Ulf Hansson
> Cc: Y.B. Lu; linux-mmc; Scott Wood; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; linux-...@vger.kernel.org;
> io...@lists.linux-foundation.org; net...@vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie
> Subject: Re: [v11, 7/8] base: soc: introduce soc_device_match() interface
>
> On Tuesday, September 6, 2016 1:44:23 PM CEST Ulf Hansson wrote:
> > On 6 September 2016 at 10:28, Yangbo Lu <yangbo...@nxp.com> wrote:
> > > We keep running into cases where device drivers want to know the
> > > exact version of the a SoC they are currently running on. In the
> > > past, this has usually been done through a vendor specific API that
> > > can be called by a driver, or by directly accessing some kind of
> > > version register that is not part of the device itself but that
> > > belongs to a global register area of the chip.
>
> Please add "From: Arnd Bergmann <a...@arndb.de>" as the first line, to
> preserve authorship. If you use "git send-email" or "git format-patch",
> that should happen automatically if the author field is set right (if not,
> use 'git commit --amend --author="Arnd Bergmann <a...@arndb.de>"'
> to fix it).
>
[Lu Yangbo-B47093] Oh, I'm sorry for my careless. Will correct it in next
version.
> > > +
> > > +/*
> > > + * soc_device_match - identify the SoC in the machine
> > > + * @matches: zero-terminated array of possible matches
> >
> > Perhaps also express the constraint on the matching entries. As you
> > need at least one of the ->machine(), ->family(), ->revision() or
> > ->soc_id() callbacks implemented, right!?
>
> They are not callbacks, just strings. Having an empty entry indicates the
> end of the array, and this is not called.
>
> > > + *
> > > + * returns the first matching entry of the argument array, or NULL
> > > + * if none of them match.
> > > + *
> > > + * This function is meant as a helper in place of of_match_node()
> > > + * in cases where either no device tree is available or the
> > > + information
> > > + * in a device node is insufficient to identify a particular
> > > + variant
> > > + * by its compatible strings or other properties. For new devices,
> > > + * the DT binding should always provide unique compatible strings
> > > + * that allow the use of of_match_node() instead.
> > > + *
> > > + * The calling function can use the .data entry of the
> > > + * soc_device_attribute to pass a structure or function pointer for
> > > + * each entry.
> >
> > I don't get the use case behind this, could you elaborate?
> >
> > Perhaps we should postpone adding the .data entry until we actually
> > see a need for it?
>
> I think the interface is rather useless without a way to figure out which
> entry you got. Almost all users of of_match_node() actually use the
> returned ->data field, and I expect this to be the same here.
>
> > > + */
> > > +const struct soc_device_attribute *soc_device_match(
> > > + const struct soc_device_attribute *matches) {
> > > + struct device *dev;
> > > + int ret;
> > > +
> > > + for (ret = 0; ret == 0; matches++) {
> >
> > This loop looks a bit weird and unsafe.
>
> Ah, and I thought I was being clever ;-)
>
> > 1) Perhaps using a while loop makes this more readable?
> > 2) As this is an exported API, I guess validation of the ->matches
> > pointer needs to be done before accessing it.
>
> Sounds fine.
[Lu Yangbo-B47093] Ok, Will change this according to Uffe.
And actually there is issue with this for() when I verified it again this
morning.
We will get matches++ rather than matches which is correct finally :)
>
> > > + if (!(matches->machine || matches->family ||
> > > + matches->revision || matches->soc_id))
> > > + return NULL;
> > > + dev = NULL;
> >
> > There's no need to use a struct device just to assign it to NULL.
> > Instead just provide the function below with NULL.
> >
> > > + ret = bus_for_each_dev(_bus_type, dev, (void
> *)matches,
> > > + soc_device_match_one);
>
>
> I don't remember what led to this, I think you are right, we should just
> pass NULL as most other callers.
[Lu Yangbo-B47093] Will correct it. Thanks. :)
>
> Thanks for the review.
>
> ARnd
RE: [v11, 7/8] base: soc: introduce soc_device_match() interface
Hi Anrd and Uffe,
Thank you for your comment.
Please see my comment inline.
Best regards,
Yangbo Lu
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, September 06, 2016 8:46 PM
> To: Ulf Hansson
> Cc: Y.B. Lu; linux-mmc; Scott Wood; linuxppc-...@lists.ozlabs.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-clk; linux-...@vger.kernel.org;
> io...@lists.linux-foundation.org; net...@vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie
> Subject: Re: [v11, 7/8] base: soc: introduce soc_device_match() interface
>
> On Tuesday, September 6, 2016 1:44:23 PM CEST Ulf Hansson wrote:
> > On 6 September 2016 at 10:28, Yangbo Lu wrote:
> > > We keep running into cases where device drivers want to know the
> > > exact version of the a SoC they are currently running on. In the
> > > past, this has usually been done through a vendor specific API that
> > > can be called by a driver, or by directly accessing some kind of
> > > version register that is not part of the device itself but that
> > > belongs to a global register area of the chip.
>
> Please add "From: Arnd Bergmann " as the first line, to
> preserve authorship. If you use "git send-email" or "git format-patch",
> that should happen automatically if the author field is set right (if not,
> use 'git commit --amend --author="Arnd Bergmann "'
> to fix it).
>
[Lu Yangbo-B47093] Oh, I'm sorry for my careless. Will correct it in next
version.
> > > +
> > > +/*
> > > + * soc_device_match - identify the SoC in the machine
> > > + * @matches: zero-terminated array of possible matches
> >
> > Perhaps also express the constraint on the matching entries. As you
> > need at least one of the ->machine(), ->family(), ->revision() or
> > ->soc_id() callbacks implemented, right!?
>
> They are not callbacks, just strings. Having an empty entry indicates the
> end of the array, and this is not called.
>
> > > + *
> > > + * returns the first matching entry of the argument array, or NULL
> > > + * if none of them match.
> > > + *
> > > + * This function is meant as a helper in place of of_match_node()
> > > + * in cases where either no device tree is available or the
> > > + information
> > > + * in a device node is insufficient to identify a particular
> > > + variant
> > > + * by its compatible strings or other properties. For new devices,
> > > + * the DT binding should always provide unique compatible strings
> > > + * that allow the use of of_match_node() instead.
> > > + *
> > > + * The calling function can use the .data entry of the
> > > + * soc_device_attribute to pass a structure or function pointer for
> > > + * each entry.
> >
> > I don't get the use case behind this, could you elaborate?
> >
> > Perhaps we should postpone adding the .data entry until we actually
> > see a need for it?
>
> I think the interface is rather useless without a way to figure out which
> entry you got. Almost all users of of_match_node() actually use the
> returned ->data field, and I expect this to be the same here.
>
> > > + */
> > > +const struct soc_device_attribute *soc_device_match(
> > > + const struct soc_device_attribute *matches) {
> > > + struct device *dev;
> > > + int ret;
> > > +
> > > + for (ret = 0; ret == 0; matches++) {
> >
> > This loop looks a bit weird and unsafe.
>
> Ah, and I thought I was being clever ;-)
>
> > 1) Perhaps using a while loop makes this more readable?
> > 2) As this is an exported API, I guess validation of the ->matches
> > pointer needs to be done before accessing it.
>
> Sounds fine.
[Lu Yangbo-B47093] Ok, Will change this according to Uffe.
And actually there is issue with this for() when I verified it again this
morning.
We will get matches++ rather than matches which is correct finally :)
>
> > > + if (!(matches->machine || matches->family ||
> > > + matches->revision || matches->soc_id))
> > > + return NULL;
> > > + dev = NULL;
> >
> > There's no need to use a struct device just to assign it to NULL.
> > Instead just provide the function below with NULL.
> >
> > > + ret = bus_for_each_dev(_bus_type, dev, (void
> *)matches,
> > > + soc_device_match_one);
>
>
> I don't remember what led to this, I think you are right, we should just
> pass NULL as most other callers.
[Lu Yangbo-B47093] Will correct it. Thanks. :)
>
> Thanks for the review.
>
> ARnd
