Re: [patch] Staging: sb105x: info leak in mp_get_count()
On Mon, Nov 04, 2013 at 10:01:00AM +0300, Dan Carpenter wrote: I've dropped most of the people from the CC list. On Sun, Nov 03, 2013 at 08:31:50PM -0800, Josh Triplett wrote: On Mon, Nov 04, 2013 at 02:11:50AM +0300, Dan Carpenter wrote: On Sun, Nov 03, 2013 at 10:28:02AM -0800, Josh Triplett wrote: On Tue, Oct 29, 2013 at 11:01:43PM +0300, Dan Carpenter wrote: The icount.reserved[] array isn't initialized so it leaks stack information to userspace. Reported-by: Nico Golde n...@ngolde.de Reported-by: Fabian Yamaguchi f...@goesec.de Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Reviewed-by: Josh Triplett j...@joshtriplett.org Also, you don't quite have the patch format right here; you should have a --- line after the commit mesage, followed by a diffstat. Did you use git format-patch to generate this patch? I normally don't include the diffstat. Which tools care about that? Human wetware. :) It isn't required by any tools. The --- is, though, to produce something applicable by git. That's really weird. I've been using the same scripts for years and no one has complained before. The patch applies fine with `git am` for me. I'm using git version 1.7.10.4. I stand corrected. I was under the impression that the --- was required to mark the end of the commit message, but sure enough, git am seems to accept it. Reading the git am manpage, it says that a line starting with diff - will also indicate the end of the commit message and start of the patch. It still isn't the conventional format produced by git format-patch, which I'd recommend matching for ease of human consumption, but nonetheless it apparently works. - Josh Triplett ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ft1000: fixed a few styling issues
Dan Carpenter wrote: On Sun, Nov 03, 2013 at 04:20:38PM +0200, Aldo Iljazi wrote: Fixed a few styling issues, specifically: Gar... No one wants to read that changelog. That was over 700 lines of repeated text. regards, dan carpenter You are right. I'll be careful next time. Should I resend? -- Aldo Iljazi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ft1000: fixed a few styling issues
On Mon, Nov 04, 2013 at 10:17:04AM +0200, Aldo Iljazi wrote: Dan Carpenter wrote: On Sun, Nov 03, 2013 at 04:20:38PM +0200, Aldo Iljazi wrote: Fixed a few styling issues, specifically: Gar... No one wants to read that changelog. That was over 700 lines of repeated text. regards, dan carpenter You are right. I'll be careful next time. Should I resend? Yes, please. Also could you indent all the numbers one tab? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ft1000: fixed a few styling issues
On Mon, Nov 04, 2013 at 02:15:22PM +0200, Aldo Iljazi wrote: Fixed the following styling issues: Line 30: Removed space before open square bracket '[' Lines 31 to 155: Moved the commas that were in the start of the lines, to the end of the lines. Inserted spaces after the commas. Inserted a one tab indentation to each line. Signed-off-by: Aldo Iljazi m...@aldo.io Looks nice. Thank you. Reviewed-by: Dan Carpenter dan.carpen...@oracle.com regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ft1000: fixed a few styling issues
Dan Carpenter wrote: On Mon, Nov 04, 2013 at 02:15:22PM +0200, Aldo Iljazi wrote: Fixed the following styling issues: Line 30: Removed space before open square bracket '[' Lines 31 to 155: Moved the commas that were in the start of the lines, to the end of the lines. Inserted spaces after the commas. Inserted a one tab indentation to each line. Signed-off-by: Aldo Iljazi m...@aldo.io Looks nice. Thank you. Reviewed-by: Dan Carpenter dan.carpen...@oracle.com regards, dan carpenter I am sorry for the previous mess. I am new to this. -- Aldo Iljazi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ft1000: fixed a few styling issues
On Monday 04 November 2013, Aldo Iljazi wrote:
Fixed the following styling issues:
Line 30:
Removed space before open square bracket '['
Lines 31 to 155:
Moved the commas that were in the start of the lines, to the end of the
lines. Inserted spaces after the commas.
Inserted a one tab indentation to each line.
Signed-off-by: Aldo Iljazi m...@aldo.io
---
drivers/staging/ft1000/ft1000-pcmcia/boot.h | 252
++-- 1 file changed, 126 insertions(+), 126
deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
b/drivers/staging/ft1000/ft1000-pcmcia/boot.h index 9dce54e..915165e 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
+++ b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
@@ -27,132 +27,132 @@
#define _BOOTH_
// Official bootloader
-static unsigned char bootimage [] = {
-0x00,0x00,0x01,0x5E,0x00,0x00
-,0x00,0x00,0x00,0x00,0x02,0xD7
-,0x00,0x00,0x01,0x5E,0x46,0xB3
-,0xE6,0x02,0x00,0x98,0xE6,0x8C
-,0x00,0x98,0xFB,0x92,0xFF,0xFF
-,0x98,0xFB,0x94,0xFF,0xFF,0x98
-,0xFB,0x06,0x08,0x00,0x98,0xFB
-,0x96,0x84,0x00,0x98,0xFB,0x08
-,0x1C,0x00,0x98,0xFB,0x51,0x25
-,0x10,0x1C,0x00,0xE6,0x51,0x01
-,0x07,0xFD,0x4C,0xFF,0x20,0xF5
-,0x51,0x02,0x20,0x08,0x00,0x4C
-,0xFF,0x20,0x3C,0x00,0xC0,0x64
-,0x98,0xC0,0x66,0x98,0xC0,0x68
-,0x98,0xC0,0x6A,0x98,0xC0,0x6C
-,0x98,0x90,0x08,0x90,0x09,0x90
-,0x0A,0x90,0x0B,0x90,0x0C,0x90
-,0x0D,0x90,0x0E,0x90,0x0F,0x90
-,0x04,0x90,0x06,0xFB,0x51,0x22
-,0x16,0x08,0x03,0xFB,0x51,0x52
-,0x16,0x08,0x04,0xFB,0x51,0x24
-,0x2B,0x08,0x06,0xFB,0x51,0x54
-,0x2B,0x08,0x07,0xFB,0x51,0x24
-,0x2B,0x08,0x09,0xFB,0x51,0x54
-,0x2B,0x08,0x0A,0xFB,0x51,0x12
-,0x16,0x08,0x0C,0xFB,0x51,0x52
-,0x16,0x08,0x0D,0x78,0x00,0x00
-,0x00,0x16,0x00,0x00,0xEC,0x31
-,0xAE,0x00,0x00,0x81,0x4C,0x0F
-,0xE6,0x43,0xFF,0xEC,0x31,0x4E
-,0x00,0x00,0x91,0xEC,0x31,0xAE
-,0x00,0x00,0x91,0x4C,0x0F,0xE6
-,0x43,0xFF,0xEC,0x31,0x5E,0x00
-,0x00,0xA1,0xEB,0x31,0x08,0x00
-,0x00,0xA6,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x3C,0x00,0xEB,0x31
-,0x08,0x00,0x00,0xA8,0x76,0xFE
-,0xFE,0x08,0xEB,0x31,0x08,0x20
-,0x00,0x00,0x76,0xFF,0xFF,0x18
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x26,0x10,0x04,0x10,0xF5,0x3C
-,0x01,0x3C,0x00,0x08,0x01,0x12
-,0x3C,0x11,0x3C,0x00,0x08,0x01
-,0x0B,0x08,0x00,0x6D,0xEC,0x31
-,0xAE,0x20,0x00,0x06,0xED,0x4D
-,0x08,0x00,0x00,0x67,0x80,0x6F
-,0x00,0x01,0x0B,0x6F,0x00,0x02
-,0x2E,0x76,0xEE,0x01,0x48,0x06
-,0x01,0x39,0xED,0x4D,0x18,0x00
-,0x02,0xED,0x4D,0x08,0x00,0x04
-,0x14,0x06,0xA4,0xED,0x31,0x22
-,0x00,0x00,0xAC,0x76,0xEE,0x07
-,0x48,0x6D,0x22,0x01,0x1E,0x08
-,0x01,0x58,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x06,0xFF,0xBA,0x3C
-,0x00,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x30,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x00
-,0x00,0xA2,0x91,0x00,0x9C,0x3C
-,0x80,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0xB6,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0xA0,0x31,0x20,0x00
-,0x06,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0x68,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0x48,0x04,0xEB,0x31
-,0x08,0x20,0x00,0x04,0xEB,0x31
-,0x18,0x20,0x00,0x02,0x3C,0x11
-,0xEB,0x31,0x18,0x20,0x00,0x00
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x04,0x10,0xF7,0xED,0x31,0x08
-,0x20,0x00,0x02,0x66,0x00,0x6F
-,0x00,0x01,0x16,0x76,0xEE,0x06
-,0x48,0x4A,0x1E,0x48,0x04,0xED
-,0x31,0x08,0x20,0x00,0x04,0xEB
-,0x31,0x08,0x00,0x00,0xA4,0x48
-,0x04,0xED,0x31,0x08,0x20,0x00
-,0x04,0xEB,0x31,0x08,0x00,0x00
-,0xA2,0x48,0x04,0x20,0x20,0x4A
-,0x7C,0x46,0x82,0x50,0x05,0x50
-,0x15,0xB5,0x1E,0x98,0xED,0x31
-,0x08,0x00,0x00,0xA8,0x10,0x47
-,0x3B,0x2C,0x01,0xDB,0x40,0x11
-,0x98,0xC1,0x1E,0x98,0x10,0x07
-,0x30,0xF9,0x40,0x07,0x18,0x98
-,0x2A,0x10,0xEB,0x31,0x08,0x00
-,0x00,0xA8,0xA4,0x1E,0x98,0xBB
-,0x1E,0x98,0x50,0x14,0x50,0x04
-,0x46,0x83,0x48,0x04,0x02,0x01
-,0x00,0x50,0x05,0x50,0x15,0x10
-,0x87,0x3F,0x90,0x2B,0x18,0x01
-,0x00,0xC0,0x31,0x00,0x00,0xAE
-,0xDF,0x41,0x00,0x08,0x00,0x1A
-,0x42,0x11,0x67,0x01,0xDF,0x41
-,0x02,0x08,0x00,0x10,0x42,0x11
-,0x62,0x01,0xB4,0x43,0x4A,0x68
-,0x50,0x14,0x50,0x04,0x24,0x10
-,0x48,0x04,0xF2,0x31,0x00,0x01
-,0x00,0x00,0xAE,0xF6,0x31,0x00
-,0x01,0x00,0x00,0xAE,0x62,0xE4
-,0xE5,0x61,0x04,0x48,0x04,0xE5
-,0x63,0x05,0x48,0x04,0x20,0x20
-,0x00,0x00,0x00,0x00
+static unsigned char bootimage[] =
[PATCH] Staging: dgnc: dgnc_cls.c: fixed a brace coding style issue
Fixed a coding style issue.
Signed-off-by: Simon Crequer simoncreq...@gmail.com
---
drivers/staging/dgnc/dgnc_cls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index 117e158..357d000 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -1305,9 +1305,9 @@ static uint cls_get_uart_bytes_left(struct channel_t *ch)
/* Determine whether the Transmitter is empty or not */
if (!(lsr UART_LSR_TEMT)) {
- if (ch-ch_flags CH_TX_FIFO_EMPTY) {
+ if (ch-ch_flags CH_TX_FIFO_EMPTY)
tasklet_schedule(ch-ch_bd-helper_tasklet);
- }
+
left = 1;
}
else {
--
1.8.2.1 (Apple Git-45)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ft1000: fixed a few styling issues
On Mon, Nov 04, 2013 at 01:32:20PM +0100, Ondrej Zary wrote: Shouldn't this be removed from the code, converted to a binary file and loaded by the kernel firmware loader instead? I have no idea. We may as well apply this and do that later unless someone wants to jump on it before 3.13-rc1 is released. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch] Staging: sb105x: info leak in mp_get_count()
On Mon, Nov 04, 2013 at 12:08:50PM -0500, Steven Rostedt wrote: On Mon, 4 Nov 2013 02:11:50 +0300 Dan Carpenter dan.carpen...@oracle.com wrote: On Sun, Nov 03, 2013 at 10:28:02AM -0800, Josh Triplett wrote: On Tue, Oct 29, 2013 at 11:01:43PM +0300, Dan Carpenter wrote: The icount.reserved[] array isn't initialized so it leaks stack information to userspace. Reported-by: Nico Golde n...@ngolde.de Reported-by: Fabian Yamaguchi f...@goesec.de Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Reviewed-by: Josh Triplett j...@joshtriplett.org Also, you don't quite have the patch format right here; you should have a --- line after the commit mesage, followed by a diffstat. Did you use git format-patch to generate this patch? I normally don't include the diffstat. Which tools care about that? As Josh already replied, it is most helpful for the human reviewer. Linus uses it all the time to see how intrusive a patch may be. Yes, please always include a diffstat for any patch you send. It sounds simple to add a diffstat but it's sort of a pain to redo my workflow... I don't use git commits. If I need to make the same change to multiple files then I end up appending the diff to the end of an existing email and tweaking the diff hunks together by hand. I guess I could writing an append_diff.sh script which munges the diffstat but it seems like it might be error prone. I'll take a look though. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] imx-drm: Add mx6 hdmi transmitter support
On Thu, Oct 31, 2013 at 4:48 PM, Matt Sealey n...@bakuhatsu.net wrote: On Thu, Oct 31, 2013 at 4:08 PM, Fabio Estevam feste...@gmail.com wrote: On Thu, Oct 31, 2013 at 7:00 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Interesting. With the monitor I have tested I am not able to see this magenta line. Monitor or TV? Beware of overscans which will hide this effect. I used a PC monitor on my tests. I sent v5 using 4 as the number of loops according to Troy's results. Stop, stop, stop! Has nobody noticed this register isn't described in the reference manual? What does it even do? How can we quantify Troy's results by just throwing numbers at it and then saying no magenta line here? Okay a little worry here is that the last time I kicked an HDMI transmitter around a huge magenta line was basically a side effect of doing the following things that weren't necessary to spec; either enabling audio infoframes when in DVI mode (the transmitter doesn't care if you're in DVI mode, it will shove audio out there anyway) or some really weird timing effects, almost a race condition, if you're generating infoframes at the wrong points (such as SPD or suchlike) - sometimes the monitor will figure it out. Sometimes not. The easiest case is enable HDMI transmitter mode on a monitor that does not actually have an HDMI-spec-capable decoder on it. If you have an HDMI to DVI cable, you have this. If you have an older or cheaper monitor with no speakers, this can also be entirely possible. You almost never see this on TVs, but you DO see it on maybe the 3rd HDMI port on some TVs (where audio mysteriously doesn't work, but it works fine on the other two ports). I wrote a little treatise on this about those Radeon HDMI-DVI dongles to the DRM list, it's the same deal. Essentially there's not a lot of point enabling HDMI mode if your monitor doesn't support audio, and if you do enable it, you HAVE to make sure your AVI InfoFrames are being sent (but, obviously, don't send AVI InfoFrames in DVI mode or all you'll see is a magenta line if it extends the blanking timings, and the monitor doesn't handle it). I notice the register enums have DVI mode in there, also I saw a weird case where the CEA modes in the kernel that got introduced with DRM had a couple backwards polarities, and one or two of them on some monitors that specified them would give the magenta line (and on others that had the same VIC in their CEA list) would work fine.. I guess they had more resilient logic to detect things like the wrong HSYNC polarity. What modes are being set here (are they derived from VIC codes or actual detail timings?) that cause the magenta line? The actual fix may be to go through the HDMI spec and fix the CEA mode definitions that correspond to each VIC and be sure they're accurate. Hammering the register 4 times probably just resolves it by approaching what seems like a more correct waveform by constantly re-starting the transmission path. That might explain why some values work for some and some don't for others. I'm concerned that the real problem isn't addressed (and I did see a patch that fiddled a polarity value earlier..) and the actual effects of these bits is not actually documented in the manuals. Fabio, Shawn, could you go so far as to bring this up with the i.MX guys responsible for documentation or find the original transmitter IP specs, or find the two pages missing from the manual? This is a really important register if the definition in the source code is to be believed (do we believe it?) if working HDMI output is to be achieved. Thanks, Matt Sealey n...@bakuhatsu.net ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] imx-drm: Add mx6 hdmi transmitter support
On Mon, Nov 4, 2013 at 9:20 PM, Matt Sealey n...@bakuhatsu.net wrote: Fabio, Shawn, could you go so far as to bring this up with the i.MX guys responsible for documentation or find the original transmitter IP specs, or find the two pages missing from the manual? This is a really The multiple writes comes from the following erratum: ERR005173 HDMI: Clarification on HDMI programming procedure to avoid FIFO overflow Regards, Fabio Estevam ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
