On Mon, 2017-05-01 at 11:40 +0200, Arend van Spriel wrote:
>
> So I will include this patch in my patchset for PSK/1X offloading
> taken above into account.
Great, thanks!
johannes
Hi Shikha,
> *** V1.0 ***
> This patch series is generated on top of latest
> code available on nfc-next.
>
> This patch series introduces the following features:
>
> (a) A generic Digital NFC UART framework.
> The framework itself is an LDISC registered
> with the tty core. Any NFC transciever
Some NFC controller supports UART as host interface.
Such controllers which are direct implementation of
digital protocol can use this framework.
This patch add the generic support of UART and
provides some extension API for vendor specific needs.
This code is strongly inspired by the nci ldisc
im
Add support of ST NFC transceiver controlled over SPI.
This driver enables ST NFC transceiver to communicate
with host over SPI interface and as a phy driver it
registers with ST NFC transceiver core framework.
Signed-off-by: Shikha Singh
---
drivers/nfc/nfcst/Kconfig | 15 ++
drivers/nfc/nfc
This patch removes all references to old st95hf driver.
A new ST NFC driver is added under drivers/nfc/nfcst.
The new driver design is based on modular
approach to have ST NFC core framework which is
independent of PHY and Two ST NFC PHY drivers to support
SPI and UART interfaces.
Signed-off-by:
*** V1.0 ***
This patch series is generated on top of latest
code available on nfc-next.
This patch series introduces the following features:
(a) A generic Digital NFC UART framework.
The framework itself is an LDISC registered
with the tty core. Any NFC transciever implementing
the digital specs
This patch adds ST NFC binding doc that guides
how to make SPI slave node entry of ST NFC transceiver
in DT file of any platform.
Signed-off-by: Shikha Singh
---
.../devicetree/bindings/net/nfc/stnfc.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 D
This patch implements the ST NFC Transceiver
core framework.
This framework implements the digital specifications.
ST NFC Phy drivers supporting SPI or UART interface can
register with this framework when a Transceiver is connected
with host using the respective interface.
Following the modular de
Add support of ST NFC transceiver controlled over UART.
This driver registers with the digital LDisc UART
framework as an UART LDisc driver, and as a phy driver
with the ST NFC transceiver core framework.
Signed-off-by: Shikha Singh
---
drivers/nfc/nfcst/Kconfig | 17 +
drivers/nfc/nfcst/
I have a notebook with Ubuntu installed, and an Intel 7265N driver for
WiFi and bluetooth. I cannot pair any device to it. Ubuntu finds the
devices, but doesn't get their name, and doesn't allow me to pair them
either.
Is there a fix for this? Should it be working?
Thanks!
--
Luis Pablo
This reverts b057886524be060021e3cfad0ba8458c850330cd in 2015
which converted this allocation from dma_map_coherent() to
kzalloc() / dma_map_single().
The current problem manifests when using later model NICs with larger
(>700KiB) scratch spaces in memory. Although the kzalloc call
succeeds, the
On Mon, May 01, 2017 at 12:37:00PM -0700, Brian Norris wrote:
> Similar to the SDIO driver, we should implement this so that we will
> automatically reset the device whenever there's a command timeout or
> similar.
>
> Signed-off-by: Brian Norris
Reviewed-by: Dmitry Torokhov
> ---
> v3: keep a
On Mon, May 01, 2017 at 12:36:59PM -0700, Brian Norris wrote:
> The non-atomic test + set is a little awkward here, and it technically
> means we might double-schedule work unnecessarily. AFAICT, this is not
> really a problem, since the extra "work" will be a no-op (the flag(s)
> will be cleared b
The non-atomic test + set is a little awkward here, and it technically
means we might double-schedule work unnecessarily. AFAICT, this is not
really a problem, since the extra "work" will be a no-op (the flag(s)
will be cleared by then), but it's still an anti-pattern.
Rewrite this to use the atom
Similar to the SDIO driver, we should implement this so that we will
automatically reset the device whenever there's a command timeout or
similar.
Signed-off-by: Brian Norris
---
v3: keep all the new reset code in patch 2, not patch 1
v2: use atomic test/set, based on Dmitry's suggestion
---
dr
On Mon, May 01, 2017 at 11:45:48AM -0700, Brian Norris wrote:
> The non-atomic test + set is a little awkward here, and it technically
> means we might double-schedule work unnecessarily. AFAICT, this is not
> really a problem, since the extra "work" will be a no-op (the flag(s)
> will be cleared b
Similar to the SDIO driver, we should implement this so that we will
automatically reset the device whenever there's a command timeout or
similar.
Signed-off-by: Brian Norris
---
v2: use atomic test/set, based on Dmitry's suggestion
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 11 ++
The non-atomic test + set is a little awkward here, and it technically
means we might double-schedule work unnecessarily. AFAICT, this is not
really a problem, since the extra "work" will be a no-op (the flag(s)
will be cleared by then), but it's still an anti-pattern.
Rewrite this to use the atom
On 4/28/2017 11:02 PM, Johannes Berg wrote:
On Wed, 2017-04-26 at 12:05 +0200, Arend van Spriel wrote:
the mobility domain does not require new 802.1X authentication, but
roaming to another mobility domain does.
Not sure about the terminology here. Is "mobility domain" the same
as "ESS" whi
On 4/30/2017 9:39 PM, Hans de Goede wrote:
Hi,
On 27-04-17 02:36, Luis R. Rodriguez wrote:
On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote:
Right, sorry. For the pcie device I'm looking at the
name is brcmfmac4356-pcie.txt and I would like to propose
to first check for
"brcm
20 matches
Mail list logo
