Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: > On 11/03/2014 01:09 PM, Mark Brown wrote: > >No function calls, just use regulators_node. What is unclear about the > >functionality? > I don't understand what you mean by "regulators_node". > "grep -R regulators_node *" in the kernel source tree returns no results, > nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. signature.asc Description: Digital signature
Re: [patch 1/3] mm: embed the memcg pointer directly into struct page
Hi Joonsoo, On Mon, Nov 03, 2014 at 05:02:08PM +0900, Joonsoo Kim wrote: > On Sat, Nov 01, 2014 at 11:15:54PM -0400, Johannes Weiner wrote: > > Memory cgroups used to have 5 per-page pointers. To allow users to > > disable that amount of overhead during runtime, those pointers were > > allocated in a separate array, with a translation layer between them > > and struct page. > > Hello, Johannes. > > I'd like to leave this translation layer. > Could you just disable that code with #ifdef until next user comes? > > In our company, we uses PAGE_OWNER on mm tree which is the feature > saying who allocates the page. To use PAGE_OWNER needs modifying > struct page and then needs re-compile. This re-compile makes us difficult > to use this feature. So, we decide to implement run-time configurable > PAGE_OWNER through page_cgroup's translation layer code. Moreover, with > this infrastructure, I plan to implement some other debugging feature. > > Because of my laziness, it didn't submitted to LKML. But, I will > submit it as soon as possible. If the code is removed, I would > copy-and-paste the code, but, it would cause lose of the history on > that code. So if possible, I'd like to leave that code now. Please re-introduce this code when your new usecase is ready to be upstreamed. There is little reason to burden an unrelated feature with a sizable chunk of dead code for a vague future user. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ALSA: echoaudio: add reference of struct echoaudio
On Mon, 2014-11-03 at 15:17 +0100, Takashi Iwai wrote: > At Mon, 3 Nov 2014 16:04:12 +0530, > Sudip Mukherjee wrote: > > > > added reference of struct echoaudio to free_firmware function. > > this structure will be later used to get a reference of the card > > when converting snd_printk to dev_* in the next patch of the series. > > > > Signed-off-by: Sudip Mukherjee > > Thanks, now applied both. Though, I noticed that there is also a > dev_notice() usage that should be also dev_dbg(). Corrected such > lines in my side. Are any of these changes going to cause a null pointer dereference of chip->card->dev? ftrace exists and is generic. Several of these seem to be function tracing style uses and should just be deleted instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] Compact interface for Device-Tree
On Friday 31 October 2014 23:53:28 Rafael J. Wysocki wrote:
> On Saturday, November 01, 2014 05:13:45 AM Rob Herring wrote:
> > On Fri, Oct 31, 2014 at 6:59 AM, Gilad Avidov
> > wrote:
> > >
> > > Device-Tree compact API
> > >
> > >
> > > Common code seen in driver’s probe reads device tree values and handling
> > > erroneous return codes from all those of_property_read_xxx() APIs. This
> > > common code is factored out by the of_property_map module which allows
> > > driver’s probe to replace that (often lengthy) code with a concise table:
> > >
> > > struct of_prop_map map[] = {
> > > {"i2c",>id,OF_REQ, OF_ID, -1},
> > > {"qcom,clk-freq-out",>clk_freq_out,OF_REQ, OF_U32, 0},
> > > {"qcom,clk-freq-in",>clk_freq_in,OF_REQ, OF_U32, 0},
> > > {"qcom,disable-dma",>disable_dma,OF_OPT, OF_BOOL, 0},
> > > {"qcom,master-id",>mstr_id,OF_SGST, OF_U32, 0},
> > > {NULL,NULL,0, 0, 0},
> > > };
> > >
> > > Then call populate to read the values into the device’s variables:
> > >
> > > ret = of_prop_populate(dev, dev->of_node, map);
> >
> > Interesting idea. The main concern I have with this is there has been
> > on-going discussions about how to generalize property handling across
> > DT and ACPI to make drivers more agnostic, so I'm copying a few folks
> > involved in that. That may be a bit orthogonal to what this is doing,
> > but we may want some coordination here.
>
> Agreed.
>
> We actually have a patchset adding a unified device property API in
> linux-next
> (http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=device-properties)
> and I'd prefer to see the "compactization" to happen at that level, if
> possible,
> rather that for of_ only.
Agreed, this should definitely use the new generalized API.
I have prototyped a similar concept last year, which actually went much
further and also abstracted high-level properties such as interrupts,
gpios, pwm, dma-engine, etc. I still think we should do something
like that, but I've never had the time to follow up and nobody else
picked up my work from back then.
Would others like to see that?
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: [PATCH 2/4] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
On Mon, 27 Oct 2014, Vignesh R wrote:
> From: Brad Griffis
>
> TSC interrupt handler had udelay to avoid reporting of false pen-up
> interrupt to user space. This patch implements workaround suggesting in
> Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
> and touchscreen lag. This also improves performance of touchscreen and
> eliminates sudden jump of cursor at touch release.
>
> IDLECONFIG and CHARGECONFIG registers are to be configured
> with same values in order to eliminate false pen-up events. This
> workaround may result in false pen-down to be detected, hence considerable
> charge step delay needs to be added. The charge delay is set to 0xB000
> (in terms of ADC clock cycles) by default.
>
> TSC steps are disabled at the end of every sampling cycle and EOS bit is
> set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
> next sampling cycle.
>
> In one shot mode, sequencer automatically disables all enabled steps at
> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> need not be saved in reg_se_cache for clearing these steps at a later
> stage.
>
> Signed-off-by: Brad Griffis
> [vigne...@ti.com: Ported patch from v3.12 to v3.18rc2]
> Signed-off-by: Vignesh R
> ---
> drivers/input/touchscreen/ti_am335x_tsc.c | 56
> ---
> drivers/mfd/ti_am335x_tscadc.c| 7 ++--
> include/linux/mfd/ti_am335x_tscadc.h | 4 ++-
> 3 files changed, 30 insertions(+), 37 deletions(-)
[...]
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index d877e777cce6..94ef8992f46b 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> *tsadc)
> spin_lock_irq(>reg_lock);
> finish_wait(>reg_se_wait, );
>
> + /*
> + * Sequencer should either be idle or
> + * busy applying the charge step.
> + */
> reg = tscadc_readl(tsadc, REG_ADCFSM);
> - WARN_ON(reg & SEQ_STATUS);
> + WARN_ON(reg & SEQ_STATUS & (!CHARGE_STEP));
> tsadc->adc_waiting = false;
> }
> tsadc->adc_in_use = true;
> @@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> *tsadc)
> void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
> {
> spin_lock_irq(>reg_lock);
> - tsadc->reg_se_cache |= val;
> am335x_tscadc_need_adc(tsadc);
>
> tscadc_writel(tsadc, REG_SE, val);
I believe all of these changes can, and therefor should live in a
separate patch.
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
> b/include/linux/mfd/ti_am335x_tscadc.h
> index e2e70053470e..fcce182e4a35 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -52,6 +52,7 @@
>
> /* IRQ enable */
> #define IRQENB_HW_PENBIT(0)
> +#define IRQENB_EOS BIT(1)
> #define IRQENB_FIFO0THRESBIT(2)
> #define IRQENB_FIFO0OVRRUN BIT(3)
> #define IRQENB_FIFO0UNDRFLW BIT(4)
> @@ -107,7 +108,7 @@
> /* Charge delay */
> #define CHARGEDLY_OPEN_MASK (0x3 << 0)
> #define CHARGEDLY_OPEN(val) ((val) << 0)
> -#define CHARGEDLY_OPENDLYCHARGEDLY_OPEN(1)
> +#define CHARGEDLY_OPENDLYCHARGEDLY_OPEN(0xB000)
>
> /* Control register */
> #define CNTRLREG_TSCSSENBBIT(0)
> @@ -127,6 +128,7 @@
>
> /* Sequencer Status */
> #define SEQ_STATUS BIT(5)
> +#define CHARGE_STEP 0x11
>
> #define ADC_CLK 300
> #define TOTAL_STEPS 16
The header changes should be split between the two Input and MFD
patches.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: Userspace software event and ioctl
On Mon, 2014-11-03 at 14:48 +, Tomeu Vizoso wrote: > On 29 September 2014 17:53, Pawel Moll wrote: > > On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote: > >> Also none of the many words above describe > >> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about? > > > > Hopefully description of the v2 makes better job in this: > > > > http://thread.gmane.org/gmane.linux.kernel/1793272/focus=4813 > > > > where it's already called "UEVENT" and was generated by write(). > > > > Before you get into this, though, the most important outcomes of both v1 > > and v2 discussions: > > > > * Ingo suggested prctl(PR_TRACE_UEVENT, type, size, data, 0) as the way > > of generating such events (so the tracee doesn't have to know the fd to > > do ioctl); Frederic seems to have the same on his mind. > > > > * Namhyung proposed sticking the userspace-originating events into the > > buffer as PERF_RECORD_UEVENT rather then PERF_SAMPLE_UEVENT. > > > > Working on making both happen now. > > are you still working on this? Would be happy to lend a hand if that > can speed things up. By all means! In fact I'm typing commit messages right now and will post the patches later today. Stay tuned and I'm looking forward to all suggestions, reviews etc. Cheers! Pawel -- 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] ACPI / GPIO: Pass index to acpi_get_gpiod_by_index() when using properties
On Sunday, November 02, 2014 08:49:37 PM Darren Hart wrote:
>
> On 11/1/14 4:11, Grant Likely wrote:
> > On Tue, 28 Oct 2014 22:59:57 +0100
> > , "Rafael J. Wysocki"
> > wrote:
> >> On Tuesday, October 28, 2014 01:15:27 PM Mika Westerberg wrote:
> >>> acpi_dev_add_driver_gpios() makes it possible to set up mapping between
> >>> properties and ACPI GpioIo resources in a driver, so we can take index
> >>> parameter in acpi_find_gpio() into use with _DSD device properties now.
> >>>
> >>> This index can be used to select a GPIO from a property with multiple
> >>> GPIOs:
> >>>
> >>> Package () {
> >>> "data-gpios",
> >>> Package () {
> >>> \_SB.GPIO, 0, 0, 0,
> >>> \_SB.GPIO, 1, 0, 0,
> >>> \_SB.GPIO, 2, 0, 1,
> >>> }
> >>> }
> >>>
> >>> In order to retrieve the last GPIO from a driver we can simply do:
> >>>
> >>> desc = devm_gpiod_get_index(dev, "data", 2);
> >>>
> >>> and so on.
> >>>
> >>> Signed-off-by: Mika Westerberg
> >>
> >> Cool. :-)
> >>
> >> Any objections anyone?
> >
> > Actually, I do. Not in the idea, but in the implementation. The way this
> > gets encoded:
> >
> > Package () {
> > \_SB.GPIO, 0, 0, 0,
> > \_SB.GPIO, 1, 0, 0,
> > \_SB.GPIO, 2, 0, 1,
> > }
> >
> > Means that decoding each GPIO tuple requires the length of a tuple to be
> > fixed, or to implement a DT-like #gpio-cells. If it is fixed, then there
> > is no way to expand the binding later. Can this be done in the following
> > way instead?
> >
> > Package () {
> > Package () { \_SB.GPIO, 0, 0, 0 },
> > Package () { \_SB.GPIO, 1, 0, 0 },
> > Package () { \_SB.GPIO, 2, 0, 1 },
> > }
> >
> > This is one of the biggest pains in device tree. We don't have any way
> > to group tuples so it requires looking up stuff across the tree to
> > figure out how to parse each multi-item property.
> >
> > I know that last year we talked about how bios vendors would get
> > complicated properties wrong, but I think there is little risk in this
> > case. If the property is encoded wrong, the driver simply won't work and
> > it is unlikely to get shipped before being fixed.
>
> This particular nesting of Packages is expressly prohibited by the
> Device Properties UUID for the reasons you mention.
>
> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Also we don't use properties where single name is assigned to multiple GPIOs
anywhere in the current device-properties patchset, so this is not relevant at
the moment.
Moreover, even if we were to use them, we would need to ensure that this:
Package () {
\_SB.GPIO, 0, 0, 0
}
was equivalent to
Package () {
Package () { \_SB.GPIO, 0, 0, 0 }
}
This is not impossible to do and I suppose we could even explain that in the
implementation guide document in a sensible way, but that would require the
document linked above to be changed first and *then* we can think about writing
kernel code to it. Not the other way around, please.
So Grant, do you want us to proceed with that?
Rafael
--
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/
stmmac: potential circular locking dependency
Hi everyone,
I was playing with iperf on my Cubietruck today when I hit this lockdep
report/breakage on stmmac. It seems to be fairly reproducible by
1) Being on a GbE network
2) "iperf -s" on the stmmmac device
3) "iperf -c -d -P 5" on some other device on the LAN
Here it goes:
==
[ INFO: possible circular locking dependency detected ]
3.18.0-rc3-3-g7180edf #916 Not tainted
---
iperf/141 is trying to acquire lock:
(&(>tx_global_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x350/0x43c
but task is already holding lock:
(&(>tx_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x30/0x43c
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(>tx_lock)->rlock){+.-...}:
[] _raw_spin_lock+0x5c/0x94
[] stmmac_xmit+0x88/0x620
[] dev_hard_start_xmit+0x230/0x49c
[] sch_direct_xmit+0xdc/0x20c
[] __dev_queue_xmit+0x218/0x604
[] dev_queue_xmit+0x1c/0x20
[] neigh_resolve_output+0x180/0x254
[] ip6_finish_output2+0x188/0x8a4
[] ip6_output+0xc8/0x398
[] mld_sendpack+0x2e0/0x6d8
[] mld_ifc_timer_expire+0x1f0/0x308
[] call_timer_fn+0xb4/0x1f0
[] run_timer_softirq+0x224/0x2f0
[] __do_softirq+0x1d4/0x3e0
[] irq_exit+0x9c/0xd0
[] __handle_domain_irq+0x70/0xb4
[] gic_handle_irq+0x34/0x6c
[] __irq_svc+0x44/0x5c
[] lock_acquire+0xec/0x17c
[] lock_acquire+0xec/0x17c
[] _raw_spin_lock+0x5c/0x94
[] do_read_fault.isra.93+0xa8/0x2a0
[] handle_mm_fault+0x44c/0x8dc
[] do_page_fault+0x160/0x2d8
[] do_PrefetchAbort+0x44/0xa8
[] ret_from_exception+0x0/0x20
[] 0xb6eb0120
-> #1 (_xmit_ETHER#2){+.-...}:
[] _raw_spin_lock+0x5c/0x94
[] dev_deactivate_many+0xd0/0x250
[] dev_deactivate+0x3c/0x4c
[] linkwatch_do_dev+0x50/0x84
[] __linkwatch_run_queue+0xdc/0x148
[] linkwatch_event+0x3c/0x44
[] process_one_work+0x1ec/0x510
[] worker_thread+0x5c/0x4d8
[] kthread+0xe8/0xfc
[] ret_from_fork+0x14/0x20
-> #0 (&(>tx_global_lock)->rlock){+.-...}:
[] lock_acquire+0xdc/0x17c
[] _raw_spin_lock+0x5c/0x94
[] stmmac_tx_clean+0x350/0x43c
[] stmmac_poll+0x3c/0x618
[] net_rx_action+0x178/0x28c
[] __do_softirq+0x1d4/0x3e0
[] irq_exit+0x9c/0xd0
[] __handle_domain_irq+0x70/0xb4
[] gic_handle_irq+0x34/0x6c
[] __irq_svc+0x44/0x5c
[] __local_bh_enable_ip+0x9c/0xfc
[] __local_bh_enable_ip+0x9c/0xfc
[] _raw_read_unlock_bh+0x40/0x44
[] inet6_dump_addr+0x33c/0x530
[] inet6_dump_ifaddr+0x1c/0x20
[] rtnl_dump_all+0x50/0xf4
[] netlink_dump+0xc0/0x250
[] netlink_recvmsg+0x234/0x300
[] sock_recvmsg+0xa4/0xc8
[] ___sys_recvmsg.part.33+0xe4/0x1c0
[] __sys_recvmsg+0x60/0x90
[] SyS_recvmsg+0x18/0x1c
[] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Chain exists of:
&(>tx_global_lock)->rlock --> _xmit_ETHER#2 -->
&(>tx_lock)->rlock
Possible unsafe locking scenario:
CPU0CPU1
lock(&(>tx_lock)->rlock);
lock(_xmit_ETHER#2);
lock(&(>tx_lock)->rlock);
lock(&(>tx_global_lock)->rlock);
*** DEADLOCK ***
3 locks held by iperf/141:
#0: (rtnl_mutex){+.+.+.}, at: [] netlink_dump+0x28/0x250
#1: (rcu_read_lock){..}, at: [] inet6_dump_addr+0x0/0x530
#2: (&(>tx_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x30/0x43c
stack backtrace:
CPU: 0 PID: 141 Comm: iperf Not tainted 3.18.0-rc3-3-g7180edf #916
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x9c/0xbc)
[] (dump_stack) from [] (print_circular_bug+0x21c/0x33c)
[] (print_circular_bug) from []
(__lock_acquire+0x2060/0x2148)
[] (__lock_acquire) from [] (lock_acquire+0xdc/0x17c)
[] (lock_acquire) from [] (_raw_spin_lock+0x5c/0x94)
[] (_raw_spin_lock) from []
(stmmac_tx_clean+0x350/0x43c)
[] (stmmac_tx_clean) from [] (stmmac_poll+0x3c/0x618)
[] (stmmac_poll) from [] (net_rx_action+0x178/0x28c)
[] (net_rx_action) from [] (__do_softirq+0x1d4/0x3e0)
[] (__do_softirq) from [] (irq_exit+0x9c/0xd0)
[] (irq_exit) from [] (__handle_domain_irq+0x70/0xb4)
[] (__handle_domain_irq) from []
(gic_handle_irq+0x34/0x6c)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c)
Exception stack(0xcabc1be0 to 0xcabc1c28)
1be0: 0001 2df53000 caf15e80 cabc 0201 ca9a9840
c03ad050
1c00: ca8d9404 ca9b4f50 cabc1c44 c08732d0 cabc1c28 c005d5d0
c002435c
1c20: 2013
[] (__irq_svc) from [] (__local_bh_enable_ip+0x9c/0xfc)
[] (__local_bh_enable_ip) from []
(_raw_read_unlock_bh+0x40/0x44)
[] (_raw_read_unlock_bh) from []
Re: [PATCH 2/8] perf tools: Add gzip decompression support for kernel module
On Mon, Nov 3, 2014 at 10:54 PM, Jiri Olsa wrote: > On Mon, Nov 03, 2014 at 04:27:52PM +0900, Namhyung Kim wrote: > > SNIP > >> # >> # Overhead Command Shared ObjectSymbol >> # ... ... >> .. >> # >> >>0.04% kworker/u16:3[ext4] [k] >> ext4_read_block_bitmap >>0.03% kworker/u16:0[mac80211] [k] >> ieee80211_sta_reset_beacon_monitor >>0.02% irq/50-iwlwifi [mac80211] [k] >> ieee80211_get_bssid >>0.02% firefox [e1000e] [k] >> __ew32_prepare >>0.02% swapper [libahci][k] >> ahci_handle_port_interrupt >>0.02% emacslibglib-2.0.so.0.4000.0 [.] >> g_mutex_unlock >>0.02% swapper [e1000e] [k] >> e1000_clean_tx_irq >>0.02% dwm [kernel.kallsyms][k] __schedule >>0.02% gnome-terminal- [vdso] [.] >> __vdso_clock_gettime >>0.02% swapper [e1000e] [k] >> e1000_alloc_rx_buffers >>0.02% irq/50-iwlwifi [mac80211] [k] ieee80211_rx >>0.01% firefox [vdso] [.] >> __vdso_gettimeofday >>0.01% irq/50-iwlwifi [iwlwifi][k] >> iwl_pcie_rxq_restock.part.13 >> >> Signed-off-by: Namhyung Kim >> --- >> tools/perf/Makefile.perf | 7 +++ >> tools/perf/config/Makefile | 15 +- >> tools/perf/config/feature-checks/Makefile| 6 ++- >> tools/perf/config/feature-checks/test-zlib.c | 9 > > missing update for feature-checks/test-all.c Ah, right. Will add. :) Thanks, Namhyung -- 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/8] perf tools: Preparation for compressed kernel module support
Hi Jiri,
On Mon, Nov 3, 2014 at 10:51 PM, Jiri Olsa wrote:
> On Mon, Nov 03, 2014 at 04:27:51PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>> +static int decompress_dummy(const char *input __maybe_unused,
>> + int output __maybe_unused)
>> +{
>> + return -1;
>> +}
>> +
>> +static const struct {
>> + const char *fmt;
>> + int (*decompress)(const char *input, int output);
>> +} compressions[] = {
>> + { "gz", decompress_dummy },
>> +};
>> +
>> +bool is_supported_compression(const char *ext)
>> +{
>> + unsigned i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(compressions); i++) {
>> + if (!strcmp(ext, compressions[i].fmt))
>> + return true;
>> + }
>> + return false;
>> +}
>> +
>> +bool is_kmodule_extension(const char *ext)
>> +{
>> + if (!strcmp(ext, "ko"))
>> + return true;
>> +
>> + if (ext[2] == '\0' || (ext[2] == '.' &&
>> is_supported_compression(ext+3)))
>> + return true;
>
> I got stuck in here.. so any 2 chars string is kernel module extension?
Oops, the first check should be:
if (strncmp(ext, "ko", 2))
return false;
> plus how do u know ext[3] (or [2]) is valid memory?
Hmm.. if it ends at ext[0] or ext[1], it should be checked in the
first check above. And I check ext[2] first, and then access ext[3]
and so on.
Thanks,
Namhyung
--
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] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote: > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote: > > > I think adding the module exit + allowing this driver to be a module > > > would be a good approach. Then we don't need to force generic x86 kernel > > > binaries to always have this driver. Unless Mathias or Mika knows a > > > constraint to force this driver to be builtin only. > > > > It helps if I CC them when asking for feedback :) > > > > Mathias, Mika, do you know any constraint that forces pinctrl-baytrail > > to be bool? > > The only constraint that has been keeping this driver as bool is that > some machines like, Asus T100, uses ACPI GPIO operation regions for > toggling GPIOs to get things like sensor hub powered on. The GPIO > operation region code does not yet handle -EPROBE_DEFER so only way to > ensure that the operation region is there is to have the driver compiled > in to the kernel. But that's not enough excuse to have every single x86 in the market shipping with this driver. Think about a distro kernel, most likely this gets enabled and it's wrong in 80% of the cases. It would be nicer to add EPROBE_DEFER support, convert this into tristate and have default = M if BAYTRAIL, or something. -- balbi signature.asc Description: Digital signature
Re: [PATCH] mfd: tc6393xb fail ohci suspend if full state restore is required
On Fri, 24 Oct 2014, Dmitry Eremin-Solenikov wrote:
> Some boards with TC6393XB chip require full state restore during system
> resume thanks to chip's VCC being cut off during suspend (Sharp SL-6000
> tosa is one of them). Failing to do so would result in ohci Oops on
> resume due to internal memory contentes being changed. Fail ohci suspend
> on tc6393xb is full state restore is required.
>
> Recommended workaround is to unbind tmio-ohci driver before suspend and
> rebind it after resume.
>
> Signed-off-by: Dmitry Eremin-Solenikov
> Cc: sta...@vger.kernel.org
> ---
> drivers/mfd/tc6393xb.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
> index 11c19e5..48579e5 100644
> --- a/drivers/mfd/tc6393xb.c
> +++ b/drivers/mfd/tc6393xb.c
> @@ -263,6 +263,17 @@ static int tc6393xb_ohci_disable(struct platform_device
> *dev)
> return 0;
> }
>
> +static int tc6393xb_ohci_suspend(struct platform_device *dev)
> +{
> + struct tc6393xb_platform_data *tcpd = dev_get_platdata(dev->dev.parent);
> +
> + /* We can't properly store/restore OHCI state, so fail here */
> + if (tcpd->resume_restore)
> + return -EBUSY;
Wouldn't it be easier to just put these three lines into
tc6393xb_ohci_disable() instead off adding 7 superfluous lines and
making the Ops names inconsistent?
> + return tc6393xb_ohci_disable(dev);
> +}
> +
> static int tc6393xb_fb_enable(struct platform_device *dev)
> {
> struct tc6393xb *tc6393xb = dev_get_drvdata(dev->dev.parent);
> @@ -403,7 +414,7 @@ static struct mfd_cell tc6393xb_cells[] = {
> .num_resources = ARRAY_SIZE(tc6393xb_ohci_resources),
> .resources = tc6393xb_ohci_resources,
> .enable = tc6393xb_ohci_enable,
> - .suspend = tc6393xb_ohci_disable,
> + .suspend = tc6393xb_ohci_suspend,
> .resume = tc6393xb_ohci_enable,
> .disable = tc6393xb_ohci_disable,
> },
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] perf tools: perf diff for different binaries
> > @@ -1164,6 +1164,9 @@ int cmd_diff(int argc, const char **argv, const > char *prefix __maybe_unused) > > if (setup_sorting() < 0) > > usage_with_options(diff_usage, options); > > > > + if (sort__has_sym_name) > > + tool.mmap2 = perf_event__process_mmap2; > > why is the mmap2 callback set only for sort__has_sym_name? > Shouldn't we use/define it directly in the tool's definition? > If we define it in tools definition, perf diff will display the differential profile between functions (Not previous userspace IPs). For same binary, IPs are same. So I think it's better to compare between IPs. For different binaries, IPs change. But most of the function names are same for most binary update case. So we'd better compare between functions. I want to keep both IP and function compare. So only new sort key "symble_name" set mmap2 which implies function compare. If we only need to compare between IPs, we don't need to set mmap2. Thanks, Kan > jirka -- 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: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Mon, Nov 03, 2014 at 02:57:31AM -0800, tip-bot for Jiang Liu wrote:
> Commit-ID: e22ce93870deae0e9a54e1539f0088538f187780
> Gitweb: http://git.kernel.org/tip/e22ce93870deae0e9a54e1539f0088538f187780
> Author: Jiang Liu
> AuthorDate: Mon, 27 Oct 2014 13:21:34 +0800
> Committer: Thomas Gleixner
> CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
>
> x86, PCI, ACPI: Kill private function resource_to_addr() in
> arch/x86/pci/acpi.c
>
> Private function resource_to_addr() is used to parse ACPI resources
> for PCI host bridge. There are public interfaces available for that
> purpose, so replace resource_to_addr() with public interfaces.
>
> Signed-off-by: Jiang Liu
> Reviewed-by: Bjorn Helgaas
> Cc: Konrad Rzeszutek Wilk
> Cc: Tony Luck
> Cc: Joerg Roedel
> Cc: Greg Kroah-Hartman
> Cc: Benjamin Herrenschmidt
> Cc: Rafael J. Wysocki
> Cc: Randy Dunlap
> Cc: Yinghai Lu
> Cc: Borislav Petkov
> Link:
> http://lkml.kernel.org/r/1414387308-27148-5-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner
> ---
...
> static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data)
> {
> struct pci_root_info *info = data;
> - struct resource *res;
> - struct acpi_resource_address64 addr;
> - acpi_status status;
> - unsigned long flags;
> - u64 start, orig_end, end;
> + u64 translation_offset = 0;
> + struct resource r = {
> + .flags = 0
> + };
> +
> + if (acpi_dev_resource_memory(acpi_res, )) {
> + r.flags &= IORESOURCE_MEM | IORESOURCE_IO;
> + } else if (acpi_dev_resource_address_space(acpi_res, )) {
> + u64 orig_end;
> + struct acpi_resource_address64 addr;
> +
> + r.flags &= IORESOURCE_MEM | IORESOURCE_IO;
> + if (r.flags == 0)
> + return AE_OK;
>
> - status = resource_to_addr(acpi_res, );
> - if (!ACPI_SUCCESS(status))
> - return AE_OK;
> + if (ACPI_FAILURE(acpi_resource_to_address64(acpi_res, )))
> + return AE_OK;
>
> - if (addr.resource_type == ACPI_MEMORY_RANGE) {
> - flags = IORESOURCE_MEM;
> - if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> - flags |= IORESOURCE_PREFETCH;
> - } else if (addr.resource_type == ACPI_IO_RANGE) {
> - flags = IORESOURCE_IO;
> - } else
> - return AE_OK;
> + if (addr.resource_type == ACPI_MEMORY_RANGE &&
> + addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> + r.flags |= IORESOURCE_PREFETCH;
>
> - start = addr.minimum + addr.translation_offset;
> - orig_end = end = addr.maximum + addr.translation_offset;
> + translation_offset = addr.translation_offset;
> + orig_end = r.end;
> + r.start += translation_offset;
> + r.end += translation_offset;
>
> - /* Exclude non-addressable range or non-addressable portion of range */
> - end = min(end, (u64)iomem_resource.end);
> - if (end <= start) {
> - dev_info(>bridge->dev,
> - "host bridge window [%#llx-%#llx] "
> - "(ignored, not CPU addressable)\n", start, orig_end);
> - return AE_OK;
> - } else if (orig_end != end) {
> - dev_info(>bridge->dev,
> - "host bridge window [%#llx-%#llx] "
> - "([%#llx-%#llx] ignored, not CPU addressable)\n",
> - start, orig_end, end + 1, orig_end);
> + /* Exclude non-addressable range or non-addressable portion of
> range */
> + r.end = min(r.end, iomem_resource.end);
> + if (r.end <= r.start) {
> + dev_info(>bridge->dev,
> + "host bridge window [%#llx-%#llx] (ignored, not
> CPU addressable)\n",
> + r.start, orig_end);
> + return AE_OK;
> + } else if (orig_end != r.end) {
> + dev_info(>bridge->dev,
> + "host bridge window [%#llx-%#llx]
> ([%#llx-%#llx] ignored, not CPU addressable)\n",
> + r.start, orig_end, r.end + 1, orig_end);
> + }
I see the warnings below on 32-bit, those resource_size_t things on
32-bit are u32 through the phys_addr_t typedef:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
typedef phys_addr_t resource_size_t;
---
arch/x86/pci/acpi.c: In function ‘setup_resource’:
arch/x86/pci/acpi.c:271:4: warning: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 3 has type ‘resource_size_t’ [-Wformat=]
dev_info(>bridge->dev,
^
arch/x86/pci/acpi.c:276:4: warning: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 3 has type ‘resource_size_t’ [-Wformat=]
[PATCH v4 01/14] regulator: Document binding for initial and suspend modes
Some regulators can run on different operating modes (opmodes). This allows systems to choose the most efficient opmode for each regulator. This patch builds on top of (291d761 regulator: Document binding for regulator suspend state for PM state) adding a regulator-initial-mode DT property to configure at startup the operating mode for regulators that support changing its mode during normal operation and a property regulator-mode to be used in the regulator-state-[mem/disk] nodes for regulators that supports changing its operating mode when the system enters in a suspend state. The set of possible modes that a regulator can operate depends on the hardware capabilities so a list of generic operating modes can't be provided. Instead, each hardware binding should define the list of valid operating modes for the regulators found on that device. Signed-off-by: Javier Martinez Canillas --- Changes in v3: - Rebased on top of regulator suspend voltage series Documentation/devicetree/bindings/regulator/regulator.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 4e7ed76..3fffa3b 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -30,6 +30,20 @@ Optional properties: - regulator-off-in-suspend: regulator should be off in suspend state. - regulator-suspend-microvolt: regulator should be set to this voltage in suspend. + - regulator-mode: operating mode in the given suspend state. + The set of possible operating modes depends on the capabilities of + every hardware so the valid modes are documented on each regulator + device tree binding document. + The "regulator-mode" property only takes effect if the regulator is + enabled for the given suspend state using "regulator-on-in-suspend". + If the regulator has not been explicitly disabled for the given state + with "regulator-off-in-suspend", then setting the operating mode + will also have no effect. +- regulator-initial-mode: initial operating mode. The set of possible operating + modes is the same used for the regulator-mode property and the device binding + documentation explains which property each regulator supports. +If no mode is defined, then the OS will not manage the modes and the hardware +default values will be used instead. Deprecated properties: - regulator-compatible: If a regulator chip contains multiple -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 04/14] regulator: of: Pass the regulator description in the match table
Drivers can use the of_regulator_match() function to parse the regulator
init_data from DT. A match table is used to specify the name of the node
containing the regulators, the device node and to return the init_data
to the caller.
But also the static regulator descriptor is needed to correctly extract
some DT properties like the regulator initial and suspend modes. Use the
match table to pass that information.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/of_regulator.c | 3 ++-
include/linux/regulator/of_regulator.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 945486f..cbc1d71 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -221,7 +221,8 @@ int of_regulator_match(struct device *dev, struct
device_node *node,
continue;
match->init_data =
- of_get_regulator_init_data(dev, child, NULL);
+ of_get_regulator_init_data(dev, child,
+ match->desc);
if (!match->init_data) {
dev_err(dev,
"failed to parse DT for regulator %s\n",
diff --git a/include/linux/regulator/of_regulator.h
b/include/linux/regulator/of_regulator.h
index 3bbfb1b..ce0877d 100644
--- a/include/linux/regulator/of_regulator.h
+++ b/include/linux/regulator/of_regulator.h
@@ -13,6 +13,7 @@ struct of_regulator_match {
void *driver_data;
struct regulator_init_data *init_data;
struct device_node *of_node;
+ const struct regulator_desc *desc;
};
#if defined(CONFIG_OF)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler: Correct macro parameter expansion problem
On Mon, Nov 03, 2014 at 06:34:13AM -0800, Jeff Kirsher wrote:
> From: Mark Rustad
>
> The macro __compiletime_error_fallback has an error in that it
> lacks parens around the expansion of an expression. It also
> lacks a conversion to a boolean value. The first problem can
> result in a mis-evaluation. The second problem can also result
> in an error if the value comes out negative. That would thwart
> the intended error generation. That is, the error being asserted
> would not in fact generate an error. Fix both problems by adding
> !!() to the expansion.
>
> Signed-off-by: Mark Rustad
> Tested-by: Aaron Brown
> Signed-off-by: Jeff Kirsher
Good catch.
Reviewed-by: Josh Triplett
> include/linux/compiler.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index d5ad7b1..59dc611 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -331,7 +331,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f,
> int val, int expect);
> */
> # ifndef __CHECKER__
> # define __compiletime_error_fallback(condition) \
> - do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
> + do { ((void)sizeof(char[1 - 2 * !!(condition)])); } while (0)
> # endif
> #endif
> #ifndef __compiletime_error_fallback
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] Add ltc3562 voltage regulator driver
On 11/03/2014 01:09 PM, Mark Brown wrote:
On Mon, Nov 03, 2014 at 09:10:08AM +0100, Mike Looijmans wrote:
On 10/30/2014 05:51 PM, Mark Brown wrote:
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I've been reworking the driver, but this is the only feedback comment I
didn't quite understand. What is it that I'm expected to do here? Probably
just the name of the method I'm supposed to call here would be enough.
No function calls, just use regulators_node. What is unclear about the
functionality?
I don't understand what you mean by "regulators_node".
"grep -R regulators_node *" in the kernel source tree returns no results, nor
does http://lxr.free-electrons.com/ident?i=regulators_node
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
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 01/11] crypto: Documentation - crypto API high level spec
On Mon, Nov 03, 2014 at 03:18:29PM +0100, Stephan Mueller wrote: > > > > + * CRYPTO_ALG_TYPE_DIGESTRaw message digest > > > + * CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST > > > + * CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash > > > + * CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash > > > + * CRYPTO_ALG_TYPE_RNG Random Number Generation > > > + * CRYPTO_ALG_TYPE_PCOMPRESS > > > > What's that last one? > > Same here. pcompress is an enhanced version of compress allowing for piece-meal compression/decompression rather than having to shove everything in all at once. Eventually pcompress should replace the compress interface once everything is converted across. Thanks, -- 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 2/2] perf: Userspace software event and ioctl
On 29 September 2014 17:53, Pawel Moll wrote: > On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote: >> Also none of the many words above describe >> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about? > > Hopefully description of the v2 makes better job in this: > > http://thread.gmane.org/gmane.linux.kernel/1793272/focus=4813 > > where it's already called "UEVENT" and was generated by write(). > > Before you get into this, though, the most important outcomes of both v1 > and v2 discussions: > > * Ingo suggested prctl(PR_TRACE_UEVENT, type, size, data, 0) as the way > of generating such events (so the tracee doesn't have to know the fd to > do ioctl); Frederic seems to have the same on his mind. > > * Namhyung proposed sticking the userspace-originating events into the > buffer as PERF_RECORD_UEVENT rather then PERF_SAMPLE_UEVENT. > > Working on making both happen now. Hi Pawel, are you still working on this? Would be happy to lend a hand if that can speed things up. Cheers, Tomeu > Pawel > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] pin control fixes for v3.18
Hi Linus, this kernel cycle has been calm for both pin control and GPIO so far but here are three pin control patches for you anyway, only really dealing with Baytrail. Please pull them in! Yours, Linus Walleij The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v3.18-2 for you to fetch changes up to d90c33818967c5e5371961604ad98b4dea4fa3f4: pinctrl: baytrail: show output gpio state correctly on Intel Baytrail (2014-10-28 11:16:26 +0100) Pin control fixes for the v3.18 series: - Two fixes for the Baytrail driver affecting IRQs and output state in sysfs - Use the linux-gpio mailing list also for pinctrl patches David Cohen (2): pinctrl: use linux-gpio mailing list pinctrl: baytrail: show output gpio state correctly on Intel Baytrail Loic Poulain (1): pinctrl: baytrail: Clear DIRECT_IRQ bit MAINTAINERS| 1 + drivers/pinctrl/pinctrl-baytrail.c | 8 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stmmac: potential circular locking dependency
El 03/11/14 a las 11:39, Giuseppe CAVALLARO escibió: Hello Emilio I have a subset of new patches to review and fix locks in the driver. I will plan to send them in the next days. Great then :) Please Cc: me on the patches when you send them Cheers, Emilio -- 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 01/11] crypto: Documentation - crypto API high level spec
On Mon, Nov 03, 2014 at 03:18:29PM +0100, Stephan Mueller wrote: > > > > + * CRYPTO_ALG_TYPE_CIPHERRaw block cipher > > > + * CRYPTO_ALG_TYPE_COMPRESS Compression > > > + * CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with > Associated Data > > > (MAC) + * CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher > > > + * CRYPTO_ALG_TYPE_ABLKCIPHERAsynchronous multi-block cipher > > > + * CRYPTO_ALG_TYPE_GIVCIPHER > > > > What's this one? > > I would like to ask Herbert what that is -- I looked around in the code and I > am not sure what that flag shall indicate. givcipher is an ablkcipher packed together with an IV generator. 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/
[PATCH v4 12/14] regulator: max77802: Use unsigned int for modes in max77802_map_mode()
All function dealing with operating modes use unsigned int for modes
so change max77802_map_mode() function signature for consistency.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index d10c605..1d1f7b4 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -73,7 +73,7 @@ struct max77802_regulator_prv {
unsigned int opmode[MAX77802_REG_MAX];
};
-static inline int max77802_map_mode(int mode)
+static inline unsigned int max77802_map_mode(unsigned int mode)
{
return mode == MAX77802_OPMODE_NORMAL ?
REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 08/14] regulator: max8660: zero-initialize regulator match table array
The struct of_regulator_match rmatch[] is declared as a non-static local
variable so the structure members are not auto-initialized.
Initialize the array at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max8660.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index 2fc4111..7eee2ca 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -335,7 +335,7 @@ static int max8660_pdata_from_dt(struct device *dev,
int matched, i;
struct device_node *np;
struct max8660_subdev_data *sub;
- struct of_regulator_match rmatch[ARRAY_SIZE(max8660_reg)];
+ struct of_regulator_match rmatch[ARRAY_SIZE(max8660_reg)] = { };
np = of_get_child_by_name(dev->of_node, "regulators");
if (!np) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/14] regulator: max77802: zero-initialize regulator match table
The struct of_regulator_match is declared as a non-static local variable
so the structure members are not auto-initialized.
Initialize the struct at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index a0d1462..d10c605 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -520,7 +520,7 @@ static int max77802_pmic_dt_parse_pdata(struct
platform_device *pdev,
struct max77686_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct device_node *pmic_np, *regulators_np;
struct max77686_regulator_data *rdata;
- struct of_regulator_match rmatch;
+ struct of_regulator_match rmatch = { };
unsigned int i;
pmic_np = iodev->dev->of_node;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 09/14] regulator: s2mpa01: zero-initialize regulator match table array
The struct of_regulator_match rmatch[] is declared as a non-static local
variable so the structure members are not auto-initialized.
Initialize the array at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/s2mpa01.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 2263071..5db4e12 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -341,7 +341,7 @@ static int s2mpa01_pmic_probe(struct platform_device *pdev)
{
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct sec_platform_data *pdata = dev_get_platdata(iodev->dev);
- struct of_regulator_match rdata[S2MPA01_REGULATOR_MAX];
+ struct of_regulator_match rdata[S2MPA01_REGULATOR_MAX] = { };
struct device_node *reg_np = NULL;
struct regulator_config config = { };
struct s2mpa01_info *s2mpa01;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 11/14] regulator: max77802: Document binding for regulator operating modes
Some regulators from the max77802 PMIC support to be configured in one
of two operating mode: Output ON (normal) and Output On Low Power Mode.
Not all regulators support these two modes and for some of them, the
mode can be changed while the system is running in normal operation
while others only support their mode to be changed on system suspend.
Extend the max77802 PMIC bindin by documenting the possible operating
modes values so the regulators modes can be correctly configured.
Signed-off-by: Javier Martinez Canillas
---
Changes in v4: None
Changes in v3:
- Use the standard suspend states bindings as suggested by Mark Brown.
.../devicetree/bindings/regulator/max77802.txt | 33 ++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt
b/Documentation/devicetree/bindings/regulator/max77802.txt
index 5aeaffc..1a78ec2 100644
--- a/Documentation/devicetree/bindings/regulator/max77802.txt
+++ b/Documentation/devicetree/bindings/regulator/max77802.txt
@@ -25,6 +25,27 @@ with their hardware counterparts as follow. The valid names
are:
example: LDO1, LDO2, LDO35.
-BUCKn : for BUCKs, where n can lie in range 1 to 10.
example: BUCK1, BUCK5, BUCK10.
+
+The max77802 regulator supports two different operating modes: Normal and Low
+Power Mode. Some regulators support the modes to be changed at startup or by
+the consumers during normal operation while others only support to change the
+mode during system suspend. The standard regulator suspend states binding can
+be used to configure the regulator operating mode.
+
+The regulators that support the standard "regulator-initial-mode" property,
+changing their mode during normal operation are: LDOs 1, 3, 20 and 21.
+
+The possible values for "regulator-initial-mode" and "regulator-mode" are:
+ 1: Normal regulator voltage output mode.
+ 3: Low Power which reduces the quiescent current down to only 1uA
+
+The list of valid modes are defined in the dt-bindings/regulator/regulator.h
+header and can be included by device tree source files.
+
+The standard "regulator-mode" property can only be used for regulators that
+support changing their mode to Low Power Mode during suspend. These regulators
+are: BUCKs 2-4 and LDOs 1-35.
+
Example:
max77802@09 {
@@ -36,11 +57,23 @@ Example:
#size-cells = <0>;
regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_1v0";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regulator-always-on;
+ regulator-initial-mode = ;
+ };
+
ldo11_reg: LDO11 {
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <190>;
regulator-max-microvolt = <190>;
regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = ;
+ };
};
buck1_reg: BUCK1 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 06/14] regulator: max77686: zero-initialize regulator match table
The struct of_regulator_match is declared as a non-static local variable
so the structure members are not auto-initialized.
Initialize the struct at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77686.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index 09b0d8c..281eb4b 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -434,7 +434,7 @@ static int max77686_pmic_dt_parse_pdata(struct
platform_device *pdev,
struct max77686_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct device_node *pmic_np, *regulators_np;
struct max77686_regulator_data *rdata;
- struct of_regulator_match rmatch;
+ struct of_regulator_match rmatch = { };
unsigned int i;
pmic_np = iodev->dev->of_node;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 14/14] ARM: dts: Configure regulators for suspend on exynos Peach boards
The regulator core now has support to choose if a regulator
has to be enabled or disabled during system suspend and also
the supports changing the regulator operating mode during
runtime and when the system enters into sleep mode.
To lower power during suspend, configure the regulators state
using the same configuration found in the ChromeOS 3.8 kernel.
Signed-off-by: Javier Martinez Canillas
---
Changes in v4: None
Changes in v3:
- Use the standard suspend state binding as suggested by Mark Brown.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 81 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 81 ++
2 files changed, 162 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a050e1..8b744c7 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "exynos5420.dtsi"
/ {
@@ -192,6 +193,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck2_reg: BUCK2 {
@@ -201,6 +205,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck3_reg: BUCK3 {
@@ -210,6 +217,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck4_reg: BUCK4 {
@@ -219,6 +229,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck5_reg: BUCK5 {
@@ -227,6 +240,9 @@
regulator-max-microvolt = <120>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck6_reg: BUCK6 {
@@ -236,6 +252,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck7_reg: BUCK7 {
@@ -244,6 +263,9 @@
regulator-max-microvolt = <135>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
buck8_reg: BUCK8 {
@@ -252,6 +274,9 @@
regulator-max-microvolt = <285>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck9_reg: BUCK9 {
@@ -260,6 +285,9 @@
regulator-max-microvolt = <200>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
buck10_reg: BUCK10 {
@@ -268,6 +296,9 @@
regulator-max-microvolt = <180>;
regulator-always-on;
regulator-boot-on;
+
Re: [PATCH] ARM: dts: dra7-evm: Keep all VDD rails always-on
Hi Nishant, On 10/21/2014 05:38 PM, Nishanth Menon wrote: > DRA7 Data Manual (SPRS857L - August 2014) section 4.1.1 states: "All > unused power supply balls must be supplied with the voltages specified > in the Section 5.2, Recommended Operating Conditions". > > This implies that all unused voltage rails for Vayu can never be > switched off even if the hardware blocks inside that voltage domain is > unused. Switching off these unused rails may result in stability issues > on other domains and increased leakage and power-on-hour impacts. > > J6eco-evm dts file already considers this, however j6evm-dts file needs > to be fixed to consider this constraint of the SoC. > > Signed-off-by: Nishanth Menon Acked-by: Roger Quadros I'm assuming that vddshv8 (MMC1 power group) can be switched off. cheers, -roger > --- > > Patch is based on v3.18-rc1 tag. > > arch/arm/boot/dts/dra7-evm.dts |5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts > index c6ce625..4f4c469 100644 > --- a/arch/arm/boot/dts/dra7-evm.dts > +++ b/arch/arm/boot/dts/dra7-evm.dts > @@ -201,6 +201,7 @@ > regulator-name = "smps45"; > regulator-min-microvolt = < 85>; > regulator-max-microvolt = <115>; > + regulator-always-on; > regulator-boot-on; > }; > > @@ -209,6 +210,7 @@ > regulator-name = "smps6"; > regulator-min-microvolt = <85>; > regulator-max-microvolt = <1250>; > + regulator-always-on; > regulator-boot-on; > }; > > @@ -226,6 +228,7 @@ > regulator-name = "smps8"; > regulator-min-microvolt = < 85>; > regulator-max-microvolt = <125>; > + regulator-always-on; > regulator-boot-on; > }; > > @@ -252,6 +255,7 @@ > regulator-name = "ldo2"; > regulator-min-microvolt = <330>; > regulator-max-microvolt = <330>; > + regulator-always-on; > regulator-boot-on; > }; > > @@ -269,6 +273,7 @@ > regulator-name = "ldo9"; > regulator-min-microvolt = <105>; > regulator-max-microvolt = <105>; > + regulator-always-on; > regulator-boot-on; > }; > > -- 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 03/14] regulator: of: Add regulator desc param to of_get_regulator_init_data()
The of_get_regulator_init_data() function is used to extract the regulator
init_data but information on how to extract certain data is defined in the
static regulator descriptor (e.g: how to map the hardware operating modes).
Add a const struct regulator_desc * parameter to the function signature so
the parsing logic could use the information in the struct regulator_desc.
of_get_regulator_init_data() relies on of_get_regulation_constraints() to
actually extract the init_data so it has to pass the struct regulator_desc
but that is changed in a following patch.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/88pm8607.c | 3 ++-
drivers/regulator/anatop-regulator.c | 2 +-
drivers/regulator/arizona-ldo1.c | 3 ++-
drivers/regulator/arizona-micsupp.c| 2 +-
drivers/regulator/da9052-regulator.c | 2 +-
drivers/regulator/da9210-regulator.c | 2 +-
drivers/regulator/fan53555.c | 2 +-
drivers/regulator/fixed.c | 2 +-
drivers/regulator/gpio-regulator.c | 2 +-
drivers/regulator/max8952.c| 2 +-
drivers/regulator/max8973-regulator.c | 3 ++-
drivers/regulator/max8997.c| 2 +-
drivers/regulator/max8998.c| 4 ++--
drivers/regulator/mc13xxx-regulator-core.c | 3 ++-
drivers/regulator/of_regulator.c | 9 ++---
drivers/regulator/pwm-regulator.c | 2 +-
drivers/regulator/qcom_rpm-regulator.c | 3 ++-
drivers/regulator/s5m8767.c| 2 +-
drivers/regulator/sky81452-regulator.c | 2 +-
drivers/regulator/stw481x-vmmc.c | 2 +-
drivers/regulator/ti-abb-regulator.c | 2 +-
drivers/regulator/tps51632-regulator.c | 3 ++-
drivers/regulator/tps62360-regulator.c | 3 ++-
drivers/regulator/tps65218-regulator.c | 3 ++-
drivers/regulator/twl-regulator.c | 2 +-
drivers/regulator/vexpress.c | 3 ++-
include/linux/regulator/of_regulator.h | 8 ++--
27 files changed, 47 insertions(+), 31 deletions(-)
diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index 6d77dcd..ce0343a 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -330,7 +330,8 @@ static int pm8607_regulator_dt_init(struct platform_device
*pdev,
for_each_child_of_node(nproot, np) {
if (!of_node_cmp(np->name, info->desc.name)) {
config->init_data =
- of_get_regulator_init_data(>dev, np);
+ of_get_regulator_init_data(>dev, np,
+ NULL);
config->of_node = np;
break;
}
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index 542d14e..5cdce49 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -189,7 +189,7 @@ static int anatop_regulator_probe(struct platform_device
*pdev)
int ret = 0;
u32 val;
- initdata = of_get_regulator_init_data(dev, np);
+ initdata = of_get_regulator_init_data(dev, np, NULL);
sreg = devm_kzalloc(dev, sizeof(*sreg), GFP_KERNEL);
if (!sreg)
return -ENOMEM;
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index 4c9db58..fb393c5 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -194,7 +194,8 @@ static int arizona_ldo1_of_get_pdata(struct arizona
*arizona,
if (init_node) {
config->of_node = init_node;
- init_data = of_get_regulator_init_data(arizona->dev, init_node);
+ init_data = of_get_regulator_init_data(arizona->dev, init_node,
+ NULL);
if (init_data) {
init_data->consumer_supplies = >supply;
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index ce9aca5..71290bf 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -210,7 +210,7 @@ static int arizona_micsupp_of_get_pdata(struct arizona
*arizona,
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(arizona->dev, np);
+ init_data = of_get_regulator_init_data(arizona->dev, np, NULL);
if (init_data) {
init_data->consumer_supplies = >supply;
diff --git a/drivers/regulator/da9052-regulator.c
b/drivers/regulator/da9052-regulator.c
index 0003362..178343c 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -436,7 +436,7 @@ static int da9052_regulator_probe(struct platform_device
*pdev)
if (!of_node_cmp(np->name,
[PATCH v4 02/14] regulator: Add function to map modes to struct regulator_desc
The regulator-initial-mode and regulator-mode DT properties allows to
configure the regulator operating modes at startup or when a system
enters into a susend state.
But these properties use as valid values the operating modes supported
by each device while the core deals with the standard operating modes.
So a mapping function is needed to translate from the hardware specific
modes to the standard ones.
This mapping is a non-varying configuration for each regulator, so add
a function pointer to struct regulator_desc that will allow drivers to
define their callback to do the modes translation.
Signed-off-by: Javier Martinez Canillas
---
include/linux/regulator/driver.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 28da08e..b54d037 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -243,6 +243,8 @@ enum regulator_type {
*
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
+ *
+ * @map_modes: Callback invoked to translate between hardware to standard
modes.
*/
struct regulator_desc {
const char *name;
@@ -285,6 +287,8 @@ struct regulator_desc {
unsigned int enable_time;
unsigned int off_on_delay;
+
+ unsigned int (*map_modes)(unsigned int mode);
};
/**
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 05/14] regulator: max1586: zero-initialize regulator match table array
The struct of_regulator_match rmatch[] is declared as a non-static local
variable so the structure members are not auto-initialized.
Initialize the array at declaration time to avoid the structure members
values to be indeterminate and have sane defaults instead.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max1586.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 86db310..d2a8c64 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -163,7 +163,7 @@ static int of_get_max1586_platform_data(struct device *dev,
struct max1586_platform_data *pdata)
{
struct max1586_subdev_data *sub;
- struct of_regulator_match rmatch[ARRAY_SIZE(max1586_reg)];
+ struct of_regulator_match rmatch[ARRAY_SIZE(max1586_reg)] = { };
struct device_node *np = dev->of_node;
int i, matched;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hwmon: (pwm-fan) Fix suspend/resume behavior
The state of a PWM output is not clearly defined after resume. Some PWM
drivers do not restore the duty cycle upon resume, thus it is necessary to
manually restore the correct value.
Signed-off-by: Kamil Debski
---
drivers/hwmon/pwm-fan.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 823c877..1991d903 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -161,10 +161,17 @@ static int pwm_fan_suspend(struct device *dev)
static int pwm_fan_resume(struct device *dev)
{
struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long duty;
+ int ret;
- if (ctx->pwm_value)
- return pwm_enable(ctx->pwm);
- return 0;
+ if (ctx->pwm_value == 0)
+ return 0;
+
+ duty = DIV_ROUND_UP(ctx->pwm_value * (ctx->pwm->period - 1), MAX_PWM);
+ ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+ if (ret)
+ return ret;
+ return pwm_enable(ctx->pwm);
}
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: Add pwm-fan node to the Odroid-U3 board
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan.
Signed-off-by: Kamil Debski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index c8a64be..764bda4 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,19 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm: pwm@139D {
+ pinctrl-0 = <_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
+ };
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ status = "okay";
+ pwms = < 0 1 0>;
+ };
};
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 10/14] regulator: of: Add support for parsing initial and suspend modes
Some regulators support their operating mode to be changed on startup
or by consumers when the system is running while others only support
their operating mode to be changed while the system has entered in a
suspend state.
The regulator Device Tree binding documents a set of properties to
configure the regulators operating modes from a FDT. This patch builds
on (40e20d6 regulator: of: Add support for parsing regulator_state for
suspend state) and adds support to parse those properties and fill the
regulator constraints so the regulator core can call the right suspend
handlers when the system enters into sleep.
The modes are defined in the Device Tree using the hardware specific
modes supported by the regulators. Regulator drivers have to define a
translation function that is used to map the hardware specific modes
to the standard ones.
Signed-off-by: Javier Martinez Canillas
---
Changes in v4:
- Parse the properties in the core and map using driver provided functions.
Suggested by Mark Brown
Changes in v3:
- Use the standard suspend states binding instead of custom properties.
Suggested by Mark Brown
drivers/regulator/of_regulator.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index cbc1d71..cd65885 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -25,7 +25,8 @@ static const char *const regulator_states[PM_SUSPEND_MAX + 1]
= {
};
static void of_get_regulation_constraints(struct device_node *np,
- struct regulator_init_data **init_data)
+ struct regulator_init_data **init_data,
+ const struct regulator_desc *desc)
{
const __be32 *min_uV, *max_uV;
struct regulation_constraints *constraints = &(*init_data)->constraints;
@@ -81,6 +82,14 @@ static void of_get_regulation_constraints(struct device_node
*np,
if (!ret)
constraints->enable_time = pval;
+ if (!of_property_read_u32(np, "regulator-initial-mode", )) {
+ if (desc && desc->map_modes)
+ constraints->initial_mode = desc->map_modes(pval);
+ else
+ pr_warn("%s: failed to parse regulator-initial-mode\n",
+ np->name);
+ }
+
for (i = 0; i < ARRAY_SIZE(regulator_states); i++) {
switch (i) {
case PM_SUSPEND_MEM:
@@ -100,6 +109,15 @@ static void of_get_regulation_constraints(struct
device_node *np,
if (!suspend_np || !suspend_state)
continue;
+ if (!of_property_read_u32(suspend_np, "regulator-mode",
+ )) {
+ if (desc && desc->map_modes)
+ suspend_state->mode = desc->map_modes(pval);
+ else
+ pr_warn("%s: failed to parse regulator-mode\n",
+ np->name);
+ }
+
if (of_property_read_bool(suspend_np,
"regulator-on-in-suspend"))
suspend_state->enabled = true;
@@ -140,7 +158,7 @@ struct regulator_init_data
*of_get_regulator_init_data(struct device *dev,
if (!init_data)
return NULL; /* Out of memory? */
- of_get_regulation_constraints(node, _data);
+ of_get_regulation_constraints(node, _data, desc);
return init_data;
}
EXPORT_SYMBOL_GPL(of_get_regulator_init_data);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 13/14] regulator: max77802: Set regulator modes translation callback
The max77802 PMIC regulators output can be configured in one of two
modes: Output ON (normal) and Output ON in Low Power Mode. Some of
the regulators support their operating mode to be changed on startup
or by consumers when the system is running while others only support
their operating mode to be changed while the system has entered in a
suspend state.
Use the max77802_map_mode() function to translate the device specific
modes to the standard operating modes as used by the regulator core.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 1d1f7b4..09276c2 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -375,6 +375,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask = MAX77802_VSEL_MASK, \
.enable_reg = MAX77802_REG_LDO1CTRL1 + num - 1, \
.enable_mask= MAX77802_OPMODE_MASK << MAX77802_OPMODE_SHIFT_LDO, \
+ .map_modes = max77802_map_mode,\
}
/* LDOs 1, 2, 8, 15, 17, 27, 30, 35 */
@@ -393,6 +394,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask = MAX77802_VSEL_MASK, \
.enable_reg = MAX77802_REG_LDO1CTRL1 + num - 1, \
.enable_mask= MAX77802_OPMODE_MASK << MAX77802_OPMODE_SHIFT_LDO, \
+ .map_modes = max77802_map_mode,\
}
/* BUCKs 1, 6 */
@@ -411,6 +413,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask = MAX77802_DVS_VSEL_MASK, \
.enable_reg = MAX77802_REG_BUCK ## num ## CTRL, \
.enable_mask= MAX77802_OPMODE_MASK, \
+ .map_modes = max77802_map_mode,\
}
/* BUCKS 2-4 */
@@ -430,6 +433,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.enable_reg = MAX77802_REG_BUCK ## num ## CTRL1,\
.enable_mask= MAX77802_OPMODE_MASK << \
MAX77802_OPMODE_BUCK234_SHIFT, \
+ .map_modes = max77802_map_mode,\
}
/* BUCK 5 */
@@ -448,6 +452,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask = MAX77802_VSEL_MASK, \
.enable_reg = MAX77802_REG_BUCK5CTRL, \
.enable_mask= MAX77802_OPMODE_MASK, \
+ .map_modes = max77802_map_mode,\
}
/* BUCKs 7-10 */
@@ -466,6 +471,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.vsel_mask = MAX77802_VSEL_MASK, \
.enable_reg = MAX77802_REG_BUCK7CTRL + (num - 7) * 3, \
.enable_mask= MAX77802_OPMODE_MASK, \
+ .map_modes = max77802_map_mode,\
}
static const struct regulator_desc regulators[] = {
@@ -540,6 +546,7 @@ static int max77802_pmic_dt_parse_pdata(struct
platform_device *pdev,
for (i = 0; i < pdata->num_regulators; i++) {
rmatch.name = regulators[i].name;
+ rmatch.desc = [i];
rmatch.init_data = NULL;
rmatch.of_node = NULL;
if (of_regulator_match(>dev, regulators_np, ,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/14] Add max77802 regulator operating mode support
Hello Mark, This is the fourth version of the series that adds operating modes support for the regulators in the max77802 PMIC. This version uses the standard suspend states bindings and the opmodes are parsed by the regulator core while drivers only define a translation function to map between hardware specific to standard modes as you suggested. The series adds a "regulator-initial-mode" property to configure at startup the operating mode for the regulators that support changing its mode during normal operation and a "regulator-mode" property for the regulators that supports changing its operating mode when the system enters in a suspend state. These properties were originally part of Chanwoo Choi's regulator suspend state series [0] but were removed since there wasn't a way to define the operating modes in a generic way. In this series, the generic regulator DT binding doc explains that each device has to document what their valid operating modes are. Drivers must provide a translation function so the core can map the modes. Since parsing the modes in the core is a very different approach, most of the patches are new but those that remains have a changelog. This series depend on [0] and also v2 of patch: "ARM: EXYNOS: Call regulator core suspend prepare and finish functions" [1]. Javier Martinez Canillas (14): regulator: Document binding for initial and suspend modes regulator: Add function to map modes to struct regulator_desc regulator: of: Add regulator desc param to of_get_regulator_init_data() regulator: of: Pass the regulator description in the match table regulator: max1586: zero-initialize regulator match table array regulator: max77686: zero-initialize regulator match table regulator: max77802: zero-initialize regulator match table regulator: max8660: zero-initialize regulator match table array regulator: s2mpa01: zero-initialize regulator match table array regulator: of: Add support for parsing initial and suspend modes regulator: max77802: Document binding for regulator operating modes regulator: max77802: Use unsigned int for modes in max77802_map_mode() regulator: max77802: Set regulator modes translation callback ARM: dts: Configure regulators for suspend on exynos Peach boards Patch #1 extends the regulator DT binding to document the initial and suspend modes properties. Patch #2 adds a function pointer to the static regulator description so drivers can define a callback that does the modes translation. Patch #3 does some refactoring to pass the regulator descriptor to the function extracting the regulator initial data from DT. Patch #4 adds a pointer to the regulator descriptor in the match table so users extracting the init_data from of_regulator_match can also map the modes. Patch #5-#9 are fixes to be sure that all callers are passing an initialised match table. Patch #10 modifies the function that extracts the regulator data from DT to parse the initial and suspend modes. Patch #11 extends the max77802 DT binding to document the valid opmodes for the regulators on this device. Patch #12 change the signature of the function doing the modes mapping for the max77802 regulators mode. Patch #13 set the function handler for the max77802 modes translation. Patch #14 configure the regulators for the Peach Pit and Pi Chromebooks. Best regards, Javier [0]: https://lkml.org/lkml/2014/10/10/161 [1]: http://www.spinics.net/lists/arm-kernel/msg369923.html -- 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] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
On Mon, Nov 3, 2014 at 8:28 AM, bpqw wrote: >>This patch is used to add vendor prefix for >>Micron Technology Inc in the vendor-prefixes.txt file. > >>Micron Technology, Inc. is an American >>multinational corporation based in Boise, >>Idaho, best known for producing many forms >>of semiconductor devices. This includes DRAM, >>SDRAM, flash memory, eMMC and SSDs. > >>Signed-off-by: bean huo > > Dear linux developer: > > Is there maintainer in this mail list? Can give me a result for > this simple patch?if can be accepted or not? Or give me some suggections? > It has been long time. It has been 6 minutes since you sent the last version. I see you have fixed the line length although I'm not sure why you made it so short. 72 characters is the norm, but up to 80 is fine. You have not fixed the authorship as Mark pointed out. Also, please version your patches (i.e. [PATCH v2]). Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stmmac: potential circular locking dependency
Hello Emilio
I have a subset of new patches to review and fix locks in the
driver. I will plan to send them in the next days.
Sincerely
Peppe
On 11/3/2014 3:36 PM, Emilio López wrote:
Hi everyone,
I was playing with iperf on my Cubietruck today when I hit this lockdep
report/breakage on stmmac. It seems to be fairly reproducible by
1) Being on a GbE network
2) "iperf -s" on the stmmmac device
3) "iperf -c -d -P 5" on some other device on the LAN
Here it goes:
==
[ INFO: possible circular locking dependency detected ]
3.18.0-rc3-3-g7180edf #916 Not tainted
---
iperf/141 is trying to acquire lock:
(&(>tx_global_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x350/0x43c
but task is already holding lock:
(&(>tx_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x30/0x43c
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(>tx_lock)->rlock){+.-...}:
[] _raw_spin_lock+0x5c/0x94
[] stmmac_xmit+0x88/0x620
[] dev_hard_start_xmit+0x230/0x49c
[] sch_direct_xmit+0xdc/0x20c
[] __dev_queue_xmit+0x218/0x604
[] dev_queue_xmit+0x1c/0x20
[] neigh_resolve_output+0x180/0x254
[] ip6_finish_output2+0x188/0x8a4
[] ip6_output+0xc8/0x398
[] mld_sendpack+0x2e0/0x6d8
[] mld_ifc_timer_expire+0x1f0/0x308
[] call_timer_fn+0xb4/0x1f0
[] run_timer_softirq+0x224/0x2f0
[] __do_softirq+0x1d4/0x3e0
[] irq_exit+0x9c/0xd0
[] __handle_domain_irq+0x70/0xb4
[] gic_handle_irq+0x34/0x6c
[] __irq_svc+0x44/0x5c
[] lock_acquire+0xec/0x17c
[] lock_acquire+0xec/0x17c
[] _raw_spin_lock+0x5c/0x94
[] do_read_fault.isra.93+0xa8/0x2a0
[] handle_mm_fault+0x44c/0x8dc
[] do_page_fault+0x160/0x2d8
[] do_PrefetchAbort+0x44/0xa8
[] ret_from_exception+0x0/0x20
[] 0xb6eb0120
-> #1 (_xmit_ETHER#2){+.-...}:
[] _raw_spin_lock+0x5c/0x94
[] dev_deactivate_many+0xd0/0x250
[] dev_deactivate+0x3c/0x4c
[] linkwatch_do_dev+0x50/0x84
[] __linkwatch_run_queue+0xdc/0x148
[] linkwatch_event+0x3c/0x44
[] process_one_work+0x1ec/0x510
[] worker_thread+0x5c/0x4d8
[] kthread+0xe8/0xfc
[] ret_from_fork+0x14/0x20
-> #0 (&(>tx_global_lock)->rlock){+.-...}:
[] lock_acquire+0xdc/0x17c
[] _raw_spin_lock+0x5c/0x94
[] stmmac_tx_clean+0x350/0x43c
[] stmmac_poll+0x3c/0x618
[] net_rx_action+0x178/0x28c
[] __do_softirq+0x1d4/0x3e0
[] irq_exit+0x9c/0xd0
[] __handle_domain_irq+0x70/0xb4
[] gic_handle_irq+0x34/0x6c
[] __irq_svc+0x44/0x5c
[] __local_bh_enable_ip+0x9c/0xfc
[] __local_bh_enable_ip+0x9c/0xfc
[] _raw_read_unlock_bh+0x40/0x44
[] inet6_dump_addr+0x33c/0x530
[] inet6_dump_ifaddr+0x1c/0x20
[] rtnl_dump_all+0x50/0xf4
[] netlink_dump+0xc0/0x250
[] netlink_recvmsg+0x234/0x300
[] sock_recvmsg+0xa4/0xc8
[] ___sys_recvmsg.part.33+0xe4/0x1c0
[] __sys_recvmsg+0x60/0x90
[] SyS_recvmsg+0x18/0x1c
[] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Chain exists of:
&(>tx_global_lock)->rlock --> _xmit_ETHER#2 -->
&(>tx_lock)->rlock
Possible unsafe locking scenario:
CPU0CPU1
lock(&(>tx_lock)->rlock);
lock(_xmit_ETHER#2);
lock(&(>tx_lock)->rlock);
lock(&(>tx_global_lock)->rlock);
*** DEADLOCK ***
3 locks held by iperf/141:
#0: (rtnl_mutex){+.+.+.}, at: [] netlink_dump+0x28/0x250
#1: (rcu_read_lock){..}, at: [] inet6_dump_addr+0x0/0x530
#2: (&(>tx_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x30/0x43c
stack backtrace:
CPU: 0 PID: 141 Comm: iperf Not tainted 3.18.0-rc3-3-g7180edf #916
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x9c/0xbc)
[] (dump_stack) from []
(print_circular_bug+0x21c/0x33c)
[] (print_circular_bug) from []
(__lock_acquire+0x2060/0x2148)
[] (__lock_acquire) from [] (lock_acquire+0xdc/0x17c)
[] (lock_acquire) from [] (_raw_spin_lock+0x5c/0x94)
[] (_raw_spin_lock) from []
(stmmac_tx_clean+0x350/0x43c)
[] (stmmac_tx_clean) from [] (stmmac_poll+0x3c/0x618)
[] (stmmac_poll) from [] (net_rx_action+0x178/0x28c)
[] (net_rx_action) from [] (__do_softirq+0x1d4/0x3e0)
[] (__do_softirq) from [] (irq_exit+0x9c/0xd0)
[] (irq_exit) from [] (__handle_domain_irq+0x70/0xb4)
[] (__handle_domain_irq) from []
(gic_handle_irq+0x34/0x6c)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c)
Exception stack(0xcabc1be0 to 0xcabc1c28)
1be0: 0001 2df53000 caf15e80 cabc 0201 ca9a9840
c03ad050
1c00: ca8d9404 ca9b4f50
Re: [PATCH RFC v2 8/8] ARM: zynq: DT: Add pinctrl information
On Sun, Nov 2, 2014 at 9:20 PM, Sören Brinkmann
wrote:
(...)
> common {
> groups = "uart1_10_grp";
> function = "uart1";
> bias-pull-up = <0>;
> slew-rate = <0>;
> io-standard = <1>;
> };
>
> rx {
> pins = "MIO49";
> bias-high-impedance = <1>;
> };
>
> tx {
> pins = "MIO48";
> bias-high-impedance = <0>;
> };
(...)
> common {
> groups = "uart1_10_grp";
> function = "uart1";
> };
>
> rx {
> pins = "MIO49";
> slew-rate = <0>;
> io-standard = <1>;
> bias-high-impedance;
> };
>
> tx {
> pins = "MIO48";
> slew-rate = <0>;
> io-standard = <1>;
> };
> };
>
> In a nutshell, yes, it's possible to work without the arguments for
> pull-up or tri-state. But it adds complexity in the driver and the DT
> description.
But isn't it obvious that the latter is easier for a human to read
and understand (and not misunderstand) and remember readability
of config is one of the design goals of DT...
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: [PATCH 00/12] Add kdbus implementation
On Sat, 1 Nov 2014 18:21:30 -0700 Greg Kroah-Hartman wrote: > Here's some reasons why I feel it is better to have kdbus in the kernel > rather than trying to implement the same thing in a userspace daemon: No - these are reasons to have *something* in the kernel. I think it would be far more constructive to treat the current kdbus as a proof of concept/prototype or even a draft requirements specification. > as the only trustworthy compoenent in the game is the kernel which > adds metadata and ensures that all data passed as payload is either > copied or sealed, so that the receiver can parse the data without When the kernel adds metadata without being told to do so by one end of the link you create a new set of security and privacy leaks. Far better that the sender must choose what metadata is added and the receiver can decide to bin stuff that's not acceptable. The job of the kernel is really more like that of an auditor in a business transaction - to make sure that the data they agree to pass is truthful. (ie its the sender who must say "attach my user info", the receiver who must say "no info, no play" and the kernel who must provide the info so it can't be faked. > - semantics for apps with heavy data payloads (media apps, for instance) > with optinal priority message dequeuing, and global message ordering. Sounds like System 5 IPC ;-) > Regarding binder: binder and kdbus follow very different design > concepts. We know binder is broken but the Android guys are stuck in a special kind of hell with it for some years to come. We need to make sure kdbus isn't the same result. Alan -- 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] regulator: max77693: Fix use of uninitialized regulator config
On Mon, Nov 03, 2014 at 03:07:05PM +0100, Krzysztof Kozlowski wrote: > Driver allocated on stack struct regulator_config but didn't initialize > it fully. Few fields (driver_data, ena_gpio) were left untouched. This > lead to using random ena_gpio values as GPIOs for max77693 regulators. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 04/13] autofs4 - change printks AUTOFS defined prints
On Mon, 2014-11-03 at 17:20 +0800, Ian Kent wrote: > On Mon, 2014-11-03 at 00:25 -0800, Joe Perches wrote: > > On Mon, 2014-11-03 at 16:12 +0800, Ian Kent wrote: > > > Use the AUTOFS_*() print defines instead of raw printks. Hi again Ian > > It's probably better to simply use > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > or > > #define pr_fmt(fmt) KBUILD_MODNAME ":%d:%s" fmt, current->pid, __func__ > > if you _really_ want pid/func in the output > > I do, yes. That's fine. I left out the trailing semicolon/space. The pr_fmt could be something like: #define pr_fmt(fmt) KBUILD_MODNAME ":%d:%s: " fmt, current->pid, __func__ or add a "pid:" descriptor prefix if you like too: #define pr_fmt(fmt) KBUILD_MODNAME ":pid:%d:%s: " fmt, current->pid, __func__ > > it's better to use a consistent style for > > these logging functions ideally with terminating > > newlines so there isn't a mix of code with > > and without those newlines. That inconsistency > > leads to unintended defects. > > The idea here was to make the logging consistent throughout. Mine too. > I have become used of not using the new-line terminator in logging over > the years and tend to favour that myself. You recommend not doing that > probably from a kernel wide consistency perspective? Maybe that is > better ... Yes, kernel style consistency is the rationale. Over time, people come along and add messages while not reading the code very closely so using the kernel style with newlines can help avoid these trivial defects. cheers, Joe -- 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] compiler: Correct macro parameter expansion problem
From: Mark Rustad
The macro __compiletime_error_fallback has an error in that it
lacks parens around the expansion of an expression. It also
lacks a conversion to a boolean value. The first problem can
result in a mis-evaluation. The second problem can also result
in an error if the value comes out negative. That would thwart
the intended error generation. That is, the error being asserted
would not in fact generate an error. Fix both problems by adding
!!() to the expansion.
Signed-off-by: Mark Rustad
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index d5ad7b1..59dc611 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -331,7 +331,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int
val, int expect);
*/
# ifndef __CHECKER__
# define __compiletime_error_fallback(condition) \
- do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
+ do { ((void)sizeof(char[1 - 2 * !!(condition)])); } while (0)
# endif
#endif
#ifndef __compiletime_error_fallback
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] kernel, add panic_on_warn
There have been several times where I have had to rebuild a kernel to cause a panic when hitting a WARN() in the code in order to get a crash dump from a system. Sometimes this is easy to do, other times (such as in the case of a remote admin) it is not trivial to send new images to the user. A much easier method would be a switch to change the WARN() over to a panic. This makes debugging easier in that I can now test the actual image the WARN() was seen on and I do not have to engage in remote debugging. This patch adds a panic_on_warn kernel parameter and /proc/sys/kernel/panic_on_warn calls panic() in the warn_slowpath_common() path. The function will still print out the location of the warning. An example of the panic_on_warn output: The first line below is from the WARN_ON() to output the WARN_ON()'s location. After that the panic() output is displayed. WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]() Kernel panic - not syncing: panic_on_warn set ... CPU: 30 PID: 11698 Comm: insmod Tainted: GW OE 3.17.0+ #57 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.131329 11/11/2013 8e3f87df 88080f093c38 81665190 818aea3d 88080f093cb8 8165e2ec 0008 88080f093cc8 88080f093c68 8e3f87df Call Trace: [] dump_stack+0x46/0x58 [] panic+0xd0/0x204 [] ? init_dummy+0x1f/0x30 [dummy_module] [] warn_slowpath_common+0xd0/0xd0 [] ? dummy_greetings+0x40/0x40 [dummy_module] [] warn_slowpath_null+0x1a/0x20 [] init_dummy+0x1f/0x30 [dummy_module] [] do_one_initcall+0xd4/0x210 [] ? __vunmap+0xc2/0x110 [] load_module+0x16a9/0x1b30 [] ? store_uevent+0x70/0x70 [] ? copy_module_from_fd.isra.44+0x129/0x180 [] SyS_finit_module+0xa6/0xd0 [] system_call_fastpath+0x12/0x17 Successfully tested by me. Cc: Jonathan Corbet Cc: Andrew Morton Cc: Rusty Russell Cc: "H. Peter Anvin" Cc: Andi Kleen Cc: Masami Hiramatsu Cc: Fabian Frederick Cc: vgo...@redhat.com Cc: isimatu.yasu...@jp.fujitsu.com Cc: jba...@akamai.com Cc: h...@sgi.com Cc: linux-...@vger.kernel.org Cc: ke...@lists.infradead.org Cc: linux-...@vger.kernel.org Signed-off-by: Prarit Bhargava [v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify !slowpath cases [v3]: use proc_dointvec_minmax() in sysctl handler [v4]: remove !slowpath cases, and add __read_mostly [v5]: change to panic_on_warn, re-alphabetize Documentation/sysctl/kernel.txt [v6]: disable on kdump kernel to avoid bogus panicks. --- Documentation/kdump/kdump.txt |7 ++ Documentation/kernel-parameters.txt |3 +++ Documentation/sysctl/kernel.txt | 40 +++ include/linux/kernel.h |1 + include/uapi/linux/sysctl.h |1 + kernel/panic.c | 23 +++- kernel/sysctl.c |9 kernel/sysctl_binary.c |1 + 8 files changed, 70 insertions(+), 15 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 6c0b9f2..bc4bd5a 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -471,6 +471,13 @@ format. Crash is available on Dave Anderson's site at the following URL: http://people.redhat.com/~anderson/ +Trigger Kdump on WARN() +=== + +The kernel parameter, panic_on_warn, calls panic() in all WARN() paths. This +will cause a kdump to occur at the panic() call. In cases where a user wants +to specify this during runtime, /proc/sys/kernel/panic_on_warn can be set to 1 +to achieve the same behaviour. Contact === diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4c81a86..ea5d57c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2509,6 +2509,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. timeout < 0: reboot immediately Format: + panic_on_warn panic() instead of WARN(). Useful to cause kdump + on a WARN(). + crash_kexec_post_notifiers Run kdump after running panic-notifiers and dumping kmsg. This only for the users who doubt kdump always diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 57baff5..b5d0c85 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -54,8 +54,9 @@ show up in /proc/sys/kernel: - overflowuid - panic - panic_on_oops -- panic_on_unrecovered_nmi - panic_on_stackoverflow +- panic_on_unrecovered_nmi +- panic_on_warn - pid_max - powersave-nap [ PPC only ] - printk @@ -527,19 +528,6 @@ the recommended setting is 60.
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
>This patch is used to add vendor prefix for >Micron Technology Inc in the vendor-prefixes.txt file. >Micron Technology, Inc. is an American >multinational corporation based in Boise, >Idaho, best known for producing many forms >of semiconductor devices. This includes DRAM, >SDRAM, flash memory, eMMC and SSDs. >Signed-off-by: bean huo Dear linux developer: Is there maintainer in this mail list? Can give me a result for this simple patch?if can be accepted or not? Or give me some suggections? It has been long time. -- 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] Documentation: vm: Add 1GB large page support information
On Sat, 1 Nov 2014 01:01:57 +0900 Masanari Iida wrote: > This patch add 1GB large page support information on > x86_64 architecture in Documentation/vm/hugetlbpage.txt. > > Signed-off-by: Masanari Iida > --- > Documentation/vm/hugetlbpage.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/vm/hugetlbpage.txt > b/Documentation/vm/hugetlbpage.txt > index bdd4bb9..0a2bf4f 100644 > --- a/Documentation/vm/hugetlbpage.txt > +++ b/Documentation/vm/hugetlbpage.txt > @@ -2,7 +2,8 @@ > The intent of this file is to give a brief summary of hugetlbpage support in > the Linux kernel. This support is built on top of multiple page size support > that is provided by most modern architectures. For example, i386 > -architecture supports 4K and 4M (2M in PAE mode) page sizes, ia64 > +architecture supports 4K and 4M (2M in PAE mode) page sizes, x86_64 > +architecture supports 4K, 2M and 1G (SandyBridge or later) page sizes. ia64 Good catch, but does it make sense to mention SandyBridge? Doesn't it makes it Intel specific? What about mentioning the pdpe1gb flag instead? > architecture supports multiple page sizes 4K, 8K, 64K, 256K, 1M, 4M, 16M, > 256M and ppc64 supports 4K and 16M. A TLB is a cache of virtual-to-physical > translations. Typically this is a very scarce resource on processor. -- 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] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ceph: Deletion of unnecessary checks before two function calls
On Mon, Nov 3, 2014 at 4:27 PM, SF Markus Elfring
wrote:
>> dput() also checks for NULL argument, but the check is wrapped into
>> unlikely(), which is why I presume it wasn't picked up. It would be
>> great if you could improve your coccinelle script to handle
>> {un,}likely() as well.
>
> Thanks for your suggestion.
>
> Should I consider any more fine-tuning for the affected script
> "list_input_parameter_validation1.cocci" in the near future?
> https://lkml.org/lkml/2014/3/5/362
> http://article.gmane.org/gmane.comp.version-control.coccinelle/3514
Make sure it at least catches stuff like:
{
if (input) {
}
}
{
if (likely(input)) {
}
}
{
if (!input)
return;
...
}
{
if (unlikely(!input))
return;
...
}
And of course each match then has to be validated manually.
>
>
>>> @@ -590,15 +589,13 @@ static void queue_realm_cap_snaps(struct
>>> ceph_snap_realm
>>> *realm)
>>
>> The patch was corrupted, that should have been a single line. I fixed
>> it up but you may want to look into your email client settings.
>
> Thanks for your feedback.
>
> Does this example show a conflict between long comments after patch ranges and
> line length limitation for email eventually?
There is no line length limitation for email, at least one that would
be relevant here. Patches should be sent verbatim, no line wrapping,
expandtab, etc or they won't apply. I'd recommend git-send-email, but
if you want to make thunderbird work for patches (which is what you
seem to be using) have a look at the "Thunderbird (GUI)" section of
Documentation/email-clients.txt in the kernel tree.
Thanks,
Ilya
--
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 01/11] crypto: Documentation - crypto API high level spec
Am Montag, 3. November 2014, 08:34:39 schrieb Jonathan Corbet: Hi Jonathan, > On Sun, 02 Nov 2014 21:35:11 +0100 > > Stephan Mueller wrote: > > The design of the kernel crypto API as well as hints to program with > > the kernel crypto API are given. > > Cool to see this, thanks. Please forgive me if I go into full grumpy > editor mode here. There's a lot of good information here, but I think it > could be made better with a bit of effort... Thanks for your comments. I will include your suggestions into a new patch set. Once you staring at that documentation for too long, you will not find errors any more :-) [...] > > + > > + * CRYPTO_ALG_TYPE_CIPHER Raw block cipher > > + * CRYPTO_ALG_TYPE_COMPRESSCompression > > + * CRYPTO_ALG_TYPE_AEADAuthenticated Encryption with Associated Data > > (MAC) + * CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher > > + * CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher > > + * CRYPTO_ALG_TYPE_GIVCIPHER > > What's this one? I would like to ask Herbert what that is -- I looked around in the code and I am not sure what that flag shall indicate. > > > + * CRYPTO_ALG_TYPE_DIGEST Raw message digest > > + * CRYPTO_ALG_TYPE_HASHAlias for CRYPTO_ALG_TYPE_DIGEST > > + * CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash > > + * CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash > > + * CRYPTO_ALG_TYPE_RNG Random Number Generation > > + * CRYPTO_ALG_TYPE_PCOMPRESS > > What's that last one? Same here. [...] > > +Specifics of asynchronous multi-block cipher > > + > > + > > +There are a couple of specifics to the [ABLKCIPHER] interface. > > + > > +First of all, some of the drivers will want to use the Generic > > ScatterWalk > > +in case the hardware needs to be fed separate chunks of the scatterlist > > +which contains the plaintext and will contain the ciphertext. Please > > refer > > +below for a description and usage of the Generic ScatterWalk interface. > > + > > +It is recommended to enqueue cryptographic transformation requests into > > +generic crypto queues. This allows for these requests to be processed in > > +sequence as the cryptographic hardware becomes free. > > What's a generic crypto queue? That's a new concept. Right. I do not claim to have all completed right from the start. If so, there is much more: the AEAD and RNG implementation details are missing here too. Therefore, I thought I could leave it open for the moment to add in later. [..] > > These are all useful. But I wonder if it would be worth the effort to turn > this inti a proper docbook document that automatically has everything > together in one place? How do you suggest that is done? The API comments in the header file follow the Doxygen style. Note, Jason Cooper raised the concern that an API documentation separate from the code will surely deviate from the code relatively fast (although I do not really fear that as the kernel crypto API seems to be quite stable over the last years). Can you point me to an example about what you have in mind? I see the Documentation/DocBook/ files, but I do not see how they integrate Doxygen-like source code comments added to functions. > > > + > > +Authors > > +=== > > + > > +Stephan Mueller > > +Marek Vasut > > jon -- Ciao Stephan -- 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: A desktop environment[1] kernel wishlist
> > It's a reasonable ask but answers even if available are likely > > to be things like "because GPE36" and GPE36 will just be some connection > > to something that could be anything from a lid switch to a light sensor > > or even a smart wifi chip deciding it wants the CPU to help out because > > you are out of range of the base station. We may not even know what it > > relates to. > > But the device or platform driver would know that, presumably. Quite often it has no idea - maybe the firmware knows but it isn't telling us. It's an internal detail. > > > A non suspend system will exit deep idle type status because they got > > an IRQ or perhaps some DMA needed the cache coherency. That doesn't mean > > they've got the foggiest which IRQ kicked them out if idle, just that hey > > I'm awake and there are four pending interrupts. That of course is > > assuming it even noticed it entered a deep idle state - you don't want to > > wake an idle CPU to tell it that its more idle than it was before. > > Sure, the CPU might not be the best example of a device for which we > need to track the wakeup reason. The device drivers however... You keep assuming a wakeup is "special" - it's quite possibly not. The RTC driver knows whether an alarm went off, it's got no idea if that cause a wakeup or even what a wake up is or if the platform has wakeups or just deep sleeps. Same for most other stuff - plugging in a display may well bump a machine out of deep sleep but the graphics driver isn't going to know anything other than "I'm handling a cable change". Events can also be processed entirely by firmware so we just wake up, look round, scratch out head and go back to sleep. So I really think "why did I wake up" is actually the wrong question to be asking. What you probably should be asking (and what the kernel effectively asks) is "Why am I not idle ?". That plus "what state changes have occurred that I care about". Both of those are questions you can ask at any time without caring how sleeping may or may not happen. ie you don't care if a lid event woke you, you care if the lid is open or shut. You don't care whether a wireless event woke you, you care that the wireless has been lost etc.. Ie instead of doing if (woken && cause == BATTERY_LOW) suspend_to_disk() you want to be doing (as part of the normal flow) if (battery < BATTERY_LOW && battery_prev >= BATTERY_LOW + HYSTERISIS) suspend_to_disk(); because it's kind of irrelevant whether it woke you for this, you need to do it anyway. Alan -- 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] ALSA: echoaudio: add reference of struct echoaudio
At Mon, 3 Nov 2014 16:04:12 +0530, Sudip Mukherjee wrote: > > added reference of struct echoaudio to free_firmware function. > this structure will be later used to get a reference of the card > when converting snd_printk to dev_* in the next patch of the series. > > Signed-off-by: Sudip Mukherjee Thanks, now applied both. Though, I noticed that there is also a dev_notice() usage that should be also dev_dbg(). Corrected such lines in my side. Takashi -- 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 resent] ALSA: emu10k1: Deletion of unnecessary checks before three function calls
At Mon, 03 Nov 2014 15:10:40 +0100, SF Markus Elfring wrote: > > > Your patch can't be applied cleanly due to your MUA breaking the > > lines. Please fix your MUA setup, or use an attachment if it's > > impossible, and resend the patch. > > Thanks for your feedback. > > Does this example show a conflict between long comments like > "snd_emu10k1_ctl_private_free( ... *kctl)" after patch ranges and line length > limitation for email eventually? Conflict? It's your MUA that is broken. > > Also, try to align the subject line with the relevant commits. See > > "git log sound/pci/emu10k1" > > I have attached my update suggestion with a slightly different commit title as > before. Is this variant acceptable? So, you couldn't fix your MUA? That's bad for you. Many maintainers dislike attachments and won't accept such patches. Couldn't you simply send a patch via git-send-email? In anyway, I applied the patch now. Thanks. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
On Mon, Nov 03, 2014 at 12:10:49PM +, One Thousand Gnomes wrote: > On Sun, 2 Nov 2014 09:33:01 -0800 > Josh Triplett wrote: > > > On the vast majority of modern systems, no processes will use the > > userspsace IO syscalls, iopl and ioperm. Add a new config option, > > CONFIG_X86_IOPORT, to support configuring them out of the kernel > > entirely. Most current systems do not run programs using these > > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > > default to y. > > This isn't unreasonable but there are drivers with userspace helpers that > use iopl/ioperm type functionality where you should be doing a SELECT of > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > scan it may these days be the only mainstream one that needs the select > adding. Should kernel drivers really express dependencies that only their (current instances of) corresponding userspace components need? Something seems wrong about that. > Some X servers for legacy cards still use io port access. Sure, X servers using UMS rather than KMS seem like a common reason to need this. > There are also > a couple of other highly non-obvious userspace users that hang on for > some systems - eg some older servers DMI and error records can only by > read via a real mode BIOS call so management tools have no choice but to > go the lrmi/io path. As with any userspace interface, some callers may potentially still exist. And this still has "default y", too, to avoid user surprises. > Still makes sense IMHO. > > From a code perspective however you could define IO_BITMAP_LONGS to 0, > add an IO_BITMAP_SIZE (defined as LONGS + 1 or 0) and as far as I can see > gcc would then optimise out a lot of the code you are ifdeffing IO_BITMAP_LONGS already gets defined to (0/sizeof(long)). And as far as I can tell, that would only work for init_tss_io, not anything else. Even then, that would only work with a zero-size array left around in tss_struct, which doesn't seem appropriate. The remaining ifdefs wrap code that GCC could not constant-fold away, and making that code constant-foldable seems significantly more invasive than the ifdefs. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] media: spi: Add support for LMH0395
On 11/03/2014 02:42 PM, Laurent Pinchart wrote:
> On Monday 03 November 2014 14:36:26 Hans Verkuil wrote:
>> On 11/03/2014 02:13 PM, Laurent Pinchart wrote:
>>> Hi Jean-Michel,
>>>
>>> Thank you for the patch.
>>
>>> On Wednesday 10 September 2014 11:43:54 Jean-Michel Hautbois wrote:
>>
>>
+static int lmh0395_s_routing(struct v4l2_subdev *sd, u32 input, u32
output, + u32 config)
+{
+ struct lmh0395_state *state = to_state(sd);
+ int err = 0;
+
+ if (state->output_type != output)
+ err = lmh0395_set_output_type(sd, output);
+
+ return err;
>>> if (state->output_type == output)
>>> return 0;
>>>
>>> return lmh0395_set_output_type(sd, output);
>>>
>>> You can then get rid of the err variable.
>>>
>>> I don't really like this implementation though, the output argument is
>>> device- specific, you thus require explicit knowledge of the LMH0395 in
>>> your bridge driver.
>>
>> Well, that's the way s_routing is defined. It's the bridge driver's job to
>> translate between V4L2 inputs/outputs and low-level routing information.
>>
>>> I'm not sure what the config argument is used for, but naively I would
>>> have
>>
>> config is normally not used. There are one or two drivers that need it for
>> additional routing configuration, but it's rare.
>
> OK.
>
>>> used it to tell whether to enable (1) or disable (0) the route from input
>>> to output. The input value should then always be 0, and the output value
>>> can be 1 or 2. Another option would be to use the new S_ROUTING userspace
>>> ioctl I've proposed in
>>> http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/commit/?h=xilinx-wip
>>> d=fc094c354338861673464ed4b8fa198089fe7bf0.
>>>
>>> Hans, could you comment on that ?
>>
>> Well, first of all your proposed API isn't merged yet, or even posted on the
>> mailinglist, so it's a bit unfair to require someone else to use it :-)
>
> It's not a requirement, just a proposal :-) I can send a patch series if
> there's enough interest for using that API.
>
>> Also, while I do agree with your proposed new API I am a lot less
>> enthusiastic about creating yet another duplicate pad op for an existing
>> audio/video routing op.
>>
>> The problem is that existing drivers are never updated for the new op and
>> you are stuck with competing internal APIs. Not nice at all.
>
> Agreed, it's not nice, feel free to propose a better solution :-)
>
>> Bottom line is that this driver uses s_routing like any other driver
>> currently in the kernel, so I have no problem with that.
>
> I do :-)
>
> The bridge to subdev dependency is fine for PCI or USB devices where the
> hardware topology is known to the driver. It isn't for composite embedded
> devices, as we don't want to teach all bridges about all subdevs.
>
I agree, and your proposal is a nice solution. But whoever want to get this
merged *will* have to take a good look at the existing g/s_routing ops and
how they can be converted to the new one. I didn't block that when similar
duplicate ops were added in the past and I am increasingly sorry I didn't do
that. It's creating incompatible subdevs, where the whole point of the subdev
API was to avoid that.
Regards,
Hans
--
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 resent] ALSA: emu10k1: Deletion of unnecessary checks before three function calls
> Your patch can't be applied cleanly due to your MUA breaking the > lines. Please fix your MUA setup, or use an attachment if it's > impossible, and resend the patch. Thanks for your feedback. Does this example show a conflict between long comments like "snd_emu10k1_ctl_private_free( ... *kctl)" after patch ranges and line length limitation for email eventually? > Also, try to align the subject line with the relevant commits. See > "git log sound/pci/emu10k1" I have attached my update suggestion with a slightly different commit title as before. Is this variant acceptable? Regards, Markus >From 23bb7bd1325b7c9cc81761db3ebf3ea19f85338d Mon Sep 17 00:00:00 2001 From: Markus Elfring Date: Mon, 3 Nov 2014 14:54:36 +0100 Subject: [PATCH] ALSA: emu10k1: Deletion of unnecessary checks before three function calls The functions kfree(), release_firmware() and snd_util_memhdr_free() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- sound/pci/emu10k1/emu10k1_main.c | 9 +++-- sound/pci/emu10k1/emufx.c| 3 +-- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/sound/pci/emu10k1/emu10k1_main.c b/sound/pci/emu10k1/emu10k1_main.c index 2292697..b4458a6 100644 --- a/sound/pci/emu10k1/emu10k1_main.c +++ b/sound/pci/emu10k1/emu10k1_main.c @@ -1289,10 +1289,8 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) } if (emu->emu1010.firmware_thread) kthread_stop(emu->emu1010.firmware_thread); - if (emu->firmware) - release_firmware(emu->firmware); - if (emu->dock_fw) - release_firmware(emu->dock_fw); + release_firmware(emu->firmware); + release_firmware(emu->dock_fw); if (emu->irq >= 0) free_irq(emu->irq, emu); /* remove reserved page */ @@ -1301,8 +1299,7 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) (struct snd_util_memblk *)emu->reserved_page); emu->reserved_page = NULL; } - if (emu->memhdr) - snd_util_memhdr_free(emu->memhdr); + snd_util_memhdr_free(emu->memhdr); if (emu->silent_page.area) snd_dma_free_pages(>silent_page); if (emu->ptb_pages.area) diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c index 745f062..eb5c0ab 100644 --- a/sound/pci/emu10k1/emufx.c +++ b/sound/pci/emu10k1/emufx.c @@ -777,8 +777,7 @@ static void snd_emu10k1_ctl_private_free(struct snd_kcontrol *kctl) kctl->private_value = 0; list_del(>list); kfree(ctl); - if (kctl->tlv.p) - kfree(kctl->tlv.p); + kfree(kctl->tlv.p); } static int snd_emu10k1_add_controls(struct snd_emu10k1 *emu, -- 2.1.3
Re: [RFC] gpio: remove gpio_descs global array
On Sat, Nov 1, 2014 at 8:03 AM, Alexandre Courbot wrote: > The issue with this patch is its use of kzalloc() in gpiochip_add(), a > function potentially called during early boot, before kzalloc() becomes > usable. Hence its [RFC] status until we can find a solution for this or > agree that this issue is actually never ran into (from which point can > one use kzalloc()?) So which driver requires that the gpiochip be statically defined... I heard about early call but not *that* early. 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: [V9 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
On 03/11/14 09:50, Marc Zyngier wrote:
>> @@ -843,10 +847,14 @@ static int gic_irq_domain_alloc(struct irq_domain
>> *domain, unsigned int virq,
>> unsigned int type = IRQ_TYPE_NONE;
>> struct of_phandle_args *irq_data = arg;
>>
>> - ret = gic_irq_domain_xlate(domain, irq_data->np, irq_data->args,
>> - irq_data->args_count, , );
>> - if (ret)
>> - return ret;
>> + if (irq_data) {
>> + ret = gic_irq_domain_xlate(domain, irq_data->np,
>> irq_data->args,
>> + irq_data->args_count, ,
>> );
>> + if (ret)
>> + return ret;
>> + } else {
>> + hwirq = virq;
>> + }
>
> I'm slightly puzzled here. What's the purpose of this? The whole goal of
> the domain hierarchy is to avoid that kind of thing. Also, you should
> never have to call xlate on an MSI, because it should never be described
> in the device tree the first place.
Thinking of it some more:
The actual reason why this is required is because the MSI domain calls
into this via irq_domain_alloc_irqs_parent(). But because MSIs are not
described in DT, they do not have a of_phandle to pass down to the xlate
helper. In this case, the v2m widget has the knowledge of what are the
valid SPI numbers, and the core GIC code must blindly accept it.
This definitely requires a fat comment, because this is far from obvious.
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: [PATCH v2 1/5] video: move mediabus format definition to a more standard place
Hi Boris, Laurent,
My apologies, I missed this patch when it was posted.
First of all, please convert all existing kernel drivers that use V4L2_MBUS_FMT
to the new macro. It's easy to automate, and I see no reason why we shouldn't
do this.
If you don't do that now, then we'll be stuck with two naming conventions
in the kernel for a long time.
Actually, to be explicit, I will NACK this if this conversion isn't done
as part of the patch series.
Also add something like:
#ifdef __KERNEL__
#error Use video-bus-format.h instead of v4l2-mediabus.h
#else
#warning Use video-bus-format.h instead of v4l2-mediabus.h
#endif
to the old header to prevent future drivers from using it. I'm not sure
about the warning when included by userspace applications. I personally
think it makes sense. While everyone claims now to keep the two headers
in sync, I think that in practice this will not work. Freezing the old
header and only adding new values to the new header is better.
Secondly, is there any reason why this shouldn't be named media-bus-format.h
instead? Besides regular video these busses can also carry VBI data or even
audio. I prefer the more generic term 'media'. Besides, it's already called a
mediabus format, just with a V4L2 prefix, so why not keep that name? Less
confusing for existing users of this header.
Thirdly, as others mentioned, the updated documentation must be part of the
patch series. I'll NACK it if it isn't. One reason why V4L2 has really good
API documentation is the strict requirement that patches that touch on the
userspace API must also update documentation.
It happened too often that developers swear up and down that they will update
the documentation later, and then they don't.
So, based on the above points:
Nacked-by: Hans Verkuil
But it really shouldn't be hard to fix it because I do like the idea behind
it very much.
Apologies once again for the late reply and thanks to Laurent for asking me
to review this.
Regards,
Hans
On 09/29/2014 04:02 PM, Boris Brezillon wrote:
> Rename mediabus formats and move the enum into a separate header file so
> that it can be used by DRM/KMS subsystem without any reference to the V4L2
> subsystem.
>
> Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
> definitions.
>
> Signed-off-by: Boris BREZILLON
> Acked-by: Guennadi Liakhovetski
> ---
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/v4l2-mediabus.h| 183
> +++---
> include/uapi/linux/video-bus-format.h | 127 +++
> 3 files changed, 207 insertions(+), 104 deletions(-)
> create mode 100644 include/uapi/linux/video-bus-format.h
>
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index be88166..8712730 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -410,6 +410,7 @@ header-y += veth.h
> header-y += vfio.h
> header-y += vhost.h
> header-y += videodev2.h
> +header-y += video-bus-format.h
> header-y += virtio_9p.h
> header-y += virtio_balloon.h
> header-y += virtio_blk.h
> diff --git a/include/uapi/linux/v4l2-mediabus.h
> b/include/uapi/linux/v4l2-mediabus.h
> index 1445e85..7b0a06c 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -13,118 +13,93 @@
>
> #include
> #include
> +#include
>
> -/*
> - * These pixel codes uniquely identify data formats on the media bus. Mostly
> - * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
> - * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where
> the
> - * data format is fixed. Additionally, "2X8" means that one pixel is
> transferred
> - * in two 8-bit samples, "BE" or "LE" specify in which order those samples
> are
> - * transferred over the bus: "LE" means that the least significant bits are
> - * transferred first, "BE" means that the most significant bits are
> transferred
> - * first, and "PADHI" and "PADLO" define which bits - low or high, in the
> - * incomplete high byte, are filled with padding bits.
> - *
> - * The pixel codes are grouped by type, bus_width, bits per component,
> samples
> - * per pixel and order of subsamples. Numerical values are sorted using
> generic
> - * numerical sort order (8 thus comes before 10).
> - *
> - * As their value can't change when a new pixel code is inserted in the
> - * enumeration, the pixel codes are explicitly given a numerical value. The
> next
> - * free values for each category are listed below, update them when inserting
> - * new pixel codes.
> - */
> -enum v4l2_mbus_pixelcode {
> - V4L2_MBUS_FMT_FIXED = 0x0001,
> +#define VIDEO_BUS_TO_V4L2_MBUS(x)V4L2_MBUS_FMT_ ## x = VIDEO_BUS_FMT_ ##
> x
>
> - /* RGB - next is 0x100e */
> - V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
> - V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
> - V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
> -
[PATCH] regulator: max77693: Fix use of uninitialized regulator config
Driver allocated on stack struct regulator_config but didn't initialize
it fully. Few fields (driver_data, ena_gpio) were left untouched. This
lead to using random ena_gpio values as GPIOs for max77693 regulators.
On occasion these values could match real GPIO numbers leading to
interfering with other drivers and to unsuccessful enable/disable of
regulator.
Signed-off-by: Krzysztof Kozlowski
Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
Cc:
---
drivers/regulator/max77693.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c
index 177dd9d2ce67..7b9755a6c3b5 100644
--- a/drivers/regulator/max77693.c
+++ b/drivers/regulator/max77693.c
@@ -227,7 +227,7 @@ static int max77693_pmic_probe(struct platform_device *pdev)
struct max77693_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct max77693_regulator_data *rdata = NULL;
int num_rdata, i;
- struct regulator_config config;
+ struct regulator_config config = { };
num_rdata = max77693_pmic_init_rdata(>dev, );
if (!rdata || num_rdata <= 0) {
--
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] UBI: Block: Add blk-mq support
On 11/03/2014 02:03 AM, Ming Lei wrote: > On Sun, Nov 2, 2014 at 9:00 PM, Richard Weinberger wrote: >> Convert the driver to blk-mq. > > It is always helpful to include some performance comparison data( > randrw, rw) between blk-mq and non-mq. > UBI block support is read-only for now so you'll be able to run read tests only. Richard: If at all possible, it would be interested to so some performance tests on *real* devices, not only RAM-based ones. Thanks for working on this! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com signature.asc Description: OpenPGP digital signature
[PATCH V6] UBI: Extend UBI layer debug/messaging capabilities
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
The R/O block driver messages were replaced by pr_* since
ubi_device structure is not used by it.
Amended a bit by Artem.
Signed-off-by: Tanya Brokhman
Signed-off-by: Artem Bityutskiy
---
Changes from V1:
- Compilation error fixed
- macros were updated to receive the ubi structure as
parameter and not just ubi_number
- Places in code, where ubi-messaging macros were used, but
ubi struct is not present yet (init phase), were updated
to just use pr_err or similar
Changes from V2:
- multi line messages layout, as requested by Artem
note that due to these changes checkpatch fails
Changes from V3:
- Compilation fix of block.c
- All ubi_* messages in block.c were replaced with pr_*
Changes from V4:
- Addressed comments on block.c
Changes from V5:
- Added ptr verification @ ubi_err/ubi_msg/ubi_warn
Removed extra printing of ubi number
Removed new messages.
Note for reviewers:
The updated macros are all in ubi.h. All other file changes are just
technical changes for compilation (usage of the defined macros)
drivers/mtd/ubi/attach.c | 126 ---
drivers/mtd/ubi/block.c | 41 +++--
drivers/mtd/ubi/build.c | 124 --
drivers/mtd/ubi/cdev.c| 29 -
drivers/mtd/ubi/debug.c | 10 ++--
drivers/mtd/ubi/eba.c | 53 +
drivers/mtd/ubi/fastmap.c | 96 ++---
drivers/mtd/ubi/io.c | 149 +++---
drivers/mtd/ubi/kapi.c| 6 +-
drivers/mtd/ubi/misc.c| 4 +-
drivers/mtd/ubi/ubi.h | 16 +++--
drivers/mtd/ubi/vmt.c | 69 +++--
drivers/mtd/ubi/vtbl.c| 43 ++---
drivers/mtd/ubi/wl.c | 60 ++-
14 files changed, 427 insertions(+), 399 deletions(-)
diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 6f27d9a..9d2e16f 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -176,6 +176,7 @@ static int add_corrupted(struct ubi_attach_info *ai, int
pnum, int ec)
/**
* validate_vid_hdr - check volume identifier header.
+ * @ubi: UBI device description object
* @vid_hdr: the volume identifier header to check
* @av: information about the volume this logical eraseblock belongs to
* @pnum: physical eraseblock number the VID header came from
@@ -188,7 +189,8 @@ static int add_corrupted(struct ubi_attach_info *ai, int
pnum, int ec)
* information in the VID header is consistent to the information in other VID
* headers of the same volume.
*/
-static int validate_vid_hdr(const struct ubi_vid_hdr *vid_hdr,
+static int validate_vid_hdr(const struct ubi_device *ubi,
+ const struct ubi_vid_hdr *vid_hdr,
const struct ubi_ainf_volume *av, int pnum)
{
int vol_type = vid_hdr->vol_type;
@@ -206,7 +208,7 @@ static int validate_vid_hdr(const struct ubi_vid_hdr
*vid_hdr,
*/
if (vol_id != av->vol_id) {
- ubi_err("inconsistent vol_id");
+ ubi_err(ubi, "inconsistent vol_id");
goto bad;
}
@@ -216,17 +218,17 @@ static int validate_vid_hdr(const struct ubi_vid_hdr
*vid_hdr,
av_vol_type = UBI_VID_DYNAMIC;
if (vol_type != av_vol_type) {
- ubi_err("inconsistent vol_type");
+ ubi_err(ubi, "inconsistent vol_type");
goto bad;
}
if (used_ebs != av->used_ebs) {
- ubi_err("inconsistent used_ebs");
+ ubi_err(ubi, "inconsistent used_ebs");
goto bad;
}
if (data_pad != av->data_pad) {
- ubi_err("inconsistent data_pad");
+ ubi_err(ubi, "inconsistent data_pad");
goto bad;
}
}
@@ -234,7 +236,7 @@ static int validate_vid_hdr(const struct ubi_vid_hdr
*vid_hdr,
return 0;
bad:
- ubi_err("inconsistent VID header at PEB %d", pnum);
+ ubi_err(ubi, "inconsistent VID header at PEB %d", pnum);
ubi_dump_vid_hdr(vid_hdr);
ubi_dump_av(av);
return -EINVAL;
@@ -336,7 +338,7 @@ int ubi_compare_lebs(struct ubi_device *ubi, const struct
ubi_ainf_peb *aeb,
* support these images anymore. Well, those images still work,
* but only if no unclean reboots happened.
*/
- ubi_err("unsupported on-flash UBI format");
+ ubi_err(ubi, "unsupported on-flash UBI format");
Re: [PATCH 3.2 000/102] 3.2.64-rc1 review
On Mon, 2014-11-03 at 11:32 +0100, Guillaume Nault wrote:
> On Sat, Nov 01, 2014 at 10:28:02PM +, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.2.64 release.
> > There are 102 patches in this series, which will be posted as responses
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> You might want to add eed4d839 "l2tp: fix race while getting PMTU on
> PPP pseudo-wire". It fixes f34c4a35 ("l2tp: take PMTU from tunnel UDP
> socket") which reached linux-3.2.y under commit 109d10d1.
>
> The 3.16.y, 3.14.y, 3.12.y and 3.10.y trees already applied the fix.
> Other stable/longterm trees which backported f34c4a35, like
> linux-3.4.y, should condider applying this fix too.
Good point, I've now added that to the queue.
Ben.
--
Ben Hutchings
Power corrupts. Absolute power is kind of neat.
- John Lehman, Secretary of the US Navy 1981-1987
signature.asc
Description: This is a digitally signed message part
Re: udev/hwdb support in pciutils (Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support)
Hi Martin, On Sat, Nov 1, 2014 at 6:51 PM, Martin Mares wrote: > The support for hwdb has finally landed in mainline pciutils. > > I have modified your patch to bring it closer to the rest of device > naming logic. Namely: Great! Thanks for merging this, and for working on it. > Aside of the README, everything should be ready for a public release. > Could you please verify that it still works for you? I can verify that it still works as expected, so it is good to go as far as I'm concerned. Cheers, Tom -- 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/8] perf tools: Add gzip decompression support for kernel module
On Mon, Nov 03, 2014 at 04:27:52PM +0900, Namhyung Kim wrote: SNIP > # > # Overhead Command Shared ObjectSymbol > # ... ... > .. > # > >0.04% kworker/u16:3[ext4] [k] > ext4_read_block_bitmap >0.03% kworker/u16:0[mac80211] [k] > ieee80211_sta_reset_beacon_monitor >0.02% irq/50-iwlwifi [mac80211] [k] > ieee80211_get_bssid >0.02% firefox [e1000e] [k] __ew32_prepare >0.02% swapper [libahci][k] > ahci_handle_port_interrupt >0.02% emacslibglib-2.0.so.0.4000.0 [.] g_mutex_unlock >0.02% swapper [e1000e] [k] > e1000_clean_tx_irq >0.02% dwm [kernel.kallsyms][k] __schedule >0.02% gnome-terminal- [vdso] [.] > __vdso_clock_gettime >0.02% swapper [e1000e] [k] > e1000_alloc_rx_buffers >0.02% irq/50-iwlwifi [mac80211] [k] ieee80211_rx >0.01% firefox [vdso] [.] > __vdso_gettimeofday >0.01% irq/50-iwlwifi [iwlwifi][k] > iwl_pcie_rxq_restock.part.13 > > Signed-off-by: Namhyung Kim > --- > tools/perf/Makefile.perf | 7 +++ > tools/perf/config/Makefile | 15 +- > tools/perf/config/feature-checks/Makefile| 6 ++- > tools/perf/config/feature-checks/test-zlib.c | 9 missing update for feature-checks/test-all.c thanks, jirka -- 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/8] perf tools: Preparation for compressed kernel module support
On Mon, Nov 03, 2014 at 04:27:51PM +0900, Namhyung Kim wrote:
SNIP
> +static int decompress_dummy(const char *input __maybe_unused,
> + int output __maybe_unused)
> +{
> + return -1;
> +}
> +
> +static const struct {
> + const char *fmt;
> + int (*decompress)(const char *input, int output);
> +} compressions[] = {
> + { "gz", decompress_dummy },
> +};
> +
> +bool is_supported_compression(const char *ext)
> +{
> + unsigned i;
> +
> + for (i = 0; i < ARRAY_SIZE(compressions); i++) {
> + if (!strcmp(ext, compressions[i].fmt))
> + return true;
> + }
> + return false;
> +}
> +
> +bool is_kmodule_extension(const char *ext)
> +{
> + if (!strcmp(ext, "ko"))
> + return true;
> +
> + if (ext[2] == '\0' || (ext[2] == '.' &&
> is_supported_compression(ext+3)))
> + return true;
I got stuck in here.. so any 2 chars string is kernel module extension?
plus how do u know ext[3] (or [2]) is valid memory?
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 091/102] KVM: x86: Emulator fixes for eip canonical checks on near branches
On Sun, 2014-11-02 at 10:44 +0200, Nadav Amit wrote:
> Sorry, but this patch is incomplete due to a bug.
> The following patch - http://www.spinics.net/lists/kvm/msg109664.html - is
> needed as well (on top of the previous one).
Thanks, I've added that (commit 7e466f6c).
Ben.
> Nadav
>
> > On Nov 2, 2014, at 00:28, Ben Hutchings wrote:
> >
> > 3.2.64-rc1 review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Nadav Amit
> >
> > commit 234f3ce485d54017f15cf5e0699cff4100121601 upstream.
> >
> > Before changing rip (during jmp, call, ret, etc.) the target should be
> > asserted
> > to be canonical one, as real CPUs do. During sysret, both target rsp and
> > rip
> > should be canonical. If any of these values is noncanonical, a #GP exception
> > should occur. The exception to this rule are syscall and sysenter
> > instructions
> > in which the assigned rip is checked during the assignment to the relevant
> > MSRs.
> >
> > This patch fixes the emulator to behave as real CPUs do for near branches.
> > Far branches are handled by the next patch.
> >
> > This fixes CVE-2014-3647.
> >
> > Signed-off-by: Nadav Amit
> > Signed-off-by: Paolo Bonzini
> > [bwh: Backported to 3.2:
> > - Adjust context
> > - Use ctxt->regs[] instead of reg_read(), reg_write(), reg_rmw()]
> > Signed-off-by: Ben Hutchings
> > ---
> > arch/x86/kvm/emulate.c | 78
> > ++
> > 1 file changed, 54 insertions(+), 24 deletions(-)
> >
> > --- a/arch/x86/kvm/emulate.c
> > +++ b/arch/x86/kvm/emulate.c
> > @@ -529,7 +529,8 @@ static int emulate_nm(struct x86_emulate
> > return emulate_exception(ctxt, NM_VECTOR, 0, false);
> > }
> >
> > -static inline void assign_eip_near(struct x86_emulate_ctxt *ctxt, ulong
> > dst)
> > +static inline int assign_eip_far(struct x86_emulate_ctxt *ctxt, ulong dst,
> > + int cs_l)
> > {
> > switch (ctxt->op_bytes) {
> > case 2:
> > @@ -539,16 +540,25 @@ static inline void assign_eip_near(struc
> > ctxt->_eip = (u32)dst;
> > break;
> > case 8:
> > + if ((cs_l && is_noncanonical_address(dst)) ||
> > + (!cs_l && (dst & ~(u32)-1)))
> > + return emulate_gp(ctxt, 0);
> > ctxt->_eip = dst;
> > break;
> > default:
> > WARN(1, "unsupported eip assignment size\n");
> > }
> > + return X86EMUL_CONTINUE;
> > +}
> > +
> > +static inline int assign_eip_near(struct x86_emulate_ctxt *ctxt, ulong dst)
> > +{
> > + return assign_eip_far(ctxt, dst, ctxt->mode == X86EMUL_MODE_PROT64);
> > }
> >
> > -static inline void jmp_rel(struct x86_emulate_ctxt *ctxt, int rel)
> > +static inline int jmp_rel(struct x86_emulate_ctxt *ctxt, int rel)
> > {
> > - assign_eip_near(ctxt, ctxt->_eip + rel);
> > + return assign_eip_near(ctxt, ctxt->_eip + rel);
> > }
> >
> > static u16 get_segment_selector(struct x86_emulate_ctxt *ctxt, unsigned seg)
> > @@ -1787,13 +1797,15 @@ static int em_grp45(struct x86_emulate_c
> > case 2: /* call near abs */ {
> > long int old_eip;
> > old_eip = ctxt->_eip;
> > - ctxt->_eip = ctxt->src.val;
> > + rc = assign_eip_near(ctxt, ctxt->src.val);
> > + if (rc != X86EMUL_CONTINUE)
> > + break;
> > ctxt->src.val = old_eip;
> > rc = em_push(ctxt);
> > break;
> > }
> > case 4: /* jmp abs */
> > - ctxt->_eip = ctxt->src.val;
> > + rc = assign_eip_near(ctxt, ctxt->src.val);
> > break;
> > case 5: /* jmp far */
> > rc = em_jmp_far(ctxt);
> > @@ -1825,10 +1837,14 @@ static int em_grp9(struct x86_emulate_ct
> >
> > static int em_ret(struct x86_emulate_ctxt *ctxt)
> > {
> > - ctxt->dst.type = OP_REG;
> > - ctxt->dst.addr.reg = >_eip;
> > - ctxt->dst.bytes = ctxt->op_bytes;
> > - return em_pop(ctxt);
> > + int rc;
> > + unsigned long eip;
> > +
> > + rc = emulate_pop(ctxt, , ctxt->op_bytes);
> > + if (rc != X86EMUL_CONTINUE)
> > + return rc;
> > +
> > + return assign_eip_near(ctxt, eip);
> > }
> >
> > static int em_ret_far(struct x86_emulate_ctxt *ctxt)
> > @@ -2060,7 +2076,7 @@ static int em_sysexit(struct x86_emulate
> > {
> > struct x86_emulate_ops *ops = ctxt->ops;
> > struct desc_struct cs, ss;
> > - u64 msr_data;
> > + u64 msr_data, rcx, rdx;
> > int usermode;
> > u16 cs_sel = 0, ss_sel = 0;
> >
> > @@ -2076,6 +2092,9 @@ static int em_sysexit(struct x86_emulate
> > else
> > usermode = X86EMUL_MODE_PROT32;
> >
> > + rcx = ctxt->regs[VCPU_REGS_RCX];
> > + rdx = ctxt->regs[VCPU_REGS_RDX];
> > +
> > cs.dpl = 3;
> > ss.dpl = 3;
> > ops->get_msr(ctxt, MSR_IA32_SYSENTER_CS, _data);
> > @@ -2093,6 +2112,9 @@ static int em_sysexit(struct x86_emulate
> > ss_sel = cs_sel + 8;
> > cs.d = 0;
>
Re: [PATCH] leds: leds-gpio: Convert gpio_blink_set() to use GPIO descriptors
On Fri, Oct 31, 2014 at 12:40 PM, Mika Westerberg
wrote:
> Commit 21f2aae91e902aad ("leds: leds-gpio: Add support for GPIO
> descriptors") already converted most of the driver to use GPIO descriptors.
> What is still missing is the platform specific hook gpio_blink_set() and
> board files which pass legacy GPIO numbers to this driver in platform data.
>
> In this patch we handle the former and convert gpio_blink_set() to take
> GPIO descriptor instead. In order to do this we convert the existing four
> users to accept GPIO descriptor and translate it to legacy GPIO number in
> the platform code. This effectively "pushes" legacy GPIO number usage from
> the driver to platforms.
>
> Also add comment to the remaining block describing that it is legacy code
> path and we are getting rid of it eventually.
>
> Suggested-by: Linus Walleij
> Signed-off-by: Mika Westerberg
Reviewed-by: Linus Walleij
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: [PATCH 3.2 087/102] nEPT: Nested INVEPT
On Sun, 2014-11-02 at 10:03 +0100, Paolo Bonzini wrote:
> You can just use the same scheme as your patch 88/102:
Why is that? Why should I not use the upstream version?
Ben.
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 685b8448d6e2..bd8cc9055fe2 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6740,6 +6740,12 @@ static int handle_vmptrst(struct kvm_vcpu *vcpu)
> return 1;
> }
>
> +static int handle_invept(struct kvm_vcpu *vcpu)
> +{
> + kvm_queue_exception(vcpu, UD_VECTOR);
> + return 1;
> +}
> +
> /*
> * The exit handlers return 1 if the exit was handled fully and guest
> execution
> * may resume. Otherwise they set the kvm_run parameter to indicate what
> needs
> @@ -6785,6 +6791,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct
> kvm_vcpu *vcpu) = {
> [EXIT_REASON_PAUSE_INSTRUCTION] = handle_pause,
> [EXIT_REASON_MWAIT_INSTRUCTION] = handle_invalid_op,
> [EXIT_REASON_MONITOR_INSTRUCTION] = handle_invalid_op,
> + [EXIT_REASON_INVEPT] = handle_invept,
> };
>
> static const int kvm_vmx_max_exit_handlers =
> @@ -7020,6 +7027,7 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu
> *vcpu)
> case EXIT_REASON_VMPTRST: case EXIT_REASON_VMREAD:
> case EXIT_REASON_VMRESUME: case EXIT_REASON_VMWRITE:
> case EXIT_REASON_VMOFF: case EXIT_REASON_VMON:
> + case EXIT_REASON_INVEPT:
> /*
>* VMX instructions trap unconditionally. This allows L1 to
>* emulate them for its L2 guest, i.e., allows 3-level nesting!
>
>
> Paolo
>
> On 01/11/2014 23:28, Ben Hutchings wrote:
> > 3.2.64-rc1 review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Nadav Har'El
> >
> > commit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream.
> >
> > If we let L1 use EPT, we should probably also support the INVEPT
> > instruction.
> >
> > In our current nested EPT implementation, when L1 changes its EPT table
> > for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in
> > the course of this modification already calls INVEPT. But if last level
> > of shadow page is unsync not all L1's changes to EPT12 are intercepted,
> > which means roots need to be synced when L1 calls INVEPT. Global INVEPT
> > should not be different since roots are synced by kvm_mmu_load() each
> > time EPTP02 changes.
> >
> > Reviewed-by: Xiao Guangrong
> > Signed-off-by: Nadav Har'El
> > Signed-off-by: Jun Nakajima
> > Signed-off-by: Xinhao Xu
> > Signed-off-by: Yang Zhang
> > Signed-off-by: Gleb Natapov
> > Signed-off-by: Paolo Bonzini
> > [bwh: Backported to 3.2:
> > - Adjust context, filename
> > - Add definition of nested_ept_get_cr3(), added upstream by commit
> >155a97a3d7c7 ("nEPT: MMU context for nested EPT")]
> > Signed-off-by: Ben Hutchings
> > ---
> > --- a/arch/x86/include/asm/vmx.h
> > +++ b/arch/x86/include/asm/vmx.h
> > @@ -279,6 +279,7 @@ enum vmcs_field {
> > #define EXIT_REASON_APIC_ACCESS 44
> > #define EXIT_REASON_EPT_VIOLATION 48
> > #define EXIT_REASON_EPT_MISCONFIG 49
> > +#define EXIT_REASON_INVEPT 50
> > #define EXIT_REASON_WBINVD 54
> > #define EXIT_REASON_XSETBV 55
> >
> > @@ -397,6 +398,7 @@ enum vmcs_field {
> > #define VMX_EPT_EXTENT_INDIVIDUAL_ADDR 0
> > #define VMX_EPT_EXTENT_CONTEXT 1
> > #define VMX_EPT_EXTENT_GLOBAL 2
> > +#define VMX_EPT_EXTENT_SHIFT 24
> >
> > #define VMX_EPT_EXECUTE_ONLY_BIT (1ull)
> > #define VMX_EPT_PAGE_WALK_4_BIT(1ull << 6)
> > @@ -404,6 +406,7 @@ enum vmcs_field {
> > #define VMX_EPTP_WB_BIT(1ull << 14)
> > #define VMX_EPT_2MB_PAGE_BIT (1ull << 16)
> > #define VMX_EPT_1GB_PAGE_BIT (1ull << 17)
> > +#define VMX_EPT_INVEPT_BIT (1ull << 20)
> > #define VMX_EPT_EXTENT_INDIVIDUAL_BIT (1ull << 24)
> > #define VMX_EPT_EXTENT_CONTEXT_BIT (1ull << 25)
> > #define VMX_EPT_EXTENT_GLOBAL_BIT (1ull << 26)
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -2869,6 +2869,7 @@ void kvm_mmu_sync_roots(struct kvm_vcpu
> > mmu_sync_roots(vcpu);
> > spin_unlock(>kvm->mmu_lock);
> > }
> > +EXPORT_SYMBOL_GPL(kvm_mmu_sync_roots);
> >
> > static gpa_t nonpaging_gva_to_gpa(struct kvm_vcpu *vcpu, gva_t vaddr,
> > u32 access, struct x86_exception *exception)
> > @@ -3131,6 +3132,7 @@ void kvm_mmu_flush_tlb(struct kvm_vcpu *
> > ++vcpu->stat.tlb_flush;
> > kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
> > }
> > +EXPORT_SYMBOL_GPL(kvm_mmu_flush_tlb);
> >
> > static void paging_new_cr3(struct kvm_vcpu *vcpu)
> > {
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -602,6 +602,7 @@ static void
Re: [PATCH V2] kernel, add bug_on_warn
On 10/30/2014 08:25 PM, Rusty Russell wrote:
> Prarit Bhargava writes:
>> On 10/22/2014 12:27 AM, Rusty Russell wrote:
>>> Prarit Bhargava writes:
There have been several times where I have had to rebuild a kernel to
cause a panic when hitting a WARN() in the code in order to get a crash
dump from a system. Sometimes this is easy to do, other times (such as
in the case of a remote admin) it is not trivial to send new images to the
user.
>>>
>>> What about during early boot?
>>
>> Hi Rusty,
>>
>> I really don't have a use case for this in early boot. The kernel boots, the
>> initramfs, and then we run whatever init (systemd in my case). A systemd
>> script
>> configures kexec for kdump and that point kdump is "armed". Doing a
>> bug_on_warn
>> before this will simply result in a panicked system. I don't get any "new"
>> information FWIW as I get a stack trace, etc., in both the WARN() and BUG()
>> cases.
>>
>>>
>>> I'd recommend you use core_param(). Less code, and can be set on
>>> commandline.
Yeah, I was just starting to do this and then I saw Hedi's comment about
disabling panic_on_warn during kdump to avoid a situation where the kdump kernel
bogus panics on a warn.
So that makes the setup function look like:
static int __init panic_on_warn_setup(char *s)
{
/* Enabling this on a kdump kernel could cause a bogus panic. */
if (!is_kdump_kernel())
panic_on_warn = 1;
return 0;
}
early_param("panic_on_warn", panic_on_warn_setup);
... so I dunno if core_param would work here :(. It would have been nice if it
did.
P.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] media: spi: Add support for LMH0395
On Monday 03 November 2014 14:36:26 Hans Verkuil wrote:
> On 11/03/2014 02:13 PM, Laurent Pinchart wrote:
> > Hi Jean-Michel,
> >
> > Thank you for the patch.
>
> > On Wednesday 10 September 2014 11:43:54 Jean-Michel Hautbois wrote:
>
>
> >> +static int lmh0395_s_routing(struct v4l2_subdev *sd, u32 input, u32
> >> output, + u32 config)
> >> +{
> >> + struct lmh0395_state *state = to_state(sd);
> >> + int err = 0;
> >> +
> >> + if (state->output_type != output)
> >> + err = lmh0395_set_output_type(sd, output);
> >> +
> >> + return err;
> >>
> > if (state->output_type == output)
> > return 0;
> >
> > return lmh0395_set_output_type(sd, output);
> >
> > You can then get rid of the err variable.
> >
> > I don't really like this implementation though, the output argument is
> > device- specific, you thus require explicit knowledge of the LMH0395 in
> > your bridge driver.
>
> Well, that's the way s_routing is defined. It's the bridge driver's job to
> translate between V4L2 inputs/outputs and low-level routing information.
>
> > I'm not sure what the config argument is used for, but naively I would
> > have
>
> config is normally not used. There are one or two drivers that need it for
> additional routing configuration, but it's rare.
OK.
> > used it to tell whether to enable (1) or disable (0) the route from input
> > to output. The input value should then always be 0, and the output value
> > can be 1 or 2. Another option would be to use the new S_ROUTING userspace
> > ioctl I've proposed in
> > http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/commit/?h=xilinx-wip
> > d=fc094c354338861673464ed4b8fa198089fe7bf0.
> >
> > Hans, could you comment on that ?
>
> Well, first of all your proposed API isn't merged yet, or even posted on the
> mailinglist, so it's a bit unfair to require someone else to use it :-)
It's not a requirement, just a proposal :-) I can send a patch series if
there's enough interest for using that API.
> Also, while I do agree with your proposed new API I am a lot less
> enthusiastic about creating yet another duplicate pad op for an existing
> audio/video routing op.
>
> The problem is that existing drivers are never updated for the new op and
> you are stuck with competing internal APIs. Not nice at all.
Agreed, it's not nice, feel free to propose a better solution :-)
> Bottom line is that this driver uses s_routing like any other driver
> currently in the kernel, so I have no problem with that.
I do :-)
The bridge to subdev dependency is fine for PCI or USB devices where the
hardware topology is known to the driver. It isn't for composite embedded
devices, as we don't want to teach all bridges about all subdevs.
--
Regards,
Laurent Pinchart
--
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 3/4] regulator: fixed: Use gpio_is_valid
On Mon, Oct 13, 2014 at 04:47:33PM +0200, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 03:47:07PM +0200, Markus Pargmann wrote:
> > Use gpio_is_valid instead of an explicit comparison with 0.
> >
> > Signed-off-by: Markus Pargmann
> > ---
> > drivers/regulator/fixed.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> > index 441a3e90e266..696f53cc1927 100644
> > --- a/drivers/regulator/fixed.c
> > +++ b/drivers/regulator/fixed.c
> > @@ -157,7 +157,7 @@ static int reg_fixed_voltage_probe(struct
> > platform_device *pdev)
> >
> > drvdata->desc.fixed_uV = config->microvolts;
> >
> > - if (config->gpio >= 0) {
> > + if (gpio_is_valid(config->gpio)) {
>
> Have you audited all users to ensure that they don't rely on zero being
> ignored? Right now we're sharing the core behaviour here so the same
> issues apply to this platform data as apply to the core.
For all other drivers this should be fine (just rechecked again). But
the fixed regulator driver patch has this problem.
Thanks,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [PATCH v4] media: spi: Add support for LMH0395
On 11/03/2014 02:13 PM, Laurent Pinchart wrote:
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Wednesday 10 September 2014 11:43:54 Jean-Michel Hautbois wrote:
>
>> +static int lmh0395_s_routing(struct v4l2_subdev *sd, u32 input, u32 output,
>> +u32 config)
>> +{
>> +struct lmh0395_state *state = to_state(sd);
>> +int err = 0;
>> +
>> +if (state->output_type != output)
>> +err = lmh0395_set_output_type(sd, output);
>> +
>> +return err;
>
> if (state->output_type == output)
> return 0;
>
> return lmh0395_set_output_type(sd, output);
>
> You can then get rid of the err variable.
>
> I don't really like this implementation though, the output argument is device-
> specific, you thus require explicit knowledge of the LMH0395 in your bridge
> driver.
Well, that's the way s_routing is defined. It's the bridge driver's job to
translate between V4L2 inputs/outputs and low-level routing information.
>
> I'm not sure what the config argument is used for, but naively I would have
config is normally not used. There are one or two drivers that need it for
additional routing configuration, but it's rare.
> used it to tell whether to enable (1) or disable (0) the route from input to
> output. The input value should then always be 0, and the output value can be
> 1
> or 2. Another option would be to use the new S_ROUTING userspace ioctl I've
> proposed in
> http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/commit/?h=xilinx-wip=fc094c354338861673464ed4b8fa198089fe7bf0.
>
> Hans, could you comment on that ?
Well, first of all your proposed API isn't merged yet, or even posted on the
mailinglist, so it's a bit unfair to require someone else to use it :-)
Also, while I do agree with your proposed new API I am a lot less enthusiastic
about creating yet another duplicate pad op for an existing audio/video routing
op.
The problem is that existing drivers are never updated for the new op and you
are
stuck with competing internal APIs. Not nice at all.
Bottom line is that this driver uses s_routing like any other driver currently
in the kernel, so I have no problem with that.
Regards,
Hans
>
>> +}
--
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 01/11] crypto: Documentation - crypto API high level spec
On Sun, 02 Nov 2014 21:35:11 +0100 Stephan Mueller wrote: > The design of the kernel crypto API as well as hints to program with > the kernel crypto API are given. Cool to see this, thanks. Please forgive me if I go into full grumpy editor mode here. There's a lot of good information here, but I think it could be made better with a bit of effort... > diff --git a/Documentation/crypto/crypto-API-spec.txt > b/Documentation/crypto/crypto-API-spec.txt > new file mode 100644 > index 000..8a24c98 > --- /dev/null > +++ b/Documentation/crypto/crypto-API-spec.txt > @@ -0,0 +1,721 @@ > +Kernel Crypto API Interface Specification > += > + > +The kernel crypto API offers a rich set of cryptographic ciphers as well as > +other data transformation mechanisms and methods to invoke these. This > document > +contains a description of the API and provides example code. > + > +To understand and properly use the kernel crypto API a brief explanation of > its > +structure is given. Based on the architecture, the API can be separated into > +different components. Following the architecture specification, hints to > +developers of ciphers are provided. Pointers to the API function call > +documentation are given at the end. > + > +The kernel crypto API refers to all algorithms as "transformation". > Therefore, a transformation*s* > +cipher handle variable usually has the name "tfm". Besides cryptographic > +operations, the kernel crypto API also knows compression transforms and > handles > +them the same way as ciphers. Should that be s/transforms/transformations/ to keep the terminology consistent? > +The kernel crypto API serves the following entity types: > + > + * consumers requesting cryptographic services > + > + * data transformation implementations (typically ciphers) that > + can be called by consumers using the kernel crypto API > + > +This specification is intended for consumers of the kernel crypto API as well > +as for developers implementing ciphers. This API specification, however, does > +not discusses all API calls available to data transformation implementations > +((i.e. implementations of ciphers and other transformations (such as CRC or > +even compression algorithms) that can register with the kernel crypto API). > + > +Note: The terms "transformation" and cipher algorithm are used > interchangably. > + > + > +Terminology > +--- > + > +The transformation implementation is an actual code or interface to hardware > +which implements a certain transformation with precisely defined behavior. > + > +The transformation object (TFM) is an instance of a transformation > +implementation. There can be multiple transformation objects associated with > +a single transformation implementation. Each of those transformation objects > +is held by a crypto API consumer or another transformation. Transformation > +object is allocated when a crypto API consumer requests a transformation > +implementation. The consumer is then provided with a structure, which > contains > +a transformation object (TFM). It seems like it would be good to show what this object is and how to allocate it here, rather than just teasing the reader saying it's possible? > +The transformation context is private data associated with the transformation > +object. > + > + > +Kernel Crypto API Architecture > +== > + > +Cipher algorithm types > +-- > + > +The kernel crypto API provides different API calls for the following cipher > +types: > + > + * Symmetric ciphers > + > + * AEAD ciphers > + > + * Message digest, including keyed message digest > + > + * Random number generation > + > + * User space interface > + > + > +Ciphers and Templates > +- > + > +The kernel crypto API provides implementations of single block ciphers and > +message digests. In addition, the kernel crypto API provides numerous > +"templates" that can be used in conjunction with the single block ciphers and > +message digests. Templates include all types of block chaining mode, the HMAC > +mechanism, etc. > + > +Single block ciphers and message digests can either be directly used by a > +caller or invoked together with a template to form multi-block ciphers or > keyed > +message digests. > + > +A single block cipher may even be called with multiple templates. However, > +templates cannot be used without a single cipher. > + > + > +Synchronous and asynchronous operation > +-- > + > +The kernel crypto API provides synchronous and asynchronous API operations. > + > +When using the synchronous API operation, the caller invokes a cipher > operation > +which is performed synchronously by the kernel crypto API. That means, the > +caller waits until the cipher operation completes. Therefore, the kernel > crypto > +API calls work like regular function calls. For synchronous
Re: [PATCH] kernel, add panic_on_warn
On 10/30/2014 09:58 PM, Hedi Berriche wrote: > On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote: > | There have been several times where I have had to rebuild a kernel to > | cause a panic when hitting a WARN() in the code in order to get a crash > | dump from a system. Sometimes this is easy to do, other times (such as > | in the case of a remote admin) it is not trivial to send new images to the > | user. > | > | A much easier method would be a switch to change the WARN() over to a > | panic. This makes debugging easier in that I can now test the actual > | image the WARN() was seen on and I do not have to engage in remote > | debugging. > > Do we want to leave it to usersspace[1] to ensure panic_on_warn is out > of the way in when the kdump kernel boots? or would a self-contained > approach be more preferable i.e. test whether we're a kdump kernel > before bothering with panic_on_warn? Hmm ... this is a good point. Vivek, do you have a preference? I'm willing to code it either way. I should be able to put in a is_kdump_kernel() check without any problems but I'm not sure if that is the right thing to do here. P. > > Cheers, > Hedi. > > [1] kexec-tools in the case of the boot param by filtering it out of the > kdump kernel cmdline. In the case of sysctl.conf, it would depend on > whether there are distros out there that include it in the kdump > initrd. > -- 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] x86: Surface Pro 3 Type Cover 3
On Fri, 31 Oct 2014, Alan Wu wrote:
> From: alanwu
>
> Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this
> thread. Both trackpad and keyboard work after compiling my own kernel.
> http://ubuntuforums.org/showthread.php?t=2231207=2=44910e0c56047e4f93dfd9fea58121ef
>
> Signed-off-by: alanwu
Hi Alan,
thanks for the patch.
For driver binding to work reliably and correctly, you also need to add
the device to hid_have_special_driver[] array in drivers/hid/hid-core.c.
Could you please fix that up and resend the patch?
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-microsoft.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index e23ab8b..15f32c2 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -648,6 +648,7 @@
> #define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
> #define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
> #define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
> +#define USB_DEVICE_ID_MS_TYPE_COVER_30x07dc
>
> #define USB_VENDOR_ID_MOJO 0x8282
> #define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
> index 8ba17a9..cacda43 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -274,6 +274,8 @@ static const struct hid_device_id ms_devices[] = {
> .driver_data = MS_NOGET },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
> .driver_data = MS_DUPLICATE_USAGES },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_TYPE_COVER_3),
> + .driver_data = MS_HIDINPUT },
>
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_PRESENTER_8K_BT),
> .driver_data = MS_PRESENTER },
> --
> 2.1.0
>
--
Jiri Kosina
SUSE Labs
--
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: ceph: Deletion of unnecessary checks before two function calls
> dput() also checks for NULL argument, but the check is wrapped into
> unlikely(), which is why I presume it wasn't picked up. It would be
> great if you could improve your coccinelle script to handle
> {un,}likely() as well.
Thanks for your suggestion.
Should I consider any more fine-tuning for the affected script
"list_input_parameter_validation1.cocci" in the near future?
https://lkml.org/lkml/2014/3/5/362
http://article.gmane.org/gmane.comp.version-control.coccinelle/3514
>> @@ -590,15 +589,13 @@ static void queue_realm_cap_snaps(struct
>> ceph_snap_realm
>> *realm)
>
> The patch was corrupted, that should have been a single line. I fixed
> it up but you may want to look into your email client settings.
Thanks for your feedback.
Does this example show a conflict between long comments after patch ranges and
line length limitation for email eventually?
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 6/8] regulator: max77686: Add external GPIO control
On Mon, Nov 03, 2014 at 01:07:02PM +0100, Krzysztof Kozlowski wrote: > On pią, 2014-10-31 at 10:32 +, Mark Brown wrote: > > We could always add a callback for the driver to handle any custom > > properties... one of the advantages of an OS like Linux is that we can > > improve the core code. > I thought about this - adding a callback, called on each child in > regulator_of_get_init_data(). However the reason behind this callback is > to parse GPIO and set config.ena_gpio. However in that context the > regulator_config is const so the callback cannot change it. Unless it > casts it to non-const... which isn't what we want I think. > So now I wonder whether adding generic bindings for ena_gpio make sense. > These would look like bindings for fixed-regulator (with "ena-" prefix). > Unfortunately this would duplicate a little the ena_gpio in > regulator_config... but to me it seems more appropriate. > What do you think about adding generic bindings for ena_gpio? Well, if you only want this for enable GPIO control (sorry, I'm really not reading a lot of these long threads when it looks like there'll be a resubmit anyway) we can always add a way for drivers to specify the name of a property to look at easily enough. signature.asc Description: Digital signature
Re: [PATCH 2/4] pinctrl: add helpers for group based drivers
On Thu, Oct 30, 2014 at 8:48 PM, Antoine Tenart wrote: > Maybe the of_pinctrl_utils_node_is_mux/config() solution is more > appropriate to avoid having a confusing function. Plus we would have a > dedicated of_pinctrl_utils_read_pins() function. > > I think I prefer the second solution because it could avoid some > confusion and the logic would stay in the pinctrl core functions. > > I'll cook up a new version if the of_pinctrl_utils_node_is_mux/config() > is okay with you. I'm following your idea and I agree. Let's see how that looks. 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: [PATCH v2 2/4] regulator: Set ena_gpio_initialized in regulator drivers
Hi, Sorry for the delay, holiday and so on. On Mon, Oct 13, 2014 at 04:42:35PM +0200, Mark Brown wrote: > On Wed, Oct 08, 2014 at 03:47:06PM +0200, Markus Pargmann wrote: > > > --- a/drivers/regulator/max8952.c > > +++ b/drivers/regulator/max8952.c > > @@ -225,6 +225,8 @@ static int max8952_pmic_probe(struct i2c_client *client, > > config.of_node = client->dev.of_node; > > > > config.ena_gpio = pdata->gpio_en; > > + if (!pdata) > > + config.ena_gpio_initialized = true; > > This looks wrong, we're checking for pdata being non-NULL immediately > after dereferencing pdata. Yes this is wrong, I changed it to check for client->dev.of_node instead. Thanks, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Sat, Oct 25, 2014 at 12:05 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Provide a way for device drivers using GPIOs described by ACPI
> GpioIo resources in _CRS to tell the GPIO subsystem what names
> (connection IDs) to associate with specific GPIO pins defined
> in there.
>
> To do that, a driver needs to define a mapping table as a
> NULL-terminated array of struct acpi_gpio_mapping objects
> that each contain a name, a pointer to an array of pin data
> (struct acpi_gpio_params) objects and the size of that array.
>
> Each struct acpi_gpio_params object consists of three fields,
> crs_entry_index, pin_index, active_low, representing the index of
I prefer that you call the second thing "line_index" rather than
"pin_index". Not all GPIOs in the world are tied to physical pins.
Also it is easy to confuse stuff with the pin control terminology
if it's called "pin".
> the target GpioIo()/GpioInt() resource in _CRS starting from zero,
> the index of the target pin in that resource starting from zero,
> and the active-low flag for that pin, respectively.
>
> Next, the mapping table needs to be passed as the second argument to
> acpi_dev_add_driver_gpios() that will register it with the ACPI device
> object pointed to by its first argument. That object must represent
> the ACPI namespace node containing the _CRS object referred to by the
> GPIO mapping. That should be done in the driver's .probe() routine.
>
> On removal, the driver should unregister its GPIO mapping table
> by calling acpi_dev_remove_driver_gpios() on the ACPI device
> object where that table was previously registered.
>
> Included are fixes from Mika Westerberg.
>
> Signed-off-by: Rafael J. Wysocki
And "pin" is mentioned several times in the commit message.
I prefer that we talk about "lines".
(...)
> +struct acpi_gpio_params {
> + unsigned int crs_entry_index;
> + unsigned int pin_index;
So line_index;
> + bool active_low;
> +};
With that change:
Reviewed-by: Linus Walleij
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: [PATCH 1/3] media: rc: add driver for Amlogic Meson IR remote receiver
Em Sun, 12 Oct 2014 22:01:53 +0200
Beniamino Galvani escreveu:
> Amlogic Meson SoCs include a infrared remote control receiver that can
> operate in two modes: in "NEC" mode the hardware can decode frames
> using the NEC IR protocol, while in "general" mode the receiver simply
> reports the duration of pulses and spaces for software decoding.
>
> This is a driver for the IR receiver that uses software decoding of
> received frames.
There are a few checkpatch warnings there:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#71:
new file mode 100644
WARNING: Missing a blank line after declarations
#151: FILE: drivers/media/rc/meson-ir.c:76:
+ u32 duration;
+ DEFINE_IR_RAW_EVENT(rawir);
WARNING: DT compatible string "amlogic,meson6-ir" appears un-documented --
check ./Documentation/devicetree/bindings/
#272: FILE: drivers/media/rc/meson-ir.c:197:
+ { .compatible = "amlogic,meson6-ir" },
total: 0 errors, 3 warnings, 238 lines checked
patches/lmml_26418_1_3_media_rc_add_driver_for_amlogic_meson_ir_remote_receiver.patch
has style problems, please review.
I'm seeing that the DT patches are there, after this one. The best
would be to add them before in the series.
Please add also an entry at the MAINTAINERS file.
>
> Signed-off-by: Beniamino Galvani
> ---
> drivers/media/rc/Kconfig| 11 +++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/meson-ir.c | 214
>
> 3 files changed, 226 insertions(+)
> create mode 100644 drivers/media/rc/meson-ir.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 8ce0810..2d742e2 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -223,6 +223,17 @@ config IR_FINTEK
> To compile this driver as a module, choose M here: the
> module will be called fintek-cir.
>
> +config IR_MESON
> + tristate "Amlogic Meson IR remote receiver"
> + depends on RC_CORE
> + depends on ARCH_MESON
Please add COMPILE_TEST too, as we want to be able to compile it on
x86 and other archs, in order to check if the driver builds fine and
to enable the static analyzers to look into this code.
> + ---help---
> +Say Y if you want to use the IR remote receiver available
> +on Amlogic Meson SoCs.
> +
> +To compile this driver as a module, choose M here: the
> +module will be called meson-ir.
> +
> config IR_NUVOTON
> tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
> depends on PNP
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 0989f94..06859bf 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_IR_IMON) += imon.o
> obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
> obj-$(CONFIG_IR_MCEUSB) += mceusb.o
> obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
> +obj-$(CONFIG_IR_MESON) += meson-ir.o
> obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
> obj-$(CONFIG_IR_ENE) += ene_ir.o
> obj-$(CONFIG_IR_REDRAT3) += redrat3.o
> diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> new file mode 100644
> index 000..0900ece
> --- /dev/null
> +++ b/drivers/media/rc/meson-ir.c
> @@ -0,0 +1,214 @@
> +/*
> + * Driver for Amlogic Meson IR remote receiver
> + *
> + * Copyright (C) 2014 Beniamino Galvani
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH v4] media: spi: Add support for LMH0395
Hi Jean-Michel,
Thank you for the patch.
On Wednesday 10 September 2014 11:43:54 Jean-Michel Hautbois wrote:
> This device is a SPI based device from TI.
> It is a 3 Gbps HD/SD SDI Dual Output Low Power
> Extended Reach Adaptive Cable Equalizer.
>
> LMH0395 enables the use of up to two outputs.
> These can be configured using DT.
>
> Controls should be accessible from userspace too.
> This will have to be done later.
>
> v2: Add DT support
> v3: Change the bit set/clear in output_type as disabled means 'set the bit'
> v4: Clearer description of endpoints usage in Doc, and some init changes.
> Add a dependency on OF and don't test CONFIG_OF anymore.
>
> Signed-off-by: Jean-Michel Hautbois
> ---
> .../devicetree/bindings/media/spi/lmh0395.txt | 48 +++
> MAINTAINERS| 6 +
> drivers/media/spi/Kconfig | 14 +
> drivers/media/spi/Makefile | 1 +
> drivers/media/spi/lmh0395.c| 354 ++
> 5 files changed, 423 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
> create mode 100644 drivers/media/spi/Kconfig
> create mode 100644 drivers/media/spi/Makefile
> create mode 100644 drivers/media/spi/lmh0395.c
>
> diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
> b/Documentation/devicetree/bindings/media/spi/lmh0395.txt new file mode
> 100644
> index 000..7cc0026
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
> @@ -0,0 +1,48 @@
> +* Texas Instruments lmh0395 3G HD/SD SDI equalizer
> +
> +The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
> +Cable Equalizer is designed to equalize data transmitted over cable (or any
> +media with similar dispersive loss characteristics).
> +The equalizer operates over a wide range of data rates from 125 Mbps to
> 2.97 Gbps
> +and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
> standards.
That's copied verbatim from the datasheet and not very relevant from a DT
bindings point of view. I would rather explain what the chip does. Something
like
"The LMH0395 is an SDI equalizer designed to extend the reach of SDI signals
transmitted over cable by equalizing the input signal and generating clean
outputs. It has one differential input and two differential output that can be
independently controlled."
> +
> +Required Properties :
> +- compatible: Must be "ti,lmh0395"
> +
> +The device node must contain one 'port' child node per device input and
> output
> +port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The port
> nodes
> +are numbered as follows.
> +
> + Port LMH0395
> +
> + SDI input 0
> + SDI output 1,2
While there shouldn't be much doubt about SDO0 corresponding to port 1 and
SDO1 to port 2, I'd like that to be mentioned explicitly.
The device node must contain one 'port' child node per device input and output
port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The LMH0395 has three ports numbered as follows.
DescriptionNumber
SDI (SDI input) 0
SDO0 (SDI output 0) 1
SDO1 (SDI output 1) 2
> +Example:
> +
> +ecspi@0201 {
> + ...
> + ...
> +
> + lmh0395@1 {
> + compatible = "ti,lmh0395";
> + reg = <1>;
> + spi-max-frequency = <2000>;
> + ports {
You need to add
#address-cells = <1>;
#size-cells = <0>;
here.
> + port@0 {
> + reg = <0>;
> + sdi0_in: endpoint {};
> + };
> + port@1 {
> + reg = <1>;
> + sdi0_out0: endpoint {};
> + };
> + port@2 {
> + reg = <2>;
> + /* endpoint not specified, disable output */
> + };
> + };
> + };
> + ...
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cf24bb5..ca42b9e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9141,6 +9141,12 @@ S: Maintained
> F: sound/soc/codecs/lm49453*
> F: sound/soc/codecs/isabelle*
>
> +TI LMH0395 DRIVER
> +M: Jean-Michel Hautbois
> +L: linux-me...@vger.kernel.org
> +S: Maintained
> +F: drivers/media/spi/lmh0395*
> +
> TI LP855x BACKLIGHT DRIVER
> M: Milo Kim
> S: Maintained
> diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
> new file mode 100644
> index 000..bcb1ab1
> --- /dev/null
> +++ b/drivers/media/spi/Kconfig
> @@ -0,0 +1,14 @@
> +if VIDEO_V4L2
> +
Re: [PATCH 4/7] perf tools: Enhance the thread stack to output call/return data
On Thu, Oct 30, 2014 at 04:09:45PM +0200, Adrian Hunter wrote: > Enhance the thread stack to output detailed information > about paired calls and returns. > > The enhanced processing consumes sample information via > thread_stack__process() and outputs information about > paired calls / returns via a call-back. While the > call-back makes it possible for the facility to be used > by arbitrary tools, a subsequent patch will provide the > information to Python scripting via the db-export > interface. > > An important part of the call/return information is the > call path which provides a structure that defines a context > sensitive call graph. > > Note that there are now two ways to use the thread stack. > For simply providing a call stack (like you would get > from the perf record -g option) the interface consists of > thread_stack__event() and thread_stack__sample(). Whereas > the enhanced interface consists of call_return_processor__new() > and thread_stack__process(). the interface seems pretty separated, with clear in and out values, so it should be fairly easy to write automated tests for that ;-) also given that there's no real user of this interface at the moment, it'd be really nice to have ;-) anyway Acked-by: Jiri Olsa jirka -- 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] mfd: intel_quark_i2c_gpio: Add Intel Quark X1000 I2C-GPIO MFD Driver
On Mon, 03 Nov 2014, Andy Shevchenko wrote:
> On Mon, 2014-11-03 at 15:39 +0800, Raymond Tan wrote:
> > In Quark X1000, there's a single PCI device that provides both
> > an I2C controller and a GPIO controller. This MFD driver will
> > split the 2 devices for their respective drivers.
> >
> > This patch is based on Josef Ahmad's initial work for Quark enabling.
>
> Few comments below.
>
> After addressing take my
> Reviewed-by: Andy Shevchenko
[...]
> > +static const struct i2c_mode_info platform_i2c_mode_info[] = {
> > + {
> > + .name = "Galileo",
> > + .i2c_scl_freq = 10,
> > + },
> > + {
> > + .name = "GalileoGen2",
> > + .i2c_scl_freq = 40,
> > + },
>
> You can decrease indentation level if you want to by using
>
> = {{
> }, {
> }};
>
> Though I don't know if Lee likes it :-)
No, please don't do that.
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 05/18] x86: Use new cache mode type in arch/x86/pci
Instead of directly using the cache mode bits in the pte switch to using the cache mode type. Based-on-patch-by: Stefan Bader Signed-off-by: Juergen Gross Reviewed-by: Thomas Gleixner --- arch/x86/pci/i386.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c index 37c1435..9b18ef3 100644 --- a/arch/x86/pci/i386.c +++ b/arch/x86/pci/i386.c @@ -433,14 +433,14 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma, return -EINVAL; if (pat_enabled && write_combine) - prot |= _PAGE_CACHE_WC; + prot |= cachemode2protval(_PAGE_CACHE_MODE_WC); else if (pat_enabled || boot_cpu_data.x86 > 3) /* * ioremap() and ioremap_nocache() defaults to UC MINUS for now. * To avoid attribute conflicts, request UC MINUS here * as well. */ - prot |= _PAGE_CACHE_UC_MINUS; + prot |= cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS); vma->vm_page_prot = __pgprot(prot); -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 10/18] x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c
When modifying page attributes via change_page_attr_set_clr() don't
test for setting _PAGE_PAT_LARGE, as this is
- never done
- PAT support for large pages is not included in the kernel up to now
Signed-off-by: Juergen Gross
---
arch/x86/mm/pageattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index ae242a7..87c0d36 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1307,7 +1307,7 @@ static int __change_page_attr_set_clr(struct cpa_data
*cpa, int checkalias)
static inline int cache_attr(pgprot_t attr)
{
return pgprot_val(attr) &
- (_PAGE_PAT | _PAGE_PAT_LARGE | _PAGE_PWT | _PAGE_PCD);
+ (_PAGE_PAT | _PAGE_PWT | _PAGE_PCD);
}
static int change_page_attr_set_clr(unsigned long *addr, int numpages,
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 00/18] x86: Full support of PAT
The x86 architecture offers via the PAT (Page Attribute Table) a way to specify different caching modes in page table entries. The PAT MSR contains 8 entries each specifying one of 6 possible cache modes. A pte references one of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD. The Linux kernel currently supports only 4 different cache modes. The PAT MSR is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the top 4 entries in the PAT MSR are the same as the 4 lower entries. This results in the kernel not supporting e.g. write-through mode. Especially this cache mode would speed up drivers of video cards which now have to use uncached accesses. OTOH some old processors (Pentium) don't support PAT correctly and the Xen hypervisor has been using a different PAT MSR configuration for some time now and can't change that as this setting is part of the ABI. This patch set abstracts the cache mode from the pte and introduces tables to translate between cache mode and pte bits (the default cache mode "write back" is hard-wired to PAT entry 0). The tables are statically initialized with values being compatible to old processors and current usage. As soon as the PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are changed accordingly. Requests of mappings with special cache modes are always possible now, in case they are not supported there will be a fallback to a compatible but slower mode. Summing it up, this patch set adds the following features: - capability to support WT and WP cache modes on processors with full PAT support - processors with no or uncorrect PAT support are still working as today, even if WT or WP cache mode are selected by drivers for some pages - reduction of Xen special handling regarding cache mode Changes in V6: - add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c) as suggested by Thomas Gleixner - replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by Borislav Petkov Changes in V5: - split up first patch as requested by Ingo Molnar and Thomas Gleixner - add a helper function in pat_init_cache_modes() as requested by Ingo Molnar Changes in V4: - rebased to 3.18-rc2 Changes in V3: - corrected two minor nits (UC_MINUS, again) detected by Toshi Kani Changes in V2: - simplified handling of PAT MSR write under Xen as suggested by David Vrabel - removed resetting of pat_enabled under Xen - two small corrections requested by Toshi Kani (UC_MINUS cache mode in vermilion driver, fix 32 bit kernel build failure) - correct build error on non-x86 arch by moving definition of update_cache_mode_entry() to x86 specific header Changes since RFC: - renamed functions and variables as suggested by Toshi Kani - corrected cache mode bits for WT and WP - modified handling of PAT MSR write under Xen as suggested by Jan Beulich Juergen Gross (18): x86: Make page cache mode a real type x86: Use new cache mode type in include/asm/fb.h x86: Use new cache mode type in drivers/video/fbdev/gbefb.c x86: Use new cache mode type in drivers/video/fbdev/vermilion x86: Use new cache mode type in arch/x86/pci x86: Use new cache mode type in arch/x86/mm/init_64.c x86: Use new cache mode type in asm/pgtable.h x86: Use new cache mode type in mm/iomap_32.c x86: Use new cache mode type in track_pfn_remap() and track_pfn_insert() x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c x86: Use new cache mode type in setting page attributes x86: Use new cache mode type in mm/ioremap.c x86: Use new cache mode type in memtype related functions x86: Clean up pgtable_types.h x86: Support PAT bit in pagetable dump for lower levels x86: Respect PAT bit when copying pte values between large and normal pages x86: Enable PAT to use cache mode translation tables xen: Support Xen pv-domains using PAT arch/x86/include/asm/cacheflush.h | 38 --- arch/x86/include/asm/fb.h | 6 +- arch/x86/include/asm/io.h | 2 +- arch/x86/include/asm/pat.h| 7 +- arch/x86/include/asm/pgtable.h| 19 ++-- arch/x86/include/asm/pgtable_types.h | 96 arch/x86/mm/dump_pagetables.c | 24 ++-- arch/x86/mm/init.c| 37 +++ arch/x86/mm/init_64.c | 9 +- arch/x86/mm/iomap_32.c| 12 +- arch/x86/mm/ioremap.c | 63 ++- arch/x86/mm/mm_internal.h | 2 + arch/x86/mm/pageattr.c| 84 -- arch/x86/mm/pat.c | 176 +++--- arch/x86/mm/pat_internal.h| 22 ++-- arch/x86/mm/pat_rbtree.c | 8 +- arch/x86/pci/i386.c | 4 +- arch/x86/xen/enlighten.c | 25 ++--- arch/x86/xen/mmu.c| 47 +---
[PATCH V6 04/18] x86: Use new cache mode type in drivers/video/fbdev/vermilion
Instead of directly using the cache mode bits in the pte switch to using the cache mode type. Based-on-patch-by: Stefan Bader Signed-off-by: Juergen Gross Reviewed-by: Thomas Gleixner --- drivers/video/fbdev/vermilion/vermilion.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/vermilion/vermilion.c b/drivers/video/fbdev/vermilion/vermilion.c index 5f930ae..6b70d7f 100644 --- a/drivers/video/fbdev/vermilion/vermilion.c +++ b/drivers/video/fbdev/vermilion/vermilion.c @@ -1003,13 +1003,15 @@ static int vmlfb_mmap(struct fb_info *info, struct vm_area_struct *vma) struct vml_info *vinfo = container_of(info, struct vml_info, info); unsigned long offset = vma->vm_pgoff << PAGE_SHIFT; int ret; + unsigned long prot; ret = vmlfb_vram_offset(vinfo, offset); if (ret) return -EINVAL; - pgprot_val(vma->vm_page_prot) |= _PAGE_PCD; - pgprot_val(vma->vm_page_prot) &= ~_PAGE_PWT; + prot = pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK; + pgprot_val(vma->vm_page_prot) = + prot | cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS); return vm_iomap_memory(vma, vinfo->vram_start, vinfo->vram_contig_size); -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 08/18] x86: Use new cache mode type in mm/iomap_32.c
Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. This requires to change
io_reserve_memtype() as well.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/include/asm/pat.h | 2 +-
arch/x86/mm/iomap_32.c | 12 +++-
arch/x86/mm/pat.c | 18 ++
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index e2c1668..a8438bc 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -20,7 +20,7 @@ extern int kernel_map_sync_memtype(u64 base, unsigned long
size,
unsigned long flag);
int io_reserve_memtype(resource_size_t start, resource_size_t end,
- unsigned long *type);
+ enum page_cache_mode *pcm);
void io_free_memtype(resource_size_t start, resource_size_t end);
diff --git a/arch/x86/mm/iomap_32.c b/arch/x86/mm/iomap_32.c
index 7b179b49..9ca35fc 100644
--- a/arch/x86/mm/iomap_32.c
+++ b/arch/x86/mm/iomap_32.c
@@ -33,17 +33,17 @@ static int is_io_mapping_possible(resource_size_t base,
unsigned long size)
int iomap_create_wc(resource_size_t base, unsigned long size, pgprot_t *prot)
{
- unsigned long flag = _PAGE_CACHE_WC;
+ enum page_cache_mode pcm = _PAGE_CACHE_MODE_WC;
int ret;
if (!is_io_mapping_possible(base, size))
return -EINVAL;
- ret = io_reserve_memtype(base, base + size, );
+ ret = io_reserve_memtype(base, base + size, );
if (ret)
return ret;
- *prot = __pgprot(__PAGE_KERNEL | flag);
+ *prot = __pgprot(__PAGE_KERNEL | cachemode2protval(pcm));
return 0;
}
EXPORT_SYMBOL_GPL(iomap_create_wc);
@@ -82,8 +82,10 @@ iomap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot)
* MTRR is UC or WC. UC_MINUS gets the real intention, of the
* user, which is "WC if the MTRR is WC, UC if you can't do that."
*/
- if (!pat_enabled && pgprot_val(prot) == pgprot_val(PAGE_KERNEL_WC))
- prot = PAGE_KERNEL_UC_MINUS;
+ if (!pat_enabled && pgprot_val(prot) ==
+ (__PAGE_KERNEL | cachemode2protval(_PAGE_CACHE_MODE_WC)))
+ prot = __pgprot(__PAGE_KERNEL |
+ cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS));
return (void __force __iomem *) kmap_atomic_prot_pfn(pfn, prot);
}
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 47282c2..6d5a8e3 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -442,25 +442,27 @@ static unsigned long lookup_memtype(u64 paddr)
* On failure, returns non-zero
*/
int io_reserve_memtype(resource_size_t start, resource_size_t end,
- unsigned long *type)
+ enum page_cache_mode *type)
{
resource_size_t size = end - start;
- unsigned long req_type = *type;
- unsigned long new_type;
+ enum page_cache_mode req_type = *type;
+ enum page_cache_mode new_type;
+ unsigned long new_prot;
int ret;
WARN_ON_ONCE(iomem_map_sanity_check(start, size));
- ret = reserve_memtype(start, end, req_type, _type);
+ ret = reserve_memtype(start, end, cachemode2protval(req_type),
+ _prot);
if (ret)
goto out_err;
- if (!is_new_memtype_allowed(start, size,
- pgprot2cachemode(__pgprot(req_type)),
- pgprot2cachemode(__pgprot(new_type
+ new_type = pgprot2cachemode(__pgprot(new_prot));
+
+ if (!is_new_memtype_allowed(start, size, req_type, new_type))
goto out_free;
- if (kernel_map_sync_memtype(start, size, new_type) < 0)
+ if (kernel_map_sync_memtype(start, size, new_prot) < 0)
goto out_free;
*type = new_type;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] perf tools: Add a thread stack for synthesizing call chains
On Thu, Oct 30, 2014 at 04:09:42PM +0200, Adrian Hunter wrote: > Add a thread stack for synthesizing call chains from call > and return events. > > Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa jirka -- 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 11/18] x86: Use new cache mode type in setting page attributes
Instead of directly using the cache mode bits in the pte switch to
using the cache mode type in the functions for modifying page
attributes.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/mm/pageattr.c | 52 +++---
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 87c0d36..9f7e1b4 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1304,12 +1304,6 @@ static int __change_page_attr_set_clr(struct cpa_data
*cpa, int checkalias)
return 0;
}
-static inline int cache_attr(pgprot_t attr)
-{
- return pgprot_val(attr) &
- (_PAGE_PAT | _PAGE_PWT | _PAGE_PCD);
-}
-
static int change_page_attr_set_clr(unsigned long *addr, int numpages,
pgprot_t mask_set, pgprot_t mask_clr,
int force_split, int in_flag,
@@ -1390,7 +1384,7 @@ static int change_page_attr_set_clr(unsigned long *addr,
int numpages,
* No need to flush, when we did not set any of the caching
* attributes:
*/
- cache = cache_attr(mask_set);
+ cache = !!pgprot2cachemode(mask_set);
/*
* On success we use CLFLUSH, when the CPU supports it to
@@ -1445,7 +1439,8 @@ int _set_memory_uc(unsigned long addr, int numpages)
* for now UC MINUS. see comments in ioremap_nocache()
*/
return change_page_attr_set(, numpages,
- __pgprot(_PAGE_CACHE_UC_MINUS), 0);
+ cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+ 0);
}
int set_memory_uc(unsigned long addr, int numpages)
@@ -1474,7 +1469,7 @@ out_err:
EXPORT_SYMBOL(set_memory_uc);
static int _set_memory_array(unsigned long *addr, int addrinarray,
- unsigned long new_type)
+ enum page_cache_mode new_type)
{
int i, j;
int ret;
@@ -1484,17 +1479,19 @@ static int _set_memory_array(unsigned long *addr, int
addrinarray,
*/
for (i = 0; i < addrinarray; i++) {
ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) + PAGE_SIZE,
- new_type, NULL);
+ cachemode2protval(new_type), NULL);
if (ret)
goto out_free;
}
ret = change_page_attr_set(addr, addrinarray,
- __pgprot(_PAGE_CACHE_UC_MINUS), 1);
+ cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+ 1);
- if (!ret && new_type == _PAGE_CACHE_WC)
+ if (!ret && new_type == _PAGE_CACHE_MODE_WC)
ret = change_page_attr_set_clr(addr, addrinarray,
- __pgprot(_PAGE_CACHE_WC),
+ cachemode2pgprot(
+ _PAGE_CACHE_MODE_WC),
__pgprot(_PAGE_CACHE_MASK),
0, CPA_ARRAY, NULL);
if (ret)
@@ -1511,13 +1508,13 @@ out_free:
int set_memory_array_uc(unsigned long *addr, int addrinarray)
{
- return _set_memory_array(addr, addrinarray, _PAGE_CACHE_UC_MINUS);
+ return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_UC_MINUS);
}
EXPORT_SYMBOL(set_memory_array_uc);
int set_memory_array_wc(unsigned long *addr, int addrinarray)
{
- return _set_memory_array(addr, addrinarray, _PAGE_CACHE_WC);
+ return _set_memory_array(addr, addrinarray, _PAGE_CACHE_MODE_WC);
}
EXPORT_SYMBOL(set_memory_array_wc);
@@ -1527,10 +1524,12 @@ int _set_memory_wc(unsigned long addr, int numpages)
unsigned long addr_copy = addr;
ret = change_page_attr_set(, numpages,
- __pgprot(_PAGE_CACHE_UC_MINUS), 0);
+ cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
+ 0);
if (!ret) {
ret = change_page_attr_set_clr(_copy, numpages,
- __pgprot(_PAGE_CACHE_WC),
+ cachemode2pgprot(
+ _PAGE_CACHE_MODE_WC),
__pgprot(_PAGE_CACHE_MASK),
0, 0, NULL);
}
@@ -1564,6 +1563,7 @@ EXPORT_SYMBOL(set_memory_wc);
int _set_memory_wb(unsigned long addr, int numpages)
{
+ /* WB cache mode is hard wired to all cache attribute bits being 0 */
return change_page_attr_clear(, numpages,
__pgprot(_PAGE_CACHE_MASK), 0);
}
@@ -1586,6 +1586,7 @@ int set_memory_array_wb(unsigned long
[PATCH V6 06/18] x86: Use new cache mode type in arch/x86/mm/init_64.c
Instead of directly using the cache mode bits in the pte switch to
using the cache mode type.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/mm/init_64.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 4cb8763..5390a5f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -338,12 +338,15 @@ pte_t * __init populate_extra_pte(unsigned long vaddr)
* Create large page table mappings for a range of physical addresses.
*/
static void __init __init_extra_mapping(unsigned long phys, unsigned long size,
- pgprot_t prot)
+ enum page_cache_mode cache)
{
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
+ pgprot_t prot;
+ pgprot_val(prot) = pgprot_val(PAGE_KERNEL_LARGE) |
+ pgprot_val(pgprot_4k_2_large(cachemode2pgprot(cache)));
BUG_ON((phys & ~PMD_MASK) || (size & ~PMD_MASK));
for (; size; phys += PMD_SIZE, size -= PMD_SIZE) {
pgd = pgd_offset_k((unsigned long)__va(phys));
@@ -366,12 +369,12 @@ static void __init __init_extra_mapping(unsigned long
phys, unsigned long size,
void __init init_extra_mapping_wb(unsigned long phys, unsigned long size)
{
- __init_extra_mapping(phys, size, PAGE_KERNEL_LARGE);
+ __init_extra_mapping(phys, size, _PAGE_CACHE_MODE_WB);
}
void __init init_extra_mapping_uc(unsigned long phys, unsigned long size)
{
- __init_extra_mapping(phys, size, PAGE_KERNEL_LARGE_NOCACHE);
+ __init_extra_mapping(phys, size, _PAGE_CACHE_MODE_UC);
}
/*
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 07/18] x86: Use new cache mode type in asm/pgtable.h
Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. This requires changing some callers of
is_new_memtype_allowed() to be changed as well.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/include/asm/pgtable.h | 19 ++-
arch/x86/mm/ioremap.c | 3 ++-
arch/x86/mm/pat.c | 8 ++--
3 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index aa97a07..c112ea6 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -9,9 +9,10 @@
/*
* Macro to mark a page protection value as UC-
*/
-#define pgprot_noncached(prot) \
- ((boot_cpu_data.x86 > 3)\
-? (__pgprot(pgprot_val(prot) | _PAGE_CACHE_UC_MINUS)) \
+#define pgprot_noncached(prot) \
+ ((boot_cpu_data.x86 > 3)\
+? (__pgprot(pgprot_val(prot) | \
+cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS))) \
: (prot))
#ifndef __ASSEMBLY__
@@ -404,8 +405,8 @@ static inline pgprot_t pgprot_modify(pgprot_t oldprot,
pgprot_t newprot)
#define canon_pgprot(p) __pgprot(massage_pgprot(p))
static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
-unsigned long flags,
-unsigned long new_flags)
+enum page_cache_mode pcm,
+enum page_cache_mode new_pcm)
{
/*
* PAT type is always WB for untracked ranges, so no need to check.
@@ -419,10 +420,10 @@ static inline int is_new_memtype_allowed(u64 paddr,
unsigned long size,
* - request is uncached, return cannot be write-back
* - request is write-combine, return cannot be write-back
*/
- if ((flags == _PAGE_CACHE_UC_MINUS &&
-new_flags == _PAGE_CACHE_WB) ||
- (flags == _PAGE_CACHE_WC &&
-new_flags == _PAGE_CACHE_WB)) {
+ if ((pcm == _PAGE_CACHE_MODE_UC_MINUS &&
+new_pcm == _PAGE_CACHE_MODE_WB) ||
+ (pcm == _PAGE_CACHE_MODE_WC &&
+new_pcm == _PAGE_CACHE_MODE_WB)) {
return 0;
}
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index af78e50..3a81eb9 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -142,7 +142,8 @@ static void __iomem *__ioremap_caller(resource_size_t
phys_addr,
if (prot_val != new_prot_val) {
if (!is_new_memtype_allowed(phys_addr, size,
- prot_val, new_prot_val)) {
+ pgprot2cachemode(__pgprot(prot_val)),
+ pgprot2cachemode(__pgprot(new_prot_val {
printk(KERN_ERR
"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",
(unsigned long long)phys_addr,
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6574388..47282c2 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -455,7 +455,9 @@ int io_reserve_memtype(resource_size_t start,
resource_size_t end,
if (ret)
goto out_err;
- if (!is_new_memtype_allowed(start, size, req_type, new_type))
+ if (!is_new_memtype_allowed(start, size,
+ pgprot2cachemode(__pgprot(req_type)),
+ pgprot2cachemode(__pgprot(new_type
goto out_free;
if (kernel_map_sync_memtype(start, size, new_type) < 0)
@@ -630,7 +632,9 @@ static int reserve_pfn_range(u64 paddr, unsigned long size,
pgprot_t *vma_prot,
if (flags != want_flags) {
if (strict_prot ||
- !is_new_memtype_allowed(paddr, size, want_flags, flags)) {
+ !is_new_memtype_allowed(paddr, size,
+ pgprot2cachemode(__pgprot(want_flags)),
+ pgprot2cachemode(__pgprot(flags {
free_memtype(paddr, paddr + size);
printk(KERN_ERR "%s:%d map pfn expected mapping type %s"
" for [mem %#010Lx-%#010Lx], got %s\n",
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 09/18] x86: Use new cache mode type in track_pfn_remap() and track_pfn_insert()
Instead of directly using the cache mode bits in the pte switch to
using the cache mode type. As those are the main callers of
lookup_memtype(), change this as well.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/mm/pat.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6d5a8e3..2f3744f 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -394,12 +394,12 @@ int free_memtype(u64 start, u64 end)
*
* Only to be called when PAT is enabled
*
- * Returns _PAGE_CACHE_WB, _PAGE_CACHE_WC, _PAGE_CACHE_UC_MINUS or
- * _PAGE_CACHE_UC
+ * Returns _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC, _PAGE_CACHE_MODE_UC_MINUS
+ * or _PAGE_CACHE_MODE_UC
*/
-static unsigned long lookup_memtype(u64 paddr)
+static enum page_cache_mode lookup_memtype(u64 paddr)
{
- int rettype = _PAGE_CACHE_WB;
+ enum page_cache_mode rettype = _PAGE_CACHE_MODE_WB;
struct memtype *entry;
if (x86_platform.is_untracked_pat_range(paddr, paddr + PAGE_SIZE))
@@ -408,13 +408,13 @@ static unsigned long lookup_memtype(u64 paddr)
if (pat_pagerange_is_ram(paddr, paddr + PAGE_SIZE)) {
struct page *page;
page = pfn_to_page(paddr >> PAGE_SHIFT);
- rettype = get_page_memtype(page);
+ rettype = pgprot2cachemode(__pgprot(get_page_memtype(page)));
/*
* -1 from get_page_memtype() implies RAM page is in its
* default state and not reserved, and hence of type WB
*/
if (rettype == -1)
- rettype = _PAGE_CACHE_WB;
+ rettype = _PAGE_CACHE_MODE_WB;
return rettype;
}
@@ -423,9 +423,9 @@ static unsigned long lookup_memtype(u64 paddr)
entry = rbt_memtype_lookup(paddr);
if (entry != NULL)
- rettype = entry->type;
+ rettype = pgprot2cachemode(__pgprot(entry->type));
else
- rettype = _PAGE_CACHE_UC_MINUS;
+ rettype = _PAGE_CACHE_MODE_UC_MINUS;
spin_unlock(_lock);
return rettype;
@@ -613,7 +613,7 @@ static int reserve_pfn_range(u64 paddr, unsigned long size,
pgprot_t *vma_prot,
if (!pat_enabled)
return 0;
- flags = lookup_memtype(paddr);
+ flags = cachemode2protval(lookup_memtype(paddr));
if (want_flags != flags) {
printk(KERN_WARNING "%s:%d map pfn RAM range req %s for
[mem %#010Lx-%#010Lx], got %s\n",
current->comm, current->pid,
@@ -715,7 +715,7 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t
*prot,
unsigned long pfn, unsigned long addr, unsigned long size)
{
resource_size_t paddr = (resource_size_t)pfn << PAGE_SHIFT;
- unsigned long flags;
+ enum page_cache_mode pcm;
/* reserve the whole chunk starting from paddr */
if (addr == vma->vm_start && size == (vma->vm_end - vma->vm_start)) {
@@ -734,18 +734,18 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t
*prot,
* For anything smaller than the vma size we set prot based on the
* lookup.
*/
- flags = lookup_memtype(paddr);
+ pcm = lookup_memtype(paddr);
/* Check memtype for the remaining pages */
while (size > PAGE_SIZE) {
size -= PAGE_SIZE;
paddr += PAGE_SIZE;
- if (flags != lookup_memtype(paddr))
+ if (pcm != lookup_memtype(paddr))
return -EINVAL;
}
*prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
-flags);
+cachemode2protval(pcm));
return 0;
}
@@ -753,15 +753,15 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t
*prot,
int track_pfn_insert(struct vm_area_struct *vma, pgprot_t *prot,
unsigned long pfn)
{
- unsigned long flags;
+ enum page_cache_mode pcm;
if (!pat_enabled)
return 0;
/* Set prot based on lookup */
- flags = lookup_memtype((resource_size_t)pfn << PAGE_SHIFT);
+ pcm = lookup_memtype((resource_size_t)pfn << PAGE_SHIFT);
*prot = __pgprot((pgprot_val(vma->vm_page_prot) & (~_PAGE_CACHE_MASK)) |
-flags);
+cachemode2protval(pcm));
return 0;
}
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 15/18] x86: Support PAT bit in pagetable dump for lower levels
Dumping page table protection bits is not correct for entries on levels
2 and 3 regarding the PAT bit, which is at a different position as on
level 4.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/mm/dump_pagetables.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 95a427e..6c2ca03 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -126,7 +126,7 @@ static void printk_prot(struct seq_file *m, pgprot_t prot,
int level, bool dmsg)
if (!pgprot_val(prot)) {
/* Not present */
- pt_dump_cont_printf(m, dmsg, " ");
+ pt_dump_cont_printf(m, dmsg, " ");
} else {
if (pr & _PAGE_USER)
pt_dump_cont_printf(m, dmsg, "USR ");
@@ -145,18 +145,16 @@ static void printk_prot(struct seq_file *m, pgprot_t
prot, int level, bool dmsg)
else
pt_dump_cont_printf(m, dmsg, "");
- /* Bit 9 has a different meaning on level 3 vs 4 */
- if (level <= 3) {
- if (pr & _PAGE_PSE)
- pt_dump_cont_printf(m, dmsg, "PSE ");
- else
- pt_dump_cont_printf(m, dmsg, "");
- } else {
- if (pr & _PAGE_PAT)
- pt_dump_cont_printf(m, dmsg, "pat ");
- else
- pt_dump_cont_printf(m, dmsg, "");
- }
+ /* Bit 7 has a different meaning on level 3 vs 4 */
+ if (level <= 3 && pr & _PAGE_PSE)
+ pt_dump_cont_printf(m, dmsg, "PSE ");
+ else
+ pt_dump_cont_printf(m, dmsg, "");
+ if ((level == 4 && pr & _PAGE_PAT) ||
+ ((level == 3 || level == 2) && pr & _PAGE_PAT_LARGE))
+ pt_dump_cont_printf(m, dmsg, "pat ");
+ else
+ pt_dump_cont_printf(m, dmsg, "");
if (pr & _PAGE_GLOBAL)
pt_dump_cont_printf(m, dmsg, "GLB ");
else
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 18/18] xen: Support Xen pv-domains using PAT
With the dynamical mapping between cache modes and pgprot values it is
now possible to use all cache modes via the Xen hypervisor PAT settings
in a pv domain.
All to be done is to read the PAT configuration MSR and set up the
translation tables accordingly.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Thomas Gleixner
---
arch/x86/xen/enlighten.c | 25 +++--
arch/x86/xen/mmu.c | 47 +--
arch/x86/xen/xen-ops.h | 1 -
3 files changed, 8 insertions(+), 65 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fac5e4f..6bf3a13 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1100,12 +1100,6 @@ static int xen_write_msr_safe(unsigned int msr, unsigned
low, unsigned high)
/* Fast syscall setup is all done in hypercalls, so
these are all ignored. Stub them out here to stop
Xen console noise. */
- break;
-
- case MSR_IA32_CR_PAT:
- if (smp_processor_id() == 0)
- xen_set_pat(((u64)high << 32) | low);
- break;
default:
ret = native_write_msr_safe(msr, low, high);
@@ -1561,10 +1555,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
/* Prevent unwanted bits from being set in PTEs. */
__supported_pte_mask &= ~_PAGE_GLOBAL;
-#if 0
- if (!xen_initial_domain())
-#endif
- __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
/*
* Prevent page tables from being allocated in highmem, even
@@ -1618,14 +1608,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
*/
acpi_numa = -1;
#endif
-#ifdef CONFIG_X86_PAT
- /*
-* For right now disable the PAT. We should remove this once
-* git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
-* (xen/pat: Disable PAT support for now) is reverted.
-*/
- pat_enabled = 0;
-#endif
/* Don't do the full vcpu_info placement stuff until we have a
possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
@@ -1636,6 +1618,13 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_raw_console_write("mapping kernel into physical memory\n");
xen_setup_kernel_pagetable((pgd_t *)xen_start_info->pt_base,
xen_start_info->nr_pages);
+ /*
+* Modify the cache mode translation tables to match Xen's PAT
+* configuration.
+*/
+
+ pat_init_cache_modes();
+
/* keep using Xen gdt for now; no urgent need to change it */
#ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a8a1a3d..9855eb8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -410,13 +410,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
__visible pteval_t xen_pte_val(pte_t pte)
{
pteval_t pteval = pte.pte;
-#if 0
- /* If this is a WC pte, convert back from Xen WC to Linux WC */
- if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
- WARN_ON(!pat_enabled);
- pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
- }
-#endif
+
return pte_mfn_to_pfn(pteval);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);
@@ -427,47 +421,8 @@ __visible pgdval_t xen_pgd_val(pgd_t pgd)
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);
-/*
- * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
- * are reserved for now, to correspond to the Intel-reserved PAT
- * types.
- *
- * We expect Linux's PAT set as follows:
- *
- * Idx PTE flagsLinuxXenDefault
- * 0 WB WB WB
- * 1PWT WC WT WT
- * 2PCD UC- UC-UC-
- * 3PCD PWT UC UC UC
- * 4PAT WB WC WB
- * 5PAT PWT WC WP WT
- * 6PAT PCD UC- rsvUC-
- * 7PAT PCD PWT UC rsvUC
- */
-
-void xen_set_pat(u64 pat)
-{
- /* We expect Linux to use a PAT setting of
-* UC UC- WC WB (ignoring the PAT flag) */
- WARN_ON(pat != 0x0007010600070106ull);
-}
-
__visible pte_t xen_make_pte(pteval_t pte)
{
-#if 0
- /* If Linux is trying to set a WC pte, then map to the Xen WC.
-* If _PAGE_PAT is set, then it probably means it is really
-* _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
-* things work out OK...
-*
-* (We should never see kernel mappings with _PAGE_PSE set,
-* but we could see hugetlbfs mappings, I think.).
-*/
- if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
- if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
- pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
- }
-#endif
[PATCH V6 16/18] x86: Respect PAT bit when copying pte values between large and normal pages
The PAT bit in the ptes is not moved to the correct position when
copying page protection attributes between entries of different sized
pages. Translate the ptes according to their page size.
Based-on-patch-by: Stefan Bader
Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
---
arch/x86/mm/pageattr.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index de807c9..6c8e3fd 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -485,14 +485,23 @@ try_preserve_large_page(pte_t *kpte, unsigned long
address,
/*
* We are safe now. Check whether the new pgprot is the same:
+* Convert protection attributes to 4k-format, as cpa->mask* are set
+* up accordingly.
*/
old_pte = *kpte;
- old_prot = req_prot = pte_pgprot(old_pte);
+ old_prot = req_prot = pgprot_large_2_4k(pte_pgprot(old_pte));
pgprot_val(req_prot) &= ~pgprot_val(cpa->mask_clr);
pgprot_val(req_prot) |= pgprot_val(cpa->mask_set);
/*
+* req_prot is in format of 4k pages. It must be converted to large
+* page format: the caching mode includes the PAT bit located at
+* different bit positions in the two formats.
+*/
+ req_prot = pgprot_4k_2_large(req_prot);
+
+ /*
* Set the PSE and GLOBAL flags only if the PRESENT flag is
* set otherwise pmd_present/pmd_huge will return true even on
* a non present pmd. The canon_pgprot will clear _PAGE_GLOBAL
@@ -585,13 +594,10 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte,
unsigned long address,
paravirt_alloc_pte(_mm, page_to_pfn(base));
ref_prot = pte_pgprot(pte_clrhuge(*kpte));
- /*
-* If we ever want to utilize the PAT bit, we need to
-* update this function to make sure it's converted from
-* bit 12 to bit 7 when we cross from the 2MB level to
-* the 4K level:
-*/
- WARN_ON_ONCE(pgprot_val(ref_prot) & _PAGE_PAT_LARGE);
+
+ /* promote PAT bit to correct position */
+ if (level == PG_LEVEL_2M)
+ ref_prot = pgprot_large_2_4k(ref_prot);
#ifdef CONFIG_X86_64
if (level == PG_LEVEL_1G) {
@@ -879,6 +885,7 @@ static int populate_pmd(struct cpa_data *cpa,
{
unsigned int cur_pages = 0;
pmd_t *pmd;
+ pgprot_t pmd_pgprot;
/*
* Not on a 2M boundary?
@@ -910,6 +917,8 @@ static int populate_pmd(struct cpa_data *cpa,
if (num_pages == cur_pages)
return cur_pages;
+ pmd_pgprot = pgprot_4k_2_large(pgprot);
+
while (end - start >= PMD_SIZE) {
/*
@@ -921,7 +930,8 @@ static int populate_pmd(struct cpa_data *cpa,
pmd = pmd_offset(pud, start);
- set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE |
massage_pgprot(pgprot)));
+ set_pmd(pmd, __pmd(cpa->pfn | _PAGE_PSE |
+ massage_pgprot(pmd_pgprot)));
start += PMD_SIZE;
cpa->pfn += PMD_SIZE;
@@ -949,6 +959,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long
start, pgd_t *pgd,
pud_t *pud;
unsigned long end;
int cur_pages = 0;
+ pgprot_t pud_pgprot;
end = start + (cpa->numpages << PAGE_SHIFT);
@@ -986,12 +997,14 @@ static int populate_pud(struct cpa_data *cpa, unsigned
long start, pgd_t *pgd,
return cur_pages;
pud = pud_offset(pgd, start);
+ pud_pgprot = pgprot_4k_2_large(pgprot);
/*
* Map everything starting from the Gb boundary, possibly with 1G pages
*/
while (end - start >= PUD_SIZE) {
- set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
massage_pgprot(pgprot)));
+ set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
+ massage_pgprot(pud_pgprot)));
start += PUD_SIZE;
cpa->pfn += PUD_SIZE;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
