On Tue, Mar 02, 2021 at 05:07:55PM +0100, Bartosz Golaszewski wrote:
> On Tue, Mar 2, 2021 at 4:21 PM Andy Shevchenko
> wrote:
> Do you want me to take these, or will you include them in your PR?
I'll send PR.
I'm waiting for vger to process the queue (it has some lags).
--
With Bes
: warning: Function parameter or member 'fwnode' not described
in 'devm_irq_domain_create_sim'
.../irq_sim.c:240: warning: Excess function parameter 'fnode' description in
'devm_irq_domain_create_sim'
Signed-off-by: Andy Shevchenko
---
kernel/irq/irq_sim.c | 4 ++--
1 file changed, 2 insertions(+), 2
On Tue, Mar 02, 2021 at 05:34:48PM +0200, Andy Shevchenko wrote:
> We have (historically) different approaches how we identify the type
> of a given fwnode. Let's standardize them across the library code.
This patch has one functional mistake (see below), otherwise I will anyway wait
for
In the ACPI case we may use the firmware node in the similar way
as it's done for OF case. We may use that fwnode for other purposes
in the future.
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib-acpi.c | 7 +++
drivers/gpio/gpiolib-acpi.h | 4
drivers/gpio/gpiolib.c | 1
per.
Amend gpiolib.c and gpiolib-of.c code in order to group OF operations.
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib-of.c | 6 --
drivers/gpio/gpiolib.c| 9 -
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/g
:
unknown-1 ==> \_SB.PCI0.GIP0.GPO
unknown-2 ==> \_SB.NIO3
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
We have (historically) different approaches how we identify the type
of a given fwnode. Let's standardize them across the library code.
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git
; **\n");
> > + pr_warn("** the kernel, report this immediately to your system
> > **\n");
> > + pr_warn("** administrator!
> > **\n");
> > + pr_warn("**
> > **\n");
> > + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> > **\n");
> > +
> > pr_warn("**\n");
>
> Fortunately gcc is already smart enough to deduplicate identical strings,
> but only in the same source file.
--
With Best Regards,
Andy Shevchenko
future version of this, because some pieces of the code
(AFAICS from this message) looks suboptimal or dup or...
> On Tue, Feb 23, 2021 at 11:51 PM Asmaa Mnebhi wrote:
That said, will wait for v2 of this.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 02, 2021 at 05:14:30PM +0200, Mika Westerberg wrote:
> On Tue, Mar 02, 2021 at 05:09:24PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 02, 2021 at 03:48:43PM +0100, Linus Walleij wrote:
> > > On Thu, Feb 25, 2021 at 5:33 PM Andy Shevchenko
> > > wrote:
>
On Tue, Mar 02, 2021 at 02:51:45PM +, Sudip Mukherjee wrote:
> On Mon, Mar 1, 2021 at 12:12 PM Andy Shevchenko
> wrote:
> >
> > On Sun, Feb 28, 2021 at 11:27:10PM +, Sudip Mukherjee wrote:
> > > On Fri, Feb 26, 2021 at 07:03:09PM +0200, Andy Shevchenko wrote:
&
On Tue, Mar 02, 2021 at 03:48:43PM +0100, Linus Walleij wrote:
> On Thu, Feb 25, 2021 at 5:33 PM Andy Shevchenko
> wrote:
>
> > On some systems the ACPI tables has wrong pin number and instead of
> > having a relative one it provides an absolute one in the global
In ->remove() unregister resources in reversed order, i.e. MFD devices first
followed by I²C clock.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel_quark_i2c_gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/
I²C header provides a descriptive definitions for standard bus speeds.
Use them instead of plain numbers.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel_quark_i2c_gpio.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b
It's convenient and less error prone to use definitions to address
different cells in an array. For this purpose we may reuse existing
BAR definitions.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel_quark_i2c_gpio.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions
Cc: Rikard Falkeborn
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel_quark_i2c_gpio.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 55a9e017edee..124c0ee84169 100644
--- a/d
The device pointer in the custom structure is not used anywhere,
remove it for good.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel_quark_i2c_gpio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index
The commit 8b9d6802583a ("ACPI: Constify acpi_bus helper functions,
switch to macros") only changed functions for CONFIG_ACPI=y case.
This part adjusts the rest.
Fixes: 8b9d6802583a ("ACPI: Constify acpi_bus helper functions, switch to
macros")
Cc: Sakari Ailus
Signed-off
in sata_dwc_isr(), which is odd.
Thanks for this information, it makes sense to me. Perhaps you need to
put this into the commit message to justify the need of the change.
> There is no issue currently does not
> mean it will never happen in the future. So I suggest the maintainer of
> function
> sata_dwc_isr() to fix this issue.
--
With Best Regards,
Andy Shevchenko
ot;checkpatch: look for symbolic permissions and suggest octal instead").
> >
> > Note: S_IFREG flag is added to the mode by __debugfs_create_file()
> > in fs/debugfs/inode.c
> >
> > Suggested-by: Andy Shevchenko
> > Signed-off-by: Drew Fustini
>
> Patch
At least one module will benefit from using next_arg() helper.
Let's export it for that module and others if they consider it
helpful.
Signed-off-by: Andy Shevchenko
---
lib/cmdline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index 5d474c626e24
cmdline library provides next_arg() helper to traverse over parameters
and their values given in command line. Replace custom approach in the driver
by it.
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpio-aggregator.c | 39 +-
1 file changed, 5 insertions
atches applied, thanks!
Ooops, you are fast!
Anyway, I have tested with gpio-aggregator (w/o this series it
sparkles with all possible bugs).
Tested-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 01, 2021 at 04:34:41PM +0100, Jiri Kosina wrote:
> On Mon, 1 Mar 2021, Benjamin Tissoires wrote:
> > On Fri, Feb 26, 2021 at 8:34 PM Andy Shevchenko
> > wrote:
> > >
> > > The driver depends on ACPI, ACPI_PTR() resolution is always the same.
>
se a failure with
> nodes that are already registered.
>
> Fixing that by incrementing the reference count of the nodes
> that have already been registered, and only registering the
> new nodes. Also, clarifying the behaviour in the function
> documentation.
Reviewed-by: An
On Mon, Mar 01, 2021 at 05:30:11PM +0300, Heikki Krogerus wrote:
> Software node can not be registered before its parent.
Reviewed-by: Andy Shevchenko
Tested-by: Andy Shevchenko
(On Intel Galileo Gen 2 with some custom patches to convert gpio-dwapb et al.
to use swnodes. Those patc
There is no point to have non-constant device properties in this driver.
Thus, constify them for good.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel-lpss-acpi.c | 8
drivers/mfd/intel-lpss-pci.c | 10 +-
drivers/mfd/intel-lpss.h | 2 +-
3 files changed, 10
From: Heikki Krogerus
The old device property API is going to be removed and
replaced with the newer software node API. This prepares MFD
subsystem for the transition.
Signed-off-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
---
drivers/mfd/mfd-core.c | 9 +
include/linux/mfd
From: Heikki Krogerus
Software node was always created for the device if it was
supplied with additional device properties, so those nodes
might as well be constant.
Signed-off-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
---
drivers/mfd/intel-lpss-acpi.c | 24
From: Heikki Krogerus
>From now on only accepting complete software nodes.
Signed-off-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
---
drivers/mfd/mfd-core.c | 6 --
include/linux/mfd/core.h | 4
2 files changed, 10 deletions(-)
diff --git a/drivers/mfd/mfd-core.c b/driv
On Mon, Mar 01, 2021 at 02:57:53PM +0100, Bartosz Golaszewski wrote:
> On Thu, Feb 25, 2021 at 4:07 PM Andy Shevchenko
> wrote:
> > On Tue, Feb 23, 2021 at 01:51:53PM +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 23, 2021 at 04:35:58PM +0800, Yang Li wrote:
> &
tem() or so.
--
With Best Regards,
Andy Shevchenko
on 2016 and 2017 MacBookPro's, also known as the iBridge. The
> drivers
> + for the Touch Bar (apple-touchbar) and light sensor (hid-sensor-hub
> + and hid-sensor-als) need to be enabled separately.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called apple-ibridge.
--
With Best Regards,
Andy Shevchenko
follow everything that some (non-ideal) tool
reports? I don't think so.
For all my experiments with that hardware, I haven't heard about the
issue with NULL pointers. Useless checks make code harder to read and
CPU to waste cycles. It might be maintainers of this driver consider
otherwise, so not my call.
--
With Best Regards,
Andy Shevchenko
sgs[outcnt++] = _buf;
> + }
...
> +
> +
One blank line is enough.
...
> + ret = virtio_i2c_send_reqs(vq, reqs, msgs, num);
> + if (ret == 0)
> + goto err_unlock_free;
> + else
Redundant.
> + nr = ret;
--
With Best Regards,
Andy Shevchenko
On Sun, Feb 28, 2021 at 11:27:10PM +, Sudip Mukherjee wrote:
> On Fri, Feb 26, 2021 at 07:03:09PM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 16, 2021 at 01:07:39PM +0200, Andy Shevchenko wrote:
> > > Introduce module_parport_driver() helper macro to reduce boilerplate
>
d SMBus support bidirectional transfers as well. I think two buffers is
the right thing to do.
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 01, 2021 at 02:09:25PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 01, 2021 at 05:24:41PM +0530, Viresh Kumar wrote:
> > On 01-03-21, 14:41, Jie Deng wrote:
> > > +/**
> > > + * struct virtio_i2c_req - the virtio I2C request structure
> > > + * @o
enum iio_event_info info, int *val,
> > + int *val2)
Ditto.
...
> > +static int __maybe_unused tsl2591_resume(struct device *dev)
> > +{
> > + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > + struct tsl2591_chip *chip = iio_priv(indio_dev);
> > + int ret;
> > + int power_state;
> > +
> > + if (chip->events_enabled)
> > + power_state = TSL2591_PWR_ON |
> > + TSL2591_ENABLE_ALS_INT |
> > + TSL2591_ENABLE_ALS;
At least the last two can be on one line.
> > + else
> > + power_state = TSL2591_PWR_ON | TSL2591_ENABLE_ALS;
> > +
> > + mutex_lock(>als_mutex);
> > + ret = tsl2591_set_power_state(chip, power_state);
> > + mutex_unlock(>als_mutex);
> > +
> > + return ret;
> > +}
...
> > +static const struct dev_pm_ops tsl2591_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> > + pm_runtime_force_resume)
One line?
> > + SET_RUNTIME_PM_OPS(tsl2591_suspend, tsl2591_resume, NULL)
> > +};
...
> > +static irqreturn_t tsl2591_event_handler(int irq, void *private)
> > +{
> > + /* Clear ALS irq */
> > + ret = i2c_smbus_write_byte(client, TSL2591_CMD_SF_CALS_NPI);
> > + if (ret < 0)
> > + dev_err(>dev, "Failed to clear als irq\n");
In the IRQ handler? Hmm... It potentially floods the logs.
> > + return IRQ_HANDLED;
> > +}
...
> > +static const struct of_device_id tsl2591_of_match[] = {
> > + { .compatible = "amstaos,tsl2591"},
> > + {},
Comma is not needed on the terminator line.
> > +};
--
With Best Regards,
Andy Shevchenko
reproduce this?
--
With Best Regards,
Andy Shevchenko
On Sun, Feb 28, 2021 at 11:29 AM Andy Shevchenko
wrote:
>
> On Sun, Feb 28, 2021 at 11:07 AM Andy Shevchenko
> wrote:
> > On Friday, February 26, 2021, Rasmus Villemoes
> > wrote:
> >>
> >> The only purpose of this driver is to serve as a consumer of t
On Sun, Feb 28, 2021 at 11:07 AM Andy Shevchenko
wrote:
> On Friday, February 26, 2021, Rasmus Villemoes
> wrote:
>>
>> The only purpose of this driver is to serve as a consumer of the input
>> clock, to prevent it from being disabled by clk_disable_unused().
>
Switch to the new style i2c-driver probe_new probe function.
Signed-off-by: Andy Shevchenko
---
v2: new patch
drivers/hid/i2c-hid/i2c-hid-acpi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c
b/drivers/hid/i2c-hid/i2c-hid-acpi.c
Move static GUID variable out of the function and add a comment
how it looks like in the human readable representation.
While at it, include uuid.h since the guid_t type is defined in it.
Signed-off-by: Andy Shevchenko
---
v2: rebased on top of patch 1 that used to be separate change
drivers
Currently the ACPI companion and handle are retrieved and checked
a few times in different functions. Instead get ACPI companion only
once and reuse it everywhere.
Signed-off-by: Andy Shevchenko
---
v2: used companion indeed everywhere (i2c_hid_acpi_shutdown_tail() included)
drivers/hid/i2c-hid
The driver depends on ACPI, ACPI_PTR() resolution is always the same.
Otherwise a compiler may produce a warning.
That said, the rule of thumb either ugly ifdeffery with ACPI_PTR or
none should be used in a driver.
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/hid/i2c-hid/i2c-hid
On Fri, Feb 26, 2021 at 8:35 PM Andy Shevchenko
wrote:
>
> The driver depends on ACPI, ACPI_PTR() resolution is always the same.
> Otherwise a compiler may produce a warning.
>
> That said, the rule of thumb either ugly ifdeffery with ACPI_PTR or
> none should be used in a drive
On Fri, Feb 26, 2021 at 8:32 PM Andy Shevchenko
wrote:
>
> Move static GUID variable out of the function and add a comment
> how it looks like in the human readable representation.
>
> While at it, include uuid.h since the guid_t type is defined in it.
Oh, I see more improvements
On Fri, Feb 26, 2021 at 8:44 PM Andy Shevchenko
wrote:
>
> Currently the ACPI companion and handle are retrieved and checked
> a few times in different functions. Instead get ACPI companion only
> once and reuse it everywhere.
>
> Signed-off-by: Andy Shevchenko
> ---
>
&g
Currently the ACPI companion and handle are retrieved and checked
a few times in different functions. Instead get ACPI companion only
once and reuse it everywhere.
Signed-off-by: Andy Shevchenko
---
It depends on previously sent patch that moves GUID out of the function.
If needed I can resend
The driver depends on ACPI, ACPI_PTR() resolution is always the same.
Otherwise a compiler may produce a warning.
That said, the rule of thumb either ugly ifdeffery with ACPI_PTR or
none should be used in a driver.
Signed-off-by: Andy Shevchenko
---
drivers/hid/i2c-hid/i2c-hid-acpi.c | 2 +-
1
Move static GUID variable out of the function and add a comment
how it looks like in the human readable representation.
While at it, include uuid.h since the guid_t type is defined in it.
Signed-off-by: Andy Shevchenko
---
drivers/hid/i2c-hid/i2c-hid-acpi.c | 9 ++---
1 file changed, 6
On Tue, Feb 16, 2021 at 01:31:48PM +0200, Andy Shevchenko wrote:
> When requesting optional GPIO echo line, bail out on error,
> so user will know that something wrong with the existing property.
Guys, any comments on this series?
> Signed-off-by: Andy Shevchenko
> ---
> driv
On Tue, Feb 16, 2021 at 01:07:39PM +0200, Andy Shevchenko wrote:
> Introduce module_parport_driver() helper macro to reduce boilerplate
> in the existing and new code.
Sudip, any comments on this?
> Signed-off-by: Andy Shevchenko
> ---
> v2: fixed typo in the macro
> inclu
place some code in pcim_release(),
> they are equivalent, and no functional change. It is more explicit
> that pcim_alloc_irq_vectors() is a device-managed function.
Thanks!
Reviewed-by: Andy Shevchenko
> Suggested-by: Andy Shevchenko
> Signed-off-by: Dejin Zheng
> ---
> v4
v4l2_pix_format structure
> directly. This reduces the stack usage to 612 bytes, and it could
> be reduced further by only storing the three members that are used.
Good to me!
Reviewed-by: Andy Shevchenko
> Signed-off-by: Arnd Bergmann
> ---
> .../staging/media/atomisp/pci/atom
OPROBE set
unexpected IRQ trap at vector 20
Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on
Galileo Gen 2")
Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the
GPIO-lib-based IRQ-chip")
Signed-off-by: Andy Shev
nders on
Galileo Gen 2")
Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the
GPIO-lib-based IRQ-chip")
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib-acpi.c | 7 ++-
include/linux/gpio/consumer.h | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
and ACPI
subsystems I guess). This is material for v5.12-rcX.
[1]:
https://lore.kernel.org/linux-gpio/20200520211916.25727-1-andriy.shevche...@linux.intel.com/
Andy Shevchenko (3):
gpiolib: acpi: Add ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER quirk
gpiolib: acpi: Allow to find GpioInt() resource by name
;gpio: pca953x: Override IRQ for one of the expanders on
Galileo Gen 2")
Depends-on: 0ea683931adb ("gpio: dwapb: Convert driver to using the
GPIO-lib-based IRQ-chip")
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib-acpi.c | 12
include/linux/acpi.h| 10
On Thu, Feb 25, 2021 at 5:11 AM Hans de Goede wrote:
> On 2/24/21 1:51 PM, Andy Shevchenko wrote:
> > On Tue, Feb 23, 2021 at 08:25:35PM +0100, Hans de Goede wrote:
> >> On 2/23/21 6:22 PM, Andy Shevchenko wrote:
> >>> It's better to describe the I²C contro
On Tue, Feb 23, 2021 at 01:51:53PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 23, 2021 at 04:35:58PM +0800, Yang Li wrote:
> > fixed the following coccicheck:
> > ./drivers/gpio/gpiolib-acpi.c:176:7-27: ERROR: Threaded IRQ with no
> > primary handler requested without IRQF_
he
> data to be transmitted or received on the I2C bus, so we should use the
> lower 8 bits to get the real data length.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Liguang Zhang
> ---
> drivers/i2c/busses/i2c-designware-core.h | 2 ++
> drivers/i2c/busses/i2c-designware-master.c |
On Wed, Feb 24, 2021 at 03:42:11PM +0100, Daniel Lezcano wrote:
> The macros for the unit conversion for frequency are duplicated in
> different places.
>
> Provide these macros in the 'units' header, so they can be reused.
For the all that have not been tagged:
Reviewed-by: And
AT) <= I2C_SMBUS_BLOCK_MAX
&& tmp > 0) {
...here?
> len = i2c_dw_recv_len(dev, tmp);
> }
> *buf++ = tmp;
> --
> 2.19.1.6.gb485710b
>
--
With Best Regards,
Andy Shevchenko
On Tue, Feb 23, 2021 at 08:25:35PM +0100, Hans de Goede wrote:
> On 2/23/21 6:22 PM, Andy Shevchenko wrote:
> > It's better to describe the I²C controller and associated IRQ domain with
> > fwnode, so they will find their place in the hierarchy in sysfs and also
> >
t_*() and they do increase the reference
counter one way or the other.
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 24, 2021 at 10:16 AM Yang Li wrote:
>
> Fix the following coccicheck warning:
> ./arch/x86/platform/intel/iosf_mbi.c:482:0-23: WARNING: iosf_mcr_fops
> should be defined with DEFINE_DEBUGFS_ATTRIBUTE
Acked-by: Andy Shevchenko
> Reported-by: Abaci Robot
> Sign
It's better to describe the I²C controller and associated IRQ domain with
fwnode, so they will find their place in the hierarchy in sysfs and also
make easier to debug.
Signed-off-by: Andy Shevchenko
---
Hans, unfortunately I have no device at hand with INT34D3. This is only compile
tested
On Mon, Feb 22, 2021 at 10:35:44PM +, Daniel Scally wrote:
> On 22/02/2021 14:58, Andy Shevchenko wrote:
> > On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally wrote:
...
> >> + if (obj->buffer.length > sizeof(*cldb)) {
> >> + dev_err(>
always request
> with IRQF_ONESHOT
Acked-by: Andy Shevchenko
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/gpio/gpiolib-acpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib
tional, you won't need this additional check.
> + clk_unregister(int3472->clock.clk);
> +
> + if (int3472->clock.cl)
> + clkdev_drop(int3472->clock.cl);
> +
> + gpiod_put(int3472->regulator.gpio);
> + gpiod_put(int3472->clock.ena_gpio);
> + gpiod_put(int3472->clock.led_gpio);
> +
> + acpi_dev_put(int3472->sensor);
> +
> + kfree(int3472->sensor_name);
> + kfree(int3472);
> +
> + return 0;
> +}
...
> + ret = skl_int3472_fill_cldb(adev, );
> + if (!ret && cldb.control_logic_type != 2) {
> + dev_err(>dev, "Unsupported control logic type %u\n",
> + cldb.control_logic_type);
> + return -EINVAL;
> + }
> +
> + if (ret)
> + cldb_present = false;
if (ret)
...
else if (...) {
...
return ...;
}
--
With Best Regards,
Andy Shevchenko
drivers/platform/x86/intel-int3472/intel_skl_int3472_common.c
> create mode 100644
> drivers/platform/x86/intel-int3472/intel_skl_int3472_common.h
> create mode 100644
> drivers/platform/x86/intel-int3472/intel_skl_int3472_discrete.c
> create mode 100644
> drivers/platform/x86/intel-int3472/intel_skl_int3472_tps68470.c
>
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally wrote:
>
> This driver only covered one scenario in which ACPI devices with _HID
> INT3472 are found, and its functionality has been taken over by the
> intel-skl-int3472 module, so remove it.
As long as patch 5 accepted
Acked-by: And
fect
Which one? "the acpi_...() function"
> for that purpose.
>
> As it's currently only used internally within the GPIO layer, provide and
> export a wrapper function that additionally holds a reference to the GPIO
> device.
Reviewed-by: Andy Shevchenko
after address
ot;
> the dependee, so add a callback and a wrapper to walk over the
> acpi_dep_list and return the dependent ACPI device.
>
Reviewed-by: Andy Shevchenko
Nit-picks below as usual :-)
> Signed-off-by: Daniel Scally
> ---
> Changes in v3:
> - Switched from
can be applied to all the dependencies in acpi_dep_list.
> Replace all existing calls to the function with calls to a wrapper, passing
> a callback that applies the same dependency reduction.
The code looks okay to me, if it was the initial idea, feel free to add
Reviewed-by: Andy Shevchenko
On Fri, Feb 19, 2021 at 02:09:03PM +, Sven Schuchmann wrote:
> > Von: Andy Shevchenko
> > Gesendet: Freitag, 19. Februar 2021 14:56
> > > > > > Can you or Dan submit patch getting the regulator support to work?
> > > > > > If
> > >
unterpart why not just an inline
> function like the one below.
It's a good suggestion, thanks!
Still we need to amend pcim_release() to explicitly show that we call
pci_free_irq_vectors().
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 19, 2021 at 3:21 PM Maciej Kwapulinski
wrote:
> Andy Shevchenko writes:
> > On Tue, Feb 16, 2021 at 6:11 PM Maciej Kwapulinski
> > wrote:
> >>
>
> >> +err_clear_master:
> >> + pci_clear_master(pcidev);
> >> +err_re
oving), sorry.
>
> No problem. It seems Andy submitted series for this.
Ah, now I understand what you, Sven, meant.
I didn't touch regulator code, so it left the same, but making it work
probably needs just enabling during ->probe().
--
With Best Regards,
Andy Shevchenko
efault setting from DT
> https://www.spinics.net/lists/linux-leds/msg17596.html
> * Fix regulator https://www.spinics.net/lists/linux-leds/msg17631.html
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 19, 2021 at 12:19:20PM +0100, Robert Richter wrote:
> On 18.02.21 16:01:56, Andy Shevchenko wrote:
> > The problem this series solves is an imbalanced API.
>
> This (added) API is bloated and incomplete. It adds functions without
> benefit, the only is to have a
On Fri, Feb 19, 2021 at 12:27:55PM +0100, Pavel Machek wrote:
> Hi!
>
> > Add missed bits.h and convert to BIT() in lp50xx_set_banks().
> >
> > Signed-off-by: Andy Shevchenko
>
> Thanks,
Thanks!
> I applied whole series except this one...
>
> <
On Thu, Feb 18, 2021 at 11:24:19AM -0800, Yury Norov wrote:
> On Thu, Feb 18, 2021 at 05:15:43PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 17, 2021 at 08:05:06PM -0800, Yury Norov wrote:
> > > This series introduces fast paths for find_bit() routines. It is
> > > ben
eing resources will take automatically when device is gone.
Acked-by: Andy Shevchenko
One side note below.
> Signed-off-by: Dejin Zheng
> ---
> v3 -> v4:
> - add some commit comments.
> v2 -> v3:
> - simplify the error handling path.
> v1 -> v2:
>
ing to maintain it.
Perhaps reviewers as well, like Rasmus, if he is okay with that, of course?
Otherwise, why not?
Acked-by: Andy Shevchenko
> Signed-off-by: Yury Norov
> ---
> MAINTAINERS | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/MAINTAINERS b
t; + if (unlikely(offset >= size))
> + return size;
> + val = *addr & GENMASK(size - 1, offset);
Yeah, GENMASK() basically for constant values or cases like (x,0). I think here
is something what has been done in BITMAP_FIRST/LAST_WORD_MASK will give better
results.
> + return val ? __ffs(val) : size;
> + }
--
With Best Regards,
Andy Shevchenko
uot;Enable fast path code generation"
> + default y
> + help
> + This option enables fast path optimization with the cost of increasing
> + the text section.
--
With Best Regards,
Andy Shevchenko
ntk.h
module.h
types.h
The rest seems fine because they are guaranteed to be included by
acpi.h (IIUC about fwnode API and acpi_mdio includes MDIO PHY APIs).
--
With Best Regards,
Andy Shevchenko
handle_put(dpmac_node);
> + if (is_of_node(dpmac_node))
> + fwnode_handle_put(dpmac_node);
Also not sure that you need a check in the above code excerpts.
--
With Best Regards,
Andy Shevchenko
amper probed via the device tree will still have
> +* precedence.
> +*/
> + if (mii_ts)
> + phy->mii_ts = mii_ts;
I'm wondering if the belo form is better to read
phy->mii_ts = mii_ts ?: phy->mii_ts;
--
With Best Regards,
Andy Shevchenko
that if we want to use PCI IRQ allocation API the
caller must know what's going on. Hiding this behind the scenes is not good.
And this series unhides that.
Also, you may go and clean up all pci_free_irq_vectors() when
pcim_enable_device() is called, but I guess you will get painful process and
rejection in a pile of cases.
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 17, 2021 at 3:11 PM Bedel, Alban wrote:
> On Tue, 2021-02-16 at 19:50 +0200, Andy Shevchenko wrote:
> > On Tue, Feb 16, 2021 at 6:37 PM Bedel, Alban
> > wrote:
> > > On Mon, 2021-02-15 at 14:53 +0200, Andy Shevchenko wrote:
> > > > On Thu,
maybe somewhere under
printk) and export to everybody to use.
--
With Best Regards,
Andy Shevchenko
e.
Perhaps as a compromise you may add this short sentence to your commit
messages, like "the freeing resources will take automatically when device
is gone".
--
With Best Regards,
Andy Shevchenko
ry about this. And I really can't explain its operation
> mechanism to you in a sentence or two. If you are really interested, you
> can read the relevant code.
I tend on agree on the above. It would be enough to spell it clearly that it's
part of devres API (Managed Device Resource) and we are fine.
--
With Best Regards,
Andy Shevchenko
On Tue, Feb 16, 2021 at 10:00:42AM -0800, Yury Norov wrote:
> On Tue, Feb 16, 2021 at 11:14:23AM +0200, Andy Shevchenko wrote:
> > On Mon, Feb 15, 2021 at 01:30:44PM -0800, Yury Norov wrote:
> > > [add David Laight ]
> > >
> > > On Sat, Jan 30, 2021 a
On Wed, Feb 17, 2021 at 12:45 AM Drew Fustini wrote:
>
> Document debugfs directories and files created for pinctrl subsystem.
Thanks for doing this!
I won't bikeshed now because it's about debugfs anyway, so
Reviewed-by: Andy Shevchenko
> Suggested-by: Andy Shevchenko
> Signed-
y particularly complex conflicts.
Yes, the file removal is the right thing to do.
Thanks!
--
With Best Regards,
Andy Shevchenko
801 - 900 of 17509 matches
Mail list logo
