Re: [PATCH] staging: et131x: Fix errors caused by phydev->addr accesses before initialisation
On Sat, Aug 09, 2014 at 09:39:17PM -0700, Greg KH wrote: > On Tue, Aug 05, 2014 at 11:57:06PM +0100, Mark Einon wrote: > > Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed > > before it is initialised, by: > > > > - letting et131x_mii_write() take a phydev address, instead of using the one > > stored in adapter by default. This is so et131x_mdio_write() can use it's > > own > > addr value. > > - removing implementation of et131x_mdio_reset(), as it's not needed. > > - moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which > > uses > > phydev->addr, until after the mdiobus has been registered. > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751 > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121 > > Cc: sta...@vger.kernel.org > > Signed-off-by: Mark Einon > > --- > > drivers/staging/et131x/et131x.c | 68 > > - > > 1 file changed, 27 insertions(+), 41 deletions(-) > > I got 3 copies of this patch, all look to be different? > > I don't know what to do, so I've deleted them all, please resend the > version you want me to apply. Your email server rejected the first two as I sent them from home, not authenticating myself with my email server. I assumed you didn't receive them. I resent the patch from a different address, which may explain the differences. Sorry for the noise. Cheers, Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND] staging: et131x: Fix errors caused by phydev->addr accesses before initialisation
On Mon, Aug 11, 2014 at 01:39:59PM +0800, gre...@linuxfoundation.org wrote: > On Mon, Aug 11, 2014 at 12:32:55AM +0300, Anca Emanuel wrote: > > Do you have this hardware ? And did you test this ? > > Mark is the maintainer of this driver, I assume he has the hardware, if > not, I don't care, I trust him :) > Hi there, :) Yes, all tested on hardware. > > How can you cc stable without an Tested by somebody else ? > > Since when is a tested-by a requirement for a stable@ marking? Please > read Documentation/stable_kernel_rules.txt for the details. As Greg says, easily if you follow those rules. Cheers, Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] Staging: Netlogic: Fix compilation error
On Mon, Aug 11, 2014 at 07:04:20AM +, Ganesan Ramalingam wrote: > Hello Greg, > > The function nlm_cop2_enable() and nlm_cop2_restore() in > arch/mips/netlogic/xlr/fmn.c are changed in commit "64f6ebe MIPS: Netlogic: > rename nlm_cop2_save/restore", these functions are used in > driver/staging/netlogic/xlr_nae.c, so I am facing compilation error when > compiling Linux with NETLOGIC_XLR_NET=y. As 64f6ebe showed up in 3.11, way back in September 2013, I'm guessing that no one else ever builds this kernel module? With that track record, is it even used by anyone? Should we just remove it? > The patch "[PATCH 1/3] Staging: Netlogic: Fix compilation error" is to > address the above issue. > > Sorry that the commit message is not clear, I will submit a new patchset with > a appropriate message. And wrap your line-ends, it's nicer that way :) thanks, greg kh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] mmc: rtsx: fix incorrect last byte in R2 response
From: Roger Tseng
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, it is impossible to obtain the real values since the
controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
response. This could cause mmc stack to obtain inconsistent CID from the same
card after resume and misidentify it as a different card.
Fix by assigning a dummy value 0x01 to the last byte of R2 response.
Signed-off-by: Roger Tseng
---
drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a2..54849d8 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc
*host,
}
if (rsp_type == SD_RSP_TYPE_R2) {
+ ptr[16] = 1;
for (i = 0; i < 4; i++) {
cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 5d3766e..ca08df1 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,6 +435,7 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc *host,
}
if (rsp_type == SD_RSP_TYPE_R2) {
+ ptr[16] = 1;
for (i = 0; i < 4; i++) {
cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: android: fix watermark when cma enabled
On Mon, Aug 11, 2014 at 02:06:14AM +, Zengtao (B) wrote: > From: Zeng Tao Just fix your email client to reflect your full name. > Date: Tue, 5 Aug 2014 17:58:10 +0800 > Subject: [PATCH] drivers: android: fix watermark when cma enabled > Don't add these lines. Read the first paragraph of Documentation/email-clients.txt and try applying your patch to see what I mean. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Mon, Aug 11, 2014 at 5:23 AM, Dexuan Cui wrote:
>> -Original Message-
>> From: Greg KH [mailto:gre...@linuxfoundation.org]
>> > > >
>> > > > IMO the most feasible and need-the-least-change solution may be:
>> > > > the hyperv network VSC driver passes the event
>> > > > RNDIS_STATUS_NETWORK_CHANGE to the udev daemon?
>> > > >
>> > > No, don't do that, again, act like any other network device, drop the
>> > > link and bring it up when it comes back.
>> > >
>> > Hi Greg,
>> > Do you mean tearing down the net device and re-creating it (by
>> > register_netdev() and unregister_netdev)?
>>
>> No, don't you have link-detect for your network device? Toggle that, I
>> thought patches to do this were posted a while ago...
>>
>> But if you really want to tear the whole network device down and then
>> back up again, sure, that would also work.
> Hi Greg, Stephen,
>
> Thanks for the comments!
>
> I suppose you meant the below logic:
> if (refresh) {
> rtnl_lock();
> netif_carrier_off(net);
> netif_carrier_on(net);
> rtnl_unlock();
> }
>
> We have discussed this in the previous mails of this thread itself:
> e.g., http://marc.info/?l=linux-driver-devel&m=140593811715975&w=2
>
> Unluckily this logic doesn't work because the user-space daemons
> like ifplugd, usually don't renew the DHCP immediately as long as they
> receive a link-down message: they usually wait for some seconds and if
> they find the link becomes up soon, they won't trigger renew operations.
> (I guess this behavior can be somewhat reasonable: maybe the daemons
> try to not trigger DHCP renew on temporary link instability)
>
> If we use this logic in the kernel space, we'll have to "fix" the user-space
> daemons, like ifplugd, systemd-networkd...,etc.
networkd does not suffer from this problem, and in ifplugd it can be
disabled. Most other network drivers will send
IFF_LOWER_DOWN/IFF_LOWER_UP upon suspend/resume so if you were to do
the same you will not work any worse than the others. What would be
nice, as mentioned by Dan and Lennart, would be to send an additional
explicit event such as "resumed from suspend" or "L3 may be wrong".
That should be a generic thing though, to fix all such issues in one
go.
> I'm not sure our attempt to "fix" the daemons can be easily accepted.
> BTW, by CPUID, an application has a reliable way to determine if it's
> running on hyper-v on not. Maybe we can "fix" the behavior of the
> daemons when they run on hyper-v?
> BTW2, according to my limited experience, I doubt other VMMs can
> handle this auto-DHCP-renew-in-guest issue properly.
To the extent this is a problem, it is a generic one, so we should not
need any hyper-v specific logic in userspace.
> That was why Yue's patch wanted to add a SLEEP(10s) between the
> link-down and link-up events and hoped this could be an acceptable
> fix(while it turned out not, obviously), though we admit it's not so good
> to add such a magic number "10s" in a kernel driver.
>
> Please point it out if I missed or misunderstand something.
>
> Now I understand it's not good to pass the event to the udev daemon,
> and it's not good to use a SLEEP(10s) in the kernel space(even if it's in a
> "work" task here).
Please just expose to userspace what is happening (link lost/gained,
resumed from suspend/...), and let us sort out how to react to that.
If you put assumptions about what kind of timeouts (long-dead)
userspace uses into your drivers you'll just create a mess.
> Please let me know if it's the correct direction to fix the user-space
> daemons (ifplugd, systemd-networkd, etc).
> If you think this is viable and we should do this, I'll submit a
> netif_carrier_off/on patch first and will start to work with the
> projects of ifplugd, systemd-networkd and many OSVs to make the
> while thing work eventually.
Have you actually checked that carrier_off/on does not work on
anything but ifplugd? It would surprise me...
Cheers,
Tom
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: lustre: obdclass: genops.c: Cleaning up missing null-terminate after strncpy call
On Sun, Aug 10, 2014 at 01:48:00AM +0200, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. > No. This one isn't needed. The static checker *should* know this so it is a problem with the static checker and not with the code. Don't change code, just because the static checker has problems. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/7] staging: dgap: remove useless variable
On Sat, Aug 09, 2014 at 02:36:44PM +0900, Daeseok Youn wrote: > dgap_major_serial_registered and dgap_major_transparent_print_registered > could be checked whether a board is initialized. > But it doesn't need to check that variables becasue dgap module > isn't calling the dgap_cleanup_tty() without initializing > for a board completely. I don't understand. What about the call to dgap_cleanup_module() in dgap_init_module()? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/12] staging: lustre: Fix misplaced opening brace warnings
On Thu, Aug 07, 2014 at 09:35:43AM -0700, Joe Perches wrote:
> On Thu, 2014-08-07 at 19:01 +0300, Dan Carpenter wrote:
> > On Thu, Aug 07, 2014 at 09:01:36PM +0530, Srikrishan Malik wrote:
> > > On Wed, Aug 06, 2014 at 11:18:13PM +0300, Dan Carpenter wrote:
> > > > That looks silly before and after. Everything is indented in a funny
> > > > way.
> > >
> > > Is this better:
> > >
> > > static const ldlm_policy_data_t lookup_policy = {
> > > .l_inodebits = { MDS_INODELOCK_LOOKUP }
> > > };
> > >
> >
> > That is indented too far.
> >
> > Honestly, I think it looks best on one line but in terms of real life we
> > can't ignore checkpatch warnings because eventually someone else will
> > try to "fix" it to not be on one line.
> >
> > This function has the silly thing where the types are in one column and
> > the variables are in another. But then over time inevitably we add more
> > variables and nothing is lined up any more.
> >
> > I think it's best to move this const variable block to the very front of
> > the list.
> >
> > req doesn't need to be initialized.
> >
> > rc is normally the last variable declared.
> >
> > lvb_type should be initialized to LVB_T_NONE instead of zero.
> >
> > __u64 should be u64.
> >
> > All those changes could be done as one patch titled, "cleanup variable
> > declarations in mdc_enqueue()". There may be other cleanups you could
> > do as well. Look hard.
>
> I think it looks odd to mix named and unnamed
> initializers for the typedef and its members.
>
> ldlm_policy_data_t is a union and it could be
> explicit instead of a typedef.
>
> Perhaps:
> static const union ldlm_policy_data lookup_policy = {
> .l_inodebits = {
> .bits = MDS_INODELOCK_LOOKUP,
> },
> };
>
> or maybe use another DECLARE_ macro indirection.
>
This patch set is aimed at removing checkpatch issues from files in
lustre/lustre/mdc.
Is it ok if I just fix those in this set and post another patch set
to take care of other issues identified in review?
- removing typedef for ldlm_policy_data_t will touch many other
files/dirs which were not initially targeted for this patch set.
- There can be a separate patch to remove __u64.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: lustre: ptlrpc: nrs.c: Cleaning up missing null-terminate after strncpy call
On Sun, Aug 10, 2014 at 01:49:12AM +0200, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. No. This is a problem in the static checker and not in the code. Look at the start of the function. This stuff should be obvious for the static checker. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/12] staging: lustre: Fix misplaced opening brace warnings
On Mon, 2014-08-11 at 16:27 +0530, Srikrishan Malik wrote:
> On Thu, Aug 07, 2014 at 09:35:43AM -0700, Joe Perches wrote:
> > On Thu, 2014-08-07 at 19:01 +0300, Dan Carpenter wrote:
> > > On Thu, Aug 07, 2014 at 09:01:36PM +0530, Srikrishan Malik wrote:
> > > > On Wed, Aug 06, 2014 at 11:18:13PM +0300, Dan Carpenter wrote:
> > > > > That looks silly before and after. Everything is indented in a funny
> > > > > way.
> > > >
> > > > Is this better:
> > > >
> > > > static const ldlm_policy_data_t lookup_policy = {
> > > > .l_inodebits = { MDS_INODELOCK_LOOKUP }
> > > > };
> > > >
> > >
> > > That is indented too far.
> > >
> > > Honestly, I think it looks best on one line but in terms of real life we
> > > can't ignore checkpatch warnings because eventually someone else will
> > > try to "fix" it to not be on one line.
[]
> > I think it looks odd to mix named and unnamed
> > initializers for the typedef and its members.
> >
> > ldlm_policy_data_t is a union and it could be
> > explicit instead of a typedef.
> >
> > Perhaps:
> > static const union ldlm_policy_data lookup_policy = {
> > .l_inodebits = {
> > .bits = MDS_INODELOCK_LOOKUP,
> > },
> > };
> >
> > or maybe use another DECLARE_ macro indirection.
> >
>
> This patch set is aimed at removing checkpatch issues from files in
> lustre/lustre/mdc.
I think eliminating checkpatch identified issues should
not be the primary goal but a secondary one to the
overall goal of code style uniformity.
Julia Lawall and Himangi Saraogi from coccinelle fame
have created a "detypedef" script that is useful for
structs, perhaps you could extend it for unions and
run it over this lustre code.
For instance:
https://lkml.org/lkml/2014/8/9/104
> Is it ok if I just fix those in this set and post another patch set
> to take care of other issues identified in review?
Up to you.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/12] staging: lustre: Fix misplaced opening brace warnings
On Mon, Aug 11, 2014 at 04:27:06PM +0530, Srikrishan Malik wrote: > This patch set is aimed at removing checkpatch issues from files in > lustre/lustre/mdc. > > Is it ok if I just fix those in this set and post another patch set > to take care of other issues identified in review? checkpatch fixes are worthless if they don't make the code better for human readers. > > - removing typedef for ldlm_policy_data_t will touch many other > files/dirs which were not initially targeted for this patch set. Yeah. You're right. This should be done in a separate patch because it doesn't completely fall under the "cleanup variable declarations in mdc_enqueue()" header. > - There can be a separate patch to remove __u64. It's all part of the same thing "variable declarations in that function." regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response
On Mon, Aug 11, 2014 at 04:32:16PM +0800, rogera...@realtek.com wrote:
> From: Roger Tseng
>
> Current code erroneously fill the last byte of R2 response with an undefined
> value. In addition, it is impossible to obtain the real values since the
> controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
> response. This could cause mmc stack to obtain inconsistent CID from the same
> card after resume and misidentify it as a different card.
>
> Fix by assigning a dummy value 0x01 to the last byte of R2 response.
>
> Signed-off-by: Roger Tseng
> ---
> drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
> drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
> b/drivers/mmc/host/rtsx_pci_sdmmc.c
> index dfde4a2..54849d8 100644
> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> @@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc
> *host,
> }
>
> if (rsp_type == SD_RSP_TYPE_R2) {
> + ptr[16] = 1;
Avoid magic numbers like 16 and 0x1.
This is subtle enough that it deserves a comment.
ptr[stat_idx] = 0x1 /* 0x1 chosen randomly */
> for (i = 0; i < 4; i++) {
> cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
> dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
There are a lot of magic numbers in this function. We could get rid
of this i < 4 loop but doing:
memcpy(cmd->resp, ptr + 1, resp_len);
Currently we don't use resp_len and the resp_len = 5 assignment is off
by one... It should be resp_len = 4. This function is quite ugly.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/12] staging: lustre: Fix misplaced opening brace warnings
On Mon, 11 Aug 2014, Joe Perches wrote:
> On Mon, 2014-08-11 at 16:27 +0530, Srikrishan Malik wrote:
> > On Thu, Aug 07, 2014 at 09:35:43AM -0700, Joe Perches wrote:
> > > On Thu, 2014-08-07 at 19:01 +0300, Dan Carpenter wrote:
> > > > On Thu, Aug 07, 2014 at 09:01:36PM +0530, Srikrishan Malik wrote:
> > > > > On Wed, Aug 06, 2014 at 11:18:13PM +0300, Dan Carpenter wrote:
> > > > > > That looks silly before and after. Everything is indented in a
> > > > > > funny
> > > > > > way.
> > > > >
> > > > > Is this better:
> > > > >
> > > > > static const ldlm_policy_data_t lookup_policy = {
> > > > > .l_inodebits = { MDS_INODELOCK_LOOKUP }
> > > > > };
> > > > >
> > > >
> > > > That is indented too far.
> > > >
> > > > Honestly, I think it looks best on one line but in terms of real life we
> > > > can't ignore checkpatch warnings because eventually someone else will
> > > > try to "fix" it to not be on one line.
> []
> > > I think it looks odd to mix named and unnamed
> > > initializers for the typedef and its members.
> > >
> > > ldlm_policy_data_t is a union and it could be
> > > explicit instead of a typedef.
> > >
> > > Perhaps:
> > > static const union ldlm_policy_data lookup_policy = {
> > > .l_inodebits = {
> > > .bits = MDS_INODELOCK_LOOKUP,
> > > },
> > > };
> > >
> > > or maybe use another DECLARE_ macro indirection.
> > >
> >
> > This patch set is aimed at removing checkpatch issues from files in
> > lustre/lustre/mdc.
>
> I think eliminating checkpatch identified issues should
> not be the primary goal but a secondary one to the
> overall goal of code style uniformity.
>
> Julia Lawall and Himangi Saraogi from coccinelle fame
> have created a "detypedef" script that is useful for
> structs, perhaps you could extend it for unions and
> run it over this lustre code.
>
> For instance:
> https://lkml.org/lkml/2014/8/9/104
The complete semantic patch is below. It is in two parts: first for the
case where there is a name for the struct and the second for the case
where there is not. The code could be extended to automatically drop the
_t's that are commonly put on typedefs.
julia
@tn@
identifier i;
type td;
@@
-typedef
struct i { ... }
-td
;
@@
type tn.td;
identifier tn.i;
@@
-td
+ struct i
// --
// No name case
@tn1@
type td;
@@
typedef struct { ... } td;
@script:python tf@
td << tn1.td;
tdres;
@@
coccinelle.tdres = td
@@
type tn1.td;
identifier tf.tdres;
@@
-typedef
struct
+ tdres
{ ... }
-td
;
@@
type tn1.td;
identifier tf.tdres;
@@
-td
+ struct tdres
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND] staging: wlan-ng: prism2mgmt.c Fix break not useful
Fixes up warning, break is not useful after a goto or return statement
Signed-off-by: Jeshwanth Kumar N K
---
drivers/staging/wlan-ng/prism2mgmt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
b/drivers/staging/wlan-ng/prism2mgmt.c
index e6a82d3..5837b0e 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1168,7 +1168,6 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev, void
*msgp)
msg->resultcode.data = P80211ENUM_resultcode_success;
result = 0;
goto exit;
- break;
case P80211ENUM_truth_true:
/* Disable the port (if enabled), only check Port 0 */
if (hw->port_enabled[0]) {
@@ -1315,12 +1314,10 @@ int prism2mgmt_wlansniff(wlandevice_t *wlandev, void
*msgp)
msg->resultcode.data = P80211ENUM_resultcode_success;
result = 0;
goto exit;
- break;
default:
msg->resultcode.data = P80211ENUM_resultcode_invalid_parameters;
result = 0;
goto exit;
- break;
}
failed:
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 07/13] staging: comedi: amplc_dio200: tidy up comedi_driver declaration
On Saturday, August 09, 2014 9:15 PM, Greg KH wrote: > On Fri, Aug 01, 2014 at 01:07:05PM -0700, H Hartley Sweeten wrote: >> For aesthetics, add some whitespace to the declaration. >> >> Signed-off-by: H Hartley Sweeten >> Reviewed-by: Ian Abbott >> --- >> drivers/staging/comedi/drivers/amplc_dio200.c | 14 +++--- >> 1 file changed, 7 insertions(+), 7 deletions(-) > > This patch fails to apply, so I'll drop the rest of this series. Sync > up after I push my tree out, after 3.17-rc1 is out. Sorry about that. I have already rebased this series but didn't expect you to be applying anything to your tree until later this week or next week. As suggested, I will wait until 3.17-rc1 is out then sync up and repost the remaining pieces of this series as well as the 8255 cleanup series. Thanks, Hartley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: staging: vt6655: wpactl.h: corrected comment format
corrected C99 style comment format related error
Signed-off-by: Avinash Kumar
---
drivers/staging/vt6655/wpactl.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.h b/drivers/staging/vt6655/wpactl.h
index f7638ba..2ff42c5 100644
--- a/drivers/staging/vt6655/wpactl.h
+++ b/drivers/staging/vt6655/wpactl.h
@@ -36,7 +36,7 @@
/*- Export Definitions -*/
-//WPA related
+/*WPA related*/
enum wpa_alg { WPA_ALG_NONE, WPA_ALG_WEP, WPA_ALG_TKIP, WPA_ALG_CCMP };
enum wpa_cipher { CIPHER_NONE, CIPHER_WEP40, CIPHER_TKIP, CIPHER_CCMP,
@@ -61,4 +61,4 @@ int wpa_set_wpadev(PSDevice pDevice, int val);
int wpa_ioctl(PSDevice pDevice, struct iw_point *p);
int wpa_set_keys(PSDevice pDevice, void *ctx, bool fcpfkernel);
-#endif // __WPACL_H__
+#endif /* __WPACL_H__*/
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: Check against NULL in fw_download_code
I am fixing the bug entry , https://bugzilla.kernel.org/show_bug.cgi?id=60461.
This entry states that we are not checking the skb allocated in fw_download_code
and after checking I fixed it to check for the NULL value before using the
allocate
skb.
Signed-off-by: Nicholas Krause
---
drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
index 1a95d1f..0a4c926 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
@@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev, u8
*code_virtual_address,
}
- skb = dev_alloc_skb(frag_length + 4);
- memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
- tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
- tcb_desc->queue_index = TXCMD_QUEUE;
- tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
- tcb_desc->bLastIniPkt = bLastIniPkt;
+ skb = dev_alloc_skb(frag_length + 4);
+ if (skb) {
+ memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
+ tcb_desc = (struct cb_desc *)(skb->cb +
MAX_DEV_ADDR_SIZE);
+ tcb_desc->queue_index = TXCMD_QUEUE;
+ tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
+ tcb_desc->bLastIniPkt = bLastIniPkt;
+ }
seg_ptr = skb->data;
for (i = 0; i < frag_length; i += 4) {
*seg_ptr++ = ((i+0) < frag_length) ?
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause wrote:
> I am fixing the bug entry , https://bugzilla.kernel.org/show_bug.cgi?id=60461.
> This entry states that we are not checking the skb allocated in
> fw_download_code
> and after checking I fixed it to check for the NULL value before using the
> allocate
> skb.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..0a4c926 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
>
> }
>
> - skb = dev_alloc_skb(frag_length + 4);
> - memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
> - tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
> - tcb_desc->queue_index = TXCMD_QUEUE;
> - tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
> - tcb_desc->bLastIniPkt = bLastIniPkt;
>
> + skb = dev_alloc_skb(frag_length + 4);
> + if (skb) {
> + memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
> + tcb_desc = (struct cb_desc *)(skb->cb +
> MAX_DEV_ADDR_SIZE);
> + tcb_desc->queue_index = TXCMD_QUEUE;
> + tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
> + tcb_desc->bLastIniPkt = bLastIniPkt;
> + }
> seg_ptr = skb->data;
> for (i = 0; i < frag_length; i += 4) {
> *seg_ptr++ = ((i+0) < frag_length) ?
> --
> 1.9.1
>
And I did check it against Linus's tree to make sure it applies , just
to let you known.
Nick
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On 08/11/14 11:04, Nick Krause wrote:
> On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause wrote:
>> I am fixing the bug entry ,
>> https://bugzilla.kernel.org/show_bug.cgi?id=60461.
>> This entry states that we are not checking the skb allocated in
>> fw_download_code
>> and after checking I fixed it to check for the NULL value before using the
>> allocate
>> skb.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> index 1a95d1f..0a4c926 100644
>> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> @@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev, u8
>> *code_virtual_address,
>>
>> }
>>
>> - skb = dev_alloc_skb(frag_length + 4);
>> - memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
>> - tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>> - tcb_desc->queue_index = TXCMD_QUEUE;
>> - tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>> - tcb_desc->bLastIniPkt = bLastIniPkt;
>>
>> + skb = dev_alloc_skb(frag_length + 4);
>> + if (skb) {
>> + memcpy((unsigned char *)(skb->cb), &dev,
>> sizeof(dev));
>> + tcb_desc = (struct cb_desc *)(skb->cb +
>> MAX_DEV_ADDR_SIZE);
>> + tcb_desc->queue_index = TXCMD_QUEUE;
>> + tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>> + tcb_desc->bLastIniPkt = bLastIniPkt;
>> + }
and what happens here (below) if skb is NULL?
>> seg_ptr = skb->data;
>> for (i = 0; i < frag_length; i += 4) {
>> *seg_ptr++ = ((i+0) < frag_length) ?
>> --
>> 1.9.1
>>
> And I did check it against Linus's tree to make sure it applies , just
> to let you known.
> Nick
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On Mon, Aug 11, 2014 at 2:07 PM, Randy Dunlap wrote:
> On 08/11/14 11:04, Nick Krause wrote:
>> On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause wrote:
>>> I am fixing the bug entry ,
>>> https://bugzilla.kernel.org/show_bug.cgi?id=60461.
>>> This entry states that we are not checking the skb allocated in
>>> fw_download_code
>>> and after checking I fixed it to check for the NULL value before using the
>>> allocate
>>> skb.
>>>
>>> Signed-off-by: Nicholas Krause
>>> ---
>>> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
>>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> index 1a95d1f..0a4c926 100644
>>> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> @@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev, u8
>>> *code_virtual_address,
>>>
>>> }
>>>
>>> - skb = dev_alloc_skb(frag_length + 4);
>>> - memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
>>> - tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>>> - tcb_desc->queue_index = TXCMD_QUEUE;
>>> - tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>>> - tcb_desc->bLastIniPkt = bLastIniPkt;
>>>
>>> + skb = dev_alloc_skb(frag_length + 4);
>>> + if (skb) {
>>> + memcpy((unsigned char *)(skb->cb), &dev,
>>> sizeof(dev));
>>> + tcb_desc = (struct cb_desc *)(skb->cb +
>>> MAX_DEV_ADDR_SIZE);
>>> + tcb_desc->queue_index = TXCMD_QUEUE;
>>> + tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>>> + tcb_desc->bLastIniPkt = bLastIniPkt;
>>> + }
>
> and what happens here (below) if skb is NULL?
>
>>> seg_ptr = skb->data;
>>> for (i = 0; i < frag_length; i += 4) {
>>> *seg_ptr++ = ((i+0) < frag_length) ?
>>> --
>>> 1.9.1
>>>
>> And I did check it against Linus's tree to make sure it applies , just
>> to let you known.
>> Nick
>
>
> --
> ~Randy
Sorry Randy.
I may be mis reading this, but are you asking me to write a different
commit message or is this patch just another bad patch in my series of
bad patches?
Nick
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 01/13] staging: lustre: remove space between function name and and open parenthesis
Fixes following checkpatch warning:
WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_internal.h | 2 +-
drivers/staging/lustre/lustre/mdc/mdc_lib.c | 4 ++--
drivers/staging/lustre/lustre/mdc/mdc_locks.c| 2 +-
drivers/staging/lustre/lustre/mdc/mdc_request.c | 14 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_internal.h
b/drivers/staging/lustre/lustre/mdc/mdc_internal.h
index e8235559e27f..f4da8f3523d2 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_internal.h
+++ b/drivers/staging/lustre/lustre/mdc/mdc_internal.h
@@ -40,7 +40,7 @@
#include "../include/lustre_mdc.h"
#include "../include/lustre_mds.h"
-#if defined (CONFIG_PROC_FS)
+#if defined CONFIG_PROC_FS
void lprocfs_mdc_init_vars(struct lprocfs_static_vars *lvars);
#else
static inline void lprocfs_mdc_init_vars(struct lprocfs_static_vars *lvars)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
index f54dd90c7e50..60217ba440aa 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
@@ -42,7 +42,7 @@
static void __mdc_pack_body(struct mdt_body *b, __u32 suppgid)
{
- LASSERT (b != NULL);
+ LASSERT(b != NULL);
b->suppgid = suppgid;
b->uid = from_kuid(&init_user_ns, current_uid());
@@ -409,7 +409,7 @@ void mdc_link_pack(struct ptlrpc_request *req, struct
md_op_data *op_data)
CLASSERT(sizeof(struct mdt_rec_reint) == sizeof(struct mdt_rec_link));
rec = req_capsule_client_get(&req->rq_pill, &RMF_REC_REINT);
- LASSERT (rec != NULL);
+ LASSERT(rec != NULL);
rec->lk_opcode = REINT_LINK;
rec->lk_fsuid= op_data->op_fsuid;//current->fsuid;
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index 71219b90e22b..88b43823c632 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -633,7 +633,7 @@ static int mdc_finish_enqueue(struct obd_export *exp,
body = req_capsule_server_get(pill, &RMF_MDT_BODY);
if (body == NULL) {
- CERROR ("Can't swab mdt_body\n");
+ CERROR("Can't swab mdt_body\n");
return -EPROTO;
}
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 4a1cc4eb73d5..0b517e550477 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -1702,7 +1702,7 @@ static int mdc_quotactl(struct obd_device *unused, struct
obd_export *exp,
if (oqc) {
*oqctl = *oqc;
} else if (!rc) {
- CERROR ("Can't unpack obd_quotactl\n");
+ CERROR("Can't unpack obd_quotactl\n");
rc = -EPROTO;
}
} else if (!rc) {
@@ -2426,14 +2426,14 @@ static int mdc_setup(struct obd_device *obd, struct
lustre_cfg *cfg)
struct lprocfs_static_vars lvars = { NULL };
int rc;
- OBD_ALLOC(cli->cl_rpc_lock, sizeof (*cli->cl_rpc_lock));
+ OBD_ALLOC(cli->cl_rpc_lock, sizeof(*cli->cl_rpc_lock));
if (!cli->cl_rpc_lock)
return -ENOMEM;
mdc_init_rpc_lock(cli->cl_rpc_lock);
ptlrpcd_addref();
- OBD_ALLOC(cli->cl_close_lock, sizeof (*cli->cl_close_lock));
+ OBD_ALLOC(cli->cl_close_lock, sizeof(*cli->cl_close_lock));
if (!cli->cl_close_lock)
GOTO(err_rpc_lock, rc = -ENOMEM);
mdc_init_rpc_lock(cli->cl_close_lock);
@@ -2459,9 +2459,9 @@ static int mdc_setup(struct obd_device *obd, struct
lustre_cfg *cfg)
return rc;
err_close_lock:
- OBD_FREE(cli->cl_close_lock, sizeof (*cli->cl_close_lock));
+ OBD_FREE(cli->cl_close_lock, sizeof(*cli->cl_close_lock));
err_rpc_lock:
- OBD_FREE(cli->cl_rpc_lock, sizeof (*cli->cl_rpc_lock));
+ OBD_FREE(cli->cl_rpc_lock, sizeof(*cli->cl_rpc_lock));
ptlrpcd_decref();
return rc;
}
@@ -2523,8 +2523,8 @@ static int mdc_cleanup(struct obd_device *obd)
{
struct client_obd *cli = &obd->u.cli;
- OBD_FREE(cli->cl_rpc_lock, sizeof (*cli->cl_rpc_lock));
- OBD_FREE(cli->cl_close_lock, sizeof (*cli->cl_close_lock));
+ OBD_FREE(cli->cl_rpc_lock, sizeof(*cli->cl_rpc_lock));
+ OBD_FREE(cli->cl_close_lock, sizeof(*cli->cl_close_lock));
ptlrpcd_decref();
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 02/13] staging: lustre: remove spaces from start of line
Fixes the following checkpatch warning:
WARNING: please, no spaces at the start of a line
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/lproc_mdc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
index d1d891b91663..f883d9c28f20 100644
--- a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
+++ b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
@@ -209,6 +209,6 @@ static struct lprocfs_vars lprocfs_mdc_module_vars[] = {
void lprocfs_mdc_init_vars(struct lprocfs_static_vars *lvars)
{
-lvars->module_vars = lprocfs_mdc_module_vars;
-lvars->obd_vars = lprocfs_mdc_obd_vars;
+ lvars->module_vars = lprocfs_mdc_module_vars;
+ lvars->obd_vars = lprocfs_mdc_obd_vars;
}
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 03/13] staging: lustre: move open brace to next line after functions
Fixes the following checkpatch error:
ERROR: open brace '{' following function declarations go on the next line
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_lib.c | 3 ++-
drivers/staging/lustre/lustre/mdc/mdc_request.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
index 60217ba440aa..daaa7422c03f 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
@@ -256,7 +256,8 @@ void mdc_open_pack(struct ptlrpc_request *req, struct
md_op_data *op_data,
set_mrc_cr_flags(rec, cr_flags);
}
-static inline __u64 attr_pack(unsigned int ia_valid) {
+static inline __u64 attr_pack(unsigned int ia_valid)
+{
__u64 sa_valid = 0;
if (ia_valid & ATTR_MODE)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 0b517e550477..0bcf624620ce 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -2384,7 +2384,8 @@ int mdc_fid_alloc(struct obd_export *exp, struct lu_fid
*fid,
return seq_client_alloc_fid(NULL, seq, fid);
}
-struct obd_uuid *mdc_get_uuid(struct obd_export *exp) {
+struct obd_uuid *mdc_get_uuid(struct obd_export *exp)
+{
struct client_obd *cli = &exp->exp_obd->u.cli;
return &cli->cl_target_uuid;
}
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 06/13] staging: lustre: replace c99 style comments with C89
Fixes the following checkpatch error: ERROR: do not use C99 // comments Signed-off-by: Srikrishan Malik --- drivers/staging/lustre/lustre/mdc/mdc_lib.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_lib.c b/drivers/staging/lustre/lustre/mdc/mdc_lib.c index 35ce2fdf696c..8b301f4d7e23 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_lib.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_lib.c @@ -416,9 +416,9 @@ void mdc_link_pack(struct ptlrpc_request *req, struct md_op_data *op_data) LASSERT(rec != NULL); rec->lk_opcode = REINT_LINK; - rec->lk_fsuid= op_data->op_fsuid;//current->fsuid; - rec->lk_fsgid= op_data->op_fsgid;//current->fsgid; - rec->lk_cap = op_data->op_cap;//current->cap_effective; + rec->lk_fsuid= op_data->op_fsuid; /* current->fsuid; */ + rec->lk_fsgid= op_data->op_fsgid; /* current->fsgid; */ + rec->lk_cap = op_data->op_cap; /* current->cap_effective; */ rec->lk_suppgid1 = op_data->op_suppgids[0]; rec->lk_suppgid2 = op_data->op_suppgids[1]; rec->lk_fid1 = op_data->op_fid1; -- 1.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 07/13] staging: lustre: add blank lines after declarations
Fixes the following checkpatch warning:
WARNING: Missing a blank line after declarations
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_lib.c | 1 +
drivers/staging/lustre/lustre/mdc/mdc_locks.c | 3 +++
drivers/staging/lustre/lustre/mdc/mdc_request.c | 5 +
3 files changed, 9 insertions(+)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
index 8b301f4d7e23..e8732cc30ce2 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
@@ -490,6 +490,7 @@ void mdc_getattr_pack(struct ptlrpc_request *req, __u64
valid, int flags,
if (op_data->op_name) {
char *tmp = req_capsule_client_get(&req->rq_pill, &RMF_NAME);
+
LOGL0(op_data->op_name, op_data->op_namelen, tmp);
}
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index a5a2597616e9..4d837d61be65 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -134,6 +134,7 @@ int mdc_set_lock_data(struct obd_export *exp, __u64 *lockh,
void *data,
if (lock->l_resource->lr_lvb_inode &&
lock->l_resource->lr_lvb_inode != data) {
struct inode *old_inode = lock->l_resource->lr_lvb_inode;
+
LASSERTF(old_inode->i_state & I_FREEING,
"Found existing inode %p/%lu/%u state %lu in lock: "
"setting data to %p/%lu/%u\n", old_inode,
@@ -678,6 +679,7 @@ static int mdc_finish_enqueue(struct obd_export *exp,
*/
if ((it->it_op & IT_OPEN) && req->rq_replay) {
void *lmm;
+
if (req_capsule_get_size(pill, &RMF_EADATA,
RCL_CLIENT) <
body->eadatasize)
@@ -1029,6 +1031,7 @@ static int mdc_finish_intent_lock(struct obd_export *exp,
lock = ldlm_handle2lock(lockh);
if (lock) {
ldlm_policy_data_t policy = lock->l_policy_data;
+
LDLM_DEBUG(lock, "matching against this");
LASSERTF(fid_res_name_eq(&mdt_body->fid1,
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 6def92133227..57d903156917 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -203,6 +203,7 @@ static int mdc_getattr_common(struct obd_export *exp,
if (body->valid & OBD_MD_FLMDSCAPA) {
struct lustre_capa *capa;
+
capa = req_capsule_server_get(pill, &RMF_CAPA1);
if (capa == NULL)
return -EPROTO;
@@ -283,6 +284,7 @@ int mdc_getattr_name(struct obd_export *exp, struct
md_op_data *op_data,
if (op_data->op_name) {
char *name = req_capsule_client_get(&req->rq_pill, &RMF_NAME);
+
LASSERT(strnlen(op_data->op_name, op_data->op_namelen) ==
op_data->op_namelen);
memcpy(name, op_data->op_name, op_data->op_namelen);
@@ -696,6 +698,7 @@ void mdc_replay_open(struct ptlrpc_request *req)
void mdc_commit_open(struct ptlrpc_request *req)
{
struct md_open_data *mod = req->rq_cb_data;
+
if (mod == NULL)
return;
@@ -2390,6 +2393,7 @@ int mdc_fid_alloc(struct obd_export *exp, struct lu_fid
*fid,
struct obd_uuid *mdc_get_uuid(struct obd_export *exp)
{
struct client_obd *cli = &exp->exp_obd->u.cli;
+
return &cli->cl_target_uuid;
}
@@ -2742,6 +2746,7 @@ int __init mdc_init(void)
{
int rc;
struct lprocfs_static_vars lvars = { NULL };
+
lprocfs_mdc_init_vars(&lvars);
rc = class_register_type(&mdc_obd_ops, &mdc_md_ops, lvars.module_vars,
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 09/13] staging: lustre: Added space between type name and *
Fixes the following checkpatch error: ERROR: "(foo*)" should be "(foo *)" Signed-off-by: Srikrishan Malik --- drivers/staging/lustre/lustre/mdc/mdc_locks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c b/drivers/staging/lustre/lustre/mdc/mdc_locks.c index 7f724e3c3f06..c03d77c9c5b8 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c @@ -218,7 +218,7 @@ int mdc_find_cbdata(struct obd_export *exp, struct ldlm_res_id res_id; int rc = 0; - fid_build_reg_res_name((struct lu_fid*)fid, &res_id); + fid_build_reg_res_name((struct lu_fid *)fid, &res_id); rc = ldlm_resource_iterate(class_exp2obd(exp)->obd_namespace, &res_id, it, data); if (rc == LDLM_ITER_STOP) -- 1.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 12/13] staging: lustre: remove parentheses usage with return
Fix the following checkpatch error: ERROR: return is not a function, parentheses are not required Signed-off-by: Srikrishan Malik --- drivers/staging/lustre/lustre/mdc/mdc_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 5a9a8526dea1..4ab75c24bd17 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -2588,7 +2588,7 @@ static int mdc_process_config(struct obd_device *obd, obd_count len, void *buf) rc = 0; break; } - return(rc); + return rc; } -- 1.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 08/13] staging: lustre: fix multi line strings
Fixes the following checkpatch warning:
WARNING: quoted string split across lines
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_locks.c | 9 +++
drivers/staging/lustre/lustre/mdc/mdc_reint.c | 3 +--
drivers/staging/lustre/lustre/mdc/mdc_request.c | 36 -
3 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index 4d837d61be65..7f724e3c3f06 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -136,11 +136,10 @@ int mdc_set_lock_data(struct obd_export *exp, __u64
*lockh, void *data,
struct inode *old_inode = lock->l_resource->lr_lvb_inode;
LASSERTF(old_inode->i_state & I_FREEING,
-"Found existing inode %p/%lu/%u state %lu in lock: "
-"setting data to %p/%lu/%u\n", old_inode,
-old_inode->i_ino, old_inode->i_generation,
-old_inode->i_state,
-new_inode, new_inode->i_ino, new_inode->i_generation);
+"Found existing inode %p/%lu/%u state %lu in lock:
setting data to %p/%lu/%u\n",
+old_inode, old_inode->i_ino, old_inode->i_generation,
+old_inode->i_state, new_inode, new_inode->i_ino,
+new_inode->i_generation);
}
lock->l_resource->lr_lvb_inode = new_inode;
if (bits)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_reint.c
b/drivers/staging/lustre/lustre/mdc/mdc_reint.c
index b8c0f482b76f..46800335ca7d 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_reint.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_reint.c
@@ -158,8 +158,7 @@ int mdc_setattr(struct obd_export *exp, struct md_op_data
*op_data,
*mod = obd_mod_alloc();
if (*mod == NULL) {
- DEBUG_REQ(D_ERROR, req, "Can't allocate "
- "md_open_data");
+ DEBUG_REQ(D_ERROR, req, "Can't allocate md_open_data");
} else {
req->rq_replay = 1;
req->rq_cb_data = *mod;
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 57d903156917..6c691a4763b5 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -517,14 +517,14 @@ int mdc_get_lustre_md(struct obd_export *exp, struct
ptlrpc_request *req,
struct lov_mds_md *lmm;
if (!S_ISREG(md->body->mode)) {
- CDEBUG(D_INFO, "OBD_MD_FLEASIZE set, should be a "
- "regular file, but is not\n");
+ CDEBUG(D_INFO,
+ "OBD_MD_FLEASIZE set, should be a regular file,
but is not\n");
GOTO(out, rc = -EPROTO);
}
if (md->body->eadatasize == 0) {
- CDEBUG(D_INFO, "OBD_MD_FLEASIZE set, "
- "but eadatasize 0\n");
+ CDEBUG(D_INFO,
+ "OBD_MD_FLEASIZE set, but eadatasize 0\n");
GOTO(out, rc = -EPROTO);
}
lmmsize = md->body->eadatasize;
@@ -537,8 +537,8 @@ int mdc_get_lustre_md(struct obd_export *exp, struct
ptlrpc_request *req,
GOTO(out, rc);
if (rc < sizeof(*md->lsm)) {
- CDEBUG(D_INFO, "lsm size too small: "
- "rc < sizeof (*md->lsm) (%d < %d)\n",
+ CDEBUG(D_INFO,
+ "lsm size too small: rc < sizeof (*md->lsm) (%d
< %d)\n",
rc, (int)sizeof(*md->lsm));
GOTO(out, rc = -EPROTO);
}
@@ -548,14 +548,14 @@ int mdc_get_lustre_md(struct obd_export *exp, struct
ptlrpc_request *req,
struct lov_mds_md *lmv;
if (!S_ISDIR(md->body->mode)) {
- CDEBUG(D_INFO, "OBD_MD_FLDIREA set, should be a "
- "directory, but is not\n");
+ CDEBUG(D_INFO,
+ "OBD_MD_FLDIREA set, should be a directory, but
is not\n");
GOTO(out, rc = -EPROTO);
}
if (md->body->eadatasize == 0) {
- CDEBUG(D_INFO, "OBD_MD_FLDIREA is set, "
- "but eadatasize 0\n");
+ CDEBUG(D_INFO,
+ "OBD_MD_FLDIREA is set, but eadatasize 0\n");
return -EPROTO;
}
if (md->body->valid & OBD_MD_MEA) {
@@ -571,8 +571,8 @@
[PATCH v2 04/13] staging: lustre: fix lines over 80 chars
Fixes the following checkpatch warning:
WARNING: line over 80 characters
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/lproc_mdc.c | 6 --
drivers/staging/lustre/lustre/mdc/mdc_lib.c | 9 ++---
drivers/staging/lustre/lustre/mdc/mdc_locks.c | 7 ---
drivers/staging/lustre/lustre/mdc/mdc_request.c | 6 --
4 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
index f883d9c28f20..16341c818358 100644
--- a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
+++ b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
@@ -56,7 +56,8 @@ static ssize_t mdc_max_rpcs_in_flight_seq_write(struct file
*file,
size_t count,
loff_t *off)
{
- struct obd_device *dev = ((struct seq_file
*)file->private_data)->private;
+ struct obd_device *dev =
+ ((struct seq_file *)file->private_data)->private;
struct client_obd *cli = &dev->u.cli;
int val, rc;
@@ -84,7 +85,8 @@ static int mdc_kuc_open(struct inode *inode, struct file
*file)
static ssize_t mdc_kuc_write(struct file *file, const char *buffer,
size_t count, loff_t *off)
{
- struct obd_device *obd = ((struct seq_file
*)file->private_data)->private;
+ struct obd_device *obd =
+ ((struct seq_file *)file->private_data)->private;
struct kuc_hdr *lh;
struct hsm_action_list *hal;
struct hsm_action_item *hai;
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
index daaa7422c03f..16e2e0b611d1 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
@@ -52,7 +52,8 @@ static void __mdc_pack_body(struct mdt_body *b, __u32 suppgid)
b->capability = cfs_curproc_cap_pack();
}
-void mdc_pack_capa(struct ptlrpc_request *req, const struct req_msg_field
*field,
+void mdc_pack_capa(struct ptlrpc_request *req,
+ const struct req_msg_field *field,
struct obd_capa *oc)
{
struct req_capsule *pill = &req->rq_pill;
@@ -317,7 +318,8 @@ static void mdc_setattr_pack_rec(struct mdt_rec_setattr
*rec,
rec->sa_atime = LTIME_S(op_data->op_attr.ia_atime);
rec->sa_mtime = LTIME_S(op_data->op_attr.ia_mtime);
rec->sa_ctime = LTIME_S(op_data->op_attr.ia_ctime);
- rec->sa_attr_flags = ((struct ll_iattr
*)&op_data->op_attr)->ia_attr_flags;
+ rec->sa_attr_flags =
+ ((struct ll_iattr *)&op_data->op_attr)->ia_attr_flags;
if ((op_data->op_attr.ia_valid & ATTR_GID) &&
in_group_p(op_data->op_attr.ia_gid))
rec->sa_suppgid =
@@ -552,7 +554,8 @@ int mdc_enter_request(struct client_obd *cli)
list_add_tail(&mcw.mcw_entry, &cli->cl_cache_waiters);
init_waitqueue_head(&mcw.mcw_waitq);
client_obd_list_unlock(&cli->cl_loi_list_lock);
- rc = l_wait_event(mcw.mcw_waitq, mdc_req_avail(cli, &mcw),
&lwi);
+ rc = l_wait_event(mcw.mcw_waitq, mdc_req_avail(cli, &mcw),
+ &lwi);
if (rc) {
client_obd_list_lock(&cli->cl_loi_list_lock);
if (list_empty(&mcw.mcw_entry))
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index 88b43823c632..5de9e8862393 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -450,8 +450,8 @@ static struct ptlrpc_request *mdc_intent_unlink_pack(struct
obd_export *exp,
}
static struct ptlrpc_request *mdc_intent_getattr_pack(struct obd_export *exp,
- struct lookup_intent *it,
- struct md_op_data
*op_data)
+ struct lookup_intent *it,
+ struct md_op_data *op_data)
{
struct ptlrpc_request *req;
struct obd_device *obddev = class_exp2obd(exp);
@@ -1039,7 +1039,8 @@ static int mdc_finish_intent_lock(struct obd_export *exp,
memcpy(&old_lock, lockh, sizeof(*lockh));
if (ldlm_lock_match(NULL, LDLM_FL_BLOCK_GRANTED, NULL,
- LDLM_IBITS, &policy, LCK_NL, &old_lock, 0))
{
+ LDLM_IBITS, &policy, LCK_NL,
+ &old_lock, 0)) {
ldlm_lock_decref_and_cancel(lockh,
it->d.lustre.it_lock_mode);
memcpy(lockh, &old_lock, sizeof(old_lock));
diff --git a/driver
[PATCH v2 05/13] staging: lustre: Add missing spaces around operators and braces.
Fixes the following checkpatch errors:
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required after that close brace '}'
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_lib.c | 25 +
drivers/staging/lustre/lustre/mdc/mdc_locks.c | 5 +++--
drivers/staging/lustre/lustre/mdc/mdc_reint.c | 2 +-
drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 ---
4 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
index 16e2e0b611d1..35ce2fdf696c 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_lib.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_lib.c
@@ -345,7 +345,8 @@ void mdc_setattr_pack(struct ptlrpc_request *req, struct
md_op_data *op_data,
struct mdt_ioepoch *epoch;
struct lov_user_md *lum = NULL;
- CLASSERT(sizeof(struct mdt_rec_reint) ==sizeof(struct mdt_rec_setattr));
+ CLASSERT(sizeof(struct mdt_rec_reint) ==
+ sizeof(struct mdt_rec_setattr));
rec = req_capsule_client_get(&req->rq_pill, &RMF_REC_REINT);
mdc_setattr_pack_rec(rec, op_data);
@@ -385,18 +386,18 @@ void mdc_unlink_pack(struct ptlrpc_request *req, struct
md_op_data *op_data)
rec = req_capsule_client_get(&req->rq_pill, &RMF_REC_REINT);
LASSERT(rec != NULL);
- rec->ul_opcode = op_data->op_cli_flags & CLI_RM_ENTRY ?
+ rec->ul_opcode = op_data->op_cli_flags & CLI_RM_ENTRY ?
REINT_RMENTRY : REINT_UNLINK;
- rec->ul_fsuid = op_data->op_fsuid;
- rec->ul_fsgid = op_data->op_fsgid;
- rec->ul_cap = op_data->op_cap;
- rec->ul_mode= op_data->op_mode;
- rec->ul_suppgid1= op_data->op_suppgids[0];
- rec->ul_suppgid2= -1;
- rec->ul_fid1= op_data->op_fid1;
- rec->ul_fid2= op_data->op_fid2;
- rec->ul_time= op_data->op_mod_time;
- rec->ul_bias= op_data->op_bias;
+ rec->ul_fsuid= op_data->op_fsuid;
+ rec->ul_fsgid= op_data->op_fsgid;
+ rec->ul_cap = op_data->op_cap;
+ rec->ul_mode = op_data->op_mode;
+ rec->ul_suppgid1 = op_data->op_suppgids[0];
+ rec->ul_suppgid2 = -1;
+ rec->ul_fid1 = op_data->op_fid1;
+ rec->ul_fid2 = op_data->op_fid2;
+ rec->ul_time = op_data->op_mod_time;
+ rec->ul_bias = op_data->op_bias;
mdc_pack_capa(req, &RMF_CAPA1, op_data->op_capa1);
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index 5de9e8862393..a5a2597616e9 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -621,7 +621,7 @@ static int mdc_finish_enqueue(struct obd_export *exp,
* function without doing so, and try to replay a failed create
* (bug 3440) */
if (it->it_op & IT_OPEN && req->rq_replay &&
- (!it_disposition(it, DISP_OPEN_OPEN) ||intent->it_status != 0))
+ (!it_disposition(it, DISP_OPEN_OPEN) || intent->it_status != 0))
mdc_clear_replay_flag(req, intent->it_status);
DEBUG_REQ(D_RPCTRACE, req, "op: %d disposition: %x, status: %d",
@@ -1047,7 +1047,8 @@ static int mdc_finish_intent_lock(struct obd_export *exp,
it->d.lustre.it_lock_handle = lockh->cookie;
}
}
- CDEBUG(D_DENTRY,"D_IT dentry %.*s intent: %s status %d disp %x rc %d\n",
+ CDEBUG(D_DENTRY,
+ "D_IT dentry %.*s intent: %s status %d disp %x rc %d\n",
op_data->op_namelen, op_data->op_name, ldlm_it2str(it->it_op),
it->d.lustre.it_status, it->d.lustre.it_disposition, rc);
return rc;
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_reint.c
b/drivers/staging/lustre/lustre/mdc/mdc_reint.c
index c5420a42bc33..b8c0f482b76f 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_reint.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_reint.c
@@ -71,7 +71,7 @@ int mdc_resource_get_unused(struct obd_export *exp, const
struct lu_fid *fid,
__u64 bits)
{
struct ldlm_namespace *ns = exp->exp_obd->obd_namespace;
- ldlm_policy_data_t policy = {{0}};
+ ldlm_policy_data_t policy = {};
struct ldlm_res_id res_id;
struct ldlm_resource *res;
int count;
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 5126262aa73d..6def92133227 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -326,7 +326,8 @@ static int mdc_is_subdir(struct obd_export *exp,
return rc;
}
-static int mdc_xattr_common(struct obd_export *exp,const struct req_format
*fmt,
+static int mdc_xattr_common(struct obd_export *exp,
+
[PATCH v2 11/13] staging: lustre: move else on the same line as closing brace
Fix the following checkpatch error:
ERROR: else should follow close brace '}'
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_request.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index bf2dcf50afd4..5a9a8526dea1 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -587,8 +587,7 @@ int mdc_get_lustre_md(struct obd_export *exp, struct
ptlrpc_request *req,
lustre_swab_mdt_remote_perm);
if (!md->remote_perm)
GOTO(out, rc = -EPROTO);
- }
- else if (md->body->valid & OBD_MD_FLACL) {
+ } else if (md->body->valid & OBD_MD_FLACL) {
/* for ACL, it's possible that FLACL is set but aclsize is zero.
* only when aclsize != 0 there's an actual segment for ACL
* in reply buffer.
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 10/13] staging: lustre: Fix misplaced opening brace warnings
Fixes the following checkpatch error:
ERROR: that open brace { should be on the previous line
Signed-off-by: Srikrishan Malik
---
drivers/staging/lustre/lustre/mdc/mdc_locks.c | 18 +++---
drivers/staging/lustre/lustre/mdc/mdc_reint.c | 3 +--
drivers/staging/lustre/lustre/mdc/mdc_request.c | 7 +--
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index c03d77c9c5b8..288ce9119ed5 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -785,14 +785,18 @@ int mdc_enqueue(struct obd_export *exp, struct
ldlm_enqueue_info *einfo,
__u64 flags, saved_flags = extra_lock_flags;
int rc;
struct ldlm_res_id res_id;
- static const ldlm_policy_data_t lookup_policy =
- { .l_inodebits = { MDS_INODELOCK_LOOKUP } };
- static const ldlm_policy_data_t update_policy =
- { .l_inodebits = { MDS_INODELOCK_UPDATE } };
- static const ldlm_policy_data_t layout_policy =
- { .l_inodebits = { MDS_INODELOCK_LAYOUT } };
+ static const ldlm_policy_data_t lookup_policy = {
+ .l_inodebits = { MDS_INODELOCK_LOOKUP }
+ };
+ static const ldlm_policy_data_t update_policy = {
+ .l_inodebits = { MDS_INODELOCK_UPDATE }
+ };
+ static const ldlm_policy_data_t layout_policy = {
+ .l_inodebits = { MDS_INODELOCK_LAYOUT }
+ };
static const ldlm_policy_data_t getxattr_policy = {
- .l_inodebits = { MDS_INODELOCK_XATTR } };
+ .l_inodebits = { MDS_INODELOCK_XATTR }
+ };
ldlm_policy_data_t const *policy = &lookup_policy;
int generation, resends = 0;
struct ldlm_reply *lockrep;
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_reint.c
b/drivers/staging/lustre/lustre/mdc/mdc_reint.c
index 46800335ca7d..01af30ac1a52 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_reint.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_reint.c
@@ -152,8 +152,7 @@ int mdc_setattr(struct obd_export *exp, struct md_op_data
*op_data,
ptlrpc_request_set_replen(req);
if (mod && (op_data->op_flags & MF_EPOCH_OPEN) &&
- req->rq_import->imp_replayable)
- {
+ req->rq_import->imp_replayable) {
LASSERT(*mod == NULL);
*mod = obd_mod_alloc();
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 6c691a4763b5..bf2dcf50afd4 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -1794,8 +1794,11 @@ static int mdc_iocontrol(unsigned int cmd, struct
obd_export *exp, int len,
GOTO(out, rc);
case OBD_IOC_CHANGELOG_CLEAR: {
struct ioc_changelog *icc = karg;
- struct changelog_setinfo cs =
- {.cs_recno = icc->icc_recno, .cs_id = icc->icc_id};
+ struct changelog_setinfo cs = {
+ .cs_recno = icc->icc_recno,
+ .cs_id = icc->icc_id
+ };
+
rc = obd_set_info_async(NULL, exp, strlen(KEY_CHANGELOG_CLEAR),
KEY_CHANGELOG_CLEAR, sizeof(cs), &cs,
NULL);
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 13/13] staging: lustre: Cleanup variable declarations in mdc_enqueue()
Changes:
- move const union vars to the top
- move rc to bottom
- do not initialize req
- set lvb_type to enum member instead of 0
- change __u64 to u64
- fix inconsistant columnization
Signed-off-by: Srikrishan Malik
---
These changes were suggested by Dan Carpenter .
drivers/staging/lustre/lustre/mdc/mdc_locks.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
index 288ce9119ed5..c64a38eaee3e 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c
@@ -778,13 +778,8 @@ static int mdc_finish_enqueue(struct obd_export *exp,
int mdc_enqueue(struct obd_export *exp, struct ldlm_enqueue_info *einfo,
struct lookup_intent *it, struct md_op_data *op_data,
struct lustre_handle *lockh, void *lmm, int lmmsize,
- struct ptlrpc_request **reqp, __u64 extra_lock_flags)
+ struct ptlrpc_request **reqp, u64 extra_lock_flags)
{
- struct obd_device *obddev = class_exp2obd(exp);
- struct ptlrpc_request *req = NULL;
- __u64 flags, saved_flags = extra_lock_flags;
- int rc;
- struct ldlm_res_id res_id;
static const ldlm_policy_data_t lookup_policy = {
.l_inodebits = { MDS_INODELOCK_LOOKUP }
};
@@ -798,9 +793,14 @@ int mdc_enqueue(struct obd_export *exp, struct
ldlm_enqueue_info *einfo,
.l_inodebits = { MDS_INODELOCK_XATTR }
};
ldlm_policy_data_t const *policy = &lookup_policy;
- int generation, resends = 0;
- struct ldlm_reply *lockrep;
- enum lvb_type lvb_type = 0;
+ struct obd_device *obddev = class_exp2obd(exp);
+ struct ptlrpc_request *req;
+ u64 flags, saved_flags = extra_lock_flags;
+ struct ldlm_res_id res_id;
+ int generation, resends = 0;
+ struct ldlm_reply *lockrep;
+ enum lvb_type lvb_type = LVB_T_NONE;
+ int rc;
LASSERTF(!it || einfo->ei_type == LDLM_IBITS, "lock type %d\n",
einfo->ei_type);
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/13] staging: comedi: amplc_dio200: tidy up comedi_driver declaration
On Mon, Aug 11, 2014 at 05:09:49PM +, Hartley Sweeten wrote: > On Saturday, August 09, 2014 9:15 PM, Greg KH wrote: > > On Fri, Aug 01, 2014 at 01:07:05PM -0700, H Hartley Sweeten wrote: > >> For aesthetics, add some whitespace to the declaration. > >> > >> Signed-off-by: H Hartley Sweeten > >> Reviewed-by: Ian Abbott > >> --- > >> drivers/staging/comedi/drivers/amplc_dio200.c | 14 +++--- > >> 1 file changed, 7 insertions(+), 7 deletions(-) > > > > This patch fails to apply, so I'll drop the rest of this series. Sync > > up after I push my tree out, after 3.17-rc1 is out. > > Sorry about that. I have already rebased this series but didn't > expect you to be applying anything to your tree until later this > week or next week. And here I was trying to keep on top of things :) > As suggested, I will wait until 3.17-rc1 is out then sync up and > repost the remaining pieces of this series as well as the 8255 > cleanup series. Oops, was this the series I was supposed to drop? Anyway, no big deal, just resend whenever you have them ready. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dgnc: Encapsulate global variables in a structure
On 08/11, Greg KH wrote:
> On Sun, Aug 10, 2014 at 09:19:15PM +0200, Konrad Zapalowicz wrote:
> > On 08/10, Greg KH wrote:
> > > On Sat, Aug 09, 2014 at 08:16:37PM +0200, Konrad Zapalowicz wrote:
> > > > This commit binds global variables of dgnc driver in a structure so
> > > > that it is logically consistent. The structure is accessed via getter
> > > > function and as a result the externing of globals is removed. The names
> > > > of the variables are also changed to be more eye friendly.
> > > >
> > > > Signed-off-by: Konrad Zapalowicz
> > > > ---
> > > >
> > > > This patch applies on top of my two previous patch series. In case it
> > > > is an issue I can resubmit the whole series for dgnc driver as one
> > > > patch set - just let me know.
> > > >
> > > > drivers/staging/dgnc/dgnc_driver.c | 82
> > > > +++---
> > > > drivers/staging/dgnc/dgnc_driver.h | 20 ++
> > > > drivers/staging/dgnc/dgnc_mgmt.c | 48 --
> > > > drivers/staging/dgnc/dgnc_sysfs.c | 31 ++
> > > > 4 files changed, 102 insertions(+), 79 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/dgnc/dgnc_driver.c
> > > > b/drivers/staging/dgnc/dgnc_driver.c
> > > > index 724e4ab..9a23e9a 100644
> > > > --- a/drivers/staging/dgnc/dgnc_driver.c
> > > > +++ b/drivers/staging/dgnc/dgnc_driver.c
> > > > @@ -83,17 +83,11 @@ static const struct file_operations dgnc_BoardFops
> > > > = {
> > > > .release= dgnc_mgmt_close
> > > > };
> > > >
> > > > -
> > > > -/*
> > > > - * Globals
> > > > - */
> > > > -uint dgnc_NumBoards;
> > > > -struct dgnc_board *dgnc_Board[MAXBOARDS];
> > > > -DEFINE_SPINLOCK(dgnc_global_lock);
> > > > -intdgnc_driver_state = DRIVER_INITIALIZED;
> > > > -ulong dgnc_poll_counter;
> > > > -uint dgnc_Major;
> > > > -intdgnc_poll_tick = 20;/* Poll interval - 20
> > > > ms */
> > > > +static struct dgnc_driver driver = {
> > > > + .lock = __SPIN_LOCK_UNLOCKED(driver.lock),
> > > > + .state = DRIVER_INITIALIZED,
> > > > + .poll_tick = 20,
> > > > +};
> > >
> > > While it is great to get rid of a bunch of globals, you now just
> > > replaced it with a different one :(
> > >
> > > This all should be dynamic, no need for a static array of devices at
> > > all.
> > >
> > > There shouldn't be a need for the driver_state at all, and the poll_tick
> > > should be device specific, not driver-wide. The major is fine, but it
> > > can just be a single static variable, right?
> > >
> > > So, I'd like to see the array of devices go away, can you do that
> > > instead of just moving it elsewhere?
> >
> > No doubt that there is a lot of room for improvement in this code. Now,
> > since I'm new to this driver and do not own the hardware yet I'm
> > taking the step-by-step approach patiently learning the code and
> > dependencies between different files of this driver.
>
> That's fine, and is a good thing to do.
>
> > Now, do you accept this patch knowing that this is an ongoing process of
> > this driver refubrishment and there will be more patches (ie. I can base
> > the future work on this patch) or you prefer it to be done differently
> > (ie. I should revert and do it right from the beginning).
>
> I think you should do this "correct" from the beginning, I don't want to
> take this patch.
Ok.
> How about doing the "easy" things first, like the driver-static
> variables you have here and try to get rid of them, except for
> dgnc_Major, that should just be a simple static variable.
>
> Get rid of dgnc_driver_state, that shouldn't be needed, and the poll
> counter mess, that should be device specific, not a global for the
> driver. Then move to the device-specific things, making them dynamic
> and living off of the device structure that the kernel gives you (in the
> tty device).
>
> Does that sound reasonable?
Thanks, I appreciate the guidelines. I especially found intersting the
suggestion to put emphasis on using the tty device structure.
Cheers,
Konrad
> thanks,
>
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On 08/11/14 11:26, Nick Krause wrote:
> On Mon, Aug 11, 2014 at 2:07 PM, Randy Dunlap wrote:
>> On 08/11/14 11:04, Nick Krause wrote:
>>> On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause
>>> wrote:
I am fixing the bug entry ,
https://bugzilla.kernel.org/show_bug.cgi?id=60461.
This entry states that we are not checking the skb allocated in
fw_download_code
and after checking I fixed it to check for the NULL value before using the
allocate
skb.
Signed-off-by: Nicholas Krause
---
drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
index 1a95d1f..0a4c926 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
@@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev,
u8 *code_virtual_address,
}
- skb = dev_alloc_skb(frag_length + 4);
- memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
- tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
- tcb_desc->queue_index = TXCMD_QUEUE;
- tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
- tcb_desc->bLastIniPkt = bLastIniPkt;
+ skb = dev_alloc_skb(frag_length + 4);
+ if (skb) {
+ memcpy((unsigned char *)(skb->cb), &dev,
sizeof(dev));
+ tcb_desc = (struct cb_desc *)(skb->cb +
MAX_DEV_ADDR_SIZE);
+ tcb_desc->queue_index = TXCMD_QUEUE;
+ tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
+ tcb_desc->bLastIniPkt = bLastIniPkt;
+ }
>>
>> and what happens here (below) if skb is NULL?
Nick,
I'm asking if you have completely fixed the bug or only partially fixed it.
The answer is that the patch is only a partial fix. If skb is NULL, there
is still a problem in the statement below here. The kernel will oops on
that reference to skb, which is NULL.
>>
seg_ptr = skb->data;
for (i = 0; i < frag_length; i += 4) {
*seg_ptr++ = ((i+0) < frag_length) ?
--
1.9.1
>>> And I did check it against Linus's tree to make sure it applies , just
>>> to let you known.
>>> Nick
>>
>>
>> --
>> ~Randy
> Sorry Randy.
> I may be mis reading this, but are you asking me to write a different
> commit message or is this patch just another bad patch in my series of
> bad patches?
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: vt6655: wpactl.h: corrected comment format
On Mon, Aug 11, 2014 at 11:26:32PM +0530, Avinash kumar wrote:
> corrected C99 style comment format related error
>
> Signed-off-by: Avinash Kumar
> ---
> drivers/staging/vt6655/wpactl.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vt6655/wpactl.h b/drivers/staging/vt6655/wpactl.h
> index f7638ba..2ff42c5 100644
> --- a/drivers/staging/vt6655/wpactl.h
> +++ b/drivers/staging/vt6655/wpactl.h
> @@ -36,7 +36,7 @@
>
> /*- Export Definitions -*/
>
> -//WPA related
> +/*WPA related*/
Shouldn't you use 2 extra ' ' characters here?
> enum wpa_alg { WPA_ALG_NONE, WPA_ALG_WEP, WPA_ALG_TKIP, WPA_ALG_CCMP };
> enum wpa_cipher { CIPHER_NONE, CIPHER_WEP40, CIPHER_TKIP, CIPHER_CCMP,
> @@ -61,4 +61,4 @@ int wpa_set_wpadev(PSDevice pDevice, int val);
> int wpa_ioctl(PSDevice pDevice, struct iw_point *p);
> int wpa_set_keys(PSDevice pDevice, void *ctx, bool fcpfkernel);
>
> -#endif // __WPACL_H__
> +#endif /* __WPACL_H__*/
And one extra ' ' here, right before the '*/' please.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On Mon, Aug 11, 2014 at 2:45 PM, Randy Dunlap wrote:
> On 08/11/14 11:26, Nick Krause wrote:
>> On Mon, Aug 11, 2014 at 2:07 PM, Randy Dunlap wrote:
>>> On 08/11/14 11:04, Nick Krause wrote:
On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause
wrote:
> I am fixing the bug entry ,
> https://bugzilla.kernel.org/show_bug.cgi?id=60461.
> This entry states that we are not checking the skb allocated in
> fw_download_code
> and after checking I fixed it to check for the NULL value before using
> the allocate
> skb.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..0a4c926 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev,
> u8 *code_virtual_address,
>
> }
>
> - skb = dev_alloc_skb(frag_length + 4);
> - memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
> - tcb_desc = (struct cb_desc *)(skb->cb +
> MAX_DEV_ADDR_SIZE);
> - tcb_desc->queue_index = TXCMD_QUEUE;
> - tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
> - tcb_desc->bLastIniPkt = bLastIniPkt;
>
> + skb = dev_alloc_skb(frag_length + 4);
> + if (skb) {
> + memcpy((unsigned char *)(skb->cb), &dev,
> sizeof(dev));
> + tcb_desc = (struct cb_desc *)(skb->cb +
> MAX_DEV_ADDR_SIZE);
> + tcb_desc->queue_index = TXCMD_QUEUE;
> + tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
> + tcb_desc->bLastIniPkt = bLastIniPkt;
> + }
>>>
>>> and what happens here (below) if skb is NULL?
>
> Nick,
> I'm asking if you have completely fixed the bug or only partially fixed it.
> The answer is that the patch is only a partial fix. If skb is NULL, there
> is still a problem in the statement below here. The kernel will oops on
> that reference to skb, which is NULL.
>
>>>
> seg_ptr = skb->data;
> for (i = 0; i < frag_length; i += 4) {
> *seg_ptr++ = ((i+0) < frag_length) ?
> --
> 1.9.1
>
And I did check it against Linus's tree to make sure it applies , just
to let you known.
Nick
>>>
>>>
>>> --
>>> ~Randy
>> Sorry Randy.
>> I may be mis reading this, but are you asking me to write a different
>> commit message or is this patch just another bad patch in my series of
>> bad patches?
>
>
> --
> ~Randy
Randy ,
Thanks for the catch :). Would you recommend just putting it in the if
statement I created or create a second if statement for
code readability.
Cheers Nick
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On 08/11/14 11:55, Nick Krause wrote:
> On Mon, Aug 11, 2014 at 2:45 PM, Randy Dunlap wrote:
>> On 08/11/14 11:26, Nick Krause wrote:
>>> On Mon, Aug 11, 2014 at 2:07 PM, Randy Dunlap wrote:
On 08/11/14 11:04, Nick Krause wrote:
> On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause
> wrote:
>> I am fixing the bug entry ,
>> https://bugzilla.kernel.org/show_bug.cgi?id=60461.
>> This entry states that we are not checking the skb allocated in
>> fw_download_code
>> and after checking I fixed it to check for the NULL value before using
>> the allocate
>> skb.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> index 1a95d1f..0a4c926 100644
>> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> @@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device *dev,
>> u8 *code_virtual_address,
>>
>> }
>>
>> - skb = dev_alloc_skb(frag_length + 4);
>> - memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
>> - tcb_desc = (struct cb_desc *)(skb->cb +
>> MAX_DEV_ADDR_SIZE);
>> - tcb_desc->queue_index = TXCMD_QUEUE;
>> - tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>> - tcb_desc->bLastIniPkt = bLastIniPkt;
>>
>> + skb = dev_alloc_skb(frag_length + 4);
>> + if (skb) {
>> + memcpy((unsigned char *)(skb->cb), &dev,
>> sizeof(dev));
>> + tcb_desc = (struct cb_desc *)(skb->cb +
>> MAX_DEV_ADDR_SIZE);
>> + tcb_desc->queue_index = TXCMD_QUEUE;
>> + tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>> + tcb_desc->bLastIniPkt = bLastIniPkt;
>> + }
and what happens here (below) if skb is NULL?
>>
>> Nick,
>> I'm asking if you have completely fixed the bug or only partially fixed it.
>> The answer is that the patch is only a partial fix. If skb is NULL, there
>> is still a problem in the statement below here. The kernel will oops on
>> that reference to skb, which is NULL.
>>
>> seg_ptr = skb->data;
>> for (i = 0; i < frag_length; i += 4) {
>> *seg_ptr++ = ((i+0) < frag_length) ?
>> --
>> 1.9.1
>>
> And I did check it against Linus's tree to make sure it applies , just
> to let you known.
> Nick
--
~Randy
>>> Sorry Randy.
>>> I may be mis reading this, but are you asking me to write a different
>>> commit message or is this patch just another bad patch in my series of
>>> bad patches?
>>
>>
>> --
>> ~Randy
>
> Randy ,
> Thanks for the catch :). Would you recommend just putting it in the if
> statement I created or create a second if statement for
> code readability.
Neither one of those choices. I suggest that the code immediately check for
skb == NULL and return 0 (or false) if it is NULL. Then the code below that
check
won't need to be changed at all.
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On Mon, Aug 11, 2014 at 3:04 PM, Randy Dunlap wrote:
> On 08/11/14 11:55, Nick Krause wrote:
>> On Mon, Aug 11, 2014 at 2:45 PM, Randy Dunlap wrote:
>>> On 08/11/14 11:26, Nick Krause wrote:
On Mon, Aug 11, 2014 at 2:07 PM, Randy Dunlap
wrote:
> On 08/11/14 11:04, Nick Krause wrote:
>> On Mon, Aug 11, 2014 at 2:02 PM, Nicholas Krause
>> wrote:
>>> I am fixing the bug entry ,
>>> https://bugzilla.kernel.org/show_bug.cgi?id=60461.
>>> This entry states that we are not checking the skb allocated in
>>> fw_download_code
>>> and after checking I fixed it to check for the NULL value before using
>>> the allocate
>>> skb.
>>>
>>> Signed-off-by: Nicholas Krause
>>> ---
>>> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 14 --
>>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> index 1a95d1f..0a4c926 100644
>>> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>>> @@ -60,13 +60,15 @@ static bool fw_download_code(struct net_device
>>> *dev, u8 *code_virtual_address,
>>>
>>> }
>>>
>>> - skb = dev_alloc_skb(frag_length + 4);
>>> - memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
>>> - tcb_desc = (struct cb_desc *)(skb->cb +
>>> MAX_DEV_ADDR_SIZE);
>>> - tcb_desc->queue_index = TXCMD_QUEUE;
>>> - tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>>> - tcb_desc->bLastIniPkt = bLastIniPkt;
>>>
>>> + skb = dev_alloc_skb(frag_length + 4);
>>> + if (skb) {
>>> + memcpy((unsigned char *)(skb->cb), &dev,
>>> sizeof(dev));
>>> + tcb_desc = (struct cb_desc *)(skb->cb +
>>> MAX_DEV_ADDR_SIZE);
>>> + tcb_desc->queue_index = TXCMD_QUEUE;
>>> + tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>>> + tcb_desc->bLastIniPkt = bLastIniPkt;
>>> + }
>
> and what happens here (below) if skb is NULL?
>>>
>>> Nick,
>>> I'm asking if you have completely fixed the bug or only partially fixed it.
>>> The answer is that the patch is only a partial fix. If skb is NULL, there
>>> is still a problem in the statement below here. The kernel will oops on
>>> that reference to skb, which is NULL.
>>>
>
>>> seg_ptr = skb->data;
>>> for (i = 0; i < frag_length; i += 4) {
>>> *seg_ptr++ = ((i+0) < frag_length) ?
>>> --
>>> 1.9.1
>>>
>> And I did check it against Linus's tree to make sure it applies , just
>> to let you known.
>> Nick
>
>
> --
> ~Randy
Sorry Randy.
I may be mis reading this, but are you asking me to write a different
commit message or is this patch just another bad patch in my series of
bad patches?
>>>
>>>
>>> --
>>> ~Randy
>>
>> Randy ,
>> Thanks for the catch :). Would you recommend just putting it in the if
>> statement I created or create a second if statement for
>> code readability.
>
> Neither one of those choices. I suggest that the code immediately check for
> skb == NULL and return 0 (or false) if it is NULL. Then the code below that
> check
> won't need to be changed at all.
>
>
>
> --
> ~Randy
Thanks Randy for your help otherwise is my patch good? Please let me
known if there our any other issues.
Regards Nick
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
On 08/11/14 12:18, Nick Krause wrote: > > Thanks Randy for your help otherwise is my patch good? Please let me > known if there our any other issues. > Regards Nick I didn't notice any other issues with it. -- ~Randy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Check against NULL in fw_download_code
Thanks Randy for checking this I am going to resend as a v2 patch. Regards Nick On Mon, Aug 11, 2014 at 3:40 PM, Randy Dunlap wrote: > On 08/11/14 12:18, Nick Krause wrote: >> >> Thanks Randy for your help otherwise is my patch good? Please let me >> known if there our any other issues. >> Regards Nick > > I didn't notice any other issues with it. > > -- > ~Randy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2] staging: Check against NULL in fw_download_code
I am fixing the bug entry , https://bugzilla.kernel.org/show_bug.cgi?id=60461. This entry states that we are not checking the skb allocated in fw_download_code and after checking I fixed it to check for the NULL value before using the allocate skb. Signed-off-by: Nicholas Krause --- drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c index 1a95d1f..817e50e 100644 --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c @@ -61,6 +61,8 @@ static bool fw_download_code(struct net_device *dev, u8 *code_virtual_address, } skb = dev_alloc_skb(frag_length + 4); + if (skb == NULL) + return !rt_status; memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev)); tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE); tcb_desc->queue_index = TXCMD_QUEUE; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: lustre: ptlrpc: nrs.c: Cleaning up missing null-terminate after strncpy call
2014-08-11 12:58 GMT+02:00 Dan Carpenter : > On Sun, Aug 10, 2014 at 01:49:12AM +0200, Rickard Strandqvist wrote: >> Added a guaranteed null-terminate after call to strncpy. > > No. This is a problem in the static checker and not in the code. > > Look at the start of the function. This stuff should be obvious for the > static checker. > > regards, > dan carpenter > Hi Dan Okay, no, it was me who missed it, not cppcheck. Ensuring that from string will fit was an unusual solution. If I see code where an effort is made to ensure that no more than x characters copied I react to it. But it is zeroing of the string you were looking for then. Ok sorry :-( Kind regards Rickard Strandqvist ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2] staging: Check against NULL in fw_download_code
On Mon, Aug 11, 2014 at 5:48 PM, Jerry Snitselaar wrote: > On Mon Aug 11 14, Nicholas Krause wrote: >> I am fixing the bug entry , >> https://bugzilla.kernel.org/show_bug.cgi?id=60461. >> This entry states that we are not checking the skb allocated in >> fw_download_code >> and after checking I fixed it to check for the NULL value before using the >> allocate >> skb. >> >> Signed-off-by: Nicholas Krause >> --- >> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c >> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c >> index 1a95d1f..817e50e 100644 >> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c >> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c >> @@ -61,6 +61,8 @@ static bool fw_download_code(struct net_device *dev, u8 >> *code_virtual_address, >> } >> >> skb = dev_alloc_skb(frag_length + 4); >> + if (skb == NULL) >> + return !rt_status; >> memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev)); >> tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE); >> tcb_desc->queue_index = TXCMD_QUEUE; >> -- >> 1.9.1 > > > Look at fw_download_code() in drivers/staging/rtl8192u/r819xU_firmware.c Hey Jerry, I assume you want me to return true or false directly and remove rt_status. Cheers Nick ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
A sparse warning is generated about 'ieee80211_debug_init' and 'ieee80211_debug_exit' not being declared. drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: symbol 'ieee80211_debug_init' was not declared. Should it be static? drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: symbol 'ieee80211_debug_exit' was not declared. Should it be static? These functions are used outside of this file so using static will not work. Fix the warning by declaring the functions in the header file, ieee80211.h Signed-off-by: Jeremiah Mahler Cc: Greg Kroah-Hartman Cc: Teodora Baluta Cc: Andrea Merello Cc: Joel Pelaez Jorge Cc: Bob Copeland Cc: Joe Perches Cc: Arnd Bergmann Cc: Himangi Saraogi --- drivers/staging/rtl8192u/ieee80211/ieee80211.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h index 1040bab..9cbda69 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h @@ -2485,6 +2485,12 @@ extern int ieee80211_wx_set_freq(struct ieee80211_device *ieee, struct iw_reques extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct iw_request_info *a, union iwreq_data *wrqu, char *b); +/* ieee80211_module.c */ +#ifdef CONFIG_IEEE80211_DEBUG +extern int __init ieee80211_debug_init(void); +extern void __exit ieee80211_debug_exit(void); +#endif /* CONFIG_IEEE80211_DEBUG */ + //extern void ieee80211_wx_sync_scan_wq(struct ieee80211_device *ieee); extern void ieee80211_wx_sync_scan_wq(struct work_struct *work); -- 2.1.0.rc1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2] staging: Check against NULL in fw_download_code
On Mon Aug 11 14, Nicholas Krause wrote: > I am fixing the bug entry , https://bugzilla.kernel.org/show_bug.cgi?id=60461. > This entry states that we are not checking the skb allocated in > fw_download_code > and after checking I fixed it to check for the NULL value before using the > allocate > skb. > > Signed-off-by: Nicholas Krause > --- > drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c > b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c > index 1a95d1f..817e50e 100644 > --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c > +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c > @@ -61,6 +61,8 @@ static bool fw_download_code(struct net_device *dev, u8 > *code_virtual_address, > } > > skb = dev_alloc_skb(frag_length + 4); > + if (skb == NULL) > + return !rt_status; > memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev)); > tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE); > tcb_desc->queue_index = TXCMD_QUEUE; > -- > 1.9.1 Look at fw_download_code() in drivers/staging/rtl8192u/r819xU_firmware.c ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
On Mon, Aug 11, 2014 at 03:15:54PM -0700, Jeremiah Mahler wrote: > A sparse warning is generated about 'ieee80211_debug_init' and > 'ieee80211_debug_exit' not being declared. > > drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: > symbol 'ieee80211_debug_init' was not declared. Should it be static? > drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: > symbol 'ieee80211_debug_exit' was not declared. Should it be static? > > These functions are used outside of this file so using static will not > work. Fix the warning by declaring the functions in the header file, > ieee80211.h > > Signed-off-by: Jeremiah Mahler > Cc: Greg Kroah-Hartman > Cc: Teodora Baluta > Cc: Andrea Merello > Cc: Joel Pelaez Jorge > Cc: Bob Copeland > Cc: Joe Perches > Cc: Arnd Bergmann > Cc: Himangi Saraogi > --- > drivers/staging/rtl8192u/ieee80211/ieee80211.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h > b/drivers/staging/rtl8192u/ieee80211/ieee80211.h > index 1040bab..9cbda69 100644 > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h > @@ -2485,6 +2485,12 @@ extern int ieee80211_wx_set_freq(struct > ieee80211_device *ieee, struct iw_reques > extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct > iw_request_info *a, >union iwreq_data *wrqu, char *b); > > +/* ieee80211_module.c */ > +#ifdef CONFIG_IEEE80211_DEBUG > +extern int __init ieee80211_debug_init(void); > +extern void __exit ieee80211_debug_exit(void); > +#endif /* CONFIG_IEEE80211_DEBUG */ > + As it's a header file, why not always have them here, no need for the ifdef. And __init and __exit don't belong in a .h function prototype. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv3] staging: Check for Null allocated skb in fw_download_code
I am fixing the bug entry , https://bugzilla.kernel.org/show_bug.cgi?id=60461.
This entry states that we are not checking the skb allocated in fw_download_code
for NULL and after checking it ,I fixed it to check for the NULL value before
returning false and exiting fw_download_code cleanly. In additon I removed the
variable, rt_status as it's easier to read this function's return value with
just true or false and rt status is a unneeded variable for the bool return
of this function.
Signed-off-by: Nicholas Krause
---
drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
index 1a95d1f..66d83f8 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
@@ -36,7 +36,6 @@ static bool fw_download_code(struct net_device *dev, u8
*code_virtual_address,
u32 buffer_len)
{
struct r8192_priv *priv = rtllib_priv(dev);
- boolrt_status = true;
u16 frag_threshold;
u16 frag_length, frag_offset = 0;
int i;
@@ -61,6 +60,8 @@ static bool fw_download_code(struct net_device *dev, u8
*code_virtual_address,
}
skb = dev_alloc_skb(frag_length + 4);
+ if (skb == NULL)
+ return false;
memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
tcb_desc->queue_index = TXCMD_QUEUE;
@@ -99,7 +100,7 @@ static bool fw_download_code(struct net_device *dev, u8
*code_virtual_address,
write_nic_byte(dev, TPPoll, TPPoll_CQ);
- return rt_status;
+ return true;
}
static bool CPUcheck_maincodeok_turnonCPU(struct net_device *dev)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv3] staging: Check for Null allocated skb in fw_download_code
On Mon, Aug 11, 2014 at 7:12 PM, Nicholas Krause wrote:
> I am fixing the bug entry , https://bugzilla.kernel.org/show_bug.cgi?id=60461.
> This entry states that we are not checking the skb allocated in
> fw_download_code
> for NULL and after checking it ,I fixed it to check for the NULL value before
> returning false and exiting fw_download_code cleanly. In additon I removed the
> variable, rt_status as it's easier to read this function's return value with
> just true or false and rt status is a unneeded variable for the bool return
> of this function.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..66d83f8 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -36,7 +36,6 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
> u32 buffer_len)
> {
> struct r8192_priv *priv = rtllib_priv(dev);
> - boolrt_status = true;
> u16 frag_threshold;
> u16 frag_length, frag_offset = 0;
> int i;
> @@ -61,6 +60,8 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
> }
>
> skb = dev_alloc_skb(frag_length + 4);
> + if (skb == NULL)
> + return false;
> memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
> tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
> tcb_desc->queue_index = TXCMD_QUEUE;
> @@ -99,7 +100,7 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
>
> write_nic_byte(dev, TPPoll, TPPoll_CQ);
>
> - return rt_status;
> + return true;
> }
>
> static bool CPUcheck_maincodeok_turnonCPU(struct net_device *dev)
> --
> 1.9.1
>
Sorry about the three versions, other people wanted to make the code
and my bug fix correct.
Cheers Nick
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/7] staging: dgap: remove useless variable
Hi, Dan 2014-08-11 19:56 GMT+09:00 Dan Carpenter : > On Sat, Aug 09, 2014 at 02:36:44PM +0900, Daeseok Youn wrote: >> dgap_major_serial_registered and dgap_major_transparent_print_registered >> could be checked whether a board is initialized. >> But it doesn't need to check that variables becasue dgap module >> isn't calling the dgap_cleanup_tty() without initializing >> for a board completely. > > I don't understand. What about the call to dgap_cleanup_module() in > dgap_init_module()? I think the call of dgap_cleanup_tty() in dgap_cleanup_module() from dgap_init_module() is not reached. Because dgap_init_module() is called when driver is loaded, at this point of time, there are no boards that are initialized.(dgap_numboards is zero) And the change log of this is needed to modify for clearing message. Thanks. regards, Daeseok Youn. > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Aug 9, 2014, at 11:47 AM, Greg Kroah-Hartman wrote: > On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote: >> >>> Because maybe these stats preceed the introduction of perf and other >>> tracing/debug tools? I don't know, it's really low down on the list of >>> reasons why lustre can't be merged out of staging at the moment, you all >>> have much bigger issues to address first. >> >> I wonder what is the prioritized list you have in mind? > > Do I really have to spell out what is wrong with that codebase that > needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix > up a _portion_ of the include file mess that is in there. Now is the > first time the code actually _builds_ properly in the kernel tree (i.e. > no magic header file include path modifications in Makefiles preventing > individual files from being built correctly.) Well, last time we discussed this topic, you said that moving most of lustre proc files into sysfs and other suitable venues is what prevents moving lustre out of the staging tree under fs/ There well might be include mess, but this is the first time I hear about it, and I have not seen any build breakage or other obviously broken behavior. I am sure there are more things too, that's why I am asking. We are trying to deal with stuff we know about, but it's a bit harder to deal with the stuff we don't know about that does not manifest itself in some clear way. Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
A sparse warning is generated about 'ieee80211_debug_init' and 'ieee80211_debug_exit' not being declared. drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: symbol 'ieee80211_debug_init' was not declared. Should it be static? drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: symbol 'ieee80211_debug_exit' was not declared. Should it be static? These functions are used outside of this file so using static will not work. Fix the warning by declaring the functions in the header file, ieee80211.h Signed-off-by: Jeremiah Mahler Cc: Greg Kroah-Hartman Cc: Teodora Baluta Cc: Andrea Merello Cc: Joel Pelaez Jorge Cc: Bob Copeland Cc: Joe Perches Cc: Arnd Bergmann Cc: Himangi Saraogi --- Notes: Changes in v2: - remove #ifdef CONFIG_IEEE80211_DEBUG, not needed in header. - remove __init and __exit, not needed in header. drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h index 1040bab..c118551 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h @@ -2485,6 +2485,10 @@ extern int ieee80211_wx_set_freq(struct ieee80211_device *ieee, struct iw_reques extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct iw_request_info *a, union iwreq_data *wrqu, char *b); +/* ieee80211_module.c */ +extern int ieee80211_debug_init(void); +extern void ieee80211_debug_exit(void); + //extern void ieee80211_wx_sync_scan_wq(struct ieee80211_device *ieee); extern void ieee80211_wx_sync_scan_wq(struct work_struct *work); -- 2.1.0.rc1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: lustre: fix sparse warnings / delete unused function
On Aug 10, 2014, at 12:34 AM, Greg KH wrote: > Very odd, with this patch applied, I now get a build warning: > > drivers/staging/lustre/lnet/lnet/config.c: In function ‘lnet_parse_ip2nets’: > drivers/staging/lustre/lnet/lnet/config.c:1193:2: warning: ‘ipaddrs’ may be > used uninitialized in this function [-Wmaybe-uninitialized] > lnet_ipaddr_free_enumeration(ipaddrs, nip); > ^ What's even more odd is that the very previous line also uses ipaddrs, yet it does not trigger the warning. In any case I believe it's a false positive, since the only way it could remain unitialized is if libcfs_ipif_enumerate returned negative value (stored in nif in this function) and we check for it being more than zero before getting to that part of code. I'll submit a patch assigning ipaddrs to NULL as a workaround shortly. Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] staging: comedi: addi_apci_1564: miscellaneous cleanups
This patchset removes an uncorrect and unneeded insn_config operation, strips out remaining in-driver watchdog subdevice code, and cleans up the driver's register map defines. Chase Southwood (3): staging: comedi: addi_apci_1564: remove apci1564_do_config staging: comedi: addi_apci_1564: Remove in-driver watchdog support code staging: comedi: addi_apci_1564: tidy register map defines .../comedi/drivers/addi-data/hwdrv_apci1564.c | 158 +++-- drivers/staging/comedi/drivers/addi_apci_1564.c| 20 +-- 2 files changed, 60 insertions(+), 118 deletions(-) -- 2.0.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: lustre: fix sparse warnings / delete unused function
On Aug 11, 2014, at 9:58 PM, Oleg Drokin wrote: > > On Aug 10, 2014, at 12:34 AM, Greg KH wrote: >> Very odd, with this patch applied, I now get a build warning: >> >> drivers/staging/lustre/lnet/lnet/config.c: In function ‘lnet_parse_ip2nets’: >> drivers/staging/lustre/lnet/lnet/config.c:1193:2: warning: ‘ipaddrs’ may be >> used uninitialized in this function [-Wmaybe-uninitialized] >> lnet_ipaddr_free_enumeration(ipaddrs, nip); >> ^ > > What's even more odd is that the very previous line also uses ipaddrs, yet it > does not trigger the warning. > In any case I believe it's a false positive, since the only way it could > remain unitialized is if > libcfs_ipif_enumerate returned negative value (stored in nif in this > function) and we check for it being more than zero > before getting to that part of code. > > I'll submit a patch assigning ipaddrs to NULL as a workaround shortly. Err, looking at the wrong function there, it's lnet_ipaddr_enumerate that returns negative if ipaddrs was not changed. Anyway still false positive. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: comedi: addi_apci_1564: remove apci1564_do_config
The DO config function served the purpose of configuring the diagnostic
interrupts for the board. As the driver currently does not support
diagnostic interrupts, the digital output subdevice does not need an
insn_config operation and this function can be safely removed.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 34 --
drivers/staging/comedi/drivers/addi_apci_1564.c| 1 -
2 files changed, 35 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 8a613ae..0ce1deb 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -88,40 +88,6 @@
#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
/*
- * Configures The Digital Output Subdevice.
- *
- * data[1] 0 = Disable VCC Interrupt, 1 = Enable VCC Interrupt
- * data[2] 0 = Disable CC Interrupt, 1 = Enable CC Interrupt
- */
-static int apci1564_do_config(struct comedi_device *dev,
- struct comedi_subdevice *s,
- struct comedi_insn *insn,
- unsigned int *data)
-{
- struct apci1564_private *devpriv = dev->private;
- unsigned int ul_Command = 0;
-
- if ((data[0] != 0) && (data[0] != 1)) {
- dev_err(dev->class_dev, "Data should be 1 or 0\n");
- return -EINVAL;
- }
-
- if (data[1] == 1)
- ul_Command = ul_Command | 0x1;
- else
- ul_Command = ul_Command & 0xFFFE;
-
- if (data[2] == 1)
- ul_Command = ul_Command | 0x2;
- else
- ul_Command = ul_Command & 0xFFFD;
-
- outl(ul_Command, devpriv->amcc_iobase + APCI1564_DO_INT_CTRL_REG);
- devpriv->tsk_current = current;
- return insn->n;
-}
-
-/*
* Configures The Timer, Counter or Watchdog
*
* data[0] Configure as: 0 = Timer, 1 = Counter, 2 = Watchdog
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 543cb07..555e0a9 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -388,7 +388,6 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->n_chan = 32;
s->maxdata = 1;
s->range_table = &range_digital;
- s->insn_config = apci1564_do_config;
s->insn_bits = apci1564_do_insn_bits;
/* Change-Of-State (COS) interrupt subdevice */
--
2.0.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: comedi: addi_apci_1564: tidy register map defines
This commit performs a final tidying of the register map defines, bringing
them to a state that is ready for merging into addi_apci_1564.c when the
time comes. Actions performed include:
*Removes the APCI1564_ADDRESS_RANGE macro, which is no longer needed/used.
*Renames the APCI1564_DIGITAL_OP_{VCC,CC}_INTERRUPT_{ENABLE,DISABLE}
macros to shorter names which are more consistent with the digital input
interrupt macros.
*Fixes a typo in a comment (dev>iobase changed to dev->iobase).
*Renames the APCI1564_TCW_* macros to APCI1564_COUNTER_* names to more
accurately reflect that they are only offsets to counter registers (since
only the counters are offset from dev->iobase).
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 70 --
drivers/staging/comedi/drivers/addi_apci_1564.c| 19 +++---
2 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index f8d8cc9..198c627 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -21,8 +21,6 @@
*
*/
-#define APCI1564_ADDRESS_RANGE 128
-
/* Digital Input IRQ Function Selection */
#define APCI1564_DI_INT_OR (0 << 1)
#define APCI1564_DI_INT_AND(1 << 1)
@@ -32,10 +30,10 @@
#define APCI1564_DI_INT_DISABLE0xfffb
/* Digital Output Interrupt Enable Disable. */
-#define APCI1564_DIGITAL_OP_VCC_INTERRUPT_ENABLE 0x1
-#define APCI1564_DIGITAL_OP_VCC_INTERRUPT_DISABLE 0xfffe
-#define APCI1564_DIGITAL_OP_CC_INTERRUPT_ENABLE0x2
-#define APCI1564_DIGITAL_OP_CC_INTERRUPT_DISABLE 0xfffd
+#define APCI1564_DO_VCC_INT_ENABLE 0x1
+#define APCI1564_DO_VCC_INT_DISABLE0xfffe
+#define APCI1564_DO_CC_INT_ENABLE 0x2
+#define APCI1564_DO_CC_IN_DISABLE 0xfffd
/* TIMER COUNTER WATCHDOG DEFINES */
#define ADDIDATA_TIMER 0
@@ -76,16 +74,16 @@
#define APCI1564_TIMER_WARN_TIMEBASE_REG 0x64
/*
- * dev>iobase Register Map
+ * dev->iobase Register Map
*/
-#define APCI1564_TCW_REG(x)(0x00 + ((x) * 0x20))
-#define APCI1564_TCW_RELOAD_REG(x) (0x04 + ((x) * 0x20))
-#define APCI1564_TCW_TIMEBASE_REG(x) (0x08 + ((x) * 0x20))
-#define APCI1564_TCW_CTRL_REG(x) (0x0c + ((x) * 0x20))
-#define APCI1564_TCW_STATUS_REG(x) (0x10 + ((x) * 0x20))
-#define APCI1564_TCW_IRQ_REG(x)(0x14 + ((x) *
0x20))
-#define APCI1564_TCW_WARN_TIMEVAL_REG(x) (0x18 + ((x) * 0x20))
-#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
+#define APCI1564_COUNTER_REG(x)(0x00 + ((x) *
0x20))
+#define APCI1564_COUNTER_RELOAD_REG(x) (0x04 + ((x) * 0x20))
+#define APCI1564_COUNTER_TIMEBASE_REG(x) (0x08 + ((x) * 0x20))
+#define APCI1564_COUNTER_CTRL_REG(x) (0x0c + ((x) * 0x20))
+#define APCI1564_COUNTER_STATUS_REG(x) (0x10 + ((x) * 0x20))
+#define APCI1564_COUNTER_IRQ_REG(x)(0x14 + ((x) * 0x20))
+#define APCI1564_COUNTER_WARN_TIMEVAL_REG(x) (0x18 + ((x) * 0x20))
+#define APCI1564_COUNTER_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
/*
* Configures The Timer or Counter
@@ -121,14 +119,14 @@ static int apci1564_timer_config(struct comedi_device
*dev,
outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
outl(0x0, devpriv->amcc_iobase + APCI1564_DO_IRQ_REG);
outl(0x0, devpriv->amcc_iobase + APCI1564_WDOG_IRQ_REG);
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER1));
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER2));
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER3));
- outl(0x0,
-dev->iobase +
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER4));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1564_COUNTER1));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1564_COUNTER2));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1564_COUNTER3));
+ outl(0x0, dev->iobase +
+ APCI1564_COUNTER_IRQ_REG(APCI1
[PATCH 2/3] staging: comedi: addi_apci_1564: Remove in-driver watchdog support code
Starting with commit 1496e5961113 ("staging: comedi: addi_apci_1564: use
addi_watchdog module to init watchdog subdevice"), this driver uses the
addi_watchdog module to provide support for the watchdog subdevice. Any
remaining watchdog code in-driver can and should be removed.
This will also make future work on the timer and counter subdevices easier.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 54 +-
1 file changed, 12 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 0ce1deb..f8d8cc9 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -88,9 +88,9 @@
#define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20))
/*
- * Configures The Timer, Counter or Watchdog
+ * Configures The Timer or Counter
*
- * data[0] Configure as: 0 = Timer, 1 = Counter, 2 = Watchdog
+ * data[0] Configure as: 0 = Timer, 1 = Counter
* data[1] 1 = Enable Interrupt, 0 = Disable Interrupt
* data[2] Time Unit
* data[3] Reload Value
@@ -107,14 +107,7 @@ static int apci1564_timer_config(struct comedi_device *dev,
unsigned int ul_Command1 = 0;
devpriv->tsk_current = current;
- if (data[0] == ADDIDATA_WATCHDOG) {
- devpriv->timer_select_mode = ADDIDATA_WATCHDOG;
-
- /* Disable the watchdog */
- outl(0x0, devpriv->amcc_iobase + APCI1564_WDOG_CTRL_REG);
- /* Loading the Reload value */
- outl(data[3], devpriv->amcc_iobase + APCI1564_WDOG_RELOAD_REG);
- } else if (data[0] == ADDIDATA_TIMER) {
+ if (data[0] == ADDIDATA_TIMER) {
/* First Stop The Timer */
ul_Command1 = inl(devpriv->amcc_iobase +
APCI1564_TIMER_CTRL_REG);
ul_Command1 = ul_Command1 & 0xF9FEUL;
@@ -187,14 +180,13 @@ static int apci1564_timer_config(struct comedi_device
*dev,
} else {
dev_err(dev->class_dev, "Invalid subdevice.\n");
}
-
return insn->n;
}
/*
- * Start / Stop The Selected Timer, Counter or Watchdog
+ * Start / Stop The Selected Timer or Counter
*
- * data[0] Configure as: 0 = Timer, 1 = Counter, 2 = Watchdog
+ * data[0] Configure as: 0 = Timer, 1 = Counter
* data[1] 0 = Stop, 1 = Start, 2 = Trigger Clear (Only Counter)
*/
static int apci1564_timer_write(struct comedi_device *dev,
@@ -205,23 +197,6 @@ static int apci1564_timer_write(struct comedi_device *dev,
struct apci1564_private *devpriv = dev->private;
unsigned int ul_Command1 = 0;
- if (devpriv->timer_select_mode == ADDIDATA_WATCHDOG) {
- switch (data[1]) {
- case 0: /* stop the watchdog */
- /* disable the watchdog */
- outl(0x0, devpriv->amcc_iobase +
APCI1564_WDOG_CTRL_REG);
- break;
- case 1: /* start the watchdog */
- outl(0x0001, devpriv->amcc_iobase +
APCI1564_WDOG_CTRL_REG);
- break;
- case 2: /* Software trigger */
- outl(0x0201, devpriv->amcc_iobase +
APCI1564_WDOG_CTRL_REG);
- break;
- default:
- dev_err(dev->class_dev, "Specified functionality does
not exist.\n");
- return -EINVAL;
- }
- }
if (devpriv->timer_select_mode == ADDIDATA_TIMER) {
if (data[1] == 1) {
ul_Command1 = inl(devpriv->amcc_iobase +
APCI1564_TIMER_CTRL_REG);
@@ -236,8 +211,7 @@ static int apci1564_timer_write(struct comedi_device *dev,
ul_Command1 = ul_Command1 & 0xF9FEUL;
outl(ul_Command1, devpriv->amcc_iobase +
APCI1564_TIMER_CTRL_REG);
}
- }
- if (devpriv->timer_select_mode == ADDIDATA_COUNTER) {
+ } else if (devpriv->timer_select_mode == ADDIDATA_COUNTER) {
ul_Command1 =
inl(dev->iobase +
APCI1564_TCW_CTRL_REG(devpriv->mode_select_register
- 1));
@@ -254,12 +228,14 @@ static int apci1564_timer_write(struct comedi_device *dev,
}
outl(ul_Command1, dev->iobase +
APCI1564_TCW_CTRL_REG(devpriv->mode_select_register - 1));
+ } else {
+ dev_err(dev->class_dev, "Invalid subdevice.\n");
}
return insn->n;
}
/*
- * Read The Selected Timer, Counter or Watchdog
+ * Read The Selected Timer or Counter
*/
static int apci1564_timer_read(struct comedi_device *dev,
struct comedi_subdevice *s,
@@ -269,11 +245,7 @@ static int apci1564_timer_read(struct comedi_device *dev,
Re: [PATCH v2 08/13] staging: lustre: fix multi line strings
On Aug 11, 2014, at 2:27 PM, Srikrishan Malik wrote: > Fixes the following checkpatch warning: > > WARNING: quoted string split across lines > diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c > b/drivers/staging/lustre/lustre/mdc/mdc_request.c > index 57d903156917..6c691a4763b5 100644 > --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c > +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c > @@ -2055,8 +2055,8 @@ static int mdc_hsm_copytool_send(int len, void *val) > return -EPROTO; > } > > - CDEBUG(D_HSM, " Received message mg=%x t=%d m=%d l=%d actions=%d " > -"on %s\n", > + CDEBUG(D_HSM, > +" Received message mg=%x t=%d m=%d l=%d actions=%d on %s\n", > lh->kuc_magic, lh->kuc_transport, lh->kuc_msgtype, > lh->kuc_msglen, hal->hal_count, hal->hal_fsname); I imagine we can drop the leading space here as well. Thanks. Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/lustre/lnet: Fix potential uninitialized variable warning
Greg reports that with one of the patches in his queue
there's now an unused variable warning in lnet_parse_ip2nets
for ipaddrs variable.
Apparently the warning is a false positive as in all cases where
lnet_ipaddr_enumerate can return without setting ipaddrs to something
a negative return value is returned that is then checked
before we actually use ipaddrs.
Assign ipaddrs to NULL to quiet this.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/lnet/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/lnet/config.c
b/drivers/staging/lustre/lnet/lnet/config.c
index 7c8b947..d77aa31 100644
--- a/drivers/staging/lustre/lnet/lnet/config.c
+++ b/drivers/staging/lustre/lnet/lnet/config.c
@@ -1187,7 +1187,7 @@ lnet_ipaddr_enumerate(__u32 **ipaddrsp)
int
lnet_parse_ip2nets(char **networksp, char *ip2nets)
{
- __u32 *ipaddrs;
+ __u32 *ipaddrs = NULL;
int nip = lnet_ipaddr_enumerate(&ipaddrs);
int rc;
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
hyperv_keyboard invokes serio_interrupt(), which needs a valid serio driver like atkbd.c. atkbd.c depends on libps2.c because it invokes ps2_command(). libps2.c depends on i8042.c because it invokes i8042_check_port_owner(). As a result, hyperv_keyboard actually depends on i8042.c. For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m rather than =y, atkbd.ko can't load because i8042.ko can't load(due to no i8042 device emulated) and finally hyperv_keyboard can't work and the user can't input: https://bugs.archlinux.org/task/39820 (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y) Decoupling the dependency between hyperv_keyboard and i8042 needs non-trivial efforts and is hence a long term goal. For now, let's make the dependency explicit so people can beware of this. Thank Claudio for the initial reporting, investigation and suggesting the fix. Signed-off-by: Dexuan Cui Reported-by: Claudio Latini Cc: K. Y. Srinivasan --- drivers/input/serio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index bc2d474..3277bff 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -273,7 +273,7 @@ config SERIO_OLPC_APSP config HYPERV_KEYBOARD tristate "Microsoft Synthetic Keyboard driver" - depends on HYPERV + depends on HYPERV && SERIO_I8042=y default HYPERV help Select this option to enable the Hyper-V Keyboard driver. -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Mon, Aug 11, 2014 at 09:44:47PM -0400, Oleg Drokin wrote: > > On Aug 9, 2014, at 11:47 AM, Greg Kroah-Hartman wrote: > > > On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote: > >> > >>> Because maybe these stats preceed the introduction of perf and other > >>> tracing/debug tools? I don't know, it's really low down on the list of > >>> reasons why lustre can't be merged out of staging at the moment, you all > >>> have much bigger issues to address first. > >> > >> I wonder what is the prioritized list you have in mind? > > > > Do I really have to spell out what is wrong with that codebase that > > needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix > > up a _portion_ of the include file mess that is in there. Now is the > > first time the code actually _builds_ properly in the kernel tree (i.e. > > no magic header file include path modifications in Makefiles preventing > > individual files from being built correctly.) > > Well, last time we discussed this topic, you said that moving most of lustre > proc files > into sysfs and other suitable venues is what prevents moving lustre out of the > staging tree under fs/ Yes, that's one of the big things, but the structure of the code itself still needs lots of work. You have wrapper functions and defines that are not needed. You have version-specific checks and still a quite complex and unnecessary include directory structure. > There well might be include mess, but this is the first time I hear about it, > and I have not seen > any build breakage or other obviously broken behavior. The build breakage came about in a thread on this mailing list when we had a tool that could build an individual .o file, which I found to break on all of the lustre files due to the odd way you were redefining the include search path of the .c files. I unwound all of that to use direct paths and now things build properly. But even then, there are way too many .h files and nested mess that is not needed and is the result of trying to get this code to build on other platforms a long time ago. > I am sure there are more things too, that's why I am asking. > We are trying to deal with stuff we know about, but it's a bit harder > to deal with the stuff we don't know about that does not manifest > itself in some clear way. Try getting rid of the typedefs and wrapper functions and #defines for function names and coding style issues. That would be a great first step and would then expose what really is left to do. Right now, it's just to hard to see the real issues. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u/ieee80211: Fix sparse ieee80211_debug_init/_exit not declared warning
El 11/08/14 a las 17:32, Greg Kroah-Hartman escibió: > On Mon, Aug 11, 2014 at 03:15:54PM -0700, Jeremiah Mahler wrote: >> A sparse warning is generated about 'ieee80211_debug_init' and >> 'ieee80211_debug_exit' not being declared. >> >> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:275:12: warning: >> symbol 'ieee80211_debug_init' was not declared. Should it be static? >> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c:297:13: warning: >> symbol 'ieee80211_debug_exit' was not declared. Should it be static? >> >> These functions are used outside of this file so using static will not >> work. Fix the warning by declaring the functions in the header file, >> ieee80211.h >> >> Signed-off-by: Jeremiah Mahler >> Cc: Greg Kroah-Hartman >> Cc: Teodora Baluta >> Cc: Andrea Merello >> Cc: Joel Pelaez Jorge >> Cc: Bob Copeland >> Cc: Joe Perches >> Cc: Arnd Bergmann >> Cc: Himangi Saraogi >> --- >> drivers/staging/rtl8192u/ieee80211/ieee80211.h | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> b/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> index 1040bab..9cbda69 100644 >> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h >> @@ -2485,6 +2485,12 @@ extern int ieee80211_wx_set_freq(struct >> ieee80211_device *ieee, struct iw_reques >> extern int ieee80211_wx_get_freq(struct ieee80211_device *ieee, struct >> iw_request_info *a, >> union iwreq_data *wrqu, char *b); >> >> +/* ieee80211_module.c */ >> +#ifdef CONFIG_IEEE80211_DEBUG >> +extern int __init ieee80211_debug_init(void); >> +extern void __exit ieee80211_debug_exit(void); >> +#endif /* CONFIG_IEEE80211_DEBUG */ >> + > > As it's a header file, why not always have them here, no need for the > ifdef. > > And __init and __exit don't belong in a .h function prototype. > > thanks, > > greg k-h > The symbol ieee80211_debug_init(void) and ieee80211_debug_exit(void) are declared as prototype in r8192U_core.c, this cause a double function prototype. It is only a comment, it not affect anything. Check it to next time. - Joel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
On Mon, Aug 11, 2014 at 08:30:40PM -0700, Dexuan Cui wrote: > hyperv_keyboard invokes serio_interrupt(), which needs a valid serio driver > like atkbd.c. > atkbd.c depends on libps2.c because it invokes ps2_command(). > libps2.c depends on i8042.c because it invokes i8042_check_port_owner(). > As a result, hyperv_keyboard actually depends on i8042.c. > > For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a Linux > VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m rather than > =y, atkbd.ko can't load because i8042.ko can't load(due to no i8042 device > emulated) and finally hyperv_keyboard can't work and the user can't input: > https://bugs.archlinux.org/task/39820 > (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y) > > Decoupling the dependency between hyperv_keyboard and i8042 needs > non-trivial efforts and is hence a long term goal. > > For now, let's make the dependency explicit so people can beware of this. You didn't make anyone "aware" of this, you just prevented people from being able to select the module unless they build the driver into the kernel, which isn't very nice. What exactly needs to be done to fix this "correctly" that is going to take too much work at the moment? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Decoupling the dependency between hyperv_keyboard and i8042 needs > > non-trivial efforts and is hence a long term goal. > > > > For now, let's make the dependency explicit so people can beware of this. > > You didn't make anyone "aware" of this, you just prevented people from > being able to select the module unless they build the driver into the > kernel, which isn't very nice. Yes, exactly. > What exactly needs to be done to fix this "correctly" that is going to > take too much work at the moment? Hi Greg, The current implementation of hyperv-keyboard.c borrows serio_interrupt() to pass the key strokes to the high level component. serio_interrupt() actually depends on atkbd.c and i8042.c, so this doesn't work for a Generation 2 hyper-v guest because no i8042 keyboard controller is emulated: http://technet.microsoft.com/en-us/library/dn282285.aspx To decouple the dependency between the hyperv-keyboard and i8042 modules, I suppose we probably have to re-implement hyperv-keyboard by using input_allocate_device(), input_register_device(), and using input_report_key() to pass the key strokes to the high level. I'll have to need some time for further investigation and a new implementation. Before the new code is completely ready, IMHO the patch can help to avoid a bad user experience like Arch Linux working as a Generation 2 hyper-v guest. BTW, looks most of Linux distros (like RHEL, Ubuntu, SUSE) have CONFIG_SERIO_I8042=y, probably because it's the result of "make defconfig". So the patch actually doesn't affect these distros. Thanks, -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
On Tue, Aug 12, 2014 at 05:51:28AM +, Dexuan Cui wrote: > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > Decoupling the dependency between hyperv_keyboard and i8042 needs > > > non-trivial efforts and is hence a long term goal. > > > > > > For now, let's make the dependency explicit so people can beware of this. > > > > You didn't make anyone "aware" of this, you just prevented people from > > being able to select the module unless they build the driver into the > > kernel, which isn't very nice. > > Yes, exactly. > > > What exactly needs to be done to fix this "correctly" that is going to > > take too much work at the moment? > Hi Greg, > The current implementation of hyperv-keyboard.c borrows > serio_interrupt() to pass the key strokes to the high level component. > serio_interrupt() actually depends on atkbd.c and i8042.c, so this doesn't > work for a Generation 2 hyper-v guest because no i8042 keyboard controller > is emulated: http://technet.microsoft.com/en-us/library/dn282285.aspx > > To decouple the dependency between the hyperv-keyboard and i8042 > modules, I suppose we probably have to re-implement hyperv-keyboard by > using input_allocate_device(), input_register_device(), and using > input_report_key() to pass the key strokes to the high level. Yes, that would be the best thing to do, and shouldn't be that hard to create an input driver, it's pretty simple code, right? > I'll have to need some time for further investigation and a new > implementation. Before the new code is completely ready, IMHO the > patch can help to avoid a bad user experience like Arch Linux working > as a Generation 2 hyper-v guest. You are still preventing Arch from working here, as the driver can't be built at all, right? > BTW, looks most of Linux distros (like RHEL, Ubuntu, SUSE) have > CONFIG_SERIO_I8042=y, probably because it's the result of > "make defconfig". So the patch actually doesn't affect these distros. Or maybe it is beause they use older kernels and like to turn on every single possible option :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/7] staging: dgnc: Fix externs should be avoided in the .c files
This commit fixes the following checkpatch warnings:
WARNING: externs should be avoided in .c files
#80: FILE: drivers/staging/dgnc/dgnc_driver.c:80:
+intdgnc_init_module(void);
#81: FILE: drivers/staging/dgnc/dgnc_driver.c:81:
+void dgnc_cleanup_module(void);
This was caused by putting the declarations for module init and module
exit fucntions on the top of the file. The fix removes these
declarations plus it also corrects the type of the init/exit functions.
Due to the dependency between init and exit functions the
dgnc_cleanup_module had to be put first.
Signed-off-by: Konrad Zapalowicz
---
v2:
- remove the __exit annotation for the cleanup function as it caused
the test-bot unhappy.
drivers/staging/dgnc/dgnc_driver.c | 84 ++
1 file changed, 39 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 764613b..2c2abf8 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -76,12 +76,6 @@ static void dgnc_remove_one(struct pci_dev *dev);
static int dgnc_probe1(struct pci_dev *pdev, int card_type);
static voiddgnc_do_remap(struct dgnc_board *brd);
-/* Driver load/unload functions */
-intdgnc_init_module(void);
-void dgnc_cleanup_module(void);
-
-module_init(dgnc_init_module);
-module_exit(dgnc_cleanup_module);
/*
@@ -199,13 +193,49 @@ char *dgnc_driver_state_text[] = {
*
/
+/*
+ * dgnc_cleanup_module()
+ *
+ * Module unload. This is where it all ends.
+ */
+static void dgnc_cleanup_module(void)
+{
+ int i;
+ ulong lock_flags;
+
+ DGNC_LOCK(dgnc_poll_lock, lock_flags);
+ dgnc_poll_stop = 1;
+ DGNC_UNLOCK(dgnc_poll_lock, lock_flags);
+
+ /* Turn off poller right away. */
+ del_timer_sync(&dgnc_poll_timer);
+
+ dgnc_remove_driver_sysfiles(&dgnc_driver);
+
+ if (dgnc_Major_Control_Registered) {
+ device_destroy(dgnc_class, MKDEV(dgnc_Major, 0));
+ class_destroy(dgnc_class);
+ unregister_chrdev(dgnc_Major, "dgnc");
+ }
+
+ for (i = 0; i < dgnc_NumBoards; ++i) {
+ dgnc_remove_ports_sysfiles(dgnc_Board[i]);
+ dgnc_tty_uninit(dgnc_Board[i]);
+ dgnc_cleanup_board(dgnc_Board[i]);
+ }
+
+ dgnc_tty_post_uninit();
+
+ if (dgnc_NumBoards)
+ pci_unregister_driver(&dgnc_driver);
+}
/*
* init_module()
*
* Module load. This is where it all starts.
*/
-int dgnc_init_module(void)
+static int __init dgnc_init_module(void)
{
int rc = 0;
@@ -243,6 +273,8 @@ int dgnc_init_module(void)
return rc;
}
+module_init(dgnc_init_module);
+module_exit(dgnc_cleanup_module);
/*
* Start of driver.
@@ -355,44 +387,6 @@ static void dgnc_remove_one(struct pci_dev *dev)
}
/*
- * dgnc_cleanup_module()
- *
- * Module unload. This is where it all ends.
- */
-void dgnc_cleanup_module(void)
-{
- int i;
- ulong lock_flags;
-
- DGNC_LOCK(dgnc_poll_lock, lock_flags);
- dgnc_poll_stop = 1;
- DGNC_UNLOCK(dgnc_poll_lock, lock_flags);
-
- /* Turn off poller right away. */
- del_timer_sync(&dgnc_poll_timer);
-
- dgnc_remove_driver_sysfiles(&dgnc_driver);
-
- if (dgnc_Major_Control_Registered) {
- device_destroy(dgnc_class, MKDEV(dgnc_Major, 0));
- class_destroy(dgnc_class);
- unregister_chrdev(dgnc_Major, "dgnc");
- }
-
- for (i = 0; i < dgnc_NumBoards; ++i) {
- dgnc_remove_ports_sysfiles(dgnc_Board[i]);
- dgnc_tty_uninit(dgnc_Board[i]);
- dgnc_cleanup_board(dgnc_Board[i]);
- }
-
- dgnc_tty_post_uninit();
-
- if (dgnc_NumBoards)
- pci_unregister_driver(&dgnc_driver);
-}
-
-
-/*
* dgnc_cleanup_board()
*
* Free all the memory associated with a board
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/7 V2] staging: dgap: remove useless variable
dgap_major_serial_registered and dgap_major_transparent_print_registered
could be checked whether a board is initialized.
But it doesn't need to check that variables becasue dgap_board
as global is managed for boards which are initialized completely.
So when it called dgap_cleanup_tty() function, various allocated
variables in a board will free properly.
Signed-off-by: Daeseok Youn
---
V2: update change log.
drivers/staging/dgap/dgap.c | 48 +-
drivers/staging/dgap/dgap.h |3 --
2 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index ac12e99..55c06c9 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -1320,11 +1320,9 @@ static int dgap_tty_register(struct board_t *brd)
if (rc < 0)
goto unregister_serial_drv;
- brd->dgap_major_serial_registered = TRUE;
dgap_boards_by_major[brd->serial_driver->major] = brd;
brd->dgap_serial_major = brd->serial_driver->major;
- brd->dgap_major_transparent_print_registered = TRUE;
dgap_boards_by_major[brd->print_driver->major] = brd;
brd->dgap_transparent_print_major = brd->print_driver->major;
@@ -1544,35 +1542,29 @@ static void dgap_cleanup_tty(struct board_t *brd)
struct device *dev;
int i;
- if (brd->dgap_major_serial_registered) {
- dgap_boards_by_major[brd->serial_driver->major] = NULL;
- brd->dgap_serial_major = 0;
- for (i = 0; i < brd->nasync; i++) {
- tty_port_destroy(&brd->serial_ports[i]);
- dev = brd->channels[i]->ch_tun.un_sysfs;
- dgap_remove_tty_sysfs(dev);
- tty_unregister_device(brd->serial_driver, i);
- }
- tty_unregister_driver(brd->serial_driver);
- put_tty_driver(brd->serial_driver);
- kfree(brd->serial_ports);
- brd->dgap_major_serial_registered = FALSE;
- }
-
- if (brd->dgap_major_transparent_print_registered) {
- dgap_boards_by_major[brd->print_driver->major] = NULL;
- brd->dgap_transparent_print_major = 0;
- for (i = 0; i < brd->nasync; i++) {
- tty_port_destroy(&brd->printer_ports[i]);
- dev = brd->channels[i]->ch_pun.un_sysfs;
- dgap_remove_tty_sysfs(dev);
- tty_unregister_device(brd->print_driver, i);
- }
- tty_unregister_driver(brd->print_driver);
- put_tty_driver(brd->print_driver);
- kfree(brd->printer_ports);
- brd->dgap_major_transparent_print_registered = FALSE;
+ dgap_boards_by_major[brd->serial_driver->major] = NULL;
+ brd->dgap_serial_major = 0;
+ for (i = 0; i < brd->nasync; i++) {
+ tty_port_destroy(&brd->serial_ports[i]);
+ dev = brd->channels[i]->ch_tun.un_sysfs;
+ dgap_remove_tty_sysfs(dev);
+ tty_unregister_device(brd->serial_driver, i);
+ }
+ tty_unregister_driver(brd->serial_driver);
+ put_tty_driver(brd->serial_driver);
+ kfree(brd->serial_ports);
+
+ dgap_boards_by_major[brd->print_driver->major] = NULL;
+ brd->dgap_transparent_print_major = 0;
+ for (i = 0; i < brd->nasync; i++) {
+ tty_port_destroy(&brd->printer_ports[i]);
+ dev = brd->channels[i]->ch_pun.un_sysfs;
+ dgap_remove_tty_sysfs(dev);
+ tty_unregister_device(brd->print_driver, i);
}
+ tty_unregister_driver(brd->print_driver);
+ put_tty_driver(brd->print_driver);
+ kfree(brd->printer_ports);
}
/*===
diff --git a/drivers/staging/dgap/dgap.h b/drivers/staging/dgap/dgap.h
index 9728d59..0482a4c 100644
--- a/drivers/staging/dgap/dgap.h
+++ b/drivers/staging/dgap/dgap.h
@@ -586,9 +586,6 @@ struct board_t {
struct tty_port *printer_ports;
charprint_name[200];
- u32 dgap_major_serial_registered;
- u32 dgap_major_transparent_print_registered;
-
u32 dgap_serial_major;
u32 dgap_transparent_print_major;
--
1.7.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: speakup: Insert blank lines after declarations in speakup_soft.c
On Mon, 11 Aug 2014, Greg KH wrote: On Sun, Aug 10, 2014 at 10:56:38PM +1000, Artemiy Volkov wrote: On Sat, 9 Aug 2014, Greg KH wrote: On Thu, Aug 07, 2014 at 01:21:25PM +1000, Artemiy Volkov wrote: This patch fixes the checkpatch.pl 'Missing a blank line after declarations' warning in speakup_soft.c. Signed-off-by: Artemiy Volkov --- drivers/staging/speakup/speakup_soft.c | 3 +++ 1 file changed, 3 insertions(+) Can you refresh this against Linus's latest tree (or linux-next), it has a bunch of fuzz in it as it is. Hi, I'm sorry but I'm having a hard time understanding this -- since no changes have been made to this part of the tree (drivers/staging/speakup/) since Jul 17, the patch which I tried to generate against today's linux-next following your recommendation is identical to the sent v2. What might I be doing wrong here? I don't know, it didn't apply properly, which is odd. How about making it against Linus's tree right now, as it has all of my changes in it now, so we are synced up. After cloning Linus's tree and am-ing v2 on top of it, the result stands the same -- clean application... Could you have possibly already applied it, maybe? If not, I have little idea what to do from here, might as well drop the whole thing... Thanks, Artemiy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
