- Apr 05, 2017
-
-
Andy Shevchenko authored
Another place in the code that unveils non-tested at all ACPI case. Use unified device property API in meaningful way. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
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 fixed voltage regulator rather than custom GPIO handling. But this is out of scope of the change. Signed-off-by:
-
Andy Shevchenko authored
I2C framework followed by IRQ framework does 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 authored
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 authored
We return -ENODEV if ACPI provides a GPIO resource. Looks really wrong. If it has even been tested? Signed-off-by:
-
Andy Shevchenko authored
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 authored
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 authored
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 authored
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 authored
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:
-
- Apr 02, 2017
-
-
Samuel Ortiz authored
They are no longer active and their email addresses bounce. Signed-off-by: -
Andrey Rusalin authored
Sometimes during probing and registration of pn533_i2c NULL pointer dereference happens. Reproduced in cycle of inserting and removing pn533_i2c and pn533 modules. Backtrace: [<8004205c>] (__queue_work) from [<80042324>] (queue_work_on+0x50/0x5c) r10:acdc7c80 r9:8006b330 r8:ac0dfb40 r7:ac50c600 r6:00000004 r5:acbbee40 r4:600f0113 [<800422d4>] (queue_work_on) from [<7f7d5b6c>] (pn533_recv_frame+0x158/0x1fc [pn533]) r7:ffffff87 r6:00000000 r5:acbbee40 r4:acbbee00 [<7f7d5a14>] (pn533_recv_frame [pn533]) from [<7f7df4b8>] (pn533_i2c_irq_thread_fn+0x184/0x) r6:acb2a000 r5:00000000 r4:acdc7b90 [<7f7df334>] (pn533_i2c_irq_thread_fn [pn533_i2c]) from [<8006b354>] (irq_thread_fn+0x24/0x) r7:00000000 r6:accde000 r5:ac0dfb40 r4:acdc7c80 ... Seems there is some race condition due registration of irq handler until all data stuctures that could be needed are ready. So I re-ordered some ops. After this, problem has gone. Changes in USB part was not tested, but it should not break anything. Signed-off-by:
Andrey Rusalin <arusalin@dev.rtsoft.ru> Signed-off-by:
-
Andrey Rusalin authored
Make sure cmd is set before a frame is passed to the transport layer for sending. In addition pn533_send_async_complete checks if cmd is set before accessing its members. Signed-off-by:
Michael Thalmeier <michael.thalmeier@hale.at> Rework a little bit changes in pn532_send_async_complete. Signed-off-by:
-
Andrey Rusalin authored
Change order of free_irq and dev unregistration. It fixes situation when device already unregistered and an interrupt happens and nobody can handle it. Signed-off-by:
-
Sudip Mukherjee authored
We are checking phy after dereferencing it. We can print the debug information after checking it. If phy is NULL then we will get a good stack trace to tell us that we are in this irq handler. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Guan Ben authored
Make the EN2 pin optional. This is useful for boards, which have this pin fix wired, for example to ground. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Guan Ben <ben.guan@cn.bosch.com> Signed-off-by:
Mark Jonas <mark.jonas@de.bosch.com> Signed-off-by:
Heiko Schocher <hs@denx.de> Signed-off-by:
-
Nicholas Mc Guire authored
ulseep_range() uses hrtimers and provides no advantage over msleep() for larger delays. For this large delay msleep() is preferable. Fixes: commit 6be88670 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver") Link: http://lkml.org/lkml/2017/1/11/377 Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
-
Christophe JAILLET authored
If all bits of 'dev_mask' are already set, there is a memory leak because 'info' should be freed before returning. While fixing it, 'return -ENOMEM' directly if the first kzalloc fails. This makes the code more readable. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Dan Carpenter authored
The nci_spi_send() function calls kfree_skb(skb) on both error and success so this extra kfree_skb() is a double free. Fixes: caf6e49b ("NFC: nfcmrvl: add spi driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Corentin Labbe authored
drivers/nfc/st21nfca/i2c.c does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Corentin Labbe authored
drivers/nfc/pn544/i2c.c does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by:
-
Corentin Labbe authored
drivers/nfc/nxp-nci/i2c.c does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by:
-
Guenter Roeck authored
Directly including access_ok.h can result in the following compile errors if an architecture such as ia64 does not support direct unaligned accesses. include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16' include/linux/unaligned/le_struct.h:6:19: note: previous definition of 'get_unaligned_le16' was here include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32' include/linux/unaligned/le_struct.h:11:19: note: previous definition of 'get_unaligned_le32' was here Include asm/unaligned.h instead and let the architecture decide which access functions to use. Cc: Clément Perrochaud <clement.perrochaud@effinnov.com> Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Tobias Klauser authored
Including linux/unaligned/access_ok.h causes the allmodconfig build on ia64 (and maybe others) to fail with the following warnings: include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16' include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32' include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64' include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16' include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32' include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64' include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64' Fix these by including asm/unaligned.h instead and leave it up to the architecture to decide how to implement unaligned accesses. Fixes: 3194c687 ("NFC: nfcmrvl: add firmware download support") Reported-by:
kbuild test robot <fengguang.wu@intel.com> Link: https://lkml.org/lkml/2016/10/22/247 Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Geliang Tang authored
Drop duplicate header gpio.h from nfcmrvl/spi.c. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Rob Herring authored
It appears that TI WiLink devices including NFC (WL185x/WL189x) never shipped. The only information I found were announcements in Feb 2012 about the parts. There's been no activity on this driver besided common changes since initially added in Jan 2012. There's also no in users that instantiate the platform device (nor DT bindings). This is a first step in removing TI ST (shared transport) driver in favor of extending the BT hci_ll driver to support WL183x chips. Cc: Ilan Elias <ilane@ti.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org> Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org> Cc: linux-wireless@vger.kernel.org Signed-off-by:
-
OGAWA Hirofumi authored
If port100_send_ack() was called twice or more, it has race to hangup. port100_send_ack() port100_send_ack() init_completion() [...] dev->cmd_cancel = true /* this removes previous from completion */ init_completion() [...] dev->cmd_cancel = true wait_for_completion() /* never be waked up */ wait_for_completion() Like above race, this code is not assuming port100_send_ack() is called twice or more. To fix, this checks dev->cmd_cancel to know if prior cancel is in-flight or not. And never be remove prior task from completion by using reinit_completion(), so this guarantees to be waked up properly soon or later. Signed-off-by:OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
OGAWA Hirofumi authored
If sent packet size is wMaxPacketSize boundary, this device doesn't answer. To fix this, we have to send zero-length packet in usb spec. Signed-off-by:
-
OGAWA Hirofumi authored
Now, NFC_EVENT_DEVICE_ADDED doesn't send NFC_ATTR_RF_MODE. But NFC_CMD_GET_DEVICE send. To get NFC_ATTR_RF_MODE, we have to call NFC_CMD_GET_DEVICE just for NFC_ATTR_RF_MODE when get NFC_EVENT_DEVICE_ADDED. This fixes those inconsistent. Signed-off-by:
-
OGAWA Hirofumi authored
Signed-off-by:
-
David S. Miller authored
Alexei Starovoitov says: ==================== bpf: program testing framework Development and testing of networking bpf programs is quite cumbersome. Especially tricky are XDP programs that attach to real netdevices and program development feels like working on the car engine while the car is in motion. Another problem is ongoing changes to upstream llvm core that can introduce an optimization that verifier will not recognize. llvm bpf backend tests have no ability to run the programs. To improve this situation introduce BPF_PROG_TEST_RUN command to test and performance benchmark bpf programs. It achieves several goals: - development of xdp and skb based bpf programs can be done in a canned environment with unit tests - program performance optimizations can be benchmarked outside of networking core (without driver and skb costs) - continuous testing of upstream changes is finally practical Patches 4,5,6 add C based test cases of various complexity to cover some sched_cls and xdp features. More tests will be added in the future. The tests were run on centos7 only. For now the framework supports only skb and xdp programs. In the future it can be extended to socket_filter and tracing program types. More details are in individual patches. v1->v2: - rename bpf_program_test_run->bpf_prog_test_run - add missing #include <linux/bpf.h> since libbpf.h shouldn't depend on prior includes - reordered patches 3 and 4 to keep bisect clean ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Alexei Starovoitov authored
this l4lb demo is a comprehensive test case for LLVM codegen and kernel verifier. It's using fully inlined jhash(), complex packet parsing and multiple map lookups of different types to stress llvm and verifier. The map sizes, map population and test vectors are artificial to exercise different paths through the bpf program. Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Martin KaFai Lau <kafai@fb.com> Signed-off-by:
-
Alexei Starovoitov authored
add C test for xdp_adjust_head(), packet rewrite and map lookups Signed-off-by:
-
Alexei Starovoitov authored
add simple C test case for llvm and verifier range check fix from commit b1977682 ("bpf: improve verifier packet range checks") Signed-off-by:
-
Alexei Starovoitov authored
expose bpf_program__set_type() to set program type Signed-off-by:
-
Alexei Starovoitov authored
add support for BPF_PROG_TEST_RUN command to libbpf.a Signed-off-by:
Wang Nan <wangnan0@huawei.com> Signed-off-by:
-
Alexei Starovoitov authored
development and testing of networking bpf programs is quite cumbersome. Despite availability of user space bpf interpreters the kernel is the ultimate authority and execution environment. Current test frameworks for TC include creation of netns, veth, qdiscs and use of various packet generators just to test functionality of a bpf program. XDP testing is even more complicated, since qemu needs to be started with gro/gso disabled and precise queue configuration, transferring of xdp program from host into guest, attaching to virtio/eth0 and generating traffic from the host while capturing the results from the guest. Moreover analyzing performance bottlenecks in XDP program is impossible in virtio environment, since cost of running the program is tiny comparing to the overhead of virtio packet processing, so performance testing can only be done on physical nic with another server generating traffic. Furthermore ongoing changes to user space control plane of production applications cannot be run on the test servers leaving bpf programs stubbed out for testing. Last but not least, the upstream llvm changes are validated by the bpf backend testsuite which has no ability to test the code generated. To improve this situation introduce BPF_PROG_TEST_RUN command to test and performance benchmark bpf programs. Joint work with Daniel Borkmann. Signed-off-by:
-
Florian Fainelli authored
This patch adds support for a DSA mock-up driver which essentially does the following: - registers/unregisters 4 fixed PHYs to the slave network devices - uses eth0 (configurable) as the master netdev - registers the switch as a fixed MDIO device against the fixed MDIO bus at address 31 - includes dynamic debug prints for dsa_switch_ops functions that can be enabled to get call traces This is a good way to test modular builds as well as exercise the DSA APIs without requiring access to real hardware. This does not test the data-path, although this could be added later on. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: mv88e6xxx: program cross-chip bridging The purpose of this patch series is to bring hardware cross-chip bridging configuration to the DSA layer and the mv88e6xxx DSA driver. Most recent Marvell switch chips have a Cross-chip Port Based VLAN Table (PVT) used to restrict to which internal destination port an arbitrary external source port is allowed to egress frames to. The current behavior of the mv88e6xxx driver is to program this table table with all ones, allowing any external ports to egress frames on any internal ports. This means that carefully crafted Ethernet frames can potentially bypass the user bridging configuration. Patches 1 to 7 prepare the setup of this table and factorize the common bits of both in-chip and cross-chip Marvell bridging code. Patch 8 adds new optional cross-chip bridging operations to DSA switch. Patch 9 switches the current behavior to program the table according to the user bridging configuration when (cross-chip) ports get (un)bridged. On a ZII Rev B board, bridging together the 3 user ports of both 88E6352 will result in the following PVTs on respectively switch 0 and switch 1: External Internal Ports Dev Port 0 1 2 3 4 5 6 1 0 * * * - - * * 1 1 * * * - - * * 1 2 * * * - - * * 1 3 - - - - - * * 1 4 - - - - - * * 1 5 * * * * * * * 1 6 * * * * * * * 0 0 * * * - - * * 0 1 * * * - - * * 0 2 * * * - - * * 0 3 - - - - - * * 0 4 - - - - - * * 0 5 * * * * * * * 0 6 * * * * * * * Changes since v2: - Define MV88E6XXX_MAX_PVT_SWITCHES and MV88E6XXX_MAX_PVT_PORTS - use mv88e6xxx_g2_misc_4_bit_port instead of the 5-bit variant - add Andrew's tags and reword commit 6/9 ==================== Signed-off-by: -
Vivien Didelot authored
Implement the DSA cross-chip bridging operations by remapping the local ports an external source port can egress frames to, when this cross-chip port joins or leaves a bridge. The PVT is no longer configured with all ones allowing any external frame to egress any local port. Only DSA and CPU ports, as well as bridge group members, can egress frames on local ports. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
