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
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
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
bool(&pdev->dev,
> "fsl,erratum-a011043");
...this...
> -
...and this changes can go to a separate patch.
--
With Best Regards,
Andy Shevchenko
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
E_MASK;
> + spi->mode |= SPI_MODE_0;
?
--
With Best Regards,
Andy Shevchenko
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
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
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
_disable_unprepare() in
> intel_eth_pci_remove().
Thanks! I'm not sure how I missed this...
Reviewed-by: Andy Shevchenko
> Fixes: 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove
> paths")
> Cc: Andy Shevchenko
> Reviewed-by: Voon Weifeng
>
On Wed, Aug 26, 2020 at 06:22:23PM +0300, Andy Shevchenko wrote:
> Refactor phy_led_trigger_register() and deduplicate its functionality
> when registering LED trigger for link.
Is it good enough now?
> Signed-off-by: Andy Shevchenko
> Reviewed-by: Andrew Lunn
> ---
> v2:
On Thu, Sep 10, 2020 at 11:25 AM Vadym Kochan wrote:
> On Fri, Sep 04, 2020 at 10:12:07PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 4, 2020 at 7:52 PM Vadym Kochan
> > wrote:
> > > + .param = {.admin_state = admin_state}
> >
> > + white
On Wed, Sep 9, 2020 at 5:00 PM Vadym Kochan wrote:
> On Tue, Sep 08, 2020 at 12:38:04PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 8, 2020 at 11:35 AM Vadym Kochan
> > wrote:
> > > On Fri, Sep 04, 2020 at 10:12:07PM +0300, Andy Shevchenko wrote:
> > > >
On Tue, Sep 8, 2020 at 11:35 AM Vadym Kochan wrote:
> On Fri, Sep 04, 2020 at 10:12:07PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 4, 2020 at 7:52 PM Vadym Kochan
> > wrote:
...
> > > + words[3] |= FIELD_PREP(PRESTERA_W3_HW_DEV_NUM, (dsa->hw_dev_num
On Mon, Sep 7, 2020 at 10:30 AM Vadym Kochan wrote:
> On Fri, Sep 04, 2020 at 10:12:07PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 4, 2020 at 7:52 PM Vadym Kochan
> > wrote:
I'm assuming that you agree on all non-commented.
...
> > > +#define prestera_dev
e are some limitations like:
>
> - Only 1 VLAN-aware bridge instance supported
> - FDB ageing timeout parameter is set globally per device
Similar comments as per previous patches.
> + struct list_head vlans_list;
How this container is being protected against races?
--
With Best Regards,
Andy Shevchenko
a_hw_mdix_from_eth(u8 mode)
> +{
> + switch (mode) {
> + case ETH_TP_MDI:
> + return PRESTERA_PORT_TP_MDI;
> + case ETH_TP_MDI_X:
> + return PRESTERA_PORT_TP_MDIX;
> + case ETH_TP_MDI_AUTO:
> + return PRESTERA_PORT_TP_AUTO;
> + }
> +
> + return PRESTERA_PORT_TP_NA;
> +}
Ditto.
...
> +enum {
> + PRESTERA_PORT_DUPLEX_HALF,
> + PRESTERA_PORT_DUPLEX_FULL
Comma ?
> +};
--
With Best Regards,
Andy Shevchenko
> + release_firmware(f);
> + return err;
goto out_release; ?
> + }
> +
> + prestera_ldr_write(fw, PRESTERA_LDR_IMG_SIZE_REG, f->size - hlen);
> + prestera_ldr_write(fw, PRESTERA_LDR_CTL_REG,
> PRESTERA_LDR_CTL_DL_START);
> +
> + dev_info(fw->dev.dev, "Loading %s ...", fw_path);
> +
> + err = prestera_ldr_fw_send(fw, f->data + hlen, f->size - hlen);
out_release: ?
> + release_firmware(f);
> + return err;
--
With Best Regards,
Andy Shevchenko
buf->desc_dma);
> +
> + if (b == PRESTERA_SDMA_TX_DESC_PER_Q - 1)
> + prestera_sdma_tx_desc_set_next(sdma, buf->desc,
> + head->desc_dma);
> + }
Similar comments as per above similar for-loop.
...
> +static int prestera_sdma_tx_wait(struct prestera_sdma *sdma,
> +struct prestera_tx_ring *tx_ring)
> +{
> + int tx_retry_num = PRESTERA_SDMA_WAIT_MUL * tx_ring->max_burst;
> +
> + do {
> + if (prestera_sdma_is_ready(sdma))
> + return 0;
> +
> + udelay(1);
> + } while (--tx_retry_num);
> +
> + return -EBUSY;
> +}
iopoll.h
readx_poll_timeout().
...
> +/*
> + * Copyright (c) 2019-2020 Marvell International Ltd. All rights reserved.
> + *
> + */
One line.
...
> +#include "prestera.h"
I don't see users of the above header here. You may use declarations instead.
> +int prestera_rxtx_switch_init(struct prestera_switch *sw);
> +void prestera_rxtx_switch_fini(struct prestera_switch *sw);
> +
> +int prestera_rxtx_port_init(struct prestera_port *port);
> +
> +netdev_tx_t prestera_rxtx_xmit(struct prestera_port *port, struct sk_buff
> *skb);
--
With Best Regards,
Andy Shevchenko
v->dev_addr, addr->sa_data, dev->addr_len);
>
> Is addr_len ever not ETH_ALEN for this device?
And if it is ETH_ALEN, here is [3].
[3]:
https://elixir.bootlin.com/linux/latest/source/include/linux/etherdevice.h#L287
--
With Best Regards,
Andy Shevchenko
e *tbl,
> if (!mask)
> continue;
>
> - flow = masked_flow_lookup(ti, match->key, mask, &n_mask_hit);
> + flow = masked_flow_lookup(ti, match->key, mask, NULL);
> if (flow && ovs_identifier_is_key(&flow->id) &&
> ovs_flow_cmp_unmasked_key(flow, match)) {
> return flow;
> --
> 2.18.1
>
--
With Best Regards,
Andy Shevchenko
On Tue, Aug 25, 2020 at 07:40:15AM -0700, David Miller wrote:
> From: Andy Shevchenko
> Date: Mon, 24 Aug 2020 20:09:04 +0300
>
> > Refactor phy_led_trigger_register() and deduplicate its functionality
> > when registering LED trigger for link.
> >
> > Signed
On Mon, Aug 24, 2020 at 07:45:58PM +0200, Andrew Lunn wrote:
> On Mon, Aug 24, 2020 at 08:09:04PM +0300, Andy Shevchenko wrote:
> > Refactor phy_led_trigger_register() and deduplicate its functionality
> > when registering LED trigger for link.
> >
> > Sig
Refactor phy_led_trigger_register() and deduplicate its functionality
when registering LED trigger for link.
Signed-off-by: Andy Shevchenko
---
drivers/net/phy/phy_led_triggers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy
1 - 100 of 495 matches
Mail list logo
