03 Jul, 2018

1 commit

  • commit 76d81243a487c09619822ef8e7201a756e58a87d upstream.

    As warned by smatch:
    drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'.
    Locked on: line 288
    line 295
    line 306
    line 314
    Unlocked on: line 303

    The lock implementation for get event is wrong, as, if an
    interrupt occurs, down_interruptible() will fail, and the
    routine will call up() twice when userspace calls the ioctl
    again.

    The bad code is there since when Linux migrated to git, in
    2005.

    Cc: stable@vger.kernel.org
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Mauro Carvalho Chehab
     

25 May, 2018

1 commit

  • [ Upstream commit a145f64c6107d3aa5a7cec9f8977d04ac2a896c9 ]

    Returning -EINVAL when an ioctl is not implemented is a very
    bad idea, as it is hard to distinguish from other error
    contitions that an ioctl could lead. Replace it by its
    right error code: -ENOTTY.

    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Mauro Carvalho Chehab
     

17 Dec, 2017

2 commits

  • commit b1cb7372fa822af6c06c8045963571d13ad6348b upstream.

    dvb_frontend_invoke_release() may free the frontend struct.
    So, the free logic can't update it anymore after calling it.

    That's OK, as __dvb_frontend_free() is called only when the
    krefs are zeroed, so nobody is using it anymore.

    That should fix the following KASAN error:

    The KASAN report looks like this (running on kernel 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+)):
    ==================================================================
    BUG: KASAN: use-after-free in __dvb_frontend_free+0x113/0x120
    Write of size 8 at addr ffff880067d45a00 by task kworker/0:1/24

    CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc5-43687-g06ab8a23e0e6 #545
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: usb_hub_wq hub_event
    Call Trace:
    __dump_stack lib/dump_stack.c:16
    dump_stack+0x292/0x395 lib/dump_stack.c:52
    print_address_description+0x78/0x280 mm/kasan/report.c:252
    kasan_report_error mm/kasan/report.c:351
    kasan_report+0x23d/0x350 mm/kasan/report.c:409
    __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
    __dvb_frontend_free+0x113/0x120 drivers/media/dvb-core/dvb_frontend.c:156
    dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
    dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
    dvb_usb_adapter_frontend_exit+0xd6/0x160 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
    dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
    dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
    dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
    usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
    __device_release_driver drivers/base/dd.c:861
    device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
    device_release_driver+0x1e/0x30 drivers/base/dd.c:918
    bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
    device_del+0x5c4/0xab0 drivers/base/core.c:1985
    usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
    usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
    hub_port_connect drivers/usb/core/hub.c:4754
    hub_port_connect_change drivers/usb/core/hub.c:5009
    port_event drivers/usb/core/hub.c:5115
    hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
    process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
    worker_thread+0x221/0x1850 kernel/workqueue.c:2253
    kthread+0x363/0x440 kernel/kthread.c:231
    ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

    Allocated by task 24:
    save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
    save_stack+0x43/0xd0 mm/kasan/kasan.c:447
    set_track mm/kasan/kasan.c:459
    kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
    kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
    kmalloc ./include/linux/slab.h:493
    kzalloc ./include/linux/slab.h:666
    dtt200u_fe_attach+0x4c/0x110 drivers/media/usb/dvb-usb/dtt200u-fe.c:212
    dtt200u_frontend_attach+0x35/0x80 drivers/media/usb/dvb-usb/dtt200u.c:136
    dvb_usb_adapter_frontend_init+0x32b/0x660 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286
    dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86
    dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162
    dvb_usb_device_init+0xf73/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277
    dtt200u_usb_probe+0xa1/0xe0 drivers/media/usb/dvb-usb/dtt200u.c:155
    usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
    really_probe drivers/base/dd.c:413
    driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
    __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
    bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
    __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
    device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
    bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
    device_add+0xd0b/0x1660 drivers/base/core.c:1835
    usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
    generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
    usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
    really_probe drivers/base/dd.c:413
    driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
    __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
    bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
    __device_attach+0x26b/0x3c0 drivers/base/dd.c:710
    device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
    bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
    device_add+0xd0b/0x1660 drivers/base/core.c:1835
    usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
    hub_port_connect drivers/usb/core/hub.c:4903
    hub_port_connect_change drivers/usb/core/hub.c:5009
    port_event drivers/usb/core/hub.c:5115
    hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
    process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
    worker_thread+0x221/0x1850 kernel/workqueue.c:2253
    kthread+0x363/0x440 kernel/kthread.c:231
    ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

    Freed by task 24:
    save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
    save_stack+0x43/0xd0 mm/kasan/kasan.c:447
    set_track mm/kasan/kasan.c:459
    kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
    slab_free_hook mm/slub.c:1390
    slab_free_freelist_hook mm/slub.c:1412
    slab_free mm/slub.c:2988
    kfree+0xf6/0x2f0 mm/slub.c:3919
    dtt200u_fe_release+0x3c/0x50 drivers/media/usb/dvb-usb/dtt200u-fe.c:202
    dvb_frontend_invoke_release.part.13+0x1c/0x30 drivers/media/dvb-core/dvb_frontend.c:2790
    dvb_frontend_invoke_release drivers/media/dvb-core/dvb_frontend.c:2789
    __dvb_frontend_free+0xad/0x120 drivers/media/dvb-core/dvb_frontend.c:153
    dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
    dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
    dvb_usb_adapter_frontend_exit+0xd6/0x160 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
    dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
    dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
    dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
    usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
    __device_release_driver drivers/base/dd.c:861
    device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
    device_release_driver+0x1e/0x30 drivers/base/dd.c:918
    bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
    device_del+0x5c4/0xab0 drivers/base/core.c:1985
    usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
    usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
    hub_port_connect drivers/usb/core/hub.c:4754
    hub_port_connect_change drivers/usb/core/hub.c:5009
    port_event drivers/usb/core/hub.c:5115
    hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
    process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
    worker_thread+0x221/0x1850 kernel/workqueue.c:2253
    kthread+0x363/0x440 kernel/kthread.c:231
    ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

    The buggy address belongs to the object at ffff880067d45500
    which belongs to the cache kmalloc-2048 of size 2048
    The buggy address is located 1280 bytes inside of
    2048-byte region [ffff880067d45500, ffff880067d45d00)
    The buggy address belongs to the page:
    page:ffffea00019f5000 count:1 mapcount:0 mapping: (null)
    index:0x0 compound_mapcount: 0
    flags: 0x100000000008100(slab|head)
    raw: 0100000000008100 0000000000000000 0000000000000000 00000001000f000f
    raw: dead000000000100 dead000000000200 ffff88006c002d80 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
    ffff880067d45900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ffff880067d45980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ffff880067d45a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ^
    ffff880067d45a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ffff880067d45b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================

    Fixes: ead666000a5f ("media: dvb_frontend: only use kref after initialized")

    Reported-by: Andrey Konovalov
    Suggested-by: Matthias Schwarzott
    Tested-by: Andrey Konovalov
    Signed-off-by: Mauro Carvalho Chehab
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Mauro Carvalho Chehab
     
  • commit 62229de19ff2b7f3e0ebf4d48ad99061127d0281 upstream.

    Follow-up to: ead666000a5f ("media: dvb_frontend: only use kref after initialized")

    The aforementioned commit fixed refcount OOPSes when demod driver attaching
    succeeded but tuner driver didn't. However, the use count of the attached
    demod drivers don't go back to zero and thus couldn't be cleanly unloaded.
    Improve on this by calling dvb_frontend_invoke_release() in
    __dvb_frontend_free() regardless of fepriv being NULL, instead of returning
    when fepriv is NULL. This is safe to do since _invoke_release() will check
    for passed pointers being valid before calling the .release() function.

    [mchehab@s-opensource.com: changed the logic a little bit to reduce
    conflicts with another bug fix patch under review]
    Fixes: ead666000a5f ("media: dvb_frontend: only use kref after initialized")
    Signed-off-by: Daniel Scheller
    Signed-off-by: Mauro Carvalho Chehab
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Daniel Scheller
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

12 Oct, 2017

1 commit

  • As reported by Laurent, when a DVB frontend need to register
    two drivers (e. g. a tuner and a demod), if the second driver
    fails to register (for example because it was not compiled),
    the error handling logic frees the frontend by calling
    dvb_frontend_detach(). That used to work fine, but changeset
    1f862a68df24 ("[media] dvb_frontend: move kref to struct dvb_frontend")
    added a kref at struct dvb_frontend. So, now, instead of just
    freeing the data, the error handling do a kref_put().

    That works fine only after dvb_register_frontend() succeeds.

    While it would be possible to add a helper function that
    would be initializing earlier the kref, that would require
    changing every single DVB frontend on non-trivial ways, and
    would make frontends different than other drivers.

    So, instead of doing that, let's focus on the real issue:
    only call kref_put() after kref_init(). That's easy to
    check, as, when the dvb frontend is successfuly registered,
    it will allocate its own private struct. So, if such
    struct is allocated, it means that it is safe to use
    kref_put(). If not, then nobody is using yet the frontend,
    and it is safe to just deallocate it.

    Fixes: 1f862a68df24 ("[media] dvb_frontend: move kref to struct dvb_frontend")

    Reported-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     

05 Sep, 2017

3 commits


28 Aug, 2017

2 commits

  • GIT_AUTHOR_NAME=Colin King
    GIT_AUTHOR_EMAIL=colin.king@canonical.com

    In a previous commit, we added FE_NONE as an unknown fe_status.
    Initialize variable s to FE_NONE instead of the more opaque value 0.

    Signed-off-by: Colin Ian King
    Reviewed-by: Shuah Khan
    Signed-off-by: Mauro Carvalho Chehab

    Colin Ian King
     
  • The fe_status variable s is not initialized meaning it can have any
    random garbage status. This could be problematic if fe->ops.tune is
    false as s is not updated by the call to fe->ops.tune() and a
    subsequent check on the change status will using a garbage value.
    Fix this by adding FE_NONE to the enum fe_status and initializing
    s to this.

    Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")

    Signed-off-by: Colin Ian King
    Reviewed-by: Shuah Khan
    Signed-off-by: Mauro Carvalho Chehab

    Colin Ian King
     

21 Jul, 2017

19 commits


17 Jul, 2017

1 commit

  • Linux v4.13-rc1

    * tag 'v4.13-rc1': (11136 commits)
    Linux v4.13-rc1
    random: reorder READ_ONCE() in get_random_uXX
    random: suppress spammy warnings about unseeded randomness
    replace incorrect strscpy use in FORTIFY_SOURCE
    kmod: throttle kmod thread limit
    kmod: add test driver to stress test the module loader
    MAINTAINERS: give kmod some maintainer love
    xtensa: use generic fb.h
    fault-inject: add /proc//fail-nth
    fault-inject: simplify access check for fail-nth
    fault-inject: make fail-nth read/write interface symmetric
    fault-inject: parse as natural 1-based value for fail-nth write interface
    fault-inject: automatically detect the number base for fail-nth write interface
    kernel/watchdog.c: use better pr_fmt prefix
    MAINTAINERS: move the befs tree to kernel.org
    lib/atomic64_test.c: add a test that atomic64_inc_not_zero() returns an int
    mm: fix overflow check in expand_upwards()
    ubifs: Set double hash cookie also for RENAME_EXCHANGE
    ubifs: Massage assert in ubifs_xattr_set() wrt. init_xattrs
    ubifs: Don't leak kernel memory to the MTD
    ...

    Mauro Carvalho Chehab
     

07 Jul, 2017

1 commit

  • Pull media updates from Mauro Carvalho Chehab:

    - addition of fwnode support at V4L2 core

    - addition of a few more SDR formats

    - new imx driver to support i.MX6 cameras

    - new driver for Qualcon venus codecs

    - new I2C sensor drivers: dw9714, max2175, ov13858, ov5640

    - new CEC driver: stm32-cec

    - some improvements to DVB frontend documentation and a few fixups

    - several driver improvements and fixups

    * tag 'media/v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (361 commits)
    [media] media: entity: Catch unbalanced media_pipeline_stop calls
    [media] media/uapi/v4l: clarify cropcap/crop/selection behavior
    [media] v4l2-ioctl/exynos: fix G/S_SELECTION's type handling
    [media] vimc: sen: Declare vimc_sen_video_ops as static
    [media] vimc: sca: Add scaler
    [media] vimc: deb: Add debayer filter
    [media] vimc: Subdevices as modules
    [media] vimc: cap: Support several image formats
    [media] vimc: sen: Support several image formats
    [media] vimc: common: Add vimc_colorimetry_clamp
    [media] vimc: common: Add vimc_link_validate
    [media] vimc: common: Add vimc_pipeline_s_stream helper
    [media] vimc: common: Add vimc_ent_sd_* helper
    [media] vimc: Move common code from the core
    [media] vimc: sen: Integrate the tpg on the sensor
    [media] media: i2c: ov772x: Force use of SCCB protocol
    [media] dvb uapi docs: enums are passed by value, not reference
    [media] dvb: don't use 'time_t' in event ioctl
    [media] media: venus: enable building with COMPILE_TEST
    [media] af9013: refactor power control
    ...

    Linus Torvalds
     

26 Jun, 2017

3 commits

  • Some lower level drivers may work better when sending blocks of data
    instead byte per byte. For this we need new function pointers in the
    dvb_ca_en50221 protocol structure (read_data, write_data) and the protocol
    needs to execute them, if they are defined.
    Block data transmission is done in all states except LINKINIT.

    Original code change by Ralph Metzler, modified by Jasmin Jessich and
    Daniel Scheller to match Kernel code style.

    Signed-off-by: Ralph Metzler
    Signed-off-by: Daniel Scheller
    Signed-off-by: Jasmin Jessich
    Signed-off-by: Mauro Carvalho Chehab

    Ralph Metzler
     
  • Some CAMs do a really slow initialization, which requires a longer timeout
    for the first response.

    Original code change by Ralph Metzler, modified by Jasmin Jessich to match
    Kernel code style.

    Signed-off-by: Ralph Metzler
    Signed-off-by: Jasmin Jessich
    Signed-off-by: Mauro Carvalho Chehab

    Ralph Metzler
     
  • In case of a linkinit failure change to state UNINITIALISED to re-init
    the CAM.

    Original code change by Ralph Metzler, modified by Jasmin Jessich to match
    Kernel code style.

    Signed-off-by: Ralph Metzler
    Signed-off-by: Jasmin Jessich
    Signed-off-by: Mauro Carvalho Chehab

    Ralph Metzler
     

16 Jun, 2017

2 commits

  • It seems like a historic accident that these return unsigned char *,
    and in many places that means casts are required, more often than not.

    Make these functions (skb_put, __skb_put and pskb_put) return void *
    and remove all the casts across the tree, adding a (u8 *) cast only
    where the unsigned char pointer was used directly, all done with the
    following spatch:

    @@
    expression SKB, LEN;
    typedef u8;
    identifier fn = { skb_put, __skb_put };
    @@
    - *(fn(SKB, LEN))
    + *(u8 *)fn(SKB, LEN)

    @@
    expression E, SKB, LEN;
    identifier fn = { skb_put, __skb_put };
    type T;
    @@
    - E = ((T *)(fn(SKB, LEN)))
    + E = fn(SKB, LEN)

    which actually doesn't cover pskb_put since there are only three
    users overall.

    A handful of stragglers were converted manually, notably a macro in
    drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
    instances in net/bluetooth/hci_sock.c. In the former file, I also
    had to fix one whitespace problem spatch introduced.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • A common pattern with skb_put() is to just want to memcpy()
    some data into the new space, introduce skb_put_data() for
    this.

    An spatch similar to the one for skb_put_zero() converts many
    of the places using it:

    @@
    identifier p, p2;
    expression len, skb, data;
    type t, t2;
    @@
    (
    -p = skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    |
    -p = (t)skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, len);
    |
    -memcpy(p, data, len);
    )

    @@
    type t, t2;
    identifier p, p2;
    expression skb, data;
    @@
    t *p;
    ...
    (
    -p = skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    |
    -p = (t *)skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, sizeof(*p));
    |
    -memcpy(p, data, sizeof(*p));
    )

    @@
    expression skb, len, data;
    @@
    -memcpy(skb_put(skb, len), data, len);
    +skb_put_data(skb, data, len);

    (again, manually post-processed to retain some comments)

    Reviewed-by: Stephen Hemminger
    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     

08 Jun, 2017

2 commits


18 Apr, 2017

1 commit

  • It started with a sporadic message in syslog: "CAM tried to send a
    buffer larger than the ecount size" This message is not the fault
    itself, but a consecutive fault, after a read error from the CAM. This
    happens only on several CAMs, several hardware, and of course sporadic.

    It is a consecutive fault, if the last read from the CAM did fail. I
    guess this will not happen on all CAMs, but at least it did on mine.
    There was a write error to the CAM and during the re-initialization
    procedure, the CAM finished the last read, although it got a RS.

    The write error to the CAM happened because a race condition between HC
    write, checking DA and FR.

    This patch added an additional check for DA(RE), just after checking FR.
    It is important to read the CAMs status register again, to give the CAM
    the necessary time for a proper reaction to HC. Please note the
    description within the source code (patch below).

    [mchehab@s-opensource.com: make checkpatch happy]

    Signed-off-by: Jasmin jessich
    Tested-by: Ralph Metzler
    Signed-off-by: Mauro Carvalho Chehab

    Jasmin J