Re: [PATCH] memcg: Add memory.pressure_level events
>>> +void __init enable_pressure_cgroup(void)
>>> +{
>>> + WARN_ON(cgroup_add_cftypes(_cgroup_subsys,
>>> + vmpressure_cgroup_files));
>>> +}
>>
>> There is no functionality discovery going on here, and this is
>> conditional on nothing. Isn't it better then to just add the register +
>> read functions to memcontrol.c and add the files in the memcontrol cftype ?
>
> I was trying to make the stuff similar to the existing CONFIG_MEMCG_SWAP
> code, which does this kind of adding files to the cgroup. But I can surely
> place files into memcontrol cftype as you suggest.
>
> Thanks a lot for the comments!
>
Note that swap can be command line disabled, and in that case we won't
register the files.
Then it makes sense to do it in a separate helper. If I understand your
code correctly, once it is compiled in, it will always be enabled. So I
personally think it is clearer if you register it together with the rest
of the crew.
--
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] sched: fix env->src_cpu for active migration
Hi Damien,
Thanks for the test and the feedback.
Could you send me the sched_domain configuration of your machine with
the kernel that boots on your machine ?
It's available in /proc/sys/kernel/sched_domain/cpu*/
This should not have any impact on your machine but it looks like it have one.
Regards,
Vincent
On 13 February 2013 07:18, Damien Wyart wrote:
> Hi,
>
> I tested this on top of 3.8-rc7 and this made the machine (x86_64, Core
> i7 920) unable to boot (very early as nothing at all is displayed on
> screen). Nothing in the kernel log (after booting with a working
> kernel).
>
> Double-checked by just backing out only this patch and this made the
> machine boot again.
>
> Damien
>
>> need_active_balance uses env->src_cpu which is set only if there is more
>> than 1 task on the run queue. We must set the src_cpu field unconditionnally
>> otherwise the test "env->src_cpu > env->dst_cpu" will always fail if there is
>> only 1 task on the run queue
>>
>> Signed-off-by: Vincent Guittot
>> ---
>> kernel/sched/fair.c |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 81fa536..32938ea 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5044,6 +5044,10 @@ redo:
>>
>> ld_moved = 0;
>> lb_iterations = 1;
>> +
>> + env.src_cpu = busiest->cpu;
>> + env.src_rq= busiest;
>> +
>> if (busiest->nr_running > 1) {
>> /*
>>* Attempt to move tasks. If find_busiest_group has found
>> @@ -5052,8 +5056,6 @@ redo:
>>* correctly treated as an imbalance.
>>*/
>> env.flags |= LBF_ALL_PINNED;
>> - env.src_cpu = busiest->cpu;
>> - env.src_rq= busiest;
>> env.loop_max = min(sysctl_sched_nr_migrate,
>> busiest->nr_running);
>>
>> update_h_load(env.src_cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf stat: refactor aggregation code
Hi Stephane,
On Tue, 12 Feb 2013 15:09:27 +0100, Stephane Eranian wrote:
> Refactor aggregation code by introducing
> a single aggr_mode variable and an enum
> for aggregation.
>
> Also refactor cpumap code having to do
> with cpu to socket mappings. All in preparation
> for extended modes, such as cpu -> core.
>
> Also fix socket aggregation and ensure
> that sockets are printed in increasing order.
[snip]
> -static void print_aggr_socket(char *prefix)
> +static void print_aggr(char *prefix)
> {
> struct perf_evsel *counter;
> + int cpu, s, s2, id, nr;
> u64 ena, run, val;
> - int cpu, s, s2, sock, nr;
>
> - if (!sock_map)
> + if (!(aggr_map || aggr_get_id))
> return;
>
> - for (s = 0; s < sock_map->nr; s++) {
> - sock = cpu_map__socket(sock_map, s);
> + for (s = 0; s < aggr_map->nr; s++) {
> + id = aggr_map->map[s];
> list_for_each_entry(counter, _list->entries, node) {
> val = ena = run = 0;
> nr = 0;
...
> @@ -1073,14 +1081,20 @@ static void print_stat(int argc, const char **argv)
> fprintf(output, ":\n\n");
> }
>
> - if (aggr_socket)
> - print_aggr_socket(NULL);
> - else if (no_aggr) {
> - list_for_each_entry(counter, _list->entries, node)
> - print_counter(counter, NULL);
> - } else {
> + switch (aggr_mode) {
> + case AGGR_SOCKET:
> + print_aggr(NULL);
> + break;
This line should look like this IMHO:
list_for_each_entry(counter, _list->entries, node)
print_aggr(counter, NULL);
and the equivalent loop in the print_aggr() should be removed. This is
for consistency with other formats if multiple events counted.
For instance, it'd sorting on events first and then sockets like:
# time socket cpus counts events
t0 S0 4XX cycles
t0 S1 4XX cycles
t0 S0 4 cache-misses
t0 S1 4 cache-misses
t1 S0 4ZZ cycles
...
But current code looks like sorting on sockets first instead.
# time socket cpus counts events
t0 S0 4XX cycles
t0 S0 4 cache-misses
t0 S1 4XX cycles
t0 S1 4 cache-misses
t1 S0 4ZZ cycles
...
Thanks,
Namhyung
> + case AGGR_GLOBAL:
> list_for_each_entry(counter, _list->entries, node)
> print_counter_aggr(counter, NULL);
> + break;
> + case AGGR_NONE:
> + list_for_each_entry(counter, _list->entries, node)
> + print_counter(counter, NULL);
> + break;
> + default:
> + break;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3 RESEND] mmc: sdhci: check voltage range only on regulators aware of voltage value
On Wed, 13 Feb 2013, Marek Szyprowski wrote:
> Hello,
>
> On 2/12/2013 11:10 PM, Guennadi Liakhovetski wrote:
> > Hi Marek
> >
> > On Tue, 12 Feb 2013, Marek Szyprowski wrote:
> >
> > > Some regulators don't report any voltage values, so checking supported
> > > voltage range results in disabling all SDHCI_CAN_VDD_* flags and
> > > registration failure. This patch finally provides a correct fix for the
> > > registration of SDHCI driver with all possible voltage regulators:
> > > dummy, fixed and regulated without using regulator_count_voltages()
> > > hacks.
> > >
> > > Signed-off-by: Marek Szyprowski
> > > ---
> > > drivers/mmc/host/sdhci.c |6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > index ba586ae..735526b 100644
> > > --- a/drivers/mmc/host/sdhci.c
> > > +++ b/drivers/mmc/host/sdhci.c
> > > @@ -2976,7 +2976,11 @@ int sdhci_add_host(struct sdhci_host *host)
> > > }
> > >
> > > #ifdef CONFIG_REGULATOR
> > > - if (host->vmmc) {
> > > + /*
> > > + * Voltage range check makes sense only if regulator reports
> > > + * any voltage value.
> > > + */
> > > + if (host->vmmc && regulator_get_voltage(host->vmmc) > 0) {
> > > ret = regulator_is_supported_voltage(host->vmmc, 270,
> > > 360);
> >
> > Wouldn't using mmc_regulator_get_ocrmask() be a better option?
>
> The idea behind this patch it to avoid messing ocr mask and voltage
> regulators when voltage regulator is a simple on/off switch, which doesn't
> report any value.
Wouldn't mmc_regulator_get_ocrmask() also report an error back in this
case?
> This solves the serious problems with sdhci driver when
> dummy regulator is enabled in kconfig, otherwise the sdhci driver
> concludes that no supported voltage is available and fails to initialize.
> Using mmc_regulator_get_ocrmask() won't solve this problem.
>
> BTW, mmc_regulator_get_ocrmask() won't work with continuous range regulators.
This seems like a problem, that has to be fixed...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [REGRESSION] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
[CC initramfs-tools] On Wed, Feb 13, 2013 at 08:16:28AM +0100, Andreas Mohr wrote: > Hi, > > On Wed, Feb 13, 2013 at 07:44:36AM +0100, Andreas Mohr wrote: > > So, what to do? I'm now going to do some experimentation with git revert > > on some revision, and I'm trying to establish the USB port dependency > > (BIOS-owned handoff root hub invisible!?, as discussed in initial mail). > > > After some bingo moment, seems the solution is easier than expected: > > andi@andinet:~$ ls > /tmp/initrd_extracted/lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ > ehci-hcd.ko ohci-hcd.ko uhci-hcd.ko xhci-hcd.ko > andi@andinet:~$ ls /lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ > ehci-hcd.ko isp116x-hcd.ko sl811_cs.ko uhci-hcd.ko > ehci-pci.ko ohci-hcd.ko sl811-hcd.ko whci > hwa-hc.kor8a66597-hcd.ko u132-hcd.ko xhci-hcd.ko > > So it's probably only that the initrd simply fails to ship > the ehci-pci.ko module (I could verify this by extending initrd content, BTW). > Now the question would be: > are modules listed in a static list on initramfs package/config side, > or does the kernel fail to signal the list of required modules properly? > (e.g. did some config-side files fail to get upgraded for this dependency??) > > > So maybe it's not a "regression" per se, but it's at least a grave > usability issue on kernel upgrade which should be handled as benignly as > possible (i.e., without any disruption). OK, initramfs-tools hook-functions file contains (even in git master): for arg in "$@" ; do case "$arg" in base) modules="$modules ehci-hcd ohci-hcd uhci-hcd usbhid" modules="$modules xhci xhci-hcd" modules="$modules hid-apple hid-cherry hid-generic" modules="$modules hid-logitech hid-logitech-dj" modules="$modules hid-microsoft hid-sunplus" modules="$modules btrfs ext2 ext3 ext4 ext4dev " modules="$modules isofs jfs nfs reiserfs udf xfs" modules="$modules af_packet atkbd i8042 virtio_pci" ;; So it seems it actually *is* the user side (initramfs-tools) which has to maintain knowledge of all dependencies in a painfully maintained hard-coded list, and it seems this change is now making it croak, due to not knowing about the newly split extra ehci-pci.ko. Questions: - is this mechanism how one would want things to be? (is there a way to cleanly provide the accurately updated list from the kernel side? Or is there a scripted mechanism to at least extract all required *dependee* modules from the list of the ones that we already know of? That would have saved our a** here...) - was this module change properly communicated sufficiently in advance, to (all/most of) some affected parties? If not, might want to do better next time if that's possible... - should ehci-pci be added to the literal list now (and does this work properly on kernels which don't have it??), to get back to a working state ASAP? Thanks, Andreas Mohr -- 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/
linux-next: manual merge of the samsung tree with the arm-soc tree
Hi Kukjin, Today's linux-next merge of the samsung tree got conflicts in quite a few files between commits from the arm-soc tree and commits from the samsung tree. I took Olof's advice and just dropped the samsung tree for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpKPnNii2EUK.pgp Description: PGP signature
Re: [PATCH linux-next] autofs4: autofs4_catatonic_mode(): remove redundant null check on kfree()
13.02.2013 11:37, Ian Kent wrote: [] So, you would like me to forward this to Linus? I'd be inclined to wait until the window for 3.9 opens since Linus probably has more than enough to do finalizing 3.8 right now. I guess this change is anything but urgent ;) Thanks, /mjt -- 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 linux-next] autofs4: autofs4_catatonic_mode(): remove redundant null check on kfree()
On Wed, 2013-02-13 at 11:23 +0400, Michael Tokarev wrote: > 13.02.2013 11:20, Ian Kent wrote: > > On Tue, 2013-02-12 at 10:12 -0700, Tim Gardner wrote: > >> smatch analysis: > >> > >> fs/autofs4/waitq.c:46 autofs4_catatonic_mode() info: redundant null > >> check on wq->name.name calling kfree() > > > > I'm not sure about this change. > > > > autofs4_catatonic_mode() could be called when there are remaining > > entries in the wait queue, which is nulled, so autofs4_wait_release() > > won't see the the discarded waits if it is called. > > Ian, this is about something else really. The patch is about the > NULL check before calling kfree() -- it does the NULL check internally. > It is nothing about code flow or anything else, it is about calling > kfree() unconditionally regardless whenever the argument is actually > NULL or non-NULL. It makes the code shorter and easier to read. Oh, right, kfree() does the a NULL check since a long time now. My bad, sorry. > > You can add my > > Signed-off-by: Michael Tokarev So, you would like me to forward this to Linus? I'd be inclined to wait until the window for 3.9 opens since Linus probably has more than enough to do finalizing 3.8 right now. Ian -- 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] memcg: Add memory.pressure_level events
On Sun, Feb 10 2013, Anton Vorontsov wrote: > With this patch userland applications that want to maintain the > interactivity/memory allocation cost can use the new pressure level > notifications. The levels are defined like this: > > The "low" level means that the system is reclaiming memory for new > allocations. Monitoring reclaiming activity might be useful for > maintaining overall system's cache level. Upon notification, the program > (typically "Activity Manager") might analyze vmstat and act in advance > (i.e. prematurely shutdown unimportant services). > > The "medium" level means that the system is experiencing medium memory > pressure, there is some mild swapping activity. Upon this event > applications may decide to analyze vmstat/zoneinfo/memcg or internal > memory usage statistics and free any resources that can be easily > reconstructed or re-read from a disk. > > The "critical" level means that the system is actively thrashing, it is > about to out of memory (OOM) or even the in-kernel OOM killer is on its > way to trigger. Applications should do whatever they can to help the > system. It might be too late to consult with vmstat or any other > statistics, so it's advisable to take an immediate action. > > The events are propagated upward until the event is handled, i.e. the > events are not pass-through. Here is what this means: for example you have > three cgroups: A->B->C. Now you set up an event listener on cgroup A and > cgroup B, and suppose group C experiences some pressure. In this > situation, only group B will receive the notification, i.e. group A will > not receive it. This is done to avoid excessive "broadcasting" of > messages, which disturbs the system and which is especially bad if we are > low on memory or thrashing. So, organize the cgroups wisely, or propagate > the events manually (or, ask us to implement the pass-through events, > explaining why would you need them.) > > The file mempressure.level is used to show the current memory pressure > level, and cgroups event control file can be used to setup an eventfd > notification with a specific memory pressure level threshold. > > Signed-off-by: Anton Vorontsov > Acked-by: Kirill A. Shutemov > --- > > Hi all, > > Here comes another iteration of the memory pressure saga. The previous > version of the patch (and discussion) can be found here: > > http://lkml.org/lkml/2013/1/4/55 > > And here are changes in this revision: > > - Andrew Morton was concerned that the mempressure stuff was tied to > memcg, which was non-issue since mempressure wasn't actually bolted into > memcg at that time. But now it is. :) So now you need memcg to use > mempressure. Why? It makes things easier, simpler (e.g. this ends any > questions on how two different cgroups would interact, which can be > complex when two are distinct entities). Plus, as I understood it, > that's how cgroup folks want to see it eventually; > > - Only cgroups API implemented. Let's start with making memcg people > happy, i.e. handling the most complex cases, and then we can start with > any niche solutions; > > - Implemented Minchan Kim's idea of checking gfp mask. Unfortunately, it > is not as simple as checking '__GFP_HIGHMEM | __GFP_MOVABLE', since we > also need to account files caches and kswapd reclaim. But even so we can > filter out DMA or atomic allocations, which are not interesting for > userland. Plus it opens doors for other gfp tuning, so definitely a good > stuff; > > - Per Leonid Moiseichuk's comments decreased vmpressure_level_critical to > 95. I didn't look close enough, but it seems that we the minimum step is > indeed ~3%, and 99% makes it actually 100%. 95% should be fine; > > - Per Kamezawa Hiroyuki added some words into documentation about that > it's always a good idea to consult with vmstat/zoneinfo/memcg statistics > before taking any action (with the exception of critical level). Also > added 'TODO' wrt. automatic window adjustment; > > - Documented events propagation strategy; > > - Removed ulong/uint usage, per Andrew's comments; > > - Glauber Costa didn't like too short and non-descriptive mpc_ naming, > suggesting mempressure_ instead. And Andrew suggested mpcg_. I went with > something completely different: vmpressure_/vmpr_. :) Also renamed > xxx2yyy() to xxx_to_yyy() per Glauber Costa suggestion. > > - _OOM level renamed to _CRITICAL. Andrew wanted _HIGH affix, but by using > 'critical' I want to denote that this level is the last one (e.g. we > might want to introduce _HIGH some time later, if we can find a good > definition for it); > > - This patch does not include shrinker interface. In the last series I > showed that implementing shrinker is possible, and that it actually can > be useful. At the same time I explained that shrinker is not a > substitution for the pressure levels. So, once we settle on the simple > thing, I might continue my shrinker efforts (which, btw,
Re: [PATCH 3/3 RESEND] mmc: sdhci: check voltage range only on regulators aware of voltage value
Hello,
On 2/12/2013 11:10 PM, Guennadi Liakhovetski wrote:
Hi Marek
On Tue, 12 Feb 2013, Marek Szyprowski wrote:
> Some regulators don't report any voltage values, so checking supported
> voltage range results in disabling all SDHCI_CAN_VDD_* flags and
> registration failure. This patch finally provides a correct fix for the
> registration of SDHCI driver with all possible voltage regulators:
> dummy, fixed and regulated without using regulator_count_voltages()
> hacks.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/mmc/host/sdhci.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ba586ae..735526b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2976,7 +2976,11 @@ int sdhci_add_host(struct sdhci_host *host)
>}
>
> #ifdef CONFIG_REGULATOR
> - if (host->vmmc) {
> + /*
> + * Voltage range check makes sense only if regulator reports
> + * any voltage value.
> + */
> + if (host->vmmc && regulator_get_voltage(host->vmmc) > 0) {
>ret = regulator_is_supported_voltage(host->vmmc, 270,
>360);
Wouldn't using mmc_regulator_get_ocrmask() be a better option?
The idea behind this patch it to avoid messing ocr mask and voltage
regulators when voltage regulator is a simple on/off switch, which doesn't
report any value. This solves the serious problems with sdhci driver when
dummy regulator is enabled in kconfig, otherwise the sdhci driver
concludes that no supported voltage is available and fails to initialize.
Using mmc_regulator_get_ocrmask() won't solve this problem.
BTW, mmc_regulator_get_ocrmask() won't work with continuous range
regulators.
Best regards
--
Marek Szyprowski
Samsung Poland R Center
--
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] staging/comedi: Fix undefined array subscript
On Wed, Feb 13, 2013 at 04:30:54AM +0100, Peter Huewe wrote:
> In vmk80xx_do_insn_bits the local variable reg, which is used as an
> index to the tx_buf array, can be used uninitialized if
> - data[0] == 0
> and
> - devpriv->model != VMK8061_MODEL
> -> we get into the else branch without having reg initialized.
It's weird that GCC doesn't warn about this...
This patch works, or at least it doesn't break anything that wasn't
already broken, but it doesn't feel like the right thing. Probably
we could move the reg setting outside the if statement.
if (devpriv->model == VMK8055_MODEL) {
reg = VMK8055_DO_REG;
cmd = VMK8055_CMD_WRT_AD;
} else { /* VMK8061_MODEL */
reg = VMK8061_DO_REG;
cmd = VMK8061_CMD_DO;
}
if (data[0]) {
tx_buf[reg] &= ~data[0];
Or maybe data[0] == 0 needs to be handled differently.
Ian would know for sure.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3 v3] selftests: Add tests for efivarfs
On Tue, 2013-02-12 at 15:50 -0800, Andrew Morton wrote: > On Fri, 08 Feb 2013 10:08:49 + > Matt Fleming wrote: > > > On Fri, 2013-02-08 at 18:05 +0800, Jeremy Kerr wrote: > > > However, the tests expose a bug at the moment, so run_tests will fail. > > > Matt will have that fixed soon though :) > > > > In which case, would it make more sense for me to take these tests > > through the efi tree? I'm fine either way, I'm just looking for the > > least surprising option. > > I don't think it matters much at this stage. selftests is new and is > used by approximately zero people so if the tests fail, few will > notice. Let's just get it in there and get it settled down. Fine by me. Thanks Andrew. -- 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] USB: EHCI: make ehci-vt8500 a separate driver
From: Manjunath Goudar
Separate the vt8500 host controller driver from ehci-hcd host code
into its own driver module.
Signed-off-by: Manjunath Goudar
Cc: Greg KH
Cc: Alan Stern
Cc: Tony Prisk
Cc: Alexey Charkov
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/usb/host/Kconfig |8 +
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-hcd.c|6 +---
drivers/usb/host/ehci-vt8500.c | 73 ++--
4 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 2aa4ece..4e15b87 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -162,6 +162,14 @@ config USB_EHCI_HCD_OMAP
Enables support for the on-chip EHCI controller on
OMAP3 and later chips.
+config USB_EHCI_HCD_VT8500
+tristate "Support for VT8500 on-chip EHCI USB controller"
+depends on USB_EHCI_HCD && ARCH_VT8500
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ VT8500 chips.
+
config USB_EHCI_HCD_SPEAR
tristate "Support for ST SPEAr on-chip EHCI USB controller"
depends on USB_EHCI_HCD && PLAT_SPEAR
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index d593017..1fe0579 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_OXU210HP_HCD)+= oxu210hp-hcd.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_EHCI_MV) += ehci-mv.o
+obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 9cf4d73..eefa3d7 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1287,11 +1287,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include "ehci-vt8500.c"
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_MSM
#include "ehci-msm.c"
#define PLATFORM_DRIVERehci_msm_driver
@@ -1331,6 +1326,7 @@ MODULE_LICENSE ("GPL");
!IS_ENABLED(CONFIG_ARCH_AT91) && \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
!IS_ENABLED(CONFIG_USB_EHCI_MV) && \
+ !IS_ENABLED(CONFIG_ARCH_VT8500) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index 11695d5..98d65bd 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,52 +16,25 @@
*
*/
+#include
+#include
+#include
+#include
+#include
+#include
#include
#include
-static const struct hc_driver vt8500_ehci_hc_driver = {
- .description= hcd_name,
- .product_desc = "VT8500 EHCI",
- .hcd_priv_size = sizeof(struct ehci_hcd),
+#include "ehci.h"
- /*
-* generic hardware linkage
-*/
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /*
-* basic lifecycle operations
-*/
- .reset = ehci_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
+#define DRIVER_DESC "vt8500 On-Chip EHCI Host driver"
- /*
-* managing i/o requests and associated device resources
-*/
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
+static const char hcd_name[] = "ehci-vt8500";
- /*
-* scheduling support
-*/
- .get_frame_number = ehci_get_frame,
+static struct hc_driver __read_mostly vt8500_ehci_hc_driver;
- /*
-* root hub support
-*/
- .hub_status_data= ehci_hub_status_data,
- .hub_control= ehci_hub_control,
- .bus_suspend= ehci_bus_suspend,
- .bus_resume = ehci_bus_resume,
- .relinquish_port= ehci_relinquish_port,
- .port_handed_over = ehci_port_handed_over,
-
- .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
+static const struct ehci_driver_overrides ehci_vt8500_overrides __initdata = {
+ .reset = ehci_setup,
};
static u64 vt8500_ehci_dma_mask = DMA_BIT_MASK(32);
@@ -140,11 +113,31 @@ static struct platform_driver vt8500_ehci_driver = {
.remove = vt8500_ehci_drv_remove,
.shutdown =
Re: [PATCH] memcg: Add memory.pressure_level events
Hi Glauber,
On Mon, Feb 11, 2013 at 02:17:06PM +0400, Glauber Costa wrote:
[...]
> > +static struct vmpressure *vmpressure_parent(struct vmpressure *vmpr)
> > +{
> > + struct cgroup *cg = vmpr_to_css(vmpr)->cgroup->parent;
> > +
> > + if (!cg)
> > + return NULL;
> > + return cg_to_vmpr(cg);
> > +}
>
> Unfortunately, "parent" in memcg have different meanings for information
> propagation purposes depending on the value of the flag "use_hierarchy".
> That is set for deprecation, but still...
>
> I suggest you use the helper mem_cgroup_parent, that will already give
> you the right parent (either immediate parent or root) with all that
> taken into account.
Got it, will change.
[...]
> > +void __init enable_pressure_cgroup(void)
> > +{
> > + WARN_ON(cgroup_add_cftypes(_cgroup_subsys,
> > + vmpressure_cgroup_files));
> > +}
>
> There is no functionality discovery going on here, and this is
> conditional on nothing. Isn't it better then to just add the register +
> read functions to memcontrol.c and add the files in the memcontrol cftype ?
I was trying to make the stuff similar to the existing CONFIG_MEMCG_SWAP
code, which does this kind of adding files to the cgroup. But I can surely
place files into memcontrol cftype as you suggest.
Thanks a lot for the comments!
Anton
--
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 linux-next] autofs4: autofs4_catatonic_mode(): remove redundant null check on kfree()
13.02.2013 11:20, Ian Kent wrote:
On Tue, 2013-02-12 at 10:12 -0700, Tim Gardner wrote:
smatch analysis:
fs/autofs4/waitq.c:46 autofs4_catatonic_mode() info: redundant null
check on wq->name.name calling kfree()
I'm not sure about this change.
autofs4_catatonic_mode() could be called when there are remaining
entries in the wait queue, which is nulled, so autofs4_wait_release()
won't see the the discarded waits if it is called.
Ian, this is about something else really. The patch is about the
NULL check before calling kfree() -- it does the NULL check internally.
It is nothing about code flow or anything else, it is about calling
kfree() unconditionally regardless whenever the argument is actually
NULL or non-NULL. It makes the code shorter and easier to read.
You can add my
Signed-off-by: Michael Tokarev
if you want.
Cc: Ian Kent
Cc: aut...@vger.kernel.org
Signed-off-by: Tim Gardner
---
fs/autofs4/waitq.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
index 03bc1d3..3db70da 100644
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -42,10 +42,8 @@ void autofs4_catatonic_mode(struct autofs_sb_info *sbi)
while (wq) {
nwq = wq->next;
wq->status = -ENOENT; /* Magic is gone - report failure */
- if (wq->name.name) {
- kfree(wq->name.name);
- wq->name.name = NULL;
- }
+ kfree(wq->name.name);
+ wq->name.name = NULL;
wq->wait_ctr--;
wake_up_interruptible(>queue);
wq = nwq;
--
To unsubscribe from this list: send the line "unsubscribe autofs" 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 linux-next] autofs4: autofs4_catatonic_mode(): remove redundant null check on kfree()
On Tue, 2013-02-12 at 10:12 -0700, Tim Gardner wrote:
> smatch analysis:
>
> fs/autofs4/waitq.c:46 autofs4_catatonic_mode() info: redundant null
> check on wq->name.name calling kfree()
I'm not sure about this change.
autofs4_catatonic_mode() could be called when there are remaining
entries in the wait queue, which is nulled, so autofs4_wait_release()
won't see the the discarded waits if it is called.
>
> Cc: Ian Kent
> Cc: aut...@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> fs/autofs4/waitq.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> index 03bc1d3..3db70da 100644
> --- a/fs/autofs4/waitq.c
> +++ b/fs/autofs4/waitq.c
> @@ -42,10 +42,8 @@ void autofs4_catatonic_mode(struct autofs_sb_info *sbi)
> while (wq) {
> nwq = wq->next;
> wq->status = -ENOENT; /* Magic is gone - report failure */
> - if (wq->name.name) {
> - kfree(wq->name.name);
> - wq->name.name = NULL;
> - }
> + kfree(wq->name.name);
> + wq->name.name = NULL;
> wq->wait_ctr--;
> wake_up_interruptible(>queue);
> wq = nwq;
--
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] memcg: Add memory.pressure_level events
Hi Greg,
Thanks for taking a look!
On Tue, Feb 12, 2013 at 10:42:51PM -0800, Greg Thelen wrote:
[...]
> > +static unsigned long vmpressure_calc_level(unsigned int win,
> > + unsigned int s, unsigned int r)
>
> Should seems like the return type of this function should be enum
> vmpressure_levels? If yes, then the 'return 0' below should be
> VMPRESSURE_LOW. And it would be nice if there was a little comment
> describing the meaning of the win, s, and r parameters. The "We
> calculate ..." comment below makes me think that win is the number of
> pages scanned, which makes me wonder what the s param is.
Got it, will make it clearer.
[...]
> > +static bool vmpressure_event(struct vmpressure *vmpr,
> > +unsigned long s, unsigned long r)
> > +{
> > + struct vmpressure_event *ev;
> > + int level = vmpressure_calc_level(vmpressure_win, s, r);
> > + bool signalled = 0;
> s/bool/int/
Um... I surely can do this, but why do you think it is a good idea?
> > +
> > + mutex_lock(>events_lock);
> > +
> > + list_for_each_entry(ev, >events, node) {
> > + if (level >= ev->level) {
> > + eventfd_signal(ev->efd, 1);
> > + signalled++;
> > + }
> > + }
> > +
> > + mutex_unlock(>events_lock);
> > +
> > + return signalled;
[...]
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1982,6 +1982,10 @@ static void shrink_zone(struct zone *zone, struct
> > scan_control *sc)
> > }
> > memcg = mem_cgroup_iter(root, memcg, );
> > } while (memcg);
> > +
> > + vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
> > + sc->nr_scanned - nr_scanned, nr_reclaimed);
>
> (sc->nr_scanned - nr_scanned) is the number of pages scanned in above
> while loop but nr_reclaimed is the starting position of the reclaim
> counter before the loop. It seems like you want:
> vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
> sc->nr_scanned - nr_scanned,
> sc->nr_reclaimed - nr_reclaimed);
Yeah, right you are. There actually was a merge conflict when I rebased my
patch onto linux-next, and it seems that I overlooked that the logic has
changed. So we might get a bit distorted pressure because of that.
Thanks for catching this!
Anton
--
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/
linux-next: manual merge of the arm-soc tree with the metag tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/irqchip/Makefile between commit 270de53f851b ("metag: Internal
and external irqchips") from the metag tree and commit a900e5d99718
("ARM: exynos: move exynos4210-combiner to drivers/irqchip") from the
arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/irqchip/Makefile
index ff02f6b,e65fbf2..000
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -1,6 -1,9 +1,11 @@@
+ obj-$(CONFIG_IRQCHIP) += irqchip.o
+
obj-$(CONFIG_ARCH_BCM2835)+= irq-bcm2835.o
+obj-$(CONFIG_METAG) += irq-metag-ext.o
+obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
+ obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o
obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi.o
- obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
obj-$(CONFIG_ARCH_SPEAR3XX) += spear-shirq.o
+ obj-$(CONFIG_ARM_GIC) += irq-gic.o
+ obj-$(CONFIG_ARM_VIC) += irq-vic.o
+ obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
pgpK1JS1eHXLc.pgp
Description: PGP signature
Re: [PATCH] [Watchdog][Trivial] Added comments to explain watchdog_disabled variable
Is the below patch picked up? On Sun, Feb 3, 2013 at 9:31 PM, anish kumar wrote: > From: anish kumar > > This watchdog_disabled flag is bit of cryptic.Howerver it's usefullnes is > multifold. > Uses are: > 1. Check if smpboot_register_percpu_thread function passed. > 2. Makes sure that user enables and disables the watchdog in sequence >i.e. enable watchdog->disable watchdog->enable watchdog >Unlike enable watchdog->enable watchdog which is wrong. > > Signed-off-by: anish kumar > --- > kernel/watchdog.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/kernel/watchdog.c b/kernel/watchdog.c > index 75a2ab3..87a19aa 100644 > --- a/kernel/watchdog.c > +++ b/kernel/watchdog.c > @@ -518,6 +518,11 @@ int proc_dowatchdog(struct ctl_table *table, int write, > return ret; > > set_sample_period(); > + /* > +* We shouldn't enable watchdog threads if it is > +* disabled.This is done by watchdog_disabled > +* variable check in watchdog_*_all_cpus function. > +*/ > if (watchdog_enabled && watchdog_thresh) > watchdog_enable_all_cpus(); > else > -- > 1.7.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: [REGRESSION] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
Hi, On Wed, Feb 13, 2013 at 07:44:36AM +0100, Andreas Mohr wrote: > So, what to do? I'm now going to do some experimentation with git revert > on some revision, and I'm trying to establish the USB port dependency > (BIOS-owned handoff root hub invisible!?, as discussed in initial mail). After some bingo moment, seems the solution is easier than expected: andi@andinet:~$ ls /tmp/initrd_extracted/lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ ehci-hcd.ko ohci-hcd.ko uhci-hcd.ko xhci-hcd.ko andi@andinet:~$ ls /lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ ehci-hcd.ko isp116x-hcd.ko sl811_cs.ko uhci-hcd.ko ehci-pci.ko ohci-hcd.ko sl811-hcd.ko whci hwa-hc.kor8a66597-hcd.ko u132-hcd.ko xhci-hcd.ko So it's probably only that the initrd simply fails to ship the ehci-pci.ko module (I could verify this by extending initrd content, BTW). Now the question would be: are modules listed in a static list on initramfs package/config side, or does the kernel fail to signal the list of required modules properly? (e.g. did some config-side files fail to get upgraded for this dependency??) So maybe it's not a "regression" per se, but it's at least a grave usability issue on kernel upgrade which should be handled as benignly as possible (i.e., without any disruption). Thanks, Andreas Mohr -- 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] USB: EHCI: make ehci-mv a separate driver
From: Manjunath Goudar
Separate the mv(marvell) host controller driver from ehci-hcd host code
into its own driver module.
Signed-off-by: Manjunath Goudar
Cc: Greg KH
Cc: Alan Stern
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/usb/host/Kconfig|2 +-
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-hcd.c |6 +---
drivers/usb/host/ehci-mv.c | 80 ---
4 files changed, 40 insertions(+), 49 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8ffbafa..2aa4ece 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -221,7 +221,7 @@ config USB_EHCI_S5P
Enable support for the S5P SOC's on-chip EHCI controller.
config USB_EHCI_MV
- bool "EHCI support for Marvell on-chip controller"
+ tristate "EHCI support for Marvell on-chip controller"
depends on USB_EHCI_HCD && (ARCH_PXA || ARCH_MMP)
select USB_EHCI_ROOT_HUB_TT
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 77e0331..d593017 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_MV) += ehci-mv.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fa0e665..9cf4d73 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1317,11 +1317,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVERehci_grlib_driver
#endif
-#ifdef CONFIG_USB_EHCI_MV
-#include "ehci-mv.c"
-#definePLATFORM_DRIVER ehci_mv_driver
-#endif
-
#ifdef CONFIG_MIPS_SEAD3
#include "ehci-sead3.c"
#definePLATFORM_DRIVER ehci_hcd_sead3_driver
@@ -1335,6 +1330,7 @@ MODULE_LICENSE ("GPL");
!defined(PLATFORM_DRIVER) && \
!IS_ENABLED(CONFIG_ARCH_AT91) && \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
+ !IS_ENABLED(CONFIG_USB_EHCI_MV) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 3065809..67de419 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -17,7 +17,18 @@
#include
#include
+#include
+#include
+#include
+#include
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI mv driver"
+
#define CAPLENGTH_MASK (0xff)
+static const char hcd_name[] = "ehci-mv";
+static struct hc_driver __read_mostly mv_ehci_hc_driver;
struct ehci_hcd_mv {
struct usb_hcd *hcd;
@@ -95,48 +106,6 @@ static int mv_ehci_reset(struct usb_hcd *hcd)
return retval;
}
-static const struct hc_driver mv_ehci_hc_driver = {
- .description = hcd_name,
- .product_desc = "Marvell EHCI",
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq = ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /*
-* basic lifecycle operations
-*/
- .reset = mv_ehci_reset,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /*
-* managing i/o requests and associated device resources
-*/
- .urb_enqueue = ehci_urb_enqueue,
- .urb_dequeue = ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
- .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-
- /*
-* scheduling support
-*/
- .get_frame_number = ehci_get_frame,
-
- /*
-* root hub support
-*/
- .hub_status_data = ehci_hub_status_data,
- .hub_control = ehci_hub_control,
- .bus_suspend = ehci_bus_suspend,
- .bus_resume = ehci_bus_resume,
-};
-
static int mv_ehci_probe(struct platform_device *pdev)
{
struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
@@ -350,8 +319,33 @@ static struct platform_driver ehci_mv_driver = {
.remove = mv_ehci_remove,
.shutdown = mv_ehci_shutdown,
.driver = {
- .name = "mv-ehci",
+ .name = hcd_name,
.bus = _bus_type,
},
.id_table = ehci_id_table,
};
+static const struct ehci_driver_overrides mv_overrides __initdata = {
+ .reset = mv_ehci_reset,
+};
+
+static int __init ehci_mv_init(void)
+{
+ if (usb_disabled())
+ return -ENODEV;
+
+ pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
Re: [PATCH v3] gpio: Add device driver for GRGPIO cores and support custom accessors with gpio-generic
On Tue, Feb 12, 2013 at 08:24:33AM +0100, Andreas Larsson wrote:
> This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP
> core library from Aeroflex Gaisler.
>
> This also adds support to gpio-generic for using custom accessor
> functions. The grgpio driver uses this to use ioread32be and iowrite32be
> for big endian register accesses.
>
> Signed-off-by: Andreas Larsson
> ---
[...]
Overall, the changes look good, so
Reviewed-by: Anton Vorontsov
Though, you might still want to fix some nits down below.
> +/*
> + * Driver for Aeroflex Gaisler GRGPIO General Purpose I/O cores.
> + *
> + * 2013 (c) Aeroflex Gaisler AB
> + *
> + * This driver supports the GRGPIO GPIO core available in the GRLIB VHDL IP
> core
> + * library.
> + *
> + * Full documentation of the GRGPIO core can be found here:
> + * http://www.gaisler.com/products/grlib/grip.pdf
> + *
> + * See "Documentation/devicetree/bindings/gpio/gpio-grgpio.txt" for
> information
> + * on open firmware properties.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * Contributors: Andreas Larsson
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "grgpio"
> +
> +#define GRGPIO_MAX_NGPIO 32
> +
> +struct grgpio_regs {
> + u32 data; /* 0x00 */
> + u32 output; /* 0x04 */
> + u32 dir;/* 0x08 */
> + u32 imask; /* 0x0c */
> + u32 ipol; /* 0x10 */
> + u32 iedge; /* 0x14 */
> + u32 bypass; /* 0x18 */
> + u32 __reserved; /* 0x1c */
> + u32 imap[8];/* 0x20-0x3c */
> +};
> +
> +struct grgpio_priv {
> + struct bgpio_chip bgc;
> + struct grgpio_regs __iomem *regs;
> +
> + u32 imask; /* irq mask shadow register */
> + s32 *irqmap;/* maps offset to irq or -1 if no irq */
> +};
> +
> +static unsigned long grgpio_read_reg(void __iomem *reg)
> +{
> + return ioread32be(reg);
> +}
> +
> +static void grgpio_write_reg(void __iomem *reg, unsigned long data)
> +{
> + iowrite32be(data, reg);
> +}
> +
> +static inline struct grgpio_priv *grgpio_gc_to_priv(struct gpio_chip *gc)
> +{
> + struct bgpio_chip *bgc = to_bgpio_chip(gc);
An empty line here is needed.
> + return container_of(bgc, struct grgpio_priv, bgc);
> +}
> +
> +static void grgpio_set_imask(struct grgpio_priv *priv, unsigned int offset,
> + int val)
> +{
> + struct bgpio_chip *bgc = >bgc;
> + unsigned long mask = bgc->pin2mask(bgc, offset);
> + unsigned long flags;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + if (val)
> + priv->imask |= mask;
> + else
> + priv->imask &= ~mask;
> + bgc->write_reg(>regs->imask, priv->imask);
> +
> + spin_unlock_irqrestore(>lock, flags);
> +}
> +
> +static int grgpio_to_irq(struct gpio_chip *gc, unsigned offset)
> +{
> + struct grgpio_priv *priv = grgpio_gc_to_priv(gc);
> + int index, irq;
One variable declaration per line.
> +
> + if (!priv->irqmap || offset > gc->ngpio)
> + return -ENXIO;
> +
> + index = priv->irqmap[offset];
> + if (index < 0)
> + return -ENXIO;
> +
> + irq = irq_of_parse_and_map(priv->bgc.gc.dev->of_node, index);
> + if (irq) {
> + /* Enable interrupt and return irq */
> + grgpio_set_imask(priv, offset, 1);
> + return irq;
> + } else {
> + return -ENXIO;
> + }
No need for else.
> +}
> +
> +static void grgpio_free(struct gpio_chip *gc, unsigned offset)
> +{
> + struct grgpio_priv *priv = grgpio_gc_to_priv(gc);
> + struct bgpio_chip *bgc = >bgc;
> + unsigned long mask = bgc->pin2mask(bgc, offset);
> +
> + if (unlikely(priv->imask & mask))
> + grgpio_set_imask(priv, offset, 0);
> +}
> +
> +static int grgpio_probe(struct platform_device *ofdev)
> +{
> + struct device_node *np = ofdev->dev.of_node;
> + struct grgpio_regs __iomem *regs;
> + struct gpio_chip *gc;
> + struct bgpio_chip *bgc;
> + struct grgpio_priv *priv;
> + struct resource *res;
> + int err, i, size;
One variable declaration per line.
> + u32 prop;
> + s32 *irqmap;
> + char *label;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + res = platform_get_resource(ofdev, IORESOURCE_MEM, 0);
> + regs = devm_request_and_ioremap(>dev, res);
Just wonder, is it safe to pass null res to devm_request_and_ioremap()?
> + if (!regs) {
> + dev_err(>dev, "Couldn't map registers\n");
> + return -EADDRNOTAVAIL;
> + }
> +
> +
Re: [PATCH V2] clk: tegra: initialise parent of uart clocks
On Tuesday 12 February 2013 11:16 PM, Stephen Warren wrote:
On 02/12/2013 08:17 AM, Laxman Dewangan wrote:
Initialise the parent of UARTs to PLLP and disabling clock by
default.
This patch wasn't tested, was it? Without the patch I just sent titled
"ARM: tegra: remove clock-frequency properties from serial nodes", the
UART clocks get turned off and the console breaks.
I tested this in next-20130212 where "clock-frequency" is there in
tegra30.dtsi file.
If you remove this from dts file at all then it will not work as there
is no execution path to call the clk_prepare_enable().
of_serial.c file:
if (of_property_read_u32(np, "clock-frequency", )) {
/* Get clk rate through clk driver if present */
info->clk = clk_get(>dev, NULL);
if (IS_ERR(info->clk)) {
dev_warn(>dev,
"clk or clock-frequency not defined\n");
return PTR_ERR(info->clk);
}
clk_prepare_enable(info->clk);
clk = clk_get_rate(info->clk);
}
--
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: [ 00/61] 3.7.8-stable review
At Tue, 12 Feb 2013 12:34:20 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.7.8 release. > There are 61 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Feb 14 20:31:32 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian wheezy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian wheezy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patches and it looks good to me. > Stephen Hemminger > MAINTAINERS: Stephen Hemminger email change ... > Sjur Brændeland > virtio_console: Don't access uninitialized data. Thanks, Satoru -- 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/4] gpiolib: check descriptors validity before use
From: Alexandre Courbot
Some functions dereferenced their GPIO descriptor argument without
checking its validity first, potentially leading to an oops when given
an invalid argument.
This patch also makes gpio_get_value() more resilient when given an
invalid GPIO, returning 0 instead of oopsing.
Signed-off-by: Alexandre Courbot
---
drivers/gpio/gpiolib.c | 64 +++---
1 file changed, 35 insertions(+), 29 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index fff9786..8a2cf9c 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -174,7 +174,7 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
/* caller holds gpio_lock *OR* gpio is marked as requested */
static struct gpio_chip *gpiod_to_chip(struct gpio_desc *desc)
{
- return desc->chip;
+ return desc ? desc->chip : NULL;
}
struct gpio_chip *gpio_to_chip(unsigned gpio)
@@ -653,7 +653,12 @@ static ssize_t export_store(struct class *class,
if (status < 0)
goto done;
+ status = -EINVAL;
+
desc = gpio_to_desc(gpio);
+ /* reject invalid GPIOs */
+ if (!desc)
+ goto done;
/* No extra locking here; FLAG_SYSFS just signifies that the
* request and export were done by on behalf of userspace, so
@@ -867,8 +872,8 @@ static int gpiod_export_link(struct device *dev, const char
*name,
done:
if (status)
- pr_debug("%s: gpio%d status %d\n", __func__, desc_to_gpio(desc),
-status);
+ pr_debug("%s: gpio%d status %d\n", __func__,
+desc ? desc_to_gpio(desc) : -1, status);
return status;
}
@@ -916,8 +921,8 @@ unlock:
done:
if (status)
- pr_debug("%s: gpio%d status %d\n", __func__, desc_to_gpio(desc),
-status);
+ pr_debug("%s: gpio%d status %d\n", __func__,
+desc ? desc_to_gpio(desc) : -1, status);
return status;
}
@@ -964,8 +969,8 @@ static void gpiod_unexport(struct gpio_desc *desc)
}
done:
if (status)
- pr_debug("%s: gpio%d status %d\n", __func__, desc_to_gpio(desc),
-status);
+ pr_debug("%s: gpio%d status %d\n", __func__,
+desc ? desc_to_gpio(desc) : -1, status);
}
void gpio_unexport(unsigned gpio)
@@ -1432,8 +1437,7 @@ static int gpiod_request(struct gpio_desc *desc, const
char *label)
done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
-desc ? desc_to_gpio(desc) : -1,
-label ? : "?", status);
+desc ? desc_to_gpio(desc) : -1, label ? : "?", status);
spin_unlock_irqrestore(_lock, flags);
return status;
}
@@ -1655,13 +1659,9 @@ lose:
return status;
fail:
spin_unlock_irqrestore(_lock, flags);
- if (status) {
- int gpio = -1;
- if (desc)
- gpio = desc_to_gpio(desc);
+ if (status)
pr_debug("%s: gpio-%d status %d\n",
- __func__, gpio, status);
- }
+ __func__, desc ? desc_to_gpio(desc) : -1, status);
return status;
}
@@ -1678,6 +1678,9 @@ static int gpiod_direction_output(struct gpio_desc *desc,
int value)
int status = -EINVAL;
int offset;
+ if (!desc)
+ goto fail_unlocked;
+
/* Open drain pin should not be driven to 1 */
if (value && test_bit(FLAG_OPEN_DRAIN, >flags))
return gpiod_direction_input(desc);
@@ -1688,8 +1691,6 @@ static int gpiod_direction_output(struct gpio_desc *desc,
int value)
spin_lock_irqsave(_lock, flags);
- if (!desc)
- goto fail;
chip = desc->chip;
if (!chip || !chip->set || !chip->direction_output)
goto fail;
@@ -1725,13 +1726,10 @@ lose:
return status;
fail:
spin_unlock_irqrestore(_lock, flags);
- if (status) {
- int gpio = -1;
- if (desc)
- gpio = desc_to_gpio(desc);
+fail_unlocked:
+ if (status)
pr_debug("%s: gpio-%d status %d\n",
- __func__, gpio, status);
- }
+ __func__, desc ? desc_to_gpio(desc) : -1, status);
return status;
}
@@ -1776,13 +1774,9 @@ static int gpiod_set_debounce(struct gpio_desc *desc,
unsigned debounce)
fail:
spin_unlock_irqrestore(_lock, flags);
- if (status) {
- int gpio = -1;
- if (desc)
- gpio = desc_to_gpio(desc);
+ if (status)
pr_debug("%s: gpio-%d status %d\n",
- __func__, gpio, status);
- }
+ __func__, desc ?
[PATCH 2/4] gpiolib: use const parameters when possible
From: Alexandre Courbot
Constify descriptor parameter of gpiod_* functions for those that
should obviously not modify it. This includes value or direction get,
cansleep, and IRQ number query.
Signed-off-by: Alexandre Courbot
---
drivers/gpio/gpiolib.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 8a2cf9c..ad6df6b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -88,13 +88,14 @@ static int gpiod_request(struct gpio_desc *desc, const char
*label);
static void gpiod_free(struct gpio_desc *desc);
static int gpiod_direction_input(struct gpio_desc *desc);
static int gpiod_direction_output(struct gpio_desc *desc, int value);
+static int gpiod_get_direction(const struct gpio_desc *desc);
static int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
-static int gpiod_get_value_cansleep(struct gpio_desc *desc);
+static int gpiod_get_value_cansleep(const struct gpio_desc *desc);
static void gpiod_set_value_cansleep(struct gpio_desc *desc, int value);
-static int gpiod_get_value(struct gpio_desc *desc);
+static int gpiod_get_value(const struct gpio_desc *desc);
static void gpiod_set_value(struct gpio_desc *desc, int value);
-static int gpiod_cansleep(struct gpio_desc *desc);
-static int gpiod_to_irq(struct gpio_desc *desc);
+static int gpiod_cansleep(const struct gpio_desc *desc);
+static int gpiod_to_irq(const struct gpio_desc *desc);
static int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
static int gpiod_export_link(struct device *dev, const char *name,
struct gpio_desc *desc);
@@ -172,7 +173,7 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
}
/* caller holds gpio_lock *OR* gpio is marked as requested */
-static struct gpio_chip *gpiod_to_chip(struct gpio_desc *desc)
+static struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
{
return desc ? desc->chip : NULL;
}
@@ -207,7 +208,7 @@ static int gpiochip_find_base(int ngpio)
}
/* caller ensures gpio is valid and requested, chip->get_direction may sleep
*/
-static int gpiod_get_direction(struct gpio_desc *desc)
+static int gpiod_get_direction(const struct gpio_desc *desc)
{
struct gpio_chip*chip;
unsignedoffset;
@@ -223,11 +224,13 @@ static int gpiod_get_direction(struct gpio_desc *desc)
if (status > 0) {
/* GPIOF_DIR_IN, or other positive */
status = 1;
- clear_bit(FLAG_IS_OUT, >flags);
+ /* FLAG_IS_OUT is just a cache of the result of get_direction(),
+* so it does not affect constness per se */
+ clear_bit(FLAG_IS_OUT, &((struct gpio_desc *)desc)->flags);
}
if (status == 0) {
/* GPIOF_DIR_OUT */
- set_bit(FLAG_IS_OUT, >flags);
+ set_bit(FLAG_IS_OUT, &((struct gpio_desc *)desc)->flags);
}
return status;
}
@@ -263,7 +266,7 @@ static DEFINE_MUTEX(sysfs_lock);
static ssize_t gpio_direction_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct gpio_desc*desc = dev_get_drvdata(dev);
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
ssize_t status;
mutex_lock(_lock);
@@ -1818,7 +1821,7 @@ EXPORT_SYMBOL_GPL(gpio_set_debounce);
* It returns the zero or nonzero value provided by the associated
* gpio_chip.get() method; or zero if no such method is provided.
*/
-static int gpiod_get_value(struct gpio_desc *desc)
+static int gpiod_get_value(const struct gpio_desc *desc)
{
struct gpio_chip*chip;
int value;
@@ -1936,7 +1939,7 @@ EXPORT_SYMBOL_GPL(__gpio_set_value);
* This is used directly or indirectly to implement gpio_cansleep(). It
* returns nonzero if access reading or writing the GPIO value can sleep.
*/
-static int gpiod_cansleep(struct gpio_desc *desc)
+static int gpiod_cansleep(const struct gpio_desc *desc)
{
if (!desc)
return 0;
@@ -1959,7 +1962,7 @@ EXPORT_SYMBOL_GPL(__gpio_cansleep);
* It returns the number of the IRQ signaled by this (input) GPIO,
* or a negative errno.
*/
-static int gpiod_to_irq(struct gpio_desc *desc)
+static int gpiod_to_irq(const struct gpio_desc *desc)
{
struct gpio_chip*chip;
int offset;
@@ -1982,7 +1985,7 @@ EXPORT_SYMBOL_GPL(__gpio_to_irq);
* Common examples include ones connected to I2C or SPI chips.
*/
-static int gpiod_get_value_cansleep(struct gpio_desc *desc)
+static int gpiod_get_value_cansleep(const struct gpio_desc *desc)
{
struct gpio_chip*chip;
int value;
--
1.8.1.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
[PATCH 0/4] gpiolib: some fixup patches
This short series is a fixup to patch 6/9 of my previous series ("gpiolib: use
descriptors internally"), which mainly addresses issues raised by Linus W. in
this patch and a few other minor ones caught while proof-reading gpiolib.
First patch is the most significant. It mostly avoids oopses when passing an
invalid GPIO to some functions. Also gpio_get/set_value*() now return 0 when
given an invalid GPIO number instead of oopsing. I tend to think that's an
improvement, but if it's not please let me know.
Ideally these patches should be melded into the above-mentioned patch since
they were intended to become a new revision, but I leave that decision to
Grant's discretion.
This patchset has been thoroughly tested on Tegra 2/Ventana with a GPIO
backlight driver and the sysfs interface.
Alexandre Courbot (4):
gpiolib: check descriptors validity before use
gpiolib: use const parameters when possible
gpiolib: move comment to right function
gpiolib: rename local offset variables to "hwgpio"
drivers/gpio/gpiolib.c | 165 ++---
1 file changed, 87 insertions(+), 78 deletions(-)
--
1.8.1.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 4/4] gpiolib: rename local offset variables to "hwgpio"
Delivered-To: gnu...@gmail.com
Received: by 10.64.96.232 with SMTP id dv8csp15271ieb;
Sun, 10 Feb 2013 05:48:07 -0800 (PST)
X-Received: by 10.68.0.39 with SMTP id 7mr11102539pbb.124.1360504086445;
Sun, 10 Feb 2013 05:48:06 -0800 (PST)
Return-Path:
Received: from hqemgate04.nvidia.com (hqemgate04.nvidia.com. [216.228.121.35])
by mx.google.com with ESMTPS id qj7si3931281pbb.322.2013.02.10.05.48.06
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Sun, 10 Feb 2013 05:48:06 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of
acour...@nvidia.com designates 216.228.121.35 as permitted sender)
client-ip=216.228.121.35;
Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of
acour...@nvidia.com designates 216.228.121.35 as permitted sender)
smtp.mail=acour...@nvidia.com
Received: from hqnvupgp05.nvidia.com (Not Verified[216.228.121.13]) by
hqemgate04.nvidia.com
id ; Sun, 10 Feb 2013 05:47:56 -0800
Received: from hqemhub01.nvidia.com ([172.17.108.22])
by hqnvupgp05.nvidia.com (PGP Universal service);
Sun, 10 Feb 2013 05:48:05 -0800
X-PGP-Universal: processed;
by hqnvupgp05.nvidia.com on Sun, 10 Feb 2013 05:48:05 -0800
Received: from [10.18.131.155] (172.20.144.16) by hqemhub01.nvidia.com
(172.20.150.30) with Microsoft SMTP Server id 8.3.297.1; Sun, 10 Feb 2013
05:48:05 -0800
Message-ID: <5117a5ab.5090...@nvidia.com>
Date: Sun, 10 Feb 2013 22:50:35 +0900
From: Alex Courbot
Organization: NVIDIA
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109
Thunderbird/17.0.2
MIME-Version: 1.0
To:
Subject: Re: [grant:gpio/next 10/16] gpiolib.c:undefined reference to
`gpiod_unexport'
References: <51166e1c.nrfqn8vgi14zunwf%fengguang...@intel.com>
In-Reply-To:
Return-Path: acour...@nvidia.com
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
On 02/10/2013 01:34 AM, Grant Likely wrote:
> Alex, this is broken when the sysfs interface isn't enabled. Can you
> send a fixup patch?
>
> g.
>
> On Sat, Feb 9, 2013 at 3:41 PM, kbuild test robot
> wrote:
>> tree: git://git.secretlab.ca/git/linux-2.6.git gpio/next
>> head: 8a307b35962e42de0f998c6029e8851c61eadb4e
>> commit: 5bb47609e8167d733786cb781ada29536385635c [10/16] gpiolib: use
>> descriptors internally
>> config: i386-randconfig-b040 (attached as .config)
>>
>> All error/warnings:
>>
>> drivers/built-in.o: In function `gpiod_free':
gpiolib.c:(.text+0xda3): undefined reference to `gpiod_unexport'
>> drivers/built-in.o: In function `gpio_request_one':
(.text+0x147f): undefined reference to `gpiod_export'
Oops, apologies. Here follows the fix. Please meld it into the culprit
patch to fix all warnings and errors when sysfs is not compiled in.
Thanks,
Alex.
---
drivers/gpio/gpiolib.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e6e597c..b5a71c5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1085,6 +1085,27 @@ static inline void gpiochip_unexport(struct
gpio_chip *chip)
{
}
+static inline int gpiod_export(struct gpio_desc *desc,
+ bool direction_may_change)
+{
+ return -ENOSYS;
+}
+
+static inline int gpiod_export_link(struct device *dev, const char *name,
+ struct gpio_desc *desc)
+{
+ return -ENOSYS;
+}
+
+static inline int gpiod_sysfs_set_active_low(struct gpio_desc *desc,
int value)
+{
+ return -ENOSYS;
+}
+
+static inline void gpiod_unexport(struct gpio_desc *desc)
+{
+}
+
#endif /* CONFIG_GPIO_SYSFS */
/*
--
1.8.1.3
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] gpiolib: move comment to right function
From: Alexandre Courbot
This comment applies to gpio_to_chip(), not gpiod_to_chip().
Signed-off-by: Alexandre Courbot
---
drivers/gpio/gpiolib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index ad6df6b..d8aa1a0 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -172,12 +172,12 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
return 0;
}
-/* caller holds gpio_lock *OR* gpio is marked as requested */
static struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
{
return desc ? desc->chip : NULL;
}
+/* caller holds gpio_lock *OR* gpio is marked as requested */
struct gpio_chip *gpio_to_chip(unsigned gpio)
{
return gpiod_to_chip(gpio_to_desc(gpio));
--
1.8.1.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 4/4] gpiolib: rename local offset variables to "hwgpio"
From: Alexandre Courbot
Their value being obtained by gpio_chip_hwgpio(), this better reflects
their use.
Signed-off-by: Alexandre Courbot
---
drivers/gpio/gpiolib.c | 70 +-
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d8aa1a0..42838c2 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -72,7 +72,7 @@ struct gpio_desc {
};
static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
-#define GPIO_OFFSET_VALID(chip, offset) (offset >= 0 && offset < chip->ngpio)
+#define GPIO_HWNUM_VALID(chip, hwgpio) (hwgpio >= 0 && hwgpio < chip->ngpio)
static LIST_HEAD(gpio_chips);
@@ -211,16 +211,16 @@ static int gpiochip_find_base(int ngpio)
static int gpiod_get_direction(const struct gpio_desc *desc)
{
struct gpio_chip*chip;
- unsignedoffset;
+ unsignedhwgpio;
int status = -EINVAL;
chip = gpiod_to_chip(desc);
- offset = gpio_chip_hwgpio(desc);
+ hwgpio = gpio_chip_hwgpio(desc);
if (!chip->get_direction)
return status;
- status = chip->get_direction(chip, offset);
+ status = chip->get_direction(chip, hwgpio);
if (status > 0) {
/* GPIOF_DIR_IN, or other positive */
status = 1;
@@ -754,7 +754,7 @@ static int gpiod_export(struct gpio_desc *desc, bool
direction_may_change)
int status;
const char *ioname = NULL;
struct device *dev;
- int offset;
+ int hwgpio;
/* can't export until sysfs is available ... */
if (!gpio_class.p) {
@@ -785,9 +785,9 @@ static int gpiod_export(struct gpio_desc *desc, bool
direction_may_change)
direction_may_change = false;
spin_unlock_irqrestore(_lock, flags);
- offset = gpio_chip_hwgpio(desc);
- if (desc->chip->names && desc->chip->names[offset])
- ioname = desc->chip->names[offset];
+ hwgpio = gpio_chip_hwgpio(desc);
+ if (desc->chip->names && desc->chip->names[hwgpio])
+ ioname = desc->chip->names[hwgpio];
dev = device_create(_class, desc->chip->dev, MKDEV(0, 0),
desc, ioname ? ioname : "gpio%u",
@@ -1591,7 +1591,7 @@ const char *gpiochip_is_requested(struct gpio_chip *chip,
unsigned offset)
{
struct gpio_desc *desc;
- if (!GPIO_OFFSET_VALID(chip, offset))
+ if (!GPIO_HWNUM_VALID(chip, offset))
return NULL;
desc = >desc[offset];
@@ -1621,7 +1621,7 @@ static int gpiod_direction_input(struct gpio_desc *desc)
unsigned long flags;
struct gpio_chip*chip;
int status = -EINVAL;
- int offset;
+ int hwgpio;
spin_lock_irqsave(_lock, flags);
@@ -1640,9 +1640,9 @@ static int gpiod_direction_input(struct gpio_desc *desc)
might_sleep_if(chip->can_sleep);
- offset = gpio_chip_hwgpio(desc);
+ hwgpio = gpio_chip_hwgpio(desc);
if (status) {
- status = chip->request(chip, offset);
+ status = chip->request(chip, hwgpio);
if (status < 0) {
pr_debug("GPIO-%d: chip request fail, %d\n",
desc_to_gpio(desc), status);
@@ -1653,7 +1653,7 @@ static int gpiod_direction_input(struct gpio_desc *desc)
}
}
- status = chip->direction_input(chip, offset);
+ status = chip->direction_input(chip, hwgpio);
if (status == 0)
clear_bit(FLAG_IS_OUT, >flags);
@@ -1679,7 +1679,7 @@ static int gpiod_direction_output(struct gpio_desc *desc,
int value)
unsigned long flags;
struct gpio_chip*chip;
int status = -EINVAL;
- int offset;
+ int hwgpio;
if (!desc)
goto fail_unlocked;
@@ -1707,9 +1707,9 @@ static int gpiod_direction_output(struct gpio_desc *desc,
int value)
might_sleep_if(chip->can_sleep);
- offset = gpio_chip_hwgpio(desc);
+ hwgpio = gpio_chip_hwgpio(desc);
if (status) {
- status = chip->request(chip, offset);
+ status = chip->request(chip, hwgpio);
if (status < 0) {
pr_debug("GPIO-%d: chip request fail, %d\n",
desc_to_gpio(desc), status);
@@ -1720,7 +1720,7 @@ static int gpiod_direction_output(struct gpio_desc *desc,
int value)
}
}
- status = chip->direction_output(chip, offset, value);
+ status = chip->direction_output(chip, hwgpio, value);
if (status == 0)
set_bit(FLAG_IS_OUT,
Re: [PATCH v2] IIO ADC support for AD7923
Le 12/02/2013 19:54, Lars-Peter Clausen a écrit : On 02/12/2013 06:10 PM, Christophe Leroy wrote: This patch adds support for Analog Devices AD7923 ADC in the IIO Subsystem. Signed-off-by: Patrick Vasseur Signed-off-by: Christophe Leroy Looks good to me except for one small, but important issue. Oh, many thanks. Good points . I'll fix it and resubmit. Christophe -- 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 v3] IIO ADC support for AD7923
This patch adds support for Analog Devices AD7923 ADC in the IIO Subsystem.
Signed-off-by: Patrick Vasseur
Signed-off-by: Christophe Leroy
diff -urN linux-next-e347c98/drivers/iio/adc/Kconfig
linux-next-e347c98.new/drivers/iio/adc/Kconfig
--- linux-next-e347c98/drivers/iio/adc/Kconfig 2013-02-08 05:22:35.0
+0100
+++ linux-next-e347c98.new/drivers/iio/adc/Kconfig 2013-02-12
13:02:52.0 +0100
@@ -30,6 +30,18 @@
To compile this driver as a module, choose M here: the
module will be called ad7298.
+config AD7923
+ tristate "Analog Devices AD7923 ADC driver"
+ depends on SPI
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Analog Devices AD7923
+ 4 Channel ADC with temperature sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7923.
+
config AD7791
tristate "Analog Devices AD7791 ADC driver"
depends on SPI
diff -urN linux-next-e347c98/drivers/iio/adc/Makefile
linux-next-e347c98.new/drivers/iio/adc/Makefile
--- linux-next-e347c98/drivers/iio/adc/Makefile 2013-02-08 05:22:35.0
+0100
+++ linux-next-e347c98.new/drivers/iio/adc/Makefile 2013-02-12
13:03:02.0 +0100
@@ -5,6 +5,7 @@
obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
obj-$(CONFIG_AD7266) += ad7266.o
obj-$(CONFIG_AD7298) += ad7298.o
+obj-$(CONFIG_AD7923) += ad7923.o
obj-$(CONFIG_AD7476) += ad7476.o
obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AD7793) += ad7793.o
diff -urN linux-next-e347c98/drivers/iio/adc/ad7923.c
linux-next-e347c98.new/drivers/iio/adc/ad7923.c
--- linux-next-e347c98/drivers/iio/adc/ad7923.c 1970-01-01 01:00:00.0
+0100
+++ linux-next-e347c98.new/drivers/iio/adc/ad7923.c 2013-02-13
02:03:38.0 +0100
@@ -0,0 +1,298 @@
+/*
+ * AD7923 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc (from AD7923 Driver)
+ * Copyright 2012 CS Systemes d'Information
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define AD7923_WRITE_CR(1 << 11) /* write control
register */
+#define AD7923_RANGE (1 << 1)/* range to REFin */
+#define AD7923_CODING (1 << 0)/* coding is straight binary */
+#define AD7923_PM_MODE_AS (1) /* auto shutdown */
+#define AD7923_PM_MODE_FS (2) /* full shutdown */
+#define AD7923_PM_MODE_OPS (3) /* normal operation */
+#define AD7923_CHANNEL_0 (0) /* analog input 0 */
+#define AD7923_CHANNEL_1 (1) /* analog input 1 */
+#define AD7923_CHANNEL_2 (2) /* analog input 2 */
+#define AD7923_CHANNEL_3 (3) /* analog input 3 */
+#define AD7923_SEQUENCE_OFF(0) /* no sequence fonction */
+#define AD7923_SEQUENCE_PROTECT(2) /* no interrupt write
cycle */
+#define AD7923_SEQUENCE_ON (3) /* continuous sequence */
+
+#define AD7923_MAX_CHAN4
+
+#define AD7923_PM_MODE_WRITE(mode) (mode << 4) /* write mode */
+#define AD7923_CHANNEL_WRITE(channel) (channel << 6) /* write channel */
+#define AD7923_SEQUENCE_WRITE(sequence)(((sequence & 1) << 3) \
+ + ((sequence & 2) << 9))
+ /* write sequence fonction */
+/* left shift for CR : bit 11 transmit in first */
+#define AD7923_SHIFT_REGISTER 4
+
+/* val = value, dec = left shift, bits = number of bits of the mask */
+#define EXTRACT(val, dec, bits)((val >> dec) & ((1 << bits) -
1))
+
+struct ad7923_state {
+ struct spi_device *spi;
+ struct spi_transfer ring_xfer[5];
+ struct spi_transfer scan_single_xfer[2];
+ struct spi_message ring_msg;
+ struct spi_message scan_single_msg;
+ /*
+* DMA (thus cache coherency maintenance) requires the
+* transfer buffers to live in their own cache lines.
+*/
+ __be16 rx_buf[4] cacheline_aligned;
+ __be16 tx_buf[4];
+};
+
+#define AD7923_V_CHAN(index) \
+ { \
+ .type = IIO_VOLTAGE,\
+ .indexed = 1, \
+ .channel = index, \
+ .info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT | \
+ IIO_CHAN_INFO_SCALE_SHARED_BIT, \
+ .address = index, \
+
[REGRESSION] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
Hi guys (*wink*),
On Tue, Feb 12, 2013 at 08:16:17AM -0800, Greg KH wrote:
> On Tue, Feb 12, 2013 at 05:07:27PM +0100, Andreas Mohr wrote:
> > On Sun, Feb 10, 2013 at 03:05:54PM +0100, Andreas Mohr wrote:
> > > Regression sorta confirmed now. -rc3 with a fully suitable .config does
> > > not boot either. Will start bisection. Will take ages.
> >
> > Down to 91 commits (all in USB land!), around 7 steps left.
> > Pretty certain of a valid regression now. Things did properly do the
> > good/good/bad/bad/good... dance.
> >
> > Oh so lovely if you're constrained to >= 5 hour build times,
>
> You do know about 'make localmodconfig', right? That should cut your
> build time down a large amount.
[I didn't]
Never managed to actually get to run localmodconfig, since I never
got to a bad build again (for properly confirming a reduced-set bad
vs. full-build bad) before finally hitting a subsequent bad one
with very limited incremental build efforts anyway (module headers only), doh...
And the winner is... ("oh no!")
# git bisect good
adfa79d1c06a32650332930ca4c488ca570b3407 is the first bad commit
commit adfa79d1c06a32650332930ca4c488ca570b3407
Author: Alan Stern
Date: Thu Nov 1 11:13:04 2012 -0400
USB: EHCI: make ehci-pci a separate driver
This patch (as1625) splits the PCI portion of ehci-hcd out into its
own separate driver module, called ehci-pci. Consistently with the
current practice, the decision whether to build this module is not
user-configurable. If EHCI and PCI are enabled then the module will
be built, always.
Signed-off-by: Alan Stern
CC: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
:04 04 1b7bf7a030df56852a48bf243862f70d5522e098
ad780e9c56d6647de5db9a5e87256ae2a79d4041 M drivers
# git bisect log
git bisect start
# bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070] Merge tag 'dt' of
# git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070
# bad: [fef3ff2eb777e76cfa5ae67591982d902c17139c] Merge branch 'for-3.8'
# of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu
git bisect bad fef3ff2eb777e76cfa5ae67591982d902c17139c
# good: [7bcb57cde66c19df378f3468ea342166a8a4504d] Merge tag
# 'iio-for-3.8f' of
# git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into
# staging-next
git bisect good 7bcb57cde66c19df378f3468ea342166a8a4504d
# good: [c6bd5bcc4983f1a2d2f87a3769bf309482ee8c04] Merge tag
# 'tty-3.8-rc1' of
# git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good c6bd5bcc4983f1a2d2f87a3769bf309482ee8c04
# bad: [aefb058b0c27dafb15072406fbfd92d2ac2c8790] Merge branch
# 'irq-core-for-linus' of
# git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad aefb058b0c27dafb15072406fbfd92d2ac2c8790
# bad: [70847780dca19f3707d9fa433f68edf8cbaf91f2] usb: host: tegra:
# remove pointless NULL check in tegra_ehci_remove()
git bisect bad 70847780dca19f3707d9fa433f68edf8cbaf91f2
# bad: [09f6ffde2ecef4cc4e2a5edaa303210cabd96f57] USB: EHCI: fix build
# error by making ChipIdea host a normal EHCI driver
git bisect bad 09f6ffde2ecef4cc4e2a5edaa303210cabd96f57
# good: [e1deb56cb775ab953bc5245feaf1f43269409139] usb: ehci-s5p: use
# clk_prepare_enable and clk_disable_unprepare
git bisect good e1deb56cb775ab953bc5245feaf1f43269409139
# good: [86effe5980e25f4fac10a0f22938c2fcd4a32690] USB: fix build with
# XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled
git bisect good 86effe5980e25f4fac10a0f22938c2fcd4a32690
# good: [571e41214e988bc38c99d804e6d8e1ea1d016342] USB: remove iteration
# limit in hub_tt_work()
git bisect good 571e41214e988bc38c99d804e6d8e1ea1d016342
# good: [7c83b4483606f5fe14127249336ac53ef177a63a] USB: option: idVendor
# and idProduct are __le16
git bisect good 7c83b4483606f5fe14127249336ac53ef177a63a
# bad: [99f91934a907df31ba878dfdd090002049dc476a] USB: EHCI: make
# ehci-platform a separate driver
git bisect bad 99f91934a907df31ba878dfdd090002049dc476a
# bad: [adfa79d1c06a32650332930ca4c488ca570b3407] USB: EHCI: make
# ehci-pci a separate driver
git bisect bad adfa79d1c06a32650332930ca4c488ca570b3407
# good: [3e0232039967d7a1a06c013d097458b4d5892af1] USB: EHCI: prepare to
# make ehci-hcd a library module
git bisect good 3e0232039967d7a1a06c013d097458b4d5892af1
History: Acer Aspire One netbook, boot from USB SSD failed to populate
/dev/disk/by-uuid/ properly, due to enumerating *parts* of the USB
device tree only, as seen via /sys/bus/usb
(see original mail for further details).
Thus it seems this bug was introduced early in the v3.7 -> v3.8-rc1 cycle.
And I failed to have
Re: [PATCH] x86: Lock down MSR writing in secure boot
On Tue, 2013-02-12 at 22:33 -0800, H. Peter Anvin wrote: > That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() > which means you can reprogram your northbridge, at which point you most > definitely *can* modify the running kernel. Well right, that's the point of this patchset - it adds some extra permission checks to some of the existing CAP_SYS_RAWIO checks. CAP_SYS_RAWIO hasn't meant "I can perform arbitrary pio and mmio" for years - it means "I can do things that might maybe break something somehow". So sure, removing CAP_SYS_RAWIO would give us basically all the security we want in a secure boot environment, but it would also block things that we *want* to work.
ksignal changes for 3.9
Hi Al, linux-next contains ksignal conversion for some of the architectures. Are you planning to complete that in 3.9 merge window. The reason I ask is so that the newer architectures (arc/metag - for a likely 3.9 merge) can queue the corresponding changes via respective trees. Thx, -Vineet -- 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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers
On Tue, Feb 12, 2013 at 01:20:36PM -0800, Joe Perches wrote: > His email bounces and he hasn't done work on > these sections in a couple of years. > I've added him to the CC list. Can we just update MAINTAINERS with the correct email address? It's been useful to CC him on stuff. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Lock down MSR writing in secure boot
On 02/12/2013 10:27 PM, Matthew Garrett wrote: On Tue, 2013-02-12 at 22:12 -0800, H. Peter Anvin wrote: Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a huge difference between MSRs and I/O control registers... just different address spaces. Not having CAP_SYS_RAWIO blocks various SCSI commands, for instance. These might result in the ability to write individual blocks or destroy the device firmware, but do any of them permit modifying the running kernel? That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() which means you can reprogram your northbridge, at which point you most definitely *can* modify the running kernel. And some SCSI driver requires this??! -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 0/2] Adding USB 3.0 DRD-phy support for exynos5250
Vivek Gautam wrote: > > Based on 'usb-next' > > Changes from v4: > - Modifying function names and driver names to follow a common >naming convention. > "usb2phy" for samsung-usb2phy driver > "usb3phy" for samsung-usb3phy driver > - Changing file names "samsung-usb2.c" to "samsung-usb2phy.c" and, >"samsung-usb3.c" to "samsung-usb3phy.c" > - Removing dependencies for SAMSUNG_USB2PHY and > SAMSUNG_USB3PHY. > - Arranging SAMSUNG_USB2PHY and SAMSUNG_USB3PHY to select > SAMSUNG_USBPHY, >which is the usb-phy helper driver. > > Vivek Gautam (2): > usb: phy: samsung: Common out the generic stuff > usb: phy: samsung: Add PHY support for USB 3.0 controller > > drivers/usb/phy/Kconfig | 25 +- > drivers/usb/phy/Makefile |2 + > drivers/usb/phy/samsung-usb2phy.c | 511 > ++ > drivers/usb/phy/samsung-usb3phy.c | 349 ++ > drivers/usb/phy/samsung-usbphy.c | 717 + > drivers/usb/phy/samsung-usbphy.h | 328 + > 6 files changed, 1219 insertions(+), 713 deletions(-) > create mode 100644 drivers/usb/phy/samsung-usb2phy.c > create mode 100644 drivers/usb/phy/samsung-usb3phy.c > create mode 100644 drivers/usb/phy/samsung-usbphy.h > > -- > 1.7.6.5 For now, looks good to me, and if any enhancement is required, it can be done next time. Felipe, please go ahead with my ack :-) Acked-by: Kukjin Kim Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Lock down MSR writing in secure boot
On Tue, 2013-02-12 at 22:12 -0800, H. Peter Anvin wrote:
> Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a
> huge difference between MSRs and I/O control registers... just different
> address spaces.
Not having CAP_SYS_RAWIO blocks various SCSI commands, for instance.
These might result in the ability to write individual blocks or destroy
the device firmware, but do any of them permit modifying the running
kernel?
N�r��yb�X��ǧv�^�)Þº{.n�+{zX����ܨ}ï¿½ï¿½ï¿½Æ z�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jÇ«y�m��@A�a���
0��h���i
Re: [PATCH] sched: fix env->src_cpu for active migration
Hi,
I tested this on top of 3.8-rc7 and this made the machine (x86_64, Core
i7 920) unable to boot (very early as nothing at all is displayed on
screen). Nothing in the kernel log (after booting with a working
kernel).
Double-checked by just backing out only this patch and this made the
machine boot again.
Damien
> need_active_balance uses env->src_cpu which is set only if there is more
> than 1 task on the run queue. We must set the src_cpu field unconditionnally
> otherwise the test "env->src_cpu > env->dst_cpu" will always fail if there is
> only 1 task on the run queue
>
> Signed-off-by: Vincent Guittot
> ---
> kernel/sched/fair.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 81fa536..32938ea 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5044,6 +5044,10 @@ redo:
>
> ld_moved = 0;
> lb_iterations = 1;
> +
> + env.src_cpu = busiest->cpu;
> + env.src_rq= busiest;
> +
> if (busiest->nr_running > 1) {
> /*
>* Attempt to move tasks. If find_busiest_group has found
> @@ -5052,8 +5056,6 @@ redo:
>* correctly treated as an imbalance.
>*/
> env.flags |= LBF_ALL_PINNED;
> - env.src_cpu = busiest->cpu;
> - env.src_rq= busiest;
> env.loop_max = min(sysctl_sched_nr_migrate,
> busiest->nr_running);
>
> update_h_load(env.src_cpu);
--
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: [PATCHv4 6/7] zswap: add flushing support
On 02/01/2013 01:27 AM, Minchan Kim wrote:
> On Tue, Jan 29, 2013 at 03:40:26PM -0600, Seth Jennings wrote:
>> This patchset adds support for flush pages out of the compressed
>> pool to the swap device
>>
Thanks for the review Minchan! Sorry for the delayed response. I'm
prepping v5 for posting.
>
> I know you don't have a enough time since you sent previous patch.
> Please add lots of words next time.
>
> 1. advertise "awesome feature", which igrate from zswap to real swap device
> 2. What's the tmppage?
> 3. frontswap_load/store/invalidate/flush race and object life time
> 4. policy to reclaim.
Will do.
>
>> Signed-off-by: Seth Jennings
>> ---
>> mm/zswap.c | 451
>> ++---
>> 1 file changed, 434 insertions(+), 17 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> index a6c2928..b8e5673 100644
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -34,6 +34,12 @@
>> #include
>> #include
>>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> /*
>> * statistics
>> **/
>> @@ -41,6 +47,8 @@
>> static atomic_t zswap_pool_pages = ATOMIC_INIT(0);
>> /* The number of compressed pages currently stored in zswap */
>> static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
>> +/* The number of outstanding pages awaiting writeback */
>> +static atomic_t zswap_outstanding_flushes = ATOMIC_INIT(0);
>>
>> /*
>> * The statistics below are not protected from concurrent access for
>> @@ -49,9 +57,14 @@ static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
>> * certain event is occurring.
>> */
>> static u64 zswap_pool_limit_hit;
>> +static u64 zswap_flushed_pages;
>> static u64 zswap_reject_compress_poor;
>> +static u64 zswap_flush_attempted;
>> +static u64 zswap_reject_tmppage_fail;
>
> What's does it mean? Hmm, I looked at the code.
> It means fail to allocator for tmppage.
I'll add a comment for this and additional information about the roll of
the tmppage mechanism in the code since it's a little unusual.
>
> How about "zswap_tmppage_alloc_fail"?
The method to my naming madness was that any stat that counted a reason
for a failed store started with zswap_reject_*
>
>> +static u64 zswap_reject_flush_fail;
>
> I am confused, too so looked at code but fail to find usecase.
> Remove?
Good call. I'll remove. Must have been left over from something else.
>
>> static u64 zswap_reject_zsmalloc_fail;
>
> We can remove this because get it by (zswap_flush_attempted -
> zswap_saved_by_flush)
>
This is true. I'll keep it in for now since it's not completely obvious
is can be derived from other stats without looking at the code.
>> static u64 zswap_reject_kmemcache_fail;
>> +static u64 zswap_saved_by_flush;
>
> I can't think better naming but need a comment at a minimum.
Yeah...
>
>> static u64 zswap_duplicate_entry;
>>
>> /*
>> @@ -80,6 +93,14 @@ static unsigned int zswap_max_compression_ratio = 80;
>> module_param_named(max_compression_ratio,
>> zswap_max_compression_ratio, uint, 0644);
>>
>> +/*
>> + * Maximum number of outstanding flushes allowed at any given time.
>> + * This is to prevent decompressing an unbounded number of compressed
>> + * pages into the swap cache all at once, and to help with writeback
>> + * congestion.
>> +*/
>> +#define ZSWAP_MAX_OUTSTANDING_FLUSHES 64
>> +
>> /*
>> * compression functions
>> **/
>> @@ -145,14 +166,23 @@ static void zswap_comp_exit(void)
>> **/
>
> Please introduce why we need LRU and refcount.
Will do.
>
>> struct zswap_entry {
>> struct rb_node rbnode;
>> +struct list_head lru;
>> +int refcount;
>
> Just nit,
> I understand why you don't use atomic but it would be nice to
> write down it in description of patch for preventing unnecessary
> arguing.
Yes. For the record, the reason is that we must take the tree lock in
order to change the refcount of an entry contained in the tree.
Incrementing an atomic under lock would be redundantly atomic.
>
>> unsigned type;
>> pgoff_t offset;
>> unsigned long handle;
>> unsigned int length;
>> };
>>
>> +/*
>> + * The tree lock in the zswap_tree struct protects a few things:
>> + * - the rbtree
>> + * - the lru list
>> + * - the refcount field of each entry in the tree
>> + */
>> struct zswap_tree {
>> struct rb_root rbroot;
>> +struct list_head lru;
>> spinlock_t lock;
>> struct zs_pool *pool;
>> };
>> @@ -184,6 +214,8 @@ static inline struct zswap_entry
>> *zswap_entry_cache_alloc(gfp_t gfp)
>> entry = kmem_cache_alloc(zswap_entry_cache, gfp);
>> if (!entry)
>> return NULL;
>> +INIT_LIST_HEAD(>lru);
>> +entry->refcount = 1;
>> return entry;
>> }
>>
>> @@ -192,6 +224,17 @@ static inline
Re: [PATCH]sched/stop_task: Do not account zero delta_exec in put_prev_task_stop
Hi Kirill, On Tue, 12 Feb 2013 01:40:04 +0400, Kirill Tkhai wrote: > Simple return > > Signed-off-by: Kirill V Tkhai > CC: Steven Rostedt > CC: Ingo Molnar > CC: Peter Zijlstra > CC: linux-rt-users > --- > kernel/sched/stop_task.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > diff --git a/kernel/sched/stop_task.c b/kernel/sched/stop_task.c > index da5eb5b..78d0458 100644 > --- a/kernel/sched/stop_task.c > +++ b/kernel/sched/stop_task.c > @@ -58,8 +58,8 @@ static void put_prev_task_stop(struct rq *rq, struct > task_struct *prev) > u64 delta_exec; > > delta_exec = rq->clock_task - curr->se.exec_start; > - if (unlikely((s64)delta_exec < 0)) > - delta_exec = 0; > + if (unlikely((s64)delta_exec <= 0)) > + return; It seems it needs to update curr->se.exec_start then. Thanks, Namhyung > > schedstat_set(curr->se.statistics.exec_max, > max(curr->se.statistics.exec_max, delta_exec)); > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 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] x86: Lock down MSR writing in secure boot
On 02/12/2013 09:39 PM, Matthew Garrett wrote: On Tue, 2013-02-12 at 16:48 -0800, H. Peter Anvin wrote: OK... what none of this gets into: Why should CAP_RAWIO be allowed on a secure boot system, when there are 2^n known ways of compromise a system with CAP_RAWIO? CAP_SYS_RAWIO seems to have ended up being a catchall of "Maybe someone who isn't entirely root should be able to do this", and not everything it covers is equivalent to being able to compromise the running kernel. I wouldn't argue with the idea that maybe we should just reappraise most of the current uses of CAP_SYS_RAWIO, but removing capability checks from places that currently have them seems like an invitation for userspace breakage. Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a huge difference between MSRs and I/O control registers... just different address spaces. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: [v2 3/3] ARM: tegra: Unify Device tree board files
Stephen Warren wrote @ Tue, 12 Feb 2013 17:35:56 +0100:
> However I'd like to avoid changing the body of those two functions at
> all if possible, since I hope the PCIe driver rework will be merged in
> 3.10, and that will allow the Harmony and TrimSlice init functions to be
> removed entirely. I'd rather not have conflicts with the removal patch.
>
> > Since we are not going to add any other board specfic init functions, you
> > can also unroll the loop and put everything into tegra_dt_init_late:
>
> That's not necessarily true. While we certainly don't plan to, I don't
> think we can rule it out; after all, we don't have rfkill bindings and
> yet other boards will need them.
Considering the above points,
- The Harmony and TrimSlice init functions will be removed entirely
so soon that we want to avoid those merge conflicts as much as
possible.
- We may still need board specific init, especially for rfkill.
- We want to build any combination of Tegra{20,30,114}, 2^3 - 1 == 7.
The patch for "tegra.c" would be as below.
Should I still keep the name, "tegra20_auxdata_lookup" to avoid
any conflicts or "tegra_auxdata_lookup" would be ok for merge?
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index fca18e9..fd4412d 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -1,6 +1,7 @@
/*
- * nVidia Tegra device tree board support
+ * NVIDIA Tegra SoC device tree board support
*
+ * Copyright (C) 2011, 2013, NVIDIA Corporation
* Copyright (C) 2010 Secret Lab Technologies, Ltd.
* Copyright (C) 2010 Google, Inc.
*
@@ -67,7 +68,7 @@ static struct tegra_ehci_platform_data tegra_ehci3_pdata = {
.vbus_gpio = -1,
};
-static struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
+static struct of_dev_auxdata tegra_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xC500, "tegra-ehci.0",
_ehci1_pdata),
OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xC5004000, "tegra-ehci.1",
@@ -84,7 +85,7 @@ static void __init tegra_dt_init(void)
* devices
*/
of_platform_populate(NULL, of_default_bus_match_table,
- tegra20_auxdata_lookup, NULL);
+ tegra_auxdata_lookup, NULL);
}
static void __init trimslice_init(void)
@@ -111,7 +112,8 @@ static void __init harmony_init(void)
static void __init paz00_init(void)
{
- tegra_paz00_wifikill_init();
+ if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
+ tegra_paz00_wifikill_init();
}
static struct {
@@ -137,12 +139,14 @@ static void __init tegra_dt_init_late(void)
}
}
-static const char *tegra20_dt_board_compat[] = {
+static const char * const tegra_dt_board_compat[] = {
+ "nvidia,tegra114",
+ "nvidia,tegra30",
"nvidia,tegra20",
NULL
};
-DT_MACHINE_START(TEGRA_DT, "nVidia Tegra20 (Flattened Device Tree)")
+DT_MACHINE_START(TEGRA_DT, "NVIDIA Tegra SoC (Flattened Device Tree)")
.map_io = tegra_map_common_io,
.smp= smp_ops(tegra_smp_ops),
.init_early = tegra_init_early,
@@ -151,5 +155,5 @@ DT_MACHINE_START(TEGRA_DT, "nVidia Tegra20 (Flattened
Device Tree)")
.init_machine = tegra_dt_init,
.init_late = tegra_dt_init_late,
.restart= tegra_assert_system_reset,
- .dt_compat = tegra20_dt_board_compat,
+ .dt_compat = tegra_dt_board_compat,
MACHINE_END
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Lock down MSR writing in secure boot
On Tue, 2013-02-12 at 16:48 -0800, H. Peter Anvin wrote: > OK... what none of this gets into: > > Why should CAP_RAWIO be allowed on a secure boot system, when there are > 2^n known ways of compromise a system with CAP_RAWIO? CAP_SYS_RAWIO seems to have ended up being a catchall of "Maybe someone who isn't entirely root should be able to do this", and not everything it covers is equivalent to being able to compromise the running kernel. I wouldn't argue with the idea that maybe we should just reappraise most of the current uses of CAP_SYS_RAWIO, but removing capability checks from places that currently have them seems like an invitation for userspace breakage.
Re: Debugging Thinkpad T430s occasional suspend failure.
On Tue, 12 Feb 2013, Dave Jones wrote: > On Tue, Feb 12, 2013 at 04:56:55PM -0800, Hugh Dickins wrote: > > > > so I can hit this pretty quickly with this.. > > > > > > while [ 1 ]; > > > do > > > rtcwake -s 5 -m no ; pm-suspend > > > done > > > > > > Which should make it bisectable at least.. > > > > Thanks, I'll give that a try this evening. > > So uh, put a 'sleep 5' in that loop. I had already put exactly that, to help break out when I got bored. I'm afraid it just confirms that we have different problems: that script gives me no trouble. Perhaps it would give me trouble if the timeout went up from 5 seconds to 10 hours (it does not at 10 minutes), but that doesn't feel like a very useful line of enquiry. I think for the moment I'm going to hope that under the surface our problems are related, and when your bisection points a finger, look around to see if it suggests anything for my case. Lazy, but... Hugh > > Turns out that the firmware on my Thinkpad craps itself when it tries to > suspend while > the cpu fan is still spinning back up, and eventually it gets in a state (on > a 'good' boot) > where the fan is stuck in the 'off' state. > > Result: hot laptop, machine check exceptions, and then a nice > "CPU FAN ERROR" message from the BIOS on next reboot. > > Full marks Lenovo. > > Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 05/12] iommu/exynos: support for device tree
KyongHo Cho wrote: > > On Fri, Feb 1, 2013 at 10:51 PM, Joerg Roedel wrote: > > Cho, > > > > On Wed, Jan 02, 2013 at 02:53:49PM +0900, KyongHo Cho wrote: > >> On Tuesday, January 1, 2013, Sylwester Nawrocki > > > > >> > Cc: devicetree-disc...@lists.ozlabs.org > > > > Since patch 7 of this set is already merged, do you mind to re-post the > > rest of this patch-set with the latest comments addressed? I can have a > > look at it again then and consider it for 3.9. > > > Thank you for your considerations. > > I also think that I need to post the patch set again with some fixes that are > addressed in the comments. > > Due to the heavy workload in my business I have hardly had a chance to > handle this patch-set. > As soon as the business lets me handle other pending issues, I will > work on this patchset. > I think I can start to it in the next 2 weeks. > OK, I see. Joerg, please hold this on until KyongHo's re-work, probably 3.10? Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] Input: matrix-keymap: Add function to read the new DT binding
Hi,
On Wednesday 13 February 2013 08:12 AM, Simon Glass wrote:
We now have a binding which adds two parameters to the matrix keypad DT
node. This is separate from the GPIO-driven matrix keypad binding, and
unfortunately incompatible, since that uses row-gpios/col-gpios for the
row and column counts.
So the easiest option here is to provide a function for non-GPIO drivers
to use to decode the binding.
Note: We could in fact create an entirely separate structure to hold
these two fields, but it does not seem worth it, yet. If we have more
parameters then we can add this, and then refactor each driver to hold
such a structure.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to decode matrix-keypad DT binding
drivers/input/keyboard/lpc32xx-keys.c | 11 ++-
drivers/input/keyboard/omap4-keypad.c | 16 +---
drivers/input/keyboard/tca8418_keypad.c | 11 +++
drivers/input/matrix-keymap.c | 20
include/linux/input/matrix_keypad.h | 11 +++
5 files changed, 49 insertions(+), 20 deletions(-)
diff --git a/drivers/input/keyboard/lpc32xx-keys.c
b/drivers/input/keyboard/lpc32xx-keys.c
index 1b8add6..4218143 100644
--- a/drivers/input/keyboard/lpc32xx-keys.c
+++ b/drivers/input/keyboard/lpc32xx-keys.c
@@ -144,12 +144,13 @@ static int lpc32xx_parse_dt(struct device *dev,
{
struct device_node *np = dev->of_node;
u32 rows = 0, columns = 0;
+ int err;
- of_property_read_u32(np, "keypad,num-rows",);
- of_property_read_u32(np, "keypad,num-columns",);
- if (!rows || rows != columns) {
- dev_err(dev,
- "rows and columns must be specified and be equal!\n");
+ err = matrix_keypad_parse_of_params(dev,,);
+ if (err)
+ return err;
+ if (rows != columns) {
+ dev_err(dev, "rows and columns must be equal!\n");
return -EINVAL;
}
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e25b022..1b28909 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -215,18 +215,12 @@ static int omap4_keypad_parse_dt(struct device *dev,
struct omap4_keypad *keypad_data)
{
struct device_node *np = dev->of_node;
+ int err;
- if (!np) {
- dev_err(dev, "missing DT data");
- return -EINVAL;
- }
-
- of_property_read_u32(np, "keypad,num-rows",_data->rows);
- of_property_read_u32(np, "keypad,num-columns",_data->cols);
- if (!keypad_data->rows || !keypad_data->cols) {
- dev_err(dev, "number of keypad rows/columns not specified\n");
- return -EINVAL;
- }
+ err = matrix_keypad_parse_of_params(dev,_data->rows,
+ _data->cols);
+ if (err)
+ return err;
if (of_get_property(np, "linux,input-no-autorepeat", NULL))
keypad_data->no_autorepeat = true;
diff --git a/drivers/input/keyboard/tca8418_keypad.c
b/drivers/input/keyboard/tca8418_keypad.c
index a34cc67..4d5a6d5 100644
--- a/drivers/input/keyboard/tca8418_keypad.c
+++ b/drivers/input/keyboard/tca8418_keypad.c
@@ -288,17 +288,20 @@ static int tca8418_keypad_probe(struct i2c_client *client,
irq_is_gpio = pdata->irq_is_gpio;
} else {
struct device_node *np = dev->of_node;
- of_property_read_u32(np, "keypad,num-rows",);
- of_property_read_u32(np, "keypad,num-columns",);
+ int err;
+
+ err = matrix_keypad_parse_of_params(dev,,);
+ if (err)
+ return err;
rep = of_property_read_bool(np, "keypad,autorepeat");
}
- if (!rows || rows> TCA8418_MAX_ROWS) {
+ if (rows> TCA8418_MAX_ROWS) {
dev_err(dev, "invalid rows\n");
return -EINVAL;
}
- if (!cols || cols> TCA8418_MAX_COLS) {
+ if (cols> TCA8418_MAX_COLS) {
dev_err(dev, "invalid columns\n");
return -EINVAL;
}
diff --git a/drivers/input/matrix-keymap.c b/drivers/input/matrix-keymap.c
index 3ae496e..64bad81 100644
--- a/drivers/input/matrix-keymap.c
+++ b/drivers/input/matrix-keymap.c
@@ -50,6 +50,25 @@ static bool matrix_keypad_map_key(struct input_dev
*input_dev,
}
#ifdef CONFIG_OF
+int matrix_keypad_parse_of_params(struct device *dev,
+ unsigned int *rows, unsigned int *cols)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ dev_err(dev, "missing DT data");
+ return -EINVAL;
+ }
+ of_property_read_u32(np, "keypad,num-rows", rows);
+ of_property_read_u32(np, "keypad,num-columns", cols);
+ if (!*rows || !*cols) {
+ dev_err(dev,
[next-20130204] nouveau: lockdep warning (not the same as the subdev lockdep warning)
Got this lockdep warning straightaway during boot:
[7.435890] =
[7.435891] [ INFO: possible recursive locking detected ]
[7.435893] 3.8.0-next-20130204+pcipatch-xeon+lockdep #20130204+pcipatch Not
tainted
[7.435893] -
[7.435895] modprobe/255 is trying to acquire lock:
[7.435942] (>lock){+.+...}, at: []
evo_wait+0x43/0xf0 [nouveau]
[7.435942]
[7.435942] but task is already holding lock:
[7.435964] (>lock){+.+...}, at: []
evo_wait+0x43/0xf0 [nouveau]
[7.435964]
[7.435964] other info that might help us debug this:
[7.435965] Possible unsafe locking scenario:
[7.435965]
[7.435966]CPU0
[7.435967]
[7.435968] lock(>lock);
[7.435970] lock(>lock);
[7.435970]
[7.435970] *** DEADLOCK ***
[7.435970]
[7.435971] May be due to missing lock nesting notation
[7.435971]
[7.435973] 9 locks held by modprobe/255:
[7.435979] #0: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x5b/0xb0
[7.435982] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x69/0xb0
[7.436001] #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xbd/0x2a0 [drm]
[7.436012] #3: (registration_lock){+.+.+.}, at: []
register_framebuffer+0x25/0x2f0
[7.436016] #4: (_info->lock){+.+.+.}, at: []
lock_fb_info+0x26/0x60
[7.436023] #5: ((fb_notifier_list).rwsem){.+.+.+}, at:
[] __blocking_notifier_call_chain+0x56/0xc0
[7.436035] #6: (>mode_config.mutex){+.+.+.}, at:
[] drm_modeset_lock_all+0x2a/0x70 [drm]
[7.436046] #7: (>mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x54/0x70 [drm]
[7.436068] #8: (>lock){+.+...}, at: []
evo_wait+0x43/0xf0 [nouveau]
[7.436068]
[7.436068] stack backtrace:
[7.436070] Pid: 255, comm: modprobe Not tainted
3.8.0-next-20130204+pcipatch-xeon+lockdep #20130204+pcipatch
[7.436072] Call Trace:
[7.436077] [] __lock_acquire+0x697/0x1a80
[7.436080] [] lock_acquire+0xa1/0x200
[7.436100] [] ? evo_wait+0x43/0xf0 [nouveau]
[7.436121] [] ? evo_wait+0x43/0xf0 [nouveau]
[7.436125] [] mutex_lock_nested+0x63/0x3a0
[7.436145] [] ? evo_wait+0x43/0xf0 [nouveau]
[7.436148] [] ? mutex_lock_nested+0x29e/0x3a0
[7.436168] [] ? evo_wait+0x43/0xf0 [nouveau]
[7.436170] [] ? mark_held_locks+0xaf/0x110
[7.436190] [] evo_wait+0x43/0xf0 [nouveau]
[7.436212] [] evo_sync+0x5c/0xf0 [nouveau]
[7.436233] [] nv50_display_flip_next+0x5ad/0x5c0
[nouveau]
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] NFSD: fix races in service per-net resources allocation
13.02.2013 01:18, Peter Staubach пишет:
The "+" thing seems a little odd. Why not use "||" instead? The sum of the
two returns isn't really the important thing, is it? It is that either call to svc_close_list()
returns non-zero.
Thanx...
Yep, thanks for the notice.
ps
-Original Message-
From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs-ow...@vger.kernel.org]
On Behalf Of J. Bruce Fields
Sent: Tuesday, February 12, 2013 3:46 PM
To: Stanislav Kinsbursky
Cc: a...@linux-foundation.org; linux-...@vger.kernel.org;
trond.mykleb...@netapp.com; linux-kernel@vger.kernel.org; de...@openvz.org
Subject: Re: [PATCH 0/2] NFSD: fix races in service per-net resources allocation
On Tue, Feb 12, 2013 at 01:52:32PM +0400, Stanislav Kinsbursky wrote:
12.02.2013 00:58, J. Bruce Fields пишет:
void svc_close_net(struct svc_serv *serv, struct net *net)
{
- svc_close_list(serv, >sv_tempsocks, net);
- svc_close_list(serv, >sv_permsocks, net);
-
- svc_clear_pools(serv, net);
- /*
-* At this point the sp_sockets lists will stay empty, since
-* svc_xprt_enqueue will not add new entries without taking the
-* sp_lock and checking XPT_BUSY.
-*/
- svc_clear_list(serv, >sv_tempsocks, net);
- svc_clear_list(serv, >sv_permsocks, net);
+ int closed;
+ int delay = 0;
+
+again:
+ closed = svc_close_list(serv, >sv_permsocks, net);
+ closed += svc_close_list(serv, >sv_tempsocks, net);
+ if (closed) {
+ svc_clean_up_xprts(serv, net);
+ msleep(delay++);
+ goto again;
+ }
Frankly, this hunk above makes me feel sick... :( But I have no better
idea right now...
Maybe make this hunk a bit less weird (this is from my POW only, of course),
like this:
+ while (svc_close_list(serv, >sv_permsocks, net) +
+ svc_close_list(serv, >sv_tempsocks, net)) {
+ svc_clean_up_xprts(serv, net);
+ msleep(delay++);
+ }
?
OK, that's a little more compact at least.
--b.
Anyway, thanks!
Acked-by: Stanislav Kinsbursky
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
Best regards,
Stanislav Kinsbursky
--
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: [next-20130204] hard LOCKUP on cpu 5, 3, 4, 2
On Tue, 2013-02-12 at 23:45 -0500, Peter Hurley wrote: > Got this message log (excerpted below) while building a kernel on > next-20130204. > > The build was taking place on an ext4 fs which is device-mapped on > stripped fakeraid. Happened directly on boot on a lockdep next-20130204 kernel. Log attached. > [I have no idea what gvfs was doing.] > > Besides the obvious hard lockups in the fs, the IPIs failed to trigger > stack dumps for any of the other CPUs [thus +cc x86]. I'm building the > NMI selftest in now. > > [ 2635.021602] [ cut here ] > [ 2635.021602] WARNING: at /home/peter/src/kernels/next/kernel/watchdog.c:245 > watchdog_overflow_callback+0x9f/0xd0() > [ 2635.021602] Hardware name: Precision WorkStation T5400 > [ 2635.021602] Watchdog detected hard LOCKUP on cpu 5 > [ 2635.021602] Modules linked in: ext2 ip6table_filter ip6_tables ebtable_nat > ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT > xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge > stp llc bnep rfcomm lp snd_ctxfi snd_pcm snd_seq_midi snd_rawmidi > snd_seq_midi_event snd_seq joydev snd_timer coretemp btusb kvm_intel > snd_seq_device snd psmouse soundcore ppdev bluetooth parport_pc kvm > i5400_edac snd_page_alloc edac_core mac_hid i5k_amb dm_multipath parport > gpio_ich scsi_dh lpc_ich shpchp serio_raw dcdbas microcode netconsole > configfs hid_logitech_dj dm_mirror dm_region_hash dm_log hid_generic usbhid > hid usb_storage tg3 nouveau e1000e ptp ttm pps_core drm_kms_helper drm > i2c_algo_bit[ 2656.019995] INFO: rcu_preempt detected stalls on CPUs/tasks: > [ 2656.02]5: (0 ticks this GP) idle=cfd/141/0 > last_accelerate: e84a/fccd, nonlazy_posted: 0, .. > [ 2656.02](detected by 1, t=5252 jiffies, g=99488, c=99487, q=215) > [ 2656.02] sending NMI to all CPUs: > [ 2656.020036] NMI backtrace for cpu 2 > [ 2656.020053] CPU 2 > [ 2656.020060] Pid: 3116, comm: gvfs-afc-volume Tainted: GW > 3.8.0-next-20130204+pcipatch-xeon #20130204+pcipatch Dell Inc. Precision > WorkStation T5400 /0RW203 > [ 2656.020065] RIP: 0010:[] [] > __ticket_spin_lock+0x1d/0x30 > [ 2656.020076] RSP: 0018:8802a0989c28 EFLAGS: 0297 > [ 2656.020080] RAX: 0042 RBX: 00010e10 RCX: > 8802a0989db8 > [ 2656.020083] RDX: 0043 RSI: RDI: > 8802afc90e10 > [ 2656.020085] RBP: 8802a0989c28 R08: R09: > 8d8d9adfc58cdaff > [ 2656.020088] R10: 8080808080808080 R11: R12: > 8800b88cb020 > [ 2656.020090] R13: 0041 R14: ff9c R15: > 8802a0989db8 > [ 2656.020093] FS: 7faef9388700() GS:8802afc8() > knlGS: > [ 2656.020096] CS: 0010 DS: ES: CR0: 8005003b > [ 2656.020099] CR2: 2b01d8c0 CR3: 000285a32000 CR4: > 07e0 > [ 2656.020102] DR0: DR1: DR2: > > [ 2656.020104] DR3: DR6: 0ff0 DR7: > 0400 > [ 2656.020107] Process gvfs-afc-volume (pid: 3116, threadinfo > 8802a0988000, task 8802a0f64530) > [ 2656.020109] Stack: > [ 2656.020112] 8802a0989c48 810895f5 8802a0989c58 > 8802a0989db8 > [ 2656.020120] 8802a0989ca8 811a17d5 8802a0989c88 > 8b97 > [ 2656.020128] 8802a0989cb8 81098929 8802a0989c88 > 8802a0989db8 > [ 2656.020136] Call Trace: > [ 2656.020144] [] lg_local_lock+0x35/0x40 > [ 2656.020151] [] path_init+0x205/0x430 > [ 2656.020156] [] ? update_curr+0x99/0x1a0 > [ 2656.020160] [] path_lookupat+0x33/0x760 > [ 2656.020166] [] ? sched_clock+0x9/0x10 > [ 2656.020170] [] filename_lookup+0x34/0xc0 > [ 2656.020175] [] user_path_at_empty+0x8e/0x110 > [ 2656.020181] [] ? _raw_spin_lock_irqsave+0x42/0x60 > [ 2656.020186] [] ? lock_hrtimer_base.isra.21+0x30/0x60 > [ 2656.020190] [] ? hrtimer_try_to_cancel+0x55/0x120 > [ 2656.020194] [] user_path_at+0x11/0x20 > [ 2656.020198] [] vfs_fstatat+0x52/0xb0 > [ 2656.020203] [] vfs_stat+0x1b/0x20 > [ 2656.020206] [] sys_newstat+0x1a/0x40 > [ 2656.020210] [] ? hrtimer_start_range_ns+0x14/0x20 > [ 2656.020214] [] ? sys_nanosleep+0x66/0x80 > [ 2656.020219] [] system_call_fastpath+0x16/0x1b > [ 2656.020222] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 b8 00 01 00 > 00 48 > > > [ 21.620002] [ cut here ] [ 21.620002] WARNING: at /home/peter/src/kernels/next/kernel/watchdog.c:245 watchdog_overflow_callback+0x9f/0xd0() [ 21.620002] Hardware name: Precision WorkStation T5400 [ 21.620002] Watchdog detected hard LOCKUP on cpu 0 [ 21.620002] Modules linked in: kvm(+) lp ppdev gpio_ich snd_ctxfi(+) snd_pcm dcdbas snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq dm_multipath scsi_dh snd_timer snd_seq_device microcode btusb snd bluetooth soundcore snd_page_alloc psmouse
[GIT PULL] parisc fixes for 3.8-rc7
This is a couple of patches, one to fix a broken build with HPUX
compatibility and the other to solve a coherency problem we've been
seeing in our TLB where setting a page read only occasionally fails to
trigger a COW because of a stale writeable TLB entry.
The patches are here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6.git parisc-fixes
The short changelog is:
Geert Uytterhoeven (1):
hpux: Remove obsolete regs parameter from do_execve() in hpux_execve()
John David Anglin (1):
Purge existing TLB entries in set_pte_at and ptep_set_wrprotect
and the diffstat:
arch/parisc/hpux/fs.c | 3 +--
arch/parisc/include/asm/pgtable.h | 13 ++---
arch/parisc/kernel/cache.c| 18 ++
3 files changed, 29 insertions(+), 5 deletions(-)
Full diff is attached below.
James
---
diff --git a/arch/parisc/hpux/fs.c b/arch/parisc/hpux/fs.c
index a0760b8..838b479 100644
--- a/arch/parisc/hpux/fs.c
+++ b/arch/parisc/hpux/fs.c
@@ -43,8 +43,7 @@ int hpux_execve(struct pt_regs *regs)
error = do_execve(filename->name,
(const char __user *const __user *) regs->gr[25],
- (const char __user *const __user *) regs->gr[24],
- regs);
+ (const char __user *const __user *) regs->gr[24]);
putname(filename);
diff --git a/arch/parisc/include/asm/pgtable.h
b/arch/parisc/include/asm/pgtable.h
index ee99f23..7df49fa 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -12,11 +12,10 @@
#include
#include
+#include
#include
#include
-struct vm_area_struct;
-
/*
* kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
* memory. For the return value to be meaningful, ADDR must be >=
@@ -40,7 +39,14 @@ struct vm_area_struct;
do{ \
*(pteptr) = (pteval); \
} while(0)
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
+
+extern void purge_tlb_entries(struct mm_struct *, unsigned long);
+
+#define set_pte_at(mm, addr, ptep, pteval) \
+ do {\
+ set_pte(ptep, pteval); \
+ purge_tlb_entries(mm, addr);\
+ } while (0)
#endif /* !__ASSEMBLY__ */
@@ -466,6 +472,7 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr,
old = pte_val(*ptep);
new = pte_val(pte_wrprotect(__pte (old)));
} while (cmpxchg((unsigned long *) ptep, old, new) != old);
+ purge_tlb_entries(mm, addr);
#else
pte_t old_pte = *ptep;
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 48e16dc..b89a85a 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -419,6 +419,24 @@ void kunmap_parisc(void *addr)
EXPORT_SYMBOL(kunmap_parisc);
#endif
+void purge_tlb_entries(struct mm_struct *mm, unsigned long addr)
+{
+ unsigned long flags;
+
+ /* Note: purge_tlb_entries can be called at startup with
+ no context. */
+
+ /* Disable preemption while we play with %sr1. */
+ preempt_disable();
+ mtsp(mm->context, 1);
+ purge_tlb_start(flags);
+ pdtlb(addr);
+ pitlb(addr);
+ purge_tlb_end(flags);
+ preempt_enable();
+}
+EXPORT_SYMBOL(purge_tlb_entries);
+
void __flush_tlb_range(unsigned long sid, unsigned long start,
unsigned long end)
{
--
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/
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/radeon/evergreen_cs.c between commit de0babd60d8d
("drm/radeon: enforce use of radeon_get_ib_value when reading user cmd")
from Linus' tree and commit 0fcb6155cb5c ("radeon/kms: cleanup async dma
packet checking") from the drm tree.
I fixed it up (I think (I did it fairly mechanically) - see below) and
can carry the fix as necessary (no action is required - but it might be
worth doing this merge yourself before asking Linus to pull - you could
just *merge* the above commit from Linus' tree (or the head of the branch
that Linus merged)).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/radeon/evergreen_cs.c
index ee4cff5,d8f5d5f..000
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@@ -2908,15 -2708,19 +2708,19 @@@ int evergreen_dma_cs_parse(struct radeo
DRM_ERROR("bad DMA_PACKET_WRITE\n");
return -EINVAL;
}
- if (tiled) {
+ switch (sub_cmd) {
+ /* tiled */
+ case 8:
- dst_offset = ib[idx+1];
+ dst_offset = radeon_get_ib_value(p, idx+1);
dst_offset <<= 8;
ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset
>> 8);
p->idx += count + 7;
- } else {
+ break;
+ /* linear */
+ case 0:
- dst_offset = ib[idx+1];
- dst_offset |= ((u64)(ib[idx+2] & 0xff)) << 32;
+ dst_offset = radeon_get_ib_value(p, idx+1);
+ dst_offset |= ((u64)(radeon_get_ib_value(p,
idx+2) & 0xff)) << 32;
ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset &
0xfffc);
ib[idx+2] +=
upper_32_bits(dst_reloc->lobj.gpu_offset) & 0xff;
@@@ -2939,338 -2747,330 +2747,330 @@@
DRM_ERROR("bad DMA_PACKET_COPY\n");
return -EINVAL;
}
- if (tiled) {
- idx_value = radeon_get_ib_value(p, idx + 2);
- if (new_cmd) {
- switch (misc) {
- case 0:
- /* L2T, frame to fields */
- if (idx_value & (1 << 31)) {
- DRM_ERROR("bad L2T,
frame to fields DMA_PACKET_COPY\n");
- return -EINVAL;
- }
- r = r600_dma_cs_next_reloc(p,
_reloc);
- if (r) {
- DRM_ERROR("bad L2T,
frame to fields DMA_PACKET_COPY\n");
- return -EINVAL;
- }
- dst_offset =
radeon_get_ib_value(p, idx+1);
- dst_offset <<= 8;
- dst2_offset =
radeon_get_ib_value(p, idx+2);
- dst2_offset <<= 8;
- src_offset =
radeon_get_ib_value(p, idx+8);
- src_offset |=
((u64)(radeon_get_ib_value(p, idx+9) & 0xff)) << 32;
- if ((src_offset + (count * 4))
> radeon_bo_size(src_reloc->robj)) {
- dev_warn(p->dev, "DMA
L2T, frame to fields src buffer too small (%llu %lu)\n",
-src_offset +
(count * 4), radeon_bo_size(src_reloc->robj));
- return -EINVAL;
- }
- if ((dst_offset + (count * 4))
> radeon_bo_size(dst_reloc->robj)) {
- dev_warn(p->dev, "DMA
L2T, frame to fields buffer too small (%llu %lu)\n",
-dst_offset +
(count * 4), radeon_bo_size(dst_reloc->robj));
- return -EINVAL;
- }
- if
Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
On Tue, Feb 12, 2013 at 7:58 PM, KY Srinivasan wrote: > > >> -Original Message- >> From: H. Peter Anvin [mailto:h...@zytor.com] >> Sent: Tuesday, February 12, 2013 10:55 PM >> To: KY Srinivasan >> Cc: Yinghai Lu; mi...@kernel.org; linux-kernel@vger.kernel.org; >> t...@linutronix.de; h...@linux.intel.com; linux-tip-comm...@vger.kernel.org >> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special >> hypervisor interrupts >> >> On 02/12/2013 07:49 PM, KY Srinivasan wrote: >> >>> >> >>> The issue was that you could turn on CONFIG_HYPERV without enabling >> >>> CONFIG_X86_LOCAL_APIC. Peter fixed it. >> >>> >> >> >> >> He is asking why you are using IS_ENABLED() instead of #ifdef. The >> >> difference is that IS_ENABLED() works even for modules. >> > >> > My mistake! >> > >> >> Well, which one do you need? > > I chose the IS_ENABLED() because I wanted to cover the case where HYPERV is > configured as a module as well. > ok, so when HYPERV is built as module, actually it is partially module as it put some code built-in already? if user never load hyperv, those code will never not be used. Can those code not be put in module _init function? Thanks Yinghai -- 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: Abysmal HDD/USB write speed after sleep on a UEFI system
[+cc linux-pci, Rafael, Alan] [https://bugzilla.kernel.org/show_bug.cgi?id=53551] On Tue, Feb 12, 2013 at 1:13 PM, Artem S. Tashkinov wrote: > Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote: > On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote: >>> Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote: A few things to try to pinpoint: (a) Is it *only* write performance that suffers, or is it other performance too? Networking (DMA? Perhaps only writing *to* the network?)? CPU? >>> >>> I 've tested hdpard -tT --direct and the output on boot and after suspend >>> is quite similar. >>> >>> I 've also checked my network read/write speed, and it 's the same >>> ~ 100MBit/sec (I have no 1Gbit computers on my network >>> unfortunately). >> >>Ok. So it really sounds like just USB and HD writes. Which is quite >>odd, since they have basically nothing in common I can think of >>(except the obvious block layer issues). >> (b) the fact that it apparently happens with both SATA and USB implies that it's neither, and is more likely something core like memory speed (mtrr, caching) or PCI (DMA, burst sizes, whatever). >>> >>> I 've no idea, please, check my bug report where I 've just added lots of >>> information including a diff between on boot and after suspend. >> >>I 'm not seeing anything particularly interesting there. >> >>Except why/how did the MSI address/data change for the SATA >>controller? The irq itself hasn 't changed.. There 's probably some sane >>reason for that too (it 's an odd encoding, maybe they code for the >>same thing), and there 's nothing like that for USB, so... >> >>And if it was irq problems, I 'd expect you to see it more for reads >>than for writes anyway. Along with a few messages about missed irqs >>and whatever. >> >>I'm stumped, and have no ideas. I can 't even begin to guess how this >>would happen. One thing to try is if it happens for all USB ports (you >>have multiple controllers) and I assume performance doesn 't come back >>if you unplug and replug the USB disk.. > > I've just plugged and unplugged my USB stick into all available hubs > (including a USB3 one, that is xhci_hcd) and I've got the same write speed > on all of them - around 930KB/sec (quite a weird number - as if I'm on USB > 1.1) - lsusb says I'm happily running ehci_hcd/2p, 480M and xhci_hcd/2p, > 5000M. > > The only pattern that I see here is that write speed to real devices degrades, > tmpfs write speed stays the same: > > $ dd if=/dev/zero of=test bs=32M count=32 > 32+0 records indegrade > 32+0 records out > 1073741824 bytes (1.1 GB) copied, 0.296323 s, 3.6 GB/s I'm sort of stumped here, too. For the SATA controller, the only PCI-related difference I see is the change in the MSI address, which should just change the target CPU, which doesn't seem like it should make this much difference. But could you try this after the resume: $ sudo setpci -s00:1f.2 0x84.L=0xfee0400c to set the MSI address back to the original value to see if it makes a difference? The XHCI controllers both have Unsupported Request errors logged. I assume these are related to the suspend/resume, and it seems like we ought to either avoid them or clean them up somehow, but I don't know enough about AER, and I don't know whether they would cause the performance issue you're seeing. There should be more AER logging than is decoded by lspci, so can you also collect the output of "lspci -vvv -"? That will include the raw logging registers that lspci doesn't decode. Bjorn -- 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, PCI: Get PRT entry during acpi_pci_enable_irq()
On Tue, 2013-02-12 at 18:42 -0800, Yinghai Lu wrote: > On Tue, Feb 12, 2013 at 6:20 PM, Peter Hurley > wrote: > > > > Reported-and-tested-by: Peter Hurley > > Thanks. > > > PS - I just happened to see this version on the list. Would you please > > cc me on any future versions? > > oh, my fault. I take it for granted that "git send-email" will pick > that email from > patch just like Cc. No problem. Actually, I'm sorry it took this long for me to test. I was stuck in an epic bisect that I eventually abandoned at the 41st test with it still in merge bases. -- 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: Debugging Thinkpad T430s occasional suspend failure.
On Tue, Feb 12, 2013 at 04:56:55PM -0800, Hugh Dickins wrote: > > so I can hit this pretty quickly with this.. > > > > while [ 1 ]; > > do > > rtcwake -s 5 -m no ; pm-suspend > > done > > > > Which should make it bisectable at least.. > > Thanks, I'll give that a try this evening. So uh, put a 'sleep 5' in that loop. Turns out that the firmware on my Thinkpad craps itself when it tries to suspend while the cpu fan is still spinning back up, and eventually it gets in a state (on a 'good' boot) where the fan is stuck in the 'off' state. Result: hot laptop, machine check exceptions, and then a nice "CPU FAN ERROR" message from the BIOS on next reboot. Full marks Lenovo. Dave -- 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/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Tuesday, February 12, 2013 10:55 PM > To: KY Srinivasan > Cc: Yinghai Lu; mi...@kernel.org; linux-kernel@vger.kernel.org; > t...@linutronix.de; h...@linux.intel.com; linux-tip-comm...@vger.kernel.org > Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special > hypervisor interrupts > > On 02/12/2013 07:49 PM, KY Srinivasan wrote: > >>> > >>> The issue was that you could turn on CONFIG_HYPERV without enabling > >>> CONFIG_X86_LOCAL_APIC. Peter fixed it. > >>> > >> > >> He is asking why you are using IS_ENABLED() instead of #ifdef. The > >> difference is that IS_ENABLED() works even for modules. > > > > My mistake! > > > > Well, which one do you need? I chose the IS_ENABLED() because I wanted to cover the case where HYPERV is configured as a module as well. K. Y > > -hpa > > > -- > H. Peter Anvin, Intel Open Source Technology Center > I work for Intel. I don't speak on their behalf. > >
Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
On 02/12/2013 07:49 PM, KY Srinivasan wrote: The issue was that you could turn on CONFIG_HYPERV without enabling CONFIG_X86_LOCAL_APIC. Peter fixed it. He is asking why you are using IS_ENABLED() instead of #ifdef. The difference is that IS_ENABLED() works even for modules. My mistake! Well, which one do you need? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Tuesday, February 12, 2013 10:46 PM
> To: KY Srinivasan
> Cc: Yinghai Lu; mi...@kernel.org; linux-kernel@vger.kernel.org;
> t...@linutronix.de; h...@linux.intel.com; linux-tip-comm...@vger.kernel.org
> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> hypervisor interrupts
>
> On 02/12/2013 07:32 PM, KY Srinivasan wrote:
> >>>
> >>> +#if IS_ENABLED(CONFIG_HYPERV)
> >>> +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> >>> + hyperv_callback_vector hyperv_vector_handler
> >>> +#endif /* CONFIG_HYPERV */
> >>> +
> >>
> >> so #ifdef CONFIG_HYPERV does not work here?
> >
> > The issue was that you could turn on CONFIG_HYPERV without enabling
> > CONFIG_X86_LOCAL_APIC. Peter fixed it.
> >
>
> He is asking why you are using IS_ENABLED() instead of #ifdef. The
> difference is that IS_ENABLED() works even for modules.
My mistake!
K. Y
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
N�r��yb�X��ǧv�^�)Þº{.n�+{zX����ܨ}ï¿½ï¿½ï¿½Æ z�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jÇ«y�m��@A�a���
0��h���i
Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
On 02/12/2013 07:32 PM, KY Srinivasan wrote: +#if IS_ENABLED(CONFIG_HYPERV) +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \ + hyperv_callback_vector hyperv_vector_handler +#endif /* CONFIG_HYPERV */ + so #ifdef CONFIG_HYPERV does not work here? The issue was that you could turn on CONFIG_HYPERV without enabling CONFIG_X86_LOCAL_APIC. Peter fixed it. He is asking why you are using IS_ENABLED() instead of #ifdef. The difference is that IS_ENABLED() works even for modules. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: [ 61/61] drm/nouveau: add lockdep annotations
On Tue, 2013-02-12 at 12:35 -0800, Greg Kroah-Hartman wrote: > 3.7-stable review patch. If anyone has any objections, please let me know. FWIW, I never saw this on 3.7 but it happened 1st time on 3.8-rcX I haven't tested this fix either. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/6] mfd: Add ChromeOS EC implementation
On Tue, 2013-02-12 at 18:42 -0800, Simon Glass wrote:
> This is the base EC implementation, which provides a high level
> interface to the EC for use by the rest of the kernel. The actual
> communcations is dealt with by a separate protocol driver which
> registers itself with this interface.
trivial logging message comments...
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
[]
> +struct cros_ec_device *cros_ec_alloc(const char *name)
> +{
> + struct cros_ec_device *ec_dev;
> +
> + ec_dev = kzalloc(sizeof(*ec_dev), GFP_KERNEL);
> + if (ec_dev == NULL) {
> + dev_err(ec_dev->dev, "cannot allocate\n");
allocation OOM messages aren't useful as there's
a standard one on all allocs without __GFP_WARN
> +int cros_ec_register(struct cros_ec_device *ec_dev)
> +{
[]
> + ec_dev->din = kmalloc(ec_dev->din_size, GFP_KERNEL);
> + if (!ec_dev->din) {
> + err = -ENOMEM;
> + dev_err(dev, "cannot allocate din\n");
etc...
> + if (err) {
> + dev_err(dev, "failed to add mfd devices");
missing terminating newline
--
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/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Tuesday, February 12, 2013 9:56 PM
> To: mi...@kernel.org; h...@zytor.com; linux-kernel@vger.kernel.org; KY
> Srinivasan; t...@linutronix.de; h...@linux.intel.com
> Cc: linux-tip-comm...@vger.kernel.org
> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special
> hypervisor interrupts
>
> On Tue, Feb 12, 2013 at 4:58 PM, tip-bot for K. Y. Srinivasan
> wrote:
> > Commit-ID: bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> > Gitweb:
> http://git.kernel.org/tip/bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> > Author: K. Y. Srinivasan
> > AuthorDate: Sun, 3 Feb 2013 17:22:39 -0800
> > Committer: H. Peter Anvin
> > CommitDate: Tue, 12 Feb 2013 16:27:15 -0800
> >
> > X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> >
> > Starting with win8, vmbus interrupts can be delivered on any VCPU in the
> > guest
> > and furthermore can be concurrently active on multiple VCPUs. Support this
> > interrupt delivery model by setting up a separate IDT entry for Hyper-V
> > vmbus.
> > interrupts. I would like to thank Jan Beulich and
> > Thomas Gleixner , for their help.
> >
> > In this version of the patch, based on the feedback, I have merged the IDT
> > vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
> > based on Jan's feedback I have added the necessary compilation switches.
> >
> > Signed-off-by: K. Y. Srinivasan
> > Link: http://lkml.kernel.org/r/1359940959-32168-3-git-send-email-
> k...@microsoft.com
> > Signed-off-by: H. Peter Anvin
> > ---
> > arch/x86/include/asm/irq_vectors.h | 4 ++--
> > arch/x86/include/asm/mshyperv.h| 4
> > arch/x86/kernel/cpu/mshyperv.c | 44
> ++
> > arch/x86/kernel/entry_32.S | 9 +++-
> > arch/x86/kernel/entry_64.S | 7 +-
> > drivers/xen/events.c | 7 +++---
> > 6 files changed, 68 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/irq_vectors.h
> b/arch/x86/include/asm/irq_vectors.h
> > index 1508e51..aac5fa6 100644
> > --- a/arch/x86/include/asm/irq_vectors.h
> > +++ b/arch/x86/include/asm/irq_vectors.h
> > @@ -109,8 +109,8 @@
> >
> > #define UV_BAU_MESSAGE 0xf5
> >
> > -/* Xen vector callback to receive events in a HVM domain */
> > -#define XEN_HVM_EVTCHN_CALLBACK0xf3
> > +/* Vector on which hypervisor callbacks will be delivered */
> > +#define HYPERVISOR_CALLBACK_VECTOR 0xf3
> >
> > /*
> > * Local APIC timer IRQ vector is on a different priority level,
> > diff --git a/arch/x86/include/asm/mshyperv.h
> b/arch/x86/include/asm/mshyperv.h
> > index 79ce568..c2934be 100644
> > --- a/arch/x86/include/asm/mshyperv.h
> > +++ b/arch/x86/include/asm/mshyperv.h
> > @@ -11,4 +11,8 @@ struct ms_hyperv_info {
> >
> > extern struct ms_hyperv_info ms_hyperv;
> >
> > +void hyperv_callback_vector(void);
> > +void hyperv_vector_handler(struct pt_regs *regs);
> > +void hv_register_vmbus_handler(int irq, irq_handler_t handler);
> > +
> > #endif
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> b/arch/x86/kernel/cpu/mshyperv.c
> > index 4dab317..a7d26d8 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -14,10 +14,15 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> >
> > struct ms_hyperv_info ms_hyperv;
> > EXPORT_SYMBOL_GPL(ms_hyperv);
> > @@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
> >
> > if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
> > clocksource_register_hz(_cs, NSEC_PER_SEC/100);
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > + /*
> > +* Setup the IDT for hypervisor callback.
> > +*/
> > + alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
> hyperv_callback_vector);
> > +#endif
> > }
> >
> > const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
> > @@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86
> x86_hyper_ms_hyperv = {
> > .init_platform = ms_hyperv_init_platform,
> > };
> > EXPORT_SYMBOL(x86_hyper_ms_hyperv);
> > +
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > +static int vmbus_irq = -1;
> > +static irq_handler_t vmbus_isr;
> > +
> > +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> > +{
> > + vmbus_irq = irq;
> > + vmbus_isr = handler;
> > +}
> > +
> > +void hyperv_vector_handler(struct pt_regs *regs)
> > +{
> > + struct pt_regs *old_regs = set_irq_regs(regs);
> > + struct irq_desc *desc;
> > +
> > + irq_enter();
> > + exit_idle();
> > +
> > + desc = irq_to_desc(vmbus_irq);
> > +
> > + if (desc)
> > + generic_handle_irq_desc(vmbus_irq, desc);
> > +
> > + irq_exit();
> > +
Re: [PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
Hi Rafael,
I have another comment at container.c.
2013/02/13 12:08, Yasuaki Ishimatsu wrote:
Hi Rafael,
The patch seems good.
There is a comment below.
2013/02/13 9:19, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki
---
On top of linux-pm.git/linux-next.
Thanks,
Rafael
---
drivers/acpi/acpi_memhotplug.c | 56 +++---
drivers/acpi/container.c | 10 +++--
drivers/acpi/dock.c| 19 --
drivers/acpi/processor_driver.c| 24 +---
drivers/acpi/scan.c| 69
+
drivers/pci/hotplug/acpiphp_glue.c |6 +++
drivers/pci/hotplug/sgi_hotplug.c |5 ++
include/acpi/acpi_bus.h|3 +
8 files changed, 138 insertions(+), 54 deletions(-)
Index: test/drivers/acpi/scan.c
===
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -42,6 +42,18 @@ struct acpi_device_bus_id{
struct list_head node;
};
+void acpi_scan_lock_acquire(void)
+{
+mutex_lock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_acquire);
+
+void acpi_scan_lock_release(void)
+{
+mutex_unlock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
+
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
{
if (!handler || !handler->attach)
@@ -95,8 +107,6 @@ acpi_device_modalias_show(struct device
}
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
-static void __acpi_bus_trim(struct acpi_device *start);
-
/**
* acpi_bus_hot_remove_device: hot-remove a device and its children
* @context: struct acpi_eject_event pointer (freed in this func)
@@ -107,7 +117,7 @@ static void __acpi_bus_trim(struct acpi_
*/
void acpi_bus_hot_remove_device(void *context)
{
-struct acpi_eject_event *ej_event = (struct acpi_eject_event *) context;
+struct acpi_eject_event *ej_event = context;
struct acpi_device *device = ej_event->device;
acpi_handle handle = device->handle;
acpi_handle temp;
@@ -118,11 +128,19 @@ void acpi_bus_hot_remove_device(void *co
mutex_lock(_scan_lock);
+/* If there is no handle, the device node has been unregistered. */
+if (!device->handle) {
+dev_dbg(>dev, "ACPI handle missing\n");
+put_device(>dev);
+goto out;
+}
+
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Hot-removing device %s...\n", dev_name(>dev)));
-__acpi_bus_trim(device);
-
[PATCH] staging/comedi: Fix undefined array subscript
In vmk80xx_do_insn_bits the local variable reg, which is used as an
index to the tx_buf array, can be used uninitialized if
- data[0] == 0
and
- devpriv->model != VMK8061_MODEL
-> we get into the else branch without having reg initialized.
Since the driver usually differentiates between VMK8061_MODEL and
VMK8055_MODEL it's safe to assume that VMK8055_DO_REG was meant as an
initial value.
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/vmk80xx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index ebf2d48..4ced56a 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -716,6 +716,7 @@ static int vmk80xx_do_insn_bits(struct comedi_device *dev,
retval = 2;
}
} else {
+ reg = VMK8055_DO_REG;
data[1] = tx_buf[reg];
retval = 2;
}
--
1.7.8.6
--
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] VSOCK: Introduce VM Sockets
Hi Gerd, > > +/* Option name for socket's service label. Use as the option name in > > + * setsockopt(3) or getsockopt(3) to set or get the service label for a > > socket. > > + * The service label is a C-style NUL-terminated string. Only available > > for > > + * hypervisor endpoints. > > + */ > > + > > +#define SO_VM_SOCKETS_SERVICE_LABEL 4 > > + > > What is this and how does it work? Oops, that's specific to ESX. Thankfully it's only in the header and not in anything under net/vmw_vsock, so removing it is easy. I'll send out a patch in the morning. Thanks! - Andy -- 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: [Pv-drivers] [PATCH 1/1] VSOCK: Introduce VM Sockets
> stream_has_data: Returns amount of data available (in bytes) in the > socket's receive buffer, or -1 if empty. > > stream_has_space: Returns amount of space available (in bytes) in the > socket's send buffer, or -1 if full. Actually, I think it's for empty/full, and -1 for an error (say, the transport closed or whatever). Thanks! - Andy -- 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 / hotplug: Fix concurrency issues and memory leaks
Hi Rafael,
The patch seems good.
There is a comment below.
2013/02/13 9:19, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki
---
On top of linux-pm.git/linux-next.
Thanks,
Rafael
---
drivers/acpi/acpi_memhotplug.c | 56 +++---
drivers/acpi/container.c | 10 +++--
drivers/acpi/dock.c| 19 --
drivers/acpi/processor_driver.c| 24 +---
drivers/acpi/scan.c| 69
+
drivers/pci/hotplug/acpiphp_glue.c |6 +++
drivers/pci/hotplug/sgi_hotplug.c |5 ++
include/acpi/acpi_bus.h|3 +
8 files changed, 138 insertions(+), 54 deletions(-)
Index: test/drivers/acpi/scan.c
===
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -42,6 +42,18 @@ struct acpi_device_bus_id{
struct list_head node;
};
+void acpi_scan_lock_acquire(void)
+{
+ mutex_lock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_acquire);
+
+void acpi_scan_lock_release(void)
+{
+ mutex_unlock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
+
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
{
if (!handler || !handler->attach)
@@ -95,8 +107,6 @@ acpi_device_modalias_show(struct device
}
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
-static void __acpi_bus_trim(struct acpi_device *start);
-
/**
* acpi_bus_hot_remove_device: hot-remove a device and its children
* @context: struct acpi_eject_event pointer (freed in this func)
@@ -107,7 +117,7 @@ static void __acpi_bus_trim(struct acpi_
*/
void acpi_bus_hot_remove_device(void *context)
{
- struct acpi_eject_event *ej_event = (struct acpi_eject_event *) context;
+ struct acpi_eject_event *ej_event = context;
struct acpi_device *device = ej_event->device;
acpi_handle handle = device->handle;
acpi_handle temp;
@@ -118,11 +128,19 @@ void acpi_bus_hot_remove_device(void *co
mutex_lock(_scan_lock);
+ /* If there is no handle, the device node has been unregistered. */
+ if (!device->handle) {
+ dev_dbg(>dev, "ACPI handle missing\n");
+ put_device(>dev);
+ goto out;
+ }
+
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Hot-removing device %s...\n", dev_name(>dev)));
- __acpi_bus_trim(device);
- /* Device node has been
[PATCH 9/9] staging/rtl8187se: Mark functions as static to silence sparse
Sparse complains that some functions can be declared as static:
123:6: warning: symbol 'PlatformIOWrite1Byte' was not declared. Should it be
static?
129:6: warning: symbol 'PlatformIOWrite2Byte' was not declared. Should it be
static?
135:6: warning: symbol 'PlatformIOWrite4Byte' was not declared. Should it be
static?
178:6: warning: symbol 'SetOutputEnableOfRfPins' was not declared. Should it
be static?
354:6: warning: symbol 'ZEBRA_Config_85BASIC_HardCode' was not declared.
Should it be static?
655:6: warning: symbol 'InitTxPwrTracking87SE' was not declared. Should it be
static?
665:6: warning: symbol 'PhyConfig8185' was not declared. Should it be static?
692:6: warning: symbol 'HwConfigureRTL8185' was not declared. Should it be
static?
817:4: warning: symbol 'GetSupportedWirelessMode8185' was not declared. Should
it be static?
822:6: warning: symbol 'ActUpdateChannelAccessSetting' was not declared.
Should it be static?
857:6: warning: symbol 'ActSetWirelessMode8185' was not declared. Should it be
static?
914:6: warning: symbol 'MgntDisconnectIBSS' was not declared. Should it be
static?
940:6: warning: symbol 'MlmeDisassociateRequest' was not declared. Should it
be static?
957:6: warning: symbol 'MgntDisconnectAP' was not declared. Should it be static?
975:6: warning: symbol 'MgntDisconnect' was not declared. Should it be static?
1011:6: warning: symbol 'SetRFPowerState' was not declared. Should it be static?
1115:6: warning: symbol 'InactivePowerSave' was not declared. Should it be
static?
-> Add the static keyword.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 34 +++---
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 2ca857d..978dc5f 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -120,19 +120,19 @@ static u8 PlatformIORead1Byte(struct net_device *dev, u32
offset)
return read_nic_byte(dev, offset);
}
-void PlatformIOWrite1Byte(struct net_device *dev, u32 offset, u8 data)
+static void PlatformIOWrite1Byte(struct net_device *dev, u32 offset, u8 data)
{
write_nic_byte(dev, offset, data);
read_nic_byte(dev, offset); /* To make sure write operation is
completed, 2005.11.09, by rcnjko. */
}
-void PlatformIOWrite2Byte(struct net_device *dev, u32 offset, u16 data)
+static void PlatformIOWrite2Byte(struct net_device *dev, u32 offset, u16 data)
{
write_nic_word(dev, offset, data);
read_nic_word(dev, offset); /* To make sure write operation is
completed, 2005.11.09, by rcnjko. */
}
-void PlatformIOWrite4Byte(struct net_device *dev, u32 offset, u32 data)
+static void PlatformIOWrite4Byte(struct net_device *dev, u32 offset, u32 data)
{
if (offset == PhyAddr) {
/* For Base Band configuration. */
@@ -175,7 +175,7 @@ void PlatformIOWrite4Byte(struct net_device *dev, u32
offset, u32 data)
}
}
-void SetOutputEnableOfRfPins(struct net_device *dev)
+static void SetOutputEnableOfRfPins(struct net_device *dev)
{
write_nic_word(dev, RFPinsEnable, 0x1bff);
}
@@ -327,7 +327,7 @@ bool SetAntennaConfig87SE(struct net_device *dev,
*--
*/
-void ZEBRA_Config_85BASIC_HardCode(struct net_device *dev)
+static void ZEBRA_Config_85BASIC_HardCode(struct net_device *dev)
{
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
@@ -628,7 +628,7 @@ void UpdateInitialGain(struct net_device *dev)
* Tx Power tracking mechanism routine on 87SE.
* Created by Roger, 2007.12.11.
*/
-void InitTxPwrTracking87SE(struct net_device *dev)
+static void InitTxPwrTracking87SE(struct net_device *dev)
{
u32 u4bRfReg;
@@ -638,7 +638,7 @@ void InitTxPwrTracking87SE(struct net_device *dev)
RF_WriteReg(dev, 0x02, u4bRfReg|PWR_METER_EN);
mdelay(1);
}
-void PhyConfig8185(struct net_device *dev)
+static void PhyConfig8185(struct net_device *dev)
{
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
write_nic_dword(dev, RCR, priv->ReceiveConfig);
@@ -665,7 +665,7 @@ void PhyConfig8185(struct net_device *dev)
return;
}
-void HwConfigureRTL8185(struct net_device *dev)
+static void HwConfigureRTL8185(struct net_device *dev)
{
/* RTL8185_TODO: Determine Retrylimit, TxAGC, AutoRateFallback control.
*/
u8 bUNIVERSAL_CONTROL_RL = 0;
@@ -790,12 +790,12 @@ static void MacConfig_85BASIC(struct net_device *dev)
write_nic_byte(dev, 0x24E, 0x01);
}
-u8 GetSupportedWirelessMode8185(struct net_device *dev)
+static u8 GetSupportedWirelessMode8185(struct net_device *dev)
{
return WIRELESS_MODE_B | WIRELESS_MODE_G;
}
-void ActUpdateChannelAccessSetting(struct net_device *dev,
+static void
[PATCH 5/9] staging/rtl8187se: Reuse ReadBBPortUchar to avoid duplicated code
WriteBBPortUchar reimplements ReadBBPortUchar in its body, so we can
remove the duplicated code by calling ReadBBPortUchar directly.
Unfortunately we have to move ReadBBPortUchar around; while at it we can
also get rid of the temporary variable for the return value.
Also we can remove the local variables UCharData and RegisterContent in
WriteBBPortUchar as they are not used / without effect.
Both functions are only 'local' so we can mark them as static.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 30 +++---
1 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 1e54ead..a3b836c 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -287,35 +287,19 @@ u16 RF_ReadReg(struct net_device *dev, u8 offset)
return reg;
}
+static u8 ReadBBPortUchar(struct net_device *dev, u32 addr)
+{
+ PlatformIOWrite4Byte(dev, PhyAddr, addr & 0xff7f);
+ return PlatformIORead1Byte(dev, PhyDataR);
+}
/* by Owen on 04/07/14 for writing BB register successfully */
-void WriteBBPortUchar(struct net_device *dev, u32 Data)
+static void WriteBBPortUchar(struct net_device *dev, u32 Data)
{
- /* u8 TimeoutCounter; */
- u8 RegisterContent;
- u8 UCharData;
-
- UCharData = (u8)((Data & 0xff00) >> 8);
PlatformIOWrite4Byte(dev, PhyAddr, Data);
- /* for(TimeoutCounter = 10; TimeoutCounter > 0; TimeoutCounter--) */
- {
- PlatformIOWrite4Byte(dev, PhyAddr, Data & 0xff7f);
- RegisterContent = PlatformIORead1Byte(dev, PhyDataR);
- /*if(UCharData == RegisterContent) */
- /* break; */
- }
+ ReadBBPortUchar(dev, Data);
}
-u8 ReadBBPortUchar(struct net_device *dev, u32 addr)
-{
- /*u8TimeoutCounter; */
- u8 RegisterContent;
-
- PlatformIOWrite4Byte(dev, PhyAddr, addr & 0xff7f);
- RegisterContent = PlatformIORead1Byte(dev, PhyDataR);
-
- return RegisterContent;
-}
/*
* Description:
* Perform Antenna settings with antenna diversity on 87SE.
--
1.7.8.6
--
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/9] staging/rtl8187se: Remove code without effect
Am Mittwoch, 13. Februar 2013, 03:54:26 schrieb Peter Huewe: > Local variable AcmCtrl is never read/used after assignment so we can remove > all assignments to it and the related code around the assignments. > > Signed-off-by: Peter Huewe Sorry wrong distribution list. Seems my script went a bit nuts. Will resend with correct list. Sorry for the noise. Peter -- 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 7/9] staging/rtl8187se: Remove unused functions PlatformIORead2Byte / PlatformIORead4Byte
These two functions PlatformIORead2Byte and PlatformIORead4Byte are
unused and thus can be removed.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 20
1 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 1dfa78e..005fb0b 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -175,26 +175,6 @@ void PlatformIOWrite4Byte(struct net_device *dev, u32
offset, u32 data)
}
}
-u16 PlatformIORead2Byte(struct net_device *dev, u32 offset)
-{
- u16 data = 0;
-
- data = read_nic_word(dev, offset);
-
-
- return data;
-}
-
-u32 PlatformIORead4Byte(struct net_device *dev, u32 offset)
-{
- u32 data = 0;
-
- data = read_nic_dword(dev, offset);
-
-
- return data;
-}
-
void SetOutputEnableOfRfPins(struct net_device *dev)
{
write_nic_word(dev, RFPinsEnable, 0x1bff);
--
1.7.8.6
--
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 8/9] staging/rtl8187se: Remove duplicated code by using an offset
In SetAntennaConfig87SE both branches of if (bAntDiversity) do exactly
the same, except that there is an offset of 0x80 for the register values
if bAntDiversity is true.
-> Consolidate both branches and assign the offset if necessary.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 76 +++
1 files changed, 26 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 005fb0b..2ca857d 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -284,62 +284,38 @@ bool SetAntennaConfig87SE(struct net_device *dev,
{
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
bool bAntennaSwitched = true;
+ u8 ant_diversity_offset = 0x00; /* 0x00 = disabled, 0x80 = enabled
*/
/* printk("SetAntennaConfig87SE(): DefaultAnt(%d),
bAntDiversity(%d)\n", DefaultAnt, bAntDiversity); */
/* Threshold for antenna diversity. */
write_phy_cck(dev, 0x0c, 0x09); /* Reg0c : 09 */
- if (bAntDiversity) {/* Enable Antenna Diversity. */
- if (DefaultAnt == 1) { /* aux antenna */
-
- /* Mac register, aux antenna */
- write_nic_byte(dev, ANTSEL, 0x00);
-
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0xbb); /* Reg11 : bb */
- write_phy_cck(dev, 0x01, 0xc7); /* Reg01 : c7 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0D, 0x54);/* Reg0d : 54 */
- write_phy_ofdm(dev, 0x18, 0xb2);/* Reg18 : b2 */
- } else { /* use main antenna */
- /* Mac register, main antenna */
- write_nic_byte(dev, ANTSEL, 0x03);
- /* base band */
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0x9b); /* Reg11 : 9b */
- write_phy_cck(dev, 0x01, 0xc7); /* Reg01 : c7 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0d, 0x5c); /* Reg0d : 5c */
- write_phy_ofdm(dev, 0x18, 0xb2); /* Reg18 : b2 */
- }
- } else {
- /* Disable Antenna Diversity. */
- if (DefaultAnt == 1) { /* aux Antenna */
- /* Mac register, aux antenna */
- write_nic_byte(dev, ANTSEL, 0x00);
-
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0xbb); /* Reg11 : bb */
- write_phy_cck(dev, 0x01, 0x47); /* Reg01 : 47 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0D, 0x54);/* Reg0d : 54 */
- write_phy_ofdm(dev, 0x18, 0x32);/* Reg18 : 32 */
- } else { /* main Antenna */
- /* Mac register, main antenna */
- write_nic_byte(dev, ANTSEL, 0x03);
-
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0x9b); /* Reg11 : 9b */
- write_phy_cck(dev, 0x01, 0x47); /* Reg01 : 47 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0D, 0x5c); /* Reg0d : 5c */
- write_phy_ofdm(dev, 0x18, 0x32); /*Reg18 : 32 */
- }
+ if (bAntDiversity) /* Enable Antenna Diversity. */
+ ant_diversity_offset = 0x80;
+
+ if (DefaultAnt == 1) { /* aux Antenna */
+ /* Mac register, aux antenna */
+ write_nic_byte(dev, ANTSEL, 0x00);
+
+ /* Config CCK RX antenna. */
+ write_phy_cck(dev, 0x11, 0xbb); /* Reg11 : bb */
+ write_phy_cck(dev, 0x01, 0x47|ant_diversity_offset); /* Reg01 :
47 | ant_diversity_offset */
+
+ /* Config OFDM RX antenna. */
+ write_phy_ofdm(dev, 0x0D, 0x54);/* Reg0d : 54 */
+ write_phy_ofdm(dev, 0x18, 0x32|ant_diversity_offset); /*
Reg18 : 32 */
+ } else { /* main Antenna */
+ /* Mac register, main antenna */
+ write_nic_byte(dev, ANTSEL, 0x03);
+
+ /* Config CCK RX antenna. */
+ write_phy_cck(dev, 0x11, 0x9b); /* Reg11 : 9b */
+ write_phy_cck(dev, 0x01, 0x47|ant_diversity_offset); /* Reg01 :
47 */
+
+ /* Config OFDM RX antenna. */
+ write_phy_ofdm(dev, 0x0D, 0x5c); /* Reg0d : 5c */
+ write_phy_ofdm(dev, 0x18, 0x32|ant_diversity_offset); /*Reg18 :
32 */
}
priv->CurrAntennaIndex = DefaultAnt; /* Update default settings. */
return
[PATCH 6/9] staging/rtl8187se: Remove temporary variable for return value
The simple PlatformIORead1Byte function doesn't need to store its return
value in a temporary variable; rather simply return the value directly.
By moving the function to the top we can also get rid of the forward
declaration.
The wrapper functions could be easily replaced by direct calls to
read_nic_byte but is kept for readability.
Since this functions is local only we can mark it as static.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index a3b836c..1dfa78e 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -115,6 +115,11 @@ static u8 OFDM_CONFIG[]= {
*---
*/
+static u8 PlatformIORead1Byte(struct net_device *dev, u32 offset)
+{
+ return read_nic_byte(dev, offset);
+}
+
void PlatformIOWrite1Byte(struct net_device *dev, u32 offset, u8 data)
{
write_nic_byte(dev, offset, data);
@@ -127,8 +132,6 @@ void PlatformIOWrite2Byte(struct net_device *dev, u32
offset, u16 data)
read_nic_word(dev, offset); /* To make sure write operation is
completed, 2005.11.09, by rcnjko. */
}
-u8 PlatformIORead1Byte(struct net_device *dev, u32 offset);
-
void PlatformIOWrite4Byte(struct net_device *dev, u32 offset, u32 data)
{
if (offset == PhyAddr) {
@@ -172,16 +175,6 @@ void PlatformIOWrite4Byte(struct net_device *dev, u32
offset, u32 data)
}
}
-u8 PlatformIORead1Byte(struct net_device *dev, u32 offset)
-{
- u8 data = 0;
-
- data = read_nic_byte(dev, offset);
-
-
- return data;
-}
-
u16 PlatformIORead2Byte(struct net_device *dev, u32 offset)
{
u16 data = 0;
--
1.7.8.6
--
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/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
On Tue, Feb 12, 2013 at 4:58 PM, tip-bot for K. Y. Srinivasan
wrote:
> Commit-ID: bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> Gitweb: http://git.kernel.org/tip/bc2b0331e077f576369a2b6c75d15ed4de4ef91f
> Author: K. Y. Srinivasan
> AuthorDate: Sun, 3 Feb 2013 17:22:39 -0800
> Committer: H. Peter Anvin
> CommitDate: Tue, 12 Feb 2013 16:27:15 -0800
>
> X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
>
> Starting with win8, vmbus interrupts can be delivered on any VCPU in the guest
> and furthermore can be concurrently active on multiple VCPUs. Support this
> interrupt delivery model by setting up a separate IDT entry for Hyper-V vmbus.
> interrupts. I would like to thank Jan Beulich and
> Thomas Gleixner , for their help.
>
> In this version of the patch, based on the feedback, I have merged the IDT
> vector for Xen and Hyper-V and made the necessary adjustments. Furhermore,
> based on Jan's feedback I have added the necessary compilation switches.
>
> Signed-off-by: K. Y. Srinivasan
> Link:
> http://lkml.kernel.org/r/1359940959-32168-3-git-send-email-...@microsoft.com
> Signed-off-by: H. Peter Anvin
> ---
> arch/x86/include/asm/irq_vectors.h | 4 ++--
> arch/x86/include/asm/mshyperv.h| 4
> arch/x86/kernel/cpu/mshyperv.c | 44
> ++
> arch/x86/kernel/entry_32.S | 9 +++-
> arch/x86/kernel/entry_64.S | 7 +-
> drivers/xen/events.c | 7 +++---
> 6 files changed, 68 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/irq_vectors.h
> b/arch/x86/include/asm/irq_vectors.h
> index 1508e51..aac5fa6 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -109,8 +109,8 @@
>
> #define UV_BAU_MESSAGE 0xf5
>
> -/* Xen vector callback to receive events in a HVM domain */
> -#define XEN_HVM_EVTCHN_CALLBACK0xf3
> +/* Vector on which hypervisor callbacks will be delivered */
> +#define HYPERVISOR_CALLBACK_VECTOR 0xf3
>
> /*
> * Local APIC timer IRQ vector is on a different priority level,
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 79ce568..c2934be 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -11,4 +11,8 @@ struct ms_hyperv_info {
>
> extern struct ms_hyperv_info ms_hyperv;
>
> +void hyperv_callback_vector(void);
> +void hyperv_vector_handler(struct pt_regs *regs);
> +void hv_register_vmbus_handler(int irq, irq_handler_t handler);
> +
> #endif
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 4dab317..a7d26d8 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -14,10 +14,15 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> struct ms_hyperv_info ms_hyperv;
> EXPORT_SYMBOL_GPL(ms_hyperv);
> @@ -77,6 +82,12 @@ static void __init ms_hyperv_init_platform(void)
>
> if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
> clocksource_register_hz(_cs, NSEC_PER_SEC/100);
> +#if IS_ENABLED(CONFIG_HYPERV)
> + /*
> +* Setup the IDT for hypervisor callback.
> +*/
> + alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, hyperv_callback_vector);
> +#endif
> }
>
> const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
> @@ -85,3 +96,36 @@ const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv
> = {
> .init_platform = ms_hyperv_init_platform,
> };
> EXPORT_SYMBOL(x86_hyper_ms_hyperv);
> +
> +#if IS_ENABLED(CONFIG_HYPERV)
> +static int vmbus_irq = -1;
> +static irq_handler_t vmbus_isr;
> +
> +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> +{
> + vmbus_irq = irq;
> + vmbus_isr = handler;
> +}
> +
> +void hyperv_vector_handler(struct pt_regs *regs)
> +{
> + struct pt_regs *old_regs = set_irq_regs(regs);
> + struct irq_desc *desc;
> +
> + irq_enter();
> + exit_idle();
> +
> + desc = irq_to_desc(vmbus_irq);
> +
> + if (desc)
> + generic_handle_irq_desc(vmbus_irq, desc);
> +
> + irq_exit();
> + set_irq_regs(old_regs);
> +}
> +#else
> +void hv_register_vmbus_handler(int irq, irq_handler_t handler)
> +{
> +}
> +#endif
> +EXPORT_SYMBOL_GPL(hv_register_vmbus_handler);
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 6ed91d9..8831176 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1091,11 +1091,18 @@ ENTRY(xen_failsafe_callback)
> _ASM_EXTABLE(4b,9b)
> ENDPROC(xen_failsafe_callback)
>
> -BUILD_INTERRUPT3(xen_hvm_callback_vector, XEN_HVM_EVTCHN_CALLBACK,
> +BUILD_INTERRUPT3(xen_hvm_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
> xen_evtchn_do_upcall)
>
> #endif /* CONFIG_XEN */
>
> +#if
[PATCH 2/9] staging/rtl8187se: Remove code without effect
The local variable u4bAcParam is never read/used after assignment,
thus we can remove the declaration, assignment and any related code.
-> the local variables u1bAIFS, eACI and pAcParam can also be removed.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 39 +--
1 files changed, 1 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 41419f0..5495d1e 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -928,44 +928,7 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
for (eACI = 0; eACI < AC_MAX; eACI++) {
AcParam.f.AciAifsn.f.ACI = (u8)eACI;
- {
- PAC_PARAM pAcParam =
(PAC_PARAM)();
- AC_CODING eACI;
- u8 u1bAIFS;
- u32 u4bAcParam;
-
- /* Retrieve parameters to update. */
- eACI = pAcParam->f.AciAifsn.f.ACI;
- u1bAIFS = pAcParam->f.AciAifsn.f.AIFSN *
ChnlAccessSetting->SlotTimeTimer + aSifsTime;
- u4bAcParam = u32)(pAcParam->f.TXOPLimit))
<< AC_PARAM_TXOP_LIMIT_OFFSET)|
-
(((u32)(pAcParam->f.Ecw.f.ECWmax)) << AC_PARAM_ECW_MAX_OFFSET) |
-
(((u32)(pAcParam->f.Ecw.f.ECWmin)) << AC_PARAM_ECW_MIN_OFFSET) |
- (((u32)u1bAIFS) <<
AC_PARAM_AIFS_OFFSET));
-
- switch (eACI) {
- case AC1_BK:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- case AC0_BE:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- case AC2_VI:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- case AC3_VO:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- default:
- DMESGW("SetHwReg8185(): invalid ACI: %d
!\n", eACI);
- break;
- }
-
- write_nic_byte(dev, ACM_CONTROL, 0);
- }
+ write_nic_byte(dev, ACM_CONTROL, 0);
}
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] staging/rtl8187se: Remove unused/unnecessary variables
The local variables priv and ieee are not used and thus can be removed.
The local variable u1bAIFS is not used/read after assignment and thus
can be removed.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 4aca954..1e54ead 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -866,10 +866,7 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
WIRELESS_MODE WirelessMode,
PCHANNEL_ACCESS_SETTING ChnlAccessSetting)
{
- struct r8180_priv *priv = ieee80211_priv(dev);
- struct ieee80211_device *ieee = priv->ieee80211;
AC_CODING eACI;
- u8 u1bAIFS;
/*
*
@@ -891,8 +888,6 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
write_nic_byte(dev, SIFS, ChnlAccessSetting->SIFS_Timer);
write_nic_byte(dev, SLOT, ChnlAccessSetting->SlotTimeTimer); /*
Rewrited from directly use PlatformEFIOWrite1Byte(), by Annie, 2006-03-29. */
- u1bAIFS = aSifsTime + (2 * ChnlAccessSetting->SlotTimeTimer);
-
write_nic_byte(dev, EIFS, ChnlAccessSetting->EIFS_Timer);
write_nic_byte(dev, AckTimeOutReg, 0x5B); /* Suggested by
wcchu, it is the default value of EIFS register, 2005.12.08. */
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] staging/rtl8187se: Remove code without effect
The local variable AcParam is only assigned to but not read/used
afterwards, thus it and all related code can be removed.
The bFollowLegacySetting variable and check can also be removed as it is
always true.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 35 +-
1 files changed, 2 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 5495d1e..4aca954 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -869,8 +869,6 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
struct r8180_priv *priv = ieee80211_priv(dev);
struct ieee80211_device *ieee = priv->ieee80211;
AC_CODING eACI;
- AC_PARAMAcParam;
- u8 bFollowLegacySetting = 0;
u8 u1bAIFS;
/*
@@ -899,37 +897,8 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
write_nic_byte(dev, AckTimeOutReg, 0x5B); /* Suggested by
wcchu, it is the default value of EIFS register, 2005.12.08. */
- { /* Legacy 802.11. */
- bFollowLegacySetting = 1;
-
- }
-
- /* this setting is copied from rtl8187B. xiong-2006-11-13 */
- if (bFollowLegacySetting) {
-
- /*
-* Follow 802.11 seeting to AC parameter, all AC shall use
the same parameter.
-* 2005.12.01, by rcnjko.
-*/
- AcParam.longData = 0;
- AcParam.f.AciAifsn.f.AIFSN = 2; /* Follow 802.11 DIFS. */
- AcParam.f.AciAifsn.f.ACM = 0;
- AcParam.f.Ecw.f.ECWmin = ChnlAccessSetting->CWminIndex; /*
Follow 802.11 CWmin. */
- AcParam.f.Ecw.f.ECWmax = ChnlAccessSetting->CWmaxIndex; /*
Follow 802.11 CWmax. */
- AcParam.f.TXOPLimit = 0;
-
- /* lzm reserved 080826 */
- /* For turbo mode setting. port from 87B by Isaiah 2008-08-01 */
- if (ieee->current_network.Turbo_Enable == 1)
- AcParam.f.TXOPLimit = 0x01FF;
- /* For 87SE with Intel 4965 Ad-Hoc mode have poor throughput
(19MB) */
- if (ieee->iw_mode == IW_MODE_ADHOC)
- AcParam.f.TXOPLimit = 0x0020;
-
- for (eACI = 0; eACI < AC_MAX; eACI++) {
- AcParam.f.AciAifsn.f.ACI = (u8)eACI;
- write_nic_byte(dev, ACM_CONTROL, 0);
- }
+ for (eACI = 0; eACI < AC_MAX; eACI++) {
+ write_nic_byte(dev, ACM_CONTROL, 0);
}
}
--
1.7.8.6
--
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/9] staging/rtl8187se: Remove code without effect
Local variable AcmCtrl is never read/used after assignment so we can remove
all assignments to it and the related code around the assignments.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 49 +--
1 files changed, 1 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index f1db9e4..41419f0 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -964,54 +964,7 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
break;
}
- /* Cehck ACM bit. */
- /* If it is set, immediately set ACM control
bit to downgrading AC for passing WMM testplan. Annie, 2005-12-13. */
- {
- PACI_AIFSN pAciAifsn =
(PACI_AIFSN)(>f.AciAifsn);
- AC_CODING eACI = pAciAifsn->f.ACI;
-
- /*for 8187B AsynIORead issue */
- u8 AcmCtrl = 0;
- if (pAciAifsn->f.ACM) {
- /* ACM bit is 1. */
- switch (eACI) {
- case AC0_BE:
- AcmCtrl |=
(BEQ_ACM_EN|BEQ_ACM_CTL|ACM_HW_EN); /* or 0x21 */
- break;
-
- case AC2_VI:
- AcmCtrl |=
(VIQ_ACM_EN|VIQ_ACM_CTL|ACM_HW_EN); /* or 0x42 */
- break;
-
- case AC3_VO:
- AcmCtrl |=
(VOQ_ACM_EN|VOQ_ACM_CTL|ACM_HW_EN); /* or 0x84 */
- break;
-
- default:
- DMESGW("SetHwReg8185():
[HW_VAR_ACM_CTRL] ACM set failed: eACI is %d\n", eACI);
- break;
- }
- } else {
- /* ACM bit is 0. */
- switch (eACI) {
- case AC0_BE:
- AcmCtrl &=
((~BEQ_ACM_EN) & (~BEQ_ACM_CTL) & (~ACM_HW_EN)); /* and 0xDE */
- break;
-
- case AC2_VI:
- AcmCtrl &=
((~VIQ_ACM_EN) & (~VIQ_ACM_CTL) & (~ACM_HW_EN)); /* and 0xBD */
- break;
-
- case AC3_VO:
- AcmCtrl &=
((~VOQ_ACM_EN) & (~VOQ_ACM_CTL) & (~ACM_HW_EN)); /* and 0x7B */
- break;
-
- default:
- break;
- }
- }
- write_nic_byte(dev, ACM_CONTROL, 0);
- }
+ write_nic_byte(dev, ACM_CONTROL, 0);
}
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] staging/rtl8187se: Remove code without effect
The local variable AcParam is only assigned to but not read/used
afterwards, thus it and all related code can be removed.
The bFollowLegacySetting variable and check can also be removed as it is
always true.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 35 +-
1 files changed, 2 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 5495d1e..4aca954 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -869,8 +869,6 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
struct r8180_priv *priv = ieee80211_priv(dev);
struct ieee80211_device *ieee = priv->ieee80211;
AC_CODING eACI;
- AC_PARAMAcParam;
- u8 bFollowLegacySetting = 0;
u8 u1bAIFS;
/*
@@ -899,37 +897,8 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
write_nic_byte(dev, AckTimeOutReg, 0x5B); /* Suggested by
wcchu, it is the default value of EIFS register, 2005.12.08. */
- { /* Legacy 802.11. */
- bFollowLegacySetting = 1;
-
- }
-
- /* this setting is copied from rtl8187B. xiong-2006-11-13 */
- if (bFollowLegacySetting) {
-
- /*
-* Follow 802.11 seeting to AC parameter, all AC shall use
the same parameter.
-* 2005.12.01, by rcnjko.
-*/
- AcParam.longData = 0;
- AcParam.f.AciAifsn.f.AIFSN = 2; /* Follow 802.11 DIFS. */
- AcParam.f.AciAifsn.f.ACM = 0;
- AcParam.f.Ecw.f.ECWmin = ChnlAccessSetting->CWminIndex; /*
Follow 802.11 CWmin. */
- AcParam.f.Ecw.f.ECWmax = ChnlAccessSetting->CWmaxIndex; /*
Follow 802.11 CWmax. */
- AcParam.f.TXOPLimit = 0;
-
- /* lzm reserved 080826 */
- /* For turbo mode setting. port from 87B by Isaiah 2008-08-01 */
- if (ieee->current_network.Turbo_Enable == 1)
- AcParam.f.TXOPLimit = 0x01FF;
- /* For 87SE with Intel 4965 Ad-Hoc mode have poor throughput
(19MB) */
- if (ieee->iw_mode == IW_MODE_ADHOC)
- AcParam.f.TXOPLimit = 0x0020;
-
- for (eACI = 0; eACI < AC_MAX; eACI++) {
- AcParam.f.AciAifsn.f.ACI = (u8)eACI;
- write_nic_byte(dev, ACM_CONTROL, 0);
- }
+ for (eACI = 0; eACI < AC_MAX; eACI++) {
+ write_nic_byte(dev, ACM_CONTROL, 0);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] staging/rtl8187se: Remove unused/unnecessary variables
The local variables priv and ieee are not used and thus can be removed.
The local variable u1bAIFS is not used/read after assignment and thus
can be removed.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 4aca954..1e54ead 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -866,10 +866,7 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
WIRELESS_MODE WirelessMode,
PCHANNEL_ACCESS_SETTING ChnlAccessSetting)
{
- struct r8180_priv *priv = ieee80211_priv(dev);
- struct ieee80211_device *ieee = priv->ieee80211;
AC_CODING eACI;
- u8 u1bAIFS;
/*
*
@@ -891,8 +888,6 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
write_nic_byte(dev, SIFS, ChnlAccessSetting->SIFS_Timer);
write_nic_byte(dev, SLOT, ChnlAccessSetting->SlotTimeTimer); /*
Rewrited from directly use PlatformEFIOWrite1Byte(), by Annie, 2006-03-29. */
- u1bAIFS = aSifsTime + (2 * ChnlAccessSetting->SlotTimeTimer);
-
write_nic_byte(dev, EIFS, ChnlAccessSetting->EIFS_Timer);
write_nic_byte(dev, AckTimeOutReg, 0x5B); /* Suggested by
wcchu, it is the default value of EIFS register, 2005.12.08. */
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] staging/rtl8187se: Remove code without effect
The local variable u4bAcParam is never read/used after assignment,
thus we can remove the declaration, assignment and any related code.
-> the local variables u1bAIFS, eACI and pAcParam can also be removed.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 39 +--
1 files changed, 1 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 41419f0..5495d1e 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -928,44 +928,7 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
for (eACI = 0; eACI < AC_MAX; eACI++) {
AcParam.f.AciAifsn.f.ACI = (u8)eACI;
- {
- PAC_PARAM pAcParam =
(PAC_PARAM)();
- AC_CODING eACI;
- u8 u1bAIFS;
- u32 u4bAcParam;
-
- /* Retrieve parameters to update. */
- eACI = pAcParam->f.AciAifsn.f.ACI;
- u1bAIFS = pAcParam->f.AciAifsn.f.AIFSN *
ChnlAccessSetting->SlotTimeTimer + aSifsTime;
- u4bAcParam = u32)(pAcParam->f.TXOPLimit))
<< AC_PARAM_TXOP_LIMIT_OFFSET)|
-
(((u32)(pAcParam->f.Ecw.f.ECWmax)) << AC_PARAM_ECW_MAX_OFFSET) |
-
(((u32)(pAcParam->f.Ecw.f.ECWmin)) << AC_PARAM_ECW_MIN_OFFSET) |
- (((u32)u1bAIFS) <<
AC_PARAM_AIFS_OFFSET));
-
- switch (eACI) {
- case AC1_BK:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- case AC0_BE:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- case AC2_VI:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- case AC3_VO:
- /* write_nic_dword(dev, AC_BK_PARAM,
u4bAcParam); */
- break;
-
- default:
- DMESGW("SetHwReg8185(): invalid ACI: %d
!\n", eACI);
- break;
- }
-
- write_nic_byte(dev, ACM_CONTROL, 0);
- }
+ write_nic_byte(dev, ACM_CONTROL, 0);
}
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] staging/rtl8187se: Remove temporary variable for return value
The simple PlatformIORead1Byte function doesn't need to store its return
value in a temporary variable; rather simply return the value directly.
By moving the function to the top we can also get rid of the forward
declaration.
The wrapper functions could be easily replaced by direct calls to
read_nic_byte but is kept for readability.
Since this functions is local only we can mark it as static.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index a3b836c..1dfa78e 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -115,6 +115,11 @@ static u8 OFDM_CONFIG[]= {
*---
*/
+static u8 PlatformIORead1Byte(struct net_device *dev, u32 offset)
+{
+ return read_nic_byte(dev, offset);
+}
+
void PlatformIOWrite1Byte(struct net_device *dev, u32 offset, u8 data)
{
write_nic_byte(dev, offset, data);
@@ -127,8 +132,6 @@ void PlatformIOWrite2Byte(struct net_device *dev, u32
offset, u16 data)
read_nic_word(dev, offset); /* To make sure write operation is
completed, 2005.11.09, by rcnjko. */
}
-u8 PlatformIORead1Byte(struct net_device *dev, u32 offset);
-
void PlatformIOWrite4Byte(struct net_device *dev, u32 offset, u32 data)
{
if (offset == PhyAddr) {
@@ -172,16 +175,6 @@ void PlatformIOWrite4Byte(struct net_device *dev, u32
offset, u32 data)
}
}
-u8 PlatformIORead1Byte(struct net_device *dev, u32 offset)
-{
- u8 data = 0;
-
- data = read_nic_byte(dev, offset);
-
-
- return data;
-}
-
u16 PlatformIORead2Byte(struct net_device *dev, u32 offset)
{
u16 data = 0;
--
1.7.8.6
--
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 9/9] staging/rtl8187se: Mark functions as static to silence sparse
Sparse complains that some functions can be declared as static:
123:6: warning: symbol 'PlatformIOWrite1Byte' was not declared. Should it be
static?
129:6: warning: symbol 'PlatformIOWrite2Byte' was not declared. Should it be
static?
135:6: warning: symbol 'PlatformIOWrite4Byte' was not declared. Should it be
static?
178:6: warning: symbol 'SetOutputEnableOfRfPins' was not declared. Should it
be static?
354:6: warning: symbol 'ZEBRA_Config_85BASIC_HardCode' was not declared.
Should it be static?
655:6: warning: symbol 'InitTxPwrTracking87SE' was not declared. Should it be
static?
665:6: warning: symbol 'PhyConfig8185' was not declared. Should it be static?
692:6: warning: symbol 'HwConfigureRTL8185' was not declared. Should it be
static?
817:4: warning: symbol 'GetSupportedWirelessMode8185' was not declared. Should
it be static?
822:6: warning: symbol 'ActUpdateChannelAccessSetting' was not declared.
Should it be static?
857:6: warning: symbol 'ActSetWirelessMode8185' was not declared. Should it be
static?
914:6: warning: symbol 'MgntDisconnectIBSS' was not declared. Should it be
static?
940:6: warning: symbol 'MlmeDisassociateRequest' was not declared. Should it
be static?
957:6: warning: symbol 'MgntDisconnectAP' was not declared. Should it be static?
975:6: warning: symbol 'MgntDisconnect' was not declared. Should it be static?
1011:6: warning: symbol 'SetRFPowerState' was not declared. Should it be static?
1115:6: warning: symbol 'InactivePowerSave' was not declared. Should it be
static?
-> Add the static keyword.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 34 +++---
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 2ca857d..978dc5f 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -120,19 +120,19 @@ static u8 PlatformIORead1Byte(struct net_device *dev, u32
offset)
return read_nic_byte(dev, offset);
}
-void PlatformIOWrite1Byte(struct net_device *dev, u32 offset, u8 data)
+static void PlatformIOWrite1Byte(struct net_device *dev, u32 offset, u8 data)
{
write_nic_byte(dev, offset, data);
read_nic_byte(dev, offset); /* To make sure write operation is
completed, 2005.11.09, by rcnjko. */
}
-void PlatformIOWrite2Byte(struct net_device *dev, u32 offset, u16 data)
+static void PlatformIOWrite2Byte(struct net_device *dev, u32 offset, u16 data)
{
write_nic_word(dev, offset, data);
read_nic_word(dev, offset); /* To make sure write operation is
completed, 2005.11.09, by rcnjko. */
}
-void PlatformIOWrite4Byte(struct net_device *dev, u32 offset, u32 data)
+static void PlatformIOWrite4Byte(struct net_device *dev, u32 offset, u32 data)
{
if (offset == PhyAddr) {
/* For Base Band configuration. */
@@ -175,7 +175,7 @@ void PlatformIOWrite4Byte(struct net_device *dev, u32
offset, u32 data)
}
}
-void SetOutputEnableOfRfPins(struct net_device *dev)
+static void SetOutputEnableOfRfPins(struct net_device *dev)
{
write_nic_word(dev, RFPinsEnable, 0x1bff);
}
@@ -327,7 +327,7 @@ bool SetAntennaConfig87SE(struct net_device *dev,
*--
*/
-void ZEBRA_Config_85BASIC_HardCode(struct net_device *dev)
+static void ZEBRA_Config_85BASIC_HardCode(struct net_device *dev)
{
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
@@ -628,7 +628,7 @@ void UpdateInitialGain(struct net_device *dev)
* Tx Power tracking mechanism routine on 87SE.
* Created by Roger, 2007.12.11.
*/
-void InitTxPwrTracking87SE(struct net_device *dev)
+static void InitTxPwrTracking87SE(struct net_device *dev)
{
u32 u4bRfReg;
@@ -638,7 +638,7 @@ void InitTxPwrTracking87SE(struct net_device *dev)
RF_WriteReg(dev, 0x02, u4bRfReg|PWR_METER_EN);
mdelay(1);
}
-void PhyConfig8185(struct net_device *dev)
+static void PhyConfig8185(struct net_device *dev)
{
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
write_nic_dword(dev, RCR, priv->ReceiveConfig);
@@ -665,7 +665,7 @@ void PhyConfig8185(struct net_device *dev)
return;
}
-void HwConfigureRTL8185(struct net_device *dev)
+static void HwConfigureRTL8185(struct net_device *dev)
{
/* RTL8185_TODO: Determine Retrylimit, TxAGC, AutoRateFallback control.
*/
u8 bUNIVERSAL_CONTROL_RL = 0;
@@ -790,12 +790,12 @@ static void MacConfig_85BASIC(struct net_device *dev)
write_nic_byte(dev, 0x24E, 0x01);
}
-u8 GetSupportedWirelessMode8185(struct net_device *dev)
+static u8 GetSupportedWirelessMode8185(struct net_device *dev)
{
return WIRELESS_MODE_B | WIRELESS_MODE_G;
}
-void ActUpdateChannelAccessSetting(struct net_device *dev,
+static void
[PATCH v2 3/6] mfd: Add ChromeOS EC I2C driver
This uses an I2C bus to talk to the ChromeOS EC. The protocol
is defined by the EC and is fairly simple, with a length byte,
checksum, command byte and version byte (to permit easy creation
of new commands).
Signed-off-by: Simon Glass
Signed-off-by: Che-Liang Chiou
---
Changes in v2:
- Remove use of __devinit/__devexit
drivers/mfd/Kconfig | 10 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/cros_ec_i2c.c | 262 ++
3 files changed, 273 insertions(+)
create mode 100644 drivers/mfd/cros_ec_i2c.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 837a16b..e1cd15e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -29,6 +29,16 @@ config MFD_CROS_EC
You also ned to enable the driver for the bus you are using. The
protocol for talking to the EC is defined by the bus driver.
+config MFD_CROS_EC_I2C
+ tristate "ChromeOS Embedded Controller (I2C)"
+ depends on MFD_CROS_EC && I2C
+
+ help
+ If you say here, you get support for talking to the ChromeOS EC
+ through an I2C bus. This uses a simple byte-level protocol with
+ a checksum. Failing accesses will be retried three times to
+ improve reliability.
+
config MFD_88PM800
tristate "Support Marvell 88PM800"
depends on I2C=y && GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 967767d..895257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_SM501)+= sm501.o
obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
+obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
rts5227.o
obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
new file mode 100644
index 000..fe3f2bf
--- /dev/null
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -0,0 +1,262 @@
+/*
+ * ChromeOS EC multi-function device (I2C)
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/* Since I2C can be unreliable, we retry commands */
+#define COMMAND_MAX_TRIES 3
+
+static inline struct cros_ec_device *to_ec_dev(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+
+ return i2c_get_clientdata(client);
+}
+
+static int cros_ec_command_xfer_noretry(struct cros_ec_device *ec_dev,
+ struct cros_ec_msg *msg)
+{
+ struct i2c_client *client = ec_dev->priv;
+ int ret = -ENOMEM;
+ int i;
+ int packet_len;
+ u8 *out_buf = NULL;
+ u8 *in_buf = NULL;
+ u8 sum;
+ struct i2c_msg i2c_msg[2];
+
+ i2c_msg[0].addr = client->addr;
+ i2c_msg[0].flags = 0;
+ i2c_msg[1].addr = client->addr;
+ i2c_msg[1].flags = I2C_M_RD;
+
+ /*
+* allocate larger packet (one byte for checksum, one byte for
+* length, and one for result code)
+*/
+ packet_len = msg->in_len + 3;
+ in_buf = kzalloc(packet_len, GFP_KERNEL);
+ if (!in_buf)
+ goto done;
+ i2c_msg[1].len = packet_len;
+ i2c_msg[1].buf = (char *)in_buf;
+
+ /*
+* allocate larger packet (one byte for checksum, one for
+* command code, one for length, and one for command version)
+*/
+ packet_len = msg->out_len + 4;
+ out_buf = kzalloc(packet_len, GFP_KERNEL);
+ if (!out_buf)
+ goto done;
+ i2c_msg[0].len = packet_len;
+ i2c_msg[0].buf = (char *)out_buf;
+
+ out_buf[0] = EC_CMD_VERSION0 + msg->version;
+ out_buf[1] = msg->cmd;
+ out_buf[2] = msg->out_len;
+
+ /* copy message payload and compute checksum */
+ sum = out_buf[0] + out_buf[1] + out_buf[2];
+ for (i = 0; i < msg->out_len; i++) {
+ out_buf[3 + i] = msg->out_buf[i];
+ sum += out_buf[3 + i];
+ }
+ out_buf[3 + msg->out_len] = sum;
+
+ /* send command to EC and read answer */
+ ret = i2c_transfer(client->adapter, i2c_msg, 2);
+ if (ret < 0) {
+ dev_err(ec_dev->dev, "i2c transfer failed: %d\n", ret);
+ goto done;
+ } else if (ret != 2) {
+ dev_err(ec_dev->dev, "failed to get
[PATCH 5/9] staging/rtl8187se: Reuse ReadBBPortUchar to avoid duplicated code
WriteBBPortUchar reimplements ReadBBPortUchar in its body, so we can
remove the duplicated code by calling ReadBBPortUchar directly.
Unfortunately we have to move ReadBBPortUchar around; while at it we can
also get rid of the temporary variable for the return value.
Also we can remove the local variables UCharData and RegisterContent in
WriteBBPortUchar as they are not used / without effect.
Both functions are only 'local' so we can mark them as static.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 30 +++---
1 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 1e54ead..a3b836c 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -287,35 +287,19 @@ u16 RF_ReadReg(struct net_device *dev, u8 offset)
return reg;
}
+static u8 ReadBBPortUchar(struct net_device *dev, u32 addr)
+{
+ PlatformIOWrite4Byte(dev, PhyAddr, addr & 0xff7f);
+ return PlatformIORead1Byte(dev, PhyDataR);
+}
/* by Owen on 04/07/14 for writing BB register successfully */
-void WriteBBPortUchar(struct net_device *dev, u32 Data)
+static void WriteBBPortUchar(struct net_device *dev, u32 Data)
{
- /* u8 TimeoutCounter; */
- u8 RegisterContent;
- u8 UCharData;
-
- UCharData = (u8)((Data & 0xff00) >> 8);
PlatformIOWrite4Byte(dev, PhyAddr, Data);
- /* for(TimeoutCounter = 10; TimeoutCounter > 0; TimeoutCounter--) */
- {
- PlatformIOWrite4Byte(dev, PhyAddr, Data & 0xff7f);
- RegisterContent = PlatformIORead1Byte(dev, PhyDataR);
- /*if(UCharData == RegisterContent) */
- /* break; */
- }
+ ReadBBPortUchar(dev, Data);
}
-u8 ReadBBPortUchar(struct net_device *dev, u32 addr)
-{
- /*u8TimeoutCounter; */
- u8 RegisterContent;
-
- PlatformIOWrite4Byte(dev, PhyAddr, addr & 0xff7f);
- RegisterContent = PlatformIORead1Byte(dev, PhyDataR);
-
- return RegisterContent;
-}
/*
* Description:
* Perform Antenna settings with antenna diversity on 87SE.
--
1.7.8.6
--
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 7/9] staging/rtl8187se: Remove unused functions PlatformIORead2Byte / PlatformIORead4Byte
These two functions PlatformIORead2Byte and PlatformIORead4Byte are
unused and thus can be removed.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 20
1 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 1dfa78e..005fb0b 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -175,26 +175,6 @@ void PlatformIOWrite4Byte(struct net_device *dev, u32
offset, u32 data)
}
}
-u16 PlatformIORead2Byte(struct net_device *dev, u32 offset)
-{
- u16 data = 0;
-
- data = read_nic_word(dev, offset);
-
-
- return data;
-}
-
-u32 PlatformIORead4Byte(struct net_device *dev, u32 offset)
-{
- u32 data = 0;
-
- data = read_nic_dword(dev, offset);
-
-
- return data;
-}
-
void SetOutputEnableOfRfPins(struct net_device *dev)
{
write_nic_word(dev, RFPinsEnable, 0x1bff);
--
1.7.8.6
--
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/9] staging/rtl8187se: Remove code without effect
Local variable AcmCtrl is never read/used after assignment so we can remove
all assignments to it and the related code around the assignments.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 49 +--
1 files changed, 1 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index f1db9e4..41419f0 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -964,54 +964,7 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
break;
}
- /* Cehck ACM bit. */
- /* If it is set, immediately set ACM control
bit to downgrading AC for passing WMM testplan. Annie, 2005-12-13. */
- {
- PACI_AIFSN pAciAifsn =
(PACI_AIFSN)(>f.AciAifsn);
- AC_CODING eACI = pAciAifsn->f.ACI;
-
- /*for 8187B AsynIORead issue */
- u8 AcmCtrl = 0;
- if (pAciAifsn->f.ACM) {
- /* ACM bit is 1. */
- switch (eACI) {
- case AC0_BE:
- AcmCtrl |=
(BEQ_ACM_EN|BEQ_ACM_CTL|ACM_HW_EN); /* or 0x21 */
- break;
-
- case AC2_VI:
- AcmCtrl |=
(VIQ_ACM_EN|VIQ_ACM_CTL|ACM_HW_EN); /* or 0x42 */
- break;
-
- case AC3_VO:
- AcmCtrl |=
(VOQ_ACM_EN|VOQ_ACM_CTL|ACM_HW_EN); /* or 0x84 */
- break;
-
- default:
- DMESGW("SetHwReg8185():
[HW_VAR_ACM_CTRL] ACM set failed: eACI is %d\n", eACI);
- break;
- }
- } else {
- /* ACM bit is 0. */
- switch (eACI) {
- case AC0_BE:
- AcmCtrl &=
((~BEQ_ACM_EN) & (~BEQ_ACM_CTL) & (~ACM_HW_EN)); /* and 0xDE */
- break;
-
- case AC2_VI:
- AcmCtrl &=
((~VIQ_ACM_EN) & (~VIQ_ACM_CTL) & (~ACM_HW_EN)); /* and 0xBD */
- break;
-
- case AC3_VO:
- AcmCtrl &=
((~VOQ_ACM_EN) & (~VOQ_ACM_CTL) & (~ACM_HW_EN)); /* and 0x7B */
- break;
-
- default:
- break;
- }
- }
- write_nic_byte(dev, ACM_CONTROL, 0);
- }
+ write_nic_byte(dev, ACM_CONTROL, 0);
}
}
}
--
1.7.8.6
--
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 8/9] staging/rtl8187se: Remove duplicated code by using an offset
In SetAntennaConfig87SE both branches of if (bAntDiversity) do exactly
the same, except that there is an offset of 0x80 for the register values
if bAntDiversity is true.
-> Consolidate both branches and assign the offset if necessary.
Signed-off-by: Peter Huewe
---
drivers/staging/rtl8187se/r8185b_init.c | 76 +++
1 files changed, 26 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8185b_init.c
b/drivers/staging/rtl8187se/r8185b_init.c
index 005fb0b..2ca857d 100644
--- a/drivers/staging/rtl8187se/r8185b_init.c
+++ b/drivers/staging/rtl8187se/r8185b_init.c
@@ -284,62 +284,38 @@ bool SetAntennaConfig87SE(struct net_device *dev,
{
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
bool bAntennaSwitched = true;
+ u8 ant_diversity_offset = 0x00; /* 0x00 = disabled, 0x80 = enabled
*/
/* printk("SetAntennaConfig87SE(): DefaultAnt(%d),
bAntDiversity(%d)\n", DefaultAnt, bAntDiversity); */
/* Threshold for antenna diversity. */
write_phy_cck(dev, 0x0c, 0x09); /* Reg0c : 09 */
- if (bAntDiversity) {/* Enable Antenna Diversity. */
- if (DefaultAnt == 1) { /* aux antenna */
-
- /* Mac register, aux antenna */
- write_nic_byte(dev, ANTSEL, 0x00);
-
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0xbb); /* Reg11 : bb */
- write_phy_cck(dev, 0x01, 0xc7); /* Reg01 : c7 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0D, 0x54);/* Reg0d : 54 */
- write_phy_ofdm(dev, 0x18, 0xb2);/* Reg18 : b2 */
- } else { /* use main antenna */
- /* Mac register, main antenna */
- write_nic_byte(dev, ANTSEL, 0x03);
- /* base band */
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0x9b); /* Reg11 : 9b */
- write_phy_cck(dev, 0x01, 0xc7); /* Reg01 : c7 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0d, 0x5c); /* Reg0d : 5c */
- write_phy_ofdm(dev, 0x18, 0xb2); /* Reg18 : b2 */
- }
- } else {
- /* Disable Antenna Diversity. */
- if (DefaultAnt == 1) { /* aux Antenna */
- /* Mac register, aux antenna */
- write_nic_byte(dev, ANTSEL, 0x00);
-
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0xbb); /* Reg11 : bb */
- write_phy_cck(dev, 0x01, 0x47); /* Reg01 : 47 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0D, 0x54);/* Reg0d : 54 */
- write_phy_ofdm(dev, 0x18, 0x32);/* Reg18 : 32 */
- } else { /* main Antenna */
- /* Mac register, main antenna */
- write_nic_byte(dev, ANTSEL, 0x03);
-
- /* Config CCK RX antenna. */
- write_phy_cck(dev, 0x11, 0x9b); /* Reg11 : 9b */
- write_phy_cck(dev, 0x01, 0x47); /* Reg01 : 47 */
-
- /* Config OFDM RX antenna. */
- write_phy_ofdm(dev, 0x0D, 0x5c); /* Reg0d : 5c */
- write_phy_ofdm(dev, 0x18, 0x32); /*Reg18 : 32 */
- }
+ if (bAntDiversity) /* Enable Antenna Diversity. */
+ ant_diversity_offset = 0x80;
+
+ if (DefaultAnt == 1) { /* aux Antenna */
+ /* Mac register, aux antenna */
+ write_nic_byte(dev, ANTSEL, 0x00);
+
+ /* Config CCK RX antenna. */
+ write_phy_cck(dev, 0x11, 0xbb); /* Reg11 : bb */
+ write_phy_cck(dev, 0x01, 0x47|ant_diversity_offset); /* Reg01 :
47 | ant_diversity_offset */
+
+ /* Config OFDM RX antenna. */
+ write_phy_ofdm(dev, 0x0D, 0x54);/* Reg0d : 54 */
+ write_phy_ofdm(dev, 0x18, 0x32|ant_diversity_offset); /*
Reg18 : 32 */
+ } else { /* main Antenna */
+ /* Mac register, main antenna */
+ write_nic_byte(dev, ANTSEL, 0x03);
+
+ /* Config CCK RX antenna. */
+ write_phy_cck(dev, 0x11, 0x9b); /* Reg11 : 9b */
+ write_phy_cck(dev, 0x01, 0x47|ant_diversity_offset); /* Reg01 :
47 */
+
+ /* Config OFDM RX antenna. */
+ write_phy_ofdm(dev, 0x0D, 0x5c); /* Reg0d : 5c */
+ write_phy_ofdm(dev, 0x18, 0x32|ant_diversity_offset); /*Reg18 :
32 */
}
priv->CurrAntennaIndex = DefaultAnt; /* Update default settings. */
return
Re: iio: adc: add exynos5 adc driver under iio framwork
On 13 February 2013 02:37, Guenter Roeck wrote:
> On Wed, Jan 23, 2013 at 04:58:06AM -, Naveen Krishna Chatradhi wrote:
>> This patch add an ADC IP found on EXYNOS5 series socs from Samsung.
>> Also adds the Documentation for device tree bindings.
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>>
>> ---
>> Changes since v1:
>>
>> 1. Fixed comments from Lars
>> 2. Added support for ADC on EXYNOS5410
>>
>> Changes since v2:
>>
>> 1. Changed the instance name for (struct iio_dev *) to indio_dev
>> 2. Changed devm_request_irq to request_irq
>>
>> Few doubts regarding the mappings and child device handling.
>> Kindly, suggest me better methods.
>>
>> .../bindings/arm/samsung/exynos5-adc.txt | 37 ++
>> drivers/iio/adc/Kconfig|7 +
>> drivers/iio/adc/Makefile |1 +
>> drivers/iio/adc/exynos5_adc.c | 464
>>
>> 4 files changed, 509 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> create mode 100644 drivers/iio/adc/exynos5_adc.c
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> new file mode 100644
>> index 000..9a5b515
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> @@ -0,0 +1,37 @@
>> +Samsung Exynos5 Analog to Digital Converter bindings
>> +
>> +Required properties:
>> +- compatible:Must be "samsung,exynos5250-adc" for
>> exynos5250 controllers.
>> +- reg: Contains ADC register address range (base
>> address and
>> + length).
>> +- interrupts:Contains the interrupt information for the
>> timer. The
>> + format is being dependent on which interrupt controller
>> + the Samsung device uses.
>> +
>> +Note: child nodes can be added for auto probing from device tree.
>> +
>> +Example: adding device info in dtsi file
>> +
>> +adc@12D1 {
>> + compatible = "samsung,exynos5250-adc";
>> + reg = <0x12D1 0x100>;
>> + interrupts = <0 106 0>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +};
>> +
>> +
>> +Example: Adding child nodes in dts file
>> +
>> +adc@12D1 {
>> +
>> + /* NTC thermistor is a hwmon device */
>> + ncp15wb473@0 {
>> + compatible = "ntc,ncp15wb473";
>> + reg = <0x0>;
>> + pullup-uV = <180>;
>> + pullup-ohm = <47000>;
>> + pulldown-ohm = <0>;
>> + };
>> +};
>
> How about:
>
> adc: adc@12D1 {
> compatible = "samsung,exynos5250-adc";
> reg = <0x12D1 0x100>;
> interrupts = <0 106 0>;
> #io-channel-cells = <1>;
> };
>
> ...
>
> ncp15wb473@0 {
> compatible = "ntc,ncp15wb473";
> reg = <0x0>; /* is this needed ? */
> io-channels = < 0>;
> io-channel-names = "adc";
> pullup-uV = <180>; /* uV or uv ? */
> pullup-ohm = <47000>;
> pulldown-ohm = <0>;
> };
>
> The ncp15wb473 driver would then use either iio_channel_get_all() to get the
> iio
> channel list or, if it only supports one adc channel per instance,
> iio_channel_get().
>
> In that context, it would probably make sense to rework the ntc_thermistor
> driver to support both DT as well as direct instantiation using access
> functions
> and platform data (as it does today).
>
> Also see https://patchwork.kernel.org/patch/2112171/.
>
> Thanks,
> Guenter
Yes Guenter, I will rebase and submit the ADC driver based on your patch set.
>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index fe822a1..33ceabf 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -91,6 +91,13 @@ config AT91_ADC
>> help
>> Say yes here to build support for Atmel AT91 ADC.
>>
>> +config EXYNOS5_ADC
>> + bool "Exynos5 ADC driver support"
>> + help
>> + Core support for the ADC block found in the Samsung EXYNOS5 series
>> + of SoCs for drivers such as the touchscreen and hwmon to use to share
>> + this resource.
>> +
>> config LP8788_ADC
>> bool "LP8788 ADC driver"
>> depends on MFD_LP8788
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 2d5f100..5b4a4f6 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_AD7791) += ad7791.o
>> obj-$(CONFIG_AD7793) += ad7793.o
>> obj-$(CONFIG_AD7887) += ad7887.o
>> obj-$(CONFIG_AT91_ADC) += at91_adc.o
>> +obj-$(CONFIG_EXYNOS5_ADC) += exynos5_adc.o
>> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>> obj-$(CONFIG_MAX1363) += max1363.o
>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>
[PATCH v2 1/6] mfd: Add ChromeOS EC messages header
This file is included verbatim from the ChromeOS EC respository. Ideally we would prefer to avoid changing it, to make it easier to track this rapidly-changing file. Signed-off-by: Simon Glass Signed-off-by: Che-Liang Chiou Signed-off-by: Vincent Palatin --- Changes in v2: None include/linux/mfd/cros_ec_commands.h | 1369 ++ 1 file changed, 1369 insertions(+) create mode 100644 include/linux/mfd/cros_ec_commands.h diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h new file mode 100644 index 000..86fd069 --- /dev/null +++ b/include/linux/mfd/cros_ec_commands.h @@ -0,0 +1,1369 @@ +/* + * Host communication command constants for ChromeOS EC + * + * Copyright (C) 2012 Google, Inc + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * The ChromeOS EC multi function device is used to mux all the requests + * to the EC device for its multiple features: keyboard controller, + * battery charging and regulator control, firmware update. + * + * NOTE: This file is copied verbatim from the ChromeOS EC Open Source + * project in an attempt to make future updates easy to make. + */ + +#ifndef __CROS_EC_COMMANDS_H +#define __CROS_EC_COMMANDS_H + +/* + * Protocol overview + * + * request: CMD [ P0 P1 P2 ... Pn S ] + * response: ERR [ P0 P1 P2 ... Pn S ] + * + * where the bytes are defined as follow : + * - CMD is the command code. (defined by EC_CMD_ constants) + * - ERR is the error code. (defined by EC_RES_ constants) + * - Px is the optional payload. + *it is not sent if the error code is not success. + *(defined by ec_params_ and ec_response_ structures) + * - S is the checksum which is the sum of all payload bytes. + * + * On LPC, CMD and ERR are sent/received at EC_LPC_ADDR_KERNEL|USER_CMD + * and the payloads are sent/received at EC_LPC_ADDR_KERNEL|USER_PARAM. + * On I2C, all bytes are sent serially in the same message. + */ + +/* Current version of this protocol */ +#define EC_PROTO_VERSION 0x0002 + +/* Command version mask */ +#define EC_VER_MASK(version) (1UL << (version)) + +/* I/O addresses for ACPI commands */ +#define EC_LPC_ADDR_ACPI_DATA 0x62 +#define EC_LPC_ADDR_ACPI_CMD 0x66 + +/* I/O addresses for host command */ +#define EC_LPC_ADDR_HOST_DATA 0x200 +#define EC_LPC_ADDR_HOST_CMD 0x204 + +/* I/O addresses for host command args and params */ +#define EC_LPC_ADDR_HOST_ARGS 0x800 +#define EC_LPC_ADDR_HOST_PARAM 0x804 +#define EC_HOST_PARAM_SIZE 0x0fc /* Size of param area in bytes */ + +/* I/O addresses for host command params, old interface */ +#define EC_LPC_ADDR_OLD_PARAM 0x880 +#define EC_OLD_PARAM_SIZE 0x080 /* Size of param area in bytes */ + +/* EC command register bit functions */ +#define EC_LPC_CMDR_DATA (1 << 0) /* Data ready for host to read */ +#define EC_LPC_CMDR_PENDING(1 << 1) /* Write pending to EC */ +#define EC_LPC_CMDR_BUSY (1 << 2) /* EC is busy processing a command */ +#define EC_LPC_CMDR_CMD(1 << 3) /* Last host write was a command */ +#define EC_LPC_CMDR_ACPI_BRST (1 << 4) /* Burst mode (not used) */ +#define EC_LPC_CMDR_SCI(1 << 5) /* SCI event is pending */ +#define EC_LPC_CMDR_SMI(1 << 6) /* SMI event is pending */ + +#define EC_LPC_ADDR_MEMMAP 0x900 +#define EC_MEMMAP_SIZE 255 /* ACPI IO buffer max is 255 bytes */ +#define EC_MEMMAP_TEXT_MAX 8 /* Size of a string in the memory map */ + +/* The offset address of each type of data in mapped memory. */ +#define EC_MEMMAP_TEMP_SENSOR 0x00 /* Temp sensors */ +#define EC_MEMMAP_FAN 0x10 /* Fan speeds */ +#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* Temp sensors (second set) */ +#define EC_MEMMAP_ID 0x20 /* 'E' 'C' */ +#define EC_MEMMAP_ID_VERSION 0x22 /* Version of data in 0x20 - 0x2f */ +#define EC_MEMMAP_THERMAL_VERSION 0x23 /* Version of data in 0x00 - 0x1f */ +#define EC_MEMMAP_BATTERY_VERSION 0x24 /* Version of data in 0x40 - 0x7f */ +#define EC_MEMMAP_SWITCHES_VERSION 0x25 /* Version of data in 0x30 - 0x33 */ +#define EC_MEMMAP_EVENTS_VERSION 0x26 /* Version of data in 0x34 - 0x3f */ +#define EC_MEMMAP_HOST_CMD_FLAGS 0x27 /* Host command interface flags */ +#define EC_MEMMAP_SWITCHES 0x30 +#define EC_MEMMAP_HOST_EVENTS 0x34 +#define EC_MEMMAP_BATT_VOLT0x40 /* Battery Present Voltage */ +#define EC_MEMMAP_BATT_RATE0x44 /* Battery Present Rate */ +#define EC_MEMMAP_BATT_CAP 0x48 /* Battery Remaining
[PATCH v2 5/6] Input: matrix-keymap: Add function to read the new DT binding
We now have a binding which adds two parameters to the matrix keypad DT
node. This is separate from the GPIO-driven matrix keypad binding, and
unfortunately incompatible, since that uses row-gpios/col-gpios for the
row and column counts.
So the easiest option here is to provide a function for non-GPIO drivers
to use to decode the binding.
Note: We could in fact create an entirely separate structure to hold
these two fields, but it does not seem worth it, yet. If we have more
parameters then we can add this, and then refactor each driver to hold
such a structure.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to decode matrix-keypad DT binding
drivers/input/keyboard/lpc32xx-keys.c | 11 ++-
drivers/input/keyboard/omap4-keypad.c | 16 +---
drivers/input/keyboard/tca8418_keypad.c | 11 +++
drivers/input/matrix-keymap.c | 20
include/linux/input/matrix_keypad.h | 11 +++
5 files changed, 49 insertions(+), 20 deletions(-)
diff --git a/drivers/input/keyboard/lpc32xx-keys.c
b/drivers/input/keyboard/lpc32xx-keys.c
index 1b8add6..4218143 100644
--- a/drivers/input/keyboard/lpc32xx-keys.c
+++ b/drivers/input/keyboard/lpc32xx-keys.c
@@ -144,12 +144,13 @@ static int lpc32xx_parse_dt(struct device *dev,
{
struct device_node *np = dev->of_node;
u32 rows = 0, columns = 0;
+ int err;
- of_property_read_u32(np, "keypad,num-rows", );
- of_property_read_u32(np, "keypad,num-columns", );
- if (!rows || rows != columns) {
- dev_err(dev,
- "rows and columns must be specified and be equal!\n");
+ err = matrix_keypad_parse_of_params(dev, , );
+ if (err)
+ return err;
+ if (rows != columns) {
+ dev_err(dev, "rows and columns must be equal!\n");
return -EINVAL;
}
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e25b022..1b28909 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -215,18 +215,12 @@ static int omap4_keypad_parse_dt(struct device *dev,
struct omap4_keypad *keypad_data)
{
struct device_node *np = dev->of_node;
+ int err;
- if (!np) {
- dev_err(dev, "missing DT data");
- return -EINVAL;
- }
-
- of_property_read_u32(np, "keypad,num-rows", _data->rows);
- of_property_read_u32(np, "keypad,num-columns", _data->cols);
- if (!keypad_data->rows || !keypad_data->cols) {
- dev_err(dev, "number of keypad rows/columns not specified\n");
- return -EINVAL;
- }
+ err = matrix_keypad_parse_of_params(dev, _data->rows,
+ _data->cols);
+ if (err)
+ return err;
if (of_get_property(np, "linux,input-no-autorepeat", NULL))
keypad_data->no_autorepeat = true;
diff --git a/drivers/input/keyboard/tca8418_keypad.c
b/drivers/input/keyboard/tca8418_keypad.c
index a34cc67..4d5a6d5 100644
--- a/drivers/input/keyboard/tca8418_keypad.c
+++ b/drivers/input/keyboard/tca8418_keypad.c
@@ -288,17 +288,20 @@ static int tca8418_keypad_probe(struct i2c_client *client,
irq_is_gpio = pdata->irq_is_gpio;
} else {
struct device_node *np = dev->of_node;
- of_property_read_u32(np, "keypad,num-rows", );
- of_property_read_u32(np, "keypad,num-columns", );
+ int err;
+
+ err = matrix_keypad_parse_of_params(dev, , );
+ if (err)
+ return err;
rep = of_property_read_bool(np, "keypad,autorepeat");
}
- if (!rows || rows > TCA8418_MAX_ROWS) {
+ if (rows > TCA8418_MAX_ROWS) {
dev_err(dev, "invalid rows\n");
return -EINVAL;
}
- if (!cols || cols > TCA8418_MAX_COLS) {
+ if (cols > TCA8418_MAX_COLS) {
dev_err(dev, "invalid columns\n");
return -EINVAL;
}
diff --git a/drivers/input/matrix-keymap.c b/drivers/input/matrix-keymap.c
index 3ae496e..64bad81 100644
--- a/drivers/input/matrix-keymap.c
+++ b/drivers/input/matrix-keymap.c
@@ -50,6 +50,25 @@ static bool matrix_keypad_map_key(struct input_dev
*input_dev,
}
#ifdef CONFIG_OF
+int matrix_keypad_parse_of_params(struct device *dev,
+ unsigned int *rows, unsigned int *cols)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ dev_err(dev, "missing DT data");
+ return -EINVAL;
+ }
+ of_property_read_u32(np, "keypad,num-rows", rows);
+ of_property_read_u32(np, "keypad,num-columns", cols);
+ if (!*rows || !*cols) {
+ dev_err(dev, "number of keypad rows/columns not specified\n");
+
[PATCH v2 0/6] Add ChromeOS Embedded Controller support
The ChromeOS Embedded Controller (EC) is an Open Source EC implementation used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt line is used to indicate when the EC needs service. Functions performed by the EC vary by platform, but typically include battery charging, keyboard scanning and power sequencing. This series includes support for the EC message protocol, and implements a matrix keyboard handler for Linux using the protocol. The EC performs key scanning and passes scan data in response to AP requests. This is used on the Samsung ARM Chromebook. No driver is available for LPC at present. This series can in principle operate on any hardware, but for it to actually work on the Samsung ARM Chromebook, it needs patches which are currently in progress to mainline: Exynos FDT interrupt support and I2C bus arbitration. The driver is device-tree-enabled and a suitable binding is included in this series. Example device tree nodes are included in the examples, but no device tree patch for exynos5250-snow is provided at this stage, since we must wait for the above-mentioned patches to land to avoid errors from dtc. This can be added with a follow-on patch when that work is complete. Changes in v2: - Remove use of __devinit/__devexit - Remove use of __devinit/__devexit - Remove use of __devinit/__devexit - Add new patch to decode matrix-keypad DT binding - Remove use of __devinit/__devexit - Use function to read matrix-keypad parameters from DT - Remove key autorepeat parameters from DT binding and driver - Use unsigned int for rows/cols Simon Glass (6): mfd: Add ChromeOS EC messages header mfd: Add ChromeOS EC implementation mfd: Add ChromeOS EC I2C driver mfd: Add ChromeOS EC SPI driver Input: matrix-keymap: Add function to read the new DT binding Input: Add ChromeOS EC keyboard driver .../devicetree/bindings/input/cros-ec-keyb.txt | 72 + Documentation/devicetree/bindings/mfd/cros-ec.txt | 56 + drivers/input/keyboard/Kconfig | 12 + drivers/input/keyboard/Makefile|1 + drivers/input/keyboard/cros_ec_keyb.c | 394 ++ drivers/input/keyboard/lpc32xx-keys.c | 11 +- drivers/input/keyboard/omap4-keypad.c | 16 +- drivers/input/keyboard/tca8418_keypad.c| 11 +- drivers/input/matrix-keymap.c | 20 + drivers/mfd/Kconfig| 28 + drivers/mfd/Makefile |3 + drivers/mfd/cros_ec.c | 219 drivers/mfd/cros_ec_i2c.c | 262 drivers/mfd/cros_ec_spi.c | 412 ++ include/linux/input/matrix_keypad.h| 11 + include/linux/mfd/cros_ec.h| 190 +++ include/linux/mfd/cros_ec_commands.h | 1369 17 files changed, 3067 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt create mode 100644 drivers/input/keyboard/cros_ec_keyb.c create mode 100644 drivers/mfd/cros_ec.c create mode 100644 drivers/mfd/cros_ec_i2c.c create mode 100644 drivers/mfd/cros_ec_spi.c create mode 100644 include/linux/mfd/cros_ec.h create mode 100644 include/linux/mfd/cros_ec_commands.h -- 1.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] mfd: Add ChromeOS EC SPI driver
This uses a SPI bus to talk to the ChromeOS EC. The protocol
is defined by the EC and is fairly simple, with a length byte,
checksum, command byte and version byte (to permit easy creation
of new commands).
Signed-off-by: Simon Glass
---
Changes in v2:
- Remove use of __devinit/__devexit
drivers/mfd/Kconfig | 10 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/cros_ec_spi.c | 412 ++
3 files changed, 423 insertions(+)
create mode 100644 drivers/mfd/cros_ec_spi.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e1cd15e..e30b801 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -39,6 +39,16 @@ config MFD_CROS_EC_I2C
a checksum. Failing accesses will be retried three times to
improve reliability.
+config MFD_CROS_EC_SPI
+ tristate "ChromeOS Embedded Controller (SPI)"
+ depends on MFD_CROS_EC && SPI
+
+ ---help---
+ If you say Y here, you get support for talking to the ChromeOS EC
+ through a SPI bus, using a byte-level protocol. Since the EC's
+ response time cannot be guaranteed, we support ignoring
+ 'pre-amble' bytes before the response actually starts.
+
config MFD_88PM800
tristate "Support Marvell 88PM800"
depends on I2C=y && GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 895257b..f62a583 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_SM501) += sm501.o
obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
+obj-$(CONFIG_MFD_CROS_EC_SPI) += cros_ec_spi.o
rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
rts5227.o
obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
new file mode 100644
index 000..3a97653
--- /dev/null
+++ b/drivers/mfd/cros_ec_spi.c
@@ -0,0 +1,412 @@
+/*
+ * ChromeOS EC multi-function device (SPI)
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/* The header byte, which follows the preamble */
+#define EC_MSG_HEADER 0xec
+
+/*
+ * Number of EC preamble bytes we read at a time. Since it takes
+ * about 400-500us for the EC to respond there is not a lot of
+ * point in tuning this. If the EC could respond faster then
+ * we could increase this so that might expect the preamble and
+ * message to occur in a single transaction. However, the maximum
+ * SPI transfer size is 256 bytes, so at 5MHz we need a response
+ * time of perhaps <320us (200 bytes / 1600 bits).
+ */
+#define EC_MSG_PREAMBLE_COUNT 32
+
+/*
+ * We must get a response from the EC in 5ms. This is a very long
+ * time, but the flash write command can take 2-3ms. The EC command
+ * processing is currently not very fast (about 500us). We could
+ * look at speeding this up and making the flash write command a
+ * 'slow' command, requiring a GET_STATUS wait loop, like flash
+ * erase.
+ */
+#define EC_MSG_DEADLINE_MS 5
+
+/*
+ * Time between raising the SPI chip select (for the end of a
+ * transaction) and dropping it again (for the next transaction).
+ * If we go too fast, the EC will miss the transaction. It seems
+ * that 50us is enough with the 16MHz STM32 EC.
+ */
+#define EC_SPI_RECOVERY_TIME_NS(50 * 1000)
+
+/**
+ * struct cros_ec_spi - information about a SPI-connected EC
+ *
+ * @spi: SPI device we are connected to
+ * @last_transfer_ns: time that we last finished a transfer, or 0 if there
+ * if no record
+ */
+struct cros_ec_spi {
+ struct spi_device *spi;
+ s64 last_transfer_ns;
+};
+
+static void debug_packet(struct device *dev, const char *name, u8 *ptr,
+ int len)
+{
+#ifdef DEBUG
+ int i;
+
+ dev_dbg(dev, "%s: ", name);
+ for (i = 0; i < len; i++)
+ dev_cont(dev, " %02x", ptr[i]);
+#endif
+}
+
+/**
+ * cros_ec_spi_receive_response - Receive a response from the EC.
+ *
+ * This function has two phases: reading the preamble bytes (since if we read
+ * data from the EC before it is ready to send, we just get preamble) and
+ * reading the actual message.
+ *
+ * The received data is placed into ec_dev->din.
+ *
+ * @ec_dev: ChromeOS EC device
+ * @need_len: Number of message bytes we need
[PATCH v2 6/6] Input: Add ChromeOS EC keyboard driver
Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.
Additional FDT bindings are provided to specify rows/columns and the
auto-repeat information.
Signed-off-by: Simon Glass
Signed-off-by: Luigi Semenzato
Signed-off-by: Vincent Palatin
---
Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols
.../devicetree/bindings/input/cros-ec-keyb.txt | 72
drivers/input/keyboard/Kconfig | 12 +
drivers/input/keyboard/Makefile| 1 +
drivers/input/keyboard/cros_ec_keyb.c | 394 +
4 files changed, 479 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: "google,cros-ec-keyb"
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
+ /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACEL_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x021d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x0461 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFTP O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT*/
+ 0x070b0067 0x070c0069>;
+};
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 078305e..3a70be7 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -628,4 +628,16 @@ config KEYBOARD_W90P910
To compile this driver as a module, choose M here: the
module will be called w90p910_keypad.
+config
[PATCH v2 2/6] mfd: Add ChromeOS EC implementation
This is the base EC implementation, which provides a high level
interface to the EC for use by the rest of the kernel. The actual
communcations is dealt with by a separate protocol driver which
registers itself with this interface.
Interrupts are passed on through a notifier. The driver supports
resume notification also, in case drivers wish to perform some
action there.
A simple message structure is used to pass messages to the
protocol driver.
Signed-off-by: Simon Glass
Signed-off-by: Che-Liang Chiou
Signed-off-by: Jonathan Kliegman
Signed-off-by: Luigi Semenzato
Signed-off-by: Olof Johansson
Signed-off-by: Vincent Palatin
---
Changes in v2:
- Remove use of __devinit/__devexit
Documentation/devicetree/bindings/mfd/cros-ec.txt | 56 ++
drivers/mfd/Kconfig | 8 +
drivers/mfd/Makefile | 1 +
drivers/mfd/cros_ec.c | 219 ++
include/linux/mfd/cros_ec.h | 190 +++
5 files changed, 474 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
create mode 100644 drivers/mfd/cros_ec.c
create mode 100644 include/linux/mfd/cros_ec.h
diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: "google,cros-ec-i2c"
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: "google,cros-ec-spi"
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: "google,cros-ec-lpc"
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA {
+ cros-ec@1e {
+ reg = <0x1e>;
+ compatible = "google,cros-ec-i2c";
+ interrupts = <14 0>;
+ interrupt-parent = <_eint>;
+ wakeup-source;
+ };
+
+
+Example for SPI:
+
+spi@131b {
+ ec@0 {
+ compatible = "google,cros-ec-spi";
+ reg = <0x0>;
+ interrupts = <14 0>;
+ interrupt-parent = <_eint>;
+ wakeup-source;
+ spi-max-frequency = <500>;
+ controller-data {
+ cs-gpio = < 3 4 3 0>;
+ samsung,spi-cs;
+ samsung,spi-feedback-delay = <2>;
+ };
+ };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 671f5b1..837a16b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -21,6 +21,14 @@ config MFD_88PM860X
select individual components like voltage regulators, RTC and
battery-charger under the corresponding menus.
+config MFD_CROS_EC
+ bool "Support ChromeOS Embedded Controller"
+ help
+ If you say yes here you get support for the ChromeOS Embedded
+ Controller (EC) providing keyboard, battery and power services.
+ You also ned to enable the driver for the bus you are using. The
+ protocol for talking to the EC is defined by the bus driver.
+
config MFD_88PM800
tristate "Support Marvell 88PM800"
depends on I2C=y && GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..967767d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_SM501)+= sm501.o
obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
rts5227.o
obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
new file mode 100644
index 000..fc7fce3
--- /dev/null
+++ b/drivers/mfd/cros_ec.c
@@ -0,0 +1,219 @@
+/*
+ * ChromeOS EC multi-function device
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but
Re: [PATCH] ACPI, PCI: Get PRT entry during acpi_pci_enable_irq()
On Tue, Feb 12, 2013 at 6:20 PM, Peter Hurley wrote: > On Tue, 2013-02-12 at 11:11 -0800, Yinghai Lu wrote: >> Peter Hurley found "irq 18 nobody cared" with pci-next, and dmesg has >> >> [8.983246] pci :00:1e.0: can't derive routing for PCI INT A >> [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 >> >> bisect to >> | commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 >> | PCI: Put pci_dev in device tree as early as possible >> >> It turns out we need to call acpi_pci_irq_add_prt() after the pci bridges >> are scanned. >> >> Bjorn said: >> The bus number binding means acpi_pci_irq_add_prt() has to happen >> after enumerating everything below a bridge, and it will prevent us >> from doing any bus number reassignment for hotplug. >> >> I think we should remove the bus numbers from the cached _PRT (or >> maybe even remove the _PRT caching completely). When we enable a PCI >> device's IRQ, we should search up the PCI device tree looking for a >> _PRT associated with each node, and applying normal PCI bridge >> swizzling when we don't find a _PRT. I think this can be done without >> using PCI bus numbers at all. >> >> So here we try to remove _PRT caching completely. >> >> -v2: check !handle early. >> >> Reported-and-tested-by: Peter Hurley > > Actually true now :) > > Reported-and-tested-by: Peter Hurley Thanks. > PS - I just happened to see this version on the list. Would you please > cc me on any future versions? oh, my fault. I take it for granted that "git send-email" will pick that email from patch just like Cc. Yinghai -- 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 00/26] x86, irq: support ioapic device hotplug
On Mon, Feb 11, 2013 at 10:10 PM, H. Peter Anvin wrote: > On 02/11/2013 01:34 AM, Ingo Molnar wrote: >> >> * Yinghai Lu wrote: >> >>> Hi, >>> >>> Current x86 code does not support iapic hotplug yet. >> >> Please give a better high-level description: outline how an >> IO-APIC will be hotplugged physically and what changes the >> user will experience. Intel cpu (from IVB) include cpu, mem controller, and IIO. When hotadd cpu physically, it will involve cpu hotplug, mem hotplug, and pci root hotplug. IIO includes pci host bridge, ioapic controller and iommu. pci devices will need to use ioapic and iommu. So to make pci hotplug working, we need to add ioapic hotplug support. >> >> That needs at least 2 paragraphs, not one cursory sentence. Then >> should come technical descriptions - but even those need >> improvements, please first explain the current status quo, then >> explain how that is inadequate for IO-APIC hot-plugging, *then* >> only explain what you are doing in the patch ... Now ioapics are with ACPI MADT table. During booting, kernel will parse MADT and put info into ioapic arrays. Also Bjorn added one pci device based driver, but it is not wired in yet, as it need to call acpi_register_ioapic, and that is TBD. This patchset will 1. extend genirq to support reserve/realloc method. because we want to irqs for one ioapic controller to be linear mapping to the gsi range. 2. change ioapic array operation code so we could insert new ioapic and remove one leave the blank slot. 3. record irq_base in gsi_config in ioapic struct, and use it to convert gsi to irq for pci device using that ioapic controller 4. make static ioapic path (from MADT) use same code as hotadd path, with reserve/realloc. 5. change ioapic add/removing to acpi way, as that is only need when pci root bus hotplug. Also it will make it support the case that ioapic controller is hiding in pci controller space or ioapic address is not managed by pci reallocation system. >> > > A few more notes: > > Please explain what you mean with pre-reserve IRQ blocks, and in > particular, how do you know what to reserve and for what? For each ioapic controller, and we should get gsi range already. So we could keep irq to gsi mapping linear for each ioapic controller. > > Second, some of the things in this patchset seems to overlap with what > we would need to support MSI (as opposed to MSI-X), and you have several > patches related to MSI vs MSI-X. Are you also supporting multivector > MSI (I believe the answer is no) or could some of this work make > multivector MSI practical (possible)? Patches that is related to MSI/MSI-X, is just print out clean up. Now we don't tell if it is MSI or MSI-X in /proc/interrupts or dmesg. Patches from multivector MSI support from Alex are already put in x86/apic branch by Ingo. And my v2 patches are on top of x86/apic and pci/next. Thanks Yinghai -- 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, PCI: Get PRT entry during acpi_pci_enable_irq()
On Tue, 2013-02-12 at 11:11 -0800, Yinghai Lu wrote: > Peter Hurley found "irq 18 nobody cared" with pci-next, and dmesg has > > [8.983246] pci :00:1e.0: can't derive routing for PCI INT A > [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 > > bisect to > | commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 > | PCI: Put pci_dev in device tree as early as possible > > It turns out we need to call acpi_pci_irq_add_prt() after the pci bridges > are scanned. > > Bjorn said: > The bus number binding means acpi_pci_irq_add_prt() has to happen > after enumerating everything below a bridge, and it will prevent us > from doing any bus number reassignment for hotplug. > > I think we should remove the bus numbers from the cached _PRT (or > maybe even remove the _PRT caching completely). When we enable a PCI > device's IRQ, we should search up the PCI device tree looking for a > _PRT associated with each node, and applying normal PCI bridge > swizzling when we don't find a _PRT. I think this can be done without > using PCI bus numbers at all. > > So here we try to remove _PRT caching completely. > > -v2: check !handle early. > > Reported-and-tested-by: Peter Hurley Actually true now :) Reported-and-tested-by: Peter Hurley Regards and thanks again, Peter Hurley PS - I just happened to see this version on the list. Would you please cc me on any future versions? -- 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/
