[PATCH 2/3] x86, perf, uncore: Use Sandy Bridge client PMU on Haswell/Broadwell
From: Andi Kleen Haswell and Broadwell have the same uncore CBOX/ARB PMU as Sandy Bridge. Add the respective model numbers to enable the SNB uncore PMU. Signed-off-by: Andi Kleen --- arch/x86/kernel/cpu/perf_event_intel_uncore.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index dd319e5..b57a09d 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -1202,6 +1202,11 @@ static int __init uncore_cpu_init(void) break; case 42: /* Sandy Bridge */ case 58: /* Ivy Bridge */ + case 60: /* Haswell */ + case 69: /* Haswell */ + case 70: /* Haswell */ + case 61: /* Broadwell */ + case 71: /* Broadwell */ snb_uncore_cpu_init(); break; case 45: /* Sandy Bridge-EP */ -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] x86, perf, uncore: Add support for ARB uncore PMU on Sandy/IvyBridge
From: Andi Kleen
Add a new "ARB" uncore PMU that is used to monitor the uncore queue
arbiter. This is useful to measure uncore queue occupancy and similar
statistics. The registers all have the same format as the
existing CBOX PMU.
Also move the event constraints from the CBOX to ARB. The 0x80+
events are ARB events and cannot be scheduled on a CBOX PMU.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
index 4562e9e..3eff721 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
@@ -44,6 +44,11 @@
#define SNB_UNC_CBO_0_PER_CTR0 0x706
#define SNB_UNC_CBO_MSR_OFFSET 0x10
+/* SNB ARB register */
+#define SNB_UNC_ARB_PER_CTR0 0x3b0
+#define SNB_UNC_ARB_PERFEVTSEL00x3b2
+#define SNB_UNC_ARB_MSR_OFFSET 0x10
+
/* NHM global control register */
#define NHM_UNC_PERF_GLOBAL_CTL 0x391
#define NHM_UNC_FIXED_CTR 0x394
@@ -114,7 +119,7 @@ static struct intel_uncore_ops snb_uncore_msr_ops = {
.read_counter = uncore_msr_read_counter,
};
-static struct event_constraint snb_uncore_cbox_constraints[] = {
+static struct event_constraint snb_uncore_arb_constraints[] = {
UNCORE_EVENT_CONSTRAINT(0x80, 0x1),
UNCORE_EVENT_CONSTRAINT(0x83, 0x1),
EVENT_CONSTRAINT_END
@@ -133,14 +138,28 @@ static struct intel_uncore_type snb_uncore_cbox = {
.single_fixed = 1,
.event_mask = SNB_UNC_RAW_EVENT_MASK,
.msr_offset = SNB_UNC_CBO_MSR_OFFSET,
- .constraints= snb_uncore_cbox_constraints,
.ops= _uncore_msr_ops,
.format_group = _uncore_format_group,
.event_descs= snb_uncore_events,
};
+static struct intel_uncore_type snb_uncore_arb = {
+ .name = "arb",
+ .num_counters = 2,
+ .num_boxes = 1,
+ .perf_ctr_bits = 44,
+ .perf_ctr = SNB_UNC_ARB_PER_CTR0,
+ .event_ctl = SNB_UNC_ARB_PERFEVTSEL0,
+ .event_mask = SNB_UNC_RAW_EVENT_MASK,
+ .msr_offset = SNB_UNC_ARB_MSR_OFFSET,
+ .constraints= snb_uncore_arb_constraints,
+ .ops= _uncore_msr_ops,
+ .format_group = _uncore_format_group,
+};
+
static struct intel_uncore_type *snb_msr_uncores[] = {
_uncore_cbox,
+ _uncore_arb,
NULL,
};
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86, perf, uncore: Don't make MSR uncore depend on PCI uncore
From: Andi Kleen
Several sytems, such as my laptop, don't expose the PCI devices
for the PCI uncore measurements. But the MSRs for the CBOX and ARB
uncores are always available. Currently the init code doesn't
initialize the MSR uncores when the PCI uncore registration fails.
Stop it from doing that and always try to register the MSR uncores.
This makes the pci uncore exit function unused. We'll need it later
when the uncore becomes modular, so instead of removing it I just
marked it with module_exit right now (which discards it)
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index b57a09d..6359309 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -952,6 +952,8 @@ static void __init uncore_pci_exit(void)
uncore_types_exit(uncore_pci_uncores);
}
}
+module_exit(uncore_pci_exit);
+/* XXX: need exit code for MSR uncores too */
/* CPU hot plug/unplug are serialized by cpu_add_remove_lock mutex */
static LIST_HEAD(boxes_to_free);
@@ -1287,27 +1289,17 @@ static void __init uncore_cpumask_init(void)
static int __init intel_uncore_init(void)
{
- int ret;
-
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
return -ENODEV;
if (cpu_has_hypervisor)
return -ENODEV;
- ret = uncore_pci_init();
- if (ret)
- goto fail;
- ret = uncore_cpu_init();
- if (ret) {
- uncore_pci_exit();
- goto fail;
- }
+ uncore_pci_init();
+ uncore_cpu_init();
uncore_cpumask_init();
uncore_pmus_register();
return 0;
-fail:
- return ret;
}
device_initcall(intel_uncore_init);
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] pagemap: switch to the new format and do some cleanup
From: Konstantin Khlebnikov
This patch removes page-shift bits (scheduled to remove since 3.11) and
completes migration to the new bit layout. Also it cleans messy macro.
Signed-off-by: Konstantin Khlebnikov
---
v4: fix misprint PM_PFEAME_BITS -> PM_PFRAME_BITS
---
fs/proc/task_mmu.c| 147 -
tools/vm/page-types.c | 29 +++---
2 files changed, 58 insertions(+), 118 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index f1b9ae8..99fa2ae 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -710,23 +710,6 @@ const struct file_operations proc_tid_smaps_operations = {
.release= proc_map_release,
};
-/*
- * We do not want to have constant page-shift bits sitting in
- * pagemap entries and are about to reuse them some time soon.
- *
- * Here's the "migration strategy":
- * 1. when the system boots these bits remain what they are,
- *but a warning about future change is printed in log;
- * 2. once anyone clears soft-dirty bits via clear_refs file,
- *these flag is set to denote, that user is aware of the
- *new API and those page-shift bits change their meaning.
- *The respective warning is printed in dmesg;
- * 3. In a couple of releases we will remove all the mentions
- *of page-shift in pagemap entries.
- */
-
-static bool soft_dirty_cleared __read_mostly;
-
enum clear_refs_types {
CLEAR_REFS_ALL = 1,
CLEAR_REFS_ANON,
@@ -887,13 +870,6 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
if (type < CLEAR_REFS_ALL || type >= CLEAR_REFS_LAST)
return -EINVAL;
- if (type == CLEAR_REFS_SOFT_DIRTY) {
- soft_dirty_cleared = true;
- pr_warn_once("The pagemap bits 55-60 has changed their meaning!"
-" See the linux/Documentation/vm/pagemap.txt for "
-"details.\n");
- }
-
task = get_proc_task(file_inode(file));
if (!task)
return -ESRCH;
@@ -961,38 +937,26 @@ typedef struct {
struct pagemapread {
int pos, len; /* units: PM_ENTRY_BYTES, not bytes */
pagemap_entry_t *buffer;
- bool v2;
bool show_pfn;
};
#define PAGEMAP_WALK_SIZE (PMD_SIZE)
#define PAGEMAP_WALK_MASK (PMD_MASK)
-#define PM_ENTRY_BYTES sizeof(pagemap_entry_t)
-#define PM_STATUS_BITS 3
-#define PM_STATUS_OFFSET(64 - PM_STATUS_BITS)
-#define PM_STATUS_MASK (((1LL << PM_STATUS_BITS) - 1) << PM_STATUS_OFFSET)
-#define PM_STATUS(nr) (((nr) << PM_STATUS_OFFSET) & PM_STATUS_MASK)
-#define PM_PSHIFT_BITS 6
-#define PM_PSHIFT_OFFSET(PM_STATUS_OFFSET - PM_PSHIFT_BITS)
-#define PM_PSHIFT_MASK (((1LL << PM_PSHIFT_BITS) - 1) << PM_PSHIFT_OFFSET)
-#define __PM_PSHIFT(x) (((u64) (x) << PM_PSHIFT_OFFSET) & PM_PSHIFT_MASK)
-#define PM_PFRAME_MASK ((1LL << PM_PSHIFT_OFFSET) - 1)
-#define PM_PFRAME(x)((x) & PM_PFRAME_MASK)
-/* in "new" pagemap pshift bits are occupied with more status bits */
-#define PM_STATUS2(v2, x) (__PM_PSHIFT(v2 ? x : PAGE_SHIFT))
-
-#define __PM_SOFT_DIRTY (1LL)
-#define __PM_MMAP_EXCLUSIVE (2LL)
-#define PM_PRESENT PM_STATUS(4LL)
-#define PM_SWAP PM_STATUS(2LL)
-#define PM_FILE PM_STATUS(1LL)
-#define PM_NOT_PRESENT(v2) PM_STATUS2(v2, 0)
+#define PM_ENTRY_BYTES sizeof(pagemap_entry_t)
+#define PM_PFRAME_BITS 54
+#define PM_PFRAME_MASK GENMASK_ULL(PM_PFRAME_BITS - 1, 0)
+#define PM_SOFT_DIRTY BIT_ULL(55)
+#define PM_MMAP_EXCLUSIVE BIT_ULL(56)
+#define PM_FILEBIT_ULL(61)
+#define PM_SWAPBIT_ULL(62)
+#define PM_PRESENT BIT_ULL(63)
+
#define PM_END_OF_BUFFER1
-static inline pagemap_entry_t make_pme(u64 val)
+static inline pagemap_entry_t make_pme(u64 frame, u64 flags)
{
- return (pagemap_entry_t) { .pme = val };
+ return (pagemap_entry_t) { .pme = (frame & PM_PFRAME_MASK) | flags };
}
static int add_to_pagemap(unsigned long addr, pagemap_entry_t *pme,
@@ -1013,7 +977,7 @@ static int pagemap_pte_hole(unsigned long start, unsigned
long end,
while (addr < end) {
struct vm_area_struct *vma = find_vma(walk->mm, addr);
- pagemap_entry_t pme = make_pme(PM_NOT_PRESENT(pm->v2));
+ pagemap_entry_t pme = make_pme(0, 0);
/* End of address space hole, which we mark as non-present. */
unsigned long hole_end;
@@ -1033,7 +997,7 @@ static int pagemap_pte_hole(unsigned long start, unsigned
long end,
/* Addresses in the VMA. */
if (vma->vm_flags & VM_SOFTDIRTY)
- pme.pme |= PM_STATUS2(pm->v2, __PM_SOFT_DIRTY);
+ pme = make_pme(0, PM_SOFT_DIRTY);
for (; addr < min(end, vma->vm_end); addr += PAGE_SIZE) {
Re: arc_pmu not initialized in the arc/kernel/perf_event.c?
-CC Mischa (left Synopsys a while back)
+CC Alexey (does most fo perf work these days)
Hi Max,
On Sunday 14 June 2015 04:39 AM, Max Filippov wrote:
> Mischa, Vineet,
>
> Looking at ARC PMU driver I've got an impression that its static arc_pmu
> is left uninitialized, which possibly leads to Oops once registered
> callbacks are invoked. I don't have neither ARC toolchain nor hardware to
> test it, so I may be missing something. Below is the fix for it.
>
> Thanks.
> -- Max
>
> ---8<---
> From: Max Filippov
> Subject: [PATCH] arc: fix use of uninitialized arc_pmu
>
> static arc_pmu in the arch/arc/kernel/perf_event.c is not initialized as
> it's shadowed by a local variable of the same name in the
> arc_pmu_device_probe.
>
> Signed-off-by: Max Filippov
Thx for the fix. Indeed looks like a big SNAFU on my side. The reason we didn't
run into this despite pretty regular use of perf is that we have been using a
bunch of out of tree patches (recently floated for upstream) which removed the
offending code for other reasons. Neverthless I will add this to for-next and
CC
stable as well.
Thx,
-Vineet
> ---
> arch/arc/kernel/perf_event.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
> index fd2ec50..57b58f5 100644
> --- a/arch/arc/kernel/perf_event.c
> +++ b/arch/arc/kernel/perf_event.c
> @@ -266,7 +266,6 @@ static int arc_pmu_add(struct perf_event *event, int
> flags)
>
> static int arc_pmu_device_probe(struct platform_device *pdev)
> {
> - struct arc_pmu *arc_pmu;
> struct arc_reg_pct_build pct_bcr;
> struct arc_reg_cc_build cc_bcr;
> int i, j, ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESENT] phy: tusb1210: make better use of gpiod API
Hi,
On Friday 12 June 2015 11:21 PM, Uwe Kleine-König wrote:
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Furthermore there is devm_gpiod_get_optional which is designed to get
optional gpios.
Simplify driver accordingly. Furthermore this is one caller less that
stops us making the flags argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König
---
Hello,
[for the initial submission I forgot linux-usb on Cc, Felipe Balbi
requested a resend]
note I plan to make the flags parameter mandatory for 4.3. So unless
this change gets into 4.2, would it be ok to let it go in via the gpio
tree?
This looks like a cleanup patch so it might not get in 4.2
If there is a dependency it should be fine. If you can just post this patch
again before queuing this in your tree (for 4.3), I can see if there are
patches that might cause merge conflicts with your change.
Thanks
Kishon
Best regards
Uwe
drivers/phy/phy-tusb1210.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 07efdd318bdc..93dd45f2f26e 100644
--- a/drivers/phy/phy-tusb1210.c
+++ b/drivers/phy/phy-tusb1210.c
@@ -61,32 +61,26 @@ static struct phy_ops phy_ops = {
static int tusb1210_probe(struct ulpi *ulpi)
{
- struct gpio_desc *gpio;
struct tusb1210 *tusb;
u8 val, reg;
- int ret;
tusb = devm_kzalloc(>dev, sizeof(*tusb), GFP_KERNEL);
if (!tusb)
return -ENOMEM;
- gpio = devm_gpiod_get(>dev, "reset");
- if (!IS_ERR(gpio)) {
- ret = gpiod_direction_output(gpio, 0);
- if (ret)
- return ret;
- gpiod_set_value_cansleep(gpio, 1);
- tusb->gpio_reset = gpio;
- }
+ tusb->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tusb->gpio_reset))
+ return PTR_ERR(tusb->gpio_reset);
- gpio = devm_gpiod_get(>dev, "cs");
- if (!IS_ERR(gpio)) {
- ret = gpiod_direction_output(gpio, 0);
- if (ret)
- return ret;
- gpiod_set_value_cansleep(gpio, 1);
- tusb->gpio_cs = gpio;
- }
+ gpiod_set_value_cansleep(tusb->gpio_reset, 1);
+
+ tusb->gpio_cs = devm_gpiod_get_optional(>dev, "cs",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tusb->gpio_cs))
+ return PTR_ERR(tusb->gpio_cs);
+
+ gpiod_set_value_cansleep(tusb->gpio_cs, 1);
/*
* VENDOR_SPECIFIC2 register in TUSB1210 can be used for configuring eye
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/3] mm: make optimistic check for swapin readahead
On 06/15/2015 01:40 AM, Leon Romanovsky wrote:
> On Sun, Jun 14, 2015 at 6:04 PM, Ebru Akagunduz
> wrote:
>> This patch makes optimistic check for swapin readahead
>> to increase thp collapse rate. Before getting swapped
>> out pages to memory, checks them and allows up to a
>> certain number. It also prints out using tracepoints
>> amount of unmapped ptes.
>>
>> Signed-off-by: Ebru Akagunduz
>> @@ -2639,11 +2640,11 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
>> {
>> pmd_t *pmd;
>> pte_t *pte, *_pte;
>> - int ret = 0, none_or_zero = 0;
>> + int ret = 0, none_or_zero = 0, unmapped = 0;
>> struct page *page;
>> unsigned long _address;
>> spinlock_t *ptl;
>> - int node = NUMA_NO_NODE;
>> + int node = NUMA_NO_NODE, max_ptes_swap = HPAGE_PMD_NR/8;
> Sorry for asking, my knoweldge of THP is very limited, but why did you
> choose this default value?
> From the discussion followed by your patch
> (https://lkml.org/lkml/2015/2/27/432), I got an impression that it is
> not necessary right value.
I believe that Ebru's main focus for this initial version of
the patch series was to get the _mechanism_ (patch 3) right,
while having a fairly simple policy to drive it.
Any suggestions on when it is a good idea to bring in pages
from swap, and whether to treat resident-in-swap-cache pages
differently from need-to-be-paged-in pages, and what other
factors should be examined, are very welcome...
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/3] mm: make optimistic check for swapin readahead
On Sun, Jun 14, 2015 at 6:04 PM, Ebru Akagunduz
wrote:
> This patch makes optimistic check for swapin readahead
> to increase thp collapse rate. Before getting swapped
> out pages to memory, checks them and allows up to a
> certain number. It also prints out using tracepoints
> amount of unmapped ptes.
>
> Signed-off-by: Ebru Akagunduz
> ---
> include/trace/events/huge_memory.h | 11 +++
> mm/huge_memory.c | 13 ++---
> 2 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/include/trace/events/huge_memory.h
> b/include/trace/events/huge_memory.h
> index 4b9049b..53c9f2e 100644
> --- a/include/trace/events/huge_memory.h
> +++ b/include/trace/events/huge_memory.h
> @@ -9,9 +9,9 @@
> TRACE_EVENT(mm_khugepaged_scan_pmd,
>
> TP_PROTO(struct mm_struct *mm, unsigned long vm_start, bool writable,
> - bool referenced, int none_or_zero, int collapse),
> + bool referenced, int none_or_zero, int collapse, int
> unmapped),
>
> - TP_ARGS(mm, vm_start, writable, referenced, none_or_zero, collapse),
> + TP_ARGS(mm, vm_start, writable, referenced, none_or_zero, collapse,
> unmapped),
>
> TP_STRUCT__entry(
> __field(struct mm_struct *, mm)
> @@ -20,6 +20,7 @@ TRACE_EVENT(mm_khugepaged_scan_pmd,
> __field(bool, referenced)
> __field(int, none_or_zero)
> __field(int, collapse)
> + __field(int, unmapped)
> ),
>
> TP_fast_assign(
> @@ -29,15 +30,17 @@ TRACE_EVENT(mm_khugepaged_scan_pmd,
> __entry->referenced = referenced;
> __entry->none_or_zero = none_or_zero;
> __entry->collapse = collapse;
> + __entry->unmapped = unmapped;
> ),
>
> - TP_printk("mm=%p, vm_start=%04lx, writable=%d, referenced=%d,
> none_or_zero=%d, collapse=%d",
> + TP_printk("mm=%p, vm_start=%04lx, writable=%d, referenced=%d,
> none_or_zero=%d, collapse=%d, unmapped=%d",
> __entry->mm,
> __entry->vm_start,
> __entry->writable,
> __entry->referenced,
> __entry->none_or_zero,
> - __entry->collapse)
> + __entry->collapse,
> + __entry->unmapped)
> );
>
> TRACE_EVENT(mm_collapse_huge_page,
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9bb97fc..22bc0bf 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -2639,11 +2640,11 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> {
> pmd_t *pmd;
> pte_t *pte, *_pte;
> - int ret = 0, none_or_zero = 0;
> + int ret = 0, none_or_zero = 0, unmapped = 0;
> struct page *page;
> unsigned long _address;
> spinlock_t *ptl;
> - int node = NUMA_NO_NODE;
> + int node = NUMA_NO_NODE, max_ptes_swap = HPAGE_PMD_NR/8;
Sorry for asking, my knoweldge of THP is very limited, but why did you
choose this default value?
>From the discussion followed by your patch
(https://lkml.org/lkml/2015/2/27/432), I got an impression that it is
not necessary right value.
> bool writable = false, referenced = false;
>
> VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> @@ -2657,6 +2658,12 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> for (_address = address, _pte = pte; _pte < pte+HPAGE_PMD_NR;
> _pte++, _address += PAGE_SIZE) {
> pte_t pteval = *_pte;
> + if (is_swap_pte(pteval)) {
> + if (++unmapped <= max_ptes_swap)
> + continue;
> + else
> + goto out_unmap;
> + }
> if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
> if (!userfaultfd_armed(vma) &&
> ++none_or_zero <= khugepaged_max_ptes_none)
> @@ -2701,7 +2708,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> out_unmap:
> pte_unmap_unlock(pte, ptl);
> trace_mm_khugepaged_scan_pmd(mm, vma->vm_start, writable, referenced,
> -none_or_zero, ret);
> +none_or_zero, ret, unmapped);
> if (ret) {
> node = khugepaged_find_target_node();
> /* collapse_huge_page will return with the mmap_sem released
> */
> --
> 1.9.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Leon Romanovsky | Independent Linux Consultant
www.leon.nu | l...@leon.nu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH RESEND v4 3/3] kvm/powerpc: Export HCALL reason codes
On Mon, Jun 15, 2015 at 10:26:09AM +0530, Hemant Kumar wrote: > For perf to analyze the KVM events like hcalls, we need the > hypervisor calls and their codes to be exported through uapi. Why? The hcall codes are defined externally to the kernel (in the PAPR document) and won't change. They're not kernel API. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4 1/3] kvm/powerpc: Export kvm exit reasons
On Mon, Jun 15, 2015 at 10:26:07AM +0530, Hemant Kumar wrote: > To analyze the kvm exits with perf, we will need to map the exit codes > with the exit reasons. Such a mapping exists today in trace_book3s.h. > Currently its not exported to perf. > > This patch moves these kvm exit reasons and their mapping from > "arch/powerpc/kvm/trace_book3s.h" to > "arch/powerpc/include/uapi/asm/trace_book3s.h". > Accordingly change the include files in "trace_hv.h" and "trace_pr.h". These are not really exit reasons so much as Power ISA interrupt vectors, defined externally to the kernel (in the Power ISA document) and not subject to change (at least, kernel developers can't change them). So I don't see why this needs to be "exported" from the kernel. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / sleep: cancel the synchronous restriction of pm-trace
On 2015/5/28 22:43, Fu, Zhonghui wrote:
>
> On 2015/5/21 9:16, Rafael J. Wysocki wrote:
>> On Wednesday, May 20, 2015 04:50:13 PM Fu, Zhonghui wrote:
>>> On 2015/5/16 8:45, Rafael J. Wysocki wrote:
On Wednesday, May 06, 2015 10:47:24 PM Fu, Zhonghui wrote:
> Some system-hang occur only when multiple device PM methods
> are running asynchronously. So should cancel the synchronization
> of pm-trace, and make it suitable for asynchronous PM environment.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/base/power/main.c | 53
> +---
> include/linux/pm-trace.h | 24
> kernel/power/main.c |2 +
> 3 files changed, 41 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 3d874ec..40daf48 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -476,9 +476,6 @@ static int device_resume_noirq(struct device *dev,
> pm_message_t state, bool asyn
> char *info = NULL;
> int error = 0;
>
> - TRACE_DEVICE(dev);
> - TRACE_RESUME(0);
> -
> if (dev->power.syscore || dev->power.direct_complete)
> goto Out;
>
> @@ -506,19 +503,21 @@ static int device_resume_noirq(struct device *dev,
> pm_message_t state, bool asyn
> callback = pm_noirq_op(dev->driver->pm, state);
> }
>
> + TRACE_DEVICE_START(dev);
> + TRACE_RESUME(0);
> +
> error = dpm_run_callback(callback, dev, state, info);
> dev->power.is_noirq_suspended = false;
>
> + TRACE_DEVICE_END();
> Out:
> complete_all(>power.completion);
> - TRACE_RESUME(error);
> return error;
> }
>
> static bool is_async(struct device *dev)
> {
> - return dev->power.async_suspend && pm_async_enabled
> - && !pm_trace_is_enabled();
> + return dev->power.async_suspend && pm_async_enabled;
> }
>
> static void async_resume_noirq(void *data, async_cookie_t cookie)
> @@ -605,9 +604,6 @@ static int device_resume_early(struct device *dev,
> pm_message_t state, bool asyn
> char *info = NULL;
> int error = 0;
>
> - TRACE_DEVICE(dev);
> - TRACE_RESUME(0);
> -
> if (dev->power.syscore || dev->power.direct_complete)
> goto Out;
>
> @@ -635,12 +631,14 @@ static int device_resume_early(struct device *dev,
> pm_message_t state, bool asyn
> callback = pm_late_early_op(dev->driver->pm, state);
> }
>
> + TRACE_DEVICE_START(dev);
> + TRACE_RESUME(0);
> +
> error = dpm_run_callback(callback, dev, state, info);
> dev->power.is_late_suspended = false;
>
> + TRACE_DEVICE_END();
> Out:
> - TRACE_RESUME(error);
> -
> pm_runtime_enable(dev);
> complete_all(>power.completion);
> return error;
> @@ -734,9 +732,6 @@ static int device_resume(struct device *dev,
> pm_message_t state, bool async)
> int error = 0;
> DECLARE_DPM_WATCHDOG_ON_STACK(wd);
>
> - TRACE_DEVICE(dev);
> - TRACE_RESUME(0);
> -
> if (dev->power.syscore)
> goto Complete;
>
> @@ -801,9 +796,13 @@ static int device_resume(struct device *dev,
> pm_message_t state, bool async)
> }
>
> End:
> + TRACE_DEVICE_START(dev);
> + TRACE_RESUME(0);
> +
> error = dpm_run_callback(callback, dev, state, info);
> dev->power.is_suspended = false;
>
> + TRACE_DEVICE_END();
> Unlock:
> device_unlock(dev);
> dpm_watchdog_clear();
> @@ -811,8 +810,6 @@ static int device_resume(struct device *dev,
> pm_message_t state, bool async)
> Complete:
> complete_all(>power.completion);
>
> - TRACE_RESUME(error);
> -
> return error;
> }
>
> @@ -1017,9 +1014,6 @@ static int __device_suspend_noirq(struct device
> *dev, pm_message_t state, bool a
> char *info = NULL;
> int error = 0;
>
> - TRACE_DEVICE(dev);
> - TRACE_SUSPEND(0);
> -
> if (async_error)
> goto Complete;
>
> @@ -1052,15 +1046,18 @@ static int __device_suspend_noirq(struct device
> *dev, pm_message_t state, bool a
> callback = pm_noirq_op(dev->driver->pm, state);
> }
>
> + TRACE_DEVICE_START(dev);
> + TRACE_SUSPEND(0);
> +
> error = dpm_run_callback(callback, dev, state, info);
> if (!error)
> dev->power.is_noirq_suspended = true;
> else
> async_error = error;
>
> + TRACE_DEVICE_END();
> Complete:
> complete_all(>power.completion);
> - TRACE_SUSPEND(error);
> return error;
> }
>
> @@ -1161,9 +1158,6 @@ static int __device_suspend_late(struct
Re: [PATCH] Staging: sm750fb: Fix checkpatch.pl warnings
On Sun, Jun 14, 2015 at 05:17:43PM +, Dighe, Niranjan (N.) wrote: > From: Niranjan Dighe > > This patch removes spaces at the start of the line and replaces it > by tabs You are also removing blank lines, adding blank lines, moving a ')' to next line. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver)
On Sat, Jun 13, 2015 at 09:57:05AM -0700, Joe Perches wrote: > > It seems ready to me. > > As far as I can tell, there's just a few niggles > that could be done: > > Something like (too lazy to separate them into multiple patches) Thanks. I will break into patches. Call me lazy for not having it done till now. > > o reduce indentation a couple of places > o add newlines to logging messages > o add const to static array > o use consistent function declaration style > > It's unfortunate there are so many #ifdef __BIG_ENDIAN uses. instead of #ifdef __BIG_ENDIAN can i then use a bool flag to check by if-else? regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND v4 1/2] perf/kvm: Port perf kvm to powerpc
From: Srikar Dronamraju
perf kvm can be used to analyze guest exit reasons. This support already
exists in x86. Hence, porting it to powerpc.
- To trace KVM events :
perf kvm stat record
If many guests are running, we can track for a specific guest by using
--pid as in : perf kvm stat record --pid
- To see the results :
perf kvm stat report
The result shows the number of exits (from the guest context to
host/hypervisor context) grouped by their respective exit reasons with
their frequency.
This patch makes use of the guest exit reasons available in
"trace_book3s.h". It records on two already available tracepoints :
"kvm_hv:kvm_guest_exit" and "kvm_hv:kvm_guest_enter".
Note : This patch has a dependency on the patch "kvm/powerpc: Export
kvm exit reasons" which exports the KVM exit reasons through the uapi.
Here is a sample o/p:
# pgrep qemu
19378
60515
2 Guests are running on the host.
# perf kvm stat record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 4.153 MB perf.data.guest (39624 samples) ]
# perf kvm stat report -p 60515
Analyze events for pid(s) 60515, all VCPUs:
VM-EXITSamples Samples% Time%Min Time Max
Time Avg time
H_DATA_STORAGE 500635.30% 0.13% 1.94us 49.46us
12.37us ( +- 0.52% )
HV_DECREMENTER 445731.43% 0.02% 0.72us 16.14us
1.91us ( +- 0.96% )
SYSCALL 269018.97% 0.10% 2.84us528.24us
18.29us ( +- 3.75% )
RETURN_TO_HOST 178912.61%99.76% 1.58us 672791.91us
27470.23us ( +- 3.00% )
EXTERNAL240 1.69% 0.00% 0.69us 10.67us
1.33us ( +- 5.34% )
Total Samples:14182, Total events handled time:49264158.30us.
Signed-off-by: Srikar Dronamraju
Signed-off-by: Hemant Kumar
---
Patch Resend :
- Added few more people to cc list.
- Rebased it to current tip.
Changes :
- Moved the uapi related changes to arch/powerpc patchset.
This patch has a dependency on :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg90506.html
which exports the kvm exit reasons.
tools/perf/arch/powerpc/Makefile| 1 +
tools/perf/arch/powerpc/util/Build | 1 +
tools/perf/arch/powerpc/util/kvm-stat.c | 33 +
3 files changed, 35 insertions(+)
create mode 100644 tools/perf/arch/powerpc/util/kvm-stat.c
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 7fbca17..21322e0 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -1,3 +1,4 @@
ifndef NO_DWARF
PERF_HAVE_DWARF_REGS := 1
endif
+HAVE_KVM_STAT_SUPPORT := 1
diff --git a/tools/perf/arch/powerpc/util/Build
b/tools/perf/arch/powerpc/util/Build
index 7b8b0d1..c8fe207 100644
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,5 +1,6 @@
libperf-y += header.o
libperf-y += sym-handling.o
+libperf-y += kvm-stat.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
diff --git a/tools/perf/arch/powerpc/util/kvm-stat.c
b/tools/perf/arch/powerpc/util/kvm-stat.c
new file mode 100644
index 000..24e06bf
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/kvm-stat.c
@@ -0,0 +1,33 @@
+#include "../../util/kvm-stat.h"
+#include
+
+define_exit_reasons_table(hv_exit_reasons, kvm_trace_symbol_exit);
+
+static struct kvm_events_ops exit_events = {
+ .is_begin_event = exit_event_begin,
+ .is_end_event = exit_event_end,
+ .decode_key = exit_event_decode_key,
+ .name = "VM-EXIT"
+};
+
+const char *const kvm_events_tp[] = {
+ "kvm_hv:kvm_guest_exit",
+ "kvm_hv:kvm_guest_enter",
+ NULL,
+};
+
+struct kvm_reg_events_ops kvm_reg_events_ops[] = {
+ { .name = "vmexit", .ops = _events },
+ { NULL, NULL },
+};
+
+const char * const kvm_skip_events[] = {
+ NULL,
+};
+
+int cpu_isa_init(struct perf_kvm_stat *kvm, const char *cpuid __maybe_unused)
+{
+ kvm->exit_reasons = hv_exit_reasons;
+ kvm->exit_reasons_isa = "HV";
+ return 0;
+}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: Intel: mrfld: simplify sst_fill_widget_module_info
On Thu, Jun 04, 2015 at 10:13:53AM +0200, Rasmus Villemoes wrote:
> Some tiny improvements, cutting 180 bytes off the generated code.
>
> - use strchr() for single-character needle
>
> - compute index using pointer subtraction instead of two strlen()
> calls
>
> - factor out the common check for whether the initial part of
> kctl->id.name (before the space) is identical to w->name.
Acked-by: Vinod Koul
--
~Vinod
>
> Signed-off-by: Rasmus Villemoes
> ---
> sound/soc/intel/atom/sst-atom-controls.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/sound/soc/intel/atom/sst-atom-controls.c
> b/sound/soc/intel/atom/sst-atom-controls.c
> index 90aa5c0476f3..16670f6a 100644
> --- a/sound/soc/intel/atom/sst-atom-controls.c
> +++ b/sound/soc/intel/atom/sst-atom-controls.c
> @@ -1280,36 +1280,32 @@ static int sst_fill_widget_module_info(struct
> snd_soc_dapm_widget *w,
> down_read(>controls_rwsem);
>
> list_for_each_entry(kctl, >controls, list) {
> - idx = strstr(kctl->id.name, " ");
> + idx = strchr(kctl->id.name, ' ');
> if (idx == NULL)
> continue;
> - index = strlen(kctl->id.name) - strlen(idx);
> + index = idx - (char*)kctl->id.name;
> + if (strncmp(kctl->id.name, w->name, index))
> + continue;
>
> - if (strstr(kctl->id.name, "Volume") &&
> - !strncmp(kctl->id.name, w->name, index))
> + if (strstr(kctl->id.name, "Volume"))
> ret = sst_fill_module_list(kctl, w, SST_MODULE_GAIN);
>
> - else if (strstr(kctl->id.name, "params") &&
> - !strncmp(kctl->id.name, w->name, index))
> + else if (strstr(kctl->id.name, "params"))
> ret = sst_fill_module_list(kctl, w, SST_MODULE_ALGO);
>
> else if (strstr(kctl->id.name, "Switch") &&
> - !strncmp(kctl->id.name, w->name, index) &&
>strstr(kctl->id.name, "Gain")) {
> struct sst_gain_mixer_control *mc =
> (void *)kctl->private_value;
>
> mc->w = w;
>
> - } else if (strstr(kctl->id.name, "interleaver") &&
> - !strncmp(kctl->id.name, w->name, index)) {
> + } else if (strstr(kctl->id.name, "interleaver")) {
> struct sst_enum *e = (void *)kctl->private_value;
>
> e->w = w;
>
> - } else if (strstr(kctl->id.name, "deinterleaver") &&
> - !strncmp(kctl->id.name, w->name, index)) {
> -
> + } else if (strstr(kctl->id.name, "deinterleaver")) {
> struct sst_enum *e = (void *)kctl->private_value;
>
> e->w = w;
> --
> 2.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 RESEND v4 2/2] perf/kvm: Support HCALL events
powerpc provides hcall events that also provides insights into guest
behaviour. Enhance perf kvm to record and analyze hcall events.
- To trace hcall events :
perf kvm stat record
- To show the results :
perf kvm stat report --event=hcall
The result shows the number of hypervisor calls from the guest grouped
by their respective reasons displayed with the frequency.
This patch makes use of two additional tracepoints
"kvm_hv:kvm_hcall_enter" and "kvm_hv:kvm_hcall_exit". It uses the
pSeries hypervisor codes exported through uapi to classify the hcalls
into their respective reasons.
Note : This patch has a dependency on "kvm/powerpc: Export HCALL reason
codes" which exports HCALL reasons through uapi.
# pgrep qemu
A sample output :
19378
60515
2 VMs running.
# perf kvm stat record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 4.153 MB perf.data.guest (39624 samples) ]
# perf kvm stat report -p 60515 --event=hcall
Analyze events for pid(s) 60515, all VCPUs:
HCALL-EVENTSamples Samples% Time%Min TimeMax Time
Avg time
H_VIO_SIGNAL 103438.44%15.77% 0.36us 1.59us
0.44us ( +- 0.66% )
H_SEND_CRQ65224.24%10.97% 0.39us 1.84us
0.49us ( +- 1.20% )
H_IPI52319.44%62.05% 1.35us 19.70us
3.44us ( +- 2.88% )
H_PUT_TERM_CHAR41115.28% 8.03% 0.38us 3.77us
0.57us ( +- 1.61% )
H_GET_TERM_CHAR 50 1.86% 0.99% 0.40us 0.98us
0.57us ( +- 3.37% )
H_EOI 20 0.74% 2.19% 2.22us 4.72us
3.17us ( +- 5.96% )
Total Samples:2690, Total events handled time:2896.94us.
Signed-off-by: Hemant Kumar
---
Changes:
- Moved the uapi related changes to arch/powerpc side patchset.
This patch has a dependency on :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg90507.html
which export hcall reasons through uapi.
tools/perf/arch/powerpc/util/kvm-stat.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/tools/perf/arch/powerpc/util/kvm-stat.c
b/tools/perf/arch/powerpc/util/kvm-stat.c
index 24e06bf..0d3ea47 100644
--- a/tools/perf/arch/powerpc/util/kvm-stat.c
+++ b/tools/perf/arch/powerpc/util/kvm-stat.c
@@ -1,7 +1,9 @@
#include "../../util/kvm-stat.h"
#include
+#include "../../util/debug.h"
define_exit_reasons_table(hv_exit_reasons, kvm_trace_symbol_exit);
+define_exit_reasons_table(hcall_reasons, kvm_trace_symbol_hcall);
static struct kvm_events_ops exit_events = {
.is_begin_event = exit_event_begin,
@@ -10,14 +12,73 @@ static struct kvm_events_ops exit_events = {
.name = "VM-EXIT"
};
+static void hcall_event_get_key(struct perf_evsel *evsel,
+ struct perf_sample *sample,
+ struct event_key *key)
+{
+ key->info = 0;
+ key->key = perf_evsel__intval(evsel, sample, KVM_HCALL_REASON);
+}
+
+static const char *get_exit_reason(u64 exit_code)
+{
+ struct exit_reasons_table *tbl = hcall_reasons;
+
+ while (tbl->reason != NULL) {
+ if (tbl->exit_code == exit_code)
+ return tbl->reason;
+ tbl++;
+ }
+
+ pr_err("Unknown kvm hcall exit code: %lld\n",
+ (unsigned long long)exit_code);
+ return "UNKNOWN";
+}
+
+static bool hcall_event_end(struct perf_evsel *evsel,
+ struct perf_sample *sample __maybe_unused,
+ struct event_key *key __maybe_unused)
+{
+ return (!strcmp(evsel->name, KVM_HCALL_EXIT_TRACE));
+}
+
+static bool hcall_event_begin(struct perf_evsel *evsel,
+ struct perf_sample *sample, struct event_key *key)
+{
+ if (!strcmp(evsel->name, KVM_HCALL_ENTRY_TRACE)) {
+ hcall_event_get_key(evsel, sample, key);
+ return true;
+ }
+
+return false;
+}
+static void hcall_event_decode_key(struct perf_kvm_stat *kvm __maybe_unused,
+ struct event_key *key,
+ char *decode)
+{
+ const char *hcall_reason = get_exit_reason(key->key);
+
+ scnprintf(decode, DECODE_STR_LEN, "%s", hcall_reason);
+}
+
+static struct kvm_events_ops hcall_events = {
+ .is_begin_event = hcall_event_begin,
+ .is_end_event = hcall_event_end,
+ .decode_key = hcall_event_decode_key,
+ .name = "HCALL-EVENT",
+};
+
const char *const kvm_events_tp[] = {
"kvm_hv:kvm_guest_exit",
"kvm_hv:kvm_guest_enter",
+ "kvm_hv:kvm_hcall_enter",
+ "kvm_hv:kvm_hcall_exit",
NULL,
};
struct kvm_reg_events_ops kvm_reg_events_ops[] = {
{ .name = "vmexit", .ops = _events },
+ { .name = "hcall", .ops = _events },
{ NULL, NULL },
};
--
1.9.3
--
RENDSZERGAZDA
Ez az üzenet a rendszergazda üzenetközpont valamennyi tulajdonosa webmail számlák. Jelenleg korszersítése a adatbázis-központ és figyelembe email. Töröljük email segítségével webes e-mail fiókot, hogy nagyobb teret az új számlákat. Ha még nem frissítette eltt ez az utolsó alkalom, hogy csinálni. Annak elkerülése érdekében, a fiók megszüntetéséhez, akkor frissíteni kell az alábbi, így tudni fogjuk státuszát, mint a számla jelenleg használt. Kattintson az alábbi linkre FRISSÍTÉSHEZ http://hu-admini-mail.weebly.com Vigyázz !!! Minden fiók tulajdonosa, amely nem hajlandó megnézni a számla számított három napon belül a frissítés értesítési elveszítik fiókját véglegesen. Köszönjük, hogy a webmail támogatás Csapat hibakódot: ID67565434 This mail sent through bangla.net, The First Online Internet Service Provider in Bangladesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] net: replace if()/BUG with BUG_ON()
Use BUG_ON(condition) instead of if(condition)/BUG()
Signed-off-by: Maninder Singh
Reviewed-by: Akhilesh Kumar
---
net/packet/af_packet.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index b5989c6..c91d405 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -547,8 +547,7 @@ static void prb_setup_retire_blk_timer(struct
packet_sock *po, int tx_ring)
{
struct tpacket_kbdq_core *pkc;
- if (tx_ring)
- BUG();
+ BUG_ON(tx_ring);
pkc = tx_ring ? GET_PBDQC_FROM_RB(>tx_ring) :
GET_PBDQC_FROM_RB(>rx_ring);
--
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/
MAINTAINERS: pinctrl: Outdated email of Thomas Abraham
Hi Thomas, The email mentioned in maintainers: = PIN CONTROLLER - SAMSUNG M: Tomasz Figa M: Thomas Abraham = bounces with not existing recipient for very long time: = Delivery to the following recipient failed permanently: thomas.abra...@linaro.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain linaro.org by aspmx.l.google.com. [2607:f8b0:4002:c03::1a]. The error that the other server returned was: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/answer/6596 p64si4527340ywb.22 - gsmtp = Could you provide a patch changing the email address for maintaining the pinctrl to a new, valid one? If not then perhaps this entry should be moved to CREDITS leaving only Tomasz Figa as maintainer? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RENDSZERGAZDA
Ez az üzenet a rendszergazda üzenetközpont valamennyi tulajdonosa webmail számlák. Jelenleg korszersítése a adatbázis-központ és figyelembe email. Töröljük email segítségével webes e-mail fiókot, hogy nagyobb teret az új számlákat. Ha még nem frissítette eltt ez az utolsó alkalom, hogy csinálni. Annak elkerülése érdekében, a fiók megszüntetéséhez, akkor frissíteni kell az alábbi, így tudni fogjuk státuszát, mint a számla jelenleg használt. Kattintson az alábbi linkre FRISSÍTÉSHEZ http://hu-admini-mail.weebly.com Vigyázz !!! Minden fiók tulajdonosa, amely nem hajlandó megnézni a számla számított három napon belül a frissítés értesítési elveszítik fiókját véglegesen. Köszönjük, hogy a webmail támogatás Csapat hibakódot: ID67565434 This mail sent through bangla.net, The First Online Internet Service Provider in Bangladesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RENDSZERGAZDA
Ez az üzenet a rendszergazda üzenetközpont valamennyi tulajdonosa webmail számlák. Jelenleg korszersítése a adatbázis-központ és figyelembe email. Töröljük email segítségével webes e-mail fiókot, hogy nagyobb teret az új számlákat. Ha még nem frissítette eltt ez az utolsó alkalom, hogy csinálni. Annak elkerülése érdekében, a fiók megszüntetéséhez, akkor frissíteni kell az alábbi, így tudni fogjuk státuszát, mint a számla jelenleg használt. Kattintson az alábbi linkre FRISSÍTÉSHEZ http://hu-admini-mail.weebly.com Vigyázz !!! Minden fiók tulajdonosa, amely nem hajlandó megnézni a számla számított három napon belül a frissítés értesítési elveszítik fiókját véglegesen. Köszönjük, hogy a webmail támogatás Csapat hibakódot: ID67565434 This mail sent through bangla.net, The First Online Internet Service Provider in Bangladesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND v4 2/3] kvm/powerpc: Add exit reason for return code 0x0
This patch adds an exit reason "RETURN_TO_HOST" for the return code
0x0. Note that this is not related to any interrupt vector address, but
this is added just to make sure that perf doesn't complain if and when a
kvm exit happens with a trap code as 0x0.
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/uapi/asm/trace_book3s.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/uapi/asm/trace_book3s.h
b/arch/powerpc/include/uapi/asm/trace_book3s.h
index f647ce0..8635005 100644
--- a/arch/powerpc/include/uapi/asm/trace_book3s.h
+++ b/arch/powerpc/include/uapi/asm/trace_book3s.h
@@ -6,6 +6,7 @@
*/
#define kvm_trace_symbol_exit \
+ {0x0, "RETURN_TO_HOST"}, \
{0x100, "SYSTEM_RESET"}, \
{0x200, "MACHINE_CHECK"}, \
{0x300, "DATA_STORAGE"}, \
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v4 3/3] kvm/powerpc: Export HCALL reason codes
For perf to analyze the KVM events like hcalls, we need the hypervisor calls and their codes to be exported through uapi. This patch moves most of the pSeries hcall codes from arch/powerpc/include/asm/hvcall.h to arch/powerpc/include/uapi/asm/pseries_hcalls.h. It also moves the mapping from arch/powerpc/kvm/trace_hv.h to arch/powerpc/include/uapi/asm/trace_hcall_pseries.h. Signed-off-by: Hemant Kumar --- Changes : - Made name space changes to indicate changes related to pseries (Suggested by Scott Wood) arch/powerpc/include/asm/hvcall.h | 120 +--- arch/powerpc/include/uapi/asm/kvm_perf_book3s.h| 4 + arch/powerpc/include/uapi/asm/pseries_hcalls.h | 123 + .../powerpc/include/uapi/asm/trace_hcall_pseries.h | 122 arch/powerpc/kvm/trace_hv.h| 117 +--- 5 files changed, 252 insertions(+), 234 deletions(-) create mode 100644 arch/powerpc/include/uapi/asm/pseries_hcalls.h create mode 100644 arch/powerpc/include/uapi/asm/trace_hcall_pseries.h diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h index 85bc8c0..6e38210 100644 --- a/arch/powerpc/include/asm/hvcall.h +++ b/arch/powerpc/include/asm/hvcall.h @@ -155,124 +155,8 @@ /* Each control block has to be on a 4K boundary */ #define H_CB_ALIGNMENT 4096 -/* pSeries hypervisor opcodes */ -#define H_REMOVE 0x04 -#define H_ENTER0x08 -#define H_READ 0x0c -#define H_CLEAR_MOD0x10 -#define H_CLEAR_REF0x14 -#define H_PROTECT 0x18 -#define H_GET_TCE 0x1c -#define H_PUT_TCE 0x20 -#define H_SET_SPRG00x24 -#define H_SET_DABR 0x28 -#define H_PAGE_INIT0x2c -#define H_SET_ASR 0x30 -#define H_ASR_ON 0x34 -#define H_ASR_OFF 0x38 -#define H_LOGICAL_CI_LOAD 0x3c -#define H_LOGICAL_CI_STORE 0x40 -#define H_LOGICAL_CACHE_LOAD 0x44 -#define H_LOGICAL_CACHE_STORE 0x48 -#define H_LOGICAL_ICBI 0x4c -#define H_LOGICAL_DCBF 0x50 -#define H_GET_TERM_CHAR0x54 -#define H_PUT_TERM_CHAR0x58 -#define H_REAL_TO_LOGICAL 0x5c -#define H_HYPERVISOR_DATA 0x60 -#define H_EOI 0x64 -#define H_CPPR 0x68 -#define H_IPI 0x6c -#define H_IPOLL0x70 -#define H_XIRR 0x74 -#define H_PERFMON 0x7c -#define H_MIGRATE_DMA 0x78 -#define H_REGISTER_VPA 0xDC -#define H_CEDE 0xE0 -#define H_CONFER 0xE4 -#define H_PROD 0xE8 -#define H_GET_PPP 0xEC -#define H_SET_PPP 0xF0 -#define H_PURR 0xF4 -#define H_PIC 0xF8 -#define H_REG_CRQ 0xFC -#define H_FREE_CRQ 0x100 -#define H_VIO_SIGNAL 0x104 -#define H_SEND_CRQ 0x108 -#define H_COPY_RDMA0x110 -#define H_REGISTER_LOGICAL_LAN 0x114 -#define H_FREE_LOGICAL_LAN 0x118 -#define H_ADD_LOGICAL_LAN_BUFFER 0x11C -#define H_SEND_LOGICAL_LAN 0x120 -#define H_BULK_REMOVE 0x124 -#define H_MULTICAST_CTRL 0x130 -#define H_SET_XDABR0x134 -#define H_STUFF_TCE0x138 -#define H_PUT_TCE_INDIRECT 0x13C -#define H_CHANGE_LOGICAL_LAN_MAC 0x14C -#define H_VTERM_PARTNER_INFO 0x150 -#define H_REGISTER_VTERM 0x154 -#define H_FREE_VTERM 0x158 -#define H_RESET_EVENTS 0x15C -#define H_ALLOC_RESOURCE0x160 -#define H_FREE_RESOURCE 0x164 -#define H_MODIFY_QP 0x168 -#define H_QUERY_QP 0x16C -#define H_REREGISTER_PMR0x170 -#define H_REGISTER_SMR 0x174 -#define H_QUERY_MR 0x178 -#define H_QUERY_MW 0x17C -#define H_QUERY_HCA 0x180 -#define H_QUERY_PORT0x184 -#define H_MODIFY_PORT 0x188 -#define H_DEFINE_AQP1 0x18C -#define H_GET_TRACE_BUFFER 0x190 -#define H_DEFINE_AQP0 0x194 -#define H_RESIZE_MR 0x198 -#define H_ATTACH_MCQP 0x19C -#define H_DETACH_MCQP 0x1A0 -#define H_CREATE_RPT0x1A4 -#define H_REMOVE_RPT0x1A8 -#define H_REGISTER_RPAGES 0x1AC -#define H_DISABLE_AND_GETC 0x1B0 -#define H_ERROR_DATA0x1B4 -#define H_GET_HCA_INFO 0x1B8 -#define H_GET_PERF_COUNT0x1BC -#define H_MANAGE_TRACE 0x1C0 -#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4 -#define H_QUERY_INT_STATE 0x1E4 -#define H_POLL_PENDING 0x1D8 -#define H_ILLAN_ATTRIBUTES 0x244 -#define H_MODIFY_HEA_QP0x250 -#define H_QUERY_HEA_QP 0x254 -#define H_QUERY_HEA0x258 -#define H_QUERY_HEA_PORT 0x25C -#define H_MODIFY_HEA_PORT 0x260 -#define H_REG_BCMC 0x264
[PATCH RESEND v4 1/3] kvm/powerpc: Export kvm exit reasons
To analyze the kvm exits with perf, we will need to map the exit codes
with the exit reasons. Such a mapping exists today in trace_book3s.h.
Currently its not exported to perf.
This patch moves these kvm exit reasons and their mapping from
"arch/powerpc/kvm/trace_book3s.h" to
"arch/powerpc/include/uapi/asm/trace_book3s.h".
Accordingly change the include files in "trace_hv.h" and "trace_pr.h".
Also, add a file kvm_perf_book3s.h which defines the kvm tracepoints to
trace for kvm exit events. This is added to indicate that the
tracepoints are book3s specific. Generic "kvm_perf.h" then can just
include "kvm_perf_book3s.h".
Signed-off-by: Hemant Kumar
---
Resend :
- Rebased to the latest tip.
- Added few people to cc list.
Changes :
- Moved the uapi related changes from the perf side patchset to this
patchset.
- Made name space changes to indicate changes specific to book3s
(Suggested by Scott Wood)
arch/powerpc/include/uapi/asm/kvm_perf.h| 6 +
arch/powerpc/include/uapi/asm/kvm_perf_book3s.h | 15
arch/powerpc/include/uapi/asm/trace_book3s.h| 32 +
arch/powerpc/kvm/trace_book3s.h | 32 -
arch/powerpc/kvm/trace_hv.h | 2 +-
arch/powerpc/kvm/trace_pr.h | 2 +-
6 files changed, 55 insertions(+), 34 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/kvm_perf.h
create mode 100644 arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
create mode 100644 arch/powerpc/include/uapi/asm/trace_book3s.h
delete mode 100644 arch/powerpc/kvm/trace_book3s.h
diff --git a/arch/powerpc/include/uapi/asm/kvm_perf.h
b/arch/powerpc/include/uapi/asm/kvm_perf.h
new file mode 100644
index 000..5ed2ff3
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_POWERPC_KVM_PERF_H
+#define _ASM_POWERPC_KVM_PERF_H
+
+#include
+
+#endif
diff --git a/arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
b/arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
new file mode 100644
index 000..735901f
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
@@ -0,0 +1,15 @@
+#ifndef _ASM_POWERPC_KVM_PERF_BOOK3S_H
+#define _ASM_POWERPC_KVM_PERF_BOOK3S_H
+
+#include
+#include
+
+#define DECODE_STR_LEN 20
+
+#define VCPU_ID "vcpu_id"
+
+#define KVM_ENTRY_TRACE "kvm_hv:kvm_guest_enter"
+#define KVM_EXIT_TRACE "kvm_hv:kvm_guest_exit"
+#define KVM_EXIT_REASON "trap"
+
+#endif /* _ASM_POWERPC_KVM_PERF_BOOK3S_H */
diff --git a/arch/powerpc/include/uapi/asm/trace_book3s.h
b/arch/powerpc/include/uapi/asm/trace_book3s.h
new file mode 100644
index 000..f647ce0
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/trace_book3s.h
@@ -0,0 +1,32 @@
+#if !defined(_TRACE_KVM_BOOK3S_H)
+#define _TRACE_KVM_BOOK3S_H
+
+/*
+ * Common defines used by the trace macros in trace_pr.h and trace_hv.h
+ */
+
+#define kvm_trace_symbol_exit \
+ {0x100, "SYSTEM_RESET"}, \
+ {0x200, "MACHINE_CHECK"}, \
+ {0x300, "DATA_STORAGE"}, \
+ {0x380, "DATA_SEGMENT"}, \
+ {0x400, "INST_STORAGE"}, \
+ {0x480, "INST_SEGMENT"}, \
+ {0x500, "EXTERNAL"}, \
+ {0x501, "EXTERNAL_LEVEL"}, \
+ {0x502, "EXTERNAL_HV"}, \
+ {0x600, "ALIGNMENT"}, \
+ {0x700, "PROGRAM"}, \
+ {0x800, "FP_UNAVAIL"}, \
+ {0x900, "DECREMENTER"}, \
+ {0x980, "HV_DECREMENTER"}, \
+ {0xc00, "SYSCALL"}, \
+ {0xd00, "TRACE"}, \
+ {0xe00, "H_DATA_STORAGE"}, \
+ {0xe20, "H_INST_STORAGE"}, \
+ {0xe40, "H_EMUL_ASSIST"}, \
+ {0xf00, "PERFMON"}, \
+ {0xf20, "ALTIVEC"}, \
+ {0xf40, "VSX"}
+
+#endif
diff --git a/arch/powerpc/kvm/trace_book3s.h b/arch/powerpc/kvm/trace_book3s.h
deleted file mode 100644
index f647ce0..000
--- a/arch/powerpc/kvm/trace_book3s.h
+++ /dev/null
@@ -1,32 +0,0 @@
-#if !defined(_TRACE_KVM_BOOK3S_H)
-#define _TRACE_KVM_BOOK3S_H
-
-/*
- * Common defines used by the trace macros in trace_pr.h and trace_hv.h
- */
-
-#define kvm_trace_symbol_exit \
- {0x100, "SYSTEM_RESET"}, \
- {0x200, "MACHINE_CHECK"}, \
- {0x300, "DATA_STORAGE"}, \
- {0x380, "DATA_SEGMENT"}, \
- {0x400, "INST_STORAGE"}, \
- {0x480, "INST_SEGMENT"}, \
- {0x500, "EXTERNAL"}, \
- {0x501, "EXTERNAL_LEVEL"}, \
- {0x502, "EXTERNAL_HV"}, \
- {0x600, "ALIGNMENT"}, \
- {0x700, "PROGRAM"}, \
- {0x800, "FP_UNAVAIL"}, \
- {0x900, "DECREMENTER"}, \
- {0x980, "HV_DECREMENTER"}, \
- {0xc00, "SYSCALL"}, \
- {0xd00, "TRACE"}, \
- {0xe00, "H_DATA_STORAGE"}, \
- {0xe20, "H_INST_STORAGE"}, \
- {0xe40, "H_EMUL_ASSIST"}, \
- {0xf00, "PERFMON"}, \
- {0xf20, "ALTIVEC"}, \
- {0xf40, "VSX"}
-
-#endif
diff --git a/arch/powerpc/kvm/trace_hv.h b/arch/powerpc/kvm/trace_hv.h
index 33d9daf..02d0a07 100644
--- a/arch/powerpc/kvm/trace_hv.h
+++ b/arch/powerpc/kvm/trace_hv.h
@@ -2,7 +2,7 @@
#define _TRACE_KVM_HV_H
[PATCH] pinctrl: samsung: Remove old unused defines
Since 9a2c1c3b91aa ("pinctrl: samsung: Allow grouping multiple
pinmux/pinconf nodes") the defines for GPIO group and function names are
not used anywhere in the driver.
Signed-off-by: Krzysztof Kozlowski
Inspired-by: Dan Carpenter
---
drivers/pinctrl/samsung/pinctrl-samsung.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c
b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 3dd5a3b2ac62..c760bf43d116 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -33,11 +33,6 @@
#include "../core.h"
#include "pinctrl-samsung.h"
-#define GROUP_SUFFIX "-grp"
-#define GSUFFIX_LENsizeof(GROUP_SUFFIX)
-#define FUNCTION_SUFFIX"-mux"
-#define FSUFFIX_LENsizeof(FUNCTION_SUFFIX)
-
/* list of all possible config options supported */
static struct pin_config {
const char *property;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [Patch V2 2/3] usb: Introduce Xen pvUSB frontend
On 06/12/2015 06:20 PM, Greg KH wrote:
On Fri, Jun 12, 2015 at 04:10:00PM +0200, Juergen Gross wrote:
Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a driver domain
(usually Dom0) which is owner of the physical device.
The code is taken from the pvUSB implementation in Xen done by Fujitsu
based on Linux kernel 2.6.18.
Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- minor code modifications to increase readability
Signed-off-by: Juergen Gross
---
drivers/usb/Kconfig|2 +
drivers/usb/Makefile |2 +
drivers/usb/xen/Kconfig| 10 +
drivers/usb/xen/Makefile |5 +
drivers/usb/xen/xen-usbfront.c | 1647
A subdirectory for a single file? That seems like overkill, don't you
think? As this is a USB "host" driver, why not put it in that
directory?
As already suggested by David: I'll change this.
Also, last time these patches were posted, people asked why you can't
use libusb/usbfs instead, what happened with that? Or usbip?
Like David already said: this was the backend, which I'm currently
working on to be part of qemu using libusb.
+config XEN_USB_FRONTEND
+ tristate "Xen USB frontend driver"
+ depends on XEN
+ default m
Remove this, default should be 'n'.
Really? Don't you think default should be to use USB devices in Xen
guests? Kernels configured not to be able to run as Xen guests with
pv drivers won't have that module due to "depends on XEN".
+/* status of attached device */
+struct vdevice_status {
+ int devnum;
+ enum usb_device_state status;
+enum usb_device_speed speed;
+};
Always run your patches through checkpatch.pl so people don't tell you
about the things that checkpatch.pl would have told you about...
I did (I'll change the indentation, of course):
./scripts/checkpatch.pl
jg/out.pvusb.v2/0002-usb-Introduce-Xen-pvUSB-frontend.patch
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#57:
new file mode 100644
total: 0 errors, 1 warnings, 1675 lines checked
jg/out.pvusb.v2/0002-usb-Introduce-Xen-pvUSB-frontend.patch has style
problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ext4: mballoc: avoid 20-argument function call
On Thu, Jun 11, 2015 at 12:28:02AM +0200, Rasmus Villemoes wrote: > Making a function call with 20 arguments is rather expensive in both > stack and .text. In this case, doing the formatting manually doesn't > make it any less readable, so we might as well save 155 bytes of .text > and 112 bytes of stack. > > Signed-off-by: Rasmus Villemoes Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
Ping. Regards, Punnaiah On Mon, Jun 8, 2015 at 11:38 PM, Punnaiah Choudary Kalluri wrote: > Add driver for arm pl353 static memory controller nand interface with > HW ECC support. This controller is used in xilinx zynq soc for interfacing > the nand flash memory. > > Signed-off-by: Punnaiah Choudary Kalluri > --- > Changes in v7: > - Currently not implemented the memclk rate adjustments. I will >look into this later and once the basic driver is accepted. > - Fixed GPL licence ident > Changes in v6: > - Fixed the checkpatch.pl reported warnings > - Using the address cycles information from the onfi param page >earlier it is hardcoded to 5 in driver > Changes in v5: > - Configure the nand timing parameters as per the onfi spec > Changes in v4: > - Updated the driver to sync with pl353_smc driver APIs > Changes in v3: > - implemented the proper error codes > - further breakdown this patch to multiple sets > - added the controller and driver details to Documentation section > - updated the licenece to GPLv2 > - reorganized the pl353_nand_ecc_init function > Changes in v2: > - use "depends on" rather than "select" option in kconfig > - remove unused variable parts > - remove dummy helper and use writel_relaxed directly > --- > drivers/mtd/nand/Kconfig |7 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/pl353_nand.c | 909 > + > 3 files changed, 917 insertions(+), 0 deletions(-) > create mode 100644 drivers/mtd/nand/pl353_nand.c > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 5897d8d..c14a955 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -497,6 +497,13 @@ config MTD_NAND_NUC900 > This enables the driver for the NAND Flash on evaluation board based > on w90p910 / NUC9xx. > > +config MTD_NAND_PL353 > + tristate "ARM Pl353 NAND flash driver" > + depends on MTD_NAND && ARM > + depends on PL353_SMC > + help > + This enables access to the NAND flash device on PL353 SMC > controller. > + > config MTD_NAND_JZ4740 > tristate "Support for JZ4740 SoC NAND controller" > depends on MACH_JZ4740 > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index 582bbd05..c68fd7c 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o > obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ > obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o > obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o > +obj-$(CONFIG_MTD_NAND_PL353) += pl353_nand.o > > nand-objs := nand_base.o nand_bbt.o nand_timings.o > diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c > new file mode 100644 > index 000..ff6cf3e > --- /dev/null > +++ b/drivers/mtd/nand/pl353_nand.c > @@ -0,0 +1,909 @@ > +/* > + * ARM PL353 NAND Flash Controller Driver > + * > + * Copyright (C) 2009 - 2014 Xilinx, Inc. > + * > + * This driver is based on plat_nand.c and mxc_nand.c drivers > + * > + * This program is free software; you can redistribute it and/or modify it > under > + * the terms of the GNU General Public License version 2 as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PL353_NAND_DRIVER_NAME "pl353-nand" > + > +/* NAND flash driver defines */ > +#define PL353_NAND_CMD_PHASE 1 /* End command valid in command phase > */ > +#define PL353_NAND_DATA_PHASE 2 /* End command valid in data phase */ > +#define PL353_NAND_ECC_SIZE512 /* Size of data for ECC operation */ > + > +/* Flash memory controller operating parameters */ > + > +#define PL353_NAND_ECC_CONFIG (BIT(4) | /* ECC read at end of page */ > \ > +(0 << 5)) /* No Jumping */ > + > +/* AXI Address definitions */ > +#define START_CMD_SHIFT3 > +#define END_CMD_SHIFT 11 > +#define END_CMD_VALID_SHIFT20 > +#define ADDR_CYCLES_SHIFT 21 > +#define CLEAR_CS_SHIFT 21 > +#define ECC_LAST_SHIFT 10 > +#define COMMAND_PHASE (0 << 19) > +#define DATA_PHASE BIT(19) > + > +#define PL353_NAND_ECC_LASTBIT(ECC_LAST_SHIFT) /* Set ECC_Last */ > +#define PL353_NAND_CLEAR_CSBIT(CLEAR_CS_SHIFT) /* Clear chip select > */ > + > +#define ONDIE_ECC_FEATURE_ADDR 0x90 > +#define PL353_NAND_ECC_BUSY_TIMEOUT(1 * HZ) > +#define PL353_NAND_DEV_BUSY_TIMEOUT(1 * HZ) > +#define PL353_NAND_LAST_TRANSFER_LENGTH4 > + > +/** > + * struct pl353_nand_command_format -
Re: [PATCH v7 2/2] memory: pl353: Add driver for arm pl353 static memory controller
Ping. Regards, Punnaiah On Mon, Jun 8, 2015 at 11:37 PM, Punnaiah Choudary Kalluri wrote: > Add driver for arm pl353 static memory controller. This controller is > used in xilinx zynq soc for interfacing the nand and nor/sram memory > devices. > > Signed-off-by: Punnaiah Choudary Kalluri > --- > Changes in v7: > - Corrected the kconfig to use tristate selection > - Corrected the GPL licence ident > - Added boundary checks for nand timing parameters > Changes in v6: > - Fixed checkpatch.pl reported warnings > Changes in v5: > - Added pl353_smc_get_clkrate function, made pl353_smc_set_cycles as public > API > - Removed nand timing parameter initialization and moved it to nand driver > Changes in v4: > - Modified driver to support multiple instances > - Used sleep instaed of busywait for delay > Changes in v3: > - None > Changes in v2: > - Since now the timing parameters are in nano seconds, added logic to convert > them to the cycles > --- > drivers/memory/Kconfig |7 + > drivers/memory/Makefile |1 + > drivers/memory/pl353-smc.c | 559 > ++ > include/linux/memory/pl353-smc.h | 37 +++ > 4 files changed, 604 insertions(+), 0 deletions(-) > create mode 100644 drivers/memory/pl353-smc.c > create mode 100644 include/linux/memory/pl353-smc.h > > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig > index 868036f..b855cc5 100644 > --- a/drivers/memory/Kconfig > +++ b/drivers/memory/Kconfig > @@ -92,6 +92,13 @@ config JZ4780_NEMC > the Ingenic JZ4780. This controller is used to handle external > memory devices such as NAND and SRAM. > > +config PL353_SMC > + tristate "ARM PL353 Static Memory Controller (SMC) driver" > + depends on ARM > + help > + This driver is for the ARM PL353 Static Memory Controller (SMC) > + module. > + > source "drivers/memory/tegra/Kconfig" > > endif > diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile > index b670441..d943700 100644 > --- a/drivers/memory/Makefile > +++ b/drivers/memory/Makefile > @@ -14,5 +14,6 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o > obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o > obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o > obj-$(CONFIG_JZ4780_NEMC) += jz4780-nemc.o > +obj-$(CONFIG_PL353_SMC)+= pl353-smc.o > > obj-$(CONFIG_TEGRA_MC) += tegra/ > diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c > new file mode 100644 > index 000..9cd6e56 > --- /dev/null > +++ b/drivers/memory/pl353-smc.c > @@ -0,0 +1,559 @@ > +/* > + * ARM PL353 SMC Driver > + * > + * Copyright (C) 2012 - 2015 Xilinx, Inc. > + * > + * This program is free software: you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation, either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * Currently only a single SMC instance is supported. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Register definitions */ > +#define PL353_SMC_MEMC_STATUS_OFFS 0 /* Controller status reg, RO > */ > +#define PL353_SMC_CFG_CLR_OFFS 0xC /* Clear config reg, WO */ > +#define PL353_SMC_DIRECT_CMD_OFFS 0x10/* Direct command reg, WO */ > +#define PL353_SMC_SET_CYCLES_OFFS 0x14/* Set cycles register, WO */ > +#define PL353_SMC_SET_OPMODE_OFFS 0x18/* Set opmode register, WO */ > +#define PL353_SMC_ECC_STATUS_OFFS 0x400 /* ECC status register */ > +#define PL353_SMC_ECC_MEMCFG_OFFS 0x404 /* ECC mem config reg */ > +#define PL353_SMC_ECC_MEMCMD1_OFFS 0x408 /* ECC mem cmd1 reg */ > +#define PL353_SMC_ECC_MEMCMD2_OFFS 0x40C /* ECC mem cmd2 reg */ > +#define PL353_SMC_ECC_VALUE0_OFFS 0x418 /* ECC value 0 reg */ > + > +/* Controller status register specific constants */ > +#define PL353_SMC_MEMC_STATUS_RAW_INT_1_SHIFT 6 > + > +/* Clear configuration register specific constants */ > +#define PL353_SMC_CFG_CLR_INT_CLR_10x10 > +#define PL353_SMC_CFG_CLR_ECC_INT_DIS_10x40 > +#define PL353_SMC_CFG_CLR_INT_DIS_10x2 > +#define PL353_SMC_CFG_CLR_DEFAULT_MASK (PL353_SMC_CFG_CLR_INT_CLR_1 | \ > +PL353_SMC_CFG_CLR_ECC_INT_DIS_1 | \ > +PL353_SMC_CFG_CLR_INT_DIS_1) > + > +/* Set cycles register specific constants */ > +#define PL353_SMC_SET_CYCLES_T0_MASK 0xF > +#define PL353_SMC_SET_CYCLES_T0_SHIFT 0 > +#define PL353_SMC_SET_CYCLES_T1_MASK 0xF > +#define
Re: [PATCH v3 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
Ping. Regards, Punnaiah On Fri, May 22, 2015 at 11:49 PM, Punnaiah Choudary Kalluri wrote: > Added the basic driver for Arasan Nand Flash Controller used in > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit > correction. > > Signed-off-by: Punnaiah Choudary Kalluri > --- > Chnages in v3: > - Removed unused variables > - Avoided busy loop and used jifies based implementation > - Fixed compiler warnings "right shift count >= width of type" > - Removed unneeded codei and improved error reporting > - Added onfi version check to ensure reading the valid address cycles > Changes in v2: > - Added missing of.h to avoid kbuild system report error > --- > drivers/mtd/nand/Kconfig |7 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/arasan_nfc.c | 873 > + > 3 files changed, 881 insertions(+), 0 deletions(-) > create mode 100644 drivers/mtd/nand/arasan_nfc.c > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 5897d8d..64e497c 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -530,4 +530,11 @@ config MTD_NAND_HISI504 > help > Enables support for NAND controller on Hisilicon SoC Hip04. > > +config MTD_NAND_ARASAN > + tristate "Support for Arasan Nand Flash controller" > + depends on MTD_NAND > + help > + Enables the driver for the Arasan Nand Flash controller on > + Zynq UltraScale+ MPSoC. > + > endif # MTD_NAND > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index 582bbd05..fd863ea 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o > obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ > obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o > obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o > > nand-objs := nand_base.o nand_bbt.o nand_timings.o > diff --git a/drivers/mtd/nand/arasan_nfc.c b/drivers/mtd/nand/arasan_nfc.c > new file mode 100644 > index 000..fbf543c > --- /dev/null > +++ b/drivers/mtd/nand/arasan_nfc.c > @@ -0,0 +1,873 @@ > +/* > + * Arasan Nand Flash Controller Driver > + * > + * Copyright (C) 2014 - 2015 Xilinx, Inc. > + * > + * This program is free software; you can redistribute it and/or modify it > under > + * the terms of the GNU General Public License version 2 as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRIVER_NAME"arasan_nfc" > +#define EVNT_TIMEOUT 1000 > +#define STATUS_TIMEOUT 2000 > + > +#define PKT_OFST 0x00 > +#define MEM_ADDR1_OFST 0x04 > +#define MEM_ADDR2_OFST 0x08 > +#define CMD_OFST 0x0C > +#define PROG_OFST 0x10 > +#define INTR_STS_EN_OFST 0x14 > +#define INTR_SIG_EN_OFST 0x18 > +#define INTR_STS_OFST 0x1C > +#define READY_STS_OFST 0x20 > +#define DMA_ADDR1_OFST 0x24 > +#define FLASH_STS_OFST 0x28 > +#define DATA_PORT_OFST 0x30 > +#define ECC_OFST 0x34 > +#define ECC_ERR_CNT_OFST 0x38 > +#define ECC_SPR_CMD_OFST 0x3C > +#define ECC_ERR_CNT_1BIT_OFST 0x40 > +#define ECC_ERR_CNT_2BIT_OFST 0x44 > +#define DMA_ADDR0_OFST 0x50 > + > +#define PKT_CNT_SHIFT 12 > + > +#define ECC_ENABLE BIT(31) > +#define DMA_EN_MASKGENMASK(27, 26) > +#define DMA_ENABLE 0x2 > +#define DMA_EN_SHIFT 26 > +#define PAGE_SIZE_MASK GENMASK(25, 23) > +#define PAGE_SIZE_SHIFT23 > +#define PAGE_SIZE_512 0 > +#define PAGE_SIZE_1K 5 > +#define PAGE_SIZE_2K 1 > +#define PAGE_SIZE_4K 2 > +#define PAGE_SIZE_8K 3 > +#define PAGE_SIZE_16K 4 > +#define CMD2_SHIFT 8 > +#define ADDR_CYCLES_SHIFT 28 > + > +#define XFER_COMPLETE BIT(2) > +#define READ_READY BIT(1) > +#define WRITE_READYBIT(0) > +#define MBIT_ERROR BIT(3) > +#define ERR_INTRPT BIT(4) > + > +#define PROG_PGRD BIT(0) > +#define PROG_ERASE BIT(2) > +#define PROG_STATUSBIT(3) > +#define PROG_PGPROGBIT(4) > +#define PROG_RDID BIT(6) > +#define
Re: [PATCH 1/1 linux-next] ext4: use swap() in mext_page_double_lock()
On Fri, Jun 12, 2015 at 06:59:15PM +0200, Fabian Frederick wrote: > Use kernel.h macro definition. > > Thanks to Julia Lawall for Coccinelle scripting support. > > Signed-off-by: Fabian Frederick Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-next] ext4: use swap() in memswap()
On Fri, Jun 12, 2015 at 06:58:54PM +0200, Fabian Frederick wrote: > Use kernel.h macro definition. > > Thanks to Julia Lawall for Coccinelle scripting support. > > Signed-off-by: Fabian Frederick Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch V2 1/3] usb: Add Xen pvUSB protocol description
On 06/12/2015 06:23 PM, Greg KH wrote:
On Fri, Jun 12, 2015 at 04:09:59PM +0200, Juergen Gross wrote:
+enum usb_spec_version {
+ USB_VER_UNKNOWN = 0,
+ USB_VER_USB11,
+ USB_VER_USB20,
+ USB_VER_USB30, /* not supported yet */
+};
+
You are defining a bunch of things in this .h file that start with
"usb" yet are not part of the USB core at all, but rather are xen
specific. Please don't polute the namespace with such things.
Okay.
+/*
+ * USB pipe in usbif_request
+ *
+ * - port number: bits 0-4
+ * (USB_MAXCHILDREN is 31)
+ *
+ * - operation flag: bit 5
+ * (0 = submit urb,
+ * 1 = unlink urb)
+ *
+ * - direction: bit 7
+ * (0 = Host-to-Device [Out]
+ * 1 = Device-to-Host [In])
+ *
+ * - device address: bits 8-14
+ *
+ * - endpoint:bits 15-18
+ *
+ * - pipe type: bits 30-31
+ * (00 = isochronous, 01 = interrupt,
+ * 10 = control, 11 = bulk)
+ */
+
+#define USBIF_PIPE_PORT_MASK 0x001f
+#define USBIF_PIPE_UNLINK 0x0020
+#define USBIF_PIPE_DIR 0x0080
+#define USBIF_PIPE_DEV_MASK0x007f
+#define USBIF_PIPE_DEV_SHIFT 8
+#define USBIF_PIPE_EP_MASK 0x000f
+#define USBIF_PIPE_EP_SHIFT15
+#define USBIF_PIPE_TYPE_MASK 0x0003
+#define USBIF_PIPE_TYPE_SHIFT 30
+#define USBIF_PIPE_TYPE_ISOC 0
+#define USBIF_PIPE_TYPE_INT1
+#define USBIF_PIPE_TYPE_CTRL 2
+#define USBIF_PIPE_TYPE_BULK 3
Why can't you just use the defines we have for this already?
This interface is a stable ABI to be used outside of Linux by other
Xen guests as well. As long as those Linux internal definitions are
not guaranteed to remain unchanged forever, I'd rather have my own
defines.
+
+#define usbif_pipeportnum(pipe)((pipe) &
USBIF_PIPE_PORT_MASK)
+#define usbif_setportnum_pipe(pipe, portnum) ((pipe) | (portnum))
+
+#define usbif_pipeunlink(pipe) ((pipe) & USBIF_PIPE_UNLINK)
+#define usbif_pipesubmit(pipe) (!usbif_pipeunlink(pipe))
+#define usbif_setunlink_pipe(pipe) ((pipe) | USBIF_PIPE_UNLINK)
+
+#define usbif_pipein(pipe) ((pipe) & USBIF_PIPE_DIR)
+#define usbif_pipeout(pipe)(!usbif_pipein(pipe))
+
+#define usbif_pipedevice(pipe) \
+ (((pipe) >> USBIF_PIPE_DEV_SHIFT) & USBIF_PIPE_DEV_MASK)
+
+#define usbif_pipeendpoint(pipe) \
+ (((pipe) >> USBIF_PIPE_EP_SHIFT) & USBIF_PIPE_EP_MASK)
+
+#define usbif_pipetype(pipe) \
+ (((pipe) >> USBIF_PIPE_TYPE_SHIFT) & USBIF_PIPE_TYPE_MASK)
+#define usbif_pipeisoc(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_ISOC)
+#define usbif_pipeint(pipe)(usbif_pipetype(pipe) == USBIF_PIPE_TYPE_INT)
+#define usbif_pipectrl(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_CTRL)
+#define usbif_pipebulk(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_BULK)
Same for all of these?
Correct. :-)
+
+#define USBIF_MAX_SEGMENTS_PER_REQUEST (16)
+#define USBIF_MAX_PORTNR 31
Why does userspace have to know this?
Not userspace, but Xen guests. The number of segments per request and
the maximum port number are part of the interface between frontend and
backend, so they are defined here.
+
+/*
+ * RING for transferring urbs.
+ */
+struct usbif_request_segment {
+ grant_ref_t gref;
+ uint16_t offset;
+ uint16_t length;
+};
Please use proper kernel types for things that go outside of the kernel
(__u16 and the like). There is no "uint16_t" as a valid type in the
kernel, sorry. Well, ok, we have it, just because it snuck in somehow,
but it should be removed one of these days...
Okay.
+struct usbif_urb_request {
Again, very generic structure name for a xen specific thing :(
I'll change all names to use "xenusb_" instead of "usbif_" as prefix.
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
On 15.06.2015 11:13, Anand Moon wrote:
> hi Krzysztof
>
> On 15 June 2015 at 05:21, Krzysztof Kozlowski wrote:
>> On 14.06.2015 19:24, Anand Moon wrote:
>>> This changes enables TMU IP block on the Exynos5422 Odroid-XU3
>>> device.
>>>
>>> Signed-off-by: Anand Moon
>>> Tested-by: Markus Reichl
>>> Acked-by: Lukasz Majewski
>>> ---
>>> Changes rebase on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
>>> for-next
>>> Changes from v5: Use LDO7 regulator instead of LD010.
>>>
>>> The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
>>>
>>> I think the schematics are missing some of details but it can be deducted
>>> that:
>>> 1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
>>> pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
>>> 2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
>>> S2MPS11 PMIC.
>>> 3. I confirmed with the Exynos5422 datasheet that these
>>> VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
>>>
>>> So the LDO7 it is... but before using it there is a caveat. The LDO7
>>> is also connected to VDD of MIPI, HDMI and few more. So when you use
>>> this regulator in TMU it may be turned off by TMU driver (e.g. during
>>> unbind). In such case these other blocks also should be tested and
>>> checked whether they take this regulator and enable it.
>>
>> Why did you took my email and pasted it here?
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/343702.html
>>
>> It is written now in first person so it pretends that you wrote this.
>> You are actually doing this for second time - taking my
>> reply and putting into commit message or changelog. Why?
>>
>> And where is proper changelog?
>>
>
> Sorry: My intention was never to take credit on what your guidance and
> your pointers.
> I value ever input of your and try not to repeat the mistakes I am repeating.
> I will send updated version soon.
If you want to quote me, then it's fine. But please indicate that this
is a quote.
Thanks for resending. Later I'll give the patchset a try on my XU3-Lite.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kexec_load(2) bypasses signature verification
>From experimentation and from looking at the sources, it appears that the signature checking is only done in the kexec_file_load(2) system all, and not in the kexec_load(2) system call. And I understand why -- the signature is not sent from userspace to the kernel in the older kexec_load(2) system call. The problem is that if you use an old version of kexec, it will use the old kexec_load(2) system call, and even though CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an unsigned kernel, and then "kexec -e" will happily boot into it. Correct me if I am wrong, but this appears to be a hole in Secure Boot you could drive a Mack Truck through. (I noticed this because Debian is still using a kexec-tools from the stone ages, version 2.0.7, and I was wondering **why** I was able to kexec boot completely unsigned kernels.) It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the old kexec_load(2) system call should be disabled (and a warning be placed in the Kconfig help that the user should have at least verision 2.X of kexec-tools if they enable this kernel option). Am I missing something? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: orion5x: Use vsprintf %pM extension
On Sun, Jun 14, 2015 at 07:01:30PM -0700, Joe Perches wrote:
> Format mac addresses with the normal kernel extension.
>
> Signed-off-by: Joe Perches
Acked-by: Andrew Lunn
Andrew
> ---
> arch/arm/mach-orion5x/dns323-setup.c | 4 +---
> arch/arm/mach-orion5x/tsx09-common.c | 4 +---
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-orion5x/dns323-setup.c
> b/arch/arm/mach-orion5x/dns323-setup.c
> index 09d2a26..f267e58 100644
> --- a/arch/arm/mach-orion5x/dns323-setup.c
> +++ b/arch/arm/mach-orion5x/dns323-setup.c
> @@ -236,9 +236,7 @@ static int __init dns323_read_mac_addr(void)
> }
>
> iounmap(mac_page);
> - printk("DNS-323: Found ethernet MAC address: ");
> - for (i = 0; i < 6; i++)
> - printk("%.2x%s", addr[i], (i < 5) ? ":" : ".\n");
> + printk("DNS-323: Found ethernet MAC address: %pM\n", addr);
>
> memcpy(dns323_eth_data.mac_addr, addr, 6);
>
> diff --git a/arch/arm/mach-orion5x/tsx09-common.c
> b/arch/arm/mach-orion5x/tsx09-common.c
> index 7189827..24b2959 100644
> --- a/arch/arm/mach-orion5x/tsx09-common.c
> +++ b/arch/arm/mach-orion5x/tsx09-common.c
> @@ -101,9 +101,7 @@ static int __init qnap_tsx09_check_mac_addr(const char
> *addr_str)
> addr[i] = byte;
> }
>
> - printk(KERN_INFO "tsx09: found ethernet mac address ");
> - for (i = 0; i < 6; i++)
> - printk("%.2x%s", addr[i], (i < 5) ? ":" : ".\n");
> + printk(KERN_INFO "tsx09: found ethernet mac address %pM\n", addr);
>
> memcpy(qnap_tsx09_eth_data.mac_addr, addr, 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] Staging: sm750fb: fix checkpatch.pl indentation warnings
On Sun, Jun 14, 2015 at 08:45:02PM +0200, Markus Böhme wrote: > >This patch fixes indentation issues by replacing spaces by tabs at > >the start of line > > > >Signed-off-by: Niranjan Dighe > > > >diff --git a/drivers/staging/sm750fb/ddk750_dvi.c > >b/drivers/staging/sm750fb/ddk750_dvi.c > >index b2bf7e6..c73b74a 100644 > >--- a/drivers/staging/sm750fb/ddk750_dvi.c > >+++ b/drivers/staging/sm750fb/ddk750_dvi.c > > >-if(pCurrentDviCtrl->pfnInit != NULL) > >+if (pCurrentDviCtrl->pfnInit != NULL) > > You are fixing a different type of warning here. Please make only one > kind of change per patch. > > Regards, > Markus > Hello Markus, Thanks for your review. I will correct and resend a new patch. Please disregard this for the moment. Thanks, Niranjan Dighe-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched/deadline: remove needless parameter in dl_runtime_exceeded()
Sine commit 269ad80(sched/deadline: Avoid double-accounting in
case of missed deadlines), parameter rq is no longer used, so
remove it.
Signed-off-by: Zhiqiang Zhang
---
kernel/sched/deadline.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 5e95145..437ecdc 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -640,7 +640,7 @@ void init_dl_task_timer(struct sched_dl_entity *dl_se)
}
static
-int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity *dl_se)
+int dl_runtime_exceeded(struct sched_dl_entity *dl_se)
{
return (dl_se->runtime <= 0);
}
@@ -684,7 +684,7 @@ static void update_curr_dl(struct rq *rq)
sched_rt_avg_update(rq, delta_exec);
dl_se->runtime -= dl_se->dl_yielded ? 0 : delta_exec;
- if (dl_runtime_exceeded(rq, dl_se)) {
+ if (dl_runtime_exceeded(dl_se)) {
dl_se->dl_throttled = 1;
__dequeue_task_dl(rq, curr, 0);
if (unlikely(!start_dl_timer(dl_se, curr->dl.dl_boosted)))
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] arm64/hw_breakpoint.c: remove unnecessary header
Header is not needed for arm64, removing the same. Signed-off-by: Maninder Singh Reviewed-by: Vaneet Narang --- arch/arm64/kernel/hw_breakpoint.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c index e7d934d..7a1a5da 100644 --- a/arch/arm64/kernel/hw_breakpoint.c +++ b/arch/arm64/kernel/hw_breakpoint.c @@ -31,7 +31,6 @@ #include #include #include -#include #include #include #include -- 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/
[PATCH 1/1] arm/hw_breakpoint.c: remove unnecessary header
Header is not needed for arm, removing the same. Signed-off-by: Maninder Singh Reviewed-by: Vaneet Narang --- arch/arm/kernel/hw_breakpoint.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c index dc7d0a9..6284779 100644 --- a/arch/arm/kernel/hw_breakpoint.c +++ b/arch/arm/kernel/hw_breakpoint.c @@ -35,7 +35,6 @@ #include #include #include -#include #include /* Breakpoint currently in use for each BRP. */ -- 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: [Patch 0/2] Add mt6580 basic chip support
Hi all May I know if I miss anything to let this patch be reviewed? I will do my best to fix the problems. Thanks a lot. On Wed, 2015-06-03 at 16:18 +0800, Mars Cheng wrote: > This series add support to mediatek's new SoC, mt6580, a 4-core CA7. > Only basic I/O, including interrupt, timer & uart. > > Mars Cheng (2): > Document: DT: Add bindings for mediatek MT6580 SoC Platform > ARM: dts: mediatek: add mt6580 basic support > > Documentation/devicetree/bindings/arm/mediatek.txt | 4 + > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/mt6580-evbp1.dts | 34 ++ > arch/arm/boot/dts/mt6580.dtsi | 130 > + > 4 files changed, 169 insertions(+) > create mode 100644 arch/arm/boot/dts/mt6580-evbp1.dts > create mode 100644 arch/arm/boot/dts/mt6580.dtsi > > -- > 1.8.1.1.dirty > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm:arm64/hw_breakpoint.c: Remove unnecessary header
>On Thu, Jun 11, 2015 at 04:29:43PM +0100, Will Deacon wrote: >> On Thu, Jun 11, 2015 at 11:39:58AM +0100, Maninder Singh wrote: >> > Header is not needed in hw_breakpoint.c >> > for arm as well as arm64. >> > Removing the same. >> > >> > Signed-off-by: Maninder Singh >> > Reviewed-by: Vaneet Narang >> > --- >> > arch/arm/kernel/hw_breakpoint.c |1 - >> > arch/arm64/kernel/hw_breakpoint.c |1 - >> > 2 files changed, 0 insertions(+), 2 deletions(-) >> >> Sorry for the bother, but can you send this as two separate patches please? >> They'll need to go via two different trees to get into mainline. > >Or just send it to kernel-janit...@vger.kernel.org. > >-- >Catalin Sure, I am sending two separate patches. Thanks
RE: [PATCH 2/7] input: cyapa: add gen6 device module support in driver
Jeremiah,
Thanks for the review.
I will correct all the spelling errors you helped pointed out, and I will
double check the spell, space and black line issues again.
Thanks,
Dudley
> -Original Message-
> From: Jeremiah Mahler [mailto:jmmah...@gmail.com]
> Sent: 2015?6?13? 14:57
> To: Dudley Du
> Cc: dmitry.torok...@gmail.com; mark.rutl...@arm.com; robh...@kernel.org;
> rydb...@euromail.se; ble...@google.com; devicet...@vger.kernel.org;
> linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/7] input: cyapa: add gen6 device module support in
> driver
>
> Dudley,
>
> A few more spelling errors...
>
> On Fri, Jun 12, 2015 at 02:56:33PM +0800, Dudley Du wrote:
> > Based on the cyapa core, add the gen6 trackpad device's basic functions
> > supported, so gen6 trackpad device can work with kernel input system.
> > And also based on the state parse interface, the cyapa driver can
> > automatically determine the attached is gen3, gen5 or gen6 protocol
> > trackpad device, then set the correct protocol to work with the attached
> > trackpad device.
> > TEST=test on Chromebook.
> >
> > Signed-off-by: Dudley Du
> > ---
> > drivers/input/mouse/Makefile | 2 +-
> > drivers/input/mouse/cyapa.c | 22 ++
> > drivers/input/mouse/cyapa.h | 15 +
> > drivers/input/mouse/cyapa_gen5.c | 69 +++-
> > drivers/input/mouse/cyapa_gen6.c | 729
> +++
> [...]
> > +static int cyapa_get_pip_fixed_info(struct cyapa *cyapa,
> > +struct pip_fixed_info *pip_info, bool is_bootloader)
> > +{
> > +u8 resp_data[PIP_READ_SYS_INFO_RESP_LENGTH];
> > +int resp_len;
> > +u16 product_family;
> > +int error;
> > +
> > +if (is_bootloader) {
> > +/* Read Bootlaoder Inforamtion to determine Gen5 or Gen6. */
>sp: ^^^
>
> > +resp_len = sizeof(resp_data);
> > +error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
> > +pip_get_bl_info, sizeof(pip_get_bl_info),
> > +resp_data, _len,
> > +2000, cyapa_sort_tsg_pip_bl_resp_data,
> > +false);
> [...]
> > +
> > +product_family = get_unaligned_le16(_data[7]);
> > +if ((product_family & PIP_PRODUCT_FAMILY_MASK) !=
> > +PIP_PRODUCT_FAMILY_TRACKPAD)
> > +return -EINVAL;
> > +
> > +pip_info->family_id = resp_data[19];
> > +pip_info->silicon_id_low = resp_data[21];
> > +pip_info->silicon_id_high = resp_data[22];
> > +
> > +return 0;
> > +
> > +}
> Why the extra blank line?
>
> > +
> > +int cyapa_pip_state_parse(struct cyapa *cyapa, u8 *reg_data, int len)
> > +{
> > +u8 cmd[] = { 0x01, 0x00};
> > +struct pip_fixed_info pip_info;
> > +u8 resp_data[PIP_HID_DESCRIPTOR_SIZE];
> > +int resp_len;
> > +bool is_bootloader;
> > +int error;
> > +
> > +cyapa->state = CYAPA_STATE_NO_DEVICE;
> > +
> > +/* Try to wake from it deep sleep state if it is. */
> > +cyapa_pip_deep_sleep(cyapa, PIP_DEEP_SLEEP_STATE_ON);
> > +
> > +/* Empty the buffer queue to get fresh data with later commands. */
> > +cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
> [...]
> > +static ssize_t cyapa_gen6_show_baseline(struct device *dev,
> > +struct device_attribute *attr, char *buf)
> > +{
> > +struct cyapa *cyapa = dev_get_drvdata(dev);
> > +u8 data[GEN6_MAX_RX_NUM];
> > +int data_len;
> > +int size = 0;
> > +int i;
> > +int error;
> > +int resume_error;
> > +
> > +if (!cyapa_is_pip_app_mode(cyapa))
> > +return -EBUSY;
> > +
> > +/* 1. Suspend Scanning*/
> space? ^^^
>
> > +error = cyapa_pip_suspend_scanning(cyapa);
> > +if (error)
> > +return error;
> > +
> > +/* 2. IDAC and RX Attenuator Calibration Data (Center Frequency). */
> > +data_len = sizeof(data);
> > +error = cyapa_pip_reterive_data_structure(cyapa, 0, data_len,
> > +GEN6_RETERIVE_DATA_ID_RX_ATTENURATOR_IDAC,
> > +data, _len);
> > +if (error)
> > +goto resume_scanning;
> > +
> > +size = scnprintf(buf, PAGE_SIZE, "%d %d %d %d %d %d ",
> > +data[0], /* RX Attenuator Mutal */
> > +data[1], /* IDAC Mutual */
> > +data[2], /* RX Attenuator Self RX */
> > +data[3], /* IDAC Self RX */
> > +data[4], /* RX Attenuator Self TX */
> > +data[5] /* IDAC Self TX */
> > +);
> > +
> > +/* 3. Read Attenuator Trim. */
> > +data_len = sizeof(data);
> > +error = cyapa_pip_reterive_data_structure(cyapa, 0, data_len,
> > +GEN6_RETERIVE_DATA_ID_ATTENURATOR_TRIM,
> > +data, _len);
> > +if (error)
> > +goto resume_scanning;
> > +
> > +/* set attenuator trim values. */
> > +for (i = 0; i < data_len; i++)
> > +size += scnprintf(buf + size, PAGE_SIZE - size,"%d ", data[i]);
> > +size += scnprintf(buf + size, PAGE_SIZE - size, "\n");
> > +
> > +resume_scanning:
> > +/* 4. Resume Scanning*/
> space? ^^^
>
> > +resume_error = cyapa_pip_resume_scanning(cyapa);
> > +if (resume_error || error) {
> > +memset(buf, 0, PAGE_SIZE);
> > +return resume_error ? resume_error : error;
> > +}
> > +
> > +return size;
> > +}
> > +
> > +static int cyapa_gen6_operational_check(struct cyapa *cyapa)
> > +{
> > +struct device *dev = >client->dev;
> > +int error;
> > +
> > +if
[PATCH v3 1/1] usb: core: lpm: set lpm_capable for root hub device
Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.
Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.
This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate
a host supports Link PM.").
Cc: sta...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser
Signed-off-by: Lu Baolu
---
drivers/usb/core/hcd.c | 7 +--
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/usb.h | 1 +
3 files changed, 7 insertions(+), 3 deletions(-)
v1->v2 change log:
1. two code blocks merged
2. fix build error when CONFIG_PM is not set
v2->v3 change log:
1. further fix of build error when CONFIG_PM is not set
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..1c1385e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1022,9 +1022,12 @@ static int register_root_hub(struct usb_hcd *hcd)
dev_name(_dev->dev), retval);
return (retval < 0) ? retval : -EMSGSIZE;
}
- if (usb_dev->speed == USB_SPEED_SUPER) {
+
+ if (le16_to_cpu(usb_dev->descriptor.bcdUSB) >= 0x0201) {
retval = usb_get_bos_descriptor(usb_dev);
- if (retval < 0) {
+ if (!retval) {
+ usb_dev->lpm_capable = usb_device_supports_lpm(usb_dev);
+ } else if (usb_dev->speed == USB_SPEED_SUPER) {
mutex_unlock(_bus_list_lock);
dev_dbg(parent_dev, "can't read %s bos descriptor %d\n",
dev_name(_dev->dev), retval);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3b71516..884d702 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -122,7 +122,7 @@ struct usb_hub *usb_hub_to_struct_hub(struct usb_device
*hdev)
return usb_get_intfdata(hdev->actconfig->interface[0]);
}
-static int usb_device_supports_lpm(struct usb_device *udev)
+int usb_device_supports_lpm(struct usb_device *udev)
{
/* USB 2.1 (and greater) devices indicate LPM support through
* their USB 2.0 Extended Capabilities BOS descriptor.
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 7eb1e26..457255a 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -65,6 +65,7 @@ extern int usb_hub_init(void);
extern void usb_hub_cleanup(void);
extern int usb_major_init(void);
extern void usb_major_cleanup(void);
+extern int usb_device_supports_lpm(struct usb_device *udev);
#ifdef CONFIG_PM
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: why do we need vmalloc_sync_all?
On Sun, Jun 14, 2015 at 7:47 PM, Andi Kleen wrote: > Oleg Nesterov writes: >> >> But again, the kernel no longer does this? do_page_fault() does >> vmalloc_fault() >> without notify_die(). If it fails, I do not see how/why a modular DIE_OOPS >> handler could try to resolve this problem and trigger another fault. > > The same problem can happen from NMI handlers or machine check > handlers. It's not necessarily tied to page faults only. AIUI, the point of the one and only vmalloc_sync_all call is to prevent infinitely recursive faults when we call a notify_die callback. The only thing that it could realistically protect is module text or static non-per-cpu module data, since that's the only thing that's reliably already in the init pgd. I'm with Oleg: I don't see how that can happen, since do_page_fault fixes up vmalloc faults before it calls notify_die. --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/
[PATCHv7 3/4] ARM: dts: exynos5422-odroidxu3: Define default thermal-zones
Trip points corresponding to the one defined in the exynos_tmu_data.c
for Exynos5422 have been included so define thermal-zones attribute.
Signed-off-by: Anand Moon
Tested-by: Markus Reichl
Acked-by: Lukasz Majewski
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
new file mode 100644
index 000..2b289d7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -0,0 +1,59 @@
+/*
+ * Device tree sources for Exynos5422 thermal zone
+ *
+ * Copyright (c) 2015 Lukasz Majewski
+ * Anand Moon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+
+/ {
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+ thermal-sensors = <_cpu0 0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = <5>; /* millicelsius
*/
+ hysteresis = <5000>; /* millicelsius */
+ type = "active";
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = <6>; /* millicelsius
*/
+ hysteresis = <5000>; /* millicelsius */
+ type = "active";
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = <7>; /* millicelsius
*/
+ hysteresis = <5000>; /* millicelsius */
+ type = "active";
+ };
+ cpu_crit0: cpu-crit-0 {
+ temperature = <12>; /* millicelsius
*/
+ hysteresis = <0>; /* millicelsius */
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = <_alert0>;
+cooling-device = < 0 1>;
+ };
+ map1 {
+trip = <_alert1>;
+cooling-device = < 1 2>;
+ };
+ map2 {
+trip = <_alert2>;
+cooling-device = < 2 3>;
+ };
+ };
+ };
+ };
+};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv7 4/4] ARM: dts: exynos5422-odroidxu3: Enable thermal-zones
Include exynos5422-cpu-thermal.dtsi to enable thermal_zone support.
Signed-off-by: Anand Moon
Acked-by: Lukasz Majewski
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 96d894e..2b65932 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -15,6 +15,7 @@
#include
#include
#include "exynos5800.dtsi"
+#include "exynos5422-cpu-thermal.dtsi"
/ {
memory {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv7 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
This changes enables TMU IP block on the Exynos5422 Odroid-XU3
device.
Signed-off-by: Anand Moon
Acked-by: Lukasz Majewski
---
Changes rebase on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
for-next
Changes from v5 and v6: Use LDO7 regulator instead of LDO10 regulator to
control TMU.
Fixed the commit log.
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25 ++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 17e6a9a..96d894e 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -474,6 +474,31 @@
status = "okay";
};
+_cpu0 {
+ vtmu-supply = <_reg>;
+ status = "okay";
+};
+
+_cpu1 {
+ vtmu-supply = <_reg>;
+ status = "okay";
+};
+
+_cpu2 {
+ vtmu-supply = <_reg>;
+ status = "okay";
+};
+
+_cpu3 {
+ vtmu-supply = <_reg>;
+ status = "okay";
+};
+
+_gpu {
+ vtmu-supply = <_reg>;
+ status = "okay";
+};
+
{
status = "okay";
clocks = < CLK_RTC>, <_osc S2MPS11_CLK_AP>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv7 1/4] ARM: dts: exynos5422-odroidxu3: Add pwm-fan node
Add pwm-fan node to the Odroid-XU3 board.
Signed-off-by: Anand Moon
Tested-by: Markus Reichl
Acked-by: Lukasz Majewski
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 8adf455..17e6a9a 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -107,6 +107,15 @@
clocks = < CLK_I2S_CDCLK>;
};
};
+
+ fan0: pwm-fan {
+ compatible = "pwm-fan";
+ pwms = < 0 20972 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 130 170 230>;
+ };
};
_audss {
@@ -461,6 +470,7 @@
*/
pinctrl-0 = <_out _out _out _out>;
pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
status = "okay";
};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] usb: core: lpm: set lpm_capable for root hub device
On 06/13/2015 11:00 PM, Alan Stern wrote:
On Sat, 13 Jun 2015, Lu Baolu wrote:
Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.
Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.
This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate
a host supports Link PM.").
Cc: sta...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser
Signed-off-by: Lu Baolu
---
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -82,6 +82,7 @@ extern int usb_runtime_suspend(struct device *dev);
extern int usb_runtime_resume(struct device *dev);
extern int usb_runtime_idle(struct device *dev);
extern int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable);
+extern int usb_device_supports_lpm(struct usb_device *udev);
#else
@@ -106,6 +107,11 @@ static inline int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable)
return 0;
}
+static inline int usb_device_supports_lpm(struct usb_device *udev)
+{
+ return 0;
+}
+
#endif
extern struct bus_type usb_bus_type;
In fact, usb_device_supports_lpm() is compiled even when CONFIG_PM
isn't set. Maybe this should be changed. But if you don't want to
change it now, you need to put the declaration outside the "#ifdef
CONFIG_PM" region. As it is, your patch is still broken (did you try
building it with CONFIG_PM unset?).
I am sorry for this silly mistake. I will move it out of CONFIG_PM region.
I tried building with CONFIG_PM unset. But it turns out that CONFIG_PM
was auto selected by some other items. I will test my next version of
patch with CONFIG_PM *really* unset before sending it out.
Thanks,
Baolu
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Suspicious RCU usage in linux-next: Bisected to commit 8d52d399
On 06/14/2015 08:20 PM, Martin KaFai Lau wrote: On Sun, Jun 14, 2015 at 06:06:21PM -0500, Larry Finger wrote: I will be happy to test any suggested patches. Can you also turn off kmemleak and give it a try? Thanks for the quick response. As you expected, the problem is not found when kmemleak is not enabled in the configuration. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why do we need vmalloc_sync_all?
Oleg Nesterov writes: > > But again, the kernel no longer does this? do_page_fault() does > vmalloc_fault() > without notify_die(). If it fails, I do not see how/why a modular DIE_OOPS > handler could try to resolve this problem and trigger another fault. The same problem can happen from NMI handlers or machine check handlers. It's not necessarily tied to page faults only. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: fs_enet: Disable NETIF_F_SG feature for Freescale MPC5121
10.06.2015 03:14, David Miller пишет: From: Alexander Popov Date: Wed, 10 Jun 2015 02:57:42 +0300 skb_copy_from_linear_data() which doesn't work well for non-linear sk_buff: The correct fix is to use an SKB copy routine which can handle non-linear data. Thanks, David. I'll prepare the second version of the patch. Best regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpio: generic: add get_direction support
On Sat, Jun 13, 2015 at 1:20 AM, Philipp Zabel wrote: > Allow to determine the current direction configuration by > reading back from the direction register. Interesting that this was missing. Acked-by: Alexandre Courbot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ASoC: mediatek: Add machine driver for MAX98090 codec
On Fri, 2015-06-12 at 14:13 +0100, Mark Brown wrote:
> On Wed, Jun 10, 2015 at 10:24:35PM +0800, Koro Chen wrote:
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
> > @@ -0,0 +1,17 @@
> > +MT8173 with MAX98090 CODEC
> > +
> > +Required properties:
> > +- compatible : "mediatek,mt8173-max98090"
> > +- mediatek,audio-codec: the phandle of the MAX98090 audio codec
> > +- dvdd-supply : the phandle of regulator to supply 1.2V
> > +- avdd-supply : the phandle of regulator to supply 1.8V
>
> Why are these supplies part of the machine driver?
>
These are for the codec as you said. I think I should remove all these
supplies as well as codes in machine drivers, since now the regulators
are configured during the board's bootloader stage.
> > +config SND_SOC_MT8173_MAX98090
> > + bool "ASoC Audio driver for MT8173 with MAX98090 codec"
>
> Why bool?
>
This should be tristate as Paul mentioned before. I will fix it.
> > + codec_node = of_parse_phandle(pdev->dev.of_node,
> > + "mediatek,audio-codec", 0);
> > + if (!codec_node) {
> > + dev_err(>dev,
> > + "Property 'audio-codec' missing or invalid\n");
> > + } else {
>
> Isn't this a fatal error?
>
Thank you and yes it should be fatal, I will fix it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/7] input: cyapa: add of match device support and description document
Jeremiah,
Thanks for the review.
I made the patch based on dtor-next's code based.
I will make the next v1 patches based on the linux-next to avoid this problem.
Thanks,
Dudley
> -Original Message-
> From: Jeremiah Mahler [mailto:jmmah...@gmail.com]
> Sent: 2015?6?13? 11:54
> To: Dudley Du
> Cc: dmitry.torok...@gmail.com; mark.rutl...@arm.com; robh...@kernel.org;
> rydb...@euromail.se; ble...@google.com; devicet...@vger.kernel.org;
> linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 6/7] input: cyapa: add of match device support and
> description
> document
>
> Dudley,
>
> On Fri, Jun 12, 2015 at 02:56:37PM +0800, Dudley Du wrote:
> > Add of_match_device machanism support for Cypress trackpad device, and
> > add the sample description document of adding the trackpad device node in
> > DT.
> > TEST=test on Chromebook.
> >
> > Signed-off-by: Dudley Du
> > ---
> > .../devicetree/bindings/input/cypress,cyapa.txt| 44
> ++
> > .../devicetree/bindings/vendor-prefixes.txt| 1 +
> > drivers/input/mouse/cyapa.c| 10 +
> > 3 files changed, 55 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/input/cypress,cyapa.txt
> >
> [...]
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 728cd0e..4813437 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -48,6 +48,7 @@ cnxtConexant Systems, Inc.
> > cortinaCortina Systems, Inc.
> > cosmicCosmic Circuits
> > crystalfontzCrystalfontz America, Inc.
> > +cypressCypress Semiconductor Corporation
> > dallasMaxim Integrated Products (formerly Dallas Semiconductor)
> > davicomDAVICOM Semiconductor, Inc.
> > denxDenx Software Engineering
> > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> > index 86f2263..7e7613f 100644
> > --- a/drivers/input/mouse/cyapa.c
> > +++ b/drivers/input/mouse/cyapa.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "cyapa.h"
> >
> >
> > @@ -1562,12 +1563,21 @@ static const struct acpi_device_id cyapa_acpi_id[] =
> {
> > MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
> > #endif
> >
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cyapa_of_match[] = {
> > +{ .compatible = "cypress,cyapa" },
> > +{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, cyapa_of_match);
> > +#endif
> > +
> > static struct i2c_driver cyapa_driver = {
> > .driver = {
> > .name = "cyapa",
> > .owner = THIS_MODULE,
> > .pm = _pm_ops,
> > .acpi_match_table = ACPI_PTR(cyapa_acpi_id),
> > +.of_match_table = of_match_ptr(cyapa_of_match),
> > },
> >
> > .probe = cyapa_probe,
> > --
> > 1.9.1
>
> This patch fails to apply on linux-next 20150611 because of difference
> in vendor-prefixes.txt. Probably just needs to be updated.
>
> Applying: input: cyapa: add of match device support and description
> document
> error: patch failed:
> Documentation/devicetree/bindings/vendor-prefixes.txt:48
> error: Documentation/devicetree/bindings/vendor-prefixes.txt: patch does
> not apply
> Patch failed at 0001 input: cyapa: add of match device support and
> description document
>
> --
> - Jeremiah Mahler
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this 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/
Re: [PATCH v2] gpio / ACPI: Add label to the gpio request
On Mon, Jun 15, 2015 at 7:00 AM, Tobias Diedrich wrote: > In leds-gpio.c create_gpio_led only the legacy path propagates the label > by passing it into devm_gpio_request_one. Similarily gpio_keys_polled.c > also neglects to propagate the name to the gpio subsystem. > > On the newer devicetree/acpi path the label is lost as far as the GPIO > subsystem goes (it is only retained as name in struct gpio_led. > > Amend devm_get_gpiod_from_child to take an additonal (optional) label > argument and propagate it so it will show up in /sys/kernel/debug/gpio. > > So instead of: > > GPIOs 288-511, platform/PRP0001:00, AMD SBX00: > gpio-475 (? ) in hi > gpio-477 (? ) out hi > gpio-478 (? ) out lo > gpio-479 (? ) out hi > > we get the much nicer output: > > GPIOs 288-511, platform/PRP0001:00, AMD SBX00: > gpio-475 (switch1 ) in hi > gpio-477 (led1) out hi > gpio-478 (led2) out lo > gpio-479 (led3) out hi We want to reuse higher-level information (like the con_id) as much as possible to generate labels, but in the case of devm_get_gpiod_from_child() there is no such information available anyway, so why not. Acked-by: Alexandre Courbot Generally speaking this label thing is almost useless, we should now be able to trace which device requested a GPIO and for what purpose and provide that complete information in debugfs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/24] Convert the posix_clock_operations and k_clock structure to ready for 2038
On 12 June 2015 at 21:16, Thomas Gleixner wrote:
> On Fri, 12 Jun 2015, Baolin Wang wrote:
>
> Sigh. Again threading of the series failed. Some patches are, the
> whole series is not. Can you please get your tools straight?
>
> You neither managed to cc me on the security patch.
>
>> - Modify the subject line and the changelog:
>
>> timekeeping: Change the implementation of timekeeping_clocktai()
>
> Sigh. How is that better than the previous one? It's more accurate,
> but equally useless.
>
> And of course you did not address my request to change the macro mess
> in
>
>> posix-timers: Introduce {get,put}_timespec and {get,put}_itimerspec
>
> according to the discussion with Arnd.
>
> Thanks,
>
> tglx
Hi Thomas,
Thanks for your comments, and i'll fix these problems you point out.
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/7] input: cyapa: add proximity and interrupt sysfs interfaces support
Dmitry,
Thanks for the review.
The purpose of adding the proximity interface is:
1. User can apply the use of the proximity function as they want.
Some productions may need the proximity function, but some may not.
And for product, the requirements may be also different in the different
usage time.
so through this interface, user can apply their specific strategy to use the
proximity function as required instead of the default behaver.
The purpose of adding the interrupt interface is:
1. For temporary disable the trackpad device, user can disable the trackpad
device to report data through the interrupt interface.
And keep the trackpad device scanning when the data report is disabled, so
when re-enable the report data of the device,
the trackpad device can be re-enabled immediately without the disturb
re-initialize processing.
It may helpful in firmware debugging.
Thanks,
Dudley
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 2015?6?12? 19:10
> To: Dudley Du
> Cc: mark.rutl...@arm.com; robh...@kernel.org; rydb...@euromail.se;
> ble...@google.com; jmmah...@gmail.com; devicet...@vger.kernel.org;
> linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 5/7] input: cyapa: add proximity and interrupt sysfs
> interfaces
> support
>
> Hi Dudley,
>
> On Fri, Jun 12, 2015 at 02:56:36PM +0800, Dudley Du wrote:
> > Add proximity and interrupt control interfaces in sysfs device node.
> > The proximity interface is used to disable/enable proximity function in
> > device.
> > The interrupt interface is used to disbale/enable interrupt from device.
>
> Please explain why you feel that these sysfs interfaces are needed. Why
> would one want to disable interrupt for Gen6 devices? And why do we
> need to enable/disable proximity function? I'd expect kernel provide the
> data and clients to decide if they want to use it or not...
>
> Thanks.
>
> > TEST=test on Chromebook.
> >
> > Signed-off-by: Dudley Du
> > ---
> > drivers/input/mouse/cyapa.c | 101
> +++
> > drivers/input/mouse/cyapa.h | 4 ++
> > drivers/input/mouse/cyapa_gen3.c | 1 +
> > drivers/input/mouse/cyapa_gen5.c | 2 +
> > drivers/input/mouse/cyapa_gen6.c | 14 ++
> > 5 files changed, 122 insertions(+)
> >
> > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> > index faead4d..86f2263 100644
> > --- a/drivers/input/mouse/cyapa.c
> > +++ b/drivers/input/mouse/cyapa.c
> > @@ -594,6 +594,7 @@ static int cyapa_initialize(struct cyapa *cyapa)
> >
> > cyapa->state = CYAPA_STATE_NO_DEVICE;
> > cyapa->gen = CYAPA_GEN_UNKNOWN;
> > +cyapa->interrupt = true;
> > mutex_init(>state_sync_lock);
> >
> > /*
> > @@ -1217,12 +1218,110 @@ static ssize_t cyapa_show_mode(struct device
> *dev,
> > return size;
> > }
> >
> > +static ssize_t cyapa_show_interrupt(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > +struct cyapa *cyapa = dev_get_drvdata(dev);
> > +int size;
> > +int error;
> > +
> > +error = mutex_lock_interruptible(>state_sync_lock);
> > +if (error)
> > +return error;
> > +
> > +size = scnprintf(buf, PAGE_SIZE, "%d\n", cyapa->interrupt ? 1 : 0);
> > +
> > +mutex_unlock(>state_sync_lock);
> > +return size;
> > +}
> > +
> > +static ssize_t cyapa_interrupt_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
> > +{
> > +struct cyapa *cyapa = dev_get_drvdata(dev);
> > +u16 value;
> > +int error;
> > +
> > +if (cyapa->gen < CYAPA_GEN6)
> > +return -EOPNOTSUPP;
> > +
> > +if (kstrtou16(buf, 10, )) {
> > +dev_err(dev, "invalid interrupt set parameter\n");
> > +return -EINVAL;
> > +}
> > +
> > +error = mutex_lock_interruptible(>state_sync_lock);
> > +if (error)
> > +return error;
> > +
> > +if (cyapa->operational)
> > +error = cyapa->ops->set_interrupt(cyapa,
> > + value ? true : false);
> > +else
> > +error = -EBUSY; /* Still running in bootloader mode. */
> > +
> > +mutex_unlock(>state_sync_lock);
> > +return error < 0 ? error : count;
> > +}
> > +
> > +static ssize_t cyapa_show_proximity(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > +struct cyapa *cyapa = dev_get_drvdata(dev);
> > +int size;
> > +int error;
> > +
> > +error = mutex_lock_interruptible(>state_sync_lock);
> > +if (error)
> > +return error;
> > +
> > +size = scnprintf(buf, PAGE_SIZE, "%d\n", cyapa->proximity ? 1 : 0);
> > +
> > +mutex_unlock(>state_sync_lock);
> > +return size;
> > +}
> > +
> > +static ssize_t cyapa_proximity_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
> > +{
> > +struct cyapa *cyapa = dev_get_drvdata(dev);
> > +u16 value;
> > +int error;
> > +
> > +if (cyapa->gen < CYAPA_GEN5)
> > +return -EOPNOTSUPP;
> > +
> > +if (kstrtou16(buf, 10, )) {
> > +dev_err(dev, "invalid set value of proximity\n");
> > +return -EINVAL;
> > +}
> > +
> >
Re: [PATCH 1/1] perf tools: Check access permission when reading /proc/kcore file.
On 2015年06月10日 22:44, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 11:01:33AM +0800, Li Zhang escreveu:
When using command perf report --kallsyms=/proc/kallsyms with a non-root
user, symbols are resolved. Then select one symbol and annotate it, it
reports the error as the following:
Can't annotate __clear_user: No vmlinux file with build id xxx was found.
The problem is caused by reading /proc/kcore without access permission.
It needs to change access permission to allow a specific user to read
/proc/kcore or use root to execute the perf command.
But then only if the user tries it again, using -v to enable verbose
mode is that the message will be presented, how about instead return
-EPERM, or -errno, so that this error is propagated back and we
eventually emit a more meaningful message to the user, such as:
"Insufficient permission to access %s.", kcore_filename
Trying to check if that is possible by going to the dso__load_kcore()
callers and on back to the tools.
This sounds much better. I will check whether it can deliver this
message to user.
Thanks Li
- Arnaldo
This patch is to check access permission when reading kcore file.
Signed-off-by: Li Zhang
---
tools/perf/util/symbol.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 201f6c4c..826 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1125,6 +1125,11 @@ static int dso__load_kcore(struct dso *dso, struct map
*map,
md.type = map->type;
INIT_LIST_HEAD();
+ if (access(kcore_filename, R_OK)) {
+ pr_debug("Can't access file %s.\n", kcore_filename);
+ return -EINVAL;
+ }
+
fd = open(kcore_filename, O_RDONLY);
if (fd < 0)
return -EINVAL;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Li Zhang
IBM China Linux Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
hi Krzysztof
On 15 June 2015 at 05:41, Krzysztof Kozlowski wrote:
> On 14.06.2015 19:24, Anand Moon wrote:
>> This changes enables TMU IP block on the Exynos5422 Odroid-XU3
>> device.
>>
>> Signed-off-by: Anand Moon
>> Tested-by: Markus Reichl
>
> This does not look right.
> You put this "Tested-by" since beginning of this patchset (v1) but first
> it was LDO10. Then you proposed LDO18 and now you use LDO7 from my
> suggestion. Which of this was tested by Markus because I cannot find his
> emails with it on LKML?
Markus Reichl tested the earlier version with LDO10.
Commit logs got carry forward by mistake.
-Anand Moon
>
> Krzysztof
>
>> Acked-by: Lukasz Majewski
>> ---
>> Changes rebase on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
>> for-next
>> Changes from v5: Use LDO7 regulator instead of LD010.
>>
>> The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
>>
>> I think the schematics are missing some of details but it can be deducted
>> that:
>> 1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
>> pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
>> 2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
>> S2MPS11 PMIC.
>> 3. I confirmed with the Exynos5422 datasheet that these
>> VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
>>
>> So the LDO7 it is... but before using it there is a caveat. The LDO7
>> is also connected to VDD of MIPI, HDMI and few more. So when you use
>> this regulator in TMU it may be turned off by TMU driver (e.g. during
>> unbind). In such case these other blocks also should be tested and
>> checked whether they take this regulator and enable it.
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25
>> ++
>> 1 file changed, 25 insertions(+)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Linux 4.1-rc8
On Sun, Jun 14, 2015 at 4:10 PM, Linus Torvalds wrote: > So I'm on vacation, but time doesn't stop for that, and it's Sunday, > so time for a hopefully final rc. .. and if you were quick, and on the ball, and confused about why you couldn't find the tar-ball or patch, it's because I'm a clutzy moron. I put the tar-ball and patches in the v3.x testing directory, not the v4.x one. What can I say? Maybe I should just make noises about how tar-balls and patches are so last century, and that if you were *really* on the ball, you wouldn't even have noticed, because you'd have been using git. Anyway. It's re-uploading to the *right* location now. I'm sure I'll get it right _eventually_. Blame the foofy drinks, or whatever.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
hi Krzysztof
On 15 June 2015 at 05:21, Krzysztof Kozlowski wrote:
> On 14.06.2015 19:24, Anand Moon wrote:
>> This changes enables TMU IP block on the Exynos5422 Odroid-XU3
>> device.
>>
>> Signed-off-by: Anand Moon
>> Tested-by: Markus Reichl
>> Acked-by: Lukasz Majewski
>> ---
>> Changes rebase on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
>> for-next
>> Changes from v5: Use LDO7 regulator instead of LD010.
>>
>> The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
>>
>> I think the schematics are missing some of details but it can be deducted
>> that:
>> 1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
>> pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
>> 2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
>> S2MPS11 PMIC.
>> 3. I confirmed with the Exynos5422 datasheet that these
>> VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
>>
>> So the LDO7 it is... but before using it there is a caveat. The LDO7
>> is also connected to VDD of MIPI, HDMI and few more. So when you use
>> this regulator in TMU it may be turned off by TMU driver (e.g. during
>> unbind). In such case these other blocks also should be tested and
>> checked whether they take this regulator and enable it.
>
> Why did you took my email and pasted it here?
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/343702.html
>
> It is written now in first person so it pretends that you wrote this.
> You are actually doing this for second time - taking my
> reply and putting into commit message or changelog. Why?
>
> And where is proper changelog?
>
Sorry: My intention was never to take credit on what your guidance and
your pointers.
I value ever input of your and try not to repeat the mistakes I am repeating.
I will send updated version soon.
-Anand Moon
> Krzysztof
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25
>> ++
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index a2f9941..b6570fc 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -474,6 +474,31 @@
>> status = "okay";
>> };
>>
>> +_cpu0 {
>> + vtmu-supply = <_reg>;
>> + status = "okay";
>> +};
>> +
>> +_cpu1 {
>> + vtmu-supply = <_reg>;
>> + status = "okay";
>> +};
>> +
>> +_cpu2 {
>> + vtmu-supply = <_reg>;
>> + status = "okay";
>> +};
>> +
>> +_cpu3 {
>> + vtmu-supply = <_reg>;
>> + status = "okay";
>> +};
>> +
>> +_gpu {
>> + vtmu-supply = <_reg>;
>> + status = "okay";
>> +};
>> +
>> {
>> status = "okay";
>> clocks = < CLK_RTC>, <_osc S2MPS11_CLK_AP>;
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] clk: mediatek: Add subsystem clocks of MT8173
On Fri, 2015-06-12 at 19:09 +0200, Matthias Brugger wrote:
> On Thursday, May 21, 2015 03:12:55 PM James Liao wrote:
> > +
> > +static struct mtk_gate_regs venclt_cg_regs = {
> > + .set_ofs = 0x0004,
> > + .clr_ofs = 0x0008,
> > + .sta_ofs = 0x,
> > +};
>
>
> The register for imagesys, vencsys and vencltsys have all the same offset.
> We could use just one struct for all of them.
OK. I'll merge them in next patch.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4.1-rc8
So I'm on vacation, but time doesn't stop for that, and it's Sunday,
so time for a hopefully final rc.
It turns out it's just as well that I wanted to drag the release out
by a week so that I don't have the merge window while on vacation - we
still have some fixes in md. As Neil Brown put it "Hasn't been a good
cycle for md has it :-(".
The fixes are pretty small, and hopefully we're all good now. But
another week of testing certainly won't hurt, so rc8 is perfectly
appropriate.
There's also various other things going on, including continuing MIPS
fixes as well, along with small ARM, s390 and x86 updates.
But the bulk is (as usual) drivers, and no, that's not from the md
camp (those fixes are very small). Mostly ethernet, slave-dma, and
spund. But some drm fixes and random other noise too.
There's some generic networking fixes as well, and random small stuff.
The shortlog is appended as usual, for people who want to get an
overview of the details.
Anyway, it's not like there is a *ton* of fixes, and most of them are
very small, so I don't think this is particularly worrisome. It's just
that rc8 works out not just because of my timing, but due to
continuing small details cropping up.
Let's make next week really calm, shall we? Because I will very
actively try to avoid having to read email.
Linus
---
Aaro Koskinen (1):
pata_octeon_cf: fix broken build
Alex Deucher (2):
Revert "drm/radeon: don't share plls if monitors differ in audio support"
Revert "drm/radeon: adjust pll when audio is not enabled"
Ander Conselvan de Oliveira (1):
drm/i915: Properly initialize SDVO analog connectors
Andrew Morton (1):
arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug
Anjali Singhai Jain (3):
i40e/i40evf: Fix mixed size frags and linearization
i40e: start up in VEPA mode by default
i40e: Make sure to be in VEB mode if SRIOV is enabled at probe
Axel Lin (1):
irqchip: sunxi-nmi: Fix off-by-one error in irq iterator
Dan Williams (1):
block: fix ext_dev_lock lockdep report
Daniel Verkamp (1):
ntb: initialize max_mw for Atom before using it
Dave Airlie (1):
ALSA: hda - fix number of devices query on hotplug
David S. Miller (2):
Revert "bridge: use _bh spinlock variant for br_fdb_update to
avoid lockup"
Revert "ipv6: Fix protocol resubmission"
David Woodhouse (3):
iommu/vt-d: Fix passthrough mode with translation-disabled devices
iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register
iommu/vt-d: Only enable extended context tables if PASID is supported
Erik Hugne (1):
tipc: disconnect socket directly after probe failure
Florian Fainelli (1):
net: bcmgenet: power on MII block for all MII modes
Govindarajulu Varadarajan (3):
enic: unlock napi busy poll before unmasking intr
enic: check return value for stat dump
enic: fix memory leak in rq_clean
Gu Zheng (1):
mm/memory_hotplug.c: set zone->wait_table to null after freeing it
Guenter Roeck (2):
blackfin: Fix build error
score: Fix exception handler label
Hauke Mehrtens (3):
rhashtable: add missing import
b44: call netif_napi_del()
SSB: Fix handling of ssb_pmu_get_alp_clock()
Imre Kaloz (1):
ARM: mvebu: armada-xp-linksys-mamba: Disable internal RTC
Ingo Molnar (1):
Revert "perf/x86/intel/uncore: Move uncore_box_init() out of
driver initialization"
Jaedon Shin (1):
MPI: MIPS: Fix compilation error with GCC 5.1
Jani Nikula (1):
drm/i915: Fix DDC probe for passive adapters
Jiang Liu (1):
virtio_pci: Clear stale cpumask when setting irq affinity
Jiri Benc (1):
openvswitch: disable LRO
Joe Perches (1):
checkpatch: fix "GLOBAL_INITIALISERS" test
Johannes Berg (1):
cfg80211: wext: clear sinfo struct before calling driver
Johannes Weiner (1):
mm: memcontrol: fix false-positive VM_BUG_ON() on -rt
Jon Mason (1):
ntb: iounmap MW reg and vbase in error path
Josh Hunt (1):
ipv6: Fix protocol resubmission
Jurgen Kramer (1):
ALSA: usb-audio: add native DSD support for JLsounds I2SoverUSB
Jérôme Glisse (1):
drm/radeon: fix freeze for laptop with Turks/Thames GPU.
Kan Liang (1):
perf/x86/intel/uncore: Fix CBOX bit wide and UBOX reg on Haswell-EP
Krzysztof Kozlowski (1):
dmaengine: Fix choppy sound because of unimplemented resume
Lendacky, Thomas (1):
amd-xgbe: Use disable_irq_nosync from within timer function
Linus Torvalds (1):
Linux 4.1-rc8
Ludovic Desroches (2):
dmaengine: at_xdmac: lock fixes
dmaengine: at_xdmac: rework slave configuration part
Marc Zyngier (1):
ARM: exynos: Fix wake-up interrupts for Exynos3250
Marcelo Ricardo Leitner (1):
sctp: allow authenticating DATA chunks that are bundled with COOKIE_ECHO
Markos Chandras (1):
MIPS: pgtable-bits: Fix XPA damage to R6 definitions.
Masanari Iida (1):
Doc:
Re: [PATCH 1/1] iio:adc: XADC: Set offset explicitly to zero on voltage channels
On 14 June 2015 at 23:55, Jonathan Cameron wrote: > On 14/06/15 16:45, Lars-Peter Clausen wrote: >> On 06/14/2015 05:15 AM, Gergely Imreh wrote: >>> On 14 June 2015 at 02:30, Jonathan Cameron wrote: On 11/06/15 09:22, Gergely Imreh wrote: > The Xilinx XADC driver has both a temperature channel and 8 voltage > channels. The voltage channels have no offset, but actually were still > set the same offset as the temperature channel. This did not cause > problems in /sys/bus/iio/ but can cause problems with other drivers > using iio data. For example iio-hwmon did return wrong voltage values > because of the offset. > > Change tested with the Parallella board. > > Signed-off-by: Gergely Imreh Well spotted on the bug, but I think we are better off fixing this at the true source of the problem which is in drivers/iio/inkern.c iio_convert_raw_to_processed_unlocked which does a call to iio_channel_read(chan, , NULL, IIO_CHAN_INFO_OFFSET) then uses the error return to check if the offset parameter is available. It should be checking that before making this call with a call to iio_channel_has_info. I don't suppose you could prepare a patch fixing that as you found the problem? >>> >>> I'll check it out, and send an updated patch! Thanks for the pointers >>> to the core of the issue. >> >> The issue was already fixed a while ago, see this patch: >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65de7654d39c70c2b942f801cea01590cf7e3458 >> >> Starting with that commit iio_channel_read() returns an error when >> the attribute is not available, which causes >> iio_convert_raw_to_processed_unlocked() to skip the offset if it is >> not available. >> > oops. Good spot. I'd completely forgotten about that and failed to spot > the check when looking at the code yesterday. > > Glad you were keeping an eagle eye on things ;) Okay, thanks, then it's all good, scrub this patch! That linked change was not backported to the Parallella yet, and missed it. Looks like it's going to be included now. Thanks for the feedback! Greg > > J >> - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: mediatek: Add AFE platform driver
On Fri, 2015-06-12 at 14:06 +0100, Mark Brown wrote: > On Wed, Jun 10, 2015 at 10:24:34PM +0800, Koro Chen wrote: > > This is the DPCM based platform driver of AFE (Audio Front End) unit. > > > > Signed-off-by: Koro Chen > > Signed-off-by: Sascha Hauer > > Your signoff should be last if you're the one sending the patch. > Otherwise this seems basically fine, but you said you were going to send > a new version so not applying. Thank you, I will fix this in the next version of patch along with fixups of Paul's comments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: ttpci: Use vsprintf %pM extension
Format mac addresses with the normal kernel extension.
Signed-off-by: Joe Perches
---
drivers/media/pci/ttpci/ttpci-eeprom.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/pci/ttpci/ttpci-eeprom.c
b/drivers/media/pci/ttpci/ttpci-eeprom.c
index 32d4315..c6f31f2 100644
--- a/drivers/media/pci/ttpci/ttpci-eeprom.c
+++ b/drivers/media/pci/ttpci/ttpci-eeprom.c
@@ -162,9 +162,7 @@ int ttpci_eeprom_parse_mac(struct i2c_adapter *adapter, u8
*proposed_mac)
}
memcpy(proposed_mac, decodedMAC, 6);
- dprintk("adapter has MAC addr = %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
- decodedMAC[0], decodedMAC[1], decodedMAC[2],
- decodedMAC[3], decodedMAC[4], decodedMAC[5]);
+ dprintk("adapter has MAC addr = %pM\n", decodedMAC);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m68k: Use vsprintf %pM extension
Format mac addresses with the normal kernel extension.
Signed-off-by: Joe Perches
---
arch/m68k/68000/m68EZ328.c | 3 +--
arch/m68k/68000/m68VZ328.c | 3 +--
arch/m68k/68360/config.c | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/m68k/68000/m68EZ328.c b/arch/m68k/68000/m68EZ328.c
index 2195290..e6ab321 100644
--- a/arch/m68k/68000/m68EZ328.c
+++ b/arch/m68k/68000/m68EZ328.c
@@ -62,8 +62,7 @@ void __init config_BSP(char *command, int len)
#ifdef CONFIG_UCSIMM
printk(KERN_INFO "uCsimm serial string [%s]\n",getserialnum());
p = cs8900a_hwaddr = gethwaddr(0);
- printk(KERN_INFO "uCsimm hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ printk(KERN_INFO "uCsimm hwaddr %pM\n", p);
p = getbenv("APPEND");
if (p) strcpy(p,command);
diff --git a/arch/m68k/68000/m68VZ328.c b/arch/m68k/68000/m68VZ328.c
index 0e5e5a1..1154bdb 100644
--- a/arch/m68k/68000/m68VZ328.c
+++ b/arch/m68k/68000/m68VZ328.c
@@ -152,8 +152,7 @@ static void __init init_hardware(char *command, int size)
printk(KERN_INFO "uCdimm serial string [%s]\n", getserialnum());
p = cs8900a_hwaddr = gethwaddr(0);
- printk(KERN_INFO "uCdimm hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ printk(KERN_INFO "uCdimm hwaddr %pM\n", p);
p = getbenv("APPEND");
if (p)
strcpy(p, command);
diff --git a/arch/m68k/68360/config.c b/arch/m68k/68360/config.c
index fd1f948c..b65fe4e 100644
--- a/arch/m68k/68360/config.c
+++ b/arch/m68k/68360/config.c
@@ -154,8 +154,7 @@ void __init config_BSP(char *command, int len)
#if defined(CONFIG_UCQUICC) && 0
printk(KERN_INFO "uCquicc serial string [%s]\n",getserialnum());
p = scc1_hwaddr = gethwaddr(0);
- printk(KERN_INFO "uCquicc hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
- p[0], p[1], p[2], p[3], p[4], p[5]);
+ printk(KERN_INFO "uCquicc hwaddr %pM\n", p);
p = getbenv("APPEND");
if (p)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: orion5x: Use vsprintf %pM extension
Format mac addresses with the normal kernel extension.
Signed-off-by: Joe Perches
---
arch/arm/mach-orion5x/dns323-setup.c | 4 +---
arch/arm/mach-orion5x/tsx09-common.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-orion5x/dns323-setup.c
b/arch/arm/mach-orion5x/dns323-setup.c
index 09d2a26..f267e58 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -236,9 +236,7 @@ static int __init dns323_read_mac_addr(void)
}
iounmap(mac_page);
- printk("DNS-323: Found ethernet MAC address: ");
- for (i = 0; i < 6; i++)
- printk("%.2x%s", addr[i], (i < 5) ? ":" : ".\n");
+ printk("DNS-323: Found ethernet MAC address: %pM\n", addr);
memcpy(dns323_eth_data.mac_addr, addr, 6);
diff --git a/arch/arm/mach-orion5x/tsx09-common.c
b/arch/arm/mach-orion5x/tsx09-common.c
index 7189827..24b2959 100644
--- a/arch/arm/mach-orion5x/tsx09-common.c
+++ b/arch/arm/mach-orion5x/tsx09-common.c
@@ -101,9 +101,7 @@ static int __init qnap_tsx09_check_mac_addr(const char
*addr_str)
addr[i] = byte;
}
- printk(KERN_INFO "tsx09: found ethernet mac address ");
- for (i = 0; i < 6; i++)
- printk("%.2x%s", addr[i], (i < 5) ? ":" : ".\n");
+ printk(KERN_INFO "tsx09: found ethernet mac address %pM\n", addr);
memcpy(qnap_tsx09_eth_data.mac_addr, addr, 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 V2 1/1] usb:serial:f81534 Add F81532/534 Driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration for transceiver (for RS232/RS485/RS422) (/sys/class/ttyUSBx/uart_mode) 4. There are 4x3 output-only GPIOs to control transceiver mode. It's can be controlled via sysfs (/sys/class/ttyUSBx/gpio) Changelog from v1: 1. v1 version submit to staging tree, but Greg KH advised me to cleanup source code & re-submit it to correct subsystem 2. Remove all custom ioctl commands If had any question, Please send email to hpeter+linux_ker...@gmail.com peter_h...@fintek.com.tw Signed-off-by: Peter Hung --- drivers/usb/serial/Kconfig | 10 + drivers/usb/serial/Makefile |1 + drivers/usb/serial/f81534.c | 3162 +++ 3 files changed, 3173 insertions(+) create mode 100644 drivers/usb/serial/f81534.c diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index b7cf198..4bf3011 100644 --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -255,6 +255,16 @@ config USB_SERIAL_F81232 To compile this driver as a module, choose M here: the module will be called f81232. +config USB_SERIAL_F8153X + tristate "USB Fintek F81532/534 Multi-Ports Serial Driver" + help + Say Y here if you want to use the Fintek F81532/534 Multi-Ports + usb to serial adapter. + + To compile this driver as a module, choose M here: the + module will be called f81534. + + config USB_SERIAL_GARMIN tristate "USB Garmin GPS driver" help diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile index 349d9df..9e43b7b 100644 --- a/drivers/usb/serial/Makefile +++ b/drivers/usb/serial/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI) += io_ti.o obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o +obj-$(CONFIG_USB_SERIAL_F8153X)+= f81534.o obj-$(CONFIG_USB_SERIAL_FTDI_SIO) += ftdi_sio.o obj-$(CONFIG_USB_SERIAL_GARMIN)+= garmin_gps.o obj-$(CONFIG_USB_SERIAL_IPAQ) += ipaq.o diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c new file mode 100644 index 000..8c817ee --- /dev/null +++ b/drivers/usb/serial/f81534.c @@ -0,0 +1,3162 @@ +/* + * F81532/F81534 USB to Serial Ports Bridge + * + * F81532 => 2 Serial Ports + * F81534 => 4 Serial Ports + * + * Copyright (C) 2014 Tom Tsai (tom_t...@fintek.com.tw) + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Serial Port register Address */ +#define SERIAL_BASE_ADDRESS0x1200 +#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS) +#define TRANSMIT_HOLDING_REGISTER (0x00 + SERIAL_BASE_ADDRESS) +#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS) +#define INTERRUPT_IDENT_REGISTER (0x02 + SERIAL_BASE_ADDRESS) +#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS) +#define LINE_CONTROL_REGISTER (0x03 + SERIAL_BASE_ADDRESS) +#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS) +#define LINE_STATUS_REGISTER (0x05 + SERIAL_BASE_ADDRESS) +#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS) +#define CLK_SEL_REGISTER (0x08 + SERIAL_BASE_ADDRESS) +#define CONFIG1_REGISTER (0x09 + SERIAL_BASE_ADDRESS) +#define SADDRESS_REGISTER (0x0a + SERIAL_BASE_ADDRESS) +#define SADEN_REGISTER (0x0b + SERIAL_BASE_ADDRESS) +#define DIVISOR_LATCH_LSB (0x00 + SERIAL_BASE_ADDRESS) +#define DIVISOR_LATCH_MSB (0x01 + SERIAL_BASE_ADDRESS) +#define SCRATCH_PAD_REGISTER (0x07 + SERIAL_BASE_ADDRESS) + +#define F81534_RESERVE_ADDRESS_START 0x3000 +#define F81534_RESERVE_SIZE8 + +#define F81534_CUSTOM_ADDRESS_START0x4000 +#define F81534_CUSTOM_TOTAL_SIZE 0x1000 + +#define F81534_CUSTOM_DATA_SIZE0x10 +#define F81534_CUSTOM_MAX_IDX \ + (F81534_CUSTOM_TOTAL_SIZE/F81534_CUSTOM_DATA_SIZE) +#define F81534_CUSTOM_NO_CUSTOM_DATA (-1) + +#define F81534_MAX_DATA_BLOCK 64 +#define F81534_BUSY_STATUS 0x03 +#define F81534_MAX_BUS_RETRY 2000 + +/* default urb timeout for usb operations */ +#define F81534_USB_MAX_RETRY 5 +#define F81534_USB_TIMEOUT 1000 +#define F81534_CONTROL_BYTE0x1B +#define F81534_SET_GET_REGISTER0xA0 + +#define F81534_NUM_PORT4 +#define F81534_UNUSED_PORT 0xff +#define
Re: [lkp] [jbd2] 562bef4565e: kernel BUG at fs/jbd2/transaction.c:1329!
On Mon, Jun 15, 2015 at 09:17:04AM +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://internal_merge_and_test_tree
> revert-562bef4565ef88e3c7206d5340263c8bb15bd87d-562bef4565ef88e3c7206d5340263c8bb15bd87d
> commit 562bef4565ef88e3c7206d5340263c8bb15bd87d ("jbd2: speedup
> jbd2_journal_dirty_metadata()")
Thanks, this commit has already been dropped from the ext4 git tree.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 cgroup/for-4.2] MAINTAINERS: add a cgroup core co-maintainer
On Fri, Jun 12, 2015 at 05:15:23PM -0500, Tejun Heo wrote: > Add Johannes Weiner as a co-maintainer of cgroup core. Johannes has > been heavily involved with the design of the v2 interface and is > familiar with design and implementation of cgroup core. > > Signed-off-by: Tejun Heo > Cc: Li Zefan > Cc: Johannes Weiner Applied to cgroup/for-4.2. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Suspicious RCU usage in linux-next: Bisected to commit 8d52d399
On Sun, Jun 14, 2015 at 06:06:21PM -0500, Larry Finger wrote: > I will be happy to test any suggested patches. Can you also turn off kmemleak and give it a try? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 cgroup/for-4.2] MAINTAINERS: add a cgroup core co-maintainer
On 2015/6/13 6:15, Tejun Heo wrote: > Add Johannes Weiner as a co-maintainer of cgroup core. Johannes has > been heavily involved with the design of the v2 interface and is > familiar with design and implementation of cgroup core. > > Signed-off-by: Tejun Heo > Cc: Li Zefan > Cc: Johannes Weiner acked > --- > MAINTAINERS |1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ea00017..1d39599 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2695,6 +2695,7 @@ F: drivers/connector/ > CONTROL GROUP (CGROUP) > M: Tejun Heo > M: Li Zefan > +M: Johannes Weiner > L: cgro...@vger.kernel.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git > S: Maintained > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/3] mm: add tracepoint for scanning pages
On 06/14/2015 11:04 AM, Ebru Akagunduz wrote: > Using static tracepoints, data of functions is recorded. > It is good to automatize debugging without doing a lot > of changes in the source code. > > This patch adds tracepoint for khugepaged_scan_pmd, > collapse_huge_page and __collapse_huge_page_isolate. These trace points seem like a useful set to figure out what the THP collapse code is doing. > Signed-off-by: Ebru Akagunduz Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [sched/preempt] BUG: KASan: out of bounds access in trace_graph_entry at addr ffff88000d717e48
Hi Frederic, On Sun, Jun 14, 2015 at 02:33:32PM +0200, Frederic Weisbecker wrote: > On Sun, Jun 14, 2015 at 04:55:59PM +0800, Fengguang Wu wrote: > > Hi Frederic, > > > > FYI, there are a number more bug messages showing up after this commit > > > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > > > commit b30f0e3ffedfa52b1d67a302ae5860c49998e5e2 > > Author: Frederic Weisbecker > > AuthorDate: Tue May 12 16:41:49 2015 +0200 > > Commit: Ingo Molnar > > CommitDate: Tue May 19 08:39:12 2015 +0200 > > > > sched/preempt: Optimize preemption operations on __schedule() callers > > > > __schedule() disables preemption and some of its callers > > (the preempt_schedule*() family) also set PREEMPT_ACTIVE. > > > > So we have two preempt_count() modifications that could be performed > > at once. > > > > Lets remove the preemption disablement from __schedule() and pull > > this responsibility to its callers in order to optimize preempt_count() > > operations in a single place. > > > > Suggested-by: Linus Torvalds > > Signed-off-by: Frederic Weisbecker > > Signed-off-by: Peter Zijlstra (Intel) > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Link: > > http://lkml.kernel.org/r/1431441711-29753-5-git-send-email-fweis...@gmail.com > > Signed-off-by: Ingo Molnar > > Do you still see that issue after latest tip:/sched/core. I fixed it a few > days ago with: > > 9a92e3dc6ad02208a014d0d8404ebbd697e3d5ef (preempt: Reorganize the notrace > definitions a bit) > 4eaca0a887eaee04fc7a3866d0f5b51b34030dfa (preempt: Use > preempt_schedule_context() as the official tracing preemption point) > be690035df893385ceaac2323b29be1fb7f2a67f (sched: Make > preempt_schedule_context() function-tracing safe) > > But maybe there are other issues remaining. The tip sched/core HEAD looks perfect now -- 1000 boots are all fine except for 2 OOM errors, which look like noises. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 1/5] drivers: pwm: core: Add pwmchip_add_inversed
On Fri, Jun 12, 2015 at 2:45 AM, Thierry Reding wrote: > On Tue, May 26, 2015 at 01:08:16PM -0700, Jonathan Richardson wrote: >> From: Tim Kryger >> >> Add a new function to register a PWM chip with channels that have their >> initial polarity as inversed. This benefits drivers of controllers that >> by default operate with inversed polarity by removing the need to modify >> the polarity during initialization. >> >> Signed-off-by: Tim Kryger >> Signed-off-by: Jonathan Richardson >> --- >> drivers/pwm/core.c | 36 >> include/linux/pwm.h |6 ++ >> 2 files changed, 34 insertions(+), 8 deletions(-) > > I had to bikeshed this a little, so I ended up applying a variant that > exports pwmchip_add_with_polarity() instead of having the additional > wrapper. The rationale here is that pwmchip_add_with_polarity() is more > explicit than pwmchip_add_inversed(). > > Thierry Sounds good. Thanks. -Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/12] x86/mm/hotplug: Remove pgd_list use from the memory hotplug code
On Sun, Jun 14, 2015 at 09:38:25PM +0200, Oleg Nesterov wrote: > On 06/14, Oleg Nesterov wrote: > > > > On 06/14, Ingo Molnar wrote: > > > > > > * Oleg Nesterov wrote: > > > > > > > > + spin_lock(_lock); /* Implies rcu_read_lock() for > > > > > the task list iteration: */ > > > > ^^^ > > > > > > > > Hmm, but it doesn't if PREEMPT_RCU? No, no, I do not pretend I > > > > understand how it > > > > actually works ;) But, say, rcu_check_callbacks() can be called from > > > > irq and > > > > since spin_lock() doesn't increment current->rcu_read_lock_nesting this > > > > can lead > > > > to rcu_preempt_qs()? > > > > > > No, RCU grace periods are still defined by 'heavy' context boundaries > > > such as > > > context switches, entering idle or user-space mode. > > > > > > PREEMPT_RCU is like traditional RCU, except that blocking is allowed > > > within the > > > RCU read critical section - that is why it uses a separate nesting counter > > > (current->rcu_read_lock_nesting), not the preempt count. > > > > Yes. > > > > > But if a piece of kernel code is non-preemptible, such as a spinlocked > > > region or > > > an irqs-off region, then those are still natural RCU read lock regions, > > > regardless > > > of the RCU model, and need no additional RCU locking. > > > > I do not think so. Yes I understand that rcu_preempt_qs() itself doesn't > > finish the gp, but if there are no other rcu-read-lock holders then it > > seems synchronize_rcu() on another CPU can return _before_ spin_unlock(), > > this CPU no longer needs rcu_preempt_note_context_switch(). > > > > OK, I can be easily wrong, I do not really understand the implementation > > of PREEMPT_RCU. Perhaps preempt_disable() can actually act as > > rcu_read_lock() > > with the _current_ implementation. Still this doesn't look right even if > > happens to work, and Documentation/RCU/checklist.txt says: > > > > 11. Note that synchronize_rcu() -only- guarantees to wait until > > all currently executing rcu_read_lock()-protected RCU read-side > > critical sections complete. It does -not- necessarily guarantee > > that all currently running interrupts, NMIs, preempt_disable() > > code, or idle loops will complete. Therefore, if your > > read-side critical sections are protected by something other > > than rcu_read_lock(), do -not- use synchronize_rcu(). > > > I've even checked this ;) I applied the stupid patch below and then > > $ taskset 2 perl -e 'syscall 157, 666, 5000' & > [1] 565 > > $ taskset 1 perl -e 'syscall 157, 777' > > $ > [1]+ Donetaskset 2 perl -e 'syscall 157, 666, 5000' > > $ dmesg -c > SPIN start > SYNC start > SYNC done! > SPIN done! Please accept my apologies for my late entry to this thread. Youngest kid graduated from university this weekend, so my attention has been elsewhere. If you were to disable interrupts instead of preemption, I would expect that the preemptible-RCU grace period would be blocked -- though I am not particularly comfortable with people relying on disabled interrupts blocking a preemptible-RCU grace period. Here is what can happen if you try to block a preemptible-RCU grace period by disabling preemption, assuming that there are at least two online CPUs in the system: 1. CPU 0 does spin_lock(), which disables preemption. 2. CPU 1 starts a grace period. 3. CPU 0 takes a scheduling-clock interrupt. It raises softirq, and the RCU_SOFTIRQ handler notes that there is a new grace period and sets state so that a subsequent quiescent state on this CPU will be noted. 4. CPU 0 takes another scheduling-clock interrupt, which checks current->rcu_read_lock_nesting, and notes that there is no preemptible-RCU read-side critical section in progress. It again raises softirq, and the RCU_SOFTIRQ handler reports the quiescent state to core RCU. 5. Once each of the other CPUs report a quiescent state, the grace period can end, despite CPU 0 having preemption disabled the whole time. So Oleg's test is correct, disabling preemption is not sufficient to block a preemptible-RCU grace period. The usual suggestion would be to add rcu_read_lock() just after the lock is acquired and rcu_read_unlock() just before each release of that same lock. Putting the entire RCU read-side critical section under the lock prevents RCU from having to invoke rcu_read_unlock_special() due to preemption. (It might still invoke it if the RCU read-side critical section was overly long, but that is much cheaper than the preemption-handling case.) Thanx, Paul > Oleg. > > --- a/kernel/sys.c > +++ b/kernel/sys.c > @@ -2049,6 +2049,9 @@ static int prctl_get_tid_address(struct task_struct > *me, int __user **tid_addr) >
Re: [PATCH] module: add per-module param_lock
Dan Streetman writes:
> You suggested giving direct access to the mutex, but this patch just
> provides lock/unlock functions to the appropriate mutex, which seemed
> cleaner and clearer to me, but if you prefer the direct mutex access
> I can update the patch for that.
Happy with your judgement on this, and I think we've done enough
bike-shedding that existant code wins.
> Also, this combines the making the kparam_lock into a per-module mutex,
> with also removing the kparam_block_sysfs_*() macros; I can split that up
> if you would prefer two patches.
Hmm, I've split the "make u16 perm const" into its own patch instead,
since that's a nice independent change.
> +/* Use the module's mutex, or if built-in use the built-in mutex */
> +#define KPARAM_MUTEX(mod)((mod) ? &(mod)->param_lock : _lock)
> +#define KPARAM_IS_LOCKED(mod)mutex_is_locked(KPARAM_MUTEX(mod))
In future I prefer inlines to macros. In fact, since this is just in
params.c it's not too bad to just open-code them in the two places
they're each used.
But that's nit-picking.
Applied, thanks!
Rusty.
> +
> /* This just allows us to keep track of which parameters are kmalloced. */
> struct kmalloced_param {
> struct list_head list;
> char val[];
> };
> static LIST_HEAD(kmalloced_params);
> +static DEFINE_SPINLOCK(kmalloced_params_lock);
>
> static void *kmalloc_parameter(unsigned int size)
> {
> @@ -43,7 +48,10 @@ static void *kmalloc_parameter(unsigned int size)
> if (!p)
> return NULL;
>
> + spin_lock(_params_lock);
> list_add(>list, _params);
> + spin_unlock(_params_lock);
> +
> return p->val;
> }
>
> @@ -52,6 +60,7 @@ static void maybe_kfree_parameter(void *param)
> {
> struct kmalloced_param *p;
>
> + spin_lock(_params_lock);
> list_for_each_entry(p, _params, list) {
> if (p->val == param) {
> list_del(>list);
> @@ -59,6 +68,7 @@ static void maybe_kfree_parameter(void *param)
> break;
> }
> }
> + spin_unlock(_params_lock);
> }
>
> static char dash2underscore(char c)
> @@ -118,10 +128,10 @@ static int parse_one(char *param,
> return -EINVAL;
> pr_debug("handling %s with %p\n", param,
> params[i].ops->set);
> - mutex_lock(_lock);
> + kernel_param_lock(params[i].mod);
> param_check_unsafe([i]);
> err = params[i].ops->set(val, [i]);
> - mutex_unlock(_lock);
> + kernel_param_unlock(params[i].mod);
> return err;
> }
> }
> @@ -364,12 +374,11 @@ EXPORT_SYMBOL(param_ops_invbool);
>
> int param_set_bint(const char *val, const struct kernel_param *kp)
> {
> - struct kernel_param boolkp;
> + /* Match bool exactly, by re-using it. */
> + struct kernel_param boolkp = *kp;
> bool v;
> int ret;
>
> - /* Match bool exactly, by re-using it. */
> - boolkp = *kp;
> boolkp.arg =
>
> ret = param_set_bool(val, );
> @@ -387,7 +396,8 @@ struct kernel_param_ops param_ops_bint = {
> EXPORT_SYMBOL(param_ops_bint);
>
> /* We break the rule and mangle the string. */
> -static int param_array(const char *name,
> +static int param_array(struct module *mod,
> +const char *name,
> const char *val,
> unsigned int min, unsigned int max,
> void *elem, int elemsize,
> @@ -418,7 +428,7 @@ static int param_array(const char *name,
> /* nul-terminate and parse */
> save = val[len];
> ((char *)val)[len] = '\0';
> - BUG_ON(!mutex_is_locked(_lock));
> + BUG_ON(!KPARAM_IS_LOCKED(mod));
> ret = set(val, );
>
> if (ret != 0)
> @@ -440,7 +450,7 @@ static int param_array_set(const char *val, const struct
> kernel_param *kp)
> const struct kparam_array *arr = kp->arr;
> unsigned int temp_num;
>
> - return param_array(kp->name, val, 1, arr->max, arr->elem,
> + return param_array(kp->mod, kp->name, val, 1, arr->max, arr->elem,
> arr->elemsize, arr->ops->set, kp->level,
> arr->num ?: _num);
> }
> @@ -449,14 +459,13 @@ static int param_array_get(char *buffer, const struct
> kernel_param *kp)
> {
> int i, off, ret;
> const struct kparam_array *arr = kp->arr;
> - struct kernel_param p;
> + struct kernel_param p = *kp;
>
> - p = *kp;
> for (i = off = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> if (i)
> buffer[off++] = ',';
> p.arg = arr->elem + arr->elemsize * i;
> - BUG_ON(!mutex_is_locked(_lock));
> + BUG_ON(!KPARAM_IS_LOCKED(p.mod));
>
Re: [PATCH] kernel/params.c: make use of unused but set variable
Tejun Heo writes:
> On Fri, Jun 12, 2015 at 10:57:24AM +0930, Rusty Russell wrote:
>> Linus Torvalds writes:
>> > On Sun, Jun 7, 2015 at 5:00 PM, Tejun Heo wrote:
>> > At most, it could be a "WARN_ON_ONCE()". Maybe even just silently
>> > ignore the error. But BUG_ON()? Hell no.
>>
>> Yeah, in practice it's already (1) paniced if we ran out of memory, or
>> (2) warned if we somehow tried to create two entries with the same name.
>>
>> So the WARN_ON_ONCE() is a bit... meh. How's this, too snarky?
>
> Sounds pretty passive agressive to me. At least reply to the actual
> argument?
Oh. Perhaps my sense of humour is miscalibrated.
err = sysfs_create_file(>kobj, >mattr.attr);
+ /*
+* That should not fail at boot due to OOM, and it'll
+* already warn if we somehow get two identical names,
+* but this one line should quiet both gcc and lkml.
+*/
+ WARN_ON_ONCE(err);
Oh well, I'll skip the inline commentry entirely then:
===
Subject: params: suppress unused variable error, warn once just in case code
changes.
It shouldn't fail due to OOM (it's boot time), and already warns if we
get two identical names. But you never know what the future holds, and
WARN_ON_ONCE() keeps gcc happy with minimal code.
Reported-by: Louis Langholtz
Signed-off-by: Rusty Russell
diff --git a/kernel/params.c b/kernel/params.c
index 7edf31f2ce96..0b9bbdf830cb 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -884,6 +884,7 @@ static void __init version_sysfs_builtin(void)
mk = locate_module_kobject(vattr->module_name);
if (mk) {
err = sysfs_create_file(>kobj, >mattr.attr);
+ WARN_ON_ONCE(err);
kobject_uevent(>kobj, KOBJ_ADD);
kobject_put(>kobj);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/12] mm: mirrored memory support for page buddy allocations
On Fri, Jun 12, 2015 at 12:03:35PM -0700, Luck, Tony wrote: > On Fri, Jun 12, 2015 at 08:42:33AM +, Naoya Horiguchi wrote: > > 4?) I don't have the whole picture of how address ranging mirroring works, > > but I'm curious about what happens when an uncorrected memory error happens > > on the a mirror page. If HW/FW do some useful work invisible from kernel, > > please document it somewhere. And my questions are: > > - can the kernel with this patchset really continue its operation without > >breaking consistency? More specifically, the corrupted page is replaced > > with > >its mirror page, but can any other pages which have references (like > > struct > >page or pfn) for the corrupted page properly switch these references to > > the > >mirror page? Or no worry about that? (This is difficult for kernel pages > >like slab, and that's why currently hwpoison doesn't handle any kernel > > pages.) > > The mirror is operated by h/w (perhaps with some platform firmware > intervention when things start breaking badly). > > In normal operation there are two DIMM addresses backing each > system physical address in the mirrored range (thus total system > memory capacity is reduced when mirror is enabled). Memory writes > are directed to both locations. Memory reads are interleaved to > maintain bandwidth, so could come from either address. I misunderstood that both of mirrored page and mirroring page are visible to OS, which is incorrect. > When a read returns with an ECC failure the h/w automatically: > 1) Re-issues the read to the other DIMM address. If that also fails - then > we do the normal machine check processing for an uncorrected error > 2) But if the other side of the mirror is good, we can send the good > data to the reader (cpu, or dma) and, in parallel try to fix the > bad side by writing the good data to it. > 3) A corrected error will be logged, it may indicate whether the > attempt to fix succeeded or not. > 4) If platform firmware wants, it can be notified of the correction > and it may keep statistics on the rate of errors, correction status, > etc. If things get very bad it may "break" the mirror and direct > all future reads to the remaining "good" side. If does this it will > likely tell the OS via some ACPI method. Thanks, this fully answered my question. > All of this is done at much less than page granularity. Cache coherence > is maintained ... apart from some small performance glitches and the corrected > error logs, the OS is unware of all of this. > > Note that in current implementations the mirror copies are both behind > the same memory controller ... so this isn't intended to cope with high > level failure of a memory controller ... just to deal with randomly > distributed ECC errors. OK, I looked at "Memory Address Range Mirroring Validation Guide" and Fig 2-2 clearly shows that. > > - How can we test/confirm that the whole scheme works fine? Is current > > memory > >error injection framework enough? > > Still working on that piece. To validate you need to be able to > inject errors to just one side of the mirror, and I'm not really > sure that the ACPI/EINJ interface is up to the task. OK. Thanks, Naoya Horiguchi-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Suspicious RCU usage in linux-next: Bisected to commit 8d52d399
On Sun, Jun 14, 2015 at 06:06:21PM -0500, Larry Finger wrote:
> When booting kernels from Linux-next, the following is output:
>
> [2.816564] ===
> [2.816986] [ INFO: suspicious RCU usage. ]
> [2.817402] 4.1.0-rc7-next-20150612 #1 Not tainted
> [2.817881] ---
> [2.818297] kernel/sched/core.c:7318 Illegal context switch in
> RCU-bh read-side critical section!
> [2.819180]
> other info that might help us debug this:
>
> [2.819947]
> rcu_scheduler_active = 1, debug_locks = 0
> [2.820578] 3 locks held by systemd/1:
> [2.820954] #0: (rtnl_mutex){+.+.+.}, at: []
> rtnetlink_rcv+0x1f/0x40
> [2.821855] #1: (rcu_read_lock_bh){..}, at:
> [] ipv6_add_addr+0x62/0x540
> [2.822808] #2: (addrconf_hash_lock){+...+.}, at:
> [] ipv6_add_addr+0x184/0x540
> [2.823790]
> stack backtrace:
> [2.824212] CPU: 0 PID: 1 Comm: systemd Not tainted
> 4.1.0-rc7-next-20150612 #1
> [2.824932] Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS
> Version 4.20 04/17/2014
> [2.825751] 0001 880224e07838 817263a4
> 810ccf2a
> [2.826560] 880224e08000 880224e07868 810b6827
>
> [2.827368] 81a445d3 04f4 88022682e100
> 880224e07898
> [2.828177] Call Trace:
> [2.828422] [] dump_stack+0x4c/0x6e
> [2.828937] [] ? console_unlock+0x1ca/0x510
> [2.829514] [] lockdep_rcu_suspicious+0xe7/0x120
> [2.830139] [] ___might_sleep+0x1d5/0x1f0
> [2.830699] [] __might_sleep+0x4d/0x90
> [2.831239] [] ? create_object+0x39/0x2e0
> [2.831800] [] kmem_cache_alloc+0x47/0x250
> [2.832375] [] ? find_next_zero_bit+0x1e/0x20
> [2.832973] [] create_object+0x39/0x2e0
> [2.833515] [] ? mark_held_locks+0x66/0x90
> [2.834089] [] ? _raw_spin_unlock_irqrestore+0x4b/0x60
> [2.834761] [] kmemleak_alloc_percpu+0x61/0xe0
It seems to be a problem specific to kmemleak_alloc_percpu()
which does not get the 'gfp' param from pcpu_alloc. The comment from
kmemleak_alloc_percpu():
/*
* This function is called from the kernel percpu allocator when a new object
* (memory block) is allocated (alloc_percpu). It assumes GFP_KERNEL
* allocation.
*/
I will try out a change tomorrow.
--Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: vf610: Extend I2C support to all available buses.
This commit extends the existing Vybrid I2C support to cover buses i2c1,
i2c2, and i2c3. Based in (very) large part on an initial patch by
Stefan Agner that was just lacking a couple of DMA assignments.
Signed-off-by: Cory Tusar
---
arch/arm/boot/dts/vfxxx.dtsi | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..25f2615 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -347,6 +347,20 @@
status = "disabled";
};
+ i2c1: i2c@40067000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-i2c";
+ reg = <0x40067000 0x1000>;
+ interrupts = <72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_I2C1>;
+ clock-names = "ipg";
+ dmas = < 0 52>,
+ < 0 53>;
+ dma-names = "rx","tx";
+ status = "disabled";
+ };
+
clks: ccm@4006b000 {
compatible = "fsl,vf610-ccm";
reg = <0x4006b000 0x1000>;
@@ -520,6 +534,33 @@
status = "disabled";
};
+ i2c2: i2c@400e6000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-i2c";
+ reg = <0x400e6000 0x1000>;
+ interrupts = <73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_I2C2>;
+ clock-names = "ipg";
+ dmas = < 1 36>,
+ < 1 37>;
+ dma-names = "rx","tx";
+ status = "disabled";
+ };
+
+ i2c3: i2c@400e7000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-i2c";
+ reg = <0x400e7000 0x1000>;
+ interrupts = <74 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_I2C3>;
+ clock-names = "ipg";
+ dmas = < 1 38>,
+ < 1 39>;
+ dma-names = "rx","tx";
+ status = "disabled";
+ };
};
};
};
--
2.3.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 kernel] powerpc/powernv/ioda2: Add devices only from buses which belong to PE
On Fri, Jun 12, 2015 at 08:06:43AM -0700, Nishanth Aravamudan wrote: >On 12.06.2015 [16:47:03 +1000], Gavin Shan wrote: >> On Fri, Jun 12, 2015 at 04:19:17PM +1000, Alexey Kardashevskiy wrote: >> >The existing code puts all devices from a root PE to the same IOMMU group. >> >However it is a possible situation when subordinate buses belong to >> >separate PEs, in this case devices from these subordinate buses >> >should be added to lower level PE rather to the root PE. >> > >> >This limits pnv_ioda_setup_bus_dma() invocation to only PEs which own >> >all subordinate buses. >> > >> >Suggested-by: Gavin Shan >> >Signed-off-by: Alexey Kardashevskiy >> >> Alexey, I think it's good candidate for stable. > >Why? This commit message doesn't imply there is a serious bug just a >"possible" (does that mean theoretical?) situtation and the following: > The problem depends on the PCI topology. Below topology, existing on firestone machine, is one of the cases that wrong IOMMU group is used for devices behind the upstream port of the PCIe switch: The PE for Bus#2 has same IOMMU group as that one of the PE for "Root Bus" wrongly here. | +---+ (Root Bus) | | [ Root Port ][ System Peripheral ] + | (Bus#1) + [ Up Port ] + | ++---+ (Bus#2) || [ Dn port][ Dn Port] >> >This would be nice to have together with the DDW patchset. >> >This does not fix anything DDW patchset did, it fixes IOMMU >> >groups management which is essential for the whole feature to work. > >implies it is both related and independent of DDW? > The problem is independent of DDW. Thanks, Gavin >-Nish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
On 14.06.2015 19:24, Anand Moon wrote:
> This changes enables TMU IP block on the Exynos5422 Odroid-XU3
> device.
>
> Signed-off-by: Anand Moon
> Tested-by: Markus Reichl
This does not look right.
You put this "Tested-by" since beginning of this patchset (v1) but first
it was LDO10. Then you proposed LDO18 and now you use LDO7 from my
suggestion. Which of this was tested by Markus because I cannot find his
emails with it on LKML?
Krzysztof
> Acked-by: Lukasz Majewski
> ---
> Changes rebase on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
> for-next
> Changes from v5: Use LDO7 regulator instead of LD010.
>
> The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
>
> I think the schematics are missing some of details but it can be deducted
> that:
> 1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
> pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
> 2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
> S2MPS11 PMIC.
> 3. I confirmed with the Exynos5422 datasheet that these
> VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
>
> So the LDO7 it is... but before using it there is a caveat. The LDO7
> is also connected to VDD of MIPI, HDMI and few more. So when you use
> this regulator in TMU it may be turned off by TMU driver (e.g. during
> unbind). In such case these other blocks also should be tested and
> checked whether they take this regulator and enable it.
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25
> ++
> 1 file changed, 25 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv6 4/4] ARM: dts: exynos5422-odroidxu3: Enable thermal-zones
On 14.06.2015 19:24, Anand Moon wrote: > Include exynos5422-cpu-thermal.dtsi to enable thermal_zone support. > > Signed-off-by: Anand Moon > Tested-by: Markus Reichl > Acked-by: Lukasz Majewski > --- > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 + > 1 file changed, 1 insertion(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv6 2/4] ARM: dts: exynos5422-odroidxu3: Enable TMU at Exynos5422 base
On 14.06.2015 19:24, Anand Moon wrote:
> This changes enables TMU IP block on the Exynos5422 Odroid-XU3
> device.
>
> Signed-off-by: Anand Moon
> Tested-by: Markus Reichl
> Acked-by: Lukasz Majewski
> ---
> Changes rebase on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung branch
> for-next
> Changes from v5: Use LDO7 regulator instead of LD010.
>
> The output of LDO18 goes to VDD_EMMC_1V8. This is not regulator for TMU.
>
> I think the schematics are missing some of details but it can be deducted
> that:
> 1. TEMP SE is supplied by VDD18_TS power domain. It consists of 5
> pairs of pins (XTSTEST_OUT[0-4], XTSEXT_RES[0-4]).
> 2. The VDD18_TS01, VDD18_TS23 and VDD18_TS4 are wired to the LDO7 of
> S2MPS11 PMIC.
> 3. I confirmed with the Exynos5422 datasheet that these
> VDD18_TS{01,23,4} supply the XTSTEST pins (OUT and RES).
>
> So the LDO7 it is... but before using it there is a caveat. The LDO7
> is also connected to VDD of MIPI, HDMI and few more. So when you use
> this regulator in TMU it may be turned off by TMU driver (e.g. during
> unbind). In such case these other blocks also should be tested and
> checked whether they take this regulator and enable it.
Why did you took my email and pasted it here?
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/343702.html
It is written now in first person so it pretends that you wrote this.
You are actually doing this for second time - taking my
reply and putting into commit message or changelog. Why?
And where is proper changelog?
Krzysztof
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 25
> ++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index a2f9941..b6570fc 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -474,6 +474,31 @@
> status = "okay";
> };
>
> +_cpu0 {
> + vtmu-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_cpu1 {
> + vtmu-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_cpu2 {
> + vtmu-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_cpu3 {
> + vtmu-supply = <_reg>;
> + status = "okay";
> +};
> +
> +_gpu {
> + vtmu-supply = <_reg>;
> + status = "okay";
> +};
> +
> {
> status = "okay";
> clocks = < CLK_RTC>, <_osc S2MPS11_CLK_AP>;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 23:24 +0800, Daniel J Blueman wrote: > val=0x$(setpci -s 00:18.3 0xd4.l) # read D18F3xD4 > val=$((val &~(1 << 13))) # clear bit13 (MTC1eEn) > setpci -d 1022:1603 0xd4.l=$(printf %x $val) # write back This slows down the whole system dramatically: - before: MTC1eEn set: Booting takes 11 secs - after : MTC1eEn cleared: Booting takes 53 secs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspicious RCU usage in linux-next: Bisected to commit 8d52d399
When booting kernels from Linux-next, the following is output:
[2.816564] ===
[2.816986] [ INFO: suspicious RCU usage. ]
[2.817402] 4.1.0-rc7-next-20150612 #1 Not tainted
[2.817881] ---
[2.818297] kernel/sched/core.c:7318 Illegal context switch in RCU-bh
read-side critical section!
[2.819180]
other info that might help us debug this:
[2.819947]
rcu_scheduler_active = 1, debug_locks = 0
[2.820578] 3 locks held by systemd/1:
[2.820954] #0: (rtnl_mutex){+.+.+.}, at: []
rtnetlink_rcv+0x1f/0x40
[2.821855] #1: (rcu_read_lock_bh){..}, at: []
ipv6_add_addr+0x62/0x540
[2.822808] #2: (addrconf_hash_lock){+...+.}, at: []
ipv6_add_addr+0x184/0x540
[2.823790]
stack backtrace:
[2.824212] CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612
#1
[2.824932] Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20
04/17/2014
[2.825751] 0001 880224e07838 817263a4
810ccf2a
[2.826560] 880224e08000 880224e07868 810b6827
[2.827368] 81a445d3 04f4 88022682e100
880224e07898
[2.828177] Call Trace:
[2.828422] [] dump_stack+0x4c/0x6e
[2.828937] [] ? console_unlock+0x1ca/0x510
[2.829514] [] lockdep_rcu_suspicious+0xe7/0x120
[2.830139] [] ___might_sleep+0x1d5/0x1f0
[2.830699] [] __might_sleep+0x4d/0x90
[2.831239] [] ? create_object+0x39/0x2e0
[2.831800] [] kmem_cache_alloc+0x47/0x250
[2.832375] [] ? find_next_zero_bit+0x1e/0x20
[2.832973] [] create_object+0x39/0x2e0
[2.833515] [] ? mark_held_locks+0x66/0x90
[2.834089] [] ? _raw_spin_unlock_irqrestore+0x4b/0x60
[2.834761] [] kmemleak_alloc_percpu+0x61/0xe0
[2.835369] [] pcpu_alloc+0x370/0x630
[2.835900] [] ? dst_ifdown+0x41/0x90
[2.836425] [] __alloc_percpu_gfp+0x12/0x20
[2.837008] [] ip6_dst_alloc.isra.41+0x30/0xa0
[2.837610] [] addrconf_dst_alloc+0x3d/0xf0
[2.838191] [] ipv6_add_addr+0x27c/0x540
[2.838743] [] ? ipv6_add_addr+0x62/0x540
[2.839307] [] inet6_addr_add+0x11b/0x260
[2.839872] [] inet6_rtm_newaddr+0x343/0x450
[2.840457] [] ? __lock_acquire+0x53d/0x1510
[2.841048] [] rtnetlink_rcv_msg+0x95/0x240
[2.841625] [] ? trace_hardirqs_on+0xd/0x10
[2.860830] [] ? rtnetlink_rcv+0x1f/0x40
[2.879948] [] ? rtnetlink_rcv+0x40/0x40
[2.898849] [] netlink_rcv_skb+0xaf/0xc0
[2.917687] [] rtnetlink_rcv+0x2e/0x40
[2.936468] [] netlink_unicast+0x14c/0x1f0
[2.955266] [] netlink_sendmsg+0x320/0x3a0
[2.973517] [] ? __might_fault+0x4d/0xa0
[2.991353] [] sock_sendmsg+0x38/0x50
[3.009172] [] SYSC_sendto+0xef/0x170
[3.026925] [] ? up_write+0x23/0x50
[3.045032] [] ? lockdep_sys_exit_thunk+0x12/0x14
[3.063189] [] SyS_sendto+0xe/0x10
[3.081227] [] entry_SYSCALL_64_fastpath+0x12/0x6f
The above splat is followed by several "BUG: sleeping function called from
invalid context at mm/slub.c:1268" messages, but these are probably secondary.
The most recent commit was d9b5ec5b1b4d4055e256674de4a5337f6a66d284.
This problem has been bisected to the following:
commit d52d3997f843ffefaa8d8462790ffcaca6c74192
Author: Martin KaFai Lau
Date: Fri May 22 20:56:06 2015 -0700
ipv6: Create percpu rt6_info
After the patch
'ipv6: Only create RTF_CACHE routes after encountering pmtu exception',
we need to compensate the performance hit (bouncing dst->__refcnt).
Signed-off-by: Martin KaFai Lau
Cc: Hannes Frederic Sowa
Cc: Steffen Klassert
Cc: Julian Anastasov
Signed-off-by: David S. Miller
I will be happy to test any suggested patches.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: lockup when C1E and high-resolution timers enabled
> > already using latest microcode: > > > > [0.514490] microcode: CPU0: patch_level=0x06000822 > > [0.514497] microcode: CPU1: patch_level=0x06000822 > > [0.514508] microcode: CPU2: patch_level=0x06000822 > > [0.514519] microcode: CPU3: patch_level=0x06000822 > > [0.514529] microcode: CPU4: patch_level=0x06000822 > > [0.514540] microcode: CPU5: patch_level=0x06000822 > > [0.514550] microcode: CPU6: patch_level=0x06000822 > > [0.514561] microcode: CPU7: patch_level=0x06000822 > > This is not the latest microcode. > so what changed? nice catch, my bad -- forgot to post all microcode messages. $ dmesg | grep microcode: [0.514422] microcode: CPU0: patch_level=0x06000822 [0.514429] microcode: CPU1: patch_level=0x06000822 [0.514440] microcode: CPU2: patch_level=0x06000822 [0.514450] microcode: CPU3: patch_level=0x06000822 [0.514460] microcode: CPU4: patch_level=0x06000822 [0.514493] microcode: CPU5: patch_level=0x06000822 [0.514502] microcode: CPU6: patch_level=0x06000822 [0.514513] microcode: CPU7: patch_level=0x06000822 [0.514557] microcode: Microcode Update Driver: v2.00 , Peter Oruba [3.909642] microcode: CPU0: new patch_level=0x06000832 [3.940694] microcode: CPU2: new patch_level=0x06000832 [3.955187] microcode: CPU4: new patch_level=0x06000832 [3.963403] microcode: CPU6: new patch_level=0x06000832 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/16] staging: rtl8192e: Remove rtllib_wx_get_encode_ext()
This function was declared but never unused.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h| 3 --
drivers/staging/rtl8192e/rtllib_wx.c | 57
2 files changed, 60 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 4b6ccb8..6d6e637 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -2153,9 +2153,6 @@ extern int rtllib_wx_get_encode(struct rtllib_device
*ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
#if WIRELESS_EXT >= 18
-extern int rtllib_wx_get_encode_ext(struct rtllib_device *ieee,
- struct iw_request_info *info,
- union iwreq_data *wrqu, char *extra);
extern int rtllib_wx_set_encode_ext(struct rtllib_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra);
diff --git a/drivers/staging/rtl8192e/rtllib_wx.c
b/drivers/staging/rtl8192e/rtllib_wx.c
index f31d864..967ba8b 100644
--- a/drivers/staging/rtl8192e/rtllib_wx.c
+++ b/drivers/staging/rtl8192e/rtllib_wx.c
@@ -682,63 +682,6 @@ done:
}
EXPORT_SYMBOL(rtllib_wx_set_encode_ext);
-int rtllib_wx_get_encode_ext(struct rtllib_device *ieee,
- struct iw_request_info *info,
- union iwreq_data *wrqu, char *extra)
-{
- struct iw_point *encoding = >encoding;
- struct iw_encode_ext *ext = (struct iw_encode_ext *)extra;
- struct lib80211_crypt_data *crypt;
- int idx, max_key_len;
-
- max_key_len = encoding->length - sizeof(*ext);
- if (max_key_len < 0)
- return -EINVAL;
-
- idx = encoding->flags & IW_ENCODE_INDEX;
- if (idx) {
- if (idx < 1 || idx > NUM_WEP_KEYS)
- return -EINVAL;
- idx--;
- } else {
- idx = ieee->crypt_info.tx_keyidx;
- }
- if (!(ext->ext_flags & IW_ENCODE_EXT_GROUP_KEY) &&
- (ext->alg != IW_ENCODE_ALG_WEP))
- if (idx != 0 || (ieee->iw_mode != IW_MODE_INFRA))
- return -EINVAL;
-
- crypt = ieee->crypt_info.crypt[idx];
-
- encoding->flags = idx + 1;
- memset(ext, 0, sizeof(*ext));
-
- if (crypt == NULL || crypt->ops == NULL) {
- ext->alg = IW_ENCODE_ALG_NONE;
- ext->key_len = 0;
- encoding->flags |= IW_ENCODE_DISABLED;
- } else {
- if (strcmp(crypt->ops->name, "R-WEP") == 0)
- ext->alg = IW_ENCODE_ALG_WEP;
- else if (strcmp(crypt->ops->name, "R-TKIP"))
- ext->alg = IW_ENCODE_ALG_TKIP;
- else if (strcmp(crypt->ops->name, "R-CCMP"))
- ext->alg = IW_ENCODE_ALG_CCMP;
- else
- return -EINVAL;
- ext->key_len = crypt->ops->get_key(ext->key, SCM_KEY_LEN,
- NULL, crypt->priv);
- encoding->flags |= IW_ENCODE_ENABLED;
- if (ext->key_len &&
- (ext->alg == IW_ENCODE_ALG_TKIP ||
-ext->alg == IW_ENCODE_ALG_CCMP))
- ext->ext_flags |= IW_ENCODE_EXT_TX_SEQ_VALID;
-
- }
-
- return 0;
-}
-
int rtllib_wx_set_mlme(struct rtllib_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra)
--
1.8.4.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 08/16] staging: rtl8192e: Remove rtllib_is_shortslot()
This function was declared but never unused.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h | 1 -
drivers/staging/rtl8192e/rtllib_softmac.c | 5 -
2 files changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index b4eb24e..4b6ccb8 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -2170,7 +2170,6 @@ extern int rtllib_wx_set_gen_ie(struct rtllib_device
*ieee, u8 *ie, size_t len);
/* rtllib_softmac.c */
extern short rtllib_is_54g(struct rtllib_network *net);
-extern short rtllib_is_shortslot(const struct rtllib_network *net);
extern int rtllib_rx_frame_softmac(struct rtllib_device *ieee,
struct sk_buff *skb,
struct rtllib_rx_stats *rx_stats, u16 type,
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index a123772..dc3fc12 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -28,11 +28,6 @@ short rtllib_is_54g(struct rtllib_network *net)
return (net->rates_ex_len > 0) || (net->rates_len > 4);
}
-short rtllib_is_shortslot(const struct rtllib_network *net)
-{
- return net->capability & WLAN_CAPABILITY_SHORT_SLOT_TIME;
-}
-
/* returns the total length needed for placing the RATE MFIE
* tag and the EXTENDED RATE MFIE tag if needed.
* It encludes two bytes per tag for the tag itself and its len
--
1.8.4.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 11/16] staging: rtl8192e: Remove WIRELESS_EXT checks
Current WIRELESS_EXT version is at least 22.
Resolve ifdefs and delete dead code.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 22cbd45..f785e84 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -421,16 +421,6 @@ struct ieee_param {
} u;
};
-
-#if WIRELESS_EXT < 17
-#define IW_QUAL_QUAL_INVALID 0x10
-#define IW_QUAL_LEVEL_INVALID 0x20
-#define IW_QUAL_NOISE_INVALID 0x40
-#define IW_QUAL_QUAL_UPDATED 0x1
-#define IW_QUAL_LEVEL_UPDATED 0x2
-#define IW_QUAL_NOISE_UPDATED 0x4
-#endif
-
#define msleep_interruptible_rsl msleep_interruptible
/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section
@@ -2151,11 +2141,9 @@ extern int rtllib_wx_set_encode(struct rtllib_device
*ieee,
extern int rtllib_wx_get_encode(struct rtllib_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
-#if WIRELESS_EXT >= 18
extern int rtllib_wx_set_encode_ext(struct rtllib_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra);
-#endif
extern int rtllib_wx_set_auth(struct rtllib_device *ieee,
struct iw_request_info *info,
struct iw_param *data, char *extra);
--
1.8.4.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 14/16] staging: rtl8192e: Remove unused rtllib_device members
Delete several members of rtllib_device including
their initializers if needed.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 --
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 1 -
drivers/staging/rtl8192e/rtllib.h| 12
drivers/staging/rtl8192e/rtllib_module.c | 3 ---
drivers/staging/rtl8192e/rtllib_softmac.c| 6 --
5 files changed, 28 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 71289ca..49110d3 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1059,8 +1059,6 @@ static void rtl8192_init_priv_handler(struct net_device
*dev)
priv->rtllib->UpdateBeaconInterruptHandler = NULL;
priv->rtllib->ScanOperationBackupHandler = PHY_ScanOperationBackup8192;
-
- priv->rtllib->rtllib_rfkill_poll = NULL;
}
static void rtl8192_init_priv_constant(struct net_device *dev)
@@ -1080,7 +1078,6 @@ static void rtl8192_init_priv_variable(struct net_device
*dev)
priv->AcmMethod = eAcmWay2_SW;
priv->dot11CurrentPreambleMode = PREAMBLE_AUTO;
- priv->rtllib->hwscan_sem_up = 1;
priv->rtllib->status = 0;
priv->polling_timer_on = 0;
priv->up_first_time = 1;
@@ -1150,10 +1147,7 @@ static void rtl8192_init_priv_variable(struct net_device
*dev)
priv->rtllib->host_encrypt = 1;
priv->rtllib->host_decrypt = 1;
- priv->rtllib->dot11PowerSaveMode = eActive;
priv->rtllib->fts = DEFAULT_FRAG_THRESHOLD;
- priv->rtllib->MaxMssDensity = 0;
- priv->rtllib->MinSpaceCfg = 0;
priv->card_type = PCI;
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 8532e0c..1b21f38 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -1812,7 +1812,6 @@ static void dm_init_ctstoself(struct net_device *dev)
struct r8192_priv *priv = rtllib_priv((struct net_device *)dev);
priv->rtllib->bCTSToSelfEnable = true;
- priv->rtllib->CTSToSelfTH = CTSToSelfTHVal;
}
static void dm_ctstoself(struct net_device *dev)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 49f31ec..f3a4bbc 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1538,8 +1538,6 @@ struct rtllib_device {
bool disable_mgnt_queue;
unsigned long status;
- short hwscan_ch_bk;
- u8 hwscan_sem_up;
u8 CntAfterLink;
enum rt_op_mode OpMode;
@@ -1557,7 +1555,6 @@ struct rtllib_device {
bool ieee_up;
bool cannot_notify;
bool bSupportRemoteWakeUp;
- enum rt_ps_mode dot11PowerSaveMode;
bool actscanning;
bool FirstIe_InScan;
bool be_scan_inprogress;
@@ -1567,7 +1564,6 @@ struct rtllib_device {
bool is_set_key;
bool wx_set_enc;
struct rt_hi_throughput *pHTInfo;
- spinlock_t bw_spinlock;
spinlock_t reorder_spinlock;
u8 Regdot11HTOperationalRateSet[16];
@@ -1576,12 +1572,9 @@ struct rtllib_device {
u8 RegHTSuppRateSet[16];
u8 HTCurrentOperaRate;
u8 HTHighestOperaRate;
- u8 MinSpaceCfg;
- u8 MaxMssDensity;
u8 bTxDisableRateFallBack;
u8 bTxUseDriverAssingedRate;
u8 bTxEnableFwCalcDur;
- atomic_tatm_chnlop;
atomic_tatm_swbw;
struct list_headTx_TS_Admit_List;
@@ -1634,7 +1627,6 @@ struct rtllib_device {
int ieee802_1x; /* is IEEE 802.1X used */
/* WPA data */
- bool bHalfNMode;
bool bHalfWirelessN24GMode;
int wpa_enabled;
int drop_unencrypted;
@@ -1766,14 +1758,11 @@ struct rtllib_device {
u8 AsocRetryCount;
struct sk_buff_head skb_waitQ[MAX_QUEUE_SIZE];
struct sk_buff_head skb_aggQ[MAX_QUEUE_SIZE];
- u32 sta_edca_param[4];
bool aggregation;
- bool enable_rx_imm_BA;
boolbdynamic_txpower_enable;
bool bCTSToSelfEnable;
- u8 CTSToSelfTH;
u32 fsync_time_interval;
u32 fsync_rate_bitmap;
@@ -1929,7 +1918,6 @@ struct rtllib_device {
void (*rtllib_ips_leave_wq)(struct net_device *dev);
void (*rtllib_ips_leave)(struct net_device *dev);
void (*LeisurePSLeave)(struct net_device *dev);
- void (*rtllib_rfkill_poll)(struct net_device *dev);
/* This must be the last item so that it points to the data
* allocated beyond this structure by alloc_rtllib
diff --git a/drivers/staging/rtl8192e/rtllib_module.c
b/drivers/staging/rtl8192e/rtllib_module.c
index 845d9b8..578b41b 100644
--- a/drivers/staging/rtl8192e/rtllib_module.c
+++
[PATCH 13/16] staging: rtl8192e: Remove rt_pwr_save_ctrl members
Following members were removed:
- tmpJoinAction
- tmpSuppRateBuf
- bTmpIbpm
As a consequence several unused defines/enums/structs were
also removed from rtllib.h
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h | 36
1 file changed, 36 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 3895694..49f31ec 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1368,42 +1368,12 @@ enum ips_callback_function {
IPS_CALLBACK_JOIN_REQUEST = 2,
};
-enum rt_join_action {
- RT_JOIN_INFRA = 1,
- RT_JOIN_IBSS = 2,
- RT_START_IBSS = 3,
- RT_NO_ACTION = 4,
-};
-
-struct ibss_parms {
- u16 atimWin;
-};
-#define MAX_NUM_RATES 264
-
enum rt_rf_power_state {
eRfOn,
eRfSleep,
eRfOff
};
-#defineMAX_SUPPORT_WOL_PATTERN_NUM 8
-
-enum wol_pattern_type {
- eNetBIOS = 0,
- eIPv4IPv6ARP,
- eIPv4IPv6TCPSYN,
- eMACIDOnly,
- eNoDefined,
-};
-
-struct rt_pm_wol_info {
- u32 PatternId;
- u32 Mask[4];
- u16 CrcRemainder;
- u8 WFMIndex;
- enum wol_pattern_type PatternType;
-};
-
struct rt_pwr_save_ctrl {
boolbInactivePs;
@@ -1412,10 +1382,6 @@ struct rt_pwr_save_ctrl {
enum rt_rf_power_state eInactivePowerState;
enum ips_callback_function ReturnPoint;
- enum rt_join_action tmpJoinAction;
- u8 tmpSuppRateBuf[MAX_NUM_RATES];
- boolbTmpIbpm;
-
boolbLeisurePs;
u8 LpsIdleCount;
u8 RegMaxLPSAwakeIntvl;
@@ -1426,8 +1392,6 @@ struct rt_pwr_save_ctrl {
boolbFwCtrlLPS;
- struct rt_pm_wol_info PmWoLPatternInfo[MAX_SUPPORT_WOL_PATTERN_NUM];
-
};
#define RT_RF_CHANGE_SOURCE u32
--
1.8.4.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 10/16] staging: rtl8192e: Remove rtllib_device::get_nic_desc_num()
This function/callback was initialized and never called.
rtl8192_get_nic_desc_num() function that was default
implementation was also removed.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 17 -
drivers/staging/rtl8192e/rtllib.h| 1 -
2 files changed, 18 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 4c53c87..71289ca 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -440,22 +440,6 @@ bool MgntActSet_RF_State(struct net_device *dev,
return bActionAllowed;
}
-
-static short rtl8192_get_nic_desc_num(struct net_device *dev, int prio)
-{
- struct r8192_priv *priv = rtllib_priv(dev);
- struct rtl8192_tx_ring *ring = >tx_ring[prio];
-
- /* For now, we reserved two free descriptor as a safety boundary
- * between the tail and the head
- */
- if ((prio == MGNT_QUEUE) && (skb_queue_len(>queue) > 10))
- RT_TRACE(COMP_DBG,
-"-[%d]-ring->idx=%d
queue_len=%d-\n",
-prio, ring->idx, skb_queue_len(>queue));
- return skb_queue_len(>queue);
-}
-
static short rtl8192_check_nic_enough_desc(struct net_device *dev, int prio)
{
struct r8192_priv *priv = rtllib_priv(dev);
@@ -1046,7 +1030,6 @@ static void rtl8192_init_priv_handler(struct net_device
*dev)
priv->rtllib->data_hard_stop= rtl8192_data_hard_stop;
priv->rtllib->data_hard_resume = rtl8192_data_hard_resume;
priv->rtllib->check_nic_enough_desc = rtl8192_check_nic_enough_desc;
- priv->rtllib->get_nic_desc_num = rtl8192_get_nic_desc_num;
priv->rtllib->handle_assoc_response = rtl8192_handle_assoc_response;
priv->rtllib->handle_beacon = rtl8192_handle_beacon;
priv->rtllib->SetWirelessMode = rtl8192_SetWirelessMode;
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 6d6e637..22cbd45 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1952,7 +1952,6 @@ struct rtllib_device {
/* check whether Tx hw resource available */
short (*check_nic_enough_desc)(struct net_device *dev, int queue_index);
- short (*get_nic_desc_num)(struct net_device *dev, int queue_index);
void (*SetBWModeHandler)(struct net_device *dev,
enum ht_channel_width Bandwidth,
enum ht_extchnl_offset Offset);
--
1.8.4.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 12/16] staging: rtl8192e: Remove rtllib_network::last_associate
Variable was initialized and never used.
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h| 1 -
drivers/staging/rtl8192e/rtllib_rx.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index f785e84..3895694 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1246,7 +1246,6 @@ struct rtllib_network {
unsigned long last_scanned;
u8 mode;
u32 flags;
- u32 last_associate;
u32 time_stamp[2];
u16 beacon_interval;
u16 listen_interval;
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index 2bef1f6..48a188a 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -2326,7 +2326,6 @@ static inline int rtllib_network_init(
/* Where to pull this? beacon->listen_interval;*/
network->listen_interval = 0x0A;
network->rates_len = network->rates_ex_len = 0;
- network->last_associate = 0;
network->ssid_len = 0;
network->hidden_ssid_len = 0;
memset(network->hidden_ssid, 0, sizeof(network->hidden_ssid));
@@ -2504,7 +2503,6 @@ static inline void update_network(struct rtllib_device
*ieee,
dst->qos_data.active = qos_active;
dst->qos_data.old_param_count = old_param;
- /* dst->last_associate is not overwritten */
dst->wmm_info = src->wmm_info;
if (src->wmm_param[0].ac_aci_acm_aifsn ||
src->wmm_param[1].ac_aci_acm_aifsn ||
--
1.8.4.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 15/16] staging: rtl8192e: Remove softmac_hint11d_wq queue
This queue is never used, and function handler is empty
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h | 1 -
drivers/staging/rtl8192e/rtllib_softmac.c | 6 --
2 files changed, 7 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index f3a4bbc..74c2a28 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1794,7 +1794,6 @@ struct rtllib_device {
struct work_struct ips_leave_wq;
struct delayed_work associate_procedure_wq;
struct delayed_work softmac_scan_wq;
- struct delayed_work softmac_hint11d_wq;
struct delayed_work associate_retry_wq;
struct delayed_work start_ibss_wq;
struct delayed_work hw_wakeup_wq;
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 6d11205..3f4a932 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -492,10 +492,6 @@ void rtllib_send_probe_requests(struct rtllib_device
*ieee, u8 is_mesh)
}
}
-static void rtllib_softmac_hint11d_wq(void *data)
-{
-}
-
void rtllib_update_active_chan_map(struct rtllib_device *ieee)
{
memcpy(ieee->active_channel_map, GET_DOT11D_INFO(ieee)->channel_map,
@@ -3045,8 +3041,6 @@ void rtllib_softmac_init(struct rtllib_device *ieee)
(void *)rtllib_associate_procedure_wq, ieee);
INIT_DELAYED_WORK_RSL(>softmac_scan_wq,
(void *)rtllib_softmac_scan_wq, ieee);
- INIT_DELAYED_WORK_RSL(>softmac_hint11d_wq,
- (void *)rtllib_softmac_hint11d_wq, ieee);
INIT_DELAYED_WORK_RSL(>associate_retry_wq,
(void *)rtllib_associate_retry_wq, ieee);
INIT_WORK_RSL(>wx_sync_scan_wq, (void *)rtllib_wx_sync_scan_wq,
--
1.8.4.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 16/16] staging: rtl8192e: Remove rtllib_device::agregation
Variable is always true; Resolve condition where it is used
(and change indentation of conditional expression).
Signed-off-by: Mateusz Kulikowski
---
drivers/staging/rtl8192e/rtllib.h | 1 -
drivers/staging/rtl8192e/rtllib_rx.c | 52 ++-
drivers/staging/rtl8192e/rtllib_softmac.c | 1 -
3 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index 74c2a28..fd38c6d 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1758,7 +1758,6 @@ struct rtllib_device {
u8 AsocRetryCount;
struct sk_buff_head skb_waitQ[MAX_QUEUE_SIZE];
struct sk_buff_head skb_aggQ[MAX_QUEUE_SIZE];
- bool aggregation;
boolbdynamic_txpower_enable;
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index 48a188a..da862c3 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -1883,38 +1883,34 @@ static void rtllib_parse_mife_generic(struct
rtllib_device *ieee,
}
}
- if (ieee->aggregation) {
- if (network->bssht.bdSupportHT) {
- if (info_element->len >= 4 &&
- info_element->data[0] == 0x00 &&
- info_element->data[1] == 0xe0 &&
- info_element->data[2] == 0x4c &&
- info_element->data[3] == 0x02) {
- ht_realtek_agg_len = min_t(u8,
- info_element->len,
- MAX_IE_LEN);
- memcpy(ht_realtek_agg_buf,
- info_element->data,
- info_element->len);
- }
- if (ht_realtek_agg_len >= 5) {
- network->realtek_cap_exit = true;
- network->bssht.bdRT2RTAggregation = true;
-
- if ((ht_realtek_agg_buf[4] == 1) &&
- (ht_realtek_agg_buf[5] & 0x02))
- network->bssht.bdRT2RTLongSlotTime =
true;
-
- if ((ht_realtek_agg_buf[4] == 1) &&
- (ht_realtek_agg_buf[5] &
RT_HT_CAP_USE_92SE))
- network->bssht.RT2RT_HT_Mode |=
RT_HT_CAP_USE_92SE;
- }
+ if (network->bssht.bdSupportHT) {
+ if (info_element->len >= 4 &&
+ info_element->data[0] == 0x00 &&
+ info_element->data[1] == 0xe0 &&
+ info_element->data[2] == 0x4c &&
+ info_element->data[3] == 0x02) {
+ ht_realtek_agg_len = min_t(u8, info_element->len,
+ MAX_IE_LEN);
+ memcpy(ht_realtek_agg_buf, info_element->data,
+ info_element->len);
}
if (ht_realtek_agg_len >= 5) {
- if ((ht_realtek_agg_buf[5] & RT_HT_CAP_USE_SOFTAP))
- network->bssht.RT2RT_HT_Mode |=
RT_HT_CAP_USE_SOFTAP;
+ network->realtek_cap_exit = true;
+ network->bssht.bdRT2RTAggregation = true;
+
+ if ((ht_realtek_agg_buf[4] == 1) &&
+ (ht_realtek_agg_buf[5] & 0x02))
+ network->bssht.bdRT2RTLongSlotTime = true;
+
+ if ((ht_realtek_agg_buf[4] == 1) &&
+ (ht_realtek_agg_buf[5] & RT_HT_CAP_USE_92SE))
+ network->bssht.RT2RT_HT_Mode |=
RT_HT_CAP_USE_92SE;
}
}
+ if (ht_realtek_agg_len >= 5) {
+ if ((ht_realtek_agg_buf[5] & RT_HT_CAP_USE_SOFTAP))
+ network->bssht.RT2RT_HT_Mode |= RT_HT_CAP_USE_SOFTAP;
+ }
if ((info_element->len >= 3 &&
info_element->data[0] == 0x00 &&
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 3f4a932..444fac7 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -3017,7 +3017,6 @@ void rtllib_softmac_init(struct rtllib_device *ieee)
ieee->is_set_key = false;
init_mgmt_queue(ieee);
- ieee->aggregation = true;
ieee->tx_pending.txb = NULL;
_setup_timer(>associate_timer,
--
1.8.4.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
