On Sun, 2018-07-29 at 15:49 +0300, Andy Shevchenko wrote:
> On Fri, 2018-07-27 at 16:10 -0500, Bjorn Helgaas wrote:
> Do you think variant with ##vend##dev is better? I will update it for
> v4
> if needed.
Okay, I have sent v4 with your comment addressed.
--
Andy Shevchenko
Intel Finland Oy
-by: Andy Shevchenko
---
- Add vend to the device (Bjorn)
Bjorn, this also looks good.
drivers/net/wireless/ralink/rt2x00/rt2x00pci.h | 6 --
include/linux/pci.h| 15 +++
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net
On Fri, 2018-07-27 at 16:10 -0500, Bjorn Helgaas wrote:
> On Fri, Jul 27, 2018 at 11:49:44PM +0300, Andy Shevchenko wrote:
> > There are a lot of examples in the kernel where PCI_VDEVICE() is
> > used and still
> > looks not so convenient due to additional driver_da
.
Signed-off-by: Andy Shevchenko
---
- fix commit message (Randy)
drivers/net/wireless/ralink/rt2x00/rt2x00pci.h | 6 --
include/linux/pci.h| 15 +++
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00
On Fri, 2018-07-27 at 13:42 -0700, Randy Dunlap wrote:
> On 07/27/2018 01:41 PM, Andy Shevchenko wrote:
> > On Fri, 2018-07-27 at 23:39 +0300, Andy Shevchenko wrote:
> > > There are a lot of examples in the kernel where PCI_VDEVICE() is
> > > used
> > > and sti
-by: Andy Shevchenko
---
drivers/net/wireless/ralink/rt2x00/rt2x00pci.h | 6 --
include/linux/pci.h| 15 +++
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
b/drivers/net/wireless/ralink
On Fri, 2018-07-27 at 23:39 +0300, Andy Shevchenko wrote:
> There are a lot of examples in the kernel where PCI_VDEVICE() is used
> and still
> looks not so convenient due to additional driver_data field attached.
>
> Introduce PCI_DEVICE_DATA() macro to fully describe
-by: Andy Shevchenko
---
drivers/net/wireless/ralink/rt2x00/rt2x00pci.h | 6 --
include/linux/pci.h| 15 +++
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
b/drivers/net/wireless/ralink
you encounter this null pointer deref?
>
> Is this happen even when there is not wifi firmware?
> boot without any firmware in the filesystem and then trigger a reboot
Something like the above I had noticed for a long (couple of kernel
releases?) time, but wasn't a big priority to me.
Though, I can test this on my side.
P.S. I think rmmod or echo > unbind will trigger that as well.
--
With Best Regards,
Andy Shevchenko
On Tue, May 22, 2018 at 6:30 AM, Yisheng Xie <xieyishe...@huawei.com> wrote:
>> But it's up tu Loca.
Shame on me. I meant Luca, of course!
Luca, sorry.
> OK, I will change it if Loca agree your opinion.
--
With Best Regards,
Andy Shevchenko
t;
bt_force_... = ret;
But it's up tu Loca.
>
> ret = 0;
--
With Best Regards,
Andy Shevchenko
__func__ use dev_dbg() in "NFC: fdp: Fix possible
> buffer overflow in WCS4000 NFC driver" patch.
>
> Also drivers/nfc/fdp/ is full of __func__ parameter usage in
> dev_dbg(),
> so submitting a new patch separately to clean that up.
>
After addressing one comment, FWIW
t;next_read_size = 5;
Shouldn't be this magic replaced by
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
?
> + goto flush;
> + }
> } else {
> phy->next_read_size =
> FDP_NCI_I2C_MIN_PAYLOAD;
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
__func__);
> + dev_dbg(>dev, "corrupted packet\n");
> phy->next_read_size = 5;
> goto flush;
> }
> @@ -215,7 +211,6 @@ static irqreturn_t fdp_nci_i2c_irq_thread_fn(int
> irq, void *phy_id)
> }
>
> client = phy->i2c_dev;
> - dev_dbg(>dev, "%s\n", __func__);
>
> r = fdp_nci_i2c_read(phy, );
>
> @@ -296,8 +291,6 @@ static int fdp_nci_i2c_probe(struct i2c_client
> *client)
> u32 clock_freq;
> int r = 0;
>
> - dev_dbg(dev, "%s\n", __func__);
> -
> if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> {
> nfc_err(dev, "No I2C_FUNC_I2C support\n");
> return -ENODEV;
> @@ -359,8 +352,6 @@ static int fdp_nci_i2c_remove(struct i2c_client
> *client)
> {
> struct fdp_i2c_phy *phy = i2c_get_clientdata(client);
>
> - dev_dbg(>dev, "%s\n", __func__);
> -
> fdp_nci_remove(phy->ndev);
> fdp_nci_i2c_disable(phy);
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
On Wed, 2018-05-02 at 23:19 +0530, Amit Pundir wrote:
> - dev_dbg(dev, "%s\n", __func__);
> + dev_dbg(dev, "\n");
If one enables function tracer this will be redundant completely.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
+ }
> } else {
> phy->next_read_size =
> FDP_NCI_I2C_MIN_PAYLOAD;
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
n->aid_len + transaction-
> >params_len + 4) {
> + devm_kfree(dev, transaction);
Oh, no.
This is not memory leak per se, this is bad choice of devm_ API where it
should use plain kmalloc() / kfree().
> return -EPROTO;
> + }
--
Andy She
g on your side should be done.
--
With Best Regards,
Andy Shevchenko
read
> - q = >ack_wait_queue;
> spin_lock_irqsave(>lock, flags);
>
> skb_queue_walk(q, skb) {
--
With Best Regards,
Andy Shevchenko
-X status
(enabled/disabled)
So, if there is no MSI-X involved or MSI-X is handled in the same way
as MSI in the driver, one can use
pci_dev_msi_enabled() instead.
> Are everyone happy with this plan?
Sounds reasonable.
--
With Best Regards,
Andy Shevchenko
.cocci
> 0-day tested with no failures.
>
Makes sense.
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
> Suggested-by: Luis R. Rodriguez <mcg...@kernel.org>
> Signed-off-by: Himanshu Jha <himanshujha199...@gmail.com>
> ---
> .../net/wireless/broadcom/brcm8021
/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
> index a319bf1e49de..ef5c16dfabfa 100644
Acked-by: Andy Shevchenko <andy.shevche...@gmail.com>
for PDx86 changes.
--
With Best Regards,
Andy Shevchenko
:310: recipe for target
'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed
Seems like something happened with W=1 and wrong kernel doc format.
As a quick fix remove dubious /** in the code.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/net/wi
On Tue, Oct 3, 2017 at 4:22 AM, Jérémy Lefaure
<jeremy.lefa...@lse.epita.fr> wrote:
> On Mon, 2 Oct 2017 16:07:36 +0300
> Andy Shevchenko <andy.shevche...@gmail.com> wrote:
>
>> > + {_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0),
>> > 26
ore0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 26,
> 192,
> +32},
For all such cases I would rather put on one line disregard checkpatch
warning for better readability.
--
With Best Regards,
Andy Shevchenko
On Wed, 2017-08-30 at 14:38 +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> >
> > I have just sent a v2 of this patch sep
On Wed, 2017-08-02 at 14:44 +, Kalle Valo wrote:
> Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>
> > There are new types and helpers that are supposed to be used in new
> > code.
> >
> > As a preparation to get rid of legacy types and API
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drive
On Sun, 2017-07-30 at 10:37 -0700, Greg Kroah-Hartman wrote:
> On Sun, Jul 30, 2017 at 08:26:48PM +0300, Andy Shevchenko wrote:
> > On Sun, Jul 30, 2017 at 6:32 PM, Greg Kroah-Hartman
> > <gre...@linuxfoundation.org> wrote:
> > > Doesn't apply to the staging tree a
On Sun, Jul 30, 2017 at 6:32 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Wed, Jul 26, 2017 at 01:01:41PM +0300, Andy Shevchenko wrote:
>> On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
>> > There are new types and helpers that are supposed to
On Wed, 2017-07-26 at 02:27 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 03:35:01 AM Andy Shevchenko wrote:
> > On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki <r...@rjwysocki.ne
> > t> wrote:
> > > Andy, do you want me to apply th
On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
> There are new types and helpers that are supposed to be used in new
> code.
>
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
>
> While here, re-indent couple of lines to
On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> On Tuesday, July 25, 2017 05:12:35 PM Mika Westerberg wrote:
>> On Wed, Jul 19, 2017 at 09:28:57PM +0300, Andy Shevchenko wrote:
>> > There are new types and helpers that are suppose
On Thu, 2017-07-20 at 13:18 +0100, Ard Biesheuvel wrote:
> On 19 July 2017 at 19:28, Andy Shevchenko
> <andriy.shevche...@linux.intel.com> wrote:
> > There are new types and helpers that are supposed to be used in new
> > code.
> >
> > As a preparation to get r
> mode code.
It will work still the same after this change.
--
With Best Regards,
Andy Shevchenko
There is no more users for uapi/uuid.h. Remove it for good.
Anyone needs it in user space better to use libuuid.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
include/linux/uuid.h | 20 +++-
include/uapi/linux/uuid.
"K. Y. Srinivasan" <k...@microsoft.com>
Cc: Haiyang Zhang <haiya...@microsoft.com>
Cc: Stephen Hemminger <sthem...@microsoft.com>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Andy Shevchenko (6):
efi: Switch to use new
com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/mei/bus-fixup.c| 35 +++
drivers/misc/mei/bus.c | 14 +++---
drivers/misc/mei/client.c | 21 ++---
drivers/misc
artman <gre...@linuxfoundation.org>
Cc: sparmaintai...@unisys.com
Cc: de...@driverdev.osuosl.org
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/staging/unisys/Documentation/overview.txt | 14 +++
drivers/staging/unisys/include/channe
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Signed-off-by: And
vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/acpi/property.c | 50 -
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 917c7
them...@microsoft.com>
Cc: de...@linuxdriverproject.org
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/hv/channel.c| 4 +-
drivers/hv/channel_mgmt.c | 18
drivers/hv/hyperv_vmbus.h | 4 +-
drivers/hv/vmbus_drv.c
Use unified device properties API in meaningful way.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st-nci/i2c.c | 30 ++
drivers/nfc/st-nci/spi.c | 29 +
2 files changed, 11 insertions(+), 48 del
Since we got rid of platform data, the driver may use GPIO descriptor
directly.
Looking deeply to the use of the GPIO pin it looks like it should be
a GPIO based reset control rather than custom GPIO handling. But this
is out of scope of the change.
Signed-off-by: Andy Shevchenko <andriy.shev
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
There is no platform code that uses i2c module table.
Remove it altogether and adjust ->probe() to be ->probe_new().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/fdp/i2c.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify
error path and fix potentially wrong assignment if ->probe() fails.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/pn544/i2c.c | 3 +--
1 file changed, 1 insertion(+), 2
I2C and SPI frameworks followed by IRQ framework do set
interrupt polarity correctly if it's properly specified in firmware
(ACPI or DT).
Get rid of the redundant trick when requesting interrupt.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st-nci/i2c
artificial IDs.
Changelog v3:
- incorporate Samuel's fixes
- fix the bug kbuild bot complains about
- add MAINTAINERS patch
Changelog v2:
- add patches 1,4-12
Andy Shevchenko (13):
NFC: pn544: Switch to devm_acpi_dev_add_driver_gpios()
NFC: st21nfca: Add GPIO ACPI mapping table
NFC: st21nfca
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st-nci/i2c.c | 61 +++-
drivers/nfc/st-
Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.
If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.
There are no longer platform data files for NFC drivers.
Remove it from MAINTAINERS data base.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f2d96313230..6b6079ad91f4
It looks like there are two leftovers, at least one of which can leak
the resource (IRQ).
Convert both places to use managed variants of the functions.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/fdp/fdp.c | 15 ---
drivers/nfc/fdp/i2c.
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st21nfca/i2c.c | 62 --
1 file ch
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
On Mon, 2017-06-12 at 22:56 +0200, Samuel Ortiz wrote:
> On Mon, Jun 12, 2017 at 06:36:12PM +0300, Andy Shevchenko wrote:
> > Samuel, anything to comment?
>
> I will get to my pending NFC patches during the week.
Thanks!
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
On Mon, 2017-06-05 at 23:19 +0300, Andy Shevchenko wrote:
> This clean up series to NFC drivers that are using GPIOs on ACPI
> enabled
> platforms. Since GPIO ACPI library goes stricter about requesting
> resources we need to amend drivers for that. Here we are for NFC
> subsys
On Sat, Jun 10, 2017 at 10:27 PM, Arend van Spriel
<arend.vanspr...@broadcom.com> wrote:
> On 03-06-17 17:36, Andy Shevchenko wrote:
>> On Sat, Jun 3, 2017 at 1:29 AM, Peter S. Housel <hou...@acm.org> wrote:
The following looks good to me.
Feel free to add
Reviewe
Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify
error path and fix potentially wrong assingment if ->probe() fails.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
net/rfkill/rfkill-gpio.c | 5 +
1 file changed, 1 insertion(+), 4
Since we got rid of platform data, the driver may use GPIO descriptor
directly.
Looking deeply to the use of the GPIO pin it looks like it should be
a GPIO based reset control rather than custom GPIO handling. But this
is out of scope of the change.
Signed-off-by: Andy Shevchenko <andriy.shev
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
On Mon, 2017-05-22 at 21:33 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 21:41 +0300, Andy Shevchenko wrote:
> > In order to make GPIO ACPI library stricter prepare users of
> > gpiod_get_index() to correctly behave when there no mapping is
> > provided by firmware.
Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.
If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st-nci/i2c.c | 61 +++---
drivers/nfc/st-nci/s
There is no platform code that uses i2c module table. Remove it altogether and
adjust ->probe() to be ->probe_new().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/fdp/i2c.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st21nfca/i2c.c | 62 --
1 file ch
artificial IDs.
Changelog v2:
- add patches 1,4-12
Andy Shevchenko (12):
NFC: pn544: Switch to devm_acpi_dev_add_driver_gpios()
NFC: st21nfca: Add GPIO ACPI mapping table
NFC: st21nfca: Get rid of code duplication in ->probe()
NFC: fdp: Convert I2C driver to ->probe_new()
NFC: fdp: C
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
It looks like there are two leftovers, at least one of which can leak
the resource (IRQ).
Convert both places to use devm variants of functions.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/fdp/fdp.c | 15 ---
drivers/nfc/fdp/i2c.
Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify
error path and fix potentially wrong assingment if ->probe() fails.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/pn544/i2c.c | 3 +--
1 file changed, 1 insertion(+), 2
Use unified device property API in meaningful way.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st-nci/i2c.c | 30 ++
drivers/nfc/st-nci/spi.c | 29 +
2 files changed, 11 insertions(+), 48 del
I2C and SPI frameworks followed by IRQ framework do set
interrupt polarity correctly if it's properly specified in firmware
(ACPI or DT).
Get rid of the redundant trick when requesting interrupt.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st-nci/i2c
rn in use if (!ret)
2. Less error prone in case someone decides to expand the code and
missed ! or something else there.
Since both makes an approach less error prone I wouldn't suggest doing
that as I commented in new version.
--
With Best Regards,
Andy Shevchenko
(sdiodev, SDIO_FUNC_2, false, addr,
> pktq);
--
With Best Regards,
Andy Shevchenko
o often?
Version 5 look pretty good to me. Just stop posting it again and wait
when Greg takes it.
FWIW (version 5!):
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
--
With Best Regards,
Andy Shevchenko
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/st21nfca/i2c.c | 62 --
1 file ch
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
On Tue, 2017-03-07 at 12:25 +0200, Andy Shevchenko wrote:
> We return -ENODEV if ACPI provides a GPIO resource. Looks really
> wrong.
> If it has even been tested?
Samuel, Christophe, anything I have to address?
>
> Signed-off-by: Andy Shevchenko <andriy.shevche.
On Tue, 2017-03-28 at 12:36 +0300, Andy Shevchenko wrote:
> Legacy platform data must go away. We are on the safe side here since
> there are no users of it in the kernel.
>
> If anyone by any odd reason needs it the GPIO lookup tables and
> built-in device properties at your serv
Since we got rid of platform data, the driver may use
GPIO descriptor directly.
This change fixes a potential issue of double freeing GPIOs in ACPI
case by converting to devm_gpiod_get().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3: no change
drivers/nfc
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3: use dev_dbg() instead of nfc_dbg()
drivers/nfc/pn544/i
The error handling will be neat and short when using managed resources.
Convert the driver to use devm_request_threaded_irq().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
v3: no change
drivers/nfc/pn544/i2c.c | 16 +---
1 file changed, 5 inse
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.
If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
-
On Wed, 2017-03-22 at 21:22 +0200, Andy Shevchenko wrote:
> In some cases nfc_dbg() is useful. Add such macro to a header.
>
I think we may drop this, since the idea is to get rid of such macros
(as I read back in 2011 in commit message of change that removed
nfc_dbg() one).
I will
On Fri, 2017-03-24 at 10:14 -0700, David Miller wrote:
> From: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Date: Fri, 24 Mar 2017 18:10:35 +0200
>
> > Should I escalate to Linus?
>
> Threats of "escalating" are never effective, please never do
>
s for the delays.
NP.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
>
> url:https://github.com/0day-ci/linux/commits/Andy-Shevchenko/NFC-p
> n544-Get-rid-of-platform-data/20170324-232445
> config: i386-randconfig-x078-201712 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config
Hi!
I have sent couple of versions against couple of drivers in NFC
subsystem (drivers part) and heard nothing in response from subsystem
maintainers.
Is the subsystem abandoned?
Whom should I send my patches? (There are more anticipated)
Should I escalate to Linus?
--
Andy Shevchenko
Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.
If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shev
The error handling will be neat and short when using managed resources.
Convert the driver to use devm_request_threaded_irq().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/pn544/i2c.c | 16 +---
1 file changed, 5 insertions(+), 11 del
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
The patch depends on early sent
http://marc.info/?l=linux-wireless=149021085530803=2
drivers/
Since we got rid of platform data, the driver may use
GPIO descriptor directly.
This change fixes a potential issue of double freeing GPIOs in ACPI
case by converting to devm_gpiod_get().
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/nfc/pn544/i2c.c
In some cases nfc_dbg() is useful. Add such macro to a header.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
include/net/nfc/nfc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/nfc/nfc.h b/include/net/nfc/nfc.h
index 1a3de8b34ad2..bbdc73a3239d
-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
net/nfc/netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 03f3d5c7beb8..03be522127ec 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -918,7 +918,7 @@
he
>
> On 17/03/2017 08:49, Andy Shevchenko wrote:
> > On Tue, 2017-03-07 at 12:25 +0200, Andy Shevchenko wrote:
> > > We return -ENODEV if ACPI provides a GPIO resource. Looks really
> > > wrong.
> > > If it has even been tested?
> >
&
On Tue, 2017-03-07 at 12:25 +0200, Andy Shevchenko wrote:
> We return -ENODEV if ACPI provides a GPIO resource. Looks really
> wrong.
> If it has even been tested?
Any comments on this clean up?
Next patch which is dependent to this is related to ACPI enumeration.
After GPIO ACPI lib
1 - 100 of 149 matches
Mail list logo