[PATCH] IB/hfi1: Delete an unnecessary check before the function call "sc_return_credits"
From: Markus Elfring Date: Sat, 23 Jul 2016 08:30:52 +0200 The sc_return_credits() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/infiniband/hw/hfi1/file_ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/hfi1/file_ops.c b/drivers/infiniband/hw/hfi1/file_ops.c index c702a00..32c19fa 100644 --- a/drivers/infiniband/hw/hfi1/file_ops.c +++ b/drivers/infiniband/hw/hfi1/file_ops.c @@ -228,7 +228,7 @@ static long hfi1_file_ioctl(struct file *fp, unsigned int cmd, sizeof(struct hfi1_base_info)); break; case HFI1_IOCTL_CREDIT_UPD: - if (uctxt && uctxt->sc) + if (uctxt) sc_return_credits(uctxt->sc); break; -- 2.9.2
RE: [PATCH v5 0/8] Replay Protected Memory Block (RPMB) subsystem
> > Few storage technologies such is EMMC, UFS, and NVMe support RPMB > hardware partition with common protocol and frame layout. > The RPMB partition cannot be accessed via standard block layer, but by a set > of specific commands: WRITE, READ, GET_WRITE_COUNTER, and > PROGRAM_KEY. > Such a partition provides authenticated and replay protected access, hence > suitable as a secure storage. > > The RPMB layer aims to provide in-kernel API for Trusted Execution > Environment (TEE) devices that are capable to securely compute block frame > signature. In case a TEE device wish to store a replay protected data, it > creates an RPMB frame with requested data and computes HMAC of the > frame, then it requests the storage device via RPMB layer to store the data. > A TEE driver can claim the RPMB interface, for example, via > class_interface_register (). > The layer provides two APIs, for rpmb_req_cmd() for issuing one of RPMB > specific commands and rpmb_seq_cmd() for issuing of raw RPMB protocol > frames, which is close to emmc multi ioctl interface. > > A storage device registers its RPMB hardware (eMMC) partition or RPMB W- > LUN (UFS) with the RPMB layer providing an implementation for > rpmb_seq_cmd() handler. The interface enables sending sequence of RPMB > standard frames. > > A parallel user space API is provided via /dev/rpmbX character device with > two IOCTL commands. > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD > where the whole RPMB sequence, including RESULT_READ is supplied by the > caller. > The latter is intended for easier adjusting of the applications that use > MMC_IOC_MULTI_CMD ioctl, such as > https://android.googlesource.com/trusty/app/storage/ > > There is a also sample tool under tools/rpmb/ directory that exercises these > interfaces and a simulation device that implements the device part. > > Tomas Winkler (8): > rpmb: add Replay Protected Memory Block (RPMB) subsystem > char: rpmb: add sysfs-class ABI documentation > char: rpmb: add device attributes > char: rpmb: provide a user space interface > char: rpmb: add RPMB simulation device > tools rpmb: add RPBM access tool > mmc: block: register RPMB partition with the RPMB subsystem > scsi: ufs: connect to RPMB subsystem > I've got few off line request for git access of this code, so here si the repo https://github.com/tomasbw/linux-mei.git branch rpmb. The branch is rebasing one over linux master branch Thanks and will appreciate any public review. Tomas
[tip:x86/mm] x86/mm/cpa: Fix populate_pgd(): Stop trying to deallocate failed PUDs
Commit-ID: e959c4cb39feebe85e2b1191f5f666c79807631a
Gitweb: http://git.kernel.org/tip/e959c4cb39feebe85e2b1191f5f666c79807631a
Author: Andy Lutomirski
AuthorDate: Fri, 22 Jul 2016 21:58:08 -0700
Committer: Ingo Molnar
CommitDate: Sat, 23 Jul 2016 09:43:42 +0200
x86/mm/cpa: Fix populate_pgd(): Stop trying to deallocate failed PUDs
Valdis Kletnieks bisected a boot failure back to this recent commit:
360cb4d15567 ("x86/mm/cpa: In populate_pgd(), don't set the PGD entry until
it's populated")
I broke the case where a PUD table got allocated -- populate_pud()
would wander off a pgd_none entry and get lost. I'm not sure how
this survived my testing.
Fixing this directly is difficult or impossible because of the awful
state of Linux's page table accessors.
Instead, fix the original issue in a much simpler way. The problem
was that, if we allocated a PUD table, failed to populate it, and
freed it, another CPU could potentially keep using the PGD entry we
installed (either by copying it via vmalloc_fault or by speculatively
caching it). There's a straightforward fix: simply leave the
top-level entry in place if this happens. This can't waste any
significant amount of memory -- there are at most 256 entries like
this systemwide and, as a practical matter, if we hit this failure
path repeatedly, we're likely to reuse the same page anyway.
For context, this is a reversion with this hunk added in:
if (ret < 0) {
+ /*
+* Leave the PUD page in place in case some other CPU or thread
+* already found it, but remove any useless entries we just
+* added to it.
+*/
- unmap_pgd_range(cpa->pgd, addr,
+ unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
}
This effectively open-codes what the now-deleted unmap_pgd_range()
function used to do except that unmap_pgd_range() used to try to
free the page as well.
Reported-by: Valdis Kletnieks
Signed-off-by: Andy Lutomirski
Cc: Andrew Morton
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Luis R. Rodriguez
Cc: Mike Krinkin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Toshi Kani
Link:
http://lkml.kernel.org/r/21cbc2822aa18aa812c0215f4231dbf5f65afa7f.1469249789.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/mm/pageattr.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 26c93c6..2bc6ea1 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1082,6 +1082,8 @@ static int populate_pgd(struct cpa_data *cpa, unsigned
long addr)
pud = (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK);
if (!pud)
return -1;
+
+ set_pgd(pgd_entry, __pgd(__pa(pud) | _KERNPG_TABLE));
}
pgprot_val(pgprot) &= ~pgprot_val(cpa->mask_clr);
@@ -1089,16 +1091,11 @@ static int populate_pgd(struct cpa_data *cpa, unsigned
long addr)
ret = populate_pud(cpa, addr, pgd_entry, pgprot);
if (ret < 0) {
- if (pud)
- free_page((unsigned long)pud);
unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
}
- if (pud)
- set_pgd(pgd_entry, __pgd(__pa(pud) | _KERNPG_TABLE));
-
cpa->numpages = ret;
return 0;
}
Re: [PATCH v2 16/17] x86/insn: remove pcommit
* Dan Williams wrote: > On Fri, Jul 22, 2016 at 9:52 AM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> On Tue, Jul 12, 2016 at 3:12 PM, Dan Williams > >> wrote: > >> > On Tue, Jul 12, 2016 at 7:57 AM, Peter Zijlstra > >> > wrote: > >> >> On Sat, Jul 09, 2016 at 08:25:54PM -0700, Dan Williams wrote: > >> >>> The pcommit instruction is being deprecated in favor of either ADR > >> >>> (asynchronous DRAM refresh: flush-on-power-fail) at the platform > >> >>> level, or > >> >>> posted-write-queue flush addresses as defined by the ACPI 6.x NFIT > >> >>> (NVDIMM > >> >>> Firmware Interface Table). > >> >> > >> >>> arch/x86/include/asm/cpufeatures.h |1 > >> >>> arch/x86/include/asm/special_insns.h | 46 > >> >>> > >> >>> arch/x86/lib/x86-opcode-map.txt|2 - > >> >>> tools/objtool/arch/x86/insn/x86-opcode-map.txt |2 - > >> >>> tools/perf/arch/x86/tests/insn-x86-dat-32.c|2 - > >> >>> tools/perf/arch/x86/tests/insn-x86-dat-64.c|2 - > >> >>> tools/perf/arch/x86/tests/insn-x86-dat-src.c |4 -- > >> >> > >> >> Just deprecated, or is it completely eradicated, removed from history, > >> >> will never ever happen and we'll reissue the opcode for something else? > >> >> > >> >> Because if its only deprecated then removing it from the instruction > >> >> decoders seems wrong, old binaries might still contain the opcode. > >> > > >> > Eradicated. > >> > > >> > "The new instructions like CLWB and CLFLUSHOPT will be rolled into the > >> > SDM but PCOMMIT will be removed from the Extensions doc and not rolled > >> > into the SDM." [1] > >> > > >> > Existing binaries are already gating their usage on the presence of > >> > the cpu id flag, that flag and the instruction opcode are reserved > >> > going forward. > >> > > >> > [1]: https://lists.01.org/pipermail/linux-nvdimm/2016-June/005923.html > >> > >> x86 maintainers, I have the other patches in this series queued in -next. > >> Please > >> ack this one and I'll add it for v4.8-rc1, or otherwise let me know how > >> you want > >> to handle this patch. > > > > Since it's just a removal AFAICS that the rest of your series should not > > depend > > on, can you submit it to the x86 tree? > > This patch depends on the previous patches in the series removing > calls to pcommit_sfence(). Ok, and the patch looks harmless: Acked-by: Ingo Molnar Thanks, Ingo
[PATCH] sched/core: make "Preemption disabled at" message more useful
This message is currently really useless since it always prints a value
that comes from the printk() we just did, e.g.:
BUG: sleeping function called from invalid context at mm/slab.h:388
in_atomic(): 0, irqs_disabled(): 0, pid: 31996, name: trinity-c1
Preemption disabled at:[] down_trylock+0x13/0x80
BUG: sleeping function called from invalid context at
include/linux/freezer.h:56
in_atomic(): 0, irqs_disabled(): 0, pid: 31996, name: trinity-c1
Preemption disabled at:[] console_unlock+0x2f7/0x930
Here, both down_trylock() and console_unlock() is somewhere in the
printk() path.
We should save the value before calling printk() and use the saved value
instead. That immediately reveals the offending callsite:
BUG: sleeping function called from invalid context at mm/slab.h:388
in_atomic(): 0, irqs_disabled(): 0, pid: 14971, name: trinity-c2
Preemption disabled at:[] rhashtable_walk_start+0x46/0x150
(Bug report: http://marc.info/?l=linux-netdev&m=146925979821849&w=2)
Cc: Peter Zijlstra
Cc: Paul E. McKenney
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Rusty Russel
Signed-off-by: Vegard Nossum
---
kernel/sched/core.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7171cf9..87689a6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3144,9 +3144,18 @@ static inline void preempt_latency_stop(int val) { }
*/
static noinline void __schedule_bug(struct task_struct *prev)
{
+#ifdef CONFIG_DEBUG_PREEMPT
+ unsigned long preempt_disable_ip;
+#endif
+
if (oops_in_progress)
return;
+#ifdef CONFIG_DEBUG_PREEMPT
+ /* Save this before calling printk(), since that will clobber it */
+ preempt_disable_ip = current->preempt_disable_ip;
+#endif
+
printk(KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n",
prev->comm, prev->pid, preempt_count());
@@ -3157,7 +3166,7 @@ static noinline void __schedule_bug(struct task_struct
*prev)
#ifdef CONFIG_DEBUG_PREEMPT
if (in_atomic_preempt_off()) {
pr_err("Preemption disabled at:");
- print_ip_sym(current->preempt_disable_ip);
+ print_ip_sym(preempt_disable_ip);
pr_cont("\n");
}
#endif
@@ -7541,6 +7550,9 @@ EXPORT_SYMBOL(__might_sleep);
void ___might_sleep(const char *file, int line, int preempt_offset)
{
static unsigned long prev_jiffy;/* ratelimiting */
+#ifdef CONFIG_DEBUG_PREEMPT
+ unsigned long preempt_disable_ip;
+#endif
rcu_sleep_check(); /* WARN_ON_ONCE() by default, no rate limit reqd. */
if ((preempt_count_equals(preempt_offset) && !irqs_disabled() &&
@@ -7551,6 +7563,11 @@ void ___might_sleep(const char *file, int line, int
preempt_offset)
return;
prev_jiffy = jiffies;
+#ifdef CONFIG_DEBUG_PREEMPT
+ /* Save this before calling printk(), since that will clobber it */
+ preempt_disable_ip = current->preempt_disable_ip;
+#endif
+
printk(KERN_ERR
"BUG: sleeping function called from invalid context at %s:%d\n",
file, line);
@@ -7568,7 +7585,7 @@ void ___might_sleep(const char *file, int line, int
preempt_offset)
#ifdef CONFIG_DEBUG_PREEMPT
if (!preempt_count_equals(preempt_offset)) {
pr_err("Preemption disabled at:");
- print_ip_sym(current->preempt_disable_ip);
+ print_ip_sym(preempt_disable_ip);
pr_cont("\n");
}
#endif
--
1.9.1
Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio
Paul Gortmaker writes: > While working on some for-4.9 cleanups of linux/gpio/driver.h it was > found that changes there caused build failures when walking all the > ARM defconfigs, in ARM specific mach-* files. > > The proposed GPIO header change is just this: > > --- > --- a/include/linux/gpio/driver.h > +++ b/include/linux/gpio/driver.h > @@ -3,7 +3,6 @@ > > #include > #include > -#include > #include > #include > #include > @@ -16,6 +15,7 @@ struct of_phandle_args; > struct device_node; > struct seq_file; > struct gpio_device; > +struct module; > > #ifdef CONFIG_GPIOLIB > --- > > ...which is what we've already got in ~50 other include/linux/* files to > try and keep cross contamination entanglement at a minimum. > > So we uncovered three users in ARM specific files relying on the above > presence in this header, vs. dealing with it within the driver itself. > > But with ARM and GPIO being different subsystems, we'll need to get > this in ARM 1st, and then wait a release before changing the GPIO > header, otherwise we'll risk triggering these three build failures. > > So, if folks consider these three trivial changes OK for late in the > for-4.8 cycle, then great. Otherwise I'll resubmit the ARM parts for > for-4.9 and the GPIO bits for the one after that. > > [Yes, there were gpio implicit users too, but they are easily sync'd > with the gpio header change being at the end of that series.] > > Paul. > -- > > Cc: Alexandre Courbot > Cc: Daniel Mack > Cc: Haojian Zhuang > Cc: Linus Walleij > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-g...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: Robert Jarzmik > Cc: Russell King > Cc: Tony Lindgren > > Paul Gortmaker (3): > ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals > ARM: pxa: add module.h for corgi symbol_get/symbol_put usage > ARM: pxa: add module.h for spitz symbol_get/symbol_put usage > > arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +- > arch/arm/mach-pxa/corgi.c| 1 + > arch/arm/mach-pxa/spitz.c| 1 + > 3 files changed, 3 insertions(+), 1 deletion(-) Hi Paul, I'll take the mach-pxa changes to pxa/for-next tree with Linus's ack. Tony, I think you will carry the remaining omap2 one, right ? As for the cycle, I'd prefer have it for-4.9 as we're at rc7 and it's a bit late for me. If you want your GPIO bits to get in 4.9 I think I can commit to request pull very early (-rc1 time) or give my ack so that Linus can carry these changes through the gpio tree with the other changes. Cheers. -- Robert
Re: [tip:x86/mm] x86/mm/cpa: Fix populate_pgd(): Stop trying to deallocate failed PUDs
On Sat, Jul 23, 2016 at 4:46 PM, tip-bot for Andy Lutomirski wrote: > > Fixing this directly is difficult or impossible because of the awful > state of Linux's page table accessors. Quite frankly, this part of the message is misleading and wrong. The "awful state" is purely "Andy didn't understand the folding". There is nothing awful about it, quite the reverse. It is what allows the generic code to mostly not have to care whether a particular level actually exists or not, or is just folded into the next-higher level. No, we don't alway have I do agree that our *naming* is not great, and that when we get five-level page tables we should strive to start having numbers instead of the magic letters. The magic letters made sense with three levels that had fairly well-known names (pgd/pmd/pte is not a Linux invention), but with four levels it's already fairly questionable. But the fact that a pud may not even exist, and in fact is just another nested version of the pgd, is definitely *not* awful. And Andy not understanding it and getting it wrong *still* doesn't make it awful. Yes, a folded level can be subtle. The level above the folded level has no actual storage of its own, it just contains the folded level directly. We've had confusion about it, and the naming really doesn't help. But looking through include/asm-generic/pgtable-nopmd.h can actually be instructive. Calling something "awful" just because it's clever and you didn't understand it is not right. It would be *truly* awful if we forced everybody to actually have all the levels, and then had to follow idiotic single-entry pointers at the upper end that doesn't actually exist in reality, and we'd just have these silly "software-only" levels to make everything be four levels even if the hardware only does two. That would be awful, because it would be *stupid*. Linus
Re: [PATCH V2 1/2] mmc: sdhci: Request regulators before reading capabilities
On 12 July 2016 at 15:53, Jon Hunter wrote:
> The capabilities of the SDHCI host controller are read early during the
> SDHCI host initialisation in sdhci_setup_host() and before any
> regulators for the host have been requested. This means that if the host
> supports some high-speed modes (according to its capabilities register),
> but the board cannot because the appropriate voltage regulator is not
> available, then the host cannot easily override the capabilities that
> are supported.
>
> To allow a SDHCI host controller to determine if it can support high
> speed modes via the presense of the MMC regulators, request the
> regulators before reading the capabilites of the host controller. This
> will allow the SDHCI host to use the 'reset' callback to take the
> appropriate action (set flags, configure registers, etc) before the
> capabilities register(s) are read.
>
> Please note that some SDHCI hosts, such as the Tegra SDHCI host, has
> the ability to mask bits in the capabilities register to prevent
> certain capabilities from being advertised.
>
> Signed-off-by: Jon Hunter
Thanks, applied for next! I changed the minor things pointed out by Adrian.
Kind regards
Uffe
> ---
>
> Although this is described as a "V2" this patch has been added since
> the original patch was posted.
>
> If the below is deemed not appropriate, then another solution I was
> thinking of is to allow the SDHCI host to call 'mmc_regulator_get_supply'
> before calling sdhci_setup_host() and then in sdhci_setup_host() check
> if any regulators are already present before calling
> mmc_regulator_get_supply().
>
> drivers/mmc/host/sdhci.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 2ee8bfa77116..628c4b3558c0 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -3021,6 +3021,17 @@ int sdhci_setup_host(struct sdhci_host *host)
>
> mmc = host->mmc;
>
> + /*
> +* If there are external regulators, get them. Note
> +* this must be done early before resetting the host
> +* and reading the capabilities so that the host can
> +* take the appropriate action if regulators are not
> +* available.
> +*/
> + ret = mmc_regulator_get_supply(mmc);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> sdhci_read_caps(host);
>
> override_timeout_clk = host->timeout_clk;
> @@ -3253,11 +3264,6 @@ int sdhci_setup_host(struct sdhci_host *host)
> mmc_gpio_get_cd(host->mmc) < 0)
> mmc->caps |= MMC_CAP_NEEDS_POLL;
>
> - /* If there are external regulators, get them */
> - ret = mmc_regulator_get_supply(mmc);
> - if (ret == -EPROBE_DEFER)
> - goto undma;
> -
> /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> if (!IS_ERR(mmc->supply.vqmmc)) {
> ret = regulator_enable(mmc->supply.vqmmc);
> --
> 2.1.4
>
Re: [PATCH] mmc: sdhci-msm: Do not reset the controller if no card in the slot
On 24 June 2016 at 18:24, Georgi Djakov wrote:
> The controller does not clear the "reset bit" when it is reset without
> a card in the slot. Because of this, the following error message is seen
> while booting with no plugged SD card.
>
> mmc1: Reset 0x1 never completed.
>
> Add the SDHCI_QUIRK_NO_CARD_NO_RESET quirk to avoid this.
>
> Signed-off-by: Ivan T. Ivanov
> Signed-off-by: Georgi Djakov
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-msm.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index ac5700233e12..c613137ae91e 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -477,6 +477,7 @@ static const struct sdhci_ops sdhci_msm_ops = {
>
> static const struct sdhci_pltfm_data sdhci_msm_pdata = {
> .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> + SDHCI_QUIRK_NO_CARD_NO_RESET |
> SDHCI_QUIRK_SINGLE_POWER_WRITE,
> .ops = &sdhci_msm_ops,
> };
Re: [PATCH V2 2/2] mmc: tegra: Only advertise UHS modes if IO regulator is present
On 12 July 2016 at 15:53, Jon Hunter wrote:
> To support UHS modes for Tegra an external regulator must be present
> to adjust the IO voltage accordingly. Even if the regulator is not
> present but the host supports the UHS modes and the device supports the
> UHS modes, then we will attempt to switch to a high-speed mode. Without
> an external regulator, Tegra will fail to switch to the high-speed
> mode.
>
> It has been found that with some SD cards, that once it has been switch
> to operate at a high-speed mode, all subsequent commands issues to the
> card will fail and so it will not be possible to switch back to a non
> high-speed mode and so the SD card initialisation will fail.
>
> The SDHCI core does not require that the host have an external regulator
> when switching to UHS modes and therefore, the Tegra SDHCI host
> controller should only advertise the UHS modes as being supported if the
> regulator for the IO voltage is present. Fortunately, Tegra has a vendor
> specific register which can be used to control which modes are
> advertised via the SDHCI_CAPABILITIES register. Hence, if there is no IO
> voltage regulator available for the Tegra SDHCI host, then don't
> advertise the UHS modes.
>
> Note that if the regulator is not available, we also don't advertise that
> the SDHCI is compatible with v3.0 of the SDHCI specification because
> this will read the SDHCI_CAPABILITIES_1 register which will enable other
> UHS modes.
>
> This fixes commit 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes") which
> enables UHS mode without checking if the board can support them.
>
> Fixes: 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
>
> Signed-off-by: Jon Hunter
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-tegra.c | 49
> +-
> 1 file changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index bcc0de47fe7e..bd1199825f9f 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -148,28 +148,37 @@ static void tegra_sdhci_reset(struct sdhci_host *host,
> u8 mask)
> return;
>
> misc_ctrl = sdhci_readl(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> - /* Erratum: Enable SDHCI spec v3.00 support */
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
> - /* Advertise UHS modes as supported by host */
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR50)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR50;
> - else
> - misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR50;
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_DDR50)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_DDR50;
> - else
> - misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_DDR50;
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR104)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR104;
> - else
> - misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR104;
> - sdhci_writel(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> -
> clk_ctrl = sdhci_readl(host, SDHCI_TEGRA_VENDOR_CLOCK_CTRL);
> +
> + misc_ctrl &= ~(SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300 |
> + SDHCI_MISC_CTRL_ENABLE_SDR50 |
> + SDHCI_MISC_CTRL_ENABLE_DDR50 |
> + SDHCI_MISC_CTRL_ENABLE_SDR104);
> +
> clk_ctrl &= ~SDHCI_CLOCK_CTRL_SPI_MODE_CLKEN_OVERRIDE;
> - if (soc_data->nvquirks & SDHCI_MISC_CTRL_ENABLE_SDR50)
> - clk_ctrl |= SDHCI_CLOCK_CTRL_SDR50_TUNING_OVERRIDE;
> +
> + /*
> +* If the board does not define a regulator for the SDHCI
> +* IO voltage, then don't advertise support for UHS modes
> +* even if the device supports it because the IO voltage
> +* cannot be configured.
> +*/
> + if (!IS_ERR(host->mmc->supply.vqmmc)) {
> + /* Erratum: Enable SDHCI spec v3.00 support */
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
> + /* Advertise UHS modes as supported by host */
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR50)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR50;
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_DDR50)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_DDR50;
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR104)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR104;
> + if (soc_data->nvquirks & SDHCI_MISC_CTRL_ENABLE_SDR50)
> + clk_ctrl |= SDHCI_CLOCK_CTRL_SDR50_TUNING_OVERRIDE;
> + }
> +
> + sdhci_writel(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> sdhci_writel(host, clk_ctrl, SDHCI_TEGRA_VENDO
Re: [PATCH] mmc: sdhci-msm: Add support for UHS cards
On 24 June 2016 at 17:07, Georgi Djakov wrote:
> Enabling support for ultra high speed mode cards requires some
> voltage switching and interaction with the PMIC via a special
> power IRQ. Add support for this.
>
> Signed-off-by: Georgi Djakov
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-msm.c | 66
> ++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 0653fe730150..ac5700233e12 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -32,6 +32,21 @@
> #define CORE_POWER 0x0
> #define CORE_SW_RSTBIT(7)
>
> +#define CORE_PWRCTL_STATUS 0xdc
> +#define CORE_PWRCTL_MASK 0xe0
> +#define CORE_PWRCTL_CLEAR 0xe4
> +#define CORE_PWRCTL_CTL0xe8
> +#define CORE_PWRCTL_BUS_OFFBIT(0)
> +#define CORE_PWRCTL_BUS_ON BIT(1)
> +#define CORE_PWRCTL_IO_LOW BIT(2)
> +#define CORE_PWRCTL_IO_HIGHBIT(3)
> +#define CORE_PWRCTL_BUS_SUCCESS BIT(0)
> +#define CORE_PWRCTL_IO_SUCCESS BIT(2)
> +#define REQ_BUS_OFFBIT(0)
> +#define REQ_BUS_ON BIT(1)
> +#define REQ_IO_LOW BIT(2)
> +#define REQ_IO_HIGHBIT(3)
> +#define INT_MASK 0xf
> #define MAX_PHASES 16
> #define CORE_DLL_LOCK BIT(7)
> #define CORE_DLL_ENBIT(16)
> @@ -56,6 +71,7 @@
> struct sdhci_msm_host {
> struct platform_device *pdev;
> void __iomem *core_mem; /* MSM SDCC mapped address */
> + int pwr_irq;/* power irq */
> struct clk *clk;/* main SD/MMC bus clock */
> struct clk *pclk; /* SDHC peripheral bus clock */
> struct clk *bus_clk;/* SDHC bus voter clock */
> @@ -410,6 +426,39 @@ retry:
> return rc;
> }
>
> +static void sdhci_msm_voltage_switch(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + u32 irq_status, irq_ack = 0;
> +
> + irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
> + irq_status &= INT_MASK;
> +
> + writel_relaxed(irq_status, msm_host->core_mem + CORE_PWRCTL_CLEAR);
> +
> + if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
> + irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
> + if (irq_status & (CORE_PWRCTL_IO_LOW | CORE_PWRCTL_IO_HIGH))
> + irq_ack |= CORE_PWRCTL_IO_SUCCESS;
> +
> + /*
> +* The driver has to acknowledge the interrupt, switch voltages and
> +* report back if it succeded or not to this register. The voltage
> +* switches are handled by the sdhci core, so just report success.
> +*/
> + writel_relaxed(irq_ack, msm_host->core_mem + CORE_PWRCTL_CTL);
> +}
> +
> +static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
> +{
> + struct sdhci_host *host = (struct sdhci_host *)data;
> +
> + sdhci_msm_voltage_switch(host);
> +
> + return IRQ_HANDLED;
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
> @@ -423,6 +472,7 @@ static const struct sdhci_ops sdhci_msm_ops = {
> .set_clock = sdhci_set_clock,
> .set_bus_width = sdhci_set_bus_width,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> + .voltage_switch = sdhci_msm_voltage_switch,
> };
>
> static const struct sdhci_pltfm_data sdhci_msm_pdata = {
> @@ -545,6 +595,22 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>CORE_VENDOR_SPEC_CAPABILITIES0);
> }
>
> + /* Setup IRQ for handling power/voltage tasks with PMIC */
> + msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
> + if (msm_host->pwr_irq < 0) {
> + dev_err(&pdev->dev, "Get pwr_irq failed (%d)\n",
> + msm_host->pwr_irq);
> + goto clk_disable;
> + }
> +
> + ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq, NULL,
> + sdhci_msm_pwr_irq, IRQF_ONESHOT,
> + dev_name(&pdev->dev), host);
> + if (ret) {
> + dev_err(&pdev->dev, "Request IRQ failed (%d)\n", ret);
> + goto clk_disable;
> + }
> +
> ret = sdhci_add_host(host);
> if (ret)
> goto clk_disable;
Re: [PATCH 2/3] phy: rockchip-emmc: Be tolerant to card clock of 0 in power on
On 29 June 2016 at 17:18, Doug Anderson wrote:
> Kishon,
>
> On Wed, Jun 29, 2016 at 6:49 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Monday 27 June 2016 11:09 PM, Douglas Anderson wrote:
>>> It's possible that there are some reasons to turn the PHY on while the
>>> clock is 0. In this case we just won't wait for the DLL to lock.
>>>
>>> This is a bit of a stopgap until we figure out exactly when we're
>>> supposed to wait for the DLL to lock and when we're supposed to power
>>> cycle the PHY.
>>>
>>> Note: this patch should help with suspend/resume where the system will
>>> try to turn the PHY back on when the clock is 0.
>>>
>>> Signed-off-by: Douglas Anderson
>>> ---
>>> drivers/phy/phy-rockchip-emmc.c | 59
>>> ++---
>>> 1 file changed, 37 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/drivers/phy/phy-rockchip-emmc.c
>>> b/drivers/phy/phy-rockchip-emmc.c
>>> index 9dce958233a0..a2aa6aca7dec 100644
>>> --- a/drivers/phy/phy-rockchip-emmc.c
>>> +++ b/drivers/phy/phy-rockchip-emmc.c
>>> @@ -88,15 +88,36 @@ static int rockchip_emmc_phy_power(struct phy *phy,
>>> bool on_off)
>>> unsigned int caldone;
>>> unsigned int dllrdy;
>>> unsigned int freqsel = PHYCTRL_FREQSEL_200M;
>>> + unsigned long rate;
>>> unsigned long timeout;
>>>
>>> - if (rk_phy->emmcclk != NULL) {
>>> - unsigned long rate = clk_get_rate(rk_phy->emmcclk);
>>> + /*
>>> + * Keep phyctrl_pdb and phyctrl_endll low to allow
>>> + * initialization of CALIO state M/C DFFs
>>> + */
>>> + regmap_write(rk_phy->reg_base,
>>> + rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>>> + HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
>>> +PHYCTRL_PDB_MASK,
>>> +PHYCTRL_PDB_SHIFT));
>>> + regmap_write(rk_phy->reg_base,
>>> + rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>>> + HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
>>> +PHYCTRL_ENDLL_MASK,
>>> +PHYCTRL_ENDLL_SHIFT));
>>> +
>>> + /* Already finish power_off above */
>>> + if (on_off == PHYCTRL_PDB_PWR_OFF)
>>> + return 0;
>>> +
>>> + rate = clk_get_rate(rk_phy->emmcclk);
>>> +
>>> + if (rate != 0) {
>>> unsigned long ideal_rate;
>>> unsigned long diff;
>>>
>>> switch (rate) {
>>> - case 0 ... 7499:
>>> + case 1 ... 7499:
>>> ideal_rate = 5000;
>>> freqsel = PHYCTRL_FREQSEL_50M;
>>> break;
>>> @@ -127,25 +148,6 @@ static int rockchip_emmc_phy_power(struct phy *phy,
>>> bool on_off)
>>> }
>>>
>>> /*
>>> - * Keep phyctrl_pdb and phyctrl_endll low to allow
>>> - * initialization of CALIO state M/C DFFs
>>> - */
>>> - regmap_write(rk_phy->reg_base,
>>> - rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>>> - HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
>>> -PHYCTRL_PDB_MASK,
>>> -PHYCTRL_PDB_SHIFT));
>>> - regmap_write(rk_phy->reg_base,
>>> - rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>>> - HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
>>> -PHYCTRL_ENDLL_MASK,
>>> -PHYCTRL_ENDLL_SHIFT));
>>> -
>>> - /* Already finish power_off above */
>>> - if (on_off == PHYCTRL_PDB_PWR_OFF)
>>> - return 0;
>>> -
>>> - /*
>>>* According to the user manual, calpad calibration
>>>* cycle takes more than 2us without the minimal recommended
>>>* value, so we may need a little margin here
>>> @@ -183,6 +185,19 @@ static int rockchip_emmc_phy_power(struct phy *phy,
>>> bool on_off)
>>>HIWORD_UPDATE(PHYCTRL_ENDLL_ENABLE,
>>> PHYCTRL_ENDLL_MASK,
>>> PHYCTRL_ENDLL_SHIFT));
>>> +
>>> + /*
>>> + * We turned on the DLL even though the rate was 0 because we the
>>> + * clock might be turned on later. ...but we can't wait for the DLL
>>> + * to lock when the rate is 0 because it will never lock with no
>>> + * input clock.
>>> + *
>>> + * Technically we should be checking the lock later when the clock
>>> + * is turned on, but for now we won't.
>>> + */
>>> + if (rate == 0)
>>> + return 0;
>>
>> Why not return initially from rockchip_emmc_phy_power if the clock rate is
>> '0'.
>> Are there other functions to lock the DLL apart from phy_power?
>
> Yeah, it's a big ugly right now. This ugliness is really needed
> because of
Re: [PATCH] mmc: sdhci-msm: Add set_uhs_signaling() implementation
On 19 July 2016 at 16:52, Georgi Djakov wrote:
> From: Ritesh Harjani
>
> To allow UHS mode to work properly, we need to implement a Qualcomm
> specific set_uhs_signaling() callback function. This function differs
> from the sdhci_set_uhs_signaling() in that we need check the clock
> rate and enable UHS timing only if the frequency is above 100MHz.
>
> Signed-off-by: Ritesh Harjani
> Signed-off-by: Georgi Djakov
Thanks, applied for next! Updated the change log according to comments
from Adrian.
Kind regards
Uffe
> ---
>
> This patch resolves the mmc_select_hs200 timeouts noticed after merging
> commit a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after
> speed mode switch")
>
> mmc0: mmc_select_hs200 failed, error -110
> mmc0: error -110 whilst initialising MMC card
> mmc0: Reset 0x1 never completed.
> sdhci: === REGISTER DUMP (mmc0)===
> sdhci: Sys addr: 0x | Version: 0x2e02
> sdhci: Blk size: 0x4000 | Blk cnt: 0x
> sdhci: Argument: 0x | Trn mode: 0x
> sdhci: Present: 0x01f8 | Host ctl: 0x
> sdhci: Power: 0x | Blk gap: 0x
> sdhci: Wake-up: 0x | Clock: 0x0003
> sdhci: Timeout: 0x | Int stat: 0x
> sdhci: Int enab: 0x | Sig enab: 0x
> sdhci: AC12 err: 0x | Slot int: 0x
> sdhci: Caps: 0x322dc8b2 | Caps_1: 0x8007
> sdhci: Cmd: 0x | Max curr: 0x
> sdhci: Host ctl2: 0x
> sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> sdhci: ===
>
> drivers/mmc/host/sdhci-msm.c | 48
> +-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 343e4bd4dc08..d1fce941cdd4 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -410,6 +410,52 @@ retry:
> return rc;
> }
>
> +static void sdhci_msm_set_uhs_signaling(struct sdhci_host *host,
> + unsigned int uhs)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u16 ctrl_2;
> +
> + ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + /* Select Bus Speed Mode for host */
> + ctrl_2 &= ~SDHCI_CTRL_UHS_MASK;
> + switch (uhs) {
> + case MMC_TIMING_UHS_SDR12:
> + ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
> + break;
> + case MMC_TIMING_UHS_SDR25:
> + ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
> + break;
> + case MMC_TIMING_UHS_SDR50:
> + ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
> + break;
> + case MMC_TIMING_MMC_HS200:
> + case MMC_TIMING_UHS_SDR104:
> + ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
> + break;
> + case MMC_TIMING_UHS_DDR50:
> + case MMC_TIMING_MMC_DDR52:
> + ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
> + break;
> + }
> +
> + /*
> +* When clock frequency is less than 100MHz, the feedback clock must
> be
> +* provided and DLL must not be used so that tuning can be skipped. To
> +* provide feedback clock, the mode selection can be any value less
> +* than 3'b011 in bits [2:0] of HOST CONTROL2 register.
> +*/
> + if (host->clock <= 1 &&
> + (uhs == MMC_TIMING_MMC_HS400 ||
> +uhs == MMC_TIMING_MMC_HS200 ||
> +uhs == MMC_TIMING_UHS_SDR104))
> + ctrl_2 &= ~SDHCI_CTRL_UHS_MASK;
> +
> + dev_dbg(mmc_dev(mmc), "%s: clock=%u uhs=%u ctrl_2=0x%x\n",
> + mmc_hostname(host->mmc), host->clock, uhs, ctrl_2);
> + sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
> @@ -422,7 +468,7 @@ static const struct sdhci_ops sdhci_msm_ops = {
> .reset = sdhci_reset,
> .set_clock = sdhci_set_clock,
> .set_bus_width = sdhci_set_bus_width,
> - .set_uhs_signaling = sdhci_set_uhs_signaling,
> + .set_uhs_signaling = sdhci_msm_set_uhs_signaling,
> };
>
> static const struct sdhci_pltfm_data sdhci_msm_pdata = {
RE: [PATCH] tipc: fix NULL pointer dereference in shutdown()
Acked-by: Ying Xue -Original Message- From: Vegard Nossum [mailto:vegard.nos...@oracle.com] Sent: Saturday, July 23, 2016 2:15 PM To: Jon Maloy; Xue, Ying Cc: net...@vger.kernel.org; David S. Miller; Michael Kerrisk; linux-kernel@vger.kernel.org; Vegard Nossum; sta...@vger.kernel.org Subject: [PATCH] tipc: fix NULL pointer dereference in shutdown() tipc_msg_create() can return a NULL skb and if so, we shouldn't try to call tipc_node_xmit_skb() on it. general protection fault: [#1] PREEMPT SMP KASAN CPU: 3 PID: 30298 Comm: trinity-c0 Not tainted 4.7.0-rc7+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 task: 8800baf09980 ti: 8800595b8000 task.ti: 8800595b8000 RIP: 0010:[] [] tipc_node_xmit_skb+0x6b/0x140 RSP: 0018:8800595bfce8 EFLAGS: 00010246 RAX: RBX: RCX: 3023b0e0 RDX: RSI: dc00 RDI: 83d12580 RBP: 8800595bfd78 R08: ed000b2b7f32 R09: R10: fbfff0759725 R11: R12: 11000b2b7f9f R13: 8800595bfd58 R14: 83d12580 R15: dc00 FS: 7fcdde242700() GS:88011af8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fcddde1db10 CR3: 6874b000 CR4: 06e0 DR0: 7fcdde248000 DR1: 7fcddd73d000 DR2: 7fcdde248000 DR3: DR6: 0ff0 DR7: 00090602 Stack: 0018 0018 41b58ab3 83954208 830bb400 8800595bfd30 8309d767 0018 0018 8800595bfd78 8309da1a 810ee611 Call Trace: [] tipc_shutdown+0x553/0x880 [] SyS_shutdown+0x14b/0x170 [] do_syscall_64+0x19c/0x410 [] entry_SYSCALL64_slow_path+0x25/0x25 Code: 90 00 b4 0b 83 c7 00 f1 f1 f1 f1 4c 8d 6d e0 c7 40 04 00 00 00 f4 c7 40 08 f3 f3 f3 f3 48 89 d8 48 c1 e8 03 c7 45 b4 00 00 00 00 <80> 3c 30 00 75 78 48 8d 7b 08 49 8d 75 c0 48 b8 00 00 00 00 00 RIP [] tipc_node_xmit_skb+0x6b/0x140 RSP ---[ end trace 57b0484e351e71f1 ]--- I feel like we should maybe return -ENOMEM or -ENOBUFS, but I'm not sure userspace is equipped to handle that. Anyway, this is better than a GPF and looks somewhat consistent with other tipc_msg_create() callers. Cc: sta...@vger.kernel.org Signed-off-by: Vegard Nossum --- net/tipc/socket.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index c49b8df..f9f5f3c 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -2180,7 +2180,8 @@ restart: TIPC_CONN_MSG, SHORT_H_SIZE, 0, dnode, onode, dport, oport, TIPC_CONN_SHUTDOWN); - tipc_node_xmit_skb(net, skb, dnode, tsk->portid); + if (skb) + tipc_node_xmit_skb(net, skb, dnode, tsk->portid); } tsk->connected = 0; sock->state = SS_DISCONNECTING; -- 1.9.1
[PATCH 4/6] spi: octeon: Move include file from arch/mips to drivers/spi
Move the register definitions to the drivers directory because they
are only used there.
Signed-off-by: Jan Glauber
Tested-by: Steven J. Hill
---
.../cvmx-mpi-defs.h => drivers/spi/spi-cavium.h| 32 +-
drivers/spi/spi-octeon.c | 3 +-
2 files changed, 3 insertions(+), 32 deletions(-)
rename arch/mips/include/asm/octeon/cvmx-mpi-defs.h =>
drivers/spi/spi-cavium.h (84%)
diff --git a/arch/mips/include/asm/octeon/cvmx-mpi-defs.h
b/drivers/spi/spi-cavium.h
similarity index 84%
rename from arch/mips/include/asm/octeon/cvmx-mpi-defs.h
rename to drivers/spi/spi-cavium.h
index 4615b10..d41dba5 100644
--- a/arch/mips/include/asm/octeon/cvmx-mpi-defs.h
+++ b/drivers/spi/spi-cavium.h
@@ -1,32 +1,4 @@
-/***license start***
- * Author: Cavium Networks
- *
- * Contact: supp...@caviumnetworks.com
- * This file is part of the OCTEON SDK
- *
- * Copyright (c) 2003-2012 Cavium Networks
- *
- * This file is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, Version 2, as
- * published by the Free Software Foundation.
- *
- * This file is distributed in the hope that it will be useful, but
- * AS-IS and WITHOUT ANY WARRANTY; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, TITLE, or
- * NONINFRINGEMENT. See the GNU General Public License for more
- * details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this file; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- * or visit http://www.gnu.org/licenses/.
- *
- * This file may also be available under a different license from Cavium.
- * Contact Cavium Networks for more information
- ***license end**/
-
-#ifndef __CVMX_MPI_DEFS_H__
-#define __CVMX_MPI_DEFS_H__
+/* MPI register descriptions */
#define CVMX_MPI_CFG (CVMX_ADD_IO_SEG(0x000107001000ull))
#define CVMX_MPI_DATX(offset) (CVMX_ADD_IO_SEG(0x000107001080ull) +
((offset) & 15) * 8)
@@ -324,5 +296,3 @@ union cvmx_mpi_tx {
struct cvmx_mpi_tx_s cn66xx;
struct cvmx_mpi_tx_cn61xx cnf71xx;
};
-
-#endif
diff --git a/drivers/spi/spi-octeon.c b/drivers/spi/spi-octeon.c
index 209eddc..2180176 100644
--- a/drivers/spi/spi-octeon.c
+++ b/drivers/spi/spi-octeon.c
@@ -15,7 +15,8 @@
#include
#include
-#include
+
+#include "spi-cavium.h"
#define OCTEON_SPI_MAX_BYTES 9
--
2.9.0.rc0.21.g322
[PATCH 0/6] SPI ThunderX driver
Hi Mark, This series adds support for SPI on Cavium's ThunderX (arm64). The SPI hardware is the same as on MIPS Octeon, the only difference is that the device appears as a PCI device. To avoid copy and paste of the Octeon driver I've moved the common parts into a shared file. Patches #1-5 prepare the Octeon driver for re-use. Patch #6 adds the ThunderX driver. The series was tested on MIPS (Edge Router PRO and cn71xx) and ThunderX. Feedback welcome! thanks, Jan Jan Glauber (5): spi: octeon: Store system clock freqency in struct octeon_spi spi: octeon: Put register offsets into a struct spi: octeon: Move include file from arch/mips to drivers/spi spi: octeon: Split driver into Octeon specific and common parts spi: octeon: Add thunderx driver Steven J. Hill (1): spi: octeon: Convert driver to use readq()/writeq() functions drivers/spi/Kconfig| 7 + drivers/spi/Makefile | 3 + drivers/spi/spi-cavium-octeon.c| 104 + drivers/spi/spi-cavium-thunderx.c | 158 + drivers/spi/spi-cavium.c | 151 .../cvmx-mpi-defs.h => drivers/spi/spi-cavium.h| 62 ++--- drivers/spi/spi-octeon.c | 255 - 7 files changed, 456 insertions(+), 284 deletions(-) create mode 100644 drivers/spi/spi-cavium-octeon.c create mode 100644 drivers/spi/spi-cavium-thunderx.c create mode 100644 drivers/spi/spi-cavium.c rename arch/mips/include/asm/octeon/cvmx-mpi-defs.h => drivers/spi/spi-cavium.h (84%) delete mode 100644 drivers/spi/spi-octeon.c -- 2.9.0.rc0.21.g322
[PATCH 3/6] spi: octeon: Put register offsets into a struct
Instead of hard-coding the register offsets put them into a struct
and set them in the probe function.
Signed-off-by: Jan Glauber
Tested-by: Steven J. Hill
---
drivers/spi/spi-octeon.c | 41 +++--
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-octeon.c b/drivers/spi/spi-octeon.c
index e722040..209eddc 100644
--- a/drivers/spi/spi-octeon.c
+++ b/drivers/spi/spi-octeon.c
@@ -17,22 +17,30 @@
#include
#include
-#define OCTEON_SPI_CFG 0
-#define OCTEON_SPI_STS 0x08
-#define OCTEON_SPI_TX 0x10
-#define OCTEON_SPI_DAT0 0x80
-
#define OCTEON_SPI_MAX_BYTES 9
#define OCTEON_SPI_MAX_CLOCK_HZ 1600
+struct octeon_spi_regs {
+ int config;
+ int status;
+ int tx;
+ int data;
+};
+
struct octeon_spi {
void __iomem *register_base;
u64 last_cfg;
u64 cs_enax;
int sys_freq;
+ struct octeon_spi_regs regs;
};
+#define OCTEON_SPI_CFG(x) (x->regs.config)
+#define OCTEON_SPI_STS(x) (x->regs.status)
+#define OCTEON_SPI_TX(x) (x->regs.tx)
+#define OCTEON_SPI_DAT0(x) (x->regs.data)
+
static void octeon_spi_wait_ready(struct octeon_spi *p)
{
union cvmx_mpi_sts mpi_sts;
@@ -41,7 +49,7 @@ static void octeon_spi_wait_ready(struct octeon_spi *p)
do {
if (loops++)
__delay(500);
- mpi_sts.u64 = readq(p->register_base + OCTEON_SPI_STS);
+ mpi_sts.u64 = readq(p->register_base + OCTEON_SPI_STS(p));
} while (mpi_sts.s.busy);
}
@@ -83,7 +91,7 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
if (mpi_cfg.u64 != p->last_cfg) {
p->last_cfg = mpi_cfg.u64;
- writeq(mpi_cfg.u64, p->register_base + OCTEON_SPI_CFG);
+ writeq(mpi_cfg.u64, p->register_base + OCTEON_SPI_CFG(p));
}
tx_buf = xfer->tx_buf;
rx_buf = xfer->rx_buf;
@@ -95,19 +103,19 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
d = *tx_buf++;
else
d = 0;
- writeq(d, p->register_base + OCTEON_SPI_DAT0 + (8 * i));
+ writeq(d, p->register_base + OCTEON_SPI_DAT0(p) + (8 *
i));
}
mpi_tx.u64 = 0;
mpi_tx.s.csid = spi->chip_select;
mpi_tx.s.leavecs = 1;
mpi_tx.s.txnum = tx_buf ? OCTEON_SPI_MAX_BYTES : 0;
mpi_tx.s.totnum = OCTEON_SPI_MAX_BYTES;
- writeq(mpi_tx.u64, p->register_base + OCTEON_SPI_TX);
+ writeq(mpi_tx.u64, p->register_base + OCTEON_SPI_TX(p));
octeon_spi_wait_ready(p);
if (rx_buf)
for (i = 0; i < OCTEON_SPI_MAX_BYTES; i++) {
- u64 v = readq(p->register_base +
OCTEON_SPI_DAT0 + (8 * i));
+ u64 v = readq(p->register_base +
OCTEON_SPI_DAT0(p) + (8 * i));
*rx_buf++ = (u8)v;
}
len -= OCTEON_SPI_MAX_BYTES;
@@ -119,7 +127,7 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
d = *tx_buf++;
else
d = 0;
- writeq(d, p->register_base + OCTEON_SPI_DAT0 + (8 * i));
+ writeq(d, p->register_base + OCTEON_SPI_DAT0(p) + (8 * i));
}
mpi_tx.u64 = 0;
@@ -130,12 +138,12 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
mpi_tx.s.leavecs = !xfer->cs_change;
mpi_tx.s.txnum = tx_buf ? len : 0;
mpi_tx.s.totnum = len;
- writeq(mpi_tx.u64, p->register_base + OCTEON_SPI_TX);
+ writeq(mpi_tx.u64, p->register_base + OCTEON_SPI_TX(p));
octeon_spi_wait_ready(p);
if (rx_buf)
for (i = 0; i < len; i++) {
- u64 v = readq(p->register_base + OCTEON_SPI_DAT0 + (8 *
i));
+ u64 v = readq(p->register_base + OCTEON_SPI_DAT0(p) +
(8 * i));
*rx_buf++ = (u8)v;
}
@@ -194,6 +202,11 @@ static int octeon_spi_probe(struct platform_device *pdev)
p->register_base = reg_base;
p->sys_freq = octeon_get_io_clock_rate();
+ p->regs.config = 0;
+ p->regs.status = 0x08;
+ p->regs.tx = 0x10;
+ p->regs.data = 0x80;
+
master->num_chipselect = 4;
master->mode_bits = SPI_CPHA |
SPI_CPOL |
@@ -226,7 +239,7 @@ static int octeon_spi_remove(struct platform_device *pdev)
struct octeon_spi *p = spi_master_get_devdata(master);
/* Clear the CSENA* and put everything in a known state. */
- writeq(0, p->register_base + OCTEON_SPI_CFG);
+ writeq(0, p->register_base + OCTEON_SPI_CFG(p));
return 0;
}
--
2.9.0.rc0.21.g322
[PATCH 6/6] spi: octeon: Add thunderx driver
Add ThunderX SPI driver using the shared part from the Octeon
driver. The main difference of the ThunderX driver is that it
is a PCI device so probing is different. The system clock settings
can be specified in device tree.
Signed-off-by: Jan Glauber
---
drivers/spi/Kconfig | 7 ++
drivers/spi/Makefile | 2 +
drivers/spi/spi-cavium-thunderx.c | 158 ++
drivers/spi/spi-cavium.h | 3 +
4 files changed, 170 insertions(+)
create mode 100644 drivers/spi/spi-cavium-thunderx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 4b931ec..db02ba7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -630,6 +630,13 @@ config SPI_TEGRA20_SLINK
help
SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
+config SPI_THUNDERX
+ tristate "Cavium ThunderX SPI controller"
+ depends on 64BIT && PCI && !CAVIUM_OCTEON_SOC
+ help
+ SPI host driver for the hardware found on Cavium ThunderX
+ SOCs.
+
config SPI_TOPCLIFF_PCH
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) SPI"
depends on PCI && (X86_32 || MIPS || COMPILE_TEST)
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 185367e..133364b 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -91,6 +91,8 @@ obj-$(CONFIG_SPI_TEGRA114)+= spi-tegra114.o
obj-$(CONFIG_SPI_TEGRA20_SFLASH) += spi-tegra20-sflash.o
obj-$(CONFIG_SPI_TEGRA20_SLINK)+= spi-tegra20-slink.o
obj-$(CONFIG_SPI_TLE62X0) += spi-tle62x0.o
+spi-thunderx-objs := spi-cavium.o spi-cavium-thunderx.o
+obj-$(CONFIG_SPI_THUNDERX) += spi-thunderx.o
obj-$(CONFIG_SPI_TOPCLIFF_PCH) += spi-topcliff-pch.o
obj-$(CONFIG_SPI_TXX9) += spi-txx9.o
obj-$(CONFIG_SPI_XCOMM)+= spi-xcomm.o
diff --git a/drivers/spi/spi-cavium-thunderx.c
b/drivers/spi/spi-cavium-thunderx.c
new file mode 100644
index 000..7eb9141
--- /dev/null
+++ b/drivers/spi/spi-cavium-thunderx.c
@@ -0,0 +1,158 @@
+/*
+ * Cavium ThunderX SPI driver.
+ *
+ * Copyright (C) 2016 Cavium Inc.
+ * Authors: Jan Glauber
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "spi-cavium.h"
+
+#define DRV_NAME "spi-thunderx"
+
+#define SYS_FREQ_DEFAULT 7
+
+static void thunderx_spi_clock_enable(struct device *dev, struct octeon_spi *p)
+{
+ int ret;
+
+ p->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(p->clk)) {
+ p->clk = NULL;
+ goto skip;
+ }
+
+ ret = clk_prepare_enable(p->clk);
+ if (ret)
+ goto skip;
+ p->sys_freq = clk_get_rate(p->clk);
+
+skip:
+ if (!p->sys_freq)
+ p->sys_freq = SYS_FREQ_DEFAULT;
+
+ dev_info(dev, "Set system clock to %u\n", p->sys_freq);
+}
+
+static void thunderx_spi_clock_disable(struct device *dev, struct clk *clk)
+{
+ if (!clk)
+ return;
+ clk_disable_unprepare(clk);
+ devm_clk_put(dev, clk);
+}
+
+static int thunderx_spi_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ struct device *dev = &pdev->dev;
+ struct spi_master *master;
+ struct octeon_spi *p;
+ int ret = -ENOENT;
+
+ master = spi_alloc_master(dev, sizeof(struct octeon_spi));
+ if (!master)
+ return -ENOMEM;
+ p = spi_master_get_devdata(master);
+
+ ret = pci_enable_device(pdev);
+ if (ret) {
+ dev_err(dev, "Failed to enable PCI device\n");
+ goto out_free;
+ }
+
+ ret = pci_request_regions(pdev, DRV_NAME);
+ if (ret) {
+ dev_err(dev, "PCI request regions failed 0x%x\n", ret);
+ goto out_disable;
+ }
+
+ p->register_base = pci_ioremap_bar(pdev, 0);
+ if (!p->register_base) {
+ dev_err(dev, "Cannot map reg base\n");
+ ret = -EINVAL;
+ goto out_region;
+ }
+
+ p->regs.config = 0x1000;
+ p->regs.status = 0x1008;
+ p->regs.tx = 0x1010;
+ p->regs.data = 0x1080;
+
+ thunderx_spi_clock_enable(dev, p);
+
+ master->num_chipselect = 4;
+ master->mode_bits = SPI_CPHA | SPI_CPOL | SPI_CS_HIGH |
+ SPI_LSB_FIRST | SPI_3WIRE;
+ master->transfer_one_message = octeon_spi_transfer_one_message;
+ master->bits_per_word_mask = SPI_BPW_MASK(8);
+ master->max_speed_hz = OCTEON_SPI_MAX_CLOCK_HZ;
+ master->dev.of_node = pdev->dev.of_node;
+
+ pci_set_drvdata(pdev, master);
+ ret = devm_spi_register_master(dev, master);
+ if (ret) {
+ dev_err(&pdev->dev, "Register master failed: %d\n", ret);
+ goto out_unmap;
+ }
+
+ dev_info(&pdev->dev, "Cavium SPI bus driver probed\n");
+ return 0;
+
[PATCH 2/6] spi: octeon: Store system clock freqency in struct octeon_spi
Storing the system clock frequency in struct octeon_spi avoids
calling the MIPS specific octeon_get_io_clock_rate() for every transfer.
Signed-off-by: Jan Glauber
Tested-by: Steven J. Hill
---
drivers/spi/spi-octeon.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-octeon.c b/drivers/spi/spi-octeon.c
index b53ba53..e722040 100644
--- a/drivers/spi/spi-octeon.c
+++ b/drivers/spi/spi-octeon.c
@@ -30,6 +30,7 @@ struct octeon_spi {
void __iomem *register_base;
u64 last_cfg;
u64 cs_enax;
+ int sys_freq;
};
static void octeon_spi_wait_ready(struct octeon_spi *p)
@@ -53,7 +54,6 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
union cvmx_mpi_cfg mpi_cfg;
union cvmx_mpi_tx mpi_tx;
unsigned int clkdiv;
- unsigned int speed_hz;
int mode;
bool cpha, cpol;
const u8 *tx_buf;
@@ -65,9 +65,7 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
cpha = mode & SPI_CPHA;
cpol = mode & SPI_CPOL;
- speed_hz = xfer->speed_hz;
-
- clkdiv = octeon_get_io_clock_rate() / (2 * speed_hz);
+ clkdiv = p->sys_freq / (2 * xfer->speed_hz);
mpi_cfg.u64 = 0;
@@ -194,6 +192,7 @@ static int octeon_spi_probe(struct platform_device *pdev)
}
p->register_base = reg_base;
+ p->sys_freq = octeon_get_io_clock_rate();
master->num_chipselect = 4;
master->mode_bits = SPI_CPHA |
--
2.9.0.rc0.21.g322
[PATCH 1/6] spi: octeon: Convert driver to use readq()/writeq() functions
From: "Steven J. Hill"
Remove all calls to cvmx_read_csr()/cvmx_write_csr() and use
the portable readq()/writeq() functions.
Signed-off-by: Steven J. Hill
Signed-off-by: Jan Glauber
---
drivers/spi/spi-octeon.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-octeon.c b/drivers/spi/spi-octeon.c
index 3b17009..b53ba53 100644
--- a/drivers/spi/spi-octeon.c
+++ b/drivers/spi/spi-octeon.c
@@ -27,7 +27,7 @@
#define OCTEON_SPI_MAX_CLOCK_HZ 1600
struct octeon_spi {
- u64 register_base;
+ void __iomem *register_base;
u64 last_cfg;
u64 cs_enax;
};
@@ -40,7 +40,7 @@ static void octeon_spi_wait_ready(struct octeon_spi *p)
do {
if (loops++)
__delay(500);
- mpi_sts.u64 = cvmx_read_csr(p->register_base + OCTEON_SPI_STS);
+ mpi_sts.u64 = readq(p->register_base + OCTEON_SPI_STS);
} while (mpi_sts.s.busy);
}
@@ -85,7 +85,7 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
if (mpi_cfg.u64 != p->last_cfg) {
p->last_cfg = mpi_cfg.u64;
- cvmx_write_csr(p->register_base + OCTEON_SPI_CFG, mpi_cfg.u64);
+ writeq(mpi_cfg.u64, p->register_base + OCTEON_SPI_CFG);
}
tx_buf = xfer->tx_buf;
rx_buf = xfer->rx_buf;
@@ -97,19 +97,19 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
d = *tx_buf++;
else
d = 0;
- cvmx_write_csr(p->register_base + OCTEON_SPI_DAT0 + (8
* i), d);
+ writeq(d, p->register_base + OCTEON_SPI_DAT0 + (8 * i));
}
mpi_tx.u64 = 0;
mpi_tx.s.csid = spi->chip_select;
mpi_tx.s.leavecs = 1;
mpi_tx.s.txnum = tx_buf ? OCTEON_SPI_MAX_BYTES : 0;
mpi_tx.s.totnum = OCTEON_SPI_MAX_BYTES;
- cvmx_write_csr(p->register_base + OCTEON_SPI_TX, mpi_tx.u64);
+ writeq(mpi_tx.u64, p->register_base + OCTEON_SPI_TX);
octeon_spi_wait_ready(p);
if (rx_buf)
for (i = 0; i < OCTEON_SPI_MAX_BYTES; i++) {
- u64 v = cvmx_read_csr(p->register_base +
OCTEON_SPI_DAT0 + (8 * i));
+ u64 v = readq(p->register_base +
OCTEON_SPI_DAT0 + (8 * i));
*rx_buf++ = (u8)v;
}
len -= OCTEON_SPI_MAX_BYTES;
@@ -121,7 +121,7 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
d = *tx_buf++;
else
d = 0;
- cvmx_write_csr(p->register_base + OCTEON_SPI_DAT0 + (8 * i), d);
+ writeq(d, p->register_base + OCTEON_SPI_DAT0 + (8 * i));
}
mpi_tx.u64 = 0;
@@ -132,12 +132,12 @@ static int octeon_spi_do_transfer(struct octeon_spi *p,
mpi_tx.s.leavecs = !xfer->cs_change;
mpi_tx.s.txnum = tx_buf ? len : 0;
mpi_tx.s.totnum = len;
- cvmx_write_csr(p->register_base + OCTEON_SPI_TX, mpi_tx.u64);
+ writeq(mpi_tx.u64, p->register_base + OCTEON_SPI_TX);
octeon_spi_wait_ready(p);
if (rx_buf)
for (i = 0; i < len; i++) {
- u64 v = cvmx_read_csr(p->register_base +
OCTEON_SPI_DAT0 + (8 * i));
+ u64 v = readq(p->register_base + OCTEON_SPI_DAT0 + (8 *
i));
*rx_buf++ = (u8)v;
}
@@ -193,7 +193,7 @@ static int octeon_spi_probe(struct platform_device *pdev)
goto fail;
}
- p->register_base = (u64)reg_base;
+ p->register_base = reg_base;
master->num_chipselect = 4;
master->mode_bits = SPI_CPHA |
@@ -225,10 +225,9 @@ static int octeon_spi_remove(struct platform_device *pdev)
{
struct spi_master *master = platform_get_drvdata(pdev);
struct octeon_spi *p = spi_master_get_devdata(master);
- u64 register_base = p->register_base;
/* Clear the CSENA* and put everything in a known state. */
- cvmx_write_csr(register_base + OCTEON_SPI_CFG, 0);
+ writeq(0, p->register_base + OCTEON_SPI_CFG);
return 0;
}
--
2.9.0.rc0.21.g322
[PATCH 5/6] spi: octeon: Split driver into Octeon specific and common parts
Separate driver probing from SPI transfer functions.
Signed-off-by: Jan Glauber
Tested-by: Steven J. Hill
---
drivers/spi/Makefile | 1 +
drivers/spi/spi-cavium-octeon.c| 104 +
drivers/spi/{spi-octeon.c => spi-cavium.c} | 120 +
drivers/spi/spi-cavium.h | 31
4 files changed, 138 insertions(+), 118 deletions(-)
create mode 100644 drivers/spi/spi-cavium-octeon.c
rename drivers/spi/{spi-octeon.c => spi-cavium.c} (55%)
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 3c74d00..185367e 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o
obj-$(CONFIG_SPI_MXS) += spi-mxs.o
obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o
obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o
+spi-octeon-objs:= spi-cavium.o
spi-cavium-octeon.o
obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K)+= spi-omap-100k.o
diff --git a/drivers/spi/spi-cavium-octeon.c b/drivers/spi/spi-cavium-octeon.c
new file mode 100644
index 000..ee4703e
--- /dev/null
+++ b/drivers/spi/spi-cavium-octeon.c
@@ -0,0 +1,104 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2011, 2012 Cavium, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "spi-cavium.h"
+
+static int octeon_spi_probe(struct platform_device *pdev)
+{
+ struct resource *res_mem;
+ void __iomem *reg_base;
+ struct spi_master *master;
+ struct octeon_spi *p;
+ int err = -ENOENT;
+
+ master = spi_alloc_master(&pdev->dev, sizeof(struct octeon_spi));
+ if (!master)
+ return -ENOMEM;
+ p = spi_master_get_devdata(master);
+ platform_set_drvdata(pdev, master);
+
+ res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg_base = devm_ioremap_resource(&pdev->dev, res_mem);
+ if (IS_ERR(reg_base)) {
+ err = PTR_ERR(reg_base);
+ goto fail;
+ }
+
+ p->register_base = reg_base;
+ p->sys_freq = octeon_get_io_clock_rate();
+
+ p->regs.config = 0;
+ p->regs.status = 0x08;
+ p->regs.tx = 0x10;
+ p->regs.data = 0x80;
+
+ master->num_chipselect = 4;
+ master->mode_bits = SPI_CPHA |
+ SPI_CPOL |
+ SPI_CS_HIGH |
+ SPI_LSB_FIRST |
+ SPI_3WIRE;
+
+ master->transfer_one_message = octeon_spi_transfer_one_message;
+ master->bits_per_word_mask = SPI_BPW_MASK(8);
+ master->max_speed_hz = OCTEON_SPI_MAX_CLOCK_HZ;
+
+ master->dev.of_node = pdev->dev.of_node;
+ err = devm_spi_register_master(&pdev->dev, master);
+ if (err) {
+ dev_err(&pdev->dev, "register master failed: %d\n", err);
+ goto fail;
+ }
+
+ dev_info(&pdev->dev, "OCTEON SPI bus driver\n");
+
+ return 0;
+fail:
+ spi_master_put(master);
+ return err;
+}
+
+static int octeon_spi_remove(struct platform_device *pdev)
+{
+ struct spi_master *master = platform_get_drvdata(pdev);
+ struct octeon_spi *p = spi_master_get_devdata(master);
+
+ /* Clear the CSENA* and put everything in a known state. */
+ writeq(0, p->register_base + OCTEON_SPI_CFG(p));
+
+ return 0;
+}
+
+static const struct of_device_id octeon_spi_match[] = {
+ { .compatible = "cavium,octeon-3010-spi", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, octeon_spi_match);
+
+static struct platform_driver octeon_spi_driver = {
+ .driver = {
+ .name = "spi-octeon",
+ .of_match_table = octeon_spi_match,
+ },
+ .probe = octeon_spi_probe,
+ .remove = octeon_spi_remove,
+};
+
+module_platform_driver(octeon_spi_driver);
+
+MODULE_DESCRIPTION("Cavium, Inc. OCTEON SPI bus driver");
+MODULE_AUTHOR("David Daney");
+MODULE_LICENSE("GPL");
diff --git a/drivers/spi/spi-octeon.c b/drivers/spi/spi-cavium.c
similarity index 55%
rename from drivers/spi/spi-octeon.c
rename to drivers/spi/spi-cavium.c
index 2180176..5aaf215 100644
--- a/drivers/spi/spi-octeon.c
+++ b/drivers/spi/spi-cavium.c
@@ -6,42 +6,13 @@
* Copyright (C) 2011, 2012 Cavium, Inc.
*/
-#include
-#include
#include
#include
#include
#include
-#include
-
-#include
#include "spi-cavium.h"
-#define OCTEON_SPI_MAX_BYTES 9
-
-#define OCTEON_SPI_MAX_CLOCK_HZ 1600
-
-struct octeon_spi_regs {
- int config;
- int status;
- int tx;
- int data;
-};
-
-struct octeon_spi {
-
Re: [PATCH RFC] coccinelle: tests: if and else branch should probably not be identical
On Fri, 22 Jul 2016, Nicholas Mc Guire wrote: > On Fri, Jul 22, 2016 at 06:56:47PM +0200, Julia Lawall wrote: > > > +virtual context > > > +virtual org > > > +virtual report > > > + > > > +@cond@ > > > +statement S1; > > > +position p; > > > +@@ > > > + > > > +<+... > > > +* if@p (...) S1 else S1 > > > +...+> > > > > You don't need the <+... ...+>. Just put the if by itself. > > > > will drop that then - though those would be needed for the cases that > do this recursively. Will fix it and resend. Sorry, I don't get your point about recursiveness at all. Even if you have bizarrely if (e1) if (e2) S else S else if (e2) S else S the version without <+... ...+> will still work, finding three matches. The <+... ...+> starts the matching process at the beginning of the function and ends it at the end of the function, instead of just working on each if one by one. Thus <+... ...+> should be much less efficient. Also with <+... ...+> if you put a position variable on eg the if, you will get a single position array with all the matches, whereas without it you get one position array per if. The latter is probably easier to manage. julia
[PATCH 0/3] IB/mthca: Fine-tuning for mthca_reset()
From: Markus Elfring Date: Sat, 23 Jul 2016 12:50:12 +0200 Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (3): Delete an unnecessary check before the function call "pci_dev_put" Less function calls after error detection Delete unnecessary variable initialisations drivers/infiniband/hw/mthca/mthca_reset.c | 48 +++ 1 file changed, 23 insertions(+), 25 deletions(-) -- 2.9.2
Re: [PATCH v2 3/4] mfd: add support for Allwinner SoCs ADC
On 22/07/16 15:55, Lee Jones wrote:
> On Thu, 21 Jul 2016, Maxime Ripard wrote:
>
>> 1;4205;0c
>> On Thu, Jul 21, 2016 at 01:12:53PM +0100, Lee Jones wrote:
>>> On Wed, 20 Jul 2016, Jonathan Cameron wrote:
>>>
On 19/07/16 08:31, Lee Jones wrote:
> On Mon, 18 Jul 2016, Jonathan Cameron wrote:
>
>> On 15/07/16 10:59, Quentin Schulz wrote:
>>> The Allwinner SoCs all have an ADC that can also act as a touchscreen
>>> controller and a thermal sensor. For now, only the ADC and the thermal
>>> sensor drivers are probed by the MFD, the touchscreen controller support
>>> will be added later.
>>>
>>> Signed-off-by: Quentin Schulz
>> Hmm. Previous patch includes the header this one creates. Ordering
>> issue?
>> The depends kind of prevents build failures by ensuring that can't be
>> built
>> until this one is in place, but it is certainly an ugly way to do it.
>>
>> Few little bits innline.
>>> ---
>>>
>>> v2:
>>> - add license headers,
>>> - reorder alphabetically includes,
>>> - add SUNXI_GPADC_ prefixes for defines,
>>>
>>> drivers/mfd/Kconfig | 14 +++
>>> drivers/mfd/Makefile| 2 +
>>> drivers/mfd/sunxi-gpadc-mfd.c | 197
>>>
>>> include/linux/mfd/sunxi-gpadc-mfd.h | 23 +
>>> 4 files changed, 236 insertions(+)
>>> create mode 100644 drivers/mfd/sunxi-gpadc-mfd.c
>>> create mode 100644 include/linux/mfd/sunxi-gpadc-mfd.h
>
> [...]
>
>>> +static struct mfd_cell sun6i_gpadc_mfd_cells[] = {
>>> + {
>>> + .name = "sun6i-a31-gpadc-iio",
>>> + .resources = adc_resources,
>>> + .num_resources = ARRAY_SIZE(adc_resources),
>>> + }, {
>>> + .name = "iio_hwmon",
>> I still really dislike using this to force the probe of that driver but
>> kind of up to the hwmon / mfd guys on this.
>
> Can you at least say *why* you don't like it?
It just feels odd to have an mfd child that isn't really dependent
on the mfd hardware itself.
Still if you are happy, mfd is your domain and my objections were
as you probably noticed not that strong - or well described!)
So I'm fine with this.
>>>
>>> I see. So it's not actually part of the same IP/chip?
>>
>> The chip has a temperature sensor, and we want to expose that
>> temperature through IIO.
>>
>> But we don't really have the choice on how we probe iio-hwmon
>> here. The binding was already there, and we have to keep it.
>
> What binding?
>
The somewhat 'interesting' one for iio-hwmon I would guess is what
Maxime is referring to. Here they are using what was effectively
the old 'board file' methods inside the driver itself. Which is
fine and done in quite a few places - though we have some issues
with deferred probing that we can improve upon.
Anyhow, it's real hardware and as this doesn't have anything to
do with device tree there is no need to get around the objections
of lack of generality that bothers the dt maintainers :)
Lets go with it as it is. Sorry for confusing everyone!
p.s. I'm pitching a tech session for the KS at the moment
on ksummit-discuss to hit the fiddlier question of bindings
/ cross subsystem interactions if anyone is interested.
Re: [RCF 1/3] hwmon: Add ads1118 driver
On 22/07/16 16:39, Joshua Clayton wrote: > Greetings Guenter, > > Thank you for reviewing my submission. > > On 07/15/2016 06:40 PM, Guenter Roeck wrote: >> On 07/15/2016 05:18 PM, Joshua Clayton wrote: >>> Add new driver for Texas Instruments ADS1118 and and ADS1018. >>> This driver works with ADS1018, because of code borrowed >>> from asd1015, which is similar, but I can only test ADS1118 >>> >> >> Browsing through the datasheet, I think this should probably be implemented >> as iio driver (and iio already has a driver for ads1015). >> >> Jonathan, what do you think ? >> >> Thanks, >> Guenter >> > No response from Jonathan as yet, but I am willing to rework the driver when I > have some time. It might be weeks before I can start, though. Sorry, made week and I thought I'd have time to get reviews done in evenings so didn't look at anything last weekend. Catching up on train home this morning. > > I am not very familiar with the iio subsystem, (actually had never heard of > it before > receiving your response). Learning it might be beneficial, as it looks like a > good fit > for an in house driver, which I'd like to eventually upstream. Cool > > If an hwmon driver is adequate, I have new patches that address kbuild and > endianness > issues in the first version. I'd flip it over to IIO. If you keep to just the simple bits it'll end up pretty simple to do. > > > ~Joshua Clayton > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH v2] iio: humidity: hdc100x: add triggered buffer support for HDC100X
On 22/07/16 07:31, Alison Schofield wrote:
> Triggered buffer support uses the HDC100X's dual acquisition mode
> to read both humidity and temperature in one shot.
>
> Signed-off-by: Alison Schofield
> Cc: Daniel Baluta
Few bits and pieces. Didn't read your own review email closely enough
to know how many of your bits I missed ;)
The 'big' one here is that this introduces a regression if the
I2C adapter isn't able to do the new reads.
Also, if the combined read makes sense, then let the demux
in the IIO core handle the channel shuffling necessary.
>From your comments I suspect both of these will go away anyway
if you are going to read only relevant channels in the next version.
Jonathan
> ---
> Changes in v2:
> Thanks for the review Peter
> - switched endianness from IIO_CPU to IIO_BE
> - use only one buffer in the handler
> - simplify selection of temp &/or humidity to push to buffer
>
> drivers/iio/humidity/Kconfig | 2 +
> drivers/iio/humidity/hdc100x.c | 135
> +++--
> 2 files changed, 131 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
> index 738a86d..4883ce1 100644
> --- a/drivers/iio/humidity/Kconfig
> +++ b/drivers/iio/humidity/Kconfig
> @@ -25,6 +25,8 @@ config DHT11
> config HDC100X
> tristate "TI HDC100x relative humidity and temperature sensor"
> depends on I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> help
>Say yes here to build support for the TI HDC100x series of
>relative humidity and temperature sensors.
> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
> index a03832a..9f41bb5 100644
> --- a/drivers/iio/humidity/hdc100x.c
> +++ b/drivers/iio/humidity/hdc100x.c
> @@ -22,13 +22,19 @@
>
> #include
> #include
> +#include
> +#include
> +#include
>
> #define HDC100X_REG_TEMP 0x00
> #define HDC100X_REG_HUMIDITY 0x01
>
> #define HDC100X_REG_CONFIG 0x02
> +#define HDC100X_REG_CONFIG_ACQ_MODE BIT(12)
> #define HDC100X_REG_CONFIG_HEATER_EN BIT(13)
>
> +#define HDC100X_ALL_CHANNEL_MASK GENMASK(1, 0)
Not used?
> +
> struct hdc100x_data {
> struct i2c_client *client;
> struct mutex lock;
> @@ -87,20 +93,36 @@ static const struct iio_chan_spec hdc100x_channels[] = {
> BIT(IIO_CHAN_INFO_SCALE) |
> BIT(IIO_CHAN_INFO_INT_TIME) |
> BIT(IIO_CHAN_INFO_OFFSET),
> + .scan_index = 0,
> + .scan_type = {
> + .sign = 's',
> + .realbits = 16,
> + .storagebits = 16,
> + .endianness = IIO_BE,
> + },
> },
> {
> .type = IIO_HUMIDITYRELATIVE,
> .address = HDC100X_REG_HUMIDITY,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> BIT(IIO_CHAN_INFO_SCALE) |
> - BIT(IIO_CHAN_INFO_INT_TIME)
> + BIT(IIO_CHAN_INFO_INT_TIME),
> + .scan_index = 1,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 16,
> + .storagebits = 16,
> + .endianness = IIO_BE,
> + },
> },
> {
> .type = IIO_CURRENT,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> .extend_name = "heater",
> .output = 1,
> + .scan_index = -1,
> },
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> };
>
> static int hdc100x_update_config(struct hdc100x_data *data, int mask, int
> val)
> @@ -191,18 +213,21 @@ static int hdc100x_read_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_RAW: {
> int ret;
>
> - mutex_lock(&data->lock);
Why the lock removal - remember the direct_mode stuff is only used
for locking the mode. At least from a readability point of view, I'd
keep the local lock.
> if (chan->type == IIO_CURRENT) {
> *val = hdc100x_get_heater_status(data);
> ret = IIO_VAL_INT;
> } else {
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
> +
> ret = hdc100x_get_measurement(data, chan);
> + iio_device_release_direct_mode(indio_dev);
> if (ret >= 0) {
> *val = ret;
> ret = IIO_VAL_INT;
> }
> }
> - mutex_unlock(&data->lock);
> return ret;
> }
> case IIO_CHAN_INFO_INT_TIME:
> @@ -259,6 +284,80 @@ static int hdc100x_write_raw(struct iio_dev *indio_dev,
> }
> }
>
> +static int h
Re: [PATCH v2 2/4] iio: adc: add support for Allwinner SoCs ADC
On 21/07/16 14:15, Quentin Schulz wrote: > On 20/07/2016 16:57, Jonathan Cameron wrote: >> On 19/07/16 09:33, Quentin Schulz wrote: >>> On 18/07/2016 15:18, Jonathan Cameron wrote: On 15/07/16 10:59, Quentin Schulz wrote: > [...] > + enable_irq(info->temp_data_irq); Is this hardware spitting out extra irqs? If not, much better to just leave it enabled all the time and control whether it can occur or not by controlling the device state.. >>> >>> The temp_data_irq occurs every SUNXI_GPADC_TEMP_PERIOD(x) periods (in >>> the current state of the driver: 2s). What do you mean by controlling >>> the device state? Enabling or disabling the hardware part of the IP >>> responsible of getting the temperature >>> (SUNXI_GPADC_TP_TPR_TEMP_ENABLE(x) here)? >> Yes, or something along those lines if it wakes up fast enough. > > The ADC wakes up fast enough but resets its internal time clock (I don't > know if it's the right term to use). Note that the temperature interrupt > occurs by period of X seconds in this IP. > > This means that each time we disable the ADC on the hardware side, no > temperature interrupt will occur within the first X seconds. I don't > think this is what we want. I'm guessing X is non trivial ;) So fair enough. Could you add this justification as a comment in the driver somewhere so that people coming back to this in a few years time will know what the justification for this 'unusual' handling is. Thanks, Jonathan > > [...] > > Quentin > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 1/3] IB/mthca: Delete an unnecessary check before the function call "pci_dev_put"
From: Markus Elfring Date: Sat, 23 Jul 2016 10:05:12 +0200 The pci_dev_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/infiniband/hw/mthca/mthca_reset.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/mthca/mthca_reset.c b/drivers/infiniband/hw/mthca/mthca_reset.c index 74c6a94..c521654 100644 --- a/drivers/infiniband/hw/mthca/mthca_reset.c +++ b/drivers/infiniband/hw/mthca/mthca_reset.c @@ -279,8 +279,7 @@ good: } out: - if (bridge) - pci_dev_put(bridge); + pci_dev_put(bridge); kfree(bridge_header); kfree(hca_header); -- 2.9.2
Re: [PATCH 2/2] iio: accel: Add support for Domintech DMARD06 accelerometer
On 22/07/16 00:41, Peter Meerwald-Stadler wrote:
>
>> This patch add support for Domintech DMARD06 accelerometer.
>
> comments below
>
>> Domintech DMARD06 is a low-g tri-axial digital accelerometer for
>> cost-sensitive consumer application.
>>
>> Signed-off-by: Aleksei Mamlin
I don't have anything to add here. Nice fairly clean first version.
>> ---
>> .../devicetree/bindings/iio/accel/dmard06.txt | 17 ++
>> drivers/iio/accel/Kconfig | 11 ++
>> drivers/iio/accel/Makefile | 1 +
>> drivers/iio/accel/dmard06.c| 219
>> +
>> 4 files changed, 248 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/accel/dmard06.txt
>> create mode 100644 drivers/iio/accel/dmard06.c
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/dmard06.txt
>> b/Documentation/devicetree/bindings/iio/accel/dmard06.txt
>> new file mode 100644
>> index 000..cc2231a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/accel/dmard06.txt
>> @@ -0,0 +1,17 @@
>> +Device tree bindings for Domintech DMARD06 acceletometer
>
> typo: accelerometer
>
>> +
>> +Required properties:
>> + - compatible : Should be "domintech,dmard06"
>> + - reg : I2C address of the chip. Should be 0x1c
>> +
>> +Example:
>> +&i2c1 {
>> +/* ... */
>> +
>> +accelerometer@1c {
>> +compatible = "domintech,dmard06";
>> +reg = <0x1c>;
>> +};
>> +
>> +/* ... */
>> +};
>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>> index e4a758c..abc8536 100644
>> --- a/drivers/iio/accel/Kconfig
>> +++ b/drivers/iio/accel/Kconfig
>> @@ -40,6 +40,17 @@ config BMC150_ACCEL_SPI
>> tristate
>> select REGMAP_SPI
>>
>> +config DMARD06
>> +tristate "Domintech DMARD06 Digital Accelerometer Driver"
>> +depends on OF || COMPILE_TEST
>> +depends on I2C
>> +help
>> + Say yes here to build support for the Domintech DMARD06 low-g
>> + tri-axial digital accelerometer connected via an I2C bus.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called dmard06.
>> +
>> config HID_SENSOR_ACCEL_3D
>> depends on HID_SENSOR_HUB
>> select IIO_BUFFER
>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>> index 71b6794..a96b269 100644
>> --- a/drivers/iio/accel/Makefile
>> +++ b/drivers/iio/accel/Makefile
>> @@ -7,6 +7,7 @@ obj-$(CONFIG_BMA180) += bma180.o
>> obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
>> obj-$(CONFIG_BMC150_ACCEL_I2C) += bmc150-accel-i2c.o
>> obj-$(CONFIG_BMC150_ACCEL_SPI) += bmc150-accel-spi.o
>> +obj-$(CONFIG_DMARD06) += dmard06.o
>> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>> obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>> obj-$(CONFIG_KXSD9) += kxsd9.o
>> diff --git a/drivers/iio/accel/dmard06.c b/drivers/iio/accel/dmard06.c
>> new file mode 100644
>> index 000..433e430
>> --- /dev/null
>> +++ b/drivers/iio/accel/dmard06.c
>> @@ -0,0 +1,219 @@
>> +/*
>> + * IIO driver for Domintech DMARD06 accelerometer
>> + *
>> + * Copyright (C) 2016 Aleksei Mamlin
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +struct dmard06_data {
>> +struct i2c_client *client;
>> +};
>> +
>> +#define DMARD06_DRV_NAME"dmard06"
>> +
>> +/* Device data registers */
>> +#define DMARD06_CHIP_ID_REG 0x0f
>> +#define DMARD06_TOUT_REG0x40
>> +#define DMARD06_XOUT_REG0x41
>> +#define DMARD06_YOUT_REG0x42
>> +#define DMARD06_ZOUT_REG0x43
>> +
>> +/* Device ID value */
>> +#define DMARD06_CHIP_ID 0x06
>> +
>> +/* Device values */
>> +#define DMARD06_AXIS_MAX_VAL64
>> +#define DMARD06_AXIS_SCALE_VAL 31250
>> +#define DMARD06_TEMP_CENTER_VAL 25
>> +
>> +static int dmard06_i2c_read(struct i2c_client *client, u8 reg, u8 *buf)
>> +{
>> +int error;
>
> 'error' is a bit pessimistic, how about 'ret'? :-)
>
>> +
>
> can't use i2c_smbus_read_byte_data()?
>
>> +error = i2c_master_send(client, ®, 1);
>> +if (unlikely(error < 0))
>> +return error;
>> +
>> +error = i2c_master_recv(client, buf, 1);
>> +if (unlikely(error < 0))
>> +return error;
>
> not sure if it is worth to annotate unlikely() here -- i2c is slooow
> locking is needed if you really need two i2c_master calls
>
>> +return 0;
>> +}
>> +
>> +static int dmard06_read_chip_id(struct dmard06_data *dmard06)
>> +{
>> +u8 buf;
>> +u8 chip_id;
>> +int error;
>> +
>> +error = dmard06_i2c_read(dmard06->clie
Re: ADS1118: hwmon or iio ? [was: Re: [RCF 1/3] hwmon: Add ads1118 driver]
On 23/07/16 03:20, Guenter Roeck wrote: > On 07/22/2016 07:39 AM, Joshua Clayton wrote: >> Greetings Guenter, >> >> Thank you for reviewing my submission. >> >> On 07/15/2016 06:40 PM, Guenter Roeck wrote: >>> On 07/15/2016 05:18 PM, Joshua Clayton wrote: Add new driver for Texas Instruments ADS1118 and and ADS1018. This driver works with ADS1018, because of code borrowed from asd1015, which is similar, but I can only test ADS1118 >>> >>> Browsing through the datasheet, I think this should probably be implemented >>> as iio driver (and iio already has a driver for ads1015). >>> >>> Jonathan, what do you think ? >>> >>> Thanks, >>> Guenter >>> >> No response from Jonathan as yet, but I am willing to rework the driver when >> I >> have some time. It might be weeks before I can start, though. >> > > Changing the subject - maybe it helps to get Jonathan's attention. Sorry bit of silly travelling for day job over the last few days has left me rather behind. Just had my first experience of missing the last train home from the airport and having to sleep in a 'pod' hotel waiting for the first on in the morning. 'interesting' and I hope I never have to repeat it. Anyhow, looking fairly quickly through the datasheet I agree with Guenter. This is a reasonably standard looking ADC with a decent analog front end. Whilst they state thermal monitoring in the 'applications' and there are a few design choices in there (such as really small over voltage protection) that make sense for thermocouples, there is nothing that specific. Also as Guenter has pointed out above we already have some thermocouple focused chips in IIO. Sampling is quick enough (up to 860 sps) that you'll probably want to use the 'buffer' support in IIO rather than just a simple polled (hwmon like) driver - but that can always come in a follow up patch. There is a nice datardy output that can be used to drive a general purpose trigger (used to sample other devices in parallel with this one if you want to). Anyhow, all in, looks like a good general purpose ADC to me. So would be delighted to have a driver for it in IIO. You could combine it with the existing ads1015 driver, but there are probably enough differences to make that fiddly even using regmap to deal with the different bus (i2c -> spi), so I think it doesn't really make sense (feel free to tell me otherwise as I've only glanced at the datasheet!) Thanks, Jonathan > > Guenter > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] iio: vcnl4000: Add IR current adjust support
On 19/07/16 08:21, Peter Meerwald-Stadler wrote: > >>> comments below; nice addition >>> >>> it seems this patch clashes with the recent changes to this driver in >>> iio-testing; can you rebase on top please? >> >> Where is iio-testing? I couldn't found it in linux. > > https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/log/?h=testing > In theory stuff only stays in testing (alone) until I get the autobuilder responses on it. I've had a bit of an 'interesting' few weeks however so haven't done the usual which is to push it out as togreg (which is the non rebasing tree) in as timely a fashion as I should. Worth checking testing to see if there is anything very recent, but better to base new work on top of togreg. Thanks Jonathan > p. >
Re: [PATCH 1/1] iio: vcnl4000: Add IR current adjust support
On 22/07/16 00:14, Peter Meerwald-Stadler wrote: > > comments below; nice addition > > it seems this patch clashes with the recent changes to this driver in > iio-testing; can you rebase on top please? Where is iio-testing? I couldn't found it in linux. >>> >>> https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/log/?h=testing >> >> Means we have to do development here and this testing branch will get >> merged to main branch later. > > yes, Jonathan will queue up stuff in testing, then send to GregHK, and > then to mainline Testing is a special branch for the autobuilders. Except when I'm being useless, the right branch to use is togreg as that 'never' rebases. Jonathan > > p. >
Re: [PATCH v5 2/3] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.
On 21/07/16 09:17, Zhiyong Tao wrote:
> Add Mediatek auxadc driver based on iio.
> It will register a device in iio and support iio.
> So thermal can read auxadc channel to sample data by iio device.
> It is tested successfully on mt2701 platform.
> Mt8173 and mt6577 platforms are not tested.
> But the expectation is compatible.
>
> Signed-off-by: Zhiyong Tao
As you are re spinning anyway to address Peter's comments one
more minor point from me inline
Shaping up to be a nice little driver.
Jonathan
> ---
> drivers/iio/adc/Kconfig | 13 ++
> drivers/iio/adc/Makefile|1 +
> drivers/iio/adc/mt6577_auxadc.c | 289
> +++
> 3 files changed, 303 insertions(+)
> create mode 100644 drivers/iio/adc/mt6577_auxadc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 25378c5..14929fc 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -305,6 +305,19 @@ config MCP3422
> This driver can also be built as a module. If so, the module will be
> called mcp3422.
>
> +config MEDIATEK_MT6577_AUXADC
> +tristate "MediaTek AUXADC driver"
> +depends on ARCH_MEDIATEK || COMPILE_TEST
> +depends on HAS_IOMEM
> +help
> + Say yes here to enable support for MediaTek mt65xx AUXADC.
> +
> + The driver supports immediate mode operation to read from one of
> sixteen
> + channels (external or internal).
> +
> + This driver can also be built as a module. If so, the module will
> be
> + called mt6577_auxadc.
> +
> config MEN_Z188_ADC
> tristate "MEN 16z188 ADC IP Core support"
> depends on MCB
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 38638d4..8306347 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MAX1363) += max1363.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> +obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
> obj-$(CONFIG_NAU7802) += nau7802.o
> diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
> new file mode 100644
> index 000..6240236
> --- /dev/null
> +++ b/drivers/iio/adc/mt6577_auxadc.c
> @@ -0,0 +1,289 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Zhiyong Tao
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Register definitions */
> +#define MT6577_AUXADC_CON00x00
> +#define MT6577_AUXADC_CON10x04
> +#define MT6577_AUXADC_CON20x10
> +#define MT6577_AUXADC_STA BIT(0)
> +
> +#define MT6577_AUXADC_DAT00x14
> +#define MT6577_AUXADC_RDY0BIT(12)
> +
> +#define MT6577_AUXADC_MISC0x94
> +#define MT6577_AUXADC_PDN_EN BIT(14)
> +
> +#define MT6577_AUXADC_DAT_MASK0xfff
> +#define MT6577_AUXADC_SLEEP_US1000
> +#define MT6577_AUXADC_TIMEOUT_US 1
> +#define MT6577_AUXADC_POWER_READY_MS 1
> +#define MT6577_AUXADC_SAMPLE_READY_US 25
> +
> +struct mt6577_auxadc_device {
> + void __iomem *reg_base;
> + struct clk *adc_clk;
> + struct mutex lock;
> +};
> +
> +#define MT6577_AUXADC_CHANNEL(idx) { \
> + .type = IIO_VOLTAGE,\
> + .indexed = 1, \
> + .channel = (idx), \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> +}
> +
> +static const struct iio_chan_spec mt6577_auxadc_iio_channels[] = {
> + MT6577_AUXADC_CHANNEL(0),
> + MT6577_AUXADC_CHANNEL(1),
> + MT6577_AUXADC_CHANNEL(2),
> + MT6577_AUXADC_CHANNEL(3),
> + MT6577_AUXADC_CHANNEL(4),
> + MT6577_AUXADC_CHANNEL(5),
> + MT6577_AUXADC_CHANNEL(6),
> + MT6577_AUXADC_CHANNEL(7),
> + MT6577_AUXADC_CHANNEL(8),
> + MT6577_AUXADC_CHANNEL(9),
> + MT6577_AUXADC_CHANNEL(10),
> + MT6577_AUXADC_CHANNEL(11),
> + MT6577_AUXADC_CHANNEL(12),
> + MT6577_AUXADC_CHANNEL(13),
> + MT6577_AUXADC_CHANNEL(14),
> + MT6577_AUXADC_CHANNEL(15),
> +};
> +
[PATCH 2/3] IB/mthca: Less function calls in mthca_reset() after error detection
From: Markus Elfring
Date: Sat, 23 Jul 2016 11:28:30 +0200
The kfree() function was called in a few cases by the mthca_reset()
function during error handling even if the passed variables "bridge_header"
and "hca_header" contained a null pointer.
Adjust jump targets according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mthca/mthca_reset.c | 41 +++
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_reset.c
b/drivers/infiniband/hw/mthca/mthca_reset.c
index c521654..6727af2 100644
--- a/drivers/infiniband/hw/mthca/mthca_reset.c
+++ b/drivers/infiniband/hw/mthca/mthca_reset.c
@@ -98,7 +98,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENOMEM;
mthca_err(mdev, "Couldn't allocate memory to save HCA "
"PCI header, aborting.\n");
- goto out;
+ goto put_dev;
}
for (i = 0; i < 64; ++i) {
@@ -108,7 +108,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENODEV;
mthca_err(mdev, "Couldn't save HCA "
"PCI header, aborting.\n");
- goto out;
+ goto free_hca;
}
}
@@ -121,7 +121,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENOMEM;
mthca_err(mdev, "Couldn't allocate memory to save HCA "
"bridge PCI header, aborting.\n");
- goto out;
+ goto free_hca;
}
for (i = 0; i < 64; ++i) {
@@ -131,7 +131,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENODEV;
mthca_err(mdev, "Couldn't save HCA bridge "
"PCI header, aborting.\n");
- goto out;
+ goto free_bh;
}
}
bridge_pcix_cap = pci_find_capability(bridge, PCI_CAP_ID_PCIX);
@@ -139,7 +139,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENODEV;
mthca_err(mdev, "Couldn't locate HCA bridge "
"PCI-X capability, aborting.\n");
- goto out;
+ goto free_bh;
}
}
@@ -152,7 +152,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENOMEM;
mthca_err(mdev, "Couldn't map HCA reset register, "
"aborting.\n");
- goto out;
+ goto free_bh;
}
writel(MTHCA_RESET_VALUE, reset);
@@ -172,7 +172,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENODEV;
mthca_err(mdev, "Couldn't access HCA after
reset, "
"aborting.\n");
- goto out;
+ goto free_bh;
}
if (v != 0x)
@@ -184,7 +184,7 @@ int mthca_reset(struct mthca_dev *mdev)
err = -ENODEV;
mthca_err(mdev, "PCI device did not come back after reset, "
"aborting.\n");
- goto out;
+ goto free_bh;
}
good:
@@ -195,14 +195,14 @@ good:
err = -ENODEV;
mthca_err(mdev, "Couldn't restore HCA bridge Upstream "
"split transaction control, aborting.\n");
- goto out;
+ goto free_bh;
}
if (pci_write_config_dword(bridge, bridge_pcix_cap + 0xc,
bridge_header[(bridge_pcix_cap + 0xc) / 4])) {
err = -ENODEV;
mthca_err(mdev, "Couldn't restore HCA bridge Downstream
"
"split transaction control, aborting.\n");
- goto out;
+ goto free_bh;
}
/*
* Bridge control register is at 0x3e, so we'll
@@ -216,7 +216,7 @@ good:
err = -ENODEV;
mthca_err(mdev, "Couldn't restore HCA bridge
reg %x, "
"aborting.\n", i);
- goto out;
+ goto free_bh;
}
}
@@ -225,7 +225,7 @@ good:
err = -ENODEV;
mthca_err(mdev, "Couldn't restore HCA bridge COMMAND, "
[PATCH 3/3] IB/mthca: Delete unnecessary variable initialisations in mthca_reset()
From: Markus Elfring
Date: Sat, 23 Jul 2016 11:54:06 +0200
Three local variables will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mthca/mthca_reset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_reset.c
b/drivers/infiniband/hw/mthca/mthca_reset.c
index 6727af2..0a458c6 100644
--- a/drivers/infiniband/hw/mthca/mthca_reset.c
+++ b/drivers/infiniband/hw/mthca/mthca_reset.c
@@ -42,12 +42,12 @@ int mthca_reset(struct mthca_dev *mdev)
{
int i;
int err = 0;
- u32 *hca_header= NULL;
+ u32 *hca_header;
u32 *bridge_header = NULL;
struct pci_dev *bridge = NULL;
int bridge_pcix_cap = 0;
- int hca_pcie_cap = 0;
- int hca_pcix_cap = 0;
+ int hca_pcie_cap;
+ int hca_pcix_cap;
u16 devctl;
u16 linkctl;
--
2.9.2
Why do we need reset_control_get_optional() ?
Hi.
Now the reset subsystem provides
a bunch of reset_control_get variants.
I am still wondering why we need to have _optional ones.
As far as I see, the difference is WARN_ON(1)
when CONFIG_RESET_CONTROLLER is not defined.
[1] When the reset is mandatory,
the code of the reset consumer is probably like follows:
rst = devm_reset_control_get(dev, NULL);
if (IS_ERR(rst)) {
dev_err(dev, "failed to get reset\n");
return PTR_ERR(rst);
}
ret = reset_control_deassert(rst);
if (ret) {
dev_err(dev, "failed to deassert reset\n");
return ret;
}
...
[2] When the reset is optional,
the code should be something like follows:
rst = devm_reset_control_get(dev, NULL);
if (ERR_PTR(rst) == -EPROBE_DEFER)
return -EPROBE_DEFER;
/* deassert reset if it is available */
if (!IS_ERR(rst)) {
ret = reset_control_deassert(rst);
if (ret) {
dev_err(dev, "failed to deassert reset\n");
return ret;
}
}
What I mean is, we can write a driver in either way
without using the _optional one.
No need to call WARN_ON(1).
What does _optional buy us?
One more thing.
WARN_ON(1) is only useful on run-time,
but run-time test is more expensive than compile-time test.
If a driver really needs reset control,
it should not be complied without CONFIG_RESET_CONTROLLER.
So, the driver should have "depends on RESET_CONTROLLER" in Kconfig.
I dug the git-log to figure out historical reason.
The _optional functions were introduced by the following commit:
->8-
commit b424080a9e086e683ad5fdc624a7cf3c024e0c0f
Author: Philipp Zabel
Date: Fri Mar 7 15:18:47 2014 +0100
reset: Add optional resets and stubs
This patch adds device_reset_optional and (devm_)reset_control_get_optional
variants that drivers can use to indicate they can function without control
over the reset line. For those functions, stubs are added so the drivers can
be compiled with CONFIG_RESET_CONTROLLER disabled.
Also, device_reset is annotated with __must_check. Drivers
ignoring the return
value should use device_reset_optional instead.
Signed-off-by: Philipp Zabel
--8<-
At that point of time, the reset_control_get (without _optional)
did not have a stub, so drivers calling reset_control_get()
could not be built without CONFIG_RESET_CONTROLLER enabled.
So, it made sense to add _optional variants.
A while later, any drivers became able to be built
without CONFIG_RESET_CONTROLLER, by the following commit.
->8
commit 5bcd0b7f3c56c616abffd89e11c841834dd1528c
Author: Axel Lin
Date: Tue Sep 1 07:56:38 2015 +0800
reset: Add (devm_)reset_control_get stub functions
So the drivers can be compiled with CONFIG_RESET_CONTROLLER disabled.
Signed-off-by: Axel Lin
Signed-off-by: Philipp Zabel
---8<
Since then, it became pointless to have _optional variants.
I want to deprecate _optional variants in the following steps:
[1] Add "depends on RESET_CONTROLLER" to drivers
for which reset_control is mandatory.
We can find those driver easily by grepping
the reference to non-optional reset_control_get().
[2] Change all of _optional calls to non-optional ones.
[3] Remove _optional static inline functions from include/linux/reset.h
It will take some releases to complete this task,
but I am happy to volunteer to it if we agree on this idea.
--
Best Regards
Masahiro Yamada
Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
On Sat, 23 Jul 2016 09:17:59 +0300 (EEST), Julian Anastasov wrote: > > In my case, the gateway refuses to send unicast packets to me, before it sees > my ARP request. So it's critical to enter REACHABLE state by sending ARP > request, but not by external confirmation. > > > What kind of problem is this? Remote host wants to > see a recent probe from us, otherwise it refuses to resolve > our address before its traffic to us and it is not sent? > Can you explain this in more detail because after looking > again I have some doubts what actually happens, see below. > The remote host is configured to refuse to send any packets to a host it doesn't "know" (but broadcast is allowed), and it can only "learn" from ARP packets. When I send packets, if broadcast ARP requests from the remote host are received and set the state to NUD_STALE, then I stuck. >> (2) But NUD_PROBE -> NUD_STALE is acceptable, because in NUD_PROBE, ARP >> request >> has been sent, it is sufficient to break the "dead loop". >> More attempts are accomplished by the following sequence: >> NUD_STALE --> NUD_DELAY -(sent req)-> NUD_PROBE -(reset by neigh_update())-> > > I think, when entering NUD_DELAY we do not send > any ARP probe: for NUD_STALE __neigh_event_send is called on > outgoing traffic to change state to NUD_DELAY and to start > timer (it was stopped in NUD_STALE) to detect if address is > still alive before probing it again. Now in this period of > 5 seconds (delay_first_probe_time) two things can happen: > Yes, we do not send any probe when entering NUD_DELAY. "NUD_DELAY -(send req)-> NUD_PROBE" means when entering NUD_PROBE, send req. > 1. Unexpected Unicast ARP reply (immediate switch to NUD_REACHABLE) > or protocol indication (dst_confirm) causing delayed switch to > NUD_REACHABLE on next outgoing packet. On sporadic > request+reply we may not switch immediately to NUD_REACHABLE. > Even if the reply called dst_confirm, the change happens > next time when new request is sent and dst_neigh_output is called. > > 2. Remote host is fast enough to reset us again to NUD_STALE > before we change state to ->NUD_PROBE->NUD_REACHABLE. > > To summarize: currently the change to NUD_STALE serves the > purpose to avoid/delay our hwaddr refreshing probes. They are > avoided if protocols indicate progress with the current hwaddr. > Outgoing IP traffic that does not trigger confirmation > from replies (for example TCP ACK calling dst_confirm) or > from applications (MSG_CONFIRM) surely will cause a > switch to NUD_PROBE. > Yes, I agree. But now it is possible to delay the probes *forever*, and at the same time we get no positive response from the remote host. When entering NUD_DELAY, it means we need some confirmations to ensure the address we fill is not stale. If we get no evidence, it's our responsibility to ensure reachability. So some probes are unavoidable, and delay by NUD_STALE(can not proof fresh) is unacceptable. > Now the main question: is reaching a NUD_REACHABLE > state a good enough goal (if we ignore the NUD_STALE in > NUD_DELAY | NUD_PROBE state) or we prefer traffic that does > not provide confirmation indications to use the current > hwaddr based only on indications from received ARP broadcasts > or requests, in which case we avoid our ARP probes. In the > latter case remote hosts do not see fresh probes from us > and we may cycle between NUD_STALE and NUD_DELAY if > such remote packets come more often. > > So, the question is, to avoid probes or to refresh > frequently? Is there a good reason to ignore this NUD_STALE > event in NUD_DELAY | NUD_PROBE state? > So reaching a NUD_REACHABLE state in not our goal. It's to ensure correctness. Cycle between NUD_STALE and NUD_DELAY is not correct. Maybe it is enough to ignore NUD_STALE? Regards, Chunhui
Re: [fs] bdd20132c6: BUG: sleeping function called from invalid context at fs/proc/proc_sysctl.c:1569
kernel test robot writes:
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-testing
> commit bdd20132c624a976f88b108ff37c7481c6f33e70 ("fs: Set s_user_ns to
> &init_user_ns in sget when MS_KERNMOUNT")
>
> in testcase: boot
>
> on test machine: 2 threads qemu-system-x86_64 -enable-kvm with 360M memory
>
> caused below changes:
Thank you for the report. For anyone who is watching the change that
actually has the problem is:
a02420f1402ca76a6f2833c14fa82044cb2a0ae4 ("userns: Add per user namespace
sysctls.")
It looks like that change isn't ready. Close but not quite. Ah well.
Eric
RE: [PATCH v4 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
Hi, Dmitry
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Fri, Jul 22, 2016 at 08:37:50AM +, Zheng, Lv wrote:
> > Hi, Dmitry
> >
> > Thanks for the review.
> >
> > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> control
> > > method lid device restrictions
> > >
> > > Hi Lv,
> > >
> > > On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> > > > Hi, Dmitry
> > > >
> > > >
> > > > Thanks for the review.
> > > >
> > > > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > > > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> > > control
> > > > > method lid device restrictions
> > > > >
> > > > > On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
> > > > > > This patch adds documentation for the usage model of the
> control
> > > > > method lid
> > > > > > device.
> > > > > >
> > > > > > Signed-off-by: Lv Zheng
> > > > > > Cc: Dmitry Torokhov
> > > > > > Cc: Benjamin Tissoires
> > > > > > Cc: Bastien Nocera:
> > > > > > Cc: linux-in...@vger.kernel.org
> > > > > > ---
> > > > > > Documentation/acpi/acpi-lid.txt | 89
> > > > > +++
> > > > > > 1 file changed, 89 insertions(+)
> > > > > > create mode 100644 Documentation/acpi/acpi-lid.txt
> > > > > >
> > > > > > diff --git a/Documentation/acpi/acpi-lid.txt
> > > b/Documentation/acpi/acpi-
> > > > > lid.txt
> > > > > > new file mode 100644
> > > > > > index 000..2addedc
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/acpi/acpi-lid.txt
> > > > > > @@ -0,0 +1,89 @@
> > > > > > +Usage Model of the ACPI Control Method Lid Device
> > > > > > +
> > > > > > +Copyright (C) 2016, Intel Corporation
> > > > > > +Author: Lv Zheng
> > > > > > +
> > > > > > +
> > > > > > +Abstract:
> > > > > > +
> > > > > > +Platforms containing lids convey lid state (open/close) to
> OSPMs
> > > using
> > > > > a
> > > > > > +control method lid device. To implement this, the AML tables
> issue
> > > > > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state
> > > has
> > > > > > +changed. The _LID control method for the lid device must be
> > > > > implemented to
> > > > > > +report the "current" state of the lid as either "opened" or
> "closed".
> > > > > > +
> > > > > > +This document describes the restrictions and the expections of
> the
> > > > > Linux
> > > > > > +ACPI lid device driver.
> > > > > > +
> > > > > > +
> > > > > > +1. Restrictions of the returning value of the _LID control method
> > > > > > +
> > > > > > +The _LID control method is described to return the "current" lid
> > > state.
> > > > > > +However the word of "current" has ambiguity, many AML tables
> > > return
> > > > > the lid
> > > > >
> > > > > Can this be fixed in the next ACPI revision?
> > > > [Lv Zheng]
> > > > Even this is fixed in the ACPI specification, there are platforms
> already
> > > doing this.
> > > > Especially platforms from Microsoft.
> > > > So the de-facto standard OS won't care about the change.
> > > > And we can still see such platforms.
> > > >
> > > > Here is an example from Surface 3:
> > > >
> > > > DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I ",
> 0x01072009)
> > > > {
> > > > Scope (_SB)
> > > > {
> > > > Device (PCI0)
> > > > {
> > > > Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID
> > > > Name (_CID, EisaId ("PNP0A03")) // _CID: Compatible ID
> > > > Device (SPI1)
> > > > {
> > > > Name (_HID, "8086228E") // _HID: Hardware ID
> > > > Device (NTRG)
> > > > {
> > > > Name (_HID, "MSHW0037") // _HID: Hardware ID
> > > > }
> > > > }
> > > > }
> > > >
> > > > Device (LID)
> > > > {
> > > > Name (_HID, EisaId ("PNP0C0D"))
> > > > Name (LIDB, Zero)
> > >
> > > Start with lid closed? In any case might be wrong.
> > [Lv Zheng]
> > And we validated with qemu that during boot, Windows7 evaluates _LID
> once but doesn't get suspended because of this value.
> > So we think Windows only suspends against "notification" not _LID
> evaluation result.
> >
> > >
> > > > Method (_LID, 0, NotSerialized)
> > > > {
> > > > Return (LIDB)
> > >
> > > So "_LID" returns the last state read by "_EC4". "_EC4" is
> > > edge-triggered and will be evaluated every time gpio changes state.
> > [Lv Zheng]
> > Right.
> >
> > >
> > > > }
> > > > }
> > > >
> > > > Device (GPO0)
> > > > {
> > > > Name (_HID, "INT33FF") // _HID: Hardware ID
> > > > OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
> > >
Re: PM-wakeup: Delete unnecessary checks before two function calls
On Saturday, July 23, 2016 07:32:22 AM SF Markus Elfring wrote: > >> How do you think about to integrate this update suggestion > >> into another source code repository? > > > > I'm not really sure what you mean. > > Do you find the suggested source code change acceptable? > > http://article.gmane.org/gmane.linux.power-management.general/61766 > https://lkml.org/lkml/2015/6/28/21 Yes, it is acceptable, but you also should remove some braces that aren't necessary any more. Thanks, Rafael
RE: [PATCH v4 2/2] ACPI / button: Add document for ACPI control method lid device restrictions
Hi, Dmitry
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov
> Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> On Fri, Jul 22, 2016 at 08:55:00AM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 22, 2016 at 6:37 AM, Dmitry Torokhov
> > wrote:
> > > Hi Lv,
> > >
> > > On Fri, Jul 22, 2016 at 12:24:50AM +, Zheng, Lv wrote:
> > >> Hi, Dmitry
> > >>
> > >>
> > >> Thanks for the review.
> > >>
> > >> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > >> > Subject: Re: [PATCH v4 2/2] ACPI / button: Add document for ACPI
> control
> > >> > method lid device restrictions
> > >> >
> > >> > On Tue, Jul 19, 2016 at 04:11:21PM +0800, Lv Zheng wrote:
> > >> > > This patch adds documentation for the usage model of the control
> > >> > method lid
> > >> > > device.
> > >> > >
> > >> > > Signed-off-by: Lv Zheng
> > >> > > Cc: Dmitry Torokhov
> > >> > > Cc: Benjamin Tissoires
> > >> > > Cc: Bastien Nocera:
> > >> > > Cc: linux-in...@vger.kernel.org
> > >> > > ---
> > >> > > Documentation/acpi/acpi-lid.txt | 89
> > >> > +++
> > >> > > 1 file changed, 89 insertions(+)
> > >> > > create mode 100644 Documentation/acpi/acpi-lid.txt
> > >> > >
> > >> > > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-
> > >> > lid.txt
> > >> > > new file mode 100644
> > >> > > index 000..2addedc
> > >> > > --- /dev/null
> > >> > > +++ b/Documentation/acpi/acpi-lid.txt
> > >> > > @@ -0,0 +1,89 @@
> > >> > > +Usage Model of the ACPI Control Method Lid Device
> > >> > > +
> > >> > > +Copyright (C) 2016, Intel Corporation
> > >> > > +Author: Lv Zheng
> > >> > > +
> > >> > > +
> > >> > > +Abstract:
> > >> > > +
> > >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
> using
> > >> > a
> > >> > > +control method lid device. To implement this, the AML tables
> issue
> > >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state has
> > >> > > +changed. The _LID control method for the lid device must be
> > >> > implemented to
> > >> > > +report the "current" state of the lid as either "opened" or
> "closed".
> > >> > > +
> > >> > > +This document describes the restrictions and the expections of
> the
> > >> > Linux
> > >> > > +ACPI lid device driver.
> > >> > > +
> > >> > > +
> > >> > > +1. Restrictions of the returning value of the _LID control method
> > >> > > +
> > >> > > +The _LID control method is described to return the "current" lid
> state.
> > >> > > +However the word of "current" has ambiguity, many AML tables
> return
> > >> > the lid
> > >> >
> > >> > Can this be fixed in the next ACPI revision?
> > >> [Lv Zheng]
> > >> Even this is fixed in the ACPI specification, there are platforms already
> doing this.
> > >> Especially platforms from Microsoft.
> > >> So the de-facto standard OS won't care about the change.
> > >> And we can still see such platforms.
> > >>
> > >> Here is an example from Surface 3:
> > >>
> > >> DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I ",
> 0x01072009)
> > >> {
> > >> Scope (_SB)
> > >> {
> > >> Device (PCI0)
> > >> {
> > >> Name (_HID, EisaId ("PNP0A08")) // _HID: Hardware ID
> > >> Name (_CID, EisaId ("PNP0A03")) // _CID: Compatible ID
> > >> Device (SPI1)
> > >> {
> > >> Name (_HID, "8086228E") // _HID: Hardware ID
> > >> Device (NTRG)
> > >> {
> > >> Name (_HID, "MSHW0037") // _HID: Hardware ID
> > >> }
> > >> }
> > >> }
> > >>
> > >> Device (LID)
> > >> {
> > >> Name (_HID, EisaId ("PNP0C0D"))
> > >> Name (LIDB, Zero)
> > >
> > > Start with lid closed? In any case might be wrong.
> >
> > Actually the initial value doesn't matter if the gpiochip triggers the
> > _EC4 at boot, which it should
> > (https://github.com/hadess/fedora-surface3-
> kernel/commit/13200f81662c1c0b58137947c3e6c000fe62a2ba,
> > still unsubmitted)
> >
> > >
> > >> Method (_LID, 0, NotSerialized)
> > >> {
> > >> Return (LIDB)
> > >
> > > So "_LID" returns the last state read by "_EC4". "_EC4" is
> > > edge-triggered and will be evaluated every time gpio changes state.
> >
> > That's assuming the change happens while the system is on. If you go
> > into suspend by closing the LID. Open it while on suspend and then hit
> > the power button given that the system doesn't wake up when the lid is
> > opened, the edge change was made while the system is asleep, and we
> > are screwed (from an ACPI point of view). See my next comment for a
> > solution.
>
> Can we extend the patch you referenced above and do similar thing on
> resume? Won't help Surface but might others.
>
> >
> > >
> > >> }
> > >> }
>
Re: [PATCH v5 1/3] ACPI / button: Add missing event to keep SW_LID running without additional event loss
On Friday, July 22, 2016 02:24:42 PM Lv Zheng wrote:
> There are several possibilities that a lid event can be lost. For example,
> EC event queue full, or the resume order of the underlying drivers.
>
> When the event loss happens, new event may also be lost due to the type of
> the SW_LID (switch event). The 2nd loss is what we want to avoid.
>
> This patch adds a mechanism to insert lid events as a compensation for the
> switch event nature of the lid events in order to avoid the 2nd loss.
Can you please provide a high-level description of the new mechanism here?
>
> Signed-off-by: Lv Zheng
> Cc: Dmitry Torokhov
> Cc: Benjamin Tissoires
> Cc: Bastien Nocera:
> Cc: linux-in...@vger.kernel.org
> ---
> drivers/acpi/button.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 148f4e5..41fd21d 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -104,6 +104,8 @@ struct acpi_button {
> struct input_dev *input;
> char phys[32]; /* for input device */
> unsigned long pushed;
> + int sw_last_state;
> + unsigned long sw_last_time;
> bool suspended;
> };
>
> @@ -111,6 +113,10 @@ static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
> static struct acpi_device *lid_device;
> static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
>
> +static unsigned long lid_report_interval __read_mostly = 500;
> +module_param(lid_report_interval, ulong, 0644);
> +MODULE_PARM_DESC(lid_report_interval, "Interval (ms) between lid key
> events");
> +
> /* --
>FS Interface (/proc)
>
> -- */
> @@ -133,11 +139,22 @@ static int acpi_lid_evaluate_state(struct acpi_device
> *device)
> static int acpi_lid_notify_state(struct acpi_device *device, int state)
> {
> struct acpi_button *button = acpi_driver_data(device);
> + unsigned long sw_tout;
> int ret;
>
> - /* input layer checks if event is redundant */
> + /* Send the switch event */
> + sw_tout = button->sw_last_time +
> + msecs_to_jiffies(lid_report_interval);
Is it really necessary to use jiffies here?
> + if (time_after(jiffies, sw_tout) &&
> + (button->sw_last_state == !!state)) {
The inner parens are not necessary.
And why not just button->sw_last_state == state?
> + /* Send the complement switch event */
> + input_report_switch(button->input, SW_LID, state);
> + input_sync(button->input);
> + }
> input_report_switch(button->input, SW_LID, !state);
> input_sync(button->input);
> + button->sw_last_state = !!state;
> + button->sw_last_time = jiffies;
>
> if (state)
> pm_wakeup_event(&device->dev, 0);
> @@ -407,6 +424,8 @@ static int acpi_button_add(struct acpi_device *device)
> strcpy(name, ACPI_BUTTON_DEVICE_NAME_LID);
> sprintf(class, "%s/%s",
> ACPI_BUTTON_CLASS, ACPI_BUTTON_SUBCLASS_LID);
> + button->sw_last_state = !!acpi_lid_evaluate_state(device);
> + button->sw_last_time = jiffies;
> } else {
> printk(KERN_ERR PREFIX "Unsupported hid [%s]\n", hid);
> error = -ENODEV;
>
Thanks,
Rafael
Re: [PATCH] intel_pstate: Update cpu_frequency tracepoint every time
On Tuesday, July 19, 2016 08:14:53 PM Doug Smythies wrote: > On 2016.07.19 15:10 Srinivas Pandruvada wrote: > > On Tue, 2016-07-19 at 15:10 +0200, Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> Currently, intel_pstate only updates the cpu_frequency tracepoint > >> if the new P-state to set is different from the current one, but > >> that causes powertop to report 100% idle on an 100% loaded system > >> sometimes. > >> > >> Prevent that from happening by updating the cpu_frequency tracepoint > >> every time intel_pstate_update_pstate() is called. > >> > >> Signed-off-by: Rafael J. Wysocki > > > > Acked-by: Srinivas Pandruvada - > > Shouldn't this patch refer to: > > commit fdfdb2b1301670a69195ba1e5666df4a7f02eb46 > Author: Rafael J. Wysocki > Date: Fri Mar 18 23:20:02 2016 +0100 > > intel_pstate: Do not call wrmsrl_on_cpu() with disabled interrupts > > which is the patch that introduced the regression? The logic changed by the $subject patch was there before the above commit, so I don't think the issue at hand really is a regression introduced by it Thanks, Rafael
Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code
On Sat, Jul 23, 2016 at 02:39:52PM +0900, Linus Torvalds wrote: > On Sat, Jul 23, 2016 at 2:35 PM, Josh Poimboeuf wrote: > > > > While doing the scanning and printing, it does call the frame pointer > > unwinder in parallel, but like before, that's *only* used to determine > > whether a found address should be printed without a question mark. If > > the unwinder goes off the rails, the scanning and printing of text > > addresses goes on, undisturbed. > > > > The frame pointer unwinder code itself is quite careful not to > > dereference anything it shouldn't (though of course I welcome any review > > comments that find otherwise). > > So this was the bug the last time around we did unwinders - the code > would dereference the unwind tables, and the tables would be > corrupted. End result: recursive oops. > > And they were corrupted not even because of memory corruption, but > simply because they contained incorrect data, due to compiler bugs and > other issues. > > I have really bad memories from that time. Several years after the > fact. It took months to finally revert the crap, because the author > continued to insist that "this was the last bug" for several passes > through that thing. > > As they say, "Once burned, twice shy". But in this case, it's more > like "Four times burned, sixteen times as shy". But that was DWARF, right? This is still just simple frame pointers. Don't think of it as a new unwinder. Think of it instead as a "gentle reshuffling of the existing code to vastly improve readability and maintenance." Yes, I would like to eventually propose a DWARF unwinder, which hopefully learns from the mistakes of previous attempts. But either way, I think this patch set stands on its own as a big improvement. -- Josh
[PATCH] power: generic-adc-battery: Delete unnecessary checks before the function call "iio_channel_release"
From: Markus Elfring
Date: Sat, 23 Jul 2016 14:50:47 +0200
The iio_channel_release() function tests whether its argument is NULL
and then returns immediately. Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/power/generic-adc-battery.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/power/generic-adc-battery.c
b/drivers/power/generic-adc-battery.c
index edb36bf..8f7f24c 100644
--- a/drivers/power/generic-adc-battery.c
+++ b/drivers/power/generic-adc-battery.c
@@ -350,10 +350,8 @@ err_gpio:
gpio_req_fail:
power_supply_unregister(adc_bat->psy);
err_reg_fail:
- for (chan = 0; chan < ARRAY_SIZE(gab_chan_name); chan++) {
- if (adc_bat->channel[chan])
- iio_channel_release(adc_bat->channel[chan]);
- }
+ for (chan = 0; chan < ARRAY_SIZE(gab_chan_name); chan++)
+ iio_channel_release(adc_bat->channel[chan]);
second_mem_fail:
kfree(psy_desc->properties);
first_mem_fail:
@@ -373,11 +371,8 @@ static int gab_remove(struct platform_device *pdev)
gpio_free(pdata->gpio_charge_finished);
}
- for (chan = 0; chan < ARRAY_SIZE(gab_chan_name); chan++) {
- if (adc_bat->channel[chan])
- iio_channel_release(adc_bat->channel[chan]);
- }
-
+ for (chan = 0; chan < ARRAY_SIZE(gab_chan_name); chan++)
+ iio_channel_release(adc_bat->channel[chan]);
kfree(adc_bat->psy_desc.properties);
cancel_delayed_work(&adc_bat->bat_work);
return 0;
--
2.9.2
Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface
On Fri, Jul 22, 2016 at 04:52:10PM -0700, Andy Lutomirski wrote: > On Fri, Jul 22, 2016 at 4:26 PM, Andy Lutomirski wrote: > > On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote: > >> valid_stack_ptr() is buggy: it assumes that all stacks are of size > >> THREAD_SIZE, which is not true for exception stacks. So the > >> walk_stack() callbacks will need to know the location of the beginning > >> of the stack as well as the end. > >> > >> Another issue is that in general the various features of a stack (type, > >> size, next stack pointer, description string) are scattered around in > >> various places throughout the stack dump code. > > > > I finally figured out what visit_info is. But would it make more > > sense to track it in the unwind state so that the unwinder can > > directly make sure it doesn't start looping? > > > > I just realized that it *is* in the unwind state. But maybe this code > in update_stack_state: > > sp = info->next; > if (!sp). > goto unknown; > > if (get_stack_info(sp, state->task, info, &state->stack_mask)) > goto unknown; > > if (!on_stack(info, addr, len)) > goto unknown; > > should do something like: > > if (get_stack_info(addr, ...)) > goto unknown. > > sp = info->end; > > instead. Alternatively, maybe it would make sense to keep sp as is > (have update_stack_state return bool instead of returning a pointer) > so that a frame that switches stacks still shows the actual sp at the > time that the frame called whatever the it called. > > I'm really quite confused by what state->sp means in your current > code. In the non-stack-switching case (everything is on the thread > stack), it appears to always match state->bp. Am I missing something? > If I'm understanding this correctly, when you're pointing at a call > frame, state->bp is that frame's base address (the top of the stack > frame), unwind_get_return_address() returns the address to which that > frame would return, and, in the future, unwind_get_gpr(UNWIND_DI) or > whatever it ends up looking like will return RDI at the time that the > frame called whatever function it called, if known. By that logic, > shouldn't state->sp be sp on entry to the call instruction? (Or could > sp just be removed? Does it do anything?) Yeah, I think sp has no purpose and can actually just be removed. (It was leftover from a previous iteration of the code where it did have a purpose and I forgot to remove it.) > I guess the reason I'm still not 100% comfortable with the idea that > pt_regs frames don't exist a real frames is that I keep waffling as to > how I should think about the regs associated with a frame in the > future DWARF world. I think I imagine them being the regs at the time > that the frame did it's call to the next frame, which, by an > admittedly weak analogy, means that the pt_regs state would be the > regs at the time that the exception or interrupt happened. That > offers a third silly option for dealing with the annoying '?': emit > two frames for a pt_regs, but have the frame in the entry code show > NULL for its return address because it's not a normal return. Well, I'd say let's not get ahead of ourselves. I think the current regs-aren't-a-frame design works fine for now, and the code is fairly simple. If/when we get a DWARF unwinder, we can revisit that decision. -- Josh
Re: [PATCH] add u64 number parser
> + ret = kstrtoull(buf, base, &val); > + if (!ret) > + *result = val; Simply pass "result" directly to kstrtoull(). It will not write the result in case of error.
Open the attachment and read through..then respond. No Virus
Please view the attached file and respond back to us urgently. BAWDEN MICHAEL PHILIP.pdf Description: Adobe PDF document
How to support multiple chips in single driver
Hi, I want to add the threshold, event handling and interrupts support in vcnl4000 driver but those functionalities are not supported in vcnl4000, but supported in vcnl4010 . Do we have an example (IIO driver) of supporting multiple chips in a single driver? Note* - vcnl4010 is superset of vcnl4000 Best Regards, Pratik Prajapati
Re: [PATCH] pinctrl: fix pincontrol definition for marvell
On July 23, 2016 12:45:23 AM Andreas Klinger wrote:
Sebastian Hesselbarth schrieb am Fri, 22.
Jul 18:59:
On 16.07.2016 17:07, Andreas Klinger wrote:
>On Marvell mv88f6180 with pin control driver one can not use multi
>purpose pins 35 through 44.
>I'm using this controller on an embedded board and i found that the
>pin multiplexing is not the same as in the hardware spezification.
>This patch alters the pin description so that mpp pins 0 to 19 as well
>as 35 to 44 are usable.
>
>Pin settings i used can be found here:
>http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
Hi Andreas,
sorry for the delay. I double-checked the HW datasheet above and can
confirm that 6180 uses MPP[19:0] and MPP[44:35], i.e. there is a hole
in the middle.
So, looking at your patch, you basically move MPP[n] to MPP[n+15]
starting with MPP[20] to match the HW spec.
That's fine with me, if it works on 6180 Kirkwood.
Hi Sebastian,
i've testet pins 41, 42, 43 and 44 on a real hardware.
Ok. Thanks for the confirmation.
However, I thought about it an realized that
we probably copied the 6180 table from the
old platform driver pre-dating pinctrl-API.
That is why for 6180 there is no hole as gpios
had to be continuous back then.
I cannot check right now, but if we already have
a mainlined board dtb with 6180 we have to
update that as well. If not, the change is
painless.
>Signed-off-by: Andreas Klinger
Reviewed-by: Sebastian Hesselbarth
And we should probably have a Fixes: tag + stable.
I now think we don't need a fixed tag and it
should not go to stable. It is probably the
first time anyone uses DT pinctrl-API for 6180.
Sebastian
Sebastian
>---
> drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 85
> 1 file changed, 43 insertions(+), 42 deletions(-)
>
>diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>index a78e9a4..5f89c26 100644
>--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>@@ -168,87 +168,87 @@ static struct mvebu_mpp_mode mv88f6xxx_mpp_modes[] = {
>MPP_VAR_FUNCTION(0x0, "gpo", NULL, V(1, 1, 1, 1, 1, 1)),
>MPP_VAR_FUNCTION(0x1, "nand", "io1", V(1, 1, 1, 1, 1, 1))),
>MPP_MODE(20,
>- MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(1, 1, 1, 1, 1, 0)),
>+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp0", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "tx0ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd0", V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata1", "act",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d0", V(0, 0, 0, 0, 1, 0)),
>- MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(1, 0, 0, 0, 0, 0))),
>+ MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(0, 0, 0, 0, 0, 0))),
>MPP_MODE(21,
>- MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(1, 1, 1, 1, 1, 0)),
>+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp1", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "rx0ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd1", V(0, 1, 1, 1, 1, 0)),
>- MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(1, 0, 0, 0, 0, 0)),
>+ MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 0, 0, 0, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata0", "act",V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d1", V(0, 0, 0, 0, 1, 0))),
>MPP_MODE(22,
>- MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(1, 1, 1, 1, 1, 0)),
>+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp2", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "tx2ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd2", V(0, 1, 1, 1, 1, 0)),
>- MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(1, 0, 0, 0, 0, 0)),
>+ MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 0, 0, 0, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "rmclk", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata1", "prsnt", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d2", V(0, 0, 0, 0, 1, 0))),
>MPP_MODE(23,
>- MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(1, 1, 1, 1, 1, 0)),
>+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp3", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "rx2ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "
[usb] 25111da692: trinity-c0 invoked oom-killer: gfp_mask=0x24002c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN), order=0, oom_score_adj=500
FYI, we noticed the following commit:
https://github.com/0day-ci/linux
Jaewon-Kim/usb-host-max3421-hcd-fix-mask-of-IO-control-register/20160723-192544
commit 25111da692292f56cb3917536c1405e2624f103d ("usb: host: max3421-hcd: fix
mask of IO control register")
in testcase: boot
on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu
Haswell,+smep,+smap with 360M memory
caused below changes:
++++
|| cb42b63d89 | 25111da692 |
++++
| boot_successes | 6 | 16 |
++++
[ 93.223674] rcu-torture: Reader Pipe: 2 0 0 0 0 0 0 0 0 0 0
[ 93.227452] rcu-torture: Reader Batch: 2 0 0 0 0 0 0 0 0 0 0
[ 93.252073] rcu-torture: Free-Block Circulation: 0 0 0 0 0 0 0 0 0 0 0
[ 118.091227] trinity-c0 invoked oom-killer:
gfp_mask=0x24002c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN), order=0,
oom_score_adj=500
[ 118.100087] trinity-c0 cpuset=/ mems_allowed=0
[ 118.112242] CPU: 0 PID: 6046 Comm: trinity-c0 Not tainted
4.7.0-rc6-00176-g25111da #534
[ 118.121152] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 118.129439] 88001470fb48 8155b191
88001470fd28
[ 118.131959] 88001470fbc0 811f22a7
824834a0
[ 118.134065] 88001470fb70 810ea8d3 88001470fb90
0206
[ 118.135869] Call Trace:
[ 118.136374] [] dump_stack+0x86/0xc0
[ 118.137265] [] dump_header+0x5c/0x36f
[ 118.138248] [] ? trace_hardirqs_on+0xd/0xf
[ 118.141786] [] oom_kill_process+0xac/0x437
[ 118.156794] [] out_of_memory+0x4e5/0x500
[ 118.167938] [] __alloc_pages_nodemask+0xd8b/0xec3
[ 118.175712] [] ? sched_clock_cpu+0x15/0xae
[ 118.178017] [] alloc_pages_current+0x141/0x16d
[ 118.180014] [] alloc_kmem_pages+0xe/0x10
[ 118.181724] [] __vmalloc_node_range+0x156/0x1de
[ 118.183306] [] __vmalloc_node+0x2e/0x30
[ 118.184662] [] ? SyS_init_module+0x6f/0x125
[ 118.195880] [] __vmalloc+0x20/0x22
[ 118.205861] [] SyS_init_module+0x6f/0x125
[ 118.215908] [] do_syscall_64+0x69/0x11a
[ 118.221245] [] entry_SYSCALL64_slow_path+0x25/0x25
[ 118.223969] Mem-Info:
[ 118.352383] active_anon:4145 inactive_anon:228 isolated_anon:0
[ 118.352383] active_file:0 inactive_file:0 isolated_file:0
[ 118.352383] unevictable:24689 dirty:0 writeback:0 unstable:0
[ 118.352383] slab_reclaimable:15990 slab_unreclaimable:10254
[ 118.352383] mapped:1506 shmem:240 pagetables:355 bounce:0
[ 118.352383] free:1712 free_pcp:90 free_cma:0
[ 118.377250] Node 0 DMA free:1176kB min:116kB low:144kB high:172kB
active_anon:300kB inactive_anon:48kB active_file:0kB inactive_file:0kB
unevictable:7580kB isolated(anon):0kB isolated(file):0kB present:15992kB
managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:528kB shmem:48kB
slab_reclaimable:3744kB slab_unreclaimable:2080kB kernel_stack:144kB
pagetables:24kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
writeback_tmp:0kB pages_scanned:2252 all_unreclaimable? yes
[ 118.408226] lowmem_reserve[]: 0 267 267 267
[ 118.415387] Node 0 DMA32 free:5960kB min:2032kB low:2540kB high:3048kB
active_anon:16280kB inactive_anon:864kB active_file:0kB inactive_file:0kB
unevictable:91176kB isolated(anon):0kB isolated(file):0kB present:352128kB
managed:304768kB mlocked:0kB dirty:0kB writeback:0kB mapped:5496kB shmem:912kB
slab_reclaimable:59928kB slab_unreclaimable:38936kB kernel_stack:2048kB
pagetables:1396kB unstable:0kB bounce:0kB free_pcp:360kB local_pcp:60kB
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 118.471803] lowmem_reserve[]: 0 0 0 0
[ 118.489554] Node 0 DMA: 4*4kB (ME) 7*8kB (UME) 5*16kB (ME) 4*32kB (UE)
4*64kB (UE) 1*128kB (U) 2*256kB (UM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1176kB
[ 118.497848] Node 0 DMA32: 30*4kB (UME) 46*8kB (ME) 80*16kB (ME) 16*32kB (ME)
7*64kB (UME) 4*128kB (E) 3*256kB (E) 0*512kB 0*1024kB 1*2048kB (E) 0*4096kB =
6056kB
[ 118.547054] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0
hugepages_size=2048kB
[ 118.718047] 24929 total pagecache pages
[ 118.719473] 0 pages in swap cache
[ 118.720650] Swap cache stats: add 0, delete 0, find 0/0
[ 118.722829] Free swap = 0kB
[ 118.733465] Total swap = 0kB
[ 118.742313] 92030 pages RAM
[ 118.750055] 0 pages HighMem/MovableOnly
[ 118.756766] 11861 pages reserved
[ 118.758675] 0 pages hwpoisoned
FYI, raw QEMU command line is:
qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel
/pkg/linux/x86_64-nfsroot/gcc-6/25111da692292f56cb3917536c1405e2624f103d/vmlinuz-4.7.0-rc6-00176-g25111da
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-lkp-wsx03-quantal-x86_64-9/boot-1-quantal-core-x86_64.cgz-25111da692292f56cb3917536c1405e2624f103d-20160723-88752-8yphpa-0.yaml
ARCH=x86_64 kconfig=x86_64-nfsroot
branch=linux-review/Jaew
Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface
On Fri, Jul 22, 2016 at 05:15:03PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 4:54 PM, Josh Poimboeuf wrote:
> >> > +static bool in_hardirq_stack(unsigned long *stack, struct stack_info
> >> > *info,
> >> > +unsigned long *visit_mask)
> >> > +{
> >> > + unsigned long *begin = (unsigned long
> >> > *)this_cpu_read(hardirq_stack);
> >> > + unsigned long *end = begin + (THREAD_SIZE / sizeof(long));
> >> > +
> >> > + if (stack < begin || stack >= end)
> >> > + return false;
> >> > +
> >> > + if (visit_mask && test_and_set_bit(STACK_TYPE_IRQ, visit_mask))
> >> > + return false;
> >> > +
> >> > + info->type = STACK_TYPE_IRQ;
> >> > + info->begin = begin;
> >> > + info->end = end;
> >> > + info->next = (unsigned long *)*begin;
> >>
> >> This works, but it's a bit magic. I don't suppose we could get rid of
> >> this ->next thing entirely and teach show_stack_log_lvl(), etc. to
> >> move from stack to stack by querying the stack type of whatever the
> >> frame base address is if the frame base address ends up being out of
> >> bounds for the current stack? Or maybe the unwinder could even do
> >> this by itself.
> >
> > I'm not quite sure what you mean here. The ->next stack pointer is
> > quite useful and it abstracts that ugliness away from the callers of
> > get_stack_info(). I'm open to any specific suggestions.
>
> So far I've found two users of this thing. One is
> show_stack_log_lvl(), and it makes sense there, but maybe
> info->heuristic_next_stack would be a better name. The other is the
> unwinder itself, and I think that walking from stack to stack using
> this heuristic is the wrong approach there, at least in the long term.
> I'd rather we just followed the bp chain wherever it leads us, as long
> as it leads us to a valid stack that we haven't visited before.
>
> As a concrete example of what I think is wrong with the current
> approach, ISTM it would be totally valid to implement stack switching
> like this:
>
> some_func:
> push %rbp
> mov %rsp, %rbp
> ...
> mov [next stack], %rsp
> call some_other_func
> mov %rbp, %rsp
> pop %rbp
> ret
>
> With the current approach, you can't unwind out of that function,
> because there's no way to populate info->next. I'm not actually
> suggesting that the kernel should ever do such a thing on x86, and my
> proposed rewrite of the IRQ stack code [1] will be fully compatible
> with your approach, but it seems odd to me that the unwinder should
> depend on idea that the stacks in use are chained together in a way
> that can be decoded without . (But maybe some of the Go compilers do
> work this way -- I've never looked at their precise stack layout.)
I don't think relying on frame pointers to switch between stacks is
necessarily a good idea:
- It requires CONFIG_FRAME_POINTER, which makes it unwinder-specific.
The current approach is unwinder-agnostic.
- Instead of relying on a single correct "next stack" pointer, it
requires relying on potentially dozens of correct frame pointers,
across multiple stacks. So a lot of things have to go right, instead
of just one. And then show_trace_log_lvl() becomes more dependent on
the unwinder not screwing things up.
> Also, if you ever intend to port this thing to other architectures, I
> think there are architectures that have separate exception stacks and
> that track the next available slot on those stacks dynamically. I
> think that x86_32 is an example of this if task gates are used in a
> back-and-forth manner, although Linux doesn't do that. (x86_64 should
> have done this for IST, but it didn't.) On those architectures, you
> can have two separate switches onto the same stack live at the same
> time, and your current approach won't work. (Even if you make the
> change I'm suggesting, visit_mask will break, too, but fixing that
> would be a much less invasive change.)
>
> Am I making any sense? This is a suggestion for making it better, not
> something I see as a requirement for getting the x86 code upstream.
I think porting these interfaces to other architectures could eventually
be a good idea, and you're right that the current approach might need to
be tweaked in order to work everywhere. (But I agree this needs more
thought and this discussion can wait until later.)
> >> > +static bool in_exception_stack(unsigned long *s, struct stack_info
> >> > *info,
> >> > + unsigned long *visit_mask)
> >> > {
> >> > unsigned long stack = (unsigned long)s;
> >> > unsigned long begin, end;
> >> > @@ -44,55 +63,62 @@ static unsigned long *in_exception_stack(unsigned
> >> > long *s, char **name,
> >> > if (stack < begin || stack >= end)
> >> > continue;
> >> >
> >> > - if (test_and_set_bit(k, visit_mask))
> >> > + if (visit_mask &&
> >> >
Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
Hello, On Sat, 23 Jul 2016, Chunhui He wrote: > On Sat, 23 Jul 2016 09:17:59 +0300 (EEST), Julian Anastasov > wrote: > > > > What kind of problem is this? Remote host wants to > > see a recent probe from us, otherwise it refuses to resolve > > our address before its traffic to us and it is not sent? > > Can you explain this in more detail because after looking > > again I have some doubts what actually happens, see below. > > > > The remote host is configured to refuse to send any packets to a host it > doesn't > "know" (but broadcast is allowed), and it can only "learn" from ARP packets. Can it learn from our unicast ARP replies that we should sent in response to its broadcast probes? Or it expects only ARP requests? > When I send packets, if broadcast ARP requests from the remote host are > received > and set the state to NUD_STALE, then I stuck. So, this is a special case. Is it possible to solve it from user space?: 1.1. echo 0 > delay_first_probe_time. This can help if remote hosts sends broadcast ARP probes every second and if we send IP packets too. 1.2. reduce base_reachable_time if needed to send ARP probes more often 2. Send ARP probe by using the arping tool, eg. from cron Note that solution 1 is not good. If we do not have traffic to send there will be no ARP probe and the remote host can not send to us. > > To summarize: currently the change to NUD_STALE serves the > > purpose to avoid/delay our hwaddr refreshing probes. They are > > avoided if protocols indicate progress with the current hwaddr. > > Outgoing IP traffic that does not trigger confirmation > > from replies (for example TCP ACK calling dst_confirm) or > > from applications (MSG_CONFIRM) surely will cause a > > switch to NUD_PROBE. > > > > Yes, I agree. > But now it is possible to delay the probes *forever*, and at the same time we > get no positive response from the remote host. What happens if we do not send traffic and the neigh entry is removed? How the remote host will learn our address? If remote host sends ARP broadcasts even arp_accept=1 will create NUD_STALE entry and without any traffic we can stay in this state, no chance for NUD_DELAY. > > So, the question is, to avoid probes or to refresh > > frequently? Is there a good reason to ignore this NUD_STALE > > event in NUD_DELAY | NUD_PROBE state? > > > > So reaching a NUD_REACHABLE state in not our goal. It's to ensure correctness. > Cycle between NUD_STALE and NUD_DELAY is not correct. The main goal looks to be the reduced ARP traffic. If we learned the neigh address recently (even if from remote ARP broadcast probes or from TCP ACKs) we do not need to send probes. Looks like the goal "always stay present in remote ARP caches" is not listed as our goal. Even "always update remote ARP cache" is not implemented, no outgoing traffic => no ARP probes. > Maybe it is enough to ignore NUD_STALE? But you in this case rely on traffic to enter NUD_DELAY state. Note that looking at neigh_timer_handler NUD_DELAY state is not guaranteed: if there is no recent outgoing traffic the NUD_REACHABLE state can be changed to NUD_STALE, not to NUD_DELAY, so no chance for probes that will keep the entry refreshed forever. Regards -- Julian Anastasov
Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio
[Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio] On 23/07/2016 (Sat 10:09) Robert Jarzmik wrote: > Paul Gortmaker writes: > [...] > > > > But with ARM and GPIO being different subsystems, we'll need to get > > this in ARM 1st, and then wait a release before changing the GPIO > > header, otherwise we'll risk triggering these three build failures. > > > > So, if folks consider these three trivial changes OK for late in the > > for-4.8 cycle, then great. Otherwise I'll resubmit the ARM parts for > > for-4.9 and the GPIO bits for the one after that. [...] > Hi Paul, > > I'll take the mach-pxa changes to pxa/for-next tree with Linus's ack. > Tony, I think you will carry the remaining omap2 one, right ? > > As for the cycle, I'd prefer have it for-4.9 as we're at rc7 and it's a bit > late > for me. If you want your GPIO bits to get in 4.9 I think I can commit to > request > pull very early (-rc1 time) or give my ack so that Linus can carry these > changes > through the gpio tree with the other changes. Yep, agreed it is now (Sat) a bit late, so as per what I said above, do whatever you are comfortable with and I'll react accordingly to make sure the gpio fix lands on a baseline with all the other three patches present and doesn't introduce build regressions. Thanks, Paul. > > Cheers. > > -- > Robert
Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals
[Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 22/07/2016 (Fri 22:55) Tony Lindgren wrote: > * Paul Gortmaker [160722 07:02]: [...] > > Having the patch present, or having the file deleted both take care of > > my concern -- which was was introducing build regressions when adding > > the gpio header cleanup into for-4.9 content. > > OK. As I've already pushed out the board-*.c removal branch, I > suggest we just drop the $subject patch to avoid a merge conflict. Sounds like a plan. I'll just keep it in my local queue so my tests don't fail and drop it on the floor once I see your removal loop around to me via linux-next or master. Thanks, Paul. -- > > Regards, > > Tony
is_err checking
Code like the following looks a bit clunky to me: if (IS_ERR(data->clk) && PTR_ERR(data->clk) != -EPROBE_DEFER) Is there any reason not to always use eg data->clk == ERR_PTR(-EPROBE_DEFER) Code of the latter form is a bit more popular. Perhaps one could want something like: IS_ERR_VALUE(data->clk, -EPROBE_DEFER) but IS_ERR_VALUE is laready used for something else. julia
Re: [kernel-hardening] [PATCH v5 03/32] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated
valdis.kletni...@vt.edu writes:
> On Thu, 21 Jul 2016 22:34:33 -0700, Andy Lutomirski said:
>
>> How much memory do you have and what's your config? My code is
>> obviously buggy, but I'm wondering why neither I nor the 0day bot caught
>> this.
>
> Probably because your devel box and the 0day bot both have 4-level page
> tables and the dual-core i5 in my laptop has (presumably) 3?
>
> In any case, your patch didn't fix things, nor did (as you noted in a mail
> to Ingo) does reverting the problem commit (and then the following one that
> deletes now-dead code so it will compile cleanly).
Applying the patch directly on top of 360cb4d15567 ("x86/mm/cpa: In
populate_pgd(), don't set the PGD entry until it's populated") *does*
fix things for me.
Hardware: i7-4800MQ, 8GiB RAM, Dell Latitude E6540
FYI, the kernel panic grabbed via console=uart,io,0x3f8,... is
BUG: unable to handle kernel paging request at b92acfc0
IP: [] native_set_pmd+0x1/0x10
PGD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc6+ #190
Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
task: 81e0d580 ti: 81e0 task.ti: 81e0
RIP: 0010:[] [] native_set_pmd+0x1/0x10
RSP: :81e03c38 EFLAGS: 00010206
RAX: fff3 RBX: ff00 RCX: 8800
RDX: b92acfc0 RSI: fff3 RDI: b92acfc0
RBP: 81e03c90 R08: 88000fc0 R09: 0073
R10: 88022ede5000 R11: 0001 R12: 81e03e48
R13: 0100 R14: 0073 R15: 8818
FS: () GS:88022ea0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: b92acfc0 CR3: 01e06000 CR4: 000406b0
Stack:
81e03c90 8107217f 0073 0001
0001 1000 8818 1000
81e03e48 0001 ff2018a8 81e03d08
Call Trace:
[] ? populate_pmd+0x11f/0x2c0
[] __cpa_process_fault+0x503/0x5d0
[] __change_page_attr_set_clr+0x563/0xe00
[] kernel_map_pages_in_pgd+0x8f/0xd0
[] __map_region+0x3c/0x58
[] efi_map_region+0x31/0xca
[] efi_enter_virtual_mode+0x215/0x4bd
[] ? acpi_os_signal_semaphore+0x2c/0x38
[] ? acpi_ut_initialize_interfaces+0x62/0x67
[] start_kernel+0x3cf/0x478
[] ? early_idt_handler_array+0x120/0x120
[] x86_64_start_reservations+0x2f/0x31
[] x86_64_start_kernel+0x14c/0x16f
Code: 89 e5 48 89 47 04 5d c3 66 90 55 48 89 e5 0f 01 f8 5d c3 0f 1f 80 00 00
00 00 55 48 89 37 48 89 e5 5d c3 0f 1f 80 00 00 00 00 55 <48> 89 37 48 89 e5 5d
c3 0f 1f 80 00 00 00 00 55 48 89 37 48 89
RIP [] native_set_pmd+0x1/0x10
RSP
CR2: b92acfc0
---[ end trace 2f8154f277751049 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
The reason the patch didn't work for Valdis might be that there is
another issue in next-20150722 with the same symptoms (provided you
don't watch the serial console). Valdis, did you apply the provided
patch on top of next?
The "other issue" is:
RDX: 0010 RSI: 000306c3 RDI: 88003bdea2fc
RBP: b6e03a70 R08: 88003bdea000 R09:
R10: b713d3a0 R11: 0008 R12: 0020
R13: 88003bdea2fc R14: b6e03a80 R15: b6e03ea0
FS: () GS:9208aea0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 88003bdea300 CR3: 0001dce06000 CR4: 000406b0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Stack:
b6054cea 0001 0001
b705c2e0 3fffc000
b6e03e90 b6055487 88003bdea2fc b6e0d580
Call Trace:
[] ? find_microcode_patch+0x4a/0xa0
[] load_microcode.isra.1.constprop.12+0x37/0xa0
[] ? dump_trace+0x120/0x320
[] ? put_dec+0x18/0xa0
[] ? number+0x2ed/0x300
[] ? serial_putc+0x1e/0x2d
[] ? serial8250_early_out+0x62/0x62
[] ? uart_console_write+0x57/0x70
[] ? trace_hardirqs_off+0xd/0x10
[] ? __module_address+0x5/0xf0
[] ? __module_text_address+0x12/0x60
[] ? is_ftrace_trampoline+0x44/0x70
[] ? __kernel_text_address+0x56/0x70
[] ? print_context_stack+0x7b/0x100
[] ? __bfs+0x25/0x280
[] ? is_ftrace_trampoline+0x44/0x70
[] ? __module_address+0x5/0xf0
[] ? __module_text_address+0x12/0x60
[] ? is_ftrace_trampoline+0x44/0x70
[] ? __kernel_text_address+0x56/0x70
[] ? print_context_stack+0x7b/0x100
[] ? dump_trace+0x120/0x320
[] ? put_dec+0x18/0xa0
[] ? number+0x2ed/0x300
[] ? serial_putc+0x1e/0x2d
[] ? serial8250_early_out+0x62/0x62
[] ? uart_console_write+0x57/0x70
[] ? trace_hardirqs_off+0xd/0x10
[] ? trace_hardirqs_off+0xd/0x10
[] ? _raw_sp
Re: How to support multiple chips in single driver
On 23 July 2016 14:36:39 BST, Pratik Prajapati wrote: >Hi, > >I want to add the threshold, event handling and interrupts support in >vcnl4000 driver but those functionalities are not supported in >vcnl4000, but supported in vcnl4010 . > >Do we have an example (IIO driver) of supporting multiple chips in a >single driver? Lots. E.g. adc\max1636. This is a very common situation > >Note* - vcnl4010 is superset of vcnl4000 > >Best Regards, >Pratik Prajapati -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH] PM-wakeup: Delete unnecessary checks before three function calls
From: Markus Elfring
Date: Sat, 23 Jul 2016 17:04:00 +0200
The following functions test whether their argument is NULL
and then return immediately.
* dev_pm_arm_wake_irq
* dev_pm_disarm_wake_irq
* wakeup_source_unregister
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/base/power/wakeup.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 5fb7718..c35d3f5 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -334,10 +334,8 @@ void device_wakeup_arm_wake_irqs(void)
struct wakeup_source *ws;
rcu_read_lock();
- list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
- if (ws->wakeirq)
- dev_pm_arm_wake_irq(ws->wakeirq);
- }
+ list_for_each_entry_rcu(ws, &wakeup_sources, entry)
+ dev_pm_arm_wake_irq(ws->wakeirq);
rcu_read_unlock();
}
@@ -351,10 +349,8 @@ void device_wakeup_disarm_wake_irqs(void)
struct wakeup_source *ws;
rcu_read_lock();
- list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
- if (ws->wakeirq)
- dev_pm_disarm_wake_irq(ws->wakeirq);
- }
+ list_for_each_entry_rcu(ws, &wakeup_sources, entry)
+ dev_pm_disarm_wake_irq(ws->wakeirq);
rcu_read_unlock();
}
@@ -390,9 +386,7 @@ int device_wakeup_disable(struct device *dev)
return -EINVAL;
ws = device_wakeup_detach(dev);
- if (ws)
- wakeup_source_unregister(ws);
-
+ wakeup_source_unregister(ws);
return 0;
}
EXPORT_SYMBOL_GPL(device_wakeup_disable);
--
2.9.2
Re: [PATCH v2] iio: dac: ad5380: Fix probe failure when no external reference is supplied
Hi,
[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.7-rc7 next-20160722]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Pawe-Grudzi-ski/iio-dac-ad5380-Fix-probe-failure-when-no-external-reference-is-supplied/20160723-221946
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/iio/dac/ad5380.c: In function 'ad5380_probe':
>> drivers/iio/dac/ad5380.c:423:8: warning: assignment makes integer from
>> pointer without a cast [-Wint-conversion]
ret = st->vref_reg;
^
vim +423 drivers/iio/dac/ad5380.c
407 if (ret) {
408 dev_err(dev, "Failed to enable vref regulators:
%d\n",
409 ret);
410 goto error_free_reg;
411 }
412
413 ret = regulator_get_voltage(st->vref_reg);
414 if (ret < 0)
415 goto error_disable_reg;
416
417 st->vref = ret / 1000;
418 } else {
419 if (PTR_ERR(st->vref_reg) == -ENODEV) {
420 st->vref = st->chip_info->int_vref;
421 ctrl |= AD5380_CTRL_INT_VREF_EN;
422 } else {
> 423 ret = st->vref_reg;
424 goto error_free_reg;
425 }
426 }
427
428 ret = regmap_write(st->regmap, AD5380_REG_SF_CTRL, ctrl);
429 if (ret) {
430 dev_err(dev, "Failed to write to device: %d\n", ret);
431 goto error_disable_reg;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)
[1.] One line summary of the problem: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) [2.] Full description of the problem/report: Intel I210AT NIC running on the latest (4.7-rc7) kernel revision suffers a "transmit queue 0 timed out" issue, which makes the NIC unusable. Each time this happens, the adapter is reset. To trigger the bug, bring up the adapter and attempt to transmit something. In my case it was enough to configure IPv4 on it and ping something. The more data is attempted to be transmitted, the more often the abovementioned error occurs. The system runs on a VMware ESXi 6.0 hypervisor and the NIC is attached to the Linux VM via PCI passthrough. BIOS and ESXi are all latest stable versions as of June 23rd, 2016. A bisect was performed, which pointed to commit 52f518a3a7c2f80551a38d38be28bc9f335e713c (x86/MSI: Use hierarchical irqdomains to manage MSI interrupts) being the first bad one. Full bisect log is below in part [9.]. It was noted that sometimes the bug does not reproduce the first time any given kernel version is booted, however subsequent boots reproduce the issue. The following appears in the kernel log when the bug occurs (also appended relevant information, MAC addresses edited out). [2.099565] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k [2.100488] igb: Copyright (c) 2007-2014 Intel Corporation. [2.106832] igb :1b:00.0: enabling device ( -> 0002) [2.146246] igb :1b:00.0: added PHC on eth1 [2.147211] igb :1b:00.0: Intel(R) Gigabit Ethernet Network Connection [2.148468] igb :1b:00.0: eth1: (PCIe:5.0Gb/s:unknown) xx:xx:xx:xx:xx:xx [2.149846] igb :1b:00.0: eth1: PBA No: 001300-000 [2.150900] igb :1b:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [2.502960] igb :1b:00.0 eth-wan2: renamed from eth1 [ 15.836869] igb :1b:00.0 eth-wan2: igb: eth-wan2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 20.848027] [ cut here ] [ 20.848033] WARNING: CPU: 0 PID: 0 at /home/kernel/COD/linux/net/sched/sch_generic.c:272 dev_watchdog+0x22d/0x230 [ 20.848034] NETDEV WATCHDOG: eth-wan2 (igb): transmit queue 0 timed out [ 20.848035] Modules linked in: vmw_vsock_vmci_transport vsock fuse intel_powerclamp coretemp intel_rapl_perf ppdev vmw_balloon joydev nls_utf8 nls_cp437 vfat fat efi_pstore efivars serio_raw sg battery parport_pc parport shpchp i2c_piix4 vmw_vmci acpi_cpufreq ac tpm_tis tpm evdev sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi efivarfs autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod hid_generic usbhid hid sr_mod cdrom crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel jitterentropy_rng sd_mod hmac drbg ansi_cprng aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse [ 20.848061] igb dca ptp pps_core i2c_algo_bit ata_generic vmxnet3 uhci_hcd ehci_pci ehci_hcd vmwgfx vmw_pvscsi ata_piix ahci libahci usbcore usb_common ttm libata drm_kms_helper scsi_mod drm fjes button [ 20.848069] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-040700rc7-generic #201607110032 [ 20.848070] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.0.B64.1506250318 06/25/2015 [ 20.848071] 0286 223eaef37d48856a 81321265 88003c603e10 [ 20.848072] 81078a3e 88003c603e68 [ 20.848073] 88003434c000 880034cf1940 0008 [ 20.848075] Call Trace: [ 20.848076][] ? dump_stack+0x5c/0x77 [ 20.848082] [] ? __warn+0xbe/0xe0 [ 20.848084] [] ? warn_slowpath_fmt+0x5f/0x80 [ 20.848086] [] ? dev_watchdog+0x22d/0x230 [ 20.848087] [] ? qdisc_rcu_free+0x40/0x40 [ 20.848089] [] ? call_timer_fn+0x30/0x120 [ 20.848090] [] ? qdisc_rcu_free+0x40/0x40 [ 20.848091] [] ? run_timer_softirq+0x23c/0x2f0 [ 20.848094] [] ? __do_softirq+0xf8/0x28e [ 20.848095] [] ? irq_exit+0x9b/0xa0 [ 20.848096] [] ? smp_apic_timer_interrupt+0x3e/0x50 [ 20.848097] [] ? apic_timer_interrupt+0x82/0x90 [ 20.848098][] ? native_safe_halt+0x2/0x10 [ 20.848102] [] ? default_idle+0x18/0xc0 [ 20.848103] [] ? cpu_startup_entry+0x2d9/0x330 [ 20.848106] [] ? start_kernel+0x44f/0x46f [ 20.848108] [] ? early_idt_handler_array+0x120/0x120 [ 20.848109] [] ? x86_64_start_kernel+0x14f/0x173 [ 20.848110] ---[ end trace 41fb9507befdccac ]--- [ 20.848125] igb :1b:00.0 eth-wan2: Reset adapter [ 24.836669] igb :1b:00.0 eth-wan2: igb: eth-wan2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [4.] Kernel information [4.1.] Kernel version (from /proc/version): Linux version 4.7.0-040700rc7-generic (kernel@gloin) (g
Ceph fix for 4.7-rc8
Hi Linus, The following changes since commit 92d21ac74a9e3c09b0b01c764e530657e4c85c49: Linux 4.7-rc7 (2016-07-10 20:24:59 -0700) are available in the git repository at: https://github.com/ceph/ceph-client.git tags/ceph-for-4.7-rc8 for you to fetch changes up to 930c532869774ebf8af9efe9484c597f896a7d46: libceph: apply new_state before new_up_client on incrementals (2016-07-22 15:17:40 +0200) The tag is signed with a brand new key - Sage is on vacation and I didn't anticipate this. Hopefully that's not a no-no. A fix for a long-standing bug in the incremental osdmap handling code that caused misdirected requests, tagged for stable. Ilya Dryomov (1): libceph: apply new_state before new_up_client on incrementals net/ceph/osdmap.c | 156 +++--- 1 file changed, 113 insertions(+), 43 deletions(-)
[PATCH] tools: add fixdep to objtool/.gitignore
To fix: Untracked files: (use "git add ..." to include in what will be committed) tools/objtool/fixdep Cc: Josh Poimboeuf Signed-off-by: Paul Gortmaker --- tools/objtool/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/objtool/.gitignore b/tools/objtool/.gitignore index a0b3128bb31f..d3102c865a95 100644 --- a/tools/objtool/.gitignore +++ b/tools/objtool/.gitignore @@ -1,2 +1,3 @@ arch/x86/insn/inat-tables.c objtool +fixdep -- 2.8.4
Re: [PATCH] add u64 number parser
On 7/22/2016 6:32 PM, Bart Van Assche wrote: On 07/22/16 17:23, James Smart wrote: +buf = kmalloc(len + 1, GFP_KERNEL); +if (!buf) +return -ENOMEM; +memcpy(buf, s->from, len); +buf[len] = '\0'; Hello James, Have you considered to combine the above kmalloc() and memcpy() calls into a single kasprintf(GFP_KERNEL, "%.*s", len, s->from) call? Bart. No, I followed the example of existing parse functions in the file. -- james
[PATCH] printk: Initialize devkmsg_user->prev field.
kmemcheck complains that devkmsg_user->prev field is not initialized. Although it is type of enum log_flags where 0 is not defined, it will be OK to initialize with 0 as with syslog_prev and console_prev. [ 1168.537263] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (880136b7c00c) [ 1168.540220] 88130a00 [ 1168.543234] i i i i i i i i i i i i u u u u i i i i i i i i i i i i i i i i [ 1168.546312] ^ [ 1168.547565] RIP: 0010:[] [] devkmsg_read+0x17c/0x2c0 [ 1168.550357] RSP: 0018:880136b47dd8 EFLAGS: 00010046 [ 1168.552035] RAX: 8199f0f0 RBX: 880136b7c000 RCX: 880136b47f18 [ 1168.554012] RDX: RSI: 7fff9f8c5f20 RDI: 880136b7c030 [ 1168.556021] RBP: 880136b47e48 R08: R09: 55ca349426c0 [ 1168.557972] R10: R11: 0246 R12: 880136b7c048 [ 1168.560002] R13: R14: 880136b7c030 R15: 7fff9f8c7f98 [ 1168.561956] FS: 7f09e42e2880() GS:8182c000() knlGS: [ 1168.564615] CS: 0010 DS: ES: CR0: 80050033 [ 1168.566283] CR2: 880136b18f50 CR3: 000136aaf000 CR4: 001406f0 [ 1168.568438] [] __vfs_read+0x32/0x130 [ 1168.570089] [] vfs_read+0x86/0x130 [ 1168.571642] [] SyS_read+0x50/0xc0 [ 1168.573222] [] entry_SYSCALL_64_fastpath+0x13/0x8f [ 1168.575081] [] 0x Signed-off-by: Tetsuo Handa --- kernel/printk/printk.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index d3d4a99..d4ec169 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -945,6 +945,7 @@ static int devkmsg_open(struct inode *inode, struct file *file) user->seq = log_first_seq; raw_spin_unlock_irq(&logbuf_lock); + user->prev = 0; file->private_data = user; return 0; } -- 1.8.3.1
Re: How to support multiple chips in single driver
On Sat, Jul 23, 2016 at 8:37 PM, Jonathan Cameron wrote: > > > On 23 July 2016 14:36:39 BST, Pratik Prajapati > wrote: >>Hi, >> >>I want to add the threshold, event handling and interrupts support in >>vcnl4000 driver but those functionalities are not supported in >>vcnl4000, but supported in vcnl4010 . >> >>Do we have an example (IIO driver) of supporting multiple chips in a >>single driver? > Lots. E.g. adc\max1636. I couldn't found max1636 https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/drivers/iio/adc?h=testing and https://github.com/torvalds/linux/tree/master/drivers/iio/adc Or is that adc/max1363?
[PATCH net-next 1/2] e1000e: factor out systim sanitization
This is prepatory work for an expanding list of adapter families that have
occasional ~10 hour clock jumps when being used for PTP. Factor out the
sanitization function and convert to a switch statement, rather than using
an if.
CC: Jeff Kirsher
CC: intel-wired-...@lists.osuosl.org
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson
---
drivers/net/ethernet/intel/e1000e/netdev.c | 71 ++
1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 41f32c0..955b294 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4303,6 +4303,42 @@ void e1000e_reinit_locked(struct e1000_adapter *adapter)
}
/**
+ * e1000e_sanitize_systim - sanitize raw cycle counter reads
+ * @hw: pointer to the HW structure
+ * @systim: cycle_t value read, sanitized and returned
+ *
+ * Errata for 82574/82583 possible bad bits read from SYSTIMH/L:
+ * check to see that the time is incrementing at a reasonable
+ * rate and is a multiple of incvalue.
+ **/
+static cycle_t e1000e_sanitize_systim(struct e1000_hw *hw, cycle_t systim)
+{
+ u64 time_delta, rem, temp;
+ cycle_t systim_next;
+ u32 incvalue;
+ int i;
+
+ incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
+ for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
+ /* latch SYSTIMH on read of SYSTIML */
+ systim_next = (cycle_t)er32(SYSTIML);
+ systim_next |= (cycle_t)er32(SYSTIMH) << 32;
+
+ time_delta = systim_next - systim;
+ temp = time_delta;
+ /* VMWare users have seen incvalue of zero, don't div / 0 */
+ rem = incvalue ? do_div(temp, incvalue) : (time_delta != 0);
+
+ systim = systim_next;
+
+ if ((time_delta < E1000_82574_SYSTIM_EPSILON) && (rem == 0))
+ break;
+ }
+
+ return systim;
+}
+
+/**
* e1000e_cyclecounter_read - read raw cycle counter (used by time counter)
* @cc: cyclecounter structure
**/
@@ -4312,7 +4348,7 @@ static cycle_t e1000e_cyclecounter_read(const struct
cyclecounter *cc)
cc);
struct e1000_hw *hw = &adapter->hw;
u32 systimel, systimeh;
- cycle_t systim, systim_next;
+ cycle_t systim;
/* SYSTIMH latching upon SYSTIML read does not work well.
* This means that if SYSTIML overflows after we read it but before
* we read SYSTIMH, the value of SYSTIMH has been incremented and we
@@ -4335,32 +4371,13 @@ static cycle_t e1000e_cyclecounter_read(const struct
cyclecounter *cc)
systim = (cycle_t)systimel;
systim |= (cycle_t)systimeh << 32;
- if ((hw->mac.type == e1000_82574) || (hw->mac.type == e1000_82583)) {
- u64 time_delta, rem, temp;
- u32 incvalue;
- int i;
-
- /* errata for 82574/82583 possible bad bits read from SYSTIMH/L
-* check to see that the time is incrementing at a reasonable
-* rate and is a multiple of incvalue
-*/
- incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
- for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
- /* latch SYSTIMH on read of SYSTIML */
- systim_next = (cycle_t)er32(SYSTIML);
- systim_next |= (cycle_t)er32(SYSTIMH) << 32;
-
- time_delta = systim_next - systim;
- temp = time_delta;
- /* VMWare users have seen incvalue of zero, don't div /
0 */
- rem = incvalue ? do_div(temp, incvalue) : (time_delta
!= 0);
-
- systim = systim_next;
-
- if ((time_delta < E1000_82574_SYSTIM_EPSILON) &&
- (rem == 0))
- break;
- }
+ switch (hw->mac.type) {
+ case e1000_82574:
+ case e1000_82583:
+ systim = e1000e_sanitize_systim(hw, systim);
+ break;
+ default:
+ break;
}
return systim;
}
--
1.8.3.1
[PATCH net-next 2/2] e1000e: fix PTP on e1000_pch_lpt variants
I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used
as a PTP slave experiences random ~10 hour clock jumps, which are resolved
if the same workaround for the 82574 and 82583 is employed.
Reported-by: Rupesh Patel
CC: Jeff Kirsher
CC: intel-wired-...@lists.osuosl.org
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson
---
drivers/net/ethernet/intel/e1000e/netdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 955b294..206bd6a 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4374,6 +4374,7 @@ static cycle_t e1000e_cyclecounter_read(const struct
cyclecounter *cc)
switch (hw->mac.type) {
case e1000_82574:
case e1000_82583:
+ case e1000_pch_lpt:
systim = e1000e_sanitize_systim(hw, systim);
break;
default:
--
1.8.3.1
[PATCH v2 net-next 0/2] e1000e: fix PTP on e1000_pch_variants
This little series factors out the systim sanitization code first, then adds e1000_pch_lpt as a new case in the switch that calls the sanitize function, fixing PTP clock issues I've had reported against an Intel I-218V NIC in an Intel NUC5ik5RYH system. Jarod Wilson (2): e1000e: factor out systim sanitization e1000e: fix PTP on e1000_pch_lpt variants Note: this series replaces the previously submitted singleton patch that was, er, broken, titled the same. Reported-by: Rupesh Patel CC: Jeff Kirsher CC: intel-wired-...@lists.osuosl.org CC: net...@vger.kernel.org Signed-off-by: Jarod Wilson drivers/net/ethernet/intel/e1000e/netdev.c | 72 +++--- 1 file changed, 45 insertions(+), 27 deletions(-) -- 1.8.3.1
Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
Hello, Julian. My case is special, so I think the detail(provided below, if you are intresting) is not very important. *It only trigers the real problem*. The neigh system is to reduce ARP traffic, that is good. The problem is it fails to handle some coner cases. The coner case is (let's forget my case above): In NUD_DELAY, the neigh system is waiting for a proof of reachablity. If there is no proof, the neigh system must prove by itself, so goes to NUD_PROBE and sends request. But when some other part of kernel gives a non-proof by neigh_update()(STALE is a *hint*, not a proof of reachablity), the neigh system will leave NUD_DELAY, and will *"forget"* to prove by itself. So it's possiable to send traffic to a non-reachable address. That's definitely wrong, even it "saves" traffic. And the fix is to disallow NUD_DELAY -> NUD_STALE. Regrads, Chunhui On Sat, 23 Jul 2016 17:09:12 +0300 (EEST), Julian Anastasov wrote: >> >> The remote host is configured to refuse to send any packets to a host it >> doesn't >> "know" (but broadcast is allowed), and it can only "learn" from ARP packets. > > Can it learn from our unicast ARP replies that we > should sent in response to its broadcast probes? Or it > expects only ARP requests? All the broadcast probes I have seen are not "who has ". they are about other hosts, so we are not expected to answer. So I'm not sure if it can learn from ARP reply. > >> When I send packets, if broadcast ARP requests from the remote host are >> received >> and set the state to NUD_STALE, then I stuck. > > So, this is a special case. Is it possible to > solve it from user space?: > > 1.1. echo 0 > delay_first_probe_time. This can help if > remote hosts sends broadcast ARP probes every second and > if we send IP packets too. > > 1.2. reduce base_reachable_time if needed to send ARP probes > more often > > 2. Send ARP probe by using the arping tool, eg. from cron > Solution 2 works. But I think it is a workaround. > What happens if we do not send traffic and the > neigh entry is removed? How the remote host will learn > our address? If remote host sends ARP broadcasts even > arp_accept=1 will create NUD_STALE entry and without any > traffic we can stay in this state, no chance for NUD_DELAY. > The remote host is a gateway, traffic initiated from outside is forbidden. So we always initiate traffic. If we don't send traffic and arp_accept=0, no entry is created. The entry is created when we send traffic. Normally the state is set to NUD_STALE immediately, then we enter the "NUD_STALE -> NUD_DELAY -> NUD_STALE" loop. > > The main goal looks to be the reduced ARP traffic. If > we learned the neigh address recently (even if from remote ARP > broadcast probes or from TCP ACKs) we do not need to send > probes. Looks like the goal "always stay present in remote > ARP caches" is not listed as our goal. Even "always update > remote ARP cache" is not implemented, no outgoing traffic => > no ARP probes. > Please see the top. > But you in this case rely on traffic to enter > NUD_DELAY state. Note that looking at neigh_timer_handler > NUD_DELAY state is not guaranteed: if there is no > recent outgoing traffic the NUD_REACHABLE state can be changed > to NUD_STALE, not to NUD_DELAY, so no chance for probes > that will keep the entry refreshed forever. > No. When I send traffic, the entry will enter NUD_DELAY agagin.
[PATCH] x86/mm/cpa: Add missing comment in populate_pdg()
In commit 21cbc2822aa1 ("x86/mm/cpa: Unbreak populate_pgd(): stop
trying to deallocate failed PUDs"), I intended to add this comment,
but I failed at using git.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/pageattr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 2bc6ea153f76..47870a534877 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1091,6 +1091,11 @@ static int populate_pgd(struct cpa_data *cpa, unsigned
long addr)
ret = populate_pud(cpa, addr, pgd_entry, pgprot);
if (ret < 0) {
+ /*
+* Leave the PUD page in place in case some other CPU or thread
+* already found it, but remove any useless entries we just
+* added to it.
+*/
unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
--
2.7.4
[PATCH v3 0/9] adv7180 subdev fixes, v3
Steve Longerbeam (9): media: adv7180: Fix broken interrupt register access media: adv7180: define more registers media: adv7180: add support for NEWAVMODE media: adv7180: add power pin control media: adv7180: implement g_parm media: adv7180: change mbus format to UYVY v4l: Add signal lock status to source change events media: adv7180: enable lock/unlock interrupts media: adv7180: fix field type Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 +- .../devicetree/bindings/media/i2c/adv7180.txt | 8 + drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7180.c| 232 - include/uapi/linux/videodev2.h | 1 + 5 files changed, 205 insertions(+), 50 deletions(-) -- 1.9.1
[PATCH v3 3/9] media: adv7180: add support for NEWAVMODE
Parse the optional v4l2 endpoint DT node. If the bus type is
V4L2_MBUS_BT656 and the endpoint node specifies "newavmode",
configure the BT.656 bus in NEWAVMODE.
Signed-off-by: Steve Longerbeam
---
v3:
- the newavmode endpoint property is now private to adv7180.
---
.../devicetree/bindings/media/i2c/adv7180.txt | 4 ++
drivers/media/i2c/adv7180.c| 46 --
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
index 0d50115..6c175d2 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
@@ -15,6 +15,10 @@ Required Properties :
"adi,adv7282"
"adi,adv7282-m"
+Optional Endpoint Properties :
+- newavmode: a boolean property to indicate the BT.656 bus is operating
+ in Analog Device's NEWAVMODE. Valid for BT.656 busses only.
+
Example:
i2c0@1c22000 {
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index cb83ebb..3067d5f 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -106,6 +107,7 @@
#define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
#define ADV7180_REG_CTRL_2 0x001d
#define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
+#define ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE 0x02
#define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
#define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
#define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
@@ -214,6 +216,7 @@ struct adv7180_state {
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
v4l2_std_id curr_norm;
+ boolnewavmode;
boolpowered;
boolstreaming;
u8 input;
@@ -864,9 +867,15 @@ static int adv7180_init(struct adv7180_state *state)
if (ret < 0)
return ret;
- /* Manually set V bit end position in NTSC mode */
- return adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
- ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+ if (!state->newavmode) {
+ /* Manually set V bit end position in NTSC mode */
+ ret = adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
+ ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
}
static int adv7180_set_std(struct adv7180_state *state, unsigned int std)
@@ -1217,6 +1226,13 @@ static int init_device(struct adv7180_state *state)
if (ret)
goto out_unlock;
+ if (state->newavmode) {
+ ret = adv7180_write(state, ADV7180_REG_VSYNC_FIELD_CTL_1,
+ ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE);
+ if (ret < 0)
+ goto out_unlock;
+ }
+
ret = adv7180_program_std(state);
if (ret)
goto out_unlock;
@@ -1257,6 +1273,28 @@ out_unlock:
return ret;
}
+static void adv7180_of_parse(struct adv7180_state *state)
+{
+ struct i2c_client *client = state->client;
+ struct device_node *np = client->dev.of_node;
+ struct device_node *endpoint;
+ struct v4l2_of_endpoint ep;
+
+ endpoint = of_graph_get_next_endpoint(np, NULL);
+ if (!endpoint) {
+ v4l_warn(client, "endpoint node not found\n");
+ return;
+ }
+
+ v4l2_of_parse_endpoint(endpoint, &ep);
+ if (ep.bus_type == V4L2_MBUS_BT656) {
+ if (of_property_read_bool(endpoint, "newavmode"))
+ state->newavmode = true;
+ }
+
+ of_node_put(endpoint);
+}
+
static int adv7180_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1279,6 +1317,8 @@ static int adv7180_probe(struct i2c_client *client,
state->field = V4L2_FIELD_INTERLACED;
state->chip_info = (struct adv7180_chip_info *)id->driver_data;
+ adv7180_of_parse(state);
+
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
state->csi_client = i2c_new_dummy(client->adapter,
ADV7180_DEFAULT_CSI_I2C_ADDR);
--
1.9.1
[PATCH v3 2/9] media: adv7180: define more registers
Replace hard-coded addresses with new register macro defines. No
functional changes.
Signed-off-by: Steve Longerbeam
Acked-by: Lars-Peter Clausen
v3: no changes
---
drivers/media/i2c/adv7180.c | 73 ++---
1 file changed, 49 insertions(+), 24 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 95cbc85..cb83ebb 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -56,10 +56,11 @@
#define ADV7182_REG_INPUT_VIDSEL 0x0002
+#define ADV7180_REG_OUTPUT_CONTROL 0x0003
#define ADV7180_REG_EXTENDED_OUTPUT_CONTROL0x0004
#define ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS0xC5
-#define ADV7180_REG_AUTODETECT_ENABLE 0x07
+#define ADV7180_REG_AUTODETECT_ENABLE 0x0007
#define ADV7180_AUTODETECT_DEFAULT 0x7f
/* Contrast */
#define ADV7180_REG_CON0x0008 /*Unsigned */
@@ -100,6 +101,20 @@
#define ADV7180_REG_IDENT 0x0011
#define ADV7180_ID_7180 0x18
+#define ADV7180_REG_STATUS30x0013
+#define ADV7180_REG_ANALOG_CLAMP_CTL 0x0014
+#define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
+#define ADV7180_REG_CTRL_2 0x001d
+#define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
+#define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
+#define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
+#define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
+#define ADV7180_REG_LOCK_CNT 0x0051
+#define ADV7180_REG_CVBS_TRIM 0x0052
+#define ADV7180_REG_CLAMP_ADJ 0x005a
+#define ADV7180_REG_RES_CIR0x005f
+#define ADV7180_REG_DIFF_MODE 0x0060
+
#define ADV7180_REG_ICONF1 0x2040
#define ADV7180_ICONF1_ACTIVE_LOW 0x01
#define ADV7180_ICONF1_PSYNC_ONLY 0x10
@@ -129,9 +144,15 @@
#define ADV7180_REG_VPP_SLAVE_ADDR 0xFD
#define ADV7180_REG_CSI_SLAVE_ADDR 0xFE
-#define ADV7180_REG_FLCONTROL 0x40e0
+#define ADV7180_REG_ACE_CTRL1 0x4080
+#define ADV7180_REG_ACE_CTRL5 0x4084
+#define ADV7180_REG_FLCONTROL 0x40e0
#define ADV7180_FLCONTROL_FL_ENABLE 0x1
+#define ADV7180_REG_RST_CLAMP 0x809c
+#define ADV7180_REG_AGC_ADJ1 0x80b6
+#define ADV7180_REG_AGC_ADJ2 0x80c0
+
#define ADV7180_CSI_REG_PWRDN 0x00
#define ADV7180_CSI_PWRDN 0x80
@@ -886,16 +907,20 @@ static int adv7182_init(struct adv7180_state *state)
/* ADI required writes */
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
- adv7180_write(state, 0x0003, 0x4e);
- adv7180_write(state, 0x0004, 0x57);
- adv7180_write(state, 0x001d, 0xc0);
+ adv7180_write(state, ADV7180_REG_OUTPUT_CONTROL, 0x4e);
+ adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
+ adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
} else {
if (state->chip_info->flags & ADV7180_FLAG_V2)
- adv7180_write(state, 0x0004, 0x17);
+ adv7180_write(state,
+ ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
+ 0x17);
else
- adv7180_write(state, 0x0004, 0x07);
- adv7180_write(state, 0x0003, 0x0c);
- adv7180_write(state, 0x001d, 0x40);
+ adv7180_write(state,
+ ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
+ 0x07);
+ adv7180_write(state, ADV7180_REG_OUTPUT_CONTROL, 0x0c);
+ adv7180_write(state, ADV7180_REG_CTRL_2, 0x40);
}
adv7180_write(state, 0x0013, 0x00);
@@ -972,8 +997,8 @@ static int adv7182_select_input(struct adv7180_state
*state, unsigned int input)
return ret;
/* Reset clamp circuitry - ADI recommended writes */
- adv7180_write(state, 0x809c, 0x00);
- adv7180_write(state, 0x809c, 0xff);
+ adv7180_write(state, ADV7180_REG_RST_CLAMP, 0x00);
+ adv7180_write(state, ADV7180_REG_RST_CLAMP, 0xff);
input_type = adv7182_get_input_type(input);
@@ -981,10 +1006,10 @@ static int adv7182_select_input(struct adv7180_state
*state, unsigned int input)
case ADV7182_INPUT_TYPE_CVBS:
case ADV7182_INPUT_TYPE_DIFF_CVBS:
/* ADI recommends to use the SH1 filter */
- adv7180_write(state, 0x0017, 0x41);
+ adv7180_write(state, ADV7180_REG_SHAP_FILTER_CTL_1, 0x41);
break;
default:
- adv7180_write(state, 0x0017, 0x01);
+ adv7180_write(state, ADV7180_REG_SHAP_FILTER_CTL_1, 0x01);
break;
}
@@ -994,21 +1019,21 @@ static int adv7182_select_input(struct adv7180_state
*state, unsigned int input)
lbias = adv7182_lbias_settings[input_type];
for (i = 0; i <
[PATCH v3 8/9] media: adv7180: enable lock/unlock interrupts
Enable the SD lock/unlock interrupts and send V4L2_EVENT_SRC_CH_LOCK_STATUS
in the interrupt handler on a detected lock/unlock.
Signed-off-by: Steve Longerbeam
---
v3: no changes
v2:
- last version of this patch was based on the old reverted autodetect
code. This version now only enables the interrupt and sends the
event in the interrupt handler.
---
drivers/media/i2c/adv7180.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index ef2a107..6bcc652 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -874,19 +874,29 @@ static const struct v4l2_subdev_ops adv7180_ops = {
static irqreturn_t adv7180_irq(int irq, void *devid)
{
struct adv7180_state *state = devid;
- u8 isr3;
+ u8 isr1, isr3;
mutex_lock(&state->mutex);
+ isr1 = adv7180_read(state, ADV7180_REG_ISR1);
isr3 = adv7180_read(state, ADV7180_REG_ISR3);
/* clear */
+ adv7180_write(state, ADV7180_REG_ICR1, isr1);
adv7180_write(state, ADV7180_REG_ICR3, isr3);
- if (isr3 & ADV7180_IRQ3_AD_CHANGE) {
- static const struct v4l2_event src_ch = {
+ if ((isr3 & ADV7180_IRQ3_AD_CHANGE) ||
+ (isr1 & (ADV7180_IRQ1_LOCK | ADV7180_IRQ1_UNLOCK))) {
+ static struct v4l2_event src_ch = {
.type = V4L2_EVENT_SOURCE_CHANGE,
- .u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
};
+ if (isr3 & ADV7180_IRQ3_AD_CHANGE)
+ src_ch.u.src_change.changes |=
+ V4L2_EVENT_SRC_CH_RESOLUTION;
+
+ if (isr1 & (ADV7180_IRQ1_LOCK | ADV7180_IRQ1_UNLOCK))
+ src_ch.u.src_change.changes |=
+ V4L2_EVENT_SRC_CH_LOCK_STATUS;
+
v4l2_subdev_notify_event(&state->sd, &src_ch);
}
mutex_unlock(&state->mutex);
@@ -1287,7 +1297,9 @@ static int init_device(struct adv7180_state *state)
if (ret < 0)
goto out_unlock;
- ret = adv7180_write(state, ADV7180_REG_IMR1, 0);
+ /* enable lock/unlock interrupts */
+ ret = adv7180_write(state, ADV7180_REG_IMR1,
+ ADV7180_IRQ1_LOCK | ADV7180_IRQ1_UNLOCK);
if (ret < 0)
goto out_unlock;
--
1.9.1
[PATCH v3 7/9] v4l: Add signal lock status to source change events
Add a signal lock status change to the source changes bitmask.
This indicates there was a signal lock or unlock event detected
at the input of a video decoder.
Signed-off-by: Steve Longerbeam
Cc: Mauro Carvalho Chehab
---
v3: no changes
v2: no changes
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 ++--
include/uapi/linux/videodev2.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index c9c3c77..7758ad7 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -233,8 +233,9 @@
This event is triggered when a source parameter change is
detected during runtime by the video device. It can be a
- runtime resolution change triggered by a video decoder or the
- format change happening on an input connector.
+ runtime resolution change or signal lock status change
+ triggered by a video decoder, or the format change happening
+ on an input connector.
This event requires that the id
matches the input index (when used with a video device node)
or the pad index (when used with a subdevice node) from which
@@ -461,6 +462,13 @@
from a video decoder.
+
+ V4L2_EVENT_SRC_CH_LOCK_STATUS
+ 0x0002
+ This event gets triggered when there is a signal lock or
+ unlock detected at the input of a video decoder.
+
+
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 724f43e..08a153f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
};
#define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
+#define V4L2_EVENT_SRC_CH_LOCK_STATUS (1 << 1)
struct v4l2_event_src_change {
__u32 changes;
--
1.9.1
[PATCH v3 9/9] media: adv7180: fix field type
The ADV7180 and ADV7182 transmit whole fields, bottom field followed
by top (or vice-versa, depending on detected video standard). So
for chips that do not have support for explicitly setting the field
mode, set the field mode to SEQ_BT for PAL, and SEQ_TB for NTSC (there
seems to be conflicting info on field order of PAL vs NTSC, so follow
what is in adv7183.c).
Signed-off-by: Steve Longerbeam
---
v3: no changes
v2:
- the init of state->curr_norm in probe needs to be moved up, ahead
of the init of state->field.
---
drivers/media/i2c/adv7180.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 6bcc652..3b8041e 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -718,10 +718,17 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd,
switch (format->format.field) {
case V4L2_FIELD_NONE:
if (!(state->chip_info->flags & ADV7180_FLAG_I2P))
- format->format.field = V4L2_FIELD_INTERLACED;
+ format->format.field =
+ (state->curr_norm & V4L2_STD_525_60) ?
+ V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
break;
default:
- format->format.field = V4L2_FIELD_INTERLACED;
+ if (state->chip_info->flags & ADV7180_FLAG_I2P)
+ format->format.field = V4L2_FIELD_INTERLACED;
+ else
+ format->format.field =
+ (state->curr_norm & V4L2_STD_525_60) ?
+ V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
break;
}
@@ -1365,8 +1372,14 @@ static int adv7180_probe(struct i2c_client *client,
return -ENOMEM;
state->client = client;
- state->field = V4L2_FIELD_INTERLACED;
state->chip_info = (struct adv7180_chip_info *)id->driver_data;
+ state->curr_norm = V4L2_STD_NTSC;
+
+ if (state->chip_info->flags & ADV7180_FLAG_I2P)
+ state->field = V4L2_FIELD_INTERLACED;
+ else
+ state->field = (state->curr_norm & V4L2_STD_525_60) ?
+ V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
adv7180_of_parse(state);
@@ -1396,7 +1409,6 @@ static int adv7180_probe(struct i2c_client *client,
state->irq = client->irq;
mutex_init(&state->mutex);
- state->curr_norm = V4L2_STD_NTSC;
if (state->chip_info->flags & ADV7180_FLAG_RESET_POWERED)
state->powered = true;
else
--
1.9.1
[PATCH v3 1/9] media: adv7180: Fix broken interrupt register access
Access to the interrupt page registers has been broken since at least
commit 3999e5d01da7 ("[media] adv7180: Do implicit register paging").
That commit forgot to add the interrupt page number to the register
defines.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Acked-by: Lars-Peter Clausen
---
v3: no changes
v2: no changes
---
drivers/media/i2c/adv7180.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index b77b0a4..95cbc85 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -100,7 +100,7 @@
#define ADV7180_REG_IDENT 0x0011
#define ADV7180_ID_7180 0x18
-#define ADV7180_REG_ICONF1 0x0040
+#define ADV7180_REG_ICONF1 0x2040
#define ADV7180_ICONF1_ACTIVE_LOW 0x01
#define ADV7180_ICONF1_PSYNC_ONLY 0x10
#define ADV7180_ICONF1_ACTIVE_TO_CLR 0xC0
@@ -113,15 +113,15 @@
#define ADV7180_IRQ1_LOCK 0x01
#define ADV7180_IRQ1_UNLOCK0x02
-#define ADV7180_REG_ISR1 0x0042
-#define ADV7180_REG_ICR1 0x0043
-#define ADV7180_REG_IMR1 0x0044
-#define ADV7180_REG_IMR2 0x0048
+#define ADV7180_REG_ISR1 0x2042
+#define ADV7180_REG_ICR1 0x2043
+#define ADV7180_REG_IMR1 0x2044
+#define ADV7180_REG_IMR2 0x2048
#define ADV7180_IRQ3_AD_CHANGE 0x08
-#define ADV7180_REG_ISR3 0x004A
-#define ADV7180_REG_ICR3 0x004B
-#define ADV7180_REG_IMR3 0x004C
-#define ADV7180_REG_IMR4 0x50
+#define ADV7180_REG_ISR3 0x204A
+#define ADV7180_REG_ICR3 0x204B
+#define ADV7180_REG_IMR3 0x204C
+#define ADV7180_REG_IMR4 0x2050
#define ADV7180_REG_NTSC_V_BIT_END 0x00E6
#define ADV7180_NTSC_V_BIT_END_MANUAL_NVEND0x4F
--
1.9.1
[PATCH v3 5/9] media: adv7180: implement g_parm
Implement g_parm to return the current standard's frame period.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
---
v3: no changes
v2: no changes
---
drivers/media/i2c/adv7180.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 58f4eca..b8a6d94 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -764,6 +764,27 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
return 0;
}
+static int adv7180_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm *a)
+{
+ struct adv7180_state *state = to_state(sd);
+ struct v4l2_captureparm *cparm = &a->parm.capture;
+
+ if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ memset(a, 0, sizeof(*a));
+ a->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ if (state->curr_norm & V4L2_STD_525_60) {
+ cparm->timeperframe.numerator = 1001;
+ cparm->timeperframe.denominator = 3;
+ } else {
+ cparm->timeperframe.numerator = 1;
+ cparm->timeperframe.denominator = 25;
+ }
+
+ return 0;
+}
+
static int adv7180_cropcap(struct v4l2_subdev *sd, struct v4l2_cropcap
*cropcap)
{
struct adv7180_state *state = to_state(sd);
@@ -822,6 +843,7 @@ static int adv7180_subscribe_event(struct v4l2_subdev *sd,
static const struct v4l2_subdev_video_ops adv7180_video_ops = {
.s_std = adv7180_s_std,
.g_std = adv7180_g_std,
+ .g_parm = adv7180_g_parm,
.querystd = adv7180_querystd,
.g_input_status = adv7180_g_input_status,
.s_routing = adv7180_s_routing,
--
1.9.1
[PATCH v3 4/9] media: adv7180: add power pin control
Some targets control the ADV7180 power pin via a gpio, so add
optional support for "powerdown" pin control.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Acked-by: Lars-Peter Clausen
---
v3: no changes
v2:
- placed call to gpiod_get inline in adv7180_probe().
- rename gpio pin to "powerdown".
- document optional powerdown-gpios property in
Documentation/devicetree/bindings/media/i2c/adv7180.txt.
- include error number in error message on gpiod_get failure.
---
.../devicetree/bindings/media/i2c/adv7180.txt | 4
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/adv7180.c| 27 ++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
index 6c175d2..ab9ef02 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
@@ -15,6 +15,10 @@ Required Properties :
"adi,adv7282"
"adi,adv7282-m"
+Optional Properties :
+- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
+ if any.
+
Optional Endpoint Properties :
- newavmode: a boolean property to indicate the BT.656 bus is operating
in Analog Device's NEWAVMODE. Valid for BT.656 busses only.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ce9006e..6769898 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -187,7 +187,7 @@ comment "Video decoders"
config VIDEO_ADV7180
tristate "Analog Devices ADV7180 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
---help---
Support for the Analog Devices ADV7180 video decoder.
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 3067d5f..58f4eca 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -215,6 +216,7 @@ struct adv7180_state {
struct media_padpad;
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
+ struct gpio_desc*pwdn_gpio;
v4l2_std_id curr_norm;
boolnewavmode;
boolpowered;
@@ -466,6 +468,19 @@ static int adv7180_g_std(struct v4l2_subdev *sd,
v4l2_std_id *norm)
return 0;
}
+static void adv7180_set_power_pin(struct adv7180_state *state, bool on)
+{
+ if (!state->pwdn_gpio)
+ return;
+
+ if (on) {
+ gpiod_set_value_cansleep(state->pwdn_gpio, 0);
+ usleep_range(5000, 1);
+ } else {
+ gpiod_set_value_cansleep(state->pwdn_gpio, 1);
+ }
+}
+
static int adv7180_set_power(struct adv7180_state *state, bool on)
{
u8 val;
@@ -1219,6 +1234,8 @@ static int init_device(struct adv7180_state *state)
mutex_lock(&state->mutex);
+ adv7180_set_power_pin(state, true);
+
adv7180_write(state, ADV7180_REG_PWR_MAN, ADV7180_PWR_MAN_RES);
usleep_range(5000, 1);
@@ -1319,6 +1336,14 @@ static int adv7180_probe(struct i2c_client *client,
adv7180_of_parse(state);
+ state->pwdn_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(state->pwdn_gpio)) {
+ ret = PTR_ERR(state->pwdn_gpio);
+ v4l_err(client, "request for power pin failed: %d\n", ret);
+ return ret;
+ }
+
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
state->csi_client = i2c_new_dummy(client->adapter,
ADV7180_DEFAULT_CSI_I2C_ADDR);
@@ -1410,6 +1435,8 @@ static int adv7180_remove(struct i2c_client *client)
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2)
i2c_unregister_device(state->csi_client);
+ adv7180_set_power_pin(state, false);
+
mutex_destroy(&state->mutex);
return 0;
--
1.9.1
[PATCH v3 6/9] media: adv7180: change mbus format to UYVY
Change the media bus format from YUYV8_2X8 to UYVY8_2X8. Colors
now look correct when capturing with the i.mx6 backend.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Acked-by: Lars-Peter Clausen
Acked-by: Niklas Söderlund
---
v3: no changes
v2: no changes
---
drivers/media/i2c/adv7180.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index b8a6d94..ef2a107 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -636,7 +636,7 @@ static int adv7180_enum_mbus_code(struct v4l2_subdev *sd,
if (code->index != 0)
return -EINVAL;
- code->code = MEDIA_BUS_FMT_YUYV8_2X8;
+ code->code = MEDIA_BUS_FMT_UYVY8_2X8;
return 0;
}
@@ -646,7 +646,7 @@ static int adv7180_mbus_fmt(struct v4l2_subdev *sd,
{
struct adv7180_state *state = to_state(sd);
- fmt->code = MEDIA_BUS_FMT_YUYV8_2X8;
+ fmt->code = MEDIA_BUS_FMT_UYVY8_2X8;
fmt->colorspace = V4L2_COLORSPACE_SMPTE170M;
fmt->width = 720;
fmt->height = state->curr_norm & V4L2_STD_525_60 ? 480 : 576;
--
1.9.1
Re: [PATCH] vfs:Fix memory leak on error path in get_empty_file
On Fri, Jul 22, 2016 at 11:47:35AM +0100, Catalin Marinas wrote: > I can't find the original post (probably it only went to the > linux-fsdevel list), so replying to Nicholas here: You couldn't find the original post because there is a *reason* why Nick has been banned from bugzilla.kernel.org, and all of the vger.kernel.org mailing lists. The best thing to do is to just hit the 'D' key when Nick tries to send you a patch personally, and don't reply. It's not worth your time. Many people have tried educating him, and he's apparently beyond education. This includes something as simple as asking him to test his patches before submitting it. - Ted
[PATCH] memory: omap-gpmc: Delete an unnecessary check before the function call "gpiochip_free_own_desc"
From: Markus Elfring Date: Sat, 23 Jul 2016 18:54:02 +0200 The gpiochip_free_own_desc() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/memory/omap-gpmc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 869c83f..e138875 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -2143,9 +2143,7 @@ err_child_fail: ret = -ENODEV; err_cs: - if (waitpin_desc) - gpiochip_free_own_desc(waitpin_desc); - + gpiochip_free_own_desc(waitpin_desc); err: gpmc_cs_free(cs); -- 2.9.2
Re: How to support multiple chips in single driver
On 23 July 2016 17:38:07 BST, Pratik Prajapati wrote: >On Sat, Jul 23, 2016 at 8:37 PM, Jonathan Cameron > wrote: >> >> >> On 23 July 2016 14:36:39 BST, Pratik Prajapati > wrote: >>>Hi, >>> >>>I want to add the threshold, event handling and interrupts support in >>>vcnl4000 driver but those functionalities are not supported in >>>vcnl4000, but supported in vcnl4010 . >>> >>>Do we have an example (IIO driver) of supporting multiple chips in a >>>single driver? >> Lots. E.g. adc\max1636. >I couldn't found max1636 >https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/drivers/iio/adc?h=testing >and https://github.com/torvalds/linux/tree/master/drivers/iio/adc >Or is that adc/max1363? Sorry yes max1363! >-- >To unsubscribe from this list: send the line "unsubscribe linux-iio" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH 12/15] staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<
On Sat, 2016-07-23 at 02:37 -0400, Oleg Drokin wrote: > From: Emoly Liu unrelated trivial notes: > diff --git a/drivers/staging/lustre/lustre/obdecho/echo_internal.h > b/drivers/staging/lustre/lustre/obdecho/echo_internal.h [] > @@ -33,9 +33,9 @@ > > /* The persistent object (i.e. actually stores stuff!) */ > #define ECHO_PERSISTENT_OBJID1ULL > -#define ECHO_PERSISTENT_SIZE ((__u64)(1<<20)) > +#define ECHO_PERSISTENT_SIZE ((__u64)(1 << 20)) This is generally an error-prone pattern as the cast is done after the shift. Perhaps better is using a specific type #define ECHO_PERSISTENT_SIZE(1ULL << 20) And lustre seems to use types with unnecessary __ prefixes.
[PATCH] omapfb: panel-dsi-cm: Delete an unnecessary check before backlight_device_unregister()
From: Markus Elfring Date: Sat, 23 Jul 2016 19:29:28 +0200 The backlight_device_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c index b58012b..9d308db 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c @@ -1283,8 +1283,7 @@ static int dsicm_probe(struct platform_device *pdev) return 0; err_sysfs_create: - if (bldev != NULL) - backlight_device_unregister(bldev); + backlight_device_unregister(bldev); err_bl: destroy_workqueue(ddata->workqueue); err_reg: -- 2.9.2
Re: [PATCH 12/15] staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<
On Jul 23, 2016, at 1:31 PM, Joe Perches wrote: > On Sat, 2016-07-23 at 02:37 -0400, Oleg Drokin wrote: >> From: Emoly Liu > > unrelated trivial notes: > >> diff --git a/drivers/staging/lustre/lustre/obdecho/echo_internal.h >> b/drivers/staging/lustre/lustre/obdecho/echo_internal.h > [] >> @@ -33,9 +33,9 @@ >> >> /* The persistent object (i.e. actually stores stuff!) */ >> #define ECHO_PERSISTENT_OBJID1ULL >> -#define ECHO_PERSISTENT_SIZE ((__u64)(1<<20)) >> +#define ECHO_PERSISTENT_SIZE ((__u64)(1 << 20)) > > This is generally an error-prone pattern as the cast is > done after the shift. Hm, indeed. > Perhaps better is using a specific type > > #define ECHO_PERSISTENT_SIZE (1ULL << 20) Yes, I guess this is a better way. > And lustre seems to use types with unnecessary __ prefixes. Need to see if this file is included in userspace where the __ is needed.
[GIT PULL] KVM bonus fix for 4.7
Linus,
it is possible that you read this pull request before the reverty one
from last Saturday that was asking to pull tags/for-linus ("[GIT PULL]
KVM fixes for 4.7-rc8") and therefore could pull uncommented changes
with this one. I am sorry for the inconvenience.
The following changes since commit b244c9fc251e14a083a1cbf04bef10bd99303a76:
KVM: VMX: handle PML full VMEXIT that occurs during event delivery
(2016-07-16 15:27:40 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-for-4.7-rc8
for you to fetch changes up to 4c47eb1c18c38b755eb4894a6ca38f834de3ec23:
arm64: KVM: VHE: Context switch MDSCR_EL1 (2016-07-23 18:07:12 +0200)
ARM VHE fix (Cc stable) to isolate host's MDSCR_EL1 from a guest.
Marc Zyngier (1):
arm64: KVM: VHE: Context switch MDSCR_EL1
arch/arm64/kvm/hyp/sysreg-sr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
[PATCH] coresight: tmc: Delete an unnecessary check before the function call "kfree"
From: Markus Elfring Date: Sat, 23 Jul 2016 20:04:09 +0200 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/hwtracing/coresight/coresight-tmc-etf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c index e68289b..5fa49c4 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c @@ -168,7 +168,7 @@ out: spin_unlock_irqrestore(&drvdata->spinlock, flags); /* Free memory outside the spinlock if need be */ - if (!used && buf) + if (!used) kfree(buf); if (!ret) -- 2.9.2
Re: [PATCH] mfd: arizona: Remove pointless switch case
Hi all! On Fri, 2016-07-22 at 16:58 +0100, Charles Keepax wrote: [...] > case IRQF_TRIGGER_RISING: > case IRQF_TRIGGER_FALLING: > break; > - > - case IRQ_TYPE_NONE: > default: Don't know about the kernels coding rule in that case but personally, I use that style to explicit list all enum/#define values so that it is obvious that none was forgotten. For the compiler output, it shouldn't matter anyways ... MfG, Bernd -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services
[PATCH] list: Expand list_first_entry_or_null()
Due to the use of READ_ONCE() in list_empty() the compiler cannot
optimise !list_empty() ? list_first_entry() : NULL very well. By
manually expanding list_first_entry_or_null() we can take advantage of
the READ_ONCE() to avoid the list element changing under the test while
the compiler can generate smaller code.
Signed-off-by: Chris Wilson
Cc: "Paul E. McKenney"
Cc: Andrew Morton
Cc: Dan Williams
Cc: Jan Kara
Cc: Josef Bacik
Cc: linux-kernel@vger.kernel.org
---
include/linux/list.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index 5356f4d661a7..7f8b08492cb3 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -381,8 +381,11 @@ static inline void list_splice_tail_init(struct list_head
*list,
*
* Note that if the list is empty, it returns NULL.
*/
-#define list_first_entry_or_null(ptr, type, member) \
- (!list_empty(ptr) ? list_first_entry(ptr, type, member) : NULL)
+#define list_first_entry_or_null(ptr, type, member) ({ \
+ struct list_head *head__ = (ptr); \
+ struct list_head *pos__ = READ_ONCE(head__->next); \
+ pos__ != head__ ? list_entry(pos__, type, member) : NULL; \
+})
/**
* list_next_entry - get the next element in list
--
2.8.1
Re: [RFC PATCH 1/2] mempool: do not consume memory reserves from the reclaim path
On 07/22/2016 09:44 PM, Andrew Morton wrote: > On Fri, 22 Jul 2016 14:26:19 +0200 Vlastimil Babka wrote: > >> On 07/22/2016 08:37 AM, Michal Hocko wrote: >>> On Thu 21-07-16 16:53:09, Michal Hocko wrote: From d64815758c212643cc1750774e2751721685059a Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 21 Jul 2016 16:40:59 +0200 Subject: [PATCH] Revert "mm, mempool: only set __GFP_NOMEMALLOC if there are free elements" This reverts commit f9054c70d28bc214b2857cf8db8269f4f45a5e23. >>> >>> I've noticed that Andrew has already picked this one up. Is anybody >>> against marking it for stable? >> >> It would be strange to have different behavior with known regression in >> 4.6 and 4.7 stables. Actually, there's still time for 4.7 proper? >> > > I added the cc:stable. > > Do we need to bust a gut to rush it into 4.7? It sounds safer to let > it bake for a while, fix it in 4.7.1? Yeah, I guess it's safer to wait now. Would be different if the reverted commit went in the same cycle. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org >
[PATCH] staging: sm750fb: Fix block comment style
This patch fixes the checkpatch.pl warning:
WARNING: Block comments use * on subsequent lines
Signed-off-by: Edward Lipinsky
---
drivers/staging/sm750fb/ddk750_dvi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c
b/drivers/staging/sm750fb/ddk750_dvi.c
index a4a2550..8252f77 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -6,9 +6,11 @@
#include "ddk750_sii164.h"
-/* This global variable contains all the supported driver and its corresponding
- function API. Please set the function pointer to NULL whenever the function
- is not supported. */
+/*
+ * This global variable contains all the supported driver and its corresponding
+ * function API. Please set the function pointer to NULL whenever the function
+ * is not supported.
+ */
static dvi_ctrl_device_t g_dcftSupportedDviController[] = {
#ifdef DVI_CTRL_SII164
{
--
2.7.4
[PATCH] spi: pic32-sqi: fixup wait_for_completion_timeout return handling
wait_for_completion_timeout returns unsigned long not int so the check for
<= 0 should be == 0 here, and the type unsigned long. The function return
is set to -ETIMEDOUT to reflect the actual problem.
Signed-off-by: Nicholas Mc Guire
---
the only call site of pic32_sqi_one_messag() is in
drivers/spi/spi.c:__spi_pump_messages() (via struct spi_master
master->transfer_one_message) which is checking for non-zero
return only so technically -EIO is fine, for consistency this
should probably be -ETIMEDOUT though.
Compile tested with: pic32mzda_defconfig + CONFIG_SPI=y,
CONFIG_SPI_PIC32_SQI=m
Patch is against 4.7.0-rc7 (localversion-next -next-20160719)
drivers/spi/spi-pic32-sqi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-pic32-sqi.c b/drivers/spi/spi-pic32-sqi.c
index ca3c8d9..c41abdd 100644
--- a/drivers/spi/spi-pic32-sqi.c
+++ b/drivers/spi/spi-pic32-sqi.c
@@ -354,6 +354,7 @@ static int pic32_sqi_one_message(struct spi_master *master,
struct spi_transfer *xfer;
struct pic32_sqi *sqi;
int ret = 0, mode;
+ unsigned long timeout;
u32 val;
sqi = spi_master_get_devdata(master);
@@ -419,10 +420,10 @@ static int pic32_sqi_one_message(struct spi_master
*master,
writel(val, sqi->regs + PESQI_BD_CTRL_REG);
/* wait for xfer completion */
- ret = wait_for_completion_timeout(&sqi->xfer_done, 5 * HZ);
- if (ret <= 0) {
+ timeout = wait_for_completion_timeout(&sqi->xfer_done, 5 * HZ);
+ if (timeout == 0) {
dev_err(&sqi->master->dev, "wait timedout/interrupted\n");
- ret = -EIO;
+ ret = -ETIMEDOUT;
msg->status = ret;
} else {
/* success */
--
2.1.4
Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
Hello, On Sat, 23 Jul 2016, Chunhui He wrote: > The neigh system is to reduce ARP traffic, that is good. The problem is it > fails > to handle some coner cases. > > The coner case is (let's forget my case above): > In NUD_DELAY, the neigh system is waiting for a proof of reachablity. If there > is no proof, the neigh system must prove by itself, so goes to NUD_PROBE and > sends request. But when some other part of kernel gives a non-proof by > neigh_update()(STALE is a *hint*, not a proof of reachablity), the neigh > system > will leave NUD_DELAY, and will *"forget"* to prove by itself. So it's > possiable > to send traffic to a non-reachable address. That's definitely wrong, even it > "saves" traffic. > > And the fix is to disallow NUD_DELAY -> NUD_STALE. But NUD_STALE event happens only for received packet, for the concerned remote IP address, for same or different hwaddr, for any kind of tip (target IP). Examples: - Received ARP request who-has LOCAL_IP tell NEIGH_IP: neigh_event_ns is called for the RTN_LOCAL case, for sip/sha. Reply is sent. - Received ARP request who-has UNICAST_IP tell NEIGH_IP: neigh_event_ns is called for the IN_DEV_FORWARD case, for sip/sha, i.e. if we use proxy_arp. Deferred or immediate reply is sent. - Received ARP request who-has UNICAST_IP tell NEIGH_IP: neigh_update is called for existing entry when proxy_arp=0, i.e. request not catched by above case. No reply is sent. - Received Gratuitous ARP request who-has NEIGH_IP tell NEIGH_IP: neigh_update is called for broadcast request when arp_accept=1 or when arp_accept=0 while cache entry exists. No reply is sent. - Received Gratuitous ARP reply NEIGH_IP is-at hwaddr: neigh_update is called for the received broadcast reply This was all for NUD_STALE. There is only one ARP case where NUD_REACHABLE is set, usually in response to our request: - Received unicast reply NEIGH_IP is-at hwaddr - the second non-ARP case for NUD_REACHABLE is from dst_confirm > > Can it learn from our unicast ARP replies that we > > should sent in response to its broadcast probes? Or it > > expects only ARP requests? > > All the broadcast probes I have seen are not "who has ". they are > about > other hosts, so we are not expected to answer. May be that is the problem: we receive such packet, ip_route_input_noref detects that we allow such packet from NEIGH_IP on this interface, tip is not RTN_LOCAL (no ARP reply from us), tip is RTN_UNICAST but proxy_arp is not allowed, so we continue and reach __neigh_lookup which finds the existing cache entry because we talked to GW before that. As this is an ARP request, neigh_update is called with NUD_STALE. No reply is sent because request was not for us but we just learned that NEIGH_IP is alive because it lookups for someone else. This is common to observe with broadcasts, GW lookups for other hosts and has to expose its IP+hwaddr. More difficult to happen with unicast packets, you need hub, not switch, to detect such packets. It is possible that you miss the packet that tries to set NUD_STALE. May be you can add some printk's to catch what kind of packet causes this. This can help too: tcpdump -lnnn -s0 arp and host GW_IP If you see such packet, that is it. Our cache is updated with NUD_STALE. > So I'm not sure if it can learn from ARP reply. See above, received broadcast GARP reply can set NUD_STALE. But the most trivial case of GW exposing its IP while looking for other hosts should be the culprit. It probably happens often, that is why we have no chance to send ARP requests, GW is more ARP-active than us and updates our cache and we are happy. Regards -- Julian Anastasov
Re: [tip:x86/mm] x86/mm/cpa: Fix populate_pgd(): Stop trying to deallocate failed PUDs
* Linus Torvalds wrote: > On Sat, Jul 23, 2016 at 4:46 PM, tip-bot for Andy Lutomirski > wrote: > > > > Fixing this directly is difficult or impossible because of the awful > > state of Linux's page table accessors. > > Quite frankly, this part of the message is misleading and wrong. Fair enough - I amended the commit and pushed out the new version. Thanks, Ingo
[tip:x86/mm] x86/mm/cpa: Fix populate_pgd(): Stop trying to deallocate failed PUDs
Commit-ID: 530dd8d4b9daf77e3e5d145a26210d91ced954c7
Gitweb: http://git.kernel.org/tip/530dd8d4b9daf77e3e5d145a26210d91ced954c7
Author: Andy Lutomirski
AuthorDate: Fri, 22 Jul 2016 21:58:08 -0700
Committer: Ingo Molnar
CommitDate: Sat, 23 Jul 2016 21:13:25 +0200
x86/mm/cpa: Fix populate_pgd(): Stop trying to deallocate failed PUDs
Valdis Kletnieks bisected a boot failure back to this recent commit:
360cb4d15567 ("x86/mm/cpa: In populate_pgd(), don't set the PGD entry until
it's populated")
I broke the case where a PUD table got allocated -- populate_pud()
would wander off a pgd_none entry and get lost. I'm not sure how
this survived my testing.
Fix the original issue in a much simpler way. The problem
was that, if we allocated a PUD table, failed to populate it, and
freed it, another CPU could potentially keep using the PGD entry we
installed (either by copying it via vmalloc_fault or by speculatively
caching it). There's a straightforward fix: simply leave the
top-level entry in place if this happens. This can't waste any
significant amount of memory -- there are at most 256 entries like
this systemwide and, as a practical matter, if we hit this failure
path repeatedly, we're likely to reuse the same page anyway.
For context, this is a reversion with this hunk added in:
if (ret < 0) {
+ /*
+* Leave the PUD page in place in case some other CPU or thread
+* already found it, but remove any useless entries we just
+* added to it.
+*/
- unmap_pgd_range(cpa->pgd, addr,
+ unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
}
This effectively open-codes what the now-deleted unmap_pgd_range()
function used to do except that unmap_pgd_range() used to try to
free the page as well.
Reported-by: Valdis Kletnieks
Signed-off-by: Andy Lutomirski
Cc: Andrew Morton
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Luis R. Rodriguez
Cc: Mike Krinkin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Toshi Kani
Link:
http://lkml.kernel.org/r/21cbc2822aa18aa812c0215f4231dbf5f65afa7f.1469249789.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/mm/pageattr.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 26c93c6..2bc6ea1 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1082,6 +1082,8 @@ static int populate_pgd(struct cpa_data *cpa, unsigned
long addr)
pud = (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK);
if (!pud)
return -1;
+
+ set_pgd(pgd_entry, __pgd(__pa(pud) | _KERNPG_TABLE));
}
pgprot_val(pgprot) &= ~pgprot_val(cpa->mask_clr);
@@ -1089,16 +1091,11 @@ static int populate_pgd(struct cpa_data *cpa, unsigned
long addr)
ret = populate_pud(cpa, addr, pgd_entry, pgprot);
if (ret < 0) {
- if (pud)
- free_page((unsigned long)pud);
unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
}
- if (pud)
- set_pgd(pgd_entry, __pgd(__pa(pud) | _KERNPG_TABLE));
-
cpa->numpages = ret;
return 0;
}
[tip:x86/mm] x86/mm/cpa: Add missing comment in populate_pdg()
Commit-ID: 55920d31f1e3fea06702c74271dd56c4fc9b70ca
Gitweb: http://git.kernel.org/tip/55920d31f1e3fea06702c74271dd56c4fc9b70ca
Author: Andy Lutomirski
AuthorDate: Sat, 23 Jul 2016 09:59:28 -0700
Committer: Ingo Molnar
CommitDate: Sat, 23 Jul 2016 21:17:10 +0200
x86/mm/cpa: Add missing comment in populate_pdg()
In commit:
21cbc2822aa1 ("x86/mm/cpa: Unbreak populate_pgd(): stop trying to deallocate
failed PUDs")
I intended to add this comment, but I failed at using git.
Signed-off-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/242baf8612394f4e31216f96d13c4d2e9b90d1b7.1469293159.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/mm/pageattr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 2bc6ea1..47870a5 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1091,6 +1091,11 @@ static int populate_pgd(struct cpa_data *cpa, unsigned
long addr)
ret = populate_pud(cpa, addr, pgd_entry, pgprot);
if (ret < 0) {
+ /*
+* Leave the PUD page in place in case some other CPU or thread
+* already found it, but remove any useless entries we just
+* added to it.
+*/
unmap_pud_range(pgd_entry, addr,
addr + (cpa->numpages << PAGE_SHIFT));
return ret;
[PATCH] spi: pic32: fixup wait_for_completion_timeout return handling
wait_for_completion_timeout returns unsigned long not int so the check for
<= 0 should be == 0 here.
Signed-off-by: Nicholas Mc Guire
---
API non-compliance was located by coccinelle
Compile tested with: pic32mzda_defconfig + CONFIG_SPI=y,
CONFIG_SPI_PIC32=m
Patch is against 4.7.0-rc7 (localversion-next -next-20160719)
drivers/spi/spi-pic32.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pic32.c b/drivers/spi/spi-pic32.c
index 73db87f..fefb688 100644
--- a/drivers/spi/spi-pic32.c
+++ b/drivers/spi/spi-pic32.c
@@ -507,6 +507,7 @@ static int pic32_spi_one_transfer(struct spi_master *master,
{
struct pic32_spi *pic32s;
bool dma_issued = false;
+ unsigned long timeout;
int ret;
pic32s = spi_master_get_devdata(master);
@@ -553,8 +554,8 @@ static int pic32_spi_one_transfer(struct spi_master *master,
}
/* wait for completion */
- ret = wait_for_completion_timeout(&pic32s->xfer_done, 2 * HZ);
- if (ret <= 0) {
+ timeout = wait_for_completion_timeout(&pic32s->xfer_done, 2 * HZ);
+ if (timeout == 0) {
dev_err(&spi->dev, "wait error/timedout\n");
if (dma_issued) {
dmaengine_terminate_all(master->dma_rx);
--
2.1.4
Re: [PATCH v4 1/2] bpf: Add bpf_probe_write BPF helper to be called in tracers (kprobes)
On Fri, Jul 22, 2016 at 05:05:27PM -0700, Sargun Dhillon wrote:
> It was tested with the tracex7 program on x86-64.
it's my fault to start tracexN tradition that turned out to be
cumbersome, let's not continue it. Instead could you rename it
to something meaningful? Like test_probe_write_user ?
Right now it just prints client's peer address and human needs to
visually verify that probe_write_user actually happened, if you can
convert it into a test it will help a lot.
We were planning to convert all of the samples/bpf/ into tests,
so we can run them continuously.
btw, single patch re-submit will not be picked up. Please always
re-submit the whole patch set together.
> +static const struct bpf_func_proto *bpf_get_probe_write_proto(void) {
> + pr_warn_once("*\n");
> + pr_warn_once("* bpf_probe_write_user: Experimental Feature in use *\n");
> + pr_warn_once("* bpf_probe_write_user: Feature may corrupt memory *\n");
> + pr_warn_once("*\n");
> + pr_notice_ratelimited("bpf_probe_write_user: %s[%d] installing program
> with helper: it may corrupt user memory!",
> + current->comm, task_pid_nr(current));
I thought we were argeeing on single pr_warn_ratelimited without banner ?
The rest looks good.
Thanks!
