from:"Luis Ortega"

[Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM

2014-02-13 Thread Luis Ortega

Hi, testing 3.14-rc2 I noticed I could not adjust the brightness of the
screen any longer. This problem is already present in 3.14-rc1. 3.13 works fine.

My hardware is a netbook with intel atom and a 945GM graphics card.

I bisected the problem down to the next commit:

bc0bb9fd1c7810407ab810d204bbaecb255fddde is the first bad commit
commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
Author: Jani Nikula 
Date:   Thu Nov 14 12:14:29 2013 +0200

drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE

The quirk was added as what I'd say was a stopgap measure in

commit e85843bec6c2ea7c10ec61238396891cc2b753a9
Author: Kamal Mostafa 
Date:   Fri Jul 19 15:02:01 2013 -0700

drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight

without really digging into what was going on.

Also, as mentioned in the related bug [1], having the quirk regressed
some of the machines it was supposed to fix to begin with, and there
were patches posted to disable the quirk on such machines [2]!

The fact is, we do need the BLM_PCH_PWM_ENABLE bit set to have
backlight. With the quirk, we've relied on BIOS to have set it, and our
save/restore code to retain it. With the full backlight setup at enable,
we have no place for things that rely on previous state.

With the per platform hooks, we've also made a change in the PCH
platform enable order: setting the backlight duty cycle between CPU and
PCH PWM enable. Some experimenting and

commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai 
Date:   Sat Aug 11 08:56:42 2012 +0200

drm/i915: Fix blank panel at reopening lid

indicate that we can't set the backlight before enabling CPU PWM; the
value just won't stick. But AFAICT we should do it before enabling the
PCH PWM.

Finally, any fallout we should fix properly, preferrably without quirks,
and absolutely without quirks that rely on existing state. With the per
platform hooks have much more flexibility to adjust the sequence as
required by platforms.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=47941
[2] 
http://lkml.kernel.org/r/1378229848-29113-1-git-send-email-ka...@canonical.com

Signed-off-by: Jani Nikula 
Reviewed-by: Imre Deak 
Signed-off-by: Daniel Vetter 


Additionally, when I had narrowed the problem to around 11 commits all the
resulting kernel I compiled made the screen blink and shake from left to right
non-stop. In the -rc kernels this doesn't happen. Thought it was worth
mentioning.
--
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/

Re: [Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM

2014-02-13 Thread Luis Ortega

> I dare say either your bisect went sour or you don't have 945GM. Please
> verify your steps.

Well, what can I say? I was careful when testing and the last kernel I compiled
shows the problem. I can replay the bisection if needed but if I have to start
all over again it's gonna take some time. I'm compiling in the netbook and took
me day and a half to finish the process.

In all honesty, along the way I met commit messages that I thought were more
probable to introduce this regression. (backlight related)

Also, here's the output of lspci:
00:00.0 Host bridge: Intel Corporation Mobile 945GSE Express Memory Controller 
Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express 
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller (rev 03)

> Please provide dmesg with drm.debug=0xe with 3.14-rc2.

Care to explain a bit more before I recompile 3.14-rc2? Do I need to
enable some particular debug option? How do I proceed for drm.debug=0xe?


Luis
> On Thu, Feb 13, 2014 at 05:04:23PM +0200, Jani Nikula wrote:
> On Thu, 13 Feb 2014, Luis Ortega  wrote:
> > Hi, testing 3.14-rc2 I noticed I could not adjust the brightness of the
> > screen any longer. This problem is already present in 3.14-rc1. 3.13 works 
> > fine.
> >
> > My hardware is a netbook with intel atom and a 945GM graphics card.
> >
> > I bisected the problem down to the next commit:
> 
> I dare say either your bisect went sour or you don't have 945GM. Please
> verify your steps.
> 
> Please provide dmesg with drm.debug=0xe with 3.14-rc2.
> 
> BR,
> Jani.
> 
> >
> > bc0bb9fd1c7810407ab810d204bbaecb255fddde is the first bad commit
> > commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
> > Author: Jani Nikula 
> > Date:   Thu Nov 14 12:14:29 2013 +0200
> >
> > drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
> > 
> > The quirk was added as what I'd say was a stopgap measure in
> > 
> > commit e85843bec6c2ea7c10ec61238396891cc2b753a9
> > Author: Kamal Mostafa 
> > Date:   Fri Jul 19 15:02:01 2013 -0700
> > 
> > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
> > 
> > without really digging into what was going on.
> > 
> > Also, as mentioned in the related bug [1], having the quirk regressed
> > some of the machines it was supposed to fix to begin with, and there
> > were patches posted to disable the quirk on such machines [2]!
> > 
> > The fact is, we do need the BLM_PCH_PWM_ENABLE bit set to have
> > backlight. With the quirk, we've relied on BIOS to have set it, and our
> > save/restore code to retain it. With the full backlight setup at enable,
> > we have no place for things that rely on previous state.
> > 
> > With the per platform hooks, we've also made a change in the PCH
> > platform enable order: setting the backlight duty cycle between CPU and
> > PCH PWM enable. Some experimenting and
> > 
> > commit 770c12312ad617172b1a65b911d3e6564fc5aca8
> > Author: Takashi Iwai 
> > Date:   Sat Aug 11 08:56:42 2012 +0200
> > 
> > drm/i915: Fix blank panel at reopening lid
> > 
> > indicate that we can't set the backlight before enabling CPU PWM; the
> > value just won't stick. But AFAICT we should do it before enabling the
> > PCH PWM.
> > 
> > Finally, any fallout we should fix properly, preferrably without quirks,
> > and absolutely without quirks that rely on existing state. With the per
> > platform hooks have much more flexibility to adjust the sequence as
> > required by platforms.
> > 
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=47941
> > [2] 
> > http://lkml.kernel.org/r/1378229848-29113-1-git-send-email-ka...@canonical.com
> > 
> > Signed-off-by: Jani Nikula 
> > Reviewed-by: Imre Deak 
> > Signed-off-by: Daniel Vetter 
> >
> >
> > Additionally, when I had narrowed the problem to around 11 commits all the
> > resulting kernel I compiled made the screen blink and shake from left to 
> > right
> > non-stop. In the -rc kernels this doesn't happen. Thought it was worth
> > mentioning.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
--
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/

Re: [Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM

2014-02-14 Thread Luis Ortega

> On Fri, Feb 14, 2014 at 09:09:52AM +0200, Jani Nikula wrote:
> 
> It seems that it will be better to track this in bugzilla rather than
> the mailing lists. Please file a bug on DRM/Intel component at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI. Attach these
> files.

Done. We can continue tracking this issue in
https://bugs.freedesktop.org/show_bug.cgi?id=75001

FYI, I re-bisected this issue and a different commit came up as the offendor.
It's all in the bugzilla report.

Luis
--
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/

[PATCH] Staging: bcm: Qos: fixed braces' coding style

2014-04-08 Thread Luis Ortega

Fixed badly placed and unnecessary braces.

PS: Performed as task 10 of the Eudyptula Challenge.

Signed-off-by: Luis Ortega 
---
 drivers/staging/bcm/Qos.c | 174 +-
 1 file changed, 48 insertions(+), 126 deletions(-)

diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
index 4f31583..4b9ce26 100644
--- a/drivers/staging/bcm/Qos.c
+++ b/drivers/staging/bcm/Qos.c
@@ -33,14 +33,11 @@ static bool MatchSrcIpAddress(struct bcm_classifier_rule 
*pstClassifierRule, ULO
ulSrcIP = ntohl(ulSrcIP);
if (0 == pstClassifierRule->ucIPSourceAddressLength)
return TRUE;
-   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPSourceAddressLength); ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPSourceAddressLength); ucLoopIndex++){
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Src Ip Address Mask:0x%x PacketIp:0x%x and Classification:0x%x", 
(UINT)pstClassifierRule->stSrcIpAddress.ulIpv4Mask[ucLoopIndex], (UINT)ulSrcIP, 
(UINT)pstClassifierRule->stSrcIpAddress.ulIpv6Addr[ucLoopIndex]);
if ((pstClassifierRule->stSrcIpAddress.ulIpv4Mask[ucLoopIndex] 
& ulSrcIP) ==

(pstClassifierRule->stSrcIpAddress.ulIpv4Addr[ucLoopIndex] & 
pstClassifierRule->stSrcIpAddress.ulIpv4Mask[ucLoopIndex]))
-   {
return TRUE;
-   }
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "Src Ip 
Address Not Matched");
return false;
@@ -68,13 +65,10 @@ static bool MatchDestIpAddress(struct bcm_classifier_rule 
*pstClassifierRule, UL
return TRUE;
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Destination Ip Address 0x%x 0x%x 0x%x  ", (UINT)ulDestIP, 
(UINT)pstClassifierRule->stDestIpAddress.ulIpv4Mask[ucLoopIndex], 
(UINT)pstClassifierRule->stDestIpAddress.ulIpv4Addr[ucLoopIndex]);

-   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPDestinationAddressLength); ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPDestinationAddressLength); ucLoopIndex++) {
if ((pstClassifierRule->stDestIpAddress.ulIpv4Mask[ucLoopIndex] 
& ulDestIP) ==

(pstClassifierRule->stDestIpAddress.ulIpv4Addr[ucLoopIndex] & 
pstClassifierRule->stDestIpAddress.ulIpv4Mask[ucLoopIndex]))
-   {
return TRUE;
-   }
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Destination Ip Address Not Matched");
return false;
@@ -99,9 +93,8 @@ static bool MatchTos(struct bcm_classifier_rule 
*pstClassifierRule, UCHAR ucType
return TRUE;

if (((pstClassifierRule->ucTosMask & ucTypeOfService) <= 
pstClassifierRule->ucTosHigh) && ((pstClassifierRule->ucTosMask & 
ucTypeOfService) >= pstClassifierRule->ucTosLow))
-   {
return TRUE;
-   }
+
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "Type Of 
Service Not Matched");
return false;
 }
@@ -123,13 +116,10 @@ bool MatchProtocol(struct bcm_classifier_rule 
*pstClassifierRule, UCHAR ucProtoc
struct bcm_mini_adapter *Adapter = GET_BCM_ADAPTER(gblpnetdev);
if (0 == pstClassifierRule->ucProtocolLength)
return TRUE;
-   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucProtocolLength; ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucProtocolLength; ucLoopIndex++) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Protocol:0x%X Classification Protocol:0x%X", ucProtocol, 
pstClassifierRule->ucProtocol[ucLoopIndex]);
if (pstClassifierRule->ucProtocol[ucLoopIndex] == ucProtocol)
-   {
return TRUE;
-   }
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "Protocol 
Not Matched");
return false;
@@ -155,13 +145,10 @@ bool MatchSrcPort(struct bcm_classifier_rule 
*pstClassifierRule, USHORT ushSrcPo

if (0 == pstClassifierRule->ucSrcPortRangeLength)
return TRUE;
-   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucSrcPortRangeLength; ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucSrcPortRangeLength; ucLoopIndex++) {
if (ushSrcPort <= 
pstClassifierRule->usSrcPortRangeHi[ucLoopIndex] &&
ushSrcPort >= 
pstClassifierRule->usSrcPortRangeLo[ucLoopIndex])
-   {

Re: [PATCH] Staging: bcm: Qos: fixed braces' coding style

2014-04-09 Thread Luis Ortega

On Tue, Apr 8, 2014 at 11:11 PM, Greg KH  wrote:
>
> Why the  before the '{' character?

It must have slipped in accidentally. Feel free to remove.
--
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/

[PATCH v2] Staging: bcm: Qos: fixed braces' coding style

2014-04-09 Thread Luis Ortega

Fixed badly placed and unnecessary braces.

PS: Performed as task 10 of the Eudyptula Challenge.

Signed-off-by: Luis Ortega 
---
Changes for v2:
- Removed accidental 
---
 drivers/staging/bcm/Qos.c | 174 +-
 1 file changed, 48 insertions(+), 126 deletions(-)

diff --git a/drivers/staging/bcm/Qos.c b/drivers/staging/bcm/Qos.c
index 4f31583..4b9ce26 100644
--- a/drivers/staging/bcm/Qos.c
+++ b/drivers/staging/bcm/Qos.c
@@ -33,14 +33,11 @@ static bool MatchSrcIpAddress(struct bcm_classifier_rule 
*pstClassifierRule, ULO
ulSrcIP = ntohl(ulSrcIP);
if (0 == pstClassifierRule->ucIPSourceAddressLength)
return TRUE;
-   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPSourceAddressLength); ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPSourceAddressLength); ucLoopIndex++) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Src Ip Address Mask:0x%x PacketIp:0x%x and Classification:0x%x", 
(UINT)pstClassifierRule->stSrcIpAddress.ulIpv4Mask[ucLoopIndex], (UINT)ulSrcIP, 
(UINT)pstClassifierRule->stSrcIpAddress.ulIpv6Addr[ucLoopIndex]);
if ((pstClassifierRule->stSrcIpAddress.ulIpv4Mask[ucLoopIndex] 
& ulSrcIP) ==

(pstClassifierRule->stSrcIpAddress.ulIpv4Addr[ucLoopIndex] & 
pstClassifierRule->stSrcIpAddress.ulIpv4Mask[ucLoopIndex]))
-   {
return TRUE;
-   }
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "Src Ip 
Address Not Matched");
return false;
@@ -68,13 +65,10 @@ static bool MatchDestIpAddress(struct bcm_classifier_rule 
*pstClassifierRule, UL
return TRUE;
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Destination Ip Address 0x%x 0x%x 0x%x  ", (UINT)ulDestIP, 
(UINT)pstClassifierRule->stDestIpAddress.ulIpv4Mask[ucLoopIndex], 
(UINT)pstClassifierRule->stDestIpAddress.ulIpv4Addr[ucLoopIndex]);

-   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPDestinationAddressLength); ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
(pstClassifierRule->ucIPDestinationAddressLength); ucLoopIndex++) {
if ((pstClassifierRule->stDestIpAddress.ulIpv4Mask[ucLoopIndex] 
& ulDestIP) ==

(pstClassifierRule->stDestIpAddress.ulIpv4Addr[ucLoopIndex] & 
pstClassifierRule->stDestIpAddress.ulIpv4Mask[ucLoopIndex]))
-   {
return TRUE;
-   }
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Destination Ip Address Not Matched");
return false;
@@ -99,9 +93,8 @@ static bool MatchTos(struct bcm_classifier_rule 
*pstClassifierRule, UCHAR ucType
return TRUE;

if (((pstClassifierRule->ucTosMask & ucTypeOfService) <= 
pstClassifierRule->ucTosHigh) && ((pstClassifierRule->ucTosMask & 
ucTypeOfService) >= pstClassifierRule->ucTosLow))
-   {
return TRUE;
-   }
+
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "Type Of 
Service Not Matched");
return false;
 }
@@ -123,13 +116,10 @@ bool MatchProtocol(struct bcm_classifier_rule 
*pstClassifierRule, UCHAR ucProtoc
struct bcm_mini_adapter *Adapter = GET_BCM_ADAPTER(gblpnetdev);
if (0 == pstClassifierRule->ucProtocolLength)
return TRUE;
-   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucProtocolLength; ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucProtocolLength; ucLoopIndex++) {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, 
"Protocol:0x%X Classification Protocol:0x%X", ucProtocol, 
pstClassifierRule->ucProtocol[ucLoopIndex]);
if (pstClassifierRule->ucProtocol[ucLoopIndex] == ucProtocol)
-   {
return TRUE;
-   }
}
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, IPV4_DBG, DBG_LVL_ALL, "Protocol 
Not Matched");
return false;
@@ -155,13 +145,10 @@ bool MatchSrcPort(struct bcm_classifier_rule 
*pstClassifierRule, USHORT ushSrcPo

if (0 == pstClassifierRule->ucSrcPortRangeLength)
return TRUE;
-   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucSrcPortRangeLength; ucLoopIndex++)
-   {
+   for (ucLoopIndex = 0; ucLoopIndex < 
pstClassifierRule->ucSrcPortRangeLength; ucLoopIndex++) {
if (ushSrcPort <= 
pstClassifierRule->usSrcPortRangeHi[ucLoopIndex] &&
ushSrcPort >= 
pstClassifierRule->usSrcPortRangeLo[ucLoopIndex])
-

[PATCH] staging: wlags49_h2: fix sparse warning "should it be static"

2014-05-07 Thread Luis Ortega

Fixes the following warning:
drivers/staging/wlags49_h2/sta_h2.c:4471:10: warning: symbol 'fw_image' was not 
declared. Should it be static?

Signed-off-by: Luis Ortega 
---
 drivers/staging/wlags49_h2/sta_h2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlags49_h2/sta_h2.c 
b/drivers/staging/wlags49_h2/sta_h2.c
index 0ba8def..2838faa 100644
--- a/drivers/staging/wlags49_h2/sta_h2.c
+++ b/drivers/staging/wlags49_h2/sta_h2.c
@@ -4468,7 +4468,7 @@ static const CFG_RANGE20_STRCT fw_image_infocompat[] = {
{ , , , , { { , ,  } } }/* endsentinel 
*/
 };

-memimage fw_image = {
+static memimage fw_image = {
"FUPU7D37dhfwci\001C",  /* signature, , 
C/Bin type */
(CFG_PROG_STRCT *) fw_image_code,
0x000F368E,
--
1.9.2

--
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/

[PATCH 4/4] Input: zforce - reduce stack memory allocated to frames

2014-01-27 Thread Luis Ortega

A frame is a u8 array with the following structure:
[PAYLOAD_HEADER, PAYLOAD_LENGTH, ...PAYLOAD_BODY...]

PAYLOAD_BODY can be at most 255 bytes long, as it's size is represented
by PAYLOAD_LENGTH. Therefore we can reduce the stack memory allocated to
payload_buffer[] roughly by half, from 512 to 257 bytes.

Signed-off-by: Luis Ortega 
---
 drivers/input/touchscreen/zforce_ts.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/zforce_ts.c 
b/drivers/input/touchscreen/zforce_ts.c
index e082d5c..afb2492 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -33,6 +33,7 @@
 #define WAIT_TIMEOUT   msecs_to_jiffies(1000)
 
 #define FRAME_START0xee
+#define FRAME_MAXSIZE  257
 
 /* Offsets of the different parts of the payload the controller sends */
 #define PAYLOAD_HEADER 0
@@ -475,7 +476,7 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
struct i2c_client *client = ts->client;
const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
int ret;
-   u8 payload_buffer[512];
+   u8 payload_buffer[FRAME_MAXSIZE];
u8 *payload;
 
/*
-- 
1.8.5.3

--
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/

[PATCH 3/4] Input: zforce - Remove unnecessary payload data checks

2014-01-27 Thread Luis Ortega

The function zforce_read_packet() reads 2 values (bytes) of payload
header, validates them and then proceeds to read the payload body.
The function stores all these in a u8 buffer.

The PAYLOAD_LENGTH check seems to be trying to detect an overflow error.
However, since we are just reading a u8 value from the buffer, these
checks are unnecessary and we should simply compare against zero.

Signed-off-by: Luis Ortega 
---
 drivers/input/touchscreen/zforce_ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/zforce_ts.c 
b/drivers/input/touchscreen/zforce_ts.c
index c1b6b82..e082d5c 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -423,7 +423,7 @@ static int zforce_read_packet(struct zforce_ts *ts, u8 *buf)
goto unlock;
}
 
-   if (buf[PAYLOAD_LENGTH] <= 0 || buf[PAYLOAD_LENGTH] > 255) {
+   if (buf[PAYLOAD_LENGTH] == 0) {
dev_err(&client->dev, "invalid payload length: %d\n",
buf[PAYLOAD_LENGTH]);
ret = -EIO;
-- 
1.8.5.3

--
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/

[PATCH 2/4] Input: zforce - fix lines exceeding 80 columns

2014-01-27 Thread Luis Ortega

Fixed lines exceeding 80 characters long wherever possible,
as per the coding style.

Signed-off-by: Luis Ortega 
---
 drivers/input/touchscreen/zforce_ts.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/input/touchscreen/zforce_ts.c 
b/drivers/input/touchscreen/zforce_ts.c
index c145c1d..c1b6b82 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -235,7 +235,8 @@ static int zforce_scan_frequency(struct zforce_ts *ts, u16 
idle, u16 finger,
(finger & 0xff), ((finger >> 8) & 0xff),
(stylus & 0xff), ((stylus >> 8) & 0xff) };
 
-   dev_dbg(&client->dev, "set scan frequency to (idle: %d, finger: %d, 
stylus: %d)\n",
+   dev_dbg(&client->dev,
+   "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
idle, finger, stylus);
 
return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
@@ -332,7 +333,8 @@ static int zforce_touch_event(struct zforce_ts *ts, u8 
*payload)
 
count = payload[0];
if (count > ZFORCE_REPORT_POINTS) {
-   dev_warn(&client->dev, "too many coordinates %d, expected max 
%d\n",
+   dev_warn(&client->dev,
+"too many coordinates %d, expected max %d\n",
 count, ZFORCE_REPORT_POINTS);
count = ZFORCE_REPORT_POINTS;
}
@@ -494,8 +496,8 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
while (!gpio_get_value(pdata->gpio_int)) {
ret = zforce_read_packet(ts, payload_buffer);
if (ret < 0) {
-   dev_err(&client->dev, "could not read packet, ret: 
%d\n",
-   ret);
+   dev_err(&client->dev,
+   "could not read packet, ret: %d\n", ret);
break;
}
 
@@ -539,7 +541,8 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
payload[RESPONSE_DATA + 4];
ts->version_rev   = (payload[RESPONSE_DATA + 7] << 8) |
payload[RESPONSE_DATA + 6];
-   dev_dbg(&ts->client->dev, "Firmware Version %04x:%04x 
%04x:%04x\n",
+   dev_dbg(&ts->client->dev,
+   "Firmware Version %04x:%04x %04x:%04x\n",
ts->version_major, ts->version_minor,
ts->version_build, ts->version_rev);
 
@@ -552,7 +555,8 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
break;
 
default:
-   dev_err(&ts->client->dev, "unrecognized response id: 
0x%x\n",
+   dev_err(&ts->client->dev,
+   "unrecognized response id: 0x%x\n",
payload[RESPONSE_ID]);
break;
}
@@ -618,7 +622,8 @@ static int zforce_suspend(struct device *dev)
 
enable_irq_wake(client->irq);
} else if (input->users) {
-   dev_dbg(&client->dev, "suspend without being a wakeup 
source\n");
+   dev_dbg(&client->dev,
+   "suspend without being a wakeup source\n");
 
ret = zforce_stop(ts);
if (ret)
-- 
1.8.5.3

--
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/

[PATCH 1/4] Input: zforce - fix spelling errors

2014-01-27 Thread Luis Ortega

Fixed a few spelling errors.

Signed-off-by: Luis Ortega 
---
 drivers/input/touchscreen/zforce_ts.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/input/touchscreen/zforce_ts.c 
b/drivers/input/touchscreen/zforce_ts.c
index 2175f34..c145c1d 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -64,7 +64,7 @@
 #define RESPONSE_STATUS0X1e
 
 /*
- * Notifications are send by the touch controller without
+ * Notifications are sent by the touch controller without
  * being requested by the driver and include for example
  * touch indications
  */
@@ -103,8 +103,8 @@ struct zforce_point {
  * @suspended  device suspended
  * @access_mutex   serialize i2c-access, to keep multipart reads together
  * @command_done   completion to wait for the command result
- * @command_mutex  serialize commands send to the ic
- * @command_waitingthe id of the command that that is currently waiting
+ * @command_mutex  serialize commands sent to the ic
+ * @command_waitingthe id of the command that is currently waiting
  * for a result
  * @command_result returned result of the command
  */
@@ -332,7 +332,7 @@ static int zforce_touch_event(struct zforce_ts *ts, u8 
*payload)
 
count = payload[0];
if (count > ZFORCE_REPORT_POINTS) {
-   dev_warn(&client->dev, "to many coordinates %d, expected max 
%d\n",
+   dev_warn(&client->dev, "too many coordinates %d, expected max 
%d\n",
 count, ZFORCE_REPORT_POINTS);
count = ZFORCE_REPORT_POINTS;
}
@@ -798,7 +798,7 @@ static int zforce_probe(struct i2c_client *client,
return ret;
}
 
-   /* this gets the firmware version among other informations */
+   /* this gets the firmware version among other information */
ret = zforce_command_wait(ts, COMMAND_STATUS);
if (ret < 0) {
dev_err(&client->dev, "couldn't get status, %d\n", ret);
-- 
1.8.5.3

--
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/

Input: zforce - fix various small issues

2014-01-27 Thread Luis Ortega

As a kernel newbie and owner of a Barnes & Noble e-reader I was
curious to review this driver to learn more about the touchscreen.

The first two patches are fairly innocuous whereas the last two
slightly modify the code to fix two small issues I discovered.
I don't have the setup to test them but they look logically correct
to me.

[PATCH 1/4] Input: zforce - fix spelling errors
[PATCH 2/4] Input: zforce - fix lines exceeding 80 columns
[PATCH 3/4] Input: zforce - Remove unnecessary payload data checks
[PATCH 4/4] Input: zforce - reduce stack memory allocated to frames
--
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/

Re: [PATCH 2/4] Input: zforce - fix lines exceeding 80 columns

2014-01-27 Thread Luis Ortega

Yeah, I also ran checkpatch on the file and it had nothing to report.
Unfortunately those lines are slightly long and got word wrapped in my
editor, disrupting the flow of text. I thought fixing them wouldn't hurt.

On Mon, Jan 27, 2014 at 8:12 PM, Heiko Stübner  wrote:
> On Monday, 27. January 2014 19:46:11 Luis Ortega wrote:
>> Fixed lines exceeding 80 characters long wherever possible,
>> as per the coding style.
>>
>> Signed-off-by: Luis Ortega 
>
> checkpatch did not complain on the initial submission, so I guess it's more an
> issue of taste. Nevertheless I don't have a preference for one way or the
> other, so
>
> Acked-by: Heiko Stuebner 
>
>
>> ---
>>  drivers/input/touchscreen/zforce_ts.c | 19 ---
>>  1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/zforce_ts.c
>> b/drivers/input/touchscreen/zforce_ts.c index c145c1d..c1b6b82 100644
>> --- a/drivers/input/touchscreen/zforce_ts.c
>> +++ b/drivers/input/touchscreen/zforce_ts.c
>> @@ -235,7 +235,8 @@ static int zforce_scan_frequency(struct zforce_ts *ts,
>> u16 idle, u16 finger, (finger & 0xff), ((finger >> 8) & 0xff),
>>   (stylus & 0xff), ((stylus >> 8) & 0xff) };
>>
>> - dev_dbg(&client->dev, "set scan frequency to (idle: %d, finger: %d,
>> stylus: %d)\n", + dev_dbg(&client->dev,
>> + "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
>>   idle, finger, stylus);
>>
>>   return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
>> @@ -332,7 +333,8 @@ static int zforce_touch_event(struct zforce_ts *ts, u8
>> *payload)
>>
>>   count = payload[0];
>>   if (count > ZFORCE_REPORT_POINTS) {
>> - dev_warn(&client->dev, "too many coordinates %d, expected max 
>> %d\n",
>> + dev_warn(&client->dev,
>> +  "too many coordinates %d, expected max %d\n",
>>count, ZFORCE_REPORT_POINTS);
>>   count = ZFORCE_REPORT_POINTS;
>>   }
>> @@ -494,8 +496,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
>> *dev_id) while (!gpio_get_value(pdata->gpio_int)) {
>>   ret = zforce_read_packet(ts, payload_buffer);
>>   if (ret < 0) {
>> - dev_err(&client->dev, "could not read packet, ret: 
>> %d\n",
>> - ret);
>> + dev_err(&client->dev,
>> + "could not read packet, ret: %d\n", ret);
>>   break;
>>   }
>>
>> @@ -539,7 +541,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
>> *dev_id) payload[RESPONSE_DATA + 4];
>>   ts->version_rev   = (payload[RESPONSE_DATA + 7] << 8) |
>>   payload[RESPONSE_DATA + 6];
>> - dev_dbg(&ts->client->dev, "Firmware Version %04x:%04x 
>> %04x:
> %04x\n",
>> + dev_dbg(&ts->client->dev,
>> + "Firmware Version %04x:%04x %04x:%04x\n",
>>   ts->version_major, ts->version_minor,
>>   ts->version_build, ts->version_rev);
>>
>> @@ -552,7 +555,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
>> *dev_id) break;
>>
>>   default:
>> - dev_err(&ts->client->dev, "unrecognized response id: 
>> 0x%x\n",
>> + dev_err(&ts->client->dev,
>> + "unrecognized response id: 0x%x\n",
>>   payload[RESPONSE_ID]);
>>   break;
>>   }
>> @@ -618,7 +622,8 @@ static int zforce_suspend(struct device *dev)
>>
>>   enable_irq_wake(client->irq);
>>   } else if (input->users) {
>> - dev_dbg(&client->dev, "suspend without being a wakeup 
>> source\n");
>> + dev_dbg(&client->dev,
>> + "suspend without being a wakeup source\n");
>>
>>   ret = zforce_stop(ts);
>>   if (ret)
>
--
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/

[PATCH] Staging: dwc2: core: coding style - indentation should use tabs

2013-09-25 Thread Luis Ortega Perez de Villar

Fixed coding style issue where lines are indented with spaces
instead of tabs.

Signed-off-by: Luis Ortega Perez de Villar 
---
 drivers/staging/dwc2/core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
index 06dae67..f8dfca1 100644
--- a/drivers/staging/dwc2/core.c
+++ b/drivers/staging/dwc2/core.c
@@ -2205,7 +2205,7 @@ int dwc2_set_param_phy_type(struct dwc2_hsotg *hsotg, int 
val)
 {
 #ifndef NO_FS_PHY_HW_CHECKS
int valid = 0;
-u32 hs_phy_type, fs_phy_type;
+   u32 hs_phy_type, fs_phy_type;
 #endif
int retval = 0;
 
@@ -2553,7 +2553,7 @@ int dwc2_set_param_ahbcfg(struct dwc2_hsotg *hsotg, int 
val)
hsotg->core_params->ahbcfg = val;
else
hsotg->core_params->ahbcfg = GAHBCFG_HBSTLEN_INCR4 <<
- GAHBCFG_HBSTLEN_SHIFT;
+   GAHBCFG_HBSTLEN_SHIFT;
return 0;
 }
 
-- 
1.7.9.5

--
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/

[Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM

Re: [Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM

Re: [Regression 3.14-rc2] drm/i915: Brightness adjustment is broken in 945GM

[PATCH] Staging: bcm: Qos: fixed braces' coding style

Re: [PATCH] Staging: bcm: Qos: fixed braces' coding style

[PATCH v2] Staging: bcm: Qos: fixed braces' coding style

[PATCH] staging: wlags49_h2: fix sparse warning "should it be static"

[PATCH 4/4] Input: zforce - reduce stack memory allocated to frames

[PATCH 3/4] Input: zforce - Remove unnecessary payload data checks

[PATCH 2/4] Input: zforce - fix lines exceeding 80 columns

[PATCH 1/4] Input: zforce - fix spelling errors

Input: zforce - fix various small issues

Re: [PATCH 2/4] Input: zforce - fix lines exceeding 80 columns

[PATCH] Staging: dwc2: core: coding style - indentation should use tabs

14 matches

Site Navigation

Mail list logo

Footer information