iio: adc: ad9361: add ad9361_write_bist_reg() accessor to cache bist reg value #64

commodo · 2018-03-08T12:06:59Z

The value of the BIST register via ad9361_get_dig_tune_data() needs to be
stored on the state struct when written back.
Otherwise there could be a discrepancy when between the cached value and
the value in the register.

To do this, the ad9361_write_bist_reg() accessor has been added, which
always caches the last written value.

Signed-off-by: Alexandru Ardelean [email protected]

…reg value The value of the BIST_CONFIG register should also be stored on the cached bist_config after it is written to the physical register. Otherwise there could be a discrepancy between the cached value and the value in the register. To do this, the ad9361_write_bist_reg() accessor has been added, which always caches the last written value. Signed-off-by: Alexandru Ardelean <[email protected]>

lclausen-adi · 2018-03-08T12:16:10Z

.travis.yml


 script:
-  - COMMIT_RANGE=$([ -z "$TRAVIS_COMMIT_RANGE" ] &&  echo "HEAD~1" || echo ${TRAVIS_COMMIT_RANGE/.../..})
+  - COMMIT_RANGE=$([ "$TRAVIS_PULL_REQUEST" == "false" ] &&  echo "HEAD~1" || echo ${TRAVIS_BRANCH}..)


I'd still use COMMIT_RANGE if it is available if it is not a pull request. As far as I understood it COMMIT_RANGE gets only confused for force push.

hmmm; i suspect it could still use some testing [ $TRAVIS_COMMIT_RANGE i mean ] ;
i am not sure [yet] if it gets confused also when force-pushing a branch [without a PR] ;

maybe we could bring it back later, after we test it outside of this context ?
my concern here would be to avoid email spam due to false broken builds

Another thing. This should be origin/${TRAVIS_BRANCH}..

There is no local checkout of the branch that the code should be merged into.

ah ; good point

I tried the push force method on branches, and it's problematic as for PRs:

https://travis-ci.org/commodo/linux/jobs/350851554

the hashes seem to be commodo/linux@a1108f8...5c00ae7

it could be that commit-range [in the context of a force-push] is the old hash and new hash

commodo · 2018-03-08T14:50:59Z

Changelog v1 -> v2:

changed ${TRAVIS_BRANCH}.. to origin/${TRAVIS_BRANCH}..

lclausen-adi · 2018-03-08T15:56:08Z

Still doesn't work. I believe the problem is that when --depth is specified git will not fetch information about remote branches. Maybe we have to do with 'depth: false' in the travis config.

lclausen-adi · 2018-03-08T16:00:08Z

Or maybe remotes/origin/${TRAVIS_BRANCH} will work

commodo · 2018-03-08T16:04:45Z

i suspect the depth is the problem
i'm trying to tackle that on Stefan's PR because that one seems to be special

lclausen-adi · 2018-03-08T16:09:46Z

the git manual says that --depth implies --single-branch. I've just tried it here and I really only get the ref to the master branch. This is why it is working for PRs for the master branch, but not for other branches.

I believe if we add a git fetch origin +refs/heads/${TRAVIS_BRANCH} we should be good. This will only fetch the commit ID for the branch and not require to clone the full repository.

lclausen-adi · 2018-03-08T16:13:10Z

sorry needs to be git fetch origin +refs/heads/${TRAVIS_BRANCH}:${TRAVIS_BRANCH} and then we can use ${TRAVIS_BRANCH} as a reference.

commodo · 2018-03-08T18:43:37Z

closing and re-opening to trigger build

commodo · 2018-03-09T07:24:36Z

Travis CI is not triggering ; I'm trying to figure out which rate limit we hit

lclausen-adi · 2018-03-09T07:50:09Z

did it trigger before for this branch?

The TRAVIS_COMMIT_RANGE var seems unreliable when force-pushing to a branch that has a PR open. It sometimes gives this error for the checkpatch.pl script: ``` fatal: ambiguous argument '1061308fc9d1..d05c2e7': unknown revision or path not in the working tree. ``` The TRAVIS_BRANCH var seems ok to use as a commit range start. From docs: * TRAVIS_BRANCH: * for push builds, or builds not triggered by a pull request, this is the name of the branch. * for builds triggered by a pull request this is the name of the branch targeted by the pull request. * for builds triggered by a tag, this is the same as the name of the tag (TRAVIS_TAG). So, we use `TRAVIS_PULL_REQUEST == false` to check if we are in a PR context [or not]. According to the docs: * TRAVIS_PULL_REQUEST: The pull request number if the current job is a pull request, “false” if it’s not a pull request. For the checkpatch.pl script, the target branch may not be available, so also fetch it. Signed-off-by: Alexandru Ardelean <[email protected]>

commodo · 2018-03-09T07:57:11Z

fixed it ;
.travis.yml file was malformed ;
it looks like Travis has done some UI updates, where it does not tell you when a yaml file is malformed in the main build page, but rather in the "More Options ==> Requests" page, which seems a bit minimized;

i found this article explaining things [from 4 years ago that hinted me in that direction]:
https://blog.travis-ci.com/2014-05-12-why-is-my-build-not-running

but it's good to know in the future;

commodo · 2018-03-09T08:00:09Z

the part that was malformed was this:

 -  [ -z "$TRAVIS_BRANCH" ] || git fetch origin +refs/heads/${TRAVIS_BRANCH}:${TRAVIS_BRANCH}

with err msg

syntax error: (<unknown>): did not find expected comment or line break while scanning a block scalar at line 21 column 29

well, that was after I put it through : https://lint.travis-ci.org/

in this page: https://travis-ci.org/analogdevicesinc/linux/requests
i only get Could not parse .travis.yml

rgetz · 2018-03-09T19:41:17Z

Just FYI : I use the command line utils.
https://docs.travis-ci.com/user/travis-lint

They also work pretty well. (But not great).

Robin

This fixes the below calltrace when the CONFIG_DMA_API_DEBUG is enabled. DMA-API: thunderx_mmc 0000:01:01.4: cpu touching an active dma mapped cacheline [cln=0x000000002fdf9800] WARNING: CPU: 21 PID: 1 at kernel/dma/debug.c:596 debug_dma_assert_idle+0x1f8/0x270 Modules linked in: CPU: 21 PID: 1 Comm: init Not tainted 5.3.0-rc1-next-20190725-yocto-standard+ #64 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 80400009 (Nzcv daif +PAN -UAO) pc : debug_dma_assert_idle+0x1f8/0x270 lr : debug_dma_assert_idle+0x1f8/0x270 sp : ffff0000113cfc10 x29: ffff0000113cfc10 x28: 0000ffff8c880000 x27: ffff800bc72a0000 x26: ffff000010ff8000 x25: ffff000010ff8940 x24: ffff000010ff8968 x23: 0000000000000000 x22: ffff000010e83700 x21: ffff000010ea2000 x20: ffff000010e835c8 x19: ffff800bc2c73300 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff000010e835c8 x14: 6d20616d64206576 x13: 69746361206e6120 x12: 676e696863756f74 x11: 20757063203a342e x10: 31303a31303a3030 x9 : 303020636d6d5f78 x8 : 3230303030303030 x7 : 00000000000002fd x6 : ffff000010fd57d0 x5 : 0000000000000000 x4 : ffff0000106c5210 x3 : 00000000ffffffff x2 : 0000800bee9c0000 x1 : 57d5843f4aa62800 x0 : 0000000000000000 Call trace: debug_dma_assert_idle+0x1f8/0x270 wp_page_copy+0xb0/0x688 do_wp_page+0xa8/0x5b8 __handle_mm_fault+0x600/0xd00 handle_mm_fault+0x118/0x1e8 do_page_fault+0x200/0x500 do_mem_abort+0x50/0xb0 el0_da+0x20/0x24 ---[ end trace a005534bd23e109f ]--- DMA-API: Mapped at: debug_dma_map_sg+0x94/0x350 cvm_mmc_request+0x3c4/0x988 __mmc_start_request+0x9c/0x1f8 mmc_start_request+0x7c/0xb0 mmc_blk_mq_issue_rq+0x5c4/0x7b8 Signed-off-by: Kevin Hao <[email protected]> Fixes: ba3869f ("mmc: cavium: Add core MMC driver for Cavium SOCs") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>

Some of the platforms may connect the INT pin via inversion logic effectively make the triggering to be active-low. Remove explicit trigger flag to respect the settings from firmware. Without this change even idling chip produces spurious interrupts and kernel disables the line in the result: irq 33: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 125 Comm: irq/33-i2c-INT3 Not tainted 6.12.0-00236-g8b874ed11dae #64 Hardware name: Intel Corp. QUARK/Galileo, BIOS 0x01000900 01/01/2014 ... handlers: [<86e86bea>] irq_default_primary_handler threaded [<d153e44a>] cy8c95x0_irq_handler [pinctrl_cy8c95x0] Disabling IRQ #33 Fixes: e6cbbe4 ("pinctrl: Add Cypress cy8c95x0 support") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]>

When igc_led_setup() fails, igc_probe() fails and triggers kernel panic in free_netdev() since unregister_netdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2] Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic. [1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:free_netdev+0x278/0x2b0 [...] Call Trace: <TASK> igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind Fixes: ea57870 ("igc: Add support for LEDs on i225/i226") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Reviewed-by: Vitaly Lifshits <[email protected]> Reviewed-by: Kurt Kanzenbach <[email protected]> Tested-by: Mor Bar-Gabay <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>

cxl EDAC calls cxl_feature_info() to get the feature information and if the hardware has no Features support, cxlfs may be passed in as NULL. [ 51.957498] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 51.965571] #PF: supervisor read access in kernel mode [ 51.971559] #PF: error_code(0x0000) - not-present page [ 51.977542] PGD 17e4f6067 P4D 0 [ 51.981384] Oops: Oops: 0000 [#1] SMP NOPTI [ 51.986300] CPU: 49 UID: 0 PID: 3782 Comm: systemd-udevd Not tainted 6.17.0dj test+ #64 PREEMPT(voluntary) [ 51.997355] Hardware name: <removed> [ 52.009790] RIP: 0010:cxl_feature_info+0xa/0x80 [cxl_core] Add a check for cxlfs before dereferencing it and return -EOPNOTSUPP if there is no cxlfs created due to no hardware support. Fixes: eb5dfcb ("cxl: Add support to handle user feature commands for set feature") Reviewed-by: Davidlohr Bueso <[email protected]> Reviewed-by: Alison Schofield <[email protected]> Signed-off-by: Dave Jiang <[email protected]>

commodo requested review from dbogdan, lclausen-adi, mhennerich and stefpopa March 8, 2018 12:07

lclausen-adi approved these changes Mar 8, 2018

View reviewed changes

lclausen-adi reviewed Mar 8, 2018

View reviewed changes

mhennerich approved these changes Mar 8, 2018

View reviewed changes

commodo force-pushed the ad9361-bist-config-store-reg branch from 8df6048 to 3c23d5e Compare March 8, 2018 14:50

commodo force-pushed the ad9361-bist-config-store-reg branch from 3c23d5e to a827e6c Compare March 8, 2018 16:50

commodo closed this Mar 8, 2018

commodo reopened this Mar 8, 2018

dbogdan approved these changes Mar 8, 2018

View reviewed changes

commodo force-pushed the ad9361-bist-config-store-reg branch from a827e6c to a98815a Compare March 9, 2018 07:54

stefpopa approved these changes Mar 9, 2018

View reviewed changes

stefpopa merged commit 06747c3 into master Mar 12, 2018

stefpopa deleted the ad9361-bist-config-store-reg branch March 12, 2018 08:42

commodo mentioned this pull request Mar 12, 2018

iio: adc: ad9361: re-organize structs to make them opaque to other files #62

Merged

iio: adc: ad9361: add ad9361_write_bist_reg() accessor to cache bist reg value #64

iio: adc: ad9361: add ad9361_write_bist_reg() accessor to cache bist reg value #64

Uh oh!

Conversation

commodo commented Mar 8, 2018

Uh oh!

lclausen-adi Mar 8, 2018

Choose a reason for hiding this comment

Uh oh!

commodo Mar 8, 2018

Choose a reason for hiding this comment

Uh oh!

lclausen-adi Mar 8, 2018

Choose a reason for hiding this comment

Uh oh!

commodo Mar 8, 2018

Choose a reason for hiding this comment

Uh oh!

commodo Mar 8, 2018

Choose a reason for hiding this comment

Uh oh!

commodo commented Mar 8, 2018

Uh oh!

lclausen-adi commented Mar 8, 2018

Uh oh!

lclausen-adi commented Mar 8, 2018

Uh oh!

commodo commented Mar 8, 2018

Uh oh!

lclausen-adi commented Mar 8, 2018

Uh oh!

lclausen-adi commented Mar 8, 2018

Uh oh!

commodo commented Mar 8, 2018

Uh oh!

commodo commented Mar 9, 2018

Uh oh!

lclausen-adi commented Mar 9, 2018

Uh oh!

commodo commented Mar 9, 2018

Uh oh!

commodo commented Mar 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rgetz commented Mar 9, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

commodo commented Mar 9, 2018 •

edited

Loading