On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> The series provides one fix (patch 1) for GPIO to be able to wait for
> the GPIO driver to appear. This is separated from the conversion to
> the GPIO descriptors (patch 2) in order to have a possibility for
> backport
from something which has its own domain
At the same time convert users tree-wide to use new headers, although
for the time being include new header back to kernel.h to avoid twisted
indirected includes for existing users.
Signed-off-by: Andy Shevchenko
Reviewed-by: Bjorn Andersson
Acked-by
On Thu, Apr 08, 2021 at 09:57:12AM +, Flavio Suligoi wrote:
> > > > On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> > > > > The series provides one fix (patch 1) for GPIO to be able to wait for
> > > > > the GPIO driver to appear
On Tue, Mar 30, 2021 at 07:46:58AM +, Flavio Suligoi wrote:
> Hi Andy,
> ...
> > On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> > > The series provides one fix (patch 1) for GPIO to be able to wait for
> > > the GPIO driver to appear. This is
We have currently three users of the PSEC_PER_SEC each of them defining it
individually. Instead, move it to time64.h to be available for everyone.
There is a new user coming with the same constant in use. It will also
make its life easier.
Signed-off-by: Andy Shevchenko
Acked-by: Heiko
The PCI device IDs are defined with a prefix PCI_DEVICE_ID.
There is no need to repeat the ID part at the end of each definition.
Signed-off-by: Andy Shevchenko
---
.../net/ethernet/stmicro/stmmac/dwmac-intel.c | 60 +--
1 file changed, 30 insertions(+), 30 deletions(-)
diff
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> The series provides one fix (patch 1) for GPIO to be able to wait for
> the GPIO driver to appear. This is separated from the conversion to
> the GPIO descriptors (patch 2) in order to have a possibility for
> backport
y device (but this is an opposite,
what should we do on broken devices that do change their state based on that
bit while violating specification).
In any case
Acked-by: Andy Shevchenko
for DesignWare DMA case. I have added that and I never saw that IP connected
to the old PCI.
--
With Best Regards,
Andy Shevchenko
(different
base types)
.../pch_gbe_main.c:158:56:expected unsigned short [usertype] seqid
.../pch_gbe_main.c:158:56:got restricted __be16 [usertype]
Fix that by switching to use proper accessors to BE data.
Signed-off-by: Andy Shevchenko
---
.../ethernet/oki-semi/pch_gbe
Use readx_poll_timeout_atomic() instead of open coded variants.
While at it, add __iomem attribute to the parameter of pch_gbe_wait_clr_bit().
Signed-off-by: Andy Shevchenko
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 27 ++-
1 file changed, 8 insertions(+), 19
al meaning anymore.
Signed-off-by: Andy Shevchenko
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 2 --
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 2 ++
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c| 4
3 files changed, 2 insertions(+), 6 deletions(-)
di
This switches the PCH GBE driver to use GPIO descriptors.
Signed-off-by: Andy Shevchenko
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 45 +--
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
b/drivers
. Patch 5 is MODULE_VERSION() clean up.
Tested on Intel Minnowboard (v1).
Since v2:
- added a few cleanups on top of the fix
Andy Shevchenko (5):
net: pch_gbe: Propagate error from devm_gpio_request_one()
net: pch_gbe: Convert to use GPIO descriptors
net: pch_gbe: use readx_poll_timeout_atomic
If GPIO controller is not available yet we need to defer
the probe of GBE until provider will become available.
While here, drop GPIOF_EXPORT because it's deprecated and
may not be available.
Fixes: f1a26fdf5944 ("pch_gbe: Add MinnowBoard support")
Signed-off-by: Andy Shevchenk
On Wed, Mar 24, 2021 at 11:23:10PM +0200, Andy Shevchenko wrote:
> If GPIO controller is not available yet we need to defer
> the probe of GBE until provider will become available.
>
> While here, drop GPIOF_EXPORT because it's deprecated and
> may not be available.
I&#x
If GPIO controller is not available yet we need to defer
the probe of GBE until provider will become available.
While here, drop GPIOF_EXPORT because it's deprecated and
may not be available.
Fixes: f1a26fdf5944 ("pch_gbe: Add MinnowBoard support")
Signed-off-by: Andy Shevchenk
On Wed, Mar 17, 2021 at 11:36 AM Andy Shevchenko
wrote:
> On Wed, Mar 17, 2021 at 10:21 AM Menglong Dong
> wrote:
...
> It maybe fixed by swapping positions of the arguments, i.e. ~(FOO |
> BAR) & flags.
...and type casting will be needed anyway here...
I was thinking
On Wed, Mar 17, 2021 at 10:21 AM Menglong Dong wrote:
> On Wed, Mar 17, 2021 at 9:38 AM Guenter Roeck wrote:
> > On Wed, Mar 17, 2021 at 01:02:51AM +0200, Andy Shevchenko wrote:
> > > On Wednesday, March 17, 2021, Guenter Roeck wrote:
> > >
> ...
> &
On Thu, Mar 11, 2021 at 8:00 PM Calvin Johnson
wrote:
> On Thu, Mar 11, 2021 at 02:09:37PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 11, 2021 at 8:21 AM Calvin Johnson
> > wrote:
...
> > > +config FWNODE_MDIO
> > > + def_tristate PHYLIB
> >
>
t acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle
> *fwnode);
> +#else /* CONFIG_ACPI_MDIO */
> +static inline int acpi_mdiobus_register(struct mii_bus *mdio, struct
> fwnode_handle *fwnode)
> +{
> + /*
> +* Fall back to mdiobus_register() function to register a bus.
> +* This way, we don't have to keep compat bits around in drivers.
> +*/
> +
> + return mdiobus_register(mdio);
> +}
> +#endif
> +
> +#endif /* __LINUX_ACPI_MDIO_H */
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 11, 2021 at 8:22 AM Calvin Johnson
wrote:
>
> Introduce a wrapper around the _ADR evaluation.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Replace fwnode_get_id()
truct mii_bus *of_mdio_find_bus(struct device_node
> *mdio_np);
> int of_phy_register_fixed_link(struct device_node *np);
> void of_phy_deregister_fixed_link(struct device_node *np);
> bool of_phy_is_fixed_link(struct device_node *np);
> +struct mii_timestamper *of_find_mii_timestamper(struct device_node *np);
> int of_mdiobus_phy_device_register(struct mii_bus *mdio, struct phy_device
> *phy,
>struct device_node *child, u32 addr);
>
> @@ -118,7 +119,10 @@ static inline bool of_phy_is_fixed_link(struct
> device_node *np)
> {
> return false;
> }
> -
> +static inline struct mii_timestamper *of_find_mii_timestamper(struct
> device_node *np)
> +{
> + return NULL;
> +}
> static inline int of_mdiobus_phy_device_register(struct mii_bus *mdio,
> struct phy_device *phy,
> struct device_node *child, u32
> addr)
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 11, 2021 at 8:21 AM Calvin Johnson
wrote:
>
> Callers of unregister_mii_timestamper() currently check for NULL
> value of mii_ts before calling it.
>
> Place the NULL check inside unregister_mii_timestamper() and update
> the callers accordingly
FWIW,
Reviewed-b
ease
(v5.11) till the first rc of the new cycle (v5.12-rc1).
Now we are more than a week after v5.12-rc1.
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 8, 2021 at 6:28 PM Calvin Johnson
wrote:
> On Mon, Mar 08, 2021 at 04:57:35PM +0200, Andy Shevchenko wrote:
> I thought of including device.h instead of dev_printk.h because, it is the
> only file that includes dev_printk.h and device.h is widely used. Of course,
>
On Mon, Mar 8, 2021 at 4:11 PM Calvin Johnson
wrote:
> On Thu, Feb 18, 2021 at 05:08:05PM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 18, 2021 at 7:28 AM Calvin Johnson
> > wrote:
> > > Define acpi_mdiobus_register() to Register mii_bus and create PHYs for
&g
> On Feb 24, 2021, at 12:03 AM, wanghongzhe wrote:
>
> As Kees haved accepted the v2 patch at a381b70a1 which just
> replaced rmb() with smp_rmb(), this patch will base on that and just adjust
> the smp_rmb() to the correct position.
>
> As the original comment shown (and indeed it should be)
v_printk.h
module.h
types.h
The rest seems fine because they are guaranteed to be included by
acpi.h (IIUC about fwnode API and acpi_mdio includes MDIO PHY APIs).
--
With Best Regards,
Andy Shevchenko
node_handle_put(dpmac_node);
> + if (is_of_node(dpmac_node))
> + fwnode_handle_put(dpmac_node);
Also not sure that you need a check in the above code excerpts.
--
With Best Regards,
Andy Shevchenko
. A
> +* mii_timestamper probed via the device tree will still have
> +* precedence.
> +*/
> + if (mii_ts)
> + phy->mii_ts = mii_ts;
I'm wondering if the belo form is better to read
phy->mii_ts = mii_ts ?: phy->mii_ts;
--
With Best Regards,
Andy Shevchenko
definition (maybe somewhere under
printk) and export to everybody to use.
--
With Best Regards,
Andy Shevchenko
WHENCE.
>
> The alternative is to leave firmwares in place with CVEs.
Good, thanks, I haven't looked into that script.
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko
> wrote:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helpers under string.h hood
On Mon, Feb 15, 2021 at 5:13 PM Andy Shevchenko
wrote:
>
> On Mon, Feb 15, 2021 at 2:33 PM Calvin Johnson
> wrote:
> > On Mon, Feb 08, 2021 at 04:28:31PM +, Russell King - ARM Linux admin
> > wrote:
>
> ...
>
> > I think of_phy_is_fixed_link() n
es being NULL below.
> /* New binding */
> dn = of_get_child_by_name(np, "fixed-link");
> if (dn) {
--
With Best Regards,
Andy Shevchenko
+Cc: Sakari and printk people
On Mon, Feb 15, 2021 at 4:28 PM Christian König
wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helper
long as it's needed. Alternative solution is
to provide the links during installation.
Btw, I haven't seen the driver change for that. Care to provide a
commit ID in upstream?
--
With Best Regards,
Andy Shevchenko
We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_utils.h | 5 -
include/linux/string.h| 5 +
2 files changed, 5 insertions(+), 5 deletions
We have already few similar implementation and a lot of code that can benefit
of the yesno() helper. Consolidate yesno() helpers under string.h hood.
Signed-off-by: Andy Shevchenko
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c| 6 +-
drivers/gpu/drm/i915/i915_utils.h
We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_utils.h | 5 -
include/linux/string.h| 5 +
2 files changed, 5 insertions(+), 5
rn child;
> + }
...
> + if (is_of_node(dev->parent->fwnode))
Ditto ?
> + of_node_put(dpmacs);
--
With Best Regards,
Andy Shevchenko
/* CONFIG_ACPI_MDIO */
> +static inline int acpi_mdiobus_register(struct mii_bus *mdio, struct
> fwnode_handle *fwnode)
> +{
> + /*
> +* Fall back to mdiobus_register() function to register a bus.
> +* This way, we don't have to keep compat bits around in drivers.
> +*/
> +
> + return mdiobus_register(mdio);
> +}
> +#endif
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 5, 2021 at 8:41 PM Andy Shevchenko
wrote:
> On Fri, Feb 5, 2021 at 8:25 PM Andy Shevchenko
> wrote:
> > On Fri, Feb 5, 2021 at 7:25 PM Calvin Johnson
> > wrote:
> > > On Fri, Jan 22, 2021 at 09:12:52PM +0530, Calvin Johnson wrote:
>
On Fri, Feb 5, 2021 at 8:25 PM Andy Shevchenko
wrote:
> On Fri, Feb 5, 2021 at 7:25 PM Calvin Johnson
> wrote:
> > On Fri, Jan 22, 2021 at 09:12:52PM +0530, Calvin Johnson wrote:
>
> ...
>
> > > + rc = fwnode_property_match_string(child, "compatible&q
rnet-phy-ieee802.3-c45"}
>}
> })
> } // end of PHY4
>
> What is see is that in acpi_data_get_property(),
> propvalue->type = 0x2(ACPI_TYPE_STRING) and type = 0x4(ACPI_TYPE_PACKAGE).
>
> Any help please?
>
> fwnode_property_match_string() works fine for DT.
C
> On Feb 1, 2021, at 4:06 AM, wanghongzhe wrote:
>
> If a thread(A)'s TSYNC flag is set from seccomp(), then it will
> synchronize its seccomp filter to other threads(B) in same thread
> group. To avoid race condition, seccomp puts rmb() between
> reading the mode and filter in seccomp check
u may not need the fwnode_get_local_addr() at all then, just
> evaluate either the "reg" property for OF or acpi_get_local_address()
> for ACPI in the "caller" code directly. A common helper doing this can
> be added later.
Sounds good to me and it will address your concern about different
semantics of reg/_ADR on per driver/subsystem basis.
--
With Best Regards,
Andy Shevchenko
ou have to discover a full firmware image to make
any assumptions about CPU ISA used there and address mapping.
--
With Best Regards,
Andy Shevchenko
low level that ops
suits best for them and quite different resource types like GPIO. And
the latter is closer to certain framework rather than to POD handling
cases.
> So fwnode_ops->get_id() would be the OP ACPI and OF would implement.
> And then we can have a wrapper in drivers/base/property.c.
--
With Best Regards,
Andy Shevchenko
f years. And I have no idea where to put a common base for
them so they will not duplicate this in each case.
> so maybe put this function somewhere closer to the code that's going
> to use it, because it seems to be kind of specific to this particular
> use case?
--
With Best Regards,
Andy Shevchenko
t; + if (ACPI_FAILURE(status))
> + return -EINVAL;
> + *id = (u32)adr;
> +#else
> + return ret;
> +#endif
> + }
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 20, 2021 at 8:18 PM Rafael J. Wysocki wrote:
> On Tue, Jan 12, 2021 at 4:47 PM Andy Shevchenko
> wrote:
> > On Tue, Jan 12, 2021 at 3:42 PM Calvin Johnson
> > wrote:
...
> > > +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id)
> &g
On Wed, Jan 20, 2021 at 8:18 PM Rafael J. Wysocki wrote:
> On Tue, Jan 12, 2021 at 7:02 PM Andy Shevchenko
> wrote:
> > On Tue, Jan 12, 2021 at 09:30:31AM -0800, Saravana Kannan wrote:
> > > On Tue, Jan 12, 2021 at 5:42 AM Calvin Johnson
> > > wr
tually exclusive if I'm not mistaken.
That's why we try 'reg' property for both cases first.
is_acpi_fwnode() conditional is that what I don't like though.
...
> fwnode is lower level that the device-driver framework.
Agree.
> Making
> it aware of busses like mdio, etc doesn't sound right.
Disagree. Conceptually resource providers can be quite different and fwnode API
*is* LCM for them.
--
With Best Regards,
Andy Shevchenko
On Tue, Jan 12, 2021 at 3:43 PM Calvin Johnson
wrote:
>
> Refactor phylink_of_phy_connect() to use phylink_fwnode_phy_connect().
Same Q as per previous patch. If it's indeed a bug in the existing
code, should be fixed in a separate patch
--
With Best Regards,
Andy Shevchenko
here?
> + return ret;
--
With Best Regards,
Andy Shevchenko
v->has_a011043 = device_property_read_bool(&pdev->dev,
> "fsl,erratum-a011043");
> -
Unrelated change.
--
With Best Regards,
Andy Shevchenko
n acpi_mdiobus_register(mdio, fwnode);
> +
> + return -EINVAL;
> +}
--
With Best Regards,
Andy Shevchenko
ode_handle *fwnode,
>
> const char *fwnode_get_name(const struct fwnode_handle *fwnode);
> const char *fwnode_get_name_prefix(const struct fwnode_handle *fwnode);
> +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id);
> struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode);
> struct fwnode_handle *fwnode_get_next_parent(
> struct fwnode_handle *fwnode);
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
We have currently three users of the PSEC_PER_SEC each of them defining it
individually. Instead, move it to time64.h to be available for everyone.
There is a new user coming with the same constant in use. It will also
make its life easier.
Signed-off-by: Andy Shevchenko
---
drivers/net
On Fri, Dec 18, 2020 at 7:40 AM Calvin Johnson
wrote:
> On Tue, Dec 15, 2020 at 07:53:26PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> > wrote:
...
> > I would rather see this as simple as
> >
> > if (is_of_node(f
On Fri, Dec 18, 2020 at 7:34 AM Calvin Johnson
wrote:
>
> On Tue, Dec 15, 2020 at 07:33:40PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> > wrote:
...
> > > + /* phy->mii_ts may already b
On Thu, Dec 17, 2020 at 10:28 AM Calvin Johnson
wrote:
> On Tue, Dec 15, 2020 at 07:28:10PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> > wrote:
...
> > > + if (sscanf(cp, "ethernet-phy-id%4x.%4x", &uppe
of MDIO controller
> need to be specified using "little-endian" property.
...
> @@ -2,6 +2,7 @@
> * QorIQ 10G MDIO Controller
> *
> * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2020 NXP
> *
> * Authors: Andy Fleming
> *
p;mdio->dev,
> + "MDIO device at address %lld is
> missing.\n",
> + addr);
> + }
> + return 0;
> + }
> + return -EINVAL;
> +}
--
With Best Regards,
Andy Shevchenko
EINVAL in all error cases ? Or maybe different
> error codes to mean "the backend doesn't support the concept of IDs",
> and "the device doesn't have an ID" ?
We may actually get mapping to all three if first we check for the
method/name existence followed by value check.
But I don't think we need to bloat this simple one.
> > + *id = (u32)adr;
> > + return 0;
> > + }
> > + return -EINVAL;
> > +}
--
With Best Regards,
Andy Shevchenko
I'm wondering if it compiles when CONFIG_ACPI=n.
> + *id = (u32)adr;
> + return 0;
> + }
> + return -EINVAL;
> +}
--
With Best Regards,
Andy Shevchenko
PHY driver. A
> +* mii_timestamper probed via the device tree will still have
> + * precedence.
> +*/
> + if (mii_ts)
> + phy->mii_ts = mii_ts;
How is that defined? Do you need to do something with an old pointer?
> + }
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
= 2)
return -EINVAL;
*phy_id = ((upper & 0x) << 16) | (lower & 0x);
return 0;
And perhaps GENMASK() ?
--
With Best Regards,
Andy Shevchenko
) || !IS_ERR(phy_node))
> + return phy_node;
So, what is the problem with going through the rest on ACPI?
Usually we describe the restrictions in the documentation.
--
With Best Regards,
Andy Shevchenko
On Sat, Dec 12, 2020 at 12:07 AM Thomas Gleixner wrote:
>
> On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
>
> > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
> >
> >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner
> >> wrote:
> >
;line,
> + line + irq_first,
>num_interrupts[line],
>num_wake_interrupts[line]);
--
With Best Regards,
Andy Shevchenko
dif
--
With Best Regards,
Andy Shevchenko
On Wed, Dec 9, 2020 at 12:59 PM Andy Shevchenko
wrote:
> On Wed, Dec 9, 2020 at 10:35 AM Heiner Kallweit wrote:
...
> > -int pci_try_set_mwi(struct pci_dev *dev)
> > -{
>
> > -#ifdef PCI_DISABLE_MWI
> > - return 0;
> > -#else
> > - ret
y want to elaborate here that the feature is specific to
PCI and isn't present on PCIe.
Besides that one comment below.
After addressing, have my
Reviewed-by: Andy Shevchenko
for the files left in this message.
...
> drivers/dma/dw/pci.c | 2 +-
> drivers/dma/hs
hese kind of chips,
these -> this
OR
kind -> kinds
> let's make the firmware GPIO optional.
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Frieder Schrempf
>
> ---
> Changes in v2:
> * Remove unneeded null check for phy->gpiod_fw
> ---
> D
hese kind of chips,
> let's make the firmware GPIO optional.
...
> - gpiod_set_value(phy->gpiod_fw, (mode == NXP_NCI_MODE_FW) ? 1 : 0);
> + if (phy->gpiod_fw)
> + gpiod_set_value(phy->gpiod_fw, (mode == NXP_NCI_MODE_FW) ? 1
> : 0);
This cha
ually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.
--
With Best Regards,
Andy Shevchenko
From: Kegl Rohit Sent: Sunday, November 15, 2020 1:37 AM
> On Sat, Nov 14, 2020 at 2:58 AM Andy Duan wrote:
> >
> > From: Kegl Rohit Sent: Friday, November 13, 2020
> > 8:21 PM
> > > On Fri, Nov 13, 2020 at 8:33 AM Kegl Rohit wrote:
> > > >
> >
uld this cause a different caching/flushing behaviour?
>
> Yes, after tests I think it is caused by the disabled CMA.
>
> @Andy
> I could find this mail and the attached "i.MX6 dma memory bufferable
> issue.pptx" in the archive
> https://eur01.safelinks.protection
; The application might want to implement some flow control to ensure the
> line-rate burst traffic is below 400 Mbps if it only uses consecutive small
> frames
> with minimal
> (96 bit times) or short
> Inter-frame gap (IFG) time following large frames at such a high rate.
> The limit does not exist for
> frames of size larger than 800 bytes.
> Proposed Solution:
> No fix scheduled
> Linux BSP Status:
> Workaround possible but not implemented in the BSP, impacting functionality as
> described above.
>
> Is the "ENET Status FIFO" some internal hardware FIFO or is it the descriptor
> ring.
> What would be the workaround when a "Workaround is possible"?
>
> I could only think of skipping/dropping the descriptor when the current is
> still
> busy but the next one is ready.
> But it is not easily possible because the "stuck" descriptor gets ready after
> a
> huge delay.
>
> Is this issue known already? Any suggestions?
>
We don't see the issue.
Yes, the IP has the errata on i.MX6Q, so the workaround is to enable HW flow
control.
Keep HW flow control is enabled on your networking connection to avoid FIFO
overrun happen.
Regards,
Andy
>
> Thanks in advance
E_MASK;
> + spi->mode |= SPI_MODE_0;
?
--
With Best Regards,
Andy Shevchenko
.org%2Flkml%2F2020%2F6%2F14%2F76&data=04%7C01%7Cfugang.dua
> n%40nxp.
> >
> com%7Ceaef5020d1c143dfda5208d8845a6391%7C686ea1d3bc2b4c6fa92cd99
> c5c301
> >
> 635%7C0%7C0%7C637404871050135426%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wL
> >
> jAwMDAiLCJQIjoiV2luMzIiLCJB
quot;net: fec: Ensure clocks are enabled while using mdio
> bus")
> Signed-off-by: Zhang Qilong
>From early discussion for the topic, Wolfram Sang wonder if such de-reference
>can
be better handled by pm runtime core code.
https://lkml.org/lkml/2020/6/14/76
Regards,
Andy
> -
y voice here is to ignore for the same reasons: respect
realloc(3) and making common sense with the idea of REallocating
(capital letters on purpose).
--
With Best Regards,
Andy Shevchenko
array(fences, i,
> + sizeof(*fences), GFP_KERNEL);
On 80 position is closing parenthesis, which, I think, makes it okay to put on
one line.
--
With Best Regards,
Andy Shevchenko
gt; value of this parameter depending on the chip id (88W8897) or DMI matching.
Since it's a PCIe device you already have ID table where you may add a
driver_data with what ever quirks are needed.
--
With Best Regards,
Andy Shevchenko
have available in Linux.
--
With Best Regards,
Andy Shevchenko
From: Greg Ungerer Sent: Wednesday, October 28, 2020 1:23
PM
> Some (apparently older) versions of the FEC hardware block do not like the
> MMFR register being cleared to avoid generation of MII events at
> initialization
> time. The action of clearing this register results in no future MII even
Refactor phy_led_trigger_register() and deduplicate its functionality
when registering LED trigger for link.
Signed-off-by: Andy Shevchenko
Reviewed-by: Andrew Lunn
---
v3: rebased on top of v5.10-rc1
drivers/net/phy/phy_led_triggers.c | 15 +--
1 file changed, 5 insertions(+), 10
From: Greg Ungerer Sent: Tuesday, October 27, 2020 8:18 AM
> Hi Andy,
>
> On 22/10/20 7:04 pm, Andy Duan wrote:
> > From: Greg Ungerer Sent: Thursday, October 22,
> > 2020 9:14 AM
> >> Hi Andrew,
> >>
> >> On 21/10/20 11:37 pm
n my ColdFire test target I always get a timeout if I wait for a
> FEC_IEVENT after the FEC_MII_SPEED write.
>
> Regards
> Greg
Dave Karr's last patch can fix the issue, but it may introduce 30ms delay
during boot.
Greg's patch is to add quirk flag to distinguish platform before clearing mmfr
operation,
which also can fix the issue.
Andy
From: Greg Ungerer Sent: Thursday, October 22, 2020 9:14
AM
> Hi Andrew,
>
> On 21/10/20 11:37 pm, Andrew Lunn wrote:
> >> +if (fep->quirks & FEC_QUIRK_CLEAR_SETUP_MII) {
> >> +/* Clear MMFR to avoid to generate MII event by writing
> MSCR.
> >> + * MII event generati
the discussion fizzled out without a
> > final patch fixing the issue. NXP suggested this
> >
> > writel(0, fep->hwp + FEC_MII_DATA);
> >
> > Without it, some other FEC variants break because they do generate an
> > interrupt at the wrong time causing all following MDIO transactions to
> > fail.
> >
> > At the moment, we don't seem to have a clear understanding of the
> > different FEC versions, and how their MDIO implementations vary.
>
> Based on Andy and Chris' comments is something like the attached patch what
> we need?
Greg, imx28 platform also requires the flag.
>
> Regards
> Greg
>
From: Chris Healy Sent: Tuesday, October 20, 2020 9:07 PM
> On Mon, Oct 19, 2020 at 8:02 PM Andy Duan wrote:
> >
> > From: Andrew Lunn Sent: Tuesday, October 20, 2020
> > 10:40 AM
> > > On Tue, Oct 20, 2020 at 12:14:04PM +1000, Greg Ungerer wrote:
> > &
ransactions to fail.
>
> At the moment, we don't seem to have a clear understanding of the different
> FEC versions, and how their MDIO implementations vary.
>
> Andrew
Andrew, different varants has little different behavior, so the line is
required for
Imx6/7/7 platforms but should be removed in imx5 and ColdFire.
As we discuss one solution to resolve the issue, but it bring 30ms latency for
kernel boot.
Now, I want to revert the polling mode to original interrupt mode, do you agree
?
Andy
> On Sun, Oct 11, 2020 at 08:54:38AM -0700, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > The clang build reports this warning
> >
> > fw.c:1485:21: warning: address of array 'rtwdev->chip->fw_fifo_addr'
> > will always evaluate to 'true'
> > if (!rtwdev->chip->fw_fifo_addr) {
> >
>
shared already.
[1]:
https://lore.kernel.org/linux-iio/20200824054347.3805-1-william.s...@advantech.com.tw/T/#m5f61921fa67a5b40522b7f7b17216e0d204647be
...
> - of_node_put(dpmac_node);
> + if (is_of_node(dpmac_node))
> + of_node_put(to_of_node(dpmac_node));
I'm not sure why you can't use fwnode_handle_put()?
> + if (is_of_node(dpmac_node))
> + of_node_put(to_of_node(dpmac_node));
Ditto.
--
With Best Regards,
Andy Shevchenko
On Tue, Sep 29, 2020 at 5:32 PM Andrew Lunn wrote:
>
> On Tue, Sep 29, 2020 at 04:55:40PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 29, 2020 at 4:43 PM Andrew Lunn wrote:
> > > On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
> > > > On Fri,
understand the newbie part, but can you elaborate what did you mean
under 'support'?
To me it sounds like 'network stack was developed for BE CPUs, does it
support LE ones?'
--
With Best Regards,
Andy Shevchenko
1 - 100 of 1695 matches
Mail list logo
