Business Proposal
Good day! I have a mutual business proposal of mutual interest to share with you, it involves the transfer of a large sum of money I got your reference in my search for someone who suits my business proposed. If you are interested in working with me contact me through my private email(p.won...@yahoo.com.hk)for further details, your earliest response to this letter will be appreciated. Best Regards, Peter Wong ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] driver core: export lock_device_hotplug/unlock_device_hotplug
On Wednesday, February 11, 2015 12:39:47 PM Andrew Morton wrote:
> On Wed, 11 Feb 2015 16:44:20 +0100 Vitaly Kuznetsov
> wrote:
>
> > add_memory() is supposed to be run with device_hotplug_lock grabbed,
> > otherwise
> > it can race with e.g. device_online(). Allow external modules (hv_balloon
> > for
> > now) to lock device hotplug.
> >
> > ...
> >
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -55,11 +55,13 @@ void lock_device_hotplug(void)
> > {
> > mutex_lock(&device_hotplug_lock);
> > }
> > +EXPORT_SYMBOL_GPL(lock_device_hotplug);
> >
> > void unlock_device_hotplug(void)
> > {
> > mutex_unlock(&device_hotplug_lock);
> > }
> > +EXPORT_SYMBOL_GPL(unlock_device_hotplug);
> >
> > int lock_device_hotplug_sysfs(void)
> > {
>
> It's kinda crazy that lock_device_hotplug_sysfs() didn't get any
> documentation. I suggest adding this while you're in there:
>
>
> --- a/drivers/base/core.c~a
> +++ a/drivers/base/core.c
> @@ -61,6 +61,9 @@ void unlock_device_hotplug(void)
> mutex_unlock(&device_hotplug_lock);
> }
>
> +/*
> + * "git show 5e33bc4165f3ed" for details
> + */
> int lock_device_hotplug_sysfs(void)
> {
> if (mutex_trylock(&device_hotplug_lock))
>
> which is a bit lazy but whatev.
>
> I'll assume that Greg (or Rafael?) will be processing this patchset.
Well, I would do that if I saw it (my address in the CC has been deprecated
for several months now).
Vitaly, can you please resend with a CC to a valid address of mine, please?
Rafael
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Thu, 2015-02-12 at 01:43 +0300, Dan Carpenter wrote: > On Wed, Feb 11, 2015 at 12:43:03PM -0800, Joe Perches wrote: > > Maybe some help/warning text like: > > > > --forceWithout --force, checkpatch will not scan files > > using -f or --file outside of > > drivers/staging/... > > Do not use this option merely to create > > potential > > patches that are uncompiled or untested. > > Everyone compiles their patches hopefully? Maybe they're simply hopeful their patches compile. Many checkpatch users seem unaware their patches need to compile though. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
Am 11.02.2015 um 23:43 schrieb Dan Carpenter: > On Wed, Feb 11, 2015 at 12:43:03PM -0800, Joe Perches wrote: >> Maybe some help/warning text like: >> >> --forceWithout --force, checkpatch will not scan files >> using -f or --file outside of >> drivers/staging/... >> Do not use this option merely to create >> potential >> patches that are uncompiled or untested. > > Everyone compiles their patches hopefully? The problem is with patches > that aren't really a cleanup but are just done to make checkpatch happy. > > I guess documenting --force is better than not documenting. Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Wed, Feb 11, 2015 at 12:43:03PM -0800, Joe Perches wrote: > Maybe some help/warning text like: > > --forceWithout --force, checkpatch will not scan files > using -f or --file outside of drivers/staging/... > Do not use this option merely to create potential > patches that are uncompiled or untested. Everyone compiles their patches hopefully? The problem is with patches that aren't really a cleanup but are just done to make checkpatch happy. I guess documenting --force is better than not documenting. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 20/20] arm: mach-pxa: Decrement the power supply's device reference counter
On Mon 2015-02-09 11:07:12, Krzysztof Kozlowski wrote: > On pią, 2015-02-06 at 15:59 +0100, Pavel Machek wrote: > > On Fri 2015-02-06 15:43:08, Krzysztof Kozlowski wrote: > > > On pią, 2015-02-06 at 14:49 +0100, Pavel Machek wrote: > > > > On Fri 2015-01-30 15:47:58, Krzysztof Kozlowski wrote: > > > > > Use power_supply_put() to decrement the power supply's device > > > > > reference > > > > > counter. > > > > > > > > > > Signed-off-by: Krzysztof Kozlowski > > > > > Reviewed-by: Bartlomiej Zolnierkiewicz > > > > > Reviewed-by: Sebastian Reichel > > > > > > > > 11,13,20 nothing obviously wrong. But I'm not sure if I studied them > > > > closely enough to warrant an ACK. > > > > > > > > It would be good to get this into kernel -- I seen no bad comments, > > > > and it is not going to improve without merge into mainline. > > > > > > Thanks for looking at patchset. It would be really nice if this could be > > > tested for some time in linux-next. Such testing would help a lot. But I > > > need acks from various maintainers for that. > > > > Actually, you don't. The various maintainers clearly don't care at > > this point. They had enough time. So you select one maintainer you > > want to push this through, and you push it. > > > > Someone may complain, so you'll solve the feedback... > > I am thinking also on another way of solving this huge-patch problem: > 1. Mark all drivers broken (CONFIG_BROKEN). > 2. Introduce change in power_supply_register() API. Broken drivers >will fail to build. > 3. Convert broken drivers to new API incrementally (one driver >per patch) marking them also non-broken. > > This would be much easier to review but also this would break > build-bisectability for drivers and some platforms using them (like > OLPC, compal-laptop, ACPI). It is easy enough to review as it is, playing with CONFIG_BROKEN will not improve it. Just push the patch... > I pushed the patchset here: > https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-next-power-supply-core-ownership > (actually this is v4: added acks/reviews and minor issue fixed; merge > window has opened so I'll wait with sending this to LKML). Great... now you just need one of maintainers to merge it... POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS M: Sebastian Reichel M: Dmitry Eremin-Solenikov M: David Woodhouse Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv3 2/2] ft1000-pcmcia: ft1000_hw.c: code refactoring: add ft1000_read_dsp_timer()
Add new function ft1000_read_dsp_timer() replacing recurring code block for
reading DSP timer. Such code refactoring solves all remaining "line over 80
characters" warnings reported by checkpatch.pl.
Signed-off-by: Daniele Alessandrelli
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 199 +--
1 file changed, 41 insertions(+), 158 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 23b27f8..a1f7a97 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -303,6 +303,41 @@ static void ft1000_disable_interrupts(struct net_device
*dev)
}
/*---
+ Function:ft1000_read_dsp_timer
+ Description: This function reads the DSP timer and stores its value in the
+ DSP_TIME field of the ft1000_info struct passed as argument
+ Input:
+ dev- device structure
+ info - ft1000_info structure
+ Output:
+ None.
+
+ -*/
+static void ft1000_read_dsp_timer(struct net_device *dev,
+ struct ft1000_info *info)
+{
+ if (info->AsicID == ELECTRABUZZ_ID) {
+ info->DSP_TIME[0] = ft1000_read_dpram(dev, FT1000_DSP_TIMER0);
+ info->DSP_TIME[1] = ft1000_read_dpram(dev, FT1000_DSP_TIMER1);
+ info->DSP_TIME[2] = ft1000_read_dpram(dev, FT1000_DSP_TIMER2);
+ info->DSP_TIME[3] = ft1000_read_dpram(dev, FT1000_DSP_TIMER3);
+ } else {
+ info->DSP_TIME[0] =
+ ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER0,
+FT1000_MAG_DSP_TIMER0_INDX);
+ info->DSP_TIME[1] =
+ ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER1,
+FT1000_MAG_DSP_TIMER1_INDX);
+ info->DSP_TIME[2] =
+ ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER2,
+FT1000_MAG_DSP_TIMER2_INDX);
+ info->DSP_TIME[3] =
+ ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER3,
+FT1000_MAG_DSP_TIMER3_INDX);
+ }
+}
+
+/*---
Function: ft1000_reset_asic
Description: This function will call the Card Service function to reset the
@@ -580,33 +615,7 @@ static void ft1000_hbchk(u_long data)
}
if (tempword != ho) {
pr_info("heartbeat failed - no ho detected\n");
- if (info->AsicID == ELECTRABUZZ_ID) {
- info->DSP_TIME[0] =
- ft1000_read_dpram(dev,
FT1000_DSP_TIMER0);
- info->DSP_TIME[1] =
- ft1000_read_dpram(dev,
FT1000_DSP_TIMER1);
- info->DSP_TIME[2] =
- ft1000_read_dpram(dev,
FT1000_DSP_TIMER2);
- info->DSP_TIME[3] =
- ft1000_read_dpram(dev,
FT1000_DSP_TIMER3);
- } else {
- info->DSP_TIME[0] =
- ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER0,
-
FT1000_MAG_DSP_TIMER0_INDX);
- info->DSP_TIME[1] =
- ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER1,
-
FT1000_MAG_DSP_TIMER1_INDX);
- info->DSP_TIME[2] =
- ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER2,
-
FT1000_MAG_DSP_TIMER2_INDX);
- info->DSP_TIME[3] =
- ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER3,
-
FT1000_MAG_DSP_TIMER3_INDX);
- }
+ ft1000_read_dsp_timer(dev, info);
info->DrvErrNum = DSP_HB_INFO;
if (ft1000_reset_card(dev) == 0) {
pr_info("Hardware Failure Detected - PC Card
disabled\n");
@@ -627,33 +636,7 @@ s
[PATCHv3 0/2] staging: ft1000-pcmcia: ft1000_hw.c: fix checkpatch warnings
This small patchset fixes all the style problems reported by checkpatch.pl on ft1000-pcmcia/ft1000_hw.c * Patch 1/2 fixes all trivial issues not requiring code refactoring * Patch 2/2 fixes all remaining "line over 80 characters" warnings by means of some code refactoring. Specifically, the function ft1000_read_dsp_timer() is introduced to replace a recurring block of code used for reading the DSP timer value. This updated version of the patchset should apply cleanly to Greg's Tree. Daniele Alessandrelli (2): ft1000-pcmcia: ft1000_hw.c: fix style issues not requiring code refactoring ft1000-pcmcia: ft1000_hw.c: code refactoring: add ft1000_read_dsp_timer() drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 596 ++- 1 file changed, 249 insertions(+), 347 deletions(-) -- 1.8.3.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv3 1/2] ft1000-pcmcia: ft1000_hw.c: fix style issues not requiring code refactoring
Fix all the trivial style issues (as reported by checkpatch.pl) not requiring
code refactoring. A following patch is expected to fix the remaining issues by
performing some code refactoring.
Signed-off-by: Daniele Alessandrelli
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 455 ---
1 file changed, 237 insertions(+), 218 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 017c3b9..23b27f8 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -28,8 +28,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#include
@@ -67,8 +67,7 @@ static void ft1000_disable_interrupts(struct net_device *dev);
/* new kernel */
MODULE_AUTHOR("");
-MODULE_DESCRIPTION
-("Support for Flarion Flash OFDM NIC Device. Support for PCMCIA when used with
ft1000_cs.");
+MODULE_DESCRIPTION("Support for Flarion Flash OFDM NIC Device. Support for
PCMCIA when used with ft1000_cs.");
MODULE_LICENSE("GPL");
MODULE_SUPPORTED_DEVICE("FT1000");
@@ -267,7 +266,8 @@ void ft1000_write_dpram_mag_32(struct net_device *dev, int
offset, u32 value)
/*---
Function: ft1000_enable_interrupts
- Description: This function will enable interrupts base on the current
interrupt mask.
+ Description: This function will enable interrupts base on the current
+ interrupt mask.
Input:
dev- device structure
Output:
@@ -375,7 +375,8 @@ static int ft1000_reset_card(struct net_device *dev)
/* Make sure we free any memory reserve for provisioning */
while (list_empty(&info->prov_list) == 0) {
pr_debug("deleting provisioning record\n");
- ptr = list_entry(info->prov_list.next, struct prov_record,
list);
+ ptr = list_entry(info->prov_list.next, struct prov_record,
+list);
list_del(&ptr->list);
kfree(ptr->pprov_data);
kfree(ptr);
@@ -406,7 +407,8 @@ static int ft1000_reset_card(struct net_device *dev)
FT1000_DPRAM_MAG_RX_BASE);
for (i = 0; i < MAX_DSP_SESS_REC / 2; i++) {
info->DSPSess.MagRec[i] =
- inl(dev->base_addr +
FT1000_REG_MAG_DPDATA);
+ inl(dev->base_addr
+ + FT1000_REG_MAG_DPDATA);
}
}
spin_unlock_irqrestore(&info->dpram_lock, flags);
@@ -435,11 +437,12 @@ static int ft1000_reset_card(struct net_device *dev)
mdelay(10);
pr_debug("Take DSP out of reset\n");
- /* Wait for 0xfefe indicating dsp ready before starting
download */
+ /* Wait for 0xfefe indicating dsp ready before starting
+* download */
for (i = 0; i < 50; i++) {
- tempword =
- ft1000_read_dpram_mag_16(dev,
FT1000_MAG_DPRAM_FEFE,
-
FT1000_MAG_DPRAM_FEFE_INDX);
+ tempword = ft1000_read_dpram_mag_16(dev,
+ FT1000_MAG_DPRAM_FEFE,
+ FT1000_MAG_DPRAM_FEFE_INDX);
if (tempword == 0xfefe)
break;
mdelay(20);
@@ -459,16 +462,15 @@ static int ft1000_reset_card(struct net_device *dev)
if (card_download(dev, fw_entry->data, fw_entry->size)) {
pr_debug("card download unsuccessful\n");
return false;
- } else {
- pr_debug("card download successful\n");
}
+ pr_debug("card download successful\n");
mdelay(10);
if (info->AsicID == ELECTRABUZZ_ID) {
/*
-* Need to initialize the FIFO length counter to zero in order
to sync up
-* with the DSP
+* Need to initialize the FIFO length counter to zero in order
+* to sync up with the DSP
*/
info->fifo_cnt = 0;
ft1000_write_dpram(dev, FT1000_FIFO_LEN, info->fifo_cnt);
@@ -665,8 +667,8 @@ static void ft1000_hbchk(u_long data)
return;
}
/*
-* Set dedicated area to hi and ring appropriate doorbell
according
-* to hi/ho heartbeat protocol
+* Set dedicated area to hi and ring appropriate doorbell
+* according to hi/ho heartbeat protocol
*/
if (info->AsicID == ELECTRABUZZ_ID) {
Re: checkpatch induced patches...
On Wed, 2015-02-11 at 21:24 +0100, Pavel Machek wrote: > On Wed 2015-02-11 12:20:25, Joe Perches wrote: > > On Wed, 2015-02-11 at 21:02 +0100, Richard Weinberger wrote: > > > On Wed, Feb 11, 2015 at 7:36 PM, Dan Carpenter > > > wrote: > > > > On Wed, Feb 11, 2015 at 10:00:29AM -0800, Joe Perches wrote: > > > >> I'm half tempted to submit some patch like this to > > > >> make it difficult to use checkpatch on files outside > > > >> of drivers/staging. > > > >> o Only allow checkpatch to be used with the -f/--file > > > >> option for drivers/staging/ > > > >> o Add an undocumented --force command line option > > > > Sure. We could try that. I once sent a patch to make -f generate a > > > > warning about not wasting people's time, but this is also ok. > > > >> o Make --strict the default for drivers/staging [] > > > FYI: We had already a heated debate on that topic. > > > https://lkml.org/lkml/2014/7/17/415 [] > > This is basically a patch that implements my suggestion > > in that thread. > > https://lkml.org/lkml/2014/7/17/427 > > > > I wonder if the undocumented --force option is acceptable > > to Pavel and Kalle. > Undocumented options are evil... You can add warning about not wasting > people's time in --force documentation... Yeah, I had added --force to the help text then removed it before sending, so I suppose adding a warning there is OK too. Nobody reads the --help text anyway. Dan/Andrew/Greg? You got a preference? Maybe some help/warning text like: --forceWithout --force, checkpatch will not scan files using -f or --file outside of drivers/staging/... Do not use this option merely to create potential patches that are uncompiled or untested. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] driver core: export lock_device_hotplug/unlock_device_hotplug
On Wed, 11 Feb 2015 16:44:20 +0100 Vitaly Kuznetsov wrote:
> add_memory() is supposed to be run with device_hotplug_lock grabbed, otherwise
> it can race with e.g. device_online(). Allow external modules (hv_balloon for
> now) to lock device hotplug.
>
> ...
>
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -55,11 +55,13 @@ void lock_device_hotplug(void)
> {
> mutex_lock(&device_hotplug_lock);
> }
> +EXPORT_SYMBOL_GPL(lock_device_hotplug);
>
> void unlock_device_hotplug(void)
> {
> mutex_unlock(&device_hotplug_lock);
> }
> +EXPORT_SYMBOL_GPL(unlock_device_hotplug);
>
> int lock_device_hotplug_sysfs(void)
> {
It's kinda crazy that lock_device_hotplug_sysfs() didn't get any
documentation. I suggest adding this while you're in there:
--- a/drivers/base/core.c~a
+++ a/drivers/base/core.c
@@ -61,6 +61,9 @@ void unlock_device_hotplug(void)
mutex_unlock(&device_hotplug_lock);
}
+/*
+ * "git show 5e33bc4165f3ed" for details
+ */
int lock_device_hotplug_sysfs(void)
{
if (mutex_trylock(&device_hotplug_lock))
which is a bit lazy but whatev.
I'll assume that Greg (or Rafael?) will be processing this patchset.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: slicoss: slicoss: Removed variables that is never used
On Sat, Jan 31, 2015 at 7:13 AM, Rickard Strandqvist
wrote:
> Variable was assigned a value that was never used.
> I have also removed all the code that thereby serves no purpose.
>
> This was found using a static code analysis program called cppcheck
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/staging/slicoss/slicoss.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/slicoss/slicoss.c
> b/drivers/staging/slicoss/slicoss.c
> index 42d62ef..41b3687 100644
> --- a/drivers/staging/slicoss/slicoss.c
> +++ b/drivers/staging/slicoss/slicoss.c
> @@ -1395,14 +1395,11 @@ static void slic_cmdq_reset(struct adapter *adapter)
> {
> struct slic_hostcmd *hcmd;
> struct sk_buff *skb;
> - u32 outstanding;
>
> spin_lock_irqsave(&adapter->cmdq_free.lock.lock,
> adapter->cmdq_free.lock.flags);
> spin_lock_irqsave(&adapter->cmdq_done.lock.lock,
> adapter->cmdq_done.lock.flags);
> - outstanding = adapter->cmdq_all.count - adapter->cmdq_done.count;
> - outstanding -= adapter->cmdq_free.count;
> hcmd = adapter->cmdq_all.head;
> while (hcmd) {
> if (hcmd->busy) {
> @@ -1728,7 +1725,6 @@ static u32 slic_rcvqueue_reinsert(struct adapter
> *adapter, struct sk_buff *skb)
> */
> static void slic_link_event_handler(struct adapter *adapter)
> {
> - int status;
> struct slic_shmem *pshmem;
>
> if (adapter->state != ADAPT_UP) {
> @@ -1739,13 +1735,13 @@ static void slic_link_event_handler(struct adapter
> *adapter)
> pshmem = (struct slic_shmem *)(unsigned long)adapter->phys_shmem;
>
> #if BITS_PER_LONG == 64
> - status = slic_upr_request(adapter,
> + slic_upr_request(adapter,
> SLIC_UPR_RLSR,
> SLIC_GET_ADDR_LOW(&pshmem->linkstatus),
> SLIC_GET_ADDR_HIGH(&pshmem->linkstatus),
> 0, 0);
> #else
> - status = slic_upr_request(adapter, SLIC_UPR_RLSR,
> + slic_upr_request(adapter, SLIC_UPR_RLSR,
> (u32) &pshmem->linkstatus, /* no 4GB wrap guaranteed */
>
I imagine the request status should be handled, not ignored. So deleting
'status' seems like a step in the wrong direction.
0, 0, 0);
> #endif
> @@ -2087,8 +2083,6 @@ static void slic_interrupt_card_up(u32 isr, struct
> adapter *adapter,
> adapter->error_interrupts++;
> if (isr & ISR_RMISS) {
> int count;
> - int pre_count;
> - int errors;
>
> struct slic_rcvqueue *rcvq =
> &adapter->rcvqueue;
> @@ -2097,8 +2091,6 @@ static void slic_interrupt_card_up(u32 isr, struct
> adapter *adapter,
>
> if (!rcvq->errors)
> rcv_count = rcvq->count;
> - pre_count = rcvq->count;
> - errors = rcvq->errors;
>
> while (rcvq->count < SLIC_RCVQ_FILLTHRESH) {
> count = slic_rcvqueue_fill(adapter);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Wed, 2015-02-11 at 21:02 +0100, Richard Weinberger wrote: > On Wed, Feb 11, 2015 at 7:36 PM, Dan Carpenter > wrote: > > On Wed, Feb 11, 2015 at 10:00:29AM -0800, Joe Perches wrote: > >> I'm half tempted to submit some patch like this to > >> make it difficult to use checkpatch on files outside > >> of drivers/staging. > >> > >> o Only allow checkpatch to be used with the -f/--file > >> option for drivers/staging/ > >> o Add an undocumented --force command line option > > > > Sure. We could try that. I once sent a patch to make -f generate a > > warning about not wasting people's time, but this is also ok. > > > >> o Make --strict the default for drivers/staging > > > > Ack. > > FYI: We had already a heated debate on that topic. > https://lkml.org/lkml/2014/7/17/415 Yeah, I remember. It's always a pleasure to chat with Borislav. This is basically a patch that implements my suggestion in that thread. https://lkml.org/lkml/2014/7/17/427 I wonder if the undocumented --force option is acceptable to Pavel and Kalle. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Wed 2015-02-11 12:20:25, Joe Perches wrote: > On Wed, 2015-02-11 at 21:02 +0100, Richard Weinberger wrote: > > On Wed, Feb 11, 2015 at 7:36 PM, Dan Carpenter > > wrote: > > > On Wed, Feb 11, 2015 at 10:00:29AM -0800, Joe Perches wrote: > > >> I'm half tempted to submit some patch like this to > > >> make it difficult to use checkpatch on files outside > > >> of drivers/staging. > > >> > > >> o Only allow checkpatch to be used with the -f/--file > > >> option for drivers/staging/ > > >> o Add an undocumented --force command line option > > > > > > Sure. We could try that. I once sent a patch to make -f generate a > > > warning about not wasting people's time, but this is also ok. > > > > > >> o Make --strict the default for drivers/staging > > > > > > Ack. > > > > FYI: We had already a heated debate on that topic. > > https://lkml.org/lkml/2014/7/17/415 > > Yeah, I remember. > > It's always a pleasure to chat with Borislav. > > This is basically a patch that implements my suggestion > in that thread. > > https://lkml.org/lkml/2014/7/17/427 > > I wonder if the undocumented --force option is acceptable > to Pavel and Kalle. Undocumented options are evil... You can add warning about not wasting people's time in --force documentation... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Wed, Feb 11, 2015 at 7:36 PM, Dan Carpenter wrote: > On Wed, Feb 11, 2015 at 10:00:29AM -0800, Joe Perches wrote: >> I'm half tempted to submit some patch like this to >> make it difficult to use checkpatch on files outside >> of drivers/staging. >> >> o Only allow checkpatch to be used with the -f/--file >> option for drivers/staging/ >> o Add an undocumented --force command line option > > Sure. We could try that. I once sent a patch to make -f generate a > warning about not wasting people's time, but this is also ok. > >> o Make --strict the default for drivers/staging > > Ack. FYI: We had already a heated debate on that topic. https://lkml.org/lkml/2014/7/17/415 -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Fix possible leak in vnt_download_firmware()
When failing to allocate buffer memory, function vnt_download_firmware() goes
through the wrong exit path and fails to release the already requested
firmware. Thus use the correct cleanup. Detected by Coverity CID 1269128.
Signed-off-by: Christian Engelmayer
---
Compile tested only. Applies against branch staging-next.
---
drivers/staging/vt6656/firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/firmware.c
b/drivers/staging/vt6656/firmware.c
index a177645af83e..d440f284bf18 100644
--- a/drivers/staging/vt6656/firmware.c
+++ b/drivers/staging/vt6656/firmware.c
@@ -61,7 +61,7 @@ int vnt_download_firmware(struct vnt_private *priv)
buffer = kmalloc(FIRMWARE_CHUNK_SIZE, GFP_KERNEL);
if (!buffer)
- goto out;
+ goto free_fw;
for (ii = 0; ii < fw->size; ii += FIRMWARE_CHUNK_SIZE) {
length = min_t(int, fw->size - ii, FIRMWARE_CHUNK_SIZE);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Fwd:Что всё-таки подарить? = презент любимой подруге к 14 февраля
Что всё-таки подарить? = Клевый знак внимания к 14 февраля = http://www.google.com/url?q=htt%70%3A%2F%2Fvp%6f%64aro%6b.l%75%62i%6d%6f%79.%63%636%39%2er%75%2F%23at%6c%73%63%61zy0%6fk%7a%6c%71%66&sa=D&sntz=1&usg=AFQjCNGaBtr4u73mMq3TaQAGXIlyg8roFw ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Wed, Feb 11, 2015 at 10:00:29AM -0800, Joe Perches wrote: > I'm half tempted to submit some patch like this to > make it difficult to use checkpatch on files outside > of drivers/staging. > > o Only allow checkpatch to be used with the -f/--file > option for drivers/staging/ > o Add an undocumented --force command line option Sure. We could try that. I once sent a patch to make -f generate a warning about not wasting people's time, but this is also ok. > o Make --strict the default for drivers/staging Ack. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
checkpatch induced patches...
On Wed, 2015-02-11 at 13:51 +0300, Dan Carpenter wrote:
> On Wed, Feb 11, 2015 at 01:40:37AM -0800, Joe Perches wrote:
> > On Wed, 2015-02-11 at 11:33 +0300, Dan Carpenter wrote:
> > > You can't fight checkpatch.pl.
> >
> > Sure you can, Ignore it whenever appropriate.
>
> People will just keep sending patches until something gets merged.
>
> It's rude to ignore patches and it's useless because people will just
> send another email asking you "have you received my patch yet?". It
> just creates a bigger fight.
> Applying mediocre checkpatch cleanups takes less time and energy than
> constantly fighting.
Mediocre cleanup patches that fall into the
"not satisfactory, poor, inferior" category
shouldn't be applied.
> It's easiest to not fight over stupid stuff and
> just apply the patches. Plus it makes the patch senders happy and
> that creates a happier community.
The primary thing I'd like to see stopped is the
use of checkpatch to satisfy some CS assignment.
Have any of those submitters ever gone on to produce
more thorough patches?
I'm half tempted to submit some patch like this to
make it difficult to use checkpatch on files outside
of drivers/staging.
o Only allow checkpatch to be used with the -f/--file
option for drivers/staging/
o Add an undocumented --force command line option
o Make --strict the default for drivers/staging
---
scripts/checkpatch.pl | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3642b0d..70f1047 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -25,6 +25,7 @@ my $tst_only;
my $emacs = 0;
my $terse = 0;
my $file = 0;
+my $force = 0;
my $check = 0;
my $check_orig = 0;
my $summary = 1;
@@ -130,6 +131,7 @@ GetOptions(
'emacs!'=> \$emacs,
'terse!'=> \$terse,
'f|file!' => \$file,
+ 'force!'=> \$force,
'subjective!' => \$check,
'strict!' => \$check,
'ignore=s' => \@ignore,
@@ -674,6 +676,10 @@ my $fixlinenr = -1;
my $vname;
for my $filename (@ARGV) {
my $FILE;
+ if (!$force && $file && $filename !~ m@^drivers/staging/@) {
+ warn "$P: checking '$filename' is not supported\n";
+ next;
+ }
if ($file) {
open($FILE, '-|', "diff -u /dev/null $filename") ||
die "$P: $filename: diff failed - $!\n";
@@ -2062,7 +2068,7 @@ sub process {
}
if ($found_file) {
- if ($realfile =~ m@^(drivers/net/|net/)@) {
+ if ($realfile =~
m@^(?:drivers/net/|net/|drivers/staging/)@) {
$check = 1;
} else {
$check = $check_orig;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] Drivers: hv: balloon: fix deadlock between memory adding and onlining
If newly added memory is brought online with e.g. udev rule:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"
the following deadlock is observed (and easily reproducable):
First participant, worker thread doing add_memory():
...
[ 725.491469] 6 locks held by kworker/0:1/27:
[ 725.505037] #0: ("events"){..}, at: []
process_one_work+0x16d/0x4e0
[ 725.533370] #1: ((&dm_device.ha_wrk.wrk)){..}, at:
[] process_one_work+0x16d/0x4e0
[ 725.565580] #2: (mem_hotplug.lock){..}, at: []
mem_hotplug_begin+0x5/0x80
[ 725.594369] #3: (mem_hotplug.lock#2){..}, at: []
mem_hotplug_begin+0x4f/0x80
[ 725.628554] #4: (mem_sysfs_mutex){..}, at: []
register_new_memory+0x33/0xd0
[ 725.658519] #5: (&dev->mutex){..}, at: []
device_attach+0x23/0xb0
Second participant, udev:
...
[ 726.150691] 7 locks held by systemd-udevd/888:
[ 726.165044] #0: (sb_writers#3){..}, at: []
vfs_write+0x1b3/0x1f0
[ 726.192422] #1: (&of->mutex){..}, at: []
kernfs_fop_write+0x66/0x1a0
[ 726.220289] #2: (s_active#60){..}, at: []
kernfs_fop_write+0x6e/0x1a0
[ 726.249382] #3: (device_hotplug_lock){..}, at: []
lock_device_hotplug_sysfs+0x15/0x50
[ 726.281901] #4: (&dev->mutex){..}, at: []
device_online+0x23/0xa0
[ 726.308619] #5: (mem_hotplug.lock){..}, at: []
mem_hotplug_begin+0x5/0x80
[ 726.337994] #6: (mem_hotplug.lock#2){..}, at: []
mem_hotplug_begin+0x4f/0x80
Solve the issue bu grabbing device_hotplug_lock before doing add_memory(). If
we do that, lock_device_hotplug_sysfs() will cause syscall retry which will
eventually succeed.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_balloon.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b958ded..0af1aa2 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -592,9 +592,19 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
dm_device.ha_waiting = true;
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
+
+ /*
+* Grab hotplug lock as we'll be doing device_register() and we
+* need to protect against someone (e.g. udev doing memory
+* onlining) locking it before we're done.
+*/
+ lock_device_hotplug();
+
ret = add_memory(nid, PFN_PHYS((start_pfn)),
(HA_CHUNK << PAGE_SHIFT));
+ unlock_device_hotplug();
+
if (ret) {
pr_info("hot_add memory failed error is %d\n", ret);
if (ret == -EEXIST) {
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] memory_hotplug: hyperv: fix deadlock between memory adding and onlining
If newly added memory is brought online with e.g. udev rule:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"
the following deadlock is observed (and easily reproducable):
First participant, worker thread doing add_memory():
[ 724.948846] kworker/0:1 D 88000412f9c8 1324827 2 0x
[ 724.973543] Workqueue: events hot_add_req [hv_balloon]
[ 724.991736] 88000412f9c8 88003fa1dc30
000151c0
[ 725.019725] 0246 88000412ffd8 000151c0
88003a77a4e0
[ 725.046486] 88003fa1dc30 0001032a6000 88003a7ca838
88003a7ca898
[ 725.072969] Call Trace:
[ 725.082690] [] schedule_preempt_disabled+0x29/0x70
[ 725.103799] [] mutex_lock_nested+0x14b/0x470
[ 725.122367] [] ? device_attach+0x23/0xb0
[ 725.140992] [] device_attach+0x23/0xb0
[ 725.159131] [] bus_probe_device+0xb0/0xe0
[ 725.177055] [] device_add+0x443/0x650
[ 725.195558] [] device_register+0x1e/0x30
[ 725.213133] [] init_memory_block+0xd0/0xf0
[ 725.231533] [] register_new_memory+0xb1/0xd0
[ 725.250769] [] __add_pages+0x13f/0x250
[ 725.269642] [] ? arch_add_memory+0x70/0xf0
[ 725.288764] [] arch_add_memory+0x70/0xf0
[ 725.306117] [] add_memory+0xef/0x1f0
[ 725.322466] [] hot_add_req+0x33f/0xf90 [hv_balloon]
[ 725.342777] [] process_one_work+0x1df/0x4e0
[ 725.361459] [] ? process_one_work+0x16d/0x4e0
[ 725.380390] [] worker_thread+0x11b/0x450
[ 725.397684] [] ? process_one_work+0x4e0/0x4e0
[ 725.416533] [] kthread+0xf3/0x110
[ 725.433372] [] ? kthread_create_on_node+0x240/0x240
[ 725.453749] [] ret_from_fork+0x7c/0xb0
[ 725.470994] [] ? kthread_create_on_node+0x240/0x240
[ 725.491469] 6 locks held by kworker/0:1/27:
[ 725.505037] #0: ("events"){..}, at: []
process_one_work+0x16d/0x4e0
[ 725.533370] #1: ((&dm_device.ha_wrk.wrk)){..}, at:
[] process_one_work+0x16d/0x4e0
[ 725.565580] #2: (mem_hotplug.lock){..}, at: []
mem_hotplug_begin+0x5/0x80
[ 725.594369] #3: (mem_hotplug.lock#2){..}, at: []
mem_hotplug_begin+0x4f/0x80
[ 725.628554] #4: (mem_sysfs_mutex){..}, at: []
register_new_memory+0x33/0xd0
[ 725.658519] #5: (&dev->mutex){..}, at: []
device_attach+0x23/0xb0
Second participant, udev:
[ 725.750889] systemd-udevd D 88003b94fc68 14016 888530 0x0004
[ 725.773767] 88003b94fc68 8800034949c0
000151c0
[ 725.798332] 8210d980 88003b94ffd8 000151c0
880037a69270
[ 725.822841] 8800034949c0 00010001 8800034949c0
81ff2b48
[ 725.849184] Call Trace:
[ 725.858987] [] schedule_preempt_disabled+0x29/0x70
[ 725.879231] [] mutex_lock_nested+0x14b/0x470
[ 725.897860] [] ? mem_hotplug_begin+0x4f/0x80
[ 725.916698] [] mem_hotplug_begin+0x4f/0x80
[ 725.935064] [] ? mem_hotplug_begin+0x5/0x80
[ 725.953464] [] online_pages+0x3b/0x520
[ 725.971542] [] ? device_online+0x23/0xa0
[ 725.989207] [] memory_subsys_online+0x64/0xc0
[ 726.008513] [] device_online+0x6d/0xa0
[ 726.025579] [] store_mem_state+0x5b/0xe0
[ 726.043400] [] dev_attr_store+0x18/0x30
[ 726.060506] [] sysfs_kf_write+0x48/0x60
[ 726.077940] [] kernfs_fop_write+0x13b/0x1a0
[ 726.099416] [] vfs_write+0xb7/0x1f0
[ 726.115748] [] SyS_write+0x58/0xd0
[ 726.131933] [] system_call_fastpath+0x12/0x17
[ 726.150691] 7 locks held by systemd-udevd/888:
[ 726.165044] #0: (sb_writers#3){..}, at: []
vfs_write+0x1b3/0x1f0
[ 726.192422] #1: (&of->mutex){..}, at: []
kernfs_fop_write+0x66/0x1a0
[ 726.220289] #2: (s_active#60){..}, at: []
kernfs_fop_write+0x6e/0x1a0
[ 726.249382] #3: (device_hotplug_lock){..}, at: []
lock_device_hotplug_sysfs+0x15/0x50
[ 726.281901] #4: (&dev->mutex){..}, at: []
device_online+0x23/0xa0
[ 726.308619] #5: (mem_hotplug.lock){..}, at: []
mem_hotplug_begin+0x5/0x80
[ 726.337994] #6: (mem_hotplug.lock#2){..}, at: []
mem_hotplug_begin+0x4f/0x80
In short: onlining grabs device lock and then tries to do mem_hotplug_begin()
while add_memory() is between mem_hotplug_begin() and mem_hotplug_done() and it
tries grabbing device lock.
To my understanding ACPI memory hotplug doesn't have the same issue as
device_hotplug_lock is being grabbed when the ACPI device is added.
Solve the issue by grabbing device_hotplug_lock before doing add_memory(). If
we do that, lock_device_hotplug_sysfs() will cause syscall retry which will
eventually succeed. To support the change we need to export lock_device_hotplug/
unlock_device_hotplug. This approach can be completely wrong though.
Vitaly Kuznetsov (3):
driver core: export lock_device_hotplug/unlock_device_hotplug
memory_hotplug: add note about holding device_hotplug_lock and
add_memory()
Drivers: hv: balloon: fix deadlock between memory adding and onlining
drivers/base/core.c | 2 ++
drivers/hv/hv_balloon.c | 10 ++
mm/memory_hotplug.c | 6 +-
3 files chan
[PATCH 2/3] memory_hotplug: add note about holding device_hotplug_lock and add_memory()
add_memory() is supposed to be run with device_hotplug_lock grabbed, otherwise
it can race with e.g. device_online(). ACPI memory hotplug does that already
but e.g. Hyper-V ballooning driver doesn't.
Signed-off-by: Vitaly Kuznetsov
---
mm/memory_hotplug.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 9fab107..41638eb 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1213,7 +1213,11 @@ int zone_for_memory(int nid, u64 start, u64 size, int
zone_default)
return zone_default;
}
-/* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */
+/*
+ * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
+ * and online/offline operations before this call.
+ * We are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG.
+ */
int __ref add_memory(int nid, u64 start, u64 size)
{
pg_data_t *pgdat = NULL;
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] driver core: export lock_device_hotplug/unlock_device_hotplug
add_memory() is supposed to be run with device_hotplug_lock grabbed, otherwise
it can race with e.g. device_online(). Allow external modules (hv_balloon for
now) to lock device hotplug.
Signed-off-by: Vitaly Kuznetsov
---
drivers/base/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 97e2baf..b3073af 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -55,11 +55,13 @@ void lock_device_hotplug(void)
{
mutex_lock(&device_hotplug_lock);
}
+EXPORT_SYMBOL_GPL(lock_device_hotplug);
void unlock_device_hotplug(void)
{
mutex_unlock(&device_hotplug_lock);
}
+EXPORT_SYMBOL_GPL(unlock_device_hotplug);
int lock_device_hotplug_sysfs(void)
{
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/30] staging: unisys: serverdown variable change bool to int virthba
On Wed, Feb 11, 2015 at 08:32:52AM -0600, Romer, Benjamin M wrote: > On Wed, 2015-02-11 at 11:36 +0300, Dan Carpenter wrote: > > On Tue, Feb 10, 2015 at 12:58:35PM -0500, Benjamin Romer wrote: > > > From: Erik Arfvidson > > > > > > This patch changes serverdown variable to int instead of bool > > > > > > > Why? It looks like bool is more appropriate? > > Hi Dan, > > We had received some comments on our code that said that our BOOL > typedef wasn't acceptable, Because we already have the "bool" type. > and that we really ought to be returning 0 > for success and error values in failure cases. By switching these to int > we're taking a first step towards that. True, but I'm not sure if these patches help us do that generally, and especially here we're changed a struct member and not a return type... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/30] staging: unisys: serverdown variable change bool to int virthba
On Wed, 2015-02-11 at 11:36 +0300, Dan Carpenter wrote: > On Tue, Feb 10, 2015 at 12:58:35PM -0500, Benjamin Romer wrote: > > From: Erik Arfvidson > > > > This patch changes serverdown variable to int instead of bool > > > > Why? It looks like bool is more appropriate? Hi Dan, We had received some comments on our code that said that our BOOL typedef wasn't acceptable, and that we really ought to be returning 0 for success and error values in failure cases. By switching these to int we're taking a first step towards that. -- Ben Romer | Software Engineer | Virtual Systems Development Unisys Corporation | 2476 Swedesford Rd | Malvern, PA 19355 | 610-648-7140 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: unisys: remove unused variable
On Tue, Feb 10, 2015 at 02:34:15PM +0800, Greg Kroah-Hartman wrote: > On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote: > > > > > > But as I've missed this in the past, nevermind, I'll take it as is. Can > > > you resend your outstanding patches and I'll queue them up after > > > 3.20-rc1 is out. > > i will resend them now or should i send after the merge window closes? > > You can send patches any time, I'll batch them up and apply them to my > trees at the proper time. i have sent them as v2, i think i should have sent as [PATCH resend] :( sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: panel: initialize lcd if lcd enabled
initialiaze lcd parameters only if lcd is enabled.
Signed-off-by: Sudip Mukherjee
---
v2: fix indention of comment
drivers/staging/panel/panel.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index 6ed35b6..31d8608 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -2323,25 +2323,6 @@ static int __init panel_init_module(void)
break;
}
- /*
-* Init lcd struct with load-time values to preserve exact current
-* functionality (at least for now).
-*/
- lcd.height = lcd_height;
- lcd.width = lcd_width;
- lcd.bwidth = lcd_bwidth;
- lcd.hwidth = lcd_hwidth;
- lcd.charset = lcd_charset;
- lcd.proto = lcd_proto;
- lcd.pins.e = lcd_e_pin;
- lcd.pins.rs = lcd_rs_pin;
- lcd.pins.rw = lcd_rw_pin;
- lcd.pins.cl = lcd_cl_pin;
- lcd.pins.da = lcd_da_pin;
- lcd.pins.bl = lcd_bl_pin;
-
- /* Leave it for now, just in case */
- lcd.esc_seq.len = -1;
/*
* Overwrite selection with module param values (both keypad and lcd),
@@ -2361,6 +2342,28 @@ static int __init panel_init_module(void)
lcd.enabled = (selected_lcd_type > 0);
+ if (lcd.enabled) {
+ /*
+* Init lcd struct with load-time values to preserve exact
+* current functionality (at least for now).
+*/
+ lcd.height = lcd_height;
+ lcd.width = lcd_width;
+ lcd.bwidth = lcd_bwidth;
+ lcd.hwidth = lcd_hwidth;
+ lcd.charset = lcd_charset;
+ lcd.proto = lcd_proto;
+ lcd.pins.e = lcd_e_pin;
+ lcd.pins.rs = lcd_rs_pin;
+ lcd.pins.rw = lcd_rw_pin;
+ lcd.pins.cl = lcd_cl_pin;
+ lcd.pins.da = lcd_da_pin;
+ lcd.pins.bl = lcd_bl_pin;
+
+ /* Leave it for now, just in case */
+ lcd.esc_seq.len = -1;
+ }
+
switch (selected_keypad_type) {
case KEYPAD_TYPE_OLD:
keypad_profile = old_keypad_profile;
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv2 2/2] ft1000-pcmcia: ft1000_hw.c: code refactoring: add ft1000_read_dsp_timer()
I'm sorry. I just realized I sent the wrong patch. This one is embarrassingly wrong :/ I'm going to resend the whole patchset tonight or tomorrow. Please excuse me for the mess :/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/6] staging: rtl8188eu: hal: removed code indent error
On Wed, Feb 11, 2015 at 01:40:37AM -0800, Joe Perches wrote: > On Wed, 2015-02-11 at 11:33 +0300, Dan Carpenter wrote: > > You can't fight checkpatch.pl. > > Sure you can, Ignore it whenever appropriate. People will just keep sending patches until something gets merged. It's rude to ignore patches and it's useless because people will just send another email asking you "have you received my patch yet?". It just creates a bigger fight. Applying mediocre checkpatch cleanups takes less time and energy than constantly fighting. It's easiest to not fight over stupid stuff and just apply the patches. Plus it makes the patch senders happy and that creates a happier community. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] Staging: dgnc: dgnc_tty: code style improvements
That looks kind of uglier than before. Please run your patch throught scripts/checkpatch.pl --strict. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: unisys: Remove allocation from declaration line
On Wed, Feb 11, 2015 at 06:26:27AM +0800, Greg Kroah-Hartman wrote: > On Tue, Feb 10, 2015 at 02:02:14PM +0100, Quentin Lambert wrote: > > This patch removes allocation from declaration line because > > people are known to gloss over declarations. > > Again, who are these lazy people, and why are they reading kernel code? > >From my work with smatch: 1) Probably 70-80% of inconsistent NULL checking is when done in the initializer. I'm sending a patch for one of these today. 2) If there is an allocation in the initializer then it's more likely that the NULL check will be missing. Initializers are a blind spot that people do not read. It's not just one maintainer, it's consistent across the board. Also if you put an allocation in the initializer then it almost always has to be mangled to fit in 80 characters and it looks ugly. But after these patches then all the allocations fit naturally. Plus you have to have that blank line to separate the initialization paragraph from the paragraph with the check for allocation failure. Really, it is fairly uncommon to put an allocation in the initalizer. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/6] staging: rtl8188eu: hal: removed code indent error
On Wed, 2015-02-11 at 11:33 +0300, Dan Carpenter wrote: > On Tue, Feb 10, 2015 at 03:27:11PM +0100, Bas Peters wrote: > > >> @@ -101,8 +101,7 @@ void rtl88eu_phy_rf6052_set_cck_txpower(struct > > >> adapter *adapt, u8 *powerlevel) > > >> ptr++; > > >> } > > >> } > > >> - rtl88eu_dm_txpower_track_adjust(&hal_data->odmpriv, 1, &direction, > > >> - &pwrtrac_value); > > >> + rtl88eu_dm_txpower_track_adjust(&hal_data->odmpriv, 1, &direction, > > >> &pwrtrac_value); > > > you are introducing one warning to fix one error. line over 80 character. > > > > Isn't that warning more of a guideline, rather than an actual warning? Yes, it is more informational than defect. > You can't fight checkpatch.pl. Sure you can, Ignore it whenever appropriate. It's a pity there are _so_ many people that think checkpatch messages are gospel. > We reject the worst or the worst "break > lines up into smaller chunks" patches where they obviously hurt > readability, but we almost always silence the warning in the end. The > original code in this case was fine. Any line with 30+ char identifiers generally doesn't fit well in 80 char lines. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Staging: dgnc: dgnc_tty: code style improvements
Coding style improvements based on check_patch.pl:
1) Modified lines over 80 characters to fit.
2) Removed curly braces from a single line if block at
dgnc_check_queue_flow_control().
3) Combined two if statements to reduce nesting in
dgnc_wakeup_writes().
4) Combined and reverted logic in if statement in
dgnc_tty_ioctl() at case TCLFLSH to reduce nesting.
Signed-off-by: Tolga Ceylan
---
drivers/staging/dgnc/dgnc_tty.c | 266 +---
1 file changed, 168 insertions(+), 98 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index f81a375..ff650cb 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -105,10 +105,14 @@ static struct ktermios DgncDefaultTermios = {
/* Our function prototypes */
static int dgnc_tty_open(struct tty_struct *tty, struct file *file);
static void dgnc_tty_close(struct tty_struct *tty, struct file *file);
-static int dgnc_block_til_ready(struct tty_struct *tty, struct file *file,
struct channel_t *ch);
-static int dgnc_tty_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned
long arg);
-static int dgnc_tty_digigeta(struct tty_struct *tty, struct digi_t __user
*retinfo);
-static int dgnc_tty_digiseta(struct tty_struct *tty, struct digi_t __user
*new_info);
+static int dgnc_block_til_ready(struct tty_struct *tty, struct file *file,
+ struct channel_t *ch);
+static int dgnc_tty_ioctl(struct tty_struct *tty, unsigned int cmd,
+ unsigned long arg);
+static int dgnc_tty_digigeta(struct tty_struct *tty,
+ struct digi_t __user *retinfo);
+static int dgnc_tty_digiseta(struct tty_struct *tty,
+ struct digi_t __user *new_info);
static int dgnc_tty_write_room(struct tty_struct *tty);
static int dgnc_tty_put_char(struct tty_struct *tty, unsigned char c);
static int dgnc_tty_chars_in_buffer(struct tty_struct *tty);
@@ -119,14 +123,19 @@ static void dgnc_tty_unthrottle(struct tty_struct *tty);
static void dgnc_tty_flush_chars(struct tty_struct *tty);
static void dgnc_tty_flush_buffer(struct tty_struct *tty);
static void dgnc_tty_hangup(struct tty_struct *tty);
-static int dgnc_set_modem_info(struct tty_struct *tty, unsigned int command,
unsigned int __user *value);
-static int dgnc_get_modem_info(struct channel_t *ch, unsigned int __user
*value);
+static int dgnc_set_modem_info(struct tty_struct *tty, unsigned int command,
+ unsigned int __user *value);
+static int dgnc_get_modem_info(struct channel_t *ch,
+ unsigned int __user *value);
static int dgnc_tty_tiocmget(struct tty_struct *tty);
-static int dgnc_tty_tiocmset(struct tty_struct *tty, unsigned int set,
unsigned int clear);
+static int dgnc_tty_tiocmset(struct tty_struct *tty, unsigned int set,
+ unsigned int clear);
static int dgnc_tty_send_break(struct tty_struct *tty, int msec);
static void dgnc_tty_wait_until_sent(struct tty_struct *tty, int timeout);
-static int dgnc_tty_write(struct tty_struct *tty, const unsigned char *buf,
int count);
-static void dgnc_tty_set_termios(struct tty_struct *tty, struct ktermios
*old_termios);
+static int dgnc_tty_write(struct tty_struct *tty,
+ const unsigned char *buf, int count);
+static void dgnc_tty_set_termios(struct tty_struct *tty,
+ struct ktermios *old_termios);
static void dgnc_tty_send_xchar(struct tty_struct *tty, char ch);
@@ -207,18 +216,22 @@ int dgnc_tty_register(struct dgnc_board *brd)
brd->SerialDriver.subtype = SERIAL_TYPE_NORMAL;
brd->SerialDriver.init_termios = DgncDefaultTermios;
brd->SerialDriver.driver_name = DRVSTR;
- brd->SerialDriver.flags = (TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV
| TTY_DRIVER_HARDWARE_BREAK);
+ brd->SerialDriver.flags = (TTY_DRIVER_REAL_RAW |
+ TTY_DRIVER_DYNAMIC_DEV |
+ TTY_DRIVER_HARDWARE_BREAK);
/*
* The kernel wants space to store pointers to
* tty_struct's and termios's.
*/
- brd->SerialDriver.ttys = kcalloc(brd->maxports,
sizeof(*brd->SerialDriver.ttys), GFP_KERNEL);
+ brd->SerialDriver.ttys = kcalloc(brd->maxports,
+ sizeof(*brd->SerialDriver.ttys), GFP_KERNEL);
if (!brd->SerialDriver.ttys)
return -ENOMEM;
kref_init(&brd->SerialDriver.kref);
- brd->SerialDriver.termios = kcalloc(brd->maxports,
sizeof(*brd->SerialDriver.termios), GFP_KERNEL);
+ brd->SerialDriver.termios = kcalloc(brd->maxports,
+ sizeof(*brd->SerialDriver.termios), GFP_KERNEL);
if (!brd->SerialDriver.termios)
return -ENOMEM;
@@ -256,18 +269,22 @@ int dgnc_tty_register(struct dgnc_board *brd)
brd->PrintDriver.subtype = SERIAL_TYPE_NORMAL;
brd->PrintDriver.init_termios = DgncDefaultTermios;
brd->PrintDriver.driver_name = DRVSTR;
- brd->PrintDriver.flags = (TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV
| TTY_DRIVER_HARDWARE_BREAK);
+ brd->PrintDriv
Re: [PATCH 02/30] staging: unisys: change serverchangingstate variable bool to int
On Tue, Feb 10, 2015 at 12:58:36PM -0500, Benjamin Romer wrote: > From: Erik Arfvidson > > This patch changes serverchangingstate variable from bool to int serverchangingstate is a terriblevariablename. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/30] staging: unisys: serverdown variable change bool to int virthba
On Tue, Feb 10, 2015 at 12:58:35PM -0500, Benjamin Romer wrote: > From: Erik Arfvidson > > This patch changes serverdown variable to int instead of bool > Why? It looks like bool is more appropriate? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/6] staging: rtl8188eu: hal: removed code indent error
On Tue, Feb 10, 2015 at 03:27:11PM +0100, Bas Peters wrote: > >> @@ -101,8 +101,7 @@ void rtl88eu_phy_rf6052_set_cck_txpower(struct adapter > >> *adapt, u8 *powerlevel) > >> ptr++; > >> } > >> } > >> - rtl88eu_dm_txpower_track_adjust(&hal_data->odmpriv, 1, &direction, > >> - &pwrtrac_value); > >> + rtl88eu_dm_txpower_track_adjust(&hal_data->odmpriv, 1, &direction, > >> &pwrtrac_value); > > you are introducing one warning to fix one error. line over 80 character. > > Isn't that warning more of a guideline, rather than an actual warning? You can't fight checkpatch.pl. We reject the worst or the worst "break lines up into smaller chunks" patches where they obviously hurt readability, but we almost always silence the warning in the end. The original code in this case was fine. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
