Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1
On Wed, Oct 5, 2016 at 12:22 AM, Greg KH wrote: > > Here is the big staging and IIO driver pull request for 4.9-rc1. > > There are a lot of patches in here, the majority due to the > drivers/staging/greybus/ subsystem being merged in with full development > history that went back a few years, in order to preserve the work that > those developers did over time. This was done the same way that btrfs > was merged into the tree, so all should be ok there. So I certainly have nothing against merging the development history this way - as you say we've done this before. However, before I pull this, I do want to understand why pulling it makes sense in the first place. I realize that people (very much including you personally) have spent lots of effort on greybus, but excuse my somewhat indelicate question: is there any *point* to merging greybus support? Is anything ever going to use it? With project Ara being dead, where else would you find users? Please fill me in on details - at the very least, even if there realyl *are* good reasons to merge it, that's the kind of information that should go into the pull request and into the merge message. Linus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1
On Wed, Oct 05, 2016 at 09:32:01AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 12:22 AM, Greg KH wrote: > > > > Here is the big staging and IIO driver pull request for 4.9-rc1. > > > > There are a lot of patches in here, the majority due to the > > drivers/staging/greybus/ subsystem being merged in with full development > > history that went back a few years, in order to preserve the work that > > those developers did over time. This was done the same way that btrfs > > was merged into the tree, so all should be ok there. > > So I certainly have nothing against merging the development history > this way - as you say we've done this before. > > However, before I pull this, I do want to understand why pulling it > makes sense in the first place. > > I realize that people (very much including you personally) have spent > lots of effort on greybus, but excuse my somewhat indelicate question: > is there any *point* to merging greybus support? > > Is anything ever going to use it? With project Ara being dead, where > else would you find users? Please fill me in on details - at the very > least, even if there realyl *are* good reasons to merge it, that's the > kind of information that should go into the pull request and into the > merge message. Fair enough. Right now there is a phone from Motorola shipping with this code (a slightly older version, but the same tree), so even though Ara is not alive in the same form, the functionality is happening. We are working with the developers of that phone to merge the newer stuff in with their fork so they can use the upstream version in future versions of their phone product line. Toshiba has at least one chip shipping in their catalog that needs/uses this protocol over a Unipro link, and rumor has it that there might be more in the future. There are also other users of the greybus protocols, there is a talk next week at ELC that shows how it is being used across a network connection to control a device, and previous ELC talks have showed the protocol stack being used over USB to drive embedded Linux boards. I've also talked to some people who are starting to work to add a host controller driver to control arduinos as the greybus PHY protocols are very useful to control a serial/i2c/spio/whatever device across a random physical link, as it is a way to have a self-describing device be attached to a host without needing manual configuration. So yes, people are using it, and there is still the chance that it will show up in a phone/laptop/tablet/whatever from Google in the future as well, the tech isn't dead, even if the original large phone project happens to be. Should I respin the merge request with the above information in it? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: speakup: Replaced obsolete simple_strtoul
From: Jitendra Kumar Khasdev
This patch is for replacing obsolete simple_strtoul to kstrtoul which remove
warning produce by checkpatch.
Signed-off-by: Jitendra Kumar Khasdev
---
drivers/staging/speakup/varhandlers.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/speakup/varhandlers.c
b/drivers/staging/speakup/varhandlers.c
index 21186e3..1a3caf3 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -323,9 +323,11 @@ char *spk_strlwr(char *s)
char *spk_s2uchar(char *start, char *dest)
{
- int val;
+ unsigned long val;
+
+ if (kstrtoul(start, 10, &val))
+ return NULL;
- val = simple_strtoul(skip_spaces(start), &start, 10);
if (*start == ',')
start++;
*dest = (u_char)val;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Replaced obsolete simple_strtoul
Hello, Jitendra Khasdev, on Thu 06 Oct 2016 02:02:58 +0530, wrote: > From: Jitendra Kumar Khasdev > > This patch is for replacing obsolete simple_strtoul to kstrtoul which remove > warning produce by checkpatch. > + unsigned long val; > + > + if (kstrtoul(start, 10, &val)) > + return NULL; > > - val = simple_strtoul(skip_spaces(start), &start, 10); > if (*start == ',') simple_strtoul modifies start, so you can't just replace it with kstrtoul. Samuel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] hv: do not lose pending heartbeat vmbus packets
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when
the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1
On Wed, Oct 5, 2016 at 1:17 PM, Greg KH wrote: > > Should I respin the merge request with the above information in it? This is sufficient - I just need to know (and want to document) the reasons for the merges I do. In fact, I'd love it if your pull requests in general were a bit more about what is going on, but for things like the greybus thing I *really* needed it. Linus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging:dgnc:dgnc_neo: fixed 80 character line limit coding style issue
Fixed coding style issue
Signed-off-by: Nadim Almas
---
drivers/staging/dgnc/dgnc_neo.h | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.h b/drivers/staging/dgnc/dgnc_neo.h
index abddd48..65994e3 100644
--- a/drivers/staging/dgnc/dgnc_neo.h
+++ b/drivers/staging/dgnc/dgnc_neo.h
@@ -30,7 +30,8 @@
struct neo_uart_struct {
u8 txrx;/* WR RHR/THR - Holding Reg */
u8 ier; /* WR IER - Interrupt Enable Reg */
- u8 isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo
Control Reg */
+ u8 isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo Control */
+ /*Reg */
u8 lcr; /* WR LCR - Line Control Reg */
u8 mcr; /* WR MCR - Modem Control Reg */
u8 lsr; /* WR LSR - Line Status Reg */
@@ -108,7 +109,8 @@ struct neo_uart_struct {
/* 17158 Extended IIR's */
#define UART_17158_IIR_RDI_TIMEOUT 0x0C/* Receiver data TIMEOUT */
#define UART_17158_IIR_XONXOFF 0x10/* Received an XON/XOFF char */
-#define UART_17158_IIR_HWFLOW_STATE_CHANGE 0x20/* CTS/DSR or RTS/DTR
state change */
+#define UART_17158_IIR_HWFLOW_STATE_CHANGE 0x20/* CTS/DSR or RTS/DTR
state */
+ /* change */
#define UART_17158_IIR_FIFO_ENABLED0xC0/* 16550 FIFOs are Enabled */
/*
@@ -119,8 +121,10 @@ struct neo_uart_struct {
#define UART_17158_RXRDY_TIMEOUT 0x2 /* RX Ready Timeout */
#define UART_17158_TXRDY 0x3 /* TX Ready */
#define UART_17158_MSR 0x4 /* Modem State Change */
-#define UART_17158_TX_AND_FIFO_CLR 0x40/* Transmitter Holding Reg
Empty */
-#define UART_17158_RX_FIFO_DATA_ERROR 0x80/* UART detected an RX FIFO
Data error */
+#define UART_17158_TX_AND_FIFO_CLR 0x40/* Transmitter Holding Reg */
+ /* Empty */
+#define UART_17158_RX_FIFO_DATA_ERROR 0x80/* UART detected an RX FIFO */
+ /* Data error */
/*
* These are the EXTENDED definitions for the 17C158's Interrupt
@@ -132,8 +136,10 @@ struct neo_uart_struct {
#define UART_17158_EFR_RTSDTR 0x40/* Auto RTS/DTR Flow Control Enable */
#define UART_17158_EFR_CTSDSR 0x80/* Auto CTS/DSR Flow COntrol Enable */
-#define UART_17158_XOFF_DETECT 0x1 /* Indicates whether chip saw an
incoming XOFF char */
-#define UART_17158_XON_DETECT 0x2 /* Indicates whether chip saw an
incoming XON char */
+#define UART_17158_XOFF_DETECT 0x1 /* Indicates whether chip saw an */
+ /* incoming XOFF char */
+#define UART_17158_XON_DETECT 0x2 /* Indicates whether chip saw an */
+ /* incoming XON char */
#define UART_17158_IER_RSVD1 0x10/* Reserved by Exar */
#define UART_17158_IER_XOFF0x20/* Xoff Interrupt Enable */
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 1/1] hv: do not lose pending heartbeat vmbus packets
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when
the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
CC: Stable
---
V2: Submit the patch to stable as well - Joshua R. Poulson
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging:dgnc:dgnc_neo: fixed 80 character line limit coding style issue
On Wed, Oct 05, 2016 at 02:53:58PM -0700, Nadim Almas wrote:
> Fixed coding style issue
>
> Signed-off-by: Nadim Almas
> ---
> drivers/staging/dgnc/dgnc_neo.h | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/dgnc/dgnc_neo.h b/drivers/staging/dgnc/dgnc_neo.h
> index abddd48..65994e3 100644
> --- a/drivers/staging/dgnc/dgnc_neo.h
> +++ b/drivers/staging/dgnc/dgnc_neo.h
> @@ -30,7 +30,8 @@
> struct neo_uart_struct {
> u8 txrx;/* WR RHR/THR - Holding Reg */
> u8 ier; /* WR IER - Interrupt Enable Reg */
> - u8 isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo
> Control Reg */
> + u8 isr_fcr; /* WR ISR/FCR - Interrupt Status Reg/Fifo Control */
> + /*Reg */
Does that really look better now than it did before?
I don't think so :(
sorry,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
