Message ID | 1371440327-30512-1-git-send-email-horms+renesas@verge.net.au |
---|---|
State | New |
Headers | show |
Sorry, please ignore this, I realised that I have made an error when applying the second patch. On Mon, Jun 17, 2013 at 12:38:45PM +0900, Simon Horman wrote: > Hi Olof, Hi Arnd, > > As requested the first patch is now includes an ack from Greg Kroah-Hartman. > > I have included the r8a7790 change in this patch as it > depends on the first change in the pull-request but nothing else. > > This pull request will cause some conflicts though I believe all > of them are not difficult to resolve. The renesas-next-20130613 tag in > my tree illustrates how I have handled the conflicts with > both changes already in arm-soc and changes I intend to send > pull requests for in the near future. > > The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75: > > Linux 3.10-rc2 (2013-05-20 14:37:38 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-sh-sci-for-v3.11 > > for you to fetch changes up to fe0b1091e41e0acae8ddf2da2a5a36b6867ff012: > > ARM: shmobile: r8a7790: don't use external clock for SCIFs (2013-06-17 12:17:48 +0900) > > ---------------------------------------------------------------- > Renesas sh-sci updates for v3.11 > > HSCIF support by Ulrich Hecht. > > ---------------------------------------------------------------- > Ulrich Hecht (2): > serial: sh-sci: HSCIF support > ARM: shmobile: r8a7790: don't use external clock for SCIFs > > arch/arm/mach-shmobile/setup-r8a7790.c | 16 ++++- > drivers/tty/serial/sh-sci.c | 102 +++++++++++++++++++++++++++++--- > include/linux/serial_sci.h | 12 +++- > include/uapi/linux/serial_core.h | 3 + > 4 files changed, 120 insertions(+), 13 deletions(-) >
On Monday 17 June 2013, Simon Horman wrote: > - if (likely(baud && port->uartclk)) > - t = sci_scbrr_calc(s->cfg->scbrr_algo_id, baud, port->uartclk); > + if (likely(baud && port->uartclk)) { > + if (s->cfg->scbrr_algo_id == SCBRR_ALGO_6) { > + sci_baud_calc_hscif(baud, port->uartclk, &t, &srr, > + &cks); > + } else { > + t = sci_scbrr_calc(s->cfg->scbrr_algo_id, baud, > + port->uartclk); > + for (cks = 0; t >= 256 && cks <= 3; cks++) > + t >>= 2; > + } > + } This hunk causes build warnings in linux-next now: /git/arm-soc/drivers/tty/serial/sh-sci.c: In function 'sci_set_termios': /git/arm-soc/drivers/tty/serial/sh-sci.c:1942:37: warning: 'srr' may be used uninitialized in this function [-Wmaybe-uninitialized] serial_port_out(port, HSSRR, srr | HSCIF_SRE); ^ /git/arm-soc/drivers/tty/serial/sh-sci.c:1892:15: note: 'srr' was declared here unsigned int srr; ^ /git/arm-soc/drivers/tty/serial/sh-sci.c:1938:47: warning: 'cks' may be used uninitialized in this function [-Wmaybe-uninitialized] serial_port_out(port, SCSMR, (smr_val & ~3) | cks); ^ /git/arm-soc/drivers/tty/serial/sh-sci.c:1890:40: note: 'cks' was declared here unsigned int baud, smr_val, max_baud, cks; ^ Arnd
On Mon, Jun 17, 2013 at 02:54:48PM +0200, Arnd Bergmann wrote: > On Monday 17 June 2013, Simon Horman wrote: > > - if (likely(baud && port->uartclk)) > > - t = sci_scbrr_calc(s->cfg->scbrr_algo_id, baud, port->uartclk); > > + if (likely(baud && port->uartclk)) { > > + if (s->cfg->scbrr_algo_id == SCBRR_ALGO_6) { > > + sci_baud_calc_hscif(baud, port->uartclk, &t, &srr, > > + &cks); > > + } else { > > + t = sci_scbrr_calc(s->cfg->scbrr_algo_id, baud, > > + port->uartclk); > > + for (cks = 0; t >= 256 && cks <= 3; cks++) > > + t >>= 2; > > + } > > + } > > > This hunk causes build warnings in linux-next now: > > /git/arm-soc/drivers/tty/serial/sh-sci.c: In function 'sci_set_termios': > /git/arm-soc/drivers/tty/serial/sh-sci.c:1942:37: warning: 'srr' may be used uninitialized in this function [-Wmaybe-uninitialized] > serial_port_out(port, HSSRR, srr | HSCIF_SRE); > ^ > /git/arm-soc/drivers/tty/serial/sh-sci.c:1892:15: note: 'srr' was declared here > unsigned int srr; > ^ > /git/arm-soc/drivers/tty/serial/sh-sci.c:1938:47: warning: 'cks' may be used uninitialized in this function [-Wmaybe-uninitialized] > serial_port_out(port, SCSMR, (smr_val & ~3) | cks); > ^ > /git/arm-soc/drivers/tty/serial/sh-sci.c:1890:40: note: 'cks' was declared here > unsigned int baud, smr_val, max_baud, cks; Ulrich, could you please look into this?
On Tue, Jun 18, 2013 at 3:19 AM, Simon Horman <horms@verge.net.au> wrote: >> This hunk causes build warnings in linux-next now: >> >> /git/arm-soc/drivers/tty/serial/sh-sci.c: In function 'sci_set_termios': >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1942:37: warning: 'srr' may be used uninitialized in this function [-Wmaybe-uninitialized] >> serial_port_out(port, HSSRR, srr | HSCIF_SRE); >> ^ >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1892:15: note: 'srr' was declared here >> unsigned int srr; >> ^ >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1938:47: warning: 'cks' may be used uninitialized in this function [-Wmaybe-uninitialized] >> serial_port_out(port, SCSMR, (smr_val & ~3) | cks); >> ^ >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1890:40: note: 'cks' was declared here >> unsigned int baud, smr_val, max_baud, cks; > > Ulrich, could you please look into this? Hmmm... I get this warning with gcc 4.5, 4.6, and 4.8. Apparently gcc 4.7 is the only one that does not warn about this. Guess what I'm using... :( This is of course trivially fixed, but I have completely lost track of the transmogrifications this patch has been subjected to. What's the procedure? CU Uli
On Wed, Jun 19, 2013 at 10:46:51AM +0200, Ulrich Hecht wrote: > On Tue, Jun 18, 2013 at 3:19 AM, Simon Horman <horms@verge.net.au> wrote: > >> This hunk causes build warnings in linux-next now: > >> > >> /git/arm-soc/drivers/tty/serial/sh-sci.c: In function 'sci_set_termios': > >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1942:37: warning: 'srr' may be used uninitialized in this function [-Wmaybe-uninitialized] > >> serial_port_out(port, HSSRR, srr | HSCIF_SRE); > >> ^ > >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1892:15: note: 'srr' was declared here > >> unsigned int srr; > >> ^ > >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1938:47: warning: 'cks' may be used uninitialized in this function [-Wmaybe-uninitialized] > >> serial_port_out(port, SCSMR, (smr_val & ~3) | cks); > >> ^ > >> /git/arm-soc/drivers/tty/serial/sh-sci.c:1890:40: note: 'cks' was declared here > >> unsigned int baud, smr_val, max_baud, cks; > > > > Ulrich, could you please look into this? > > Hmmm... I get this warning with gcc 4.5, 4.6, and 4.8. Apparently gcc > 4.7 is the only one that does not warn about this. Guess what I'm > using... :( > > This is of course trivially fixed, but I have completely lost track of > the transmogrifications this patch has been subjected to. What's the > procedure? Hi Ulrich, perhaps the best way forward would be for you to post an incremental patch on top of either the sh-sci branch or renesas-next-20130618 tag of my renesas tree on kernel.org.
On Wednesday 19 June 2013, Simon Horman wrote: > > This is of course trivially fixed, but I have completely lost track of > > the transmogrifications this patch has been subjected to. What's the > > procedure? > > Hi Ulrich, > > perhaps the best way forward would be for you to post an incremental patch > on top of either the sh-sci branch or renesas-next-20130618 tag of > my renesas tree on kernel.org. I'm not sure where we stand on this series at the moment. Should I pull v3, has Olof already pulled it, or should I wait for an update? Arnd
On Wed, Jun 19, 2013 at 05:08:46PM +0200, Arnd Bergmann wrote: > On Wednesday 19 June 2013, Simon Horman wrote: > > > This is of course trivially fixed, but I have completely lost track of > > > the transmogrifications this patch has been subjected to. What's the > > > procedure? > > > > Hi Ulrich, > > > > perhaps the best way forward would be for you to post an incremental patch > > on top of either the sh-sci branch or renesas-next-20130618 tag of > > my renesas tree on kernel.org. > > I'm not sure where we stand on this series at the moment. Should > I pull v3, has Olof already pulled it, or should I wait for an > update? Hi Arnd, my preference is for you to wait for an update. In order to move things forwards I will post a proposed fix shortly. I believe that the warnings are for conditions that can never occur and thus in my patch I will propose initialising the variables that are flagged as being used uninitialised.