Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 10月, 2016 3 次提交
    • M
      [media] dvb-frontends: don't break long lines · 4bd69e7b
      由 Mauro Carvalho Chehab 提交于 
      Due to the 80-cols restrictions, and latter due to checkpatch
warnings, several strings were broken into multiple lines. This
is not considered a good practice anymore, as it makes harder
to grep for strings at the source code.

As we're right now fixing other drivers due to KERN_CONT, we need
to be able to identify what printk strings don't end with a "\n".
It is a way easier to detect those if we don't break long lines.

So, join those continuation lines.

The patch was generated via the script below, and manually
adjusted if needed.

</script>
use Text::Tabs;
while (<>) {
	if ($next ne "") {
		$c=$_;
		if ($c =~ /^\s+\"(.*)/) {
			$c2=$1;
			$next =~ s/\"\n$//;
			$n = expand($next);
			$funpos = index($n, '(');
			$pos = index($c2, '",');
			if ($funpos && $pos > 0) {
				$s1 = substr $c2, 0, $pos + 2;
				$s2 = ' ' x ($funpos + 1) . substr $c2, $pos + 2;
				$s2 =~ s/^\s+//;

				$s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne "");

				print unexpand("$next$s1\n");
				print unexpand("$s2\n") if ($s2 ne "");
			} else {
				print "$next$c2\n";
			}
			$next="";
			next;
		} else {
			print $next;
		}
		$next="";
	} else {
		if (m/\"$/) {
			if (!m/\\n\"$/) {
				$next=$_;
				next;
			}
		}
	}
	print $_;
}
</script>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      4bd69e7b
    • M
      [media] nxt6000: use pr_foo() macros instead of printk() · cc5ad2b6
      由 Mauro Carvalho Chehab 提交于 
      Replace printk() macros by their pr_foo() counterparts and
use pr_cont() for the continuation lines.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      cc5ad2b6
    • M
      [media] dvb-pll: use pr_foo() macros instead of printk() · 5479a582
      由 Mauro Carvalho Chehab 提交于 
      Replace printk() macros by their pr_foo() counterparts.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      5479a582
  3. 12 10月, 2016 1 次提交
  5. 22 9月, 2016 18 次提交
  7. 20 9月, 2016 2 次提交
  9. 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
  11. 31 8月, 2016 1 次提交
  13. 25 8月, 2016 2 次提交
  15. 24 8月, 2016 1 次提交
  17. 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
  19. 16 7月, 2016 8 次提交
  21. 13 7月, 2016 1 次提交
    • 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