From: Tobias Polzer tobias.pol...@fau.de
One missing include was added.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
drivers/staging/usbip/userspace/src/usbip_network.c | 4
1 file changed, 4 insertions(+)
diff --git
When testing usbip under powerpc, it (unexpectedly) worked, but only after
removing the following lines from vhch_hcd.c:
1004 /* will be removed */
1005 if (pdev-dev.dma_mask) {
1006 dev_info(pdev-dev, vhci_hcd DMA not supported\n);
1007 return
On Thu, Sep 19, 2013 at 10:55:18AM +0200, Tobias Polzer wrote:
When testing usbip under powerpc, it (unexpectedly) worked, but only after
removing the following lines from vhch_hcd.c:
1004 /* will be removed */
1005 if (pdev-dev.dma_mask) {
1006
On 2013-09-18 19:46, H Hartley Sweeten wrote:
Fix two issues with the analog output subdevice:
1) The raw data from the comedi core should be saved for readback
not the munged two's complement data that is written to the
hardware.
2) Avoid a possible deadlock while waiting to
On Thu, Sep 19, 2013 at 12:12:44PM +0300, Dan Carpenter wrote:
On Thu, Sep 19, 2013 at 10:55:18AM +0200, Tobias Polzer wrote:
When testing usbip under powerpc, it (unexpectedly) worked, but only after
removing the following lines from vhch_hcd.c:
1004 /* will be removed */
1005
On September 19, 2013 at 3:40 PM Dominik Paulus domi...@d-paulus.de wrote:
On Thu, Sep 19, 2013 at 12:12:44PM +0300, Dan Carpenter wrote:
On Thu, Sep 19, 2013 at 10:55:18AM +0200, Tobias Polzer wrote:
When testing usbip under powerpc, it (unexpectedly) worked, but only after
removing the
Ah, ok. I had no idea what you were talking about before. I thought
you were talking about build errors in a file that didn't exist...
(Because the subject says build and there was a typo in the file
name).
Navin, says you can remove it.
regards,
dan carpenter
Signed-off-by: Juergen Beisert j...@pengutronix.de
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut ma...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
CC: Jonathan Cameron ji...@cam.ac.uk
---
drivers/staging/iio/adc/mxs-lradc.c | 163
In order to support i.MX23 and i.MX28 within one driver we need to separate the
register definitions which differ in both SoC variants.
Signed-off-by: Juergen Beisert j...@pengutronix.de
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut ma...@denx.de
CC:
For battery driven systems it is a very bad idea to collect the touchscreen
data within a kernel busy loop.
This change uses the features of the hardware to delay and accumulate samples in
hardware to avoid a high interrupt and CPU load.
Note: this is only tested on an i.MX23 SoC yet.
Replace the individual register access by a few shared access function to make
the
code easier to read and in order to add the i.MX23 SoC in the next step.
Signed-off-by: Juergen Beisert j...@pengutronix.de
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
This is an RFC for the new touchscreen properties.
Signed-off-by: Juergen Beisert j...@pengutronix.de
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut ma...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
CC: Jonathan Cameron ji...@cam.ac.uk
CC:
The following series replaces the current busy loop touchscreen implementation
for i.MX28/i.MX23 SoCs by a fully interrupt driven implementation.
Since i.MX23 and i.MX28 silicon differs, the existing implementation can
be used for the i.MX28 SoC only.
So, the first two patches of this series
With --with-tcp-wrappers=no specified, the build system reset LIBS to
the empty string and thus fails to link against libsysfs.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
drivers/staging/usbip/userspace/configure.ac | 1 -
1 file
Hi Jonathan,
On Monday 16 September 2013 17:30:32 Jonathan Cameron wrote:
On Sunday 15 September 2013 12:56:25 Jonathan Cameron wrote:
On 09/11/13 09:18, Juergen Beisert wrote:
For battery driven systems it is a very bad idea to collect the
touchscreen data within a kernel busy loop.
Hi,
this patch series extends our previous set of patches (see [1]). We extended
the crypto support so all of the usbip network traffic can now be completely
encrypted and authenticated.
We now use GnuTLS not only for password verification, but extend the lifetime
of the TLS connection to cover
This extends the userspace code to write the generated session keys to
sysfs in hexadecimal encoding after establishing the connection.
The kernel code is modified to parse the session keys.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
In preparation for the kernel crypto support, we exchange two - randomly
generated - session keys between usbip and usbipd to be used for
encrypting all traffic generated in kernelspace. We use two different
128-bit keys, one for sending and one for receiving. Both are generated
by the client
This adds two simple wrappers around kernel_sendmsg() and
kernel_recvmsg() that can be extended to perform additional
cryptographic operations on the data before sending it.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
Also increment the kernel module version number to match the
userspace version, as compatibility with old userspace utilities
is now at least partially broken.
Signed-off-by: Dominik Paulus dominik.pau...@fau.de
Signed-off-by: Tobias Polzer tobias.pol...@fau.de
---
On Wed, Sep 18, 2013 at 11:27:51PM +, KY Srinivasan wrote:
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, September 18, 2013 2:01 PM
To: KY Srinivasan
Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
.
Jürgen Beisert j...@pengutronix.de wrote:
Hi Jonathan,
On Monday 16 September 2013 17:30:32 Jonathan Cameron wrote:
On Sunday 15 September 2013 12:56:25 Jonathan ,,, wrote:
On 09/11/13 09:18, Juergen Beisert wrote:
For battery driven systems it is a very bad idea to collect the
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Thursday, September 19, 2013 8:53 AM
To: KY Srinivasan
Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch misc/noderef.cocci
Signed-off-by: Thomas Meyer tho...@m3y3r.de
---
diff -u -p a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
---
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch misc/noderef.cocci
Signed-off-by: Thomas Meyer tho...@m3y3r.de
---
diff -u -p a/drivers/staging/rtl8188eu/core/rtw_mp.c
b/drivers/staging/rtl8188eu/core/rtw_mp.c
---
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch misc/noderef.cocci
Signed-off-by: Thomas Meyer tho...@m3y3r.de
---
diff -u -p a/drivers/staging/lustre/lustre/obdecho/echo_client.c
b/drivers/staging/lustre/lustre/obdecho/echo_client.c
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/block/nvme-core.c | 10 --
1 files changed, 4
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need to access the allocated musb platform device
from within its callbacks, which may be called during the musb
device probing.
The code sequence:
dev-coherent_dma_mask = DMA_BIT_MASK(24);
dev-dma_mask = dev-coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
36 matches
Mail list logo
