Re: [PATCH 06/15] net: hbl_cn: debugfs support

> 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

Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

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: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

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

Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

> > 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

Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

> >> +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(>in_reset, 0, 1)) { > >> +

Re: [PATCH 01/15] net: hbl_cn: add habanalabs Core Network driver

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) > > +{ > … > > +

Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

> > +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; > > +

Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

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. > > > >

Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver

> +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

Re: [PATCH net-next v10 05/14] netdev: netdevice devmem allocator

> 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

Re: [PATCH net-next v10 05/14] netdev: netdevice devmem allocator

> 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 >

Re: [PATCH v2 2/2] net: ethernet: ti: am65-cpsw: Add minimal XDP support

> 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'

Re: [PATCH v2 2/2] net: ethernet: ti: am65-cpsw: Add minimal XDP support

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

Re: [PATCH v2 2/2] net: ethernet: ti: am65-cpsw: Add minimal XDP support

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) >

Re: [PATCH] net: ethernet: ti: am65-cpsw: Add minimal XDP support

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; > >

Re: [PATCH] net: ethernet: ti: am65-cpsw: Add minimal XDP support

> +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

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

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

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

> 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

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

> > >> @@ -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); > > >> > > > > > >>

Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

> @@ -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

Re: [PATCH V6 1/9] drivers core: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V6 1/9] drivers core: Add support for Wifi band RF mitigations

> +/** > + * 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

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

> > 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

Re: [PATCH V5 4/9] wifi: mac80211: Add support for ACPI WBRF

> +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); > + >

Re: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD

> + 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; > +

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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 doe

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

> > 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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

Re: [PATCH net-next 5/6] net: phy: bcm7xxx: Add EPHY entry for 74165

d-off-by: Justin Chen Reviewed-by: Andrew Lunn Andrew

Re: [PATCH net-next 4/6] net: phy: mdio-bcm-unimac: Add asp v2.0 support

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

Re: [PATCH net-next 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller

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

Re: [PATCH] HPE BMC GXP SUPPORT

> > +#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

Re: [PATCH] HPE BMC GXP SUPPORT

> .../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

Re: [PATCH net-next 3/5] net: bcmasp: Add support for ASP2.0 Ethernet controller

> > > +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

Re: [PATCH net-next 3/5] net: bcmasp: Add support for ASP2.0 Ethernet controller

> +static int bcmasp_probe(struct platform_device *pdev) > +{ > + struct bcmasp_priv *priv; > + struct device_node *ports_node, *intf_node; > + struct device *dev = >dev; > + int ret, i, wol_irq, count = 0; > + struct bcmasp_intf *intf; > + struct resource *r; > + u32

Re: [PATCH net-next 0/5] brcm ASP 2.0 Ethernet controller

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?

Re: [PATCH 03/14] net: davicom: dm9000: allow to pass MAC address through mac_addr module parameter

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

Re: [PATCH 02/10] phy: Add configuration interface

> > > +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

Re: [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

s it goes: Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

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 >

[PATCH 1/4] component: remove old add_components method

ew. We also remove component_add_master() as that interface is no > longer useful. > > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> I've been using this patch for a couple of weeks Tested-by: Andrew Lunn Andrew > --- >

[PATCH 0/4] Component helper updates

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()

[PATCH 1/4] component: remove old add_components method

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

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

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