Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform
On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote: > Sort of. What we need is a "do not touch PIC/PIT" bit for the code that > tries to fall back to them in some cases (which may appear to work if > the hardware is physically there, but it may confuse the platform). Can "some cases" detection be nicely put into a x86_platform platform-specific method? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tip:perf/core] Revert "perf: Remove the extra validity check on nr_pages"
> > > * Liang, Kan wrote: > > > > * tip-bot for Kan Liang wrote: > > > > > > > --- a/kernel/events/core.c > > > > +++ b/kernel/events/core.c > > > > @@ -4446,7 +4446,7 @@ static int perf_mmap(struct file *file, struct > > > vm_area_struct *vma) > > > > * If we have rb pages ensure they're a power-of-two number, so > > > we > > > > * can do bitmasks instead of modulo. > > > > */ > > > > - if (!is_power_of_2(nr_pages)) > > > > + if (nr_pages != 0 && !is_power_of_2(nr_pages)) > > > > return -EINVAL; > > > > > > Hm, what does is_power_of_2(0) return? It should return 0, because 0 > is > > > not a power of 2! > > > > > > and if it's fixed to return 0, then the check should properly be > something > > > like: > > > > > > if (!nr_pages || !is_power_of_2(nr_pages)) > > > > > > or so? > > > > nr_pages == 0 is valid, we cannot return -EINVAL. Because > > vma_size = vma->vm_end - vma->vm_start; > > nr_pages = (vma_size / PAGE_SIZE) - 1; > > > > So here we only want to check is_power_of_2 > > when the pages > 1 (or nr_pages > 0). > > I don't think you answered my first question, on which my later > comments rely: > > > > Hm, what does is_power_of_2(0) return? It should return 0, because 0 > is > > > not a power of 2! Yes, is_power_of_2(0) returns 0. Thanks, Kan > > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.10 00/53] 3.10.71-stable review
On 03/03/2015 10:06 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.71 release. There are 53 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Mar 6 05:45:30 UTC 2015. Anything received after that time might be too late. Build results: total: 123 pass: 122 fail: 1 Failed builds: s390:defconfig Qemu tests: total: 27 pass: 27 fail: 0 Build failure is: arch/s390/kvm/interrupt.c: In function 'kvm_s390_inject_vm': arch/s390/kvm/interrupt.c:740:3: error: label 'unlock_fi' used but not defined make[2]: *** [arch/s390/kvm/interrupt.o] Error 1 make[1]: *** [arch/s390/kvm] Error 2 Caused by 'KVM: s390: floating irqs: fix user triggerable endless loop' which appears to depend on another commit. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/04/2015 02:53 PM, David Vrabel wrote: On 04/03/15 13:31, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Perhaps the block backend in qemu? Okay, so this would be driven by qemu then? The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. I think I would have preferred the original large file split up (if there's a sensible functional grouping of the resulting bits). If, after considering a userspace backend, you think that this kernel one is the way to go I'll give it another look and see if I can suggest a suitable split. I can split it up, if you really want. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. usbback is just a regular USB device driver and most of these don't live under drivers/usb/ but in the subsystem for the type of device they're providing (which in this case is a Xen backend, hence drivers/xen/). Okay, I'll move it to drivers/xen. 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/
intel_soc_dts_thermal binding issues
Hi All, We've seen a number of reports where people see: [ 20.499427] intel_soc_dts_thermal: request_threaded_irq ret -22 [ 20.519160] intel_soc_dts_thermal: request_threaded_irq ret -22 [ 20.532660] intel_soc_dts_thermal: request_threaded_irq ret -22 in their boot logs. They view this as a kernel bug and report is as such. The above log came from an ASUS x200ma machine, which has a quad core Baytrail-M Pentium CPU (N3530). I can't tell if the issue is because the driver is trying to bind to all 4 cores and only CPU0 works, or what other issue would cause this. I personally have a Celeron based NUC with a N2820 that gets the error above for both cores and the driver doesn't load at all. Is there something else the driver should be doing to bind to the various CPUs? If there's nothing else it can key off of, can we drop the pr_err so it stops showing up in dmesg? 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: [RFC v1 0/5] fs/locks: Use plain percpu spinlocks instead of lglock to protect file_lock
On 03/03/2015 01:29 AM, Jeff Layton wrote: >> Hmm, are you sure about that? I read the code this way that when a lock >> is added to flock_list it stays on that CPU. The locks are not moved >> from one flock_list to another during their existent. >> > > Yes, I'm sure. When a file lock is acquired, we assign the fl_link_cpu > to the current CPU and add it to the current CPU's global list. When > the lock is released, any blocked lock that might have been blocking on > it could acquire it at that point, and that doesn't necessarily occur > on the same CPU as where the lock was originally held. > > So, it's entirely possible that between when you drop the spinlock on > one CPU and pick it up on another, the lock could have been released > and then reacquired on a different CPU. D'oh. I am an idiot. I didn't really understand it the first time. Yes, you are right. cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix 1/2] x86/PCI/ACPI: Ignore resources consumed by host bridge itself
On Wednesday, March 04, 2015 04:47:11 PM Jiang Liu wrote:
> When parsing resources for PCI host bridge, we should ignore resources
> consumed by host bridge itself and only report window resources available
> to child PCI busses.
>
> Signed-off-by: Jiang Liu
Queued up for 4.0-rc3, thanks!
> ---
> arch/x86/pci/acpi.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 6ac273832f28..e4695985f9de 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -331,7 +331,7 @@ static void probe_pci_root_info(struct pci_root_info
> *info,
> struct list_head *list)
> {
> int ret;
> - struct resource_entry *entry;
> + struct resource_entry *entry, *tmp;
>
> sprintf(info->name, "PCI Bus %04x:%02x", domain, busnum);
> info->bridge = device;
> @@ -345,8 +345,13 @@ static void probe_pci_root_info(struct pci_root_info
> *info,
> dev_dbg(>dev,
> "no IO and memory resources present in _CRS\n");
> else
> - resource_list_for_each_entry(entry, list)
> - entry->res->name = info->name;
> + resource_list_for_each_entry_safe(entry, tmp, list) {
> + if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
> + (entry->res->flags & IORESOURCE_DISABLED))
> + resource_list_destroy_entry(entry);
> + else
> + entry->res->name = info->name;
> + }
> }
>
> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix 2/2] x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs
On Wednesday, March 04, 2015 04:47:12 PM Jiang Liu wrote:
> Some BIOSes report incorrect length for ACPI address space descriptors,
> so relax the checks to avoid regressions. This issue has appeared several
> times as:
> 3162b6f0c5e1 ("PNPACPI: truncate _CRS windows with _LEN > _MAX - _MIN + 1")
> d558b483d5a7 ("x86/PCI: truncate _CRS windows with _LEN > _MAX - _MIN + 1")
> f238b414a74a ("PNPACPI: compute Address Space length rather than using _LEN")
> 48728e077480 ("x86/PCI: compute Address Space length rather than using _LEN")
>
> Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221
> for more details and example malformed ACPI resource descriptors.
>
> Signed-off-by: Jiang Liu
> Tested-by: Dave Airlie
> Tested-by: Prakash Punnoor
Queued up for 4.0-rc3, thanks!
Bjorn, please let me know if you have any objections.
> ---
> drivers/acpi/resource.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index c723668e3e27..5589a6e2a023 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -42,8 +42,10 @@ static bool acpi_dev_resource_len_valid(u64 start, u64
> end, u64 len, bool io)
>* CHECKME: len might be required to check versus a minimum
>* length as well. 1 for io is fine, but for memory it does
>* not make any sense at all.
> + * Note: some BIOSes report incorrect length for ACPI address space
> + * descriptor, so remove check of 'reslen == len' to avoid regression.
>*/
> - if (len && reslen && reslen == len && start <= end)
> + if (len && reslen && start <= end)
> return true;
>
> pr_debug("ACPI: invalid or unassigned resource %s [%016llx - %016llx]
> length [%016llx]\n",
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] user_namespaces.7: Update the documention to reflect the fixes for negative groups
On 02/02/2015 10:31 PM, Alban Crequy wrote: > Hello, > > Thanks for updating the man page. > > On 12 December 2014 at 22:54, Eric W. Biederman wrote: > (...) >> Furthermore to preserve in some form the useful applications that have >> been setting gid_map without privilege the file /proc/[pid]/setgroups >> was added to allow disabling setgroups. With the setgroups system >> call permanently disabled in a user namespace it again becomes safe to >> allow writes to gid_map without privilege. >> >> Here is my meager attempt to update user_namespaces.7 to reflect these >> issues. > > The program userns_child_exec.c in user_namespaces.7 should be updated > to write in /proc/.../setgroups, near the line: > /* Update the UID and GID maps in the child */ > > Otherwise, the example given in the manpage does not work: > $ ./userns_child_exec -p -m -U -M '0 1000 1' -G '0 1000 1' bash Thanks, Alban. I've added code to the example to handle /proc/PID/setgroups (and tested). Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 15/15] x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE_2 macro
On Wed, Mar 04, 2015 at 08:26:33AM +0100, Ingo Molnar wrote: > Since most CPUs we care about have ERMS, wouldn't it be better to > patch in the actual memcpy_erms sequence into the primary memcpy() > function? It's just about 9 bytes AFAICT. Actually, most set REP_GOOD - all Intel family 6 and all relevant AMDs. And only the newer Intels have ERMS. My SNB, for example doesn't while IVB has it. So I'd guess everything >= IVB would have it. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ppc: Add missing #include
On Wednesday, March 04, 2015 12:56:20 PM Geert Uytterhoeven wrote: > If CONFIG_SMP=n, does not include , causing: > > drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init': > drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of > function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration] > > Signed-off-by: Geert Uytterhoeven > --- > Seen with e.g. corenet64_smp_defconfig + CONFIG_CPU_FREQ=y, > CONFIG_PPC_CORENET_CPUFREQ=y, CONFIG_SMP=n > > v2: > - Add comment for #include directive, as requested by Viresh Applied, thanks! > --- > drivers/cpufreq/ppc-corenet-cpufreq.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c > b/drivers/cpufreq/ppc-corenet-cpufreq.c > index bee5df7794d33d10..7cb4b766cf948d3f 100644 > --- a/drivers/cpufreq/ppc-corenet-cpufreq.c > +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c > @@ -22,6 +22,8 @@ > #include > #include > > +#include /* for get_hard_smp_processor_id() in UP configs */ > + > /** > * struct cpu_data - per CPU data struct > * @parent: the parent node of cpu clock > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] iio:inv-mpu6050: Fix inconsistency for the scale channel
> -Original Message-
> From: linux-iio-ow...@vger.kernel.org [mailto:linux-iio-
> ow...@vger.kernel.org] On Behalf Of Adriana Reus
> Sent: Monday, February 23, 2015 4:41 PM
> To: ji...@kernel.org; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Pandruvada, Srinivas; Reus, Adriana
> Subject: [PATCH] iio:inv-mpu6050: Fix inconsistency for the scale channel
>
> Fix inconsistency in the semantics of the scale attribute.
> For scale the write_raw function was considering the scale table index and
> writing the appropriate value into the range register, while for read_raw it
> was outputting the actual scale.
> Fix this behaviour and adhere to the iio ABI specification.
>
> Signed-off-by: Adriana Reus
Reviewed-by: Viorel Suman
> ---
> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 56 --
>
> 1 file changed, 30 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index 9be9b20..4cf056d 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -401,42 +401,46 @@ error_read_raw:
> }
> }
>
> -static int inv_mpu6050_write_fsr(struct inv_mpu6050_state *st, int fsr)
> +static int inv_mpu6050_write_gyro_scale(struct inv_mpu6050_state *st,
> +int val)
> {
> - int result;
> + int result, i;
> u8 d;
>
> - if (fsr < 0 || fsr > INV_MPU6050_MAX_GYRO_FS_PARAM)
> - return -EINVAL;
> - if (fsr == st->chip_config.fsr)
> - return 0;
> + for (i = 0; i < ARRAY_SIZE(gyro_scale_6050); ++i) {
> + if (gyro_scale_6050[i] == val) {
> + d = (i <<
> INV_MPU6050_GYRO_CONFIG_FSR_SHIFT);
> + result = inv_mpu6050_write_reg(st,
> + st->reg->gyro_config, d);
> + if (result)
> + return result;
>
> - d = (fsr << INV_MPU6050_GYRO_CONFIG_FSR_SHIFT);
> - result = inv_mpu6050_write_reg(st, st->reg->gyro_config, d);
> - if (result)
> - return result;
> - st->chip_config.fsr = fsr;
> + st->chip_config.fsr = i;
> + return 0;
> + }
> + }
>
> - return 0;
> + return -EINVAL;
> }
>
> -static int inv_mpu6050_write_accel_fs(struct inv_mpu6050_state *st, int
> fs)
> +static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st,
> +int val)
> {
> - int result;
> + int result, i;
> u8 d;
>
> - if (fs < 0 || fs > INV_MPU6050_MAX_ACCL_FS_PARAM)
> - return -EINVAL;
> - if (fs == st->chip_config.accl_fs)
> - return 0;
> + for (i = 0; i < ARRAY_SIZE(accel_scale); ++i) {
> + if (accel_scale[i] == val) {
> + d = (i << INV_MPU6050_ACCL_CONFIG_FSR_SHIFT);
> + result = inv_mpu6050_write_reg(st,
> + st->reg->accl_config, d);
> + if (result)
> + return result;
>
> - d = (fs << INV_MPU6050_ACCL_CONFIG_FSR_SHIFT);
> - result = inv_mpu6050_write_reg(st, st->reg->accl_config, d);
> - if (result)
> - return result;
> - st->chip_config.accl_fs = fs;
> + st->chip_config.accl_fs = i;
> + return 0;
> + }
> + }
>
> - return 0;
> + return -EINVAL;
> }
>
> static int inv_mpu6050_write_raw(struct iio_dev *indio_dev, @@ -463,10
> +467,10 @@ static int inv_mpu6050_write_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_SCALE:
> switch (chan->type) {
> case IIO_ANGL_VEL:
> - result = inv_mpu6050_write_fsr(st, val);
> + result = inv_mpu6050_write_gyro_scale(st, val2);
> break;
> case IIO_ACCEL:
> - result = inv_mpu6050_write_accel_fs(st, val);
> + result = inv_mpu6050_write_accel_scale(st, val2);
> break;
> default:
> result = -EINVAL;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in the
> body of a message to majord...@vger.kernel.org More majordomo info
> at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 1/2] perf symbols: Allow symbol alias when loading map for symbol name
When perf probe tries to add a probe in a binary using symbol name, it
sometimes failed since some symbols were discard during loading dso.
When it resolves an address to symbol, it'd be better to have just one
symbol at given address. But for finding address from symbol, it'd be
better to keep all names (including aliases).
Add and propagate a new allow_alias argument to dso (and map) load
functions so that it can keep those duplicate symbol aliases.
Cc: Masami Hiramatsu
Signed-off-by: Namhyung Kim
---
tools/perf/util/machine.c| 2 +-
tools/perf/util/map.c| 6 +++---
tools/perf/util/map.h| 8 +++-
tools/perf/util/symbol-elf.c | 5 +++--
tools/perf/util/symbol-minimal.c | 2 +-
tools/perf/util/symbol.c | 8 +---
tools/perf/util/symbol.h | 5 +++--
7 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 24f8c978cfd4..01ba9b635e4f 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1128,7 +1128,7 @@ static int machine__process_kernel_mmap_event(struct
machine *machine,
* preload dso of guest kernel and modules
*/
dso__load(kernel, machine->vmlinux_maps[MAP__FUNCTION],
- NULL);
+ NULL, false);
}
}
return 0;
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 62ca9f2607d5..711e0728520b 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -248,7 +248,7 @@ void map__fixup_end(struct map *map)
#define DSO__DELETED "(deleted)"
-int map__load(struct map *map, symbol_filter_t filter)
+int __map__load(struct map *map, symbol_filter_t filter, bool allow_alias)
{
const char *name = map->dso->long_name;
int nr;
@@ -256,7 +256,7 @@ int map__load(struct map *map, symbol_filter_t filter)
if (dso__loaded(map->dso, map->type))
return 0;
- nr = dso__load(map->dso, map, filter);
+ nr = dso__load(map->dso, map, filter, allow_alias);
if (nr < 0) {
if (map->dso->has_build_id) {
char sbuild_id[BUILD_ID_SIZE * 2 + 1];
@@ -304,7 +304,7 @@ struct symbol *map__find_symbol(struct map *map, u64 addr,
struct symbol *map__find_symbol_by_name(struct map *map, const char *name,
symbol_filter_t filter)
{
- if (map__load(map, filter) < 0)
+ if (__map__load(map, filter, true) < 0)
return NULL;
if (!dso__sorted_by_name(map->dso, map->type))
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index 0e42438b1e59..ba156076c25b 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -149,7 +149,13 @@ size_t map__fprintf_dsoname(struct map *map, FILE *fp);
int map__fprintf_srcline(struct map *map, u64 addr, const char *prefix,
FILE *fp);
-int map__load(struct map *map, symbol_filter_t filter);
+int __map__load(struct map *map, symbol_filter_t filter, bool allow_alias);
+
+static inline int map__load(struct map *map, symbol_filter_t filter)
+{
+ return __map__load(map, filter, false);
+}
+
struct symbol *map__find_symbol(struct map *map,
u64 addr, symbol_filter_t filter);
struct symbol *map__find_symbol_by_name(struct map *map, const char *name,
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index ada16762fac2..fb630f8fc45c 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -754,7 +754,7 @@ static bool want_demangle(bool is_kernel_sym)
int dso__load_sym(struct dso *dso, struct map *map,
struct symsrc *syms_ss, struct symsrc *runtime_ss,
- symbol_filter_t filter, int kmodule)
+ symbol_filter_t filter, int kmodule, bool allow_alias)
{
struct kmap *kmap = dso->kernel ? map__kmap(map) : NULL;
struct map *curr_map = map;
@@ -1048,7 +1048,8 @@ new_symbol:
* For misannotated, zeroed, ASM function sizes.
*/
if (nr > 0) {
- symbols__fixup_duplicate(>symbols[map->type]);
+ if (!allow_alias)
+ symbols__fixup_duplicate(>symbols[map->type]);
symbols__fixup_end(>symbols[map->type]);
if (kmap) {
/*
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index d7efb03b3f9a..fefeeb32697e 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -334,7 +334,7 @@ int dso__load_sym(struct dso *dso, struct map *map
__maybe_unused,
struct symsrc *ss,
struct symsrc *runtime_ss __maybe_unused,
symbol_filter_t filter __maybe_unused,
- int kmodule __maybe_unused)
+
Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform
On Wednesday, March 04, 2015 10:50:11 AM Borislav Petkov wrote: > On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote: > > > > > >Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code > > >is a mistake. > > > > ideally, the presence of that flag in the firmware table will clear/set > > more global settings, > > for example, having that flag should cause the 8042 input code to not probe > > for the 8042. > > > > for interrupts, there really ought to be a "apic first/only" mode, which is > > then used on > > all modern systems (not just hw reduced). > > Do we need some sort of platform-specific querying interfaces now too, > similar to cpu_has()? I.e., platform_has()... > > if (platform_has(X86_PLATFORM_REDUCED_HW)) > do stuff.. > > Hmmm. Sort of. What we need is a "do not touch PIC/PIT" bit for the code that tries to fall back to them in some cases (which may appear to work if the hardware is physically there, but it may confuse the platform). -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drivers: hv: hv_balloon: don't lose memory when onlining order is not natural
Memory blocks can be onlined in random order. When this order is not natural
some memory pages are not onlined because of the redundant check in
hv_online_page().
Here is a real world scenario:
1) Host tries to hot-add the following (process_hot_add):
pg_start=rg_start=0x48000, pfn_cnt=111616, rg_size=262144
2) This results in adding 4 memory blocks:
[ 109.057866] init_memory_mapping: [mem 0x4800-0x4fff]
[ 114.102698] init_memory_mapping: [mem 0x5000-0x57ff]
[ 119.168039] init_memory_mapping: [mem 0x5800-0x5fff]
[ 124.233053] init_memory_mapping: [mem 0x6000-0x67ff]
The last one is incomplete but we have special has->covered_end_pfn counter to
avoid onlining non-backed frames and hv_bring_pgs_online() function to bring
them online later on.
3) Now we have 4 offline memory blocks: /sys/devices/system/memory/memory9-12
$ for f in /sys/devices/system/memory/memory*/state; do echo $f `cat $f`; done
| grep -v onlin
/sys/devices/system/memory/memory10/state offline
/sys/devices/system/memory/memory11/state offline
/sys/devices/system/memory/memory12/state offline
/sys/devices/system/memory/memory9/state offline
4) We bring them online in non-natural order:
$grep MemTotal /proc/meminfo
MemTotal: 966348 kB
$echo online > /sys/devices/system/memory/memory12/state && grep MemTotal
/proc/meminfo
MemTotal:1019596 kB
$echo online > /sys/devices/system/memory/memory11/state && grep MemTotal
/proc/meminfo
MemTotal:1150668 kB
$echo online > /sys/devices/system/memory/memory9/state && grep MemTotal
/proc/meminfo
MemTotal:1150668 kB
As you can see memory9 block gives us zero additional memory. We can also
observe a huge discrepancy between host- and guest-reported memory sizes.
The root cause of the issue is the redundant pg >= covered_start_pfn check (and
covered_start_pfn advancing) in hv_online_page(). When upper memory block in
being onlined before the lower one (memory12 and memory11 in the above case) we
advance the covered_start_pfn pointer and all memory9 pages do not pass the
check. If the assumption that host always gives us requests in sequential order
and pg_start always equals rg_start when the first request for the new HA
region is received (that's the case in my testing) is correct than we can get
rid of covered_start_pfn and pg >= start_pfn check in hv_online_page() is
sufficient.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_balloon.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index c5bb872..614347e 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -428,14 +428,13 @@ struct dm_info_msg {
* currently hot added. We hot add in multiples of 128M
* chunks; it is possible that we may not be able to bring
* online all the pages in the region. The range
- * covered_start_pfn : covered_end_pfn defines the pages that can
+ * covered_end_pfn defines the pages that can
* be brough online.
*/
struct hv_hotadd_state {
struct list_head list;
unsigned long start_pfn;
- unsigned long covered_start_pfn;
unsigned long covered_end_pfn;
unsigned long ha_end_pfn;
unsigned long end_pfn;
@@ -678,8 +677,7 @@ static void hv_online_page(struct page *pg)
list_for_each(cur, _device.ha_region_list) {
has = list_entry(cur, struct hv_hotadd_state, list);
- cur_start_pgp = (unsigned long)
- pfn_to_page(has->covered_start_pfn);
+ cur_start_pgp = (unsigned long)pfn_to_page(has->start_pfn);
cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
if (((unsigned long)pg >= cur_start_pgp) &&
@@ -691,7 +689,6 @@ static void hv_online_page(struct page *pg)
__online_page_set_limits(pg);
__online_page_increment_counters(pg);
__online_page_free(pg);
- has->covered_start_pfn++;
}
}
}
@@ -735,10 +732,9 @@ static bool pfn_covered(unsigned long start_pfn, unsigned
long pfn_cnt)
* is, update it.
*/
- if (has->covered_end_pfn != start_pfn) {
+ if (has->covered_end_pfn != start_pfn)
has->covered_end_pfn = start_pfn;
- has->covered_start_pfn = start_pfn;
- }
+
return true;
}
@@ -783,7 +779,6 @@ static unsigned long handle_pg_range(unsigned long pg_start,
pgs_ol = pfn_cnt;
hv_bring_pgs_online(start_pfn, pgs_ol);
has->covered_end_pfn += pgs_ol;
- has->covered_start_pfn += pgs_ol;
pfn_cnt -= pgs_ol;
}
@@ -844,7 +839,6 @@ static unsigned long process_hot_add(unsigned long
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 04/03/15 13:31, Juergen Gross wrote: > On 03/02/2015 12:39 PM, David Vrabel wrote: >> On 26/02/15 13:35, Juergen Gross wrote: >>> Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen >>> domU to communicate with a USB device assigned to that domU. The >>> communication is all done via the pvUSB backend in a driver domain >>> (usually Dom0) which is owner of the physical device. >> >> Why do we need a kernel usb backend instead of a user-space one using >> libusb? > > Good question. At a first glance libusb seems to offer most/all needed > interfaces. The main question is whether performance with libusb will > be okay. There will be one additional copy of the I/O data needed if > I've read the code in drivers/usb/core/devio.c correctly. > > I haven't worked with user space backends yet. Do you recommend a > special example I should start with? Perhaps the block backend in qemu? >>> Changes from the original version are: >>> - port to upstream kernel >>> - put all code in just one source file >> >> ?? I'm not sure that was an improvement. The resulting single file is >> too large IMO. > > OTOH this reduces overall code size: > > New file has 1845 lines, while old version had in sum 2243 lines with > the largest file having 1217 lines. So the largest file is 50% larger, > while overall size is 20% smaller. I think I would have preferred the original large file split up (if there's a sensible functional grouping of the resulting bits). If, after considering a userspace backend, you think that this kernel one is the way to go I'll give it another look and see if I can suggest a suitable split. >>> - move module to appropriate location in kernel tree >> >> drivers/xen/ is the correct location for this driver. > > Hmm, so you regard placement of xen-netback under drivers/net and > xen-blkback under drivers/block as wrong? I've just followed these > examples. usbback is just a regular USB device driver and most of these don't live under drivers/usb/ but in the subsystem for the type of device they're providing (which in this case is a Xen backend, hence drivers/xen/). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 2/2] perf probe: Allow weak symbols to be probed
It currently prevents adding probes in weak symbols. But there're cases
that given name is an only weak symbol so that we cannot add probe.
$ perf probe -x /usr/lib/libc.so.6 -a calloc
Failed to find symbol calloc in /usr/lib/libc-2.21.so
Error: Failed to add events.
$ nm /usr/lib/libc.so.6 | grep calloc
0007b1f0 t __calloc
0007b1f0 T __libc_calloc
0007b1f0 W calloc
This change will result in duplicate probes when strong and weak symbols
co-exist in a binary. But I think it's not a big problem since probes
at the weak symbol will never be hit anyway.
Cc: Masami Hiramatsu
Signed-off-by: Namhyung Kim
---
tools/perf/util/probe-event.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 1c570c2fa7cc..12b7d018106e 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2339,8 +2339,7 @@ static int find_probe_functions(struct map *map, char
*name)
struct symbol *sym;
map__for_each_symbol_by_name(map, name, sym) {
- if (sym->binding == STB_GLOBAL || sym->binding == STB_LOCAL)
- found++;
+ found++;
}
return found;
@@ -2708,8 +2707,7 @@ static struct strfilter *available_func_filter;
static int filter_available_functions(struct map *map __maybe_unused,
struct symbol *sym)
{
- if ((sym->binding == STB_GLOBAL || sym->binding == STB_LOCAL) &&
- strfilter__compare(available_func_filter, sym->name))
+ if (strfilter__compare(available_func_filter, sym->name))
return 0;
return 1;
}
--
2.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 v4 4/4] scsi: ufs: inject errors to verify error handling
2015-03-02 23:56 GMT+09:00 Gilad Broner :
> From: Sujit Reddy Thumma
>
> Use fault-injection framework to simulate error conditions
> in the controller and verify error handling mechanisms
> implemented in UFS host controller driver.
>
> This is used only during development and hence
> guarded by CONFIG_UFS_FAULT_INJECTION debug config option.
This feature looks useful, but I have a couple of comments and
question.
> +static bool inject_cmd_hang_tr(struct ufs_hba *hba)
> +{
> + int tag;
> +
> + tag = find_first_bit(>outstanding_reqs, hba->nutrs);
> + if (tag == hba->nutrs)
> + return 0;
> +
> + __clear_bit(tag, >outstanding_reqs);
> + hba->lrb[tag].cmd = NULL;
> + __clear_bit(tag, >lrb_in_use);
hba->lrb_in_use is a bitmap set by test_and_set_bit_lock(). So
this should be cleared by clear_bit_unlock().
And as soon as the bit corresponds to this slot in hba->lrb_in_use is
cleared, this slot could be reused. But if the request corresponds
to the slot is not completed yet, it could sacrifice the new request,
too. So should we only inject into the commands which have been
completed like this?
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
completed_reqs = tr_doorbell ^ hba->outstanding_reqs;
tag = find_first_bit(_reqs, hba->nutrs);
...
Or clear the corresponding bit in REG_UTP_TASK_REQ_LIST_CLEAR, just
like what inject_fatal_err_tr() does?
> +
> + /* command hang injected */
> + return 1;
> +}
> +
> +static int inject_cmd_hang_tm(struct ufs_hba *hba)
> +{
> + int tag;
> +
> + tag = find_first_bit(>outstanding_tasks, hba->nutmrs);
> + if (tag == hba->nutmrs)
> + return 0;
> +
> + __clear_bit(tag, >outstanding_tasks);
> + __clear_bit(tag, >tm_slots_in_use);
> +
> + /* command hang injected */
> + return 1;
> +}
The same goes for hba->tm_slots_in_use.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/04/2015 02:41 PM, Ian Campbell wrote: On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote: - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. At least in the case of netback it really is just a normal Ethernet driver as far as the kernel is concerned. The fact it happens to talk to a virtual device doesn't matter. I don't know about other device types. usbback is just a normal USB driver as far as the kernel is concerned. :-) 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/1] regulator: Only enable disabled regulators on resume
Hello Doug,
On 03/03/2015 08:05 PM, Javier Martinez Canillas wrote:
> On 03/03/2015 06:24 PM, Doug Anderson wrote:
>>>
>>> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
>>> index f2452148c8da..8551400d57e4 100644
>>> --- a/drivers/regulator/core.c
>>> +++ b/drivers/regulator/core.c
>>> @@ -3816,9 +3816,11 @@ int regulator_suspend_finish(void)
>>> list_for_each_entry(rdev, _list, list) {
>>> mutex_lock(>mutex);
>>> if (rdev->use_count > 0 || rdev->constraints->always_on) {
>>> - error = _regulator_do_enable(rdev);
>>> - if (error)
>>> - ret = error;
>>> + if (!_regulator_is_enabled(rdev)) {
>>
>> Looking at _regulator_enable() I see that _regulator_is_enabled()
>> could return an error. Should we be checking? Maybe we should have a
>> helper function called by both callers?
>>
>
> Thanks for pointing that out. I'll change it on v2 as well.
>
Looking at the code now I remember why I didn't checked for an error
in _regulator_is_enable(), sorry I wrote the patch months ago.
The thing is that _regulator_is_enabled() used to return -EINVAL if
the rdev didn't have an .is_enabled callback but that changed in
commit 9a7f6a4c6edc8 ("regulator: Assume regulators are enabled if
they don't report anything") and now returns 1 in that case. But
_regulator_enable() was not changed and is still checking for -EINVAL
which seems to me like a left over after the mentioned commit.
Also, _regulator_enable() is the only place that has a check for a
negative errno value returned by _regulator_is_enabled().
All other functions calling _regulator_is_enabled() seems to assume
that a return value != 0 means that the regulator is enabled.
Is true though that the rdev .is_enabled callback function may return
an error so I don't know if all those callers are missing a check or
if it's a design decision to assume that a regulator should be enabled
if the actual hardware state can't be obtained.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote: > >> - move module to appropriate location in kernel tree > > > > drivers/xen/ is the correct location for this driver. > > Hmm, so you regard placement of xen-netback under drivers/net and > xen-blkback under drivers/block as wrong? I've just followed these > examples. At least in the case of netback it really is just a normal Ethernet driver as far as the kernel is concerned. The fact it happens to talk to a virtual device doesn't matter. I don't know about other device types. Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/16] arch: x86: kernel: Add prototype for fixup_bad_iret in traps.c
traps.c defines the function fixup_bad_iret used in this file only
and in some assembly. No header file declares this function so,
add a prototype for fixup_bad_iret above the function definition.
This also satisfies the following gcc(-Wmissing-prototypes) warning:
arch/x86/kernel/traps.c:500:24: warning: no previous prototype for
‘fixup_bad_iret’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index fb4cb6a..ab015cd 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -497,6 +497,9 @@ struct bad_iret_stack {
};
asmlinkage __visible notrace
+struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s);
+
+asmlinkage __visible notrace
struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s)
{
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/16] arch: x86: xen: Mark internal functions static in setup.c
setup.c defines xen_pvmmu_arch_setup and xen_ignore_unusable
used only in this file. So mark them static.
This eliminates the following gcc warnings:
arch/x86/xen/setup.c:561:6: warning: no previous prototype for
‘xen_ignore_unusable’ [-Wmissing-prototypes]
arch/x86/xen/setup.c:831:13: warning: no previous prototype for
‘xen_pvmmu_arch_setup’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/xen/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 865e56c..2b3f935 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -558,7 +558,7 @@ static void xen_align_and_add_e820_region(u64 start, u64
size, int type)
e820_add_region(start, end - start, type);
}
-void xen_ignore_unusable(struct e820entry *list, size_t map_size)
+static void xen_ignore_unusable(struct e820entry *list, size_t map_size)
{
struct e820entry *entry;
unsigned int i;
@@ -828,7 +828,7 @@ void xen_enable_syscall(void)
#endif /* CONFIG_X86_64 */
}
-void __init xen_pvmmu_arch_setup(void)
+static void __init xen_pvmmu_arch_setup(void)
{
HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
HYPERVISOR_vm_assist(VMASST_CMD_enable,
VMASST_TYPE_writable_pagetables);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/16] arch: x86: xen: Add prototypes for functions defined in mmu.c
mmu.c defines the following functions: __visible pteval_t xen_pte_val(pte_t pte) __visible pgdval_t xen_pgd_val(pgd_t pgd) __visible pte_t xen_make_pte(pteval_t pte) __visible pgd_t xen_make_pgd(pgdval_t pgd) __visible pmdval_t xen_pmd_val(pmd_t pmd) __visible pmd_t xen_make_pmd(pmdval_t pmd) __visible pudval_t xen_pud_val(pud_t pud) __visible pud_t xen_make_pud(pudval_t pud) Include prototypes for these files in mmu.h since no header file declares them. This eliminates the following warnings: arch/x86/xen/mmu.c:410:20: warning: no previous prototype for ‘xen_pte_val’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:418:20: warning: no previous prototype for ‘xen_pgd_val’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:424:17: warning: no previous prototype for ‘xen_make_pte’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:432:17: warning: no previous prototype for ‘xen_make_pgd’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:439:20: warning: no previous prototype for ‘xen_pmd_val’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:498:17: warning: no previous prototype for ‘xen_make_pmd’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:506:20: warning: no previous prototype for ‘xen_pud_val’ [-Wmissing-prototypes] arch/x86/xen/mmu.c:512:17: warning: no previous prototype for ‘xen_make_pud’ [-Wmissing-prototypes] Signed-off-by: Darshana Padmadas --- arch/x86/xen/mmu.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h index 73809bb..d38126d 100644 --- a/arch/x86/xen/mmu.h +++ b/arch/x86/xen/mmu.h @@ -20,6 +20,14 @@ void xen_ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte); unsigned long xen_read_cr2_direct(void); +pteval_t xen_pte_val(pte_t pte); +pgdval_t xen_pgd_val(pgd_t pgd); +pte_t xen_make_pte(pteval_t pte); +pgd_t xen_make_pgd(pgdval_t pgd); +pmdval_t xen_pmd_val(pmd_t pmd); +pmd_t xen_make_pmd(pmdval_t pmd); +pudval_t xen_pud_val(pud_t pud); +pud_t xen_make_pud(pudval_t pud); extern void xen_init_mmu_ops(void); extern void xen_hvm_init_mmu_ops(void); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/16] arch: x86: xen: Add prototype for xen_start_kernel in enlighten.c
enlighten.c defines xen_start_kernel which is used only in this
file and is not defined in any header file. So add a proto-
type for the same above the function definition.
This satisfies the -Wmissing-prototypes gcc warning:
arch/x86/xen/enlighten.c:1534:34: warning: no previous prototype for
‘xen_start_kernel’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/xen/enlighten.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 78a881b..4061672 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1531,6 +1531,8 @@ static void __init xen_pvh_early_guest_init(void)
#endif/* CONFIG_XEN_PVH */
/* First C function to be called on Xen boot */
+asmlinkage __visible void __init xen_start_kernel(void);
+
asmlinkage __visible void __init xen_start_kernel(void)
{
struct physdev_set_iopl set_iopl;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/16] arch: x86: xen: Mark internal function xen_flush_tlb_all static.
xen_flush_tlb_all is defined only in mmu.c, so mark it static.
This eliminates the following gcc warning:
arch/x86/xen/mmu.c:1211:6: warning: no previous prototype for
‘xen_flush_tlb_all’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/xen/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5c1f9ac..14e2fc1 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1208,7 +1208,7 @@ unsigned long xen_read_cr2_direct(void)
return this_cpu_read(xen_vcpu_info.arch.cr2);
}
-void xen_flush_tlb_all(void)
+static void xen_flush_tlb_all(void)
{
struct mmuext_op *op;
struct multicall_space mcs;
--
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] bcma: Kconfig: Let it depend on PCI
On 4 March 2015 at 13:08, Rafał Miłecki wrote: > On 4 March 2015 at 07:19, Rafał Miłecki wrote: >> On 3 March 2015 at 22:16, Chen Gang wrote: >>> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI, >>> or will cause building break for allmodconfig under c6x: >>> >>> CC [M] drivers/bcma/driver_pcie2.o >>> drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': >>> drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of >>> function 'pcie_set_readrq' [-Werror=implicit-function-declaration] >>> err = pcie_set_readrq(dev, pcie2->reqsize); >>> ^ >>> >>> Signed-off-by: Chen Gang >>> --- >>> drivers/bcma/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig >>> index 0ee48be..8be284e 100644 >>> --- a/drivers/bcma/Kconfig >>> +++ b/drivers/bcma/Kconfig >>> @@ -1,6 +1,6 @@ >>> config BCMA_POSSIBLE >>> bool >>> - depends on HAS_IOMEM && HAS_DMA >>> + depends on HAS_IOMEM && HAS_DMA && PCI >>> default y >>> >>> menu "Broadcom specific AMBA" >>> -- >>> 1.9.3 >> >> Hm, I'm not sure how to ideally handle this. Cc-ing few ppl, maybe >> they have something to add. >> >> In fact there are SoCs (not using PCI host code obviously) with >> everything embedded (without any PCI host mode cores). So note >> following info about driver_pci.c and driver_pcie2.c: >> 1) For BCMA_HOST_PCI >> They are required, because of needed host-related PCI(e) core initialization. >> 2) For BCMA_HOST_SOC >> They are needed only if your SoC has PCI(e) host cores and you want to use >> them. >> >> So I guess in theory we could have BCMA_DRIVER_PCI and *require* it >> for BCMA_HOST_PCI only. > > After thinking about this. > We already have Kconfig entries for other internal drivers, so I guess > it makes sense to do the same for PCIe. I've just realized that implementing my idea (optional PCIe core drivers) will require reworking following functions: bcma_core_pci_irq_ctl bcma_core_pci_power_save bcma_core_pci_irq_ctl bcma_core_pci_init bcma_core_pcie2_init bcma_core_pci_early_init to make them safe to call ever without BCMA_DRIVER_PCI(E). To do that we should clean headers first, which is what I started doing in [PATCH next] bcma: move internal function declarations to private header So I think that for now we could just accept Chen's patch and then improve PCIe handling in bcma dropping this dependency at some point. Any other opinions? -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/16] arch: x86: kernel: Include for function prototype
process.c defines function __switch_to_xtra which has a prototype in arch/x86/include/asm/switch_to.h. Include this header file for function prototype for __switch_to_xtra. This eliminates the following warning: arch/x86/kernel/process.c:200:6: warning: no previous prototype for ‘__switch_to_xtra’ [-Wmissing-prototypes] Signed-off-by: Darshana Padmadas --- arch/x86/kernel/process.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index e127dda..1c77bc6 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -28,6 +28,7 @@ #include #include #include +#include /* * per-CPU TSS segments. Threads are completely 'soft' on Linux, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/16] arch: x86: kernel: Mark internal function EVT_TO_HPET_DEV static
hpet.c defines the function EVT_TO_HPET_DEV internally. No other
file defines this function. So make this function static.
This eliminates the following warning:
arch/x86/kernel/hpet.c:55:25: warning: no previous prototype for
‘EVT_TO_HPET_DEV’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 319bcb9..bdb9e8c 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -52,7 +52,7 @@ struct hpet_dev {
charname[10];
};
-inline struct hpet_dev *EVT_TO_HPET_DEV(struct clock_event_device *evtdev)
+static inline struct hpet_dev *EVT_TO_HPET_DEV(struct clock_event_device
*evtdev)
{
return container_of(evtdev, struct hpet_dev, evt);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/16] arch: x86: kernel: Add prototype for smp_reboot_interrupt
smp.c defines smp_reboot_interrupt used in this file and
in some assembly, so add a prototype for the same in smp.c
This eliminates the following warning:
arch/x86/kernel/smp.c:171:27: warning: no previous prototype for
‘smp_reboot_interrupt’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/smp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index be8e1bd..07e8dec 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -168,6 +168,8 @@ static int smp_stop_nmi_callback(unsigned int val, struct
pt_regs *regs)
* this function calls the 'stop' function on all other CPUs in the system.
*/
+asmlinkage __visible void smp_reboot_interrupt(void);
+
asmlinkage __visible void smp_reboot_interrupt(void)
{
ack_APIC_irq();
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/16] arch: x86: kernel: Mark internal functions static in kvm.c
kvm.c defines functions kvm_guest_cpu_init and kvm_init_debugfs
internally. No other file defines these, so make them static.
This also eliminates the following warnings:
arch/x86/kernel/kvm.c:334:6: warning: no previous prototype for
‘kvm_guest_cpu_init’ [-Wmissing-prototypes]
arch/x86/kernel/kvm.c:658:16: warning: no previous prototype for
‘kvm_init_debugfs’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/kvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 94f6434..484f869 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -331,7 +331,7 @@ static void kvm_guest_apic_eoi_write(u32 reg, u32 val)
apic_write(APIC_EOI, APIC_EOI_ACK);
}
-void kvm_guest_cpu_init(void)
+static void kvm_guest_cpu_init(void)
{
if (!kvm_para_available())
return;
@@ -655,7 +655,7 @@ static inline void spin_time_accum_blocked(u64 start)
static struct dentry *d_spin_debug;
static struct dentry *d_kvm_debug;
-struct dentry *kvm_init_debugfs(void)
+static struct dentry *kvm_init_debugfs(void)
{
d_kvm_debug = debugfs_create_dir("kvm-guest", NULL);
if (!d_kvm_debug)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/16] arch: x86: kernel: Add prototype for function sys32_x32_rt_sigreturn
signal.c defines the function sys32_x32_rt_sigreturn, which is
used in this file and some assembly. So add a prototype for the
function.
This eliminates the following warning:
arch/x86/kernel/signal.c:784:17: warning: no previous prototype for
‘sys32_x32_rt_sigreturn’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/signal.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 0a62df4..2625c23 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -781,6 +781,9 @@ void signal_fault(struct pt_regs *regs, void __user *frame,
char *where)
}
#ifdef CONFIG_X86_X32_ABI
+
+asmlinkage long sys32_x32_rt_sigreturn(void);
+
asmlinkage long sys32_x32_rt_sigreturn(void)
{
struct pt_regs *regs = current_pt_regs();
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/16] arch: x86: kernel: Make internal functions static in cpu/intel_cacheinfo.c
cpu/intel_cacheinfo.c defines two functions amd_get_l3_disable_slot
and amd_set_l3_disable_slot. No other file uses these functions.
So make these static.
This eliminates the following warnings:
arch/x86/kernel/cpu/intel_cacheinfo.c:349:5: warning: no previous prototype for
‘amd_get_l3_disable_slot’ [-Wmissing-prototypes]
arch/x86/kernel/cpu/intel_cacheinfo.c:427:5: warning: no previous prototype for
‘amd_set_l3_disable_slot’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 6596433..c5ab252 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -346,7 +346,7 @@ static void amd_init_l3_cache(struct _cpuid4_info_regs
*this_leaf, int index)
*
* @returns: the disabled index if used or negative value if slot free.
*/
-int amd_get_l3_disable_slot(struct amd_northbridge *nb, unsigned slot)
+static int amd_get_l3_disable_slot(struct amd_northbridge *nb, unsigned slot)
{
unsigned int reg = 0;
@@ -424,7 +424,7 @@ static void amd_l3_disable_index(struct amd_northbridge
*nb, int cpu,
*
* @return: 0 on success, error status on failure
*/
-int amd_set_l3_disable_slot(struct amd_northbridge *nb, int cpu, unsigned slot,
+static int amd_set_l3_disable_slot(struct amd_northbridge *nb, int cpu,
unsigned slot,
unsigned long index)
{
int ret = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/16] arch: x86: kernel: cpu: Mark function mce_chrdev_write static
cpu/mcheck/mce.c defines mce_chrdev_write. No other file
uses or defines this function, so make this static.
This eliminates the follwing warning:
arch/x86/kernel/cpu/mcheck/mce.c:1981:9: warning: no previous prototype for
‘mce_chrdev_write’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/kernel/cpu/mcheck/mce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 4c5cd75..b0c9ea7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1978,7 +1978,7 @@ void register_mce_write_callback(ssize_t (*fn)(struct
file *filp,
}
EXPORT_SYMBOL_GPL(register_mce_write_callback);
-ssize_t mce_chrdev_write(struct file *filp, const char __user *ubuf,
+static ssize_t mce_chrdev_write(struct file *filp, const char __user *ubuf,
size_t usize, loff_t *off)
{
if (mce_write)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/16] arch: x86: boot: Make function static and add function prototype
compressed/eboot.c defines an internal function
setup_graphics(struct boot_params *boot_params). No
other file refers to this function with the same
parameters so make this function static.
This eliminates the following warning:
arch/x86/boot/compressed/eboot.c:1004:6: warning: no previous prototype for
‘setup_graphics’ [-Wmissing-prototypes]
Also make_boot_params is declared only in this file and is used
in some assembly. So add a prototype for this function.
This eliminates the following warning:
arch/x86/boot/compressed/eboot.c:1042:21: warning: no previous prototype for
‘make_boot_params’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/boot/compressed/eboot.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 92b9a5f..cb4ebab 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1001,7 +1001,7 @@ free_handle:
return status;
}
-void setup_graphics(struct boot_params *boot_params)
+static void setup_graphics(struct boot_params *boot_params)
{
efi_guid_t graphics_proto = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
struct screen_info *si;
@@ -1039,6 +1039,9 @@ void setup_graphics(struct boot_params *boot_params)
* The caller is responsible for filling out ->code32_start in the
* returned boot_params.
*/
+
+struct boot_params *make_boot_params(struct efi_config *c);
+
struct boot_params *make_boot_params(struct efi_config *c)
{
struct boot_params *boot_params;
@@ -1378,6 +1381,10 @@ free_mem_map:
* On success we return a pointer to a boot_params structure, and NULL
* on failure.
*/
+
+struct boot_params *efi_main(struct efi_config *c,
+struct boot_params *boot_params);
+
struct boot_params *efi_main(struct efi_config *c,
struct boot_params *boot_params)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/16] Eliminate GCC -Wmissing-prototype warnings
GCC warns about functions without previous prototypes i.e -Wmissing-prototypes warnings. In the following patches the following fixes have been adopted to eliminate these warnings: - Functions defined in a file, that are internal to that file have been made static. - Header files have been included in files whose non-internal functions have their prototypes defined in these headers files. - Adding prototypes for several non-internal functions in the appropriate header file while keeping the structure definitions of the parameters used by the functions in mind. - Add the prototype above the function definition. These warnings can be generated by adding -Wmissing-prototypes to KBUILD_FLAGS in the top-level Makefile and then perform the build. Darshana Padmadas (16): arch: x86: boot: Make function static and add function prototype arch: x86: boot: Add prototype for decompress_kernel arch: x86: boot: Include header string.h for function prototypes arch: x86: ia32: Add prototype for compat_ni_syscall arch: x86: kernel: Make internal functions static in cpu/intel_cacheinfo.c arch: x86: kernel: cpu: Mark function mce_chrdev_write static arch: x86: kernel: Mark internal function EVT_TO_HPET_DEV static arch: x86: kernel: Mark internal functions static in kvm.c arch: x86: kernel: Include for function prototype arch: x86: kernel: Add prototype for function sys32_x32_rt_sigreturn arch: x86: kernel: Add prototype for smp_reboot_interrupt arch: x86: kernel: Add prototype for fixup_bad_iret in traps.c arch: x86: xen: Add prototype for xen_start_kernel in enlighten.c arch: x86: xen: Mark internal function xen_flush_tlb_all static. arch: x86: xen: Add prototypes for functions defined in mmu.c arch: x86: xen: Mark internal functions static in setup.c arch/x86/boot/compressed/eboot.c | 9 - arch/x86/boot/compressed/misc.c | 7 +++ arch/x86/boot/string.c| 1 + arch/x86/ia32/nosyscall.c | 2 ++ arch/x86/kernel/cpu/intel_cacheinfo.c | 4 ++-- arch/x86/kernel/cpu/mcheck/mce.c | 2 +- arch/x86/kernel/hpet.c| 2 +- arch/x86/kernel/kvm.c | 4 ++-- arch/x86/kernel/process.c | 1 + arch/x86/kernel/signal.c | 3 +++ arch/x86/kernel/smp.c | 2 ++ arch/x86/kernel/traps.c | 3 +++ arch/x86/xen/enlighten.c | 2 ++ arch/x86/xen/mmu.c| 2 +- arch/x86/xen/mmu.h| 8 arch/x86/xen/setup.c | 4 ++-- 16 files changed, 46 insertions(+), 10 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/16] arch: x86: boot: Include header string.h for function prototypes
Include header file string.h that declares prototypes for functions defined
in string.c.
This eliminates the following warnings:
arch/x86/boot/string.c:18:5: warning: no previous prototype for ‘memcmp’
[-Wmissing-prototypes]
arch/x86/boot/compressed/../string.c:18:5: warning: no previous prototype for
‘memcmp’ [-Wmissing-prototypes]
arch/x86/boot/compressed/string.c:18:7: warning: no previous prototype for
‘memcpy’ [-Wmissing-prototypes]
arch/x86/boot/compressed/string.c:33:7: warning: no previous prototype for
‘memset’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/boot/string.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 493f3fd..847f56c 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -14,6 +14,7 @@
#include
#include "ctype.h"
+#include "string.h"
int memcmp(const void *s1, const void *s2, size_t len)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/16] arch: x86: boot: Add prototype for decompress_kernel
compressed/misc.c declares internal function decompress_kernel
used only in this file and in some assembly. Add a prototype for
the function.
This eliminates the followig warning:
arch/x86/boot/compressed/misc.c:369:28: warning: no previous prototype for
‘decompress_kernel’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/boot/compressed/misc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index a950864..43bb537 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -371,6 +371,13 @@ asmlinkage __visible void *decompress_kernel(void *rmode,
memptr heap,
unsigned long input_len,
unsigned char *output,
unsigned long output_len,
+ unsigned long run_size);
+
+asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap,
+ unsigned char *input_data,
+ unsigned long input_len,
+ unsigned char *output,
+ unsigned long output_len,
unsigned long run_size)
{
unsigned char *output_orig = output;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/16] arch: x86: ia32: Add prototype for compat_ni_syscall
nosyscall.c declares function compat_ni_syscall that returns
long datatype. compat_ni_syscall is also defined in syscall_ia32.c
but returns void. Add prototype for this function.
This eliminates the following warning:
arch/x86/ia32/nosyscall.c:4:6: warning: no previous prototype for
‘compat_ni_syscall’ [-Wmissing-prototypes]
Signed-off-by: Darshana Padmadas
---
arch/x86/ia32/nosyscall.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/ia32/nosyscall.c b/arch/x86/ia32/nosyscall.c
index 51ecd5b..22f757b 100644
--- a/arch/x86/ia32/nosyscall.c
+++ b/arch/x86/ia32/nosyscall.c
@@ -1,6 +1,8 @@
#include
#include
+long compat_ni_syscall(void);
+
long compat_ni_syscall(void)
{
return -ENOSYS;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. 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 2/3] mailbox: dt: Supply bindings for ST's Mailbox IP
On 3 March 2015 at 16:11, Lee Jones wrote:
> Signed-off-by: Lee Jones
> ---
> .../devicetree/bindings/mailbox/sti-mailbox.txt| 66
> ++
> 1 file changed, 66 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> new file mode 100644
> index 000..c965c13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
> @@ -0,0 +1,66 @@
> +ST Microelectronics Mailbox Driver
> +
> +Required properties:
> +- compatible : Should be "st,stih407-mailbox"
> +- reg : Offset and length of the register set for the device
> +- reg-names: Should contain the reg name "mbox-reg".
> +- st,name : Name of the mailbox
> +- st,mbox-chans: Mbox/channels descriptor data private to
> each channel.
> + The 4 cells represent the following data:
> + Cell #1 (rx_id) - rx mbox num in an instance.
> + Cell #2 (rx_inst) - rx mbox instance num.
> + Cell #3 (tx_id) - tx mbox num in an instance.
> + Cell #4 (tx_inst) - tx mbox instance num.
> +
> + Note that an IP Mailbox is composed by 4 instances
> and
> + each instance is composed by 32 mailboxes.
> + You define here the configuration of a channel (at
> + framework level).
>
mbox-cells ?
> +
> +Optional properties
> +- st,mbox-rx : Indicaties if the mailbox can be used as Rx mailbox.
>
isn't this property implied by the presence of interrupts property,
and hence redundant?
> +- st,mbox-rx-id: If a Rx mailbox is affected to a Tx mailbox
> (to have
> + full-duplex channel), this field indiactes the Id of
> + the Rx mailbox to use.
> +- interrupts : Contains the IRQ line for a RX mailbox.
> +- interrupt-names : Should contain the interrupt name.
> +
> +Examples:
> +
> +mailbox0: mailbox@0 {
> + compatible = "st,stih407-mailbox";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #mbox-cells = <1>;
> + reg = <0x8f0 0x1000>;
> + reg-names = "mbox-reg";
> + interrupts = ;
> + interrupt-names = "mb0_irq";
> + st,name = "a9";
> + st,mbox-rx;
> + st,mbox-rx-id = <0>;
> + st,mbox-chans = <0 1 0 1>;
> +};
> +
> +mailbox3: mailbox@3 {
> + compatible = "st,stih407-mailbox";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #mbox-cells = <1>;
> + reg = <0x8f03000 0x100>;
> + reg-names = "mbox-reg";
> + st,name = "st231_video";
> + st,mbox-rx-id = <0>;
> + st,mbox-chans = <2 1 2 1>;
> +};
> +
> +In this configuration, if you use channel 0 you will have the following
> +configuration:
> +- "chan0_video" will use mailbox0 as Rx mailbox.
> +- "chan0_video" will use instance 1, bit 2 in mailbox0 for rx.
> +- "chan0_video" will use instance 1, bit 2 in mailbox3 for tx.
> +
> +If you declare a channel only for Rx, you have to set magic number 0xff
> +for tx_id and tx_instance.
> +If you declare a channel only for Tx, you have to set magic number 0xff
> +for rx_id and rx_instance.
>
some client node example would look great 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/
Re: [PATCH 3/3] mailbox: Add support for ST's Mailbox IP
On 3 March 2015 at 16:11, Lee Jones wrote:
> ---
> drivers/mailbox/Kconfig | 7 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mailbox-sti.c | 664
> ++
> include/linux/mailbox_sti.h | 128
>
How about the header in include/linux/soc/sti/ away from the limelight?
> + */
> +#define MBOX_HW_MAX5
> +#define MBOX_NO_RX 0xff
> +
> +static struct sti_mbox_device mdev_rxs[MBOX_HW_MAX];
> +
> +static DEFINE_SPINLOCK(sti_mbox_irqs_lock);
> +
> +/* Mailbox H/W preparations */
> +static struct irq_chip sti_mbox_irq_chip;
> +
> +static inline bool sti_mbox_chan_is_rx(struct sti_mbox_dev_data *mbox)
> +{
> + return ((mbox->rx_id != MBOX_NO_RX) && (mbox->rx_inst != MBOX_NO_RX));
> +}
> +
> +static inline bool sti_mbox_chan_is_tx(struct sti_mbox_dev_data *mbox)
> +{
> + return ((mbox->tx_id != MBOX_NO_RX) && (mbox->tx_inst != MBOX_NO_RX));
>
nit: something neutral like MBOX_ABSENT or anything without RX?
> +/* Message management */
> +static void sti_mbox_read(struct sti_mbox_dev_data *mbox,
> + struct sti_mbox_msg *msg)
> +{
> + struct sti_mbox_data *md = >mdata;
> + void __iomem *hdr = md->rx_addr;
> +
> + /* Read data payload */
> + msg->dsize = readb(hdr);
> + msg->pdata = (u8*)++hdr;
> +}
> +
> +static void sti_mbox_write(struct sti_mbox_dev_data *mbox, void *data)
> +{
> + struct sti_mbox_data *md = >mdata;
> + struct sti_mbox_msg *msg = (struct sti_mbox_msg *)data;
> + u32 len = msg->dsize;
> + void __iomem *hdr;
> + u8 *wrb;
> + unsigned int j;
> +
> + hdr = md->tx_addr;
> +
> + /* Payload size */
> + writeb((u8)len, hdr);
>
So the first 1byte bitfield is the 'size' of the packset. could you
please get rid of sti_mbox_msg.dsize?
> +
> + wrb = msg->pdata;
> + if (!wrb)
> + return;
> +
> + /* Payload data */
> + for (j = 0, hdr++; j < len; j++, wrb++, hdr++)
> + writeb(*wrb, hdr);
> +}
> +
> +/* Mailbox IRQ handle functions */
> +static void sti_mbox_enable_irq(struct sti_mbox_instance *mbinst, u32 msk)
> +{
> + struct sti_mbox_device *mdev = mbinst->parent;
> + struct sti_mbox_attribute *p = mdev->cfg;
> + void __iomem *base;
> + unsigned long flags;
> +
> + base = mdev->mdev_rx->mbox_reg_base + (mbinst->id * p->num_inst);
> + spin_lock_irqsave(_mbox_irqs_lock, flags);
> + mbinst->irq_msk |= msk;
> +
> + writel_relaxed(msk, base + p->reg_ena_set);
> +
> + spin_unlock_irqrestore(_mbox_irqs_lock, flags);
> +}
> +
> +static void sti_mbox_disable_irq(struct sti_mbox_instance *mbinst, u32 msk)
> +{
> + struct sti_mbox_device *mdev = mbinst->parent;
> + struct sti_mbox_attribute *p = mdev->cfg;
> + void __iomem *base;
> + unsigned long flags;
> +
> + base = mdev->mdev_rx->mbox_reg_base + (mbinst->id * p->num_inst);
> + spin_lock_irqsave(_mbox_irqs_lock, flags);
> + mbinst->irq_msk &= ~msk;
> + writel_relaxed(msk, base + p->reg_ena_clr);
> + spin_unlock_irqrestore(_mbox_irqs_lock, flags);
> +}
> +
> +static void sti_mbox_clr_irq(struct sti_mbox_instance *mbinst, u32 msk)
> +{
> + struct sti_mbox_device *mdev = mbinst->parent;
> + struct sti_mbox_attribute *p = mdev->cfg;
> + void __iomem *base;
> +
> + base = mdev->mdev_rx->mbox_reg_base + (mbinst->id * p->num_inst);
> + writel_relaxed(msk, base + p->reg_clr);
> +}
> +
> +static irqreturn_t sti_mbox_thread_interrupt(int irq, void *data)
> +{
> + struct mbox_chan *chan = data;
> + struct sti_mbox_dev_data *mbox = chan->con_priv;
> + struct sti_mbox_device *mdev_rx = mbox->parent->mdev_rx;
> +
> + mbox_chan_received_data(chan, (void *)mbox->msg);
> + sti_mbox_enable_irq(mdev_rx->mbinst[mbox->rx_inst], BIT(mbox->rx_id));
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t sti_mbox_interrupt(int irq, void *data)
> +{
> + struct mbox_chan *chan = data;
> + struct sti_mbox_dev_data *mbox = chan->con_priv;
> + struct sti_mbox_data *md = >mdata;
> + struct sti_mbox_device *mdev_rx = mbox->parent->mdev_rx;
> +
> + sti_mbox_disable_irq(mdev_rx->mbinst[mbox->rx_inst],
> BIT(mbox->rx_id));
> +
> + if (md->rx_addr != NULL)
> + sti_mbox_read(mbox, mbox->msg);
> +
> + return IRQ_WAKE_THREAD;
> +}
> +
> +
> +static irqreturn_t sti_mbox_irq_handler(int irq, void *data)
> +{
> + struct sti_mbox_device *mdev_rx = data;
> + struct sti_mbox_attribute *p = mdev_rx->cfg;
> + struct irq_domain *mbox_irq_domain;
> + void __iomem *base;
> + u32 irq_chan;
> + unsigned long bits = 0;
> + u8 n;
> + int i;
> +
> + base = mdev_rx->mbox_reg_base + mdev_rx->cfg->reg_val;
> +
> + for (i = 0; i < p->num_inst; i++) {
> + bits
[PATCH v6] arm: perf: Directly handle SMP platforms with one SPI
Some ARM platforms mux the PMU interrupt of every core into a single
SPI. On such platforms if the PMU of any core except 0 raises an interrupt
then it cannot be serviced and eventually, if you are lucky, the spurious
irq detection might forcefully disable the interrupt.
On these SoCs it is not possible to determine which core raised the
interrupt so workaround this issue by queuing irqwork on the other
cores whenever the primary interrupt handler is unable to service the
interrupt.
The u8500 platform has an alternative workaround that dynamically alters
the affinity of the PMU interrupt. This workaround logic is no longer
required so the original code is removed as is the hook it relied upon.
Tested on imx6q (which has fours cores/PMUs all muxed to a single SPI)
using a simple soak, combined perf and CPU hotplug soak and using
perf fuzzer's fast_repro.sh.
Signed-off-by: Daniel Thompson
---
Notes:
v2 was tested on u8500 (thanks to Linus Walleij). The latest patch
doesn't change the nature of the workaround itself but there has been
substantial churn in the logic to decide when it can safely be deployed.
Thus the changes were sufficient for me not to
preserve the Tested-By:.
v6:
* Redesigned the code that decides if it is safe to deploy the
workaround (acting on the review by Mark Rutland). Code should no
longer race during hot unplug; previous patches sought to make the
hot unplug race benign and the old approach had flaws and even if
it could be made correct was tortuously hard to review.
v5:
* Removed the work queue nonsense; being completely race-free requires
us to take a mutex or avoid dispatch from interrupt (Will Deacon).
Replacement code can potentially race with a CPU hot unplug however
it is careful to minimise exposure, to mitigate harmful effects and
has fairly prominent comments.
v4:
* Ripped out the logic that tried to preserve the operation of the
spurious interrupt detector. It was complex and not really needed
(Will Deacon).
* Removed a redundant memory barrier and added a comment explaining
why it is not needed (Will Deacon).
* Made fully safe w.r.t. hotplug by falling back to a work queue
if there is a hotplug operation in flight when the PMU interrupt
comes in (Will Deacon). The work queue code paths have been tested
synthetically (by changing the if condition).
* Posted the correct, as in compilable and tested, version of the code
(Will Deacon).
v3:
* Removed function pointer indirection when deploying workaround code
and reorganise the code accordingly (Mark Rutland).
* Move the workaround state tracking into the existing percpu data
structure (Mark Rutland).
* Renamed cret to percpu_ret and rewrote the comment describing the
purpose of this variable (Mark Rutland).
* Copy the cpu_online_mask and use that to act on a consistent set of
cpus throughout the workaround (Mark Rutland).
* Changed "single_irq" to "muxed_spi" to more explicitly describe
the problem.
v2:
* Fixed build problems on systems without SMP.
v1:
* Thanks to Lucas Stach, Russell King and Thomas Gleixner for
critiquing an older, completely different way to tackle the
same problem.
arch/arm/include/asm/pmu.h | 12 +++
arch/arm/kernel/perf_event.c | 9 +-
arch/arm/kernel/perf_event_cpu.c | 179 +++
arch/arm/kernel/perf_event_v7.c | 2 +-
arch/arm/mach-ux500/cpu-db8500.c | 29 ---
5 files changed, 178 insertions(+), 53 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b1596bd59129..dfef7904b790 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -87,6 +87,14 @@ struct pmu_hw_events {
* already have to allocate this struct per cpu.
*/
struct arm_pmu *percpu_pmu;
+
+#ifdef CONFIG_SMP
+ /*
+* This is used to schedule workaround logic on platforms where all
+* the PMUs are attached to a single SPI.
+*/
+ struct irq_work work;
+#endif
};
struct arm_pmu {
@@ -117,6 +125,10 @@ struct arm_pmu {
struct platform_device *plat_device;
struct pmu_hw_events__percpu *hw_events;
struct notifier_block hotplug_nb;
+#ifdef CONFIG_SMP
+ int muxed_spi_workaround_irq;
+ atomic_tremaining_irq_work;
+#endif
};
#define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 557e128e4df0..e3fc1a0ce969 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -305,8 +305,6 @@ validate_group(struct perf_event *event)
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
Re: [PATCHv3 04/24] rmap: add argument to charge compound page
On Wed, Mar 04, 2015 at 01:09:51PM +0100, Vlastimil Babka wrote:
> On 03/04/2015 12:52 PM, Kirill A. Shutemov wrote:
> >On Mon, Feb 23, 2015 at 05:21:31PM +0100, Vlastimil Babka wrote:
> >>On 02/12/2015 05:18 PM, Kirill A. Shutemov wrote:
> >>>@@ -1052,21 +1052,24 @@ void page_add_anon_rmap(struct page *page,
> >>> * Everybody else should continue to use page_add_anon_rmap above.
> >>> */
> >>> void do_page_add_anon_rmap(struct page *page,
> >>>- struct vm_area_struct *vma, unsigned long address, int exclusive)
> >>>+ struct vm_area_struct *vma, unsigned long address, int flags)
> >>> {
> >>> int first = atomic_inc_and_test(>_mapcount);
> >>> if (first) {
> >>>+ bool compound = flags & RMAP_COMPOUND;
> >>>+ int nr = compound ? hpage_nr_pages(page) : 1;
> >>
> >>hpage_nr_pages(page) is:
> >>
> >>static inline int hpage_nr_pages(struct page *page)
> >>{
> >> if (unlikely(PageTransHuge(page)))
> >> return HPAGE_PMD_NR;
> >> return 1;
> >>}
> >>
> >>and later...
> >>
> >>> /*
> >>>* We use the irq-unsafe __{inc|mod}_zone_page_stat because
> >>>* these counters are not modified in interrupt context, and
> >>>* pte lock(a spinlock) is held, which implies preemption
> >>>* disabled.
> >>>*/
> >>>- if (PageTransHuge(page))
> >>>+ if (compound) {
> >>>+ VM_BUG_ON_PAGE(!PageTransHuge(page), page);
> >>
> >>this means that we could assume that
> >>(compound == true) => (PageTransHuge(page) == true)
> >>
> >>and simplify above to:
> >>
> >>int nr = compound ? HPAGE_PMD_NR : 1;
> >>
> >>Right?
> >
> >No. HPAGE_PMD_NR is defined based on HPAGE_PMD_SHIFT which is BUILD_BUG()
> >without CONFIG_TRANSPARENT_HUGEPAGE. We will get compiler error without
> >the helper.
>
> Oh, OK. But that doesn't mean there couldn't be another helper that would
> work in this case, or even open-coded #ifdefs in these functions. Apparently
> "compound" has to be always false for !CONFIG_TRANSPARENT_HUGEPAGE, as in
> that case PageTransHuge is defined as 0 and the VM_BUG_ON would trigger if
> compound was true. So without such ifdefs or wrappers, you are also adding
> dead code and pointless tests for !CONFIG_TRANSPARENT_HUGEPAGE?
Yeah, this definitely can be improved. I prefer to do it as follow up.
I want to get stable what I have now.
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RFC: sysctl fixes
Hello, we are running hundreds of containers and we got some valid requests from customers that want to be able to change their container's hostname using the sysctl command. The current implementation does not allow each UTS namespace to change its own hostname. So we sponsored the development of fix for this issue. Please checkout the changes here: https://github.com/1HLtd/linux/compare/b24e2bdde4af656bb0679a101265ebb8f8735d3c...sysctl-hostname-fixes If this fix is acceptable I'll send the patches as it is common. But first I want to know if you think this is the way to go. Thank you, Marian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
select on undefined THERMAL_POWER_ACTOR
Hi Javi,
your commit 8754d5115693 ("thermal: introduce the Power Allocator
governor") is included in today's linux-next tree (i.e.,
next-20150304).
This patch adds a select on the Kconfig symbol THERMAL_POWER_ACTOR.
However, THERMAL_POWER_ACTOR is not defined so that this select is a
NOOP.
@@ -99,6 +107,13 @@ config THERMAL_GOV_USER_SPACE
help
Enable this to let the user space manage the platform thermals.
+config THERMAL_GOV_POWER_ALLOCATOR
+ bool "Power allocator thermal governor"
+ select THERMAL_POWER_ACTOR
Is there a patch queued somewhere that adds this Kconfig symbol? I
detected the issue by running undertaker-checkpatch from the
Undertaker tool suite (undertaker.cs.fau.de).
Kind regards,
Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Synchronization mechanism between wait_for_completion_interruptible_timeout() & complete()
Hello, I have a question regarding the synchronization mechanism between wait_for_completion_interruptible_timeout() & complete(). I used complete() API in the ISR Tx interrupt path and wait_for_completion_interruptible_timeout() in struct file_operations .write method. Let assume a scenario in which Tx interrupt occurred and ISR called complete() API before any process actually blocked at write method on wait_for_completion_interruptible_timeout(). After a few milli seconds, a process called write() API. Does it gets blocked on wait_for_completion_interruptible_timeout() for completion of a specific task to be signaled from new Tx interrupt? Thanks, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] livepatch: fix patched module loading race
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
> It's possible for klp_register_patch() to see a module before the COMING
> notifier is called, or after the GOING notifier is called.
>
> That can cause all kinds of ugly races. As Pter Mladek reported:
>
> "The problem is that we do not keep the klp_mutex lock all the time when
> the module is being added or removed.
>
> First, the module is visible even before ftrace is ready. If we enable a
> patch
> in this time frame, adding ftrace ops will fail and the patch will get
> rejected
> just because bad timing.
Ah, this is not true after all. I did not properly check when
MODULE_STATE_COMING was set. I though that it was before ftrace was
initialized but it was not true.
> Second, if we are "lucky" and enable the patch for the coming module when
> the
> ftrace is ready but before the module notifier has been called. The notifier
> will try to enable the patch as well. It will detect that it is already
> patched,
> return error, and the module will get rejected just because bad
> timing. The more serious problem is that it will not call the notifier for
> going module, so that the mess will stay there and we wont be able to load
> the module later.
Ah, the race is there but the effect is not that serious in the
end. It seems that errors from module notifiers are ignored. In fact,
we do not propagate the error from klp_module_notify_coming(). It means
that WARN() from klp_enable_object() will be printed but the module
will be loaded and patched.
I am sorry, I was confused by kGraft where kgr_module_init() was
called directly from module_load(). The errors were propagated. It
means that kGraft rejects module when the patch cannot be applied.
Note that the current solution is perfectly fine for the simple
consistency model.
> Third, similar problems are there for going module. If a patch is enabled
> after
> the notifier finishes but before the module is removed from the list of
> modules,
> the new patch will be applied to the module. The module might disappear at
> anytime when the patch enabling is in progress, so there might be an access
> out
> of memory. Or the whole patch might be applied and some mess will be left,
> so it will not be possible to load/patch the module again."
This is true.
> Fix these races by letting the first one who sees the module do the
> needed work.
>
> Reported-by: Petr Mladek
> Signed-off-by: Josh Poimboeuf
> ---
> kernel/livepatch/core.c | 53
> +
> 1 file changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index a74e4e8..19a758c 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -89,16 +89,42 @@ static bool klp_is_object_loaded(struct klp_object *obj)
> /* sets obj->mod if object is not vmlinux and module is found */
> static void klp_find_object_module(struct klp_object *obj)
> {
> + struct module *mod;
> +
> if (!klp_is_module(obj))
> return;
>
> mutex_lock(_mutex);
> +
> /*
>* We don't need to take a reference on the module here because we have
>* the klp_mutex, which is also taken by the module notifier. This
>* prevents any module from unloading until we release the klp_mutex.
>*/
> - obj->mod = find_module(obj->name);
> + mod = find_module(obj->name);
> +
> + /*
> + * Be careful here to prevent races with the notifier:
> + *
> + * - MODULE_STATE_COMING: This may be before or after the notifier gets
> + * called. If after, the notifier didn't see the object anyway
> + * because it hadn't been added to the patch list yet. Either way,
> + * ftrace is already initialized, so it's safe to just go ahead and
> + * initialize the object here.
Well, we need to be careful. This will handle only the newly
registered patch. If there are other patches against the module
on the stack, it might produce wrong order at func_stack, see below.
> + *
> + * - MODULE_STATE_GOING: Similar to MODULE_STATE_COMING, this may be
> + * before or after the notifier gets called. If after, the notifer
> + * didn't see the object anyway. Either way it's safe to just
> + * pretend that it's already gone and leave obj->mod at NULL.
This is true for the current simple consistency model.
Note that there will be a small race window if we allow dependency
between patched functions and introduce more a complex consistency model
with lazy patching. The problem is the following sequence:
CPU0CPU1
delete_module() #SYSCALL
try_stop_module()
mod->state = MODULE_STATE_GOING;
mutex_unlock(_mutex);
klp_register_patch()
klp_enable_patch()
[PATCH] virtio_balloon: set DRIVER_OK before using device
virtio spec requires that all drivers set DRIVER_OK
before using devices. While balloon isn't yet
included in the virtio 1 spec, previous spec versions
also required this.
virtio balloon might violate this rule: probe calls
kthread_run before setting DRIVER_OK, which might run
immediately and cause balloon to inflate/deflate.
To fix, call virtio_device_ready before running the kthread.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_balloon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 5a6ad6d..6a356e3 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -508,6 +508,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
if (err < 0)
goto out_oom_notify;
+ virtio_device_ready(vdev);
+
vb->thread = kthread_run(balloon, vb, "vballoon");
if (IS_ERR(vb->thread)) {
err = PTR_ERR(vb->thread);
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] ARM: at91: dt: at91sam9n12ek: enable udp device
Le 02/03/2015 10:32, Bo Shen a écrit : > Hi Nicolas, > > On 02/10/2015 09:55 AM, Bo Shen wrote: >> This patch series enable usb device support on at91sam9n12ek board. >> >> Changes in v2: >>- Base on next-20150209 (so, remove the modification of udc driver). >>- Add pinctrl for usb1 vbus sense. >> >> Bo Shen (2): >>ARM: at91: dt: at91sam9n12: add udp device node >>ARM: at91: dt: at91sam9n12ek: enable udp > > Any comments for this patch series? (aka ping?) Hi, For the 2 patches: Acked-by: Nicolas Ferre And I've just taken these 2 patches on top of the at91-4.1-dt branch. Thanks for the "heads up" ! Bye, >> arch/arm/boot/dts/at91sam9n12.dtsi | 9 + >> arch/arm/boot/dts/at91sam9n12ek.dts | 14 ++ >> 2 files changed, 23 insertions(+) >> > > Best Regards, > Bo Shen > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ASoC]fsl_ssi: fix of_property_read_u32_array return value check
W dniu 24.02.2015 09:24, Mark Brown pisze: > On Sun, Feb 15, 2015 at 11:11:43PM +0100, Maciej S. Szmigiero wrote: >> of_property_read_u32_array returns 0 on success, so the return value >> shouldn't be inverted twice, >> first on assignment then in condition expression. > > This doesn't apply to current code, please check and resend. Please > also keep your changelog under 80 columns as covered in > SubmittingPatches. > Thanks for looking into it, Against which tree/branch patches for ASoC should be generated? Best regards, Maciej Szmigiero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 XIA - merge proposal
On 03/04/2015 12:49 AM, Greg KH wrote: On Tue, Mar 03, 2015 at 07:31:58PM -0500, Michel Machado wrote: Hi Daniel, We're fine with clearly marking Linux XIA as being under staging as well as helping to define this review process for network stacks. With regard to staging, the code there is usually horrible and I'm not sure anyone really looks there, that would mitigate the review problem to the time when you try to get it out from there, so I'm not sure it brings anything. ;) I suggested staging as a way to incrementally review the code. Yet you failed to at least ask the maintainer of the staging portion of the kernel, if this is a valid use of staging, and his resources... Not nice :( greg k-h Hi Greg, I am sorry for having not asked you. Given that the staging process doesn't include network stacks, I'd thought that the correct way to go would be to bring the discussion to netdev first. Please understand that I'm not gaming, I'm just following my best understanding of the documentation of how to submit code. I'm really in uncharted waters here since all my accepted patches are tiny. In addition, I intend to work on the feedback I get. I'm not planning to have the code upstream and run away. [ ]'s Michel Machado -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] gpio: add parameter to allow the use named gpios
On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl wrote: > From: Olliver Schinagl > > The gpio binding document says that new code should always use named > gpios. Patch 40b73183 added support to parse a list of gpios from child > nodes, but does not make it possible to use named gpios. This patch adds > the con_id property and implements it is done in gpiolib.c, where the > old-style of using unnamed gpios still works. > > Signed-off-by: Olliver Schinagl Patch applied with the ACKs and tags. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: nomadik: match status to return type of read_i2c
On Sun, Feb 8, 2015 at 1:34 PM, Nicholas Mc Guire wrote: > return type of read_i2c() is int not u32. As the assignments to status > are consistent with int here its type is changed to int. > > Signed-off-by: Nicholas Mc Guire Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: Add support for NAU8824 codec to ASoC
On Wed, Mar 04, 2015 at 08:35:52PM +0800, Chih-Chiang Chang wrote:
> On 2015/2/24 下午 10:13, Mark Brown wrote:
> > I would have expected the headphone volume control to be a stereo
> > (double) control - same for speakers.
> The nau8824 related registers which control left/right volume are located
> in different addresses and different shift bits. Since there is no available
> preprocessor macro to meet our requirements, the driver consists of left/right
> volume control separately.
Add relevant control types if you need them, it's important to have
proper stereo controls available to userspace.
> >> +struct nau8824_init_reg {
> >> +u8 reg;
> >> +u16 val;
> >> +};
> > This looks like you're reimplementing regmap's register sequence
> > stuff... It's also a *very* large sequence you have, are you sure it's
> > all required? It seems like this may be doing a bunch of machine
> > specific configuration but since it's all magic numbers it's hard to
> > tell.
> Initial settings are arranged in order
This doesn't answer or address my concern.
> >> +/* Dynamic Headset detection enabled */
> >> +snd_soc_update_bits(codec, 0x01, 0x400, 0x400);
> >> +snd_soc_update_bits(codec, 0x02, 0x0008, 0x0008);
> >> +snd_soc_update_bits(codec, 0x0f, 0x0300, 0x0100);
> >> +snd_soc_write(codec, 0x09, 0xE000);
> >> +snd_soc_write(codec, NAU8824_IRQ_SETTING, 0x1006);
> >> +snd_soc_write(codec, 0x13, 0x1615);
> >> +snd_soc_write(codec, 0x15, 0x0414);
> >> +snd_soc_update_bits(codec, 0x16, 0xFF00, 0x5900);
> >> +snd_soc_update_bits(codec, 0x66, 0x0070, 0x0060);
> > Too many magic numbers here I think and this looks like it should be
> > configured using platform data and/or the machine driver (what if the
> > headphone detection/IRQ aren't wired up?). I'd also expect to see
> > reporting via the standard interfaces for jack reporting.
> The above initial settings are for jack detection. As for other jack
> detection flow, it will be implemented in machine driver but not be included
> in
> this application.
Please either remove this for now or implement it properly.
> ===
> The privileged confidential information contained in this email is intended
> for use only by the addressees as indicated by the original sender of this
> email. If you are not the addressee indicated in this email or are not
> responsible for delivery of the email to such a person, please kindly reply
> to the sender indicating this fact and delete all copies of it from your
> computer and network server immediately. Your cooperation is highly
> appreciated. It is advised that any unauthorized use of confidential
> information of Nuvoton is strictly prohibited; and any information in this
> email irrelevant to the official business of Nuvoton shall be deemed as
> neither given nor endorsed by Nuvoton.
Don't include noise like this in upstream communication, if your company
won't fix this then please use an external mail account for upstream
communication.
signature.asc
Description: Digital signature
Re: [PATCH 1/2] i2c: nomadik: match return type of wait_for_completion_timeout
On Sun, Feb 8, 2015 at 1:34 PM, Nicholas Mc Guire wrote: > return type of wait_for_completion_timeout is unsigned long not int. as > timeout is used for wait_for_completion_timeout exclusively here its > type is simply changed to unsigned long. > > Signed-off-by: Nicholas Mc Guire Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFT] phy: exynos-mipi-video: Use spin_lock to protct state->regmap rmw operations
On Wednesday 04 March 2015 06:17 PM, Sylwester Nawrocki wrote: Hi, On 04/03/15 13:24, Kishon Vijay Abraham I wrote: This patch doesn't apply on 4.0-rc1. Can to refresh it to mainline latest? It depends on Axel's previous patch: "phy: exynos-mipi-video: Fixup the test for state->regmap". Are there any issues even with that patch applied ? no. okay I'll apply in that order. Cheers kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: Add support for NAU8824 codec to ASoC
>From fe37688e226f83ba477a3c2fbc1e64946cd4ec4e Mon Sep 17 00:00:00 2001
From: Chih-Chiang Chang
Date: Wed, 4 Mar 2015 20:03:21 +0800
Subject: [PATCH v2] ASoC: Add support for NAU8824 codec to ASoC
Signed-off-by: Chih-Chiang Chang
---
include/sound/nau8824.h| 22 ++
sound/soc/codecs/Kconfig | 5 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/nau8824.c | 807 +
sound/soc/codecs/nau8824.h | 380 +
5 files changed, 1216 insertions(+)
create mode 100644 include/sound/nau8824.h
create mode 100644 sound/soc/codecs/nau8824.c
create mode 100644 sound/soc/codecs/nau8824.h
diff --git a/include/sound/nau8824.h b/include/sound/nau8824.h
new file mode 100644
index 000..edb5f08
--- /dev/null
+++ b/include/sound/nau8824.h
@@ -0,0 +1,22 @@
+/*
+ * linux/sound/nau8824.h -- Platform data for NAU8824
+ *
+ * Copyright 2015 Nuvoton Technology Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_SND_NAU8824_H
+#define __LINUX_SND_NAU8824_H
+
+struct nau8824_platform_data {
+ unsigned int audio_mclk1;
+ unsigned int gpio_irq;
+ int naudint_irq;
+ int headset_detect;
+ int button_press_detect;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 064e6c1..862b7bd 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -75,6 +75,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX9877 if I2C
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
+ select SND_SOC_NAU8824 if I2C
select SND_SOC_HDMI_CODEC
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM1792A if SPI_MASTER
@@ -463,6 +464,10 @@ config SND_SOC_MAX98357A
config SND_SOC_MAX9850
tristate
+config SND_SOC_NAU8824
+ tristate "Nuvoton NAU8824 CODEC"
+ depends on I2C
+
config SND_SOC_PCM1681
tristate "Texas Instruments PCM1681 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 69b8666..acb7bda 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -68,6 +68,7 @@ snd-soc-max98357a-objs := max98357a.o
snd-soc-max9850-objs := max9850.o
snd-soc-mc13783-objs := mc13783.o
snd-soc-ml26124-objs := ml26124.o
+snd-soc-nau8824-objs := nau8824.o
snd-soc-hdmi-codec-objs := hdmi.o
snd-soc-pcm1681-objs := pcm1681.o
snd-soc-pcm1792a-codec-objs := pcm1792a.o
@@ -250,6 +251,7 @@ obj-$(CONFIG_SND_SOC_MAX98357A) += snd-soc-max98357a.o
obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
obj-$(CONFIG_SND_SOC_MC13783) += snd-soc-mc13783.o
obj-$(CONFIG_SND_SOC_ML26124) += snd-soc-ml26124.o
+obj-$(CONFIG_SND_SOC_NAU8824) += snd-soc-nau8824.o
obj-$(CONFIG_SND_SOC_HDMI_CODEC) += snd-soc-hdmi-codec.o
obj-$(CONFIG_SND_SOC_PCM1681) += snd-soc-pcm1681.o
obj-$(CONFIG_SND_SOC_PCM1792A) += snd-soc-pcm1792a-codec.o
diff --git a/sound/soc/codecs/nau8824.c b/sound/soc/codecs/nau8824.c
new file mode 100644
index 000..8a19b77
--- /dev/null
+++ b/sound/soc/codecs/nau8824.c
@@ -0,0 +1,807 @@
+/*
+ * linux/sound/soc/codecs/nau8824.c
+ *
+ * Copyright 2015 Nuvoton Technology Corp.
+ * Author: Meng-Huang Kuo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "nau8824.h"
+
+static int nau8824_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai);
+static int nau8824_set_dai_fmt(struct snd_soc_dai *codec_dai,
+ unsigned int fmt);
+static int nau8824_set_bias_level(struct snd_soc_codec *codec,
+ enum snd_soc_bias_level level);
+static int nau8824_dai_set_sysclk(struct snd_soc_dai *dai, int clk_id,
+ unsigned int freq, int dir);
+static const DECLARE_TLV_DB_SCALE(out_spk_vol_tlv, 0, 100, 0);
+static const DECLARE_TLV_DB_SCALE(out_hp_vol_tlv, -3000, 100, 0);
+static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -12800, 50, 0);
+static const DECLARE_TLV_DB_SCALE(in_vol_tlv, -3450, 150, 0);
+static const DECLARE_TLV_DB_SCALE(adc_vol_tlv, -12800, 50, 0);
+static const DECLARE_TLV_DB_SCALE(adc_left_vol_tlv, -12750, 50, 1);
+static const DECLARE_TLV_DB_SCALE(adc_right_vol_tlv, -12750, 50, 1);
+
+static const struct snd_kcontrol_new nau8824_snd_controls[] = {
+ /* SP Class-D mute control */
+ SOC_DOUBLE("SP Playback
Re: [PATCH 3.18 129/151] x86/xen: Treat SCI interrupt as normal GSI interrupt
On 04.03.2015 07:14, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
I thought I replied earlier today but I cannot seem to find it coming back via
the mailing list. Hope this is not duplicating too much... There was a
regression with that patch and it requires the below commit as well to prevent
that:
commit 1ea76fbadd667b19c4fa4466f3a3b55a505e83d9
Author: Jiang Liu
Date: Mon Feb 16 10:11:13 2015 +0800
x86/irq: Fix regression caused by commit b568b8601f05
Commit b568b8601f05 ("Treat SCI interrupt as normal GSI interrupt")
accidently removes support of legacy PIC interrupt when fixing a
regression for Xen, which causes a nasty regression on HP/Compaq
nc6000 where we fail to register the ACPI interrupt, and thus
lose eg. thermal notifications leading a potentially overheated
machine.
-Stefan
>
> --
>
> From: Jiang Liu
>
> commit b568b8601f05a591a7ff09d8ee1cedb5b2e815fe upstream.
>
> Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
> that is initialize irq for ACPI SCI at early stage in a special way as:
> xen_init_IRQ()
> ->pci_xen_initial_domain()
> ->xen_setup_acpi_sci()
> Allocate and initialize irq for ACPI SCI
>
> Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
> number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
> IOAPIC irqdomains through following path
> acpi_gsi_to_irq()
> ->mp_map_gsi_to_irq()
> ->mp_map_pin_to_irq()
> ->check IOAPIC irqdomain
>
> For PV domains, it uses Xen event based interrupt manangement and
> doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC.
> This causes Xen domain0 fail to install interrupt handler for ACPI SCI
> and all ACPI events will be lost. Please refer to:
> https://lkml.org/lkml/2014/12/19/178
>
> So the fix is to get rid of special treatment for ACPI SCI, just treat
> ACPI SCI as normal GSI interrupt as:
> acpi_gsi_to_irq()
> ->acpi_register_gsi()
> ->acpi_register_gsi_xen()
> ->xen_register_gsi()
>
> With above change, there's no need for xen_setup_acpi_sci() anymore.
> The above change also works with bare metal kernel too.
>
> Signed-off-by: Jiang Liu
> Tested-by: Sander Eikelenboom
> Cc: Tony Luck
> Cc: xen-de...@lists.xenproject.org
> Cc: Konrad Rzeszutek Wilk
> Cc: David Vrabel
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: Pavel Machek
> Cc: Bjorn Helgaas
> Link:
> http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Stefan Bader
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> arch/x86/kernel/acpi/boot.c | 21 ++-
> arch/x86/pci/xen.c | 47
>
> 2 files changed, 11 insertions(+), 57 deletions(-)
>
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -604,18 +604,19 @@ void __init acpi_pic_sci_set_trigger(uns
>
> int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
> {
> - int irq;
> + int rc, irq, trigger, polarity;
>
> - if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
> - *irqp = gsi;
> - } else {
> - irq = mp_map_gsi_to_irq(gsi,
> - IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
> - if (irq < 0)
> - return -1;
> - *irqp = irq;
> + rc = acpi_get_override_irq(gsi, , );
> + if (rc == 0) {
> + trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> + polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> + irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
> + if (irq >= 0) {
> + *irqp = irq;
> + return 0;
> + }
> }
> - return 0;
> + return -1;
> }
> EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
>
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -452,52 +452,6 @@ int __init pci_xen_hvm_init(void)
> }
>
> #ifdef CONFIG_XEN_DOM0
> -static __init void xen_setup_acpi_sci(void)
> -{
> - int rc;
> - int trigger, polarity;
> - int gsi = acpi_sci_override_gsi;
> - int irq = -1;
> - int gsi_override = -1;
> -
> - if (!gsi)
> - return;
> -
> - rc = acpi_get_override_irq(gsi, , );
> - if (rc) {
> - printk(KERN_WARNING "xen: acpi_get_override_irq failed for acpi"
> - " sci, rc=%d\n", rc);
> - return;
> - }
> - trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> - polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
> -
> - printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
> - "polarity=%d\n", gsi, trigger, polarity);
> -
> - /* Before we bind
[PATCH v2] mm: fix anon_vma->degree underflow in anon_vma endless growing prevention
I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after
upgrading to 3.19 and had no luck with 4.0-rc1 neither.
So, after looking into new logic introduced by 7a3ef208e662 ("mm: prevent
endless growth of anon_vma hierarchy"), I found chances are that
unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in
anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL
in error path, its degree will be incorrectly decremented in
unlink_anon_vmas() and eventually underflow when exiting as a result of
another call to unlink_anon_vmas(). That's how "kernel BUG at
mm/rmap.c:399!" is triggered for me.
This patch fixes the underflow by dropping dst->anon_vma when allocation
fails. It's safe to do so regardless of original value of dst->anon_vma
because dst->anon_vma doesn't have valid meaning if anon_vma_clone()
fails. Besides, callers don't care dst->anon_vma in such case neither.
Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as
anon_vma_clone() now does the work.
Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy")
Signed-off-by: Leon Yu
Signed-off-by: Konstantin Khlebnikov
Reviewed-by: Michal Hocko
Acked-by: David Rientjes
Cc:
---
Changes in v2:
- clean up vma_adjust() per Michal Hocko's suggestion
- comment tweaked by Andrew Morton
mm/mmap.c | 4 +---
mm/rmap.c | 7 +++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index da9990a..9ec50a3 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -774,10 +774,8 @@ again: remove_next = 1 + (end >
next->vm_end);
importer->anon_vma = exporter->anon_vma;
error = anon_vma_clone(importer, exporter);
- if (error) {
- importer->anon_vma = NULL;
+ if (error)
return error;
- }
}
}
diff --git a/mm/rmap.c b/mm/rmap.c
index 5e3e090..bed3cf2 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -287,6 +287,13 @@ int anon_vma_clone(struct vm_area_struct *dst, struct
vm_area_struct *src)
return 0;
enomem_failure:
+ /*
+* dst->anon_vma is dropped here otherwise its degree can be incorrectly
+* decremented in unlink_anon_vmas().
+* We can safely do this because callers of anon_vma_clone() don't care
+* about dst->anon_vma if anon_vma_clone() failed.
+*/
+ dst->anon_vma = NULL;
unlink_anon_vmas(dst);
return -ENOMEM;
}
--
2.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 2/2] gpio: pcf857x: Propagate wake-up setting to parent irq controller
On Thu, Feb 5, 2015 at 4:49 PM, Geert Uytterhoeven wrote: > The pcf857x GPIO and interrupt controller uses dummy_irq_chip, which > does not implement irq_chip.irq_set_wake() and does not set > IRQCHIP_SKIP_SET_WAKE. > > This causes two s2ram issues if wake-up is enabled for the pcf857x GPIO > pins: > 1. During resume from s2ram, the following warning is printed: > > WARNING: CPU: 0 PID: 1046 at kernel/irq/manage.c:537 > irq_set_irq_wake+0x9c/0xf8() > Unbalanced IRQ 113 wake disable > > 2. Wake-up through the pcf857x GPIO pins may fail, as the parent > interrupt controller may be suspended. > > Migrate the pcf857x GPIO and interrupt controller from dummy_irq_chip to > its own irq_chip. This irq chip implements irq_chip.irq_set_wake() to > propagate its wake-up setting to the parent interrupt controller. > > This fixes wake-up through gpio-keys on sh73a0/kzm9g, where the pcf857x > interrupt is cascaded to irq-renesas-intc-irqpin, and the latter must > not be suspended when wake-up is enabled. > > Signed-off-by: Geert Uytterhoeven > --- > v2: > - Rebased on top of "gpio: pcf857x: Switch to use gpiolib irqchip > helpers". Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: scsi: ufs: Fix possible null derefrence
Check for null before being dereferenced to avoid a invalid null
dereference.
Found using Coccinelle.
Signed-off-by: Tapasweni Pathak
Acked-by: Julia Lawall
---
drivers/scsi/ufs/ufshcd.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5d60a86..c54e64f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4268,12 +4268,15 @@ static int ufshcd_config_vreg(struct device *dev,
struct ufs_vreg *vreg, bool on)
{
int ret = 0;
- struct regulator *reg = vreg->reg;
- const char *name = vreg->name;
+ struct regulator *reg;
+ const char *name;
int min_uV, uA_load;
BUG_ON(!vreg);
+ reg = vreg->reg;
+ name = vreg->name;
+
if (regulator_count_voltages(reg) > 0) {
min_uV = on ? vreg->min_uV : 0;
ret = regulator_set_voltage(reg, min_uV, vreg->max_uV);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [RFC] gpio: pcf857x: Switch to use gpiolib irqchip helpers
On Thu, Feb 5, 2015 at 4:49 PM, Geert Uytterhoeven
wrote:
> Switch the PCF857x GPIO driver to use the gpiolib irqchip helpers.
> This driver uses a nested threaded interrupt, hence handle_nested_irq()
> and gpiochip_set_chained_irqchip() must be used.
>
> Note that this removes the checks added in commit 21fd3cd1874a2ac8
> ("gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done"),
> as the interrupt mappings are no longer created on-demand by the driver,
> but by gpiochip_irqchip_add() during initialization.
>
> Signed-off-by: Geert Uytterhoeven
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: Add support for NAU8824 codec to ASoC
On 2015/2/24 下午 10:13, Mark Brown wrote:
> On Sun, Feb 15, 2015 at 03:49:30PM +0800, Wan Zongshun wrote:
>
>> +/* SP Class-D mute control */
>> +SOC_DOUBLE("HP Playback Switch", NAU8824_HP_MUTE, NAU8824_L_MUTE_SFT,
>> +NAU8824_R_MUTE_SFT, 1, 1),
>> +SOC_SINGLE_TLV("HP Left Volume", NAU8824_HP_VOL, NAU8824_L_VOL_SFT,
>> +NAU8824_VOL_RSCL_RANGE, 1, out_hp_vol_tlv),
>> +SOC_SINGLE_TLV("HP Right Volume", NAU8824_HP_VOL, NAU8824_R_VOL_SFT,
>> +NAU8824_VOL_RSCL_RANGE, 1, out_hp_vol_tlv),
>
> I would have expected the headphone volume control to be a stereo
> (double) control - same for speakers.
The nau8824 related registers which control left/right volume are located
in different addresses and different shift bits. Since there is no available
preprocessor macro to meet our requirements, the driver consists of left/right
volume control separately.
>
>> +/* DMIC control */
>> +SOC_DOUBLE("DMIC L R Switch", NAU8824_ENA_CTRL, NAU8824_DMIC_CH0_SFT,
>> +NAU8824_DMIC_CH1_SFT, 1, 0),
>> +SOC_SINGLE("DMIC Enable", NAU8824_BIAS_ADJ, NAU8824_DMIC1_SFT, 1, 0),
>> +SOC_SINGLE("VMID Switch", NAU8824_BIAS_ADJ, NAU8824_VMID_SFT, 1, 0),
>> +SOC_SINGLE("BIAS Switch", NAU8824_BOOST, NAU8824_G_BIAS_SFT, 1, 0),
>
> This all looks like stuff that should be done with DAPM...
The above controls have been done with DAPM in next patch submit.
>
>> +SOC_DOUBLE_R_TLV("MIC L R Gain", NAU8824_ADC_CH0_DGAIN_CTRL,
>> +NAU8824_ADC_CH1_DGAIN_CTRL, 0,
>> +NAU8824_ADC_VOL_RSCL_RANGE, 0, adc_vol_tlv),
>
> All volume controls should be called Volume.
The naming has been changed.
>
>> +static int set_dmic_clk(struct snd_soc_dapm_widget *w,
>> +struct snd_kcontrol *kcontrol, int event)
>> +{
>> +struct snd_soc_codec *codec = w->codec;
>
> w->codec is going away, use snd_soc_dapm_to_codec(). You should always
> submit against current code.
Modified done in next patch submit.
>
>> +static const struct snd_kcontrol_new nau8824_rec_l_mix[] = {
>> +SOC_DAPM_SINGLE("BST1 Switch", SND_SOC_NOPM,
>> +0, 0, 0),
>> +};
>
> Please use normal indentation, a single tab is enough.
Modified done in next patch submit.
>
>> +static int nau8824_hp_event(struct snd_soc_dapm_widget *w,
>> +struct snd_kcontrol *kcontrol, int event)
>> +{
>> +return 0;
>> +}
>
> Remove empty functions.
Modified done in next patch submit.
>
>> +switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>> +case SND_SOC_DAIFMT_CBM_CFM:
>> +reg_val_2 |= NAU8824_I2S_MS_M;
>> +break;
>> +case SND_SOC_DAIFMT_CBS_CFS:
>> +break;
>> +case SND_SOC_DAIFMT_CBS_CFM:
>> +break;
>
> These two clocking configurations appear not to differ in terms of what
> we do to the device - this suggests that only one of them is actually
> supported.
Modified done in next patch submit.
>
>> +static int nau8824_FLL_freerun_mode(struct snd_soc_codec *codec, int
>> IsEnable)
>> +{
>> +if (IsEnable == true) {
>
> This doesn't look like Linux coding style...
Remove this function
>
>> +void set_sys_clk(struct snd_soc_codec *codec, int sys_clk)
>> +{
>> +pr_debug("%s sys_clk=%x\n", __func__, sys_clk);
>> +switch (sys_clk) {
>> +case NAU8824_INTERNALCLOCK:
>> +nau8824_FLL_freerun_mode(codec, true);
>> +break;
>> +
>> +case NAU8824_MCLK:
>> +default:
>> +nau8824_FLL_freerun_mode(codec, false);
>> +break;
>> +}
>> +}
>
> ...and I don't entirely see why it's a separate function to this (which
> is itself an internal wrapper function which possibly shouldn't exist)>
Remove "nau8824_FLL_freerun_mode()" function
>
>> +static int nau8824_set_sysclk(struct snd_soc_codec *codec,
>> +int clk_id, int source, unsigned int freq, int dir)
>> +{
>> +int divider = 1;
>> +
>> +if (clk_id == NAU8824_MCLK) {
>> +set_sys_clk(codec, NAU8824_MCLK);
>> +dev_dbg(codec->dev, "%s: input freq = %d divider = %d",
>> +__func__, freq, divider);
>> +
>> +} else if (clk_id == NAU8824_INTERNALCLOCK) {
>> +set_sys_clk(codec, NAU8824_INTERNALCLOCK);
>> +} else {
>> +dev_err(codec->dev, "Wrong clock src\n");
>> +return -EINVAL;
>> +}
>
> Use switch statements rather than if trees like other drivers. It looks
> like clk_id should actually be source since we're selecting the clock to
> use rather than selecting which clock to configure.
Modified done in next patch submit.
>
>> +static int nau8824_set_bias_level(struct snd_soc_codec *codec,
>> +enum snd_soc_bias_level level)
>> +{
>> +dev_dbg(codec->dev, "## nau8824_set_bias_level %d\n", level);
>> +if (level ==
Re: [PATCH RFT] phy: exynos-mipi-video: Use spin_lock to protct state->regmap rmw operations
Hi, On 04/03/15 13:24, Kishon Vijay Abraham I wrote: > This patch doesn't apply on 4.0-rc1. Can to refresh it to mainline > latest? It depends on Axel's previous patch: "phy: exynos-mipi-video: Fixup the test for state->regmap". Are there any issues even with that patch applied ? -- Thanks Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: Fix possible double free on error
(2015/03/04 19:01), He Kuang wrote:
> A double free occurred when get source file path failed. If lr->path
> failed to assign a new value, it will be freed as the old path and then
> be freed again during line_range__clear(), and causes this:
>
> $ perf probe -L do_execve -k vmlinux
> *** Error in `/usr/bin/perf': double free or corruption (fasttop):
> 0x00a9ac50 ***
> === Backtrace: =
> ../lib64/libc.so.6(+0x6eeef)[0x75e44eef]
> ../lib64/libc.so.6(+0x78cae)[0x75e4ecae]
> ../lib64/libc.so.6(+0x79987)[0x75e4f987]
> ../bin/perf[0x4ab41f]
> ...
>
> This patch fix this problem.
Good catch!
Acked-by: Masami Hiramatsu
Thank you,
>
> Signed-off-by: He Kuang
> ---
> tools/perf/util/probe-event.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 919937e..7df30bd 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -650,7 +650,11 @@ static int __show_line_range(struct line_range *lr,
> const char *module)
> /* Convert source file path */
> tmp = lr->path;
> ret = get_real_path(tmp, lr->comp_dir, >path);
> - free(tmp); /* Free old path */
> +
> + /* Free old path when new path is assigned */
> + if (tmp != lr->path)
> + free(tmp);
> +
> if (ret < 0) {
> pr_warning("Failed to find source file path.\n");
> return ret;
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
Re: [PATCH] Remove redhat'ism from ftrace selftests.
Hello,
On Wed, Mar 04, 2015 at 09:47:47PM +1100, Michael Ellerman wrote:
> On Tue, 2015-03-03 at 17:05 -0700, Shuah Khan wrote:
> > On 02/27/2015 08:16 PM, Namhyung Kim wrote:
> > > On Tue, Feb 24, 2015 at 01:24:59PM -0500, Dave Jones wrote:
> > >> On Tue, Feb 24, 2015 at 11:22:58AM -0700, Shuah Khan wrote:
> > >> > On 02/24/2015 11:18 AM, Steven Rostedt wrote:
> > >> > >
> > >> > > Shuah,
> > >> > >
> > >> > > Can you take this in your tree?
> > >> >
> > >> > Yes I can do that. This must be the original patch email:
> > >> > https://lkml.org/lkml/2015/2/24/435
> > >
> > > Please see below links:
> > >
> > > https://lkml.org/lkml/2014/12/10/52
> > > https://lkml.org/lkml/2014/12/22/556
> > >
> > > I think we can get rid of the (u)sleeps entirely since 'cat trace'
> > > itself should trigger scheduler events.
> >
> > Steve/Dave,
> >
> > Still good to take it through. The discussion in the threads
> > Namhyung Kim pointed to seem to be inconclusive.
> >
> > The only difference between the original patch
> > https://lkml.org/lkml/2014/12/9/780
> > and
> > https://lkml.org/lkml/2015/2/24/435
> >
> > is sleep duration change. I can take through my tree
> > https://lkml.org/lkml/2015/2/24/435
> >
> > just confirming.
>
> No, the resoultion was that busybox doesn't support fractional sleeps and so
> using them is not a solution.
>
> I thought /bin/true would work, but never got around to testing it. The other
> option was to use (echo "forked"):
>
> https://lkml.org/lkml/2014/12/23/447
I think that there's no need to even call true or echo..
>From 0549544e8e982df6478f11e2b4fe419f94c22434 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Wed, 4 Mar 2015 21:26:38 +0900
Subject: [PATCH] ftracetest: Do not use usleep
The usleep is only provided on distros from Redhat so running ftracetest
on other distro resulted in failures due to the missing usleep.
The reason of using [u]sleep in the test was to generate (scheduler)
events. But as we use 'cat trace | grep | wc -l' to read the events,
the command themselves already generate some events before reading the
trace file so no need to call [u]sleep explicitly.
Reported-by: Michael Ellerman
Reported-by: Dave Jones
Signed-off-by: Namhyung Kim
---
tools/testing/selftests/ftrace/test.d/event/event-enable.tc | 3 ---
tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc | 3 ---
2 files changed, 6 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
index 668616d9bb03..7c7b4ce383a3 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
@@ -21,7 +21,6 @@ reset_tracer
do_reset
echo 'sched:sched_switch' > set_event
-usleep 1
count=`cat trace | grep sched_switch | wc -l`
if [ $count -eq 0 ]; then
@@ -31,7 +30,6 @@ fi
do_reset
echo 1 > events/sched/sched_switch/enable
-usleep 1
count=`cat trace | grep sched_switch | wc -l`
if [ $count -eq 0 ]; then
@@ -41,7 +39,6 @@ fi
do_reset
echo 0 > events/sched/sched_switch/enable
-usleep 1
count=`cat trace | grep sched_switch | wc -l`
if [ $count -ne 0 ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
index 655c415b6e7f..08a9459224b0 100644
--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
@@ -21,7 +21,6 @@ reset_tracer
do_reset
echo 'sched:*' > set_event
-usleep 1
count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
if [ $count -lt 3 ]; then
@@ -31,7 +30,6 @@ fi
do_reset
echo 1 > events/sched/enable
-usleep 1
count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
if [ $count -lt 3 ]; then
@@ -41,7 +39,6 @@ fi
do_reset
echo 0 > events/sched/enable
-usleep 1
count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
if [ $count -ne 0 ]; then
--
2.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] irq-dw-apb-ictl: convert to platform device
On Wednesday 04 March 2015 05:30 PM, Sebastian Hesselbarth wrote: > On 03/04/2015 11:46 AM, Vineet Gupta wrote: >> > On Wednesday 04 March 2015 02:30 PM, Sebastian Hesselbarth wrote: >>> >> On 04.03.2015 04:11, Jisheng Zhang wrote: >>> On Tue, 3 Mar 2015 06:56:59 -0800 >>> Alexey Brodkin wrote: > This allows utilization of probe deferral if master interrupt > controller > was not yet probed. > > In my case there's an DW APB GPIO configured as interrupt controller > which is a master for DW APB INTC. > > [...] >>> >> Just to get this straight for me, you are using DW_APB_INTC as a _slave_ >>> >> interrupt controller of DW_APB_GPIO _master_ interrupt controller? Is >>> >> this a fictional setup to test your IP or is it a real world example? > [...] >> > >> > I think Alexey is away for rest of the week so let me fill in some of the >> > details. >> > The setup is indeed real and part of ARC SDP (Software Development >> > Platform) and >> > these patches are precursor to getting that merged upstream. >> > >> > SDP has a split main board / cpu card design, where both cards have an >> > intc of own >> > to mux the irqs from respective levels. MB has a DW APB intc which sends a >> > single >> > uplink to DW GPIO intc on cpu card, which in turn hooks up to ARC core. In >> > the >> > final design, the board guys decided that this GPIO intc will act as a >> > pass thru >> > for the downstream IRQ, but we still need to clear the interrupt on it etc >> > - hence >> > it needs to properly show up in the cascaded intc hierarchy. > Vineet, thanks for the clarification. So, above describes the following > setup: > > APB_INTC->(GPIO line)->APB_GPIO->APB_INTC->(Main INTC) Not quite, we only have 1 DW APB intc (see ASCII art below) Ethernet or xyz device IRQ -> APB INTC -> GPIO line -> APB GPIO -> ARC Core intc > > I see that current early probing of APB_INTC does not fit well into the > picture. >> > Does that mean if we tweak irq-dw-apb-ictlc.c enough, it could double as >> > driver >> > for intc component of dw-apb-gpio too ? > Hmm, I am inclined to say that if it is the setup above and not some > tweaked hardware you have, we should try to rework the existing drivers > to allow the setup. Above is part 1 of setup - although to give you complete picture (perhaps orthogonal to this exact issue), we have another GPIO intc at cpu level which is used to wire up the cpu local peripherals (e.g. debug uart). Sounds a bit crazy, but it is what it is. - | snps,arc700-intc | - | #7 | #15 --- -- | DW GPIO INTC| | DW GPIO INTC | --- -- | | |[ Debug UART on cpu card ] | | DW APB INTC (MB)| | | | | [eth] [uart] [... other perip on Main Board] Note the APB INTC to GPIO intc is more like a single wire pass thru. > We could share code of dw-apb-intc and try to distinguish early probed > vs late probed devices, but I haven't thought in detail how to achieve > this in a clean way. > > Another option would be... > > [...] > +module_platform_driver(dw_apb_ictl_device_driver); >>> This is too late. If the ictl is needed during early boot, for example >>> on Marvell BG2Q DMP board, we still need to calibrate the delay loop, >>> the >>> kernel will hang at "Calibrating delay loop..." > ... to make Berlin use another timer that is not connected to > dw-apb-intc slave controller. IIRC, there is a TWD timer in all > (current) Berlin SoCs and it is directly connected to the master > intc. We'll have to rework (silence) current TWD implementation to > be usable on BG2CD UP and I haven't thought about the second clock > source, yet. > > Also, I admit it will most likely just postpone the general issue to > the next SoC. Yeah I don't like this approach - we fix it now for good ! > > I'll have to have a deeper look into kernel sources, it has been a while > I looked at this in detail. In the meantime, I hope there is somebody > else with a better idea ;) Lets see :-) Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] do_fork(): Rename 'stack_size' argument to reflect actual use
The 'stack_size' argument is never used to pass a stack size. It's only used
when
forking a kernel thread, in which case it is an argument which should be passed
to the 'main' function which the kernel thread executes. Hence, rename it to
'kthread_arg'.
Signed-off-by: Alex Dowad
---
Hi,
Please have a look at this patch. If this is accepted, I have a series of
patches
ready for a similar cleanup to all the arch-specific implementations of
copy_thread()
(as suggested by Andrew Morton in a private e-mail).
Thank you,
Alex Dowad
kernel/fork.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index cf65139..b38a2ae 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1186,10 +1186,12 @@ init_task_pid(struct task_struct *task, enum pid_type
type, struct pid *pid)
* It copies the registers, and all the appropriate
* parts of the process environment (as per the clone
* flags). The actual kick-off is left to the caller.
+ *
+ * When copying a kernel thread, 'stack_start' is the function to run.
*/
static struct task_struct *copy_process(unsigned long clone_flags,
unsigned long stack_start,
- unsigned long stack_size,
+ unsigned long kthread_arg,
int __user *child_tidptr,
struct pid *pid,
int trace)
@@ -1401,7 +1403,7 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
retval = copy_io(clone_flags, p);
if (retval)
goto bad_fork_cleanup_namespaces;
- retval = copy_thread(clone_flags, stack_start, stack_size, p);
+ retval = copy_thread(clone_flags, stack_start, kthread_arg, p);
if (retval)
goto bad_fork_cleanup_io;
@@ -1629,8 +1631,8 @@ struct task_struct *fork_idle(int cpu)
* it and waits for it to finish using the VM if required.
*/
long do_fork(unsigned long clone_flags,
- unsigned long stack_start,
- unsigned long stack_size,
+ unsigned long stack_start, /* or function for kthread to run */
+ unsigned long kthread_arg,
int __user *parent_tidptr,
int __user *child_tidptr)
{
@@ -1656,7 +1658,7 @@ long do_fork(unsigned long clone_flags,
trace = 0;
}
- p = copy_process(clone_flags, stack_start, stack_size,
+ p = copy_process(clone_flags, stack_start, kthread_arg,
child_tidptr, NULL, trace);
/*
* Do this prior waking up the new thread - the thread pointer
@@ -1740,7 +1742,7 @@ SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned
long, clone_flags,
int, tls_val)
#elif defined(CONFIG_CLONE_BACKWARDS3)
SYSCALL_DEFINE6(clone, unsigned long, clone_flags, unsigned long, newsp,
- int, stack_size,
+ int, ignored,
int __user *, parent_tidptr,
int __user *, child_tidptr,
int, tls_val)
--
2.0.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 12/14] tools build: Allow to override feature checks setup
On Wed, Mar 04, 2015 at 09:23:01PM +0900, Namhyung Kim wrote: > On Tue, Mar 03, 2015 at 03:26:35PM +0100, Jiri Olsa wrote: > > diff --git a/tools/build/tests/features/Makefile > > b/tools/build/tests/features/Makefile > > new file mode 100644 > > index ..31782a1d3758 > > --- /dev/null > > +++ b/tools/build/tests/features/Makefile > > @@ -0,0 +1,23 @@ > > +all: test1 > > + > > +test1: > > + rm -f FEATURE-DUMP > > + make -f Makefile.test1 > out > > + # we should get one line with 'glibc' feature status > > + features=`cat out | grep '\.\.\.' | wc -l`; \ > > It seems this `cat | grep | wc -l` pipeline can be replaced with a > single `grep -cF ... out` command. right.. v2 attached, perf/build branch updated ;-) thanks, jirka --- Allowing to override configuration variables for feature checks. Also adding automated test and documentation. Signed-off-by: Jiri Olsa Cc: Arnaldo Carvalho de Melo Cc: Corey Ashford Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra --- tools/build/Documentation/Feature.txt | 93 +++ tools/build/Makefile.feature | 4 +- tools/build/tests/features/Makefile | 23 tools/build/tests/features/Makefile.test1 | 16 ++ tools/build/tests/run.sh | 4 +- 5 files changed, 137 insertions(+), 3 deletions(-) create mode 100644 tools/build/Documentation/Feature.txt create mode 100644 tools/build/tests/features/Makefile create mode 100644 tools/build/tests/features/Makefile.test1 diff --git a/tools/build/Documentation/Feature.txt b/tools/build/Documentation/Feature.txt new file mode 100644 index ..0c75419ba803 --- /dev/null +++ b/tools/build/Documentation/Feature.txt @@ -0,0 +1,93 @@ +Feature Framework += +The 'feature' framework provides information for makefiles about +installed libraries and interfaces in the system. + +The 'feature' is represented by its name and simple source located +in 'tools/build/feature/test-$(name).c' file. The framework builds +each such source for configured feature and sets $(feature-$(name)) +variable to 0 or 1 if it fails or succeeds to build respectively. + +The current usage example of the feature framework is: + +--- Makefile.test + FEATURE_TESTS := glibc backtrace + FEATURE_DISPLAY := glibc + + srctree := ../../../.. + include $(srctree)/tools/build/Makefile.feature + + ifndef feature-glibc +$(error FAILED feature-glibc variable not defined) + endif + + ifndef feature-backtrace +$(error FAILED feature-backtrace variable not defined) + endif +--- + +User defines list of features to check in FEATURE_TESTS variable: + + FEATURE_TESTS := glibc backtrace + +and list of features she wishes to display in FEATURE_DISPLAY variable: + + FEATURE_DISPLAY := glibc + +then user includes Makefile.feature makefile: + + include $(srctree)/tools/build/Makefile.feature + +following output is displayed on processing of the makefile: + + $ make -f Makefile.test + + Auto-detecting system features: + ... glibc: [ on ] + +Plus following variables are defined indicating the +requested feature status: + + $(feature-glibc) + $(feature-backtrace) + +Following features are currently available for FEATURE_TESTS: + + backtrace + dwarf + fortify-source + sync-compare-and-swap + glibc + gtk2 + gtk2-infobar + libaudit + libbfd + libelf + libelf-getphdrnum + libelf-mmap + libnuma + libperl + libpython + libpython-version + libslang + libunwind + pthread-attr-setaffinity-np + stackprotector-all + timerfd + libdw-dwarf-unwind + libbabeltrace + zlib + +It's also possible to pass options for checks compilation and linking +by using following variables: + + FEATURE_CHECK_CFLAGS-$(name) + FEATURE_CHECK_LDFLAGS-$(name) + +where $(anem) represents feature name from above list. + +For example following settings will provide options for 'libunwind' +feature compilation and linking: + +FEATURE_CHECK_CFLAGS-libunwind = $(LIBUNWIND_CFLAGS) +FEATURE_CHECK_LDFLAGS-libunwind = $(LIBUNWIND_LDFLAGS) diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature index 3249fad27993..5b712ed7e4c7 100644 --- a/tools/build/Makefile.feature +++ b/tools/build/Makefile.feature @@ -27,7 +27,7 @@ endef # the rule that uses them - an example for that is the 'bionic' # feature check. ] # -FEATURE_TESTS =\ +FEATURE_TESTS ?= \ backtrace \ dwarf \ fortify-source \ @@ -53,7 +53,7 @@ FEATURE_TESTS = \ libbabeltrace \ zlib -FEATURE_DISPLAY = \ +FEATURE_DISPLAY ?= \ dwarf \ glibc
Re: [PATCH v2] dma: mmp-tdma: refine dma disable and dma-pos update
On Tue, Mar 03, 2015 at 09:16:08AM +0800, Qiao Zhou wrote: > Below are the refinements. > 1. Set DMA abort bit when disabling dma channel. This will clear > the remaining data in dma FIFO, to fix channel-swap issue. > 2. Read DMA HW pointer when updating DMA status. Previously dma > position is calculated by adding one period size in dma interrupt. > This is inaccurate/insufficient for some high-quality audio APP. > Since interrupt bottom half handler has variable schedule delay, > it causes big error when calculating sample delay. Read the actual > HW pointer and feedback can improve the accuracy. > 3. Do some minor code clean. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
Hi Jean, See reply at v4. On 02/26/2015 10:50 AM, Jean Delvare wrote: Hi Ivan, Mark and all, Le Tuesday 03 February 2015 à 17:48 +0200, Ivan Khoronzhuk a écrit : On 02/03/2015 04:58 PM, Mark Salter wrote: On Wed, 2015-01-28 at 14:39 +0200, Ivan Khoronzhuk wrote: Some utils, like dmidecode and smbios, needs to access SMBIOS entry table area in order to get information like SMBIOS version, size, etc. Currently it's done via /dev/mem. But for situation when /dev/mem usage is disabled, the utils have to use dmi sysfs instead, which doesn't represent SMBIOS entry. So this patch adds SMBIOS area to dmi-sysfs in order to allow utils in question to work correctly with dmi sysfs interface. Reviewed-by: Ard Biesheuvel Signed-off-by: Ivan Khoronzhuk Sorry for coming in late, here. Why expose the raw header instead of exposing the pieces as individual files like the kernel does for the other dmi info? That way the kernel decodes the header and presents it in an easy to read format for dmidecode or even a shell script. Sorry for coming in even later. This is a common misconception that dmidecode would be happier with pre-processed data. In fact it's exactly the opposite, dmidecode will be much happier with raw data because it already has all the code to decode the raw data, and that code will have to stay in place anyway as not all systems have sysfs with the proper information exposed to avoid reading the raw data from /dev/mem directly. In a particular it should be noted that the current /sys/firmware/dmi/entries interface is completely unsuited for consumption by dmidecode. It would require a significant amount of extra code in dmidecode to walk and parse the hundreds of files in this directory. And there would be additional problems, such as slower execution (500 file open/close cycles, thank you very much) and entries not being displayed in the same order as when dmidecode reads the table directly. So not only Ivan is right with his idea of exposing the raw DMI/SMBIOS entry point in sysfs, but I think we need to go even further and also expose the raw DMI data table itself through sysfs. It should go under /sys/firmware/dmi/tables/, much like ACPI tables live under /sys/firmware/acpi/tables/. I would also suggest that both the raw entry point and the raw table data should be presented regardless of CONFIG_DMI_SYSFS. The code should be small enough that it should be OK to include it unconditionally. Most systems don't need the dmi-sysfs code, the use cases seem rather limited to me, and on distributions it's generally built as a module and not loaded by default. The SMBIOS entry point can contain specific fields depending on it's version. In the specification I didn't find any rules concerning this. Only field that probably will be available is version number, but the version number is not only var that can be required by utils. For example, dmidecode needs also print some additional info like phys address where dmitable is placed. I don't sure how exactly next SMBIOS version will be changed. It can happen that some new data is available...and some old is removed. It's better to export it as raw data like it was done for dmi entries via raw attribute and It's better to pass the whole entry table instead of each time modify the dmi sysfs interface when new SMBIOS version is issued. --- v1: https://lkml.org/lkml/2015/1/23/643 v2: https://lkml.org/lkml/2015/1/26/345 v3..v2: This notation is confusing, being opposite to the git syntax. Please just write "Changes since v2". firmware: dmi_scan: add symbol to get SMBIOS entry area firmware: dmi-sysfs: add SMBIOS entry point area attribute combined in one patch added SMBIOS information to ABI sysfs-dmi documentaton v2..v1: firmware: dmi_scan: add symbol to get SMBIOS entry area - used additional static var to hold SMBIOS raw table size - changed format of get_smbios_entry_area symbol returned pointer on const smbios table firmware: dmi-sysfs: add SMBIOS entry point area attribute - adopted to updated get_smbios_entry_area symbol - removed redundant array to save smbios table Documentation/ABI/testing/sysfs-firmware-dmi | 10 +++ drivers/firmware/dmi-sysfs.c | 42 drivers/firmware/dmi_scan.c | 26 + include/linux/dmi.h | 3 ++ 4 files changed, 81 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi b/Documentation/ABI/testing/sysfs-firmware-dmi index c78f9ab..3a9ffe8 100644 --- a/Documentation/ABI/testing/sysfs-firmware-dmi +++ b/Documentation/ABI/testing/sysfs-firmware-dmi @@ -12,6 +12,16 @@ Description: cannot ensure that the data as exported to userland is without error either. + The firmware provides DMI structures as a packed list of + data referenced by a SMBIOS table entry
Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
Hi Jean. On 02/26/2015 11:41 AM, Jean Delvare wrote: Replying to myself... On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote: Please also note that the recently released version 3.0.0 of the SMBIOS specification introduces a new entry point format, and the firmware is allowed to implement both the old and the new format. It may be desirable to expose both to user-space under different names. Having read the kernel code meanwhile, I see we will call either dmi_smbios3_present or dmi_present successfully, not both, so presenting both entry points to user-space would be non-trivial. So I'm fine with presenting only one entry point in sysfs for the time being. We can always revisit later if it turns out that dmidecode really needs both in some cases. Why do you need two tables ? If kernel can parse the best one why it should present the old one? The old is subset of new, so the new must contain all required information, only format can be slightly different. If dmidecode has problems in reading new version then dmidecode should be modified, not kernel. -- Regards, Ivan Khoronzhuk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf probe: Find compilation directory path for lazy matching
(2015/03/04 16:52), Naohiro Aota wrote:
> If we use lazy matching, it failed to open a souce file if perf command
> is invoked outside of compilation directory:
>
> $ perf probe -a '__schedule;clear_*'
> Failed to open kernel/sched/core.c: No such file or directory
> Error: Failed to add events. (-2)
>
> OTOH, other commands like "probe -L" can solve the souce directory by
> themselves. Let's make it possible for lazy matching too!
>
Looks good to me :)
Acked-by: Masami Hiramatsu
Thank you!
> Signed-off-by: Naohiro Aota
> ---
> tools/perf/util/probe-event.c | 59 ---
> tools/perf/util/probe-finder.c | 71
> +-
> tools/perf/util/probe-finder.h | 4 +++
> 3 files changed, 74 insertions(+), 60 deletions(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 1c570c2..adb8d1f 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -515,65 +515,6 @@ static int try_to_find_probe_trace_events(struct
> perf_probe_event *pev,
> return ntevs;
> }
>
> -/*
> - * Find a src file from a DWARF tag path. Prepend optional source path prefix
> - * and chop off leading directories that do not exist. Result is passed back
> as
> - * a newly allocated path on success.
> - * Return 0 if file was found and readable, -errno otherwise.
> - */
> -static int get_real_path(const char *raw_path, const char *comp_dir,
> - char **new_path)
> -{
> - const char *prefix = symbol_conf.source_prefix;
> -
> - if (!prefix) {
> - if (raw_path[0] != '/' && comp_dir)
> - /* If not an absolute path, try to use comp_dir */
> - prefix = comp_dir;
> - else {
> - if (access(raw_path, R_OK) == 0) {
> - *new_path = strdup(raw_path);
> - return *new_path ? 0 : -ENOMEM;
> - } else
> - return -errno;
> - }
> - }
> -
> - *new_path = malloc((strlen(prefix) + strlen(raw_path) + 2));
> - if (!*new_path)
> - return -ENOMEM;
> -
> - for (;;) {
> - sprintf(*new_path, "%s/%s", prefix, raw_path);
> -
> - if (access(*new_path, R_OK) == 0)
> - return 0;
> -
> - if (!symbol_conf.source_prefix) {
> - /* In case of searching comp_dir, don't retry */
> - zfree(new_path);
> - return -errno;
> - }
> -
> - switch (errno) {
> - case ENAMETOOLONG:
> - case ENOENT:
> - case EROFS:
> - case EFAULT:
> - raw_path = strchr(++raw_path, '/');
> - if (!raw_path) {
> - zfree(new_path);
> - return -ENOENT;
> - }
> - continue;
> -
> - default:
> - zfree(new_path);
> - return -errno;
> - }
> - }
> -}
> -
> #define LINEBUF_SIZE 256
> #define NR_ADDITIONAL_LINES 2
>
> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
> index 46f009a..e6c0262 100644
> --- a/tools/perf/util/probe-finder.c
> +++ b/tools/perf/util/probe-finder.c
> @@ -849,11 +849,22 @@ static int probe_point_lazy_walker(const char *fname,
> int lineno,
> static int find_probe_point_lazy(Dwarf_Die *sp_die, struct probe_finder *pf)
> {
> int ret = 0;
> + char *fpath;
>
> if (intlist__empty(pf->lcache)) {
> + const char *comp_dir;
> +
> + comp_dir = cu_get_comp_dir(>cu_die);
> + ret = get_real_path(pf->fname, comp_dir, );
> + if (ret < 0) {
> + pr_warning("Failed to find source file path.\n");
> + return ret;
> + }
> +
> /* Matching lazy line pattern */
> - ret = find_lazy_match_lines(pf->lcache, pf->fname,
> + ret = find_lazy_match_lines(pf->lcache, fpath,
> pf->pev->point.lazy_line);
> + free(fpath);
> if (ret <= 0)
> return ret;
> }
> @@ -1616,3 +1627,61 @@ found:
> return (ret < 0) ? ret : lf.found;
> }
>
> +/*
> + * Find a src file from a DWARF tag path. Prepend optional source path prefix
> + * and chop off leading directories that do not exist. Result is passed back
> as
> + * a newly allocated path on success.
> + * Return 0 if file was found and readable, -errno otherwise.
> + */
> +static int get_real_path(const char *raw_path, const char *comp_dir,
> + char **new_path)
> +{
> + const char *prefix = symbol_conf.source_prefix;
> +
> + if (!prefix) {
> + if (raw_path[0] != '/' && comp_dir)
>
[4.0] cryptsetup fails
Hi,
I wanted to give the new kernel a try, but the cryptsetup fails with:
[8.747114] localhost.localdomain systemd-cryptsetup[280]: Set cipher aes,
mode xts-plain64, key size 256 bits for device /dev/disk/[...]
[9.265258] localhost.localdomain kernel: device-mapper: table: 254:0:
crypt: Error allocating crypto tfm
[9.265265] localhost.localdomain kernel: device-mapper: ioctl: error adding
target to table
[9.280993] localhost.localdomain systemd-cryptsetup[280]: Failed to
activate: Input/output error
the error seems to get produced in drivers/md/dm-crypt.c:
5ebaee6d2 (Milan Broz 2010-08-12 04:14:07 +0100 1619) /*
Allocate cipher */
fd2d231fa (Mikulas Patocka2012-07-27 15:08:05 +0100 1620)
ret = crypt_alloc_tfms(cc, cipher_api);
fd2d231fa (Mikulas Patocka2012-07-27 15:08:05 +0100 1621)
if (ret < 0) {
fd2d231fa (Mikulas Patocka2012-07-27 15:08:05 +0100 1622)
ti->error = "Error allocating crypto tfm";
fd2d231fa (Mikulas Patocka2012-07-27 15:08:05 +0100 1623)
goto bad;
$ grep AES /boot/config-4.0.0-rc1-23421-g023a600
# CONFIG_SND_MAESTRO3 is not set
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
any ideas what did change here? what am i missing?
with kind regards
thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute
On 02/26/2015 11:36 AM, Jean Delvare wrote:
Hi Ivan,
Sorry for the late review.
On Wed, 4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry. So this patch adds SMBIOS area to
dmi-sysfs in order to allow utils in question to work correctly with
dmi sysfs interface.
Reviewed-by: Ard Biesheuvel
Signed-off-by: Ivan Khoronzhuk
---
v1: https://lkml.org/lkml/2015/1/23/643
v2: https://lkml.org/lkml/2015/1/26/345
v3: https://lkml.org/lkml/2015/1/28/768
v4..v2:
Please always provide a list of changes from the previous version of
the patch, otherwise it's quite confusing.
Typo v4..v2 -> v4..v3
firmware: dmi_scan: add symbol to get SMBIOS entry area
- used u8 type for smbios_header var
firmware: dmi-sysfs: add SMBIOS entry point area attribute
- replaced -ENODATA on -EINVAL
v3..v2:
firmware: dmi_scan: add symbol to get SMBIOS entry area
firmware: dmi-sysfs: add SMBIOS entry point area attribute
- combined in one patch
- added SMBIOS information to ABI sysfs-dmi documentaton
v2..v1:
firmware: dmi_scan: add symbol to get SMBIOS entry area
- used additional static var to hold SMBIOS raw table size
- changed format of get_smbios_entry_area symbol
returned pointer on const smbios table
firmware: dmi-sysfs: add SMBIOS entry point area attribute
- adopted to updated get_smbios_entry_area symbol
- removed redundant array to save smbios table
Documentation/ABI/testing/sysfs-firmware-dmi | 10 +++
drivers/firmware/dmi-sysfs.c | 42
drivers/firmware/dmi_scan.c | 26 +
include/linux/dmi.h | 3 ++
4 files changed, 81 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
+ The firmware provides DMI structures as a packed list of
+ data referenced by a SMBIOS table entry point. The SMBIOS
+ entry point contains general information, like SMBIOS
+ version, DMI table size, etc. The structure, content and
+ size of SMBIOS entry point is dependent on SMBIOS version.
+ That's why SMBIOS entry point is represented in dmi sysfs
+ like a raw attribute and is accessible via
+ /sys/firmware/dmi/smbios_raw_header. The format of SMBIOS
As mentioned before, I don't like the name "smbios_raw_header". I think
it should be "smbios_entry_point" or similar.
If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.
+ entry point header can be read in SMBIOS specification.
+
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as a firmware-provided
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..9b396d7 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -29,6 +29,8 @@
#define MAX_ENTRY_TYPE 255 /* Most of these aren't used, but we consider
the top entry type is only 8 bits */
+static const u8 *smbios_raw_header;
+
struct dmi_sysfs_entry {
struct dmi_header dh;
struct kobject kobj;
@@ -646,9 +648,37 @@ static void cleanup_entry_list(void)
}
}
+static ssize_t smbios_entry_area_raw_read(struct file *filp,
This is confusing again, now it's named "entry_area"? Please be
consistent and use entry_point everywhere.
As mentioned before I believe that this code should live in dmi_scan
and not dmi-sysfs.
+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t pos, size_t count)
+{
+ ssize_t size;
+
+ size = bin_attr->size;
+
+ if (size > pos)
+ size -= pos;
+ else
+ return 0;
+
+ if (count < size)
+ size = count;
+
+ memcpy(buf, _raw_header[pos], size);
+
+ return size;
+}
+
+static struct bin_attribute smbios_raw_area_attr = {
+ .read = smbios_entry_area_raw_read,
+ .attr = {.name = "smbios_raw_header", .mode =
Re: [PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo infrastructure
On Wed, Mar 04, 2015 at 12:00:16PM +, Sudeep Holla wrote:
> This patch removes the redundant sysfs cacheinfo code by reusing
> the newly introduced generic cacheinfo infrastructure through the
> commit 246246cbde5e ("drivers: base: support cpu cache information
> interface to userspace via sysfs")
>
> The private pointer provided by the cacheinfo is used to implement
> the AMD L3 cache specific attributes.
>
> Note that with v4.0-rc1, commit 513e3d2d11c9 ("cpumask: always use
> nr_cpu_ids in formatting and parsing functions") in particular changes
> from long format to shorter one for all cpumasks sysfs entries. As the
> consequence of the same, even the shared_cpu_map in the cacheinfo sysfs
> was also changed.
>
> This patch neither alters any existing sysfs entries nor their formating,
> however since the generic cacheinfo has switched to use the device
> attributes instead of the traditional raw kobjects, a directory named
> "power" along with its standard attributes are added similar to any
> other device.
>
> Signed-off-by: Sudeep Holla
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Borislav Petkov
> Cc: Andre Przywara
> Cc: x...@kernel.org
Applied, thanks guys.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFT] phy: exynos-mipi-video: Use spin_lock to protct state->regmap rmw operations
Hi, On Friday 27 February 2015 06:57 PM, Sylwester Nawrocki wrote: On 27/02/15 04:50, Axel Lin wrote: he state->regmap is initialized by devm_regmap_init_mmio(). So it's fine to use spin_lock rather than mutex to protct state->regmap rmw operations. Signed-off-by: Axel Lin --- Hi Sylwester, I don't have this hardware handy, so can you test if this patch works. This patch is on top of my previous patch (phy: exynos-mipi-video: Fixup the test for state->regmap) Thanks for the patch, it looks good to me. I somehow missed the syscon already uses a spinlock for regmap protection. v4.0-rc1 seems devastated as far as exynos4 is concerned, it may take some time until I get around and fix all the issues so I tested your patch on v3.19. It all works well as expected. Acked-by: Sylwester Nawrocki Tested-by: Sylwester Nawrocki This patch doesn't apply on 4.0-rc1. Can to refresh it to mainline latest? Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 12/14] tools build: Allow to override feature checks setup
On Tue, Mar 03, 2015 at 03:26:35PM +0100, Jiri Olsa wrote: > diff --git a/tools/build/tests/features/Makefile > b/tools/build/tests/features/Makefile > new file mode 100644 > index ..31782a1d3758 > --- /dev/null > +++ b/tools/build/tests/features/Makefile > @@ -0,0 +1,23 @@ > +all: test1 > + > +test1: > + rm -f FEATURE-DUMP > + make -f Makefile.test1 > out > + # we should get one line with 'glibc' feature status > + features=`cat out | grep '\.\.\.' | wc -l`; \ It seems this `cat | grep | wc -l` pipeline can be replaced with a single `grep -cF ... out` command. Thanks, Namhyung > + if [ "$$features" != "1" ]; then echo FAILED; exit 1; fi > + # we should NOT get any feature status line on second run > + make -f Makefile.test1 > out > + features=`cat out | grep '\.\.\.' | wc -l`; \ > + if [ "$$features" == "1" ]; then echo FAILED; exit 1; fi > + # we should get both 'glibc' and 'backtrace' status lines now > + make -f Makefile.test1 VF=1 > out > + features=`cat out | grep '\.\.\.' | wc -l`; \ > + if [ "$$features" != "2" ]; then echo FAILED; exit 1; fi > + # and fresh start without FEATURE-DUMP, expecting 'glibc' status line > + rm -f FEATURE-DUMP > + make -f Makefile.test1 > out > + features=`cat out | grep '\.\.\.' | wc -l`; \ > + if [ "$$features" != "1" ]; then echo FAILED; exit 1; fi > + # cleanup > + rm -f FEATURE-DUMP out -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] arm-cci: Split the code for PMU vs driver support
On 03/03/15 15:53, Sudeep Holla wrote: On 02/03/15 11:29, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" This patch separates the PMU driver code from the low level CCI driver code. Introduces config options for both. ARM_CCI400_PORT_CTRL - controls the low level driver code for CCI400 ports. ARM_CCI400_PMU - controls the PMU driver code ARM_CCI400_COMMON- Common defintions for CCI400 Also the ARM_CCI400_PORT_CTRL cannot be enabled by user. This should be selected by platforms which need it. This patch also changes: ARM_CCI - common code for probing the CCI devices. This can be used for adding support for newer CCI versions(e.g, CCI-500). Signed-off-by: Suzuki K. Poulose --- arch/arm/mach-exynos/Kconfig |2 +- arch/arm/mach-vexpress/Kconfig |4 ++-- drivers/bus/Kconfig| 27 +++ drivers/bus/arm-cci.c | 24 include/linux/arm-cci.h|7 ++- 5 files changed, 52 insertions(+), 12 deletions(-) [...] diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index b99729e..bdc189f 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -43,12 +43,31 @@ config OMAP_INTERCONNECT help Driver to enable OMAP interconnect error handling driver. -config ARM_CCI - bool "ARM CCI driver support" +config ARM_CCI400_PORT_CTRL + bool depends on ARM && OF && CPU_V7 + select ARM_CCI400_COMMON + help + Low level power management driver for CCI400 cache coherent + interconnect for ARM platforms. + +config ARM_CCI400_PMU + bool "ARM CCI400 PMU support" + depends on ARM || ARM64 + depends on HW_PERF_EVENTS + select ARM_CCI400_COMMON help - Driver supporting the CCI cache coherent interconnect for ARM - platforms. + Support for PMU events monitoring on the ARM CCI cache coherent + interconnect. + + If unsure, say N Just a query rather than comment. Before this change all platforms having ARM_CCI and HW_PERF_EVENTS had CCI PMU enabled by default. With this change, one has to select this option explicitly. I assume that's fine, else this needs to be default 'y' Yes, that makes sense. Now that we decide if we can access the CCI safely at runtime, it is safe to make this default. Regards Suzuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/5] arm-cci400: PMU monitoring support on ARM64
On 03/03/15 16:00, Sudeep Holla wrote: On 02/03/15 11:29, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" This series enables the PMU monitoring support for CCI400 on ARM64. The existing CCI400 driver code is a mix of PMU driver and the MCPM driver code. The MCPM driver is only used on ARM(32) and contains arm32 assembly and hence can't be built on ARM64. This patch splits the code to - ARM_CCI400_PORT_CTRL driver - depends on ARM && V7 - ARM_CCI400_PMU driver Accessing the Peripheral ID2 register(PID2) on CCI-400, to detect the revision of the chipset, is a secure operation. Hence, it prevents us from running this on non-secure platforms. The issue is overcome by explicitly mentioning the revision number of the CCI PMU in the device tree binding. The device-tree binding has been updated with the new bindings. i.e,arm-cci-400-pmu,r0 => revision 0 arm-cci-400-pmu,r1 => revision 1 arm-cci-400-pmu => (old) DEPRECATED The old binding has been DEPRECATED and must be used only on ARM32 system with secure access. We don't have a reliable dynamic way to detect if the system is running secure. This series tries to use the best safe method by relying on the availability of MCPM(as it was prior to the series). It is upto the MCPM platform driver to decide, if the system is secure before it goes ahead and registers its drivers and pokes the CCI. This series doesn't address/solve the problem of MCPM. I will be happy to use a better approach, if there is any. Tested on (non-secure)TC2 and Juno. For the series: Tested-by: Sudeep Holla (on secure/MCPM TC2) Thanks a lot for the testing Suzuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm-cci: Rearrange code for splitting PMU vs driver code
On 03/03/15 15:35, Sudeep Holla wrote:
On 02/03/15 11:29, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports().
Signed-off-by: Suzuki K. Poulose
---
drivers/bus/arm-cci.c | 330
+
1 file changed, 168 insertions(+), 162 deletions(-)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 84fd660..f27cf56 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
[...]
@@ -1395,11 +1412,36 @@ static int cci_probe(void)
sync_cache_w(_port);
__sync_cache_range_w(ports, sizeof(*ports) * nb_cci_ports);
pr_info("ARM CCI driver probed\n");
+
return 0;
+}
+
+static int cci_probe(void)
+{
+ int ret;
+ struct device_node *np;
+ struct resource res;
+
+ np = of_find_matching_node(NULL, arm_cci_matches);
+ if (!np)
+ return -ENODEV;
-memalloc_err:
+ if (!of_device_is_available(np))
+ return -ENODEV;
+
+ ret = of_address_to_resource(np, 0, );
+ if (!ret) {
+ cci_ctrl_base = ioremap(res.start, resource_size());
+ cci_ctrl_phys = res.start;
+ }
+ if (ret || !cci_ctrl_base) {
+ WARN(1, "unable to ioremap CCI ctrl\n");
+ ret = -ENXIO;
+ goto out;
IMO you can return directly here and get rid of this goto as nothing is
done there.
Yes, you are right. I will fix that in the next revision.
Regards
Suzuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] get the random phy addr according to slot_area info
On 03/03/15 at 08:14am, Yinghai Lu wrote: > On Tue, Mar 3, 2015 at 3:42 AM, Baoquan He wrote: > > > > Here input means the region where kernel was linked to load? > > > > In normal kernel the linked address is 0x100. In your input region > > the result of ALIGN(0x13f5ed3b4, CONFIG_PHYSICAL_ALIGN) is 0x14000. > > And size of this region is smaller than 16M. It should return in > > process_e820_entry() with two checks. > > > > I guess you use kexec or a special bootloader to put kernel in this > > load address. > > > > Hi Yinghai, I checked code but didnt' find the code bug. Now I plan to hardcode your data to the avoid[] array, then test on my laptop. Then I can check what happened by message printing. Coudl you please help clarify the datas I wrote below? > with patched grub2 that load kernel/initrd/param/cmdline etc above 4G. > Here, avoid[0] input = 0x13f376000; input_size = 9.55M since its region is [0x13f376000-0x13f37dfff] addr = 0x13f37dfff - 0x338d000 = 0x13bff0fff size = (0x338d000 >> 12) + 32768 + 18 = 45983 = 0xb39f avoid[1] initrd [0x13f376000-0x13f37dfff] addr = 0x13f376000 size = 0x8000 avoid[2] cmdline [13fffb000,13fffb7fe] addr = 0x13fffb000 size = 0x13fffb7fe - 0x13fffb000 = 0x7ff avoid[3] heap: [0x13f376000-0x13f37dfff] addr = 0x13f376000 size = BOOT_HEAP_SIZE avoid[4] stack: from end of heap addr = 0x13f37dfff size = BOOT_STACK_SIZE; > kernel: read done [ linux 9.55MiB 100% 7.25MiB/s > ] > params: [13fffc000,13fff] > cmdline: [13fffb000,13fffb7fe] > kernel: [13c00,13f38cfff] output_orig = 0x13c00 output_size = 0x13f38cfff - 0x13c00 = 0x338d000 > initrd: [139d7c000,13bfff7e3] > initrd: read 1 file done [ initrd.img 34.51MiB 100% 11.17MiB/s > ] > early console in decompress_kernel > KASLR using RDTSC... > decompress_kernel: > input: [0x13e9ed3b4-0x13f36a64b], output: 0x16c00, heap: It's very weird to get 0x16c00 which is out of bound obviously. > [0x13f376000-0x13f37dfff] > > Decompressing Linux... xz... > > XZ-compressed data is corrupt > > -- System halted > > 13c00 is loaded address. > 0x13e9ed3b4 is the copied address, and decompress_kernel will use it as input. > output is back to 13c00 if aslr is not used. > > Thanks > > Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 04/24] rmap: add argument to charge compound page
On 03/04/2015 12:52 PM, Kirill A. Shutemov wrote:
On Mon, Feb 23, 2015 at 05:21:31PM +0100, Vlastimil Babka wrote:
On 02/12/2015 05:18 PM, Kirill A. Shutemov wrote:
@@ -1052,21 +1052,24 @@ void page_add_anon_rmap(struct page *page,
* Everybody else should continue to use page_add_anon_rmap above.
*/
void do_page_add_anon_rmap(struct page *page,
- struct vm_area_struct *vma, unsigned long address, int exclusive)
+ struct vm_area_struct *vma, unsigned long address, int flags)
{
int first = atomic_inc_and_test(>_mapcount);
if (first) {
+ bool compound = flags & RMAP_COMPOUND;
+ int nr = compound ? hpage_nr_pages(page) : 1;
hpage_nr_pages(page) is:
static inline int hpage_nr_pages(struct page *page)
{
if (unlikely(PageTransHuge(page)))
return HPAGE_PMD_NR;
return 1;
}
and later...
/*
* We use the irq-unsafe __{inc|mod}_zone_page_stat because
* these counters are not modified in interrupt context, and
* pte lock(a spinlock) is held, which implies preemption
* disabled.
*/
- if (PageTransHuge(page))
+ if (compound) {
+ VM_BUG_ON_PAGE(!PageTransHuge(page), page);
this means that we could assume that
(compound == true) => (PageTransHuge(page) == true)
and simplify above to:
int nr = compound ? HPAGE_PMD_NR : 1;
Right?
No. HPAGE_PMD_NR is defined based on HPAGE_PMD_SHIFT which is BUILD_BUG()
without CONFIG_TRANSPARENT_HUGEPAGE. We will get compiler error without
the helper.
Oh, OK. But that doesn't mean there couldn't be another helper that
would work in this case, or even open-coded #ifdefs in these functions.
Apparently "compound" has to be always false for
!CONFIG_TRANSPARENT_HUGEPAGE, as in that case PageTransHuge is defined
as 0 and the VM_BUG_ON would trigger if compound was true. So without
such ifdefs or wrappers, you are also adding dead code and pointless
tests for !CONFIG_TRANSPARENT_HUGEPAGE?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/18] clocksource: Add ARM System timer driver
2015-03-03 20:43 GMT+01:00 Paul Bolle : > Maxime Coquelin schreef op ma 02-03-2015 om 17:53 [+0100]: >> Do you agree if I define it like this: >> >> config ARMV7M_SYSTICK >> bool "Clocksource driver for ARMv7-M System timer" >> depends on OF && (CPU_V7M || COMPILE_TEST) >> select CLKSRC_OF >> select CLKSRC_MMIO >> help >> This options enables clocksource support for the ARMv7-M system >> timer unit. > > I don't really have strong feelings on whatever way you choose to fix > the, well, minor problem I pointed out. > > Having said that, if a Kconfig entry without a prompt (and therefor, > without help) actually does what you want it to do, why bother adding a > prompt and a one line help text? This is because I added also support for COMPILE_TEST coverage as per Uwe advice, and thought it was necessary to have an entry for this. Maybe I'm just wrong? Thanks, Maxime > > > Paul Bolle > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] bcma: Kconfig: Let it depend on PCI
On 4 March 2015 at 07:19, Rafał Miłecki wrote: > On 3 March 2015 at 22:16, Chen Gang wrote: >> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI, >> or will cause building break for allmodconfig under c6x: >> >> CC [M] drivers/bcma/driver_pcie2.o >> drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': >> drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function >> 'pcie_set_readrq' [-Werror=implicit-function-declaration] >> err = pcie_set_readrq(dev, pcie2->reqsize); >> ^ >> >> Signed-off-by: Chen Gang >> --- >> drivers/bcma/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig >> index 0ee48be..8be284e 100644 >> --- a/drivers/bcma/Kconfig >> +++ b/drivers/bcma/Kconfig >> @@ -1,6 +1,6 @@ >> config BCMA_POSSIBLE >> bool >> - depends on HAS_IOMEM && HAS_DMA >> + depends on HAS_IOMEM && HAS_DMA && PCI >> default y >> >> menu "Broadcom specific AMBA" >> -- >> 1.9.3 > > Hm, I'm not sure how to ideally handle this. Cc-ing few ppl, maybe > they have something to add. > > In fact there are SoCs (not using PCI host code obviously) with > everything embedded (without any PCI host mode cores). So note > following info about driver_pci.c and driver_pcie2.c: > 1) For BCMA_HOST_PCI > They are required, because of needed host-related PCI(e) core initialization. > 2) For BCMA_HOST_SOC > They are needed only if your SoC has PCI(e) host cores and you want to use > them. > > So I guess in theory we could have BCMA_DRIVER_PCI and *require* it > for BCMA_HOST_PCI only. After thinking about this. We already have Kconfig entries for other internal drivers, so I guess it makes sense to do the same for PCIe. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] thermal: Fix build for !CONFIG_THERMAL
Commit ddd4dd8ddf784 (thermal: extend the cooling device API to include
power information) added stubs for newly introduced functions when
!CONFIG_THERMAL but did not provide names for the parameters which is
a syntax error causing build errors in such configurations. Add names to
fix the issue.
Also remove an extra semicolon from power_actor_set_power() which also
breaks the build and declare the functions as static inline to avoid
both multiple definitions and sparse warnings.
Signed-off-by: Mark Brown
---
include/linux/thermal.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 4fb31db70b6f..48131730187b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -405,11 +405,11 @@ void thermal_notify_framework(struct thermal_zone_device
*, int);
#else
static inline bool cdev_is_power_actor(struct thermal_cooling_device *cdev)
{ return false; }
-int power_actor_get_max_power(struct thermal_cooling_device *,
+static inline int power_actor_get_max_power(struct thermal_cooling_device
*cdev,
struct thermal_zone_device *tz, u32 *max_power)
{ return 0; }
-int power_actor_set_power(struct thermal_cooling_device *,
- struct thermal_instance *, u32);
+static inline int power_actor_set_power(struct thermal_cooling_device *cdev,
+ struct thermal_instance *instance, u32 power)
{ return 0; }
static inline struct thermal_zone_device *thermal_zone_device_register(
const char *type, int trips, int mask, void *devdata,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
On Mon, Mar 02, 2015 at 01:36:51PM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Friday, February 27, 2015 7:41 AM
> > To: Wu, Feng
> > Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> > g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> > j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
> > eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> > io...@lists.linux-foundation.org; k...@vger.kernel.org
> > Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> > is blocked
> >
> > On Fri, Dec 12, 2014 at 11:14:58PM +0800, Feng Wu wrote:
> > > This patch updates the Posted-Interrupts Descriptor when vCPU
> > > is blocked.
> > >
> > > pre-block:
> > > - Add the vCPU to the blocked per-CPU list
> > > - Clear 'SN'
> > > - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
> > >
> > > post-block:
> > > - Remove the vCPU from the per-CPU list
> > >
> > > Signed-off-by: Feng Wu
> > > ---
> > > arch/x86/include/asm/kvm_host.h | 2 +
> > > arch/x86/kvm/vmx.c | 96
> > +
> > > arch/x86/kvm/x86.c | 22 +++---
> > > include/linux/kvm_host.h| 4 ++
> > > virt/kvm/kvm_main.c | 6 +++
> > > 5 files changed, 123 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > > index 13e3e40..32c110a 100644
> > > --- a/arch/x86/include/asm/kvm_host.h
> > > +++ b/arch/x86/include/asm/kvm_host.h
> > > @@ -101,6 +101,8 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t
> > base_gfn, int level)
> > >
> > > #define ASYNC_PF_PER_VCPU 64
> > >
> > > +extern void (*wakeup_handler_callback)(void);
> > > +
> > > enum kvm_reg {
> > > VCPU_REGS_RAX = 0,
> > > VCPU_REGS_RCX = 1,
> > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > index bf2e6cd..a1c83a2 100644
> > > --- a/arch/x86/kvm/vmx.c
> > > +++ b/arch/x86/kvm/vmx.c
> > > @@ -832,6 +832,13 @@ static DEFINE_PER_CPU(struct vmcs *,
> > current_vmcs);
> > > static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
> > > static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
> > >
> > > +/*
> > > + * We maintian a per-CPU linked-list of vCPU, so in wakeup_handler() we
> > > + * can find which vCPU should be waken up.
> > > + */
> > > +static DEFINE_PER_CPU(struct list_head, blocked_vcpu_on_cpu);
> > > +static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
> > > +
> > > static unsigned long *vmx_io_bitmap_a;
> > > static unsigned long *vmx_io_bitmap_b;
> > > static unsigned long *vmx_msr_bitmap_legacy;
> > > @@ -1921,6 +1928,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu,
> > int cpu)
> > > struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > > struct pi_desc old, new;
> > > unsigned int dest;
> > > + unsigned long flags;
> > >
> > > memset(, 0, sizeof(old));
> > > memset(, 0, sizeof(new));
> > > @@ -1942,6 +1950,20 @@ static void vmx_vcpu_load(struct kvm_vcpu
> > *vcpu, int cpu)
> > > new.nv = POSTED_INTR_VECTOR;
> > > } while (cmpxchg(_desc->control, old.control,
> > > new.control) != old.control);
> > > +
> > > + /*
> > > + * Delete the vCPU from the related wakeup queue
> > > + * if we are resuming from blocked state
> > > + */
> > > + if (vcpu->blocked) {
> > > + vcpu->blocked = false;
> > > + spin_lock_irqsave(_cpu(blocked_vcpu_on_cpu_lock,
> > > + vcpu->wakeup_cpu), flags);
> > > + list_del(>blocked_vcpu_list);
> > > +
> > > spin_unlock_irqrestore(_cpu(blocked_vcpu_on_cpu_lock,
> > > + vcpu->wakeup_cpu), flags);
> > > + vcpu->wakeup_cpu = -1;
> > > + }
> > > }
> > > }
> > >
> > > @@ -1950,6 +1972,9 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
> > > if (irq_remapping_cap(IRQ_POSTING_CAP)) {
> > > struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > > struct pi_desc old, new;
> > > + unsigned long flags;
> > > + int cpu;
> > > + struct cpumask cpu_others_mask;
> > >
> > > memset(, 0, sizeof(old));
> > > memset(, 0, sizeof(new));
> > > @@ -1961,6 +1986,54 @@ static void vmx_vcpu_put(struct kvm_vcpu
> > *vcpu)
> > > pi_set_sn();
> > > } while (cmpxchg(_desc->control, old.control,
> > > new.control) != old.control);
> > > + } else if (vcpu->blocked) {
> > > + /*
> > > + * The vcpu is blocked on the wait queue.
> > > + * Store the blocked vCPU on the list of the
> > > + * vcpu->wakeup_cpu, which is the destination
> > > +
Re: [PATCH] ath10k: Delete unnecessary checks before the function call "release_firmware"
SF Markus Elfring writes: > From: Markus Elfring > Date: Wed, 4 Feb 2015 19:30:23 +0100 > > The release_firmware() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks, applied to ath.git. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: xilinx-dma: move header file to common location
On Mon, Mar 02, 2015 at 08:28:01PM +0100, Arnd Bergmann wrote: > On Monday 02 March 2015 23:24:24 Kedareswara rao Appana wrote: > > This patch moves the xilinx_dma.h header file > > to the include/linux/dma. > > > > Signed-off-by: Kedareswara rao Appana > > Please move this header file to drivers/dma/xilinx/ directly to > make it inaccessible by other driver. No driver should pass extra > data structures to a dmaengine driver. Actually that is not true. Few of the drivers need some additional parameters to be set which are not covered by the common set, hence an additional API is exposed by this driver to do so... If ever we could get rid of these... -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v6 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
Changes for v6:
- cooling-{min|max}-state properties added to pwm-fan binding
- Mandatory properties for thermal-zones added
- Indentation fixed
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 29 --
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..c6d5332 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : "pwm-fan"
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
- status = "okay";
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
pwms = < 0 1 0>;
+ cooling-levels = <0 102 170 230>;
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+thermal-sensors = < 0>;
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <10>; /*
millicelsius */
+ hysteresis = <2000>; /*
millicelsius */
+ type = "passive";
+ };
+};
+cooling-maps {
+ map0 {
+ trip = <_alert1>;
+ cooling-device = < 0
1>;
+ };
+};
+ };
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v6 4/6] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
Changes for v5:
- None
Changes for v6:
- None
---
drivers/hwmon/pwm-fan.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
};
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
- struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
- unsigned long pwm, duty;
- ssize_t ret;
-
- if (kstrtoul(buf, 10, ) || pwm > MAX_PWM)
- return -EINVAL;
+ unsigned long duty;
+ int ret = 0;
mutex_lock(>lock);
-
if (ctx->pwm_value == pwm)
- goto exit_set_pwm_no_change;
+ goto exit_set_pwm_err;
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
- ret = count;
exit_set_pwm_err:
mutex_unlock(>lock);
return ret;
}
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ unsigned long pwm;
+ int ret;
+
+ if (kstrtoul(buf, 10, ) || pwm > MAX_PWM)
+ return -EINVAL;
+
+ ret = __set_pwm(ctx, pwm);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v6 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
Signed-off-by: Lukasz Majewski
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski
- status = "okay"; dropped from the patch
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = < 0 1 0>;
+ };
+};
+
+ {
+ pinctrl-0 = <_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+ status = "okay";
};
{
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
Changes for v6:
- Adding missing ctx == NULL check in pwm_fan_get_max_state()
- Call to thermal_cooling_device_unregister(ctx->cdev); at pwm_fan_remove()
- struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
---
drivers/hwmon/pwm-fan.c | 89 -
1 file changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..7c83dc4 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MAX_PWM 255
@@ -34,6 +35,7 @@ struct pwm_fan_ctx {
unsigned int pwm_fan_state;
unsigned int pwm_fan_max_state;
unsigned int *pwm_fan_cooling_levels;
+ struct thermal_cooling_device *cdev;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -68,6 +70,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+ if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx->pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +95,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +117,62 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx->pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev->devdata;
+ int ret;
+
+ if (!ctx || (state > ctx->pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx->pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(>device, "Cannot set pwm!\n");
+ return ret;
+ }
+
+ ctx->pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
@@ -145,8 +215,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +264,21 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ _fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(>dev,
+ "Failed to register pwm-fan as cooling device");
+ pwm_disable(ctx->pwm);
+ return
[PATCH RESEND v6 5/6] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when "cooling-levels" are defined in DT, but doesn't
have the value
Changes for v5:
- Use of of_find_property() to assess if "cooling-levels" was defined in
device tree
- Replace of_property_count_elems_of_size() with of_property_count_u32_elems()
- Remove ambiguity with returning error code from of_property_count_u32_elems()
- Return -EINVAL when "cooling-levels" has zero elements
Changes for v6:
- None
---
drivers/hwmon/pwm-fan.c | 50 -
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..e6ed353 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,46 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ if (!of_find_property(np, "cooling-levels", NULL))
+ return 0;
+
+ ret = of_property_count_u32_elems(np, "cooling-levels");
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret ? : -EINVAL;
+ }
+
+ num = ret;
+ ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx->pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, "cooling-levels",
+ctx->pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, "Property 'cooling-levels' cannot be read!\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
+ dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
+ ctx->pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx->pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +188,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx->pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(>dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v6 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
Acked-by: Eduardo Valentin
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = "pwm-fan";
pwms = < 0 1 0>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ #cooling-cells = <2>;
+ cooling-levels = <0 102 170 230>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+trip = <_alert1>;
+cooling-device = < 7 7>;
+ };
+ map1 {
+trip = <_alert2>;
+cooling-device = < 13 13>;
+ };
+ map2 {
+trip = <_alert0>;
+cooling-device = < 0 1>;
+ };
+ map3 {
+trip = <_alert1>;
+cooling-device = < 1 2>;
+ };
+ map4 {
+trip = <_alert2>;
+cooling-device = < 2 3>;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND RESEND v6 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc2) SHA1: ad83a2d87bff355750a17dd00aec563eb9f9d388 Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 29 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 172 +++-- 4 files changed, 229 insertions(+), 17 deletions(-) -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] irq-dw-apb-ictl: convert to platform device
On 03/04/2015 11:46 AM, Vineet Gupta wrote: On Wednesday 04 March 2015 02:30 PM, Sebastian Hesselbarth wrote: On 04.03.2015 04:11, Jisheng Zhang wrote: On Tue, 3 Mar 2015 06:56:59 -0800 Alexey Brodkin wrote: This allows utilization of probe deferral if master interrupt controller was not yet probed. In my case there's an DW APB GPIO configured as interrupt controller which is a master for DW APB INTC. [...] Just to get this straight for me, you are using DW_APB_INTC as a _slave_ interrupt controller of DW_APB_GPIO _master_ interrupt controller? Is this a fictional setup to test your IP or is it a real world example? [...] I think Alexey is away for rest of the week so let me fill in some of the details. The setup is indeed real and part of ARC SDP (Software Development Platform) and these patches are precursor to getting that merged upstream. SDP has a split main board / cpu card design, where both cards have an intc of own to mux the irqs from respective levels. MB has a DW APB intc which sends a single uplink to DW GPIO intc on cpu card, which in turn hooks up to ARC core. In the final design, the board guys decided that this GPIO intc will act as a pass thru for the downstream IRQ, but we still need to clear the interrupt on it etc - hence it needs to properly show up in the cascaded intc hierarchy. Vineet, thanks for the clarification. So, above describes the following setup: APB_INTC->(GPIO line)->APB_GPIO->APB_INTC->(Main INTC) I see that current early probing of APB_INTC does not fit well into the picture. Does that mean if we tweak irq-dw-apb-ictlc.c enough, it could double as driver for intc component of dw-apb-gpio too ? Hmm, I am inclined to say that if it is the setup above and not some tweaked hardware you have, we should try to rework the existing drivers to allow the setup. We could share code of dw-apb-intc and try to distinguish early probed vs late probed devices, but I haven't thought in detail how to achieve this in a clean way. Another option would be... [...] +module_platform_driver(dw_apb_ictl_device_driver); This is too late. If the ictl is needed during early boot, for example on Marvell BG2Q DMP board, we still need to calibrate the delay loop, the kernel will hang at "Calibrating delay loop..." ... to make Berlin use another timer that is not connected to dw-apb-intc slave controller. IIRC, there is a TWD timer in all (current) Berlin SoCs and it is directly connected to the master intc. We'll have to rework (silence) current TWD implementation to be usable on BG2CD UP and I haven't thought about the second clock source, yet. Also, I admit it will most likely just postpone the general issue to the next SoC. I'll have to have a deeper look into kernel sources, it has been a while I looked at this in detail. In the meantime, I hope there is somebody else with a better idea ;) Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo infrastructure
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde5e ("drivers: base: support cpu cache information
interface to userspace via sysfs")
The private pointer provided by the cacheinfo is used to implement
the AMD L3 cache specific attributes.
Note that with v4.0-rc1, commit 513e3d2d11c9 ("cpumask: always use
nr_cpu_ids in formatting and parsing functions") in particular changes
from long format to shorter one for all cpumasks sysfs entries. As the
consequence of the same, even the shared_cpu_map in the cacheinfo sysfs
was also changed.
This patch neither alters any existing sysfs entries nor their formating,
however since the generic cacheinfo has switched to use the device
attributes instead of the traditional raw kobjects, a directory named
"power" along with its standard attributes are added similar to any
other device.
Signed-off-by: Sudeep Holla
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Borislav Petkov
Cc: Andre Przywara
Cc: x...@kernel.org
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 711 ++
1 file changed, 194 insertions(+), 517 deletions(-)
v2->v3:
- Fixed the NULL pointer deference that occured as a check was missed
when migrating to generic cacheinfo. Thanks to Andre Przywara for
debugging the same and Borislav Petkov for suggesting the fix.
- Added a note in the commit log regarding the recent change in
cpumask sysfs formating.
v1->v2:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 659643376dbf..54e43d58e714 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -7,16 +7,14 @@
* Andi Kleen / Andreas Herrmann : CPUID4 emulation on AMD.
*/
-#include
#include
-#include
-#include
+#include
#include
#include
+#include
#include
#include
-#include
#include
#include
@@ -116,10 +114,10 @@ static const struct _cache_table cache_table[] =
enum _cache_type {
- CACHE_TYPE_NULL = 0,
- CACHE_TYPE_DATA = 1,
- CACHE_TYPE_INST = 2,
- CACHE_TYPE_UNIFIED = 3
+ CTYPE_NULL = 0,
+ CTYPE_DATA = 1,
+ CTYPE_INST = 2,
+ CTYPE_UNIFIED = 3
};
union _cpuid4_leaf_eax {
@@ -159,11 +157,6 @@ struct _cpuid4_info_regs {
struct amd_northbridge *nb;
};
-struct _cpuid4_info {
- struct _cpuid4_info_regs base;
- DECLARE_BITMAP(shared_cpu_map, NR_CPUS);
-};
-
unsigned short num_cache_leaves;
/* AMD doesn't have CPUID4. Emulate it here to report the same
@@ -220,6 +213,13 @@ static const unsigned short assocs[] = {
static const unsigned char levels[] = { 1, 1, 2, 3 };
static const unsigned char types[] = { 1, 2, 3, 3 };
+static const enum cache_type cache_type_map[] = {
+ [CTYPE_NULL] = CACHE_TYPE_NOCACHE,
+ [CTYPE_DATA] = CACHE_TYPE_DATA,
+ [CTYPE_INST] = CACHE_TYPE_INST,
+ [CTYPE_UNIFIED] = CACHE_TYPE_UNIFIED,
+};
+
static void
amd_cpuid4(int leaf, union _cpuid4_leaf_eax *eax,
union _cpuid4_leaf_ebx *ebx,
@@ -291,14 +291,8 @@ amd_cpuid4(int leaf, union _cpuid4_leaf_eax *eax,
(ebx->split.ways_of_associativity + 1) - 1;
}
-struct _cache_attr {
- struct attribute attr;
- ssize_t (*show)(struct _cpuid4_info *, char *, unsigned int);
- ssize_t (*store)(struct _cpuid4_info *, const char *, size_t count,
-unsigned int);
-};
-
#if defined(CONFIG_AMD_NB) && defined(CONFIG_SYSFS)
+
/*
* L3 cache descriptors
*/
@@ -325,20 +319,6 @@ static void amd_calc_l3_indices(struct amd_northbridge *nb)
l3->indices = (max(max3(sc0, sc1, sc2), sc3) << 10) - 1;
}
-static void amd_init_l3_cache(struct _cpuid4_info_regs *this_leaf, int index)
-{
- int node;
-
- /* only for L3, and not in virtualized environments */
- if (index < 3)
- return;
-
- node = amd_get_nb_id(smp_processor_id());
- this_leaf->nb = node_to_amd_nb(node);
- if (this_leaf->nb && !this_leaf->nb->l3_cache.indices)
- amd_calc_l3_indices(this_leaf->nb);
-}
-
/*
* check whether a slot used for disabling an L3 index is occupied.
* @l3: L3 cache descriptor
@@ -359,15 +339,13 @@ int amd_get_l3_disable_slot(struct amd_northbridge *nb,
unsigned slot)
return -1;
}
-static ssize_t show_cache_disable(struct _cpuid4_info *this_leaf, char *buf,
+static ssize_t show_cache_disable(struct cacheinfo *this_leaf, char *buf,
unsigned int slot)
{
int index;
+ struct amd_northbridge *nb = this_leaf->priv;
- if (!this_leaf->base.nb || !amd_nb_has_feature(AMD_NB_L3_INDEX_DISABLE))
- return -EINVAL;
-
- index = amd_get_l3_disable_slot(this_leaf->base.nb, slot);
+ index =
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
Mike, Do you want me to resend this set with Robert's Reviewed-by applied, or are you happy to apply it yourself? > v2 => v3: > - Ensure DT actually reflects h/w > - i.e. Nodes should not contain a mishmash of different IP > blocks, but should identify related h/w. In the current > example we use interconnects > - Change naming from clkdomain to clk-always-on > - Place "do not abuse" warning in documentation > > v1 => v2: > - Turned the ST specific driver into a generic one > > Hardware can have a bunch of clocks which must not be turned off. > If drivers a) fail to obtain a reference to any of these or b) give > up a previously obtained reference during suspend, the common clk > framework will attempt to turn them off and the hardware will > subsequently die. The only way to recover from this failure is to > restart. > > To avoid either of these two scenarios from catastrophically > disabling the running system we have implemented a clock domain > where clocks are consumed and references are taken, thus preventing > them from being shut down by the framework. > > *** BLURB HERE *** > > Lee Jones (4): > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > ARM: sti: stih407-family: Add platform interconnects to always-on clk > domain > clk: Provide an always-on clock domain framework > clk: dt: Introduce always-on clock domain documentation > > .../devicetree/bindings/clock/clk-always-on.txt| 35 > arch/arm/boot/dts/stih407-family.dtsi | 15 ++ > drivers/clk/Makefile | 1 + > drivers/clk/clk-always-on.c| 62 > ++ > include/dt-bindings/clock/stih407-clks.h | 4 ++ > 5 files changed, 117 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt > create mode 100644 drivers/clk/clk-always-on.c > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
