> +On the other hand, due to the volume of development discussions on netdev
> +are very unlikely to be reignited after a week of silence.
My English parse falls over on 'are', and wants to backtrack and try
alternatives.
Maybe:
On the other hand, due to the volume of development discussions on
> +=
> +Devicetree Sources (DTS) Coding Style
> +=
> +
> +When writing Devicetree Sources (DTS) please observe below guidelines. They
> +should be considered complementary to any rules expressed already in
> Devicetree
> +Spe
On Sun, Nov 26, 2023 at 11:38:38AM +0100, Krzysztof Kozlowski wrote:
> On 25/11/2023 20:47, Andrew Lunn wrote:
> >> +=
> >> +Devicetree Sources (DTS) Coding Style
> >> +=
> >> +
>
> One more friendly request, I see net-next is closed today, but our downstream
> kernel release deadline is 5.20, so I want to test and release the new v14
> today,
> is it ok?
5.20? Didn't Linus run out of fingers and thumbs and went from 5.19 to
6.0?
Anyway, this is your internal issue, since
On Mon, May 27, 2024 at 12:36:19PM +0200, Thorsten Blum wrote:
> s/of/off/
>
> Signed-off-by: Thorsten Blum
Good catch.
Please could you add a Fixes: tag. And a Cc: stable tag. The file you
are patching discusses all this :-)
Thanks
Andrew
---
pw-bot: cr
On Sat, Sep 14, 2019 at 10:44:04AM +0100, Russell King wrote:
> Update the phylink documentation to make it clear that phylink is
> designed to be used on the MAC facing side of the link, rather than
> between a SFP and PHY.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
On Fri, Jun 07, 2019 at 01:08:42PM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Andrew Lunn
Andrew
; Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
> > >>+static const struct of_device_id peci_of_table[] = {
> > >>+ { .compatible = "peci-hwmon", },
> > >
> > >This does not look like a reference to some piece of hardware.
> > >
> >
> > This driver provides generic PECI hwmon function to which controller has
> > PECI HW such as Aspeed or Nuvoto
On Thu, Jan 11, 2018 at 03:14:37PM -0800, Jae Hyun Yoo wrote:
> On 1/11/2018 2:18 PM, Andrew Lunn wrote:
> >>>>>+static const struct of_device_id peci_of_table[] = {
> >>>>>+{ .compatible = "peci-hwmon", },
> >>>>
>
> +static int peci_locked_xfer(struct peci_adapter *adapter,
> + struct peci_xfer_msg *msg,
> + bool do_retry,
> + bool has_aw_fcs)
> +{
> + ktime_t start, end;
> + s64 elapsed_ms;
> + int rc = 0;
> +
> + if (!a
On Wed, Feb 21, 2018 at 08:16:00AM -0800, Jae Hyun Yoo wrote:
> This commit adds a dt-bindings document of PECI adapter driver for Aspeed
> AST24xx/25xx SoCs.
Hi Jae
It would be good to separate this into two. One binding document for a
generic adaptor, with a generic PECI bus, and generic client
> >Is there a real need to do transfers in atomic context, or with
> >interrupts disabled?
> >
>
> Actually, no. Generally, this function will be called in sleep-able context
> so this code is for an exceptional case handling.
>
> I'll rewrite this code like below:
> if (in_atomic() || irqs
> But even with this change, it still needs to use delayed creation
> because BMC side kernel doesn't know how many DIMMs are populated on
> a remote server before the remote server completes its memory
> training and testing in BIOS, but it needs to check the remote
> server's CPU temperature as i
On Tue, Mar 06, 2018 at 01:40:02PM +0100, Pavel Machek wrote:
> Hi!
>
> > Signed-off-by: Jae Hyun Yoo
> > ---
> > .../devicetree/bindings/peci/peci-aspeed.txt | 73
> > ++
> > 1 file changed, 73 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pe
On Tue, Feb 05, 2019 at 03:58:20PM +, Russell King wrote:
> Add some phylink documentation to the networking book detailing how
> to convert network drivers from phylib to phylink.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
> > +For information describing the SFP cage in DT, please see the binding
> > +documentation in the kernel source tree
> > +``Documentation/devicetree/bindings/net/sff,sfp.txt``
> oh, so SFP means "Small Form-factor Pluggable".
>
> I see that this source file:
> ./drivers/net/ethernet/intel/i40e/
On Tue, Jul 25, 2017 at 06:15:44PM +0200, Egil Hjelmeland wrote:
> Fixes after testing on actual HW:
>
> - lan9303_mdio_write()/_read() must multiply register number
> by 4 to get offset
>
> - Indirect access (PMI) to phy register only work in I2C mode. In
> MDIO mode phy registers must be ac
On Tue, Jul 25, 2017 at 06:15:45PM +0200, Egil Hjelmeland wrote:
> For some mysterious reason enable switch fabric port 0 TX fails to
> work, when the TX has previous been disabled. Resolved by not
> disable/enable switch fabric port 0 at startup. Port 1 and 2 are
> still disabled in early init.
>
On Tue, Jul 25, 2017 at 06:15:47PM +0200, Egil Hjelmeland wrote:
> This makes the driver react to device tree "fixed-link" declaration
> on CPU port.
>
> - turn off autonegotiation
> - force speed 10 or 100 mb/s
> - force duplex mode
>
> Signed-off-by: Egil Hjelmeland
> ---
> drivers/net/dsa/la
On Tue, Jul 25, 2017 at 06:15:49PM +0200, Egil Hjelmeland wrote:
> Allowing per-port access to Switch Engine Broadcast Throttling Register
Hi Egil
In general, we are against using sysfs. If there is a generic
mechanism, that applies for all sorts of network interfaces, it should
be used instead o
Hi Egil
> +/* forward special tagged packets from port 0 to port 1 *or* port 2 */
> +static int lan9303_setup_tagging(struct lan9303 *chip)
> +{
> + int ret;
Blank line please.
> + /* enable defining the destination port via special VLAN tagging
> + * for port 0
> + */
> +
Hi Egil
> +/* This function will wait a while until mask & reg == value */
> +/* Otherwise, return timeout */
> +static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno,
> + int mask, char value)
> +{
> + int i;
> +
> + for (i = 0; i < 0x1000; i++) {
> +
> > So I really want to group the patches into only a few series in order
> > to not spend months on the process.
I strongly agree with Vivien here. Good patches get accepted in about
3 days. You should expect feedback within a day or two. That allows
you to have fast cycle times for getting patch
> Good. Just one question about process. Could I have posted my work
> as a RFC? To get one round of initial feedback before chopping into
> small patch requests. As well as indicating where I am heading. Or is
> that just waste of human bandwidth?
Depends. Post 100 RFC patches, i won't look at th
> Yes, this setting can be used to reduce effect of broadcast storms.
So one way to solve this is to teach the software bridge about
broadcast storm control. Put some rate limiting into its broadcast
flood handling. Then add a switchdev call which passes this down into
the switch.
Or look at doin
> >I think you are over-simplifying here. Say i have a layer 2 VPN and i
> >bridge port 1 and the VPN? The software bridge still wants to do STP
> >on port 1, in order to solve loops.
> >
>
> Problem is that the mainline lan9303_separate_ports() does its
> work by setting port 1 & 2 in STP BLOCKIN
On Fri, Jul 28, 2017 at 01:08:25PM +0200, Egil Hjelmeland wrote:
> On 26. juli 2017 18:55, Andrew Lunn wrote:
> >On Tue, Jul 25, 2017 at 06:15:44PM +0200, Egil Hjelmeland wrote:
> >It is better to use mdiobus_read/write or if you are nesting mdio
> >busses, mdiobus_read_nested
On Fri, Nov 04, 2016 at 01:16:14PM +0100, Fabian Mewes wrote:
> Add Qualcomm QCA tagging introduced in cafdc45c9 to the
> list of supported protocols.
>
> Signed-off-by: Fabian Mewes
Thanks
Reviewed-by: Andrew Lunn
Andrew
--
To unsubscribe from this list: send the line "
> Rather than beating our heads against the wall trying to convert between
> various image formats, maybe we need to take a step back. We're trying
> to build better documentation, and there is certainly a place for
> diagrams and such in that documentation. Johannes was asking about it
> for the
> +/**
> + * devm_gpiochip_add_data() - Resource manager piochip_add_data()
^
missing g.
> + * @dev: the device pointer on which irq_chip belongs to.
> + * @chip: the chip to register, with chip->base initialized
> + * Context: potentially before
On Sat, Apr 09, 2016 at 12:00:25AM +0900, Masanari Iida wrote:
> This patch fix typos in Documentation/networking/dsa.
>
> Signed-off-by: Masanari Iida
Reviewed-by: Andrew Lunn
Thanks
Andrew
> ---
> Documentation/networking/dsa/bcm_sf2.txt | 2 +-
> Documentat
are inline, and to avoid warnings about missing declarations. But
we just prefer not to have any sort of inline functions without good
justifications within a .c file.
A nit pick, so:
Reviewed-by: Andrew Lunn
Andrew
> Thanks, perhaps something like this would help:
>
> Using inline in .h files is fine and is encouraged in place of macros
> [reference section 12].
The other major use of them in headers is for stub functions when an
API implementation has a Kconfig option. The question is, do we really
wan
> +#define PRINT_COUNTER_PREFIX(desc, cnt_type) \
> + seq_printf(seq, "%-16s %16s", desc, cnt_type)
> +
> +#define PRINT_CPU_CODE_COUNTER(cnt, code)\
> + seq_printf(seq, "%10u(cpucode:%d)", cnt, code)
> +
> +#define PRINT_DROP_CODE_COUNTER(cnt, port, code) \
> +
> +/* Assign the share buffer number 1550 to group 0 by default. */
> +static const int ipq9574_ppe_bm_group_config = 1550;
To a large extent, the comment is useless. What should be in the
comment is why, not what.
Andrew
> + /* Configure BM flow control related threshold. */
> + PPE_BM_PORT_FC_SET_WEIGHT(bm_fc_val, port_cfg.weight);
> + PPE_BM_PORT_FC_SET_RESUME_OFFSET(bm_fc_val, port_cfg.resume_offset);
> + PPE_BM_PORT_FC_SET_RESUME_THRESHOLD(bm_fc_val, port_cfg.resume_ceil);
> + PPE_BM_PORT_FC
> +/* Scheduler configuration for the assigning and releasing buffers for the
> + * packet passing through PPE, which is different per SoC.
> + */
> +static const struct ppe_scheduler_bm_config ipq9574_ppe_sch_bm_config[] = {
> + {1, 0, 0, 0, 0},
> + {1, 1, 0, 0, 0},
> + {1, 0, 5, 0, 0}
> > +#ifndef __PPE_H__
> > +#define __PPE_H__
> > +
> > +#include
> > +#include
> > +
> > +struct device;
> #include ?
>
> > +struct regmap;
> Same with previous one, include it's header file?
>
If the structure is opaque at this level, it is fine to not include
the header. There is nothing i
On Wed, Jan 08, 2025 at 09:47:19PM +0800, Luo Jie wrote:
> From: Lei Wei
>
> Configure the default L2 bridge settings for the PPE ports to
> enable L2 frame forwarding between CPU port and PPE Ethernet
> ports.
It would be good to have an 'only' in there:
> to _only_
> enable L2 frame forwardin
On Wed, Jan 08, 2025 at 09:47:20PM +0800, Luo Jie wrote:
> The PPE hardware packet counters are made available through
> the debugfs entry "/sys/kernel/debug/ppe/packet_counters".
Why?
Would it not be better to make them available via ethtool -S ?
You should justify not using standard statistics
> +CPU number auto population in userdata
> +--
> +
> +Inside the netconsole configfs hierarchy, there is a file called
> +`cpu_nr` under the `userdata` directory. This file is used to enable or
> disable
> +the automatic CPU number population feature. This feat
On Fri, Jan 24, 2025 at 07:16:39AM -0800, Breno Leitao wrote:
> The current implementation of netconsole sends all log messages in
> parallel, which can lead to an intermixed and interleaved output on the
> receiving side. This makes it challenging to demultiplex the messages
> and attribute them t
> > Why is learning needed on physical ports? In general, switches forward
> > unknown destination addresses to the CPU. Which is what you want when
> > the ports are isolated from each other. Everything goes to the
> > CPU. But maybe this switch does not work like this?
> >
>
> L2 forwarding can
> I would like to clarify that representing the bridge and its slave ports
> inside PPE (using a VSI - virtual switch instance) is a pre-requisite before
> learning can take place on a port. At this point, since switchdev
> is not enabled, VSI is not created for port/bridge and hence FDB learning
>
> > > +/* The number of packets dropped because of no buffer available, no PPE
> > > + * buffer assigned to these packets.
> > > + */
> > > +static void ppe_port_rx_drop_counter_get(struct ppe_device *ppe_dev,
> > > + struct seq_file *seq)
> > > +{
> > > + u32 reg,
> Thanks for the suggestion. Just to clarify, we preferred
> u32p_replace_bits() over FIELD_PREP() because the former does
> a clear-and-set operation against a given mask, where as with
> FIELD_PREP(), we need to clear the bits first before we use the
> macro and then set it. Due to this, we prefe
On Thu, Feb 20, 2025 at 10:38:03PM +0800, Jie Luo wrote:
>
>
> On 2/11/2025 9:22 PM, Andrew Lunn wrote:
> > > + /* Configure BM flow control related threshold. */
> > > + PPE_BM_PORT_FC_SET_WEIGHT(bm_fc_val, port_cfg.weight);
> > > + PPE_BM
> As a general rule, we have tried to keep the data structure definition
> accurately mirror the hardware table design, for easier understanding
> and debug ability of the code.
Could you point me at the datasheet which describes the table?
Andrew
49 matches
Mail list logo
