On Fri, Sep 24, 2021 at 02:44:46PM -0700, Justin Chen wrote:
> This patch set adds support for Broadcom's ASP 2.0 Ethernet controller.
Hi Justin
Does the hardware support L2 switching between the two ports? I'm just
wondering if later this is going to be modified into a switchdev
driver?
> +static int bcmasp_probe(struct platform_device *pdev)
> +{
> + struct bcmasp_priv *priv;
> + struct device_node *ports_node, *intf_node;
> + struct device *dev = &pdev->dev;
> + int ret, i, wol_irq, count = 0;
> + struct bcmasp_intf *intf;
> + struct resource *r;
> +
> > > +static int bcmasp_set_priv_flags(struct net_device *dev, u32 flags)
> > > +{
> > > + struct bcmasp_intf *intf = netdev_priv(dev);
> > > +
> > > + intf->wol_keep_rx_en = flags & BCMASP_WOL_KEEP_RX_EN ? 1 : 0;
> > > +
> > > + return 0;
> >
> > Please could you explain this some more. How can
> .../bindings/display/hpe,gxp-thumbnail.txt| 21 +
> .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 +
> .../devicetree/bindings/i2c/hpe,gxp-i2c.txt | 19 +
> .../bindings/ipmi/hpegxp-kcs-bmc-cfg.txt | 13 +
> .../bindings/ipmi/hpegxp-kcs-bmc.txt | 21 +
Hi Nick
In a
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> It's normal to list all linux/ includes before asm/ includes. Please
> rearrange.
Hi Nick
Since you are new to the kernel, please let me point out, you should
consider Russell comments fo
On Tue, Feb 11, 2020 at 10:41:20PM +0100, H. Nikolaus Schaller wrote:
> This is needed to give the MIPS Ingenic CI20 board a stable MAC address
> which can be optionally provided by vendor U-Boot.
>
> For get_mac_addr() we use an adapted copy of from ksz884x.c which
> has very similar functionalit
On Tue, Apr 18, 2023 at 05:10:15PM -0700, Justin Chen wrote:
> Add support for the Broadcom ASP 2.0 Ethernet controller which is first
> introduced with 72165. This controller features two distinct Ethernet
> ports that can be independently operated.
>
> This patch supports:
>
> - Wake-on-LAN usi
On Tue, Apr 18, 2023 at 05:10:16PM -0700, Justin Chen wrote:
> Add mdio compat string for ASP 2.0 ethernet driver.
>
> Signed-off-by: Justin Chen
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
d-off-by: Justin Chen
Reviewed-by: Andrew Lunn
Andrew
On Wed, Jun 21, 2023 at 01:45:56PM +0800, Evan Quan wrote:
> From: Mario Limonciello
>
> Due to electrical and mechanical constraints in certain platform designs
> there may be likely interference of relatively high-powered harmonics of
> the (G-)DDR memory clocks with local radio module frequenc
> > Do only ACPI based systems have:
> >
> >interference of relatively high-powered harmonics of the (G-)DDR
> >memory clocks with local radio module frequency bands used by
> >Wifi 6/6e/7."
> >
> > Could Device Tree based systems not experience this problem?
>
> They could, of cours
> I think there is enough details for this to happen. It's done
> so that either the AML can natively behave as a consumer or a
> driver can behave as a consumer.
> > > > > +/**
> > > > > + * APIs needed by drivers/subsystems for contributing frequencies:
> > > > > + * During probe, check `wbrf_su
On Wed, Jun 21, 2023 at 11:15:00AM -0500, Limonciello, Mario wrote:
>
> On 6/21/2023 10:39 AM, Johannes Berg wrote:
> > On Wed, 2023-06-21 at 17:36 +0200, Andrew Lunn wrote:
> > > On Wed, Jun 21, 2023 at 01:45:56PM +0800, Evan Quan wrote:
> > > > From: Mario Lim
> Think a little more about what a non-ACPI implementation
> would look like:
>
> 1) Would producers and consumers still need you to set CONFIG_ACPI_WBRF?
I would expect there to be an CONFIG_WBRF, and then under that a
CONFIG_WBRF_ACPI, CONFIG_WBRF_DT, CONFIG_WBRF_FOOBAR, each indicating
they ar
> I think what you're asking for is another layer of indirection
> like CONFIG_WBRF in addition to CONFIG_ACPI_WBRF.
>
> Producers would call functions like wbrf_supported_producer()
> where the source file is not guarded behind CONFIG_ACPI_WBRF,
> but instead by CONFIG_WBRF and locally use CONFIG
> And consumer would need to call it, but only if CONFIG_WBRF_ACPI isn't set.
Why? How is ACPI special that it does not need notifiers?
> I don't see why it couldn't be a DT/ACPI hybrid solution for ARM64.
As said somewhere else, nobody does hybrid. In fact, turn it
around. Why not implement all
> ACPI core does has notifiers that are used, but they don't work the same.
> If you look at patch 4, you'll see amdgpu registers and unregisters using
> both
>
> acpi_install_notify_handler()
> and
> acpi_remove_notify_handler()
>
> If we supported both ACPI notifications and non-ACPI notificati
> Honestly I'm not sure though we need this complexity right now? I mean,
> it'd be really easy to replace the calls in mac80211 with some other
> more generalised calls in the future?
>
> You need some really deep platform/hardware level knowledge and
> involvement to do this, so I don't think it
rf.c, but a generic
> version that only has an ACPI implementation right now not so much.
>
> On 6/21/2023 1:30 PM, Andrew Lunn wrote:
> > > And consumer would need to call it, but only if CONFIG_WBRF_ACPI isn't
> > > set.
> > Why? How is ACPI special that it does no
> Drivers/subsystems contributing frequencies:
>
> 1) During probe, check `wbrf_supported_producer` to see if WBRF supported
>for the device.
What is the purpose of this stage? Why would it not be supported for
this device?
> +#ifdef CONFIG_WBRF
> +bool wbrf_supported_producer(struct device
> Right now there are stubs for non CONFIG_WBRF as well as other patches are
> using #ifdef CONFIG_WBRF or having their own stubs. Like mac80211 patch
> looks for #ifdef CONFIG_WBRF.
>
> I think we should pick one or the other.
>
> Having other subsystems #ifdef CONFIG_WBRF will make the series
> + argv4 = kzalloc(sizeof(*argv4) * (2 * num_of_ranges + 2 + 1),
> GFP_KERNEL);
> + if (!argv4)
> + return -ENOMEM;
> +
> + argv4[arg_idx].package.type = ACPI_TYPE_PACKAGE;
> + argv4[arg_idx].package.count = 2 + 2 * num_of_ranges;
> + argv4[arg_idx++].package.eleme
> +static void get_chan_freq_boundary(u32 center_freq,
> +u32 bandwidth,
> +u64 *start,
> +u64 *end)
> +{
> + bandwidth = MHZ_TO_KHZ(bandwidth);
> + center_freq = MHZ_TO_KHZ(center_freq);
> +
> +
> @@ -1395,6 +1395,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> debugfs_hw_add(local);
> rate_control_add_debugfs(local);
>
> + ieee80211_check_wbrf_support(local);
> +
> rtnl_lock();
> wiphy_lock(hw->wiphy);
>
> +void ieee80211_check_wbrf_support(struc
> > >> @@ -1395,6 +1395,8 @@ int ieee80211_register_hw(struct
> > ieee80211_hw *hw)
> > >>debugfs_hw_add(local);
> > >>rate_control_add_debugfs(local);
> > >>
> > >> + ieee80211_check_wbrf_support(local);
> > >> +
> > >>rtnl_lock();
> > >>wiphy_lock(hw->wiphy);
> > >>
> > >
> > >>
> This comes back to the point that was mentioned by Johannes - you need to
> have deep design understanding of the hardware to know whether or not you
> will have producers that a consumer need to react to.
Yes, this is the policy is keep referring to. I would expect that
there is something somew
On Mon, Aug 14, 2023 at 09:50:49AM +, Quan, Evan wrote:
> [AMD Official Use Only - General]
>
> Hi Andrew,
>
> I sent out a new V8 series last week.
> A kernel parameter `wbrf` was introduced there to decide the policy.
> Please help to check whether that makes sense to you.
> Please share yo
> > What is the purpose of this stage? Why would it not be supported for this
> > device?
> This is needed for wbrf support via ACPI mechanism. If BIOS(AML code) does
> not support the wbrf adding/removing for some device,
> it should speak that out so that the device can be aware of that.
How mu
> +/**
> + * wbrf_supported_producer - Determine if the device can report frequencies
> + *
> + * @dev: device pointer
> + *
> + * WBRF is used to mitigate devices that cause harmonic interference.
> + * This function will determine if this device needs to report such
> frequencies.
How is the WB
> The wbrf_supported_producer and wbrf_supported_consumer APIs seem
> unnecessary for the generic implementation.
I'm happy with these, once the description is corrected. As i said in
another comment, 'can' should be replaced with 'should'. The device
itself knows if it can, only the core knows if
ew. We also remove component_add_master() as that interface is no
> longer useful.
>
> Signed-off-by: Russell King
I've been using this patch for a couple of weeks
Tested-by: Andrew Lunn
Andrew
> ---
> drivers/base/component.c | 31 +---
> > > +int phy_configure(struct phy *phy, enum phy_mode mode,
> > > + union phy_configure_opts *opts)
> > > +{
> > > + int ret;
> > > +
> > > + if (!phy)
> > > + return -EINVAL;
> > > +
> > > + if (!phy->ops->configure)
> > > + return 0;
> >
> > Shouldn't you report an er
On Tue, Mar 05, 2024 at 11:46:00AM +0100, Julien Panis wrote:
> On 3/1/24 17:38, Andrew Lunn wrote:
> > On Fri, Mar 01, 2024 at 04:02:53PM +0100, Julien Panis wrote:
> > > This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
> > > Ethernet driver. The followi
> 3) From 2), am65_cpsw_alloc_skb() function removed and replaced by
> netdev_alloc_skb_ip_align(), as used by the driver before -> res = 506
> Conclusion: Here is where the loss comes from.
> IOW, My am65_cpsw_alloc_skb() function is not good.
>
> Initially, I mainly created this 'custom' am65_cp
> +static struct sk_buff *am65_cpsw_alloc_skb(struct net_device *ndev, unsigned
> int len)
> +{
> + struct page *page;
> + struct sk_buff *skb;
> +
> + page = dev_alloc_pages(0);
You are likely to get better performance if you use the page_pool.
When FEC added XDP support, the first
On Thu, Feb 29, 2024 at 05:19:44PM +0100, Julien Panis wrote:
> On 2/27/24 00:18, Andrew Lunn wrote:
> > > +static struct sk_buff *am65_cpsw_alloc_skb(struct net_device *ndev,
> > > unsigned int len)
> > > +{
> > > + struct page *page;
> >
On Fri, Mar 01, 2024 at 04:02:53PM +0100, Julien Panis wrote:
> This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
> Ethernet driver. The following features are implemented:
> - NETDEV_XDP_ACT_BASIC (XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED)
> - NETDEV_XDP_ACT_REDIRECT (XDP_REDIRECT)
>
On Fri, Jun 14, 2024 at 03:48:43PM -0700, Joe Damato wrote:
> On Thu, Jun 13, 2024 at 11:22:02AM +0300, Omer Shpigelman wrote:
> > This ethernet driver is initialized via auxiliary bus by the hbl_cn
> > driver.
> > It serves mainly for control operations that are needed for AI scaling.
> >
> > Sig
> > +static void hbl_en_reset_stats(struct hbl_aux_dev *aux_dev, u32 port_idx)
> > +{
> > + struct hbl_en_port *port = HBL_EN_PORT(aux_dev, port_idx);
> > +
> > + port->net_stats.rx_packets = 0;
> > + port->net_stats.tx_packets = 0;
> > + port->net_stats.rx_bytes = 0;
> > + port->net_stat
On Mon, Jun 17, 2024 at 04:05:57PM +0200, Markus Elfring wrote:
> …
> > +++ b/drivers/net/ethernet/intel/hbl_cn/common/hbl_cn.c
> > @@ -0,0 +1,5954 @@
> …
> > +int hbl_cn_read_spmu_counters(struct hbl_cn_port *cn_port, u64 out_data[],
> > u32 *num_out_data)
> > +{
> …
> > + mutex_lock(&cn_port->
> >> +static u32 hbl_en_get_mtu(struct hbl_aux_dev *aux_dev, u32 port_idx)
> >> +{
> >> + struct hbl_en_port *port = HBL_EN_PORT(aux_dev, port_idx);
> >> + struct net_device *ndev = port->ndev;
> >> + u32 mtu;
> >> +
> >> + if (atomic_cmpxchg(&port->in_reset, 0, 1)) {
> >> +
> > Does this device require IPv4? What about users and infrastructures that
> > use IPv6 only?
> > IPv4 is legacy at this point.
>
> Gaudi2 supports IPv4 only.
Really? I guess really old stuff, SLIP from 1988 does not support
IPv6, but i don't remember seeing anything from this century which
do
On Wed, Jun 19, 2024 at 07:16:20AM +, Omer Shpigelman wrote:
> On 6/18/24 17:19, Andrew Lunn wrote:
> >>>> +static u32 hbl_en_get_mtu(struct hbl_aux_dev *aux_dev, u32 port_idx)
> >>>> +{
> >>>> + struct hbl_en_port *port = HBL_EN_PORT(au
On Thu, Jun 20, 2024 at 06:51:35AM -0700, Jakub Kicinski wrote:
> On Thu, 20 Jun 2024 08:43:34 + Omer Shpigelman wrote:
> > > You support 400G, you really need to give the user the ability
> > > to access higher pages.
> >
> > Actually the 200G and 400G modes in the ethtool code should be re
> I see other vendors have debugfs entries for debug configurations or
> settings, not just for dumping debug info.
Did you see any added in the last few years? This is also something
DaveM pushed back on. We want uniform APIs so that all devices look
alike. Please consider what you are exporting
> > But what about when the system is under memory pressure? You say it
> > allocates memory. What happens if those allocations fail. Does
> > changing the MTU take me from a working system to a dead system? It is
> > good practice to not kill a working system under situations like
> > memory press
> > If there is no netdev, what is the point of putting it into loopback?
> > How do you send packets which are to be looped back? How do you
> > receive them to see if they were actually looped back?
> >
> > Andrew
>
> To run RDMA test in loopback.
What is special about your RDMA? Why do yo
> Here is the output:
> $ ethtool eth0
> Settings for eth0:
> Supported ports: [ FIBRE Backplane ]
> Supported link modes: 10baseKR4/Full
> 10baseSR4/Full
> 10baseCR4/Full
> 1
On Wed, Sep 13, 2017 at 01:02:15PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais
> ---
> drivers/net/ethernet/sun/cassini.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/sun/cassini.c
> b/drivers/net/ethernet/sun/cassini.c
> index 382993c..
by bond_open() with:
if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB)))
return -ENOMEM;
So you might want to also modify this code, to return the return
value, rather than use the hard coded ENOMEM.
Since you code is OK as far as it goes:
Reviewed-by: And
> Interesting, as I sped up the ftrace ring buffer by a substantial amount by
> adding strategic __always_inline, noinline, likely() and unlikely()
> throughout the code. It had to do with what was considered the fast path
> and slow path, and not actually the size of the function. gcc got it
> hor
> How is the compiler going to know which path is going to be taken the most?
> There's two main paths in the ring buffer logic. One when an event stays on
> the sub-buffer, the other when the event crosses over to a new sub buffer.
> As there's 100s of events that happen on the same sub-buffer for
> +static int hbl_en_napi_poll(struct napi_struct *napi, int budget);
> +static int hbl_en_port_open(struct hbl_en_port *port);
When you do the Intel internal review, i expect this is crop up. No
forward declarations please. Put the code in the right order so they
are not needed.
> +static int hb
On Wed, Jul 02, 2014 at 06:38:41PM +0200, Jean-Francois Moine wrote:
> This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
>
> The CODEC handles both I2S and S/PDIF inputs and does dynamic input
> switch in the TDA998x I2C driver on start/stop audio streaming.
Hi Jean-Francois
On Mon, Nov 23, 2015 at 04:02:11PM +, Russell King - ARM Linux wrote:
> Greg,
>
> These four patches update the component helper by:
Hi Russell
Is there any documentation for the component helper, in particular,
when devm_ can be used?
It seems like slaves should only do a component_add() i
On Mon, Nov 23, 2015 at 04:02:37PM +, Russell King wrote:
> Now that drivers create an array of component matches at probe time, we
> can retire the old methods. This involves removing the add_components
> master method
Hi Russell
Ack for removing this. I'm using components while restructing
On Tue, Dec 17, 2024 at 12:00:39PM +0200, Avri Kehat wrote:
> Revisiting the comments regarding our use of debugfs as an interface for
> device configurations -
> A big part of the non-statistics debugfs parameters are HW related debug-only
> capabilities, and not configurations required by the u
57 matches
Mail list logo
