On Thu, 15 Apr 2021 10:36:40 +0200
Pali Rohár wrote:
> On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > On Mon, Apr 12, 2021 at 7:41 AM Pali Rohár wrote:
> > >
> > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > function and allow to build it as module")
On Tue, 13 Apr 2021 20:16:24 +0200
Tobias Waldekranz wrote:
> You could imagine a different mode in which the DSA driver would receive
> the bucket allocation from the bond/team driver (which in turn could
> come all the way from userspace). Userspace could then implement
> whatever strategy it
On Tue, 13 Apr 2021 16:46:32 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
> > On Tue, 13 Apr 2021 01:54:50 +0200
> > Marek Behun wrote:
> >
> >> I will look into this, maybe ask some follow-up questions.
> >
> &g
On Tue, 13 Apr 2021 02:27:30 +0200
Marek Behun wrote:
> On Tue, 13 Apr 2021 01:54:50 +0200
> Marek Behun wrote:
>
> > I will look into this, maybe ask some follow-up questions.
>
> Tobias,
>
> it seems that currently the LAGs in mv88e6xxx driver do not use the
>
On Tue, 13 Apr 2021 01:54:50 +0200
Marek Behun wrote:
> I will look into this, maybe ask some follow-up questions.
Tobias,
it seems that currently the LAGs in mv88e6xxx driver do not use the
HashTrunk feature (which can be enabled via bit 11 of the
MV88E6XXX_G2_TRUNK_MAPPING register).
If
On Tue, 13 Apr 2021 01:13:53 +0200
Tobias Waldekranz wrote:
> > ...you could get the isolation in place. But you will still lookup the
> > DA in the ATU, and there you will find a destination of either cpu0 or
> > cpu1. So for one of the ports, the destination will be outside of its
> > port
gt; On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean
> > >> wrote:
> > >> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> > >> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun
> > >> >>
On Tue, 13 Apr 2021 00:05:51 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> > On Mon, 12 Apr 2021 23:22:45 +0200
> > Tobias Waldekranz wrote:
> >
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >&g
On Tue, 13 Apr 2021 01:17:21 +0300
Vladimir Oltean wrote:
> On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> > On Mon, 12 Apr 2021 19:32:11 +0300
> > Vladimir Oltean wrote:
> >
> > > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
On Mon, 12 Apr 2021 19:32:11 +0300
Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> > >
> > > So I'd be tempted to say 'tough luck' if all your ports are not up, and
> > > the ones
On Mon, 12 Apr 2021 23:49:22 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On M
On Mon, 12 Apr 2021 23:22:45 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> > On Mon, 12 Apr 2021 14:46:11 +0200
> > Tobias Waldekranz wrote:
> >
> >> I agree. Unless you only have a few really wideband flows, a LAG will
On Mon, 12 Apr 2021 14:46:11 +0200
Tobias Waldekranz wrote:
> I agree. Unless you only have a few really wideband flows, a LAG will
> typically do a great job with balancing. This will happen without the
> user having to do any configuration at all. It would also perform well
> in
On Sat, 10 Apr 2021 15:34:46 +0200
Ansuel Smith wrote:
> Hi,
> this is a respin of the Marek series in hope that this time we can
> finally make some progress with dsa supporting multi-cpu port.
>
> This implementation is similar to the Marek series but with some tweaks.
> This adds support for
On Thu, 25 Mar 2021 06:04:43 +
Hermes Zhang wrote:
> > LED_FULL / LED_OFF are deprecated, don't use them.
>
> Then could I use just 0 (instead LED_OFF) and led_cdev->max_brightness
>
> (instead of LED_FULL) here? The idea here is map the states defined in dts
>
> to the full brightness
On Wed, 24 Mar 2021 15:56:29 +0800
Hermes Zhang wrote:
> From: Hermes Zhang
>
> *** BLURB HERE ***
"*** BLURB HERE ***" is meant to be substituted with your text :)
All in all I think you are adding functionality which can be
incorporated simply into the existing leds-gpio driver instead of
On Wed, 24 Mar 2021 15:56:31 +0800
Hermes Zhang wrote:
> From: Hermes Zhang
>
> Document the device tree bindings of the multiple GPIOs LED driver
> Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml.
The dt-binding should come before the actual driver. Otherwise there
will be a
On Wed, 24 Mar 2021 15:56:30 +0800
Hermes Zhang wrote:
> From: Hermes Zhang
>
> Introduce a new multiple GPIOs LED driver. This LED will made of
> multiple GPIOs (up to 8) and will map different brightness to different
> GPIOs states which defined in dts file.
I wonder how many boards have
On Fri, 12 Mar 2021 08:48:55 +
Hermes Zhang wrote:
> Hi Alexander,
>
> > Am Donnerstag, 11. März 2021, 14:04:08 CET schrieb Hermes Zhang:
> > > From: Hermes Zhang
> > >
> > > Introduce a new Dual GPIO LED driver. These two GPIOs LED will act as
> > > one LED as normal GPIO LED but give
On Fri, 12 Mar 2021 04:48:52 +
Hermes Zhang wrote:
> >
> > Sorry, leds-regulator has only a binary state LED.
> >
> > Maybe you could extend leds-regulator to be able to use all regulator
> > states?
> >
> > Or you can extend leds-gpio driver to support N states via log N gpios,
> >
On Thu, 11 Mar 2021 16:38:14 +0100
Marek Behun wrote:
> LED_FULL, LED_HALF, LED_OFF are deprecated.
>
> And this driver is redundant. This can be done with leds-regulator,
> with a gpio-regulator.
>
> Marek
Sorry, leds-regulator has only a binary state LED.
Maybe you
LED_FULL, LED_HALF, LED_OFF are deprecated.
And this driver is redundant. This can be done with leds-regulator,
with a gpio-regulator.
Marek
This patch touches only code in drivers/leds and include/linux/leds.h.
Meanwhile enum led_brightness is used in many other parts of kernel as
well, just try
git grep "enum led_brightness"
Also changing it probably to a simple int would be better. But if we
wanted a typedef anyway, it should be
On Wed, 3 Feb 2021 17:35:55 +0100
Pavel Machek wrote:
> On Wed 2021-02-03 15:39:59, Sven Schuchmann wrote:
> > Hello Pavel,
> >
> > > > In order to use a multicolor-led together with a trigger
> > > > from DT the led needs to have an intensity set to see something.
> > > > The trigger changes
Hi Pali and Miquel,
On Wed, 23 Dec 2020 17:24:03 +0100
Pali Rohár wrote:
> int xhci_mvebu_a3700_init_quirk(struct usb_hcd *hcd)
> {
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct device *dev = hcd->self.controller;
> + struct phy *phy;
> + int ret;
>
> /*
subject prefix should be
leds: ss4200: simplify the return expression of register_nasgpio_led
On Fri, 11 Dec 2020 14:08:43 +
David Laight wrote:
>
> More than 8 bits would be good.
> While not really relevant for actual 'brightness' it allows
> for 'strange' things be encoded in the brightness field.
>
> For instance we have some hardware that has RGB leds on it.
> They are a single
On Fri, 11 Dec 2020 03:48:40 +0200
Abanoub Sameh wrote:
> This gets rid of enum led_brightness in the main led files,
> because it is deprecated, and an int can be used instead,
> or maybe even a uint8_t since it only goes up to 255.
> Next we can also patch the other files to get rid of it
On Wed, 25 Nov 2020 11:42:42 +0100
Pavel Machek wrote:
> Hi!
>
> > Allow setting netdev LED trigger as default when given LED DT node has
> > the `trigger-sources` property pointing to a node corresponding to a
> > network device.
> >
> > The specific netdev trigger mode is determined from the
Hi Andrew,
On Fri, 20 Nov 2020 02:29:06 +0100
Andrew Lunn wrote:
> > + if (speed >= 2500 && port > 0 && port < 9)
> > + return -EOPNOTSUPP;
>
> Maybe i'm missing something, but it looks like at this point you can
> call
>
> return mv88e6xxx_port_set_speed_duplex(chip,
On Thu, 29 Oct 2020 18:49:52 +0100
Pavel Machek wrote:
>
> Thanks, applied.
>
> But it seems to me similar handling is needed in "success" paths, no?
>
> Best regards,
> Pavel
Pavel, the subject of this commit is wrong.
It should
On Thu, 29 Oct 2020 15:40:25 +1000
Pavana Sharma wrote:
> Updated patchset.
>
> Split the patch to separate mv88e6393 changes from refactoring
> serdes_get_lane.
> Update Documentation before adding new mode.
Pavana, the patch adding support for Amethyst has to be the last in the
series. The
On Thu, 29 Oct 2020 15:42:29 +1000
Pavana Sharma wrote:
> The Marvell 88E6393X device is a single-chip integration of a 11-port
> Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
> and three 10-Gigabit interfaces.
>
> This patch adds functionalities specific to
On Thu, 29 Oct 2020 15:42:00 +1000
Pavana Sharma wrote:
> Add new mode supported by MV88E6393 family.
>
This commit message isn't ideal. It infers that the Amethyst is first
such device to implement this mode, which is not true. The 5gbase-r mode
is supported by various other hardware, for
Pavana,
please add me to Cc for this.
Does USXGMII mode work? There are some erratas for for 10gb serdes mode.
Also you should split this patch. The code that refactores the
serdes_get_lane methods should be in a separate patch.
I have a device with this switch and also a SFP module which can
On Tue, 20 Oct 2020 15:15:25 +0100
Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote:
> > On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote:
> > > On Tue, 20 Oct 2020 11:15:52 +0100
> > > Russell Ki
On Tue, 20 Oct 2020 11:15:52 +0100
Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote:
> > When a port is configured with 'managed = "in-band-status"' don't force
> > the link up, the switch MAC will detect the link status correctly.
> >
> >
On Sat, 10 Oct 2020 20:57:00 +0200
Pavel Machek wrote:
> On Fri 2020-10-09 15:51:35, Gabriel David wrote:
> > The mentioned struct, lm3697_led, was renamed to lm3697_bank since the
> > structure is representing the control banks. This name, in my opinion,
> > is more semantically correct. The
On Mon, 5 Oct 2020 22:17:14 +0200 (CEST)
ultracool...@tutanota.com wrote:
> Subject says it all. This rename was briefly discussed in this other patch:
> https://www.spinics.net/lists/linux-leds/msg16865.html (I don't know another
> way to link to emails, so I'll just use this archive).
>
>
On Tue, 6 Oct 2020 09:57:08 -0500
Dan Murphy wrote:
> Unfortunately we cannot and should not change the ABI now.
>
> Using the led-sources as the bank indicator does not conform to the
> definition of the description of the led-sources in the yaml.
>
> The preference was to use the
Adding Rob to Cc, Rob, could we have your opinion on this? Mine is below.
On Tue, 6 Oct 2020 07:21:14 -0500
Dan Murphy wrote:
> >> By the way I just realized that the DT binding in this driver seems
> >> incorrect to me.
> >>
> >> The controller logically supports 3 LED strings, each having
>
By the way I just realized that the DT binding in this driver seems
incorrect to me.
The controller logically supports 3 LED strings, each having
configurable control bank.
But the DT binding supports 2 DT nodes, one for each control bank
(identified by the `reg` property) and then `led-sources`
On Sat, 3 Oct 2020 15:02:51 +0200 (CEST)
ultracool...@tutanota.com wrote:
> From 0dfd5ab647ccbc585c543d702b44d20f0e3fe436 Mon Sep 17 00:00:00 2001
> From: Ultracoolguy
> Date: Fri, 2 Oct 2020 18:27:00 -0400
> Subject: [PATCH] leds:lm3697:Fix out-of-bound access
>
> If both led banks aren't used
On Sat, 26 Sep 2020 15:55:09 +0200
Luka Kovacic wrote:
> Add a driver for the iEi WT61P803 PUZZLE microcontroller, used in some
> iEi Puzzle series devices. The microcontroller controls system power,
> temperature sensors, fans and LEDs.
>
> This driver implements the core functionality for
On Sat, 26 Sep 2020 15:55:12 +0200
Luka Kovacic wrote:
> Add the iei-wt61p803-puzzle driver sysfs interface documentation to allow
> monitoring and control of the microcontroller from user space.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Robert Marko
> ---
>
On Sat, 26 Sep 2020 15:55:11 +0200
Luka Kovacic wrote:
> Add support for the iEi WT61P803 PUZZLE LED driver.
> Currently only the front panel power LED is supported.
>
> This driver depends on the iEi WT61P803 PUZZLE MFD driver.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Robert
On Sat, 26 Sep 2020 15:55:08 +0200
Luka Kovacic wrote:
> diff --git
> a/Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml
> b/Documentation/devicetree/bindings/leds/iei,wt61p803-puzzle-leds.yaml
> new file mode 100644
> index ..502d97630ecc
> --- /dev/null
> +++
On Sat, 26 Sep 2020 15:55:14 +0200
Luka Kovacic wrote:
> + leds {
> + compatible = "gpio-leds";
> + status = "okay";
> + pinctrl-0 = <_sfpplus_led_pins _sfpplus_led_pins>;
> + pinctrl-names = "default";
> +
> + led0 {
> +
Already fixed in Pavel's for-next
https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next=62aa40d0e907849d740ceba2a7f6bcc88896699f
On Sat, 26 Sep 2020 01:10:11 +0200
Tobias Jordan wrote:
> In one of the error paths of the for_each_child_of_node loop in
> tlc591xx_probe, add missing call to of_node_put.
>
> Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the
> managed led API")
>
> Signed-off-by: Tobias
On Sat, 26 Sep 2020 00:59:05 +0200
Tobias Jordan wrote:
> Fix error paths in for_each_child_of_node loops that were missing an
> of_node_put call.
>
> Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to
> lp55xx")
> Signed-off-by: Tobias Jordan
> ---
>
Wrong subject, it says
lm3552
but driver is called
lm3532
Besides this:
Reviewed-by: Marek Behún
On Mon, 21 Sep 2020 16:03:22 +0200
Simon Guinot wrote:
> On Mon, Sep 21, 2020 at 03:02:08PM +0200, Marek Behun wrote:
> > On Mon, 21 Sep 2020 14:53:43 +0200
> > Simon Guinot wrote:
> >
> > > On Fri, Sep 18, 2020 at 07:14:05PM +0200, Marek Behun wrote:
> &
On Mon, 21 Sep 2020 14:53:43 +0200
Simon Guinot wrote:
> On Fri, Sep 18, 2020 at 07:14:05PM +0200, Marek Behun wrote:
> > On Fri, 18 Sep 2020 15:02:06 +0200
> > Simon Guinot wrote:
> >
> > > On Thu, Sep 17, 2020 at 01:16:50AM +0200, Marek Behú
On Sun, 20 Sep 2020 23:46:47 +0200
Pavel Machek wrote:
> On Sun 2020-09-20 22:42:03, Marek Behún wrote:
> > The leds-regulator driver only supports the old platform data binding
> > and no in-tree code uses it. It also seems that no OpenWRT board uses
> > it.
> >
> > Remove this driver.
>
>
On Sun, 20 Sep 2020 18:55:28 +0200
Jacek Anaszewski wrote:
> On 9/20/20 5:39 PM, Marek Behun wrote:
> > On Sun, 20 Sep 2020 16:15:09 +0200
> > Jacek Anaszewski wrote:
> >
> >> Hi Pavel,
> >>
> >> On 9/19/20 11:38 AM, Pavel Machek wrote:
>
On Sun, 20 Sep 2020 16:15:09 +0200
Jacek Anaszewski wrote:
> Hi Pavel,
>
> On 9/19/20 11:38 AM, Pavel Machek wrote:
> > commit 318681d3e019e39354cc6c2155a7fd1bb8e8084d
> > Author: Pavel Machek
> > Date: Sat Sep 19 11:34:58 2020 +0200
> >
> > ledtrig-cpu: Limit to 4 CPUs
> >
> >
Besides Pavel's note about the __attribute__((nonnull)) position
Reviewed-by: Marek Behún
On Sat, 19 Sep 2020 11:56:16 +0200
Pavel Machek wrote:
> #include
It can't include this header on other platforms...
On Fri, 18 Sep 2020 06:47:20 -0500
Dan Murphy wrote:
>
> Reviewed-by: Dan Murphy
>
>
Dan,
could you also review patch 14/50? That one is also lm3697 and this one
depends on it.
Marek
On Fri, 18 Sep 2020 15:02:06 +0200
Simon Guinot wrote:
> On Thu, Sep 17, 2020 at 01:16:50AM +0200, Marek Behún wrote:
>
> Hi Marek,
>
> > By using struct led_init_data when registering we do not need to parse
> > `label` DT property nor `linux,default-trigger` property.
> >
> > Also, move
On Fri, 18 Sep 2020 12:57:59 +0300
Sakari Ailus wrote:
> On Fri, Sep 18, 2020 at 11:20:58AM +0200, Marek Behun wrote:
> > On Fri, 18 Sep 2020 09:15:00 +0300
> > Sakari Ailus wrote:
> >
> > > Hi Marek,
> > >
> > > On Fri, Sep 18, 2020 at 12:32
On Fri, 18 Sep 2020 09:15:00 +0300
Sakari Ailus wrote:
> Hi Marek,
>
> On Fri, Sep 18, 2020 at 12:32:53AM +0200, Marek Behún wrote:
> > Change
> > .of_match_table = xxx,
> > to
> > .of_match_table = of_match_ptr(xxx),
> > in various drivers.
> >
> > This should be standard even for drivers
On Thu, 17 Sep 2020 10:28:12 -0500
Dan Murphy wrote:
> Marek
>
> On 9/16/20 6:16 PM, Marek Behún wrote:
> > By using struct led_init_data when registering we do not need to parse
> > `label` DT property nor `linux,default-trigger` property.
> >
> > A small refactor was also done:
> > - with
This can be done without refactoring, please ignore this patch in this
spin.
On Wed, 16 Sep 2020 19:46:25 -0500
Bjorn Andersson wrote:
> The pdev->dev -> dev and of_node changes are reasonable, but shouldn't
> be part of this patch. It simply makes it hard to reason about he actual
> change.
>
> Please respin this with only the introduction of led_init_data.
>
>
On Thu, 17 Sep 2020 06:39:56 -0500
Dan Murphy wrote:
> Marek
>
> On 9/16/20 6:16 PM, Marek Behún wrote:
> > By using struct led_init_data when registering we do not need to parse
> > `label` DT property nor `linux,default-trigger` property.
>
> I would prefer 2 separate patches. One
On Tue, 15 Sep 2020 23:35:25 +0200
Jacek Anaszewski wrote:
> Hi Marek,
>
> On 9/15/20 5:26 PM, Marek Behún wrote:
> > Allow setting netdev LED trigger as default when given LED DT node has
> > the `trigger-sources` property pointing to a node corresponding to a
> > network device.
> >
> > The
On Tue, 15 Sep 2020 17:26:15 +0200
Marek Behún wrote:
> + /*
> + * Check whether LED has defined valid source for this trigger.
> + * If yes, this trigger should be set as default trigger for LED.
> + * This should use of_led_count_trigger_sources and
> + *
Hello,
I have been thinking about another way to implement ABI for HW control
of ethernet PHY connected LEDs.
This proposal is inspired by the fact that for some time there is a
movement in the kernel to do transparent HW offloading of things (DSA
is an example of that).
So currently we have
On Thu, 10 Sep 2020 22:23:45 +0200
Pavel Machek wrote:
> Hi!
>
> > Okay, so the netdev trigger offers modes `link`, `rx`, `tx`.
> > You can enable/disable either of these (via separate sysfs files). `rx`
> > and `tx` blink the LED, `link` turns the LED on if the interface is
> > linked.
>
>
On Thu, 10 Sep 2020 19:34:35 +0100
Russell King - ARM Linux admin wrote:
> On Thu, Sep 10, 2020 at 08:31:54PM +0200, Andrew Lunn wrote:
> > Generally the driver will default to the hardware reset blink
> > pattern. There are a few PHY drivers which change this at probe, but
> > not many. The
On Wed, 9 Sep 2020 23:40:09 +0200
Pavel Machek wrote:
> > >
> > > 80 columns :-) (and please fix that globally, at least at places where
> > > it is easy, like comments).
> > >
> >
> > Linux is at 100 columns now since commit bdc48fa11e46, commited by
> > Linus. See
> >
On Wed, 9 Sep 2020 23:42:59 +0200
Andrew Lunn wrote:
> On Wed, Sep 09, 2020 at 06:25:45PM +0200, Marek Behún wrote:
> > Hello Andrew and Pavel,
> >
> > please review these patches adding support for HW controlled LEDs.
> > The main difference from previous version is that the API is now
On Wed, 9 Sep 2020 15:15:52 -0600
Rob Herring wrote:
> On Wed, Sep 09, 2020 at 06:25:46PM +0200, Marek Behún wrote:
> > Document binding for LEDs connected to and controlled by various chips
> > (such as ethernet PHY chips).
>
> If they are h/w controlled, then why are they in DT?
The idea
On Wed, 9 Sep 2020 15:31:22 -0600
Rob Herring wrote:
> On Wed, Sep 09, 2020 at 11:07:26PM +0200, Marek Behun wrote:
> > On Wed, 9 Sep 2020 14:59:23 -0600
> > Rob Herring wrote:
> >
> > > >
> > > > I don't know :) I copied this from other drivers
On Wed, 9 Sep 2020 22:48:15 +0200
Pavel Machek wrote:
> Hi!
>
> > Many an ethernet PHY (and other chips) supports various HW control modes
> > for LEDs connected directly to them.
>
> I guess this should be
>
> "Many ethernet PHYs (and other chips) support various HW control modes
> for
On Wed, 9 Sep 2020 14:59:23 -0600
Rob Herring wrote:
> >
> > I don't know :) I copied this from other drivers, I once tried setting
> > up environment for doing checking of device trees with YAML schemas,
> > and it was a little painful :)
>
> pip3 install dtschema ?
>
> Can you elaborate
Please ignore this series, still refactoring...
Please ignore this patch, still refactoring...
On Tue, 25 Aug 2020 10:13:59 +0200
Matthias Schiffer wrote:
> On Tue, 2020-07-28 at 17:05 +0200, Marek Behún wrote:
> > Hi,
> >
> > this is v4 of my RFC adding support for LEDs connected to Marvell
> > PHYs.
> >
> > Please note that if you want to test this, you still need to first
> > apply
>
On Tue, 28 Jul 2020 18:18:00 +0200
Andrew Lunn wrote:
> > +static int of_phy_register_led(struct phy_device *phydev, struct
> > device_node *np)
> > +{
> > + struct led_init_data init_data = {};
> > + struct phy_device_led *led;
> > + u32 reg;
> > + int ret;
> > +
> > + ret =
On Tue, 28 Jul 2020 18:28:16 +0200
Andrew Lunn wrote:
> > > @@ -736,6 +777,16 @@ struct phy_driver {
> > > int (*set_loopback)(struct phy_device *dev, bool enable);
> > > int (*get_sqi)(struct phy_device *dev);
> > > int (*get_sqi_max)(struct phy_device *dev);
> > > +
> > > + /* PHY LED
On Sat, 25 Jul 2020 20:48:46 +0200
Andrew Lunn wrote:
> > > > +#if 0
> > > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */
> > > > + /* TODO: Support DUAL MODE */
> > > > + if (color == LED_COLOR_ID_MULTI) {
> > > > + phydev_warn(phydev, "node %pOF:
On Sat, 25 Jul 2020 19:23:18 +0200
Andrew Lunn wrote:
> On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote:
> > This patch adds support for controlling the LEDs connected to several
> > families of Marvell PHYs via the PHY HW LED trigger API. These families
> > are: 88E1112, 88E1121R,
On Sat, 25 Jul 2020 17:03:42 +0200
Andrew Lunn wrote:
> Does hi-z mean off? In the implementation i did, i did not list off
> and on as triggers. I instead used them for untriggered
> brightness. That allowed the software triggers to work, so i had the
> PHY blinking the heartbeat etc. But i had
On Sat, 25 Jul 2020 11:21:24 +0200
Pavel Machek wrote:
> Hi!
>
> > Many PHYs support various HW control modes for LEDs connected directly
> > to them.
> >
> > This code adds a new private LED trigger called phydev-hw-mode. When
> > this trigger is enabled for a LED, the various HW control
On Sat, 25 Jul 2020 11:23:39 +0200
Pavel Machek wrote:
> Hi!
>
> > +static const struct marvell_led_mode_info marvell_led_mode_info[] = {
> > + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 },
> > + { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0
On Thu, 23 Jul 2020 23:35:31 +0200
Andrew Lunn wrote:
> Hi Marek
>
> I expect some of this should be moved into the phylib core. We don't
> want each PHY inventing its own way to do this. The core should
> provide a framework and the PHY driver fills in the gaps.
>
> Take a look at for example
On Thu, 23 Jul 2020 23:35:31 +0200
Andrew Lunn wrote:
> I thought the brightness file disappeared when a trigger takes
> over. So is this possible?
>
> Andrew
It does not disappear nor should it. When you have a LED with 10 levels
of brightness, you want to be able to configure with
On Mon, 13 Jul 2020 01:15:44 +0200
Marek Behun wrote:
> On Mon, 13 Jul 2020 00:38:21 +0200
> Ondřej Jirman wrote:
>
> > So after trying to use this, this seems to disallow the use of multiple HW
> > triggers per LED. That's fine by me, because using one HW sysfs configure
On Mon, 13 Jul 2020 00:38:21 +0200
Ondřej Jirman wrote:
> Hello,
>
> On Sun, Jul 12, 2020 at 09:11:11PM +0200, Pavel Machek wrote:
> > Hi!
> >
>
> []
>
> > }
> > diff --git a/include/linux/leds.h b/include/linux/leds.h
> > index 2451962d1ec5..cba52714558f 100644
> > ---
On Sun, 12 Jul 2020 21:11:11 +0200
Pavel Machek wrote:
> Hi!
>
> > > > > > Some LED controllers may come with an internal HW triggering
> > > > > > mechanism
> > > > > > for the LED and an ability to switch between user control of the
> > > > > > LED,
> > > > > > or the internal control. One
Hi Dan, one bug in this driver, see below.
On Mon, 22 Jun 2020 13:59:08 -0500
Dan Murphy wrote:
> Introduce the LP5036/30/24/18/12/9 RGB LED driver.
> The difference in these parts are the number of
> LED outputs where the:
>
> LP5036 can control 36 LEDs
> LP5030 can control 30 LEDs
> LP5024
On Sat, 4 Jul 2020 14:47:29 +0200
Pavel Machek wrote:
> Hi!
>
> > This is the multi color LED framework. This framework presents clustered
> > colored LEDs into an array and allows the user space to adjust the
> > brightness
> > of the cluster using a single file write. The individual
On Fri, 5 Jun 2020 19:10:58 +0100
Jonathan McDowell wrote:
> The QCA8337(N) has an SGMII port which can operate in MAC, PHY or BASE-X
> mode depending on what it's connected to (e.g. CPU vs external PHY or
> SFP). At present the driver does no configuration of this port even if
> it is selected.
On Mon, 18 May 2020 14:46:14 +0100
Lorenzo Pieralisi wrote:
> On Mon, May 18, 2020 at 12:30:04PM +0200, Pali Rohár wrote:
> > On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote:
> > > Hello,
> > >
> > > > Hello,
> > > >
> > > > On Thu, 30 Apr 2020 10:06:13 +0200
> > > > Pali Rohár wrote:
On Wed, 9 Oct 2019 07:38:03 +1100
Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 69eea31a26da ("arm64: dts: armada-3720-turris-mox: convert usb-phy to
> phy-supply")
>
> Fixes tag
>
> Fixes: eb6c2eb6c7fb ("usb: host: xhci-plat: Prevent an abnormally
>
This is weird, in the patch
Hi Austin,
this was already fixed and is staged for soc/for-next, see
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=for-next=6811d26df50d96635dd339cf8cdf43a6abc0c4b6
Thanks,
Marek
On Wed, 11 Sep 2019 14:59:38 +0900
Austin Kim wrote:
> The simple_write_to_buffer()
On Fri, 16 Aug 2019 23:41:06 +0100
Colin King wrote:
> From: Colin Ian King
>
> Currently the size_t variable res is being checked for
> an error failure however the unsigned variable is never
> less than zero so this test is always false. Fix this by
> making variable res ssize_t
>
>
1 - 100 of 125 matches
Mail list logo
