Re: [PATCH v3 3/3] ARM: dts: add suspend opp to exynos4412
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Mark 800MHz OPP as a suspend opp for Exynos4412 based
> boards so effectively cpufreq-dt driver behavior w.r.t.
> suspend frequency matches what the old exynos-cpufreq
> driver has been doing.
>
> This patch fixes suspend/resume support on Exynos4412 based
> Trats2 board and reboot hang on Exynos4412 based Odroid U3
> board.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/arm/boot/dts/exynos4412.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index ca0e3c1..294cfe4 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -98,6 +98,7 @@
> opp-hz = /bits/ 64 <8>;
> opp-microvolt = <100>;
> clock-latency-ns = <20>;
> + opp-suspend;
> };
> opp07 {
> opp-hz = /bits/ 64 <9>;
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] cpufreq-dt: add suspend frequency support
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Add suspend frequency support and if needed set it to
> the frequency obtained from the suspend opp (can be defined
> using opp-v2 bindings and is optional). Also implement
> custom suspend method (needed to not error out on platforms
> which don't require suspend frequency).
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/cpufreq/cpufreq-dt.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> +#ifdef CONFIG_PM
> +static int cpufreq_dt_suspend(struct cpufreq_policy *policy)
> +{
> + int ret;
> +
> + if (!policy->suspend_freq) {
> + pr_debug("%s: suspend_freq not defined\n", __func__);
> + return 0;
> + }
> +
> + pr_debug("%s: Setting suspend-freq: %u\n", __func__,
> + policy->suspend_freq);
> +
> + ret = __cpufreq_driver_target(policy, policy->suspend_freq,
> + CPUFREQ_RELATION_H);
> + if (ret)
> + pr_err("%s: unable to set suspend-freq: %u. err: %d\n",
> + __func__, policy->suspend_freq, ret);
> +
> + return ret;
> +}
> +#else
> +#define cpufreq_dt_suspend NULL
> +#endif
No, there is no point replicating the exactly same routine again.
Rather modify cpufreq_generic_suspend() to not print error and instead
do pr_debug(), on !policy->suspend_freq.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] PM / OPP: add dev_pm_opp_get_suspend_opp() helper
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/base/power/opp.c | 28
> include/linux/pm_opp.h | 6 ++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index eb25449..eaafca7 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -341,6 +341,34 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct
> device *dev)
> EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_clock_latency);
>
> /**
> + * dev_pm_opp_get_suspend_opp() - Get suspend opp
> + * @dev: device for which we do this operation
> + *
> + * Return: This function returns pointer to the suspend opp if it is
> + * defined, otherwise it returns NULL.
> + *
> + * Locking: This function takes rcu_read_lock().
> + */
> +struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev)
> +{
> + struct device_opp *dev_opp;
> + struct dev_pm_opp *suspend_opp;
> +
> + rcu_read_lock();
This is wrong. Please have a look at other exported APIs that return
an OPP. RCU protected structures must be accessed from within RCU
locks _ONLY_. But your function returns the pointer after dropping
the locks. Which essentially means that the OPP can be freed by core,
by the time you start using it. :)
So, in such cases, its upto the caller to ensure that locks are taken
properly.
You can look at dev_pm_opp_find_freq_exact() as an example.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mm, compaction: disginguish contended status in tracepoint
On Thu, Aug 27, 2015 at 05:24:04PM +0200, Vlastimil Babka wrote: > Compaction returns prematurely with COMPACT_PARTIAL when contended or has > fatal > signal pending. This is ok for the callers, but might be misleading in the > traces, as the usual reason to return COMPACT_PARTIAL is that we think the > allocation should succeed. This patch distinguishes the premature ending > condition. Further distinguishing the exact reason seems unnecessary for now. isolate_migratepages() could return ISOLATE_ABORT and skip to call compact_finished(). trace_mm_compaction_end() will print COMPACT_PARTIAL in this case and we cannot distinguish premature ending condition. Is it okay? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] staging: slimport: Add anx7814 driver support by analogix.
2015-09-07 1:27 GMT+02:00 Greg KH : > On Sun, Sep 06, 2015 at 11:14:02PM +0200, Enric Balletbo i Serra wrote: >> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter >> designed for portable devices. >> >> This driver adds initial support and supports HDMI to DP pass-through mode. >> >> Signed-off-by: Enric Balletbo i Serra >> --- >> drivers/staging/Kconfig|2 + >> drivers/staging/Makefile |1 + >> drivers/staging/slimport/Kconfig |7 + >> drivers/staging/slimport/Makefile |4 + >> drivers/staging/slimport/slimport.c| 301 +++ >> drivers/staging/slimport/slimport.h| 49 + >> drivers/staging/slimport/slimport_tx_drv.c | 3293 >> >> drivers/staging/slimport/slimport_tx_drv.h | 254 +++ >> drivers/staging/slimport/slimport_tx_reg.h | 786 +++ > > Why is this a staging driver? > What prevents it from being merged into the "real" part of the kernel > tree? > I'll be glad to move the driver to their subsystem if you think it's a the better place. Basically there are two reasons why I send the driver to the staging directory. The first one is because my test environment is a bit limited, with my environment I can only test the HDMI to DisplayPort pass-through mode so the driver builds but it's partially tested. The second one is that I expect I'll need to refactor some code, specially in slimport_tx_drv.c file to be accepted, I decided not change too much this file from the original to not break the functionality, so I thought that will be better send first to the staging driver to have first reviews. > All staging drivers need a TODO file, listing what needs to be done and > who is in charge of it. I can't take this without that added. > ok, I'll add in the next series once received some feedback (or move to the video subsystem) Thanks, Enric > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] soc: mediatek: Move the initial setting of pmic wrap interrupt before requesting irq.
On Fri, Sep 04, 2015 at 12:05:12PM +0800, Henry Chen wrote:
> Seperate the initialization of pmic wrap interrupt from pmic wrap init to
> make sure setting is correct before requesting irq.
It seems the problem this patch solves is the missing watchdog
initialization when the pwrap is already initialized but the watchdog is
not, so how about a commit log like:
"The watchdog may not be initialized by the bootloader, even if the rest
of the pwrap is. Move the watchdog initialization out of pwrap_init()
to make sure the watchdog is always initialized and not only when the
pwrap is uninitialized."
Also please add linebreaks to the commit log.
>
> Signed-off-by: Henry Chen
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
> b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index f432291..c91d629 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -725,10 +725,6 @@ static int pwrap_init(struct pmic_wrapper *wrp)
> pwrap_writel(wrp, 0x1, PWRAP_WACS2_EN);
> pwrap_writel(wrp, 0x5, PWRAP_STAUPD_PRD);
> pwrap_writel(wrp, 0xff, PWRAP_STAUPD_GRPEN);
> - pwrap_writel(wrp, 0xf, PWRAP_WDT_UNIT);
> - pwrap_writel(wrp, 0x, PWRAP_WDT_SRC_EN);
> - pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
> - pwrap_writel(wrp, ~((1 << 31) | (1 << 1)), PWRAP_INT_EN);
>
> if (pwrap_is_mt8135(wrp)) {
> /* enable pwrap events and pwrap bridge in AP side */
> @@ -896,6 +892,16 @@ static int pwrap_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + /*
> + * watch dog@pwrap,
> + * The bootloader may not initial the wdt/interrupt setting of pwrap,
> + * set it before reguesting the irq.
> + */
/* initialize watchdog, may not be done by the bootloader */
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dealing with the NMI mess
On Fri, 31 Jul 2015, Borislav Petkov wrote: > Yeah, INT 1. I wonder whether INT 1, i.e. CD imm8 does the same thing. > > But why do you say it is special - it simply raises #DB, i.e. vector 1. > Web page seems to say so when interrupt redirection is disabled. It > sounds like a nice and quick way to generate a breakpoint. You can do > that with INT 01, i.e., the CD opcode, too. > > If I'd had to guess, it isn't documented because of the proprietary ICE > aspect. And no one uses ICEs anymore so it is going to be forgotten with > people popping off and on and asking about the undocumented opcode. FYI, it's actually still in use with modern hardware, as a software breakpoint (and hence it has to be a single byte INT1 instruction rather than a multiple-byte regular INT 1 encoding) with JTAG probe hardware used for bare-metal debugging. E.g. Intel Atom supports it and boards have been available with a JTAG connector, which Intel calls XDP aka Extended Debug Port, e.g. the D945GCLF board (aka Crown Beach IIRC) had one. By fiddling with some bits in the CPU, which are only accessible through JTAG, probe firmware takes control over #DB making it trap into the debug mode rather than into the kernel. As noted above INT1 is used rather than INT3 (which still traps into the kernel with #BP as usually) for software breakpoints, but all the other DR0-7 resources are also available to the probe and the General Detect fault is used to prevent the kernel from fiddling with them. Similarly single-stepping traps into probe firmware. Debug mode transitions are completely transparent to any kernel-mode software run. I did some work on this a few years ago, including emulating DR0-7 accesses in software down the JTAG handler upon a General Detect fault to keep the kernel both happy and away from real debug registers. ;) Yes, you can debug any software with this stuff, including the Linux kernel: set instruction and data breakpoints, single-step it, poke at all hardware registers, including descriptor registers not otherwise accessible (you can set funny modes for segments, also in the 64-bit mode), etc. One complication though is you operate on physical addresses when poking at memory, you can't ask the CPU's MMU to remap them for you (you can walk page tables manually of course, just as the MMU would). I hope this clears things a bit around this stuff. :) You might be able to find some more by issuing a query for "Extended Debug Port" with your favourite Internet search engine. It's been a while since this discussion, but I thought I'd chime in as you might find it interesting. I'm actually a bit surprised the knowledge about this is so poor among x86 experts. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] mm/compaction: skip useless pfn when updating cached pfn
On Mon, Aug 24, 2015 at 11:07:12AM +0200, Vlastimil Babka wrote:
> On 08/24/2015 04:19 AM, Joonsoo Kim wrote:
> >Cached pfn is used to determine the start position of scanner
> >at next compaction run. Current cached pfn points the skipped pageblock
> >so we uselessly checks whether pageblock is valid for compaction and
> >skip-bit is set or not. If we set scanner's cached pfn to next pfn of
> >skipped pageblock, we don't need to do this check.
> >
> >Signed-off-by: Joonsoo Kim
> >---
> > mm/compaction.c | 13 ++---
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index 6ef2fdf..c2d3d6a 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -261,10 +261,9 @@ void reset_isolation_suitable(pg_data_t *pgdat)
> > */
> > static void update_pageblock_skip(struct compact_control *cc,
> > struct page *page, unsigned long nr_isolated,
> >-bool migrate_scanner)
> >+unsigned long pfn, bool migrate_scanner)
> > {
> > struct zone *zone = cc->zone;
> >-unsigned long pfn;
> >
> > if (cc->ignore_skip_hint)
> > return;
> >@@ -277,8 +276,6 @@ static void update_pageblock_skip(struct compact_control
> >*cc,
> >
> > set_pageblock_skip(page);
> >
> >-pfn = page_to_pfn(page);
> >-
> > /* Update where async and sync compaction should restart */
> > if (migrate_scanner) {
> > if (pfn > zone->compact_cached_migrate_pfn[0])
> >@@ -300,7 +297,7 @@ static inline bool isolation_suitable(struct
> >compact_control *cc,
> >
> > static void update_pageblock_skip(struct compact_control *cc,
> > struct page *page, unsigned long nr_isolated,
> >-bool migrate_scanner)
> >+unsigned long pfn, bool migrate_scanner)
> > {
> > }
> > #endif /* CONFIG_COMPACTION */
> >@@ -509,7 +506,8 @@ isolate_fail:
> >
> > /* Update the pageblock-skip if the whole pageblock was scanned */
> > if (blockpfn == end_pfn)
> >-update_pageblock_skip(cc, valid_page, total_isolated, false);
> >+update_pageblock_skip(cc, valid_page, total_isolated,
> >+end_pfn, false);
>
> In isolate_freepages_block() this means we actually go logically
> *back* one pageblock, as the direction is opposite? I know it's not
> an issue after the redesign patch so you wouldn't notice it when
> testing the whole series. But there's a non-zero chance that the
> smaller fixes are merged first and the redesign later...
Hello, Vlastimil.
Sorry for long delay. I was on vacation. :)
I will fix it next time.
Btw, if possible, could you review the patchset in detail? or do you
have another plan on compaction improvement? Please let me know your
position to determine future plan of this patchset.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] prepare zram for crypto api-powered zcomp
On Tue, Sep 01, 2015 at 11:12:39AM +0900, Sergey Senozhatsky wrote: > On (09/01/15 11:06), Minchan Kim wrote: > > Thanks. > > > > I want to include this patchset in Joonsoo's crypto support patch > > if you don't mind. Hello, Sorry for long delay. I will work crypto support with this patchset. Sergey, I will handle all your comments in next revision. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RT Scheduler - BUG_ON (idx >= MAX_RT_PRIO)
Hello everyone, TL;DR: In Linux RT scheduler, how can rt_nr_running be non-zero AND active-bitmap NOT have any valid bit set? Details: Recently i encountered the following BUG() within the realtime scheduler (sched_rt.c) on 3.1.10 kernel. [101640.492840] kernel BUG at kernel/sched_rt.c:1126! This turns out to be 1126 BUG_ON(idx >= MAX_RT_PRIO); within the function pick_next_rt_entity() as shown here: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/sched_rt.c?h=linux-3.1.y#n1115 What this means is that the scheduler failed to find a valid bit within the bitmap containing a prioritised list of active tasks. However before attempting to parse the bitmap, there is a check for a non-zero rt_nr_running. (i.e. parsing the bitmap should find atleast 1 bit of the active running rt task) So how could rt_nr_running be non-zero AND active-bitmap NOT have any valid bit set? The issue is observed on - a quad-core Cortex A9 SMP embedded system. - running an userspace app with ~25 RT threads (FIFO and RR) - typical ubuntu-core rootfs This issue consistently reproduces within 24-48hours on continuously running the system. Searching the net/lkml i could not find this issue reported before, though there are a few memory corruption bugs in scheduler. I have already backported the patches to fix know memory corruption issue from upstream kernel version and still encounter the above BUG(). Is anyone aware of this issue? Also including the kernel OOPS below. Do you see any tell-tale signs in the register-dump/backtrace that can point me in the right direction? [101640.488133] [ cut here ] [101640.492840] kernel BUG at kernel/sched_rt.c:1126! [101640.497621] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP [101640.504742] Modules linked in: misc_arz(P) audio_sta3_2(P) audio_sta3_1(P) audio_sta3(P) lamp_tlc8116_2(P) lamp_tlc8116_1(P) lamp_tlc8116(P) i2c_master_pcu9669(P) tegra_gpio_helper(P) outport_timer(P) intTimer(P) nvidia(P) [101640.524618] CPU: 0Tainted: P (3.1.10 #1) [101640.530015] PC is at pick_next_task_rt+0x138/0x140 [101640.534888] LR is at __schedule+0x63c/0x858 [101640.539150] pc : []lr : []psr: 200f0093 [101640.539154] sp : e2d7fcc8 ip : e2d7fce8 fp : e2d7fce4 [101640.550785] r10: c05a4e60 r9 : e21f6d4c r8 : c05c8ab0 [101640.556084] r7 : e2d7e000 r6 : 0001 r5 : c186fe60 r4 : c043f928 [101640.562685] r3 : c186ff60 r2 : 0064 r1 : fff0 r0 : c186fe60 [101640.569288] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [101640.576582] Control: 10c5387d Table: a335804a DAC: 0015 [101640.582400] [101640.582403] PC: 0xc0042880: [101640.586839] 2880 eaeb e5932008 e352 0a15 e2621000 e0012002 e16f2f12 e262205f [101640.595143] 28a0 eae3 e30034b8 e2406f5a e18320d5 e356 e1c625f8 0ac9 e2854d11 [101640.603449] 28c0 e2800070 e2844008 e1a01004 eb06b771 e5953448 e1a6 e0534004 13a04001 [101640.611753] 28e0 e58544d4 e89da878 e593200c e2621000 e0012002 e16f2f12 e262207f eacc [101640.620057] 2900 e7f001f2 e7f001f2 e1a0c00d e92ddff0 e24cb004 e24dd01c e2914038 e1a08002 [101640.628361] 2920 0a74 e5913054 e353 1a68 e30ba720 e3a09e4b e34ca05e e50ba038 [101640.636665] 2940 e2083005 e5945124 e3530001 0a04 e1c423d0 e1c501d8 e0922000 e0a33001 [101640.644969] 2960 e1c423f0 e1a5 ebffee88 e3a01000 e1a5 ebfff0b7 e5943000 e3a01000 [101640.653276] [101640.653278] LR: 0xc0435110: [101640.657713] 5110 e1932f9f e2822001 e1831f92 e331 1afa ea5d e1a8 eb000947 [101640.666017] 5130 e51b004c eb0009bc e1a8 eb0009ba eade e1a8 e1a01009 e3a02001 [101640.674323] 5150 ebf032e2 eadf e59f3248 e1a08007 e51ba070 e1a07006 e1a06005 e1a05004 [101640.682627] 5170 e1a04003 ea02 e5944000 e354 0a86 e5943018 e1a5 e12fff33 [101640.690931] 5190 e350 0af7 e1a04005 e50ba070 e1a05006 e1a0a000 e1a06007 e1a07008 [101640.699235] 51b0 eafffeb5 e1a4 eb0008fc ea48 e3000518 e3071ff4 e18420d0 e3a00e4b [101640.707539] 51d0 e34c105c e591104c e14b26fc e18420d0 e1a1 e3a01000 e14b23fc e3083080 [101640.715845] 51f0 e34c305a e50b304c e593c000 e14b26dc e1530001 0152 e14b03dc e3a03e51 [101640.724152] [101640.724154] SP: 0xe2d7fc48: [101640.728589] fc48 e21f6aa0 2c5bae94 e2d7fc74 e2d7fc68 c0042904 200f0093 [101640.736893] fc68 c000e394 e2d7fce4 e2d7fc80 c000e0c8 c00081a0 c186fe60 fff0 [101640.745197] fc88 0064 c186ff60 c043f928 c186fe60 0001 e2d7e000 c05c8ab0 e21f6d4c [101640.753501] fca8 c05a4e60 e2d7fce4 e2d7fce8 e2d7fcc8 c0435190 c0042900 200f0093 [101640.761807] fcc8 c00427c8 c043f928 c186fe60 e21f6aa0 e2d7fd64 e2d7fce8 c0435190 c00427d4 [101640.770111] fce8 e39de688 0031 0001 c05a4e60 00062904 e2d7fd54 e2d7fd10 [101640.778415] fd08 c00404f0 c003e308 c05a4e60 c05a4e60 c05a8080 5c71 c05a40c4 c05a4e60 [101640.786721] fd28
how to check how much data left to sync to disk at umount?
When umount a slow device such as an SD card, the command will take a while to run depending on how much data is left to write to the device. Is there way to check how much data is remaining waiting to write to the device? Thanks, Jeff. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] sched/numa: Convert sched_numa_balancing to a static_branch
On 9/7/15 12:10 PM, Srikar Dronamraju wrote: * Wanpeng Li [2015-09-06 12:01:10]: Hi Wanpeng Li, Hi Srikar, On 8/12/15 12:24 AM, Srikar Dronamraju wrote: Variable sched_numa_balancing toggles numa_balancing feature. Hence moving from a simple read mostly variable to a more apt static_branch. Suggested-by: Peter Zijlstra Signed-off-by: Srikar Dronamraju This commit breaks Peter's queue: kernel/sched/fair.c: In function ?task_numa_fault?: kernel/sched/fair.c:2072: error: implicit declaration of function ?static_branch_likely? kernel/sched/fair.c: In function ?task_tick_fair?: kernel/sched/fair.c:7867: error: implicit declaration of function ?static_branch_unlikely? make[1]: *** [kernel/sched/fair.o] Error 1 make[1]: *** Waiting for unfinished jobs kernel/sched/core.c:2116: warning: data definition has no type or storage class Thanks for reporting. Can you please confirm if you have the commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=11276d5306b8e5b438a36bbff855fe792d7eaa61 It seems that the sched/core branch of Peterz's queue doesn't include this commit. So your patch should be good. Regards, Wanpeng Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/2] perf,kvm/powerpc: Add kvm_perf.h for powerpc
On Fri, 2015-09-04 at 17:51 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 01, 2015 at 12:18:47PM +0530, Hemant Kumar escreveu: > > >Should I try to process the 5 together, applying thest two first? > > > Yes, this patchset needs to be applied before applying the other patchset, > > since there is a direct dependency on these two for the tooling part to > > work. > > > >I see there are no acks from powerpc arch maintainers, how should we > > >proceed here? If there are no problems with the arch bits, and if it is > > >just to enable the tooling part, again, should I process the 5 as just > > >one series? > > > The reason to split the earlier patchset into two was to separate the > > tooling/perf/ and arch/powerpc/ side patches, as asked by Michael.. > > > Here is the link to that discussion : > > http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg86916.html > > > If Michael is ok with the patches, you can process all the 5 patches > > together. Michael? > > Michael? I'm not particularly happy with it. Can we at least remove this hunk from the uapi header: +/* This is to shut the compiler up */ +#define KVM_ENTRY_TRACE "" +#define KVM_EXIT_TRACE "" +#define KVM_EXIT_REASON "" cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 1/7] mm: drop page->slab_page
On 09/03/2015 05:35 AM, Kirill A. Shutemov wrote:
Since 8456a648cf44 ("slab: use struct page for slab management") nobody
uses slab_page field in struct page.
Let's drop it.
Signed-off-by: Kirill A. Shutemov
Acked-by: Christoph Lameter
Acked-by: David Rientjes
Acked-by: Vlastimil Babka
Cc: Joonsoo Kim
Cc: Andi Kleen
---
include/linux/mm_types.h | 1 -
mm/slab.c| 17 +++--
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 0038ac7466fd..58620ac7f15c 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -140,7 +140,6 @@ struct page {
#endif
};
- struct slab *slab_page; /* slab fields */
struct rcu_head rcu_head; /* Used by SLAB
* when destroying via RCU
*/
diff --git a/mm/slab.c b/mm/slab.c
index 200e22412a16..649044f26e5d 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1888,21 +1888,10 @@ static void slab_destroy(struct kmem_cache *cachep,
struct page *page)
freelist = page->freelist;
slab_destroy_debugcheck(cachep, page);
- if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU)) {
- struct rcu_head *head;
-
- /*
-* RCU free overloads the RCU head over the LRU.
-* slab_page has been overloeaded over the LRU,
-* however it is not used from now on so that
-* we can use it safely.
-*/
- head = (void *)>rcu_head;
- call_rcu(head, kmem_rcu_free);
-
- } else {
+ if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU))
+ call_rcu(>rcu_head, kmem_rcu_free);
+ else
kmem_freepages(cachep, page);
- }
/*
* From now on, we don't use freelist
This second piece looks like it belongs in patch 2, not patch 1 based on
the descriptions.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 4/4] iio: chemical: add SGX VZ89x VOC sensor support
Thinking this over do we needed a IIO_CHAN_INFO_PROCESSED_OFFSET to signal that it needs to be after the (value - offset) * scale calculation? Thanks, Matt On Sun, Sep 6, 2015 at 9:20 PM, Matt Ranostay wrote: > Also one thing to note here is calculation is ((value - 13) * scale)) > + offset versus the normal (value + offset) * scale.. Not sure the > best way to handle this possibly could be.. > > Thanks, > > Matt > > On Sun, Sep 6, 2015 at 8:13 PM, George McCollister > wrote: >> >> >> On Sun, Sep 6, 2015 at 9:39 PM, Matt Ranostay wrote: >>> >>> Add support for VZ89X sensors VOC and CO2 reporting channels in >>> percentage which can be converted to part per million. >>> >>> Signed-off-by: Matt Ranostay >>> --- >>> .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 30 +++ >>> .../devicetree/bindings/i2c/trivial-devices.txt| 1 + >>> drivers/iio/Kconfig| 1 + >>> drivers/iio/Makefile | 1 + >>> drivers/iio/chemical/Makefile | 6 + >>> drivers/iio/chemical/vz89x.c | 236 >>> + >>> 6 files changed, 275 insertions(+) >>> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >>> create mode 100644 drivers/iio/chemical/Makefile >>> create mode 100644 drivers/iio/chemical/vz89x.c >>> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >>> b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >>> new file mode 100644 >>> index 000..74f2a35 >>> --- /dev/null >>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >>> @@ -0,0 +1,30 @@ >>> +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_CO2_raw >>> +Date: September 2015 >>> +KernelVersion: 4.3 >>> +Contact: Matt Ranostay >>> +Description: >>> + Get the unscaled, and no offset applied CO2 gas percentage >>> + value. >>> + >>> +What: >>> /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw >>> +Date: September 2015 >>> +KernelVersion: 4.3 >>> +Contact: Matt Ranostay >>> +Description: >>> + Get the raw calibration VOC value from the sensor. >>> + This value has little application outside of calibration. >>> + >>> +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_tVOC_raw >>> +Date: September 2015 >>> +KernelVersion: 4.3 >>> +Contact: Matt Ranostay >>> +Description: >>> + Get the unscaled, and no offset applied total VOC gas >>> + percentage value. >>> + >>> +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw >>> +Date: September 2015 >>> +KernelVersion: 4.3 >>> +Contact: Matt Ranostay >>> +Description: >>> + Get the unscaled sensor resistance value. >>> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt >>> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >>> index d77d412..a550216 100644 >>> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt >>> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >>> @@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE >>> REAL-TIME CLOCK IC >>> ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC >>> ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC >>> samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low >>> Power) >>> +sgx,vz89x SGX Sensortech VZ89X Sensors >>> sii,s35390a2-wire CMOS real-time clock >>> skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver >>> with Touch Panel Bias Supply >>> st-micro,24c256i2c serial eeprom (24cxx) >>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig >>> index 4011eff..9664e9c 100644 >>> --- a/drivers/iio/Kconfig >>> +++ b/drivers/iio/Kconfig >>> @@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER >>> source "drivers/iio/accel/Kconfig" >>> source "drivers/iio/adc/Kconfig" >>> source "drivers/iio/amplifiers/Kconfig" >>> +source "drivers/iio/chemical/Kconfig" >>> source "drivers/iio/common/Kconfig" >>> source "drivers/iio/dac/Kconfig" >>> source "drivers/iio/frequency/Kconfig" >>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile >>> index 698afc2..2288684 100644 >>> --- a/drivers/iio/Makefile >>> +++ b/drivers/iio/Makefile >>> @@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o >>> obj-y += accel/ >>> obj-y += adc/ >>> obj-y += amplifiers/ >>> +obj-y += chemical/ >>> obj-y += common/ >>> obj-y += dac/ >>> obj-y += gyro/ >>> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile >>> new file mode 100644 >>> index 000..7292f2d >>> --- /dev/null >>> +++ b/drivers/iio/chemical/Makefile >>> @@ -0,0 +1,6 @@ >>> +# >>> +# Makefile for IIO chemical sensors >>> +# >>> + >>> +# When adding new entries keep the list in alphabetical order >>>
[PATCH V4 2/2] watchdog: Read device status through sysfs attributes
This patch adds following attributes to watchdog device's sysfs interface
to read its different status.
* state - reads whether device is active or not
* identity - reads Watchdog device's identity string.
* timeout - reads current timeout.
* timeleft - reads timeleft before watchdog generates a reset
* bootstatus - reads status of the watchdog device at boot
* status - reads watchdog device's internal status bits
* nowayout - reads whether nowayout feature was set or not
Testing with iTCO_wdt:
# cd /sys/class/watchdog/watchdog1/
# ls
bootstatus dev device identity nowayout power state
subsystem timeleft timeout uevent
# cat identity
iTCO_wdt
# cat timeout
30
# cat state
inactive
# echo > /dev/watchdog1
# cat timeleft
26
# cat state
active
# cat bootstatus
0
# cat nowayout
0
Signed-off-by: Pratyush Anand
Reviewed-by: Guenter Roeck
---
Documentation/ABI/testing/sysfs-class-watchdog | 51
drivers/watchdog/watchdog_core.c | 2 +-
drivers/watchdog/watchdog_dev.c| 110 +
3 files changed, 162 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-watchdog
diff --git a/Documentation/ABI/testing/sysfs-class-watchdog
b/Documentation/ABI/testing/sysfs-class-watchdog
new file mode 100644
index ..736046b33040
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-watchdog
@@ -0,0 +1,51 @@
+What: /sys/class/watchdog/watchdogn/bootstatus
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains status of the watchdog
+ device at boot. It is equivalent to WDIOC_GETBOOTSTATUS of
+ ioctl interface.
+
+What: /sys/class/watchdog/watchdogn/identity
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains identity string of
+ watchdog device.
+
+What: /sys/class/watchdog/watchdogn/nowayout
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. While reading, it gives '1' if that
+ device supports nowayout feature else, it gives '0'.
+
+What: /sys/class/watchdog/watchdogn/state
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It gives active/inactive status of
+ watchdog device.
+
+What: /sys/class/watchdog/watchdogn/status
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains watchdog device's
+ internal status bits. It is equivalent to WDIOC_GETSTATUS
+ of ioctl interface.
+
+What: /sys/class/watchdog/watchdogn/timeleft
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains value of time left for
+ reset generation. It is equivalent to WDIOC_GETTIMELEFT of
+ ioctl interface.
+
+What: /sys/class/watchdog/watchdogn/timeout
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It is read to know about current
+ value of timeout programmed.
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 47d38c5c3f9a..62666f021762 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -183,7 +183,7 @@ static int __watchdog_register_device(struct
watchdog_device *wdd)
devno = wdd->cdev.dev;
wdd->dev = device_create(watchdog_class, wdd->parent, devno,
- NULL, "watchdog%d", wdd->id);
+ wdd, "watchdog%d", wdd->id);
if (IS_ERR(wdd->dev)) {
watchdog_dev_unregister(wdd);
ida_simple_remove(_ida, id);
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 986282d44b90..2b8d7f1c9599 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -248,6 +248,115 @@ out_timeleft:
return err;
}
+static ssize_t nowayout_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct watchdog_device *wdd = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", !!test_bit(WDOG_NO_WAY_OUT, >status));
+}
+static DEVICE_ATTR_RO(nowayout);
+
+static ssize_t status_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct watchdog_device *wdd = dev_get_drvdata(dev);
+ ssize_t status;
+ unsigned int val;
+
+ status = watchdog_get_status(wdd, );
+ if (!status)
+ status = sprintf(buf, "%u\n", val);
+
+ return status;
+}
+static
[PATCH V4 1/2] watchdog: Use static struct class watchdog_class in stead of pointer
We need few sysfs attributes to know different status of a watchdog device.
To do that, we need to associate .dev_groups with watchdog_class. So
convert it from pointer to static.
Putting this static struct in watchdog_dev.c, so that static device
attributes defined in that file can be attached to it.
Signed-off-by: Pratyush Anand
Suggested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
drivers/watchdog/watchdog_core.c | 15 ++-
drivers/watchdog/watchdog_core.h | 2 +-
drivers/watchdog/watchdog_dev.c | 26 ++
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 1a8059455413..47d38c5c3f9a 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -274,19 +274,9 @@ static int __init watchdog_deferred_registration(void)
static int __init watchdog_init(void)
{
- int err;
-
- watchdog_class = class_create(THIS_MODULE, "watchdog");
- if (IS_ERR(watchdog_class)) {
- pr_err("couldn't create class\n");
+ watchdog_class = watchdog_dev_init();
+ if (IS_ERR(watchdog_class))
return PTR_ERR(watchdog_class);
- }
-
- err = watchdog_dev_init();
- if (err < 0) {
- class_destroy(watchdog_class);
- return err;
- }
watchdog_deferred_registration();
return 0;
@@ -295,7 +285,6 @@ static int __init watchdog_init(void)
static void __exit watchdog_exit(void)
{
watchdog_dev_exit();
- class_destroy(watchdog_class);
ida_destroy(_ida);
}
diff --git a/drivers/watchdog/watchdog_core.h b/drivers/watchdog/watchdog_core.h
index 6c951418fca7..1c8d6b0e68c7 100644
--- a/drivers/watchdog/watchdog_core.h
+++ b/drivers/watchdog/watchdog_core.h
@@ -33,5 +33,5 @@
*/
extern int watchdog_dev_register(struct watchdog_device *);
extern int watchdog_dev_unregister(struct watchdog_device *);
-extern int __init watchdog_dev_init(void);
+extern struct class * __init watchdog_dev_init(void);
extern void __exit watchdog_dev_exit(void);
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefbad303e..986282d44b90 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -578,18 +578,35 @@ int watchdog_dev_unregister(struct watchdog_device
*watchdog)
return 0;
}
+static struct class watchdog_class = {
+ .name = "watchdog",
+ .owner =THIS_MODULE,
+};
+
/*
* watchdog_dev_init: init dev part of watchdog core
*
* Allocate a range of chardev nodes to use for watchdog devices
*/
-int __init watchdog_dev_init(void)
+struct class * __init watchdog_dev_init(void)
{
- int err = alloc_chrdev_region(_devt, 0, MAX_DOGS, "watchdog");
- if (err < 0)
+ int err;
+
+ err = class_register(_class);
+ if (err < 0) {
+ pr_err("couldn't register class\n");
+ return ERR_PTR(err);
+ }
+
+ err = alloc_chrdev_region(_devt, 0, MAX_DOGS, "watchdog");
+ if (err < 0) {
pr_err("watchdog: unable to allocate char dev region\n");
- return err;
+ class_unregister(_class);
+ return ERR_PTR(err);
+ }
+
+ return _class;
}
/*
@@ -601,4 +618,5 @@ int __init watchdog_dev_init(void)
void __exit watchdog_dev_exit(void)
{
unregister_chrdev_region(watchdog_devt, MAX_DOGS);
+ class_unregister(_class);
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CMA: fix CONFIG_CMA_SIZE_MBYTES overflow in 64bit
In 64bit system, if you set CONFIG_CMA_SIZE_MBYTES>=2048, it will overflow and size_bytes will be a big wrong number. Set CONFIG_CMA_SIZE_MBYTES=2048 and you will get an info below during system boot: * cma: Failed to reserve 17592186042368 MiB * Signed-off-by: Tan Xiaojun --- drivers/base/dma-contiguous.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c index 950fff9..426ba27 100644 --- a/drivers/base/dma-contiguous.c +++ b/drivers/base/dma-contiguous.c @@ -46,7 +46,7 @@ struct cma *dma_contiguous_default_area; * Users, who want to set the size of global CMA area for their system * should use cma= kernel parameter. */ -static const phys_addr_t size_bytes = CMA_SIZE_MBYTES * SZ_1M; +static const phys_addr_t size_bytes = (phys_addr_t)CMA_SIZE_MBYTES * SZ_1M; static phys_addr_t size_cmdline = -1; static phys_addr_t base_cmdline; static phys_addr_t limit_cmdline; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 4/4] iio: chemical: add SGX VZ89x VOC sensor support
Also one thing to note here is calculation is ((value - 13) * scale)) + offset versus the normal (value + offset) * scale.. Not sure the best way to handle this possibly could be.. Thanks, Matt On Sun, Sep 6, 2015 at 8:13 PM, George McCollister wrote: > > > On Sun, Sep 6, 2015 at 9:39 PM, Matt Ranostay wrote: >> >> Add support for VZ89X sensors VOC and CO2 reporting channels in >> percentage which can be converted to part per million. >> >> Signed-off-by: Matt Ranostay >> --- >> .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 30 +++ >> .../devicetree/bindings/i2c/trivial-devices.txt| 1 + >> drivers/iio/Kconfig| 1 + >> drivers/iio/Makefile | 1 + >> drivers/iio/chemical/Makefile | 6 + >> drivers/iio/chemical/vz89x.c | 236 >> + >> 6 files changed, 275 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >> create mode 100644 drivers/iio/chemical/Makefile >> create mode 100644 drivers/iio/chemical/vz89x.c >> >> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >> b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >> new file mode 100644 >> index 000..74f2a35 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x >> @@ -0,0 +1,30 @@ >> +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_CO2_raw >> +Date: September 2015 >> +KernelVersion: 4.3 >> +Contact: Matt Ranostay >> +Description: >> + Get the unscaled, and no offset applied CO2 gas percentage >> + value. >> + >> +What: >> /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw >> +Date: September 2015 >> +KernelVersion: 4.3 >> +Contact: Matt Ranostay >> +Description: >> + Get the raw calibration VOC value from the sensor. >> + This value has little application outside of calibration. >> + >> +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_tVOC_raw >> +Date: September 2015 >> +KernelVersion: 4.3 >> +Contact: Matt Ranostay >> +Description: >> + Get the unscaled, and no offset applied total VOC gas >> + percentage value. >> + >> +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw >> +Date: September 2015 >> +KernelVersion: 4.3 >> +Contact: Matt Ranostay >> +Description: >> + Get the unscaled sensor resistance value. >> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> index d77d412..a550216 100644 >> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> @@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE >> REAL-TIME CLOCK IC >> ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC >> ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC >> samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low >> Power) >> +sgx,vz89x SGX Sensortech VZ89X Sensors >> sii,s35390a2-wire CMOS real-time clock >> skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver >> with Touch Panel Bias Supply >> st-micro,24c256i2c serial eeprom (24cxx) >> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig >> index 4011eff..9664e9c 100644 >> --- a/drivers/iio/Kconfig >> +++ b/drivers/iio/Kconfig >> @@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER >> source "drivers/iio/accel/Kconfig" >> source "drivers/iio/adc/Kconfig" >> source "drivers/iio/amplifiers/Kconfig" >> +source "drivers/iio/chemical/Kconfig" >> source "drivers/iio/common/Kconfig" >> source "drivers/iio/dac/Kconfig" >> source "drivers/iio/frequency/Kconfig" >> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile >> index 698afc2..2288684 100644 >> --- a/drivers/iio/Makefile >> +++ b/drivers/iio/Makefile >> @@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o >> obj-y += accel/ >> obj-y += adc/ >> obj-y += amplifiers/ >> +obj-y += chemical/ >> obj-y += common/ >> obj-y += dac/ >> obj-y += gyro/ >> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile >> new file mode 100644 >> index 000..7292f2d >> --- /dev/null >> +++ b/drivers/iio/chemical/Makefile >> @@ -0,0 +1,6 @@ >> +# >> +# Makefile for IIO chemical sensors >> +# >> + >> +# When adding new entries keep the list in alphabetical order >> +obj-$(CONFIG_VZ89X)+= vz89x.o >> diff --git a/drivers/iio/chemical/vz89x.c b/drivers/iio/chemical/vz89x.c >> new file mode 100644 >> index 000..ac381cc >> --- /dev/null >> +++ b/drivers/iio/chemical/vz89x.c >> @@ -0,0 +1,236 @@ >> +/* >> + * vz89x.c - Support for SGX Sensortech MiCS VZ89X VOC sensors >> + * >> + * Copyright (C)
Re: [PATCH 01/11] ARM64 / PCI: introduce struct pci_controller for ACPI
Hi Hanjun, On Wed, May 27, 2015 at 1:51 PM, Hanjun Guo wrote: > Hi Liviu, > > On 2015年05月27日 01:20, Jiang Liu wrote: >> >> On 2015/5/27 0:58, Liviu Dudau wrote: >>> >>> On Tue, May 26, 2015 at 01:49:14PM +0100, Hanjun Guo wrote: ARM64 ACPI based PCI host bridge init needs a arch dependent struct pci_controller to accommodate common PCI host bridge code which is introduced later, or it will lead to compile errors on ARM64. >>> >>> >>> Hi Hanjun, >>> >>> Two questions: why don't you introduce this patch next to the >>> one that is going to make use of it (or even merge it there)? > > > this is because of this patch is needed by Jiang Liu's patch set > to fix the compile error on ARM64, I'd rather do that, but It's > better to let Jiang Liu's patch goes in, and then this one, that's > why I prepared a single patch for the struct. (I mentioned it > in the cover letter) > >>> Second, why is the whole struct pci_controller not surrounded >>> by #ifdef CONFIG_ACPI as you are implying that this is needed >>> only for ACPI? > > > I hope it can be reused, since the NUMA node and segment (domain) > is both needed for DT and ACPI, if it's not the case foe now, I > can surrounded them all by #ifdef CONFIG_ACPI. we can make use of this structure to hold pci to numa node mapping(pcibus_to_node). can you please pull node member out of CONFIG_ACPI ifdef. or you can put only acpi_device under ifdef. > >>> >>> Btw, looking through the whole series I'm not (yet) convinced >>> that this is needed at all. >> >> Hi Liviu, >> This structure is required by the requested patch set >> at http://patchwork.ozlabs.org/patch/472249/, which consolidates >> the common code to support PCI host bridge into ACPI core. > > > Jiang, thanks for the explanation :) > > Thanks > Hanjun thanks Ganapat > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] net: irda: pxaficp_ir: dmaengine conversion
Dne 3.9.2015 v 08:20 Robert Jarzmik napsal(a): > Hi, > > This serie aims at converting pxaficp_ir to dmaengine. This is almost the last > driver to be converted, and once this is gone, legacy DMA support in pxa > architecture can be gone. > > Nothing fancy here, standard readl/writel conversion, then dmaengine support. > > The main trouble is that I cannot test it, I only compiled and inserted the > module, which works on lubbock, but I have no way to make a communcation try. > > Petr, Dmitry, once the review is advanced enough, ie. in a couple of weeks, do > you have a way to test it on corgi/magician if I give you a git tree to pull > from ? > > Cheers > > -- > Robert > > Robert Jarzmik (3): > net: irda: pxaficp_ir: use sched_clock() for time management > net: irda: pxaficp_ir: convert to readl and writel > net: irda: pxaficp_ir: dmaengine conversion > > drivers/net/irda/pxaficp_ir.c | 366 > +++--- > 1 file changed, 233 insertions(+), 133 deletions(-) > Hi, I will test it this week. OT: (hw verified) Magician sadly does not support FIR (only SIR transceiver module) :-( . Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCIe: SPEAr13xx: fix dw_pcie_cfg_read/write() usage
dw_pcie_cfg_read/write() expects 1st argument 'addr' as a 32 bit word
aligned address, 2nd argument 'where' as the offset within that word(0, 1,
2 or 3) and 3rd argument 'size' is the number of bytes need to be read at
the offset(could be 1, 2 ,4).
SPEAr13xx is using dw_pcie_cfg_read() and dw_pcie_cfg_write() incorrectly.
Without this fix, SPEAr13xx host will never work with few buggy gen1 card
which connects with only gen1 host and also with any endpoint which would
generate a read request of more than 128 bytes.
Cc: sta...@vger.kernel.org # v3.17+
Signed-off-by: Pratyush Anand
Reported-by: Bjorn Helgaas
---
drivers/pci/host/pcie-spear13xx.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/host/pcie-spear13xx.c
b/drivers/pci/host/pcie-spear13xx.c
index c49fbdc0f6e4..40862681f010 100644
--- a/drivers/pci/host/pcie-spear13xx.c
+++ b/drivers/pci/host/pcie-spear13xx.c
@@ -163,34 +163,36 @@ static int spear13xx_pcie_establish_link(struct pcie_port
*pp)
* default value in capability register is 512 bytes. So force
* it to 128 here.
*/
- dw_pcie_cfg_read(pp->dbi_base, exp_cap_off + PCI_EXP_DEVCTL, 4, );
+ dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_DEVCTL,
+ 0, 2, );
val &= ~PCI_EXP_DEVCTL_READRQ;
- dw_pcie_cfg_write(pp->dbi_base, exp_cap_off + PCI_EXP_DEVCTL, 4, val);
+ dw_pcie_cfg_write(pp->dbi_base + exp_cap_off + PCI_EXP_DEVCTL,
+ 0, 2, val);
- dw_pcie_cfg_write(pp->dbi_base, PCI_VENDOR_ID, 2, 0x104A);
- dw_pcie_cfg_write(pp->dbi_base, PCI_DEVICE_ID, 2, 0xCD80);
+ dw_pcie_cfg_write(pp->dbi_base + PCI_VENDOR_ID, 0, 2, 0x104A);
+ dw_pcie_cfg_write(pp->dbi_base + PCI_VENDOR_ID, 2, 2, 0xCD80);
/*
* if is_gen1 is set then handle it, so that some buggy card
* also works
*/
if (spear13xx_pcie->is_gen1) {
- dw_pcie_cfg_read(pp->dbi_base, exp_cap_off + PCI_EXP_LNKCAP, 4,
-);
+ dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
+ 0, 4, );
if ((val & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
val &= ~((u32)PCI_EXP_LNKCAP_SLS);
val |= PCI_EXP_LNKCAP_SLS_2_5GB;
- dw_pcie_cfg_write(pp->dbi_base, exp_cap_off +
- PCI_EXP_LNKCAP, 4, val);
+ dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
+ PCI_EXP_LNKCAP, 0, 4, val);
}
- dw_pcie_cfg_read(pp->dbi_base, exp_cap_off + PCI_EXP_LNKCTL2, 4,
-);
+ dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
+ 0, 2, );
if ((val & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
val &= ~((u32)PCI_EXP_LNKCAP_SLS);
val |= PCI_EXP_LNKCAP_SLS_2_5GB;
- dw_pcie_cfg_write(pp->dbi_base, exp_cap_off +
- PCI_EXP_LNKCTL2, 4, val);
+ dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
+ PCI_EXP_LNKCTL2, 0, 2, val);
}
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] sched/numa: Convert sched_numa_balancing to a static_branch
* Wanpeng Li [2015-09-06 12:01:10]: Hi Wanpeng Li, > Hi Srikar, > On 8/12/15 12:24 AM, Srikar Dronamraju wrote: > >Variable sched_numa_balancing toggles numa_balancing feature. Hence > >moving from a simple read mostly variable to a more apt static_branch. > > > >Suggested-by: Peter Zijlstra > >Signed-off-by: Srikar Dronamraju > > > This commit breaks Peter's queue: > > kernel/sched/fair.c: In function ?task_numa_fault?: > kernel/sched/fair.c:2072: error: implicit declaration of function > ?static_branch_likely? > kernel/sched/fair.c: In function ?task_tick_fair?: > kernel/sched/fair.c:7867: error: implicit declaration of function > ?static_branch_unlikely? > make[1]: *** [kernel/sched/fair.o] Error 1 > make[1]: *** Waiting for unfinished jobs > kernel/sched/core.c:2116: warning: data definition has no type or storage > class Thanks for reporting. Can you please confirm if you have the commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=11276d5306b8e5b438a36bbff855fe792d7eaa61 >From 11276d5306b8e5b438a36bbff855fe792d7eaa61 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Fri, 24 Jul 2015 15:09:55 +0200 Subject: [PATCH] locking/static_keys: Add a new static_key interface -- Thanks and Regards Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime
Hi,
On Fri, Sep 04, 2015 at 02:14:07PM +0100, Matt Fleming wrote:
> From: Matt Fleming
>
> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
> signals that the firmware PE/COFF loader supports splitting code and
> data sections of PE/COFF images into separate EFI memory map entries.
> This allows the kernel to map those regions with strict memory
> protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc.
>
> Unfortunately, an unwritten requirement of this new feature is that
> the regions need to be mapped with the same offsets relative to each
> other as observed in the EFI memory map. If this is not done crashes
> like this may occur,
>
> [0.006391] BUG: unable to handle kernel paging request at
> fffefe6086dd
> [0.006923] IP: [] 0xfffefe6086dd
> [0.007000] Call Trace:
> [0.007000] [] efi_call+0x7e/0x100
> [0.007000] [] ? virt_efi_set_variable+0x61/0x90
> [0.007000] [] efi_delete_dummy_variable+0x63/0x70
> [0.007000] [] efi_enter_virtual_mode+0x383/0x392
> [0.007000] [] start_kernel+0x38a/0x417
> [0.007000] [] x86_64_start_reservations+0x2a/0x2c
> [0.007000] [] x86_64_start_kernel+0xeb/0xef
>
> Here 0xfffefe6086dd refers to an address the firmware expects to
> be mapped but which the OS never claimed was mapped. The issue is that
> included in these regions are relative addresses to other regions
> which were emitted by the firmware toolchain before the "splitting" of
> sections occurred at runtime.
>
> Needless to say, we don't satisfy this unwritten requirement on x86_64
> and instead map the EFI memory map entries in reverse order. The above
> crash is almost certainly triggerable with any kernel newer than v3.13
> because that's when we rewrote the EFI runtime region mapping code, in
> commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For
> kernel versions before v3.13 things may work by pure luck depending on
> the fragmentation of the kernel virtual address space at the time we
> map the EFI regions.
>
> Instead of mapping the EFI memory map entries in reverse order, where
> entry N has a higher virtual address than entry N+1, map them in the
> same order as they appear in the EFI memory map to preserve this
> relative offset between regions.
>
> This patch has been kept as small as possible with the intention that
> it should be applied aggressively to stable and distribution kernels.
> It is very much a bugfix rather than support for a new feature, since
> when EFI_PROPERTIES_TABLE is enabled we must map things as outlined
> above to even boot - we have no way of asking the firmware not to
> split the code/data regions.
>
> In fact, this patch doesn't even make use of the more strict memory
> protections available in UEFI v2.5. That will come later.
>
> Reported-by: Ard Biesheuvel
> Cc: Borislav Petkov
> Cc: Leif Lindholm
> Cc: Peter Jones
> Cc: James Bottomley
> Cc: Matthew Garrett
> Cc: H. Peter Anvin
> Cc: Dave Young
> Cc:
> Signed-off-by: Matt Fleming
This patch works to me on Intel S1200V3RPS to fix issue:
DMI: Intel Corporation (uefidk.com) Intel Server Board S1200V3RPS UEFI
Development Kit/ROMLEY, BIOS 2.0
Tested-by: Lee, Chun-Yi
> ---
> arch/x86/include/asm/efi.h | 1 +
> arch/x86/platform/efi/efi.c| 2 +
> arch/x86/platform/efi/efi_32.c | 1 +
> arch/x86/platform/efi/efi_64.c | 109
> ++---
> 4 files changed, 96 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 155162ea0e00..fe988599c5e1 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -96,6 +96,7 @@ extern void __init efi_call_phys_epilog(pgd_t *save_pgd);
> extern void __init efi_unmap_memmap(void);
> extern void __init efi_memory_uc(u64 addr, unsigned long size);
> extern void __init efi_map_region(efi_memory_desc_t *md);
> +extern void __init efi_map_calculate_base(void);
> extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
> extern void efi_sync_low_kernel_mappings(void);
> extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned
> num_pages);
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e4308fe6afe8..5276ec6eefef 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -714,6 +714,8 @@ static void * __init efi_map_regions(int *count, int
> *pg_shift)
> unsigned long left = 0;
> efi_memory_desc_t *md;
>
> + efi_map_calculate_base();
> +
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> md = p;
> if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
> diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
> index ed5b67338294..8a80baa877fb 100644
> --- a/arch/x86/platform/efi/efi_32.c
> +++ b/arch/x86/platform/efi/efi_32.c
> @@ -55,6 +55,7 @@ void __init
Re: [PATCH 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.
On Mon, Sep 7, 2015 at 12:00 PM, Daniel Kurtz wrote: > Hi Dawei, > > On Fri, Sep 4, 2015 at 5:01 PM, Dawei Chien wrote: >> Add thermal zone node to mt8173.dtsi. >> >> Signed-off-by: Dawei Chien >> --- >> This patch is base on following patches >> https://patchwork.kernel.org/patch/6969581/ >> https://patchwork.kernel.org/patch/6969571/ >> https://patchwork.kernel.org/patch/6969381/ >> --- >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44 >> ++ >> 1 file changed, 44 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> index 208051a..6493bfd 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include "mt8173-pinfunc.h" >> +#include Also, as a nit, (#include ) should be above '#include "mt8173-pinfunc.h"' -djk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.
Hi Dawei,
On Fri, Sep 4, 2015 at 5:01 PM, Dawei Chien wrote:
> Add thermal zone node to mt8173.dtsi.
>
> Signed-off-by: Dawei Chien
> ---
> This patch is base on following patches
> https://patchwork.kernel.org/patch/6969581/
> https://patchwork.kernel.org/patch/6969571/
> https://patchwork.kernel.org/patch/6969381/
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44
> ++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 208051a..6493bfd 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -17,6 +17,7 @@
> #include
> #include
> #include "mt8173-pinfunc.h"
> +#include
This include is not necessary, however...
>
> / {
> compatible = "mediatek,mt8173";
> @@ -116,6 +117,49 @@
> clock-output-names = "clk32k";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = < MT8173_THERMAL_ZONE_CA57>;
this fails to compile, because MT8173_THERMAL_ZONE_CA57 is defined in:
include/dt-bindings/thermal/mt8173.h
-Dan
> + sustainable-power = <1500>;
> +
> + trips {
> + threshold: trip-point@0 {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + target: trip-point@1 {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit@0 {
> + temperature = <115000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map@0 {
> + trip = <>;
> + cooling-device = < 0 0>;
> + contribution = <1024>;
> + };
> + map@1 {
> + trip = <>;
> + cooling-device = < 0 0>;
> + contribution = <2048>;
> + };
> + };
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupt-parent = <>;
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger
2015-09-07 2:23 GMT+09:00 Ramakrishna Pallala :
>
> Add new charger driver support for BQ24261 charger IC.
>
> BQ24261 charger driver relies on extcon notifications to get the
> charger cable type and based on that it will set the charging parameters.
>
> Signed-off-by: Ramakrishna Pallala
> Signed-off-by: Jennt TC
> ---
> .../devicetree/bindings/power/bq24261.txt | 37 +
> drivers/power/Kconfig |6 +
> drivers/power/Makefile |1 +
> drivers/power/bq24261_charger.c| 1208
>
> include/linux/power/bq24261_charger.h | 27 +
> 5 files changed, 1279 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt
> create mode 100644 drivers/power/bq24261_charger.c
> create mode 100644 include/linux/power/bq24261_charger.h
>
> diff --git a/Documentation/devicetree/bindings/power/bq24261.txt
> b/Documentation/devicetree/bindings/power/bq24261.txt
> new file mode 100644
> index 000..25fc5c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/bq24261.txt
> @@ -0,0 +1,37 @@
> +Binding for TI bq24261 Li-Ion Charger
Please split the bindings into separate patch (the first patch in patchset).
> +
> +Required properties:
> +- compatible: Should contain one of the following:
> +* "ti,bq24261"
> +- reg: integer, i2c address of the device.
> +- ti,charge-current: integer, default charging current (in mA);
> +- ti,charge-voltage: integer, default charging voltage (in mV);
> +- ti,termination-current: integer, charge will be terminated when current in
> +constant-voltage phase drops below this value (in mA);
> +- ti,max-charge-current: integer, maximum charging current (in mA);
> +- ti,max-charge-voltage: integer, maximum charging voltage (in mV);
> +- ti,min-charge-temperature: integer, minimum charging temperature (in DegC);
> +- ti,max-charge-temperature: integer, maximum charging temperature (in DegC).
Before accepting "[PATCH 13/13] dt: power: bq24257-charger: Cover
additional devices"
http://www.spinics.net/lists/devicetree/msg92134.html
could you and Andreas figure out common bindings? Look at this:
+- ti,charge-current: integer, maximum charging current in uA.
+- ti,charge-current: integer, default charging current (in mA);
Different meaning and different units. This is madness! :)
In the same time you are adding TI-common bindings (not device
specific, there is no prefix) so I would expect exactly the same
bindings if it is possible.
> +
> +Optional properties:
> +- ti,thermal-sensing: boolean, if present thermal regulation will be enabled;
What is the requirement for thermal-sensing? Can it be enabled always?
If yes, then this is not really a hardware property.
> +- ti,enable-user-write: boolean, if present driver will allow the user space
> +to control the charging current and voltage through sysfs;
This is not DT property. It does not describe hardware.
Best regards,
Krzysztof
> +
> +Example:
> +
> +bq25890 {
> +compatible = "ti,bq24261
> +reg = <0x6b>;
> +
> +ti,charge-current = <1000>;
> +ti,charge-voltage = <4200>;
> +ti,termination-current = <128>;
> +ti,max-charge-current = <3000>;
> +ti,max-charge-voltage = <4350>;
> +ti,min-charge-temperature = <0>;
> +ti,max-charge-temperature = <60>;
> +
> +ti,thermal-sensing;
> +ti,enable-user-write;
> +};
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index f8758d6..cd47d0d 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -396,6 +396,12 @@ config CHARGER_BQ24190
> help
> Say Y to enable support for the TI BQ24190 battery charger.
>
> +config CHARGER_BQ24261
> + tristate "TI BQ24261 charger driver"
> + depends on I2C && EXTCON
> + help
> + Say Y here to enable support for TI BQ24261 battery charger.
> +
> config CHARGER_BQ24257
> tristate "TI BQ24257 battery charger driver"
> depends on I2C
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 5752ce8..bec8409 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
> obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
> obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
> obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o
> +obj-$(CONFIG_CHARGER_BQ24261) += bq24261_charger.o
> obj-$(CONFIG_CHARGER_BQ24257) += bq24257_charger.o
> obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
> obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net 2/2] r8152: fix the runtime suspend issues
Fix the runtime suspend issues result from the linking change.
Case 1:
a) link down occurs.
b) driver disable tx/rx.
c) autosuspend occurs.
d) hw linking up.
e) device suspends without enabling tx/rx.
f) couldn't wake up when receiving packets.
Case 2:
a) Nway results in linking down.
b) autosuspend occurs.
c) device suspends.
d) device may not wake up when linking up.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 59 +++--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 6bb48bc..d9427ca 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -30,7 +30,7 @@
#define NETNEXT_VERSION"08"
/* Information for net */
-#define NET_VERSION"1"
+#define NET_VERSION"2"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -148,6 +148,7 @@
#define OCP_EEE_ABLE 0xa5c4
#define OCP_EEE_ADV0xa5d0
#define OCP_EEE_LPABLE 0xa5d2
+#define OCP_PHY_STATE 0xa708 /* nway state for 8153 */
#define OCP_ADC_CFG0xbc06
/* SRAM Register */
@@ -432,6 +433,10 @@
/* OCP_DOWN_SPEED */
#define EN_10M_BGOFF 0x0080
+/* OCP_PHY_STATE */
+#define TXDIS_STATE0x01
+#define ABD_STATE 0x02
+
/* OCP_ADC_CFG */
#define CKADSEL_L 0x0100
#define ADC_EN 0x0080
@@ -609,6 +614,7 @@ struct r8152 {
void (*unload)(struct r8152 *);
int (*eee_get)(struct r8152 *, struct ethtool_eee *);
int (*eee_set)(struct r8152 *, struct ethtool_eee *);
+ bool (*in_nway)(struct r8152 *);
} rtl_ops;
int intr_interval;
@@ -2946,6 +2952,32 @@ static void rtl8153_down(struct r8152 *tp)
r8153_enable_aldps(tp);
}
+static bool rtl8152_in_nway(struct r8152 *tp)
+{
+ u16 nway_state;
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_OCP_GPHY_BASE, 0x2000);
+ tp->ocp_base = 0x2000;
+ ocp_write_byte(tp, MCU_TYPE_PLA, 0xb014, 0x4c); /* phy state */
+ nway_state = ocp_read_word(tp, MCU_TYPE_PLA, 0xb01a);
+
+ /* bit 15: TXDIS_STATE, bit 14: ABD_STATE */
+ if (nway_state & 0xc000)
+ return false;
+ else
+ return true;
+}
+
+static bool rtl8153_in_nway(struct r8152 *tp)
+{
+ u16 phy_state = ocp_reg_read(tp, OCP_PHY_STATE) & 0xff;
+
+ if (phy_state == TXDIS_STATE || phy_state == ABD_STATE)
+ return false;
+ else
+ return true;
+}
+
static void set_carrier(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
@@ -3410,6 +3442,27 @@ static int rtl8152_post_reset(struct usb_interface *intf)
return 0;
}
+static bool delay_autosuspend(struct r8152 *tp)
+{
+ bool sw_linking = !!netif_carrier_ok(tp->netdev);
+ bool hw_linking = !!(rtl8152_get_speed(tp) & LINK_STATUS);
+
+ /* This means a linking change occurs and the driver doesn't detect it,
+* yet. If the driver has disabled tx/rx and hw is linking on, the
+* device wouldn't wake up by receiving any packet.
+*/
+ if (work_busy(>schedule.work) || sw_linking != hw_linking)
+ return true;
+
+ /* If the linking down is occurred by nway, the device may miss the
+* linking change event. And it wouldn't wake when linking on.
+*/
+ if (!sw_linking && tp->rtl_ops.in_nway(tp))
+ return true;
+ else
+ return false;
+}
+
static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
{
struct r8152 *tp = usb_get_intfdata(intf);
@@ -3419,7 +3472,7 @@ static int rtl8152_suspend(struct usb_interface *intf,
pm_message_t message)
mutex_lock(>control);
if (PMSG_IS_AUTO(message)) {
- if (netif_running(netdev) && work_busy(>schedule.work)) {
+ if (netif_running(netdev) && delay_autosuspend(tp)) {
ret = -EBUSY;
goto out1;
}
@@ -4049,6 +4102,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->unload = rtl8152_unload;
ops->eee_get= r8152_get_eee;
ops->eee_set= r8152_set_eee;
+ ops->in_nway= rtl8152_in_nway;
break;
case RTL_VER_03:
@@ -4063,6 +4117,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->unload = rtl8153_unload;
ops->eee_get= r8153_get_eee;
ops->eee_set= r8153_set_eee;
+ ops->in_nway= rtl8153_in_nway;
break;
default:
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
[PATCH net 1/2] r8152: split DRIVER_VERSION
Split DRIVER_VERSION into NETNEXT_VERSION and NET_VERSION. Then, according to the value of DRIVER_VERSION, we could know which patches are used generally without comparing the source code. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index fe4ec32..6bb48bc 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -26,8 +26,13 @@ #include #include -/* Version Information */ -#define DRIVER_VERSION "v1.08.1 (2015/07/28)" +/* Information for net-next */ +#define NETNEXT_VERSION"08" + +/* Information for net */ +#define NET_VERSION"1" + +#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION #define DRIVER_AUTHOR "Realtek linux nic maintainers " #define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" #define MODULENAME "r8152" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net 0/2] fix the autoresume may fail
Fix the autosuspend issues which occur about linking change. Hayes Wang (2): r8152: split DRIVER_VERSION r8152: fix the runtime suspend issues drivers/net/usb/r8152.c | 66 ++--- 1 file changed, 63 insertions(+), 3 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On 9/6/2015 7:16 PM, Frank Rowand wrote:
> On 9/6/2015 1:46 PM, Rob Herring wrote:
>> On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand wrote:
>>> On 9/4/2015 12:12 PM, David Daney wrote:
From: David Daney
It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.
Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
messages by making them conditional on !-ENODEV (which can only be
produced in the PCI_INTERRUPT_PIN == 0 case).
Signed-off-by: David Daney
---
drivers/of/of_pci_irq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 1710d9d..33d242a 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev
*dev, u8 slot, u8 pin)
ret = of_irq_parse_pci(dev, );
if (ret) {
- dev_err(>dev, "of_irq_parse_pci() failed with rc=%d\n",
ret);
+ if (ret != -ENODEV)
+ dev_err(>dev,
+ "of_irq_parse_pci() failed with rc=%d\n",
ret);
return 0; /* Proper return code 0 == NO_IRQ */
}
>>>
>>> It is not safe to assume that the functions that of_irq_parse_pci() calls
>>> will never be modified to return -ENODEV, thus resulting in
>>> of_irq_parse_pci()
>>> returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
>>
>> Yes, but we're talking about a print statement.
>>
>>>
>>> A more robust solution would be something like:
>
> < snip my bad solution >
>
>>> I'm not sure I like my solution, there might be a better way.
>>
>> I don't like it. That's way too complex for just silencing an
>> erroneous error message.
>>
>> Perhaps just move the error message into of_irq_parse_pci and then you
>> can control the print more easily. Or just change to dev_dbg would be
>> okay by me.
>
> I knew I was making it way too hard. Yes, just move the error message
> to of_irq_parse_pci(), where the "/* No pin, exit */" test occurs.
And this time I replied too quickly, not really thinking through my comment.
There are several error return points in of_irq_parse_pci(), so moving the
error message into of_irq_parse_pci() is not the answer.
>>> I also noticed another bug while looking at of_irq_parse_pci(). It returns
>>> the non-zero return value from pci_read_config_byte(). But that value is
>>> one of the PCI function error values from include/linux/pci.h, such as:
>>>
>>>#define PCIBIOS_BAD_REGISTER_NUMBER 0x87
>>>
>>> instead of a negative errno.
>>
>> I was puzzled by why this is not standard error codes a while back. My
>> best guess is that that there is some legacy here. Changing error
>> values on widely used functions is impossible to audit. NO_IRQ being 0
>> or -1 is one such case.
>>
>> Rob
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [RFC] m68k: Wire up direct socket calls
Hi Geert, On 06/09/15 20:06, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Both of these syscall patches look good to me: Acked-by: Greg Ungerer Regards Greg > --- > arch/m68k/include/asm/unistd.h | 2 +- > arch/m68k/include/uapi/asm/unistd.h | 15 +++ > arch/m68k/kernel/syscalltable.S | 16 +++- > 3 files changed, 31 insertions(+), 2 deletions(-) > > diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h > index 244e0dbe45dbeda3..47d6b7153960274e 100644 > --- a/arch/m68k/include/asm/unistd.h > +++ b/arch/m68k/include/asm/unistd.h > @@ -4,7 +4,7 @@ > #include > > > -#define NR_syscalls 356 > +#define NR_syscalls 371 > > #define __ARCH_WANT_OLD_READDIR > #define __ARCH_WANT_OLD_STAT > diff --git a/arch/m68k/include/uapi/asm/unistd.h > b/arch/m68k/include/uapi/asm/unistd.h > index 61fb6cb9d2ae3c66..bf168d5ec3d96d32 100644 > --- a/arch/m68k/include/uapi/asm/unistd.h > +++ b/arch/m68k/include/uapi/asm/unistd.h > @@ -361,5 +361,20 @@ > #define __NR_memfd_create353 > #define __NR_bpf 354 > #define __NR_execveat355 > +#define __NR_socket 356 > +#define __NR_socketpair 357 > +#define __NR_bind358 > +#define __NR_connect 359 > +#define __NR_listen 360 > +#define __NR_accept4 361 > +#define __NR_getsockopt 362 > +#define __NR_setsockopt 363 > +#define __NR_getsockname 364 > +#define __NR_getpeername 365 > +#define __NR_sendto 366 > +#define __NR_sendmsg 367 > +#define __NR_recvfrom368 > +#define __NR_recvmsg 369 > +#define __NR_shutdown370 > > #endif /* _UAPI_ASM_M68K_UNISTD_H_ */ > diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscalltable.S > index a0ec4303f2c8e57a..2cec7cdc8e440f08 100644 > --- a/arch/m68k/kernel/syscalltable.S > +++ b/arch/m68k/kernel/syscalltable.S > @@ -376,4 +376,18 @@ ENTRY(sys_call_table) > .long sys_memfd_create > .long sys_bpf > .long sys_execveat /* 355 */ > - > + .long sys_socket > + .long sys_socketpair > + .long sys_bind > + .long sys_connect > + .long sys_listen/* 360 */ > + .long sys_accept4 > + .long sys_getsockopt > + .long sys_setsockopt > + .long sys_getsockname > + .long sys_getpeername /* 365 */ > + .long sys_sendto > + .long sys_sendmsg > + .long sys_recvfrom > + .long sys_recvmsg > + .long sys_shutdown /* 370 */ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible deadlock related to CPU hotplug and kernfs
On 2015/9/4 22:16, Rafael J. Wysocki wrote: > Hi, > > On Fri, Sep 4, 2015 at 9:20 AM, Jiang Liu wrote: >> On 2015/9/4 4:08, Rafael J. Wysocki wrote: >>> Hi Tejun, >>> >>> On Thu, Sep 3, 2015 at 6:19 PM, Tejun Heo wrote: Hello, Rafael. On Thu, Sep 03, 2015 at 02:58:16AM +0200, Rafael J. Wysocki wrote: > So acpi_device_hotplug() calls lock_device_hotplug() which simply > acquires device_hotplug_lock. It is held throughout the entire > hot-add/hot-remove code path. > > Witing anything to /sys/devices/system/cpu/cpux/online goes through > online_store() in drivers/base/core.c and that does > lock_device_hotplug_sysfs() which then attempts to acquire > device_hotplug_lock using mutex_trylock(). And it only calls > either device_online() or device_offline() if it ends up with the > lock held. > > Quite frankly, I don't see how these particular two code paths can > deadlock in any way. > > So either a third code path is involved which is not executed > under device_hotplug_lock, or lockdep needs to be told to actually > take device_hotplug_lock into account in this case IMO. Hmm... all sysfs rw functions are protected from removal. ie. by default, removal of a sysfs file drains in-flight rw operations, so the hot plug path grabs a lock and then tries to remove a file and writing to the online file makes the file's write method to try to grab the same lock. It deadlocks if the hotunplug path already has the lock and trying to drain the online file for removal. >>> >>> My point is that you cannot get into that situation. If hotplug >>> already holds device_hotplug_lock, the write to "online" will end up >>> doing restart_syscall(). >>> >>> If the "online" code path is holding the lock, hotplug cannot acquire >>> it and cannot proceed. >>> >>> Am I missing anything? >> Hi Rafael, >> I think your are right. The lock_device_hotplug_sysfs() has >> already provided a solution for such a deadlock scenario. And there's >> another related code path at boot as: >> smp_init() >> ->cpu_up() >> ->cpu_hotplug_begin() >> So it seems to be a false alarm. Any way to teach lockdep >> about this to get rid of the false alarm? > > Well, maybe we could call lock_device_hotplug() from that code path too? Hi Rafael, Adding lock_device_hotplug() to smp_init() doesn't solve the issue. So it seems to be an false alarm of lockdep, and I don't know how to get rid of such an lockdep false alarm:( Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eata fails to load on post 4.2 kernels
On 2015/9/7 4:31, Arthur Marsh wrote: > Arthur Marsh wrote on 06/09/15 21:07: >> Arthur Marsh wrote on 06/09/15 18:34: >>> Arthur Marsh wrote on 06/09/15 15:58: Hi, I'm seeing the following on post 4.2 kernels, am currently bisecting to find where it started: >> >> First kernel in the bisection that worked without needing irqpoll: >> >> [ 73.751482] EATA0: IRQ 10 mapped to IO-APIC IRQ 17. >> [ 73.776711] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio. >> [ 73.802005] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, >> ip:n, ep:n, pp:y. >> [ 73.829175] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64. >> [ 73.82] EATA0: wide SCSI support enabled, max_id 16, max_lun 8. >> [ 73.881125] EATA0: SCSI channel 0 enabled, host target ID 7. > > After a git bisect, I get: > > git bisect good > 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit > commit 991de2e59090e55c65a7f59a049142e3c480f7bd > Author: Jiang Liu > Date: Wed Jun 10 16:54:59 2015 +0800 > > PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq() > > To support IOAPIC hotplug, we need to allocate PCI IRQ resources on > demand > and free them when not used anymore. > > Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically > allocate and free PCI IRQs. > > Remove mp_should_keep_irq(), which is no longer used. > > [bhelgaas: changelog] > Signed-off-by: Jiang Liu > Signed-off-by: Bjorn Helgaas > Acked-by: Thomas Gleixner > > :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae > f680234a27685e94b1a35ae2a7218f8eafa9071a M arch > :04 04 d55a682bcde72682e883365e88ad1df6186fd54d > f82c470a04a6845fcf5e0aa934512c75628f798d M drivers > > I'm happy to supply more details if needed. Hi Arthur, Thanks for reporting this. It seems to be an irq misrouting issue. Could you please help to provide: 1) full dmesg with the latest code 2) full dmesg and /proc/interrupts with the latest code and kernel parameter "irqpoll" specified Thanks! Gerry > > Regards, > > Arthur. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 0/4] arm/arm64: fix a migrating irq bug when hotplug cpu
On 2015/9/6 16:07, Jiang Liu wrote: On 2015/9/6 12:23, Yang Yingliang wrote: Hi All, There is a bug: When cpu is disabled, all irqs will be migratged to another cpu. In some cases, a new affinity is different, it needed to be coppied to irq's affinity. But if the type of irq is LPI, it's affinity will not be coppied because of irq_set_affinity's return value. As Marc and Will suggested, I refactor the arm/arm64 migrating interrupts code and fix the migrating irq bug while cpu is offline. I'm trying let the core code do the migrating interrupts matter. kernel/irq/migration.c depends on CONFIG_GENERIC_PENDING_IRQ, so I make it selected by CONFIG_SMP and CONFIG_HOTPLUG_CPU and rename it to CONFIG_GENERIC_IRQ_MIGRATION for more general. When CONFIG_GENERIC_IRQ_MIGRATION is enabled, an interrupt whose state_use_accessors is not set with IRQD_MOVE_PCNTXT won't be migrated immediately in irq_set_affinity_locked(). So introduce irq_settings_set_move_pcntxt() helper to set the state in gic_irq_domain_map(). With the above preparation, move the migrating interrupts code into kernel/irq/migration.c and fix the bug by using irq_do_set_affinity(). Hi Yingliang, As we are going to move migrate_irqs() to generic kernel code, and powerpc, metag, xtensa, sh, ia64 mn10300 also defines migrate_irqs() too. It would be great if we could consolidate all these. And as we are going to refine these code, there's another issue need attention. On x86, we need to allocate a CPU vector if an irq is directed to a CPU. So there's possibility that we run out of CPU vectors after CPU hot-removal. So we have a mechanism to detect whether we will run out of CPU vector after removing a CPU, and reject CPU hot-removal if that will happen. So the key point is, if we a need to allocate some sort of resource on the target CPUs for an irq, we need two steps when removing a CPU 1) check whether resources are available after removing the CPU, and reject CPU removal request if we ran out of resource 2) fix irqs after hot-removing the CPU. Thanks! Gerry On arm, as I know, it doesn't need extra resource for an irq. I am not sure other platform need this way besides x86. I think we could consolidate all migrate_irqs() later. I am not sure if it's good to do so big changing and modify other arch code in a patchset that supposed to fix a bug of arm. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] net: dsa: mv88e6171: add hardware 802.1Q support
From: Vivien Didelot Date: Fri, 4 Sep 2015 11:22:24 -0400 > The Marvell 88E6171 switch is in the 88E6351 family, which supports > 802.1Q, thus add support from the generic mv88e6xxx functions. > > Signed-off-by: Vivien Didelot Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vxlan: Refactor vxlan_udp_encap_recv() to kill compiler warning
From: Geert Uytterhoeven
Date: Fri, 4 Sep 2015 12:49:32 +0200
> drivers/net/vxlan.c: In function ‘vxlan_udp_encap_recv’:
> drivers/net/vxlan.c:1226: warning: ‘info’ may be used uninitialized in this
> function
>
> While this warning is a false positive, it can be killed easily by
> getting rid of the pointer intermediary and referring directly to the
> ip_tunnel_info structure.
>
> Signed-off-by: Geert Uytterhoeven
Applied, thanks.
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
Re: [PATCH] ethernet: synopsys: SYNOPSYS_DWC_ETH_QOS should depend on HAS_DMA
From: Geert Uytterhoeven Date: Fri, 4 Sep 2015 14:44:12 +0200 > If NO_DMA=y: > > ERROR: "dma_alloc_coherent" > [drivers/net/ethernet/synopsys/dwc_eth_qos.ko] undefined! > ERROR: "dma_free_coherent" [drivers/net/ethernet/synopsys/dwc_eth_qos.ko] > undefined! > ERROR: "dma_unmap_single" [drivers/net/ethernet/synopsys/dwc_eth_qos.ko] > undefined! > ERROR: "dma_map_page" [drivers/net/ethernet/synopsys/dwc_eth_qos.ko] > undefined! > ERROR: "dma_mapping_error" [drivers/net/ethernet/synopsys/dwc_eth_qos.ko] > undefined! > ERROR: "dma_map_single" [drivers/net/ethernet/synopsys/dwc_eth_qos.ko] > undefined! > > Signed-off-by: Geert Uytterhoeven Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lan78xx: Fix ladv/radv error handling in lan78xx_link_reset()
From: Geert Uytterhoeven Date: Fri, 4 Sep 2015 12:47:28 +0200 > net/usb/lan78xx.c: In function ‘lan78xx_link_reset’: > net/usb/lan78xx.c:1107: warning: comparison is always false due to limited > range of data type > net/usb/lan78xx.c:: warning: comparison is always false due to limited > range of data type > > Assigning return values that can be negative error codes to "u16" > variables makes them positive, ignoring the errors. Hence use "int" > instead. > > Drop the "unlikely"s (unlikely considered harmful) and propagate the > actual error values instead of overriding them to -EIO while we're at > it. > > Signed-off-by: Geert Uytterhoeven Applied, thanks.
[RFC v2 4/4] iio: chemical: add SGX VZ89x VOC sensor support
Add support for VZ89X sensors VOC and CO2 reporting channels in percentage which can be converted to part per million. Signed-off-by: Matt Ranostay --- .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 30 +++ .../devicetree/bindings/i2c/trivial-devices.txt| 1 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/chemical/Makefile | 6 + drivers/iio/chemical/vz89x.c | 236 + 6 files changed, 275 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x create mode 100644 drivers/iio/chemical/Makefile create mode 100644 drivers/iio/chemical/vz89x.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x new file mode 100644 index 000..74f2a35 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x @@ -0,0 +1,30 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_CO2_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the unscaled, and no offset applied CO2 gas percentage + value. + +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the raw calibration VOC value from the sensor. + This value has little application outside of calibration. + +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_tVOC_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the unscaled, and no offset applied total VOC gas + percentage value. + +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the unscaled sensor resistance value. diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index d77d412..a550216 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) +sgx,vz89x SGX Sensortech VZ89X Sensors sii,s35390a2-wire CMOS real-time clock skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply st-micro,24c256i2c serial eeprom (24cxx) diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 4011eff..9664e9c 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER source "drivers/iio/accel/Kconfig" source "drivers/iio/adc/Kconfig" source "drivers/iio/amplifiers/Kconfig" +source "drivers/iio/chemical/Kconfig" source "drivers/iio/common/Kconfig" source "drivers/iio/dac/Kconfig" source "drivers/iio/frequency/Kconfig" diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 698afc2..2288684 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o obj-y += accel/ obj-y += adc/ obj-y += amplifiers/ +obj-y += chemical/ obj-y += common/ obj-y += dac/ obj-y += gyro/ diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile new file mode 100644 index 000..7292f2d --- /dev/null +++ b/drivers/iio/chemical/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for IIO chemical sensors +# + +# When adding new entries keep the list in alphabetical order +obj-$(CONFIG_VZ89X)+= vz89x.o diff --git a/drivers/iio/chemical/vz89x.c b/drivers/iio/chemical/vz89x.c new file mode 100644 index 000..ac381cc --- /dev/null +++ b/drivers/iio/chemical/vz89x.c @@ -0,0 +1,236 @@ +/* + * vz89x.c - Support for SGX Sensortech MiCS VZ89X VOC sensors + * + * Copyright (C) 2015 Matt Ranostay + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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 + +#define VZ89X_REG_MEASUREMENT
[RFC v2 2/4] iio: resistance: add IIO_RESISTANCE channel type
Signed-off-by: Matt Ranostay
---
Documentation/ABI/testing/sysfs-bus-iio | 7 +++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 48080b7..0f683ed 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1466,3 +1466,10 @@ KernelVersion: 4.3
Contact: linux-...@vger.kernel.org
Description:
Raw (unscaled no offset etc.) precentage reading of a substance.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
+KernelVersion: 4.3
+Contact: linux-...@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) resistance reading in ohms.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 58a60a1..d61a363 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -76,6 +76,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
[IIO_CONCENTRATION] = "concentration",
+ [IIO_RESISTANCE] = "resistance",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index c5a0e3f..d58319c 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -36,6 +36,7 @@ enum iio_chan_type {
IIO_DISTANCE,
IIO_VELOCITY,
IIO_CONCENTRATION,
+ IIO_RESISTANCE,
};
enum iio_modifier {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 1/4] iio: chemical: Add IIO_CONCENTRATION channel type
There are air quality sensors that report data back in parts per million
of VOC (Volatile Organic Compounds) which are usually indexed from CO2
or another common pollutant.
This patchset adds an IIO_CONCENTRATION type that returns a percentage
of substance because no other channels types fit this use case.
Signed-off-by: Matt Ranostay
---
Documentation/ABI/testing/sysfs-bus-iio | 7 +++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..48080b7 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1459,3 +1459,10 @@ Description:
measurements and return the average value as output data. Each
value resulted from [_name]_oversampling_ratio
measurements
is considered as one sample for
[_name]_sampling_frequency.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
+KernelVersion: 4.3
+Contact: linux-...@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) precentage reading of a substance.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..58a60a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -75,6 +75,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_ENERGY] = "energy",
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
+ [IIO_CONCENTRATION] = "concentration",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 2f8b117..c5a0e3f 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -35,6 +35,7 @@ enum iio_chan_type {
IIO_ENERGY,
IIO_DISTANCE,
IIO_VELOCITY,
+ IIO_CONCENTRATION,
};
enum iio_modifier {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 3/4] devicetree: add SGX Sensortech vendor id
Signed-off-by: Matt Ranostay --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac5f0c3..281e8f0 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -191,6 +191,7 @@ sbs Smart Battery System schindler Schindler seagateSeagate Technology PLC semtechSemtech Corporation +sgxSGX Sensortech sharp Sharp Corporation silSilicon Image silabs Silicon Laboratories -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 0/4] iio: new chemical sensor framework and channel types
Changes from RFC v1: * Removed IIO_MOD_PPM/PPB modifiers * Fixed issues with driver that would have caused null readings * Return IIO_VAL_INT_PLUS_MICRO/IIO_VAL_INT_PLUS_NANO for CO2 and VOC channel readings * Return IIO_VAL_INT_PLUS_MICRO for IIO_CHAN_INFO_OFFSET * Add sysfs-bus-iio-chemical-vz89x documentation Matt Ranostay (4): iio: chemical: Add IIO_CONCENTRATION channel type iio: resistance: add IIO_RESISTANCE channel type devicetree: add SGX Sensortech vendor id iio: chemical: add SGX VZ89x VOC sensor support Documentation/ABI/testing/sysfs-bus-iio| 14 ++ .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 30 +++ .../devicetree/bindings/i2c/trivial-devices.txt| 1 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/chemical/Makefile | 6 + drivers/iio/chemical/vz89x.c | 236 + drivers/iio/industrialio-core.c| 2 + include/uapi/linux/iio/types.h | 2 + 10 files changed, 294 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x create mode 100644 drivers/iio/chemical/Makefile create mode 100644 drivers/iio/chemical/vz89x.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 04/13] otg-fsm: move usb_bus_start_enum into otg-fsm->ops
On Mon, Aug 24, 2015 at 04:21:15PM +0300, Roger Quadros wrote:
> This is to prevent missing symbol build error if OTG is
> enabled (built-in) and HCD core (CONFIG_USB) is module.
>
> Signed-off-by: Roger Quadros
> Acked-by: Peter Chen
> ---
> drivers/usb/common/usb-otg-fsm.c | 6 --
> drivers/usb/phy/phy-fsl-usb.c| 2 ++
> include/linux/usb/otg-fsm.h | 1 +
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/common/usb-otg-fsm.c
> b/drivers/usb/common/usb-otg-fsm.c
> index a46f29a..6e56c8c 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -165,8 +165,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum
> usb_otg_state new_state)
> otg_loc_conn(fsm, 0);
> otg_loc_sof(fsm, 1);
> otg_set_protocol(fsm, PROTO_HOST);
> - usb_bus_start_enum(fsm->otg->host,
> - fsm->otg->host->otg_port);
> + if (fsm->ops->start_enum) {
> + fsm->ops->start_enum(fsm->otg->host,
> + fsm->otg->host->otg_port);
> + }
> break;
> case OTG_STATE_A_IDLE:
> otg_drv_vbus(fsm, 0);
> diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
> index ee3f2c2..19541ed 100644
> --- a/drivers/usb/phy/phy-fsl-usb.c
> +++ b/drivers/usb/phy/phy-fsl-usb.c
> @@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
>
> .start_host = fsl_otg_start_host,
> .start_gadget = fsl_otg_start_gadget,
> +
> + .start_enum = usb_bus_start_enum,
> };
>
> /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
> diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
> index 672551c..75e82cc 100644
> --- a/include/linux/usb/otg-fsm.h
> +++ b/include/linux/usb/otg-fsm.h
> @@ -199,6 +199,7 @@ struct otg_fsm_ops {
> void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
> int (*start_host)(struct otg_fsm *fsm, int on);
> int (*start_gadget)(struct otg_fsm *fsm, int on);
> + int (*start_enum)(struct usb_bus *bus, unsigned port_num);
> };
>
>
Get one build warning:
In file included from
/u/home/b29397/work/projects/usb/drivers/usb/chipidea/udc.c:23:0:
/u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: warning:
'struct usb_bus' declared inside parameter list
int (*start_enum)(struct usb_bus *bus, unsigned port_num);
^
/u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: warning:
its scope is only this definition or declaration, which is probably not what
you want
It probably dues to we should not have struct usb_bus* at udc driver
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 07/13] usb: otg: add OTG core
On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> + * This is used by the USB Host stack to register the Host controller
> + * to the OTG core. Host controller must not be started by the
> + * caller as it is left upto the OTG state machine to do so.
> + *
> + * Returns: 0 on success, error value otherwise.
> + */
> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
> + unsigned long irqflags, struct otg_hcd_ops *ops)
> +{
> + struct usb_otg *otgd;
> + struct device *hcd_dev = hcd->self.controller;
> + struct device *otg_dev = usb_otg_get_device(hcd_dev);
> +
One big problem here is: there are two designs for current (IP) driver
code, one creates dedicated hcd device as roothub's parent, like dwc3.
Another one doesn't do this, roothub's parent is core device (or otg device
in your patch), like chipidea and dwc2.
Then, otg_dev will be glue layer device for chipidea after that.
Peter
> + if (!otg_dev)
> + return -EINVAL; /* we're definitely not OTG */
> +
> + /* we're otg but otg controller might not yet be registered */
> + mutex_lock(_list_mutex);
> + otgd = usb_otg_get_data(otg_dev);
> + mutex_unlock(_list_mutex);
> + if (!otgd) {
> + dev_dbg(hcd_dev,
> + "otg: controller not yet registered. waiting..\n");
> + /*
> + * otg controller might register later. Put the hcd in
> + * wait list and call us back when ready
> + */
> + if (usb_otg_hcd_wait_add(otg_dev, hcd, irqnum, irqflags, ops)) {
> + dev_dbg(hcd_dev, "otg: failed to add to wait list\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> + }
> +
> + /* HCD will be started by OTG fsm when needed */
> + mutex_lock(>fsm.lock);
> + if (otgd->primary_hcd.hcd) {
> + /* probably a shared HCD ? */
> + if (usb_otg_hcd_is_primary_hcd(hcd)) {
> + dev_err(otg_dev, "otg: primary host already
> registered\n");
> + goto err;
> + }
> +
> + if (hcd->shared_hcd == otgd->primary_hcd.hcd) {
> + if (otgd->shared_hcd.hcd) {
> + dev_err(otg_dev, "otg: shared host already
> registered\n");
> + goto err;
> + }
> +
> + otgd->shared_hcd.hcd = hcd;
> + otgd->shared_hcd.irqnum = irqnum;
> + otgd->shared_hcd.irqflags = irqflags;
> + otgd->shared_hcd.ops = ops;
> + dev_info(otg_dev, "otg: shared host %s registered\n",
> + dev_name(hcd->self.controller));
> + } else {
> + dev_err(otg_dev, "otg: invalid shared host %s\n",
> + dev_name(hcd->self.controller));
> + goto err;
> + }
> + } else {
> + if (!usb_otg_hcd_is_primary_hcd(hcd)) {
> + dev_err(otg_dev, "otg: primary host must be registered
> first\n");
> + goto err;
> + }
> +
> + otgd->primary_hcd.hcd = hcd;
> + otgd->primary_hcd.irqnum = irqnum;
> + otgd->primary_hcd.irqflags = irqflags;
> + otgd->primary_hcd.ops = ops;
> + dev_info(otg_dev, "otg: primary host %s registered\n",
> + dev_name(hcd->self.controller));
> + }
> +
> + /*
> + * we're ready only if we have shared HCD
> + * or we don't need shared HCD.
> + */
> + if (otgd->shared_hcd.hcd || !otgd->primary_hcd.hcd->shared_hcd) {
> + otgd->fsm.otg->host = hcd_to_bus(hcd);
> + /* FIXME: set bus->otg_port if this is true OTG port with HNP */
> +
> + /* start FSM */
> + usb_otg_start_fsm(>fsm);
> + } else {
> + dev_dbg(otg_dev, "otg: can't start till shared host
> registers\n");
> + }
> +
> + mutex_unlock(>fsm.lock);
> +
> + return 0;
> +
> +err:
> + mutex_unlock(>fsm.lock);
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(usb_otg_register_hcd);
> +
> +/**
> + * usb_otg_unregister_hcd - Unregister Host controller from OTG core
> + * @hcd: Host controller device
> + *
> + * This is used by the USB Host stack to unregister the Host controller
> + * from the OTG core. Ensures that Host controller is not running
> + * on successful return.
> + *
> + * Returns: 0 on success, error value otherwise.
> + */
> +int usb_otg_unregister_hcd(struct usb_hcd *hcd)
> +{
> + struct usb_otg *otgd;
> + struct device *hcd_dev = hcd_to_bus(hcd)->controller;
> + struct device *otg_dev = usb_otg_get_device(hcd_dev);
> +
> + if (!otg_dev)
> + return -EINVAL; /* we're definitely not OTG */
> +
> + mutex_lock(_list_mutex);
> + otgd =
Re: [RFC PATCH v1 4/4] arm/arm64: fix a migrating irq bug when hotplug cpu
On 2015/9/6 13:55, Jiang Liu wrote:
On 2015/9/6 12:23, Yang Yingliang wrote:
When cpu is disabled, all irqs will be migratged to another cpu.
In some cases, a new affinity is different, it needed to be coppied
to irq's affinity. But if the type of irq is LPI, it's affinity will
not be coppied because of irq_set_affinity's return value. Fix it by
using irq_do_set_affinity.
And migrating interrupts is a core code matter, so move the code to
kernel/irq/migration.c and select CONFIG_GENERIC_IRQ_MIGRATION when
CONFIG_HOTPLUG_CPU and CONFIG_SMP is enabled.
Cc: Jiang Liu
Cc: Thomas Gleixner
Cc: Marc Zyngier
Cc: Mark Rutland
Cc: Will Deacon
Cc: Russell King - ARM Linux
Cc: Hanjun Guo
Signed-off-by: Yang Yingliang
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/irq.h | 1 -
arch/arm/kernel/irq.c| 62
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/irq.h | 1 -
arch/arm64/kernel/irq.c | 62
kernel/irq/migration.c | 62
7 files changed, 64 insertions(+), 126 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 41cbb4a..ebc8a33 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
+ select GENERIC_IRQ_MIGRATION if SMP && HOTPLUG_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAP
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index 53c15de..d17fc900 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -24,7 +24,6 @@
#ifndef __ASSEMBLY__
struct irqaction;
struct pt_regs;
-extern void migrate_irqs(void);
extern void asm_do_IRQ(unsigned int, struct pt_regs *);
void handle_IRQ(unsigned int, struct pt_regs *);
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index baf8ede..2efdb40 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -135,64 +134,3 @@ int __init arch_probe_nr_irqs(void)
return nr_irqs;
}
#endif
-
-#ifdef CONFIG_HOTPLUG_CPU
-static bool migrate_one_irq(struct irq_desc *desc)
-{
- struct irq_data *d = irq_desc_get_irq_data(desc);
- const struct cpumask *affinity = irq_data_get_affinity_mask(d);
- struct irq_chip *c;
- bool ret = false;
-
- /*
-* If this is a per-CPU interrupt, or the affinity does not
-* include this CPU, then we have nothing to do.
-*/
- if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(),
affinity))
- return false;
-
- if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
- affinity = cpu_online_mask;
- ret = true;
- }
-
- c = irq_data_get_irq_chip(d);
- if (!c->irq_set_affinity)
- pr_debug("IRQ%u: unable to set affinity\n", d->irq);
- else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK &&
ret)
- cpumask_copy(irq_data_get_affinity_mask(d), affinity);
-
- return ret;
-}
-
-/*
- * The current CPU has been marked offline. Migrate IRQs off this CPU.
- * If the affinity settings do not allow other CPUs, force them onto any
- * available CPU.
- *
- * Note: we must iterate over all IRQs, whether they have an attached
- * action structure or not, as we need to get chained interrupts too.
- */
-void migrate_irqs(void)
-{
- unsigned int i;
- struct irq_desc *desc;
- unsigned long flags;
-
- local_irq_save(flags);
-
- for_each_irq_desc(i, desc) {
- bool affinity_broken;
-
- raw_spin_lock(>lock);
- affinity_broken = migrate_one_irq(desc);
- raw_spin_unlock(>lock);
-
- if (affinity_broken)
- pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
- i, smp_processor_id());
- }
-
- local_irq_restore(flags);
-}
-#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b7b9cea..6ffe411 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -32,6 +32,7 @@ config ARM64
select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IRQ_PROBE
+ select GENERIC_IRQ_MIGRATION if SMP && HOTPLUG_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_PCI_IOMAP
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index bbb251b..0916929 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -7,7 +7,6 @@
struct pt_regs;
-extern void migrate_irqs(void);
extern void
Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Hi Krzysztof,
在 09/07/2015 08:22 AM, Krzysztof Kozlowski 写道:
On 06.09.2015 16:49, Yakir Yang wrote:
Hi Krzysztof,
在 09/04/2015 08:41 AM, Krzysztof Kozlowski 写道:
On 03.09.2015 14:30, Yakir Yang wrote:
Hi Krzysztof,
在 09/03/2015 08:58 AM, Krzysztof Kozlowski 写道:
On 01.09.2015 14:49, Yakir Yang wrote:
Split the dp core driver from exynos directory to bridge
directory, and rename the core driver to analogix_dp_*,
leave the platform code to analogix_dp-exynos.
Signed-off-by: Yakir Yang
---
Changes in v4:
- Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT
propery.
- Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
"exynos_dp.c"
- Take Archit suggest, create a separate folder for analogix code in
bridge/
Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
to analogix_dp-exynos platform driver, add get_modes method
to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to
"analogix*".
Changes in v2:
- Take Jingoo Han suggest, remove new copyright
- Fix compiled failed dut to analogix_dp_device misspell
[.]
-static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
+static int analogix_dp_bridge_attach(struct drm_bridge *bridge)
{
-struct exynos_dp_device *dp = bridge->driver_private;
-struct drm_encoder *encoder = >encoder;
+struct analogix_dp_device *dp = bridge->driver_private;
+struct drm_encoder *encoder = dp->encoder;
struct drm_connector *connector = >connector;
int ret;
-/* Pre-empt DP connector creation if there's a bridge */
-if (dp->ptn_bridge) {
-ret = exynos_drm_attach_lcd_bridge(dp, encoder);
-if (!ret)
-return 0;
+if (!bridge->encoder) {
+DRM_ERROR("Parent encoder object not found");
+return -ENODEV;
}
+encoder->bridge = bridge;
+
connector->polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(dp->drm_dev, connector,
- _dp_connector_funcs,
+ _dp_connector_funcs,
DRM_MODE_CONNECTOR_eDP);
if (ret) {
DRM_ERROR("Failed to initialize connector with drm\n");
return ret;
}
-drm_connector_helper_add(connector,
_dp_connector_helper_funcs);
+drm_connector_helper_add(connector,
+ _dp_connector_helper_funcs);
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
-if (dp->panel)
-ret = drm_panel_attach(dp->panel, >connector);
+if (dp->plat_data && dp->plat_data->panel) {
+ret = drm_panel_attach(dp->plat_data->panel, >connector);
+if (ret) {
+DRM_ERROR("Failed to attach panel\n");
+return ret;
+}
+}
+
+/*
+ * This should be the end of attach function, caused
+ * we should ensure dp bridge could attach first.
+ */
+ if (dp->plat_data && dp->plat_data->attach) {
+ ret = dp->plat_data->attach(dp->plat_data, bridge);
+ if (ret) {
+ DRM_ERROR("Failed at platform attch func\n");
Two new error paths appeared here and above. Don't you have to
cleanup something? I don't know, just wondering...
Hmm... I think both panel & platform_attch need ERROR remind when
it failed. But if it still need clean, I though it should clean the
platform attch
error,
this is not relate to DRM directly, just analogix driver logic, so
code would like,
-if (dp->panel)
-ret = drm_panel_attach(dp->panel, >connector);
+if (dp->plat_data && dp->plat_data->panel) {
+ret = drm_panel_attach(dp->plat_data->panel, >connector);
+if (ret) {
+DRM_ERROR("Failed to attach panel\n");
+return ret;
+}
+}
+/*
+ * This should be the end of attach function, caused
+ * we should ensure dp bridge could attach first.
+ */
+ if (dp->plat_data && dp->plat_data->attach) {
+ ret = dp->plat_data->attach(dp->plat_data, bridge);
return ret;
I am lost... the code looks the same. What did you change?
I just remove the DRM_ERROR after dp->plat_data->attach(),
maybe I should paste the change that rebase on this patch,
here are they,
/*
* This should be the end of attach function, caused
* we should ensure dp bridge could attach first.
*/
- if (dp->plat_data && dp->plat_data->attach) {
+ if (dp->plat_data && dp->plat_data->attach)
ret = dp->plat_data->attach(dp->plat_data, bridge);
- if (ret) {
- DRM_ERROR("Failed at platform attch func\n");
- return ret;
- }
- }
-return 0;
+ return ret;
If this haven't meet your comment, I maybe start to think that
your comment "Two new error paths appeared here and above"
indicated that those two function is the same.
"dp->plat_data->attach(dp->plat_data, bridge); "
Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps
On Mon, Sep 07, 2015 at 02:29:53AM +0100, Pádraig Brady wrote:
> On 20/08/15 09:26, Naoya Horiguchi wrote:
> > Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> > is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> > To solve this, this patch adds a new line for hugetlb usage like below:
> >
> > Size: 20480 kB
> > Rss: 0 kB
> > Pss: 0 kB
> > Shared_Clean: 0 kB
> > Shared_Dirty: 0 kB
> > Private_Clean: 0 kB
> > Private_Dirty: 0 kB
> > Referenced:0 kB
> > Anonymous: 0 kB
> > AnonHugePages: 0 kB
> > HugetlbPages: 18432 kB
> > Swap: 0 kB
> > KernelPageSize: 2048 kB
> > MMUPageSize:2048 kB
> > Locked:0 kB
> > VmFlags: rd wr mr mw me de ht
> >
> > Signed-off-by: Naoya Horiguchi
> > Acked-by: Joern Engel
> > Acked-by: David Rientjes
> > ---
> > v3 -> v4:
> > - suspend Acked-by tag because v3->v4 change is not trivial
> > - I stated in previous discussion that HugetlbPages line can contain page
> > size info, but that's not necessary because we already have KernelPageSize
> > info.
> > - merged documentation update, where the current documentation doesn't
> > mention
> > AnonHugePages, so it's also added.
> > ---
> > Documentation/filesystems/proc.txt | 7 +--
> > fs/proc/task_mmu.c | 29 +
> > 2 files changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git v4.2-rc4/Documentation/filesystems/proc.txt
> > v4.2-rc4_patched/Documentation/filesystems/proc.txt
> > index 6f7fafde0884..22e40211ef64 100644
> > --- v4.2-rc4/Documentation/filesystems/proc.txt
> > +++ v4.2-rc4_patched/Documentation/filesystems/proc.txt
> > @@ -423,6 +423,8 @@ Private_Clean: 0 kB
> > Private_Dirty: 0 kB
> > Referenced: 892 kB
> > Anonymous: 0 kB
> > +AnonHugePages: 0 kB
> > +HugetlbPages: 0 kB
> > Swap: 0 kB
> > KernelPageSize:4 kB
> > MMUPageSize: 4 kB
> > @@ -440,8 +442,9 @@ indicates the amount of memory currently marked as
> > referenced or accessed.
> > "Anonymous" shows the amount of memory that does not belong to any file.
> > Even
> > a mapping associated with a file may contain anonymous pages: when
> > MAP_PRIVATE
> > and a page is modified, the file page is replaced by a private anonymous
> > copy.
> > -"Swap" shows how much would-be-anonymous memory is also used, but out on
> > -swap.
> > +"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
> > +"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
> > +"Swap" shows how much would-be-anonymous memory is also used, but out on
> > swap.
>
> There is no distinction between "private" and "shared" in this "huge page"
> accounting right?
Right for current version. And I think that private/shared distinction
gives some help.
> Would it be possible to account for the huge pages in the
> {Private,Shared}_{Clean,Dirty} fields?
> Or otherwise split the huge page accounting into shared/private?
As for clean/dirty distinction, I'm not sure how it's worthwhile because
hugetlb pages are always on memory and never swapped out (userspace doesn't
care about dirtiness of hugetlb?).
According to commit log of commit b4d1d99fdd8b ("hugetlb: handle updating
of ACCESSED and DIRTY in hugetlb_fault()"), dirty bit of hugetlb is maintained
to make arch-specific TLB handling convenient. It looks purely kernel-internal,
so I think we don't have to expose it.
Thanks,
Naoya Horiguchi
Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On 9/6/2015 1:46 PM, Rob Herring wrote:
> On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand wrote:
>> On 9/4/2015 12:12 PM, David Daney wrote:
>>> From: David Daney
>>>
>>> It is perfectly legitimate for a PCI device to have an
>>> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
>>> use interrupts, or on PCIe devices, where only MSI/MSI-X are
>>> supported.
>>>
>>> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
>>> messages by making them conditional on !-ENODEV (which can only be
>>> produced in the PCI_INTERRUPT_PIN == 0 case).
>>>
>>> Signed-off-by: David Daney
>>> ---
>>> drivers/of/of_pci_irq.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
>>> index 1710d9d..33d242a 100644
>>> --- a/drivers/of/of_pci_irq.c
>>> +++ b/drivers/of/of_pci_irq.c
>>> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev,
>>> u8 slot, u8 pin)
>>>
>>> ret = of_irq_parse_pci(dev, );
>>> if (ret) {
>>> - dev_err(>dev, "of_irq_parse_pci() failed with rc=%d\n",
>>> ret);
>>> + if (ret != -ENODEV)
>>> + dev_err(>dev,
>>> + "of_irq_parse_pci() failed with rc=%d\n",
>>> ret);
>>> return 0; /* Proper return code 0 == NO_IRQ */
>>> }
>>>
>>>
>>
>> It is not safe to assume that the functions that of_irq_parse_pci() calls
>> will never be modified to return -ENODEV, thus resulting in
>> of_irq_parse_pci()
>> returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
>
> Yes, but we're talking about a print statement.
>
>>
>> A more robust solution would be something like:
< snip my bad solution >
>> I'm not sure I like my solution, there might be a better way.
>
> I don't like it. That's way too complex for just silencing an
> erroneous error message.
>
> Perhaps just move the error message into of_irq_parse_pci and then you
> can control the print more easily. Or just change to dev_dbg would be
> okay by me.
I knew I was making it way too hard. Yes, just move the error message
to of_irq_parse_pci(), where the "/* No pin, exit */" test occurs.
>> I also noticed another bug while looking at of_irq_parse_pci(). It returns
>> the non-zero return value from pci_read_config_byte(). But that value is
>> one of the PCI function error values from include/linux/pci.h, such as:
>>
>>#define PCIBIOS_BAD_REGISTER_NUMBER 0x87
>>
>> instead of a negative errno.
>
> I was puzzled by why this is not standard error codes a while back. My
> best guess is that that there is some legacy here. Changing error
> values on widely used functions is impossible to audit. NO_IRQ being 0
> or -1 is one such case.
>
> Rob
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
On 2015/9/6 13:56, Jiang Liu wrote:
On 2015/9/6 12:23, Yang Yingliang wrote:
Use irq_settings_set_move_pcntxt() helper irqs status with
_IRQ_MOVE_PCNTXT. So that it can do set affinity when calling
irq_set_affinity_locked().
Hi Yingliang,
We could only set _IRQ_MOVE_PCNTCT flag to enable migrating
IRQ in process context if your hardware platform supports atomically
change IRQ configuration. Not sure whether that's true for GICv3.
If GICv3 doesn't support atomically change irq configuration, this
change may cause trouble.
Thanks!
Gerry
I am not certain sure if GICv3 supports it. But current code consider it
as true default without CONFIG_GENERIC_PENDING_IRQ enable on arm.
Does Marc have any opinion ?
Thanks
Yang
Cc: Jiang Liu
Cc: Thomas Gleixner
Cc: Marc Zyngier
Cc: Mark Rutland
Cc: Will Deacon
Cc: Russell King - ARM Linux
Cc: Hanjun Guo
Signed-off-by: Yang Yingliang
---
drivers/irqchip/irq-gic-v3.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index e406bc5..9108387 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -688,6 +688,7 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
irq_domain_set_info(d, irq, hw, _chip, d->host_data,
handle_fasteoi_irq, NULL, NULL);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+ irq_set_move_pcntxt(irq);
}
/* LPIs */
if (hw >= 8192 && hw < GIC_ID_NR) {
@@ -696,6 +697,7 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
irq_domain_set_info(d, irq, hw, _chip, d->host_data,
handle_fasteoi_irq, NULL, NULL);
set_irq_flags(irq, IRQF_VALID);
+ irq_set_move_pcntxt(irq);
}
return 0;
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 0/4] arm/arm64: fix a migrating irq bug when hotplug cpu
On 2015/9/6 12:23, Yang Yingliang wrote: > Hi All, > > There is a bug: > > When cpu is disabled, all irqs will be migratged to another cpu. > In some cases, a new affinity is different, it needed to be coppied > to irq's affinity. But if the type of irq is LPI, it's affinity will > not be coppied because of irq_set_affinity's return value. > > > > As Marc and Will suggested, I refactor the arm/arm64 migrating interrupts > code and fix the migrating irq bug while cpu is offline. > > I'm trying let the core code do the migrating interrupts matter. > kernel/irq/migration.c > depends on CONFIG_GENERIC_PENDING_IRQ, so I make it selected by CONFIG_SMP and > CONFIG_HOTPLUG_CPU and rename it to CONFIG_GENERIC_IRQ_MIGRATION for more > general. > When CONFIG_GENERIC_IRQ_MIGRATION is enabled, an interrupt whose > state_use_accessors > is not set with IRQD_MOVE_PCNTXT won't be migrated immediately in > irq_set_affinity_locked(). > So introduce irq_settings_set_move_pcntxt() helper to set the state in > gic_irq_domain_map(). > > With the above preparation, move the migrating interrupts code into > kernel/irq/migration.c > and fix the bug by using irq_do_set_affinity(). Hi Yingliang, As we are going to move migrate_irqs() to generic kernel code, and powerpc, metag, xtensa, sh, ia64 mn10300 also defines migrate_irqs() too. It would be great if we could consolidate all these. And as we are going to refine these code, there's another issue need attention. On x86, we need to allocate a CPU vector if an irq is directed to a CPU. So there's possibility that we run out of CPU vectors after CPU hot-removal. So we have a mechanism to detect whether we will run out of CPU vector after removing a CPU, and reject CPU hot-removal if that will happen. So the key point is, if we a need to allocate some sort of resource on the target CPUs for an irq, we need two steps when removing a CPU 1) check whether resources are available after removing the CPU, and reject CPU removal request if we ran out of resource 2) fix irqs affinity after removing the CPU. Thanks! Gerry > > Cc: Jiang Liu > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Mark Rutland > Cc: Will Deacon > Cc: Russell King - ARM Linux > Cc: Hanjun Guo > > Yang Yingliang (4): > genirq: Introduce irq_settings_set_move_pcntxt() helper > irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT > genirq: rename config GENERIC_PENDING_IRQ to GENERIC_IRQ_MIGRATION > arm/arm64: fix a migrating irq bug when hotplug cpu > > arch/arc/Kconfig | 2 +- > arch/arm/Kconfig | 1 + > arch/arm/include/asm/irq.h | 1 - > arch/arm/kernel/irq.c | 62 > -- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/irq.h | 1 - > arch/arm64/kernel/irq.c| 62 > -- > arch/hexagon/Kconfig | 2 +- > arch/ia64/Kconfig | 2 +- > arch/tile/Kconfig | 2 +- > arch/x86/Kconfig | 2 +- > arch/x86/kernel/apic/io_apic.c | 2 +- > drivers/irqchip/irq-gic-v3.c | 2 ++ > include/linux/irq.h| 5 +++- > include/linux/irqdesc.h| 2 +- > kernel/irq/Kconfig | 4 +-- > kernel/irq/Makefile| 2 +- > kernel/irq/irqdesc.c | 18 ++-- > kernel/irq/manage.c| 2 +- > kernel/irq/migration.c | 62 > ++ > kernel/irq/proc.c | 2 +- > kernel/irq/settings.h | 5 > 22 files changed, 102 insertions(+), 142 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] m68knommu/coldfire fixes for 4.3
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a couple of patches this time. One migrating the clock driver code to the new set-state interface. The other cleaning up to use the PFN_DOWN macro. Regards Greg The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b: Linux 4.2-rc8 (2015-08-23 20:52:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 50e48bd0673180311874d0c1bd88505eefd75c4e: m68k/coldfire: use PFN_DOWN macro (2015-08-24 14:31:38 +1000) Alexander Kuleshov (1): m68k/coldfire: use PFN_DOWN macro Viresh Kumar (1): m68k/coldfire/pit: Migrate to new 'set-state' interface arch/m68k/coldfire/m54xx.c | 9 --- arch/m68k/coldfire/pit.c | 66 +- 2 files changed, 35 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 1/4] genirq: Introduce irq_settings_set_move_pcntxt() helper
On 2015/9/7 6:08, Thomas Gleixner wrote: On Sun, 6 Sep 2015, Yang Yingliang wrote: It's expected to use the helper when interrupt can be moved in process. What's wrong with using the existing helper? irq_set_status_flags(irq, IRQ_MOVE_PCNTXT); It looks OK. I will use it next version. Thanks, Yang Thanks, tglx ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [media] atmel-isi: Protect PM-only functions to kill warning
Hi, Geert Uytterhoeven
Thanks for the patch.
On 9/6/2015 6:08 PM, Geert Uytterhoeven wrote:
If CONFIG_PM=n:
drivers/media/platform/soc_camera/atmel-isi.c:1044: warning:
‘atmel_isi_runtime_suspend’ defined but not used
drivers/media/platform/soc_camera/atmel-isi.c:1054: warning:
‘atmel_isi_runtime_resume’ defined but not used
Protect the unused functions by #ifdef CONFIG_PM to fix this.
Signed-off-by: Geert Uytterhoeven
Acked-by: Josh Wu
Best Regards,
Josh Wu
---
Resend with correct suject
---
drivers/media/platform/soc_camera/atmel-isi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 90701726a06a2e5c..ccf30ccbe389233f 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -1040,6 +1040,7 @@ err_alloc_ctx:
return ret;
}
+#ifdef CONFIG_PM
static int atmel_isi_runtime_suspend(struct device *dev)
{
struct soc_camera_host *soc_host = to_soc_camera_host(dev);
@@ -1058,6 +1059,7 @@ static int atmel_isi_runtime_resume(struct device *dev)
return clk_prepare_enable(isi->pclk);
}
+#endif /* CONFIG_PM */
static const struct dev_pm_ops atmel_isi_dev_pm_ops = {
SET_RUNTIME_PM_OPS(atmel_isi_runtime_suspend,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support
Hi Krzysztof,
在 09/07/2015 07:55 AM, Krzysztof Kozlowski 写道:
On 06.09.2015 13:07, Yakir Yang wrote:
Hi Krzysztof,
在 09/04/2015 08:36 AM, Krzysztof Kozlowski 写道:
On 01.09.2015 15:07, Yakir Yang wrote:
Empty commit message. Please explain here why you want to add platform
device type support.
Actually the title is confusing. You are not adding support for platform
device types but rather adding a field containing type of device.
Signed-off-by: Yakir Yang
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add GNU license v2 declared and samsung copyright
drivers/gpu/drm/exynos/exynos_dp.c | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 +
include/drm/bridge/analogix_dp.h| 16
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index 6060d2c..40ef727 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev,
struct device *master, void *data)
dp->dev = dev;
dp->drm_dev = drm_dev;
+dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index efea045..4934271 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev,
struct device *master,
return ret;
}
+dp->plat_data.dev_type = RK3288_DP;
dp->plat_data.attach = NULL;
dp->plat_data.get_modes = NULL;
dp->plat_data.power_on = rockchip_dp_poweron;
diff --git a/include/drm/bridge/analogix_dp.h
b/include/drm/bridge/analogix_dp.h
index 8b4ffad..7209a64 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -1,9 +1,25 @@
+/*
+ * Analogix Core DP (Display Port) interface driver.
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
Two questions:
1. Why this change is here? I would rather expect it at patch 3/16 when
you created this file... That is the usual time for adding copyrights.
Yep, I should move this to 03/16.
2. Does this file contains previous Samsung work?
Hmm... I think this haven't contains the previous Samsung works,
but I have the cover the head message from analogix_dp_core driver
(include the copyright, but without ant author).
If it does not contain Samsung's work then don't mention its copyrights.
Okay,
- Yakir
Best regards,
Krzysztof
Thanks
- Yakir
Best regards,
Krzysztof
#ifndef _ANALOGIX_DP_H_
#define _ANALOGIX_DP_H_
#include
+enum analogix_dp_devtype {
+EXYNOS_DP,
+RK3288_DP,
+};
+
struct analogix_dp_plat_data {
+enum analogix_dp_devtype dev_type;
struct drm_panel *panel;
int (*power_on)(struct analogix_dp_plat_data *);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps
On 20/08/15 09:26, Naoya Horiguchi wrote:
> Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> To solve this, this patch adds a new line for hugetlb usage like below:
>
> Size: 20480 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced:0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> HugetlbPages: 18432 kB
> Swap: 0 kB
> KernelPageSize: 2048 kB
> MMUPageSize:2048 kB
> Locked:0 kB
> VmFlags: rd wr mr mw me de ht
>
> Signed-off-by: Naoya Horiguchi
> Acked-by: Joern Engel
> Acked-by: David Rientjes
> ---
> v3 -> v4:
> - suspend Acked-by tag because v3->v4 change is not trivial
> - I stated in previous discussion that HugetlbPages line can contain page
> size info, but that's not necessary because we already have KernelPageSize
> info.
> - merged documentation update, where the current documentation doesn't mention
> AnonHugePages, so it's also added.
> ---
> Documentation/filesystems/proc.txt | 7 +--
> fs/proc/task_mmu.c | 29 +
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git v4.2-rc4/Documentation/filesystems/proc.txt
> v4.2-rc4_patched/Documentation/filesystems/proc.txt
> index 6f7fafde0884..22e40211ef64 100644
> --- v4.2-rc4/Documentation/filesystems/proc.txt
> +++ v4.2-rc4_patched/Documentation/filesystems/proc.txt
> @@ -423,6 +423,8 @@ Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 892 kB
> Anonymous: 0 kB
> +AnonHugePages: 0 kB
> +HugetlbPages: 0 kB
> Swap: 0 kB
> KernelPageSize:4 kB
> MMUPageSize: 4 kB
> @@ -440,8 +442,9 @@ indicates the amount of memory currently marked as
> referenced or accessed.
> "Anonymous" shows the amount of memory that does not belong to any file.
> Even
> a mapping associated with a file may contain anonymous pages: when
> MAP_PRIVATE
> and a page is modified, the file page is replaced by a private anonymous
> copy.
> -"Swap" shows how much would-be-anonymous memory is also used, but out on
> -swap.
> +"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
> +"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
> +"Swap" shows how much would-be-anonymous memory is also used, but out on
> swap.
There is no distinction between "private" and "shared" in this "huge page"
accounting right?
Would it be possible to account for the huge pages in the
{Private,Shared}_{Clean,Dirty} fields?
Or otherwise split the huge page accounting into shared/private?
thanks!
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] Add the driver of mbigen interrupt controller
Hi Alexey:
在 2015/9/4 8:56, Alexey Klimov 写道:
> Hi Ma Jun,
>
> On Tue, Sep 1, 2015 at 4:45 AM, majun (F) wrote:
>> Hi Alexey:
>>
[...]
+ mgn_chip->base = base;
+ mgn_chip->node = node;
+
+ domain = irq_domain_add_tree(node, _domain_ops, mgn_chip);
+ mgn_chip->domain = domain;
+
+ raw_spin_lock_init(_chip->lock);
+ INIT_LIST_HEAD(_chip->entry);
+ INIT_LIST_HEAD(_chip->mbigen_device_list);
+
+ for_each_child_of_node(node, child) {
+ mbigen_device_init(mgn_chip, child);
>>>
>>> You don't check error from mbigen_device_init()
>> I don't think we need to check errors here.
>> mbigen_device_init() handle all errors.
>
> For my eyes, mbigen_device_init() is static and used only once here.
> Here you don't check return value from it. If this is correct you can
> convert mbigen_device_init() to return void unless you have future
> plans to modify it.
>
> Or you have option to check return value here and add error path.
Ok, This will be changed in next version.
>
> Please add me to cc to next version of patch set which I guess will be v5.
>
Got it. I will add you to cc list in next version.
Thanks for you review !
Ma Jun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 5/5] perf probe: Print deleted events in cmd_probe()
>From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim
>
>Showing actual trace event when deleteing perf events is only needed in
>perf probe command. But the add functionality itself can be used by
>other places. So move the printing code into the cmd_probe().
>
>The output is not changed.
>
Looks good to me :)
Acked-by: Masami Hiramatsu
Thanks!
>Cc: Masami Hiramatsu
>Signed-off-by: Namhyung Kim
>---
> tools/perf/builtin-probe.c| 62 ++-
> tools/perf/util/probe-event.c | 5
> tools/perf/util/probe-event.h | 1 +
> tools/perf/util/probe-file.c | 7 +++--
> tools/perf/util/probe-file.h | 4 +++
> 5 files changed, 69 insertions(+), 10 deletions(-)
>
>diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
>index b8cf6cb7e1bf..ee2c46d8353e 100644
>--- a/tools/perf/builtin-probe.c
>+++ b/tools/perf/builtin-probe.c
>@@ -41,6 +41,7 @@
> #include "util/parse-options.h"
> #include "util/probe-finder.h"
> #include "util/probe-event.h"
>+#include "util/probe-file.h"
>
> #define DEFAULT_VAR_FILTER "!__k???tab_* & !__crc_*"
> #define DEFAULT_FUNC_FILTER "!_*"
>@@ -357,6 +358,65 @@ out_cleanup:
> return ret;
> }
>
>+static int perf_del_probe_events(struct strfilter *filter)
>+{
>+ int ret, ret2, ufd = -1, kfd = -1;
>+ char *str = strfilter__string(filter);
>+ struct strlist *klist = NULL, *ulist = NULL;
>+ struct str_node *ent;
>+
>+ if (!str)
>+ return -EINVAL;
>+
>+ pr_debug("Delete filter: \'%s\'\n", str);
>+
>+ /* Get current event names */
>+ ret = probe_file__open_both(, , PF_FL_RW);
>+ if (ret < 0)
>+ goto out;
>+
>+ klist = strlist__new(NULL, NULL);
>+ if (!klist)
>+ return -ENOMEM;
>+
>+ ret = probe_file__get_events(kfd, filter, klist);
>+ if (ret == 0) {
>+ strlist__for_each(ent, klist)
>+ pr_info("Removed event: %s\n", ent->s);
>+
>+ ret = probe_file__del_strlist(kfd, klist);
>+ if (ret < 0)
>+ goto error;
>+ }
>+
>+ ret2 = probe_file__get_events(ufd, filter, ulist);
>+ if (ret2 == 0) {
>+ strlist__for_each(ent, ulist)
>+ pr_info("Removed event: %s\n", ent->s);
>+
>+ ret2 = probe_file__del_strlist(ufd, ulist);
>+ if (ret2 < 0)
>+ goto error;
>+ }
>+
>+ if (ret == -ENOENT && ret2 == -ENOENT)
>+ pr_debug("\"%s\" does not hit any event.\n", str);
>+ /* Note that this is silently ignored */
>+ ret = 0;
>+
>+error:
>+ if (kfd >= 0)
>+ close(kfd);
>+ if (ufd >= 0)
>+ close(ufd);
>+out:
>+ strlist__delete(klist);
>+ strlist__delete(ulist);
>+ free(str);
>+
>+ return ret;
>+}
>+
> static int
> __cmd_probe(int argc, const char **argv, const char *prefix __maybe_unused)
> {
>@@ -529,7 +589,7 @@ __cmd_probe(int argc, const char **argv, const char
>*prefix __maybe_unused)
> return ret;
> #endif
> case 'd':
>- ret = del_perf_probe_events(params.filter);
>+ ret = perf_del_probe_events(params.filter);
> if (ret < 0) {
> pr_err_with_code(" Error: Failed to delete events.",
> ret);
> return ret;
>diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>index 01b9a5bd9449..3da9e1c792fa 100644
>--- a/tools/perf/util/probe-event.c
>+++ b/tools/perf/util/probe-event.c
>@@ -2819,8 +2819,6 @@ int del_perf_probe_events(struct strfilter *filter)
> if (!str)
> return -EINVAL;
>
>- pr_debug("Delete filter: \'%s\'\n", str);
>-
> /* Get current event names */
> ret = probe_file__open_both(, , PF_FL_RW);
> if (ret < 0)
>@@ -2835,9 +2833,6 @@ int del_perf_probe_events(struct strfilter *filter)
> ret = ret2;
> goto error;
> }
>- if (ret == -ENOENT && ret2 == -ENOENT)
>- pr_debug("\"%s\" does not hit any event.\n", str);
>- /* Note that this is silently ignored */
> ret = 0;
>
> error:
>diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
>index 610f743671e1..9bcea36359f2 100644
>--- a/tools/perf/util/probe-event.h
>+++ b/tools/perf/util/probe-event.h
>@@ -144,6 +144,7 @@ extern int convert_perf_probe_events(struct
>perf_probe_event *pevs, int npevs);
> extern int apply_perf_probe_events(struct perf_probe_event *pevs, int npevs);
> extern void cleanup_perf_probe_events(struct perf_probe_event *pevs, int
> npevs);
> extern int del_perf_probe_events(struct strfilter *filter);
>+
> extern int show_perf_probe_event(const char *group, const char *event,
>struct perf_probe_event *pev,
>const char *module, bool use_stdout);
>diff --git
Re: perf: fuzzer PEBS record without PEBS event! crash
On Sun, 6 Sep 2015, Stephane Eranian wrote: > > [ 1800.285152] [ cut here ] > > [ 1800.290757] WARNING: CPU: 0 PID: 0 at > > arch/x86/kernel/cpu/perf_event_intel_ds.c:1210 > > intel_pmu_drain_pebs_nhm+0x305/0x320() > > [ 1800.303301] PEBS record without PEBS event! status=2 pebs_enabled=1 > > active_mask=2 > > [ 1800.311916] Modules linked in: binfmt_misc intel_rapl iosf_mbi > > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm > > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi hmac > > drbg ansi_cprng i915 aesni_intel aes_x86_64 snd_hda_codec_realtek > > snd_hda_codec_generic lrw snd_hda_intel snd_hda_codec iTCO_wdt gf128mul > > drm_kms_helper snd_hda_core ppdev iTCO_vendor_support evdev glue_helper > > ablk_helper cryptd parport_pc snd_hwdep snd_pcm snd_timer psmouse tpm_tis > > tpm drm i2c_algo_bit sg parport snd pcspkr video serio_raw processor > > soundcore mei_me lpc_ich mfd_core mei i2c_i801 wmi button battery sr_mod > > sd_mod cdrom ehci_pci ehci_hcd xhci_pci xhci_hcd ahci libahci libata e1000e > > ptp usbcore crc32c_intel scsi_mod pps_core usb_common fan thermal > > [ 1800.390813] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW > > 4.2.0+ #173 > > [ 1800.399488] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS > > 01/26/2014 > > [ 1800.408243] 81a0d828 88011ea03aa8 8169da0c > > 88011ea03af0 > > [ 1800.417089] 88011ea03ae0 8106e812 0001 > > 88011900 > > [ 1800.426024] 88011ea0c120 88011900ffc0 88011900 > > 88011ea03b40 > > [ 1800.434946] Call Trace: > > [ 1800.438453][] dump_stack+0x44/0x55 > > [ 1800.445504] [] warn_slowpath_common+0x82/0xc0 > > [ 1800.452832] [] warn_slowpath_fmt+0x4c/0x50 > > [ 1800.459879] [] intel_pmu_drain_pebs_nhm+0x305/0x320 > > [ 1800.467725] [] ? __lock_acquire.isra.31+0x349/0xfc0 > > [ 1800.475613] [] intel_pmu_drain_pebs_buffer+0x18/0x20 > > > What would help here is if you could get the source line number. You can do > that > with gdb: > gdb vmlinux > (gdb) info line *0x8102ec38 (gdb) info line *0x8102ec38 Line 567 of "arch/x86/kernel/cpu/perf_event_intel_ds.c" starts at address 0x8102ec38 and ends at 0x8102ec40 . Line 567 isn't that helpful, it's just the last line of intel_pmu_drain_pebs_buffer() but that's possibly because I have done a git pull since the time I built the kernel so the source tree doesn't match up. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] ARM: imx_v6_v7_defconfig: enable imx6ul_tsc
On Fri, Aug 28, 2015 at 05:09:34PM +0800, Haibo Chen wrote: > Enable imx6ul touchscreen controller > > Signed-off-by: Haibo Chen Applied 3 ~ 5, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
On 06.09.2015 16:49, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 09/04/2015 08:41 AM, Krzysztof Kozlowski 写道:
>> On 03.09.2015 14:30, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> 在 09/03/2015 08:58 AM, Krzysztof Kozlowski 写道:
On 01.09.2015 14:49, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge
> directory, and rename the core driver to analogix_dp_*,
> leave the platform code to analogix_dp-exynos.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT
> propery.
> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
> "exynos_dp.c"
> - Take Archit suggest, create a separate folder for analogix code in
> bridge/
>
> Changes in v3:
> - Take Thierry Reding suggest, move exynos's video_timing code
> to analogix_dp-exynos platform driver, add get_modes method
> to struct analogix_dp_plat_data.
> - Take Heiko suggest, rename some "samsung*" dts propery to
> "analogix*".
>
> Changes in v2:
> - Take Jingoo Han suggest, remove new copyright
> - Fix compiled failed dut to analogix_dp_device misspell
>
> [.]
>
> -static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
> +static int analogix_dp_bridge_attach(struct drm_bridge *bridge)
>{
> -struct exynos_dp_device *dp = bridge->driver_private;
> -struct drm_encoder *encoder = >encoder;
> +struct analogix_dp_device *dp = bridge->driver_private;
> +struct drm_encoder *encoder = dp->encoder;
>struct drm_connector *connector = >connector;
>int ret;
>-/* Pre-empt DP connector creation if there's a bridge */
> -if (dp->ptn_bridge) {
> -ret = exynos_drm_attach_lcd_bridge(dp, encoder);
> -if (!ret)
> -return 0;
> +if (!bridge->encoder) {
> +DRM_ERROR("Parent encoder object not found");
> +return -ENODEV;
>}
>+encoder->bridge = bridge;
> +
>connector->polled = DRM_CONNECTOR_POLL_HPD;
> ret = drm_connector_init(dp->drm_dev, connector,
> - _dp_connector_funcs,
> + _dp_connector_funcs,
> DRM_MODE_CONNECTOR_eDP);
>if (ret) {
>DRM_ERROR("Failed to initialize connector with drm\n");
>return ret;
>}
>-drm_connector_helper_add(connector,
> _dp_connector_helper_funcs);
> +drm_connector_helper_add(connector,
> + _dp_connector_helper_funcs);
>drm_connector_register(connector);
>drm_mode_connector_attach_encoder(connector, encoder);
>-if (dp->panel)
> -ret = drm_panel_attach(dp->panel, >connector);
> +if (dp->plat_data && dp->plat_data->panel) {
> +ret = drm_panel_attach(dp->plat_data->panel, >connector);
> +if (ret) {
> +DRM_ERROR("Failed to attach panel\n");
> +return ret;
> +}
> +}
> +
> +/*
> + * This should be the end of attach function, caused
> + * we should ensure dp bridge could attach first.
> + */
> + if (dp->plat_data && dp->plat_data->attach) {
> + ret = dp->plat_data->attach(dp->plat_data, bridge);
> + if (ret) {
> + DRM_ERROR("Failed at platform attch func\n");
Two new error paths appeared here and above. Don't you have to
cleanup something? I don't know, just wondering...
>>> Hmm... I think both panel & platform_attch need ERROR remind when
>>> it failed. But if it still need clean, I though it should clean the
>>> platform attch
>>> error,
>>> this is not relate to DRM directly, just analogix driver logic, so
>>> code would like,
>>>
>>> -if (dp->panel)
>>> -ret = drm_panel_attach(dp->panel, >connector);
>>> +if (dp->plat_data && dp->plat_data->panel) {
>>> +ret = drm_panel_attach(dp->plat_data->panel, >connector);
>>> +if (ret) {
>>> +DRM_ERROR("Failed to attach panel\n");
>>> +return ret;
>>> +}
>>> +}
>>>
>>> +/*
>>> + * This should be the end of attach function, caused
>>> + * we should ensure dp bridge could attach first.
>>> + */
>>> + if (dp->plat_data && dp->plat_data->attach) {
>>> + ret = dp->plat_data->attach(dp->plat_data, bridge);
>>>
>>>return ret;
>> I am lost... the code looks the same. What did you change?
>
> I just remove the DRM_ERROR after dp->plat_data->attach(),
> maybe I should paste the change that rebase on this patch,
> here are they,
>
> /*
> * This should be the end of attach function, caused
> * we should ensure dp bridge could attach first.
> */
> - if (dp->plat_data && dp->plat_data->attach)
Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression
On Fri, 04 Sep 2015, Peter Zijlstra wrote:
-static inline bool virt_queued_spin_lock(struct qspinlock *lock)
+static inline bool virt_spin_lock(struct qspinlock *lock)
Given that we fall back to the cmpxchg loop even when PARAVIRT is not in the
picture, I believe this function is horribly misnamed.
{
if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
return false;
- while (atomic_cmpxchg(>val, 0, _Q_LOCKED_VAL) != 0)
- cpu_relax();
+ /*
+* On hypervisors without PARAVIRT_SPINLOCKS support we fall
+* back to a Test-and-Set spinlock, because fair locks have
+* horrible lock 'holder' preemption issues.
+*/
+
This comment is also misleading... but if you tuck the whole function
under some PARAVIRT option, it obviously makes sense to just leave as is.
And let native actually _use_ qspinlocks.
+ do {
+ while (atomic_read(>val) != 0)
+ cpu_relax();
+ } while (atomic_cmpxchg(>val, 0, _Q_LOCKED_VAL) != 0);
CCAS to the rescue again.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
On 07.09.2015 05:16, Sjoerd Simons wrote: > The DesignWare HS OTG USB 2.0 is used in various SoC families among wich > the various rockchip SoCs, enable the driver and the PHY glue for > rockchip > > Signed-off-by: Sjoerd Simons > > --- > > arch/arm/configs/multi_v7_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index fb673e2..49c733a 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -514,6 +514,7 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_DWC3=y > CONFIG_USB_CHIPIDEA=y > CONFIG_USB_CHIPIDEA_HOST=y > +CONFIG_USB_DWC2=y +Cc Marek and Kukjin, This would conflict with Marek's: [PATCH v2] ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB ethernet gadget http://www.spinics.net/lists/linux-samsung-soc/msg46743.html Probably your series and Marek's change should go together to the same tree. How about rebasing your work on top of it? Best regards, Krzysztof > CONFIG_AB8500_USB=y > CONFIG_KEYSTONE_USB_PHY=y > CONFIG_OMAP_USB3=y > @@ -658,6 +659,7 @@ CONFIG_PHY_HIX5HD2_SATA=y > CONFIG_PWM_STI=m > CONFIG_OMAP_USB2=y > CONFIG_TI_PIPE3=y > +CONFIG_PHY_ROCKCHIP_USB=y > CONFIG_PHY_MIPHY28LP=y > CONFIG_PHY_MIPHY365X=y > CONFIG_PHY_RCAR_GEN2=m > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Kconfig: remove BE-only platforms from LE kernel build
Currently, little endian is only supported on powernv and pseries, however, Kconfigs still allow us to include other platforms in a LE kernel, this may result in space wasting or even build error if some BE-only platforms always assume they are built for a BE kernel. So just modify the Kconfigs of BE-only platforms to remove them from being built for a LE kernel. For 32bit only platforms, nothing needs to be done, because CPU_LITTLE_ENDIAN depends on PPC64. For 64bit supported platforms, add CPU_BIG_ENDIAN to dependencies explicitly, so that these platforms will be disabled for LE [Suggested-by: Cédric Le Goater ]. Signed-off-by: Boqun Feng --- arch/powerpc/platforms/cell/Kconfig | 4 ++-- arch/powerpc/platforms/maple/Kconfig| 2 +- arch/powerpc/platforms/pasemi/Kconfig | 2 +- arch/powerpc/platforms/powermac/Kconfig | 2 +- arch/powerpc/platforms/ps3/Kconfig | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig index 2f23133..808a904 100644 --- a/arch/powerpc/platforms/cell/Kconfig +++ b/arch/powerpc/platforms/cell/Kconfig @@ -25,7 +25,7 @@ config PPC_CELL_NATIVE config PPC_IBM_CELL_BLADE bool "IBM Cell Blade" - depends on PPC64 && PPC_BOOK3S + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN select PPC_CELL_NATIVE select PPC_OF_PLATFORM_PCI select PCI @@ -35,7 +35,7 @@ config PPC_IBM_CELL_BLADE config PPC_CELL_QPACE bool "IBM Cell - QPACE" - depends on PPC64 && PPC_BOOK3S + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN select PPC_CELL_COMMON config AXON_MSI diff --git a/arch/powerpc/platforms/maple/Kconfig b/arch/powerpc/platforms/maple/Kconfig index 1ea621a..e359d0d 100644 --- a/arch/powerpc/platforms/maple/Kconfig +++ b/arch/powerpc/platforms/maple/Kconfig @@ -1,5 +1,5 @@ config PPC_MAPLE - depends on PPC64 && PPC_BOOK3S + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN bool "Maple 970FX Evaluation Board" select PCI select MPIC diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig index a2aeb32..00d4b28 100644 --- a/arch/powerpc/platforms/pasemi/Kconfig +++ b/arch/powerpc/platforms/pasemi/Kconfig @@ -1,5 +1,5 @@ config PPC_PASEMI - depends on PPC64 && PPC_BOOK3S + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN bool "PA Semi SoC-based platforms" default n select MPIC diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig index 607124b..43c6062 100644 --- a/arch/powerpc/platforms/powermac/Kconfig +++ b/arch/powerpc/platforms/powermac/Kconfig @@ -1,6 +1,6 @@ config PPC_PMAC bool "Apple PowerMac based machines" - depends on PPC_BOOK3S + depends on PPC_BOOK3S && CPU_BIG_ENDIAN select MPIC select PCI select PPC_INDIRECT_PCI if PPC32 diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig index 56f2740..b27f40f 100644 --- a/arch/powerpc/platforms/ps3/Kconfig +++ b/arch/powerpc/platforms/ps3/Kconfig @@ -1,6 +1,6 @@ config PPC_PS3 bool "Sony PS3" - depends on PPC64 && PPC_BOOK3S + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN select PPC_CELL select USB_OHCI_LITTLE_ENDIAN select USB_OHCI_BIG_ENDIAN_MMIO -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support
On 06.09.2015 13:07, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 09/04/2015 08:36 AM, Krzysztof Kozlowski 写道:
>> On 01.09.2015 15:07, Yakir Yang wrote:
>>
>> Empty commit message. Please explain here why you want to add platform
>> device type support.
>>
>> Actually the title is confusing. You are not adding support for platform
>> device types but rather adding a field containing type of device.
>>
>>
>>> Signed-off-by: Yakir Yang
>>> ---
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2:
>>> - Add GNU license v2 declared and samsung copyright
>>>
>>> drivers/gpu/drm/exynos/exynos_dp.c | 1 +
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 +
>>> include/drm/bridge/analogix_dp.h| 16
>>> 3 files changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
>>> b/drivers/gpu/drm/exynos/exynos_dp.c
>>> index 6060d2c..40ef727 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
>>> @@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev,
>>> struct device *master, void *data)
>>> dp->dev = dev;
>>> dp->drm_dev = drm_dev;
>>> +dp->plat_data.dev_type = EXYNOS_DP;
>>> dp->plat_data.power_on = exynos_dp_poweron;
>>> dp->plat_data.power_off = exynos_dp_poweroff;
>>> dp->plat_data.get_modes = exynos_dp_get_modes;
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index efea045..4934271 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev,
>>> struct device *master,
>>> return ret;
>>> }
>>> +dp->plat_data.dev_type = RK3288_DP;
>>> dp->plat_data.attach = NULL;
>>> dp->plat_data.get_modes = NULL;
>>> dp->plat_data.power_on = rockchip_dp_poweron;
>>> diff --git a/include/drm/bridge/analogix_dp.h
>>> b/include/drm/bridge/analogix_dp.h
>>> index 8b4ffad..7209a64 100644
>>> --- a/include/drm/bridge/analogix_dp.h
>>> +++ b/include/drm/bridge/analogix_dp.h
>>> @@ -1,9 +1,25 @@
>>> +/*
>>> + * Analogix Core DP (Display Port) interface driver.
>>> + *
>>> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify it
>>> + * under the terms of the GNU General Public License as published by
>>> the
>>> + * Free Software Foundation; either version 2 of the License, or (at
>>> your
>>> + * option) any later version.
>>> + */
>> Two questions:
>> 1. Why this change is here? I would rather expect it at patch 3/16 when
>> you created this file... That is the usual time for adding copyrights.
>
> Yep, I should move this to 03/16.
>
>> 2. Does this file contains previous Samsung work?
>
> Hmm... I think this haven't contains the previous Samsung works,
> but I have the cover the head message from analogix_dp_core driver
> (include the copyright, but without ant author).
If it does not contain Samsung's work then don't mention its copyrights.
Best regards,
Krzysztof
>
> Thanks
> - Yakir
>
>> Best regards,
>> Krzysztof
>>
>>> #ifndef _ANALOGIX_DP_H_
>>> #define _ANALOGIX_DP_H_
>>> #include
>>> +enum analogix_dp_devtype {
>>> +EXYNOS_DP,
>>> +RK3288_DP,
>>> +};
>>> +
>>> struct analogix_dp_plat_data {
>>> +enum analogix_dp_devtype dev_type;
>>> struct drm_panel *panel;
>>> int (*power_on)(struct analogix_dp_plat_data *);
>>>
>>
>>
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: fix alignement of __bug_table section entries
On Sun, Sep 06, 2015 at 11:31:34PM +0200, Robert Jarzmik wrote: > Russell King - ARM Linux writes: > > >> [1] Approach 1 : translation table sync > >> === > ... > > The important place is in arch/arm/include/asm/domain.h, which is where > > we manipulate the DACR within probe_kernel_address(). > > Gah, silly me. But even with [1], I still get an error [2]. I have a > confirmation that I have a "Page Permission" fault on the > probe_kernel_address(). Hmm, that's not right. If it's the DACR, then it should be a page domain fault, not a page permission fault. > [2] Oops > > # insmod /tmp/unalign.ko > RJK1: fsr=23 far=e1c23643 dacr=51 > RJK2: fsr=23 far=e1c23643 dacr=51 > RJK3: fsr=2f far=bf00202c dacr=51 > RJK: fault=4 instr=0x instrptr=bf00202c Can you add a show_pte(current->mm, instrptr) to dump those page table entries please? -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression
On Fri, Sep 04, 2015 at 01:32:33PM +0200, Peter Zijlstra wrote: > On Fri, Sep 04, 2015 at 06:12:34PM +1000, Dave Chinner wrote: > > You probably don't even need a VM to reproduce it - that would > > certainly be an interesting counterpoint if it didn't > > Even though you managed to restore your DEBUG_SPINLOCK performance by > changing virt_queued_spin_lock() to use __delay(1), I ran the thing on > actual hardware just to test. > > [ Note: In any case, I would recommend you use (or at least try) > PARAVIRT_SPINLOCKS if you use VMs, as that is where we were looking for > performance, the test-and-set fallback really wasn't meant as a > performance option (although it clearly sucks worse than expected). FSUse%Count SizeFiles/sec App Overhead 0 1600 319431.5 10116018 0 3200 307824.5 10054299 0 4800 296971.5 10770197 0 6400 281653.6 11748423 PARAVIRT_SPINLOCKS seems to work OK these days, too. I'll leave that set so I'll end up testing whatever comes along down that pipe... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator
On Thu, Sep 03, 2015 at 03:25:11PM +0530, Kishon Vijay Abraham I wrote: > PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4, > OMAP5 and DRA7 SoCs. Enable it here. > > Signed-off-by: Kishon Vijay Abraham I Tested-by: Guenter Roeck > --- > arch/arm/configs/multi_v7_defconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 5fd8df6..f497c96 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y > CONFIG_REGULATOR_MAX77686=y > CONFIG_REGULATOR_MAX77693=m > CONFIG_REGULATOR_PALMAS=y > +CONFIG_REGULATOR_PBIAS=y > CONFIG_REGULATOR_S2MPS11=y > CONFIG_REGULATOR_S5M8767=y > CONFIG_REGULATOR_TPS51632=y > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression
On Fri, Sep 04, 2015 at 05:25:23PM +0200, Peter Zijlstra wrote: > Something like so... > > --- > Subject: locking: Fix virt test-and-set lock implementation > > Dave ran into horrible performance on a VM without PARAVIRT_SPINLOCKS > set and Linus noted that the test-and-set implementation was retarded. > > One should spin on the variable with a load, not a rmw. > > While there, remove the queued from the name, as the lock isn't queued > at all, but a simple test-and-set. > > Reported-by: Dave Chinner > Suggested-by: Linus Torvalds > Signed-off-by: Peter Zijlstra (Intel) FSUse%Count SizeFiles/sec App Overhead 0 1600 319511.8 9398733 0 3200 301517.9 9516230 0 4800 300357.6 9676651 0 6400 282167.8 11513255 Looks OK. Tested-by: Dave Chinner Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] staging: slimport: Add anx7814 driver support by analogix.
On Sun, Sep 06, 2015 at 11:14:02PM +0200, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > This driver adds initial support and supports HDMI to DP pass-through mode. > > Signed-off-by: Enric Balletbo i Serra > --- > drivers/staging/Kconfig|2 + > drivers/staging/Makefile |1 + > drivers/staging/slimport/Kconfig |7 + > drivers/staging/slimport/Makefile |4 + > drivers/staging/slimport/slimport.c| 301 +++ > drivers/staging/slimport/slimport.h| 49 + > drivers/staging/slimport/slimport_tx_drv.c | 3293 > > drivers/staging/slimport/slimport_tx_drv.h | 254 +++ > drivers/staging/slimport/slimport_tx_reg.h | 786 +++ Why is this a staging driver? What prevents it from being merged into the "real" part of the kernel tree? All staging drivers need a TODO file, listing what needs to be done and who is in charge of it. I can't take this without that added. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: UAPI: Fix unrecognized opcode WSBH/DSBH/DSHD when using MIPS16.
On Sun, 6 Sep 2015, Yousong Zhou wrote: > Hi, Maciej, first of all, thank you for your time on this, > appreciate it. You're welcome! > > The bug certainly was there, it's just your analysis and consequently the > > fix that are wrong in the general case for some reason, maybe a buggy > > compiler. > > > > This is the compiler "--version", > > mips-openwrt-linux-gcc (OpenWrt/Linaro GCC 4.8-2014.04 r46763) 4.8.3 A-ha! I've checked GCC's history and the symptom you're seeing was PR target/55777: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777 and the bug has only been fixed pretty recently (r199328), already after GCC 4.8 has branched. From your troubles I infer the fix has not been backported to 4.8 and therefore is only available from GCC 4.9 up; of course either you or OpenWrt can still backport it and apply locally. Fortunately as I noted you need not dive into that hole as the reasonable choice here is to avoid the asm for MIPS16 code altogether, regardless of the GCC bug. > > Now if you stick `.set nomips16' just above WSBH, then this code will > > happily assemble, because this single instruction only (`.set pop' reverts > > any previous `.set' directives; I'm assuming you wrote above by hand and > > `.pop' is a typo) will assemble in the regular MIPS instruction mode. But > > if this code is ever reached, then the processor will still execute the > > machine code produced by the assembler from the WSBH instruction in the > > MIPS16 mode. > > Yes, I hand-copied it from the output of "gcc -S" just to > show the form/pattern (the original output is too long for > this conversation). No, that `.pop' is not a typo (I just > did a double-check). Well, please check again then as there's no such pseudo-op: $ cat pop.s .pop $ mips-mti-linux-gnu-as -o pop.o pop.s pop.s: Assembler messages: pop.s:1: Error: unknown pseudo-op: `.pop' $ > > No, it's your bug after all. I think the last paragraph I wrote quoted > > above combined with the source code in question make it clear what to do. > > Okay, I will try. Most of the time when textbooks read > clearly/obviously/apparently, things go astray ;) Well, if you really find yourself stuck with it, then come back for more hints, however please do try figuring it out yourself first as it'll be a good exercise. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] binfmt_elf: Don't clobber passed executable's file header
Do not clobber the buffer space passed from `search_binary_handler' and
originally preloaded by `prepare_binprm' with the executable's file
header by overwriting it with its interpreter's file header. Instead
keep the buffer space intact and directly use the data structure locally
allocated for the interpreter's file header, fixing a bug introduced in
2.1.14 with loadable module support (linux-mips.org commit beb11695
[Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
Adjust the amount of data read from the interpreter's file accordingly.
This was not an issue before loadable module support, because back then
`load_elf_binary' was executed only once for a given ELF executable,
whether the function succeeded or failed.
With loadable module support supported and enabled, upon a failure of
`load_elf_binary' -- which may for example be caused by architecture
code rejecting an executable due to a missing hardware feature requested
in the file header -- a module load is attempted and then the function
reexecuted by `search_binary_handler'. With the executable's file
header replaced with its interpreter's file header the executable can
then be erroneously accepted in this subsequent attempt.
Signed-off-by: Maciej W. Rozycki
---
Al,
The bug (which has already reached its adulthood) was discovered with
an upcoming MIPS feature which this fix is a prerequisite for.
Please apply.
Maciej
linux-load-elf-binary-interp-buf-fix.diff
Index: linux-org-test/fs/binfmt_elf.c
===
--- linux-org-test.orig/fs/binfmt_elf.c 2015-07-18 00:11:13.0 +0100
+++ linux-org-test/fs/binfmt_elf.c 2015-07-18 00:32:41.509841000 +0100
@@ -759,16 +759,16 @@ static int load_elf_binary(struct linux_
*/
would_dump(bprm, interpreter);
- retval = kernel_read(interpreter, 0, bprm->buf,
-BINPRM_BUF_SIZE);
- if (retval != BINPRM_BUF_SIZE) {
+ /* Get the exec headers */
+ retval = kernel_read(interpreter, 0,
+>interp_elf_ex,
+sizeof(loc->interp_elf_ex));
+ if (retval != sizeof(loc->interp_elf_ex)) {
if (retval >= 0)
retval = -EIO;
goto out_free_dentry;
}
- /* Get the exec headers */
- loc->interp_elf_ex = *((struct elfhdr *)bprm->buf);
break;
}
elf_ppnt++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/3] KVM: dynamic halt-polling
On 9/6/15 10:32 PM, Paolo Bonzini wrote:
On 05/09/2015 00:38, Wanpeng Li wrote:
@@ -1940,11 +1975,16 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
* arrives.
*/
if (kvm_vcpu_check_block(vcpu) < 0) {
+polled = true;
++vcpu->stat.halt_successful_poll;
-goto out;
+break;
}
cur = ktime_get();
} while (single_task_running() && ktime_before(cur, stop));
+
+poll_ns = ktime_to_ns(cur) - ktime_to_ns(start);
+if (polled)
+goto out;
Please move poll_ns caculation under if() when you applied, as I
explained in reply to v6.
You can do much more than just that, the patch reduces to this:
Cool, many thanks for your help, Paolo! :)
Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] binfmt_elf: Correct `arch_check_elf's description
Correct `arch_check_elf's description, mistakenly copied and pasted from `arch_elf_pt_proc'. Signed-off-by: Maciej W. Rozycki --- linux-arch-check-elf-doc-fix.diff Index: linux-org-test/fs/binfmt_elf.c === --- linux-org-test.orig/fs/binfmt_elf.c 2015-07-17 15:04:19.855789000 +0100 +++ linux-org-test/fs/binfmt_elf.c 2015-07-17 15:04:55.14710 +0100 @@ -487,7 +487,7 @@ static inline int arch_elf_pt_proc(struc } /** - * arch_check_elf() - check a PT_LOPROC..PT_HIPROC ELF program header + * arch_check_elf() - check an ELF executable * @ehdr: The main ELF header * @has_interp:True if the ELF has an interpreter, else false. * @state: Architecture-specific state preserved throughout the process -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 1/4] genirq: Introduce irq_settings_set_move_pcntxt() helper
On Sun, 6 Sep 2015, Yang Yingliang wrote: > It's expected to use the helper when interrupt can be moved > in process. What's wrong with using the existing helper? irq_set_status_flags(irq, IRQ_MOVE_PCNTXT); Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Documentation: add Device tree bindings for hwmon/nct7802
Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names
Introduced in v1:
- nct7802,reg-init
Signed-off-by: Constantine Shulyupin
---
---
.../devicetree/bindings/hwmon/nct7802.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt
b/Documentation/devicetree/bindings/hwmon/nct7802.txt
new file mode 100644
index 000..56214bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
@@ -0,0 +1,24 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+One byte registers:
+ - nct7802,Start
+ - nct7802,Mode
+ - nct7802,EnPECI
+ - nct7802,EnFan
+ - nct7802,EnV
+
+Example nct7802 node:
+
+nct7802 {
+ compatible = "nuvoton,nct7802";
+ reg = <0x2a>;
+ nct7802,Start = <0x01>;
+ nct7802,Mode = <0x7E>; // RTD1_MD = 2
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf: fuzzer PEBS record without PEBS event! crash
Hi Vince, On Thu, Sep 3, 2015 at 11:04 PM, Vince Weaver wrote: > > Hello > > running a fresh copy of current git and I can still crash my Haswell test > machine using the perf_fuzzer. > > It looks like the pebs issue still, it triggered the new warning, and > was stuck looping with these messages until I rebooted the system. > I do not have access to my Haswell Desktop machine right. I will run the test case once I get access to it again. > > [ 1800.285152] [ cut here ] > [ 1800.290757] WARNING: CPU: 0 PID: 0 at > arch/x86/kernel/cpu/perf_event_intel_ds.c:1210 > intel_pmu_drain_pebs_nhm+0x305/0x320() > [ 1800.303301] PEBS record without PEBS event! status=2 pebs_enabled=1 > active_mask=2 > [ 1800.311916] Modules linked in: binfmt_misc intel_rapl iosf_mbi > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul > crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi hmac drbg ansi_cprng i915 > aesni_intel aes_x86_64 snd_hda_codec_realtek snd_hda_codec_generic lrw > snd_hda_intel snd_hda_codec iTCO_wdt gf128mul drm_kms_helper snd_hda_core > ppdev iTCO_vendor_support evdev glue_helper ablk_helper cryptd parport_pc > snd_hwdep snd_pcm snd_timer psmouse tpm_tis tpm drm i2c_algo_bit sg parport > snd pcspkr video serio_raw processor soundcore mei_me lpc_ich mfd_core mei > i2c_i801 wmi button battery sr_mod sd_mod cdrom ehci_pci ehci_hcd xhci_pci > xhci_hcd ahci libahci libata e1000e ptp usbcore crc32c_intel scsi_mod > pps_core usb_common fan thermal > [ 1800.390813] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.2.0+ > #173 > [ 1800.399488] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS > 01/26/2014 > [ 1800.408243] 81a0d828 88011ea03aa8 8169da0c > 88011ea03af0 > [ 1800.417089] 88011ea03ae0 8106e812 0001 > 88011900 > [ 1800.426024] 88011ea0c120 88011900ffc0 88011900 > 88011ea03b40 > [ 1800.434946] Call Trace: > [ 1800.438453][] dump_stack+0x44/0x55 > [ 1800.445504] [] warn_slowpath_common+0x82/0xc0 > [ 1800.452832] [] warn_slowpath_fmt+0x4c/0x50 > [ 1800.459879] [] intel_pmu_drain_pebs_nhm+0x305/0x320 > [ 1800.467725] [] ? __lock_acquire.isra.31+0x349/0xfc0 > [ 1800.475613] [] intel_pmu_drain_pebs_buffer+0x18/0x20 What would help here is if you could get the source line number. You can do that with gdb: gdb vmlinux (gdb) info line *0x8102ec38 > > [ 1800.483550] [] ? __lock_acquire.isra.31+0x349/0xfc0 > [ 1800.491334] [] ? perf_event_update_userpage+0xff/0x170 > [ 1800.499471] [] ? debug_object_activate+0xe4/0x1c0 > [ 1800.507184] [] ? intel_stop_scheduling+0x4a/0x70 > [ 1800.514756] [] ? perf_assign_events+0x14a/0x2a0 > [ 1800.522238] [] intel_pmu_pebs_disable+0xf3/0x110 > [ 1800.529812] [] intel_pmu_disable_event+0x11b/0x120 > [ 1800.537551] [] x86_pmu_stop+0x69/0xc0 > [ 1800.544106] [] x86_pmu_enable+0x9f/0x2f0 > [ 1800.550894] [] perf_pmu_enable.part.78+0x7/0x10 > [ 1800.558425] [] perf_pmu_enable+0x21/0x30 > [ 1800.565250] [] x86_pmu_commit_txn+0x78/0xa0 > [ 1800.572352] [] ? debug_object_activate+0x8e/0x1c0 > [ 1800.580035] [] ? __lock_acquire.isra.31+0x349/0xfc0 > [ 1800.587892] [] ? hrtimer_start_range_ns+0x1bc/0x3b0 > [ 1800.595692] [] ? event_sched_in.isra.84+0xf0/0x310 > [ 1800.603470] [] group_sched_in+0x1a2/0x1c0 > [ 1800.610424] [] __perf_event_enable+0x25a/0x290 > [ 1800.617823] [] ? cpu_clock_event_start+0x30/0x30 > [ 1800.625417] [] remote_function+0x3a/0x40 > [ 1800.632238] [] flush_smp_call_function_queue+0x7f/0x160 > [ 1800.640448] [] > generic_smp_call_function_single_interrupt+0x13/0x60 > [ 1800.649816] [] > smp_trace_call_function_single_interrupt+0x34/0xb0 > [ 1800.658950] [] > trace_call_function_single_interrupt+0x82/0x90 > [ 1800.667678][] ? cpuidle_enter_state+0x130/0x270 > [ 1800.676002] [] ? cpuidle_enter_state+0x10b/0x270 > [ 1800.683645] [] cpuidle_enter+0x17/0x20 > [ 1800.690274] [] call_cpuidle+0x32/0x60 > [ 1800.696781] [] ? cpuidle_select+0x13/0x20 > [ 1800.703655] [] cpu_startup_entry+0x216/0x2d0 > [ 1800.710809] [] rest_init+0xb8/0xc0 > [ 1800.716949] [] start_kernel+0x447/0x454 > [ 1800.723593] [] ? early_idt_handler_array+0x120/0x120 > [ 1800.731414] [] x86_64_start_reservations+0x2a/0x2c > [ 1800.739055] [] x86_64_start_kernel+0x13b/0x14a > [ 1800.746311] ---[ end trace 852faffdf2d3f87f ]--- > [ 1800.751912] [ cut here ] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: fix alignement of __bug_table section entries
Russell King - ARM Linux writes:
>> [1] Approach 1 : translation table sync
>> ===
...
> The important place is in arch/arm/include/asm/domain.h, which is where
> we manipulate the DACR within probe_kernel_address().
Gah, silly me. But even with [1], I still get an error [2]. I have a
confirmation that I have a "Page Permission" fault on the
probe_kernel_address().
Next thing I'll check is if I can read the TLB cache for the code entry. It's a
very instructive bug for me :)
Cheers.
--
Robert
[1] Approach 1 : translation table sync + PrefetchFlush
===
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 7bbf325a4f31..73d5ad456e32 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -449,6 +449,13 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
#endif
.endm
+ .macro dacr_sync, rd
+ mrc p15, 0, \rd, c2, c0, 0
+ mov \rd, \rd
+ sub pc, pc, #4
+ mcr p15, 0, \rd, c7, c5, 4
+ .endm
+
.macro uaccess_disable, tmp, isb=1
#ifdef CONFIG_CPU_SW_DOMAIN_PAN
/*
@@ -457,6 +464,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
*/
mov \tmp, #DACR_UACCESS_DISABLE
mcr p15, 0, \tmp, c3, c0, 0 @ Set domain register
+ dacr_sync \tmp
.if \isb
instr_sync
.endif
@@ -471,6 +479,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
*/
mov \tmp, #DACR_UACCESS_ENABLE
mcr p15, 0, \tmp, c3, c0, 0
+ dacr_sync \tmp
.if \isb
instr_sync
.endif
@@ -488,6 +497,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
#ifdef CONFIG_CPU_SW_DOMAIN_PAN
ldr r0, [sp, #S_FRAME_SIZE]
mcr p15, 0, r0, c3, c0, 0
+ dacr_sync r0
#endif
.endm
diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h
index e878129f2fee..10c9a38636ac 100644
--- a/arch/arm/include/asm/domain.h
+++ b/arch/arm/include/asm/domain.h
@@ -97,7 +97,11 @@ static inline unsigned int get_domain(void)
static inline void set_domain(unsigned val)
{
asm volatile(
- "mcrp15, 0, %0, c3, c0 @ set domain"
+ "mcrp15, 0, %0, c3, c0; @ set domain\
+ mrc p15, 0, %0, c2, c0, 0; \
+ mov %0, %0; \
+ sub pc, pc, #4; \
+ mcr p15, 0, %0, c7, c5, 4"
: : "r" (val));
isb();
}
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 9769f1eefe3b..c9c454129344 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -747,6 +747,27 @@ do_alignment_t32_to_handler(unsigned long *pinstr, struct
pt_regs *regs,
return NULL;
}
+static u32 far_read(void)
+{
+u32 far;
+asm("mrcp15, 0, %0, c6, c0, 0" : "=r" (far));
+return far;
+}
+
+static u32 fsr_read(void)
+{
+u32 fsr;
+asm("mrcp15, 0, %0, c5, c0, 0" : "=r" (fsr));
+return fsr;
+}
+
+static u32 dacr_read(void)
+{
+u32 dacr;
+asm("mrcp15, 0, %0, c3, c0, 0" : "=r" (dacr));
+return dacr;
+}
+
static int
do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
{
@@ -763,6 +784,8 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
local_irq_enable();
instrptr = instruction_pointer(regs);
+ pr_info("RJK1: fsr=%x far=%x dacr=%x\n", fsr_read(), far_read(),
dacr_read());
+ pr_info("RJK2: fsr=%x far=%x dacr=%x\n", fsr_read(), far_read(),
dacr_read());
if (thumb_mode(regs)) {
u16 *ptr = (u16 *)(instrptr & ~1);
@@ -787,6 +810,8 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
instr = __mem_to_opcode_arm(instr);
}
+ pr_info("RJK3: fsr=%x far=%x dacr=%x\n", fsr_read(), far_read(),
dacr_read());
+ pr_info("RJK: fault=%d instr=0x%08x instrptr=%p\n", fault, instr,
instrptr);
if (fault) {
type = TYPE_FAULT;
goto bad_or_fault;
[2] Oops
# insmod /tmp/unalign.ko
RJK1: fsr=23 far=e1c23643 dacr=51
RJK2: fsr=23 far=e1c23643 dacr=51
RJK3: fsr=2f far=bf00202c dacr=51
RJK: fault=4 instr=0x instrptr=bf00202c
Unable to handle kernel paging request at virtual address e1c23643
pgd = e1cd4000
[e1c23643] *pgd=c1c0044e(bad)
Internal error: Oops: 823 [#1] ARM
Modules linked in: unalign(+)
CPU: 0 PID: 608 Comm: insmod Not tainted 4.2.0-rc8-next-20150828-cm-x300+ #919
Hardware name: CM-X300 module
task: e1c69880 ti: e1cb task.ti: e1cb
PC is at u_init+0x2c/0x40 [unalign]
LR is at u_init+0x14/0x40 [unalign]
pc : []lr : []psr: a013
sp : e1cb1df8 ip : e1c23e00 fp : 1e3dc89c
r10:
Re: [PATCH v4 3/3] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs
On 27 Jul 03:21 PM, Alex Smith wrote: > Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as > well as the hardware BCH controller. DMA is not currently implemented. > > While older 47xx SoCs also have a BCH controller, they are incompatible > with the one in the 4780 due to differing register/bit positions, which > would make implementing a common driver for them quite messy. > If the difference is only in register/bit positions, a common driver might be fairly simple. See drivers/i2c/busses/i2c-mv64xxx.c, which supports two different register layouts. Anyway, the drivers look mostly good. Just a handful of comments. > Signed-off-by: Alex Smith > Cc: Zubair Lutfullah Kakakhel > Cc: David Woodhouse > Cc: Brian Norris > Cc: linux-...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > v3 -> v4: > - Rebase to 4.2-rc4 > - Change ECC_HW_OOB_FIRST to ECC_HW, reading OOB first is not necessary. > - Fix argument to get_device() in jz4780_bch_get() > > v2 -> v3: > - Rebase to 4.0-rc6 > - Reflect binding changes > - get/put_device in bch get/release > - Removed empty .remove() callback > - Removed .owner > - Set mtd->dev.parent > > v1 -> v2: > - Fixed module license macro > - Rebase to 4.0-rc3 > --- > drivers/mtd/nand/Kconfig | 7 + > drivers/mtd/nand/Makefile | 1 + > drivers/mtd/nand/jz4780_bch.c | 354 ++ > drivers/mtd/nand/jz4780_bch.h | 42 + > drivers/mtd/nand/jz4780_nand.c | 376 > + > 5 files changed, 780 insertions(+) > create mode 100644 drivers/mtd/nand/jz4780_bch.c > create mode 100644 drivers/mtd/nand/jz4780_bch.h > create mode 100644 drivers/mtd/nand/jz4780_nand.c > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 5b2806a7e5f7..3900e5f93146 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -511,6 +511,13 @@ config MTD_NAND_JZ4740 > help > Enables support for NAND Flash on JZ4740 SoC based boards. > > +config MTD_NAND_JZ4780 > + tristate "Support for NAND on JZ4780 SoC" > + depends on MACH_JZ4780 && JZ4780_NEMC > + help > + Enables support for NAND Flash connected to the NEMC on JZ4780 SoC > + based boards, using the BCH controller for hardware error correction. > + > config MTD_NAND_FSMC > tristate "Support for NAND on ST Micros FSMC" > depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300 > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index 1f897ec3c242..3ee2fd6bc641 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -47,6 +47,7 @@ obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o > obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o > obj-$(CONFIG_MTD_NAND_RICOH) += r852.o > obj-$(CONFIG_MTD_NAND_JZ4740)+= jz4740_nand.o > +obj-$(CONFIG_MTD_NAND_JZ4780)+= jz4780_nand.o jz4780_bch.o > obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ > obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o > obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ > diff --git a/drivers/mtd/nand/jz4780_bch.c b/drivers/mtd/nand/jz4780_bch.c > new file mode 100644 > index ..1686d76f8457 > --- /dev/null > +++ b/drivers/mtd/nand/jz4780_bch.c > @@ -0,0 +1,354 @@ > +/* > + * JZ4780 BCH controller > + * > + * Copyright (c) 2015 Imagination Technologies > + * Author: Alex Smith > + * > + * 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. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "jz4780_bch.h" > + > +#define BCH_BHCR 0x0 > +#define BCH_BHCCR0x8 > +#define BCH_BHCNT0xc > +#define BCH_BHDR 0x10 > +#define BCH_BHPAR0 0x14 > +#define BCH_BHERR0 0x84 > +#define BCH_BHINT0x184 > +#define BCH_BHINTES 0x188 > +#define BCH_BHINTEC 0x18c > +#define BCH_BHINTE 0x190 > + > +#define BCH_BHCR_BSEL_SHIFT 4 > +#define BCH_BHCR_BSEL_MASK (0x7f << BCH_BHCR_BSEL_SHIFT) > +#define BCH_BHCR_ENCEBIT(2) > +#define BCH_BHCR_INITBIT(1) > +#define BCH_BHCR_BCHEBIT(0) > + > +#define BCH_BHCNT_PARITYSIZE_SHIFT 16 > +#define BCH_BHCNT_PARITYSIZE_MASK(0x7f << BCH_BHCNT_PARITYSIZE_SHIFT) > +#define BCH_BHCNT_BLOCKSIZE_SHIFT0 > +#define BCH_BHCNT_BLOCKSIZE_MASK (0x7ff << BCH_BHCNT_BLOCKSIZE_SHIFT) > + > +#define BCH_BHERR_MASK_SHIFT 16 > +#define BCH_BHERR_MASK_MASK (0x << BCH_BHERR_MASK_SHIFT) > +#define
[PATCH 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
You can add support to your board with current binding.
Example:
anx7814: anx7814@38 {
compatible = "analogix,anx7814";
reg = <0x38>;
pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
};
Signed-off-by: Enric Balletbo i Serra
---
.../devicetree/bindings/video/bridge/anx7814.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt
b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
new file mode 100644
index 000..a8cc746
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
@@ -0,0 +1,22 @@
+Analogix ANX7814 SlimPort (Full-HD Transmitter)
+---
+
+The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx7814"
+ - reg : I2C address of the device
+ - pd-gpios: Which GPIO to use for power down
+ - reset-gpios : Which GPIO to use for reset
+
+Example:
+
+ anx7814: anx7814@38 {
+ compatible = "analogix,anx7814";
+ reg = <0x38>;
+ pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] staging: slimport: Add anx7814 driver support by analogix.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
This driver adds initial support and supports HDMI to DP pass-through mode.
Signed-off-by: Enric Balletbo i Serra
---
drivers/staging/Kconfig|2 +
drivers/staging/Makefile |1 +
drivers/staging/slimport/Kconfig |7 +
drivers/staging/slimport/Makefile |4 +
drivers/staging/slimport/slimport.c| 301 +++
drivers/staging/slimport/slimport.h| 49 +
drivers/staging/slimport/slimport_tx_drv.c | 3293
drivers/staging/slimport/slimport_tx_drv.h | 254 +++
drivers/staging/slimport/slimport_tx_reg.h | 786 +++
9 files changed, 4697 insertions(+)
create mode 100644 drivers/staging/slimport/Kconfig
create mode 100644 drivers/staging/slimport/Makefile
create mode 100644 drivers/staging/slimport/slimport.c
create mode 100644 drivers/staging/slimport/slimport.h
create mode 100644 drivers/staging/slimport/slimport_tx_drv.c
create mode 100644 drivers/staging/slimport/slimport_tx_drv.h
create mode 100644 drivers/staging/slimport/slimport_tx_reg.h
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e29293c..24ccd7c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -110,4 +110,6 @@ source "drivers/staging/wilc1000/Kconfig"
source "drivers/staging/most/Kconfig"
+source "drivers/staging/slimport/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 50824dd..942e886 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -47,3 +47,4 @@ obj-$(CONFIG_FB_TFT) += fbtft/
obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
obj-$(CONFIG_WILC1000) += wilc1000/
obj-$(CONFIG_MOST) += most/
+obj-$(CONFIG_SLIMPORT_ANX78XX) += slimport/
diff --git a/drivers/staging/slimport/Kconfig b/drivers/staging/slimport/Kconfig
new file mode 100644
index 000..f5233ef
--- /dev/null
+++ b/drivers/staging/slimport/Kconfig
@@ -0,0 +1,7 @@
+config SLIMPORT_ANX78XX
+ tristate "Analogix Slimport transmitter ANX78XX support"
+ help
+ Slimport Transmitter is a HD video transmitter chip
+ over micro-USB connector for smartphone device.
+
+
diff --git a/drivers/staging/slimport/Makefile
b/drivers/staging/slimport/Makefile
new file mode 100644
index 000..9bb6ce2
--- /dev/null
+++ b/drivers/staging/slimport/Makefile
@@ -0,0 +1,4 @@
+obj-${CONFIG_SLIMPORT_ANX78XX} := anx78xx.o
+
+anx78xx-y := slimport.o
+anx78xx-y += slimport_tx_drv.o
diff --git a/drivers/staging/slimport/slimport.c
b/drivers/staging/slimport/slimport.c
new file mode 100644
index 000..95c5114
--- /dev/null
+++ b/drivers/staging/slimport/slimport.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 "slimport.h"
+#include "slimport_tx_drv.h"
+
+/* HDCP switch for external block */
+/* external_block_en = 1: enable, 0: disable */
+int external_block_en = 1;
+
+struct i2c_client *anx7814_client;
+
+int sp_read_reg_byte(uint8_t slave_addr, uint8_t offset)
+{
+ int ret = 0;
+ struct device *dev = _client->dev;
+
+ anx7814_client->addr = (slave_addr >> 1);
+ ret = i2c_smbus_read_byte_data(anx7814_client, offset);
+ if (ret < 0) {
+ dev_err(dev, "%s: failed to read i2c addr=%x\n", LOG_TAG,
+ slave_addr);
+ return ret;
+ }
+ return 0;
+}
+
+int sp_read_reg(uint8_t slave_addr, uint8_t offset, uint8_t *buf)
+{
+ int ret = 0;
+ struct device *dev = _client->dev;
+
+ anx7814_client->addr = (slave_addr >> 1);
+ ret = i2c_smbus_read_byte_data(anx7814_client, offset);
+ if (ret < 0) {
+ dev_err(dev, "%s: failed to read i2c addr=%x\n", LOG_TAG,
+ slave_addr);
+ return ret;
+ }
+ *buf = (uint8_t) ret;
+
+ return 0;
+}
+
+int sp_write_reg(uint8_t slave_addr, uint8_t offset, uint8_t value)
+{
+ int ret = 0;
+ struct device *dev = _client->dev;
+
+ anx7814_client->addr = (slave_addr >> 1);
+ ret = i2c_smbus_write_byte_data(anx7814_client, offset, value);
+ if (ret < 0) {
+ dev_err(dev, "%s: failed to write i2c addr=%x\n", LOG_TAG,
+
[PATCH 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.
Analogix Semiconductor develops analog and mixed-signal devices for digital media and communications interconnect applications. Signed-off-by: Enric Balletbo i Serra --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac5f0c3..e914a02 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -22,6 +22,7 @@ ampireAmpire Co., Ltd. amsAMS AG amstaosAMS-Taos Inc. apmApplied Micro Circuits Corporation (APM) +analogix Analogix Semiconductor, Inc. aptina Aptina Imaging arasan Arasan Chip Systems armARM Ltd. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Add initial support for slimport anx78xx
Hi all, The following series add initial support for the Slimport ANX7814 transmitter, a ultra-low power Full-HD (1080p60) transmitter designed for portable device. The driver was originally created and based from the work of Junhua Xia from Analogix. This driver is a refactor of the original driver and fixes different coding style lines, and different errors/warnings reported by checkpatch. Also there were thing that I notive that we need to change like: - Convert the numbered GPIO API to the new descriptor based GPIO API. - Review the DT binding - Add missing MODULE_DEVICE_TABLE(of, ...); - Fix Makefiles and Kconfig to build conditionally. - Use SIMPLE_DEV_PM_OPS() instead of the deprecated i2c .suspend and .resume callbacks. - Move to use managed device resources. - Remove dead/unused code. - And others ... This is the first version so probably will have mistakes so feel free to ping to incorporate other changes that I need to do in next series. Best regards, Enric Balletbo i Serra (3): of: Add vendor prefix for Analogix Semiconductor, Inc. devicetree: Add new ANX7814 SlimPort transmitter binding. staging: slimport: Add anx7814 driver support by analogix. .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/anx7814.txt | 22 + drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + drivers/staging/slimport/Kconfig |7 + drivers/staging/slimport/Makefile |4 + drivers/staging/slimport/slimport.c| 301 ++ drivers/staging/slimport/slimport.h| 49 + drivers/staging/slimport/slimport_tx_drv.c | 3293 drivers/staging/slimport/slimport_tx_drv.h | 254 ++ drivers/staging/slimport/slimport_tx_reg.h | 786 + 11 files changed, 4720 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt create mode 100644 drivers/staging/slimport/Kconfig create mode 100644 drivers/staging/slimport/Makefile create mode 100644 drivers/staging/slimport/slimport.c create mode 100644 drivers/staging/slimport/slimport.h create mode 100644 drivers/staging/slimport/slimport_tx_drv.c create mode 100644 drivers/staging/slimport/slimport_tx_drv.h create mode 100644 drivers/staging/slimport/slimport_tx_reg.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems booting 4.1.6
Hi Peter,
does the following patch help:
x86/idle: Restore trace_cpu_idle to mwait_idle() calls
http://marc.info/?l=linux-kernel=144009977312088
x86/idle: Restore trace_cpu_idle to mwait_idle() calls
Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.
Add them back to restore the proper behaviour.
Greetings,
Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
On Fri, Sep 4, 2015 at 8:14 PM, Frank Rowand wrote:
> On 9/4/2015 12:12 PM, David Daney wrote:
>> From: David Daney
>>
>> It is perfectly legitimate for a PCI device to have an
>> PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
>> use interrupts, or on PCIe devices, where only MSI/MSI-X are
>> supported.
>>
>> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
>> messages by making them conditional on !-ENODEV (which can only be
>> produced in the PCI_INTERRUPT_PIN == 0 case).
>>
>> Signed-off-by: David Daney
>> ---
>> drivers/of/of_pci_irq.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
>> index 1710d9d..33d242a 100644
>> --- a/drivers/of/of_pci_irq.c
>> +++ b/drivers/of/of_pci_irq.c
>> @@ -106,7 +106,9 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev,
>> u8 slot, u8 pin)
>>
>> ret = of_irq_parse_pci(dev, );
>> if (ret) {
>> - dev_err(>dev, "of_irq_parse_pci() failed with rc=%d\n",
>> ret);
>> + if (ret != -ENODEV)
>> + dev_err(>dev,
>> + "of_irq_parse_pci() failed with rc=%d\n", ret);
>> return 0; /* Proper return code 0 == NO_IRQ */
>> }
>>
>>
>
> It is not safe to assume that the functions that of_irq_parse_pci() calls
> will never be modified to return -ENODEV, thus resulting in of_irq_parse_pci()
> returning -ENODEV for a reason other than PCI_INTERRUPT_PIN == 0.
Yes, but we're talking about a print statement.
>
> A more robust solution would be something like:
>
>
> (1) Change of_irq_parse_pci() to _of_irq_parse_pci(), adding an argument and
> use it to report the case of PCI_INTERRUPT_PIN == 0.
>
> static int _of_irq_parse_pci(const struct pci_dev *pdev, struct
> of_phandle_args *out_irq, int *no_pin)
> {
>
> ...
> *no_pin = 0;
> ...
> /* No pin, exit */
> if (pin == 0) {
> *no_pin = 1;
> return -ENODEV;
> }
> ...
>
>
> int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args
> *out_irq)
> {
> int no_pin;
> return _of_irq_parse_pci(pdev, out_irq, _pin)
> }
>
>
> (2) Then the fix to of_irq_parse_and_map_pci() would be:
>
> + int no_pin;
>> ret = of_irq_parse_pci(dev, , _pin);
>> if (ret) {
>> - dev_err(>dev, "of_irq_parse_pci() failed with rc=%d\n",
>> ret);
>> + if (!no_pin)
>> + dev_err(>dev,
>> + "of_irq_parse_pci() failed with rc=%d\n", ret);
>> return 0; /* Proper return code 0 == NO_IRQ */
>> }
>
>
> I'm not sure I like my solution, there might be a better way.
I don't like it. That's way too complex for just silencing an
erroneous error message.
Perhaps just move the error message into of_irq_parse_pci and then you
can control the print more easily. Or just change to dev_dbg would be
okay by me.
> I also noticed another bug while looking at of_irq_parse_pci(). It returns
> the non-zero return value from pci_read_config_byte(). But that value is
> one of the PCI function error values from include/linux/pci.h, such as:
>
>#define PCIBIOS_BAD_REGISTER_NUMBER 0x87
>
> instead of a negative errno.
I was puzzled by why this is not standard error codes a while back. My
best guess is that that there is some legacy here. Changing error
values on widely used functions is impossible to audit. NO_IRQ being 0
or -1 is one such case.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] mtd: nand: jz4780: Add NAND and BCH drivers
On 27 Jul 02:50 PM, Alex Smith wrote:
> Hi,
>
> This series adds support for the BCH controller and NAND devices on
> the Ingenic JZ4780 SoC.
>
> Tested on the MIPS Creator Ci20 board. All dependencies are now in
> mainline so it should be possible to compile test now.
>
> This version of the series has been rebased on 4.2-rc4, and also adds
> an additional patch to fix an issue that was encountered in the
> external Ci20 3.18 kernel branch.
>
> Review and feedback welcome.
>
The NEMC driver seems to be upstream. Any chance you submit devicetree
changes as well for Ci20 (so we can actually test this)?
> Thanks,
> Alex
>
> Alex Smith (3):
> mtd: nand: increase ready wait timeout and report timeouts
> dt-bindings: binding for jz4780-{nand,bch}
> mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 57
> drivers/mtd/nand/Kconfig | 7 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/jz4780_bch.c | 354 +++
> drivers/mtd/nand/jz4780_bch.h | 42 +++
> drivers/mtd/nand/jz4780_nand.c | 376
> +
> drivers/mtd/nand/nand_base.c | 15 +-
> 7 files changed, 849 insertions(+), 3 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> create mode 100644 drivers/mtd/nand/jz4780_bch.c
> create mode 100644 drivers/mtd/nand/jz4780_bch.h
> create mode 100644 drivers/mtd/nand/jz4780_nand.c
>
> --
> 2.4.6
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] mtd: nand: increase ready wait timeout and report timeouts
On 27 Jul 02:50 PM, Alex Smith wrote:
> If nand_wait_ready() times out, this is silently ignored, and its
> caller will then proceed to read from/write to the chip before it is
> ready. This can potentially result in corruption with no indication as
> to why.
>
> While a 20ms timeout seems like it should be plenty enough, certain
> behaviour can cause it to timeout much earlier than expected. The
> situation which prompted this change was that CPU 0, which is
> responsible for updating jiffies, was holding interrupts disabled
> for a fairly long time while writing to the console during a printk,
> causing several jiffies updates to be delayed. If CPU 1 happens to
> enter the timeout loop in nand_wait_ready() just before CPU 0 re-
> enables interrupts and updates jiffies, CPU 1 will immediately time
> out when the delayed jiffies updates are made. The result of this is
> that nand_wait_ready() actually waits less time than the NAND chip
> would normally take to be ready, and then read_page() proceeds to
> read out bad data from the chip.
>
> The situation described above may seem unlikely, but in fact it can be
> reproduced almost every boot on the MIPS Creator Ci20.
>
Not only unlikely but scary :) BTW, can't find SMP patches for Ci20,
are you sure this behavior will apply once SMP is upstreamed?
> Debugging this was made more difficult by the misleading comment above
> nand_wait_ready() stating "The timeout is caught later" - no timeout
> was ever reported, leading me away from the real source of the problem.
>
> Therefore, this patch increases the timeout to 200ms. This should be
> enough to cover cases where jiffies updates get delayed. Additionally,
> add a pr_warn() when a timeout does occur so that it is easier to
> pinpoint any problems in future caused by the chip not becoming ready.
>
> Signed-off-by: Alex Smith
> Cc: Zubair Lutfullah Kakakhel
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: linux-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v3 -> v4:
> - New patch to fix issue encountered in external Ci20 3.18 kernel
>branch which also applies upstream.
> ---
> drivers/mtd/nand/nand_base.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index ceb68ca8277a..a0dab3414f16 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -543,23 +543,32 @@ static void panic_nand_wait_ready(struct mtd_info *mtd,
> unsigned long timeo)
> }
> }
>
> -/* Wait for the ready pin, after a command. The timeout is caught later. */
> +/**
> + * nand_wait_ready - [GENERIC] Wait for the ready pin after commands.
> + * @mtd: MTD device structure
> + *
> + * Wait for the ready pin after a command, and warn if a timeout occurs.
> + */
> void nand_wait_ready(struct mtd_info *mtd)
> {
> struct nand_chip *chip = mtd->priv;
> - unsigned long timeo = jiffies + msecs_to_jiffies(20);
> + unsigned long timeo = jiffies + msecs_to_jiffies(200);
>
> /* 400ms timeout */
> if (in_interrupt() || oops_in_progress)
> return panic_nand_wait_ready(mtd, 400);
>
> led_trigger_event(nand_led_trigger, LED_FULL);
> +
Spurious change here.
> /* Wait until command is processed or timeout occurs */
> do {
> if (chip->dev_ready(mtd))
> - break;
> + goto out;
> touch_softlockup_watchdog();
> } while (time_before(jiffies, timeo));
> +
> + pr_warn("timeout while waiting for chip to become ready\n");
> +out:
> led_trigger_event(nand_led_trigger, LED_OFF);
> }
This change looks reasonable, a timeout value should be large enough
to be confident the operation has _really_ timed out. On non-error
path, this change shouldn't make any difference.
And the warning is probably helpful too, so:
Reviewed-by: Ezequiel Garcia
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] x86/headers: Remove
On Sun, Sep 06, 2015 at 08:41:45AM +0200, Ingo Molnar wrote:
>
> * Mikko Rapeli wrote:
>
> > On Sat, Sep 05, 2015 at 01:59:43PM +0200, Ingo Molnar wrote:
> > >
> > > * Mikko Rapeli wrote:
> > >
> > > > > diff --git a/arch/x86/include/uapi/asm/sigcontext32.h
> > > > > b/arch/x86/include/uapi/asm/sigcontext32.h
> > > > > index a92b0f0dc09e..8b870175befa 100644
> > > > > --- a/arch/x86/include/uapi/asm/sigcontext32.h
> > > > > +++ b/arch/x86/include/uapi/asm/sigcontext32.h
> > > > > @@ -3,6 +3,6 @@
> > > > >
> > > > > /* This is a legacy file - all the type definitions are in
> > > > > sigcontext.h: */
> > > > >
> > > > > -#include
> > > > > +#include
> > > >
> > > > This needs to be without uapi directory in path.
> > >
> > > What do you mean?
> >
> > There is not uapi in path in userspace so it fails to compile:
>
> Ok, I see. So it's not common, but I don't think there's an outright
> prohibition
> for uapi headers to refer to each other:
>
> arch/hexagon/include/uapi/asm/signal.h:#include
> arch/mips/include/uapi/asm/siginfo.h:#include
> arch/x86/include/uapi/asm/sigcontext32.h:#include
>
> There are a couple of solutions:
>
> - copy the uapi/ directory if you take the kernel headers as-is
>
> - adapt the headers to the old user-space layout when you import them.
> (i.e. do a sed -i 's/
> - create a symbolic link from asm/uapi to asm/ in user-space.
>
> The kernel side solutions are uglier:
>
> - We could create a symbolic link from asm/uapi/sigcontext32.h to
> asm/uapi/sigcontext.h, although I'm not sure what the policy for that is
> in
> the kernel repository - I think it's generally frowned upon.
>
> - We could keep asm/sigcontext.h that includes asm/uapi/sigcontext.h - a
> poor man's symbolic link.
>
> OTOH the last option isn't all that ugly.
Yes, AFAIK it's a common patterns in kernel.
> > This is the fix:
> >
> > --- a/arch/x86/include/uapi/asm/sigcontext32.h
> > +++ b/arch/x86/include/uapi/asm/sigcontext32.h
> > @@ -3,6 +3,6 @@
> >
> > /* This is a legacy file - all the type definitions are in sigcontext.h: */
> >
> > -#include
> > +#include
>
> There's no asm/sigcontext.h file anymore if you apply my patches - but we
> could
> reintroduce it to make the copy of UAPI headers to user-space work as-is.
Actually there is, in user space :)
$ git show -s --pretty=one HEAD
bea04c5252803fa53dcc5366ae32357a0ab07b44 x86/headers: Remove
$ make headers_install
...
$ ls usr/include/asm/sigcontext.h
usr/include/asm/sigcontext.h
$ diff -up arch/x86/include/uapi/asm/sigcontext.h usr/include/asm/sigcontext.h
--- arch/x86/include/uapi/asm/sigcontext.h 2015-09-06 22:10:54.918303649
+0200
+++ usr/include/asm/sigcontext.h2015-09-06 22:11:18.214835356 +0200
@@ -1,5 +1,5 @@
-#ifndef _UAPI_ASM_X86_SIGCONTEXT_H
-#define _UAPI_ASM_X86_SIGCONTEXT_H
+#ifndef _ASM_X86_SIGCONTEXT_H
+#define _ASM_X86_SIGCONTEXT_H
/*
* Linux signal context definitions. The sigcontext includes a complex
hierarchy of CPU
@@ -14,7 +14,7 @@
* to grow new quirks for quite some time. Promise!
*/
-#include
+
#include
#define FP_XSTATE_MAGIC1 0x46505853U
@@ -271,20 +271,12 @@ struct sigcontext_64 {
/*
* Create the real 'struct sigcontext' type:
*/
-#ifdef __KERNEL__
-# ifdef __i386__
-# define sigcontext sigcontext_32
-# else
-# define sigcontext sigcontext_64
-# endif
-#endif
/*
* The old user-space sigcontext definition, just in case user-space still
* relies on it. The kernel definition (in asm/sigcontext.h) has unified
* field names but otherwise the same layout.
*/
-#ifndef __KERNEL__
#define _fpstate_ia32 _fpstate_32
#define sigcontext_ia32sigcontext_32
@@ -311,7 +303,7 @@ struct sigcontext {
__u32 eflags;
__u32 esp_at_signal;
__u16 ss, __ssh;
- struct _fpstate __user *fpstate;
+ struct _fpstate *fpstate;
__u32 oldmask;
__u32 cr2;
};
@@ -343,13 +335,12 @@ struct sigcontext {
__u64 trapno;
__u64 oldmask;
__u64 cr2;
- struct _fpstate __user *fpstate; /* Zero when no FPU
context */
+ struct _fpstate *fpstate; /* Zero when no FPU context */
# ifdef __ILP32__
__u32 __fpstate_pad;
# endif
__u64 reserved1[8];
};
# endif /* __x86_64__ */
-#endif /* !__KERNEL__ */
-#endif /* _UAPI_ASM_X86_SIGCONTEXT_H */
+#endif /* _ASM_X86_SIGCONTEXT_H */
So that's what changes when the file is exported for userspace together with
the path from which uapi is removed. So if, like you said kernel side has
problems with
--- a/arch/x86/include/uapi/asm/sigcontext32.h
+++
[PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
Enable Rockchip I2C, SPI, PWM, thermal drivers. Builtin are: * I2C as it often controls the pmic. * Thermal, prevent thermal damage. SPI and PWM configured as modules Signed-off-by: Sjoerd Simons --- arch/arm/configs/multi_v7_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 36aa6e3..25a1d574 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -302,6 +302,7 @@ CONFIG_I2C_GPIO=m CONFIG_I2C_EXYNOS5=y CONFIG_I2C_MV64XXX=y CONFIG_I2C_RIIC=y +CONFIG_I2C_RK3X=y CONFIG_I2C_S3C2410=y CONFIG_I2C_SH_MOBILE=y CONFIG_I2C_SIRF=y @@ -318,6 +319,7 @@ CONFIG_SPI_DAVINCI=y CONFIG_SPI_OMAP24XX=y CONFIG_SPI_ORION=y CONFIG_SPI_PL022=y +CONFIG_SPI_ROCKCHIP=m CONFIG_SPI_RSPI=y CONFIG_SPI_S3C64XX=m CONFIG_SPI_SH_MSIOF=m @@ -365,6 +367,7 @@ CONFIG_SENSORS_LM95245=y CONFIG_SENSORS_NTC_THERMISTOR=m CONFIG_THERMAL=y CONFIG_CPU_THERMAL=y +CONFIG_ROCKCHIP_THERMAL=y CONFIG_RCAR_THERMAL=y CONFIG_ARMADA_THERMAL=y CONFIG_DAVINCI_WATCHDOG=m @@ -642,6 +645,7 @@ CONFIG_PWM=y CONFIG_PWM_ATMEL=m CONFIG_PWM_ATMEL_TCB=m CONFIG_PWM_RENESAS_TPU=y +CONFIG_PWM_ROCKCHIP=m CONFIG_PWM_SAMSUNG=m CONFIG_PWM_SUN4I=y CONFIG_PWM_TEGRA=y -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] ARM: multi_v7_defconfig: Improve rockchip support
Enable options to provide more complete support for Rockchip boards including: support for the common act8846 PMIC, I2C, SPI, PMW, Thermal driver, HDMI video output and USB 2. Sjoerd Simons (4): ARM: multi_v7_defconfig: Enable common Rockchip devices/busses ARM: multi_v7_defconfig: Enable ACT8865 PMIC driver ARM: multi_v7_defconfig: Enable Rockchip display support ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy arch/arm/configs/multi_v7_defconfig | 10 ++ 1 file changed, 10 insertions(+) -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ARM: multi_v7_defconfig: Enable ACT8865 PMIC driver
Active Semi act8846 is used as the PMIC on various Rockchip boards, enable the ACT8865 driver to support this. Signed-off-by: Sjoerd Simons --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 25a1d574..7058fef 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -401,6 +401,7 @@ CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_AB8500=y +CONFIG_REGULATOR_ACT8865=y CONFIG_REGULATOR_AS3711=y CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_AXP20X=y -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
The DesignWare HS OTG USB 2.0 is used in various SoC families among wich the various rockchip SoCs, enable the driver and the PHY glue for rockchip Signed-off-by: Sjoerd Simons --- arch/arm/configs/multi_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index fb673e2..49c733a 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -514,6 +514,7 @@ CONFIG_USB_STORAGE=y CONFIG_USB_DWC3=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_USB_DWC2=y CONFIG_AB8500_USB=y CONFIG_KEYSTONE_USB_PHY=y CONFIG_OMAP_USB3=y @@ -658,6 +659,7 @@ CONFIG_PHY_HIX5HD2_SATA=y CONFIG_PWM_STI=m CONFIG_OMAP_USB2=y CONFIG_TI_PIPE3=y +CONFIG_PHY_ROCKCHIP_USB=y CONFIG_PHY_MIPHY28LP=y CONFIG_PHY_MIPHY365X=y CONFIG_PHY_RCAR_GEN2=m -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ARM: multi_v7_defconfig: Enable Rockchip display support
Enable options needed for HDMI out on rockchip: DRM driver, Rockchip DesignWare HDMI glue and the rockchip IOMMU (dependency of the DRM driver). Signed-off-by: Sjoerd Simons --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 7058fef..fb673e2 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -453,6 +453,8 @@ CONFIG_DRM_EXYNOS=m CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_FIMD=y CONFIG_DRM_EXYNOS_HDMI=y +CONFIG_DRM_ROCKCHIP=m +CONFIG_ROCKCHIP_DW_HDMI=m CONFIG_DRM_RCAR_DU=m CONFIG_DRM_TEGRA=y CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m @@ -630,6 +632,7 @@ CONFIG_APQ_MMCC_8084=y CONFIG_MSM_GCC_8660=y CONFIG_MSM_MMCC_8960=y CONFIG_MSM_MMCC_8974=y +CONFIG_ROCKCHIP_IOMMU=y CONFIG_TEGRA_IOMMU_GART=y CONFIG_TEGRA_IOMMU_SMMU=y CONFIG_PM_DEVFREQ=y -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: fix alignement of __bug_table section entries
On Sun, Sep 06, 2015 at 07:25:01PM +0200, Robert Jarzmik wrote: > Russell King - ARM Linux writes: > > > On Sat, Sep 05, 2015 at 07:10:49PM +0200, Robert Jarzmik wrote: > >> Russell King - ARM Linux writes: > >> So the issue is around this SW_DOMAIN_PAN, at least on PXA. > > > > If so, you may need to add: > > > > mrc p15, 0, \rd, c2, c0, 0 > > mov \rd, \rd > > sub pc, pc, #4 > > > > to the places we update the domain access register to ensure that the > > Xscale pipeline stalls to allow the CP15 DACR update to hit. > Nope, that didn't work. > I have tried 2 different patches : > - in [1], your proposed solution > - in [2], a PrefetchFlush as adviced by ARM Architecture Reference Manual > > None of them worked. I confirmed by disassembling __dabt_svc my changes hit > the > abort routine, and they did. I'll continue next week by trying to have a > closer > look at the SW_DOMAIN_PAN commit (a5e090acbf545), and take time to walk > through > the whole Oops for information I have missed. > > Cheers. > > -- > Robert > > [1] Approach 1 : translation table sync > === > diff --cc arch/arm/include/asm/assembler.h > index 7bbf325a4f31,7bbf325a4f31..6bb46198fd08 > --- a/arch/arm/include/asm/assembler.h > +++ b/arch/arm/include/asm/assembler.h > @@@ -449,6 -449,6 +449,12 @@@ THUMB(orr \reg , \reg , #PSR_T_BIT > > #endif > .endm > > ++ .macro dacr_sync, rd > ++ mrc p15, 0, \rd, c2, c0, 0 > ++ mov \rd, \rd > ++ sub pc, pc, #4 > ++ .endm > ++ > .macro uaccess_disable, tmp, isb=1 > #ifdef CONFIG_CPU_SW_DOMAIN_PAN > /* > @@@ -457,6 -457,6 +463,7 @@@ > */ > mov \tmp, #DACR_UACCESS_DISABLE > mcr p15, 0, \tmp, c3, c0, 0 @ Set domain register > ++ dacr_sync \tmp > .if \isb > instr_sync > .endif > @@@ -471,6 -471,6 +478,7 @@@ > */ > mov \tmp, #DACR_UACCESS_ENABLE > mcr p15, 0, \tmp, c3, c0, 0 > ++ dacr_sync \tmp > .if \isb > instr_sync > .endif > @@@ -488,6 -488,6 +496,7 @@@ > #ifdef CONFIG_CPU_SW_DOMAIN_PAN > ldr r0, [sp, #S_FRAME_SIZE] > mcr p15, 0, r0, c3, c0, 0 > ++ dacr_sync r0 > #endif > .endm The important place is in arch/arm/include/asm/domain.h, which is where we manipulate the DACR within probe_kernel_address(). -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Staging: rtl8192u: r8192U_core.c: Replace memcpy with eth_addr_copy
On 09/06/2015 02:04 PM, Shraddha Barke wrote: This patch replaces memcpy with eth_addr_copy The changes were applied using the following coccinelle rule: @@ expression e1, e2; @@ - memcpy(e1, e2, ETH_ALEN); + ether_addr_copy(e1, e2); Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192u/r8192U_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c index 6f6fe38..577d3a4 100644 --- a/drivers/staging/rtl8192u/r8192U_core.c +++ b/drivers/staging/rtl8192u/r8192U_core.c @@ -3430,7 +3430,7 @@ static int r8192_set_mac_adr(struct net_device *dev, void *mac) down(>wx_sem); - memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN); + ether_addr_copy(dev->dev_addr, addr->sa_data); schedule_work(>reset_wq); up(>wx_sem); This patch has the same problems as do both patches 1 and 2. NACK. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Staging: rtl8192e: Replace memcpy by ethr_addr_copy
On 09/06/2015 02:04 PM, Shraddha Barke wrote: The patch replaces memcpy with ethr_addr_copy The changes were applied using the following coccinelle rule: @@ expression e1, e2; @@ - memcpy(e1, e2, ETH_ALEN); + ether_addr_copy(e1, e2); Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192e/rtllib_softmac_wx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) The same comments apply as in patch 1/3. NACK. Larry diff --git a/drivers/staging/rtl8192e/rtllib_softmac_wx.c b/drivers/staging/rtl8192e/rtllib_softmac_wx.c index 86f52ac..cf243fe 100644 --- a/drivers/staging/rtl8192e/rtllib_softmac_wx.c +++ b/drivers/staging/rtl8192e/rtllib_softmac_wx.c @@ -122,8 +122,8 @@ int rtllib_wx_get_wap(struct rtllib_device *ieee, eth_zero_addr(wrqu->ap_addr.sa_data); else - memcpy(wrqu->ap_addr.sa_data, - ieee->current_network.bssid, ETH_ALEN); + ether_addr_copy(wrqu->ap_addr.sa_data, + ieee->current_network.bssid); spin_unlock_irqrestore(>lock, flags); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Staging: rtl8712: Replace memcpy by ether_addr_copy
On 09/06/2015 02:04 PM, Shraddha Barke wrote: This patch replaces memcpy by ethr_addr_copy The change was made using Coccinelle @@ expression e1, e2; @@ - memcpy(e1, e2, ETH_ALEN); + ether_addr_copy(e1, e2); Signed-off-by: Shraddha Barke --- drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Your commit message has a typo. More seriously, ether_addr_copy() requires that both arguments be u16 aligned. This condition is not hard to meet, but I see no indication in your commit message that you have checked this requirement. As a result, I must NACK this patch. Coccinelle is a wonderful tool, but the user must exercise judgment when applying the results. Larry Larry diff --git a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c index 77f01bf..76c1cfe 100644 --- a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c +++ b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c @@ -167,7 +167,7 @@ static int mp_start_test(struct _adapter *padapter) int res = _SUCCESS; /* 3 1. initialize a new struct wlan_bssid_ex */ - memcpy(bssid.MacAddress, pmppriv->network_macaddr, ETH_ALEN); + ether_addr_copy(bssid.MacAddress, pmppriv->network_macaddr); bssid.Ssid.SsidLength = 16; memcpy(bssid.Ssid.Ssid, (unsigned char *)"mp_pseudo_adhoc", bssid.Ssid.SsidLength); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Staging: rtl8192e: Replace memcpy by ethr_addr_copy
The patch replaces memcpy with ethr_addr_copy The changes were applied using the following coccinelle rule: @@ expression e1, e2; @@ - memcpy(e1, e2, ETH_ALEN); + ether_addr_copy(e1, e2); Signed-off-by: Shraddha Barke --- drivers/staging/rtl8192e/rtllib_softmac_wx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192e/rtllib_softmac_wx.c b/drivers/staging/rtl8192e/rtllib_softmac_wx.c index 86f52ac..cf243fe 100644 --- a/drivers/staging/rtl8192e/rtllib_softmac_wx.c +++ b/drivers/staging/rtl8192e/rtllib_softmac_wx.c @@ -122,8 +122,8 @@ int rtllib_wx_get_wap(struct rtllib_device *ieee, eth_zero_addr(wrqu->ap_addr.sa_data); else - memcpy(wrqu->ap_addr.sa_data, - ieee->current_network.bssid, ETH_ALEN); + ether_addr_copy(wrqu->ap_addr.sa_data, + ieee->current_network.bssid); spin_unlock_irqrestore(>lock, flags); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Staging: rtl8712: Replace memcpy by ether_addr_copy
This patch replaces memcpy by ethr_addr_copy The change was made using Coccinelle @@ expression e1, e2; @@ - memcpy(e1, e2, ETH_ALEN); + ether_addr_copy(e1, e2); Signed-off-by: Shraddha Barke --- drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c index 77f01bf..76c1cfe 100644 --- a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c +++ b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c @@ -167,7 +167,7 @@ static int mp_start_test(struct _adapter *padapter) int res = _SUCCESS; /* 3 1. initialize a new struct wlan_bssid_ex */ - memcpy(bssid.MacAddress, pmppriv->network_macaddr, ETH_ALEN); + ether_addr_copy(bssid.MacAddress, pmppriv->network_macaddr); bssid.Ssid.SsidLength = 16; memcpy(bssid.Ssid.Ssid, (unsigned char *)"mp_pseudo_adhoc", bssid.Ssid.SsidLength); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
