“5e98743cfad0173f8748bdcee322621df37dcc4c”上不存在“git@gitcode.net:openeuler/kernel.git”
  1. 22 9月, 2016 4 次提交
  2. 20 9月, 2016 2 次提交
  3. 06 9月, 2016 2 次提交
    • M
      [media] mb86a20s: fix demod settings · 505a0ea7
      Mauro Carvalho Chehab 提交于
      With the current settings, only one channel locks properly.
      That's likely because, when this driver was written, Brazil
      were still using experimental transmissions.
      
      Change it to reproduce the settings used by the newer drivers.
      That makes it lock on other channels.
      
      Tested with both PixelView SBTVD Hybrid (cx231xx-based) and
      C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      505a0ea7
    • M
      [media] mb86a20s: fix the locking logic · dafb65fb
      Mauro Carvalho Chehab 提交于
      On this frontend, it takes a while to start output normal
      TS data. That only happens on state S9. On S8, the TS output
      is enabled, but it is not reliable enough.
      
      However, the zigzag loop is too fast to let it sync.
      
      As, on practical tests, the zigzag software loop doesn't
      seem to be helping, but just slowing down the tuning, let's
      switch to hardware algorithm, as the tuners used on such
      devices are capable of work with frequency drifts without
      any help from software.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      dafb65fb
  4. 25 8月, 2016 2 次提交
  5. 24 8月, 2016 1 次提交
  6. 04 8月, 2016 1 次提交
    • A
      drivers/media/dvb-frontends/cxd2841er.c: avoid misleading gcc warning · bb9bd878
      Arnd Bergmann 提交于
      The addition of jump label support in dynamic_debug caused an unexpected
      warning in exactly one file in the kernel:
      
        drivers/media/dvb-frontends/cxd2841er.c: In function 'cxd2841er_tune_tc':
        include/linux/dynamic_debug.h:134:3: error: 'carrier_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
           __dynamic_dev_dbg(&descriptor, dev, fmt, \
           ^~~~~~~~~~~~~~~~~
        drivers/media/dvb-frontends/cxd2841er.c:3177:11: note: 'carrier_offset' was declared here
          int ret, carrier_offset;
                   ^~~~~~~~~~~~~~
      
      The problem seems to be that the compiler gets confused by the extra
      conditionals in static_branch_unlikely, to the point where it can no
      longer keep track of which branches have already been taken, and it
      doesn't realize that this variable is now always initialized when it
      gets used.
      
      I have done lots of randconfig kernel builds and could not find any
      other file with this behavior, so I assume it's a rare enough glitch
      that we don't need to change the jump label support but instead just
      work around the warning in the driver.
      
      To achieve that, I'm moving the check for the return value into the
      switch() statement, which is an obvious transformation, but is enough to
      un-confuse the compiler here.  The resulting code is not as nice to
      read, but at least we retain the behavior of warning if it gets changed
      to actually access an uninitialized carrier offset value in the future.
      
      Link: http://lkml.kernel.org/r/20160713204342.1221511-1-arnd@arndb.deSigned-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NAbylay Ospan <aospan@netup.ru>
      Cc: Sergey Kozlov <serjk@netup.ru>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Jason Baron <jbaron@akamai.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bb9bd878
  7. 16 7月, 2016 8 次提交
  8. 13 7月, 2016 2 次提交
    • S
      [media] ascot2e: Fix I2C message size check · cd829821
      Saso Slavicic 提交于
      Tuning a card with Sony ASCOT2E produces the following error:
      
      	kernel: i2c i2c-9: wr reg=0006: len=11 is too big!
      
      MAX_WRITE_REGSIZE is defined as 10, buf[MAX_WRITE_REGSIZE + 1] buffer is
      used in ascot2e_write_regs().
      
      The problem is that exactly 10 bytes are written in ascot2e_set_params():
      
      	/* Set BW_OFFSET (0x0F) value from parameter table */
      	data[9] = ascot2e_sett[tv_system].bw_offset;
      	ascot2e_write_regs(priv, 0x06, data, 10);
      
      The test in write_regs is as follows:
      
      	if (len + 1 >= sizeof(buf))
      
      10 + 1 = 11 and that would be exactly the size of buf. Since 10 bytes +
      buf[0] = reg would seem to fit into buf[], this shouldn't be an error.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      cd829821
    • H
      [media] af9033: fix compiler warnings · c93350a6
      Hans Verkuil 提交于
      Fix two warnings:
      
      af9033.c: In function 'af9033_read_status':
      af9033.c:883:25: warning: 'snr_lut' may be used uninitialized in this function [-Wmaybe-uninitialized]
         const struct val_snr *snr_lut;
                               ^
      af9033.c:952:25: warning: 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized]
         c->cnr.stat[0].svalue = tmp;
                               ^
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      c93350a6
  9. 09 7月, 2016 17 次提交
  10. 24 6月, 2016 1 次提交
    • M
      dib0090: comment out the unused tables · cf47faca
      Mauro Carvalho Chehab 提交于
      Those tables are currently unused, so comment them out:
      
      drivers/media/dvb-frontends/dib0090.c:852:18: warning: 'rf_ramp_pwm_sband' defined but not used [-Wunused-const-variable=]
       static const u16 rf_ramp_pwm_sband[] = {
                        ^~~~~~~~~~~~~~~~~
      drivers/media/dvb-frontends/dib0090.c:800:18: warning: 'bb_ramp_pwm_boost' defined but not used [-Wunused-const-variable=]
       static const u16 bb_ramp_pwm_boost[] = {
                        ^~~~~~~~~~~~~~~~~
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      cf47faca