Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: > > > > You haven't wired it up properly on powerpc, but I haven't mentioned it > > because > > I'd rather we did it. > > > > cheers > > It looks like I will be spinning a V5, so I will drop all but the x86 > system calls additions in that version. The MIPS bits are looking good however, so Acked-by: Ralf Baechle With my ack, will you keep them or maybe carry them as a separate patch? Cheers, Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 23
Hi all, Changes since 20150722: The ext4 tree gained a build failure so I used the version from next-20150722. The next-next tree gained a build failure so I used the version from next-20150722. The wireless-drivers-next tree still had its build failure so I used the version from next-20150721. The akpm-current tree gained a conflict against the ext3 tree Non-merge commits (relative to Linus' tree): 3380 3296 files changed, 145570 insertions(+), 83314 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 224 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (5a5ca73ac0a7 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0871b7248113 ARM: fix __virt_to_idmap build error on !MMU) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (bc0195aad0da Linux 4.2-rc2) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (d8b48911fd24 ravb: fix ring memory allocation) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (cba59972a119 ALSA: hda - Add headset mic pin quirk for a Dell device) Merging pci-current/for-linus (c9ddbac9c891 PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition) Merging wireless-drivers/master (df2cd4586f17 Merge tag 'iwlwifi-for-kalle-2015-06-12' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (52721d9d3334 Linux 4.2-rc3) Merging tty.current/tty-linus (52721d9d3334 Linux 4.2-rc3) Merging usb.current/usb-linus (1209544d8a2a USB: OHCI: fix bad #define in ohci-tmio.c) Merging usb-gadget-fixes/fixes (aebda6187181 usb: dwc3: Reset the transfer resource index on SET_INTERFACE) Merging usb-serial-fixes/usb-linus (09290f419223 USB: pl2303: fix baud-rate divisor calculations) Merging staging.current/staging-linus (52721d9d3334 Linux 4.2-rc3) Merging char-misc.current/char-misc-linus (52721d9d3334 Linux 4.2-rc3) Merging input-current/for-linus (d98399e688f8 Input: elantech - force resolution of 31 u/mm) Merging crypto-current/master (030f4e968741 crypto: nx - Fix reentrancy bugs) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (758556bdc1c8 module: Fix load_module() error path) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlig
Re: [PATCH 2/2] mm: rename and move get/set_freepage_migratetype
On Wed, Jul 22, 2015 at 02:29:08PM +0200, Vlastimil Babka wrote: > On 07/21/2015 02:53 PM, Vlastimil Babka wrote: > > The pair of get/set_freepage_migratetype() functions are used to cache > > pageblock migratetype for a page put on a pcplist, so that it does not have > > to be retrieved again when the page is put on a free list (e.g. when > > pcplists > > become full). Historically it was also assumed that the value is accurate > > for > > pages on freelists (as the functions' names unfortunately suggest), but that > > cannot be guaranteed without affecting various allocator fast paths. It is > > in > > fact not needed and all such uses have been removed. > > > > The last remaining (but pointless) usage related to pages of freelists is in > > move_freepages(), which this patch removes. > > I realized there's one more callsite that can be removed. Here's > whole updated patch due to different changelog and to cope with > context changed by the fixlet to patch 1/2. > > --8<-- > From: Vlastimil Babka > Date: Thu, 2 Jul 2015 16:37:06 +0200 > Subject: mm: rename and move get/set_freepage_migratetype > > The pair of get/set_freepage_migratetype() functions are used to cache > pageblock migratetype for a page put on a pcplist, so that it does not have > to be retrieved again when the page is put on a free list (e.g. when pcplists > become full). Historically it was also assumed that the value is accurate for > pages on freelists (as the functions' names unfortunately suggest), but that > cannot be guaranteed without affecting various allocator fast paths. It is in > fact not needed and all such uses have been removed. > > The last two remaining (but pointless) usages related to pages of freelists > are removed by this patch: > - move_freepages() which operates on pages already on freelists > - __free_pages_ok() which puts a page directly to freelist, bypassing pcplists > > To prevent further confusion, rename the functions to > get/set_pcppage_migratetype() and expand their description. Since all the > users are now in mm/page_alloc.c, move the functions there from the shared > header. > > Signed-off-by: Vlastimil Babka > Acked-by: David Rientjes > Cc: Joonsoo Kim > Cc: Minchan Kim > Cc: Michal Nazarewicz > Cc: Laura Abbott > Cc: Naoya Horiguchi > Cc: Kirill A. Shutemov > Cc: Mel Gorman > Cc: Johannes Weiner Reviewed-by: 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: [PATCH v5 7/7] powerpc/powernv: nest pmu cpumask and cpu hotplug support
On Thu, 2015-07-23 at 12:18 +0530, Madhavan Srinivasan wrote:
>
> On Wednesday 22 July 2015 10:33 AM, Daniel Axtens wrote:
> >> +static void nest_change_cpu_context(int old_cpu, int new_cpu)
> >> +{
> >> + int i;
> >> +
> >> + for (i = 0; per_nest_pmu_arr[i] != NULL; i++)
> >> + perf_pmu_migrate_context(&per_nest_pmu_arr[i]->pmu,
> >> + old_cpu, new_cpu);
> > From patch 4, I see per_nest_pmu_arr is defined as:
> > +static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
> >
> > Therefore, does this loop need to have a check that
> > i < P8_NEST_MAX_PMUS?
>
> No, that is max possible pmu, but we may have only couple for nest pmus
> registered.
>
What if we have P8_NEST_MAX_PMUS registered? Then we'll check beyond the
end of the array...
> Thanks for the review comments
> Maddy
> >
>
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
[RESEND PATCH] cpupower: Do not change the frequency of offline cpu
Check if the cpu is online before changing the frequency/governor of
the cpu.
Reported-by: Pavaman Subramaniyam
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
Acked-by: Thomas Renninger
---
Included Reported-by tag
tools/power/cpupower/utils/cpufreq-set.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/power/cpupower/utils/cpufreq-set.c
b/tools/power/cpupower/utils/cpufreq-set.c
index f656e58..4e21357 100644
--- a/tools/power/cpupower/utils/cpufreq-set.c
+++ b/tools/power/cpupower/utils/cpufreq-set.c
@@ -17,6 +17,7 @@
#include "cpufreq.h"
#include "helpers/helpers.h"
+#include "helpers/sysfs.h"
#define NORM_FREQ_LEN 32
@@ -318,6 +319,9 @@ int cmd_freq_set(int argc, char **argv)
cpufreq_cpu_exists(cpu))
continue;
+ if (sysfs_is_cpu_online(cpu) != 1)
+ continue;
+
printf(_("Setting cpu: %d\n"), cpu);
ret = do_one_cpu(cpu, &new_pol, freq, policychange);
if (ret) {
--
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 v5 7/7] powerpc/powernv: nest pmu cpumask and cpu hotplug support
On Wednesday 22 July 2015 10:33 AM, Daniel Axtens wrote:
>> +static void nest_change_cpu_context(int old_cpu, int new_cpu)
>> +{
>> +int i;
>> +
>> +for (i = 0; per_nest_pmu_arr[i] != NULL; i++)
>> +perf_pmu_migrate_context(&per_nest_pmu_arr[i]->pmu,
>> +old_cpu, new_cpu);
> From patch 4, I see per_nest_pmu_arr is defined as:
> +static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
>
> Therefore, does this loop need to have a check that
> i < P8_NEST_MAX_PMUS?
No, that is max possible pmu, but we may have only couple for nest pmus
registered.
Thanks for the review comments
Maddy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] serial: 8250_dw: Add UPF_SKIP_TEST to flags depend on device tree
On Thu, Jul 23, 2015 at 8:21 AM, Noam Camus wrote: > From: Peter Hurley [mailto:pe...@hurleysoftware.com] > Sent: Wednesday, July 22, 2015 3:21 PM > >>>On 07/22/2015 05:34 AM, Noam Camus wrote: >>> From: Noam Camus >>> >>> Add support for OF option "no-loopback-test" > >> Changes to devicetree need to at least get acks from DT maintainers. > I will add them in my v2 > Should I take this patch apart from this set or should I add DT maintainers > to whole set? Add them at least to your cover letter and this one specifically. It's a small set, so it's fine to add them to all patches, so they can see the bigger picture. No need to take this patch out of the set (and context). Frans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch V4 1/3] usb: Add Xen pvUSB protocol description
On 07/23/2015 06:36 AM, Greg KH wrote: On Thu, Jul 23, 2015 at 06:04:39AM +0200, Juergen Gross wrote: On 07/23/2015 01:46 AM, Greg KH wrote: On Tue, Jun 23, 2015 at 08:53:23AM +0200, Juergen Gross wrote: Add the definition of pvUSB protocol used between the pvUSB frontend in a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0). This header was originally provided by Fujitsu for Xen based on Linux 2.6.18. Changes are: - adapt to Linux style guide Signed-off-by: Juergen Gross --- include/xen/interface/io/usbif.h | 252 +++ Why is this a different interface than the existing ones we have today (i.e. usbip?) Where is it documented? Do the Xen developers / The interface definition is living in the Xen git repository for several years now: git://xenbits.xen.org/xen.git -> xen/include/public/io/usbif.h That's header file, not a document describing the api here. I suppose you want to tell me I should add something like: Documentation/DocBook/usb/API-struct-urb.html I can do this, of course. It is used e.g. in SUSE's xen kernel since 2.6.18. I am very aware of the amount of Xen crap in SuSE's kernel, don't use that as an excuse for me to merge it to mainline :) :-) Wasn't meant as an excuse, just a hint why the interface can't be the same as for usbip. We have to ensure compatibility with those kernels and possibly other operating systems (BSD?, Windows?) which already might be using pvUSB with a Dom0 based on the SUSE xen kernel. 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: [PATCH v9 3/7] staging: add bindings document for simple fpga bus
> +Optional properties: > +- fpga-mgr : should contain a phandle to a fpga manager. fpga->FPGA, globally. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cxl: Add alternate MMIO error handling
From: Ian Munsie
userspace programs using cxl currently have to use two strategies for
dealing with MMIO errors simultaneously. They have to check every read
for a return of all Fs in case the adapter has gone away and the kernel
has not yet noticed, and they have to deal with SIGBUS in case the
kernel has already noticed, invalidated the mapping and marked the
context as failed.
In order to simplify things, this patch adds an alternative approach
where the kernel will return a page filled with Fs instead of delivering
a SIGBUS. This allows userspace to only need to deal with one of these
two error paths, and is intended for use in libraries that use cxl
transparently and may not be able to safely install a signal handler.
This approach will only work if certain constraints are met. Namely, if
the application is both reading and writing to an address in the problem
state area it cannot assume that a non-FF read is OK, as it may just be
reading out a value it has previously written. Further - since only one
page is used per context a write to a given offset would be visible when
reading the same offset from a different page in the mapping (this only
applies within a single context, not between contexts).
An application could deal with this by e.g. making sure it also reads
from a read-only offset after any reads to a read/write offset.
Due to these constraints, this functionality must be explicitly
requested by userspace when starting the context by passing in the
CXL_START_WORK_ERR_FF flag.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/context.c | 14 ++
drivers/misc/cxl/cxl.h | 4 +++-
drivers/misc/cxl/file.c| 4 +++-
include/uapi/misc/cxl.h| 4 +++-
4 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 1287148..6570f10 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -126,6 +126,18 @@ static int cxl_mmap_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
if (ctx->status != STARTED) {
mutex_unlock(&ctx->status_mutex);
pr_devel("%s: Context not started, failing problem state
access\n", __func__);
+ if (ctx->mmio_err_ff) {
+ if (!ctx->ff_page) {
+ ctx->ff_page = alloc_page(GFP_USER);
+ if (!ctx->ff_page)
+ return VM_FAULT_OOM;
+ memset(page_address(ctx->ff_page), 0xff,
PAGE_SIZE);
+ }
+ get_page(ctx->ff_page);
+ vmf->page = ctx->ff_page;
+ vma->vm_page_prot = pgprot_cached(vma->vm_page_prot);
+ return 0;
+ }
return VM_FAULT_SIGBUS;
}
@@ -253,6 +265,8 @@ static void reclaim_ctx(struct rcu_head *rcu)
struct cxl_context *ctx = container_of(rcu, struct cxl_context, rcu);
free_page((u64)ctx->sstp);
+ if (ctx->ff_page)
+ __free_page(ctx->ff_page);
ctx->sstp = NULL;
kfree(ctx);
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 4fd66ca..b7293a4 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -34,7 +34,7 @@ extern uint cxl_verbose;
* Bump version each time a user API change is made, whether it is
* backwards compatible ot not.
*/
-#define CXL_API_VERSION 1
+#define CXL_API_VERSION 2
#define CXL_API_VERSION_COMPATIBLE 1
/*
@@ -418,6 +418,8 @@ struct cxl_context {
/* Used to unmap any mmaps when force detaching */
struct address_space *mapping;
struct mutex mapping_lock;
+ struct page *ff_page;
+ bool mmio_err_ff;
spinlock_t sste_lock; /* Protects segment table entries */
struct cxl_sste *sstp;
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index e3f4b69..34c7a5e 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers/misc/cxl/file.c
@@ -179,6 +179,8 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
if (work.flags & CXL_START_WORK_AMR)
amr = work.amr & mfspr(SPRN_UAMOR);
+ ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF);
+
/*
* We grab the PID here and not in the file open to allow for the case
* where a process (master, some daemon, etc) has opened the chardev on
@@ -519,7 +521,7 @@ int __init cxl_file_init(void)
* If these change we really need to update API. Either change some
* flags or update API version number CXL_API_VERSION.
*/
- BUILD_BUG_ON(CXL_API_VERSION != 1);
+ BUILD_BUG_ON(CXL_API_VERSION != 2);
BUILD_BUG_ON(sizeof(struct cxl_ioctl_start_work) != 64);
BUILD_BUG_ON(sizeof(struct cxl_event_header) != 8);
BUILD_BUG_ON(sizeof(struct cxl_event_afu_interrupt) != 8);
diff --git a/include/uapi/misc/cxl.h b/include/uap
Re: [PATCH v5 0/7]powerpc/powernv: Nest Instrumentation support
On Tuesday 21 July 2015 12:13 AM, Sukadev Bhattiprolu wrote: > Madhavan Srinivasan [ma...@linux.vnet.ibm.com] wrote: > | This patchset enables Nest Instrumentation support on powerpc. > | POWER8 has per-chip Nest Intrumentation which provides various > | per-chip metrics like memory, powerbus, Xlink and Alink > | bandwidth. > | > > > | Cc: Michael Ellerman > | Cc: Benjamin Herrenschmidt > | Cc: Paul Mackerras > | Cc: Anton Blanchard > | Cc: Sukadev Bhattiprolu > | Cc: Anshuman Khandual > | Cc: Stephane Eranian > | Signed-off-by: Madhavan Srinivasan > > Thanks for addressing my comments from earlier version. > > Reviewed-by: Sukadev Bhattiprolu Thanks for the review Maddy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/7] powerpc/powernv: generic nest pmu event functions
On Wednesday 22 July 2015 10:26 AM, Daniel Axtens wrote:
>> +static void p8_nest_read_counter(struct perf_event *event)
>> +{
>> +uint64_t *addr;
>> +u64 data = 0;
> You've got a u64 and a uint64_t, and then...
>> +
>> +addr = (u64 *)event->hw.event_base;
> ... you cast to event_base to a u64 pointer, which you assign to a
> uint64_t pointer.
>> +data = __be64_to_cpu(*addr);
> And now you dereference the pointer.
> Could you just have:
> data = __be64_to_cpu(*event->hw.event_base);
>> +local64_set(&event->hw.prev_count, data);
>> +}
>> +
>> +static void p8_nest_perf_event_update(struct perf_event *event)
>> +{
>> +u64 counter_prev, counter_new, final_count;
>> +uint64_t *addr;
>> +
>> +addr = (uint64_t *)event->hw.event_base;
> Here at least the cast type is the same as the type of addr, but again,
> why do you need the different types, and why local variable?
Damn sorry, copy paste errors. When I added debug prints i messed
the type case in both the functions. I will make them as uint64_t.
Thanks for this detail review
Maddy
>> +counter_prev = local64_read(&event->hw.prev_count);
>> +counter_new = __be64_to_cpu(*addr);
>> +final_count = counter_new - counter_prev;
>> +
>> +local64_set(&event->hw.prev_count, counter_new);
>> +local64_add(final_count, &event->count);
>> +}
>> +
>> +static void p8_nest_event_start(struct perf_event *event, int flags)
>> +{
>> +event->hw.state = 0;
> Should this be an enum or a #define rather than a bare 0? (It may not
> need to be, I was just wondering because I don't know what 0 means.)
I could remove it since was just initializing at the start.
>> +p8_nest_read_counter(event);
>> +}
>> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 2/7] staging: usage documentation for simple fpga bus
On Fri 2015-07-17 10:51:12, at...@opensource.altera.com wrote: > From: Alan Tull > > Add a document spelling out usage of the simple fpga bus. > +The DT overlay includes bindings (documented in bindings/simple-fpga-bus.txt) > +that specify: > + * Which fpga manager to use fpga->FPGA, globally. > + * Which image file to load > + * Flags indicating whether this this image is for full reconfiguration or > + partial. > + * a list of resets that should be released. These enable the FPGA bridges. > + * child nodes specifying the devices that will be added with appropriate > + compatible strings, etc. Either all entries in the list should start with big letter or none should. Also . at end of line should be consistent. > + Sequence > + > + 1. Load the DT overlay. One convenient way to do that is to use Pantelis' > +handy configfs interface (more below). Reader has no chance to know what Pantelis' configfs interface is, and there's nothing below. > + 2. The simple FPGA bus gets probed and will do the following: > +a. call the fpga manager core to program the FPGA > +b. release the FPGA bridges > +c. call of_platform_populate resulting in device drivers getting probed. > + -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, pat: Add comments to cachemode translation tables
>>> On 22.07.15 at 20:06, wrote: > Add comments to the cachemode translation tables to clarify that > the default values are set as minimal supported mode, which are > necessary to handle WC and WT fallback to UC- when they are not > enabled. Wait - shouldn't WT fall back to UC (so to not be affected by WC MTRR settings)? Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpufreq: Rename two functions related to CPU offline
On 23-07-15, 02:01, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish() > are about CPU offline rather than about CPU removal, rename them to > cpufreq_offline_prepare() and cpufreq_offline_finish(), respectively. > > Also change their argument from a struct device pointer to a CPU > number, because they use the CPU number only internally anyway. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq.c | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: x86: rename quirk constants to KVM_X86_QUIRK_*
On 07/23/2015 02:26 PM, Paolo Bonzini wrote: Make them clearly architecture-dependent; the capability is valid for all architectures, but the argument is not. Reviewed-by: Xiao Guangrong Okay, i saw you already have adjusted and merged my patchset, thanks for your work. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: Separate CPU device removal from CPU online
On 23-07-15, 02:04, Rafael J. Wysocki wrote:
> +static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
> +{
> + unsigned int cpu = dev->id;
> + struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> +
> + pr_debug("%s: adding CPU %u\n", __func__, cpu);
> +
> + if (policy && policy->kobj_cpu != cpu) {
Why are you comparing cpu against kobj_cpu ? I don't think it can ever
be false.
> + int ret;
> +
> + pr_debug("%s: Adding symlink for CPU: %u\n", __func__, cpu);
dev_dbg
> + ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
> + if (ret) {
> + dev_dbg(dev, "%s: Failed to create link (%d)\n",
dev_err
> + __func__, ret);
> + return ret;
> + }
> +
> + /* Track CPUs for which sysfs links are created */
> + cpumask_set_cpu(cpu, policy->linked_cpus);
> + }
> +
> + return cpu_online(cpu) ? cpufreq_dev_online(dev, false) : 0;
> +}
Looks fine otherwise. Thanks for getting your hands dirty :)
> static void cpufreq_offline_prepare(unsigned int cpu)
> {
> struct cpufreq_policy *policy;
> @@ -2344,31 +2343,35 @@ unlock:
> }
> EXPORT_SYMBOL(cpufreq_update_policy);
>
> +static void cpufreq_cpu_online(unsigned int cpu)
> +{
> + struct device *dev = get_cpu_device(cpu);
> +
> + if (dev)
> + cpufreq_dev_online(dev, true);
> +}
What about dropping this wrapper function and ...
> static int cpufreq_cpu_callback(struct notifier_block *nfb,
> unsigned long action, void *hcpu)
> {
> unsigned int cpu = (unsigned long)hcpu;
> - struct device *dev;
>
> - dev = get_cpu_device(cpu);
... keeping this as is? And then we can do
s/cpufreq_dev_online/cpufreq_cpu_online which suits better.
> - if (dev) {
> - switch (action & ~CPU_TASKS_FROZEN) {
> - case CPU_ONLINE:
> - cpufreq_add_dev(dev, NULL);
> - break;
> -
> - case CPU_DOWN_PREPARE:
> - cpufreq_offline_prepare(cpu);
> - break;
> -
> - case CPU_POST_DEAD:
> - cpufreq_offline_finish(cpu);
> - break;
> -
> - case CPU_DOWN_FAILED:
> - cpufreq_add_dev(dev, NULL);
> - break;
> - }
> + switch (action & ~CPU_TASKS_FROZEN) {
> + case CPU_ONLINE:
> + cpufreq_cpu_online(cpu);
> + break;
> +
> + case CPU_DOWN_PREPARE:
> + cpufreq_offline_prepare(cpu);
> + break;
> +
> + case CPU_POST_DEAD:
> + cpufreq_offline_finish(cpu);
> + break;
> +
> + case CPU_DOWN_FAILED:
> + cpufreq_cpu_online(cpu);
> + break;
> }
> return NOTIFY_OK;
> }
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 1/7] staging: usage documentation for FPGA manager core
On Fri 2015-07-17 10:51:11, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Add a document on the new FPGA manager core.
>
> --- /dev/null
> +++ b/drivers/staging/fpga/Documentation/fpga-mgr.txt
> @@ -0,0 +1,117 @@
> + FPGA Manager Core
> +
> + Alan Tull 2015
> +
> + Overview
> +
The formatting is quite funny here. Add a newline after ---'s? Or
better format it the way other documents are formatted?
> +The FPGA manager core exports a set of functions for programming an image to
> a
"into"?
> +FPGA. All manufacturor specifics are hidden away in a low level driver. The
manufacturer (more then one instance).
> +API is manufacturor agnostic. Of course the FPGA image data itself is very
> +manufacturor specific but for our purposes it's just data in a buffer or file
, but
> +or something. The FPGA manager core won't parse it or know anything about
> it.
kill "or know anything"?
> + Files
> + -
> +drivers/staging/fpga/fpga-mgr.c
> +include/linux/fpga/fpga-mgr.h
> +
Kill this section, as it is going to change?
> + The API Functions
> +
> +The API that is exported is currently 6 functions:
> +
> + int fpga_mgr_buf_load(struct fpga_manager *mgr,
> + u32 flags,
> + const char *buf,
> + size_t count);
> +
> +An FPGA image exists as a buffer in memory. Load it into the FPGA. The FPGA
> +ends up in operating mode or return a negative error code.
So 0 on success?
> + int fpga_mgr_firmware_load(struct fpga_manager *mgr,
> + u32 flags,
> + const char *image_name);
> +
> +An FPGA image exists as a file that is on the firmware search path (see the
", that is in"
> +firmware class documentation). Load as above.
> +
> + struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
> +
> +Given a DT node, get a reference to a fpga manager.
fpga->FPGA, fix globally??
> + void fpga_mgr_put(struct fpga_manager *mgr);
> +
> +Release the reference to the fpga manager.
> +
> + int fpga_mgr_register(struct device *dev,
> + const char *name,
> + const struct fpga_manager_ops *mops,
> + void *priv);
> + void fpga_mgr_unregister(struct device *dev);
> +
> +Register/unregister the lower level device specific driver.
"low level".. And "device specific" -> "FPGA-specific" ?
> +To add another fpga manager, look at the bottom part of socfpga.c for an
> +example, starting with the declaration of socfpga_fpga_ops.
Umm. You have good documentation below. Maybe you don't need to send
people to read sources...?
> +static const struct fpga_manager_ops socfpga_fpga_ops = {
> + .write_init = socfpga_fpga_ops_configure_init,
> + .write = socfpga_fpga_ops_configure_write,
> + .write_complete = socfpga_fpga_ops_configure_complete,
> + .state = socfpga_fpga_ops_state,
> +};
> +
> +You will want to create a platform driver that has a set of ops like that
> +and then register it with fpga_mgr_register in your probe function. Your
> +ops will implement whatever device specific register writes needed and
> +will return negative error codes if things don't go well.
> +
> +The programming seqence is:
sequence.
> + 1. .write_init
> + 2. .write (may be called once or multiple times)
> + 3. .write_complete
> +
> +The .write_init function will prepare the FPGA to receive the image data.
> +
> +The .write function receives an image buffer or a chunk of the image and
> +writes it the FPGA. The buffer may arrive as one chunk or a bunck
> of
bunch.
> +small chunks through this function being called multiple times.
> +
> +The .write_complete function is called after all the image has been written
> +to put the FPGA into operating mode.
> +
> +The .state function will read your hardware and return a code of type
> +"enum fpga_mgr_states". It doesn't result in a change in hardware state.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] KVM: MTRR: fix memory type handling if MTRR is completely disabled
On 07/23/2015 02:21 PM, Paolo Bonzini wrote: On 16/07/2015 06:10, Alex Williamson wrote: On Thu, 2015-07-16 at 03:25 +0800, Xiao Guangrong wrote: From: Xiao Guangrong Currently code uses default memory type if MTRR is fully disabled, fix it by using UC instead Signed-off-by: Xiao Guangrong --- Seems to work for me. I don't see a 0th patch, but for the series: Tested-by: Alex Williamson In fact this is the same quirk already implemented for SVM as KVM_QUIRK_CD_NW_CLEARED, so we can reuse the bit. Sounds good to me. I will drop the new bit and reuse as your suggestion. And i think we need document this whole staff in API.txt ... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] powerpc/powernv: add event attribute and group to nest pmu
On Wednesday 22 July 2015 10:14 AM, Daniel Axtens wrote:
> On Thu, 2015-07-16 at 16:43 +0530, Madhavan Srinivasan wrote:
>> Add code to create event/format attributes and attribute groups for
>> each nest pmu.
>>
>> Cc: Michael Ellerman
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Anton Blanchard
>> Cc: Sukadev Bhattiprolu
>> Cc: Anshuman Khandual
>> Cc: Stephane Eranian
>> Signed-off-by: Madhavan Srinivasan
>> ---
>> arch/powerpc/perf/nest-pmu.c | 65
>>
>> 1 file changed, 65 insertions(+)
>>
>> diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
>> index c4c08e4dee55..f3418bdec1cd 100644
>> --- a/arch/powerpc/perf/nest-pmu.c
>> +++ b/arch/powerpc/perf/nest-pmu.c
>> @@ -13,6 +13,17 @@
>> static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
>> static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
>>
>> +PMU_FORMAT_ATTR(event, "config:0-20");
>> +static struct attribute *p8_nest_format_attrs[] = {
>> +&format_attr_event.attr,
>> +NULL,
>> +};
>> +
>> +static struct attribute_group p8_nest_format_group = {
>> +.name = "format",
>> +.attrs = p8_nest_format_attrs,
>> +};
>> +
>> static int nest_event_info(struct property *pp, char *name,
>> struct nest_ima_events *p8_events, int string, u32 val)
>> {
>> @@ -46,6 +57,56 @@ static int nest_event_info(struct property *pp, char
>> *name,
>> return 0;
>> }
>>
>> +/*
>> + * Populate event name and string in attribute
>> + */
>> +static struct attribute *dev_str_attr(const char *name, const char *str)
>> +{
>> +struct perf_pmu_events_attr *attr;
>> +
>> +attr = kzalloc(sizeof(*attr), GFP_KERNEL);
>> +
>> +sysfs_attr_init(&attr->attr.attr);
>> +
>> +attr->event_str = str;
>> +attr->attr.attr.name = name;
>> +attr->attr.attr.mode = 0444;
>> +attr->attr.show = perf_event_sysfs_show;
>> +
>> +return &attr->attr.attr;
> So I asked you about this before, and you pointed me to
> perf_event_sysfs_show. Looking at that in kernel/events/core.c, it looks
> like that uses container_of to pull out the perf_pmu_events_attr. So I
> guess that is at least mostly correct.
>
> I'm hoping something else uses container_of to pull out attr->attr, so
> that they can actually grab the attr->attr.show function pointer, so
> that perf_event_sysfs_show actually gets called. Where would that be?
OK, what we return is the device attribute struct which also have sysfs_ops.
So ->show and ->store are those entries in the strucutre and here we only
populate show ops using perf_event_sysfs_show. Now at the time of
pmu registering, we end up calling device_add->device_create_file->
sysfs_create_file which will end up adding a sysfs device file linked to
this
->show ops.
>> +}
>> +
>> +static int update_events_in_group(
>> +struct nest_ima_events *p8_events, int idx, struct nest_pmu *pmu)
>> +{
>> +struct attribute_group *attr_group;
>> +struct attribute **attrs;
>> +int i;
>> +
>> +/*
>> + * Allocate memory for both event attribute group and for
>> + * event attributes array.
>> + */
>> +attr_group = kzalloc(((sizeof(struct attribute *) * (idx + 1)) +
>> +sizeof(*attr_group)), GFP_KERNEL);
>> +if (!attr_group)
>> +return -ENOMEM;
>> +
>> +/*
>> + * Assign memory for event attribute array
>> + */
>> +attrs = (struct attribute **)(attr_group + 1);
>> +attr_group->name = "events";
>> +attr_group->attrs = attrs;
> I am super uncomfortable with this block, especially the assignment to
> attrs. I *think* you're trying to allocate an attribute group and a set
> of attributes, but you've combined the allocation into one big
> contiguous chunk, and then you're trying to tease them apart. Is that
> necessary? Could it be two allocs, one for the attribute_group and one
> for the attribute?
I wanted to avoid two function calls here, but this is not a hot path
This happens at the pmu init time (booting), so I guess we can have
two allocs here.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: configs: Add Freescale LS1021A defconfig
Add Freescale LS1021A initial defconfig file. The LS1021A SoC is a dual-core Cortex-A7 based processor. LS1021A has some special configure options against common V7 SOCs, such as CONFIG_THUMB2_KERNEL, CONFIG_VMSPLIT_2G, CONFIG_VFP... Enable I2C, LPUART, eDMA, WDT, GIANFAR, Sound, DSPI at default. Signed-off-by: Haikun Wang Signed-off-by: Alison Wang --- Changes since v1: - Enable GIANFAR, Sound and DSPI. arch/arm/configs/ls1021a_defconfig | 160 + 1 file changed, 160 insertions(+) create mode 100644 arch/arm/configs/ls1021a_defconfig diff --git a/arch/arm/configs/ls1021a_defconfig b/arch/arm/configs/ls1021a_defconfig new file mode 100644 index 000..079c48f --- /dev/null +++ b/arch/arm/configs/ls1021a_defconfig @@ -0,0 +1,160 @@ +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ_IDLE=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_LOG_BUF_SHIFT=16 +CONFIG_BLK_DEV_INITRD=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS_ALL=y +CONFIG_EMBEDDED=y +CONFIG_PROFILING=y +CONFIG_OPROFILE=y +CONFIG_KPROBES=y +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_BLK_CMDLINE_PARSER=y +CONFIG_ARCH_MXC=y +CONFIG_SOC_LS1021A=y +CONFIG_ARM_LPAE=y +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_SMP=y +CONFIG_VMSPLIT_2G=y +CONFIG_PREEMPT_VOLUNTARY=y +CONFIG_THUMB2_KERNEL=y +CONFIG_HIGHMEM=y +CONFIG_CLEANCACHE=y +CONFIG_FRONTSWAP=y +CONFIG_CMDLINE="console=ttyS0,115200" +CONFIG_VFP=y +CONFIG_NEON=y +CONFIG_KERNEL_MODE_NEON=y +CONFIG_BINFMT_MISC=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_UNIX_DIAG=y +CONFIG_XFRM_USER=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_MROUTE=y +CONFIG_INET_AH=y +CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y +CONFIG_INET_UDP_DIAG=m +CONFIG_NETFILTER=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_BE_BYTE_SWAP=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_STAA=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_NAND=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=256000 +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_SG=y +CONFIG_ATA=y +CONFIG_NETDEVICES=y +CONFIG_GIANFAR=y +CONFIG_VITESSE_PHY=y +CONFIG_BROADCOM_PHY=y +CONFIG_REALTEK_PHY=y +CONFIG_NATIONAL_PHY=y +CONFIG_MICREL_PHY=y +CONFIG_MDIO_BUS_MUX_MMIOREG=y +CONFIG_INPUT_EVDEV=y +CONFIG_SERIO_SERPORT=m +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_SERIAL_FSL_LPUART=y +CONFIG_SERIAL_FSL_LPUART_CONSOLE=y +CONFIG_HW_RANDOM=y +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_MUX=y +CONFIG_I2C_MUX_PCA954x=y +CONFIG_I2C_IMX=y +CONFIG_SPI=y +CONFIG_SPI_FSL_DSPI=y +CONFIG_GPIO_SYSFS=y +CONFIG_SENSORS_LM90=y +CONFIG_SENSORS_INA2XX=y +CONFIG_WATCHDOG=y +CONFIG_IMX2_WDT=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_DEBUG=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_SOUND=y +# CONFIG_SOUND_OSS_CORE_PRECLAIM is not set +CONFIG_SND=y +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y +# CONFIG_SND_ARM is not set +CONFIG_SND_SOC=y +CONFIG_SND_SOC_FSL_SAI=y +CONFIG_SND_SOC_SGTL5000=y +CONFIG_SND_SIMPLE_CARD=y +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_OF_ARASAN=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS3232=y +CONFIG_DMADEVICES=y +CONFIG_FSL_EDMA=y +CONFIG_CLK_QORIQ=y +CONFIG_MEMORY=y +CONFIG_EXT2_FS=y +CONFIG_EXT2_FS_XATTR=y +CONFIG_EXT3_FS=y +CONFIG_EXT4_FS=y +CONFIG_FANOTIFY=y +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_ZISOFS=y +CONFIG_UDF_FS=m +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_NTFS_FS=m +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_JFFS2_FS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +CONFIG_NLS_DEFAULT="cp437" +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_ISO8859_2=y +CONFIG_NLS_ISO8859_15=y +CONFIG_NLS_UTF8=y +CONFIG_DEBUG_SECTION_MISMATCH=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_CRYPTO_LZO=y +CONFIG_CRC_CCITT=m +CONFIG_CRC_T10DIF=y +CONFIG_CRC7=m +CONFIG_LIBCRC32C=m -- 2.1.0.27.g96db324 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] KVM: x86: rename quirk constants to KVM_X86_QUIRK_*
Make them clearly architecture-dependent; the capability is valid for
all architectures, but the argument is not.
Signed-off-by: Paolo Bonzini
---
arch/x86/include/uapi/asm/kvm.h | 4 ++--
arch/x86/kvm/lapic.c| 2 +-
arch/x86/kvm/svm.c | 2 +-
arch/x86/kvm/vmx.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index a4ae82eb82aa..cd54147cb365 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -354,7 +354,7 @@ struct kvm_xcrs {
struct kvm_sync_regs {
};
-#define KVM_QUIRK_LINT0_REENABLED (1 << 0)
-#define KVM_QUIRK_CD_NW_CLEARED(1 << 1)
+#define KVM_X86_QUIRK_LINT0_REENABLED (1 << 0)
+#define KVM_X86_QUIRK_CD_NW_CLEARED(1 << 1)
#endif /* _ASM_X86_KVM_H */
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 1c425443a41a..2a5ca97c263b 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1595,7 +1595,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool
init_event)
for (i = 0; i < APIC_LVT_NUM; i++)
apic_set_reg(apic, APIC_LVTT + 0x10 * i, APIC_LVT_MASKED);
apic_update_lvtt(apic);
- if (kvm_check_has_quirk(vcpu->kvm, KVM_QUIRK_LINT0_REENABLED))
+ if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_LINT0_REENABLED))
apic_set_reg(apic, APIC_LVT0,
SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
apic_manage_nmi_watchdog(apic, kvm_apic_get_reg(apic, APIC_LVT0));
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 8cbec765b08d..8e0c0844c6b9 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1672,7 +1672,7 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
* does not do it - this results in some delay at
* reboot
*/
- if (kvm_check_has_quirk(vcpu->kvm, KVM_QUIRK_CD_NW_CLEARED))
+ if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
cr0 &= ~(X86_CR0_CD | X86_CR0_NW);
svm->vmcb->save.cr0 = cr0;
mark_dirty(svm->vmcb, VMCB_CR);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e9e1fc517ab5..83b7b5cd75d5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8650,7 +8650,7 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t
gfn, bool is_mmio)
if (kvm_read_cr0(vcpu) & X86_CR0_CD) {
ipat = VMX_EPT_IPAT_BIT;
- if (kvm_check_has_quirk(vcpu->kvm, KVM_QUIRK_CD_NW_CLEARED))
+ if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
cache = MTRR_TYPE_WRBACK;
else
cache = MTRR_TYPE_UNCACHABLE;
--
1.8.3.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 v2] cpufreq: Fix possible memory leak during CPU removal
On 23-07-15, 00:27, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > After commit 9b07109f06a1 (cpufreq: Fix double addition of sysfs > links) the second sif argument of __cpufreq_remove_dev_prepare() > and __cpufreq_remove_dev_finish() is not used by them any more. > > However, there also is a problem in cpufreq_remove_dev() that > if any of the above functions returns an error, we'll fail to > clean up after a CPU that is going away (and it is going away > no matter what). Moreover, error codes returned by them are > ignored by cpufreq_cpu_callback(), so even if any of them is > aborted and returns an error code, the caller of the notifier > callback will not know about that. > > For this reason, make __cpufreq_remove_dev_prepare() and > __cpufreq_remove_dev_finish() never fail, change them to void > functions and drop the sif argument from them. > > Signed-off-by: Rafael J. Wysocki > --- > > On top of: > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=9b07109f06a1edd6e636b1e7397157eae0e6baa4 > > Note: The commit mentioned above is on a testing branch only > at the moment. > > Well, I seem to be blind. Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/4] serial: 8250_dw: Add UPF_SKIP_TEST to flags depend on device tree
From: Peter Hurley [mailto:pe...@hurleysoftware.com]
Sent: Wednesday, July 22, 2015 3:21 PM
>>On 07/22/2015 05:34 AM, Noam Camus wrote:
>> From: Noam Camus
>>
>> Add support for OF option "no-loopback-test"
> Changes to devicetree need to at least get acks from DT maintainers.
I will add them in my v2
Should I take this patch apart from this set or should I add DT maintainers to
whole set?
Noam
N�r��yb�X��ǧv�^�)Þº{.n�+{zX����ܨ}ï¿½ï¿½ï¿½Æ z�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jÇ«y�m��@A�a���
0��h���i
Re: [PATCH 1/3] KVM: MTRR: fix memory type handling if MTRR is completely disabled
On 16/07/2015 06:10, Alex Williamson wrote: > On Thu, 2015-07-16 at 03:25 +0800, Xiao Guangrong wrote: >> > From: Xiao Guangrong >> > >> > Currently code uses default memory type if MTRR is fully disabled, >> > fix it by using UC instead >> > >> > Signed-off-by: Xiao Guangrong >> > --- > Seems to work for me. I don't see a 0th patch, but for the series: > > Tested-by: Alex Williamson In fact this is the same quirk already implemented for SVM as KVM_QUIRK_CD_NW_CLEARED, so we can reuse the bit. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: LEDs - skip unnamed LEDs
On Wed 2015-07-22 15:02:02, Dmitry Torokhov wrote:
> Devices may declare more LEDs than what is known to input-leds
> (HID does this for some devices). Instead of showing ugly warnings
> on connect and, even worse, oopsing on disconnect, let's simply
> ignore LEDs that are not known to us.
>
> Reported-by: Vlastimil Babka
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/input-leds.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
> index 074a65e..766bf26 100644
> --- a/drivers/input/input-leds.c
> +++ b/drivers/input/input-leds.c
> @@ -71,6 +71,18 @@ static void input_leds_event(struct input_handle *handle,
> unsigned int type,
> {
> }
>
> +static int input_leds_get_count(struct input_dev *dev)
> +{
> + unsigned int led_code;
> + int count = 0;
> +
> + for_each_set_bit(led_code, dev->ledbit, LED_CNT)
> + if (input_led_info[led_code].name)
> + count++;
> +
> + return count;
> +}
> +
> static int input_leds_connect(struct input_handler *handler,
> struct input_dev *dev,
> const struct input_device_id *id)
> @@ -81,7 +93,7 @@ static int input_leds_connect(struct input_handler *handler,
> int led_no;
> int error;
>
> - num_leds = bitmap_weight(dev->ledbit, LED_CNT);
> + num_leds = input_leds_get_count(dev);
> if (!num_leds)
> return -ENXIO;
>
> @@ -112,7 +124,7 @@ static int input_leds_connect(struct input_handler
> *handler,
> led->handle = &leds->handle;
> led->code = led_code;
>
> - if (WARN_ON(!input_led_info[led_code].name))
> + if (!input_led_info[led_code].name)
> continue;
>
> led->cdev.name = kasprintf(GFP_KERNEL, "%s::%s",
>
Are you sure? AFAICT you need to fix err_unregister_leds not to
unregister leds with no name...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/4] serial: 8250_dw: Add support for big-endian MMIO accesses
From: Peter Hurley [mailto:pe...@hurleysoftware.com] Sent: Wednesday, July 22, 2015 3:41 PM >> diff --git a/drivers/tty/serial/8250/8250_dw.c >> b/drivers/tty/serial/8250/8250_dw.c >> index d48b506..fe0b487 100644 >> --- a/drivers/tty/serial/8250/8250_dw.c >> +++ b/drivers/tty/serial/8250/8250_dw.c >> @@ -173,15 +173,13 @@ static void dw8250_serial_outq(struct uart_port >> *p, int offset, int value) } #endif /* CONFIG_64BIT */ >> >> -static void dw8250_serial_out32(struct uart_port *p, int offset, int >> value) >> +static void dw8250_check_control(struct uart_port *p, int offset, >> +int value) > Also, I think this fn name should be dw8250_check_LCR() to distinguish it > from modem control. No problem will rename in my v2
RE: [PATCH 1/4] serial: 8250_dw: Add support for big-endian MMIO accesses
From: Peter Hurley [mailto:pe...@hurleysoftware.com] Sent: Wednesday, July 22, 2015 3:19 PM > This is not an adequate changelog. > Please describe the refactoring. I will in my v2 patch set Noam
Re: [PATCH V2] cpufreq: Fix double addition of sysfs links
On 22-07-15, 18:42, Rafael J. Wysocki wrote: > > 3. what happens when 'policy' is NULL at the point when the first (few) CPUs > >are added - how do the symlinks get created later if/when policy becomes > >non-NULL (can it?) > > Yes, it can, and we have a design issue here that bothers me a bit. I replied to Russell with a NO here as the first CPU should have created the policy. BUT... > Namley, we need a driver's ->init callback to populate policy->cpus > for us, but this is not the only thing it is doing, so the concern is > that it may not be able to deal with CPUs that aren't online. ... the first few CPUs could have been offline and so we might not have tried to add the policy at all.. Need to fix that for sure. > I was thinking about an additional driver callback that would *only* > populate a mask of CPUs that should use the same policy as the given > one. Why so ? Drivers today are required to set policy->cpus with all CPUs that should be managed by that policy. i.e. all online+offline. So, actually ->init() fills policy->cpus with the value of policy->related_cpus. Yes, I thought earlier to change that by setting policy->related_cpus from drivers, instead of policy->cpus and wasn't sure if I should do that :) > We'd be able to call that from cpufreq_add_dev() for offline > CPUs too and this way the policy object could be created for the first > CPU using the policy that is registered instead of being added for the > first CPU using that policy that becomes online (which happens today). Creating policy for offline CPUs doesn't look that great to me. What we can do to fix the problem in hand, is to update a global mask of CPUs (with policy == NULL) which were offline when cpufreq_add_dev() was called for them. And when we create the policy, we can add links for all such CPUs. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] KVM: x86: quirkily apply WB to all memory if cache is disabled
On 07/23/2015 01:56 PM, Paolo Bonzini wrote: On 15/07/2015 21:25, Xiao Guangrong wrote: From: Xiao Guangrong Current firmware depends on WB to fast boot, please refer to https://lkml.org/lkml/2015/7/12/115 Let's us WB if CR0.CD is set to make this kind of firmware happy This quirk can be dropped by using KVM_ENABLE_CAP API with KVM_CAP_DISABLE_QUIRKS if the broken firmware is gone Signed-off-by: Xiao Guangrong Your patch is actually *enabling* the quirk if KVM_QUIRK_CD_AS_WB is included in the disabled quirks. I'm squashing in this change: Yep, i misunderstood the meaning of "disabled-quirks", thanks for your nice adjustment, Paolo! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/7] powerpc/powernv: detect supported nest pmus and its events
On Wednesday 22 July 2015 09:37 AM, Daniel Axtens wrote:
>
>> static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
>> +static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
>> +
>> +static int nest_event_info(struct property *pp, char *name,
>> +struct nest_ima_events *p8_events, int string, u32 val)
> 'int string' is a bit confusing. 'bool is_string' might be clearer, but
> I think it would be even better still to have different functions for
> string and non-string cases, especially because you only need val in the
> non-string case.
I would perfer to be a single function, since most of the code is same
just of the sting or val part. yes. We can make is as is_string and will
add
comment explaining what is done here?
> That will also allow you to give the functions clearer names. I think
> the function is populating the event with info from the dt property (in
> the string case) or the val argument (non-string case) - maybe the names
> could reflect that somehow?
>> +{
>> +char *buf;
>> +
>
>> +
>> +static int nest_pmu_create(struct device_node *dev, int pmu_index)
>> +{
>> +struct nest_ima_events **p8_events_arr, *p8_events;
>> +struct nest_pmu *pmu_ptr;
>> +struct property *pp;
>> +char *buf, *start;
>> +const __be32 *lval;
>> +u32 val;
>> +int idx = 0, ret;
>> +
>> +if (!dev)
>> +return -EINVAL;
>> +
>> +/* memory for nest pmus */
>> +pmu_ptr = kzalloc(sizeof(struct nest_pmu), GFP_KERNEL);
>> +if (!pmu_ptr)
>> +return -ENOMEM;
>> +
>> +/* Needed for hotplug/migration */
>> +per_nest_pmu_arr[pmu_index] = pmu_ptr;
>> +
>> +/* memory for nest pmu events */
>> +p8_events_arr = kzalloc((sizeof(struct nest_ima_events) * 64),
>> +GFP_KERNEL);
>> +if (!p8_events_arr)
>> +return -ENOMEM;
>> +p8_events = (struct nest_ima_events *)p8_events_arr;
> I'm still quite uncomfortable with this.
> - Why * 64? Should it be * P8_NEST_MAX_EVENTS_SUPPORTED? Or is it a
> different constant?
Yes it should be P8_NEST_MAX_EVENTS_SUPPORTED, and it should be
define as 64. Missed it to replace the macro. Nice catch.
> - p8_events = p8_events_arr[0] would be clearer
>
>> +
>> +/*
>> + * Loop through each property
>> + */
>> +for_each_property_of_node(dev, pp) {
>> +start = pp->name;
>> +
>> +if (!strcmp(pp->name, "name")) {
>> +if (!pp->value ||
>> + (strnlen(pp->value, pp->length) == pp->length) ||
>> + (pp->length > P8_NEST_MAX_PMU_NAME_LEN))
>> +return -EINVAL;
>> +
>> +buf = kzalloc(P8_NEST_MAX_PMU_NAME_LEN, GFP_KERNEL);
>> +if (!buf)
>> +return -ENOMEM;
>> +
>> +/* Save the name to register it later */
>> +sprintf(buf, "Nest_%s", (char *)pp->value);
>> +pmu_ptr->pmu.name = (char *)buf;
>> +continue;
>> +}
>> +
>> +/* Skip these, we dont need it */
> "don't" instead of "dont".
Will change it.
>> +if (!strcmp(pp->name, "phandle") ||
>> +!strcmp(pp->name, "device_type") ||
>> +!strcmp(pp->name, "linux,phandle"))
>> +continue;
>> +
>> +if (strncmp(pp->name, "unit.", 5) == 0) {
>> +/* Skip first few chars in the name */
> The whole comment is pretty uninformative, as is the similar comment
> below. If you need a comment at all, maybe something along the lines of
> "Strip the prefix because "?
Yes will change it. Thanks
>> +start += 5;
>> +ret = nest_event_info(pp, start, p8_events++, 1, 0);
>> +} else if (strncmp(pp->name, "scale.", 6) == 0) {
>> +/* Skip first few chars in the name */
>> +start += 6;
>> +ret = nest_event_info(pp, start, p8_events++, 1, 0);
>> +} else {
>> +lval = of_get_property(dev, pp->name, NULL);
>> +val = (uint32_t)be32_to_cpup(lval);
>> +
>> +ret = nest_event_info(pp, start, p8_events++, 0, val);
>> +}
>> +
>> +if (ret)
>> +return ret;
>> +
>> +/* book keeping */
>> +idx++;
> You don't seem to use idx in this function, apart from incrementing it
> here...?
Used in next patch.
>> +}
>> +
>> +return 0;
>> +}
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the akpm-current tree with the FIXME tree
Hi all, Of course, I meant the ext3 tree (not the FIXME tree :-)) -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] soc: mediatek: add scpsys support active_wakeup
Register gpd_dev_ops.active_wakeup function to support keep power
during suspend state. And add flag to each power domain to
decide whether keep power during suspend or not.
Signed-off-by: Chunfeng Yun
Signed-off-by: Eddie Huang
---
drivers/soc/mediatek/mtk-scpsys.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 43a79ed..fc78b70 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -67,6 +67,7 @@ struct scp_domain_data {
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
enum clk_id clk_id;
+ bool active_wakeup;
};
static const struct scp_domain_data scp_domain_data[] __initconst = {
@@ -77,6 +78,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
.clk_id = MT8173_CLK_MM,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_VENC] = {
.name = "venc",
@@ -85,6 +87,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
.clk_id = MT8173_CLK_MM,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_ISP] = {
.name = "isp",
@@ -93,6 +96,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
.clk_id = MT8173_CLK_MM,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_MM] = {
.name = "mm",
@@ -101,6 +105,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
.clk_id = MT8173_CLK_MM,
+ .active_wakeup = false,
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
MT8173_TOP_AXI_PROT_EN_MM_M1,
},
@@ -111,6 +116,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
.clk_id = MT8173_CLK_MM,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_AUDIO] = {
.name = "audio",
@@ -119,6 +125,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
.clk_id = MT8173_CLK_NONE,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_USB] = {
.name = "usb",
@@ -127,6 +134,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
.clk_id = MT8173_CLK_NONE,
+ .active_wakeup = true,
},
[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
.name = "mfg_async",
@@ -135,6 +143,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = 0,
.clk_id = MT8173_CLK_MFG,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_MFG_2D] = {
.name = "mfg_2d",
@@ -143,6 +152,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
.clk_id = MT8173_CLK_NONE,
+ .active_wakeup = false,
},
[MT8173_POWER_DOMAIN_MFG] = {
.name = "mfg",
@@ -151,6 +161,7 @@ static const struct scp_domain_data scp_domain_data[]
__initconst = {
.sram_pdn_bits = GENMASK(13, 8),
.sram_pdn_ack_bits = GENMASK(21, 16),
.clk_id = MT8173_CLK_NONE,
+ .active_wakeup = false,
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
MT8173_TOP_AXI_PROT_EN_MFG_M0 |
MT8173_TOP_AXI_PROT_EN_MFG_M1 |
@@ -171,6 +182,7 @@ struct scp_domain {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
+ bool active_wakeup;
};
struct scp {
@@ -370,6 +382,20 @@ out:
return ret;
}
+static bool scpsys_active_wakeup(struct device *dev)
+{
+ struct generic_pm_domain *genpd;
+ struct scp_domain *scpd;
+
+ if (IS_ERR_OR_NULL(dev->pm_domain))
+ return false;
+
+ genpd = pd_to_genpd(dev->pm_domain);
+ scpd = container_of(genpd, struct scp_do
linux-next: manual merge of the akpm-current tree with the FIXME tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
fs/ext3/super.c
between commit:
106542e7987c ("fs: Remove ext3 filesystem driver")
from the FIXME tree and commit:
d2c05ecd59bc ("parse_integer: convert ext2, ext3, ext4")
from the akpm-current tree.
I fixed it up (I just removed the file) and can carry the fix as necessary
(no action is required).
Jan, I also removed the JBD section from the MAINTAINERS file ... your
version has conflict markers left around it ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mm, compaction: introduce kcompactd
Hello, On Thu, Jul 09, 2015 at 02:53:27PM -0700, David Rientjes wrote: > The slub allocator does try to allocate its high-order memory with > __GFP_WAIT before falling back to lower orders if possible. I would think > that this would be the greatest sign of on-demand memory compaction being > a problem, especially since CONFIG_SLUB is the default, but I haven't seen > such reports. In fact, some of our product had trouble with slub's high order allocation 5 months ago. At that time, compaction didn't make high order page and compaction attempts are frequently deferred. It also causes many reclaim to make high order page so I suggested masking out __GFP_WAIT and adding __GFP_NO_KSWAPD when trying slub's high order allocation to reduce reclaim/compaction overhead. Although using high order page in slub has some gains that reducing internal fragmentation and reducing management overhead, benefit is marginal compared to the cost at making high order page. This solution improves system response time for our case. I planned to submit the patch but it is delayed due to my laziness. :) Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/7] powerpc/powernv: Nest PMU detection and device tree parser
On Wednesday 22 July 2015 09:19 AM, Daniel Axtens wrote:
> Hi,
>
>> +static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
>> +
>> +static int nest_ima_dt_parser(void)
>> +{
>> +const __be32 *gcid;
>> +const __be64 *chip_ima_reg;
>> +const __be64 *chip_ima_size;
>> +struct device_node *dev;
>> +struct perchip_nest_info *p8ni;
>> +int idx;
>> +
>> +/*
>> + * "nest-ima" folder contains two things,
>> + * a) per-chip reserved memory region for Nest PMU Counter data
>> + * b) Support Nest PMU units and their event files
>> + */
>> +for_each_node_with_property(dev, "ibm,ima-chip") {
>> +gcid = of_get_property(dev, "ibm,chip-id", NULL);
>> +chip_ima_reg = of_get_property(dev, "reg", NULL);
>> +chip_ima_size = of_get_property(dev, "size", NULL);
>> +
>> +if ((!gcid) || (!chip_ima_reg) || (!chip_ima_size)) {
>> +pr_err("Nest_PMU: device %s missing property\n",
>> +dev->full_name);
>> +return -ENODEV;
>> +}
>> +
>> +/* chip id to save reserve memory region */
>> +idx = (uint32_t)be32_to_cpup(gcid);
> So be32_to_cpup returns a __u32. You're casting to a uint32_t and then
> assigning to an int.
> - Do you need the intermediate cast?
> - Should idx be an unsigned type?
my bad, sorry abt type case of uint to int.
And your are right, idx can be __u32 (__u32 and uint32_t are same i
guess).
>> +
>> +/*
>> + * Using a local variable to make it compact and
>> + * easier to read
>> + */
> We probably don't need this comment. But a better variable name would be
> helpful!
I dont want a long name since i end up with 80 char limit warning.
but let me see.
>> +p8ni = &p8_nest_perchip_info[idx];
>> +p8ni->pbase = be64_to_cpup(chip_ima_reg);
>> +p8ni->size = be64_to_cpup(chip_ima_size);
>> +p8ni->vbase = (uint64_t) phys_to_virt(p8ni->pbase);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int __init nest_pmu_init(void)
>> +{
>> +int ret = -ENODEV;
>> +
>> +/*
>> + * Lets do this only if we are hypervisor
>> + */
>> +if (!cur_cpu_spec->oprofile_cpu_type ||
>> +!(strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8") == 0) ||
>> +!cpu_has_feature(CPU_FTR_HVMODE))
>> +return ret;
>> +
> I'm still really uncomfortable with doing this via oprofile_cpu_type.
> If the kernel is compiled without oprofile support, will that get
> populated?
I checked the per thread pmu register code and it all does the name.
But that should not stop nest pmu to enable. So probability,
I can carry only the HV mode check and drop the oprofile check.
>
> I'm also curious about why we need checking for power8 at all. We
> already know we're not going to run on hardware without a nest PMU
> because of the device tree check below.
> What happens if there's a future generation of chip that supports nest
> PMUs?
>
> If it's really important to check versions in this function, maybe you
> could put a version property in the ibm,ima-chip node?
True. I should not checkout power8 now, since we enable based on device tree
entries for Nest pmu.
>> +/*
>> + * Nest PMU information is grouped under "nest-ima" node
>> + * of the top-level device-tree directory. Detect Nest PMU
>> + * by the "ibm,ima-chip" property.
>> + */
>> +if (!of_find_node_with_property(NULL, "ibm,ima-chip"))
>> +return ret;
>> +
>> +/*
>> + * Parse device-tree for Nest PMU information
>> + */
>> +ret = nest_ima_dt_parser();
>> +if (ret)
>> +return ret;
>> +
>> +return 0;
>> +}
>> +device_initcall(nest_pmu_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] KVM: x86: quirkily apply WB to all memory if cache is disabled
On 15/07/2015 21:25, Xiao Guangrong wrote:
> From: Xiao Guangrong
>
> Current firmware depends on WB to fast boot, please refer to
> https://lkml.org/lkml/2015/7/12/115
>
> Let's us WB if CR0.CD is set to make this kind of firmware happy
>
> This quirk can be dropped by using KVM_ENABLE_CAP API with
> KVM_CAP_DISABLE_QUIRKS if the broken firmware is gone
>
> Signed-off-by: Xiao Guangrong
Your patch is actually *enabling* the quirk if KVM_QUIRK_CD_AS_WB is
included in the disabled quirks. I'm squashing in this change:
diff --cc arch/x86/kvm/x86.h
index edc8cdcd786b,ea99928d9d09..
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@@ -147,9 +147,9 @@@ static inline void kvm_register_writel(
return ktime_get_boot_ns();
}
-static inline bool kvm_check_disabled_quirks(struct kvm *kvm, u64 quirk)
+static inline bool kvm_check_has_quirk(struct kvm *kvm, u64 quirk)
{
- return !!(kvm->arch.disabled_quirks & quirk);
+ return !(kvm->arch.disabled_quirks & quirk);
}
void kvm_before_handle_nmi(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0d77b20d628a..1c425443a41a 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1595,7 +1595,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool
init_event)
for (i = 0; i < APIC_LVT_NUM; i++)
apic_set_reg(apic, APIC_LVTT + 0x10 * i, APIC_LVT_MASKED);
apic_update_lvtt(apic);
- if (!kvm_check_disabled_quirks(vcpu->kvm, KVM_QUIRK_LINT0_REENABLED))
+ if (kvm_check_has_quirk(vcpu->kvm, KVM_QUIRK_LINT0_REENABLED))
apic_set_reg(apic, APIC_LVT0,
SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
apic_manage_nmi_watchdog(apic, kvm_apic_get_reg(apic, APIC_LVT0));
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index cac9ee6abea7..8cbec765b08d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1672,7 +1672,7 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
* does not do it - this results in some delay at
* reboot
*/
- if (!kvm_check_disabled_quirks(vcpu->kvm, KVM_QUIRK_CD_NW_CLEARED))
+ if (kvm_check_has_quirk(vcpu->kvm, KVM_QUIRK_CD_NW_CLEARED))
cr0 &= ~(X86_CR0_CD | X86_CR0_NW);
svm->vmcb->save.cr0 = cr0;
mark_dirty(svm->vmcb, VMCB_CR);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7247891526ae..6b4890623146 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8650,7 +8650,7 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t
gfn, bool is_mmio)
if (kvm_read_cr0(vcpu) & X86_CR0_CD) {
ipat = VMX_EPT_IPAT_BIT;
- if (kvm_check_disabled_quirks(vcpu->kvm, KVM_QUIRK_CD_AS_WB))
+ if (kvm_check_has_quirk(vcpu->kvm, KVM_QUIRK_CD_AS_WB))
cache = MTRR_TYPE_WRBACK;
else
cache = MTRR_TYPE_UNCACHABLE;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 549051784955..5ef2560075bf 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3765,11 +3765,6 @@ static int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
return r;
}
-static void kvm_init_disabled_quirks(struct kvm *kvm)
-{
- kvm->arch.disabled_quirks = KVM_QUIRK_CD_AS_WB;
-}
-
long kvm_arch_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -7671,8 +7666,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
INIT_DELAYED_WORK(&kvm->arch.kvmclock_update_work, kvmclock_update_fn);
INIT_DELAYED_WORK(&kvm->arch.kvmclock_sync_work, kvmclock_sync_fn);
- kvm_init_disabled_quirks(kvm);
-
return 0;
}
to avoid the double negation and invert the meaning of KVM_QUIRK_CD_AS_WB.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: Fix double addition of sysfs links
On 22-07-15, 14:15, Russell King - ARM Linux wrote:
> > + /* sysfs links are only created on subsys callback */
> > + if (sif && policy) {
> > + pr_debug("%s: Adding symlink for CPU: %u\n", __func__, cpu);
>
> dev_dbg() ?
Hmm, right.
> > + ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
> > + if (ret) {
> > + dev_err(dev, "%s: Failed to create link for cpu %d
> > (%d)\n",
Rafael updated this instead with dev_dbg :), I am sending separate
patches to fix that now.
> > + __func__, cpu, ret);
>
> I wonder why we print the CPU number - since it's from dev->id, isn't it
> included in the struct device name printed by dev_err() already?
:(
> > + return ret;
> > + }
> > +
> > + /* Track CPUs for which sysfs links are created */
> > + cpumask_set_cpu(cpu, policy->symlinks);
> > + }
> > +
>
> I guess this will do for -rc, but it's not particularly nice. Can I
> suggest splitting the two operations here - the add_dev callback from
> the subsys interface, and the handling of hotplug online/offline
> notifications.
>
> You only need to do the above for the subsys interface, and you only
> need to do the remainder if the CPU was online.
>
> Also, what about the CPU "owning" the policy?
>
> So, this would become:
>
> static int cpufreq_cpu_online(struct device *dev)
> {
> pr_debug("bringing CPU%d online\n", dev->id);
> ... stuff to do when CPU is online ...
> }
>
> static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
> {
> unsigned int cpu = dev->id;
> struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
>
> pr_debug("adding CPU %u\n", cpu);
>
> if (policy && policy->kobj_cpu != cpu) {
> dev_dbg(dev, "%s: Adding cpufreq symlink\n", __func__);
> ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
> if (ret) {
> dev_err(dev,
> "%s: Failed to create cpufreq symlink (%d)\n",
> __func__, ret);
> return ret;
> }
>
> /* Track CPUs for which sysfs links are created */
> cpumask_set_cpu(cpu, policy->symlinks);
> }
>
> /* Now do the remainder if the CPU is already online */
> if (cpu_online(cpu))
> return cpufreq_cpu_online(dev);
>
> return 0;
> }
>
> Next, change the cpufreq_add_dev(dev, NULL) in the hotplug notifier call
> to cpufreq_cpu_online(dev) instead.
>
> Doing the similar thing for the cpufreq_remove_dev() path would also make
> sense.
Hmmm, Looks better ofcourse.
> > @@ -1521,42 +1472,54 @@ static int __cpufreq_remove_dev_finish(struct
> > device *dev,
> > static int cpufreq_remove_dev(struct device *dev, struct subsys_interface
> > *sif)
> > {
> > unsigned int cpu = dev->id;
> > + struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> > int ret;
> >
> > - /*
> > -* Only possible if 'cpu' is getting physically removed now. A hotplug
> > -* notifier should have already been called and we just need to remove
> > -* link or free policy here.
> > -*/
> > - if (cpu_is_offline(cpu)) {
> > - struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> > - struct cpumask mask;
> > + if (!policy)
> > + return 0;
> >
> > - if (!policy)
> > - return 0;
> > + if (cpu_online(cpu)) {
> > + ret = __cpufreq_remove_dev_prepare(dev, sif);
> > + if (!ret)
> > + ret = __cpufreq_remove_dev_finish(dev, sif);
> > + if (ret)
> > + return ret;
>
> Here, I have to wonder about this. If you look at the code in
> drivers/base/bus.c, you'll notice that the ->remove_dev return code is
> not used
Its not even using the return type of ->add_dev :), I have send an
update for that recently as that was required for cpufreq-drivers.
Greg must be applying that for 4.3 I hope :)
> (personally, I hate interfaces which are created with an int
> return type for a removal operation, but then ignore the return code.
> Either have the return code and use it, or don't confuse driver authors
> by having one.)
+1
> What this means is that in the remove path, the device _is_ going away,
> whether you like it or not. So, if you have an error early in your
> remove path, returning that error does you no good - you end up leaking
> memory because subsequent cleanup doesn't get done.
>
> It's better to either ensure that your removal path can't fail, or if it
> can, to reasonably clean up as much as you can (which here, means
> continuing to remove the symlink.)
>
> If you adopt my suggestion above, then cpufreq_remove_dev() becomes
> something like:
>
> static int cpufreq_remove_dev(struct device *dev, struct subsy
Re: Why linux console designed to work in polling mode?
Hi Peter, I always know the oops enter point(?). Why i can't just switch to old mode (per char busyloop) in this case and do things like in old console unlock? Actually, i suspect that there might be some reliability problems with this deferred stuff, but, actually, i can't come up with a test case (the only one - stuck on all CPUs with disabled interrupts). Thank you for respond. On Wed, 22 Jul 2015 17:36:56 -0400 Peter Hurley wrote: > Hi Alexander, > > On 07/22/2015 04:08 PM, Alexander wrote: > > Hi. Thanks for respond. > > Don't understand how this affects described logic (deferred printk). > > Suppose you put bytes to UART FIFO in console_unlock() until you can, > > after this up_console_sem and move forward. In UART interrupt you will > > do the same thing: get char from log_buf, put into UART FIFO until it > > will be full then break. How the fact that printk could be called from any > > context > > interfere this? Other way round, this logic will eliminate busyloop > > and decrease printk time significantly (including printk in interrupts etc) > >> it is not easy to implement in a context that you can’t call any sleep > >> function. > > Deferred printing is done in UART interrupt, there is no need to sleep > > anywhere ... > > Here's an example kernel crash report on the serial console with 'deferred' > serial output on typical 16550A h/w: > > [76330.588297] B > > That's not much to diagnose the crash with. > > Regards, > Peter Hurley > > > On Wed, 22 Jul 2015 14:53:13 +0800 > > yalin wang wrote: > > > >> > >>> On Jul 22, 2015, at 14:27, Arun KS wrote: > >>> > >>> When i checked how kernel printing works, i mentioned that it takes > >>> messages from log_buffer in console_unlock and gives it to > >>> call_console_drivers -> ...-> some uart bsp function. Basically, as i > >>> see this BSP realization tries to flush all message chars in busyloop > >>> ... so it waits until FIFO_NOT_FULL bit will be dropped by UART and it > >>> will be able to push the next byte. Basically, as i see userspace > >>> printing do something different. It puts N_FIFO_BYTES and exits, next, > >>> when FIFO will be freed - interrupt will be generated, and other > >>> characters will be put into UART FIFO. > >>> Can we do something similar for kernel printing? i.e. do not busyloop > >>> sending char after char, but put N_FIFO chars and flush other in > >>> interrupt. When panic will occur we can do busyloop printing again. Is > >>> it reliable? Suppose we have several cores. > >>> > >>> > >> > >> i think it is because printk is very different from other printf function > >> in user space, > >> printk() can be called in any context atomic / non- atomic / irq / > >> soft-irq context .. > >> > >> so your bsp->print function can’t be sleep, can’t call any sleep > >> functions . > >> > >> another reason is that in console_unlock() function, it call bas->print > >> like this: > >>call_console_drivers(level, ext_text, ext_len, text, len); > >> print expect your bsp function print all the text as showed in parameters. > >> and it doesn’t check the return value , > >> so if your driver doesn’t use POLL mode, you should only print > >> N_FIFO_BYTES bytes, > >> this need prink to check return value or need your bsp function to use > >> some special method > >> to send the remaining bytes after received FIFO empty interrupt. > >> it is not easy to implement in a context that you can’t call any sleep > >> function. > >> > >> Thanks > > > -- 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/
[PATCH v2 0/2] Add Mediatek watchdog suspend resume and shutdown
This series add Mediatek watchdog suspend, resume and shutdown support. These patches are based on v4.2-rc1 Change in v2: Use watchdog_active() to check whether watchdog been active. Change to register suspend,resume function to dev_pm_ops Greta Zhang (2): watchdog: add wdt suspend/resume support watchdog: add wdt shutdown callback to disable wdt if enabled drivers/watchdog/mtk_wdt.c | 39 +++ 1 file changed, 39 insertions(+) -- 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/
[PATCH v2 2/2] watchdog: add wdt shutdown callback to disable wdt if enabled
From: Greta Zhang
Without .shutdown(), watchdog might reset the system during power off.
For example, if watchdog's timeout is set to 30s, then it is reset to
zero by mtk_wdt_ping(). During power off, no app will ping watchdog,
but watchdog is still running and may trigger reset.
Signed-off-by: Greta Zhang
Signed-off-by: Eddie Huang
---
drivers/watchdog/mtk_wdt.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 056412c..6ad9df9 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -210,6 +210,14 @@ static int mtk_wdt_probe(struct platform_device *pdev)
return 0;
}
+static void mtk_wdt_shutdown(struct platform_device *pdev)
+{
+ struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
+
+ if (watchdog_active(&mtk_wdt->wdt_dev))
+ mtk_wdt_stop(&mtk_wdt->wdt_dev);
+}
+
static int mtk_wdt_remove(struct platform_device *pdev)
{
struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
@@ -259,6 +267,7 @@ static const struct dev_pm_ops mtk_wdt_pm_ops = {
static struct platform_driver mtk_wdt_driver = {
.probe = mtk_wdt_probe,
.remove = mtk_wdt_remove,
+ .shutdown = mtk_wdt_shutdown,
.driver = {
.name = DRV_NAME,
.pm = &mtk_wdt_pm_ops,
--
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/
[PATCH v2 1/2] watchdog: add wdt suspend/resume support
From: Greta Zhang
add wdt driver suspend/resume support
Signed-off-by: Greta Zhang
Signed-off-by: Roger Lu
Signed-off-by: Eddie Huang
---
drivers/watchdog/mtk_wdt.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 938b987..056412c 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -221,17 +221,47 @@ static int mtk_wdt_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mtk_wdt_suspend(struct device *dev)
+{
+ struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev);
+
+ if (watchdog_active(&mtk_wdt->wdt_dev))
+ mtk_wdt_stop(&mtk_wdt->wdt_dev);
+
+ return 0;
+}
+
+static int mtk_wdt_resume(struct device *dev)
+{
+ struct mtk_wdt_dev *mtk_wdt = dev_get_drvdata(dev);
+
+ if (watchdog_active(&mtk_wdt->wdt_dev)) {
+ mtk_wdt_start(&mtk_wdt->wdt_dev);
+ mtk_wdt_ping(&mtk_wdt->wdt_dev);
+ }
+
+ return 0;
+}
+#endif
+
static const struct of_device_id mtk_wdt_dt_ids[] = {
{ .compatible = "mediatek,mt6589-wdt" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
+static const struct dev_pm_ops mtk_wdt_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mtk_wdt_suspend,
+ mtk_wdt_resume)
+};
+
static struct platform_driver mtk_wdt_driver = {
.probe = mtk_wdt_probe,
.remove = mtk_wdt_remove,
.driver = {
.name = DRV_NAME,
+ .pm = &mtk_wdt_pm_ops,
.of_match_table = mtk_wdt_dt_ids,
},
};
--
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 1/3] Input: export LEDs as class devices in sysfs
On Thu, 23 Jul 2015, Vlastimil Babka wrote: > On 07/22/2015 08:55 PM, Jiri Kosina wrote: > > On Wed, 22 Jul 2015, Vlastimil Babka wrote: > > > > [ ... snip ... ] > >> The mouse has 3 green leds and one red to indicate battery status, but I > >> think > >> they operate autonomously. > > > > It's possible that the mouse is presenting them in the report descriptor > > though (and maybe it's even possible to control them from the host). > > > > Could you please provide contents of > > > > /sys/kernel/debug/hid//rdesc > > For the record, below. I wonder why there's two more "LED.?" lines (7) than > the > warnings I get (5)? Because some of them get successfully (re-)mapped to named LEDs. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm, page_isolation: remove bogus tests for isolated pages
On Tue, Jul 21, 2015 at 02:53:37PM +0200, Vlastimil Babka wrote:
> The __test_page_isolated_in_pageblock() is used to verify whether all pages
> in pageblock were either successfully isolated, or are hwpoisoned. Two of the
> possible state of pages, that are tested, are however bogus and misleading.
>
> Both tests rely on get_freepage_migratetype(page), which however has no
> guarantees about pages on freelists. Specifically, it doesn't guarantee that
> the migratetype returned by the function actually matches the migratetype of
> the freelist that the page is on. Such guarantee is not its purpose and would
> have negative impact on allocator performance.
>
> The first test checks whether the freepage_migratetype equals MIGRATE_ISOLATE,
> supposedly to catch races between page isolation and allocator activity. These
> races should be fixed nowadays with 51bb1a4093 ("mm/page_alloc: add freepage
> on isolate pageblock to correct buddy list") and related patches. As explained
> above, the check wouldn't be able to catch them reliably anyway. For the same
> reason false positives can happen, although they are harmless, as the
> move_freepages() call would just move the page to the same freelist it's
> already on. So removing the test is not a bug fix, just cleanup. After this
> patch, we assume that all PageBuddy pages are on the correct freelist and that
> the races were really fixed. A truly reliable verification in the form of e.g.
> VM_BUG_ON() would be complicated and is arguably not needed.
>
> The second test (page_count(page) == 0 && get_freepage_migratetype(page)
> == MIGRATE_ISOLATE) is probably supposed (the code comes from a big memory
> isolation patch from 2007) to catch pages on MIGRATE_ISOLATE pcplists.
> However, pcplists don't contain MIGRATE_ISOLATE freepages nowadays, those are
> freed directly to free lists, so the check is obsolete. Remove it as well.
>
> Signed-off-by: Vlastimil Babka
> Cc: Joonsoo Kim
> Cc: Minchan Kim
> Cc: Michal Nazarewicz
> Cc: Laura Abbott
> Cc: Naoya Horiguchi
Looks good to me.
Reviewed-by: 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/
[PATCH] mm, page_isolation: make set/unset_migratetype_isolate() file-local
Nowaday, set/unset_migratetype_isolate() is defined and used only in
mm/page_isolation, so let's limit the scope within the file.
Signed-off-by: Naoya Horiguchi
---
include/linux/page-isolation.h | 5 -
mm/page_isolation.c| 5 +++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git v4.2-rc2.orig/include/linux/page-isolation.h
v4.2-rc2/include/linux/page-isolation.h
index 2dc1e1697b45..047d64706f2a 100644
--- v4.2-rc2.orig/include/linux/page-isolation.h
+++ v4.2-rc2/include/linux/page-isolation.h
@@ -65,11 +65,6 @@ undo_isolate_page_range(unsigned long start_pfn, unsigned
long end_pfn,
int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn,
bool skip_hwpoisoned_pages);
-/*
- * Internal functions. Changes pageblock's migrate type.
- */
-int set_migratetype_isolate(struct page *page, bool skip_hwpoisoned_pages);
-void unset_migratetype_isolate(struct page *page, unsigned migratetype);
struct page *alloc_migrate_target(struct page *page, unsigned long private,
int **resultp);
diff --git v4.2-rc2.orig/mm/page_isolation.c v4.2-rc2/mm/page_isolation.c
index 32fdc1df05e5..4568fd58f70a 100644
--- v4.2-rc2.orig/mm/page_isolation.c
+++ v4.2-rc2/mm/page_isolation.c
@@ -9,7 +9,8 @@
#include
#include "internal.h"
-int set_migratetype_isolate(struct page *page, bool skip_hwpoisoned_pages)
+static int set_migratetype_isolate(struct page *page,
+ bool skip_hwpoisoned_pages)
{
struct zone *zone;
unsigned long flags, pfn;
@@ -72,7 +73,7 @@ int set_migratetype_isolate(struct page *page, bool
skip_hwpoisoned_pages)
return ret;
}
-void unset_migratetype_isolate(struct page *page, unsigned migratetype)
+static void unset_migratetype_isolate(struct page *page, unsigned migratetype)
{
struct zone *zone;
unsigned long flags, nr_pages;
--
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] Input: LEDs - skip unnamed LEDs
On 07/23/2015 12:02 AM, Dmitry Torokhov wrote:
> Devices may declare more LEDs than what is known to input-leds
> (HID does this for some devices). Instead of showing ugly warnings
> on connect and, even worse, oopsing on disconnect, let's simply
> ignore LEDs that are not known to us.
>
> Reported-by: Vlastimil Babka
> Signed-off-by: Dmitry Torokhov
Thanks, I'll test it tomorrow, due to being elsewhere than the machine with the
mouse today.
> ---
> drivers/input/input-leds.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
> index 074a65e..766bf26 100644
> --- a/drivers/input/input-leds.c
> +++ b/drivers/input/input-leds.c
> @@ -71,6 +71,18 @@ static void input_leds_event(struct input_handle *handle,
> unsigned int type,
> {
> }
>
> +static int input_leds_get_count(struct input_dev *dev)
> +{
> + unsigned int led_code;
> + int count = 0;
> +
> + for_each_set_bit(led_code, dev->ledbit, LED_CNT)
> + if (input_led_info[led_code].name)
> + count++;
> +
> + return count;
> +}
> +
> static int input_leds_connect(struct input_handler *handler,
> struct input_dev *dev,
> const struct input_device_id *id)
> @@ -81,7 +93,7 @@ static int input_leds_connect(struct input_handler *handler,
> int led_no;
> int error;
>
> - num_leds = bitmap_weight(dev->ledbit, LED_CNT);
> + num_leds = input_leds_get_count(dev);
> if (!num_leds)
> return -ENXIO;
>
> @@ -112,7 +124,7 @@ static int input_leds_connect(struct input_handler
> *handler,
> led->handle = &leds->handle;
> led->code = led_code;
>
> - if (WARN_ON(!input_led_info[led_code].name))
> + if (!input_led_info[led_code].name)
> continue;
>
> led->cdev.name = kasprintf(GFP_KERNEL, "%s::%s",
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] redesign compaction algorithm
On Tue, Jul 21, 2015 at 11:27:54AM +0200, Vlastimil Babka wrote: > On 07/08/2015 10:24 AM, Joonsoo Kim wrote: > >On Fri, Jun 26, 2015 at 11:22:41AM +0100, Mel Gorman wrote: > >>On Fri, Jun 26, 2015 at 11:07:47AM +0900, Joonsoo Kim wrote: > >> > >>The whole reason we avoid migrating to unmovable blocks is because it > >>did happen and quite quickly. Do not use unmovable blocks as migration > >>targets. If high-order kernel allocations are required then some reclaim > >>is necessary for compaction to work with. > > > >Hello, Mel and Vlastimil. > > > >Sorry for late response. I need some time to get the number and it takes > >so long due to bugs on page owner. Before mentioning about this patchset, > >I should mention that result of my previous patchset about active > >fragmentation avoidance that you have reviewed is wrong. Incorrect result > >is caused by page owner bug and correct result shows just slight > >improvement rather than dramatical improvment. > > > >https://lkml.org/lkml/2015/4/27/92 > > Doh, glad you found the bug. > BTW I still think patch 1 of that series would make sense and it's a > code cleanup too. Patch 2 would depend on the corrected > measurements. Patch 3 also, and the active anti-fragmentation work > could be done by kcompactd if the idea of that thread floats. Yes, I don't give up those patches. :) > > >Back to our discussion, indeed, you are right. As you expected, > >fragmentation increases due to this patch. It's not much but adding > >other changes of this patchset accelerates fragmentation more so > >it's not tolerable in the end. > > > >Below is number of *non-mixed* pageblock measured by page owner > >after running modified stress-highalloc test that repeats test 3 times > >without rebooting like as Vlastimil did. > > > >pb[n] means that it is measured after n times runs of stress-highalloc > >test without rebooting. They are averaged by 3 runs. > > > > base nonmovable redesign revert-nonmovable > >pb[1]:DMA32:movable:1359133313031380 > >pb[1]:Normal:movable: 368 341 356 364 > > > >pb[2]:DMA32:movable:1306127712161322 > >pb[2]:Normal:movable: 359 345 325 349 > > > >pb[3]:DMA32:movable:1265124011791276 > >pb[3]:Normal:movable: 330 330 312 332 > > > >Allowing scanning on nonmovable pageblock increases fragmentation so > >non-mixed pageblock is reduced by rougly 2~3%. Whole of this patchset > >bumps this reduction up to roughly 6%. But, with reverting nonmovable > >patch, it get restored and looks better than before. > > Hm that's somewhat strange. Why is it only the *combination* of > "nonmovable" and "redesign" that makes it so bad? I guess that freepage scanner scans limited zone range in nonmovable case so bad effect is also limited. > >Nevertheless, still, I'd like to change freepage scanner's behaviour > >because there are systems that most of pageblocks are unmovable pageblock. > >In this kind of system, without this change, compaction would not > >work well as my experiment, build-frag-unmovable, showed, and essential > >high-order allocation fails. > > > >I have no idea how to overcome this situation without this kind of change. > >If you have such a idea, please let me know. > > Hm it's a tough one :/ > > >Here is similar idea to handle this situation without causing more > >fragmentation. Changes as following: > > > >1. Freepage scanner just scan only movable pageblocks. > >2. If freepage scanner doesn't find any freepage on movable pageblocks > >and whole zone range is scanned, freepage scanner start to scan on > >non-movable pageblocks. > > > >Here is the result. > > new-idea > >pb[1]:DMA32:movable:1371 > >pb[1]:Normal:movable:384 > > > >pb[2]:DMA32:movable:1322 > >pb[2]:Normal:movable:372 > > > >pb[3]:DMA32:movable:1273 > >pb[3]:Normal:movable:358 > > > >Result is better than revert-nonmovable case. Although I didn't attach > >the whole result, this one is better than revert one in term of success > >rate. > > > >Before starting to optimize this idea, I'd like to hear your opinion > >about this change. > > Well, it might be better than nothing. Optimization could be > remembering from the first pass which pageblock was the emptiest? > But that would make the first pass more involved, so I'm not sure. Now, I don't have any idea for it. I need more think. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] Input: export LEDs as class devices in sysfs
On 07/22/2015 08:55 PM, Jiri Kosina wrote: > On Wed, 22 Jul 2015, Vlastimil Babka wrote: > > [ ... snip ... ] >> The mouse has 3 green leds and one red to indicate battery status, but I >> think >> they operate autonomously. > > It's possible that the mouse is presenting them in the report descriptor > though (and maybe it's even possible to control them from the host). > > Could you please provide contents of > > /sys/kernel/debug/hid//rdesc For the record, below. I wonder why there's two more "LED.?" lines (7) than the warnings I get (5)? gusiac:~ # cat /sys/kernel/debug/hid/0003\:046D\:C50E.0003/rdesc 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 08 15 00 25 01 95 08 75 01 81 02 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 05 0c 0a 38 02 95 01 81 06 09 3c 15 00 25 01 75 01 95 01 b1 22 95 07 b1 01 05 08 09 4b 15 00 25 01 95 08 75 01 81 02 05 09 19 09 29 10 81 02 c0 INPUT[INPUT] Field(0) Physical(GenericDesktop.Pointer) Application(GenericDesktop.Mouse) Usage(8) Button.0001 Button.0002 Button.0003 Button.0004 Button.0005 Button.0006 Button.0007 Button.0008 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(8) Report Offset(0) Flags( Variable Absolute ) Field(1) Physical(GenericDesktop.Pointer) Application(GenericDesktop.Mouse) Usage(3) GenericDesktop.X GenericDesktop.Y GenericDesktop.Wheel Logical Minimum(-127) Logical Maximum(127) Report Size(8) Report Count(3) Report Offset(8) Flags( Variable Relative ) Field(2) Application(GenericDesktop.Mouse) Usage(1) Consumer.HorizontalWheel Logical Minimum(-127) Logical Maximum(127) Report Size(8) Report Count(1) Report Offset(32) Flags( Variable Relative ) Field(3) Application(GenericDesktop.Mouse) Usage(8) LED.GenericIndicator LED.GenericIndicator LED.GenericIndicator LED.GenericIndicator LED.GenericIndicator LED.GenericIndicator LED.GenericIndicator LED.GenericIndicator Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(8) Report Offset(40) Flags( Variable Absolute ) Field(4) Application(GenericDesktop.Mouse) Usage(8) Button.0009 Button.000a Button.000b Button.000c Button.000d Button.000e Button.000f Button.0010 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(8) Report Offset(48) Flags( Variable Absolute ) FEATURE[FEATURE] Field(0) Application(GenericDesktop.Mouse) Usage(1) Consumer.003c Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(1) Report Offset(0) Flags( Variable Absolute NoPreferredState ) Button.0001 ---> Key.LeftBtn Button.0002 ---> Key.RightBtn Button.0003 ---> Key.MiddleBtn Button.0004 ---> Key.SideBtn Button.0005 ---> Key.ExtraBtn Button.0006 ---> Key.ForwardBtn Button.0007 ---> Key.BackBtn Button.0008 ---> Key.TaskBtn GenericDesktop.X ---> Relative.X GenericDesktop.Y ---> Relative.Y GenericDesktop.Wheel ---> Relative.Wheel Consumer.HorizontalWheel ---> Relative.HWheel LED.GenericIndicator ---> LED.Misc LED.GenericIndicator ---> LED.? LED.GenericIndicator ---> LED.? LED.GenericIndicator ---> LED.? LED.GenericIndicator ---> LED.? LED.GenericIndicator ---> LED.? LED.GenericIndicator ---> LED.? LED.GenericIndicator ---> LED.? Button.0009 ---> Key.? Button.000a ---> Key.? Button.000b ---> Key.? Button.000c ---> Key.? Button.000d ---> Key.? Button.000e ---> Key.? Button.000f ---> Key.? Button.0010 ---> Key.? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm: rename and move get/set_freepage_migratetype
On Wed, Jul 22, 2015 at 02:29:08PM +0200, Vlastimil Babka wrote: > On 07/21/2015 02:53 PM, Vlastimil Babka wrote: > > The pair of get/set_freepage_migratetype() functions are used to cache > > pageblock migratetype for a page put on a pcplist, so that it does not have > > to be retrieved again when the page is put on a free list (e.g. when > > pcplists > > become full). Historically it was also assumed that the value is accurate > > for > > pages on freelists (as the functions' names unfortunately suggest), but that > > cannot be guaranteed without affecting various allocator fast paths. It is > > in > > fact not needed and all such uses have been removed. > > > > The last remaining (but pointless) usage related to pages of freelists is in > > move_freepages(), which this patch removes. > > I realized there's one more callsite that can be removed. Here's > whole updated patch due to different changelog and to cope with > context changed by the fixlet to patch 1/2. > > --8<-- > From: Vlastimil Babka > Date: Thu, 2 Jul 2015 16:37:06 +0200 > Subject: mm: rename and move get/set_freepage_migratetype > > The pair of get/set_freepage_migratetype() functions are used to cache > pageblock migratetype for a page put on a pcplist, so that it does not have > to be retrieved again when the page is put on a free list (e.g. when pcplists > become full). Historically it was also assumed that the value is accurate for > pages on freelists (as the functions' names unfortunately suggest), but that > cannot be guaranteed without affecting various allocator fast paths. It is in > fact not needed and all such uses have been removed. > > The last two remaining (but pointless) usages related to pages of freelists > are removed by this patch: > - move_freepages() which operates on pages already on freelists > - __free_pages_ok() which puts a page directly to freelist, bypassing pcplists > > To prevent further confusion, rename the functions to > get/set_pcppage_migratetype() and expand their description. Since all the > users are now in mm/page_alloc.c, move the functions there from the shared > header. > > Signed-off-by: Vlastimil Babka > Acked-by: David Rientjes Acked-by: Joonsoo Kim Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm, page_isolation: remove bogus tests for isolated pages
On Tue, Jul 21, 2015 at 02:53:37PM +0200, Vlastimil Babka wrote:
> The __test_page_isolated_in_pageblock() is used to verify whether all pages
> in pageblock were either successfully isolated, or are hwpoisoned. Two of the
> possible state of pages, that are tested, are however bogus and misleading.
>
> Both tests rely on get_freepage_migratetype(page), which however has no
> guarantees about pages on freelists. Specifically, it doesn't guarantee that
> the migratetype returned by the function actually matches the migratetype of
> the freelist that the page is on. Such guarantee is not its purpose and would
> have negative impact on allocator performance.
>
> The first test checks whether the freepage_migratetype equals MIGRATE_ISOLATE,
> supposedly to catch races between page isolation and allocator activity. These
> races should be fixed nowadays with 51bb1a4093 ("mm/page_alloc: add freepage
> on isolate pageblock to correct buddy list") and related patches. As explained
> above, the check wouldn't be able to catch them reliably anyway. For the same
> reason false positives can happen, although they are harmless, as the
> move_freepages() call would just move the page to the same freelist it's
> already on. So removing the test is not a bug fix, just cleanup. After this
> patch, we assume that all PageBuddy pages are on the correct freelist and that
> the races were really fixed. A truly reliable verification in the form of e.g.
> VM_BUG_ON() would be complicated and is arguably not needed.
>
> The second test (page_count(page) == 0 && get_freepage_migratetype(page)
> == MIGRATE_ISOLATE) is probably supposed (the code comes from a big memory
> isolation patch from 2007) to catch pages on MIGRATE_ISOLATE pcplists.
> However, pcplists don't contain MIGRATE_ISOLATE freepages nowadays, those are
> freed directly to free lists, so the check is obsolete. Remove it as well.
>
> Signed-off-by: Vlastimil Babka
Acked-by: Joonsoo Kim
Thanks for taking care of this.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm/page_owner: set correct gfp_mask on page_owner
Hello, all. On Mon, Jul 20, 2015 at 08:54:13PM +0900, Minchan Kim wrote: > On Mon, Jul 20, 2015 at 01:27:55PM +0200, Vlastimil Babka wrote: > > On 07/16/2015 02:06 AM, Minchan Kim wrote: > > >On Wed, Jul 15, 2015 at 03:33:59PM +0900, Joonsoo Kim wrote: > > >>@@ -2003,7 +2005,7 @@ int __isolate_free_page(struct page *page, unsigned > > >>int order) > > >> zone->free_area[order].nr_free--; > > >> rmv_page_order(page); > > >> > > >>- set_page_owner(page, order, 0); > > >>+ set_page_owner(page, order, __GFP_MOVABLE); > > > > > >It seems the reason why __GFP_MOVABLE is okay is that __isolate_free_page > > >works on a free page on MIGRATE_MOVABLE|MIGRATE_CMA's pageblock. But if we > > >break the assumption in future, here is broken again? > > > > I didn't study the page owner code yet and I'm catching up after > > vacation, but I share your concern. But I don't think the > > correctness depends on the pageblock we are isolating from. I think > > the assumption is that the isolated freepage will be used as a > > target for migration, and that only movable pages can be > > successfully migrated (but also CMA pages, and that information can > > be lost?). However there are also efforts to allow migrate e.g. > > driver pages that won't be marked as movable. And I'm not sure which > > migratetype are balloon pages which already have special migration > > code. FYI, migratetype of ballon pages is also MIGRATE_MOVABLE if balloon compaction is enabled. > I am one of people who want to migrate driver pages from compaction > from zram point of view so I agree with you. > However, If I make zram support migratepages, I will use __GFP_MOVABLE. > So, I'm not sure there is any special driver that it can support migrate > via migratepage but it doesn't set __GFP_MOVABLE. > > Having said that, I support your opinion because __GFP_MOVABLE is not > only gfp mask for allocating so we should take care of complete gfp > mask from original page. Ah... In this patch, I've solved the issue very narrowly. It works for me to get correct fragmentation information but not generally correct. It's my mistake. There is another information like as stack trace so I should take care of it, too. I will handle it in migration function. > > > > > So what I would think (without knowing all details) that the page > > owner info should be transferred during page migration with all the > > other flags, and shouldn't concern __isolate_free_page() at all? > > > > I agree. Okay. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: Add STM32429i-EVAL board support
Hi Olof,
2015-07-23 1:42 GMT+02:00 Olof Johansson :
> Hi,
>
> On Sun, Jul 12, 2015 at 2:39 AM, Maxime Coquelin
> wrote:
>
>> +/ {
>> + model = "STMicroelectronics STM32429i-EVAL board";
>> + compatible = "st,stm32429i-eval", "st,stm32f429";
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200 root=/dev/ram
>> rdinit=/linuxrc";
>> + linux,stdout-path = &usart1;
>
> You should use stdout-path here instead, and with that you'll no
> longer need the console arg in the bootargs.
>
> See: https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
Thanks for the hint! I was not aware of that.
I will send the new pull request fixing this, and also fixing
STM32F429 Discovery board shortly.
Thanks,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] Initial support for user namespace owned mounts
On Wed, Jul 22, 2015 at 07:15:19PM -0500, Eric W. Biederman wrote:
> Casey Schaufler writes:
>
> > On 7/22/2015 12:32 PM, Seth Forshee wrote:
> >> On Wed, Jul 22, 2015 at 11:10:46AM -0700, Casey Schaufler wrote:
> >>> On 7/22/2015 8:56 AM, Seth Forshee wrote:
> On Tue, Jul 21, 2015 at 06:52:31PM -0700, Casey Schaufler wrote:
> > On 7/21/2015 1:35 PM, Seth Forshee wrote:
> >> On Thu, Jul 16, 2015 at 05:59:22PM -0700, Andy Lutomirski wrote:
> >>> On Thu, Jul 16, 2015 at 5:45 PM, Casey Schaufler
> >>> wrote:
> On 7/16/2015 4:29 PM, Andy Lutomirski wrote:
> > I really don't see the benefit of making up extra rules that apply
> > to
> > users outside a userns who try to access specifically a filesystem
> > with backing store. They wouldn't make sense for filesystems
> > without
> > backing store.
> Sure it would. For Smack, it would be the label a file would be
> created with, which would be the label of the process creating
> the memory based filesystem. For SELinux the rules are more a
> touch more sophisticated, but I'm sure that Paul or Stephen could
> come up with how to determine it.
>
> The point, looping all the way back to the beginning, where we
> were talking about just ignoring the labels on the filesystem,
> is that if you use the same Smack label on the files in the
> filesystem as the backing store file has, we'll all be happy.
> If that label isn't something user can write to, he won't be
> able to write to the mounted objects, either. If there is no
> backing store then use the label of the process creating the
> filesystem, which will be the user, which will mean everything
> will work hunky dory.
>
> Yes, there's work involved, but I doubt there's a lot. Getting
> the label from the backing store or the creating process is
> simple enough.
>
> >> So something like the diff below (untested)?
> > I think that this is close, and quite good for someone
> > who isn't very familiar with Smack. It's definitely headed
> > in the right direction.
> >
> >> All I'm really doing is setting smk_default as you describe above and
> >> then using it instead of smk_of_current() in
> >> smack_inode_alloc_security() and instead of the label from the disk in
> >> smack_d_instantiate().
> > Let's say your backing store is a file labeled Rubble.
> >
> > mount -o smackfsroot=Rubble,smackfsdef=Rubble ...
> >
> > It is completely reasonable for a process labeled Flintstone to
> > have rwxa access to a file labeled Rubble.
> >
> > Smack rule: Flintstone Rubble rwxa
> >
> > In the case of writing to an existing Rubble file, what you
> > have looks fine. What's not so great is that if the Flintstone
> > process creates a file, it should be labeled Flintstone. Your
> > use of the smk_default, which is going to violate the principle
> > of least astonishment, and break the Smack policy as well.
> >
> > Let's make a minor change. Instead of using smackfsroot let's
> > use smackfstransmute and a slightly different access rule:
> >
> > mount -o smackfstransmute=Rubble,smackfsdef=Rubble ...
> >
> > Smack rule: Flintstone Rubble rwxat
> >
> > Now the only change we have to make to the Smack code is
> > that we don't want to create any files unless either the
> > process is labeled Rubble or the rule allowing the creation
> > has the "t" for transmute access. That should ensure that
> > everything is labeled Rubble. If it isn't, someone has mucked
> > with the metadata in a detectable way.
> All right, that kind of makes sense, but I'm still missing some pieces.
> Questions follow.
>
> >> diff --git a/include/linux/fs.h b/include/linux/fs.h
> >> index 32f598db0b0d..4597420ab933 100644
> >> --- a/include/linux/fs.h
> >> +++ b/include/linux/fs.h
> >> @@ -1486,6 +1486,10 @@ static inline void sb_start_intwrite(struct
> >> super_block *sb)
> >>__sb_start_write(sb, SB_FREEZE_FS, true);
> >> }
> >>
> >> +static inline bool sb_in_userns(struct super_block *sb)
> >> +{
> >> + return sb->s_user_ns != &init_user_ns;
> >> +}
> >>
> >> extern bool inode_owner_or_capable(const struct inode *inode);
> >>
> >> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> >> index a143328f75eb..591fd19294e7 100644
> >> --- a/security/smack/smack_lsm.c
> >> +++ b/security/smack/smack_lsm.c
> >> @@ -255,6 +255,10 @@ static struct smack_known *smk_fetch(const char
> >> *name, struct inode *ip,
> >>char *buffer;
> >>struct smack_known *skp = NULL;
> >>
> >> + /* Should ne
Re: [PATCH] cpupower: Do not change the frequency of offline cpu
Hi Shilpa,
This looks good.
Reviewed-by: Gautham R. Shenoy
On Wed, Jul 22, 2015 at 01:50:49PM +0530, Shilpasri G Bhat wrote:
> Check if the cpu is online before changing the frequency/governor of
> the cpu.
>
> Signed-off-by: Shilpasri G Bhat
> ---
> tools/power/cpupower/utils/cpufreq-set.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/power/cpupower/utils/cpufreq-set.c
> b/tools/power/cpupower/utils/cpufreq-set.c
> index f656e58..4e21357 100644
> --- a/tools/power/cpupower/utils/cpufreq-set.c
> +++ b/tools/power/cpupower/utils/cpufreq-set.c
> @@ -17,6 +17,7 @@
>
> #include "cpufreq.h"
> #include "helpers/helpers.h"
> +#include "helpers/sysfs.h"
>
> #define NORM_FREQ_LEN 32
>
> @@ -318,6 +319,9 @@ int cmd_freq_set(int argc, char **argv)
> cpufreq_cpu_exists(cpu))
> continue;
>
> + if (sysfs_is_cpu_online(cpu) != 1)
> + continue;
> +
> printf(_("Setting cpu: %d\n"), cpu);
> ret = do_one_cpu(cpu, &new_pol, freq, policychange);
> if (ret) {
> --
> 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: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
On Wed, Jul 22, 2015 at 11:28:06AM -0500, Eric Sandeen wrote: > On 7/22/15 8:34 AM, Mike Snitzer wrote: > > On Tue, Jul 21 2015 at 10:37pm -0400, > > Dave Chinner wrote: > >> On Tue, Jul 21, 2015 at 09:40:29PM -0400, Mike Snitzer wrote: > >>> I'm open to considering alternative interfaces for getting you the info > >>> you need. I just don't have a great sense for what mechanism you'd like > >>> to use. Do we invent a new block device operations table method that > >>> sets values in a 'struct no_space_strategy' passed in to the > >>> blockdevice? > >> > >> It's long been frowned on having the filesystems dig into block > >> device structures. We have lots of wrapper functions for getting > >> information from or performing operations on block devices. (e.g. > >> bdev_read_only(), bdev_get_queue(), blkdev_issue_flush(), > >> blkdev_issue_zeroout(), etc) and so I think this is the pattern we'd > >> need to follow. If we do that - bdev_get_nospace_strategy() - then > >> how that information gets to the filesystem is completely opaque > >> at the fs level, and the block layer can implement it in whatever > >> way is considered sane... > >> > >> And, realistically, all we really need returned is a enum to tell us > >> how the bdev behaves on enospc: > >>- bdev fails fast, (i.e. immediate ENOSPC) > >>- bdev fails slow, (i.e. queue for some time, then ENOSPC) > >>- bdev never fails (i.e. queue forever) > >>- bdev doesn't support this (i.e. EOPNOTSUPP) > > I'm not sure how this is more useful than the bdev simply responding to > a query of "should we keep trying IOs?" - bdev fails fast, (i.e. immediate ENOSPC) XFS should use a bound retry behaviour for to allow the possiblity of the admin adding more space before we shut down the fs. i.e. XFS fails slow. - bdev fails slow, (i.e. queue for some time, then ENOSPC) We know that IOs are going to be delayed before they are failed, so there's no point in retrying as the admin has already had a chance to resolve the ENOSPC condition before failure was reported. i.e. XFS fails fast. - bdev never fails (i.e. queue forever) Block device will appear to hang when it runs out of space. Nothing XFS can do here because IOs never fail, but we need to note this in the log at mount time so that filesystem hangs are easily explained when reported to us. - bdev doesn't support this (i.e. EOPNOTSUPP) XFS uses default "retry forever" behaviour. > > This 'struct no_space_strategy' would be invented purely for > > informational purposes for upper layers' benefit -- I don't consider it > > a "block device structure" it the traditional sense. > > > > I was thinking upper layers would like to know the actual timeout value > > for the "fails slow" case. As such the 'struct no_space_strategy' would > > have the enum and the timeout. And would be returned with a call: > > bdev_get_nospace_strategy(bdev, &no_space_strategy) > > Asking for the timeout value seems to add complexity. It could change after > we ask, and knowing it now requires another layer to be handling timeouts... I don't think knowing the bdev timeout is necessary because the default is most likely to be "fail fast" in this case. i.e. no retries, just shut down. IOWs, if we describe the configs and actions in neutral terms, then the default configurations easy for users to understand. i.e: bdev enospc XFS default --- --- Fail slow Fail fast Fail fast Fail slow Fail never Fail never, Record in log EOPNOTSUPP Fail never With that in mind, I'm thinking I should drop the "permanent/transient" error classifications, and change it "failure behaviour" with the options "fast slow [never]" and only the slow option has retry/timeout configuration options. I think the "never" option still needs to "fail at unmount" config variable, but we enable it by default rather than hanging unmount and requiring a manual shutdown like we do now Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: Use stdout-path in STM32F429 Discovery board
This patch replaces use of linux,stdout-path by stdout-path as per
"chosen" DT bindings documentation.
Doing that, the "console" argument is no more needed in kernel command
line.
Reported-by: Olof Johansson
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stm32f429-disco.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
b/arch/arm/boot/dts/stm32f429-disco.dts
index 8bd3de5..f0b731d 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -53,8 +53,8 @@
compatible = "st,stm32f429i-disco", "st,stm32f429";
chosen {
- bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
- linux,stdout-path = &usart1;
+ bootargs = "root=/dev/ram rdinit=/linuxrc";
+ stdout-path = "serial0:115200n8";
};
memory {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mfd: devicetree: bindings: Add clock subdevice node information
2015-07-21 20:07 GMT+09:00 Vaibhav Hiremath : > This patch updates the binding documentation for optional > clocks node and related information for buffered 32KHz clock. > > Signed-off-by: Vaibhav Hiremath > --- > Documentation/devicetree/bindings/mfd/88pm800.txt | 28 > +++ > 1 file changed, 28 insertions(+) +Cc Stephen Boyd (clocks) We had a discussion whether clock bindings should be put in MFD bindings documentation or into separate file in bindings/clock but either way is fine for me: Reviewed-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: [PATCH 1/2] mm/page_owner: fix possible access violation
On Thu, Jul 16, 2015 at 08:53:35AM +0900, Minchan Kim wrote: > On Wed, Jul 15, 2015 at 03:33:58PM +0900, Joonsoo Kim wrote: > > When I tested my new patches, I found that page pointer which is used > > for setting page_owner information is changed. This is because page > > pointer is used to set new migratetype in loop. After this work, > > page pointer could be out of bound. If this wrong pointer is used for > > page_owner, access violation happens. Below is error message that I got. > > > > [ 6175.025217] BUG: unable to handle kernel paging request at > > 00b00018 > > [ 6175.026400] IP: [] save_stack_address+0x30/0x40 > > [ 6175.027341] PGD 1af2d067 PUD 166e0067 PMD 0 > > [ 6175.028129] Oops: 0002 [#1] SMP > > snip... > > [ 6175.055349] Call Trace: > > [ 6175.055780] [] print_context_stack+0xcf/0x100 > > [ 6175.056794] [] ? __module_text_address+0x12/0x70 > > [ 6175.057848] [] dump_trace+0x15f/0x320 > > [ 6175.058751] [] ? do_flush_tlb_all+0x50/0x50 > > [ 6175.059732] [] ? smp_call_function_single+0xb9/0x120 > > [ 6175.060856] [] save_stack_trace+0x2f/0x50 > > [ 6175.061812] [] __set_page_owner+0x46/0x70 > > [ 6175.062774] [] __isolate_free_page+0x1f7/0x210 > > [ 6175.063804] [] split_free_page+0x21/0xb0 > > [ 6175.064757] [] isolate_freepages_block+0x1e2/0x410 > > [ 6175.065855] [] compaction_alloc+0x22d/0x2d0 > > [ 6175.066850] [] migrate_pages+0x289/0x8b0 > > [ 6175.067798] [] ? > > isolate_migratepages_block+0x28a/0x6e0 > > [ 6175.068960] [] ? kmalloc_slab+0xa0/0xa0 > > [ 6175.069892] [] ? > > ftrace_raw_event_mm_compaction_deplete_template+0xc0/0xc0 > > [ 6175.071327] [] compact_zone+0x409/0x880 > > [ 6175.072261] [] compact_zone_order+0x6d/0x90 > > [ 6175.073250] [] try_to_compact_pages+0x110/0x210 > > [ 6175.074297] [] __alloc_pages_direct_compact+0x3d/0xe6 > > [ 6175.075427] [] __alloc_pages_nodemask+0x6cd/0x9a0 > > [ 6175.076517] [] alloc_pages_current+0x91/0x100 > > [ 6175.077545] [] runtest_store+0x296/0xa50 > > [ 6175.078497] [] ? simple_strtoull+0x2c/0x50 > > [ 6175.079465] [] simple_attr_write+0xbd/0xe0 > > [ 6175.080458] [] __vfs_write+0x28/0xf0 > > [ 6175.081349] [] ? __sb_start_write+0x49/0xf0 > > [ 6175.082345] [] ? security_file_permission+0x45/0xd0 > > [ 6175.083453] [] vfs_write+0xa9/0x1b0 > > [ 6175.084334] [] SyS_write+0x46/0xb0 > > [ 6175.085196] [] ? context_tracking_user_enter+0x13/0x20 > > [ 6175.086339] [] ? syscall_trace_leave+0xa5/0x120 > > [ 6175.087389] [] system_call_fastpath+0x16/0x75 > > > > This patch fixes this error by moving up set_page_owner(). > > > > Signed-off-by: Joonsoo Kim > Acked-by: Minchan Kim > > -stable material? Hello, Strangely, I didn't hit the error on the kernel without some of my patches. But, yes, it seems stable candidate. This patch is already merged in the mainline so I will send it to stable tree soon. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] ACPI / sysfs: Add ACPI_LV_REPAIR debug level.
This patch updates debug_level file, adding ACPI_LV_REPAIR.
Signed-off-by: Lv Zheng
---
drivers/acpi/sysfs.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 0876d77b..7ab6ba4 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -69,6 +69,7 @@ static const struct acpi_dlevel acpi_debug_levels[] = {
ACPI_DEBUG_INIT(ACPI_LV_INIT),
ACPI_DEBUG_INIT(ACPI_LV_DEBUG_OBJECT),
ACPI_DEBUG_INIT(ACPI_LV_INFO),
+ ACPI_DEBUG_INIT(ACPI_LV_REPAIR),
ACPI_DEBUG_INIT(ACPI_LV_INIT_NAMES),
ACPI_DEBUG_INIT(ACPI_LV_PARSE),
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ACPI / Documentation: Update method tracing documentation.
This patch updates method tracing documentation. Signed-off-by: Lv Zheng --- Documentation/acpi/method-tracing.txt | 53 - 1 file changed, 39 insertions(+), 14 deletions(-) diff --git a/Documentation/acpi/method-tracing.txt b/Documentation/acpi/method-tracing.txt index f6efb1e..c77f91c 100644 --- a/Documentation/acpi/method-tracing.txt +++ b/Documentation/acpi/method-tracing.txt @@ -1,26 +1,51 @@ /sys/module/acpi/parameters/: trace_method_name - The AML method name that the user wants to trace + The full path of the AML method that the user wants to use with the + "method"/"method-once" tracing mode. + Note that the full path shouldn't contain the trailing "_"s in its + name segments but should contain "\" to form an absolute path. trace_debug_layer - The temporary debug_layer used when tracing the method. - Using 0x by default if it is 0. + The temporary debug_layer used when the tracing feature is enabled. + Using ACPI_EXECUTER (0x80) by default. trace_debug_level - The temporary debug_level used when tracing the method. - Using 0x00ff by default if it is 0. + The temporary debug_level used when the tracing feature is enabled. + Using ACPI_LV_TRACE_POINT (0x10) by default. trace_state The status of the tracing feature. - "enabled" means this feature is enabled - and the AML method is traced every time it's executed. + Users can enable/disable this debug tracing feature by executing + the following command: + # echo string > /sys/module/acpi/parameters/trace_state + Where "string" should be one of the followings: + "disable" + Disable the tracing feature. + "enable" + Enable the tracing feature. + ACPICA debugging messages matching + "trace_debug_layer/trace_debug_level" during any method + execution will be logged. + "method" + Enable the tracing feature. + ACPICA debugging messages matching + "trace_debug_layer/trace_debug_level" during method execution + of "trace_method_name" will be logged. + "method-once" + Enable the tracing feature. + ACPICA debugging messages matching + "trace_debug_layer/trace_debug_level" during method execution + of "trace_method_name" will be logged only once. + "opcode" + Enable the tracing feature. + ACPICA debugging messages matching + "trace_debug_layer/trace_debug_level" during method/opcode + execution of "trace_method_name" will be logged. + "opcode-once" + Enable the tracing feature. + ACPICA debugging messages matching + "trace_debug_layer/trace_debug_level" during method/opcode + execution of "trace_method_name" will be logged only once. - "1" means this feature is enabled and the AML method - will only be traced during the next execution. - - "disabled" means this feature is disabled. - Users can enable/disable this debug tracing feature by - "echo string > /sys/module/acpi/parameters/trace_state". - "string" should be one of "enable", "disable" and "1". -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ACPI / sysfs: Add support to allow leading "\" missing in trace_method_name.
Since _SB.PCI0 can be used as relative path from root and can be easily
converted into internal trace_method_name format, we allow users to specify
trace_method_name using relative paths from root.
Note this is useful for grub2 for which users failed to pass "\" from the
grub configuration file.
Signed-off-by: Lv Zheng
---
drivers/acpi/sysfs.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 8979e4a..40a4265 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -164,14 +164,18 @@ static const struct kernel_param_ops
param_ops_debug_level = {
module_param_cb(debug_layer, ¶m_ops_debug_layer, &acpi_dbg_layer, 0644);
module_param_cb(debug_level, ¶m_ops_debug_level, &acpi_dbg_level, 0644);
-static char* trace_method_name;
-static bool trace_method_kmalloced;
+static char trace_method_name[1024];
int param_set_trace_method_name(const char *val, const struct kernel_param *kp)
{
u32 saved_flags = 0;
+ bool is_abs_path = true;
- if (strlen(val) > 1024) {
+ if (*val != '\\')
+ is_abs_path = false;
+
+ if ((is_abs_path && strlen(val) > 1023) ||
+ (!is_abs_path && strlen(val) > 1022)) {
pr_err("%s: string parameter too long\n", kp->name);
return -ENOSPC;
}
@@ -187,19 +191,13 @@ int param_set_trace_method_name(const char *val, const
struct kernel_param *kp)
acpi_gbl_trace_dbg_layer,
0);
- if (trace_method_kmalloced)
- kfree(trace_method_name);
- trace_method_name = NULL;
- trace_method_kmalloced = false;
-
/* This is a hack. We can't kmalloc in early boot. */
- if (slab_is_available()) {
- trace_method_name = kstrdup(val, GFP_KERNEL);
- if (!trace_method_name)
- return -ENOMEM;
- trace_method_kmalloced = true;
- } else
- trace_method_name = (char *)val;
+ if (is_abs_path)
+ strcpy(trace_method_name, val);
+ else {
+ trace_method_name[0] = '\\';
+ strcpy(trace_method_name+1, val);
+ }
/* Restore the original tracer state */
(void)acpi_debug_trace(trace_method_name,
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ACPI / sysfs: Update method tracing facility.
This patch updates the method tracing facility as the acpi_debug_trace()
API has been updated to allow it to trace AML interpreter execution, the
meanings and the usages of the API parameters are changed due to the
updates.
The new API:
1. Uses ACPI_TRACE_ENABLED flag to indicate the enabling of the tracer;
2. Allows tracer still can be enabled when method name is not specified so
that the AML interpreter execution can be traced without knowing the
method name, which is useful for kernel boot tracing;
3. Supports arbitrary full path name, it doesn't need to be a name related
to an entrance of acpi_evaluate_object().
Note that the sysfs parameters are also updated so that when reading the
attribute files, ACPICA internal settings are returned.
In order to make the sysfs parameters (acpi.trace_state) available during
boot, this patch adds code to bypass ACPICA semaphore/mutex invocations
when acpi mutex utilities haven't been initialized.
This patch doesn't update documentation of method tracing facility, it will
be updated by further patches.
Signed-off-by: Lv Zheng
---
drivers/acpi/osl.c |8 +++
drivers/acpi/sysfs.c | 136 +-
2 files changed, 108 insertions(+), 36 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 1925f1a..21c1e71 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -79,6 +79,7 @@ static void *acpi_irq_context;
static struct workqueue_struct *kacpid_wq;
static struct workqueue_struct *kacpi_notify_wq;
static struct workqueue_struct *kacpi_hotplug_wq;
+static bool acpi_os_initialized;
/*
* This list of permanent mappings is for memory that may be accessed from
@@ -1312,6 +1313,9 @@ acpi_status acpi_os_wait_semaphore(acpi_handle handle,
u32 units, u16 timeout)
long jiffies;
int ret = 0;
+ if (!acpi_os_initialized)
+ return AE_OK;
+
if (!sem || (units < 1))
return AE_BAD_PARAMETER;
@@ -1351,6 +1355,9 @@ acpi_status acpi_os_signal_semaphore(acpi_handle handle,
u32 units)
{
struct semaphore *sem = (struct semaphore *)handle;
+ if (!acpi_os_initialized)
+ return AE_OK;
+
if (!sem || (units < 1))
return AE_BAD_PARAMETER;
@@ -1859,6 +1866,7 @@ acpi_status __init acpi_os_initialize(void)
rv = acpi_os_map_generic_address(&acpi_gbl_FADT.reset_register);
pr_debug(PREFIX "%s: map reset_reg status %d\n", __func__, rv);
}
+ acpi_os_initialized = true;
return AE_OK;
}
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 7ab6ba4..8979e4a 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -70,6 +70,7 @@ static const struct acpi_dlevel acpi_debug_levels[] = {
ACPI_DEBUG_INIT(ACPI_LV_DEBUG_OBJECT),
ACPI_DEBUG_INIT(ACPI_LV_INFO),
ACPI_DEBUG_INIT(ACPI_LV_REPAIR),
+ ACPI_DEBUG_INIT(ACPI_LV_TRACE_POINT),
ACPI_DEBUG_INIT(ACPI_LV_INIT_NAMES),
ACPI_DEBUG_INIT(ACPI_LV_PARSE),
@@ -163,55 +164,118 @@ static const struct kernel_param_ops
param_ops_debug_level = {
module_param_cb(debug_layer, ¶m_ops_debug_layer, &acpi_dbg_layer, 0644);
module_param_cb(debug_level, ¶m_ops_debug_level, &acpi_dbg_level, 0644);
-static char trace_method_name[6];
-module_param_string(trace_method_name, trace_method_name, 6, 0644);
-static unsigned int trace_debug_layer;
-module_param(trace_debug_layer, uint, 0644);
-static unsigned int trace_debug_level;
-module_param(trace_debug_level, uint, 0644);
+static char* trace_method_name;
+static bool trace_method_kmalloced;
-static int param_set_trace_state(const char *val, struct kernel_param *kp)
+int param_set_trace_method_name(const char *val, const struct kernel_param *kp)
{
- int result = 0;
+ u32 saved_flags = 0;
- if (!strncmp(val, "enable", sizeof("enable") - 1)) {
- result = acpi_debug_trace(trace_method_name, trace_debug_level,
- trace_debug_layer, 0);
- if (result)
- result = -EBUSY;
- goto exit;
+ if (strlen(val) > 1024) {
+ pr_err("%s: string parameter too long\n", kp->name);
+ return -ENOSPC;
}
- if (!strncmp(val, "disable", sizeof("disable") - 1)) {
- int name = 0;
- result = acpi_debug_trace((char *)&name, trace_debug_level,
- trace_debug_layer, 0);
- if (result)
- result = -EBUSY;
- goto exit;
- }
+ /*
+* It's not safe to update acpi_gbl_trace_method_name without
+* having the tracer stopped, so we save the original tracer
+* state and disable it.
+*/
+ saved_flags = acpi_gbl_trace_flags;
+ (void)acpi_debug_trace(NULL,
+ acpi_gbl_trace_dbg_level,
+
[PATCH 0/4] ACPI: Update method tracing facility.
This patch updates method tracing facility according to ACPICA 20150717 release changes. Lv Zheng (4): ACPI / sysfs: Add ACPI_LV_REPAIR debug level. ACPI / sysfs: Update method tracing facility. ACPI / Documentation: Update method tracing documentation. ACPI / sysfs: Add support to allow suppress leading "\" in trace_method_name. Documentation/acpi/method-tracing.txt | 53 + drivers/acpi/osl.c|8 ++ drivers/acpi/sysfs.c | 133 - 3 files changed, 145 insertions(+), 49 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: ulpi: call put_device if device_register fails
Hi,
On Wed, Jul 22, 2015 at 08:14:46PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 22, 2015 at 09:04:40PM -0500, Felipe Balbi wrote:
> > On Wed, Jul 22, 2015 at 02:39:34PM -0700, Greg Kroah-Hartman wrote:
> > > On Tue, Jun 23, 2015 at 01:57:38PM +0300, Heikki Krogerus wrote:
> > > > On Fri, Jun 19, 2015 at 01:12:36AM +0800, ChengYi He wrote:
> > > > > put_device is required to release the last reference to the device.
> > > > >
> > > > > Signed-off-by: ChengYi He
> > > > > ---
> > > > > drivers/usb/common/ulpi.c | 4 +++-
> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> > > > > index 0e6f968..bd25bdb 100644
> > > > > --- a/drivers/usb/common/ulpi.c
> > > > > +++ b/drivers/usb/common/ulpi.c
> > > > > @@ -184,8 +184,10 @@ static int ulpi_register(struct device *dev,
> > > > > struct ulpi *ulpi)
> > > > > request_module("ulpi:v%04xp%04x", ulpi->id.vendor,
> > > > > ulpi->id.product);
> > > > >
> > > > > ret = device_register(&ulpi->dev);
> > > > > - if (ret)
> > > > > + if (ret) {
> > > > > + put_device(&ulpi->dev);
> > > >
> > > > If device_register returns failure, put_device has already been
> > > > called. Check device_add in drivers/base/core.c.
> > >
> > > Yes, please read the function, which says:
> > > * NOTE: _Never_ directly free @dev after calling this function, even
> > > * if it returned an error! Always use put_device() to give up your
> > > * reference instead.
> > >
> > > But, the problem is that the ulpi core doesn't "own" that struct device.
> > > It comes from elsewhere. It comes from somewhere deep down in the dw3
> > > core, which is where I lost the path. Something needs to be fixed in
> > > dwc3_probe() to properly clean up the device if it fails, which is not
> > > happening right now.
> > >
> > > So this patch would actually cause much bigger problems than fixing
> > > anything, so it's wrong, but for a different reason than you are talking
> > > about here.
> > >
> > > And ugh, the ulpi and dwc code binding together, what a mess, horrid...
> >
> > any suggestions ? DWC *is* the one implementing the bus. If there's a
> > better way, we can certainly shuffle code around.
>
> As dwc is the only thing using the bus, why is it drivers/usb/core/ ?
musb also has a SW-accessible ULPI bus. And, IIRC, so does DWC2 ;-)
> And the error path here is broken, the bus should be creating the device
> (i.e. no subsystem should ever be registering a device it did not
> create), so that it can properly clean things up when stuff goes wrong.
>
> The whole subsys_init() is also a bad feeling that it's not architected
> correctly, that shouldn't be needed, which is why I never took that
> patch. Just noticed it came in through yours, I wanted it "broken" so
> it would be fixed "properly" and not papered over like this.
I just felt it would be better to 'fix' it for the -rc until it can be
fixed *properly*. A follow up fix should incur no visible changes to
drivers anyway.
--
balbi
signature.asc
Description: Digital signature
[PATCH 01/22] ACPICA: Parser: Reduce parser/namespace divergences for tracer support.
This patch reduces divergences in parser/namespace components so that the
follow-up linuxized ACPICA upstream commits can be directly merged.
Including the fix to an indent issue reported and fixed by Zhouyi Zhou.
Signed-off-by: Lv Zheng
Signed-off-by: Zhouyi Zhou
---
drivers/acpi/acpica/nsnames.c |2 +-
drivers/acpi/acpica/nsparse.c |6 +++---
drivers/acpi/acpica/psloop.c |8
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c
index d293d97..2e37888 100644
--- a/drivers/acpi/acpica/nsnames.c
+++ b/drivers/acpi/acpica/nsnames.c
@@ -108,7 +108,7 @@ acpi_ns_build_external_path(struct acpi_namespace_node
*node,
if (index != 0) {
ACPI_ERROR((AE_INFO,
"Could not construct external pathname; index=%u,
size=%u, Path=%s",
- (u32) index, (u32) size, &name_buffer[size]));
+ (u32)index, (u32)size, &name_buffer[size]));
return (AE_BAD_PARAMETER);
}
diff --git a/drivers/acpi/acpica/nsparse.c b/drivers/acpi/acpica/nsparse.c
index 57a4cfe..9926a67c 100644
--- a/drivers/acpi/acpica/nsparse.c
+++ b/drivers/acpi/acpica/nsparse.c
@@ -70,7 +70,7 @@ acpi_ns_one_complete_parse(u32 pass_number,
{
union acpi_parse_object *parse_root;
acpi_status status;
- u32 aml_length;
+ u32 aml_length;
u8 *aml_start;
struct acpi_walk_state *walk_state;
struct acpi_table_header *table;
@@ -110,11 +110,11 @@ acpi_ns_one_complete_parse(u32 pass_number,
if (table->length < sizeof(struct acpi_table_header)) {
status = AE_BAD_HEADER;
} else {
- aml_start = (u8 *) table + sizeof(struct acpi_table_header);
+ aml_start = (u8 *)table + sizeof(struct acpi_table_header);
aml_length = table->length - sizeof(struct acpi_table_header);
status = acpi_ds_init_aml_walk(walk_state, parse_root, NULL,
aml_start, aml_length, NULL,
- (u8) pass_number);
+ (u8)pass_number);
}
/* Found OSDT table, enable the namespace override feature */
diff --git a/drivers/acpi/acpica/psloop.c b/drivers/acpi/acpica/psloop.c
index 9043722..6136458 100644
--- a/drivers/acpi/acpica/psloop.c
+++ b/drivers/acpi/acpica/psloop.c
@@ -126,9 +126,9 @@ acpi_ps_get_arguments(struct acpi_walk_state *walk_state,
while (GET_CURRENT_ARG_TYPE(walk_state->arg_types)
&& !walk_state->arg_count) {
walk_state->aml_offset =
- (u32) ACPI_PTR_DIFF(walk_state->parser_state.aml,
- walk_state->parser_state.
- aml_start);
+ (u32)ACPI_PTR_DIFF(walk_state->parser_state.aml,
+ walk_state->parser_state.
+ aml_start);
status =
acpi_ps_get_next_arg(walk_state,
@@ -499,7 +499,7 @@ acpi_status acpi_ps_parse_loop(struct acpi_walk_state
*walk_state)
if (walk_state->op_info) {
ACPI_DEBUG_PRINT((ACPI_DB_PARSE,
"Opcode %4.4X [%s] Op %p Aml
%p AmlOffset %5.5X\n",
- (u32) op->common.aml_opcode,
+ (u32)op->common.aml_opcode,
walk_state->op_info->name, op,
parser_state->aml,
op->common.aml_offset));
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mfd: 88pm800: Add support for clk subdevice
2015-07-21 20:07 GMT+09:00 Vaibhav Hiremath : > This patch adds mfd_cell/clk-subdevice for 88PM800 MFD > (and family of devices). > > Signed-off-by: Vaibhav Hiremath > --- > drivers/mfd/88pm800.c | 25 + > 1 file changed, 25 insertions(+) > Looks OK: Reviewed-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/
[PATCH 04/22] ACPICA: Dispatcher: Cleanup union acpi_operand_object's AML address assignments.
ACPICA commit afb52611dbe7403551f93504d3798534f5c343f4
This patch cleans up the code of assigning the AML address to the
union acpi_operand_object.
The idea behind this cleanup is:
The AML address of the union acpi_operand_object should always be determined at
the point where the object is encountered. It should be started from the
first byte of the object. For example, the opcode of the object, the name
string of the user_term object, or the first byte of the packaged object
(where a pkg_length is prefixed). So it's not cleaner to have it assigned
here and there in the entire ACPICA source tree.
There are some special cases for the internal opcodes, before cleaning up
the internal opcodes, we should also determine the rules for the AML
addresses of the internal opcodes:
1. INT_NAMEPATH_OP: the address of the first byte for the name_string.
2. INT_METHODCALL_OP: the address of the first byte for the name_string.
3. INT_BYTELIST_OP: the address of the first byte for the byte_data list.
4. INT_EVAL_SUBTREE_OP: the address of the first byte for the
Region/Package/Buffer/bank_field/Field arguments.
5. INT_NAMEDFIELD_OP: the address to the name_seg.
6. INT_RESERVEDFIELD_OP: the address to the 0x00 prefix.
7. INT_ACCESSFIELD_OP: the address to the 0x01 prefix.
8. INT_CONNECTION_OP: the address to the 0x02 prefix.
9: INT_EXTACCESSFIELD_OP: the address to the 0x03 prefix.
10.INT_RETURN_VALUE_OP: the address of the replaced operand.
11.computational_data: the address to the
Byte/Word/Dword/Qword/string_prefix.
Before cleaning up the internal root scope of the aml_walk, turning it into
the term_list, we need to remember the aml_start address as the "Aml"
attribute for the union acpi_operand_object created by
acpi_ps_create_scope_op().
Finally, we can delete some redundant AML address assignment in psloop.c.
Link: https://github.com/acpica/acpica/commit/afb52611
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acparser.h |4 ++--
drivers/acpi/acpica/dsargs.c |4 ++--
drivers/acpi/acpica/dsmethod.c |2 +-
drivers/acpi/acpica/dswload.c |2 +-
drivers/acpi/acpica/dswload2.c |2 +-
drivers/acpi/acpica/nsparse.c | 40 +++-
drivers/acpi/acpica/psargs.c | 21 -
drivers/acpi/acpica/psloop.c |3 ---
drivers/acpi/acpica/psobject.c |2 +-
drivers/acpi/acpica/psparse.c | 12
drivers/acpi/acpica/psutils.c |8 +---
drivers/acpi/acpica/psxface.c |2 +-
12 files changed, 53 insertions(+), 49 deletions(-)
diff --git a/drivers/acpi/acpica/acparser.h b/drivers/acpi/acpica/acparser.h
index 0cdd2fc..6021ccf 100644
--- a/drivers/acpi/acpica/acparser.h
+++ b/drivers/acpi/acpica/acparser.h
@@ -225,11 +225,11 @@ void acpi_ps_delete_parse_tree(union acpi_parse_object
*root);
/*
* psutils - parser utilities
*/
-union acpi_parse_object *acpi_ps_create_scope_op(void);
+union acpi_parse_object *acpi_ps_create_scope_op(u8 *aml);
void acpi_ps_init_op(union acpi_parse_object *op, u16 opcode);
-union acpi_parse_object *acpi_ps_alloc_op(u16 opcode);
+union acpi_parse_object *acpi_ps_alloc_op(u16 opcode, u8 *aml);
void acpi_ps_free_op(union acpi_parse_object *op);
diff --git a/drivers/acpi/acpica/dsargs.c b/drivers/acpi/acpica/dsargs.c
index 3e69897..e2ab59e 100644
--- a/drivers/acpi/acpica/dsargs.c
+++ b/drivers/acpi/acpica/dsargs.c
@@ -86,7 +86,7 @@ acpi_ds_execute_arguments(struct acpi_namespace_node *node,
/* Allocate a new parser op to be the root of the parsed tree */
- op = acpi_ps_alloc_op(AML_INT_EVAL_SUBTREE_OP);
+ op = acpi_ps_alloc_op(AML_INT_EVAL_SUBTREE_OP, aml_start);
if (!op) {
return_ACPI_STATUS(AE_NO_MEMORY);
}
@@ -129,7 +129,7 @@ acpi_ds_execute_arguments(struct acpi_namespace_node *node,
/* Evaluate the deferred arguments */
- op = acpi_ps_alloc_op(AML_INT_EVAL_SUBTREE_OP);
+ op = acpi_ps_alloc_op(AML_INT_EVAL_SUBTREE_OP, aml_start);
if (!op) {
return_ACPI_STATUS(AE_NO_MEMORY);
}
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index bf8c16e..4abc242 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -103,7 +103,7 @@ acpi_ds_auto_serialize_method(struct acpi_namespace_node
*node,
/* Create/Init a root op for the method parse tree */
- op = acpi_ps_alloc_op(AML_METHOD_OP);
+ op = acpi_ps_alloc_op(AML_METHOD_OP, obj_desc->method.aml_start);
if (!op) {
return_ACPI_STATUS(AE_NO_MEMORY);
}
diff --git a/drivers/acpi/acpica/dswload.c b/drivers/acpi/acpica/dswload.c
index 845ff44..097188a 100644
--- a/drivers/acpi/acpica/dswload.c
+++ b/drivers/acpi/acpica/dswload.c
@@ -388,7 +388,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state * walk_state,
/* Create a new op */
-
[PATCH 10/22] ACPICA: Executer: Add OSL trace hook support.
ACPICA commit e8e4a9b19d0b72a7b165398bdc961fc2f6f502ec
This patch adds OSL trace hook support.
OSPMs are encouraged to use acpi_os_trace_point() with
ACPI_USE_SYSTEM_TRACER defined to implement platform specific trace
facility. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/e8e4a9b1
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acinterp.h |4 ++
drivers/acpi/acpica/exdebug.c | 125
drivers/acpi/acpica/utdebug.c | 31 +-
include/acpi/acoutput.h|3 +
include/acpi/acpiosxf.h|6 ++
include/acpi/acpixf.h |5 ++
include/acpi/actypes.h |8 +++
7 files changed, 144 insertions(+), 38 deletions(-)
diff --git a/drivers/acpi/acpica/acinterp.h b/drivers/acpi/acpica/acinterp.h
index a3c6e2a..e820ed8 100644
--- a/drivers/acpi/acpica/acinterp.h
+++ b/drivers/acpi/acpica/acinterp.h
@@ -149,6 +149,10 @@ void
acpi_ex_stop_trace_opcode(union acpi_parse_object *op,
struct acpi_walk_state *walk_state);
+void
+acpi_ex_trace_point(acpi_trace_event_type type,
+ u8 begin, u8 *aml, char *pathname);
+
/*
* exfield - ACPI AML (p-code) execution - field manipulation
*/
diff --git a/drivers/acpi/acpica/exdebug.c b/drivers/acpi/acpica/exdebug.c
index 00ba9fc..708b2ae 100644
--- a/drivers/acpi/acpica/exdebug.c
+++ b/drivers/acpi/acpica/exdebug.c
@@ -52,6 +52,12 @@ ACPI_MODULE_NAME("exdebug")
static union acpi_operand_object *acpi_gbl_trace_method_object = NULL;
+/* Local prototypes */
+
+#ifdef ACPI_DEBUG_OUTPUT
+static const char *acpi_ex_get_trace_event_name(acpi_trace_event_type type);
+#endif
+
#ifndef ACPI_NO_ERROR_MESSAGES
/***
*
@@ -365,6 +371,78 @@ static u8 acpi_ex_interpreter_trace_enabled(char *name)
/***
*
+ * FUNCTION:acpi_ex_get_trace_event_name
+ *
+ * PARAMETERS: type- Trace event type
+ *
+ * RETURN: Trace event name.
+ *
+ * DESCRIPTION: Used to obtain the full trace event name.
+ *
+
**/
+
+#ifdef ACPI_DEBUG_OUTPUT
+
+static const char *acpi_ex_get_trace_event_name(acpi_trace_event_type type)
+{
+ switch (type) {
+ case ACPI_TRACE_AML_METHOD:
+
+ return "Method";
+
+ case ACPI_TRACE_AML_OPCODE:
+
+ return "Opcode";
+
+ case ACPI_TRACE_AML_REGION:
+
+ return "Region";
+
+ default:
+
+ return "";
+ }
+}
+
+#endif
+
+/***
+ *
+ * FUNCTION:acpi_ex_trace_point
+ *
+ * PARAMETERS: type- Trace event type
+ * begin - TRUE if before execution
+ * aml - Executed AML address
+ * pathname- Object path
+ *
+ * RETURN: None
+ *
+ * DESCRIPTION: Internal interpreter execution trace.
+ *
+
**/
+
+void
+acpi_ex_trace_point(acpi_trace_event_type type,
+ u8 begin, u8 *aml, char *pathname)
+{
+
+ ACPI_FUNCTION_NAME(ex_trace_point);
+
+ if (pathname) {
+ ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
+ "%s %s [0x%p:%s] execution.\n",
+ acpi_ex_get_trace_event_name(type),
+ begin ? "Begin" : "End", aml, pathname));
+ } else {
+ ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
+ "%s %s [0x%p] execution.\n",
+ acpi_ex_get_trace_event_name(type),
+ begin ? "Begin" : "End", aml));
+ }
+}
+
+/***
+ *
* FUNCTION:acpi_ex_start_trace_method
*
* PARAMETERS: method_node - Node of the method
@@ -417,16 +495,9 @@ acpi_ex_start_trace_method(struct acpi_namespace_node
*method_node,
exit:
if (enabled) {
- if (pathname) {
- ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
- "Begin method [0x%p:%s] execution.\n",
- obj_desc->method.aml_start,
- pathname));
- } else {
- ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
- "Begin method [0x%p] execution.\n",
- obj_desc->method.aml_start));
- }
+ ACPI_TRACE_POINT(ACPI_TRACE_AML_METHOD, TRUE,
+obj_desc ? obj_desc->method.aml_start : NULL,
+
[PATCH 07/22] ACPICA: Dispatcher: Move stack traversal code to dispatcher.
ACPICA commit c8275e243b58fd4adfc0362bd704af41ed14bc75
This patch moves parts of acpi_dm_dump_method_info() to the dispatcher
component.
This patch also makes the new function dependent on ACPI_DEBUG_OUTPUT
compile-stage definition so that it can be used by the trace facility.
acpi_dm_dump_method_info() traverses method stack when an exception is
encountered. Such traversal is needed to support method tracing for the
exceptions. When an exception is encountered, the end indications of the
aborted methods should be logged in order not to break the user space
analysis tool. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c8275e24
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/Makefile |1 +
drivers/acpi/acpica/acdispat.h |8 ++
drivers/acpi/acpica/dsdebug.c | 222
drivers/acpi/acpica/dsmethod.c |7 +-
4 files changed, 235 insertions(+), 3 deletions(-)
create mode 100644 drivers/acpi/acpica/dsdebug.c
diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index c1a9635..9f30ed7 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -11,6 +11,7 @@ obj-y += acpi.o
acpi-y := \
dsargs.o\
dscontrol.o \
+ dsdebug.o \
dsfield.o \
dsinit.o\
dsmethod.o \
diff --git a/drivers/acpi/acpica/acdispat.h b/drivers/acpi/acpica/acdispat.h
index 408f04b..7094dc8 100644
--- a/drivers/acpi/acpica/acdispat.h
+++ b/drivers/acpi/acpica/acdispat.h
@@ -354,4 +354,12 @@ acpi_status
acpi_ds_result_push(union acpi_operand_object *object,
struct acpi_walk_state *walk_state);
+/*
+ * dsdebug - parser debugging routines
+ */
+void
+acpi_ds_dump_method_stack(acpi_status status,
+ struct acpi_walk_state *walk_state,
+ union acpi_parse_object *op);
+
#endif /* _ACDISPAT_H_ */
diff --git a/drivers/acpi/acpica/dsdebug.c b/drivers/acpi/acpica/dsdebug.c
new file mode 100644
index 000..21c6cef
--- /dev/null
+++ b/drivers/acpi/acpica/dsdebug.c
@@ -0,0 +1,222 @@
+/**
+ *
+ * Module Name: dsdebug - Parser/Interpreter interface - debugging
+ *
+ */
+
+/*
+ * Copyright (C) 2000 - 2015, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ *substantially similar to the "NO WARRANTY" disclaimer below
+ *("Disclaimer") and any redistribution must be conditioned upon
+ *including a substantially similar Disclaimer requirement for further
+ *binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the names
+ *of any contributors may be used to endorse or promote products derived
+ *from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+ * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGES.
+ */
+
+#include
+#include "accommon.h"
+#include "acdispat.h"
+#include "acnamesp.h"
+#ifdef ACPI_DISASSEMBLER
+#include "acdisasm.h"
+#endif
+
+#define _COMPONENT ACPI_DISPATCHER
+ACPI_MODULE_NAME("dsdebug")
+
+#if defined(ACPI_DEBUG_OUTPUT) || defined(ACPI_DEBUGGER)
+/* Local prototypes */
+static void
+acpi_ds_print_node_pathname(struct acpi_namespace_node *node,
+ const char *message);
+
+/***
+ *
+ * FUNCTION:acpi_ds_print_node_pathname
+ *
+ * PARAMETERS: node- Object
+ * message - Prefix message
+
[PATCH 14/22] ACPICA: iASL: Add new warnings for method local_x and arg_x variables.
From: Bob Moore
ACPICA commit eb9f8cb9fd65f1149dd335d05944c31cbca41af3
1) Warn if a Local is set but never used
2) Warn if a arg_x is never used (for non-predefined method names)
3) Warn if a arg_x that is used as a local is never used
This patch only affects iASL which is not in the kernel source tree.
Link: https://github.com/acpica/acpica/commit/eb9f8cb9
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/aclocal.h |4
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 610d001..4758185 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -174,8 +174,12 @@ struct acpi_namespace_node {
*/
#ifdef ACPI_LARGE_NAMESPACE_NODE
union acpi_parse_object *op;
+ void *method_locals;
+ void *method_args;
u32 value;
u32 length;
+ u8 arg_count;
+
#endif
};
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/22] ACPICA: Remove extraneous check for null walk_state.
From: Markus Elfring
ACPICA commit f9fd6e8bad0f16ce2b436c5cda36ced0c2d85302
Reported by Markus Elfring.
Link: https://github.com/acpica/acpica/commit/f9fd6e8b
Signed-off-by: Markus Elfring
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dsmethod.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index ea2bdde..cb53c44 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -582,9 +582,7 @@ cleanup:
/* On error, we must terminate the method properly */
acpi_ds_terminate_control_method(obj_desc, next_walk_state);
- if (next_walk_state) {
- acpi_ds_delete_walk_state(next_walk_state);
- }
+ acpi_ds_delete_walk_state(next_walk_state);
return_ACPI_STATUS(status);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 20/22] ACPICA: Debugger: Move debugger specific APIs to debugger component.
ACPICA commit 2164923d60429eea7cd5a4a8629b607af7325afa
Some disassembler APIs should rather be debugger APIs. This patch moves
them to the debugger folder to be ready for debugger porting.
Since there is no in-kernel ACPICA debugger in the kernel source tree, this
patch doesn't affect the Linux kernel.
Link: https://github.com/acpica/acpica/commit/2164923d
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acdebug.h | 17 +
drivers/acpi/acpica/dsmethod.c | 12 +---
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index 88482f7..b5a9c51 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -264,6 +264,23 @@ char *acpi_db_get_next_token(char *string,
char **next, acpi_object_type * return_type);
/*
+ * dbobject
+ */
+void acpi_db_decode_internal_object(union acpi_operand_object *obj_desc);
+
+void
+acpi_db_display_internal_object(union acpi_operand_object *obj_desc,
+ struct acpi_walk_state *walk_state);
+
+void acpi_db_decode_arguments(struct acpi_walk_state *walk_state);
+
+void acpi_db_decode_locals(struct acpi_walk_state *walk_state);
+
+void
+acpi_db_dump_method_info(acpi_status status,
+struct acpi_walk_state *walk_state);
+
+/*
* dbstats - Generation and display of ACPI table statistics
*/
void acpi_db_generate_statistics(union acpi_parse_object *root, u8 is_method);
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index cb53c44..bc32f31 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -46,11 +46,9 @@
#include "acdispat.h"
#include "acinterp.h"
#include "acnamesp.h"
-#ifdef ACPI_DISASSEMBLER
-#include "acdisasm.h"
-#endif
#include "acparser.h"
#include "amlcode.h"
+#include "acdebug.h"
#define _COMPONENT ACPI_DISPATCHER
ACPI_MODULE_NAME("dsmethod")
@@ -205,7 +203,7 @@ acpi_ds_detect_named_opcodes(struct acpi_walk_state
*walk_state,
* RETURN: Status
*
* DESCRIPTION: Called on method error. Invoke the global exception handler if
- * present, dump the method data if the disassembler is configured
+ * present, dump the method data if the debugger is configured
*
* Note: Allows the exception handler to change the status code
*
@@ -254,10 +252,10 @@ acpi_ds_method_error(acpi_status status, struct
acpi_walk_state * walk_state)
if (ACPI_FAILURE(status)) {
acpi_ds_dump_method_stack(status, walk_state, walk_state->op);
- /* Display method locals/args if disassembler is present */
+ /* Display method locals/args if debugger is present */
-#ifdef ACPI_DISASSEMBLER
- acpi_dm_dump_method_info(status, walk_state);
+#ifdef ACPI_DEBUGGER
+ acpi_db_dump_method_info(status, walk_state);
#endif
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/22] ACPICA: Executer: Add option to bypass opcode tracing.
ACPICA commit 61e9e20aadfaa03184d0959fbdc1fa5cdfea2551
This patch adds option to bypass opcode tracing. The option can be used to
reduce the trace message output. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/61e9e20a
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/exdebug.c |6 --
include/acpi/acoutput.h |5 +++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/exdebug.c b/drivers/acpi/acpica/exdebug.c
index 708b2ae..de92458 100644
--- a/drivers/acpi/acpica/exdebug.c
+++ b/drivers/acpi/acpica/exdebug.c
@@ -598,7 +598,8 @@ acpi_ex_start_trace_opcode(union acpi_parse_object *op,
ACPI_FUNCTION_NAME(ex_start_trace_opcode);
- if (acpi_ex_interpreter_trace_enabled(NULL)) {
+ if (acpi_ex_interpreter_trace_enabled(NULL) &&
+ (acpi_gbl_trace_flags & ACPI_TRACE_OPCODE)) {
ACPI_TRACE_POINT(ACPI_TRACE_AML_OPCODE, TRUE,
op->common.aml, op->common.aml_op_name);
}
@@ -625,7 +626,8 @@ acpi_ex_stop_trace_opcode(union acpi_parse_object *op,
ACPI_FUNCTION_NAME(ex_stop_trace_opcode);
- if (acpi_ex_interpreter_trace_enabled(NULL)) {
+ if (acpi_ex_interpreter_trace_enabled(NULL) &&
+ (acpi_gbl_trace_flags & ACPI_TRACE_OPCODE)) {
ACPI_TRACE_POINT(ACPI_TRACE_AML_OPCODE, FALSE,
op->common.aml, op->common.aml_op_name);
}
diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h
index c3f0ac1..908d4f9 100644
--- a/include/acpi/acoutput.h
+++ b/include/acpi/acoutput.h
@@ -187,8 +187,9 @@
/*
* Global trace flags
*/
-#define ACPI_TRACE_ENABLED ((u32) 2)
-#define ACPI_TRACE_ONESHOT ((u32) 1)
+#define ACPI_TRACE_ENABLED ((u32) 4)
+#define ACPI_TRACE_ONESHOT ((u32) 2)
+#define ACPI_TRACE_OPCODE ((u32) 1)
/* Defaults for trace debugging level/layer */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/22] ACPICA: Debugger: Reduce structure size for debugger.
ACPICA commit 310e0ae1c4730f4dadc80125125099ab76851499
arg_types in struct acpi_db_method_info is only referenced by ACPI_DEBUGGER.
This patch only affects ACPICA debugger which is only used by a non-kernel
tool - acpiexec, so Linux kernel is currently not affected by this patch.
Link: https://github.com/acpica/acpica/commit/310e0ae1
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/aclocal.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 4758185..a6b6887 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -1107,6 +1107,9 @@ struct acpi_db_method_info {
* Index of current thread inside all them created.
*/
char init_args;
+#ifdef ACPI_DEBUGGER
+ acpi_object_type arg_types[4];
+#endif
char *arguments[4];
char num_threads_str[11];
char id_of_thread_str[11];
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 22/22] ACPICA: Update version to 20150717.
From: Bob Moore ACPICA commit 8580ce04c1b7aa415c364b06e79edb8aca77dded Version 20150717. Link: https://github.com/acpica/acpica/commit/8580ce04 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index 9aa27a3..f2e2327 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20150619 +#define ACPI_CA_VERSION 0x20150717 #include #include -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/22] ACPICA: Cleanup use of NEGATIVE and POSITIVE defines.
From: Bob Moore ACPICA commit f88814201e01043a4f8caa69a69b799af11c44a3 These were defined in two places. Changed to ACPI_SIGN* names and define them once in acmacros.h This patch doesn't affect Linux kernel. Link: https://github.com/acpica/acpica/commit/f8881420 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acmacros.h |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h index 19d40c6..e85366c 100644 --- a/drivers/acpi/acpica/acmacros.h +++ b/drivers/acpi/acpica/acmacros.h @@ -224,6 +224,11 @@ #define ACPI_IS_ASCII(c)((c) < 0x80) +/* Signed integers */ + +#define ACPI_SIGN_POSITIVE 0 +#define ACPI_SIGN_NEGATIVE 1 + /* * Rounding macros (Power of two boundaries only) */ -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/22] ACPICA: iASL: Add support for TCPA Server Table.
From: Bob Moore
ACPICA commit 55fa9555c71eaa99daebed4cd82cfde3875e8c45
In addition to the existing support for the client table.
Link: https://github.com/acpica/acpica/commit/55fa9555
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
include/acpi/actbl2.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index a948fc5..6e28f54 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -1186,20 +1186,29 @@ enum acpi_spmi_interface_types {
* December 19, 2014
*
* NOTE: There are two versions of the table with the same signature --
- * the client version and the server version.
+ * the client version and the server version. The common platform_class
+ * field is used to differentiate the two types of tables.
*
**/
-struct acpi_table_tcpa_client {
+struct acpi_table_tcpa_hdr {
struct acpi_table_header header;/* Common ACPI table header */
u16 platform_class;
+};
+
+/*
+ * Values for platform_class above.
+ * This is how the client and server subtables are differentiated
+ */
+#define ACPI_TCPA_CLIENT_TABLE 0
+#define ACPI_TCPA_SERVER_TABLE 1
+
+struct acpi_table_tcpa_client {
u32 minimum_log_length; /* Minimum length for the event log area */
u64 log_address;/* Address of the event log area */
};
struct acpi_table_tcpa_server {
- struct acpi_table_header header;/* Common ACPI table header */
- u16 platform_class;
u16 reserved;
u64 minimum_log_length; /* Minimum length for the event log area */
u64 log_address;/* Address of the event log area */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 21/22] ACPICA: iASL/Disassembler: Add prototype verbose mode.
From: Bob Moore ACPICA commit add72dca18ab5d02f1bf9b08027570e58da520e8 This mode will emit AML byte code after each ASL statement. This is a prototype only and requires additional development. This patch only affects ACPICA disassembler which is not in the kernel source tree. Link: https://github.com/acpica/acpica/commit/add72dca Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acglobal.h |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 5342300..79eb35d 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -307,6 +307,7 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_no_resource_disassembly, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); +ACPI_INIT_GLOBAL(union acpi_parse_object *, acpi_gbl_previous_op, NULL); ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/22] ACPICA: Executer: Add interpreter tracing mode for method tracing facility.
ACPICA commit 07fffd02607685b655ed92ee15c160e6a810b60b
The acpi_debug_trace() is the mechanism known as ACPI method tracing that is
used by Linux as ACPICA debugging message reducer. This facility can be
controlled through Linux ACPI subsystem - /sys/module/acpi/parameters.
This facility requires CONFIG_ACPI_DEBUG to be enabled to see ACPICA trace
logs in the kernel dmesg output.
This patch enhances acpi_debug_trace() to make it not only a message reducer,
but a real tracer to trace AML interpreter execution. Note that in addition
to the AML tracer enabling, this patch also updates the facility with the
following enhancements:
1. Allow a full path to be specified by the acpi_debug_trace() API.
2. Allow any method rather than just the entrance of acpi_evaluate_object()
to be traced.
3. All interpreter ACPI_LV_TRACE_POINT messages are collected for
ACPI_EXECUTER layer.
The Makefile of drivers/acpi/acpica is also updated to include exdebug.o
and the duplicated stubs are removed after that.
Note that since this patch has enhanced the method tracing facility, Linux
need also be updated after applying this patch. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/07fffd02
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acdebug.h |2 +
drivers/acpi/acpica/acglobal.h |2 -
drivers/acpi/acpica/acinterp.h | 18 +++
drivers/acpi/acpica/dsdebug.c | 25 +---
drivers/acpi/acpica/dsmethod.c | 32 +
drivers/acpi/acpica/exdebug.c | 271
drivers/acpi/acpica/psloop.c | 16 +--
drivers/acpi/acpica/psparse.c |4 +-
drivers/acpi/acpica/psxface.c | 121 ++
drivers/acpi/acpica/utinit.c |2 -
include/acpi/acoutput.h| 13 ++
include/acpi/acpixf.h |6 +-
12 files changed, 327 insertions(+), 185 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index 43685dd..88482f7 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -102,6 +102,8 @@ void acpi_db_display_interfaces(char *action_arg, char
*interface_name_arg);
acpi_status acpi_db_sleep(char *object_arg);
+void acpi_db_trace(char *enable_arg, char *method_arg, char *once_arg);
+
void acpi_db_display_locks(void);
void acpi_db_display_resources(char *object_arg);
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 53f96a3..5342300 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -290,8 +290,6 @@ ACPI_GLOBAL(u32,
acpi_fixed_event_count[ACPI_NUM_FIXED_EVENTS]);
ACPI_GLOBAL(u32, acpi_gbl_original_dbg_level);
ACPI_GLOBAL(u32, acpi_gbl_original_dbg_layer);
-ACPI_GLOBAL(u32, acpi_gbl_trace_dbg_level);
-ACPI_GLOBAL(u32, acpi_gbl_trace_dbg_layer);
/*
*
diff --git a/drivers/acpi/acpica/acinterp.h b/drivers/acpi/acpica/acinterp.h
index 7ac9800..a3c6e2a 100644
--- a/drivers/acpi/acpica/acinterp.h
+++ b/drivers/acpi/acpica/acinterp.h
@@ -131,6 +131,24 @@ void
acpi_ex_do_debug_object(union acpi_operand_object *source_desc,
u32 level, u32 index);
+void
+acpi_ex_start_trace_method(struct acpi_namespace_node *method_node,
+ union acpi_operand_object *obj_desc,
+ struct acpi_walk_state *walk_state);
+
+void
+acpi_ex_stop_trace_method(struct acpi_namespace_node *method_node,
+ union acpi_operand_object *obj_desc,
+ struct acpi_walk_state *walk_state);
+
+void
+acpi_ex_start_trace_opcode(union acpi_parse_object *op,
+ struct acpi_walk_state *walk_state);
+
+void
+acpi_ex_stop_trace_opcode(union acpi_parse_object *op,
+ struct acpi_walk_state *walk_state);
+
/*
* exfield - ACPI AML (p-code) execution - field manipulation
*/
diff --git a/drivers/acpi/acpica/dsdebug.c b/drivers/acpi/acpica/dsdebug.c
index 7df9b50e..a651d30 100644
--- a/drivers/acpi/acpica/dsdebug.c
+++ b/drivers/acpi/acpica/dsdebug.c
@@ -48,6 +48,7 @@
#ifdef ACPI_DISASSEMBLER
#include "acdisasm.h"
#endif
+#include "acinterp.h"
#define _COMPONENT ACPI_DISPATCHER
ACPI_MODULE_NAME("dsdebug")
@@ -128,7 +129,6 @@ acpi_ds_dump_method_stack(acpi_status status,
struct acpi_walk_state *next_walk_state;
struct acpi_namespace_node *previous_method = NULL;
union acpi_operand_object *method_desc;
- char *pathname = NULL;
ACPI_FUNCTION_TRACE(ds_dump_method_stack);
@@ -173,25 +173,10 @@ acpi_ds_dump_method_stack(acpi_status status,
while (next_walk_state) {
method_desc = next_walk_state->method_desc;
- if (method_desc && method_desc->method.node) {
- pathname = acpi_ns_get_normalized_pathname((struct
-
acpi_nam
[PATCH 15/22] ACPICA: MSVC: Fix inclusion order issue of .
ACPICA commit 49c6a6517a906900e9baa51ad5859beeb8a3089f
The following error logs can be seen for calloc/free/malloc/realloc that
defined in the stdlib.h:
...\stdlib.h(281) : error C2059: syntax error : ','
...\stdlib.h(281) : error C2143: syntax error : missing ')' before 'constant'
...\stdlib.h(281) : error C2143: syntax error : missing '{' before 'constant'
...\stdlib.h(281) : error C2059: syntax error : ''
...\stdlib.h(281) : error C2059: syntax error : ')'
This is caused by the wrong inclusion order of stdlib.h/crtdbg.h introduced
in acenv.h. This patch fixes this breakage. Lv Zheng.
This patch doesn't affect Linux kernel.
Link: https://github.com/acpica/acpica/commit/49c6a651
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
include/acpi/platform/acenvex.h |3 +++
include/acpi/platform/acmsvcex.h | 54 ++
include/acpi/platform/acwinex.h | 49 ++
3 files changed, 106 insertions(+)
create mode 100644 include/acpi/platform/acmsvcex.h
create mode 100644 include/acpi/platform/acwinex.h
diff --git a/include/acpi/platform/acenvex.h b/include/acpi/platform/acenvex.h
index 0a7dc8e..2f296cb 100644
--- a/include/acpi/platform/acenvex.h
+++ b/include/acpi/platform/acenvex.h
@@ -56,6 +56,9 @@
#if defined(_LINUX) || defined(__linux__)
#include
+#elif defined(WIN32)
+#include "acwinex.h"
+
#elif defined(_AED_EFI)
#include "acefiex.h"
diff --git a/include/acpi/platform/acmsvcex.h b/include/acpi/platform/acmsvcex.h
new file mode 100644
index 000..b647974
--- /dev/null
+++ b/include/acpi/platform/acmsvcex.h
@@ -0,0 +1,54 @@
+/**
+ *
+ * Name: acmsvcex.h - Extra VC specific defines, etc.
+ *
+ */
+
+/*
+ * Copyright (C) 2000 - 2015, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ *substantially similar to the "NO WARRANTY" disclaimer below
+ *("Disclaimer") and any redistribution must be conditioned upon
+ *including a substantially similar Disclaimer requirement for further
+ *binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the names
+ *of any contributors may be used to endorse or promote products derived
+ *from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+ * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGES.
+ */
+
+#ifndef __ACMSVCEX_H__
+#define __ACMSVCEX_H__
+
+/* Debug support. */
+
+#ifdef _DEBUG
+#define _CRTDBG_MAP_ALLOC /* Enables specific file/lineno for leaks */
+#include
+#endif
+
+#endif /* __ACMSVCEX_H__ */
diff --git a/include/acpi/platform/acwinex.h b/include/acpi/platform/acwinex.h
new file mode 100644
index 000..6ed1d71
--- /dev/null
+++ b/include/acpi/platform/acwinex.h
@@ -0,0 +1,49 @@
+/**
+ *
+ * Name: acwinex.h - Extra OS specific defines, etc.
+ *
+ */
+
+/*
+ * Copyright (C) 2000 - 2015, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ *substantially similar to the "NO WARRANTY" disclaimer below
+ *("Disc
[PATCH 16/22] ACPICA: Cleanup use of all non-ANSI local C library functions.
From: Bob Moore
ACPICA commit 7c490c28a18b435c543c6b410e7e7c2131fccc78
ACPICA implements all non-ANSI functions locally. However, there
are sometimes two or more versions of the same function throughout
the ACPICA code. This change fixes this.
Adds a new file, utilities/utnonansi.c
Link: https://github.com/acpica/acpica/commit/7c490c28
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/Makefile|1 +
drivers/acpi/acpica/acmacros.h |4 +
drivers/acpi/acpica/acutils.h | 23 ++-
drivers/acpi/acpica/utnonansi.c | 380 +++
drivers/acpi/acpica/utstring.c | 342 ---
5 files changed, 396 insertions(+), 354 deletions(-)
create mode 100644 drivers/acpi/acpica/utnonansi.c
diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index 9f30ed7..fedcc16 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -165,6 +165,7 @@ acpi-y += \
utmath.o\
utmisc.o\
utmutex.o \
+ utnonansi.o \
utobject.o \
utosi.o \
utownerid.o \
diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h
index c240bdf..19d40c6 100644
--- a/drivers/acpi/acpica/acmacros.h
+++ b/drivers/acpi/acpica/acmacros.h
@@ -220,6 +220,10 @@
#define ACPI_MUL_32(a) _ACPI_MUL(a, 5)
#define ACPI_MOD_32(a) _ACPI_MOD(a, 32)
+/* Test for ASCII character */
+
+#define ACPI_IS_ASCII(c)((c) < 0x80)
+
/*
* Rounding macros (Power of two boundaries only)
*/
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 6de0d35..566ff4df 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -167,6 +167,17 @@ struct acpi_pkg_info {
#define DB_QWORD_DISPLAY8
/*
+ * utnonansi - Non-ANSI C library functions
+ */
+void acpi_ut_strupr(char *src_string);
+
+void acpi_ut_strlwr(char *src_string);
+
+int acpi_ut_stricmp(char *string1, char *string2);
+
+acpi_status acpi_ut_strtoul64(char *string, u32 base, u64 *ret_integer);
+
+/*
* utglobal - Global data structures and procedures
*/
acpi_status acpi_ut_init_globals(void);
@@ -205,8 +216,6 @@ acpi_status acpi_ut_hardware_initialize(void);
void acpi_ut_subsystem_shutdown(void);
-#define ACPI_IS_ASCII(c) ((c) < 0x80)
-
/*
* utcopy - Object construction and conversion interfaces
*/
@@ -567,16 +576,6 @@ acpi_ut_get_resource_end_tag(union acpi_operand_object
*obj_desc, u8 **end_tag);
/*
* utstring - String and character utilities
*/
-void acpi_ut_strupr(char *src_string);
-
-#ifdef ACPI_ASL_COMPILER
-void acpi_ut_strlwr(char *src_string);
-
-int acpi_ut_stricmp(char *string1, char *string2);
-#endif
-
-acpi_status acpi_ut_strtoul64(char *string, u32 base, u64 *ret_integer);
-
void acpi_ut_print_string(char *string, u16 max_length);
#if defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP
diff --git a/drivers/acpi/acpica/utnonansi.c b/drivers/acpi/acpica/utnonansi.c
new file mode 100644
index 000..1d5f6b1
--- /dev/null
+++ b/drivers/acpi/acpica/utnonansi.c
@@ -0,0 +1,380 @@
+/***
+ *
+ * Module Name: utnonansi - Non-ansi C library functions
+ *
+
**/
+
+/*
+ * Copyright (C) 2000 - 2015, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ *substantially similar to the "NO WARRANTY" disclaimer below
+ *("Disclaimer") and any redistribution must be conditioned upon
+ *including a substantially similar Disclaimer requirement for further
+ *binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the names
+ *of any contributors may be used to endorse or promote products derived
+ *from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED
[PATCH 08/22] ACPICA: Dispatcher: Add trace support for interpreter.
ACPICA commit 71299ec8b49054daace0df50268e8e055654ca37
This patch adds trace point at the following point:
1. Begin/end of a control method execution;
2. Begin/end of an opcode execution.
The trace point feature can be enabled by defining ACPI_DEBUG_OUTPUT
and specifying a debug level that includes ACPI_LV_TRACDE_POINT and the
debug layers that include ACPI_PARSER and ACPI_DISPACTCHER.
In order to make aml_op_name of union acpi_parse_object usable for tracer, it is
enabled for ACPI_DEBUG_OUTPUT in this patch. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/71299ec8
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/aclocal.h |2 +-
drivers/acpi/acpica/dsdebug.c | 24
drivers/acpi/acpica/dsmethod.c | 31 +++
drivers/acpi/acpica/psloop.c | 15 +++
drivers/acpi/acpica/psparse.c |4
include/acpi/acoutput.h|4 +++-
6 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 607e628..610d001 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -715,7 +715,7 @@ union acpi_parse_value {
union acpi_parse_object *arg; /* arguments and contained ops */
};
-#ifdef ACPI_DISASSEMBLER
+#if defined(ACPI_DISASSEMBLER) || defined(ACPI_DEBUG_OUTPUT)
#define ACPI_DISASM_ONLY_MEMBERS(a) a;
#else
#define ACPI_DISASM_ONLY_MEMBERS(a)
diff --git a/drivers/acpi/acpica/dsdebug.c b/drivers/acpi/acpica/dsdebug.c
index 21c6cef..7df9b50e 100644
--- a/drivers/acpi/acpica/dsdebug.c
+++ b/drivers/acpi/acpica/dsdebug.c
@@ -127,6 +127,8 @@ acpi_ds_dump_method_stack(acpi_status status,
struct acpi_thread_state *thread;
struct acpi_walk_state *next_walk_state;
struct acpi_namespace_node *previous_method = NULL;
+ union acpi_operand_object *method_desc;
+ char *pathname = NULL;
ACPI_FUNCTION_TRACE(ds_dump_method_stack);
@@ -170,6 +172,28 @@ acpi_ds_dump_method_stack(acpi_status status,
/* Walk list of linked walk states */
while (next_walk_state) {
+ method_desc = next_walk_state->method_desc;
+ if (method_desc && method_desc->method.node) {
+ pathname = acpi_ns_get_normalized_pathname((struct
+
acpi_namespace_node
+ *)
+ method_desc->
+ method.node,
+ TRUE);
+ }
+ if (pathname) {
+ ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
+ "End method [0x%p:%s] execution.\n",
+ method_desc->method.aml_start,
+ pathname));
+ ACPI_FREE(pathname);
+ pathname = NULL;
+ } else {
+ ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
+ "End method [0x%p] execution.\n",
+ method_desc->method.aml_start));
+ }
+
ACPI_DEBUG_PRINT((ACPI_DB_DISPATCH,
"Method [%4.4s] executing: ",
acpi_ut_get_node_name(next_walk_state->
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index e0ae8f4..0fa6f19 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -327,6 +327,7 @@ acpi_ds_begin_method_execution(struct acpi_namespace_node
*method_node,
struct acpi_walk_state *walk_state)
{
acpi_status status = AE_OK;
+ char *pathname = NULL;
ACPI_FUNCTION_TRACE_PTR(ds_begin_method_execution, method_node);
@@ -334,6 +335,18 @@ acpi_ds_begin_method_execution(struct acpi_namespace_node
*method_node,
return_ACPI_STATUS(AE_NULL_ENTRY);
}
+ pathname = acpi_ns_get_normalized_pathname(method_node, TRUE);
+ if (pathname) {
+ ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
+ "Begin method [0x%p:%s] execution.\n",
+ obj_desc->method.aml_start, pathname));
+ ACPI_FREE(pathname);
+ } else {
+ ACPI_DEBUG_PRINT((ACPI_DB_TRACE_POINT,
+ "Begin method [0x%p] execution.\n",
+ obj_desc->method.aml_start));
+ }
+
/* Prevent wraparound of thread count */
if (obj_desc->method.thread_count == ACPI_UINT8_MAX) {
@@ -695,6 +708,7 @@ void
acpi_ds_terminate_control_method(union acpi_
[PATCH 12/22] ACPICA: Parser: Remove redundant opcode execution debugging output.
ACPICA commit c832b0a9263c560b3ae3ae31d7298ef33988f8d5
This patch removes one redundant debugging output of opcode execution which
has already been covered by acpi_ex_start_trace_opcode(). Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c832b0a9
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/psloop.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/acpi/acpica/psloop.c b/drivers/acpi/acpica/psloop.c
index a7de52e..6b11fd7 100644
--- a/drivers/acpi/acpica/psloop.c
+++ b/drivers/acpi/acpica/psloop.c
@@ -491,14 +491,6 @@ acpi_status acpi_ps_parse_loop(struct acpi_walk_state
*walk_state)
continue;
}
- if (walk_state->op_info) {
- ACPI_DEBUG_PRINT((ACPI_DB_PARSE,
- "Opcode %4.4X [%s] Op %p Aml
%p\n",
- (u32)op->common.aml_opcode,
- walk_state->op_info->name, op,
- op->common.aml));
- }
-
acpi_ex_start_trace_opcode(op, walk_state);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/22] ACPICA: Namespace: Add function to directly return normalized full path.
ACPICA commit 6e0229bb156d71675f2e07dc7960adb7ec0a60ea
This patch adds functions to return normalized full path instead of
"external path". The external path contains trailing "_" for each
name segment while the normalized full path doesn't contain the
trailing "_".
Currently this function is used by the method tracing users to specify a
none trailing "_" attached name path. Lv Zheng.
Note that we need to validate and switch all Linux kernel acpi_get_name()
users to use the new name type before removing the old name type from
ACPICA.
Link: https://github.com/acpica/acpica/commit/6e0229bb
Signed-off-by: Lv Zheng
Reviewed-by: Ruiyi Zhang
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acnamesp.h | 13 +-
drivers/acpi/acpica/exdump.c |5 +-
drivers/acpi/acpica/nsnames.c | 275 +++-
drivers/acpi/acpica/nsutils.c |2 +-
drivers/acpi/acpica/nsxfname.c |8 +-
drivers/acpi/acpica/rscreate.c |3 +-
drivers/acpi/acpica/utmisc.c |2 +-
include/acpi/actypes.h |3 +-
8 files changed, 178 insertions(+), 133 deletions(-)
diff --git a/drivers/acpi/acpica/acnamesp.h b/drivers/acpi/acpica/acnamesp.h
index 0dd0882..ea0d907 100644
--- a/drivers/acpi/acpica/acnamesp.h
+++ b/drivers/acpi/acpica/acnamesp.h
@@ -272,17 +272,20 @@ acpi_ns_check_package(struct acpi_evaluate_info *info,
*/
u32 acpi_ns_opens_scope(acpi_object_type type);
-acpi_status
-acpi_ns_build_external_path(struct acpi_namespace_node *node,
- acpi_size size, char *name_buffer);
-
char *acpi_ns_get_external_pathname(struct acpi_namespace_node *node);
+u32
+acpi_ns_build_normalized_path(struct acpi_namespace_node *node,
+ char *full_path, u32 path_size, u8 no_trailing);
+
+char *acpi_ns_get_normalized_pathname(struct acpi_namespace_node *node,
+ u8 no_trailing);
+
char *acpi_ns_name_of_current_scope(struct acpi_walk_state *walk_state);
acpi_status
acpi_ns_handle_to_pathname(acpi_handle target_handle,
- struct acpi_buffer *buffer);
+ struct acpi_buffer *buffer, u8 no_trailing);
u8
acpi_ns_pattern_match(struct acpi_namespace_node *obj_node, char *search_for);
diff --git a/drivers/acpi/acpica/exdump.c b/drivers/acpi/acpica/exdump.c
index 401e7ed..b6495fb 100644
--- a/drivers/acpi/acpica/exdump.c
+++ b/drivers/acpi/acpica/exdump.c
@@ -995,9 +995,8 @@ static void acpi_ex_dump_reference_obj(union
acpi_operand_object *obj_desc)
if (obj_desc->reference.class == ACPI_REFCLASS_NAME) {
acpi_os_printf(" %p ", obj_desc->reference.node);
- status =
- acpi_ns_handle_to_pathname(obj_desc->reference.node,
- &ret_buf);
+ status = acpi_ns_handle_to_pathname(obj_desc->reference.node,
+ &ret_buf, FALSE);
if (ACPI_FAILURE(status)) {
acpi_os_printf(" Could not convert name to pathname\n");
} else {
diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c
index 2e37888..8934b4e 100644
--- a/drivers/acpi/acpica/nsnames.c
+++ b/drivers/acpi/acpica/nsnames.c
@@ -51,73 +51,6 @@ ACPI_MODULE_NAME("nsnames")
/***
*
- * FUNCTION:acpi_ns_build_external_path
- *
- * PARAMETERS: node- NS node whose pathname is needed
- * size- Size of the pathname
- * *name_buffer- Where to return the pathname
- *
- * RETURN: Status
- * Places the pathname into the name_buffer, in external format
- * (name segments separated by path separators)
- *
- * DESCRIPTION: Generate a full pathaname
- *
-
**/
-acpi_status
-acpi_ns_build_external_path(struct acpi_namespace_node *node,
- acpi_size size, char *name_buffer)
-{
- acpi_size index;
- struct acpi_namespace_node *parent_node;
-
- ACPI_FUNCTION_ENTRY();
-
- /* Special case for root */
-
- index = size - 1;
- if (index < ACPI_NAME_SIZE) {
- name_buffer[0] = AML_ROOT_PREFIX;
- name_buffer[1] = 0;
- return (AE_OK);
- }
-
- /* Store terminator byte, then build name backwards */
-
- parent_node = node;
- name_buffer[index] = 0;
-
- while ((index > ACPI_NAME_SIZE) && (parent_node != acpi_gbl_root_node))
{
- index -= ACPI_NAME_SIZE;
-
- /* Put the name into the buffer */
-
- ACPI_MOVE_32_TO_32((name_buffer + index), &parent_node->name);
- parent_node = parent_node->parent;
-
- /* Prefix name with the path separator */
-
- index--;
-
[PATCH 05/22] ACPICA: Executer: Add back pointing reference of method operand.
ACPICA commit 9dcd124e914e87495fbd1786d9484b962e0823e0
This patch adds back pointing reference of the namespace node for a method
operand. The namespace node then can be used in
acpi_ds_terminate_control_method() to obtain method full path to be used by
tracing facilities. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/9dcd124e
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acobject.h |1 +
drivers/acpi/acpica/excreate.c |1 +
drivers/acpi/acpica/utdelete.c |3 +++
3 files changed, 5 insertions(+)
diff --git a/drivers/acpi/acpica/acobject.h b/drivers/acpi/acpica/acobject.h
index c81d98d..0bd02c4 100644
--- a/drivers/acpi/acpica/acobject.h
+++ b/drivers/acpi/acpica/acobject.h
@@ -176,6 +176,7 @@ struct acpi_object_method {
u8 param_count;
u8 sync_level;
union acpi_operand_object *mutex;
+ union acpi_operand_object *node;
u8 *aml_start;
union {
acpi_internal_method implementation;
diff --git a/drivers/acpi/acpica/excreate.c b/drivers/acpi/acpica/excreate.c
index aaeea48..ccb7219 100644
--- a/drivers/acpi/acpica/excreate.c
+++ b/drivers/acpi/acpica/excreate.c
@@ -486,6 +486,7 @@ acpi_ex_create_method(u8 * aml_start,
obj_desc->method.aml_start = aml_start;
obj_desc->method.aml_length = aml_length;
+ obj_desc->method.node = operand[0];
/*
* Disassemble the method flags. Split off the arg_count, Serialized
diff --git a/drivers/acpi/acpica/utdelete.c b/drivers/acpi/acpica/utdelete.c
index 71fce38..1638312 100644
--- a/drivers/acpi/acpica/utdelete.c
+++ b/drivers/acpi/acpica/utdelete.c
@@ -209,6 +209,9 @@ static void acpi_ut_delete_internal_obj(union
acpi_operand_object *object)
acpi_ut_delete_object_desc(object->method.mutex);
object->method.mutex = NULL;
}
+ if (object->method.node) {
+ object->method.node = NULL;
+ }
break;
case ACPI_TYPE_REGION:
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/22] ACPICA: Parser: Cleanup aml_offset in struct acpi_walk_state.
ACPICA commit d254405814495058276c0c2f9d96794d15a6c91c
This patch converts aml_offset in struct acpi_walk_state to AML address.
AML offset is actually only used by the debugger, using AML address is more
direct and efficient during the parsing stage so that we don't need to
calculate it during the parsing stage.
On the other hand, we can see several issues in the current parser logic
around the aml_offset:
1. union acpi_operand_object.Common.aml_offset is redundantly assigned in
acpi_ps_parse_loop().
2. aml_offset is not an indication of the offset from the table header but
the offset from the entry of a list of objects. Sometimes, it indicates
an entry for a Method/Package/Buffer, which makes it difficult to be
reversely calculated to a table header offset.
3. When being used with method tracers (for example, Linux function trace),
it's better to have AML address logged instead of the AML offset because
the address is the only attribute that can uniquely identify the opcode.
This patch is required to solve the above issues. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/d2544058
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acstruct.h |2 +-
drivers/acpi/acpica/dsmethod.c |9 +++--
drivers/acpi/acpica/psloop.c | 15 +--
drivers/acpi/acpica/psobject.c | 15 +--
4 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/acpica/acstruct.h b/drivers/acpi/acpica/acstruct.h
index 44997ca..f9992dc 100644
--- a/drivers/acpi/acpica/acstruct.h
+++ b/drivers/acpi/acpica/acstruct.h
@@ -85,7 +85,7 @@ struct acpi_walk_state {
u8 namespace_override; /* Override existing objects */
u8 result_size; /* Total elements for the result stack */
u8 result_count;/* Current number of occupied elements of
result stack */
- u32 aml_offset;
+ u8 *aml;
u32 arg_types;
u32 method_breakpoint; /* For single stepping */
u32 user_breakpoint;/* User AML breakpoint */
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
index 85bb951..bf8c16e 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -214,6 +214,8 @@ acpi_ds_detect_named_opcodes(struct acpi_walk_state
*walk_state,
acpi_status
acpi_ds_method_error(acpi_status status, struct acpi_walk_state * walk_state)
{
+ u32 aml_offset;
+
ACPI_FUNCTION_ENTRY();
/* Ignore AE_OK and control exception codes */
@@ -234,13 +236,16 @@ acpi_ds_method_error(acpi_status status, struct
acpi_walk_state * walk_state)
* Handler can map the exception code to anything it wants,
including
* AE_OK, in which case the executing method will not be
aborted.
*/
+ aml_offset = (u32)ACPI_PTR_DIFF(walk_state->aml,
+ walk_state->parser_state.
+ aml_start);
+
status = acpi_gbl_exception_handler(status,
walk_state->method_node ?
walk_state->method_node->
name.integer : 0,
walk_state->opcode,
- walk_state->aml_offset,
- NULL);
+ aml_offset, NULL);
acpi_ex_enter_interpreter();
}
diff --git a/drivers/acpi/acpica/psloop.c b/drivers/acpi/acpica/psloop.c
index 6136458..ce66e73 100644
--- a/drivers/acpi/acpica/psloop.c
+++ b/drivers/acpi/acpica/psloop.c
@@ -125,10 +125,7 @@ acpi_ps_get_arguments(struct acpi_walk_state *walk_state,
*/
while (GET_CURRENT_ARG_TYPE(walk_state->arg_types)
&& !walk_state->arg_count) {
- walk_state->aml_offset =
- (u32)ACPI_PTR_DIFF(walk_state->parser_state.aml,
- walk_state->parser_state.
- aml_start);
+ walk_state->aml = walk_state->parser_state.aml;
status =
acpi_ps_get_next_arg(walk_state,
@@ -140,7 +137,10 @@ acpi_ps_get_arguments(struct acpi_walk_state *walk_state,
}
if (arg) {
- arg->common.aml_offset = walk_state->aml_offset;
+ arg->common.aml_offset =
+ (u32)ACPI_PTR_DIFF(walk_state->aml,
+ walk_state->parser_state.
+ aml_start);
[PATCH 03/22] ACPICA: Parser: Cleanup aml_offset in union acpi_operand_object.
ACPICA commit 61b360074fde2bb8282722579410f5d1fb12f84d
This patch converts aml_offset in union acpi_operand_object to AML address.
AML offset is actually only used by the debugger, using AML address is more
direct and efficient during the parsing stage so that we don't need to
calculate the offset during the parsing stage and will not have
difficulities in converting it into other offset attributes.
Sometimes, aml_offset is not an indication of the offset from the table
header but the offset from the entry of a list of terms, which requires
additional efforts to convert it into an offset from the table header. By
using AML address directly, there is no such difficulty.
Thus this patch also deletes a logic in disassembler that is trying to
convert the aml_offset from
"offset from the start address of Method/Package/Buffer"
into the
"offset from the start address of the ACPI table"
(Sample code deletion can be seen in acpi_dm_deferred_parse(), but the
function is not in the Linux kernel). Lv Zheng.
Link: https://github.com/acpica/acpica/commit/61b36007
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/aclocal.h |2 +-
drivers/acpi/acpica/psargs.c |7 +++
drivers/acpi/acpica/psloop.c | 15 ---
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index bc60096..607e628 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -726,7 +726,7 @@ union acpi_parse_value {
u8 descriptor_type; /* To differentiate
various internal objs */\
u8 flags; /* Type of Op */\
u16 aml_opcode; /* AML opcode */\
- u32 aml_offset; /* Offset of
declaration in AML */\
+ u8 *aml; /* Address of
declaration in AML */\
union acpi_parse_object *next; /* Next op */\
struct acpi_namespace_node *node; /* For use by
interpreter */\
union acpi_parse_value value; /* Value or args
associated with the opcode */\
diff --git a/drivers/acpi/acpica/psargs.c b/drivers/acpi/acpica/psargs.c
index 6d03877..0bee946 100644
--- a/drivers/acpi/acpica/psargs.c
+++ b/drivers/acpi/acpica/psargs.c
@@ -484,7 +484,7 @@ acpi_ps_get_next_simple_arg(struct acpi_parse_state
*parser_state,
static union acpi_parse_object *acpi_ps_get_next_field(struct acpi_parse_state
*parser_state)
{
- u32 aml_offset;
+ u8 *aml;
union acpi_parse_object *field;
union acpi_parse_object *arg = NULL;
u16 opcode;
@@ -498,8 +498,7 @@ static union acpi_parse_object
*acpi_ps_get_next_field(struct acpi_parse_state
ACPI_FUNCTION_TRACE(ps_get_next_field);
- aml_offset =
- (u32)ACPI_PTR_DIFF(parser_state->aml, parser_state->aml_start);
+ aml = parser_state->aml;
/* Determine field type */
@@ -541,7 +540,7 @@ static union acpi_parse_object
*acpi_ps_get_next_field(struct acpi_parse_state
return_PTR(NULL);
}
- field->common.aml_offset = aml_offset;
+ field->common.aml = aml;
/* Decode the field type */
diff --git a/drivers/acpi/acpica/psloop.c b/drivers/acpi/acpica/psloop.c
index ce66e73..d584383 100644
--- a/drivers/acpi/acpica/psloop.c
+++ b/drivers/acpi/acpica/psloop.c
@@ -137,10 +137,7 @@ acpi_ps_get_arguments(struct acpi_walk_state *walk_state,
}
if (arg) {
- arg->common.aml_offset =
- (u32)ACPI_PTR_DIFF(walk_state->aml,
- walk_state->parser_state.
- aml_start);
+ arg->common.aml = walk_state->aml;
acpi_ps_append_arg(op, arg);
}
@@ -494,18 +491,14 @@ acpi_status acpi_ps_parse_loop(struct acpi_walk_state
*walk_state)
continue;
}
- op->common.aml_offset =
- (u32)ACPI_PTR_DIFF(walk_state->aml,
- walk_state->parser_state.
- aml_start);
+ op->common.aml = walk_state->aml;
if (walk_state->op_info) {
ACPI_DEBUG_PRINT((ACPI_DB_PARSE,
- "Opcode %4.4X [%s] Op %p Aml
%p AmlOffset %5.5X\n",
+ "Opcode %4.4X [%s] Op %p Aml
%p\n",
(u32)op->common.aml_opcode,
[PATCH 00/22] ACPICA: 20150717 Release
The 20150717 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. i386 + allyes + CONFIG_ACPI=y 3. i386 + default + COFNIG_ACPI=n 4. i386 + allyes + CONFIG_ACPI=n 5. x86_64 + default + COFNIG_ACPI=y 6. x86_64 + allyes + CONFIG_ACPI=y 7. x86_64 + default + COFNIG_ACPI=n 8. x86_64 + allyes + CONFIG_ACPI=n Boot tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. x86_64 + default + COFNIG_ACPI=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All "drivers/acpi" configurations All "drivers/platform" drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20150619 Release): 539 lines After applying (20150717 Release): 518 lines Note that the reduction is due to: 1. The FACS related divergences are not counted; 2. Some debugger related divergences are merged in this release as the configurability of the debugger code has improved. Bob Moore (6): ACPICA: iASL: Add new warnings for method local_x and arg_x variables. ACPICA: Cleanup use of all non-ANSI local C library functions. ACPICA: Cleanup use of NEGATIVE and POSITIVE defines. ACPICA: iASL: Add support for TCPA Server Table. ACPICA: iASL/Disassembler: Add prototype verbose mode. ACPICA: Update version to 20150717. Lv Zheng (15): ACPICA: Parser: Reduce parser/namespace divergences for tracer support. ACPICA: Parser: Cleanup aml_offset in struct acpi_walk_state. ACPICA: Parser: Cleanup aml_offset in union acpi_operand_object. ACPICA: Dispatcher: Cleanup union acpi_operand_object's AML address assignments. ACPICA: Executer: Add back pointing reference of method operand. ACPICA: Namespace: Add function to directly return normalized full path. ACPICA: Dispatcher: Move stack traversal code to dispatcher. ACPICA: Dispatcher: Add trace support for interpreter. ACPICA: Executer: Add interpreter tracing mode for method tracing facility. ACPICA: Executer: Add OSL trace hook support. ACPICA: Executer: Add option to bypass opcode tracing. ACPICA: Parser: Remove redundant opcode execution debugging output. ACPICA: MSVC: Fix inclusion order issue of . ACPICA: Debugger: Reduce structure size for debugger. ACPICA: Debugger: Move debugger specific APIs to debugger component. Markus Elfring (1): ACPICA: Remove extraneous check for null walk_state. drivers/acpi/acpica/Makefile |2 + drivers/acpi/acpica/acdebug.h| 19 ++ drivers/acpi/acpica/acdispat.h |8 + drivers/acpi/acpica/acglobal.h |3 +- drivers/acpi/acpica/acinterp.h | 22 +++ drivers/acpi/acpica/aclocal.h| 11 +- drivers/acpi/acpica/acmacros.h |9 + drivers/acpi/acpica/acnamesp.h | 13 +- drivers/acpi/acpica/acobject.h |1 + drivers/acpi/acpica/acparser.h |4 +- drivers/acpi/acpica/acstruct.h |2 +- drivers/acpi/acpica/acutils.h| 23 ++- drivers/acpi/acpica/dsargs.c |4 +- drivers/acpi/acpica/dsdebug.c| 231 +++ drivers/acpi/acpica/dsmethod.c | 35 ++-- drivers/acpi/acpica/dswload.c|2 +- drivers/acpi/acpica/dswload2.c |2 +- drivers/acpi/acpica/excreate.c |1 + drivers/acpi/acpica/exdebug.c| 324 drivers/acpi/acpica/exdump.c |5 +- drivers/acpi/acpica/nsnames.c| 275 +++ drivers/acpi/acpica/nsparse.c| 42 ++--- drivers/acpi/acpica/nsutils.c|2 +- drivers/acpi/acpica/nsxfname.c |8 +- drivers/acpi/acpica/psargs.c | 26 +-- drivers/acpi/acpica/psloop.c | 18 +- drivers/acpi/acpica/psobject.c | 17 +- drivers/acpi/acpica/psparse.c| 14 +- drivers/acpi/acpica/psutils.c|8 +- drivers/acpi/acpica/psxface.c| 123 +--- drivers/acpi/acpica/rscreate.c |3 +- drivers/acpi/acpica/utdebug.c| 31 +++- drivers/acpi/acpica/utdelete.c |3 + drivers/acpi/acpica/utinit.c |2 - drivers/acpi/acpica/utmisc.c |2 +- drivers/acpi/acpica/utnonansi.c | 380 ++ drivers/acpi/acpica/utstring.c | 342 -- include/acpi/acoutput.h | 21 ++- include/acpi/acpiosxf.h |6 + include/acpi/acpixf.h| 13 +- include/acpi/actbl2.h| 17 +- include/acpi/actypes.h | 11 +- include/acpi/platform/acenvex.h |3 + include/acpi/platform/acmsvcex.h | 54 ++ include/acpi/platform/acwinex.h | 49 + 45 files changed, 1491 insertions(+), 700 deletions(-) create mode 100644 drivers/acpi/acpica/dsdebu
Re: [PATCH-v2 2/2] regulator: 88pm800: Add support for configuration of dual phase on BUCK1
2015-07-22 1:23 GMT+09:00 Vaibhav Hiremath :
> 88PM860 device supports dual phase mode on BUCK1 output.
> In normal usecase, BUCK1A and BUCK1B operates independently with 3A
> capacity. And they both can work as a dual phase providing 6A capacity.
>
> This patch updates the regulator driver to read the respective
> DT property and enable dual-phase mode on BUCK1.
>
> Note that, this is init time (one time) initialization.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/regulator/88pm800.c | 31 +++
> include/linux/mfd/88pm80x.h | 3 +++
> 2 files changed, 34 insertions(+)
Don't you need to update the constraints also? I think the BUCK1
regulator has fixed constraint of 3 A:
PM800_BUCK(buck1, BUCK1, BUCK_ENA, 0, 300, buck1_volt_range, 0x55),
and now it can handle 6 A.
>
> diff --git a/drivers/regulator/88pm800.c b/drivers/regulator/88pm800.c
> index e846e4c..1bf2b35 100644
> --- a/drivers/regulator/88pm800.c
> +++ b/drivers/regulator/88pm800.c
> @@ -267,6 +267,31 @@ static struct pm800_regulator_info
> pm860_regulator_info[] = {
> PM800_LDO(ldo20, LDO20, LDO_ENA1_3, 3, 1, ldo_volt_table2),
> };
>
> +static int pm800_regulator_init(struct platform_device *pdev)
> +{
> + struct pm800_regulators *pm800_data = platform_get_drvdata(pdev);
> + struct pm80x_chip *chip = pm800_data->chip;
> + int ret;
'ret' is used only in if statement below. I don't have strong feelings
but can you move it there to limit its scope or always return 'ret'
(after initializing to '0'). To me this would be more readable.
Best regards,
Krzysztof
> +
> + /* Currently only supported on 88pm860 device */
> + if (chip->type != CHIP_PM860)
> + return 0;
> +
> + if (of_property_read_bool(pdev->dev.of_node,
> + "marvell,88pm860-buck1-dualphase-en")) {
> + ret = regmap_update_bits(chip->subchip->regmap_power,
> + PM860_BUCK1_MISC,
> + BUCK1_DUAL_PHASE_SEL,
> + BUCK1_DUAL_PHASE_SEL);
> + if (ret) {
> + dev_err(chip->dev, "failed to set dual-pase mode
> %d\n", ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> static int pm800_regulator_probe(struct platform_device *pdev)
> {
> struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
> @@ -336,6 +361,12 @@ static int pm800_regulator_probe(struct platform_device
> *pdev)
> }
> }
>
> + ret = pm800_regulator_init(pdev);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to init 88pm800 regulator
> device\n");
> + return ret;
> + }
> +
> return 0;
> }
>
> diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> index a92d173..05d9bad 100644
> --- a/include/linux/mfd/88pm80x.h
> +++ b/include/linux/mfd/88pm80x.h
> @@ -295,6 +295,9 @@ enum {
> #define PM860_BUCK4_MISC2 (0x82)
> #define PM860_BUCK4_FULL_DRV BIT(2)
>
> +#define PM860_BUCK1_MISC (0x8E)
> +#define BUCK1_DUAL_PHASE_SEL BIT(2)
> +
> struct pm80x_rtc_pdata {
> int vrtc;
> int rtc_wakeup;
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: add wdt suspend/resume support
On Tue, 2015-07-21 at 20:45 -0700, Guenter Roeck wrote:
> On 07/21/2015 08:26 PM, Eddie Huang wrote:
> > From: Greta Zhang
> >
> > add wdt driver suspend/resume support
> >
> > Signed-off-by: Greta Zhang
> > Signed-off-by: Roger Lu
> > Signed-off-by: Eddie Huang
> > ---
> > drivers/watchdog/mtk_wdt.c | 38 ++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> > index 938b987..5ef3910 100644
> > --- a/drivers/watchdog/mtk_wdt.c
> > +++ b/drivers/watchdog/mtk_wdt.c
> > @@ -65,6 +65,7 @@ struct mtk_wdt_dev {
> > struct watchdog_device wdt_dev;
> > void __iomem *wdt_base;
> > struct notifier_block restart_handler;
> > + bool started;
>
> Any reason why you can not use watchdog_active() ?
Will change to use watchdog_active()
>
> > };
> >
> > static int mtk_reset_handler(struct notifier_block *this, unsigned long
> > mode,
> > @@ -125,6 +126,8 @@ static int mtk_wdt_stop(struct watchdog_device *wdt_dev)
> > reg &= ~WDT_MODE_EN;
> > iowrite32(reg, wdt_base + WDT_MODE);
> >
> > + mtk_wdt->started = false;
> > +
> > return 0;
> > }
> >
> > @@ -135,6 +138,8 @@ static int mtk_wdt_start(struct watchdog_device
> > *wdt_dev)
> > void __iomem *wdt_base = mtk_wdt->wdt_base;
> > int ret;
> >
> > + mtk_wdt->started = true;
> > +
> > ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
> > if (ret < 0)
> > return ret;
> > @@ -174,6 +179,8 @@ static int mtk_wdt_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, mtk_wdt);
> >
> > + mtk_wdt->started = false;
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > mtk_wdt->wdt_base = devm_ioremap_resource(&pdev->dev, res);
> > if (IS_ERR(mtk_wdt->wdt_base))
> > @@ -221,6 +228,35 @@ static int mtk_wdt_remove(struct platform_device *pdev)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_PM
> > +static int mtk_wdt_suspend(struct platform_device *pdev, pm_message_t
> > state)
> > +{
> > + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
> > +
> > + if (mtk_wdt->started) {
> > + mtk_wdt_stop(&mtk_wdt->wdt_dev);
> > + mtk_wdt->started = true;
>
> ?
>
Because mtk_wdt_stop() change mtk_wdt->started to false, so set
mtk_wdt->started back to true here. This code is not necessary if use
watchdog_active()
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_wdt_resume(struct platform_device *pdev)
> > +{
> > + struct mtk_wdt_dev *mtk_wdt = platform_get_drvdata(pdev);
> > +
> > + if (mtk_wdt->started) {
> > + mtk_wdt_start(&mtk_wdt->wdt_dev);
> > + mtk_wdt_ping(&mtk_wdt->wdt_dev);
> > + }
> > +
> > + return 0;
> > +}
> > +#else
> > +#definemtk_wdt_suspend NULL
> > +#definemtk_wdt_resume NULL
> > +#endif
> > +
> > static const struct of_device_id mtk_wdt_dt_ids[] = {
> > { .compatible = "mediatek,mt6589-wdt" },
> > { /* sentinel */ }
> > @@ -230,6 +266,8 @@ MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
> > static struct platform_driver mtk_wdt_driver = {
> > .probe = mtk_wdt_probe,
> > .remove = mtk_wdt_remove,
> > + .suspend= mtk_wdt_suspend,
> > + .resume = mtk_wdt_resume,
> > .driver = {
> > .name = DRV_NAME,
> > .of_match_table = mtk_wdt_dt_ids,
>
> Typically drivers would use struct dev_pm_ops and
> .pm = &mtk_wdt_pm_ops,
>
> Any reason for not using the same mechanism ?
>
Will change to use dev_pm_ops
Eddie
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Make cpuid <-> nodeid mapping persistent.
On 07/16/2015 06:13 AM, Tejun Heo wrote: Hello, On Tue, Jul 07, 2015 at 05:30:20PM +0800, Tang Chen wrote: [Solution] To fix this problem, we establish cpuid <-> nodeid mapping for all the possible cpus at boot time, and make it invariable. And according to init_cpu_to_node(), cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <-> apicid mapping. So the key point is obtaining all cpus' apicid. apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in MADT (Multiple APIC Description Table). So we finish the job in the following steps: 1. Enable apic registeration flow to handle both enabled and disabled cpus. This is done by introducing an extra parameter to generic_processor_info to let the caller control if disabled cpus are ignored. 2. Introduce a new array storing all possible cpuid <-> apicid mapping. And also modify the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping when registering local apic. Store the mapping in the array introduced above. 4. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus' apicid. This is also done by introducing an extra parameter to these apis to let the caller control if disabled cpus are ignored. 5. Establish all possible cpuid <-> nodeid mapping. This is done via an additional acpi namespace walk for processors. Hmmm... given that we probably want to allocate lower ids to the online cpus, as otherwise we can end up failing to bring existing cpus online because NR_CPUS is lower than the number of possible cpus, I wonder whether doing this lazily could be better / easier. e.g. just remember the mapping as cpus come online. When a new cpu comes up, look up whether it came up before. If so, use the ids from the last time. If not, allocate new ones. I think that would be less amount of change but does require updating the mapping dynamically. Hi TJ, Allocating cpuid when a new cpu comes up and reusing the cpuid when it comes up again is possible. But I'm not quite sure if it will be less modification because we still need an array or bit map or something to keep the mapping, and select backup nodes for cpus on memory-less nodes when allocating memory. I can post a set of patches for this idea. And then we can see which one is better. Thanks. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch V4 1/3] usb: Add Xen pvUSB protocol description
On Thu, Jul 23, 2015 at 06:04:39AM +0200, Juergen Gross wrote: > On 07/23/2015 01:46 AM, Greg KH wrote: > >On Tue, Jun 23, 2015 at 08:53:23AM +0200, Juergen Gross wrote: > >>Add the definition of pvUSB protocol used between the pvUSB frontend in > >>a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0). > >> > >>This header was originally provided by Fujitsu for Xen based on Linux > >>2.6.18. > >> > >>Changes are: > >>- adapt to Linux style guide > >> > >>Signed-off-by: Juergen Gross > >>--- > >> include/xen/interface/io/usbif.h | 252 > >> +++ > > > >Why is this a different interface than the existing ones we have today > >(i.e. usbip?) Where is it documented? Do the Xen developers / > > The interface definition is living in the Xen git repository for several > years now: > > git://xenbits.xen.org/xen.git -> xen/include/public/io/usbif.h That's header file, not a document describing the api here. > It is used e.g. in SUSE's xen kernel since 2.6.18. I am very aware of the amount of Xen crap in SuSE's kernel, don't use that as an excuse for me to merge it to mainline :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next 01/15 V2] mei: bus: fix drivers and devices names confusion
On Mon, Jun 15, 2015 at 09:56:41PM +0300, Tomas Winkler wrote:
> In the mei bus layer there is use of different variables
> of driver and device types with no clear naming convention.
> There are generic struct device and struct driver,
> then mei_cl_{device, driver}, and finally mei_device which
> in this context serves as a bus device.
>
> The patch sets following naming convention:
>
> the variables of type struct device remains dev
> the variables of type struct driver remains drv
> the variables of type struct mei_cl_device are now cldev
> the variables of type struct mei_cl_driver are now cldrv
> the variables of type struct mei_device are now bus, in bus
> layer context
>
> Signed-off-by: Tomas Winkler
Due to the changes in Linus's tree, this doesn't apply to 4.2-rc3. Can
you refresh this series and resend? Same for the other outstanding mei
patches you have sent that I haven't applied.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 091/102] staging: rtl8192e: Rename IPSLeave
On Sun, Jul 19, 2015 at 07:47:21PM +0200, Mateusz Kulikowski wrote: > On 19.07.2015 19:33, Mateusz Kulikowski wrote: > > Use naming schema found in other rtlwifi devices. > > Rename IPSLeave to rtl92e_ips_leave. > > > > Signed-off-by: Mateusz Kulikowski > > --- > [...] > > Oops, I've broke the thread once gmail anti-spam filter interrupted > submission. > > Greg - is it fine if it stays as is (If I see correctly, no message > intersected this series on staging mailing list)? It's fine as, is mutt does the right thing and can order things correctly :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 0/7] FPGA Manager Framework and Simple FPGA Bus
On Fri, Jul 17, 2015 at 10:51:10AM -0500, at...@opensource.altera.com wrote: > From: Alan Tull > > This patchset adds two chunks plus documentation: > * fpga manager core: exports ABI functions that write an image to a FPGA > * DT Overlay support: simple-fpga-bus to handle FPGA from a DT overlay > > The core's ABI is minimal to start with: only 6 functions. This gives a > common interface for programming various FPGA such that any higher level > interfaces such as the DT Overlays or anything else that is added can be > shared and not be manufacturor-specific. > > The DT Overlays support exists for the usage where the FPGA will contain > some "hardware" that will need drivers. Where that use model is not > appealing, the core ABI can be used to add a different use model such as > using an FPGA as acceleration as has been discussed. > > This patchset gets rid of the sysfs controls that allowed direct > control of a FPGA from userspace. > > This patchset is under drivers/staging as the interface could change. > > The bindings for the socpfga fpga manager already are upstreamed as > 1b4e119 Alan Tull : doc: add bindings document for altera fpga manager > > The DT Support is dependent on Pantelis's dtc overlay patches from > https://github.com/pantoniou/dtc.git > and his DT overlays configfs interface patches and fixes from > https://github.com/pantoniou/linux-beagle-track-mainline > > efb0c04 Pantelis Antoniou : gcl: Fix resource linking > 85e785e Pantelis Antoniou : ARM: DT: Enable symbols when CONFIG_OF_OVERLAY is > used > af0321f Pantelis Antoniou : OF: DT-Overlay configfs interface (v5) > 4c1c675 Pantelis Antoniou : configfs: Implement binary attributes (v4) > > > Alan Tull (7): > staging: usage documentation for FPGA manager core > staging: usage documentation for simple fpga bus > staging: add bindings document for simple fpga bus > staging: fpga manager: add sysfs interface document > staging: fpga manager core > staging: add simple-fpga-bus > staging: fpga manager: add driver for socfpga fpga manager > > drivers/staging/Kconfig|2 + > drivers/staging/Makefile |1 + > .../Documentation/ABI/sysfs-class-fpga-manager | 26 + > .../Documentation/bindings/simple-fpga-bus.txt | 61 ++ > drivers/staging/fpga/Documentation/fpga-mgr.txt| 117 > .../staging/fpga/Documentation/simple-fpga-bus.txt | 48 ++ > drivers/staging/fpga/Kconfig | 31 + > drivers/staging/fpga/Makefile | 10 + > drivers/staging/fpga/fpga-mgr.c| 373 > drivers/staging/fpga/simple-fpga-bus.c | 323 ++ > drivers/staging/fpga/socfpga.c | 616 > All drivers/staging/*/ directories need a TODO file that lists what needs to be done to it in order to get the code out of staging. Please redo the series and add that. > include/linux/fpga/fpga-mgr.h | 127 This should be within drivers/staging/ all staging code should be self-contained. Why isn't this going into the "real" part of the kernel? Why staging? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch V4 1/3] usb: Add Xen pvUSB protocol description
On 07/23/2015 01:46 AM, Greg KH wrote: On Tue, Jun 23, 2015 at 08:53:23AM +0200, Juergen Gross wrote: Add the definition of pvUSB protocol used between the pvUSB frontend in a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0). This header was originally provided by Fujitsu for Xen based on Linux 2.6.18. Changes are: - adapt to Linux style guide Signed-off-by: Juergen Gross --- include/xen/interface/io/usbif.h | 252 +++ Why is this a different interface than the existing ones we have today (i.e. usbip?) Where is it documented? Do the Xen developers / The interface definition is living in the Xen git repository for several years now: git://xenbits.xen.org/xen.git -> xen/include/public/io/usbif.h It is used e.g. in SUSE's xen kernel since 2.6.18. The differences between the Xen version and the one I've posted here are only style and name space related. maintainers agree with this interface and code? I need their sign-off before I can accept such a thing. Sure. David, Konrad, Boris, could one of you please comment on the patches? 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: [PATCH 1/5] drivers: staging: rtl8192u: fixing coding style issues in r8192U_core.c
On Fri, Jul 17, 2015 at 03:59:16PM +0200, Joseph-Eugene Winzer wrote: > Fixing several coding style issues, like > C99 Comment Style > Trailing whitespaces > Inconsistent spacing of operators > Started to reformat comments/expressions for 80 character limit These are multiple things, so they need to be multiple patches, don't do it all in one single patch. Please break this up into much more easy-to-review patches and resend the series. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] livepatch: Fix the issue to make livepatch enable/disable patch correctly
On 07/22/15 at 09:40am, Josh Poimboeuf wrote: > On Wed, Jul 15, 2015 at 04:55:06PM +0800, Minfei Huang wrote: > > From: Minfei Huang > > > > Livepatch will obey the stacking rule to enable/disable the patch. It > > only allows to enable the patch, when it is the fist disabled patch, > > disable the patch, when it is the last enabled patch. > > > > In the livepatch code, it uses list to gather the all of the patches. > > And we do not know whether the previous/next patch is patched to the > > same modules or vmlinux in that way. > > > > According to above rule, livepatch will make incorrect decision to > > enable/disable the patch. Following is an example to show how livepatch > > does. > > > > - install the livepatch example module which is in samples/livepatch. > > - install the third part kernel module > > - install the livepatch module which is patched to the third part module > > - disable the livepatch example module > > > > We can find that we can not disable livepatch example module, although > > it is the last enabled patch. > > > > To fix this issue, we will find the corresponding patch which is patched > > to the same modules or vmlinux, when we enable/disable the patch. > > Is it really safe to assume that there are no dependencies between > patches which patch different objects? > I think so. It is weird that there are denpendencies which are different objects in different patches. To apply this patch, we can make livepatch more flexible to manage the patch. Thanks Minfei > -- > Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] staging: sm750fb: ddk750_power.c: Remove optionnal parentheses.
On Fri, Jul 17, 2015 at 03:04:33PM +0200, Antoine BLIN wrote: > Fix up "return is not a function, parentheses are not required" error found by > the checkpatch.pl script. > > Signed-off-by: Antoine BLIN > --- > drivers/staging/sm750fb/ddk750_power.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Someone else already sent this fix in just before you did, sorry. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc/corenet: use the mixed mode of MPIC when enabling CPU hotplug
Core reset may cause issue if using the proxy mode of MPIC.
Use the mixed mode of MPIC if enabling CPU hotplug.
Signed-off-by: Chenhui Zhao
---
arch/powerpc/platforms/85xx/corenet_generic.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index bd839dc..0119224 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -212,7 +212,15 @@ define_machine(corenet_generic) {
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
.pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
+/*
+ * Core reset may cause issue if using the proxy mode of MPIC.
+ * So, use the mixed mode of MPIC if enabling CPU hotplug.
+ */
+#ifdef CONFIG_HOTPLUG_CPU
+ .get_irq= mpic_get_irq,
+#else
.get_irq= mpic_get_coreint_irq,
+#endif
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
--
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/
