Hi!
> > > - Need to validate the uAPI and document it before moving
> > >this driver out of staging.
> >
> > > - Stabilize and document its sysfs interface.
> >
> > Would you mind starting with this one?
>
> Do you mean writing the ABI document for it? Surely I can do that,
> but
On Mon, May 17, 2021 at 11:02:58AM +0200, Mauro Carvalho Chehab wrote:
> Em Mon, 17 May 2021 10:18:57 +0200
> Greg KH escreveu:
>
> > On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote:
> > > Hi Greg,
> > >
> > > This series add support for the LEDs found at Intel NUCs since
On Sun, May 16, 2021 at 12:53:29PM +0200, Mauro Carvalho Chehab wrote:
> Some Intel Next Unit of Computing (NUC) machines have
> software-configured LEDs that can be used to display a
> variety of events:
>
> - Power State
> - HDD Activity
> - Ethernet
> - WiFi
> -
Em Mon, 17 May 2021 10:05:27 +0200
Pavel Machek escreveu:
> Hi!
>
> > > > - Need to validate the uAPI and document it before moving
> > > >this driver out of staging.
> > >
> > > > - Stabilize and document its sysfs interface.
> > >
> > > Would you mind starting with this
Em Mon, 17 May 2021 10:57:49 +0200
Mauro Carvalho Chehab escreveu:
> Em Mon, 17 May 2021 10:05:27 +0200
> Pavel Machek escreveu:
> > No. Take a look at triggers; for example hdd monitor should look very
> > much like existing disk trigger.
Btw, is there a way to trigger brightness?
When a
On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote:
> Hi Greg,
>
> This series add support for the LEDs found at Intel NUCs since
> NUC version 6.
>
> On several NUC models, the function of the LEDs are programmable,
> which allow them to indicate several different hardware
Em Mon, 17 May 2021 10:18:57 +0200
Greg KH escreveu:
> On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote:
> > Hi Greg,
> >
> > This series add support for the LEDs found at Intel NUCs since
> > NUC version 6.
> >
> > On several NUC models, the function of the LEDs are
Hi Pavel,
Em Sun, 16 May 2021 20:21:50 +0200
Pavel Machek escreveu:
> Hi!
>
> > - Need to validate the uAPI and document it before moving
> >this driver out of staging.
>
> > - Stabilize and document its sysfs interface.
>
> Would you mind starting with this one?
Do you mean
On Sun, May 16, 2021 at 12:53:30PM +0200, Mauro Carvalho Chehab wrote:
> - leds = output[0];
> + if (ver != LED_API_NUC6) {
> + ret = nuc_nmi_cmd(dev, LED_VERSION_CONTROL, input, output);
Does this need to be checked?
if (ret)
return ret;
> +
In the function ad7746_probe(), the return value of
devm_iio_device_register() can be zero or ret, thus it is
unnecessary to repeated check here. And delete unused
initialized value of 'ret', because it will be assigned by
the function i2c_smbus_write_byte_data().
Signed-off-by: Tang Bin
---
Am Montag, dem 17.05.2021 um 10:23 -0300 schrieb Ezequiel Garcia:
> On Mon, 2021-05-17 at 12:52 +0200, Lucas Stach wrote:
> > Hi Ezequiel,
> >
> > Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> > > Hi Lucas,
> > >
> > > On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
Em Mon, 17 May 2021 10:05:27 +0200
Pavel Machek escreveu:
> No. Take a look at triggers; for example hdd monitor should look very
> much like existing disk trigger.
Hmm... after looking at triggers, I'm not sure if this is the right
interface, nor if we're talking about the same thing.
See, at
On Mon, 2021-05-17 at 12:52 +0200, Lucas Stach wrote:
> Hi Ezequiel,
>
> Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> > Hi Lucas,
> >
> > On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
> > > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> >
Hi Ezequiel,
Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> Hi Lucas,
>
> On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
> > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> > > In order to be able to share the control hardware block between
>
On Sun, May 16, 2021 at 12:53:35PM +0200, Mauro Carvalho Chehab wrote:
> +static int nuc_wmi_query_leds_nuc6(struct device *dev)
> +{
> + // FIXME: add a check for the specific models that are known to work
> + struct nuc_wmi *priv = dev_get_drvdata(dev);
> + u8 cmd,
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210517
i386 randconfig-a001-20210517
i386 randconfig-a004-20210517
i386
lmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210517
i386 randconfig-a001-20210517
i386 randconfig-a004-202
randconfig-a003-20210517
i386 randconfig-a001-20210517
i386 randconfig-a004-20210517
i386 randconfig-a005-20210517
i386 randconfig-a002-20210517
i386 randconfig-a006-20210517
x86_64 randconfig
allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210517
i386 randconfig-a001-20210517
i386 randconfig-a004-20210517
i386 randconfig-a005-20210517
i386 randconfig
Hi Tang,
The patch looks overall good, though I think it could be split into two
pieces: one for simplifying ret declaration and another for removing the
check after device register.
Despite that, I guess Lucas might already be working on similar changes.
Hi Marcelo:
On 2021/5/18 6:14, Marcelo Schmitt wrote:
Hi Tang,
The patch looks overall good, though I think it could be split into two
pieces: one for simplifying ret declaration and another for removing the
check after device register.
Despite that, I guess Lucas might already be working on
21 matches
Mail list logo
