Re: [PATCH] perf trace: fix documentation for -i
Em Wed, Nov 04, 2015 at 09:21:46AM -0800, Peter Feiner escreveu: > The -i flag was incorrectly listed as a short flag for --no-inherit. > It should have only been listed as a short flag for --input. > > This documentation error has existed since the --input flag was > introduced in 6810fc915f7a89d8134edb3996dbbf8eac386c26 (perf trace: > Add option to analyze events in a file versus live). Thanks, 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 v6 14/17] aarch64: ilp32: use generic stat64 structure
On Tuesday 03 November 2015 02:30:43 Yury Norov wrote:
> Generic 32-bit and AARCH32 stat64 structures has same names.
> ILP32 needs generic stat64. So we can either make ILP32 mutual
> exclusive with AARCH32, or introduce __stat64, and where needed,
> cast stat64 to it with #define.
>
> Second option requires to duplicate cp_new_stat64 code. But we
> choose it, because it's more flexible to have independend support
> for ABIs.
>
> Signed-off-by: Yury Norov
> Reviewed-by: David Daney
I'm sorry I screwed up with the definition for stat64 in asm-generic,
by defining it to have too short st_{a,m,c}time members.
This means we have to introduce another 'struct stat64' variant already
to solve the y2038 problem, and I have patches for it already, to make
that implementation use the same structure as the 64-bit 'struct stat'
with 64-bit timestamps. There is also an ongoing effort from David Howells
to create a new 'struct statx' (or maybe xstat) system call with a
completely new layout.
I think here it would be better to avoid adding yet another version
for ilp32 mode, and we are better off defining 'struct stat64' in
the arm64 headers, and share either the normal arm32 syscall entry
(with the default asm-generic syscall) or the normal arm64 syscall
entry (as we will do for the future replacement).
Arnd
--
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: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Fu Wei wrote: SBSA 2.3 Page 23 : Note: the watchdog offset register is 32 bits wide. This gives a maximum watch period of around 10s at a system counter frequency of 400MHz. If a larger watch period is required then the compare value can be programmed directly into the compare value register. 214s means your system counter is approximately at 20MHz which is in the range of (10MHz ~ 400MHz) SBSA 2.3 Page 13 : The System Counter (of the Generic Timer) shall run at a minimum frequency of 10MHz and maximum of 400MHz. Thanks, that explains a lot. If we expected customers to have a lower system counter frequency, then we wouldn't have to worry about the timeouts being too short. It seems to me that the SBSA spec says that if you want a longer timeout, you have to lower the frequency. We shouldn't be complicating the driver because some customers might not follow the spec. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- 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] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success
From: Wang Nan [mailto:wangn...@huawei.com] > >It is possible that find_perf_probe_point_from_map() fails to find >symbol but still returns 0 because of an small error when coding: >find_perf_probe_point_from_map() set 'ret' to error code at first, >but also use it to hold return value of >kernel_get_symbol_address_by_name(). OK, I didn't expect that there is a symbol which can be found by kernel_get_symbol_address_by_name() but not by __find_kernel_function()... Would you have any example of the error? > >This patch resets 'ret' to error even kernel_get_symbol_address_by_name() >success, so if !sym, the whole function returns error correctly. Hmm, that sounds tricky. I'd rather like to add *psym to kernel_get_symbol_address_by_name() to save symbol and don't use __find_kernel_function() instead. Thank you, > >Signed-off-by: Wang Nan >Cc: Arnaldo Carvalho de Melo >Cc: Jiri Olsa >Cc: Masami Hiramatsu >Cc: Namhyung Kim >--- > tools/perf/util/probe-event.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c >index b51a8bf..e659c4f 100644 >--- a/tools/perf/util/probe-event.c >+++ b/tools/perf/util/probe-event.c >@@ -1905,6 +1905,9 @@ static int find_perf_probe_point_from_map(struct >probe_trace_point *tp, > sym = __find_kernel_function(addr, ); > } > } >+ >+ /* ret may has be overwritten so reset it */ >+ ret = -ENOENT; > if (!sym) > goto out; > >-- >1.8.3.4
Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection
On Tue, Nov 03, 2015 at 02:31:20PM +0100, Peter Zijlstra wrote:
> > @@ -5136,6 +5148,16 @@ pick_next_task_fair(struct rq *rq, struct
> > task_struct *prev)
> > struct task_struct *p;
> > int new_tasks;
> >
> > +#ifdef CONFIG_CFS_IDLE_INJECT
> > + if (cfs_rq->force_throttled &&
> > + !idle_cpu(cpu_of(rq)) &&
> > + !unlikely(local_softirq_pending())) {
> > + /* forced idle, pick no task */
> > + trace_sched_cfs_idle_inject(cpu_of(rq), 1);
> > + update_curr(cfs_rq);
> > + return NULL;
> > + }
> > +#endif
> > again:
> > #ifdef CONFIG_FAIR_GROUP_SCHED
> > if (!cfs_rq->nr_running)
>
> So this is horrible...
So this isn't ideal either (I rather liked the previous approach of a
random task assuming idle, but tglx hated that). This should at least
not touch extra cachelines in the hot paths, although it does add a few
extra instructions :/
Very limited testing didn't show anything horrible.
Your throttle would:
raw_spin_lock_irqsave(>lock, flags);
rq->cfs.forced_idle = true;
resched = rq->cfs.runnable;
rq->cfs.runnable = false;
raw_spin_unlock_irqrestore(>lock, flags);
if (resched)
resched_cpu(cpu_of(rq));
And your unthrottle:
raw_spin_lock_irqsave(>lock, flags);
rq->cfs.forced_idle = false;
resched = rq->cfs.runnable = !!rq->cfs.nr_running;
raw_spin_unlock_irqrestore(>lock, flags);
if (resched)
resched_cpu(cpu_of(rq));
---
kernel/sched/fair.c | 13 +
kernel/sched/sched.h |1 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 824aa9f..1f0c809 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2341,7 +2341,8 @@ account_entity_enqueue(struct cfs_rq *cfs_rq, struct
sched_entity *se)
list_add(>group_node, >cfs_tasks);
}
#endif
- cfs_rq->nr_running++;
+ if (!cfs_rq->nr_running++ && !cfs_rq->forced_idle)
+ cfs_rq->runnable = true;
}
static void
@@ -2354,7 +2355,8 @@ account_entity_dequeue(struct cfs_rq *cfs_rq, struct
sched_entity *se)
account_numa_dequeue(rq_of(cfs_rq), task_of(se));
list_del_init(>group_node);
}
- cfs_rq->nr_running--;
+ if (!--cfs_rq->nr_running && !cfs_rq->forced_idle)
+ cfs_rq->runnable = false;
}
#ifdef CONFIG_FAIR_GROUP_SCHED
@@ -5204,7 +5206,7 @@ pick_next_task_fair(struct rq *rq, struct task_struct
*prev)
again:
#ifdef CONFIG_FAIR_GROUP_SCHED
- if (!cfs_rq->nr_running)
+ if (!cfs_rq->runnable)
goto idle;
if (prev->sched_class != _sched_class)
@@ -5283,7 +5285,7 @@ simple:
cfs_rq = >cfs;
#endif
- if (!cfs_rq->nr_running)
+ if (!cfs_rq->runnable)
goto idle;
put_prev_task(rq, prev);
@@ -5302,6 +5304,9 @@ simple:
return p;
idle:
+ if (cfs_rq->forced_idle)
+ return NULL;
+
/*
* This is OK, because current is on_cpu, which avoids it being picked
* for load-balance and preemption/IRQs are still disabled avoiding
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index efd3bfc..33d355d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -347,6 +347,7 @@ struct cfs_bandwidth { };
struct cfs_rq {
struct load_weight load;
unsigned int nr_running, h_nr_running;
+ unsigned int runnable, forced_idle;
u64 exec_clock;
u64 min_vruntime;
--
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 4/7] pinctrl: sunxi: remove redundant "depends on RESET_CONTROLLER"
On Thu, Nov 5, 2015 at 2:40 PM, Linus Walleij wrote: > On Thu, Nov 5, 2015 at 12:15 PM, Masahiro Yamada > wrote: > >> ARCH_SUNXI selects RESET_CONTROLLER. >> The dependency "depends on RESET_CONTROLLER" is already met. >> >> Signed-off-by: Masahiro Yamada > > NACK, this pin controller needs that as dependency, I don't worry > that it's overspecified. > > They both do this: > #include You could of course replace the depends with select in this file so the menu options don't get hidden, as seems to be the problem as described in 0/7. Yours, Linus Walleij -- 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 related lockdep bug
On Thu, Nov 05, 2015 at 03:46:07AM +0100, Andi Kleen wrote: > On Wed, Nov 04, 2015 at 04:55:28PM -0800, Paul E. McKenney wrote: > > On Wed, Nov 04, 2015 at 09:58:36PM +0100, Andi Kleen wrote: > > > > > > I tested my perf stress workload with the patch applied on 4.3, > > > unfortunately got a hang again :-/ > > > > Any diagnostics, sysrq-T output, or whatever? > > The system was dead in the screen saver, no serial console. > I restarted it and may have some more information tomorrow. > > The previous hangs were usually timeout on smp_call_function, > so one CPU disappeared. > > I'll try the extra hunk you pointed out. Thank you, looking forward to seeing what you get from this. Thanx, Paul -- 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/7] doc:bindings:Add document for mfd hi665x PMIC
On Thu, Nov 05, 2015 at 09:34:42PM +0800, Chen Feng wrote:
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
> +- #interrupt-cells: Should be 2, two cells are needed for irq.
> +- interrupt-controller: hi655x has internal IRQs (has own IRQ domain).
> +- pmu_irq_gpio: should be _pmu_irq_n, is the IRQ gpio of hi655x.
I'm not entirely sure what this is but it sounds worrying - why can you
not just use a normal interrupt specifier? It also doesn't correspond
to the example:
> +Example:
> + pmic: pmic@f800 {
> + compatible = "hisilicon,hi655x-pmic-driver";
> + reg = <0x0 0xf800 0x0 0x1000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + pmic_gpios = <_pmu_irq_n>;
> + status = "okay";
> + }
> --
> 1.9.1
>
>
signature.asc
Description: PGP signature
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
Thursday, November 5, 2015, 2:53:40 PM, you wrote: > On 11/05/2015 04:13 AM, Sander Eikelenboom wrote: >> >> It makes "cat /sys/kernel/debug/kernel_page_tables" work and >> prevents a kernel with CONFIG_DEBUG_WX=y from crashing at boot. > Great. Our nightly runs also failed spectacularly due to this bug. >> >> It now does give a warning about an insecure W+X mapping, so >> CONFIG_DEBUG_WX=y >> seems to be working. No idea how to interpret it though (and if it's a >> legit >> warning). >> >> -- >> Sander >> >> [ 19.034706] Freeing unused kernel memory: 1104K (822fc000 - >> 8241) >> [ 19.041339] Write protecting the kernel read-only data: 18432k >> [ 19.052596] Freeing unused kernel memory: 1144K (880001ae2000 - >> 880001c0) >> [ 19.060285] Freeing unused kernel memory: 1560K (88000207a000 - >> 88000220) >> [ 19.067079] [ cut here ] >> [ 19.073931] WARNING: CPU: 5 PID: 1 at >> arch/x86/mm/dump_pagetables.c:225 note_page+0x619/0x7e0() > Yes, this apparently is a known issue: https://lkml.org/lkml/2015/11/4/476 > -boris Ah thx for the pointer :) -- Sander -- 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: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Hi Timur On 5 November 2015 at 21:47, Timur Tabi wrote: > Guenter Roeck wrote: >> >> I would feel much more comfortable if the driver would just use the >> standard >> watchdog timeout and live with (worst case) 20 seconds timeout for now. > > > Actually, I'm wondering where the 20 seconds comes from. When I load my > driver on our hardware, it calculates a maximum timeout of 214 seconds, and > that's just to WS0. SBSA 2.3 Page 23 : Note: the watchdog offset register is 32 bits wide. This gives a maximum watch period of around 10s at a system counter frequency of 400MHz. If a larger watch period is required then the compare value can be programmed directly into the compare value register. 214s means your system counter is approximately at 20MHz which is in the range of (10MHz ~ 400MHz) SBSA 2.3 Page 13 : The System Counter (of the Generic Timer) shall run at a minimum frequency of 10MHz and maximum of 400MHz. > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the > Code Aurora Forum, hosted by The Linux Foundation. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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: staging: most: Delete an unnecessary check before the function call "module_put"
> Please stop sending these patches for drivers/staging. Will further contributors take another look at similar update suggestions? > You are welcome to send them for other subsystems Thanks for this suggestion. > which I don't care about. I am curious if other software developers will give more positive feedback on the proposed source code fine-tuning because of collateral evolution. Regards, Markus -- 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/1] I2C: designware: fix IO timeout issue for AMD controller
On Thu, Nov 05, 2015 at 08:34:44PM +0800, Xiangliang Yu wrote:
> Because of some hardware limitation, AMD I2C controller can't
> trigger next interrupt if interrupt status has been changed
> after clearing interrupt status bits. Then, I2C will lost
> interrupt and IO timeout.
>
> According to hardware design, this patch implements a workaround
> to disable i2c controller interrupt after clearing interrupt bits
> when entering ISR and to enable i2c interrupt before exiting ISR.
>
> To reduce the performance impacts on other vendors, use unlikely
> function to check flag in ISR.
>
> Signed-off-by: Xiangliang Yu
> ---
> drivers/i2c/busses/i2c-designware-core.c| 6 ++
> drivers/i2c/busses/i2c-designware-core.h| 1 +
> drivers/i2c/busses/i2c-designware-platdrv.c | 4
> 3 files changed, 11 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c
> b/drivers/i2c/busses/i2c-designware-core.c
> index 7441cdc..04e7b65 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -783,6 +783,9 @@ irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
>
> stat = i2c_dw_read_clear_intrbits(dev);
What if the status changes right here, before you go and mask the
interrupt?
>
> + if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
> + i2c_dw_disable_int(dev);
> +
> if (stat & DW_IC_INTR_TX_ABRT) {
> dev->cmd_err |= DW_IC_ERR_TX_ABRT;
> dev->status = STATUS_IDLE;
> @@ -811,6 +814,9 @@ tx_aborted:
> if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) || dev->msg_err)
> complete(>cmd_complete);
>
> + if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
> + dw_writel(dev, DW_IC_INTR_DEFAULT_MASK, DW_IC_INTR_MASK);
The driver disables TX interrupt when it is not needed anymore or when
TX gets aborted but the above will re-enable all interrupts regardless.
Is that the intention?
> +
> return IRQ_HANDLED;
> }
> EXPORT_SYMBOL_GPL(i2c_dw_isr);
> diff --git a/drivers/i2c/busses/i2c-designware-core.h
> b/drivers/i2c/busses/i2c-designware-core.h
> index 9630222..808ef6a 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -111,6 +111,7 @@ struct dw_i2c_dev {
>
> #define ACCESS_SWAP 0x0001
> #define ACCESS_16BIT 0x0002
> +#define ACCESS_INTR_MASK 0x0004
>
> extern u32 dw_readl(struct dw_i2c_dev *dev, int offset);
> extern void dw_writel(struct dw_i2c_dev *dev, u32 b, int offset);
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 472b882..0c59357 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -251,6 +251,10 @@ static int dw_i2c_probe(struct platform_device *pdev)
> dev->rx_fifo_depth = ((param1 >> 8) & 0xff) + 1;
> dev->adapter.nr = pdev->id;
> }
> +
> + if (!strncmp(pdev->name, "AMD0010", 7))
> + dev->accessor_flags |= ACCESS_INTR_MASK;
> +
Can't you put this to ->driver_data? For example it could refer to a
configuration structure that then contains quirk flags.
> r = i2c_dw_init(dev);
> if (r)
> return r;
> --
> 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 1/4] arm64: dts: Reserve memory regions for hi6220
On Thu, Oct 29, 2015 at 04:33:01PM +0800, Leo Yan wrote:
> On Wed, Oct 28, 2015 at 11:32:29PM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 9:20 AM, Leo Yan wrote:
> > > On Fri, Oct 09, 2015 at 08:50:13AM -0500, Rob Herring wrote:
> > >> On Fri, Oct 9, 2015 at 8:30 AM, Mark Rutland
> > >> wrote:
> > >> > On Fri, Oct 09, 2015 at 08:17:16AM -0500, Rob Herring wrote:
> > >> >> On Thu, Oct 8, 2015 at 11:36 PM, Leo Yan wrote:
> > >> >> > On Hi6220, below memory regions in DDR have specific purpose:
> > >> >> >
> > >> >> > 0x05e0, - 0x05ef,: For MCU firmware using at runtime;
> > >> >> > 0x06df,f000 - 0x06df,: For mailbox message data;
> > >> >> > 0x0740,f000 - 0x0740,: For MCU firmware's section;
> > >> >> > 0x3e00, - 0x3fff,: For OP-TEE.
> > >> >> >
> > >> >> > This patch reserves these memory regions in DT.
> > >> >> >
> > >> >> > Signed-off-by: Leo Yan
> > >> >> > ---
> > >> >> > arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 16
> > >> >> >
> > >> >> > 1 file changed, 12 insertions(+), 4 deletions(-)
> > >> >> >
> > >> >> > diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > >> >> > b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > >> >> > index e36a539..e3f4cb3 100644
> > >> >> > --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > >> >> > +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > >> >> > @@ -7,9 +7,6 @@
> > >> >> >
> > >> >> > /dts-v1/;
> > >> >> >
> > >> >> > -/*Reserved 1MB memory for MCU*/
> > >> >> > -/memreserve/ 0x05e0 0x0010;
> > >> >> > -
> > >> >>
> > >> >> Why does memreserve not work for you? You can have multiple entries.
> > >> >>
> > >> >> > #include "hi6220.dtsi"
> > >> >> >
> > >> >> > / {
> > >> >> > @@ -24,8 +21,19 @@
> > >> >> > stdout-path = "serial0:115200n8";
> > >> >> > };
> > >> >> >
> > >> >> > + /*
> > >> >> > +* Reserve below regions from memory node:
> > >> >> > +*
> > >> >> > +* - 0x05e0, - 0x05ef,: MCU firmware runtime using
> > >> >> > +* - 0x06df,f000 - 0x06df,: Mailbox message data
> > >> >> > +* - 0x0740,f000 - 0x0740,: MCU firmware section
> > >> >> > +* - 0x3e00, - 0x3fff,: OP-TEE
> > >> >> > +*/
> > >> >> > memory@0 {
> > >> >> > device_type = "memory";
> > >> >> > - reg = <0x0 0x0 0x0 0x4000>;
> > >> >> > + reg = <0x 0x 0x 0x05e0>,
> > >> >> > + <0x 0x05f0 0x 0x00eff000>,
> > >> >> > + <0x 0x06e0 0x 0x0060f000>,
> > >> >> > + <0x 0x0741 0x 0x36bf>;
> > >> >>
> > >> >> No, don't do this. Please use memreserve or reserved-memory binding[1]
> > >> >> or combination of both. Probably reserved-memory if you need the
> > >> >> kernel to access some of these regions.
> > >> >
> > >> > I disagree at least for those portions owned by the secure world. The
> > >> > kernel shouldn't map those at all, so memreserve isn't appropriate.
> > >> > That
> > >> > covers OP-TEE and the MCU firmware regions, and I'd expec the EFI
> > >> > memory
> > >> > map to not list those as available to the kernel.
> > >>
> > >> I'm fine carving out the beginning or end, but otherwise think memory
> > >> should correspond to the physical memory. We have a way to describe
> > >> holes to keep out, so we should use them. If secure world uses the DT,
> > >> then it would either want to know its region in memory or add the DT
> > >> data to say what it is using. We need that to be easy to find or easy
> > >> to set, respectively. The size secure world needs could vary as well.
> > >>
> > >> The fact that the kernel maps the memory is the kernel's problem, not
> > >> a DT problem.
> > >>
> > >
> > > Just give more input here. In previous time, we have long discussion [1];
> > > So actually your suggestion is exactly same what my old patch.
> > >
> > > From previous discussion, i think here have an assumtion: Use UEFI as
> > > bootloader, the kernel will ignore (or remove) memreserve and
> > > reserved-memory
> > > nodes, so just like Mark said "the EFI memory map to not list those
> > > as available to the kernel". My new patch is just to follow this and
> > > also make sure they have same behavior for different bootloader
> > > (between UEFI and uboot).
> >
> > I've read thru the thread and see 2 main conclusions. Using
> > reserved-memory is problematic since things like grub don't support
> > that. That is fine and we should stick with /mem-reserve/ for now.
>
> Thanks for reviewing, Rob.
>
> One thing should note: after booting with UEFI, /memreserve/ nodes
> will be deleted by UEFI stub; and _ONLY_ can use /reserved-memory/
> node to reserve memory regions.
>
> Ard have another patch [1], after applied this patch, then all
> /memreserve/ nodes and /reserved-memory/
Re: [PATCH v6 11/17] ptrace: Allow compat to use the native siginfo
On Tuesday 03 November 2015 02:30:40 Yury Norov wrote: > From: Andrew Pinski > > Set COMPAT_USE_NATIVE_SIGINFO to be true for non AARCH32 tasks. > > With ARM64 ILP32 ABI, we want to use the non-compat > siginfo as we want to simplify signal handling for this new ABI. > This patch just adds a new define COMPAT_USE_NATIVE_SIGINFO and > if it is true then read/write in the compat case as it was the > non-compat case. Why does this use compat_ptrace_request()? I assume there is a good reason for it, but I'm surprised you don't use the native 64-bit ptrace syscall. Arnd -- 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: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/05/2015 04:13 AM, Sander Eikelenboom wrote: It makes "cat /sys/kernel/debug/kernel_page_tables" work and prevents a kernel with CONFIG_DEBUG_WX=y from crashing at boot. Great. Our nightly runs also failed spectacularly due to this bug. It now does give a warning about an insecure W+X mapping, so CONFIG_DEBUG_WX=y seems to be working. No idea how to interpret it though (and if it's a legit warning). -- Sander [ 19.034706] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 19.041339] Write protecting the kernel read-only data: 18432k [ 19.052596] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 19.060285] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 19.067079] [ cut here ] [ 19.073931] WARNING: CPU: 5 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x619/0x7e0() Yes, this apparently is a known issue: https://lkml.org/lkml/2015/11/4/476 -boris -- 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: [Bugfix v4] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32-bit kernel
On 05.11.2015 14:24, Jiang Liu wrote:
On 2015/11/5 20:53, Tomasz Nowicki wrote:
On 02.11.2015 16:27, Tomasz Nowicki wrote:
On 08.07.2015 09:26, Jiang Liu wrote:
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver
loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived
with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because
of this,
either ACPI or the Realtek chip kept the bad state and after
rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to
beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final.
3.18.16 was
good."
The regression is caused by commit 593669c2ac0f ("x86/PCI/ACPI: Use
common
ACPI resource interfaces to simplify implementation"). Since commit
593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI
resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The
'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when
converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-Tested-by: Boszormenyi Zoltan
Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
interfaces to simplify implementation")
Signed-off-by: Jiang Liu
Cc: sta...@vger.kernel.org # 4.0
---
drivers/acpi/resource.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 10561ce16ed1..e8d281739cbc 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -194,6 +194,7 @@ static bool acpi_decode_space(struct resource_win
*win,
u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 :
ACPI_DECODE_16;
bool wp = addr->info.mem.write_protect;
u64 len = attr->address_length;
+u64 start, end, offset = 0;
struct resource *res = >res;
/*
@@ -205,9 +206,6 @@ static bool acpi_decode_space(struct resource_win
*win,
pr_debug("ACPI: Invalid address space min_addr_fix %d,
max_addr_fix %d, len %llx\n",
addr->min_address_fixed, addr->max_address_fixed, len);
-res->start = attr->minimum;
-res->end = attr->maximum;
-
/*
* For bridges that translate addresses across the bridge,
* translation_offset is the offset that must be added to the
@@ -215,12 +213,22 @@ static bool acpi_decode_space(struct
resource_win *win,
* primary side. Non-bridge devices must list 0 for all Address
* Translation offset bits.
*/
-if (addr->producer_consumer == ACPI_PRODUCER) {
-res->start += attr->translation_offset;
-res->end += attr->translation_offset;
-} else if (attr->translation_offset) {
+if (addr->producer_consumer == ACPI_PRODUCER)
+offset = attr->translation_offset;
+else if (attr->translation_offset)
pr_debug("ACPI: translation_offset(%lld) is invalid for
non-bridge device.\n",
attr->translation_offset);
+start = attr->minimum + offset;
+end = attr->maximum + offset;
I still see the issue for this area, I mean ACPI_IO_RANGE. You are
adding translation offset to attr->minimum, build resource structure
which is then passed to acpi_dev_ioresource_flags and compared against
0x10003. It causes some IO ranges to be ignored.
Kindly reminder, any comments?
Tomasz
Hi Tomasz,
Thanks for reporting this issue! Could you please help to
test the attached patch?
I was not able to apply your patch directly but that part:
- if (res->end >= 0x10003)
+ if (res->end - offset >= 0x10003)
res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
Re: [PATCH] staging: most: Delete an unnecessary check before the function call "module_put"
Relying on hidden sanity checks makes the code harder to read. A human being cannot remember which functions have sanity checks and which do not. These sorts of patches are easy to generate automatically but they make the code worse. There are so many *better* things to do instead of focusing on making the code bad. Please stop sending these patches for drivers/staging. You are welcome to send them for other subsystems which I don't care about. regards, dan carpenter -- 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 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
On Tuesday 03 November 2015 02:30:42 Yury Norov wrote:
> From: Andrew Pinski
>
> Add a separate syscall-table for ILP32, which dispatches either to native
> LP64 system call implementation or to compat-syscalls, as appropriate.
The uapi/asm-generic/unistd.h already contains a list of compat syscalls
that should work by default, I think it would be better to use that
list and override only the ones that differ between normal compat
mode and the new mode, e.g. when you require a wrapper or want to
use the native syscall entry.
> +/* We need to make sure the pointer gets copied correctly. */
> +asmlinkage long ilp32_sys_mq_notify(mqd_t mqdes, const struct sigevent
> __user *u_notification)
> +{
> + struct sigevent __user *p = NULL;
> + if (u_notification) {
> + struct sigevent n;
> + p = compat_alloc_user_space(sizeof(*p));
> + if (copy_from_user(, u_notification, sizeof(*p)))
> + return -EFAULT;
> + if (n.sigev_notify == SIGEV_THREAD)
> + n.sigev_value.sival_ptr =
> compat_ptr((uintptr_t)n.sigev_value.sival_ptr);
> + if (copy_to_user(p, , sizeof(*p)))
> + return -EFAULT;
> + }
> + return sys_mq_notify(mqdes, p);
> +}
Could this be avoided by defining sigval_t in a way that is
compatible?
> +/* sigevent contains sigval_t which is now 64bit always
> + but need special handling due to padding for SIGEV_THREAD. */
> +#define sys_mq_notifyilp32_sys_mq_notify
> +
> +/* sigaltstack needs some special handling as the
> + padding for stack_t might not be non-zero. */
> +long ilp32_sys_sigaltstack(const stack_t __user *uss_ptr,
> +stack_t __user *uoss_ptr)
asmlinkage?
Arnd
--
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/7] doc:bindings:Document for mtcmos regulator on hi6220 SoC
Add Document for mtcmos driver on hi6220 SoC
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
.../bindings/regulator/hisilicon,hi6220-mtcmos.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
diff --git
a/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
b/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
new file mode 100644
index 000..bb06e1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
@@ -0,0 +1,32 @@
+Hi6220 mtcmos Voltage regulators
+
+Required parent device properties:
+- compatible: Must be "hisilicon,hi6220-mtcmos-driver"
+- hisilicon,mtcmos-steady-us: The time to wait for power steady
+- hisilicon,mtcmos-sc-on-base: address of mtcmos on hi6220 SoC
+
+Required child device properties:
+- regulator-name: The name of mtcmos
+- hisilicon,ctrl-regs: Offset of ctrl-regs
+- hisilicon,ctrl-data: The bit to ctrl the regulator
+
+Example:
+mtcmos {
+compatible = "hisilicon,hi6220-mtcmos-driver";
+hisilicon,mtcmos-steady-us = <10>;
+hisilicon,mtcmos-sc-on-base = <0xf780>;
+hisilicon,mtcmos-acpu-on-base = <0xf65a>;
+
+mtcmos1: regulator@a1{
+regulator-name = "G3D_PD_VDD";
+regulator-compatible = "mtcmos1";
+hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
+hisilicon,ctrl-data = <1 0x1>;
+};
+mtcmos2: regulator@a2{
+regulator-name = "SOC_MED";
+regulator-compatible = "mtcmos2";
+hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
+hisilicon,ctrl-data = <2 0x1>;
+};
+};
--
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/
[PATCH 6/7] regulator: hisilicon: Add hi655x pmic voltage regulator driver
Add driver support for HiSilicon Hi655x voltage regulators.
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
drivers/regulator/Kconfig | 13 ++
drivers/regulator/Makefile | 2 +
drivers/regulator/hi655x-regulator.c | 246 +
include/linux/regulator/hi655x-regulator.h | 63
4 files changed, 324 insertions(+)
create mode 100644 drivers/regulator/hi655x-regulator.c
create mode 100644 include/linux/regulator/hi655x-regulator.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff..9bbd43c 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -261,6 +261,19 @@ config REGULATOR_HI6421
21 general purpose LDOs, 3 dedicated LDOs, and 5 BUCKs. All
of them come with support to either ECO (idle) or sleep mode.
+config REGULATOR_HI6220_MTCMOS
+bool "Hisilicon Hi6220 mtcmos support"
+depends on ARCH_HISI
+help
+ This driver provides support for the mtcmos regulators of Hi6220 Soc.
+
+config REGULATOR_HI655X
+bool "HiSilicon Hi655x PMIC voltage regulator support"
+depends on ARCH_HISI
+help
+ This driver provides support for the voltage regulators on the
+ HiSilicon hi655x PMIC.
+
config REGULATOR_ISL9305
tristate "Intersil ISL9305 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0f81749..7345d43 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -34,6 +34,8 @@ obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
+obj-$(CONFIG_REGULATOR_HI6220_MTCMOS) += hi6220-mtcmos.o
+obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
diff --git a/drivers/regulator/hi655x-regulator.c
b/drivers/regulator/hi655x-regulator.c
new file mode 100644
index 000..b06c810
--- /dev/null
+++ b/drivers/regulator/hi655x-regulator.c
@@ -0,0 +1,246 @@
+/*
+ * Device driver for regulators in hi655x IC
+ *
+ * Copyright (c) 2015 Hisilicon.
+ *
+ * Fei Wang
+ * Chen Feng
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int hi655x_is_enabled(struct regulator_dev *rdev)
+{
+ unsigned int value = 0;
+
+ struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+ struct hi655x_regulator_ctrl_regs *ctrl_regs = >ctrl_regs;
+
+ regmap_read(rdev->regmap, ctrl_regs->status_reg, );
+ return (value & BIT(regulator->ctrl_mask));
+}
+
+static int hi655x_enable(struct regulator_dev *rdev)
+{
+ int ret = 0;
+ struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+ struct hi655x_regulator_ctrl_regs *ctrl_regs = >ctrl_regs;
+
+ ret = regmap_update_bits(rdev->regmap, ctrl_regs->enable_reg,
+regulator->ctrl_mask, regulator->ctrl_mask);
+ return ret;
+}
+
+static int hi655x_disable(struct regulator_dev *rdev)
+{
+ int ret = 0;
+ struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+
+ if (!regulator) {
+ pr_err("get driver data error!\n");
+ return -ENODEV;
+ }
+ struct hi655x_regulator_ctrl_regs *ctrl_regs = >ctrl_regs;
+
+ ret = regmap_update_bits(rdev->regmap, ctrl_regs->disable_reg,
+regulator->ctrl_mask, regulator->ctrl_mask);
+ return ret;
+}
+
+static int hi655x_get_voltage(struct regulator_dev *rdev)
+{
+ unsigned int value = 0;
+ struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+
+ if (!regulator) {
+ pr_err("get driver data error!\n");
+ return -ENODEV;
+ }
+ struct hi655x_regulator_vset_regs *vset_regs = >vset_regs;
+
+ regmap_read(rdev->regmap, vset_regs->vset_reg, );
+
+ return regulator->vset_table[value];
+}
+
+static int hi655x_set_voltage(struct regulator_dev *rdev,
+ int min_uV, int max_uV, unsigned *selector)
+{
+ int i = 0;
+ int ret = 0;
+ int vol = 0;
+ struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
+
+ if (!regulator) {
+ pr_err("get driver data error!\n");
+ return -ENODEV;
+ }
+
+ struct hi655x_regulator_vset_regs *vset_regs = >vset_regs;
+
+ /**
+
Re: [PATCH] PCI: rcar (usb): DT can override default window settings
On Tue, Nov 03, 2015 at 04:19:26PM +, Phil Edworthy wrote:
> If the dtb specifies dma-ranges, we use those values. Otherwise, we
> default to the values that were previously hardcoded into the driver.
>
> Signed-off-by: Phil Edworthy
> ---
> .../devicetree/bindings/pci/pci-rcar-gen2.txt | 6 ++
Acked-by: Rob Herring
> drivers/pci/host/pci-rcar-gen2.c | 76
> +-
> 2 files changed, 79 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index 7fab84b..891463c 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -24,6 +24,11 @@ Required properties:
> - interrupt-map-mask: standard property that helps to define the interrupt
>mapping.
>
> +Optional properties:
> +- dma-ranges: a single range for the inbound memory region. If not supplied,
> + defaults to 1GiB at 0x4000. Note there are hardware restrictions on the
> + allowed combinations of address and size.
> +
> Example SoC configuration:
>
> pci0: pci@ee09 {
> @@ -38,6 +43,7 @@ Example SoC configuration:
> #address-cells = <3>;
> #size-cells = <2>;
> #interrupt-cells = <1>;
> + dma-ranges = <0x4200 0 0x4000 0 0x4000 0
> 0x4000>;
> interrupt-map-mask = <0xff00 0 0 0x7>;
> interrupt-map = <0x 0 0 1 0 108 IRQ_TYPE_LEVEL_HIGH
>0x0800 0 0 1 0 108 IRQ_TYPE_LEVEL_HIGH
> diff --git a/drivers/pci/host/pci-rcar-gen2.c
> b/drivers/pci/host/pci-rcar-gen2.c
> index c4f64bf..6295116 100644
> --- a/drivers/pci/host/pci-rcar-gen2.c
> +++ b/drivers/pci/host/pci-rcar-gen2.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -102,6 +103,8 @@ struct rcar_pci_priv {
> unsigned busnr;
> int irq;
> unsigned long window_size;
> + unsigned long window_addr;
> + unsigned long window_pci;
> };
>
> /* PCI configuration space operations */
> @@ -239,8 +242,8 @@ static int rcar_pci_setup(int nr, struct pci_sys_data
> *sys)
> RCAR_PCI_ARBITER_PCIBP_MODE;
> iowrite32(val, reg + RCAR_PCI_ARBITER_CTR_REG);
>
> - /* PCI-AHB mapping: 0x4000 base */
> - iowrite32(0x4000 | RCAR_PCIAHB_PREFETCH16,
> + /* PCI-AHB mapping */
> + iowrite32(priv->window_addr | RCAR_PCIAHB_PREFETCH16,
> reg + RCAR_PCIAHB_WIN1_CTR_REG);
>
> /* AHB-PCI mapping: OHCI/EHCI registers */
> @@ -251,7 +254,7 @@ static int rcar_pci_setup(int nr, struct pci_sys_data
> *sys)
> iowrite32(RCAR_AHBPCI_WIN1_HOST | RCAR_AHBPCI_WIN_CTR_CFG,
> reg + RCAR_AHBPCI_WIN1_CTR_REG);
> /* Set PCI-AHB Window1 address */
> - iowrite32(0x4000 | PCI_BASE_ADDRESS_MEM_PREFETCH,
> + iowrite32(priv->window_pci | PCI_BASE_ADDRESS_MEM_PREFETCH,
> reg + PCI_BASE_ADDRESS_1);
> /* Set AHB-PCI bridge PCI communication area address */
> val = priv->cfg_res->start + RCAR_AHBPCI_PCICOM_OFFSET;
> @@ -284,6 +287,64 @@ static struct pci_ops rcar_pci_ops = {
> .write = pci_generic_config_write,
> };
>
> +static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "dma-ranges", );
> + if (!parser->range)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> + return 0;
> +}
> +
> +static int rcar_pci_parse_map_dma_ranges(struct rcar_pci_priv *pci,
> + struct device_node *np)
> +{
> + struct of_pci_range range;
> + struct of_pci_range_parser parser;
> + int index = 0;
> +
> + /* Failure to parse is ok as we fall back to defaults */
> + if (pci_dma_range_parser_init(, np))
> + return 0;
> +
> + /* Get the dma-ranges from DT */
> + for_each_of_pci_range(, ) {
> + /* Hardware only allows one inbound 32-bit range */
> + if (index)
> + return -EINVAL;
> +
> + pci->window_addr = (unsigned long)range.cpu_addr;
> + pci->window_pci = (unsigned long)range.pci_addr;
> + pci->window_size = (unsigned long)range.size;
> +
> + /* Catch HW limitations */
> + if (!(range.flags & IORESOURCE_PREFETCH)) {
> + dev_err(pci->dev, "window must be prefetchable\n");
> + return -EINVAL;
> + }
> + if (pci->window_addr) {
> + u32
[PATCH 5/7] regulator: add driver for mtcmos voltage regulator on hi6220 SoC
Add driver to support mtcmos on hi6220
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
drivers/regulator/hi6220-mtcmos.c | 245 ++
1 file changed, 245 insertions(+)
create mode 100644 drivers/regulator/hi6220-mtcmos.c
diff --git a/drivers/regulator/hi6220-mtcmos.c
b/drivers/regulator/hi6220-mtcmos.c
new file mode 100644
index 000..c79ffc0
--- /dev/null
+++ b/drivers/regulator/hi6220-mtcmos.c
@@ -0,0 +1,245 @@
+/*
+ * Device driver for regulators in hi6220 mtcmos
+ *
+ * Copyright (c) 2015 Hisilicon.
+ *
+ * Fei Wang
+ * Chen Feng
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+enum {
+ HI6220_MTCMOS1,
+ HI6220_MTCMOS2,
+ HI6220_RG_MAX,
+};
+
+struct hi6220_mtcmos_ctrl_regs {
+ unsigned int enable_reg;
+ unsigned int disable_reg;
+ unsigned int status_reg;
+};
+
+struct hi6220_mtcmos_ctrl_data {
+ int shift;
+ unsigned int mask;
+};
+
+struct hi6220_mtcmos_info {
+ struct regulator_desc rdesc;
+ struct hi6220_mtcmos_ctrl_regs ctrl_regs;
+ struct hi6220_mtcmos_ctrl_data ctrl_data;
+};
+
+struct hi6220_mtcmos {
+ struct regulator_dev *rdev[HI6220_RG_MAX];
+ void __iomem *sc_on_regs;
+};
+
+static int hi6220_mtcmos_is_on(struct hi6220_mtcmos *mtcmos,
+ unsigned int regs, unsigned int mask, int shift)
+{
+ unsigned int ret;
+
+ ret = readl(mtcmos->sc_on_regs + regs);
+ ret &= (mask << shift);
+
+ return ret;
+}
+
+static int hi6220_mtcmos_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ struct hi6220_mtcmos_info *sreg = rdev_get_drvdata(rdev);
+ struct platform_device *pdev =
+ container_of(rdev->dev.parent, struct platform_device, dev);
+ struct hi6220_mtcmos *mtcmos = platform_get_drvdata(pdev);
+ struct hi6220_mtcmos_ctrl_regs *ctrl_regs = >ctrl_regs;
+ struct hi6220_mtcmos_ctrl_data *ctrl_data = >ctrl_data;
+
+ ret = hi6220_mtcmos_is_on(mtcmos, ctrl_regs->status_reg,
+ ctrl_data->mask, ctrl_data->shift);
+ return ret;
+}
+
+static int hi6220_mtcmos_op(struct hi6220_mtcmos *mtcmos,
+ unsigned int regs, unsigned int mask, int shift)
+{
+ writel(mask << shift, mtcmos->sc_on_regs + regs);
+
+ return 0;
+}
+
+static int hi6220_mtcmos_enable(struct regulator_dev *rdev)
+{
+ int ret;
+ struct hi6220_mtcmos_info *sreg = rdev_get_drvdata(rdev);
+ struct platform_device *pdev =
+ container_of(rdev->dev.parent, struct platform_device, dev);
+ struct hi6220_mtcmos *mtcmos = platform_get_drvdata(pdev);
+ struct hi6220_mtcmos_ctrl_regs *ctrl_regs = >ctrl_regs;
+ struct hi6220_mtcmos_ctrl_data *ctrl_data = >ctrl_data;
+
+ hi6220_mtcmos_op(mtcmos, ctrl_regs->enable_reg,
+ctrl_data->mask, ctrl_data->shift);
+ ret = hi6220_mtcmos_is_on(mtcmos, ctrl_regs->status_reg,
+ ctrl_data->mask, ctrl_data->shift)
+ return ret;
+}
+
+static int hi6220_mtcmos_disable(struct regulator_dev *rdev)
+{
+ int ret;
+ struct hi6220_mtcmos_info *sreg = rdev_get_drvdata(rdev);
+ struct platform_device *pdev =
+ container_of(rdev->dev.parent, struct platform_device, dev);
+ struct hi6220_mtcmos *mtcmos = platform_get_drvdata(pdev);
+ struct hi6220_mtcmos_ctrl_regs *ctrl_regs = >ctrl_regs;
+ struct hi6220_mtcmos_ctrl_data *ctrl_data = >ctrl_data;
+
+ ret = hi6220_mtcmos_op(mtcmos, ctrl_regs->disable_reg,
+ ctrl_data->mask, ctrl_data->shift);
+
+ return ret;
+}
+
+static struct regulator_ops hi6220_mtcmos_mtcmos_rops = {
+ .is_enabled = hi6220_mtcmos_is_enabled,
+ .enable = hi6220_mtcmos_enable,
+ .disable = hi6220_mtcmos_disable,
+};
+
+#define HI6220_MTCMOS(vreg) \
+{ \
+ .rdesc = { \
+ .name = #vreg, \
+ .ops= _mtcmos_mtcmos_rops, \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
+ }, \
+}
+
+static struct hi6220_mtcmos_info hi6220_mtcmos_info[] = {
+ HI6220_MTCMOS(MTCMOS1),
+ HI6220_MTCMOS(MTCMOS2),
+};
+
+static struct of_regulator_match hi6220_mtcmos_matches[] = {
+ { .name = "mtcmos1",
+ .driver_data = _mtcmos_info[HI6220_MTCMOS1], },
+ { .name = "mtcmos2",
+
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Guenter Roeck wrote: I would feel much more comfortable if the driver would just use the standard watchdog timeout and live with (worst case) 20 seconds timeout for now. Actually, I'm wondering where the 20 seconds comes from. When I load my driver on our hardware, it calculates a maximum timeout of 214 seconds, and that's just to WS0. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- 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] mm, hugetlb: use memory policy when available
On 10/20/2015 09:53 PM, Dave Hansen wrote:
> From: Dave Hansen
>
> I have a hugetlbfs user which is never explicitly allocating huge pages
> with 'nr_hugepages'. They only set 'nr_overcommit_hugepages' and then let
> the pages be allocated from the buddy allocator at fault time.
>
> This works, but they noticed that mbind() was not doing them any good and
> the pages were being allocated without respect for the policy they
> specified.
>
> The code in question is this:
>
>> struct page *alloc_huge_page(struct vm_area_struct *vma,
> ...
>> page = dequeue_huge_page_vma(h, vma, addr, avoid_reserve, gbl_chg);
>> if (!page) {
>> page = alloc_buddy_huge_page(h, NUMA_NO_NODE);
>
> dequeue_huge_page_vma() is smart and will respect the VMA's memory policy.
> But, it only grabs _existing_ huge pages from the huge page pool. If the
> pool is empty, we fall back to alloc_buddy_huge_page() which obviously
> can't do anything with the VMA's policy because it isn't even passed the
> VMA.
>
> Almost everybody preallocates huge pages. That's probably why nobody has
> ever noticed this. Looking back at the git history, I don't think this
> _ever_ worked from when alloc_buddy_huge_page() was introduced in 7893d1d5,
> 8 years ago.
>
> The fix is to pass vma/addr down in to the places where we actually call in
> to the buddy allocator. It's fairly straightforward plumbing. This has
> been lightly tested.
>
> Cc: Andrew Morton
> Cc: Naoya Horiguchi
> Cc: Mike Kravetz
> Cc: Hillf Danton
> Cc: David Rientjes
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Dave Hansen
Together with the fix and NUMA=n cleanup
Acked=by: Vlastimil Babka
--
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: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Fu Wei wrote: (1)It is not new. pre-timeout concept has been used by two drivers before this driver. and this concept has been in kernel documentation. It's "new" in that it's a new infrastructure. The private API of two other drivers doesn't count. (1) if we don't, for this two stages timeout, we have to config them by one value. that means "the first stage timeout" have to be equal to "the second stage timeout", For example, if we need 60 second for "the second stage timeout", 30 or less for "the first stage timeout". then "the first stage timeout" have to be 60s too. I don't think it 's good idea. Why do we care about two stages? Don't have a pre-timeout, and just have one stage: the WS1 reset. Ignore the WS0 interrupt, and program the timeout so that WS1 is the reset. I'm not saying that pre-timeout is a terrible idea and we should never do it. I'm saying that it's not an important feature, and we should only support it to the extent that the hardware provides the feature. We should definitely not make the driver more complicated and less safe. If we agree that an SBSA watchdog allows for a pre-timeout at half-way through timeout, and that software can't change this, then we can use WS0 as the pre-timeout and applications just have to deal with that. The hardware is programmed to reset via WS1, and all we do in the interrupt handler is notify the application that a pre-timeout has occurred. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- 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/7] doc:bindings:Document for hi655x pmic driver
Add Document for hi655x pmic driver
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
.../regulator/hisilicon,hi655x-regulator.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
diff --git
a/Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
b/Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
new file mode 100644
index 000..66c6a73
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
@@ -0,0 +1,50 @@
+Hisilicon Hi655x Voltage regulators
+
+Note:
+The hi655x regulator control is managed by hi655x Power IC.
+So the node of this regulator must be child node of hi655x
+pmic node.
+
+The driver uses the regulator core framework, so please also
+take the bindings of regulator.txt for reference.
+
+Required properties:
+- compatible: Must be "hisilicon,hi655x-regulator-pmic";
+- regulator-name: Regulator name in SoC.
+- regulator-min-microvolt: Smallest voltage support.
+- regulator-max-microvolt: Largest voltages support.
+- regulator-initial-mode: Init mode of this regulator.
+- regulator-valid-modes-mask: Valid support mode mask.
+- regulator-off-on-delay: The time wait for power steady
+- regulator-ctrl-regs: Registers offset of control register.
+ In turn with enable disable and status register offset.
+- regulator-ctrl-mask: The control mask of the register.
+- regulator-vset-regs: Voltage set register offset.
+- regulator-vset-mask: voltage set control mask.
+- regulator-n-vol: The num of support voltages.
+- regulator-vset-table: The table of support voltages.
+
+Example:
+pmic: pmic@f800 {
+compatible = "hisilicon,hi655x-pmic-driver";
+ ...
+ldo2: regulator@a21 {
+compatible = "hisilicon,hi655x-regulator-pmic";
+regulator-name = "ldo2";
+regulator-min-microvolt = <250>;
+regulator-max-microvolt = <320>;
+regulator-valid-modes-mask = <0x02>;
+regulator-initial-mode = <0x02>;
+regulator-off-on-delay = <120>;
+regulator-ctrl-regs = <0x029 0x02a 0x02b>;
+regulator-ctrl-mask = <0x1>;
+regulator-vset-regs = <0x072>;
+regulator-vset-mask = <0x3>;
+regulator-n-vol = <8>;
+regulator-vset-table = <250>,<260>,
+<270>,<280>,
+<290>,<300>,
+<310>,<320>;
+};
+ ...
+ }
--
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] w1: w1_process() is not freezable kthread
Hi 28.10.2015, 08:26, "Jiri Kosina" : > On Tue, 27 Oct 2015, Evgeniy Polyakov wrote: > >> > w1_process() calls try_to_freeze(), but the thread doesn't mark itself >> > freezable through set_freezable(), so the try_to_freeze() call is useless. >> >> I believe it is better to mark it freezable, what do you think? Its task >> is useless if anyone else goes sleeping, it should freeze too. > > I fail to see why this kthread should be freezable at all. There is no way > for w1 device to generate new I/O requests that should be written out to > filesystem, is it? w1 doesn't generate such requests, but it was more to make this thread consistent with majority of other threads in the kernel. Ok, I'm not against it, Greg please pull this patch into your tree. Acked-by: Evgeniy Polyakov -- 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/7] Add Support for Hi6220 PMIC Hi6553 MFD Core
The patch sets add support for Hi6220 PMIC Hi655x MFD core and its regulator driver. Current testing and support board is Hikey which is one of 96boards. It is an arm64 open source board. For more information about this board, please access https://www.96boards.org. This is hardware layout for access PMIC Hi655x from AP SoC Hi6220. Between PMIC Hi655x and Hi6220, the physical signal channel is SSI. We can use memory-mapped I/O to communicate. ++ +-+ || | | |Hi6220 | SSI bus | Hi655x| ||-| | ||(REGMAP_MMIO)| | ++ +-+ The patch sets are based on 4.3-rc7. Chen Feng (7): doc:bindings:Add document for mfd hi665x PMIC doc:bindings:Document for mtcmos regulator on hi6220 SoC doc:bindings:Document for hi655x pmic driver mfd: hi655x: Add hi665x pmic driver regulator: add driver for mtcmos voltage regulator on hi6220 SoC regulator: hisilicon: Add hi655x pmic voltage regulator driver arm64: dts: Add mtcmos and pmic node for hi6220 HiKey board .../devicetree/bindings/mfd/hisilicon,hi655x.txt | 18 ++ .../bindings/regulator/hisilicon,hi6220-mtcmos.txt | 32 +++ .../regulator/hisilicon,hi655x-regulator.txt | 50 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 210 ++ drivers/mfd/Kconfig| 9 + drivers/mfd/Makefile | 1 + drivers/mfd/hi655x-pmic.c | 315 + drivers/regulator/Kconfig | 13 + drivers/regulator/Makefile | 2 + drivers/regulator/hi6220-mtcmos.c | 245 drivers/regulator/hi655x-regulator.c | 246 include/linux/mfd/hi655x-pmic.h| 50 include/linux/regulator/hi655x-regulator.h | 63 + 13 files changed, 1254 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt create mode 100644 Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt create mode 100644 Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt create mode 100644 drivers/mfd/hi655x-pmic.c create mode 100644 drivers/regulator/hi6220-mtcmos.c create mode 100644 drivers/regulator/hi655x-regulator.c create mode 100644 include/linux/mfd/hi655x-pmic.h create mode 100644 include/linux/regulator/hi655x-regulator.h -- 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/
[PATCH] staging: most: Delete an unnecessary check before the function call "module_put"
From: Markus Elfring Date: Thu, 5 Nov 2015 14:34:43 +0100 The module_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/staging/most/mostcore/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/most/mostcore/core.c b/drivers/staging/most/mostcore/core.c index 19852ca..ed1ed25 100644 --- a/drivers/staging/most/mostcore/core.c +++ b/drivers/staging/most/mostcore/core.c @@ -1587,8 +1587,7 @@ out: return 0; error: - if (iface->mod) - module_put(iface->mod); + module_put(iface->mod); modref--; mutex_unlock(>start_mutex); return ret; -- 2.6.2 -- 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/7] doc:bindings:Add document for mfd hi665x PMIC
Add document for mfd driver hi655x pmic driver
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
.../devicetree/bindings/mfd/hisilicon,hi655x.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
new file mode 100644
index 000..afa2fa5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
@@ -0,0 +1,18 @@
+Hisilicon hi655x Power Management Integrated Circuit (PMIC)
+
+Required properties:
+- compatible: Should be "hisilicon,hi655x-pmic-driver"
+- reg: Base address of PMIC on hi6220 soc
+- #interrupt-cells: Should be 2, two cells are needed for irq.
+- interrupt-controller: hi655x has internal IRQs (has own IRQ domain).
+- pmu_irq_gpio: should be _pmu_irq_n, is the IRQ gpio of hi655x.
+
+Example:
+ pmic: pmic@f800 {
+ compatible = "hisilicon,hi655x-pmic-driver";
+ reg = <0x0 0xf800 0x0 0x1000>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ pmic_gpios = <_pmu_irq_n>;
+ status = "okay";
+ }
--
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: [RFC PATCH 4/7] pinctrl: sunxi: remove redundant "depends on RESET_CONTROLLER"
On Thu, Nov 5, 2015 at 12:15 PM, Masahiro Yamada wrote: > ARCH_SUNXI selects RESET_CONTROLLER. > The dependency "depends on RESET_CONTROLLER" is already met. > > Signed-off-by: Masahiro Yamada NACK, this pin controller needs that as dependency, I don't worry that it's overspecified. They both do this: #include And the object should specify its dependencies, not rely on them being implicitly available. The dep is there for human readers too, not just machines. And to them, this is helpful information. Yours, Linus Walleij -- 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/7] mfd: hi655x: Add hi665x pmic driver
Add pmic driver to support hisilicon hi665x pmic.
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
drivers/mfd/Kconfig | 9 ++
drivers/mfd/Makefile| 1 +
drivers/mfd/hi655x-pmic.c | 315
include/linux/mfd/hi655x-pmic.h | 50 +++
4 files changed, 375 insertions(+)
create mode 100644 drivers/mfd/hi655x-pmic.c
create mode 100644 include/linux/mfd/hi655x-pmic.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d6367..c805071 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -273,6 +273,15 @@ config MFD_HI6421_PMIC
menus in order to enable them.
We communicate with the Hi6421 via memory-mapped I/O.
+config MFD_HI655X_PMIC
+bool "HiSilicon Hi655X series PMU/Codec IC"
+depends on ARCH_HISI
+depends on OF
+select MFD_CORE
+select REGMAP_MMIO
+help
+ Select this option to enable Hisilicon hi655x series pmic driver.
+
config HTC_EGPIO
bool "HTC EGPIO support"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fc..11ec427 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_HI655X_PMIC) += hi655x-pmic.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
obj-$(CONFIG_MFD_SKY81452) += sky81452.o
diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
new file mode 100644
index 000..942f96e
--- /dev/null
+++ b/drivers/mfd/hi655x-pmic.c
@@ -0,0 +1,315 @@
+/*
+ * Device driver for PMIC DRIVER in HI655X IC
+ *
+ * Copyright (c) 2015 Hisilicon Co. Ltd
+ *
+ * Fei Wang
+ * Chen Feng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct of_device_id of_hi655x_pmic_child_match_tbl[] = {
+ { .compatible = "hisilicon,hi655x-regulator-pmic", },
+ {},
+};
+
+static const struct of_device_id of_hi655x_pmic_match_tbl[] = {
+ { .compatible = "hisilicon,hi655x-pmic-driver", },
+ {},
+};
+
+static unsigned int hi655x_pmic_get_version(struct hi655x_pmic *pmic)
+{
+ u32 val;
+
+ regmap_read(pmic->regmap,
+ HI655X_REG_TO_BUS_ADDR(HI655X_VER_REG), );
+
+ return val;
+}
+
+static irqreturn_t hi655x_pmic_irq_handler(int irq, void *data)
+{
+ struct hi655x_pmic *pmic = (struct hi655x_pmic *)data;
+ u32 pending;
+ u32 ret = IRQ_NONE;
+ unsigned long offset;
+ int i;
+
+ for (i = 0; i < HI655X_IRQ_ARRAY; i++) {
+ regmap_read(pmic->regmap,
+ HI655X_REG_TO_BUS_ADDR(i + HI655X_IRQ_STAT_BASE),
+ );
+ if (pending)
+ pr_debug("pending[%d]=0x%x\n\r", i, pending);
+
+ /* clear pmic-sub-interrupt */
+ regmap_write(pmic->regmap,
+HI655X_REG_TO_BUS_ADDR(i + HI655X_IRQ_STAT_BASE),
+pending);
+
+ if (pending) {
+ for_each_set_bit(offset, (unsigned long *),
+HI655X_BITS)
+ generic_handle_irq(pmic->irqs[offset +
+ i * HI655X_BITS]);
+ ret = IRQ_HANDLED;
+ }
+ }
+ return ret;
+}
+
+static void hi655x_pmic_irq_mask(struct irq_data *d)
+{
+ u32 data, offset;
+ unsigned long pmic_spin_flag = 0;
+ struct hi655x_pmic *pmic = irq_data_get_irq_chip_data(d);
+
+ offset = ((irqd_to_hwirq(d) >> 3) + HI655X_IRQ_MASK_BASE);
+ spin_lock_irqsave(>ssi_hw_lock, pmic_spin_flag);
+ regmap_read(pmic->regmap, HI655X_REG_TO_BUS_ADDR(offset), );
+ data |= (1 << (irqd_to_hwirq(d) & 0x07));
+ regmap_write(pmic->regmap, HI655X_REG_TO_BUS_ADDR(offset), data);
+ spin_unlock_irqrestore(>ssi_hw_lock, pmic_spin_flag);
+}
+
+static void hi655x_pmic_irq_unmask(struct irq_data *d)
+{
+ u32 data, offset;
+ unsigned long pmic_spin_flag = 0;
+ struct hi655x_pmic
[PATCH 7/7] arm64: dts: Add mtcmos and pmic node for hi6220 HiKey board
Add dts node for hi665x pmic and hi6220 mtcmos driver
Signed-off-by: Chen Feng
Signed-off-by: Fei Wang
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 210 ++
1 file changed, 210 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..5e0b8260 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,215 @@
clocks = <_ctrl 36>, <_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+ mtcmos {
+ compatible = "hisilicon,hi6220-mtcmos-driver";
+ hisilicon,mtcmos-steady-us = <10>;
+ hisilicon,mtcmos-sc-on-base = <0xf780>;
+ hisilicon,mtcmos-acpu-on-base = <0xf65a>;
+
+ g3d_vdd: regulator@a1{
+ regulator-name = "G3D_PD_VDD";
+ regulator-compatible = "mtcmos1";
+ hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
+ hisilicon,ctrl-data = <1 0x1>;
+ };
+
+ soc_med: regulator@a2{
+ regulator-name = "SOC_MED";
+ regulator-compatible = "mtcmos2";
+ hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
+ hisilicon,ctrl-data = <2 0x1>;
+ };
+ };
+ };
+
+ pmic: pmic@f800 {
+ compatible = "hisilicon,hi655x-pmic-driver";
+ reg = <0x0 0xf800 0x0 0x1000>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ pmic-gpios = <_pmu_irq_n>;
+ status = "okay";
+ ldo2: regulator@a21 {
+ compatible = "hisilicon,hi655x-regulator-pmic";
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <320>;
+ regulator-valid-modes-mask = <0x02>;
+ regulator-initial-mode = <0x02>;
+ regulator-off-on-delay = <120>;
+ regulator-ctrl-regs = <0x029 0x02a 0x02b>;
+ regulator-ctrl-mask = <0x1>;
+ regulator-vset-regs = <0x072>;
+ regulator-vset-mask = <0x3>;
+ regulator-n-vol = <8>;
+ regulator-vset-table = <250>,<260>,
+ <270>,<280>,
+ <290>,<300>,
+ <310>,<320>;
+ };
+ ldo7: regulator@a26 {
+ compatible = "hisilicon,hi655x-regulator-pmic";
+ regulator-name = "ldo7";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-valid-modes-mask = <0x0a>;
+ regulator-initial-mode = <0x02>;
+ regulator-off-on-delay = <120>;
+ regulator-ctrl-regs = <0x029 0x02a 0x02b>;
+ regulator-ctrl-mask = <0x6>;
+ regulator-vset-regs = <0x078>;
+ regulator-vset-mask = <0x3>;
+ regulator-n-vol = <8>;
+ regulator-vset-table = <180>,<185>,
+ <285>,<290>,
+ <300>,<310>,
+ <320>,<330>;
+ };
+ ldo10: regulator@a29 {
+ compatible = "hisilicon,hi655x-regulator-pmic";
+ regulator-name = "ldo10";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ regulator-valid-modes-mask = <0x0a>;
+ regulator-initial-mode = <0x02>;
+ regulator-off-on-delay = <360>;
+ regulator-ctrl-regs = <0x02c 0x02d 0x02e>;
+ regulator-ctrl-mask = <0x1>;
+ regulator-vset-regs = <0x07b>;
+ regulator-vset-mask = <0x3>;
+ regulator-n-vol = <8>;
+ regulator-vset-table = <180>,<185>,
+ <190>,<275>,
+ <280>,<285>,
+ <290>,<300>;
+ };
+
Re: [RFC PATCH v6 00/17] ILP32 for ARM64
On Thu, Nov 5, 2015 at 7:36 PM, Andreas Schwab wrote: > Yury Norov writes: > >> v6: >> - time_t, __kenel_off_t and other types turned to be 32-bit >>for compatibility reasons (after v5 discussion); > > Are the updated glibc patches available somewhere? Not in an useful form right now but i will try to get them in an useful form sometime next week. I am traveling home on Saturday. Thanks, Andrew > > Andreas. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." -- 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 01/29] pci: Decouple quirks.c from i915_reg.h
On Wed, Nov 04, 2015 at 11:19:49PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > i915 register defines are going to become type safe, so going forward > the register defines can't be used as straight numbers. Since quirks.c > needs just a few extra register defines from i915_reg.h, decouple the > two by defining the required registers locally in quirks.c. This was > already done for a few other igpu related registers. > > Cc: Bjorn Helgaas > Cc: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/pci/quirks.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index b03373f..78a70fb 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3404,7 +3404,9 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev > *dev, int probe) > return 0; > } > > -#include "../gpu/drm/i915/i915_reg.h" > +#define SOUTH_CHICKEN2 0xc2004 > +#define PCH_PP_STATUS0xc7200 > +#define PCH_PP_CONTROL 0xc7204 > #define MSG_CTL 0x45010 > #define NSDE_PWR_STATE 0xd0100 > #define IGD_OPERATION_TIMEOUT1 /* set timeout 10 seconds */ Considering this is in a mixed set of quirks, perhaps now would be a good time to give them an I915_^W IGD_ prefix as well? But as far as the simple replacement goes, Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre -- 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: [Outreachy kernel] [PATCH v2] firewire: Replace timeval with timespec64
On Oct 22 Arnd Bergmann wrote:
> On Thursday 22 October 2015 04:05:00 Amitoj Kaur Chawla wrote:
> > 32 bit systems using 'struct timeval' will break in the year 2038, so
> > we replace the code appropriately. However, this driver is not broken
> > in 2038 since we are using only the microseconds portion of the
> > current time.
> >
> > This patch replaces timeval with timespec64.
> >
> > Signed-off-by: Amitoj Kaur Chawla
>
> Reviewed-by: Arnd Bergmann
>
> (adding the y2038 mailing list as well)
Committed to linux1394.git.
Arnd, do you have special y2038 plans that make it desirable to have this
merged before v4.4? Otherwise I would submit it for v4.5-rc1.
> > Changes in v2:
> > -Replaced timespec with timspec64
> > -Modified commit message
> > -Used ktime_get_real_ts64() instead of getnstimeofday64()
> >
> > drivers/firewire/nosy.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/firewire/nosy.c b/drivers/firewire/nosy.c
> > index 76b2d39..8a46077 100644
> > --- a/drivers/firewire/nosy.c
> > +++ b/drivers/firewire/nosy.c
> > @@ -33,6 +33,7 @@
> > #include /* required for linux/wait.h */
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -413,17 +414,18 @@ static void
> > packet_irq_handler(struct pcilynx *lynx)
> > {
> > struct client *client;
> > - u32 tcode_mask, tcode;
> > + u32 tcode_mask, tcode, timestamp;
> > size_t length;
> > - struct timeval tv;
> > + struct timespec64 ts64;
> >
> > /* FIXME: Also report rcv_speed. */
> >
> > length = __le32_to_cpu(lynx->rcv_pcl->pcl_status) & 0x1fff;
> > tcode = __le32_to_cpu(lynx->rcv_buffer[1]) >> 4 & 0xf;
> >
> > - do_gettimeofday();
> > - lynx->rcv_buffer[0] = (__force __le32)tv.tv_usec;
> > + ktime_get_real_ts64();
> > + timestamp = ts64.tv_nsec / NSEC_PER_USEC;
> > + lynx->rcv_buffer[0] = (__force __le32)timestamp;
> >
> > if (length == PHY_PACKET_SIZE)
> > tcode_mask = 1 << TCODE_PHY_PACKET;
> >
>
--
Stefan Richter
-=-= =-== --=-=
http://arcgraph.de/sr/
pgpk2T5ScpSNO.pgp
Description: OpenPGP digital signature
Re: [for-next][PATCH] tracefs: Fix refcount imbalance in start_creating()
Forgot to Cc Daniel.
-- Steve
On Thu, 5 Nov 2015 08:29:33 -0500
Steven Rostedt wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> for-next
>
> Head SHA1: d227c3ae4e94e5eb11dd780a811f59e1a7b74ccd
>
>
> Daniel Borkmann (1):
> tracefs: Fix refcount imbalance in start_creating()
>
>
> fs/tracefs/inode.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
> ---
> commit d227c3ae4e94e5eb11dd780a811f59e1a7b74ccd
> Author: Daniel Borkmann
> Date: Wed Nov 4 23:33:17 2015 +0100
>
> tracefs: Fix refcount imbalance in start_creating()
>
> In tracefs' start_creating(), we pin the file system to safely access
> its root. When we failed to create a file, we unpin the file system via
> failed_creating() to release the mount count and eventually the reference
> of the singleton vfsmount.
>
> However, when we run into an error during lookup_one_len() when still
> in start_creating(), we only release the parent's mutex but not so the
> reference on the mount.
>
> F.e., in securityfs_create_file(), after doing simple_pin_fs() when
> lookup_one_len() fails there, we infact do simple_release_fs(). This
> seems necessary here as well.
>
> Same issue seen in debugfs due to 190afd81e4a5 ("debugfs: split the
> beginning and the end of __create_file() off"), which seemed to got
> carried over into tracefs, too. Noticed during code review.
>
> Link:
> http://lkml.kernel.org/r/68efa86101b778cf7517ed7c6ad573bd69f60ec6.1446672850.git.dan...@iogearbox.net
>
> Fixes: 4282d60689d4 ("tracefs: Add new tracefs file system")
> Cc: sta...@vger.kernel.org # 4.1+
> Signed-off-by: Daniel Borkmann
> Signed-off-by: Steven Rostedt
>
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index cbc8d5d2755a..c66f2423e1f5 100644
> --- a/fs/tracefs/inode.c
> +++ b/fs/tracefs/inode.c
> @@ -340,8 +340,12 @@ static struct dentry *start_creating(const char *name,
> struct dentry *parent)
> dput(dentry);
> dentry = ERR_PTR(-EEXIST);
> }
> - if (IS_ERR(dentry))
> +
> + if (IS_ERR(dentry)) {
> mutex_unlock(>d_inode->i_mutex);
> + simple_release_fs(_mount, _mount_count);
> + }
> +
> return dentry;
> }
>
--
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/
[for-next][PATCH] tracefs: Fix refcount imbalance in start_creating()
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: d227c3ae4e94e5eb11dd780a811f59e1a7b74ccd
Daniel Borkmann (1):
tracefs: Fix refcount imbalance in start_creating()
fs/tracefs/inode.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
---
commit d227c3ae4e94e5eb11dd780a811f59e1a7b74ccd
Author: Daniel Borkmann
Date: Wed Nov 4 23:33:17 2015 +0100
tracefs: Fix refcount imbalance in start_creating()
In tracefs' start_creating(), we pin the file system to safely access
its root. When we failed to create a file, we unpin the file system via
failed_creating() to release the mount count and eventually the reference
of the singleton vfsmount.
However, when we run into an error during lookup_one_len() when still
in start_creating(), we only release the parent's mutex but not so the
reference on the mount.
F.e., in securityfs_create_file(), after doing simple_pin_fs() when
lookup_one_len() fails there, we infact do simple_release_fs(). This
seems necessary here as well.
Same issue seen in debugfs due to 190afd81e4a5 ("debugfs: split the
beginning and the end of __create_file() off"), which seemed to got
carried over into tracefs, too. Noticed during code review.
Link:
http://lkml.kernel.org/r/68efa86101b778cf7517ed7c6ad573bd69f60ec6.1446672850.git.dan...@iogearbox.net
Fixes: 4282d60689d4 ("tracefs: Add new tracefs file system")
Cc: sta...@vger.kernel.org # 4.1+
Signed-off-by: Daniel Borkmann
Signed-off-by: Steven Rostedt
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index cbc8d5d2755a..c66f2423e1f5 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -340,8 +340,12 @@ static struct dentry *start_creating(const char *name,
struct dentry *parent)
dput(dentry);
dentry = ERR_PTR(-EEXIST);
}
- if (IS_ERR(dentry))
+
+ if (IS_ERR(dentry)) {
mutex_unlock(>d_inode->i_mutex);
+ simple_release_fs(_mount, _mount_count);
+ }
+
return dentry;
}
--
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] mm: slab: Only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE
On Thu, 5 Nov 2015 11:50:35 + Catalin Marinas
wrote:
> Commit 8fc9cf420b36 ("slab: make more slab management structure off the
> slab") enables off-slab management objects for sizes starting with
> PAGE_SIZE >> 5. This means 128 bytes for a 4KB page configuration.
> However, on systems with a KMALLOC_MIN_SIZE of 128 (arm64 in 4.4), such
> optimisation does not make sense since the slab management allocation
> would take 128 bytes anyway (even though freelist_size is 32) with the
> additional overhead of another allocation.
>
> This patch introduces an OFF_SLAB_MIN_SIZE macro which takes
> KMALLOC_MIN_SIZE into account. It also solves a slab bug on arm64 where
> the first kmalloc_cache to be initialised after slab_early_init = 0,
> "kmalloc-128", fails to allocate off-slab management objects from the
> same "kmalloc-128" cache.
That all seems to be quite minor stuff.
> Fixes: 8fc9cf420b36 ("slab: make more slab management structure off the slab")
> Cc: # 3.15+
Yet you believe the fix should be backported.
So, the usual refrain: when fixing a bug, please describe the end-user
visible effects of that bug.
--
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/1] staging: rdma: hfi1 : Prefer using the BIT macro
On Thu, Nov 05, 2015 at 05:28:03PM +0530, Sunny Kumar wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro > > Signed-off-by: Sunny Kumar > --- > drivers/staging/rdma/hfi1/user_sdma.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > /* Last packet in the request */ > -#define TXREQ_FLAGS_REQ_LAST_PKT (1 << 0) > -#define TXREQ_FLAGS_IOVEC_LAST_PKT (1 << 0) > +#define TXREQ_FLAGS_REQ_LAST_PKT BIT(1 << 0) > +#define TXREQ_FLAGS_IOVEC_LAST_PKT BIT(1 << 0) > It is wrong. It actually creates 0x2 instead of 0x1. > -#define SDMA_PKT_Q_INACTIVE (1 << 0) > -#define SDMA_PKT_Q_ACTIVE (1 << 1) > -#define SDMA_PKT_Q_DEFERRED (1 << 2) > +#define SDMA_PKT_Q_INACTIVE BIT(1 << 0) > +#define SDMA_PKT_Q_ACTIVE BIT(1 << 1) > +#define SDMA_PKT_Q_DEFERRED BIT(1 << 2) The same comment as above. It is wrong. -- 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: ptrace and pseudoterminals
On 11/04/2015 02:43 PM, Oleg Nesterov wrote: > On 11/04, Peter Hurley wrote: >> >> Hi Pavel, >> >> On 11/03/2015 06:16 PM, Pavel Labath wrote: >>> Hello Oleg, everyone, >>> >>> I have noticed something, which may be considered a race in the >>> interaction of ptrace and pseudoterminal interfaces. Basically, what >>> happens is this: >>> - we have two processes: A and B. B has the slave end of the pty open, >>> A has the master. A is tracing B. >>> - B writes some data through the slave end and then stops. >>> - A waits for B to stop. >>> - A does a select on the master pty endpoint. select returns there is >>> no data available >>> - later, A tries the select again, and this time the data appears. >> >> This happens because a separate kworker processes the input from slave >> and wakes the master. At the moment of select() on the master pty, the >> kworker has not processed the latest input (in fact it may only be >> scheduled and not running yet). >> >> Essentially, you're measuring a asynchronous i/o path with a synchronous >> method. > > Thanks a lot Peter! > >>> We are encountering this (very rare) issue in our debugger test suite, >>> where we check the stdout of the tracee to make sure it is behaving as >>> expected. I have attached a small program reproducing this behavior >>> (it fails after about 1000 iterations on a 3.13.0 kernel, I can retry >>> it on a newer kernel next week if you believe it might work there). >>> Interestingly, when I replace the pty with a regular pipe, it works as >>> expected (the data is available as soon as the program stops). >>> >>> My question is: Is this behavior something that you would consider a >>> bug? If yes, do you have any pointers, as to where I should look to >>> fix it? >> >> I don't consider it a bug. >> >> That said, I could see a couple of different ways to add this >> functionality: >> 1. Implement f_op->fsync() for ttys, which would flush the workqueue >>(thus waiting for i/o completion). The debugger would fsync() before >>select() on the master. >> 2. Automagically for ptraced processes. The basic idea would be that >>writes to the slave end while a process was being ptraced would >>set state that would trigger workqueue flush by select/poll/read of >>the master end. > > Oh, I don't think "Automagically if ptrace" makes any sense... What makes > ptrace special? Afaics nothing. > > We can modify this test-case to use signals/futexes/whatever to let the > the parent know that the child has already done write(writefd), and it can > "fail" the same way. True. Also, new patches in mainline head make this _much_ less likely by scheduling the input processing kworker on the unbound wq (which means the kworker can start immediately on another cpu rather than pinned to the cpu performing the slave write). After thinking more about this, this use-case seems trivially solvable by re-select()ing with a timeout prior to reporting mismatch output failure. Regards, Peter Hurley -- 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/
How to mark suspicious code?
Hi all! How can I mark suspicious code, if I can not fix it? -- 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: [Bugfix v4] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32-bit kernel
On 2015/11/5 20:53, Tomasz Nowicki wrote:
> On 02.11.2015 16:27, Tomasz Nowicki wrote:
>> On 08.07.2015 09:26, Jiang Liu wrote:
>>> Zoltan Boszormenyi reported this regression:
>>>"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
>>> 1565:230e) network chip on the mainboard. After the r8169 driver
>>> loaded
>>> the IRQs in the machine went berserk. Keyboard keypressed arrived
>>> with
>>> considerable latency and duplicated, so no real work was possible.
>>> The machine responded to the power button but didn't actually power
>>> down. It just stuck at the powering down message. I had to press the
>>> power button for 4 seconds to power it down.
>>>
>>> The computer is a POS machine with a big battery inside. Because
>>> of this,
>>> either ACPI or the Realtek chip kept the bad state and after
>>> rebooting,
>>> the network chip didn't even show up in lspci. Not even the PXE ROM
>>> announced itself during boot. I had to disconnect the battery to
>>> beat
>>> some sense back to the computer.
>>>
>>> The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final.
>>> 3.18.16 was
>>> good."
>>>
>>> The regression is caused by commit 593669c2ac0f ("x86/PCI/ACPI: Use
>>> common
>>> ACPI resource interfaces to simplify implementation"). Since commit
>>> 593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI
>>> resources by
>>> first converting an ACPI resource to a 'struct resource' structure and
>>> then applying checks against the converted resource structure. The
>>> 'start'
>>> and 'end' fields in 'struct resource' are defined to be type of
>>> resource_size_t, which may be 32 bits or 64 bits depending on
>>> CONFIG_PHYS_ADDR_T_64BIT.
>>>
>>> This may cause incorrect resource validation results with 32-bit kernels
>>> because 64-bit ACPI resource descriptors may get truncated when
>>> converting
>>> to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
>>> affects PCI resource allocation subsystem and makes some PCI devices and
>>> the system behave abnormally due to incorrect resource assignment.
>>>
>>> So enhance the ACPI resource parsing interfaces to ignore ACPI resource
>>> descriptors with address/offset above 4G when running in 32-bit mode.
>>>
>>> With the fix applied, the behavior of the machine was restored to how
>>> 3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
>>> and lspci -vvxxx shows that everything is at the same memory window as
>>> they were with 3.18.16.
>>>
>>> Reported-and-Tested-by: Boszormenyi Zoltan
>>> Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
>>> interfaces to simplify implementation")
>>> Signed-off-by: Jiang Liu
>>> Cc: sta...@vger.kernel.org # 4.0
>>> ---
>>> drivers/acpi/resource.c | 24 +++-
>>> 1 file changed, 15 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>>> index 10561ce16ed1..e8d281739cbc 100644
>>> --- a/drivers/acpi/resource.c
>>> +++ b/drivers/acpi/resource.c
>>> @@ -194,6 +194,7 @@ static bool acpi_decode_space(struct resource_win
>>> *win,
>>> u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 :
>>> ACPI_DECODE_16;
>>> bool wp = addr->info.mem.write_protect;
>>> u64 len = attr->address_length;
>>> +u64 start, end, offset = 0;
>>> struct resource *res = >res;
>>>
>>> /*
>>> @@ -205,9 +206,6 @@ static bool acpi_decode_space(struct resource_win
>>> *win,
>>> pr_debug("ACPI: Invalid address space min_addr_fix %d,
>>> max_addr_fix %d, len %llx\n",
>>>addr->min_address_fixed, addr->max_address_fixed, len);
>>>
>>> -res->start = attr->minimum;
>>> -res->end = attr->maximum;
>>> -
>>> /*
>>>* For bridges that translate addresses across the bridge,
>>>* translation_offset is the offset that must be added to the
>>> @@ -215,12 +213,22 @@ static bool acpi_decode_space(struct
>>> resource_win *win,
>>>* primary side. Non-bridge devices must list 0 for all Address
>>>* Translation offset bits.
>>>*/
>>> -if (addr->producer_consumer == ACPI_PRODUCER) {
>>> -res->start += attr->translation_offset;
>>> -res->end += attr->translation_offset;
>>> -} else if (attr->translation_offset) {
>>> +if (addr->producer_consumer == ACPI_PRODUCER)
>>> +offset = attr->translation_offset;
>>> +else if (attr->translation_offset)
>>> pr_debug("ACPI: translation_offset(%lld) is invalid for
>>> non-bridge device.\n",
>>>attr->translation_offset);
>>> +start = attr->minimum + offset;
>>> +end = attr->maximum + offset;
>>
>> I still see the issue for this area, I mean ACPI_IO_RANGE. You are
>> adding translation offset to attr->minimum, build resource structure
>> which is then passed to acpi_dev_ioresource_flags and compared against
>> 0x10003. It causes some IO ranges to be ignored.
>>
>
[PATCH] mfd: syscon: check 'property' before of_node_put
When 'property' is not NULL, of_parse_phandle will return the node pointer with refcount incremented. So when of_node_put, also need to check property. Signed-off-by: Peng Fan Cc: Lee Jones Cc: Arnd Bergmann --- drivers/mfd/syscon.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index 176bf0f..fab36bc 100644 --- a/drivers/mfd/syscon.c +++ b/drivers/mfd/syscon.c @@ -168,7 +168,9 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np, return ERR_PTR(-ENODEV); regmap = syscon_node_to_regmap(syscon_np); - of_node_put(syscon_np); + + if (property) + of_node_put(syscon_np); return regmap; } -- 1.8.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/
Re: [PATCH] perf tools: Change FEATURE-DUMP to FEATURE-DUMP.libbpf for lib bpf
Em Thu, Nov 05, 2015 at 02:56:34PM +0800, Yunlong Song escreveu:
> Commit ed63f34c026e9a60d17fa750ecdfe3f600d49393 ("perf tools: Make perf
> depend on libbpf") dynamically creates FEATURE-DUMP.libbpf during the
> perf building, but the .gitignore under tools/lib/bpf/ mistakes
> FEATURE-DUMP.libbpf for FEATURE-DUMP. Besides, the Makefile under
> tools/lib/bpf/ also mistakes FEATURE-DUMP.libbpf for FEATURE-DUMP, which
> causes that "make clean" will leave (or say create) FEATURE-DUMP.libbpf
> rather than remove FEATURE-DUMP.libbpf file.
Ok, so the cset that created files with a .libbpf suffix was this one:
commit 65f041bee783
Author: Arnaldo Carvalho de Melo
Date: Mon Sep 21 17:25:27 2015 -0300
tools lib bpf: Use FEATURE_USER to allow building in the same dir as perf
---
That has this tag:
Fixes: 1b76c13e4b36 ("bpf tools: Introduce 'bpf' library and add bpf
feature check")
---
The cset you mention, ed63f34c026e9a60d17fa750ecdfe3f600d49393, just
makes perf call the code introduced by 1b76c13e4b36 and fixed by
65f041bee783, i.e. you start noticing, when building perf, that those
files are created.
Anyway, fixing it up, thanks for the patch!
- Arnaldo
> Signed-off-by: Yunlong Song
> ---
> tools/lib/bpf/.gitignore | 2 +-
> tools/lib/bpf/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/lib/bpf/.gitignore b/tools/lib/bpf/.gitignore
> index 812aeed..f81e549 100644
> --- a/tools/lib/bpf/.gitignore
> +++ b/tools/lib/bpf/.gitignore
> @@ -1,2 +1,2 @@
> libbpf_version.h
> -FEATURE-DUMP
> +FEATURE-DUMP.libbpf
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index fc9af57..a3caaf3 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -180,7 +180,7 @@ config-clean:
> clean:
> $(call QUIET_CLEAN, libbpf) $(RM) *.o *~ $(TARGETS) *.a *.so
> $(VERSION_FILES) .*.d \
> $(RM) LIBBPF-CFLAGS
> - $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP
> + $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
>
>
>
> --
> 1.8.5.2
--
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/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success
It is possible that find_perf_probe_point_from_map() fails to find symbol but still returns 0 because of an small error when coding: find_perf_probe_point_from_map() set 'ret' to error code at first, but also use it to hold return value of kernel_get_symbol_address_by_name(). This patch resets 'ret' to error even kernel_get_symbol_address_by_name() success, so if !sym, the whole function returns error correctly. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim --- tools/perf/util/probe-event.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c index b51a8bf..e659c4f 100644 --- a/tools/perf/util/probe-event.c +++ b/tools/perf/util/probe-event.c @@ -1905,6 +1905,9 @@ static int find_perf_probe_point_from_map(struct probe_trace_point *tp, sym = __find_kernel_function(addr, ); } } + + /* ret may has be overwritten so reset it */ + ret = -ENOENT; if (!sym) goto out; -- 1.8.3.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/2] perf probe: Only call probe_file__get_events() when fd is valid
In system with kprobe enabled but uprobe turned off, 'perf probe -d'
causes segfault because it calls probe_file__get_events() with a
negative fd (when deleting uprobe events).
This patch validates fds before calling probe_file__get_events().
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
---
tools/perf/builtin-probe.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 132afc9..861aa89 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -384,7 +384,11 @@ static int perf_del_probe_events(struct strfilter *filter)
goto out;
}
- ret = probe_file__get_events(kfd, filter, klist);
+ if (kfd < 0)
+ ret = -ENOENT;
+ else
+ ret = probe_file__get_events(kfd, filter, klist);
+
if (ret == 0) {
strlist__for_each(ent, klist)
pr_info("Removed event: %s\n", ent->s);
@@ -394,7 +398,11 @@ static int perf_del_probe_events(struct strfilter *filter)
goto error;
}
- ret2 = probe_file__get_events(ufd, filter, ulist);
+ if (ufd < 0)
+ ret2 = -ENOENT;
+ else
+ ret2 = probe_file__get_events(ufd, filter, ulist);
+
if (ret2 == 0) {
strlist__for_each(ent, ulist)
pr_info("Removed event: %s\n", ent->s);
--
1.8.3.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 0/2] perf tools: Two bugfixs related to perf probe
I found two bugs in perf probe related code. This two patches fix them. Wang Nan (2): perf probe: Only call probe_file__get_events() when fd is valid perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success tools/perf/builtin-probe.c| 12 ++-- tools/perf/util/probe-event.c | 3 +++ 2 files changed, 13 insertions(+), 2 deletions(-) -- 1.8.3.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 v4 4/5] net: stmmac: Fix simple style problem
This patch fix the following warnings:
- braces {} should be used on all arms of this statement
- Prefer seq_puts to seq_printf
- No space is necessary after a cast
- Missing a blank line after declarations
- Please don't use multiple blank lines
- Comparison to NULL could be written
- networking block comments don't use an empty /* line
- Do not include the paragraph about writing to the Free Software
Signed-off-by: LABBE Corentin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 71 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 18 +++---
2 files changed, 40 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f096416..d8adbdb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -13,10 +13,6 @@
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
- You should have received a copy of the GNU General Public License along with
- this program; if not, write to the Free Software Foundation, Inc.,
- 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
-
The full GNU General Public License is included in this distribution in
the file called "COPYING".
@@ -197,7 +193,7 @@ static void print_pkt(unsigned char *buf, int len)
}
/* minimum number of free TX descriptors required to wake up TX process */
-#define STMMAC_TX_THRESH(x)(x->dma_tx_size/4)
+#define STMMAC_TX_THRESH(x)(x->dma_tx_size / 4)
static inline u32 stmmac_tx_avail(struct stmmac_priv *priv)
{
@@ -207,7 +203,7 @@ static inline u32 stmmac_tx_avail(struct stmmac_priv *priv)
/**
* stmmac_hw_fix_mac_speed - callback for speed selection
* @priv: driver private structure
- * Description: on some platforms (e.g. ST), some HW system configuraton
+ * Description: on some platforms (e.g. ST), some HW system configuration
* registers have to be set according to the link speed negotiated.
*/
static inline void stmmac_hw_fix_mac_speed(struct stmmac_priv *priv)
@@ -371,8 +367,6 @@ static void stmmac_get_tx_hwtstamp(struct stmmac_priv *priv,
shhwtstamp.hwtstamp = ns_to_ktime(ns);
/* pass tstamp to stack */
skb_tstamp_tx(skb, );
-
- return;
}
/* stmmac_get_rx_hwtstamp - get HW RX timestamps
@@ -615,7 +609,7 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
* 2^x * y == (y << x), hence
* 2^32 * 5000 ==> (5000 << 32)
*/
- temp = (u64) (5000ULL << 32);
+ temp = (u64)(5000ULL << 32);
priv->default_addend = div_u64(temp, priv->clk_ptp_rate);
priv->hw->ptp->config_addend(priv->ioaddr,
priv->default_addend);
@@ -695,7 +689,7 @@ static void stmmac_adjust_link(struct net_device *dev)
int new_state = 0;
unsigned int fc = priv->flow_ctrl, pause_time = priv->pause;
- if (phydev == NULL)
+ if (!phydev)
return;
spin_lock_irqsave(>lock, flags);
@@ -704,7 +698,8 @@ static void stmmac_adjust_link(struct net_device *dev)
u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
/* Now we make sure that we can be in full duplex mode.
-* If not, we operate in half-duplex mode. */
+* If not, we operate in half-duplex mode.
+*/
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
if (!(phydev->duplex))
@@ -730,11 +725,10 @@ static void stmmac_adjust_link(struct net_device *dev)
case 10:
if (priv->plat->has_gmac) {
ctrl |= priv->hw->link.port;
- if (phydev->speed == SPEED_100) {
+ if (phydev->speed == SPEED_100)
ctrl |= priv->hw->link.speed;
- } else {
+ else
ctrl &= ~(priv->hw->link.speed);
- }
} else {
ctrl &= ~priv->hw->link.port;
}
@@ -816,6 +810,7 @@ static int stmmac_init_phy(struct net_device *dev)
char bus_id[MII_BUS_ID_SIZE];
int interface = priv->plat->interface;
int max_speed = priv->plat->max_speed;
+
priv->oldlink = 0;
priv->speed = 0;
priv->oldduplex = -1;
@@ -854,8 +849,7 @@ static int stmmac_init_phy(struct net_device *dev)
phydev->advertising &= ~(SUPPORTED_1000baseT_Half |
[PATCH v4 3/5] net: stmmac: remove some __func__ printing
Now that stmmac use netdev_xxx, some __func__ are not necessary since their
use was to clearly identify which driver was logging.
Moreover, as pointed by Joe Perches, using __func__ in xxx_dbg functions
is relatively low value and dynamic debug can add it.
This patch remove __func__ where such printing is useless.
Signed-off-by: LABBE Corentin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 81 ++-
1 file changed, 34 insertions(+), 47 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 911cf28..f096416 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -448,8 +448,8 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
sizeof(struct hwtstamp_config)))
return -EFAULT;
- netdev_dbg(priv->dev, "%s config flags:0x%x, tx_type:0x%x,
rx_filter:0x%x\n",
- __func__, config.flags, config.tx_type, config.rx_filter);
+ netdev_dbg(priv->dev, "config flags:0x%x, tx_type:0x%x,
rx_filter:0x%x\n",
+ config.flags, config.tx_type, config.rx_filter);
/* reserved for future extensions */
if (config.flags)
@@ -833,8 +833,7 @@ static int stmmac_init_phy(struct net_device *dev)
snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
priv->plat->phy_addr);
- netdev_dbg(priv->dev, "%s: trying to attach to %s\n", __func__,
- phy_id_fmt);
+ netdev_dbg(priv->dev, "trying to attach to %s\n", phy_id_fmt);
phydev = phy_connect(dev, phy_id_fmt, _adjust_link,
interface);
@@ -991,8 +990,7 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv,
struct dma_desc *p,
skb = __netdev_alloc_skb_ip_align(priv->dev, priv->dma_buf_sz, flags);
if (!skb) {
- netdev_err(priv->dev,
- "%s: Rx init fails; skb is NULL\n", __func__);
+ netdev_err(priv->dev, "Rx init fails; skb is NULL\n");
return -ENOMEM;
}
priv->rx_skbuff[i] = skb;
@@ -1000,7 +998,7 @@ static int stmmac_init_rx_buffers(struct stmmac_priv
*priv, struct dma_desc *p,
priv->dma_buf_sz,
DMA_FROM_DEVICE);
if (dma_mapping_error(priv->device, priv->rx_skbuff_dma[i])) {
- netdev_err(priv->dev, "%s: DMA mapping error\n", __func__);
+ netdev_err(priv->dev, "DMA mapping error\n");
dev_kfree_skb_any(skb);
return -EINVAL;
}
@@ -1050,8 +1048,8 @@ static int init_dma_desc_rings(struct net_device *dev,
gfp_t flags)
priv->dma_buf_sz = bfsize;
if (netif_msg_probe(priv))
- netdev_dbg(priv->dev, "%s: txsize %d, rxsize %d, bfsize %d\n",
- __func__, txsize, rxsize, bfsize);
+ netdev_dbg(priv->dev, "txsize %d, rxsize %d, bfsize %d\n",
+ txsize, rxsize, bfsize);
if (netif_msg_probe(priv)) {
netdev_dbg(priv->dev, "(%s) dma_rx_phy=0x%08x
dma_tx_phy=0x%08x\n",
@@ -1357,8 +1355,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
stmmac_get_tx_hwtstamp(priv, entry, skb);
}
if (netif_msg_tx_done(priv))
- netdev_dbg(priv->dev, "%s: curr %d, dirty %d\n",
- __func__, priv->cur_tx, priv->dirty_tx);
+ netdev_dbg(priv->dev, "curr %d, dirty %d\n",
+ priv->cur_tx, priv->dirty_tx);
if (likely(priv->tx_skbuff_dma[entry].buf)) {
if (priv->tx_skbuff_dma[entry].map_as_page)
@@ -1396,8 +1394,7 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
if (netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv)) {
if (netif_msg_tx_done(priv))
- netdev_dbg(priv->dev, "%s: restart transmit\n",
- __func__);
+ netdev_dbg(priv->dev, "restart transmit\n");
netif_wake_queue(priv->dev);
}
netif_tx_unlock(priv->dev);
@@ -1714,8 +1711,7 @@ static int stmmac_hw_setup(struct net_device *dev, bool
init_ptp)
/* DMA initialization and SW reset */
ret = stmmac_init_dma_engine(priv);
if (ret < 0) {
- netdev_err(priv->dev, "%s: DMA engine initialization failed\n",
- __func__);
+ netdev_err(priv->dev, "DMA engine initialization failed\n");
[PATCH v4 2/5] net: stmmac: replace hardcoded function name by __func__
Some printing have the function name hardcoded. It is better to use __func__ instead. Signed-off-by: LABBE Corentin --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 633a47d..911cf28 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -833,7 +833,7 @@ static int stmmac_init_phy(struct net_device *dev) snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id, priv->plat->phy_addr); - netdev_dbg(priv->dev, "stmmac_init_phy: trying to attach to %s\n", + netdev_dbg(priv->dev, "%s: trying to attach to %s\n", __func__, phy_id_fmt); phydev = phy_connect(dev, phy_id_fmt, _adjust_link, @@ -866,8 +866,8 @@ static int stmmac_init_phy(struct net_device *dev) phy_disconnect(phydev); return -ENODEV; } - netdev_dbg(priv->dev, "stmmac_init_phy: attached to PHY (UID 0x%x) Link = %d\n", - phydev->phy_id, phydev->link); + netdev_dbg(priv->dev, "%s: attached to PHY (UID 0x%x) Link = %d\n", + __func__, phydev->phy_id, phydev->link); priv->phydev = phydev; -- 2.4.10 -- 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 v4 5/5] net: stmmac: replace if (netif_msg_type) by their netif_xxx counterpart
As sugested by Joe Perches, we could replace all
if (netif_msg_type(priv)) dev_xxx(priv->devices, ...)
by the simplier macro netif_xxx(priv, hw, priv->dev, ...)
Signed-off-by: LABBE Corentin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 58 ++-
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d8adbdb..2a1aa73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -652,11 +652,13 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
if (priv->dma_cap.atime_stamp && priv->extend_desc)
priv->adv_ts = 1;
- if (netif_msg_hw(priv) && priv->dma_cap.time_stamp)
- netdev_dbg(priv->dev, "IEEE 1588-2002 Time Stamp supported\n");
+ if (priv->dma_cap.time_stamp)
+ netif_dbg(priv, hw, priv->dev,
+ "IEEE 1588-2002 Time Stamp supported\n");
- if (netif_msg_hw(priv) && priv->adv_ts)
- netdev_dbg(priv->dev, "IEEE 1588-2008 Advanced Time Stamp
supported\n");
+ if (priv->adv_ts)
+ netif_dbg(priv, hw, priv->dev,
+ "IEEE 1588-2008 Advanced Time Stamp supported\n");
priv->hw->ptp = _ptp;
priv->hwts_tx_en = 0;
@@ -735,10 +737,9 @@ static void stmmac_adjust_link(struct net_device *dev)
stmmac_hw_fix_mac_speed(priv);
break;
default:
- if (netif_msg_link(priv))
- netdev_warn(priv->dev,
- "Speed (%d) not 10/100\n",
- phydev->speed);
+ netif_warn(priv, link, priv->dev,
+ "Speed (%d) not 10/100\n",
+ phydev->speed);
break;
}
@@ -1041,18 +1042,15 @@ static int init_dma_desc_rings(struct net_device *dev,
gfp_t flags)
priv->dma_buf_sz = bfsize;
- if (netif_msg_probe(priv))
- netdev_dbg(priv->dev, "txsize %d, rxsize %d, bfsize %d\n",
- txsize, rxsize, bfsize);
+ netif_dbg(priv, probe, priv->dev, "txsize %d, rxsize %d, bfsize %d\n",
+ txsize, rxsize, bfsize);
- if (netif_msg_probe(priv)) {
- netdev_dbg(priv->dev, "(%s) dma_rx_phy=0x%08x
dma_tx_phy=0x%08x\n",
- __func__, (u32)priv->dma_rx_phy,
- (u32)priv->dma_tx_phy);
+ netif_dbg(priv, probe, priv->dev, "(%s) dma_rx_phy=0x%08x
dma_tx_phy=0x%08x\n",
+ __func__, (u32)priv->dma_rx_phy, (u32)priv->dma_tx_phy);
+
+ /* RX INITIALIZATION */
+ netif_dbg(priv, probe, priv->dev, "SKB addresses:\nskb\t\tskb data\tdma
data\n");
- /* RX INITIALIZATION */
- netdev_dbg(priv->dev, "SKB addresses:\nskb\t\tskb data\tdma
data\n");
- }
for (i = 0; i < rxsize; i++) {
struct dma_desc *p;
@@ -1065,11 +1063,9 @@ static int init_dma_desc_rings(struct net_device *dev,
gfp_t flags)
if (ret)
goto err_init_rx_buffers;
- if (netif_msg_probe(priv))
- netdev_dbg(priv->dev, "[%p]\t[%p]\t[%x]\n",
- priv->rx_skbuff[i],
-priv->rx_skbuff[i]->data,
-(unsigned int)priv->rx_skbuff_dma[i]);
+ netif_dbg(priv, probe, priv->dev, "[%p]\t[%p]\t[%x]\n",
+ priv->rx_skbuff[i], priv->rx_skbuff[i]->data,
+ (unsigned int)priv->rx_skbuff_dma[i]);
}
priv->cur_rx = 0;
priv->dirty_rx = (unsigned int)(i - rxsize);
@@ -1349,9 +1345,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
stmmac_get_tx_hwtstamp(priv, entry, skb);
}
- if (netif_msg_tx_done(priv))
- netdev_dbg(priv->dev, "curr %d, dirty %d\n",
- priv->cur_tx, priv->dirty_tx);
+ netif_dbg(priv, tx_done, priv->dev, "curr %d, dirty %d\n",
+ priv->cur_tx, priv->dirty_tx);
if (likely(priv->tx_skbuff_dma[entry].buf)) {
if (priv->tx_skbuff_dma[entry].map_as_page)
@@ -1388,8 +1383,7 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
netif_tx_lock(priv->dev);
if (netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv)) {
- if (netif_msg_tx_done(priv))
-
[PATCH v4] stmmac: improve logging
Hello This patch series try to improve logging of the stmmac driver. Changes since v3 - Fix a missing comma for letting patch to be used atomaticly. Changes since v2 - Rollback to dev_ for some early init printing - rebased on 4.4-rc1 Changes since v1 - Use netdev_xxx instead of dev_xxx - Use netif_xxx instead of "if (netif_msg_type) dev_xxx" Regards -- 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 v4 1/5] net: stmmac: replace all pr_xxx by their netdev_xxx counterpart
The stmmac driver use lots of pr_xxx functions to print information.
This is bad since we cannot know which device logs the information.
(moreover if two stmmac device are present)
Furthermore, it seems that it assumes wrongly that all logs will always
be subsequent by using a dev_xxx then some indented pr_xxx like this:
kernel: sun7i-dwmac 1c5.ethernet: no reset control found
kernel: Ring mode enabled
kernel: No HW DMA feature register supported
kernel: Normal descriptors
kernel: TX Checksum insertion supported
So this patch replace all pr_xxx by their netdev_xxx counterpart.
Excepts for some printing where netdev "cause" unpretty output like:
sun7i-dwmac 1c5.ethernet (unnamed net_device) (uninitialized): no reset
control found
In those case, I keep dev_xxx.
In the same time I remove some "stmmac:" print since
this will be a duplicate with that dev_xxx displays.
And this patch also change some pr_info by netdev_err when
the word ERROR is printed.
Signed-off-by: LABBE Corentin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 210 --
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 14 +-
2 files changed, 123 insertions(+), 101 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 64d8aa4..633a47d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -298,7 +298,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
*/
spin_lock_irqsave(>lock, flags);
if (priv->eee_active) {
- pr_debug("stmmac: disable EEE\n");
+ netdev_dbg(priv->dev, "disable EEE\n");
del_timer_sync(>eee_ctrl_timer);
priv->hw->mac->set_eee_timer(priv->hw, 0,
tx_lpi_timer);
@@ -327,7 +327,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
ret = true;
spin_unlock_irqrestore(>lock, flags);
- pr_debug("stmmac: Energy-Efficient Ethernet initialized\n");
+ netdev_dbg(priv->dev, "Energy-Efficient Ethernet
initialized\n");
}
out:
return ret;
@@ -448,8 +448,8 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
sizeof(struct hwtstamp_config)))
return -EFAULT;
- pr_debug("%s config flags:0x%x, tx_type:0x%x, rx_filter:0x%x\n",
-__func__, config.flags, config.tx_type, config.rx_filter);
+ netdev_dbg(priv->dev, "%s config flags:0x%x, tx_type:0x%x,
rx_filter:0x%x\n",
+ __func__, config.flags, config.tx_type, config.rx_filter);
/* reserved for future extensions */
if (config.flags)
@@ -659,10 +659,10 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
priv->adv_ts = 1;
if (netif_msg_hw(priv) && priv->dma_cap.time_stamp)
- pr_debug("IEEE 1588-2002 Time Stamp supported\n");
+ netdev_dbg(priv->dev, "IEEE 1588-2002 Time Stamp supported\n");
if (netif_msg_hw(priv) && priv->adv_ts)
- pr_debug("IEEE 1588-2008 Advanced Time Stamp supported\n");
+ netdev_dbg(priv->dev, "IEEE 1588-2008 Advanced Time Stamp
supported\n");
priv->hw->ptp = _ptp;
priv->hwts_tx_en = 0;
@@ -742,8 +742,9 @@ static void stmmac_adjust_link(struct net_device *dev)
break;
default:
if (netif_msg_link(priv))
- pr_warn("%s: Speed (%d) not 10/100\n",
- dev->name, phydev->speed);
+ netdev_warn(priv->dev,
+ "Speed (%d) not 10/100\n",
+ phydev->speed);
break;
}
@@ -790,10 +791,10 @@ static void stmmac_check_pcs_mode(struct stmmac_priv
*priv)
(interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- pr_debug("STMMAC: PCS RGMII support enable\n");
+ netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
priv->pcs = STMMAC_PCS_RGMII;
} else if (interface == PHY_INTERFACE_MODE_SGMII) {
- pr_debug("STMMAC: PCS SGMII support enable\n");
+ netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
priv->pcs = STMMAC_PCS_SGMII;
}
}
@@ -832,15 +833,15 @@ static
Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr
On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote: > Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers > and adds offsetof macro for the same. It extends perf_reg_value() > to use reg idx to decide on struct to return value from. Why; what's in those regs? -- 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] mm: prepare page_referenced() and page_idle to new THP refcounting
On Thu, Nov 05, 2015 at 03:53:54PM +0300, Vladimir Davydov wrote:
> On Thu, Nov 05, 2015 at 02:36:06PM +0200, Kirill A. Shutemov wrote:
> > On Thu, Nov 05, 2015 at 03:07:26PM +0300, Vladimir Davydov wrote:
> > > @@ -849,30 +836,23 @@ static int page_referenced_one(struct page *page,
> > > struct vm_area_struct *vma,
> > > if (pmd_page(*pmd) != page)
> > > goto unlock_pmd;
> > >
> > > - if (vma->vm_flags & VM_LOCKED) {
> > > - pra->vm_flags |= VM_LOCKED;
> > > - ret = SWAP_FAIL; /* To break the loop */
> > > - goto unlock_pmd;
> > > - }
> > > -
> > > - if (pmdp_clear_flush_young_notify(vma, address, pmd))
> > > - referenced++;
> > > - spin_unlock(ptl);
> > > + pte = (pte_t *)pmd;
> >
> > pmd_t and pte_t are not always compatible. We shouldn't pretend they are.
> > And we shouldn't use pte_unmap_unlock() to unlock pmd table.
>
> Out of curiosity, is it OK that __page_check_address can call
> pte_unmap_unlock on pte returned by huge_pte_offset, which isn't really
> pte, but pmd or pud?
hugetlb is usually implemented on architectures where you can expect some
level of compatibility between page table enties on different levels.
> > What about interface like this (I'm not sure about helper's name):
> >
> > void page_check_address_transhuge(struct page *page, struct mm_struct *mm,
> >unsigned long address,
> >pmd_t **pmdp, pte_t **ptep,
> >spinlock_t **ptlp);
> >
> > page_check_address_transhuge(page, mm, address, , , );
> > if (pmd) {
> > /* handle pmd... */
> > } else if (pte) {
> > /* handle pte... */
> > } else {
> > return SWAP_AGAIN;
> > }
> >
> > /* common stuff */
> >
> > if (pmd)
> > spin_unlock(ptl);
> > else
> > pte_unmap_unlock(pte, ptl);
>
> spin_unlock(ptl);
> if (pte)
> pte_unmap(pte);
>
> would look neater IMO. Other than that, I think it's OK. At least, it
> looks better and less error-prone than duplicating such a huge chunk of
> code IMO.
Okay. Could you prepare the patch?
--
Kirill A. Shutemov
--
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: lustre: Delete an unnecessary variable initialisation in class_register_type()
Looks good. regards, dan carpenter -- 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: lustre: Delete unnecessary checks before two function calls
I don't like these patches because relying on hidden sanity checks makes the code harder to read. I am CC'd on all these patches because of kernel-janitors and normally I ignore them but this is drivers/staging so I am invested in this code. Feel free to send them to other subsystems though. regards, dan carpenter -- 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] mm: prepare page_referenced() and page_idle to new THP refcounting
On Thu, Nov 05, 2015 at 02:36:06PM +0200, Kirill A. Shutemov wrote:
> On Thu, Nov 05, 2015 at 03:07:26PM +0300, Vladimir Davydov wrote:
> > @@ -849,30 +836,23 @@ static int page_referenced_one(struct page *page,
> > struct vm_area_struct *vma,
> > if (pmd_page(*pmd) != page)
> > goto unlock_pmd;
> >
> > - if (vma->vm_flags & VM_LOCKED) {
> > - pra->vm_flags |= VM_LOCKED;
> > - ret = SWAP_FAIL; /* To break the loop */
> > - goto unlock_pmd;
> > - }
> > -
> > - if (pmdp_clear_flush_young_notify(vma, address, pmd))
> > - referenced++;
> > - spin_unlock(ptl);
> > + pte = (pte_t *)pmd;
>
> pmd_t and pte_t are not always compatible. We shouldn't pretend they are.
> And we shouldn't use pte_unmap_unlock() to unlock pmd table.
Out of curiosity, is it OK that __page_check_address can call
pte_unmap_unlock on pte returned by huge_pte_offset, which isn't really
pte, but pmd or pud?
>
> What about interface like this (I'm not sure about helper's name):
>
> void page_check_address_transhuge(struct page *page, struct mm_struct *mm,
>unsigned long address,
>pmd_t **pmdp, pte_t **ptep,
> spinlock_t **ptlp);
>
> page_check_address_transhuge(page, mm, address, , , );
> if (pmd) {
> /* handle pmd... */
> } else if (pte) {
> /* handle pte... */
> } else {
> return SWAP_AGAIN;
> }
>
> /* common stuff */
>
> if (pmd)
> spin_unlock(ptl);
> else
> pte_unmap_unlock(pte, ptl);
spin_unlock(ptl);
if (pte)
pte_unmap(pte);
would look neater IMO. Other than that, I think it's OK. At least, it
looks better and less error-prone than duplicating such a huge chunk of
code IMO.
Thanks,
Vladimir
>
> /* ... */
>
> The helper shouldn't set pmd if the page is tracked to pte.
--
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: [Bugfix v4] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32-bit kernel
On 02.11.2015 16:27, Tomasz Nowicki wrote:
On 08.07.2015 09:26, Jiang Liu wrote:
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver
loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived
with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because
of this,
either ACPI or the Realtek chip kept the bad state and after
rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final.
3.18.16 was
good."
The regression is caused by commit 593669c2ac0f ("x86/PCI/ACPI: Use
common
ACPI resource interfaces to simplify implementation"). Since commit
593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The
'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when
converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-Tested-by: Boszormenyi Zoltan
Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
interfaces to simplify implementation")
Signed-off-by: Jiang Liu
Cc: sta...@vger.kernel.org # 4.0
---
drivers/acpi/resource.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 10561ce16ed1..e8d281739cbc 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -194,6 +194,7 @@ static bool acpi_decode_space(struct resource_win
*win,
u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 :
ACPI_DECODE_16;
bool wp = addr->info.mem.write_protect;
u64 len = attr->address_length;
+u64 start, end, offset = 0;
struct resource *res = >res;
/*
@@ -205,9 +206,6 @@ static bool acpi_decode_space(struct resource_win
*win,
pr_debug("ACPI: Invalid address space min_addr_fix %d,
max_addr_fix %d, len %llx\n",
addr->min_address_fixed, addr->max_address_fixed, len);
-res->start = attr->minimum;
-res->end = attr->maximum;
-
/*
* For bridges that translate addresses across the bridge,
* translation_offset is the offset that must be added to the
@@ -215,12 +213,22 @@ static bool acpi_decode_space(struct
resource_win *win,
* primary side. Non-bridge devices must list 0 for all Address
* Translation offset bits.
*/
-if (addr->producer_consumer == ACPI_PRODUCER) {
-res->start += attr->translation_offset;
-res->end += attr->translation_offset;
-} else if (attr->translation_offset) {
+if (addr->producer_consumer == ACPI_PRODUCER)
+offset = attr->translation_offset;
+else if (attr->translation_offset)
pr_debug("ACPI: translation_offset(%lld) is invalid for
non-bridge device.\n",
attr->translation_offset);
+start = attr->minimum + offset;
+end = attr->maximum + offset;
I still see the issue for this area, I mean ACPI_IO_RANGE. You are
adding translation offset to attr->minimum, build resource structure
which is then passed to acpi_dev_ioresource_flags and compared against
0x10003. It causes some IO ranges to be ignored.
Kindly reminder, any comments?
Tomasz
--
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/2] ASoC: codec: Inno codec driver for RK3036 SoC
On Thu, Nov 05, 2015 at 05:53:13PM +0800, Shunqian Zheng wrote:
> From: ZhengShunQian
>
> RK3036 SoC integrated with an Inno audio codec.
> This driver implements the functions of it.
>
> There is not need a special machine driver, since the
> simple-card machine driver works perfect in this case.
>
> Signed-off-by: ZhengShunQian
> ---
> sound/soc/codecs/Kconfig | 4 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/inno_rk3036.c | 455
> +
> sound/soc/codecs/inno_rk3036.h | 120 +++
> 4 files changed, 581 insertions(+)
> create mode 100644 sound/soc/codecs/inno_rk3036.c
> create mode 100644 sound/soc/codecs/inno_rk3036.h
>
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index cfdafc4..89d789e 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -67,6 +67,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_ES8328_I2C if I2C
> select SND_SOC_GTM601
> select SND_SOC_ICS43432
> + select SND_SOC_INNO_RK3036
> select SND_SOC_ISABELLE if I2C
> select SND_SOC_JZ4740_CODEC
> select SND_SOC_LM4857 if I2C
> @@ -471,6 +472,9 @@ config SND_SOC_GTM601
> config SND_SOC_ICS43432
> tristate
>
> +config SND_SOC_INNO_RK3036
> + tristate "Inno codec driver for RK3036 SoC"
> +
> config SND_SOC_ISABELLE
> tristate
>
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index f632fc4..2f6bc6c 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -60,6 +60,7 @@ snd-soc-es8328-i2c-objs := es8328-i2c.o
> snd-soc-es8328-spi-objs := es8328-spi.o
> snd-soc-gtm601-objs := gtm601.o
> snd-soc-ics43432-objs := ics43432.o
> +snd-soc-inno-rk3036-objs := inno_rk3036.o
> snd-soc-isabelle-objs := isabelle.o
> snd-soc-jz4740-codec-objs := jz4740.o
> snd-soc-l3-objs := l3.o
> @@ -255,6 +256,7 @@ obj-$(CONFIG_SND_SOC_ES8328_I2C)+= snd-soc-es8328-i2c.o
> obj-$(CONFIG_SND_SOC_ES8328_SPI)+= snd-soc-es8328-spi.o
> obj-$(CONFIG_SND_SOC_GTM601)+= snd-soc-gtm601.o
> obj-$(CONFIG_SND_SOC_ICS43432) += snd-soc-ics43432.o
> +obj-$(CONFIG_SND_SOC_INNO_RK3036)+= snd-soc-inno-rk3036.o
> obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o
> obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o
> obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
> diff --git a/sound/soc/codecs/inno_rk3036.c b/sound/soc/codecs/inno_rk3036.c
> new file mode 100644
> index 000..ce68f02
> --- /dev/null
> +++ b/sound/soc/codecs/inno_rk3036.c
> @@ -0,0 +1,455 @@
> +/*
> + * Driver of Inno codec for rk3036 by Rockchip Inc.
> + *
> + * Author: Rockchip Inc.
> + * Author: Zheng ShunQian
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "inno_rk3036.h"
> +
> +struct rk3036_codec_priv {
> + void __iomem *base;
> + struct clk *pclk;
> + struct regmap *regmap;
> + struct device *dev;
> +};
> +
> +static const DECLARE_TLV_DB_MINMAX(rk3036_codec_hp_tlv, -39, 0);
> +
> +static const char *rk3036_codec_antipop_text[] = {"none", "work"};
> +static const unsigned int rk3036_codec_antipop_values[] = {0x1, 0x2};
> +
> +static SOC_VALUE_ENUM_DOUBLE_DECL(rk3036_codec_antipop_enum, INNO_R09,
> + INNO_R09_HPL_ANITPOP_SHIFT, INNO_R09_HPR_ANITPOP_SHIFT, 0x3,
> + rk3036_codec_antipop_text, rk3036_codec_antipop_values);
> +
> +static const struct snd_kcontrol_new rk3036_codec_dapm_controls[] = {
> + SOC_DOUBLE_R_RANGE_TLV("Headphone Volume", INNO_R07, INNO_R08,
> + INNO_HP_GAIN_SHIFT, INNO_HP_GAIN_N39DB,
> + INNO_HP_GAIN_0DB, 0, rk3036_codec_hp_tlv),
> + SOC_DOUBLE("Zero Cross Detect", INNO_R06, INNO_R06_VOUTL_CZ_SHIFT,
> + INNO_R06_VOUTR_CZ_SHIFT, 1, 0),
> + SOC_DOUBLE("HP Mute", INNO_R09, INNO_R09_HPL_MUTE_SHIFT,
> + INNO_R09_HPR_MUTE_SHIFT, 1, 1),
> + SOC_ENUM("Anti-pop", rk3036_codec_antipop_enum),
> +};
> +
> +static const struct snd_kcontrol_new rk3036_codec_hpl_mixer_controls[] = {
> + SOC_DAPM_SINGLE("DAC Left Out Switch", INNO_R09,
> + INNO_R09_DACL_SWITCH_SHIFT, 1, 0),
> +};
> +
> +static const struct snd_kcontrol_new rk3036_codec_hpr_mixer_controls[] = {
> + SOC_DAPM_SINGLE("DAC Right Out Switch", INNO_R09,
> + INNO_R09_DACR_SWITCH_SHIFT, 1, 0),
> +};
> +
> +static const struct snd_kcontrol_new rk3036_codec_hpl_switch_controls[] = {
> + SOC_DAPM_SINGLE("HP Left Out Switch", INNO_R05,
> + INNO_R05_HPL_WORK_SHIFT, 1, 0),
> +};
> +
> +static const struct snd_kcontrol_new rk3036_codec_hpr_switch_controls[] = {
> + SOC_DAPM_SINGLE("HP Right Out Switch", INNO_R05,
> + INNO_R05_HPR_WORK_SHIFT, 1, 0),
> +};
> +
> +static const struct snd_soc_dapm_widget
[PATCH] kconfig: fix missing symbol error
Add GOLDFISH OLPC config symbols, which is missing. Signed-off-by: yalin wang --- drivers/platform/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 0adccbf..81f4fb3 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -1,3 +1,11 @@ +config GOLDFISH + bool "goldfish generic driver" + default n + +config OLPC + bool "OLPC driver" + default n + if X86 source "drivers/platform/x86/Kconfig" endif -- 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 4/4] mm: prepare page_referenced() and page_idle to new THP refcounting
On Thu, Nov 05, 2015 at 03:07:26PM +0300, Vladimir Davydov wrote:
> @@ -849,30 +836,23 @@ static int page_referenced_one(struct page *page,
> struct vm_area_struct *vma,
> if (pmd_page(*pmd) != page)
> goto unlock_pmd;
>
> - if (vma->vm_flags & VM_LOCKED) {
> - pra->vm_flags |= VM_LOCKED;
> - ret = SWAP_FAIL; /* To break the loop */
> - goto unlock_pmd;
> - }
> -
> - if (pmdp_clear_flush_young_notify(vma, address, pmd))
> - referenced++;
> - spin_unlock(ptl);
> + pte = (pte_t *)pmd;
pmd_t and pte_t are not always compatible. We shouldn't pretend they are.
And we shouldn't use pte_unmap_unlock() to unlock pmd table.
What about interface like this (I'm not sure about helper's name):
void page_check_address_transhuge(struct page *page, struct mm_struct *mm,
unsigned long address,
pmd_t **pmdp, pte_t **ptep,
spinlock_t **ptlp);
page_check_address_transhuge(page, mm, address, , , );
if (pmd) {
/* handle pmd... */
} else if (pte) {
/* handle pte... */
} else {
return SWAP_AGAIN;
}
/* common stuff */
if (pmd)
spin_unlock(ptl);
else
pte_unmap_unlock(pte, ptl);
/* ... */
The helper shouldn't set pmd if the page is tracked to pte.
--
Kirill A. Shutemov
--
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 2/7] spi: sunxi: remove redundant "depends on RESET_CONTROLLER"
2015-11-05 21:20 GMT+09:00 Mark Brown :
> On Thu, Nov 05, 2015 at 09:11:47PM +0900, Masahiro Yamada wrote:
>> 2015-11-05 20:28 GMT+09:00 Mark Brown :
>
>> > The dependency is on ARCH_SUNXI || COMPILE_TEST which is not the same as
>> > ARCH_SUNXI.
>
>> The compile test of this driver should pass even if RESET_CONTROLLER
>> is not defined.
>> So, it does not matter for COMPILE_TEST.
>
> If that is the case then the change here is that the dependency on
> RESET_CONTROLLER is just redundant which isn't what the commit message
> says.
For compile test, right, "depends on RESET_CONTROLLER" is
redundant in the first place.
For run-time on real SoCs,the driver failed at the following point
without the reset-controller sub-system.
sspi->rstc = devm_reset_control_get(>dev, NULL);
if (IS_ERR(sspi->rstc)) {
dev_err(>dev, "Couldn't get reset controller\n");
ret = PTR_ERR(sspi->rstc);
goto err_free_master;
}
--
Best Regards
Masahiro Yamada
--
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/5] spi: introduce mmap read support for spi flash devices
On 11/04/2015 08:09 PM, Mark Brown wrote: > On Tue, Nov 03, 2015 at 03:36:10PM +0530, Vignesh R wrote: > >> +} >> +mutex_lock(>mmap_lock_mutex); >> +ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf, >> +read_opcode, addr_width, >> +dummy_bytes); >> +mutex_unlock(>mmap_lock_mutex); >> +if (master->auto_runtime_pm) >> +pm_runtime_put(master->dev.parent); > > It's a bit worrying that this doesn't sync with the message queue except > via the mutex: this means that we might be out of order with respect to > any asynchronous transfers that are happening on the device. I'm not > sure that this is a practical problem, though there is some risk of > unfair scheduling that would have to be under extreme load and it might > make sense to prioritise reads anyway. > Since mmap interface is used only by mtd flash drivers and since almost all mtd flash devices use synchronous transfers (spi_sync()), IMO, there wont be out of order problem wrt mtd flashes. But mmap read might delay transfers queued for non mtd flash devices. It is difficult to wait for all transfers already queued to be pumped out by __spi_pump_messages() and then do the mmap transfer. Do you have any thoughts on how to sync with message queue? -- Regards Vignesh -- 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/5] stmmac: replace all pr_xxx by their netdev_xxx counterpart
On Thu, Nov 05, 2015 at 06:58:17PM +0800, kbuild test robot wrote:
> Hi LABBE,
>
> [auto build test ERROR on: net/master]
> [also build test ERROR on: v4.3 next-20151105]
>
> url:
> https://github.com/0day-ci/linux/commits/LABBE-Corentin/stmmac-replace-all-pr_xxx-by-their-netdev_xxx-counterpart/20151105-163344
> config: m68k-allyesconfig (attached as .config)
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m68k
>
> Note: the
> linux-review/LABBE-Corentin/stmmac-replace-all-pr_xxx-by-their-netdev_xxx-counterpart/20151105-163344
> HEAD 6d5b68276276235c73d865a816807f6073f341e9 builds fine.
> It only hurts bisectibility.
>
> All error/warnings (new ones prefixed by >>):
>
>drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
> 'stmmac_open':
> >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1822:7: error: expected
> >> ')' before '__func__'
> __func__);
> ^
> >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1822:7: warning: format
> >> '%s' expects a matching 'char *' argument [-Wformat=]
>
> vim +1822 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
> 1816priv->dma_rx_size = STMMAC_ALIGN(dma_rxsize);
> 1817priv->dma_buf_sz = STMMAC_ALIGN(buf_sz);
> 1818
> 1819ret = alloc_dma_desc_resources(priv);
> 1820if (ret < 0) {
> 1821netdev_err(priv->dev, "%s: DMA descriptors
> allocation failed\n"
> > 1822 __func__);
> 1823goto dma_desc_error;
> 1824}
> 1825
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
This part is removed by subsequent patch.
I will send a fixed version.
Regards
--
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 RFC 0/7] Adding core support for wire-MSI bridges
On Thu, 5 Nov 2015, Marc Zyngier wrote: > On 04/11/15 13:34, Thomas Gleixner wrote: > > Marc, > > > > On Fri, 16 Oct 2015, Marc Zyngier wrote: > >> On 16/10/15 02:55, Jiang Liu wrote: > >>> There's a working to enable Intel VMD storage device, which > >>> has the similar requirement. Basically a PCIe hierarchy is hidden > >>> behind a parent PCIe device, so we need to use the PCIe irqs on parent > >>> to de-multiple PCIe IRQs from hidden PCIe devices. Seems a chance for > >>> consolidation here. > >> > >> Do you know if there is a 1-1 mapping between the interrupts seen by the > >> parent device and those seen by the hidden devices? Or is it a case of > >> having to demultiplex the MSIs? Looks like the former, but I'd like to > >> be sure. > > > > Yes, it's a demultiplexer. No 1:1 mapping. > > Right. This doesn't exactly fit the scheme I have so far (there is a 1:1 > mapping between the wired interrupt and the MSI), but once we are able > to expose an MSI domain, it could be possible to construct the MSI > demultiplexer on top. That's a lot of layers! ;-) Well for the demux case it doesn't make a lot of sense. It's not easy to describe in a hierarchy. Having that parentless MSI domain for that VMD case is simple enough. 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/
Re: [PATCH RFC 0/7] Adding core support for wire-MSI bridges
On 04/11/15 13:34, Thomas Gleixner wrote: > Marc, > > On Fri, 16 Oct 2015, Marc Zyngier wrote: >> On 16/10/15 02:55, Jiang Liu wrote: >>> There's a working to enable Intel VMD storage device, which >>> has the similar requirement. Basically a PCIe hierarchy is hidden >>> behind a parent PCIe device, so we need to use the PCIe irqs on parent >>> to de-multiple PCIe IRQs from hidden PCIe devices. Seems a chance for >>> consolidation here. >> >> Do you know if there is a 1-1 mapping between the interrupts seen by the >> parent device and those seen by the hidden devices? Or is it a case of >> having to demultiplex the MSIs? Looks like the former, but I'd like to >> be sure. > > Yes, it's a demultiplexer. No 1:1 mapping. Right. This doesn't exactly fit the scheme I have so far (there is a 1:1 mapping between the wired interrupt and the MSI), but once we are able to expose an MSI domain, it could be possible to construct the MSI demultiplexer on top. That's a lot of layers! ;-) >> Sure, will do when I repost this (probably in a few weeks), and assuming >> this fits the bill for Thomas and the MBIGEN folks. > > It doesn't look that bad and the resulting mbigen stuff is way less > horrible than it was before. So I agree this is a possible solution to > the problem. Cool. I'll revisit that after the merge window. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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 2/7] spi: sunxi: remove redundant "depends on RESET_CONTROLLER"
On Thu, Nov 05, 2015 at 09:11:47PM +0900, Masahiro Yamada wrote: > 2015-11-05 20:28 GMT+09:00 Mark Brown : > > The dependency is on ARCH_SUNXI || COMPILE_TEST which is not the same as > > ARCH_SUNXI. > The compile test of this driver should pass even if RESET_CONTROLLER > is not defined. > So, it does not matter for COMPILE_TEST. If that is the case then the change here is that the dependency on RESET_CONTROLLER is just redundant which isn't what the commit message says. signature.asc Description: PGP signature
[PATCH 3/3] staging: lustre: Less function calls in class_register_type() after error detection
From: Markus Elfring
Date: Thu, 5 Nov 2015 12:48:58 +0100
The functions "kfree" and "kobject_put" were called in a few cases by the
function "class_register_type" during error handling even if the passed
variable contained a null pointer.
This implementation detail could be improved by the adjustment of
jump targets.
Signed-off-by: Markus Elfring
---
drivers/staging/lustre/lustre/obdclass/genops.c | 26 +++--
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c
b/drivers/staging/lustre/lustre/obdclass/genops.c
index acb86f0..4d99a39 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -171,13 +171,16 @@ int class_register_type(struct obd_ops *dt_ops, struct
md_ops *md_ops,
return rc;
type->typ_dt_ops = kzalloc(sizeof(*type->typ_dt_ops), GFP_NOFS);
+ if (!type->typ_dt_ops)
+ goto free_type;
+
type->typ_md_ops = kzalloc(sizeof(*type->typ_md_ops), GFP_NOFS);
- type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS);
+ if (!type->typ_md_ops)
+ goto free_dt_ops;
- if (!type->typ_dt_ops ||
- !type->typ_md_ops ||
- !type->typ_name)
- goto failed;
+ type->typ_name = kzalloc(strlen(name) + 1, GFP_NOFS);
+ if (!type->typ_name)
+ goto free_md_ops;
*(type->typ_dt_ops) = *dt_ops;
/* md_ops is optional */
@@ -193,20 +196,20 @@ int class_register_type(struct obd_ops *dt_ops, struct
md_ops *md_ops,
rc = type->typ_debugfs_entry ? PTR_ERR(type->typ_debugfs_entry)
: -ENOMEM;
type->typ_debugfs_entry = NULL;
- goto failed;
+ goto free_name;
}
type->typ_kobj = kobject_create_and_add(type->typ_name, lustre_kobj);
if (!type->typ_kobj) {
rc = -ENOMEM;
- goto failed;
+ goto free_name;
}
if (ldt != NULL) {
type->typ_lu = ldt;
rc = lu_device_type_init(ldt);
if (rc != 0)
- goto failed;
+ goto put_object;
}
spin_lock(_types_lock);
@@ -214,12 +217,15 @@ int class_register_type(struct obd_ops *dt_ops, struct
md_ops *md_ops,
spin_unlock(_types_lock);
return 0;
-
- failed:
+put_object:
kobject_put(type->typ_kobj);
+free_name:
kfree(type->typ_name);
+free_md_ops:
kfree(type->typ_md_ops);
+free_dt_ops:
kfree(type->typ_dt_ops);
+free_type:
kfree(type);
return rc;
}
--
2.6.2
--
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: lustre: Delete an unnecessary variable initialisation in class_register_type()
From: Markus Elfring
Date: Thu, 5 Nov 2015 10:55:16 +0100
The variable "rc" will be eventually set to an error return code in the
class_register_type() function.
Thus let us omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/staging/lustre/lustre/obdclass/genops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c
b/drivers/staging/lustre/lustre/obdclass/genops.c
index a1cf8e1..acb86f0 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -155,7 +155,7 @@ int class_register_type(struct obd_ops *dt_ops, struct
md_ops *md_ops,
struct lu_device_type *ldt)
{
struct obd_type *type;
- int rc = 0;
+ int rc;
/* sanity check */
LASSERT(strnlen(name, CLASS_MAX_NAME) < CLASS_MAX_NAME);
--
2.6.2
--
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] arm64: Increase the max granular size
On Thu, Nov 05, 2015 at 08:45:08PM +0900, Joonsoo Kim wrote: > 2015-11-05 19:32 GMT+09:00 Catalin Marinas : > > On ARM we have a notion of cache writeback granule (CWG) which tells us > > "the maximum size of memory that can be overwritten as a result of the > > eviction of a cache entry that has had a memory location in it > > modified". What we actually needed was ARCH_DMA_MINALIGN to be 128 > > (currently defined to the L1_CACHE_BYTES value). However, this wouldn't > > have fixed the KMALLOC_MIN_SIZE, unless we somehow generate different > > kmalloc_caches[] and kmalloc_dma_caches[] and probably introduce a > > size_dma_index[]. > > If we create separate kmalloc caches for dma, can we apply this alignment > requirement only to dma caches? I guess some memory allocation request > that will be used for DMA operation doesn't specify GFP_DMA because > it doesn't want the memory from ZONE_DMA. In this case, we should apply > dma alignment requirement to all types of caches. I think you are right. While something like swiotlb (through the streaming DMA API) could do bounce buffering and allocate one from ZONE_DMA, this is not guaranteed if the buffer physical address happens to match the dma_mask. Similarly with an IOMMU, no bouncing happens but the alignment is still required. > If it isn't possible, is there another way to reduce memory waste due to > increase of dma alignment requirement in arm64? I first need to see how significant the impact is (especially for embedded/mobiles platforms). An alternative is to leave L1_CACHE_BYTES to 64 by default but warn if the CWG is 128 on systems with non-coherent DMA (and hope that we won't have any). It's not really fix, rather an assumption. Anyway I would very much like the same kernel image for all platforms and no Kconfig entry for the cache line size but if the waste is significant, we may add one for some specific builds (like a mobile phone; or such vendors could patch the kernel themselves). -- Catalin -- 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: lustre: Delete unnecessary checks before two function calls
From: Markus Elfring
Date: Thu, 5 Nov 2015 10:18:45 +0100
The functions kobject_put() and kset_unregister() test whether their
argument is NULL and then return immediately.
Thus the tests around their calls are not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 10 +++---
drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 ++---
drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +---
drivers/staging/lustre/lustre/obdclass/genops.c | 6 ++
4 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
index ca11511..e67e84b 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
@@ -1062,13 +1062,9 @@ static int ldlm_cleanup(void)
if (ldlm_state->ldlm_cb_service != NULL)
ptlrpc_unregister_service(ldlm_state->ldlm_cb_service);
- if (ldlm_ns_kset)
- kset_unregister(ldlm_ns_kset);
- if (ldlm_svc_kset)
- kset_unregister(ldlm_svc_kset);
- if (ldlm_kobj)
- kobject_put(ldlm_kobj);
-
+ kset_unregister(ldlm_ns_kset);
+ kset_unregister(ldlm_svc_kset);
+ kobject_put(ldlm_kobj);
ldlm_debugfs_cleanup();
kfree(ldlm_state);
diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 635a93c..c3c8e8c 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -240,7 +240,7 @@ static int lmv_connect(const struct lu_env *env,
if (data->ocd_connect_flags & OBD_CONNECT_REAL)
rc = lmv_check_connect(obd);
- if (rc && lmv->lmv_tgts_kobj)
+ if (rc)
kobject_put(lmv->lmv_tgts_kobj);
return rc;
@@ -646,8 +646,7 @@ static int lmv_disconnect(struct obd_export *exp)
lmv_disconnect_mdc(obd, lmv->tgts[i]);
}
- if (lmv->lmv_tgts_kobj)
- kobject_put(lmv->lmv_tgts_kobj);
+ kobject_put(lmv->lmv_tgts_kobj);
out_local:
/*
diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c
b/drivers/staging/lustre/lustre/lov/lov_obd.c
index 7abe484..910c62c 100644
--- a/drivers/staging/lustre/lustre/lov/lov_obd.c
+++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
@@ -109,9 +109,7 @@ static void lov_putref(struct obd_device *obd)
__lov_del_obd(obd, tgt);
}
- if (lov->lov_tgts_kobj)
- kobject_put(lov->lov_tgts_kobj);
-
+ kobject_put(lov->lov_tgts_kobj);
} else {
mutex_unlock(>lov_lock);
}
diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c
b/drivers/staging/lustre/lustre/obdclass/genops.c
index 6477aeb..a1cf8e1 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -216,8 +216,7 @@ int class_register_type(struct obd_ops *dt_ops, struct
md_ops *md_ops,
return 0;
failed:
- if (type->typ_kobj)
- kobject_put(type->typ_kobj);
+ kobject_put(type->typ_kobj);
kfree(type->typ_name);
kfree(type->typ_md_ops);
kfree(type->typ_dt_ops);
@@ -244,8 +243,7 @@ int class_unregister_type(const char *name)
return -EBUSY;
}
- if (type->typ_kobj)
- kobject_put(type->typ_kobj);
+ kobject_put(type->typ_kobj);
if (!IS_ERR_OR_NULL(type->typ_debugfs_entry))
ldebugfs_remove(>typ_debugfs_entry);
--
2.6.2
--
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: NETIF_F_GSO_SOFTWARE vs NETIF_F_GSO
On Wed, Nov 04, 2015 at 12:24:47PM +0100, Jason A. Donenfeld wrote: > > Strangely, the performance does not change at all regardless of > whether or not NETIF_F_GSO is specified. The NETIF_F_GSO flag turns on software GSO which should be on anyway. So that could be why it seems to make no difference. > However, the performance becomes incredible when I use > NETIF_F_GSO_SOFTWARE instead of NETIF_F_GSO. But, when using NETIF_F_GSO_SOFTWARE is actually a collection of bits that lists the protocols for which we support software GSO. The bits themselves are in fact an indication that the hardware supports GSO directly. So by turning them on you're electing to receive GSO packets directly. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/6] dmaengine: tegra-apb: Correct runtime-pm usage
On Thu, Nov 05, 2015 at 03:15:18AM +0100, Rafael J. Wysocki wrote: > > > + Rafael > > > > > > This is contrariry to what I see, If my driver is runtime suspended and on > > > suspend, it gets runtime resumed and then suspended > > > > Since I was late to the thread, can you explain what kind of driver and > > on what bus type you're seeing this behavior? > > > > It could be that your bus-type is doing something, but I don't think it > > should be the PM core. > > Right. > > Bus types do that, the core doesn't. The ACPI PM domain does that too > for some devices. > > So Vinod, more details, please. Okay relooking at core I do think that runtime resume should not be invoked while suspending, as core seems to call pm_runtime_get_noresume() but I am still missing something here.. I do see this behaviour (runtime resume on suspend) on Intel audio drivers which are PCI devices, is PCI or ACPI doing some magic here. I have seen this as consistent behavior and actually an irritant, as we used to download firmware in resume patch, but then we end up thrashing the controller while going to suspend! -- ~Vinod -- 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 2/7] spi: sunxi: remove redundant "depends on RESET_CONTROLLER"
2015-11-05 20:28 GMT+09:00 Mark Brown : > On Thu, Nov 05, 2015 at 08:15:23PM +0900, Masahiro Yamada wrote: >> ARCH_SUNXI selects RESET_CONTROLLER. >> The dependency "depends on RESET_CONTROLLER" is already met. > > No, it isn't. > >> config SPI_SUN6I >> tristate "Allwinner A31 SPI controller" >> depends on ARCH_SUNXI || COMPILE_TEST >> - depends on RESET_CONTROLLER > > The dependency is on ARCH_SUNXI || COMPILE_TEST which is not the same as > ARCH_SUNXI. The compile test of this driver should pass even if RESET_CONTROLLER is not defined. So, it does not matter for COMPILE_TEST. -- Best Regards Masahiro Yamada -- 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: dts: zynq: describe SLCR as simple-mfd rather than simple-bus
On 11/05/2015 09:46 AM, Masahiro Yamada wrote:
> The SLCR (System-Level Control Registers) block is an MFD (Multi
> Function Device) rather than a bus.
>
> "simple-mfd" seems a more suitable compatible string than "simple-bus".
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/arm/boot/dts/zynq-7000.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
> b/arch/arm/boot/dts/zynq-7000.dtsi
> index 1a5220e..64ddd4d 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -238,7 +238,7 @@
> slcr: slcr@f800 {
> #address-cells = <1>;
> #size-cells = <1>;
> - compatible = "xlnx,zynq-slcr", "syscon", "simple-bus";
> + compatible = "xlnx,zynq-slcr", "syscon", "simple-mfd";
> reg = <0xF800 0x1000>;
> ranges;
> clkc: clkc@100 {
>
Applied.
Thanks,
Michal
--
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] staging: lustre: Deletion of some unnecessary checks
From: Markus Elfring Date: Thu, 5 Nov 2015 13:03:33 +0100 Further update suggestions were taken into account after a patch was applied from static source code analysis. Markus Elfring (3): Delete unnecessary checks before two function calls Delete an unnecessary variable initialisation in class_register_type() Less function calls in class_register_type() after error detection drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 10 +++- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 5 ++-- drivers/staging/lustre/lustre/lov/lov_obd.c | 4 +-- drivers/staging/lustre/lustre/obdclass/genops.c | 34 ++--- 4 files changed, 25 insertions(+), 28 deletions(-) -- 2.6.2 -- 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] mm: prepare page_referenced() and page_idle to new THP refcounting
On Thu, Nov 05, 2015 at 11:24:59AM +0200, Kirill A. Shutemov wrote:
> On Thu, Nov 05, 2015 at 12:10:13PM +0300, Vladimir Davydov wrote:
> > On Tue, Nov 03, 2015 at 05:26:15PM +0200, Kirill A. Shutemov wrote:
> > ...
> > > @@ -56,23 +56,69 @@ static int page_idle_clear_pte_refs_one(struct page
> > > *page,
> > > {
> > > struct mm_struct *mm = vma->vm_mm;
> > > spinlock_t *ptl;
> > > + pgd_t *pgd;
> > > + pud_t *pud;
> > > pmd_t *pmd;
> > > pte_t *pte;
> > > bool referenced = false;
> > >
> > > - if (unlikely(PageTransHuge(page))) {
> > > - pmd = page_check_address_pmd(page, mm, addr, );
> > > - if (pmd) {
> > > - referenced = pmdp_clear_young_notify(vma, addr, pmd);
> > > + pgd = pgd_offset(mm, addr);
> > > + if (!pgd_present(*pgd))
> > > + return SWAP_AGAIN;
> > > + pud = pud_offset(pgd, addr);
> > > + if (!pud_present(*pud))
> > > + return SWAP_AGAIN;
> > > + pmd = pmd_offset(pud, addr);
> > > +
> > > + if (pmd_trans_huge(*pmd)) {
> > > + ptl = pmd_lock(mm, pmd);
> > > +if (!pmd_present(*pmd))
> > > + goto unlock_pmd;
> > > + if (unlikely(!pmd_trans_huge(*pmd))) {
> > > spin_unlock(ptl);
> > > + goto map_pte;
> > > }
> > > +
> > > + if (pmd_page(*pmd) != page)
> > > + goto unlock_pmd;
> > > +
> > > + referenced = pmdp_clear_young_notify(vma, addr, pmd);
> > > + spin_unlock(ptl);
> > > + goto found;
> > > +unlock_pmd:
> > > + spin_unlock(ptl);
> > > + return SWAP_AGAIN;
> > > } else {
> > > - pte = page_check_address(page, mm, addr, , 0);
> > > - if (pte) {
> > > - referenced = ptep_clear_young_notify(vma, addr, pte);
> > > - pte_unmap_unlock(pte, ptl);
> > > - }
> > > + pmd_t pmde = *pmd;
> > > + barrier();
> > > + if (!pmd_present(pmde) || pmd_trans_huge(pmde))
> > > + return SWAP_AGAIN;
> > > +
> > > + }
> > > +map_pte:
> > > + pte = pte_offset_map(pmd, addr);
> > > + if (!pte_present(*pte)) {
> > > + pte_unmap(pte);
> > > + return SWAP_AGAIN;
> > > }
> > > +
> > > + ptl = pte_lockptr(mm, pmd);
> > > + spin_lock(ptl);
> > > +
> > > + if (!pte_present(*pte)) {
> > > + pte_unmap_unlock(pte, ptl);
> > > + return SWAP_AGAIN;
> > > + }
> > > +
> > > + /* THP can be referenced by any subpage */
> > > + if (pte_pfn(*pte) - page_to_pfn(page) >= hpage_nr_pages(page)) {
> > > + pte_unmap_unlock(pte, ptl);
> > > + return SWAP_AGAIN;
> > > + }
> > > +
> > > + referenced = ptep_clear_young_notify(vma, addr, pte);
> > > + pte_unmap_unlock(pte, ptl);
> > > +found:
> >
> > Can't we hide this stuff in a helper function, which would be used by
> > both page_referenced_one and page_idle_clear_pte_refs_one, instead of
> > duplicating page_referenced_one code here?
>
> I would like to, but there's no obvious way to do that: PMDs and PTEs
> require different handling.
>
> Any ideas?
Something like this? [COMPLETELY UNTESTED]
---
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 853f4f3c6742..bb9169d07c2b 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -216,6 +216,10 @@ static inline pte_t *page_check_address(struct page *page,
struct mm_struct *mm,
return ptep;
}
+pte_t *page_check_address_transhuge(struct page *page, struct mm_struct *mm,
+ unsigned long address,
+ pmd_t **pmdp, spinlock_t **ptlp);
+
/*
* Used by swapoff to help locate where page is expected in vma.
*/
diff --git a/mm/page_idle.c b/mm/page_idle.c
index 2c9ebe12b40d..6574ef6a1a96 100644
--- a/mm/page_idle.c
+++ b/mm/page_idle.c
@@ -56,69 +56,21 @@ static int page_idle_clear_pte_refs_one(struct page *page,
{
struct mm_struct *mm = vma->vm_mm;
spinlock_t *ptl;
- pgd_t *pgd;
- pud_t *pud;
pmd_t *pmd;
pte_t *pte;
bool referenced = false;
- pgd = pgd_offset(mm, addr);
- if (!pgd_present(*pgd))
+ pte = page_check_address_transhuge(page, mm, address, , );
+ if (!pte)
return SWAP_AGAIN;
- pud = pud_offset(pgd, addr);
- if (!pud_present(*pud))
- return SWAP_AGAIN;
- pmd = pmd_offset(pud, addr);
-
- if (pmd_trans_huge(*pmd)) {
- ptl = pmd_lock(mm, pmd);
-if (!pmd_present(*pmd))
- goto unlock_pmd;
- if (unlikely(!pmd_trans_huge(*pmd))) {
- spin_unlock(ptl);
- goto map_pte;
- }
- if (pmd_page(*pmd) != page)
- goto unlock_pmd;
-
- referenced = pmdp_clear_young_notify(vma, addr, pmd);
- spin_unlock(ptl);
- goto found;
-unlock_pmd:
- spin_unlock(ptl);
-
Re: [RFC PATCH 2/7] spi: sunxi: remove redundant "depends on RESET_CONTROLLER"
On Thu, Nov 05, 2015 at 08:15:23PM +0900, Masahiro Yamada wrote: > ARCH_SUNXI selects RESET_CONTROLLER. > The dependency "depends on RESET_CONTROLLER" is already met. No, it isn't. > config SPI_SUN6I > tristate "Allwinner A31 SPI controller" > depends on ARCH_SUNXI || COMPILE_TEST > - depends on RESET_CONTROLLER The dependency is on ARCH_SUNXI || COMPILE_TEST which is not the same as ARCH_SUNXI. signature.asc Description: PGP signature
[PATCH v6 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 ++-
6 files changed, 182 insertions(+), 6 deletions(-)
--
2.4.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 v6 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.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 v6 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", ))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", ))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.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 v6 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ctl>, <_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.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 v6 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
---
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..cce5c1f 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,75 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 32)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-config = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.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/
Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
On Wed, Nov 04, 2015 at 09:42:46PM -0500, Sinan Kaya wrote: > Here is what I proposed. > > - a common file that gets compiled into a module that wants to use > self-test with a public API. It can be called from driver's probe > routine. > - the test is independent of my implementation. It uses dmaengine > API and should be portable to most drivers. > - there *are* still drivers in the kernel that has selftest code > embedded inside them. I followed the design pattern from other > drivers thinking this must have been a good idea and it paid off for > me. > > As far as I understand, there is interest in doing more than this > and reusing the dmatest code for code duplication. the code that selftest uses to test will be very similar to dmatest code, both of these _should_ share this common code so that fixes get done for both! > Facts: > - Dmatest can be actually configured to run during boot. > - Nobody besides the dma driver developer uses dmatest. This leaves > holes for regressions that are really hard to debug due to > interaction with the rest of the system. > - Dmatest doesn't exist in most distribution kernels. That doesn't mean it is not useful. This line of thought is not quite right. You are trying to say dmatest in not important and selftest is. Sorry but you are wrong, both are equally important and since both try to test and use similar routines (dmaengien API) they need to share the code and not duplicate it > If we want to do something else, I need clear directions. I can > remove the self test code completely from my driver. But, I need an > equivalent functionality. Add selftest to dmatest, we need both! > > > > > That part is tricky, you need to do so thru clients, spi/audio/serial etc > > > > My selftest code actually attaches to all slave devices and issues a > memcpy command and then detaches from the slave devices. Not everyone supports memcpy! -- ~Vinod -- 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 v14 03/22] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags
Normally, deleting a file requires MAY_WRITE access to the parent
directory. With richacls, a file may be deleted with MAY_DELETE_CHILD access
to the parent directory or with MAY_DELETE_SELF access to the file.
To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission()
when checking for delete access inside a directory, and MAY_DELETE_SELF
when checking for delete access to a file itelf.
The MAY_DELETE_SELF permission overrides the sticky directory check.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/namei.c | 21 -
include/linux/fs.h | 2 ++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 0259392..2eab19e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -453,9 +453,9 @@ static int sb_permission(struct super_block *sb, struct
inode *inode, int mask)
* this, letting us set arbitrary permissions for filesystem access without
* changing the "normal" UIDs which are used for other things.
*
- * MAY_WRITE must be set in @mask whenever MAY_APPEND, MAY_CREATE_FILE, or
- * MAY_CREATE_DIR are set. That way, file systems that don't support these
- * permissions will check for MAY_WRITE instead.
+ * MAY_WRITE must be set in @mask whenever MAY_APPEND, MAY_CREATE_FILE,
+ * MAY_CREATE_DIR, or MAY_DELETE_CHILD are set. That way, file systems that
+ * don't support these permissions will check for MAY_WRITE instead.
*/
int inode_permission(struct inode *inode, int mask)
{
@@ -2555,7 +2555,7 @@ static int may_delete(struct inode *dir, struct dentry
*victim,
bool isdir, bool replace)
{
struct inode *inode = d_backing_inode(victim);
- int error, mask = MAY_WRITE | MAY_EXEC;
+ int error, mask = MAY_EXEC;
if (d_is_negative(victim))
return -ENOENT;
@@ -2565,15 +2565,18 @@ static int may_delete(struct inode *dir, struct dentry
*victim,
audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE);
if (replace)
- mask |= isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE;
- error = inode_permission(dir, mask);
+ mask |= MAY_WRITE | (isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE);
+ error = inode_permission(dir, mask | MAY_WRITE | MAY_DELETE_CHILD);
+ if (!error && check_sticky(dir, inode))
+ error = -EPERM;
+ if (error && IS_RICHACL(inode) &&
+ inode_permission(inode, MAY_DELETE_SELF) == 0)
+ error = 0;
if (error)
return error;
if (IS_APPEND(dir))
return -EPERM;
-
- if (check_sticky(dir, inode) || IS_APPEND(inode) ||
- IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
+ if (IS_APPEND(inode) || IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
return -EPERM;
if (isdir) {
if (!d_is_dir(victim))
diff --git a/include/linux/fs.h b/include/linux/fs.h
index d6e2330..402acd7 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -84,6 +84,8 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map, int
uptodate);
#define MAY_NOT_BLOCK 0x0080
#define MAY_CREATE_FILE0x0100
#define MAY_CREATE_DIR 0x0200
+#define MAY_DELETE_CHILD 0x0400
+#define MAY_DELETE_SELF0x0800
/*
* flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
--
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: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter,
Great thanks for your feedback!
On 5 November 2015 at 13:13, Guenter Roeck wrote:
> On 11/04/2015 05:59 PM, Timur Tabi wrote:
>>
>> On Tue, Oct 27, 2015 at 11:06 AM, wrote:
>>>
>>> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
>>> +{
>>> + struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
>>> + struct watchdog_device *wdd = >wdd;
>>> +
>>> + /* We don't use pretimeout, trigger WS1 now */
>>> + if (!wdd->pretimeout)
>>> + sbsa_gwdt_set_wcv(wdd, 0);
>>
>>
>> So I'm still concerned about the fact this driver depends on an
>> interrupt handler in order to properly program the hardware. Unlike
>> some other devices, the SBSA watchdog does not need assistance to
>> reset on a timeout -- it is a "fire and forget" device. What happens
>> if there is a hard lockup, and interrupts no longer work?
The reason for this design(program WCV in interrupt handler):
(1) if we don't, the second timeout stage(pretimeout) is only (worst
case) 10 seconds
This short time is not enough for kexec(let alone kdump), that make
panic less useful.
(2)if a hard lockup really happens, panic won't work too.But we still
can reboot system by the help of WS1
in this case, if clk is 400MHz, we just need to wait (worst case) 10
seconds for WS1 reboot system
>>
>> Keep in mind that 99% of watchdog daemons will not enable the
>> pre-timeout feature because it's new.
Answer:
(1)It is not new.
pre-timeout concept has been used by two drivers before this driver.
and this concept has been in kernel documentation.
(2)even it's new, it doesn't mean we can not do this at this time.
Because according to the info I got, I believe that is right way to do.
After I make a "non-pretimeout" version. and compare with the original
pretimeout version, I still believe pretimeout is best solution for
now.
Reason for using pretimeout:
(1) if we don't, for this two stages timeout, we have to config them
by one value.
that means "the first stage timeout" have to be equal to "the second
stage timeout",
For example, if we need 60 second for "the second stage timeout", 30
or less for "the first stage timeout".
then "the first stage timeout" have to be 60s too. I don't think it 's
good idea.
>>
> Same here, really.
>
> I would feel much more comfortable if the driver would just use the standard
> watchdog timeout and live with (worst case) 20 seconds timeout for now.
The worst case is 10s. like I said above, This short time is not
enough for kexec(let alone kdump), that make WS0(and panic, even this
two stages design) less useful
> This limitation will be gone once the infrastructure is in place to handle
> such short timeouts in the watchdog core. Until then, I would argue that the
unless WOR become 64 bit (or more then 32bit), this limitation will be there.
> system designers asked for it if they really select the highest possible
> clock rate.
>
even we can make clk to be 100MHz or lower, it is not very helpful for
a really server which has big memory. they need more time for dumping
memory for debug/analysis
> Guenter
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
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 v14 04/22] vfs: Make the inode passed to inode_change_ok non-const
We will need to call iop->permission and iop->get_acl from
inode_change_ok() for additional permission checks, and both take a
non-const inode.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/attr.c | 2 +-
include/linux/fs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 6530ced..328be71 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -28,7 +28,7 @@
* Should be called as the first thing in ->setattr implementations,
* possibly after taking additional locks.
*/
-int inode_change_ok(const struct inode *inode, struct iattr *attr)
+int inode_change_ok(struct inode *inode, struct iattr *attr)
{
unsigned int ia_valid = attr->ia_valid;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 402acd7..aab32c8 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2871,7 +2871,7 @@ extern int buffer_migrate_page(struct address_space *,
#define buffer_migrate_page NULL
#endif
-extern int inode_change_ok(const struct inode *, struct iattr *);
+extern int inode_change_ok(struct inode *, struct iattr *);
extern int inode_newsize_ok(const struct inode *, loff_t offset);
extern void setattr_copy(struct inode *inode, const struct iattr *attr);
--
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 1/1] staging: rdma: hfi1 : Prefer using the BIT macro
This patch replaces bit shifting on 1 with the BIT(x) macro Signed-off-by: Sunny Kumar --- drivers/staging/rdma/hfi1/user_sdma.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/rdma/hfi1/user_sdma.c b/drivers/staging/rdma/hfi1/user_sdma.c index 36c838d..95a6d99 100644 --- a/drivers/staging/rdma/hfi1/user_sdma.c +++ b/drivers/staging/rdma/hfi1/user_sdma.c @@ -146,8 +146,8 @@ MODULE_PARM_DESC(sdma_comp_size, "Size of User SDMA completion ring. Default: 12 #define KDETH_OM_MAX_SIZE (1 << ((KDETH_OM_LARGE / KDETH_OM_SMALL) + 1)) /* Last packet in the request */ -#define TXREQ_FLAGS_REQ_LAST_PKT (1 << 0) -#define TXREQ_FLAGS_IOVEC_LAST_PKT (1 << 0) +#define TXREQ_FLAGS_REQ_LAST_PKT BIT(1 << 0) +#define TXREQ_FLAGS_IOVEC_LAST_PKT BIT(1 << 0) #define SDMA_REQ_IN_USE 0 #define SDMA_REQ_FOR_THREAD 1 @@ -156,9 +156,9 @@ MODULE_PARM_DESC(sdma_comp_size, "Size of User SDMA completion ring. Default: 12 #define SDMA_REQ_HAS_ERROR 4 #define SDMA_REQ_DONE_ERROR 5 -#define SDMA_PKT_Q_INACTIVE (1 << 0) -#define SDMA_PKT_Q_ACTIVE (1 << 1) -#define SDMA_PKT_Q_DEFERRED (1 << 2) +#define SDMA_PKT_Q_INACTIVE BIT(1 << 0) +#define SDMA_PKT_Q_ACTIVE BIT(1 << 1) +#define SDMA_PKT_Q_DEFERRED BIT(1 << 2) /* * Maximum retry attempts to submit a TX request -- 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 v14 06/22] richacl: In-memory representation and helper functions
A richacl consists of an NFSv4 acl and an owner, group, and other mask.
These three masks correspond to the owner, group, and other file
permission bits, but they contain NFSv4 permissions instead of POSIX
permissions.
Each entry in the NFSv4 acl applies to the file owner (OWNER@), the
owning group (GROUP@), everyone (EVERYONE@), or to a specific uid or
gid.
As in the standard POSIX file permission model, each process is the
owner, group, or other file class. A richacl grants a requested access
only if the NFSv4 acl in the richacl grants the access (according to the
NFSv4 permission check algorithm), and the file mask that applies to the
process includes the requested permissions.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/Makefile | 2 +
fs/richacl_base.c| 67
include/linux/richacl.h | 179 +++
include/uapi/linux/Kbuild| 1 +
include/uapi/linux/richacl.h | 99
5 files changed, 348 insertions(+)
create mode 100644 fs/richacl_base.c
create mode 100644 include/linux/richacl.h
create mode 100644 include/uapi/linux/richacl.h
diff --git a/fs/Makefile b/fs/Makefile
index f79cf40..fe3e9dd 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_COREDUMP)+= coredump.o
obj-$(CONFIG_SYSCTL) += drop_caches.o
obj-$(CONFIG_FHANDLE) += fhandle.o
+obj-$(CONFIG_FS_RICHACL) += richacl.o
+richacl-y := richacl_base.o
obj-y += quota/
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
new file mode 100644
index 000..c3ec928
--- /dev/null
+++ b/fs/richacl_base.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2006, 2010 Novell, Inc.
+ * Copyright (C) 2015 Red Hat, Inc.
+ * Written by Andreas Gruenbacher
+ *
+ * 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, 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
+
+MODULE_LICENSE("GPL");
+
+/**
+ * richacl_alloc - allocate a richacl
+ * @count: number of entries
+ */
+struct richacl *
+richacl_alloc(int count, gfp_t gfp)
+{
+ size_t size = sizeof(struct richacl) + count * sizeof(struct richace);
+ struct richacl *acl = kzalloc(size, gfp);
+
+ if (acl) {
+ atomic_set(>a_refcount, 1);
+ acl->a_count = count;
+ }
+ return acl;
+}
+EXPORT_SYMBOL_GPL(richacl_alloc);
+
+/**
+ * richacl_clone - create a copy of a richacl
+ */
+struct richacl *
+richacl_clone(const struct richacl *acl, gfp_t gfp)
+{
+ int count = acl->a_count;
+ size_t size = sizeof(struct richacl) + count * sizeof(struct richace);
+ struct richacl *dup = kmalloc(size, gfp);
+
+ if (dup) {
+ memcpy(dup, acl, size);
+ atomic_set(>a_refcount, 1);
+ }
+ return dup;
+}
+
+/**
+ * richace_copy - copy an acl entry
+ */
+void
+richace_copy(struct richace *to, const struct richace *from)
+{
+ memcpy(to, from, sizeof(struct richace));
+}
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
new file mode 100644
index 000..edb8480
--- /dev/null
+++ b/include/linux/richacl.h
@@ -0,0 +1,179 @@
+/*
+ * Copyright (C) 2006, 2010 Novell, Inc.
+ * Copyright (C) 2015 Red Hat, Inc.
+ * Written by Andreas Gruenbacher
+ *
+ * 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, 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.
+ */
+
+#ifndef __RICHACL_H
+#define __RICHACL_H
+
+#include
+
+struct richace {
+ unsigned short e_type;
+ unsigned short e_flags;
+ unsigned inte_mask;
+ union {
+ kuid_t uid;
+ kgid_t gid;
+ unsigned intspecial;
+ } e_id;
+};
+
+struct richacl {
+ atomic_ta_refcount;
+ unsigned inta_owner_mask;
+ unsigned inta_group_mask;
+ unsigned inta_other_mask;
+ unsigned short a_count;
+ unsigned short a_flags;
+ struct richace a_entries[0];
+};
+
+#define richacl_for_each_entry(_ace, _acl) \
+
[PATCH v14 07/22] richacl: Permission mapping functions
We need to map from POSIX permissions to NFSv4 permissions when a
chmod() is done, from NFSv4 permissions to POSIX permissions when an acl
is set (which implicitly sets the file permission bits), and from the
MAY_READ/MAY_WRITE/MAY_EXEC/MAY_APPEND flags to NFSv4 permissions when
doing an access check in a richacl.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl_base.c| 118 +++
include/linux/richacl.h | 3 ++
include/uapi/linux/richacl.h | 44
3 files changed, 165 insertions(+)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index c3ec928..a393001 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -65,3 +65,121 @@ richace_copy(struct richace *to, const struct richace *from)
{
memcpy(to, from, sizeof(struct richace));
}
+
+/*
+ * richacl_mask_to_mode - compute the file permission bits from mask
+ * @mask: %RICHACE_* permission mask
+ *
+ * Compute the file permission bits corresponding to a particular set of
+ * richacl permissions.
+ *
+ * See richacl_masks_to_mode().
+ */
+static int
+richacl_mask_to_mode(unsigned int mask)
+{
+ int mode = 0;
+
+ if (mask & RICHACE_POSIX_MODE_READ)
+ mode |= S_IROTH;
+ if (mask & RICHACE_POSIX_MODE_WRITE)
+ mode |= S_IWOTH;
+ if (mask & RICHACE_POSIX_MODE_EXEC)
+ mode |= S_IXOTH;
+
+ return mode;
+}
+
+/**
+ * richacl_masks_to_mode - compute file permission bits from file masks
+ *
+ * When setting a richacl, we set the file permission bits to indicate maximum
+ * permissions: for example, we set the Write permission when a mask contains
+ * RICHACE_APPEND_DATA even if it does not also contain RICHACE_WRITE_DATA.
+ *
+ * Permissions which are not in RICHACE_POSIX_MODE_READ,
+ * RICHACE_POSIX_MODE_WRITE, or RICHACE_POSIX_MODE_EXEC cannot be represented
+ * in the file permission bits. Such permissions can still be effective, but
+ * not for new files or after a chmod(); they must be explicitly enabled in the
+ * richacl.
+ */
+int
+richacl_masks_to_mode(const struct richacl *acl)
+{
+ return richacl_mask_to_mode(acl->a_owner_mask) << 6 |
+ richacl_mask_to_mode(acl->a_group_mask) << 3 |
+ richacl_mask_to_mode(acl->a_other_mask);
+}
+EXPORT_SYMBOL_GPL(richacl_masks_to_mode);
+
+/**
+ * richacl_mode_to_mask - compute a file mask from the lowest three mode bits
+ * @mode: mode to convert to richacl permissions
+ *
+ * When the file permission bits of a file are set with chmod(), this specifies
+ * the maximum permissions that processes will get. All permissions beyond
+ * that will be removed from the file masks, and become ineffective.
+ */
+unsigned int
+richacl_mode_to_mask(umode_t mode)
+{
+ unsigned int mask = 0;
+
+ if (mode & S_IROTH)
+ mask |= RICHACE_POSIX_MODE_READ;
+ if (mode & S_IWOTH)
+ mask |= RICHACE_POSIX_MODE_WRITE;
+ if (mode & S_IXOTH)
+ mask |= RICHACE_POSIX_MODE_EXEC;
+
+ return mask;
+}
+
+/**
+ * richacl_want_to_mask - convert the iop->permission want argument to a mask
+ * @want: @want argument of the permission inode operation
+ *
+ * When checking for append, @want is (MAY_WRITE | MAY_APPEND).
+ *
+ * Richacls use the iop->may_create and iop->may_delete hooks which are used
+ * for checking if creating and deleting files is allowed. These hooks do not
+ * use richacl_want_to_mask(), so we do not have to deal with mapping MAY_WRITE
+ * to RICHACE_ADD_FILE, RICHACE_ADD_SUBDIRECTORY, and RICHACE_DELETE_CHILD
+ * here.
+ */
+unsigned int
+richacl_want_to_mask(unsigned int want)
+{
+ unsigned int mask = 0;
+
+ if (want & MAY_READ)
+ mask |= RICHACE_READ_DATA;
+ if (want & MAY_DELETE_SELF)
+ mask |= RICHACE_DELETE;
+ if (want & MAY_TAKE_OWNERSHIP)
+ mask |= RICHACE_WRITE_OWNER;
+ if (want & MAY_CHMOD)
+ mask |= RICHACE_WRITE_ACL;
+ if (want & MAY_SET_TIMES)
+ mask |= RICHACE_WRITE_ATTRIBUTES;
+ if (want & MAY_EXEC)
+ mask |= RICHACE_EXECUTE;
+ /*
+* differentiate MAY_WRITE from these request
+*/
+ if (want & (MAY_APPEND |
+ MAY_CREATE_FILE | MAY_CREATE_DIR |
+ MAY_DELETE_CHILD)) {
+ if (want & MAY_APPEND)
+ mask |= RICHACE_APPEND_DATA;
+ if (want & MAY_CREATE_FILE)
+ mask |= RICHACE_ADD_FILE;
+ if (want & MAY_CREATE_DIR)
+ mask |= RICHACE_ADD_SUBDIRECTORY;
+ if (want & MAY_DELETE_CHILD)
+ mask |= RICHACE_DELETE_CHILD;
+ } else if (want & MAY_WRITE)
+ mask |= RICHACE_WRITE_DATA;
+ return mask;
+}
+EXPORT_SYMBOL_GPL(richacl_want_to_mask);
diff --git a/include/linux/richacl.h
[PATCH v14 08/22] richacl: Compute maximum file masks from an acl
Compute upper bound owner, group, and other file masks with as few
permissions as possible without denying any permissions that the NFSv4
acl in a richacl grants.
This algorithm is used when a file inherits an acl at create time and
when an acl is set via a mechanism that does not provide file masks
(such as setting an acl via nfsd). When user-space sets an acl via
setxattr, the extended attribute already includes the file masks.
Setting an acl also sets the file mode permission bits: they are
determined by the file masks; see richacl_masks_to_mode().
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl_base.c | 157
include/linux/richacl.h | 1 +
2 files changed, 158 insertions(+)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index a393001..69b806c 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -183,3 +183,160 @@ richacl_want_to_mask(unsigned int want)
return mask;
}
EXPORT_SYMBOL_GPL(richacl_want_to_mask);
+
+/*
+ * Note: functions like richacl_allowed_to_who(),
richacl_group_class_allowed(),
+ * and richacl_compute_max_masks() iterate through the entire acl in reverse
+ * order as an optimization.
+ *
+ * In the standard algorithm, aces are considered in forward order. When a
+ * process matches an ace, the permissions in the ace are either allowed or
+ * denied depending on the ace type. Once a permission has been allowed or
+ * denied, it is no longer considered in further aces.
+ *
+ * By iterating through the acl in reverse order, we can compute the same
+ * result without having to keep track of which permissions have been allowed
+ * and denied already.
+ */
+
+/**
+ * richacl_allowed_to_who - permissions allowed to a specific who value
+ *
+ * Compute the maximum mask values allowed to a specific who value, taking
+ * everyone@ aces into account.
+ */
+static unsigned int richacl_allowed_to_who(struct richacl *acl,
+ struct richace *who)
+{
+ struct richace *ace;
+ unsigned int allowed = 0;
+
+ richacl_for_each_entry_reverse(ace, acl) {
+ if (richace_is_inherit_only(ace))
+ continue;
+ if (richace_is_same_identifier(ace, who) ||
+ richace_is_everyone(ace)) {
+ if (richace_is_allow(ace))
+ allowed |= ace->e_mask;
+ else if (richace_is_deny(ace))
+ allowed &= ~ace->e_mask;
+ }
+ }
+ return allowed;
+}
+
+/**
+ * richacl_group_class_allowed - maximum permissions of the group class
+ *
+ * Compute the maximum mask values allowed to a process in the group class
+ * (i.e., a process which is not the owner but is in the owning group or
+ * matches a user or group acl entry). This includes permissions granted or
+ * denied by everyone@ aces.
+ *
+ * See richacl_compute_max_masks().
+ */
+static unsigned int richacl_group_class_allowed(struct richacl *acl)
+{
+ struct richace *ace;
+ unsigned int everyone_allowed = 0, group_class_allowed = 0;
+ int had_group_ace = 0;
+
+ richacl_for_each_entry_reverse(ace, acl) {
+ if (richace_is_inherit_only(ace) ||
+ richace_is_owner(ace))
+ continue;
+
+ if (richace_is_everyone(ace)) {
+ if (richace_is_allow(ace))
+ everyone_allowed |= ace->e_mask;
+ else if (richace_is_deny(ace))
+ everyone_allowed &= ~ace->e_mask;
+ } else {
+ group_class_allowed |=
+ richacl_allowed_to_who(acl, ace);
+
+ if (richace_is_group(ace))
+ had_group_ace = 1;
+ }
+ }
+ /*
+* If the acl doesn't contain any group@ aces, richacl_allowed_to_who()
+* wasn't called for the owning group. We could make that call now, but
+* we already know the result (everyone_allowed).
+*/
+ if (!had_group_ace)
+ group_class_allowed |= everyone_allowed;
+ return group_class_allowed;
+}
+
+/**
+ * richacl_compute_max_masks - compute upper bound masks
+ *
+ * Computes upper bound owner, group, and other masks so that none of the
+ * permissions allowed by the acl are disabled.
+ *
+ * We don't make assumptions about who the owner is so that the owner can
+ * change with no effect on the file masks or file mode permission bits; this
+ * means that we must assume that all entries can match the owner.
+ */
+void richacl_compute_max_masks(struct richacl *acl)
+{
+ unsigned int gmask = ~0;
+ struct richace *ace;
+
+ /*
+* @gmask contains all permissions which the group class is ever
+* allowed. We use it to avoid
[PATCH v2 2/2] arm64: dts: exynos7: Enable HS200 mode operation
This patch enables HS200 mode operation on exynos7 based
espresso board.
This also removes _broken-cd_ property as per mmc binding documentation
which says one of the properties between broken-cd and non-removable
should be used. And we already use _non-removable_ as emmc mounted
on board which is a non-removable device.
Signed-off-by: Alim Akhtar
Reviewed-by: Javier Martinez Canillas
---
Changes since v1:
* Addressed Krzysztof review comments
arch/arm64/boot/dts/exynos/exynos7-espresso.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index f5a3da50ac57..d8767b00862e 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -333,8 +333,8 @@
_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
cap-mmc-highspeed;
+ mmc-hs200-1_8v;
non-removable;
card-detect-delay = <200>;
clock-frequency = <8>;
--
1.7.10.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 v2 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node
This patch add pmic (s2mps15) node of espresso board,
which includes addition of regulators and pmic-clk sub-nodes.
This patch also adds {vmmc,vqmmc}-supply properties for mmc2 node.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Alim Akhtar
Reviewed-by: Javier Martinez Canillas
---
Changes since v1:
* Addressed Javier and Krzysztof review comments.
* Removed unused ldo/buck nodes.
* Removed always-on properties from ldo/buck to disable them
* Added a consumer of pmic supply (like mmc)
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 280 +++
1 file changed, 280 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 5424cc450f72..f5a3da50ac57 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos7.dtsi"
+#include
/ {
model = "Samsung Exynos7 Espresso board based on EXYNOS7";
@@ -52,6 +53,283 @@
status = "okay";
};
+_4 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <20>;
+ status = "okay";
+
+ s2mps15_pmic@66 {
+ compatible = "samsung,s2mps15-pmic";
+ reg = <0x66>;
+ interrupts = <2 IRQ_TYPE_NONE>;
+ interrupt-parent = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_irq>;
+ wakeup-source;
+
+ s2mps15_osc: clocks {
+ compatible = "samsung,s2mps13-clk";
+ #clock-cells = <1>;
+ clock-output-names = "s2mps13_ap", "s2mps13_cp",
+ "s2mps13_bt";
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_ldo1";
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <90>;
+ regulator-always-on;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "vqmmc-sdcard";
+ regulator-min-microvolt = <162>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "vdd_ldo3";
+ regulator-min-microvolt = <162>;
+ regulator-max-microvolt = <198>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "vdd_ldo4";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <111>;
+ regulator-always-on;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "vdd_ldo5";
+ regulator-min-microvolt = <162>;
+ regulator-max-microvolt = <198>;
+ regulator-always-on;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "vdd_ldo6";
+ regulator-min-microvolt = <225>;
+ regulator-max-microvolt = <330>;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = "vdd_ldo7";
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <115>;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo8_reg: LDO8 {
+ regulator-name = "vdd_ldo8";
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <100>;
+ regulator-enable-ramp-delay = <125>;
+ };
+
+ ldo9_reg: LDO9 {
+ regulator-name = "vdd_ldo9";
+ regulator-min-microvolt = <70>;
+
Re: [RFC PATCH 3/7] spi: tegra: remove redundant "depends on RESET_CONTROLLER"
On Thu, Nov 05, 2015 at 08:15:24PM +0900, Masahiro Yamada wrote: > ARCH_TEGRA selects RESET_CONTROLLER. > The dependency "depends on RESET_CONTROLLER" is already met. > tristate "NVIDIA Tegra114 SPI Controller" > depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST > - depends on RESET_CONTROLLER && HAS_DMA > + depends on HAS_DMA Again, this driver doesn't depend on ARCH_TEGRA. signature.asc Description: PGP signature
[PATCH v14 11/22] vfs: Cache base_acl objects in inodes
POSIX ACLs and richacls are both objects allocated by kmalloc() with a
reference count which are freed by kfree_rcu(). An inode can either
cache an access and a default POSIX ACL, or a richacl (richacls do not
have default acls). To allow an inode to cache either of the two kinds
of acls, introduce a new base_acl type and convert i_acl and
i_default_acl to that type. In most cases, the vfs then doesn't care which
kind of acl an inode caches (if any).
Signed-off-by: Andreas Gruenbacher
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
fs/f2fs/acl.c | 4 +--
fs/inode.c | 4 +--
fs/jffs2/acl.c | 10 --
fs/posix_acl.c | 41 +
fs/richacl_base.c | 4 +--
include/linux/fs.h | 34 ++--
include/linux/posix_acl.h | 12 +++-
include/linux/richacl.h | 9 +++---
9 files changed, 75 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index b4ed6c8..46912c2 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1118,7 +1118,7 @@ void ll_clear_inode(struct inode *inode)
}
#ifdef CONFIG_FS_POSIX_ACL
else if (lli->lli_posix_acl) {
- LASSERT(atomic_read(>lli_posix_acl->a_refcount) == 1);
+ LASSERT(base_acl_refcount(>lli_posix_acl->a_base) == 1);
LASSERT(lli->lli_remote_perms == NULL);
posix_acl_release(lli->lli_posix_acl);
lli->lli_posix_acl = NULL;
diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
index c8f25f7..9646197 100644
--- a/fs/f2fs/acl.c
+++ b/fs/f2fs/acl.c
@@ -270,7 +270,7 @@ static struct posix_acl *f2fs_acl_clone(const struct
posix_acl *acl,
sizeof(struct posix_acl_entry);
clone = kmemdup(acl, size, flags);
if (clone)
- atomic_set(>a_refcount, 1);
+ base_acl_init(>a_base);
}
return clone;
}
@@ -282,7 +282,7 @@ static int f2fs_acl_create_masq(struct posix_acl *acl,
umode_t *mode_p)
umode_t mode = *mode_p;
int not_equiv = 0;
- /* assert(atomic_read(acl->a_refcount) == 1); */
+ /* assert(base_acl_refcount(>a_base) == 1); */
FOREACH_ACL_ENTRY(pa, acl, pe) {
switch(pa->e_tag) {
diff --git a/fs/inode.c b/fs/inode.c
index 78a17b8..5c46ae5 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -233,9 +233,9 @@ void __destroy_inode(struct inode *inode)
#ifdef CONFIG_FS_POSIX_ACL
if (inode->i_acl && inode->i_acl != ACL_NOT_CACHED)
- posix_acl_release(inode->i_acl);
+ base_acl_put(inode->i_acl);
if (inode->i_default_acl && inode->i_default_acl != ACL_NOT_CACHED)
- posix_acl_release(inode->i_default_acl);
+ base_acl_put(inode->i_default_acl);
#endif
this_cpu_dec(nr_inodes);
}
diff --git a/fs/jffs2/acl.c b/fs/jffs2/acl.c
index 2f7a3c0..569cb1b 100644
--- a/fs/jffs2/acl.c
+++ b/fs/jffs2/acl.c
@@ -294,13 +294,19 @@ int jffs2_init_acl_post(struct inode *inode)
int rc;
if (inode->i_default_acl) {
- rc = __jffs2_set_acl(inode, JFFS2_XPREFIX_ACL_DEFAULT,
inode->i_default_acl);
+ struct posix_acl *default_acl = container_of(
+ inode->i_default_acl, struct posix_acl, a_base);
+
+ rc = __jffs2_set_acl(inode, JFFS2_XPREFIX_ACL_DEFAULT,
default_acl);
if (rc)
return rc;
}
if (inode->i_acl) {
- rc = __jffs2_set_acl(inode, JFFS2_XPREFIX_ACL_ACCESS,
inode->i_acl);
+ struct posix_acl *acl = container_of(
+ inode->i_acl, struct posix_acl, a_base);
+
+ rc = __jffs2_set_acl(inode, JFFS2_XPREFIX_ACL_ACCESS, acl);
if (rc)
return rc;
}
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index aacfb58..4573315 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -21,7 +21,7 @@
#include
#include
-static struct posix_acl **acl_by_type(struct inode *inode, int type)
+static struct base_acl **acl_by_type(struct inode *inode, int type)
{
switch (type) {
case ACL_TYPE_ACCESS:
@@ -35,63 +35,64 @@ static struct posix_acl **acl_by_type(struct inode *inode,
int type)
struct posix_acl *get_cached_acl(struct inode *inode, int type)
{
- struct posix_acl **p = acl_by_type(inode, type);
- struct posix_acl *acl = ACCESS_ONCE(*p);
+ struct base_acl **p = acl_by_type(inode, type);
+ struct base_acl *acl = ACCESS_ONCE(*p);
if (acl) {
spin_lock(>i_lock);
[PATCH v14 12/22] vfs: Add get_richacl and set_richacl inode operations
These operations are similar to the get_acl and set_acl operations for
POSIX ACLs. The distinction between access and default ACLs doesn't exist
for richacls.
Signed-off-by: Andreas Gruenbacher
---
include/linux/fs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 2fd840e..3c36c72 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1662,6 +1662,7 @@ struct inode_operations {
const char * (*follow_link) (struct dentry *, void **);
int (*permission) (struct inode *, int);
struct posix_acl * (*get_acl)(struct inode *, int);
+ struct richacl * (*get_richacl)(struct inode *);
int (*readlink) (struct dentry *, char __user *,int);
void (*put_link) (struct inode *, void *);
@@ -1691,6 +1692,7 @@ struct inode_operations {
umode_t create_mode, int *opened);
int (*tmpfile) (struct inode *, struct dentry *, umode_t);
int (*set_acl)(struct inode *, struct posix_acl *, int);
+ int (*set_richacl)(struct inode *, struct richacl *);
/* WARNING: probably going away soon, do not use! */
} cacheline_aligned;
--
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] mm: slab: Only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE
Commit 8fc9cf420b36 ("slab: make more slab management structure off the
slab") enables off-slab management objects for sizes starting with
PAGE_SIZE >> 5. This means 128 bytes for a 4KB page configuration.
However, on systems with a KMALLOC_MIN_SIZE of 128 (arm64 in 4.4), such
optimisation does not make sense since the slab management allocation
would take 128 bytes anyway (even though freelist_size is 32) with the
additional overhead of another allocation.
This patch introduces an OFF_SLAB_MIN_SIZE macro which takes
KMALLOC_MIN_SIZE into account. It also solves a slab bug on arm64 where
the first kmalloc_cache to be initialised after slab_early_init = 0,
"kmalloc-128", fails to allocate off-slab management objects from the
same "kmalloc-128" cache.
Fixes: 8fc9cf420b36 ("slab: make more slab management structure off the slab")
Cc: # 3.15+
Reported-by: Geert Uytterhoeven
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Signed-off-by: Catalin Marinas
---
mm/slab.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 4fcc5dd8d5a6..419b649b395e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -282,6 +282,7 @@ static void kmem_cache_node_init(struct kmem_cache_node
*parent)
#define CFLGS_OFF_SLAB (0x8000UL)
#defineOFF_SLAB(x) ((x)->flags & CFLGS_OFF_SLAB)
+#define OFF_SLAB_MIN_SIZE (max_t(size_t, PAGE_SIZE >> 5, KMALLOC_MIN_SIZE
+ 1))
#define BATCHREFILL_LIMIT 16
/*
@@ -2212,7 +2213,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned
long flags)
* it too early on. Always use on-slab management when
* SLAB_NOLEAKTRACE to avoid recursive calls into kmemleak)
*/
- if ((size >= (PAGE_SIZE >> 5)) && !slab_early_init &&
+ if (size >= OFF_SLAB_MIN_SIZE && !slab_early_init &&
!(flags & SLAB_NOLEAKTRACE))
/*
* Size is large, assume best to place the slab management obj
@@ -2276,7 +2277,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned
long flags)
/*
* This is a possibility for one of the kmalloc_{dma,}_caches.
* But since we go off slab only for object size greater than
-* PAGE_SIZE/8, and kmalloc_{dma,}_caches get created
+* OFF_SLAB_MIN_SIZE, and kmalloc_{dma,}_caches get created
* in ascending order,this should not happen at all.
* But leave a BUG_ON for some lucky dude.
*/
--
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 v14 14/22] richacl: Update the file masks in chmod()
Doing a chmod() sets the file mode, which includes the file permission
bits. When a file has a richacl, the permissions that the richacl
grants need to be limited to what the new file permission bits allow.
This is done by setting the file masks in the richacl to what the file
permission bits map to. The richacl access check algorithm takes the
file masks into account, which ensures that the richacl cannot grant too
many permissions.
It is possible to explicitly add permissions to the file masks which go
beyond what the file permission bits can grant (like the
RICHACE_WRITE_ACL permission). The POSIX.1 standard calls this an
alternate file access control mechanism. A subsequent chmod() would
ensure that those permissions are disabled again.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl_base.c | 42 ++
fs/richacl_inode.c | 30 ++
include/linux/richacl.h | 2 ++
3 files changed, 74 insertions(+)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index 5826842..e4dd779 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -340,3 +340,45 @@ restart:
acl->a_flags &= ~(RICHACL_WRITE_THROUGH | RICHACL_MASKED);
}
EXPORT_SYMBOL_GPL(richacl_compute_max_masks);
+
+/**
+ * __richacl_chmod - update the file masks to reflect the new mode
+ * @acl: access control list
+ * @mode: new file permission bits including the file type
+ *
+ * Return a copy of @acl where the file masks have been replaced by the file
+ * masks corresponding to the file permission bits in @mode, or returns @acl
+ * itself if the file masks are already up to date. Takes over a reference
+ * to @acl.
+ */
+struct richacl *
+__richacl_chmod(struct richacl *acl, umode_t mode)
+{
+ unsigned int x = S_ISDIR(mode) ? 0 : RICHACE_DELETE_CHILD;
+ unsigned int owner_mask, group_mask, other_mask;
+ struct richacl *clone;
+
+ owner_mask = richacl_mode_to_mask(mode >> 6) & ~x;
+ group_mask = richacl_mode_to_mask(mode >> 3) & ~x;
+ other_mask = richacl_mode_to_mask(mode) & ~x;
+
+ if (acl->a_owner_mask == owner_mask &&
+ acl->a_group_mask == group_mask &&
+ acl->a_other_mask == other_mask &&
+ (acl->a_flags & RICHACL_MASKED) &&
+ (acl->a_flags & RICHACL_WRITE_THROUGH))
+ return acl;
+
+ clone = richacl_clone(acl, GFP_KERNEL);
+ richacl_put(acl);
+ if (!clone)
+ return ERR_PTR(-ENOMEM);
+
+ clone->a_flags |= (RICHACL_WRITE_THROUGH | RICHACL_MASKED);
+ clone->a_owner_mask = owner_mask;
+ clone->a_group_mask = group_mask;
+ clone->a_other_mask = other_mask;
+
+ return clone;
+}
+EXPORT_SYMBOL_GPL(__richacl_chmod);
diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
index 52c1595..e329826 100644
--- a/fs/richacl_inode.c
+++ b/fs/richacl_inode.c
@@ -224,3 +224,33 @@ out:
return denied ? -EACCES : 0;
}
EXPORT_SYMBOL_GPL(richacl_permission);
+
+/**
+ * richacl_chmod - filesystem chmod helper
+ * @inode: inode whose file permission bits to change
+ * @mode: new file permission bits including the file type
+ *
+ * Helper for filesystems to use to perform a chmod on the richacl of an inode.
+ */
+int
+richacl_chmod(struct inode *inode, umode_t mode)
+{
+ struct richacl *acl;
+ int retval;
+
+ if (S_ISLNK(mode))
+ return -EOPNOTSUPP;
+ if (!inode->i_op->set_richacl)
+ return -EOPNOTSUPP;
+ acl = get_richacl(inode);
+ if (IS_ERR_OR_NULL(acl))
+ return PTR_ERR(acl);
+ acl = __richacl_chmod(acl, mode);
+ if (IS_ERR(acl))
+ return PTR_ERR(acl);
+ retval = inode->i_op->set_richacl(inode, acl);
+ richacl_put(acl);
+
+ return retval;
+}
+EXPORT_SYMBOL(richacl_chmod);
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index 7bf912b6..a2d5600 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -184,8 +184,10 @@ extern int richacl_masks_to_mode(const struct richacl *);
extern unsigned int richacl_mode_to_mask(umode_t);
extern unsigned int richacl_want_to_mask(unsigned int);
extern void richacl_compute_max_masks(struct richacl *);
+extern struct richacl *__richacl_chmod(struct richacl *, umode_t);
/* richacl_inode.c */
extern int richacl_permission(struct inode *, const struct richacl *, int);
+extern int richacl_chmod(struct inode *, umode_t);
#endif /* __RICHACL_H */
--
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/
