Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp5310650rdb; Sat, 30 Dec 2023 15:56:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IFVLvBx8lMrKO2INv7o5thgJr3/7Fop7aJvtkWHdYOZCKQdN5mrUlVd8kvgAqWRSI28gXjB X-Received: by 2002:a05:622a:1787:b0:427:ea08:92a1 with SMTP id s7-20020a05622a178700b00427ea0892a1mr8512085qtk.29.1703980595514; Sat, 30 Dec 2023 15:56:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703980595; cv=none; d=google.com; s=arc-20160816; b=Ff9WEp1GqD0FosEZ6Eb3O6NEMRokwS2ZQSxVyMebqQOI94Dl1aSsTVOcPoyTIVDgOv DcskBdJEuC9Ay895JndMsqDNs3bFdwGCTqYzgSyI2G+Lo72QdaePEld429seVTSoJ2UR 3yvG+jGSaDexMvIMqr9wTZKpdt7knszfpnSbnANCUPV3vuVva6q1RY13iWHEwzxLjB9K ywSrqU30pjdwHsGKhXin8IMUlyseKS+EeeU8JuILqTMbkjRHuuJZz6PPv+eCMsO8+ASu zpMWkgr396n66wieyRAUQ1wb9Hd+ROMojr2ZW5LZw2p1vHRO5L+lzogfCh301O+Jw4To dOzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :dkim-signature; bh=L5zAmrcU0rDyTMldnWGuhFtbY40ZcOd+zmFip/yI9K8=; fh=3oLj8OFjg00+slgtxcapk/g1YtPCNB2rKviiFeBwpQk=; b=AazSCjme6rOAR5PqVm3elMsaye762rn/PGRZFSAO8BhbGbFWyfEIACM3pQZKbfDzwG mGj7n8plJN5N56njxg5fiNNAF5o4tmV1cd7Lz6u2rye2m4lWt7utaPLxgnx2+kWJZNUY X5JHxBv+9a3qAimh8n/ItRDIPAE4UfdD5Gz/833nWa7JvmsGPUH8xud8PKsLqXRU8pyZ 2InyLOV2Rhh83RJgbmhL2/76chQBhN+DAAzBXhZi9WhLZQq7Y79quqrftYS1pwebi2EF pOfNpNwe068K752RU6eKwgc5OzY5RWHwlIuHj9Jb9Ow7aU7pMznL+tJprny2OZP3Ruh+ rZCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CWUDlUd5; spf=pass (google.com: domain of linux-kernel+bounces-13609-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13609-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id n1-20020ac85a01000000b004277aca704asi21706116qta.283.2023.12.30.15.56.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Dec 2023 15:56:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13609-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CWUDlUd5; spf=pass (google.com: domain of linux-kernel+bounces-13609-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13609-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 2BC961C21B98 for ; Sat, 30 Dec 2023 23:56:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 73025F9CF; Sat, 30 Dec 2023 23:56:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CWUDlUd5" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1256BDDC6; Sat, 30 Dec 2023 23:56:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2ccf55bed13so8744111fa.1; Sat, 30 Dec 2023 15:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703980582; x=1704585382; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L5zAmrcU0rDyTMldnWGuhFtbY40ZcOd+zmFip/yI9K8=; b=CWUDlUd5LI4yyn4puZcvTu7vvKyts2XBTGeRqf6tcftAfXMNByNWlhvWZgKtbJBhxW AtPPoB20dwnIsf2iw0D2a98S0j1RK1PXU16TOuJK7Y/zLzmdtHqM7gkLDTatDmATEWZ0 Ac9b+o0vjGzF1Rt3Llm+jXTm5spOW43gYFxTyvSXsfXiQ5KcDoAgM98QU7JbIHjhZJ9U Mnn4+IgMSL64upk+S3A1DGYwOi7xlCCEmBzR4QhDfBpbx0bQFMpifaSt+1nqTHPNQ1tr 8T5pg0rdiPbrLiVt3YsNt4NmC44QprTGfHPbXsmHsPkhXj9v7f4OQkaIKJkGeCEoSVKh voAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703980582; x=1704585382; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=L5zAmrcU0rDyTMldnWGuhFtbY40ZcOd+zmFip/yI9K8=; b=qc09aUfp2Dr4M+du2i2qPFJFqbkpwW4LSJwRjAkyxkixe5mMm9dF0u7AKE98PVlml6 yDQj0PZBOrsdM8L2jvgn1lwAgmsRM87fo2XxDbycJWb99YhU0ac+c/AvCoNdT7NwaCPg aJHQ9lPxUOXuxTxXMXsDnDwLwZ8DTt1JEEiuYhPEQiLr/7J5djqa3cBpSM7S/Uj/9OsH +mynZoc9maIZrGI+q6HBU/Ja/IF35T1dHjusc/0G4H1b/TEPKfQSuHY0/gKKPJDj8sVW xbBvlfnkXR4poGQopC6cCbcW60lOz79ZZQQp7o2B8okE5ahhIXHh1KQsMvDzRKqLBdwD hV0A== X-Gm-Message-State: AOJu0YztGJnGQMtLZy471qO9/NK6sndEwKtv3OTkSTl2YUyG0JXw+EFz pqBDsRMMtthcwButRKfc3rervPORynmQG5E81JRgtoWVEPOnX7pI X-Received: by 2002:a2e:9686:0:b0:2cc:7db2:acb9 with SMTP id q6-20020a2e9686000000b002cc7db2acb9mr6007446lji.24.1703980581641; Sat, 30 Dec 2023 15:56:21 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231030-fix-rtl8366rb-v2-1-e66e1ef7dbd2@linaro.org> <20231030141623.ufzhb4ttvxi3ukbj@skbuf> <20231030222035.oqos7v7sdq5u6mti@skbuf> <20231030233334.jcd5dnojruo57hfk@skbuf> In-Reply-To: From: Luiz Angelo Daros de Luca Date: Sat, 30 Dec 2023 20:56:10 -0300 Message-ID: Subject: Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size To: Linus Walleij Cc: Ansuel Smith , Andrew Lunn , Vladimir Oltean , Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" > > I took a look at the LED code. It looks like you got it a little bit wrong. > > You are right... > > > If LEDs are not disabled, it will use the RTL8366RB_LED_FORCE for all > > 4 LED groups. That RTL8366RB_LED_FORCE keeps the LEDs on. I would use > > RTL8366RB_LED_LINK_ACT by default to make it blink on link activity > > (or make it configurable as the comment suggests) but it is not wrong. > > I cannot evaluate the RTL8366RB_INTERRUPT_CONTROL_REG usage when you > > disable the LEDs but it seems to be odd. > > The problem is that since I don't have a device with LEDs connected > to tHE RTL8366RB it is all just dry coding. > > I would suggest if you can test it just make a basic patch that will > at least turn on the LEDs to some default setting that works for > you? Sure. I believe using link act will be much more useful than just turning all leds on, independently from the port state. It is an easy one-line fix. I can do that after the other series gets merged. I think that we should also remove rb8366rb_set_port_led(). Even if I fix it, it will just turn the LED off when the port is administratively down. RTL8366RB_LED_0_1_CTRL_REG and RTL8366RB_LED_2_3_CTRL_REG are only used to control leds when you force them to be on (RTL8366RB_LED_FORCE). In that scenario, the OS might be in charge of triggering them, even for uses not related to the switch. > > I though that maybe we could setup a LED driver to expose the LEDs > > status in sysfs. However, I'm not sure it is worth it. If you change a > > LED behavior, it would break the HW triggering rule for all the group. > > I'm not sure the LED API is ready to expose LEDs with related fate. It > > would, indeed, be useful as a readonly source or just to > > enable/disable a LED. > > The LED subsystem supports hardware triggering etc thanks to the > elaborate work by Christian (ansuel). You can see an example of how > this is done in: > drivers/net/dsa/qca/qca8k-leds.c > > Christian also extended the LEDs subsystem with the necessary > callbacks to support HW-backed LED control. > > This can be used already to achieve HW triggers for the LEDs > from sysfs. (See callbacks .hw_control_is_supported, > .hw_control_set etc etc). > > I was working to implement this for the Marvell switches but Andrew > wanted to do some more structured approach with a LED library > for DSA switches. Yes, I took a look at it. It would be my inspiration if I go down that road. I can use the HW offload only if all LEDs in the group share the same trigger and timer. Otherwise, I'll need to fall back to software control. I'll think about it if that is a viable solution. Regards, Luiz