Re: [PATCH V2 00/26] use unified firmware and add ops in cfg
On Tue, Jan 26, 2016 at 11:44:30AM +0900, glen lee wrote: > > > On 2016년 01월 26일 02:21, Greg KH wrote: > >On Mon, Jan 25, 2016 at 03:15:31PM +0200, Kalle Valo wrote: > >>Glen Lee writes: > >> > >>>This patch series contains > >>>* support suspend and resume functionality > >>>* use a unified firmware for all mode of operations(station, ap, p2p) > >>>* support Station/AP concurrency > >>>* increase link speed > >>>* add a cfg operation for adjusting the tx power > >>>* fix bug on p2p, WEP security and chaning virtual interface > >>> > >>>Changes in V2: details in each patch files. > >>> - 0004-staging-wilc1000-add-sdio-resume-suspend.patch > >>It's good practise to also add "staging: wilc1000: " prefix to the cover > >>letter. > >Yes please, otherwise it misses my filters when I go to apply patches > >for a subsystem and I have to find it by hand :( > > Oh, I see it helps to filter. I will add prefix also. > Do I need to resend V3 patch series with adding prefix to cover letter? No, I'll take it this time... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 00/26] use unified firmware and add ops in cfg
On 2016년 01월 26일 02:21, Greg KH wrote: On Mon, Jan 25, 2016 at 03:15:31PM +0200, Kalle Valo wrote: Glen Lee writes: This patch series contains * support suspend and resume functionality * use a unified firmware for all mode of operations(station, ap, p2p) * support Station/AP concurrency * increase link speed * add a cfg operation for adjusting the tx power * fix bug on p2p, WEP security and chaning virtual interface Changes in V2: details in each patch files. - 0004-staging-wilc1000-add-sdio-resume-suspend.patch It's good practise to also add "staging: wilc1000: " prefix to the cover letter. Yes please, otherwise it misses my filters when I go to apply patches for a subsystem and I have to find it by hand :( Oh, I see it helps to filter. I will add prefix also. Do I need to resend V3 patch series with adding prefix to cover letter? regards, glen lee. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] Staging: rts5208: Add missing dma_mapping_error
Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c index eff9a4b621..43787df 100644 --- a/drivers/staging/rts5208/rtsx_transport.c +++ b/drivers/staging/rts5208/rtsx_transport.c @@ -663,7 +663,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf, return -ENXIO; addr = dma_map_single(&rtsx->pci->dev, buf, len, dma_dir); - if (!addr) + if (dma_mapping_error(&rtsx->pci->dev, addr)) return -ENOMEM; if (card == SD_CARD) -- 2.7.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Staging: rts5208: Cleanup rtsx_transport.c
This patch fixes coding style issues in rtsx_transport.c.
Signed-off-by: Shaun Ren
---
drivers/staging/rts5208/rtsx_transport.c | 115 +--
1 file changed, 65 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_transport.c
b/drivers/staging/rts5208/rtsx_transport.c
index f27491e..eff9a4b621 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -36,25 +36,30 @@
* For non-scatter-gather transfers, srb->request_buffer points to the
* transfer buffer itself and srb->request_bufflen is the buffer's length.)
* Update the *index and *offset variables so that the next copy will
- * pick up from where this one left off. */
+ * pick up from where this one left off.
+ */
unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
- unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
- unsigned int *offset, enum xfer_buf_dir dir)
+ unsigned int buflen,
+ struct scsi_cmnd *srb,
+ unsigned int *index,
+ unsigned int *offset,
+ enum xfer_buf_dir dir)
{
unsigned int cnt;
/* If not using scatter-gather, just transfer the data directly.
-* Make certain it will fit in the available buffer space. */
+* Make certain it will fit in the available buffer space.
+*/
if (scsi_sg_count(srb) == 0) {
if (*offset >= scsi_bufflen(srb))
return 0;
cnt = min(buflen, scsi_bufflen(srb) - *offset);
if (dir == TO_XFER_BUF)
- memcpy((unsigned char *) scsi_sglist(srb) + *offset,
- buffer, cnt);
+ memcpy((unsigned char *)scsi_sglist(srb) + *offset,
+ buffer, cnt);
else
- memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
+ memcpy(buffer, (unsigned char *)scsi_sglist(srb) +
*offset, cnt);
*offset += cnt;
@@ -64,31 +69,31 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char
*buffer,
* in kernel-addressable memory then kmap() will return its address.
* If the page is not directly accessible -- such as a user buffer
* located in high memory -- then kmap() will map it to a temporary
-* position in the kernel's virtual address space. */
+* position in the kernel's virtual address space.
+*/
} else {
struct scatterlist *sg =
- (struct scatterlist *) scsi_sglist(srb)
+ (struct scatterlist *)scsi_sglist(srb)
+ *index;
/* This loop handles a single s-g list entry, which may
* include multiple pages. Find the initial page structure
* and the starting offset within the page, and update
-* the *offset and *index values for the next loop. */
+* the *offset and *index values for the next loop.
+*/
cnt = 0;
while (cnt < buflen && *index < scsi_sg_count(srb)) {
struct page *page = sg_page(sg) +
((sg->offset + *offset) >> PAGE_SHIFT);
- unsigned int poff =
- (sg->offset + *offset) & (PAGE_SIZE-1);
+ unsigned int poff = (sg->offset + *offset) &
+ (PAGE_SIZE - 1);
unsigned int sglen = sg->length - *offset;
if (sglen > buflen - cnt) {
-
/* Transfer ends within this s-g entry */
sglen = buflen - cnt;
*offset += sglen;
} else {
-
/* Transfer continues to next s-g entry */
*offset = 0;
++*index;
@@ -97,7 +102,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
/* Transfer the data for all the pages in this
* s-g entry. For each page: call kmap(), do the
-* transfer, and call kunmap() immediately after. */
+* transfer, and call kunmap() immediately after.
+*/
while (sglen > 0) {
unsigned int plen = min(sglen, (unsigned int)
PAGE_SIZE - poff);
@@ -123,9 +129,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char
*buffer,
}
/* Sto
[PATCH 0/2] Staging: rts5208: Coding style and dma mapping fixes
This set of patches fixes the coding style issues in rtsx_transport.c, and adds a missing dma_mapping_error check. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
Dan Carpenter writes: > On Tue, Jan 26, 2016 at 08:32:48AM +0800, Huang, Ying wrote: >> Dan Carpenter writes: >> >> > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote: >> >> Apart from the mail which Ying Huang sent to me last week for another >> >> error >> >> (which actually turned out to be this one), i saw the first report by >> >> Ying Huang on November. >> >> https://lkml.org/lkml/2015/11/2/93 >> > >> > Ying, could you CC the subsystem list for these reports? This one was >> > CC'd to Sirnam, Greg and LKML. Sirnam is too new to understand what >> > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML. >> >> Sure. But what is the best way to find the subsystem list for a patch? >> Now we use author, committer, and the xxx-by: and Cc: list in patch to >> find the recipient. > > For this one it's simple. Get the filename from the git commit and > use ./scripts/get_maintainer.pl -f $file. That should work generally, > the only issue is maybe some patches affect things across subsystems. > > Also I don't know if netdev wants these emails? Do you guys CC them on > 0day warnings? Only if it appears in Cc: list of the commit. Best Regards, Huang, Ying ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Tue, Jan 26, 2016 at 08:32:48AM +0800, Huang, Ying wrote: > Dan Carpenter writes: > > > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote: > >> Apart from the mail which Ying Huang sent to me last week for another error > >> (which actually turned out to be this one), i saw the first report by > >> Ying Huang on November. > >> https://lkml.org/lkml/2015/11/2/93 > > > > Ying, could you CC the subsystem list for these reports? This one was > > CC'd to Sirnam, Greg and LKML. Sirnam is too new to understand what > > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML. > > Sure. But what is the best way to find the subsystem list for a patch? > Now we use author, committer, and the xxx-by: and Cc: list in patch to > find the recipient. For this one it's simple. Get the filename from the git commit and use ./scripts/get_maintainer.pl -f $file. That should work generally, the only issue is maybe some patches affect things across subsystems. Also I don't know if netdev wants these emails? Do you guys CC them on 0day warnings? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
Dan Carpenter writes: > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote: >> Apart from the mail which Ying Huang sent to me last week for another error >> (which actually turned out to be this one), i saw the first report by >> Ying Huang on November. >> https://lkml.org/lkml/2015/11/2/93 > > Ying, could you CC the subsystem list for these reports? This one was > CC'd to Sirnam, Greg and LKML. Sirnam is too new to understand what > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML. Sure. But what is the best way to find the subsystem list for a patch? Now we use author, committer, and the xxx-by: and Cc: list in patch to find the recipient. Best Regards, Huang, Ying ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/22] staging: iio: Fix dependencies for !HAS_IOMEM archs
Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger --- drivers/staging/iio/adc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig index 58d4517..b9519be 100644 --- a/drivers/staging/iio/adc/Kconfig +++ b/drivers/staging/iio/adc/Kconfig @@ -6,6 +6,7 @@ menu "Analog to digital converters" config AD7606 tristate "Analog Devices AD7606 ADC driver" depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM select IIO_BUFFER select IIO_TRIGGERED_BUFFER help -- 1.8.4.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: nvec: replace led_classdev_register
Am Donnerstag 21 Januar 2016, 10:23:46 schrieb Gujulan Elango, Hari Prasath:
> From: Hari Prasath Gujulan Elango
>
> Replace the led_classdev_register() with the platform managed version
> devm_led_classdev_register() & henceforth remove the redundant
> nvec_paz00_remove() function.
>
> Signed-off-by: Hari Prasath Gujulan Elango
Thanks!
Acked-by: Marc Dietrich
> ---
> drivers/staging/nvec/nvec_paz00.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/staging/nvec/nvec_paz00.c
> b/drivers/staging/nvec/nvec_paz00.c index 68146bf..cddbfd2 100644
> --- a/drivers/staging/nvec/nvec_paz00.c
> +++ b/drivers/staging/nvec/nvec_paz00.c
> @@ -63,7 +63,7 @@ static int nvec_paz00_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, led);
>
> - ret = led_classdev_register(&pdev->dev, &led->cdev);
> + ret = devm_led_classdev_register(&pdev->dev, &led->cdev);
> if (ret < 0)
> return ret;
>
> @@ -73,18 +73,8 @@ static int nvec_paz00_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int nvec_paz00_remove(struct platform_device *pdev)
> -{
> - struct nvec_led *led = platform_get_drvdata(pdev);
> -
> - led_classdev_unregister(&led->cdev);
> -
> - return 0;
> -}
> -
> static struct platform_driver nvec_paz00_driver = {
> .probe = nvec_paz00_probe,
> - .remove = nvec_paz00_remove,
> .driver = {
> .name = "nvec-paz00",
> },
signature.asc
Description: This is a digitally signed message part.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, Jan 25, 2016 at 06:19:44PM +0530, Sudip Mukherjee wrote: > On Mon, Jan 25, 2016 at 03:40:41PM +0300, Dan Carpenter wrote: > > Ying, could you CC the subsystem list for these reports? This one was > > CC'd to Sirnam, Greg and LKML. Sirnam is too new to understand what > > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML. > > I only read the mails whose subject is interesting and something which > I can understand. I am also still new to understand many of the things. > I am sure Alan, Greg, Linus, they will read all the mails. You could be disappointed then. Linus has always said that he doesn't read it and even pretends he's not even subscribed. Greg probably doesn't have the time given that he's flooded with the stable@ messages and virtually every e-mail on the kernel where he's CC'd like this one. As for Alan I'm not even sure he still manages to catch up with this volume. I personally stopped 7 years ago after I didn't have this dedicated display constantly on it anymore, and since then the traffic has doubled. And by then I was only reading the subjects... However LKML is great as a searchable public archive. Willy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [dm-devel] [PATCH 22/26] iscsi_tcp: Use ahash
On 01/24/2016 07:19 AM, Herbert Xu wrote: > This patch replaces uses of the long obsolete hash interface with > ahash. > > Signed-off-by: Herbert Xu > --- > > drivers/scsi/iscsi_tcp.c| 54 > ++-- > drivers/scsi/iscsi_tcp.h|4 +-- > drivers/scsi/libiscsi_tcp.c | 29 +-- > include/scsi/libiscsi_tcp.h | 13 +- > 4 files changed, 58 insertions(+), 42 deletions(-) > iSCSI parts look ok. Reviewed-by: Mike Christie ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: visornic: remove useless memset
alloc_etherdev() calls alloc_netdev_mqs(), which
already uses kzalloc/vzalloc.
This clears a sparse warning :
drivers/staging/unisys/visornic/visornic_main.c:1366:15: warning: memset with
byte count of 1460112
Signed-off-by: Hugo Camboulive
---
drivers/staging/unisys/visornic/visornic_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/unisys/visornic/visornic_main.c
b/drivers/staging/unisys/visornic/visornic_main.c
index 0519470..d894815 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -1363,7 +1363,6 @@ devdata_initialize(struct visornic_devdata *devdata,
struct visor_device *dev)
{
if (!devdata)
return NULL;
- memset(devdata, '\0', sizeof(struct visornic_devdata));
devdata->dev = dev;
devdata->incarnation_id = get_jiffies_64();
return devdata;
--
2.7.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: Fix book keeping of skb during batching process
From: Haiyang Zhang Date: Mon, 25 Jan 2016 09:49:31 -0800 > Since eliminating send_completion_tid from struct hv_netvsc_packet, we > haven't add proper book keeping for the skb of the batched packet. This > patch fixes this issue and allows the previous skb is properly freed. > Otherwise, a panic may happen. > Thanks to Simon Xiao for bisecting and analysis. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: use skb_get_hash() instead of a homegrown implementation
From: Vitaly Kuznetsov
Date: Mon, 25 Jan 2016 16:00:41 +0100
> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
> VLAN ID to flow_keys")) introduced a performance regression in netvsc
> driver. Is problem is, however, not the above mentioned commit but the
> fact that netvsc_set_hash() function did some assumptions on the struct
> flow_keys data layout and this is wrong.
>
> Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change
> will also imply switching to Jenkins hash from the currently used Toeplitz
> but it seems there is no good excuse for Toeplitz to stay.
>
> Signed-off-by: Vitaly Kuznetsov
Applied.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Move wlan-ng out of staging?
On Mon, Jan 25, 2016 at 01:16:56PM +0100, Ksenija Stanojević wrote: > Hi All, > > I'm helping Greg do a bit of cleanup in the staging tree, I noticed that > wlan-ng driver is maybe ready to be moved out of staging. Are there > any TODO tasks left to do beside checkpatch.pl clean-up? I happened to look through this code recently. It's terrible. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] staging: media: lirc: use new parport device model
Em Mon, 25 Jan 2016 23:03:43 +0530 Sudip Mukherjee escreveu: > On Monday 25 January 2016 10:42 PM, Mauro Carvalho Chehab wrote: > > Em Mon, 25 Jan 2016 22:32:31 +0530 > > Sudip Mukherjee escreveu: > > > >> On Mon, Jan 25, 2016 at 02:29:06PM -0200, Mauro Carvalho Chehab wrote: > >>> Em Fri, 18 Dec 2015 18:35:29 +0530 > >>> Sudip Mukherjee escreveu: > >>> > Modify lirc_parallel driver to use the new parallel port device model. > >>> > >>> Did you or someone else tested this patch? > >> > >> Only build tested and tested by inserting and removing the module. > >> But since the only change is in the way it registers and nothing else > >> so it should not break. > > > > It would be worth to wait for a while in the hope that someone could > > test with a real hardware. > > Sure, we have lots of time for 4.6 merge window. May be if you have the > schematic somewhere then I can try to build one. Its a Homebrew one, so > maybe I can try. Take a look at: http://www.lirc.org/parallel.html Regards, Mauro > > regards > sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] staging: media: lirc: use new parport device model
On Monday 25 January 2016 10:42 PM, Mauro Carvalho Chehab wrote: Em Mon, 25 Jan 2016 22:32:31 +0530 Sudip Mukherjee escreveu: On Mon, Jan 25, 2016 at 02:29:06PM -0200, Mauro Carvalho Chehab wrote: Em Fri, 18 Dec 2015 18:35:29 +0530 Sudip Mukherjee escreveu: Modify lirc_parallel driver to use the new parallel port device model. Did you or someone else tested this patch? Only build tested and tested by inserting and removing the module. But since the only change is in the way it registers and nothing else so it should not break. It would be worth to wait for a while in the hope that someone could test with a real hardware. Sure, we have lots of time for 4.6 merge window. May be if you have the schematic somewhere then I can try to build one. Its a Homebrew one, so maybe I can try. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 00/26] use unified firmware and add ops in cfg
On Mon, Jan 25, 2016 at 03:15:31PM +0200, Kalle Valo wrote: > Glen Lee writes: > > > This patch series contains > > > > * support suspend and resume functionality > > > > * use a unified firmware for all mode of operations(station, ap, p2p) > > > > * support Station/AP concurrency > > > > * increase link speed > > > > * add a cfg operation for adjusting the tx power > > > > * fix bug on p2p, WEP security and chaning virtual interface > > > > Changes in V2: details in each patch files. > > - 0004-staging-wilc1000-add-sdio-resume-suspend.patch > > It's good practise to also add "staging: wilc1000: " prefix to the cover > letter. Yes please, otherwise it misses my filters when I go to apply patches for a subsystem and I have to find it by hand :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] staging: media: lirc: use new parport device model
Em Mon, 25 Jan 2016 22:32:31 +0530 Sudip Mukherjee escreveu: > On Mon, Jan 25, 2016 at 02:29:06PM -0200, Mauro Carvalho Chehab wrote: > > Em Fri, 18 Dec 2015 18:35:29 +0530 > > Sudip Mukherjee escreveu: > > > > > Modify lirc_parallel driver to use the new parallel port device model. > > > > Did you or someone else tested this patch? > > Only build tested and tested by inserting and removing the module. > But since the only change is in the way it registers and nothing else > so it should not break. It would be worth to wait for a while in the hope that someone could test with a real hardware. > > Only patch 1/5 is applying now. I will send v2 after removing patch 4/5. I applied the other patches, with some fixes from my side. > > regards > sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: use skb_get_hash() instead of a homegrown implementation
On Mon, 2016-01-25 at 16:00 +0100, Vitaly Kuznetsov wrote:
> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
> VLAN ID to flow_keys")) introduced a performance regression in netvsc
> driver. Is problem is, however, not the above mentioned commit but the
> fact that netvsc_set_hash() function did some assumptions on the struct
> flow_keys data layout and this is wrong.
>
> Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change
> will also imply switching to Jenkins hash from the currently used Toeplitz
> but it seems there is no good excuse for Toeplitz to stay.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
Acked-by: Eric Dumazet
Thanks !
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] staging: media: lirc: use new parport device model
On Mon, Jan 25, 2016 at 02:29:06PM -0200, Mauro Carvalho Chehab wrote: > Em Fri, 18 Dec 2015 18:35:29 +0530 > Sudip Mukherjee escreveu: > > > Modify lirc_parallel driver to use the new parallel port device model. > > Did you or someone else tested this patch? Only build tested and tested by inserting and removing the module. But since the only change is in the way it registers and nothing else so it should not break. Only patch 1/5 is applying now. I will send v2 after removing patch 4/5. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] staging: media: lirc: use new parport device model
Em Fri, 18 Dec 2015 18:35:29 +0530
Sudip Mukherjee escreveu:
> Modify lirc_parallel driver to use the new parallel port device model.
Did you or someone else tested this patch?
Regards,
Mauro
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/staging/media/lirc/lirc_parallel.c | 100
> +++--
> 1 file changed, 65 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_parallel.c
> b/drivers/staging/media/lirc/lirc_parallel.c
> index 0156114..20ec9b6 100644
> --- a/drivers/staging/media/lirc/lirc_parallel.c
> +++ b/drivers/staging/media/lirc/lirc_parallel.c
> @@ -629,43 +629,26 @@ static void kf(void *handle)
> */
> }
>
> -/*** module initialization and cleanup ***/
> -
> -static int __init lirc_parallel_init(void)
> +static void lirc_parallel_attach(struct parport *port)
> {
> - int result;
> + struct pardev_cb lirc_parallel_cb;
>
> - result = platform_driver_register(&lirc_parallel_driver);
> - if (result) {
> - pr_notice("platform_driver_register returned %d\n", result);
> - return result;
> - }
> + if (port->base != io)
> + return;
>
> - lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
> - if (!lirc_parallel_dev) {
> - result = -ENOMEM;
> - goto exit_driver_unregister;
> - }
> + pport = port;
> + memset(&lirc_parallel_cb, 0, sizeof(lirc_parallel_cb));
> + lirc_parallel_cb.preempt = pf;
> + lirc_parallel_cb.wakeup = kf;
> + lirc_parallel_cb.irq_func = lirc_lirc_irq_handler;
>
> - result = platform_device_add(lirc_parallel_dev);
> - if (result)
> - goto exit_device_put;
> -
> - pport = parport_find_base(io);
> - if (!pport) {
> - pr_notice("no port at %x found\n", io);
> - result = -ENXIO;
> - goto exit_device_put;
> - }
> - ppdevice = parport_register_device(pport, LIRC_DRIVER_NAME,
> -pf, kf, lirc_lirc_irq_handler, 0,
> -NULL);
> - parport_put_port(pport);
> + ppdevice = parport_register_dev_model(port, LIRC_DRIVER_NAME,
> + &lirc_parallel_cb, 0);
> if (!ppdevice) {
> pr_notice("parport_register_device() failed\n");
> - result = -ENXIO;
> - goto exit_device_put;
> + return;
> }
> +
> if (parport_claim(ppdevice) != 0)
> goto skip_init;
> is_claimed = 1;
> @@ -693,18 +676,66 @@ static int __init lirc_parallel_init(void)
>
> is_claimed = 0;
> parport_release(ppdevice);
> - skip_init:
> +
> +skip_init:
> + return;
> +}
> +
> +static void lirc_parallel_detach(struct parport *port)
> +{
> + if (port->base != io)
> + return;
> +
> + parport_unregister_device(ppdevice);
> +}
> +
> +static struct parport_driver lirc_parport_driver = {
> + .name = LIRC_DRIVER_NAME,
> + .match_port = lirc_parallel_attach,
> + .detach = lirc_parallel_detach,
> + .devmodel = true,
> +};
> +
> +/*** module initialization and cleanup ***/
> +
> +static int __init lirc_parallel_init(void)
> +{
> + int result;
> +
> + result = platform_driver_register(&lirc_parallel_driver);
> + if (result) {
> + pr_notice("platform_driver_register returned %d\n", result);
> + return result;
> + }
> +
> + lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
> + if (!lirc_parallel_dev) {
> + result = -ENOMEM;
> + goto exit_driver_unregister;
> + }
> +
> + result = platform_device_add(lirc_parallel_dev);
> + if (result)
> + goto exit_device_put;
> +
> + result = parport_register_driver(&lirc_parport_driver);
> + if (result) {
> + pr_notice("parport_register_driver returned %d\n", result);
> + goto exit_device_put;
> + }
> +
> driver.dev = &lirc_parallel_dev->dev;
> driver.minor = lirc_register_driver(&driver);
> if (driver.minor < 0) {
> pr_notice("register_chrdev() failed\n");
> - parport_unregister_device(ppdevice);
> result = -EIO;
> - goto exit_device_put;
> + goto exit_unregister;
> }
> pr_info("installed using port 0x%04x irq %d\n", io, irq);
> return 0;
>
> +exit_unregister:
> + parport_unregister_driver(&lirc_parport_driver);
> exit_device_put:
> platform_device_put(lirc_parallel_dev);
> exit_driver_unregister:
> @@ -714,9 +745,8 @@ exit_driver_unregister:
>
> static void __exit lirc_parallel_exit(void)
> {
> - parport_unregister_device(ppdevice);
> lirc_unregister_driver(driver.minor);
> -
> + parport_unregister_driver(&lirc_parport_driver);
> platform_device_unregister(lirc_parallel_dev);
> platform_driver_unregister(&lirc_pa
Re: [PATCH 4/5] staging: media: lirc: place operator on previous line
Em Fri, 18 Dec 2015 18:35:28 +0530
Sudip Mukherjee escreveu:
> checkpatch complains about the logical operator, which should be on the
> previous line.
IMHO, this is a matter of personal taste. I prefer to keep the operator
on the next line, as it makes clearer to see why the logic was broken.
Anyway, this patch doesn't apply.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/staging/media/lirc/lirc_parallel.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_parallel.c
> b/drivers/staging/media/lirc/lirc_parallel.c
> index e09894d..0156114 100644
> --- a/drivers/staging/media/lirc/lirc_parallel.c
> +++ b/drivers/staging/media/lirc/lirc_parallel.c
> @@ -157,9 +157,9 @@ static unsigned int init_lirc_timer(void)
> count++;
> level = newlevel;
> do_gettimeofday(&now);
> - } while (count < 1000 && (now.tv_sec < tv.tv_sec
> - || (now.tv_sec == tv.tv_sec
> - && now.tv_usec < tv.tv_usec)));
> + } while (count < 1000 && (now.tv_sec < tv.tv_sec ||
> + (now.tv_sec == tv.tv_sec &&
> +now.tv_usec < tv.tv_usec)));
>
> timeelapsed = (now.tv_sec + 1 - tv.tv_sec) * 100
>+ (now.tv_usec - tv.tv_usec);
> @@ -279,8 +279,8 @@ static void lirc_lirc_irq_handler(void *blah)
> level = newlevel;
>
> /* giving up */
> - if (signal > timeout
> - || (check_pselecd && (in(1) & LP_PSELECD))) {
> + if (signal > timeout ||
> + (check_pselecd && (in(1) & LP_PSELECD))) {
> signal = 0;
> pr_notice("timeout\n");
> break;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 16/26] libceph: Use skcipher
On Sun, Jan 24, 2016 at 2:18 PM, Herbert Xu wrote:
> This patch replaces uses of blkcipher with skcipher.
>
> Signed-off-by: Herbert Xu
> ---
>
> net/ceph/crypto.c | 97
> +++---
> 1 file changed, 56 insertions(+), 41 deletions(-)
Could you get rid of ivsize instead of assigning to it - see the
attached diff?
Otherwise:
Acked-by: Ilya Dryomov
Thanks,
Ilya
diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c
index 42e8649c6e79..db2847ac5f12 100644
--- a/net/ceph/crypto.c
+++ b/net/ceph/crypto.c
@@ -4,7 +4,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
#include
@@ -79,9 +80,9 @@ int ceph_crypto_key_unarmor(struct ceph_crypto_key *key,
const char *inkey)
return 0;
}
-static struct crypto_blkcipher *ceph_crypto_alloc_cipher(void)
+static struct crypto_skcipher *ceph_crypto_alloc_cipher(void)
{
- return crypto_alloc_blkcipher("cbc(aes)", 0, CRYPTO_ALG_ASYNC);
+ return crypto_alloc_skcipher("cbc(aes)", 0, CRYPTO_ALG_ASYNC);
}
static const u8 *aes_iv = (u8 *)CEPH_AES_IV;
@@ -162,11 +163,10 @@ static int ceph_aes_encrypt(const void *key, int key_len,
{
struct scatterlist sg_in[2], prealloc_sg;
struct sg_table sg_out;
- struct crypto_blkcipher *tfm = ceph_crypto_alloc_cipher();
- struct blkcipher_desc desc = { .tfm = tfm, .flags = 0 };
+ struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
+ SKCIPHER_REQUEST_ON_STACK(req, tfm);
int ret;
- void *iv;
- int ivsize;
+ char iv[AES_BLOCK_SIZE];
size_t zero_padding = (0x10 - (src_len & 0x0f));
char pad[16];
@@ -184,10 +184,13 @@ static int ceph_aes_encrypt(const void *key, int key_len,
if (ret)
goto out_tfm;
- crypto_blkcipher_setkey((void *)tfm, key, key_len);
- iv = crypto_blkcipher_crt(tfm)->iv;
- ivsize = crypto_blkcipher_ivsize(tfm);
- memcpy(iv, aes_iv, ivsize);
+ crypto_skcipher_setkey((void *)tfm, key, key_len);
+ memcpy(iv, aes_iv, AES_BLOCK_SIZE);
+
+ skcipher_request_set_tfm(req, tfm);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, sg_in, sg_out.sgl,
+ src_len + zero_padding, iv);
/*
print_hex_dump(KERN_ERR, "enc key: ", DUMP_PREFIX_NONE, 16, 1,
@@ -197,8 +200,8 @@ static int ceph_aes_encrypt(const void *key, int key_len,
print_hex_dump(KERN_ERR, "enc pad: ", DUMP_PREFIX_NONE, 16, 1,
pad, zero_padding, 1);
*/
- ret = crypto_blkcipher_encrypt(&desc, sg_out.sgl, sg_in,
-src_len + zero_padding);
+ ret = crypto_skcipher_encrypt(req);
+ skcipher_request_zero(req);
if (ret < 0) {
pr_err("ceph_aes_crypt failed %d\n", ret);
goto out_sg;
@@ -211,7 +214,7 @@ static int ceph_aes_encrypt(const void *key, int key_len,
out_sg:
teardown_sgtable(&sg_out);
out_tfm:
- crypto_free_blkcipher(tfm);
+ crypto_free_skcipher(tfm);
return ret;
}
@@ -222,11 +225,10 @@ static int ceph_aes_encrypt2(const void *key, int
key_len, void *dst,
{
struct scatterlist sg_in[3], prealloc_sg;
struct sg_table sg_out;
- struct crypto_blkcipher *tfm = ceph_crypto_alloc_cipher();
- struct blkcipher_desc desc = { .tfm = tfm, .flags = 0 };
+ struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
+ SKCIPHER_REQUEST_ON_STACK(req, tfm);
int ret;
- void *iv;
- int ivsize;
+ char iv[AES_BLOCK_SIZE];
size_t zero_padding = (0x10 - ((src1_len + src2_len) & 0x0f));
char pad[16];
@@ -245,10 +247,13 @@ static int ceph_aes_encrypt2(const void *key, int
key_len, void *dst,
if (ret)
goto out_tfm;
- crypto_blkcipher_setkey((void *)tfm, key, key_len);
- iv = crypto_blkcipher_crt(tfm)->iv;
- ivsize = crypto_blkcipher_ivsize(tfm);
- memcpy(iv, aes_iv, ivsize);
+ crypto_skcipher_setkey((void *)tfm, key, key_len);
+ memcpy(iv, aes_iv, AES_BLOCK_SIZE);
+
+ skcipher_request_set_tfm(req, tfm);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, sg_in, sg_out.sgl,
+ src1_len + src2_len + zero_padding, iv);
/*
print_hex_dump(KERN_ERR, "enc key: ", DUMP_PREFIX_NONE, 16, 1,
@@ -260,8 +265,8 @@ static int ceph_aes_encrypt2(const void *key, int key_len,
void *dst,
print_hex_dump(KERN_ERR, "enc pad: ", DUMP_PREFIX_NONE, 16, 1,
pad, zero_padding, 1);
*/
- ret = crypto_blkcipher_encrypt(&desc, sg_out.sgl, sg_in,
-src1_len + src2_len + zero_padding);
+ ret = crypto_skcipher_encrypt(req);
+ skcipher_request_zero(req);
if (ret
[PATCH net-next] hv_netvsc: Fix book keeping of skb during batching process
Since eliminating send_completion_tid from struct hv_netvsc_packet, we
haven't add proper book keeping for the skb of the batched packet. This
patch fixes this issue and allows the previous skb is properly freed.
Otherwise, a panic may happen.
Thanks to Simon Xiao for bisecting and analysis.
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
---
drivers/net/hyperv/hyperv_net.h |1 +
drivers/net/hyperv/netvsc.c | 33 ++---
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index f4130af..fcb92c0 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -624,6 +624,7 @@ struct nvsp_message {
#define RNDIS_PKT_ALIGN_DEFAULT 8
struct multi_send_data {
+ struct sk_buff *skb; /* skb containing the pkt */
struct hv_netvsc_packet *pkt; /* netvsc pkt pending */
u32 count; /* counter of batched packets */
};
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 059fc52..ec313fc 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -841,6 +841,18 @@ static inline int netvsc_send_pkt(
return ret;
}
+/* Move packet out of multi send data (msd), and clear msd */
+static inline void move_pkt_msd(struct hv_netvsc_packet **msd_send,
+ struct sk_buff **msd_skb,
+ struct multi_send_data *msdp)
+{
+ *msd_skb = msdp->skb;
+ *msd_send = msdp->pkt;
+ msdp->skb = NULL;
+ msdp->pkt = NULL;
+ msdp->count = 0;
+}
+
int netvsc_send(struct hv_device *device,
struct hv_netvsc_packet *packet,
struct rndis_message *rndis_msg,
@@ -855,6 +867,7 @@ int netvsc_send(struct hv_device *device,
unsigned int section_index = NETVSC_INVALID_INDEX;
struct multi_send_data *msdp;
struct hv_netvsc_packet *msd_send = NULL, *cur_send = NULL;
+ struct sk_buff *msd_skb = NULL;
bool try_batch;
bool xmit_more = (skb != NULL) ? skb->xmit_more : false;
@@ -897,10 +910,8 @@ int netvsc_send(struct hv_device *device,
net_device->send_section_size) {
section_index = netvsc_get_next_send_section(net_device);
if (section_index != NETVSC_INVALID_INDEX) {
- msd_send = msdp->pkt;
- msdp->pkt = NULL;
- msdp->count = 0;
- msd_len = 0;
+ move_pkt_msd(&msd_send, &msd_skb, msdp);
+ msd_len = 0;
}
}
@@ -919,31 +930,31 @@ int netvsc_send(struct hv_device *device,
packet->total_data_buflen += msd_len;
}
- if (msdp->pkt)
- dev_kfree_skb_any(skb);
+ if (msdp->skb)
+ dev_kfree_skb_any(msdp->skb);
if (xmit_more && !packet->cp_partial) {
+ msdp->skb = skb;
msdp->pkt = packet;
msdp->count++;
} else {
cur_send = packet;
+ msdp->skb = NULL;
msdp->pkt = NULL;
msdp->count = 0;
}
} else {
- msd_send = msdp->pkt;
- msdp->pkt = NULL;
- msdp->count = 0;
+ move_pkt_msd(&msd_send, &msd_skb, msdp);
cur_send = packet;
}
if (msd_send) {
- m_ret = netvsc_send_pkt(msd_send, net_device, pb, skb);
+ m_ret = netvsc_send_pkt(msd_send, net_device, NULL, msd_skb);
if (m_ret != 0) {
netvsc_free_send_slot(net_device,
msd_send->send_buf_index);
- dev_kfree_skb_any(skb);
+ dev_kfree_skb_any(msd_skb);
}
}
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] iio: ade7753: avoid uninitialized data
The ade7753_spi_read_reg_16() will either successfully read a value
from SPI, or return a failure code without delivering data. However,
the ade7753_stop_device() and ade7753_reset() functions use the returned
data without checking for an error condition first. Gcc detects this
as a possible bug and warns about it:
drivers/staging/iio/meter/ade7753.c: In function 'ade7753_remove':
drivers/staging/iio/meter/ade7753.c:348:6: error: 'val' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
val |= BIT(4); /* AD converters can be turned off */
^
drivers/staging/iio/meter/ade7753.c:345:6: note: 'val' was declared here
u16 val;
^
drivers/staging/iio/meter/ade7753.c: In function 'ade7753_probe':
drivers/staging/iio/meter/ade7753.c:222:6: error: 'val' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
In both cases, we can avoids the warning by checking the return code
before using the data.
Signed-off-by: Arnd Bergmann
---
drivers/staging/iio/meter/ade7753.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/meter/ade7753.c
b/drivers/staging/iio/meter/ade7753.c
index f129039bece3..69287108f793 100644
--- a/drivers/staging/iio/meter/ade7753.c
+++ b/drivers/staging/iio/meter/ade7753.c
@@ -217,8 +217,12 @@ error_ret:
static int ade7753_reset(struct device *dev)
{
u16 val;
+ int ret;
+
+ ret = ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val);
+ if (ret)
+ return ret;
- ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val);
val |= BIT(6); /* Software Chip Reset */
return ade7753_spi_write_reg_16(dev, ADE7753_MODE, val);
@@ -343,8 +347,12 @@ error_ret:
static int ade7753_stop_device(struct device *dev)
{
u16 val;
+ int ret;
+
+ ret = ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val);
+ if (ret)
+ return ret;
- ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val);
val |= BIT(4); /* AD converters can be turned off */
return ade7753_spi_write_reg_16(dev, ADE7753_MODE, val);
--
2.7.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: iio: ad5933: avoid uninitialized variable in error case
The ad5933_i2c_read function returns an error code to indicate
whether it could read data or not. However ad5933_work() ignores
this return code and just accesses the data unconditionally,
which gets detected by gcc as a possible bug:
drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work':
drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may
be used uninitialized in this function [-Wmaybe-uninitialized]
This adds minimal error handling so we only evaluate the
data if it was correctly read.
Signed-off-by: Arnd Bergmann
---
drivers/staging/iio/impedance-analyzer/ad5933.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
b/drivers/staging/iio/impedance-analyzer/ad5933.c
index 10c43dda0f5a..304bb464e478 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -647,6 +647,7 @@ static void ad5933_work(struct work_struct *work)
__be16 buf[2];
int val[2];
unsigned char status;
+ int ret;
mutex_lock(&indio_dev->mlock);
if (st->state == AD5933_CTRL_INIT_START_FREQ) {
@@ -658,9 +659,9 @@ static void ad5933_work(struct work_struct *work)
return;
}
- ad5933_i2c_read(st->client, AD5933_REG_STATUS, 1, &status);
+ ret = ad5933_i2c_read(st->client, AD5933_REG_STATUS, 1, &status);
- if (status & AD5933_STAT_DATA_VALID) {
+ if (!ret && (status & AD5933_STAT_DATA_VALID)) {
int scan_count = bitmap_weight(indio_dev->active_scan_mask,
indio_dev->masklength);
ad5933_i2c_read(st->client,
--
2.7.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Move skein out of staging?
Hi Ksenija, On Mon, Jan 25, 2016 at 01:18:46PM +0100, Ksenija Stanojević wrote: > I'm helping Greg do a bit of cleanup in the staging tree, I noticed that > skein driver is maybe ready to be moved out of staging. Are there > any TODO tasks left to do beside checkpatch.pl clean-up? Well, I haven't looked at the code recently. But, iirc, most of the major todo items were done. I'm honestly not too worried about checkpatch warnings at this point. My biggest problem is -ETIME. If someone creates a series to move it over, I'll be happy to test and Ack. Otherwise, we'll be waiting a bit. :-/ I barely have time to keep up with my other maintainer duties, which are hobby/freetime as well. There's occasionally been interest in helping out, but it always seems to peter out prior to the actual move. thx, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: sm750fb, fix typos
From: Matej Vasek
The code contained typos like "structur", "fointers", etc. Fix that.
No code change, only comments.
Signed-off-by: Matej Vasek
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Greg Kroah-Hartman
Cc:
Cc:
Signed-off-by: Jiri Slaby
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 4 ++--
drivers/staging/sm750fb/ddk750_mode.c | 2 +-
drivers/staging/sm750fb/ddk750_sii164.h | 5 -
drivers/staging/sm750fb/sm750.c | 2 +-
drivers/staging/sm750fb/sm750.h | 2 +-
drivers/staging/sm750fb/sm750_accel.c | 4 ++--
drivers/staging/sm750fb/sm750_accel.h | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 2 +-
8 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 7be2111284f4..29140949fde7 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -128,7 +128,7 @@ static unsigned int hw_i2c_write_data(
if (hw_i2c_wait_tx_done() != 0)
break;
- /* Substract length */
+ /* Subtract length */
length -= (count + 1);
/* Total byte written */
@@ -195,7 +195,7 @@ static unsigned int hw_i2c_read_data(
for (i = 0; i <= count; i++)
*buf++ = PEEK32(I2C_DATA0 + i);
- /* Substract length by 16 */
+ /* Subtract length by 16 */
length -= (count + 1);
/* Number of bytes read. */
diff --git a/drivers/staging/sm750fb/ddk750_mode.c
b/drivers/staging/sm750fb/ddk750_mode.c
index fa35926680ab..58421898c83d 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -42,7 +42,7 @@ static unsigned long
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
dispControl &= FIELD_CLEAR(CRT_DISPLAY_CTRL, CLK);
/* Set bit 29:27 of display control register for the right clock */
- /* Note that SM750LE only need to supported 7 resoluitons. */
+ /* Note that SM750LE only need to supported 7 resolutions. */
if (x == 800 && y == 600)
dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK,
PLL41);
else if (x == 1024 && y == 768)
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h
b/drivers/staging/sm750fb/ddk750_sii164.h
index f2610c90eeb4..664ad089f753 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -39,7 +39,10 @@ unsigned char sii164IsConnected(void);
unsigned char sii164CheckInterrupt(void);
void sii164ClearInterrupt(void);
#endif
-/* below register definination is used for Silicon Image SiI164 DVI controller
chip */
+/*
+ * below register definition is used for
+ * Silicon Image SiI164 DVI controller chip
+ */
/*
* Vendor ID registers
*/
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index c78421b5b0e7..9dac9ec95428 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -319,7 +319,7 @@ static int lynxfb_ops_set_par(struct fb_info *info)
var = &info->var;
fix = &info->fix;
- /* fix structur is not so FIX ... */
+ /* fix structure is not so FIX ... */
line_length = var->xres_virtual * var->bits_per_pixel / 8;
line_length = ALIGN(line_length, crtc->line_pad);
fix->line_length = line_length;
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index b0a93cdc7292..b2089542862e 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -53,7 +53,7 @@ struct lynx_accel {
/* base virtual address of de data port */
volatile unsigned char __iomem *dpPortBase;
- /* function fointers */
+ /* function pointers */
void (*de_init)(struct lynx_accel *);
int (*de_wait)(void);/* see if hardware ready to work */
diff --git a/drivers/staging/sm750fb/sm750_accel.c
b/drivers/staging/sm750fb/sm750_accel.c
index 43e59725920c..e150680a8cd1 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -53,7 +53,7 @@ void hw_de_init(struct lynx_accel *accel)
FIELD_CLEAR(DE_STRETCH_FORMAT, ADDRESSING)&
FIELD_CLEAR(DE_STRETCH_FORMAT, SOURCE_HEIGHT);
- /* DE_STRETCH bpp format need be initilized in setMode routine */
+ /* DE_STRETCH bpp format need be initialized in setMode routine */
write_dpr(accel, DE_STRETCH_FORMAT, (read_dpr(accel, DE_STRETCH_FORMAT)
& clr) | reg);
/* disable clipping and transparent */
@@ -305,7 +305,7 @@ int hw_imageblit(struct lynx_accel *accel,
u32 dx,
u32 dy, /* Starting coordinate of destination surface */
u32 width,
-u32 height, /* width and height of rectange in pixel value */
+u32 height, /*
[PATCH net-next] hv_netvsc: use skb_get_hash() instead of a homegrown implementation
Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
VLAN ID to flow_keys")) introduced a performance regression in netvsc
driver. Is problem is, however, not the above mentioned commit but the
fact that netvsc_set_hash() function did some assumptions on the struct
flow_keys data layout and this is wrong.
Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change
will also imply switching to Jenkins hash from the currently used Toeplitz
but it seems there is no good excuse for Toeplitz to stay.
Signed-off-by: Vitaly Kuznetsov
---
- This patch is an alternative to the previosely sent "hv_netvsc: don't make
assumptions on struct flow_keys layout" and Haiyang's "hv_netvsc: Use simple
parser for IPv4 and v6 headers".
---
drivers/net/hyperv/netvsc_drv.c | 67 ++---
1 file changed, 3 insertions(+), 64 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 1c8db9a..1d3a665 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -196,65 +196,6 @@ static void *init_ppi_data(struct rndis_message *msg, u32
ppi_size,
return ppi;
}
-union sub_key {
- u64 k;
- struct {
- u8 pad[3];
- u8 kb;
- u32 ka;
- };
-};
-
-/* Toeplitz hash function
- * data: network byte order
- * return: host byte order
- */
-static u32 comp_hash(u8 *key, int klen, void *data, int dlen)
-{
- union sub_key subk;
- int k_next = 4;
- u8 dt;
- int i, j;
- u32 ret = 0;
-
- subk.k = 0;
- subk.ka = ntohl(*(u32 *)key);
-
- for (i = 0; i < dlen; i++) {
- subk.kb = key[k_next];
- k_next = (k_next + 1) % klen;
- dt = ((u8 *)data)[i];
- for (j = 0; j < 8; j++) {
- if (dt & 0x80)
- ret ^= subk.ka;
- dt <<= 1;
- subk.k <<= 1;
- }
- }
-
- return ret;
-}
-
-static bool netvsc_set_hash(u32 *hash, struct sk_buff *skb)
-{
- struct flow_keys flow;
- int data_len;
-
- if (!skb_flow_dissect_flow_keys(skb, &flow, 0) ||
- !(flow.basic.n_proto == htons(ETH_P_IP) ||
- flow.basic.n_proto == htons(ETH_P_IPV6)))
- return false;
-
- if (flow.basic.ip_proto == IPPROTO_TCP)
- data_len = 12;
- else
- data_len = 8;
-
- *hash = comp_hash(netvsc_hash_key, HASH_KEYLEN, &flow, data_len);
-
- return true;
-}
-
static u16 netvsc_select_queue(struct net_device *ndev, struct sk_buff *skb,
void *accel_priv, select_queue_fallback_t fallback)
{
@@ -267,11 +208,9 @@ static u16 netvsc_select_queue(struct net_device *ndev,
struct sk_buff *skb,
if (nvsc_dev == NULL || ndev->real_num_tx_queues <= 1)
return 0;
- if (netvsc_set_hash(&hash, skb)) {
- q_idx = nvsc_dev->send_table[hash % VRSS_SEND_TAB_SIZE] %
- ndev->real_num_tx_queues;
- skb_set_hash(skb, hash, PKT_HASH_TYPE_L3);
- }
+ hash = skb_get_hash(skb);
+ q_idx = nvsc_dev->send_table[hash % VRSS_SEND_TAB_SIZE] %
+ ndev->real_num_tx_queues;
if (!nvsc_dev->chn_table[q_idx])
q_idx = 0;
--
2.5.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, 2016-01-25 at 18:21 +0530, Sudip Mukherjee wrote: > On Mon, Jan 25, 2016 at 04:47:26AM -0800, Joe Perches wrote: > > On Mon, 2016-01-25 at 12:16 +0300, Dan Carpenter wrote: > > > Ugh... Checkpatch told us to introduce bugs... :( We almost certainly > > > would have missed this bug in review, but it wasn't sent to the list so > > > I guess we'll never know. > > > > So when isn't usleep_range preferred over udelay? > > inside a spin_lock or in some interrupt routine. That's what timers-howto says and the checkpatch message for this refers to it. This message has been in checkpatch since 2010 commit 1a15a250862fda3fbdf8454cc7131e24de904e7c Author: Patrick Pannuto Maybe the checkpatch message can have "when not atomic" added or some such. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, 2016-01-25 at 12:16 +0300, Dan Carpenter wrote: > Ugh... Checkpatch told us to introduce bugs... :( We almost certainly > would have missed this bug in review, but it wasn't sent to the list so > I guess we'll never know. So when isn't usleep_range preferred over udelay? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: rtlwifi: rtl8821ae: Fix 5G failure when EEPROM is incorrectly encoded
> Recently, it has been reported that D-Link DWA-582 cards, which use an
> RTL8812AE chip are not able to scan for 5G networks. The problems started
> with kernel 4.2, which is the first version that had commit d10101a60372
> ("rtlwifi: rtl8821ae: Fix problem with regulatory information"). With this
> patch, the driver went from setting a default channel plan to using
> the value derived from EEPROM.
>
> Bug reports at https://bugzilla.kernel.org/show_bug.cgi?id=111031 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1279653 are examples of this
> problem.
>
> The problem was solved once I learned that the internal country code was
> resulting in a regulatory set with only 2.4 GHz channels. With the RTL8821AE
> chips available to me, the country code was such that both 2.4 and 5 GHz
> channels are allowed. The fix is to allow both bands even when the EEPROM
> is incorrectly encoded.
>
> Fixes: d10101a60372 ("rtlwifi: rtl8821ae: Fix problem with regulatory
> information")
> Signed-off-by: Larry Finger
> Cc: littlesmart...@gmail.com
> Cc: g...@codehaus.org
> Cc: Stable [v4.2+]
Thanks, applied to wireless-drivers.git.
Kalle Valo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 00/26] use unified firmware and add ops in cfg
Glen Lee writes: > This patch series contains > > * support suspend and resume functionality > > * use a unified firmware for all mode of operations(station, ap, p2p) > > * support Station/AP concurrency > > * increase link speed > > * add a cfg operation for adjusting the tx power > > * fix bug on p2p, WEP security and chaning virtual interface > > Changes in V2: details in each patch files. > - 0004-staging-wilc1000-add-sdio-resume-suspend.patch It's good practise to also add "staging: wilc1000: " prefix to the cover letter. -- Kalle Valo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, Jan 25, 2016 at 04:47:26AM -0800, Joe Perches wrote: > On Mon, 2016-01-25 at 12:16 +0300, Dan Carpenter wrote: > > Ugh... Checkpatch told us to introduce bugs... :( We almost certainly > > would have missed this bug in review, but it wasn't sent to the list so > > I guess we'll never know. > > So when isn't usleep_range preferred over udelay? inside a spin_lock or in some interrupt routine. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, Jan 25, 2016 at 03:40:41PM +0300, Dan Carpenter wrote: > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote: > > Apart from the mail which Ying Huang sent to me last week for another error > > (which actually turned out to be this one), i saw the first report by > > Ying Huang on November. > > https://lkml.org/lkml/2015/11/2/93 > > Ying, could you CC the subsystem list for these reports? This one was > CC'd to Sirnam, Greg and LKML. Sirnam is too new to understand what > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML. I only read the mails whose subject is interesting and something which I can understand. I am also still new to understand many of the things. I am sure Alan, Greg, Linus, they will read all the mails. I am setting up a filter in my lkml mails so that these reports are saved in a separate folder and I will keep and track the reports i understand. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote: > Apart from the mail which Ying Huang sent to me last week for another error > (which actually turned out to be this one), i saw the first report by > Ying Huang on November. > https://lkml.org/lkml/2015/11/2/93 Ying, could you CC the subsystem list for these reports? This one was CC'd to Sirnam, Greg and LKML. Sirnam is too new to understand what they mean, Greg is too busy, and only Sudip and Alan Cox read LKML. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Move wlan-ng out of staging?
On Mon, Jan 25, 2016 at 01:16:56PM +0100, Ksenija Stanojević wrote: > Hi All, > > I'm helping Greg do a bit of cleanup in the staging tree, I noticed that > wlan-ng driver is maybe ready to be moved out of staging. Are there > any TODO tasks left to do beside checkpatch.pl clean-up? I think the main part is still pending. using in-kernel wireless stack. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Move skein out of staging?
Hi Jason, I'm helping Greg do a bit of cleanup in the staging tree, I noticed that skein driver is maybe ready to be moved out of staging. Are there any TODO tasks left to do beside checkpatch.pl clean-up? Thanks, Ksenija ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Move wlan-ng out of staging?
Hi All, I'm helping Greg do a bit of cleanup in the staging tree, I noticed that wlan-ng driver is maybe ready to be moved out of staging. Are there any TODO tasks left to do beside checkpatch.pl clean-up? Thanks, Ksenija ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/11] sync framework de-staging: part 1 - clean up
Hey, Op 21-01-16 om 13:49 schreef Gustavo Padovan: > From: Gustavo Padovan > > Hi, > > The following patches are some clean ups on the sync framework before > we start the actual de-staging. The main changes here are the move of > SW_SYNC_USER to debugfs. Removal of struct sync_pt in favor of direct > use of struct fence. And the rename of sync_fence to sync_file, a name > to better reflect what it is for, a struct that connects struct fence(s) > to a file. > > Please review. Thanks. > > Gustavo Padovan (11): > staging/android: fix sync framework documentation > staging/android: sync: remove interfaces that are not used > staging/android: remove not used sync_timeline ops > staging/android: create a 'sync' dir for debugfs information > staging/android: move SW_SYNC_USER to a debugfs file > staging/android: rename sync_fence to sync_file > staging/android: rename 'sync_pt' to 'fence' in struct sync_fence_cb > staging/android: remove struct sync_pt > staging/android: remove unused var from sync_timeline_signal() > staging/android: remove pointless sync_timeline_signal at destroy > phase > staging/android: remove sync_fence_create_dma() > For whole series: Reviewed-by: Maarten Lankhorst Renaming sync_fence to sync_file makes sense, it should hopefully reduce confusion. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote: > On Mon, Jan 25, 2016 at 12:16:01PM +0300, Dan Carpenter wrote: > > Ugh... Checkpatch told us to introduce bugs... :( We almost certainly > > would have missed this bug in review, but it wasn't sent to the list so > > I guess we'll never know. > > I can find the v1 of the patch in usb list. > http://permalink.gmane.org/gmane.linux.usb.general/132712 That's so weird. Linux-usb is the wrong list. gmane doesn't let me see the thread. When I hit search archive it doesn't find the email. http://search.gmane.org/?query=Staging%3A+panel&group=gmane.linux.usb.general Everything is such crap... :( Google works though... The bug was detected in review that same day. http://www.spinics.net/lists/linux-usb/msg131737.html Ugh... What a stinking pile of fail. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
On Mon, Jan 25, 2016 at 12:16:01PM +0300, Dan Carpenter wrote: > Ugh... Checkpatch told us to introduce bugs... :( We almost certainly > would have missed this bug in review, but it wasn't sent to the list so > I guess we'll never know. I can find the v1 of the patch in usb list. http://permalink.gmane.org/gmane.linux.usb.general/132712 Apart from the mail which Ying Huang sent to me last week for another error (which actually turned out to be this one), i saw the first report by Ying Huang on November. https://lkml.org/lkml/2015/11/2/93 I think i will start keeping a list of errors sent by 0day to check if they are getting fixed or not. Or maybe Ying Huang has some mechanism. do you? regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
Anyway, I'll update Smatch to warn about these in the future. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"
Ugh... Checkpatch told us to introduce bugs... :( We almost certainly would have missed this bug in review, but it wasn't sent to the list so I guess we'll never know. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
