RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support
Hi,Andy
> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Thursday, December 24, 2015 9:40 AM
> To: Zheng, Lv
> Cc: Chen, Yu C; Moore, Robert; Wysocki, Rafael J; Brown, Len; Andy
> Lutomirski; Lv Zheng; linux-kernel@vger.kernel.org; Linux ACPI; H. Peter
> Anvin; Borislav Petkov
> Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support
>
> On Tue, Dec 22, 2015 at 7:25 PM, Zheng, Lv wrote:
[cut]
>
> It seems a bit unfortunate to me that the ACPICA debugger lets userspace
> choose what address to dump rather than dumping by pathname, but given
> that constraint, I guess this function is needed.
>
> Can you do something like checking virt_addr_valid and then using
> virt_to_pfn and page_is_ram? If that's not enough (e.g. if it doesn't work
> for
> vmalloc addresses and you need those), you could try to do something like
> slow_virt_to_phys, but you'd need to do some extra checks to avoid the
> BUG in the function.
>
[Yu] This is a good method, firstly virt_addr_valid can exclude the vaddr of
vmalloc/kmap
, then slow_virt_to_phys can check if this vaddr has a valid pte physical
address, but I guess
we need another non-BUG_on version of slow_virt_to_phys, I'll try to test with
your suggestion,
thanks!
Yu
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2] ASoC: rsnd: fix usrcnt decrementing bug
Hi > > Field usrcnt is unsigned so it cannot be lesser than zero. > The patch fixes the check, moves it to the beginning of the function > and changes return value to -EIO in case of usercnt error. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 > > Signed-off-by: Andrzej Hajda > --- Acked-by: Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] ACPI / debugger: remove some unneeded conditions
"count" is unsigned so checking for less than zero here causes a static checker warning. And really it's better to let the access_ok() check fail if the user passes in a NULL "buf" pointer because -EFAULT is the correct error code. Signed-off-by: Dan Carpenter diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c index 381beb2..f2c92ab 100644 --- a/drivers/acpi/acpi_dbg.c +++ b/drivers/acpi/acpi_dbg.c @@ -610,8 +610,6 @@ static ssize_t acpi_aml_read(struct file *file, char __user *buf, int ret = 0; int size = 0; - if (!buf || count < 0) - return -EINVAL; if (!count) return 0; if (!access_ok(VERIFY_WRITE, buf, count)) @@ -681,8 +679,6 @@ static ssize_t acpi_aml_write(struct file *file, const char __user *buf, int ret = 0; int size = 0; - if (!buf || count < 0) - return -EINVAL; if (!count) return 0; if (!access_ok(VERIFY_READ, buf, count)) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings
On Thu, Dec 3, 2015 at 5:10 PM, Krzysztof Kozlowski
wrote:
> Bindings for Samsung S2M and S5M family PMICs are in mess. They are
> spread over different files and subdirectories in a non-consistent way.
> The devices and respective drivers for them share a lot in common so
> everything could be organized in a more readable way.
>
> Reorganize the S2MPS11/13/14/15 Device Tree bindings to match the
> drivers for this family of devices:
> - move mfd/s2mps11.txt to mfd/samsung,sec-core.txt for the main MFD
>driver (common for entire family),
> - split clock block to clock/samsung,s2mps11.txt,
> - split regulator block to regulator/samsung,s2mps11.txt.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Michael Turquette
> ---
> .../devicetree/bindings/clock/samsung,s2mps11.txt | 49 +++
> Documentation/devicetree/bindings/mfd/s2mps11.txt | 153
> -
> .../devicetree/bindings/mfd/samsung,sec-core.txt | 84 +++
> .../bindings/regulator/samsung,s2mps11.txt | 102 ++
> MAINTAINERS| 4 +-
> 5 files changed, 238 insertions(+), 154 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> delete mode 100644 Documentation/devicetree/bindings/mfd/s2mps11.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> create mode 100644
> Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> new file mode 100644
> index ..2726c1d58a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> @@ -0,0 +1,49 @@
> +Binding for Samsung S2M and S5M family clock generator block
> +
> +
> +This is a part of device tree bindings for S2M and S5M family multi-function
> +devices.
> +More information can be found in bindings/mfd/sec-core.txt file.
> +
> +The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
> +outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
> +
> +To register these as clocks with common clock framework instantiate under
> +main device node a sub-node named "clocks".
> +
> +It uses the common clock binding documented in:
> + - Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +
> +Required properties of the "clocks" sub-node:
> + - #clock-cells: should be 1.
> + - compatible: Should be one of: "samsung,s2mps11-clk",
> "samsung,s2mps13-clk",
> + "samsung,s2mps14-clk", "samsung,s5m8767-clk"
> + The S2MPS15 uses the same compatible as S2MPS13, as both provides similar
> + clocks.
> +
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +Clock ID Devices
> +--
> +32KhzAP0S2MPS11/13/14/15, S5M8767
> +32KhzCP1S2MPS11/13/15, S5M8767
> +32KhzBT2S2MPS11/13/14/15, S5M8767
> +
> +Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines
> +in device tree sources.
> +
> +
> +Example:
> +
> + s2mps11_pmic@66 {
> + compatible = "samsung,s2mps11-pmic";
> + reg = <0x66>;
> +
> + s2m_osc: clocks {
> + compatible = "samsung,s2mps11-clk";
> + #clock-cells = <1>;
> + clock-output-names = "xx", "yy", "zz";
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> deleted file mode 100644
> index 09b94c97faac..
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ /dev/null
> @@ -1,153 +0,0 @@
> -
> -* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
> -
> -The Samsung S2MPS11 is a multi-function device which includes voltage and
> -current regulators, RTC, charger controller and other sub-blocks. It is
> -interfaced to the host controller using an I2C interface. Each sub-block is
> -addressed by the host system using different I2C slave addresses.
> -
> -Required properties:
> -- compatible: Should be one of the following
> - - "samsung,s2mps11-pmic"
> - - "samsung,s2mps13-pmic"
> - - "samsung,s2mps14-pmic"
> - - "samsung,s2mps15-pmic"
> - - "samsung,s2mpu02-pmic".
> -- reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
> -
> -Optional properties:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to
> which
> - the interrupts from s2mps11 are delivered to.
> -- interrupts: Interrupt specifiers for interrupt sources.
> -- samsung,s2mps11-wrstbi-ground:
Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled
On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote: > I don't understand why the wakeup conditions are different. It seems > to me that the choice of which packets will generate a wakeup ought to > depend on the user's selection, not on the kind of suspend. For > instance, if the user says that only a magic packet should cause a > wakeup then that should be true for both runtime suspend and system > suspend. > > To put it another way, as far as the device is concerned a suspend is > just a suspend -- there's no different between a runtime suspend and a > system suspend. This literally true, but the host and the driver care. If we autosuspend a running network device, any packet (maybe filtered for MAC) should cause a remote wake up, else we'd lose packets. But you cannot keep that setting if the system goes down or any broadcast packet would resume the whole system. Yet you cannot just disable remote wake up, as WoL packages still must trigger a remote wake up. So there are drivers which must change settings on devices as the system goes to sleep, even if their devices have already been autosuspended. We could use the notifier chains for that. But can this solution be called elegant? Merry Christmas Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc/irq: tidy up inconsistent context in migrate_irqs()
> -Original Message- > From: Denis Kirjanov [mailto:k...@linux-powerpc.org] > Sent: Thursday, December 24, 2015 6:04 AM > To: Zhang Zhuoyu > Cc: Michael Ellerman ; linux-kernel@vger.kernel.org; > pau...@samba.org; t...@linutronix.de; linuxppc-...@lists.ozlabs.org; > jiang@linux.intel.com; Daniel Axtens > Subject: Re: [PATCH 1/1] powerpc/irq: tidy up inconsistent context in > migrate_irqs() > > On 12/24/15, Denis Kirjanov wrote: > > On 12/23/15, Zhang Zhuoyu wrote: > >> Hi, Denis > >> > >> Any test result on pmac machine for this patch? > > > > Hi, > > > > So I ran the tests by writing to cpuN/online. > > > > with your change I'm observing lines like the following: > > [ 713.436922] NOHZ: local_softirq_pending 08 > Hi, It is a NOHZ warning, NOHZ will check for whether there are softirqs pending when an online CPU goes idle, this warning cannot be triggered by offlining CPU, you should check which driver's softirq is preventing CPU goes idle. > Another bad thing that the current powerpc/next kernel crashed on pmac > (without this change) while enabling/disabling cpu cores :/ I've attached the > screenshot > > > > > > Thanks! > > > >> > >> Zhuoyu > >> > >>> -Original Message- > >>> From: Zhang Zhuoyu [mailto:zhangzhu...@cmss.chinamobile.com] > >>> Sent: Wednesday, December 16, 2015 10:46 PM > >>> To: 'Denis Kirjanov'; 'Michael Ellerman' > >>> Cc: 'Daniel Axtens'; 'Zhang Zhuoyu'; 'b...@kernel.crashing.org'; > >>> 'pau...@samba.org'; 't...@linutronix.de'; > >>> 'jiang@linux.intel.com'; 'linuxppc-...@lists.ozlabs.org'; 'linux- > ker...@vger.kernel.org' > >>> Subject: RE: [PATCH 1/1] powerpc/irq: tidy up inconsistent context > >>> in > >>> migrate_irqs() > >>> > >>> > >>> > -Original Message- > >>> > From: Denis Kirjanov [mailto:k...@linux-powerpc.org] > >>> > Sent: Wednesday, December 16, 2015 7:55 PM > >>> > To: Michael Ellerman > >>> > Cc: Daniel Axtens; Zhang Zhuoyu; b...@kernel.crashing.org; > >>> > pau...@samba.org; t...@linutronix.de; jiang@linux.intel.com; > >>> > zhangzhu...@cmss.chinamobile.com; linuxppc-...@lists.ozlabs.org; > >>> > linux- ker...@vger.kernel.org > >>> > Subject: Re: [PATCH 1/1] powerpc/irq: tidy up inconsistent context > >>> > in > >>> > migrate_irqs() > >>> > > >>> > On 12/16/15, Michael Ellerman wrote: > >>> > > On Wed, 2015-12-16 at 17:08 +1100, Daniel Axtens wrote: > >>> > >> Hi, > >>> > >> > >>> > >> A couple of things. > >>> > >> > >>> > >> Firstly, your two email addresses don't match: > >>> > >> > >>> > >> Zhang Zhuoyu writes: > >>> > > > >>> > >> > From: Zhang Zhuoyu > >>> > >> > >>> > >>> Mmm, My mistake, I will correct it next time. > >>> > >>> > >> These lines do seem odd! Are they causing a problem? > >>> > >> > >>> > >> I'd be more comfortable removing them if I understood why they > >>> > >> were added. But they've been around since the beginning of git > >>> > >> history so that could be a bit difficult. > >>> > > > >>> > > It's in the fullhist tree, but that doesn't tell us much (below, > >>> > > named fixup_irqs()). > >>> > > > >>> > > But I suspect those lines are actually there very deliberately. > >>> > > > >>> > > The function is migrating interrupts off the recently offlined > >>> > > cpu, because we don't want to take interrupts on an offline cpu. > >>> > > > >>> > > After it's finished doing the migration, it wants to make sure > >>> > > there are no interrupts that have already been latched by the offline > cpu. > >>> > > So it briefly enables interrupts, waits a bit for the interrupts > >>> > > to fire, and the disables them again. > >>> > > > >>> > > Whether that actually works I couldn't say, it is very old code, > >>> > > and it's used on platforms where I don't ever test cpu hotplug > >>> > > (85xx & powermac). > >>> > > >>> > Yeah, it would be nice to test this change. I'll try it on my > >>> > quad-core pmac machine > >>> > > >>> > >>> Thanks Michael for help explaining the code logic, it also resolved > >>> my doubts. > >>> These snippets are suspected when I did PM benchmark on FSL > MPC85xx > >>> series(T1040, T4240), For T4240, which has 24 CPUs, it waits 1ms in > >>> migrate_irqs()each time a CPU is plugged offline, it seems a waste > >>> of time. I also did a test on T1040, after plugging offline/online > >>> CPU hundreds of times, system works well. If you have any other > >>> suggestion on how to test, I'd like to do more benchmark. > >>> (1)for((i=0; i<1000; i++)); do echo 0 > > >>> /sys/devices/system/cpu/cpu1/online; > >>> sleep 1; echo 1 > /sys/devices/system/cpu/cpu1/online; done > >>> (2)root@t1040rdb:~# cat /proc/interrupts > >>>CPU0 CPU1 CPU2 CPU3 > >>> 36:393 1223 1 OpenPIC36 Level > >>> serial > >>> LOC: 1946 1486 1555 1361 Local timer > >>> interrupts > >>> DBL: 7371 9707 9390 7568 Doorbell interrupts > >>> (3)root@t1040rdb:~# ps > >>> PID TTY
[PATCH v2] ASoC: rsnd: fix usrcnt decrementing bug
Field usrcnt is unsigned so it cannot be lesser than zero.
The patch fixes the check, moves it to the beginning of the function
and changes return value to -EIO in case of usercnt error.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda
---
v2: changed according to Kuninori Morimoto advice
---
sound/soc/sh/rcar/ssi.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 0b91692..f23c921 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -364,29 +364,30 @@ static int rsnd_ssi_quit(struct rsnd_mod *mod,
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
struct device *dev = rsnd_priv_to_dev(priv);
- if (rsnd_ssi_is_parent(mod, io))
- goto rsnd_ssi_quit_end;
+ if (!ssi->usrcnt) {
+ dev_err(dev, "%s[%d] usrcnt error\n",
+ rsnd_mod_name(mod), rsnd_mod_id(mod));
+ return -EIO;
+ }
- if (ssi->err > 0)
- dev_warn(dev, "%s[%d] under/over flow err = %d\n",
-rsnd_mod_name(mod), rsnd_mod_id(mod), ssi->err);
+ if (!rsnd_ssi_is_parent(mod, io)) {
+ if (ssi->err > 0)
+ dev_warn(dev, "%s[%d] under/over flow err = %d\n",
+rsnd_mod_name(mod), rsnd_mod_id(mod),
+ssi->err);
- ssi->cr_own = 0;
- ssi->err= 0;
+ ssi->cr_own = 0;
+ ssi->err= 0;
- rsnd_ssi_irq_disable(mod);
+ rsnd_ssi_irq_disable(mod);
+ }
-rsnd_ssi_quit_end:
rsnd_ssi_master_clk_stop(ssi, io);
rsnd_mod_power_off(mod);
ssi->usrcnt--;
- if (ssi->usrcnt < 0)
- dev_err(dev, "%s[%d] usrcnt error\n",
- rsnd_mod_name(mod), rsnd_mod_id(mod));
-
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 12/24/2015 at 02:16 PM, Dave Young wrote:
> Hi, Xunlei
>
> On 12/24/15 at 02:05pm, Xunlei Pang wrote:
>> On 12/24/2015 at 01:54 PM, Dave Young wrote:
>>> Ccing Vivek
>>>
>>> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
Implement the protection method for the crash kernel memory
reservation for the 64-bit x86 kdump.
Signed-off-by: Xunlei Pang
---
Only provided x86_64 implementation, as I've only tested on x86_64 so far.
arch/x86/kernel/machine_kexec_64.c | 43
++
1 file changed, 43 insertions(+)
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 819ab3f..a3d289c 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -536,3 +536,46 @@ overflow:
return -ENOEXEC;
}
#endif /* CONFIG_KEXEC_FILE */
+
+#ifdef CONFIG_KEXEC_CORE
>>> The file is only compiled when CONFIG_KEXEC_CORE=y so #ifdef is not
>>> necessary
>> Yes, indeed. I'll remove this macro and send v2 later.
>>
+static int
+kexec_mark_range(unsigned long start, unsigned long end, bool protect)
+{
+ struct page *page;
+ unsigned int nr_pages;
+
+ if (!start || !end || start >= end)
+ return 0;
+
+ page = pfn_to_page(start >> PAGE_SHIFT);
+ nr_pages = (end + 1 - start) >> PAGE_SHIFT;
+ if (protect)
+ return set_pages_ro(page, nr_pages);
+ else
+ return set_pages_rw(page, nr_pages);
>>> May use set_memory_ro/rw to avoid converting to *page?
>> on x86 it just a wrapper of set_memory_ro/rw, I think both are ok.
> Ok, I have no strong opinion on that..
>
+}
+
+static void kexec_mark_crashkres(bool protect)
+{
+ unsigned long control;
+
+ kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
+
+ /* Don't touch the control code page used in crash_kexec().*/
+ control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
+ /* Control code page is located in the 2nd page. */
+ control = control + PAGE_SIZE;
> Though it works because the control code is less than 1 page, but use the
> macro
> of KEXEC_CONTROL_PAGE_SIZE looks better..
>
+ kexec_mark_range(crashk_res.start, control - 1, protect);
+ kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
>>> X86 kexec will copy the page while kexecing, could you check if we can move
>>> that copying to earliyer while kexec loading, maybe machine_kexec_prepare so
>>> that we can make a arch-independent implementation.
>> For some arch, may use huge tlb directly to do the kernel mapping,
>> in such cases, we can't implement this function. So I think it should
>> be arch-dependent.
> Ok, that's fine.
At least moving the x86 control-copying code into arch-related
machine_kexec_prepare() should work, and this can omit the
special treatment of the control code page.
Regards,
Xunlei
>
>> Regards,
>> Xunlei
>>
+}
+
+void arch_kexec_protect_crashkres(void)
+{
+ kexec_mark_crashkres(true);
+}
+
+void arch_kexec_unprotect_crashkres(void)
+{
+ kexec_mark_crashkres(false);
+}
+#endif
--
2.5.0
___
kexec mailing list
ke...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
> Thanks
> Dave
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: OOM killer kicks in after minutes or never
+CC so this doesn't get lost On 21.12.2015 13:35, Marcin Szewczyk wrote: > Hi, > > In 2010 I noticed that viewing many GIFs in a row using gpicview renders > my Linux unresponsive. There is very little I can do in such a > situation. Rarely after some minutes the OOM killer kicks in and saves > the day. Nevertheless, usually I end up using Alt+SysRq+B. > > This is the second computer I can observe this problem on. First was > Asus EeePC 1000 with Atom N270 and now I have Lenovo S210 with Celeron > 1037U. > > What happens is gpicview exhausting whole available memory in such a > pattern that userspace becomes unresponsive. I cannot switch to another > terminal either. I have written a tool that allocates memory in a very > similar way using GDK -- https://github.com/wodny/crasher. > > I have also uploaded some logs to the repository -- top, iostat (showing > a lot of reads during an episode), dmesg. > > I suppose the OS starts to oscillate between freeing memory, cleaning > caches and buffers, and loading some new data (see iostat logs). > > Currently I am using Debian Jessie with the following kernel: > 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 > GNU/Linux > > I can observe the most impressive effects on my physical machine > (logs/ph-*). On a VM (logs/vm-*) usually the OOM killer kills the > process after a short time (5-120 seconds). > > Possible factors differentiating cases of recovering in seconds from > recoveries after minutes (or never): > - another memory-consuming process running (e.g. Firefox), > - physical machine or a VM (see dmesg logs), > - chipset and associated kernel functions (see dmesg logs). > > Things that seem irrelevant (after testing): > - running the application in Xorg or a TTY, > - LUKS encryption of the root filesystem, > - vm.oom_kill_allocating_task setting. > > What can I do to diagnose the problem further? > > > (Sorry if a duplicate appears) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Problems with phys_to_pfn_t in linux-next and s390
On Wed, Dec 23, 2015 at 9:56 PM, Guenter Roeck wrote:
> s390:defconfig:
>
> ERROR: "phys_to_pfn_t" [drivers/s390/block/dcssblk.ko] undefined!
>
> s390 does not set CONFIG_HAS_IOMEM, which is required for phys_to_pfn_t to
> exist.
>
> Introduced with commit e014f77c4b ("mm-dax-pmem-introduce-pfn_t-v3") and
> possibly earlier.
Addressed in v4:
https://lists.01.org/pipermail/linux-nvdimm/2015-December/003610.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
Hi, Xunlei
On 12/24/15 at 02:05pm, Xunlei Pang wrote:
> On 12/24/2015 at 01:54 PM, Dave Young wrote:
> > Ccing Vivek
> >
> > On 12/23/15 at 07:12pm, Xunlei Pang wrote:
> >> Implement the protection method for the crash kernel memory
> >> reservation for the 64-bit x86 kdump.
> >>
> >> Signed-off-by: Xunlei Pang
> >> ---
> >> Only provided x86_64 implementation, as I've only tested on x86_64 so far.
> >>
> >> arch/x86/kernel/machine_kexec_64.c | 43
> >> ++
> >> 1 file changed, 43 insertions(+)
> >>
> >> diff --git a/arch/x86/kernel/machine_kexec_64.c
> >> b/arch/x86/kernel/machine_kexec_64.c
> >> index 819ab3f..a3d289c 100644
> >> --- a/arch/x86/kernel/machine_kexec_64.c
> >> +++ b/arch/x86/kernel/machine_kexec_64.c
> >> @@ -536,3 +536,46 @@ overflow:
> >>return -ENOEXEC;
> >> }
> >> #endif /* CONFIG_KEXEC_FILE */
> >> +
> >> +#ifdef CONFIG_KEXEC_CORE
> > The file is only compiled when CONFIG_KEXEC_CORE=y so #ifdef is not
> > necessary
>
> Yes, indeed. I'll remove this macro and send v2 later.
>
> >
> >> +static int
> >> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
> >> +{
> >> + struct page *page;
> >> + unsigned int nr_pages;
> >> +
> >> + if (!start || !end || start >= end)
> >> + return 0;
> >> +
> >> + page = pfn_to_page(start >> PAGE_SHIFT);
> >> + nr_pages = (end + 1 - start) >> PAGE_SHIFT;
> >> + if (protect)
> >> + return set_pages_ro(page, nr_pages);
> >> + else
> >> + return set_pages_rw(page, nr_pages);
> > May use set_memory_ro/rw to avoid converting to *page?
>
> on x86 it just a wrapper of set_memory_ro/rw, I think both are ok.
Ok, I have no strong opinion on that..
>
> >
> >> +}
> >> +
> >> +static void kexec_mark_crashkres(bool protect)
> >> +{
> >> + unsigned long control;
> >> +
> >> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
> >> +
> >> + /* Don't touch the control code page used in crash_kexec().*/
> >> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> >> + /* Control code page is located in the 2nd page. */
> >> + control = control + PAGE_SIZE;
Though it works because the control code is less than 1 page, but use the macro
of KEXEC_CONTROL_PAGE_SIZE looks better..
> >> + kexec_mark_range(crashk_res.start, control - 1, protect);
> >> + kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
> > X86 kexec will copy the page while kexecing, could you check if we can move
> > that copying to earliyer while kexec loading, maybe machine_kexec_prepare so
> > that we can make a arch-independent implementation.
>
> For some arch, may use huge tlb directly to do the kernel mapping,
> in such cases, we can't implement this function. So I think it should
> be arch-dependent.
Ok, that's fine.
>
> Regards,
> Xunlei
>
> >
> >> +}
> >> +
> >> +void arch_kexec_protect_crashkres(void)
> >> +{
> >> + kexec_mark_crashkres(true);
> >> +}
> >> +
> >> +void arch_kexec_unprotect_crashkres(void)
> >> +{
> >> + kexec_mark_crashkres(false);
> >> +}
> >> +#endif
> >> --
> >> 2.5.0
> >>
> >>
> >> ___
> >> kexec mailing list
> >> ke...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI / debugger: Fix an issue a flag is modified without locking
There is one line of code, executed out of locking due to rebase mistakes.
This patch fixes this issue.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpi_dbg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c
index 381beb2..fa18bd0 100644
--- a/drivers/acpi/acpi_dbg.c
+++ b/drivers/acpi/acpi_dbg.c
@@ -516,10 +516,10 @@ static int acpi_aml_open(struct inode *inode, struct file
*file)
ret = -EINVAL;
goto err_lock;
}
- acpi_aml_io.flags |= ACPI_AML_OPENED;
pr_debug("Debugger thread initialized.\n");
mutex_lock(_aml_io.lock);
+ acpi_aml_io.flags |= ACPI_AML_OPENED;
acpi_aml_io.out_crc.head = acpi_aml_io.out_crc.tail = 0;
acpi_aml_io.in_crc.head = acpi_aml_io.in_crc.tail = 0;
pr_debug("Debugger interface opened.\n");
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: rsnd: fix usrcnt decrementing bug
Hi Andrzej > >> Field usrcnt is unsigned so it cannot be lesser than zero. > >> > >> The problem has been detected using proposed semantic patch > >> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. > >> > >> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 > >> > >> Signed-off-by: Andrzej Hajda > >> --- > > Thank you for your patch. good catch ! > > I noticed current error case is not good for ssi.c > > Can you agree below ? > Yes, of course. Thanks. Who send this patch ? you or me ? I think you can do it ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 12/24/2015 at 01:54 PM, Dave Young wrote:
> Ccing Vivek
>
> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
>> Implement the protection method for the crash kernel memory
>> reservation for the 64-bit x86 kdump.
>>
>> Signed-off-by: Xunlei Pang
>> ---
>> Only provided x86_64 implementation, as I've only tested on x86_64 so far.
>>
>> arch/x86/kernel/machine_kexec_64.c | 43
>> ++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 819ab3f..a3d289c 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -536,3 +536,46 @@ overflow:
>> return -ENOEXEC;
>> }
>> #endif /* CONFIG_KEXEC_FILE */
>> +
>> +#ifdef CONFIG_KEXEC_CORE
> The file is only compiled when CONFIG_KEXEC_CORE=y so #ifdef is not necessary
Yes, indeed. I'll remove this macro and send v2 later.
>
>> +static int
>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>> +{
>> +struct page *page;
>> +unsigned int nr_pages;
>> +
>> +if (!start || !end || start >= end)
>> +return 0;
>> +
>> +page = pfn_to_page(start >> PAGE_SHIFT);
>> +nr_pages = (end + 1 - start) >> PAGE_SHIFT;
>> +if (protect)
>> +return set_pages_ro(page, nr_pages);
>> +else
>> +return set_pages_rw(page, nr_pages);
> May use set_memory_ro/rw to avoid converting to *page?
on x86 it just a wrapper of set_memory_ro/rw, I think both are ok.
>
>> +}
>> +
>> +static void kexec_mark_crashkres(bool protect)
>> +{
>> +unsigned long control;
>> +
>> +kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>> +
>> +/* Don't touch the control code page used in crash_kexec().*/
>> +control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>> +/* Control code page is located in the 2nd page. */
>> +control = control + PAGE_SIZE;
>> +kexec_mark_range(crashk_res.start, control - 1, protect);
>> +kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
> X86 kexec will copy the page while kexecing, could you check if we can move
> that copying to earliyer while kexec loading, maybe machine_kexec_prepare so
> that we can make a arch-independent implementation.
For some arch, may use huge tlb directly to do the kernel mapping,
in such cases, we can't implement this function. So I think it should
be arch-dependent.
Regards,
Xunlei
>
>> +}
>> +
>> +void arch_kexec_protect_crashkres(void)
>> +{
>> +kexec_mark_crashkres(true);
>> +}
>> +
>> +void arch_kexec_unprotect_crashkres(void)
>> +{
>> +kexec_mark_crashkres(false);
>> +}
>> +#endif
>> --
>> 2.5.0
>>
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rsnd: fix usrcnt decrementing bug
On 12/24/2015 01:04 AM, Kuninori Morimoto wrote:
> Hi Andrzej
>
>> Field usrcnt is unsigned so it cannot be lesser than zero.
>>
>> The problem has been detected using proposed semantic patch
>> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>>
>> Signed-off-by: Andrzej Hajda
>> ---
> Thank you for your patch. good catch !
> I noticed current error case is not good for ssi.c
> Can you agree below ?
Yes, of course.
Regards
Andrzej
>
> -
> diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
> index 7db05fd..e519e30 100644
> --- a/sound/soc/sh/rcar/ssi.c
> +++ b/sound/soc/sh/rcar/ssi.c
> @@ -403,6 +403,12 @@ static int rsnd_ssi_quit(struct rsnd_mod *mod,
> struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
> struct device *dev = rsnd_priv_to_dev(priv);
>
> + if (!ssi->usrcnt) {
> + dev_err(dev, "%s[%d] usrcnt error\n",
> + rsnd_mod_name(mod), rsnd_mod_id(mod));
> + return -EIO;
> + }
> +
> if (rsnd_ssi_is_parent(mod, io))
> goto rsnd_ssi_quit_end;
>
> @@ -422,10 +428,6 @@ rsnd_ssi_quit_end:
>
> ssi->usrcnt--;
>
> - if (ssi->usrcnt < 0)
> - dev_err(dev, "%s[%d] usrcnt error\n",
> - rsnd_mod_name(mod), rsnd_mod_id(mod));
> -
> return 0;
> }
>
> -
>
>
> Best regards
> ---
> Kuninori Morimoto
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Problems with phys_to_pfn_t in linux-next and s390
s390:defconfig:
ERROR: "phys_to_pfn_t" [drivers/s390/block/dcssblk.ko] undefined!
s390 does not set CONFIG_HAS_IOMEM, which is required for phys_to_pfn_t to
exist.
Introduced with commit e014f77c4b ("mm-dax-pmem-introduce-pfn_t-v3") and
possibly earlier.
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: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
Ccing Vivek
On 12/23/15 at 07:12pm, Xunlei Pang wrote:
> Implement the protection method for the crash kernel memory
> reservation for the 64-bit x86 kdump.
>
> Signed-off-by: Xunlei Pang
> ---
> Only provided x86_64 implementation, as I've only tested on x86_64 so far.
>
> arch/x86/kernel/machine_kexec_64.c | 43
> ++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index 819ab3f..a3d289c 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -536,3 +536,46 @@ overflow:
> return -ENOEXEC;
> }
> #endif /* CONFIG_KEXEC_FILE */
> +
> +#ifdef CONFIG_KEXEC_CORE
The file is only compiled when CONFIG_KEXEC_CORE=y so #ifdef is not necessary
> +static int
> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
> +{
> + struct page *page;
> + unsigned int nr_pages;
> +
> + if (!start || !end || start >= end)
> + return 0;
> +
> + page = pfn_to_page(start >> PAGE_SHIFT);
> + nr_pages = (end + 1 - start) >> PAGE_SHIFT;
> + if (protect)
> + return set_pages_ro(page, nr_pages);
> + else
> + return set_pages_rw(page, nr_pages);
May use set_memory_ro/rw to avoid converting to *page?
> +}
> +
> +static void kexec_mark_crashkres(bool protect)
> +{
> + unsigned long control;
> +
> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
> +
> + /* Don't touch the control code page used in crash_kexec().*/
> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> + /* Control code page is located in the 2nd page. */
> + control = control + PAGE_SIZE;
> + kexec_mark_range(crashk_res.start, control - 1, protect);
> + kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
X86 kexec will copy the page while kexecing, could you check if we can move
that copying to earliyer while kexec loading, maybe machine_kexec_prepare so
that we can make a arch-independent implementation.
> +}
> +
> +void arch_kexec_protect_crashkres(void)
> +{
> + kexec_mark_crashkres(true);
> +}
> +
> +void arch_kexec_unprotect_crashkres(void)
> +{
> + kexec_mark_crashkres(false);
> +}
> +#endif
> --
> 2.5.0
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH 3/4] f2fs: avoid f2fs_lock_op in f2fs_write_begin
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Thursday, December 24, 2015 10:15 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 3/4] f2fs: avoid f2fs_lock_op in f2fs_write_begin
>
> If f2fs_write_begin is to update data, we can bypass calling f2fs_lock_op() in
> order to avoid the checkpoint latency in the write syscall.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/data.c | 43 ++-
> 1 file changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 49092da..d53cf4f 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1418,10 +1418,16 @@ static int prepare_write_begin(struct f2fs_sb_info
> *sbi,
> pgoff_t index = page->index;
> struct dnode_of_data dn;
> struct page *ipage;
> + bool locked = false;
> + struct extent_info ei;
> int err = 0;
>
> - f2fs_lock_op(sbi);
> -
> + if (f2fs_has_inline_data(inode) ||
> + (pos & PAGE_CACHE_MASK) >= i_size_read(inode)) {
> + f2fs_lock_op(sbi);
> + locked = true;
> + }
> +restart:
> /* check inline_data */
> ipage = get_node_page(sbi, inode->i_ino);
> if (IS_ERR(ipage)) {
> @@ -1436,22 +1442,41 @@ static int prepare_write_begin(struct f2fs_sb_info
> *sbi,
> read_inline_data(page, ipage);
> set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
> sync_inode_page();
> - goto done;
> } else {
> err = f2fs_convert_inline_page(, page);
> if (err)
> - goto err_out;
> + goto out;
> + err = f2fs_get_block(, index);
Seems after f2fs_convert_inline_page, data_blkaddr and node_changed should
have been set, so f2fs_get_block could be removed here.
> + }
> + } else if (locked) {
> + err = f2fs_get_block(, index);
> + } else {
> + if (f2fs_lookup_extent_cache(inode, index, )) {
> + dn.data_blkaddr = ei.blk + index - ei.fofs;
> + } else {
> + bool restart = false;
> +
> + /* hole case */
> + err = get_dnode_of_data(, index, LOOKUP_NODE);
Better to handle error case like -ENOMEM or -EIO.
Thanks,
> + if (err || (!err && dn.data_blkaddr == NULL_ADDR))
> + restart = true;
> + if (restart) {
> + f2fs_put_dnode();
> + f2fs_lock_op(sbi);
> + locked = true;
> + goto restart;
> + }
> }
> }
> - err = f2fs_get_block(, index);
> -done:
> +
> /* convert_inline_page can make node_changed */
> *blk_addr = dn.data_blkaddr;
> *node_changed = dn.node_changed;
> -err_out:
> +out:
> f2fs_put_dnode();
> unlock_out:
> - f2fs_unlock_op(sbi);
> + if (locked)
> + f2fs_unlock_op(sbi);
> return err;
> }
>
> @@ -1488,7 +1513,7 @@ repeat:
>
> *pagep = page;
>
> - err = prepare_write_begin(sbi, page, pos + len,
> + err = prepare_write_begin(sbi, page, pos, len,
> , _balance);
> if (err)
> goto fail;
> --
> 2.5.4 (Apple Git-61)
>
>
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH 4/4] f2fs: call f2fs_balance_fs only when node was changed
> -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Thursday, December 24, 2015 3:14 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH 4/4] f2fs: call f2fs_balance_fs only when node > was changed > > Change log v2: > - add dio case > > >From c2d16a526371954671f9c8cff5f09f9d230f7993 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim > Date: Tue, 22 Dec 2015 13:23:35 -0800 > Subject: [PATCH] f2fs: call f2fs_balance_fs only when node was changed > > If user tries to update or read data, we don't need to call f2fs_balance_fs > which triggers f2fs_gc, which increases unnecessary long latency. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev] [PATCH 2/4] f2fs: return early when trying to read null nid
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Thursday, December 24, 2015 10:15 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 2/4] f2fs: return early when trying to read null
> nid
>
> If get_node_page() gets zero nid, we can return early without getting a wrong
> page. For example, get_dnode_of_data() can try to do that.
Good catch!
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/node.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 341de5d..e17128d 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1059,6 +1059,9 @@ struct page *get_node_page(struct f2fs_sb_info *sbi,
> pgoff_t nid)
> {
> struct page *page;
> int err;
> +
> + if (!nid)
> + return ERR_PTR(-ENOENT);
How about expand to check upper and lower boundary:
if (check_nid_range)
return ERR_PTR(-ENOENT);
Thanks,
> repeat:
> page = grab_cache_page(NODE_MAPPING(sbi), nid);
> if (!page)
> --
> 2.5.4 (Apple Git-61)
>
>
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: nsp-gpio: fix type of iterator
On 12/24/2015 4:05 AM, Ray Jui wrote:
> + Reddy
>
> On 12/23/2015 2:37 AM, Andrzej Hajda wrote:
>> Iterator i declared as unsigned is always non-negative so the
>> loop will never end.
>>
>> The problem has been detected using proposed semantic patch
>> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
>> b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
>> index 34648f6..ad5b04c 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
>> @@ -439,7 +439,8 @@ static int nsp_gpio_set_strength(struct nsp_gpio *chip,
>> unsigned gpio,
>> static int nsp_gpio_get_strength(struct nsp_gpio *chip, unsigned gpio,
>> u16 *strength)
>> {
>> -unsigned int i, offset, shift;
>> +unsigned int offset, shift;
>> +int i;
>> u32 val;
>> unsigned long flags;
>>
>>
> The fix is a valid fix. And at the same time it exposes other potential
> issues in the driver. I just found the loop used in _set_strength and
> _get_strength is inconsistent:
>
> In _set_strength:
>
> 427 for (i = GPIO_DRV_STRENGTH_BITS; i > 0; i--) {
>
> For i to start at GPIO_DRV_STRENGTH_BITS, it seems to be wrong.
>
> 428 val = readl(chip->io_ctrl + offset);
> 429 val &= ~BIT(shift);
> 430 val |= ((strength >> (i-1)) & 0x1) << shift;
> 431 writel(val, chip->io_ctrl + offset);
> 432 offset += 4;
> 433 }
>
> In _get_strength:
>
> 451 for (i = (GPIO_DRV_STRENGTH_BITS - 1); i >= 0; i--) {
> 452 val = readl(chip->io_ctrl + offset) & BIT(shift);
> 453 val >>= shift;
> 454 *strength += (val << i);
> 455 offset += 4;
> 456 }
>
> Reddy, could you please review and comment?
Hi Ray,
The logic is correct. The drive strength has three bits
distributed in three registers. In one case the "-1" is in for loop
initialization and the other case it is in the for loop body. The fix looks
good.
Thanks
Dhananjay
> Thanks,
>
> Ray
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon: gpio: Fix typo in comment (cosmetic)
Signed-off-by: Moritz Fischer --- drivers/extcon/extcon-gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 279ff8f..d023789 100644 --- a/drivers/extcon/extcon-gpio.c +++ b/drivers/extcon/extcon-gpio.c @@ -126,7 +126,7 @@ static int gpio_extcon_probe(struct platform_device *pdev) INIT_DELAYED_WORK(>work, gpio_extcon_work); /* -* Request the interrput of gpio to detect whether external connector +* Request the interrupt of gpio to detect whether external connector * is attached or detached. */ ret = devm_request_any_context_irq(>dev, data->irq, -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: gpio: Fix typo in comment.
On Wed, Dec 23, 2015 at 9:28 PM, Moritz Fischer wrote: > Signed-off-by: Moritz Fischer > --- > drivers/extcon/extcon-gpio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c > index 279ff8f..0af543a 100644 > --- a/drivers/extcon/extcon-gpio.c > +++ b/drivers/extcon/extcon-gpio.c > @@ -126,7 +126,7 @@ static int gpio_extcon_probe(struct platform_device *pdev) > INIT_DELAYED_WORK(>work, gpio_extcon_work); > > /* > -* Request the interrput of gpio to detect whether external connector > +* Request the interupt of gpio to detect whether external connector Wow ... I'm awesome ... sorry for the noise ... will resubmit... Cheers, Moritz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: gpio: Fix typo in comment.
Signed-off-by: Moritz Fischer --- drivers/extcon/extcon-gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c index 279ff8f..0af543a 100644 --- a/drivers/extcon/extcon-gpio.c +++ b/drivers/extcon/extcon-gpio.c @@ -126,7 +126,7 @@ static int gpio_extcon_probe(struct platform_device *pdev) INIT_DELAYED_WORK(>work, gpio_extcon_work); /* -* Request the interrput of gpio to detect whether external connector +* Request the interupt of gpio to detect whether external connector * is attached or detached. */ ret = devm_request_any_context_irq(>dev, data->irq, -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix v2 1/5] x86/irq: Do not reuse struct apic_chip_data.old_domain as temporary buffer
Jiang, On Wed, Dec 23, 2015 at 10:13:26PM +0800, Jiang Liu wrote: > Function __assign_irq_vector() makes use of apic_chip_data.old_domain > as a temporary buffer, which causes trouble to rollback logic in case of > failure. So use a dedicated temporary buffer for __assign_irq_vector(). > > Signed-off-by: Jiang Liu > --- > arch/x86/kernel/apic/vector.c |9 + > 1 file changed, 5 insertions(+), 4 deletions(-) [...] I tried this patch and the rest in the series but unfortunately the bug is still present. [ 10.184649] wlan0: authenticated [ 10.187883] wlan0: associate with 02:1a:11:fb:90:1c (try 1/3) [ 10.191574] do_IRQ: 0.35 No irq handler for vector [ 10.191589] do_IRQ: 0.35 No irq handler for vector [ 10.198159] do_IRQ: 0.35 No irq handler for vector [ 10.198165] do_IRQ: 0.35 No irq handler for vector [ 10.200534] wlan0: RX AssocResp from 02:1a:11:fb:90:1c (capab=0x431 status=0 aid=1) [ 10.204611] wlan0: associated [ 10.238883] do_IRQ: 0.35 No irq handler for vector [ 10.238892] do_IRQ: 0.35 No irq handler for vector [ 10.280716] do_IRQ: 0.35 No irq handler for vector [ 10.281083] do_IRQ: 0.35 No irq handler for vector [ 10.286484] do_IRQ: 0.35 No irq handler for vector ... -- - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] watchdog: tangox: Print info message using pointer to platform device
The device pointer in struct watchdog_device should not be used by drivers and may be removed in the near future. Use the platform device pointer for info messages instead. Signed-off-by: Guenter Roeck --- drivers/watchdog/tangox_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c index b9ee6246e7c2..709c1ed6fd79 100644 --- a/drivers/watchdog/tangox_wdt.c +++ b/drivers/watchdog/tangox_wdt.c @@ -184,7 +184,7 @@ static int tangox_wdt_probe(struct platform_device *pdev) if (err) dev_warn(>dev, "failed to register restart handler\n"); - dev_info(dev->wdt.dev, "SMP86xx/SMP87xx watchdog registered\n"); + dev_info(>dev, "SMP86xx/SMP87xx watchdog registered\n"); return 0; } -- 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/
[PATCH 5/5] watchdog: qcom-wdt: Do not set 'dev' in struct watchdog_device
The 'dev' pointer in struct watchdog_device is set by the watchdog core when registering the watchdog device and not by the driver. It points to the watchdog device, not its parent. Signed-off-by: Guenter Roeck --- drivers/watchdog/qcom-wdt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c index aa7105d32c02..424f9a952fee 100644 --- a/drivers/watchdog/qcom-wdt.c +++ b/drivers/watchdog/qcom-wdt.c @@ -164,7 +164,6 @@ static int qcom_wdt_probe(struct platform_device *pdev) goto err_clk_unprepare; } - wdt->wdd.dev = >dev; wdt->wdd.info = _wdt_info; wdt->wdd.ops = _wdt_ops; wdt->wdd.min_timeout = 1; -- 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/
[PATCH 0/5] watchdog: Do not use 'dev' from watchdog_device in watchdog drivers
The 'dev' variable in watchdog drivers has a different lifetime than the watchdog character device and should therefore not be used by watchdog drivers. Some of the drivers use the variable to print kernel messages. Those are either dropped or converted to use pr_ functions. One driver sets the variable during initialization to the watchdog driver's parent device, which is wrong and also removed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] watchdog: gpio: Do not use device pointer from struct watchdog_device
The device pointer in struct watchdog_device has a different lifetime
than the driver code and should not be used in drivers. Use pr_crit
instead of dev_crit.
Signed-off-by: Guenter Roeck
---
drivers/watchdog/gpio_wdt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index 035c2387b846..44df983a1232 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -9,6 +9,8 @@
* (at your option) any later version.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -54,7 +56,8 @@ static void gpio_wdt_hwping(unsigned long data)
if (priv->armed && time_after(jiffies, priv->last_jiffies +
msecs_to_jiffies(wdd->timeout * 1000))) {
- dev_crit(wdd->dev, "Timer expired. System will reboot soon!\n");
+ pr_crit("watchdog%d: Timer expired. System will reboot soon!\n",
+ wdd->id);
return;
}
--
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/
[PATCH 4/5] watchdog: mena21: Do not use device pointer from struct watchdog_device
The device pointer in struct watchdog_device has a different lifetime
than the driver code and should not be used in drivers. Use pr_err
instead of dev_err.
Signed-off-by: Guenter Roeck
---
drivers/watchdog/mena21_wdt.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/mena21_wdt.c b/drivers/watchdog/mena21_wdt.c
index 098fa9c34d6d..f0dc794d0fda 100644
--- a/drivers/watchdog/mena21_wdt.c
+++ b/drivers/watchdog/mena21_wdt.c
@@ -7,6 +7,9 @@
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -100,13 +103,14 @@ static int a21_wdt_set_timeout(struct watchdog_device
*wdt,
struct a21_wdt_drv *drv = watchdog_get_drvdata(wdt);
if (timeout != 1 && timeout != 30) {
- dev_err(wdt->dev, "Only 1 and 30 allowed as timeout\n");
+ pr_err("watchdog%d: Only 1 and 30 allowed as timeout\n",
+ wdt->id);
return -EINVAL;
}
if (timeout == 30 && wdt->timeout == 1) {
- dev_err(wdt->dev,
- "Transition from fast to slow mode not allowed\n");
+ pr_err("watchdog%d: Transition from fast to slow mode not
allowed\n",
+ wdt->id);
return -EINVAL;
}
--
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/
[PATCH 1/5] watchdog: bcm2835_wdt: Drop log message if watchdog is stopped
Stopping a watchdog is a normal operation and does not warrant a log message. Signed-off-by: Guenter Roeck --- drivers/watchdog/bcm2835_wdt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c index 8a5ce5b5a0b6..2e6164c4abc0 100644 --- a/drivers/watchdog/bcm2835_wdt.c +++ b/drivers/watchdog/bcm2835_wdt.c @@ -79,7 +79,6 @@ static int bcm2835_wdt_stop(struct watchdog_device *wdog) struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog); writel_relaxed(PM_PASSWORD | PM_RSTC_RESET, wdt->base + PM_RSTC); - dev_info(wdog->dev, "Watchdog timer stopped"); return 0; } -- 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: [PATCH 0/7][v4] Add OTG support for FSL socs
> -Original Message- > From: Jun Li [mailto:jun...@nxp.com] > Sent: Wednesday, December 23, 2015 10:02 PM > To: Mehresh Ramneek-B31383 ; Felipe > Balbi ; linux-kernel@vger.kernel.org > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > u...@vger.kernel.org > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs > > > > > -Original Message- > > From: Ramneek Mehresh [mailto:ramneek.mehr...@freescale.com] > > Sent: Wednesday, December 23, 2015 8:20 PM > > To: Jun Li ; Felipe Balbi ; linux- > > ker...@vger.kernel.org > > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > > u...@vger.kernel.org > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs > > > > > > > > > -Original Message- > > > From: Jun Li [mailto:jun...@nxp.com] > > > Sent: Wednesday, December 23, 2015 10:36 AM > > > To: Felipe Balbi ; Mehresh Ramneek-B31383 > > > ; linux-kernel@vger.kernel.org > > > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > > > u...@vger.kernel.org > > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs > > > > > > Hi > > > > > > > -Original Message- > > > > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > > > > ow...@vger.kernel.org] On Behalf Of Felipe Balbi > > > > Sent: Wednesday, December 23, 2015 2:21 AM > > > > To: Ramneek Mehresh ; linux- > > > > ker...@vger.kernel.org > > > > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > > > > u...@vger.kernel.org > > > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs > > > > > > > > > > > > Hi, > > > > > > > > Ramneek Mehresh writes: > > > > >> -Original Message- > > > > >> From: Felipe Balbi [mailto:ba...@ti.com] > > > > >> Sent: Saturday, October 10, 2015 3:04 AM > > > > >> To: Mehresh Ramneek-B31383 > ; > > > linux- > > > > >> ker...@vger.kernel.org > > > > >> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; > > > > >> linux- u...@vger.kernel.org; Mehresh Ramneek-B31383 > > > > >> > > > > >> Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs > > > > >> > > > > >> Felipe Balbi writes: > > > > >> > > > > >> > Hi, > > > > >> > > > > > >> > Ramneek Mehresh writes: > > > > >> >> Add support for otg for all freescale socs having internal > > > > >> >> usb > > phy. > > > > >> >> > > > > >> >> Ramneek Mehresh (7): > > > > >> >> usb:fsl:otg: Make fsl otg driver as tristate > > > > >> >> usb:fsl:otg: Add controller version based ULPI and UTMI phy > > > > >> >> usb:fsl:otg: Add support to add/remove usb host driver > > > > >> >> usb:fsl:otg: Signal host drv when host is otg > > > > >> >> usb:fsl:otg: Modify otg_event to start host drv > > > > >> >> usb:fsl:otg: Combine host/gadget start/resume for ID change > > > > >> >> usb:fsl:otg: Add host-gadget drv sync delay > > > > >> > > > > > >> > Unless Alan's okay with the host side changes, I can't accept > > > > >> > any of these. However, I must say some of the flags you add > > > > >> > here already exist in some way, shape or form. For example, > > > > >> > look at > > > > is_b_host flag. > > > > >> > > > > > > > > > > Could you please be more specific...which flag you think that I > > > > >should remove/I'm re-defining. The flags I'm defining are: > > > > > > > > > > have_hcd : defined in fsl specific structure for fsl specific > > > > > use-case > > > > > > > > > > had_hcd: defined in fsl specific structure for fsl specific > > > > > use-case > > > > > > > > > > is_otg : defined in include/linux/usb.h > > > > > > > > > > Are you suggesting using otg_port or is_b_host instead of is_otg? > > > > > > > > > > As I understand, is_b_host is specifically to check if an otg B > > > > > device is in host mode...correct? I just need a flag to check > > > > > if a controller is capable of otg operations? That's why defined > > "is_otg" > > > > > flag. Please suggest. > > > > > > > > no, I don't know why I made that comment. You could use otg_port, > > > > but that wouldn't look very clean. Can you resend with Alan's ack, > > > > then I'll move this series into testing/next. > > > > > > > > -- > > > > balbi > > > > > > Can you directly put the change_hcd_work in its phy driver(phy-fsl- > > usb.c)? > > > Then add/remove hcd will not through ehci_fsl_drv_suspend/resume, > > > With this, you can make it work without a new flag "is_otg". > > > > > change_hcd_work() changes host controller mode, and hence, should be > > in host controller driver. > > Reasonable, but most of OTG stuff not belong to phy actully, I see phy-msm- > usb.c directly do hcd add/remove for OTG. > Thanks for your input...but I still strongly believe that controller specific data structure and flags should remain inside the controller drv...to make things more maintainable. I'm adding and removing host controller driver on the basis of the id change value for fsl controller drv... > > To move this to phy driver (just to avoid usage of a single flag) > > won't be a good idea. > > I
[PATCH -next] MIPS: VDSO: Fix build error with binutils 2.24 and earlier
Commit 2a037f310bab ("MIPS: VDSO: Fix build error") tries to fix a build
error seen with binutils 2.24 and earlier. However, the fix does not work,
and again results in the already known build errors if the kernel is built
with an earlier version of binutils.
CC arch/mips/vdso/gettimeofday.o
/tmp/ccnOVbHT.s: Assembler messages:
/tmp/ccnOVbHT.s:50: Error: can't resolve `_start' {*UND* section} - `L0 {.text
section}
/tmp/ccnOVbHT.s:374: Error: can't resolve `_start' {*UND* section} - `L0 {.text
section}
scripts/Makefile.build:258: recipe for target 'arch/mips/vdso/gettimeofday.o'
failed
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
Fixes: 2a037f310bab ("MIPS: VDSO: Fix build error")
Cc: Qais Yousef
Signed-off-by: Guenter Roeck
---
Tested with binutils 2.25 and 2.22.
arch/mips/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 018f8c7b94f2..14568900fc1d 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -26,7 +26,7 @@ aflags-vdso := $(ccflags-vdso) \
# the comments on that file.
#
ifndef CONFIG_CPU_MIPSR6
- ifeq ($(call ld-ifversion, -lt, 2250, y),)
+ ifeq ($(call ld-ifversion, -lt, 2250, y),y)
$(warning MIPS VDSO requires binutils >= 2.25)
obj-vdso-y := $(filter-out gettimeofday.o, $(obj-vdso-y))
ccflags-vdso += -DDISABLE_MIPS_VDSO
--
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/
Running arm:versatile_defconfig with qemu in linux-next
Hi all, various versatile and realview configurations fail to run for me with qemu (2.5) in linux-next. Some of those are qemu configurations I collected from various sources, so I guess I am on my own there. However, the following standard configurations no longer work. arm:versatileab:versatile_defconfig arm:versatilepb:versatile_defconfig I can no longer get realview-eb-mpcore and realview-eb to work either, but, again, that is with a qemu specific configuration. I tried to bisect, but there have been too many related changes in the code for it to succeed; some of the bisect attempts don't even compile, others fail due to different problems. Is it known if versatile_defconfig in linux-next runs on a real system ? If so, any idea what it might take to get it to work again with qemu ? Thanks, 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/
[PATCH] staging: android: sync.c: Changed the ways nullptrs were being checked
Removed all checkpatch.pl CHECKs that suggested to check NULL by
!obj instead of obj == NULL.
Signed-off-by: Chase Metzger
---
drivers/staging/android/sync.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f83e00c..5413f28 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -43,7 +43,7 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
return NULL;
obj = kzalloc(size, GFP_KERNEL);
- if (obj == NULL)
+ if (!obj)
return NULL;
kref_init(>kref);
@@ -130,7 +130,7 @@ struct sync_pt *sync_pt_create(struct sync_timeline *obj,
int size)
return NULL;
pt = kzalloc(size, GFP_KERNEL);
- if (pt == NULL)
+ if (!pt)
return NULL;
spin_lock_irqsave(>child_list_lock, flags);
@@ -155,7 +155,7 @@ static struct sync_fence *sync_fence_alloc(int size, const
char *name)
struct sync_fence *fence;
fence = kzalloc(size, GFP_KERNEL);
- if (fence == NULL)
+ if (!fence)
return NULL;
fence->file = anon_inode_getfile("sync_fence", _fence_fops,
@@ -193,7 +193,7 @@ struct sync_fence *sync_fence_create(const char *name,
struct sync_pt *pt)
struct sync_fence *fence;
fence = sync_fence_alloc(offsetof(struct sync_fence, cbs[1]), name);
- if (fence == NULL)
+ if (!fence)
return NULL;
fence->num_fences = 1;
@@ -215,7 +215,7 @@ struct sync_fence *sync_fence_fdget(int fd)
{
struct file *file = fget(fd);
- if (file == NULL)
+ if (!file)
return NULL;
if (file->f_op != _fence_fops)
@@ -262,7 +262,7 @@ struct sync_fence *sync_fence_merge(const char *name,
unsigned long size = offsetof(struct sync_fence, cbs[num_fences]);
fence = sync_fence_alloc(size, name);
- if (fence == NULL)
+ if (!fence)
return NULL;
atomic_set(>status, num_fences);
@@ -583,14 +583,14 @@ static long sync_fence_ioctl_merge(struct sync_fence
*fence, unsigned long arg)
}
fence2 = sync_fence_fdget(data.fd2);
- if (fence2 == NULL) {
+ if (!fence2) {
err = -ENOENT;
goto err_put_fd;
}
data.name[sizeof(data.name) - 1] = '\0';
fence3 = sync_fence_merge(data.name, fence, fence2);
- if (fence3 == NULL) {
+ if (!fence3) {
err = -ENOMEM;
goto err_put_fence2;
}
@@ -666,7 +666,7 @@ static long sync_fence_ioctl_fence_info(struct sync_fence
*fence,
size = 4096;
data = kzalloc(size, GFP_KERNEL);
- if (data == NULL)
+ if (!data)
return -ENOMEM;
strlcpy(data->name, fence->name, sizeof(data->name));
--
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: [RFC PATCH v2 2/3] thread_local_abi: wire up x86 32/64 system call
On December 22, 2015 10:02:12 AM PST, Mathieu Desnoyers
wrote:
>Wire up the thread local ABI on x86 32/64. Call the
>thread_local_abi_handle_notify_resume() function on return to
>userspace if TIF_NOTIFY_RESUME thread flag is set.
>
>This provides an ABI improving the speed of a getcpu operation
>on x86 by removing the need to perform a function call, "lsl"
>instruction, or system call on the fast path.
>
>Signed-off-by: Mathieu Desnoyers
>CC: Russell King
>CC: Catalin Marinas
>CC: Will Deacon
>CC: Thomas Gleixner
>CC: Paul Turner
>CC: Andrew Hunter
>CC: Peter Zijlstra
>CC: Andy Lutomirski
>CC: Andi Kleen
>CC: Dave Watson
>CC: Chris Lameter
>CC: Ingo Molnar
>CC: Ben Maurer
>CC: Steven Rostedt
>CC: "Paul E. McKenney"
>CC: Josh Triplett
>CC: Linus Torvalds
>CC: Andrew Morton
>CC: Thomas Gleixner
>CC: linux-...@vger.kernel.org
>---
> arch/x86/entry/common.c| 2 ++
> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
> arch/x86/entry/syscalls/syscall_64.tbl | 1 +
> 3 files changed, 4 insertions(+)
>
>diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
>index a89fdbc..222cacf 100644
>--- a/arch/x86/entry/common.c
>+++ b/arch/x86/entry/common.c
>@@ -249,6 +249,8 @@ static void exit_to_usermode_loop(struct pt_regs
>*regs, u32 cached_flags)
> if (cached_flags & _TIF_NOTIFY_RESUME) {
> clear_thread_flag(TIF_NOTIFY_RESUME);
> tracehook_notify_resume(regs);
>+ if (thread_local_abi_active(current))
>+ thread_local_abi_handle_notify_resume(current);
Every caller seems likely to duplicate this pattern; why not make the call
itself a static inline containing this check and call (or no-op if compiled
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: [f2fs-dev] [PATCH 2/4 v2] f2fs: avoid unnecessary f2fs_gc for dir operations
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Thursday, December 24, 2015 10:13 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 2/4 v2] f2fs: avoid unnecessary f2fs_gc for
> dir operations
>
> Hi Chao,
>
> Right.
> But, in the rename path, we still need to do f2fs_balance_fs, since it
> produces
> another dirty node page in the mean time.
That's right.
>
> How about this?
>
> From bbc5bf8f6c940cd75a4d71ce40ce4bd3f647a823 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim
> Date: Tue, 22 Dec 2015 11:56:08 -0800
> Subject: [PATCH] f2fs: avoid unnecessary f2fs_gc for dir operations
>
> The f2fs_balance_fs doesn't need to cover f2fs_new_inode or f2fs_find_entry
> works.
>
> Signed-off-by: Jaegeuk Kim
Reviewed-by: Chao Yu
Thanks,
> ---
> fs/f2fs/namei.c | 34 ++
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 2c32110..4e27c5c 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -128,8 +128,6 @@ static int f2fs_create(struct inode *dir, struct dentry
> *dentry, umode_t
> mode,
> nid_t ino = 0;
> int err;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -142,6 +140,8 @@ static int f2fs_create(struct inode *dir, struct dentry
> *dentry, umode_t
> mode,
> inode->i_mapping->a_ops = _dblock_aops;
> ino = inode->i_ino;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -288,12 +288,13 @@ static int f2fs_unlink(struct inode *dir, struct dentry
> *dentry)
> int err = -ENOENT;
>
> trace_f2fs_unlink_enter(dir, dentry);
> - f2fs_balance_fs(sbi);
>
> de = f2fs_find_entry(dir, >d_name, );
> if (!de)
> goto fail;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = acquire_orphan_inode(sbi);
> if (err) {
> @@ -341,8 +342,6 @@ static int f2fs_symlink(struct inode *dir, struct dentry
> *dentry,
> if (len > dir->i_sb->s_blocksize)
> return -ENAMETOOLONG;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, S_IFLNK | S_IRWXUGO);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -353,6 +352,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry
> *dentry,
> inode->i_op = _symlink_inode_operations;
> inode->i_mapping->a_ops = _dblock_aops;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -433,8 +434,6 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
> *dentry, umode_t
> mode)
> struct inode *inode;
> int err;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, S_IFDIR | mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -444,6 +443,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
> *dentry, umode_t
> mode)
> inode->i_mapping->a_ops = _dblock_aops;
> mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_HIGH_ZERO);
>
> + f2fs_balance_fs(sbi);
> +
> set_inode_flag(F2FS_I(inode), FI_INC_LINK);
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> @@ -481,8 +482,6 @@ static int f2fs_mknod(struct inode *dir, struct dentry
> *dentry,
> struct inode *inode;
> int err = 0;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -490,6 +489,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry
> *dentry,
> init_special_inode(inode, inode->i_mode, rdev);
> inode->i_op = _special_inode_operations;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -516,9 +517,6 @@ static int __f2fs_tmpfile(struct inode *dir, struct
> dentry *dentry,
> struct inode *inode;
> int err;
>
> - if (!whiteout)
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -532,6 +530,8 @@ static int __f2fs_tmpfile(struct inode *dir, struct
> dentry *dentry,
> inode->i_mapping->a_ops = _dblock_aops;
> }
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = acquire_orphan_inode(sbi);
> if (err)
> @@ -604,8 +604,6 @@ static int f2fs_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> goto out;
> }
>
> - f2fs_balance_fs(sbi);
> -
> old_entry = f2fs_find_entry(old_dir, _dentry->d_name, _page);
> if (!old_entry)
> goto out;
> @@
Re: [PATCH 1/2] bonding: drop unused to_dev macro in bond_sysfs.c
From: Geliang Tang Date: Wed, 23 Dec 2015 20:42:20 +0800 > to_dev is not used anymore so drop it. > > Signed-off-by: Geliang Tang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] bridge: use kobj_to_dev instead of to_dev
From: Geliang Tang Date: Wed, 23 Dec 2015 20:42:21 +0800 > kobj_to_dev has been defined in linux/device.h, so I replace to_dev > with it. > > Signed-off-by: Geliang Tang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 1/3] crypto: KEYS: convert public key and digsig asym to the akcipher api
This patch converts the module verification code to the new akcipher API.
Signed-off-by: Tadeusz Struk
---
crypto/asymmetric_keys/Kconfig|2
crypto/asymmetric_keys/Makefile |7 -
crypto/asymmetric_keys/pkcs7_parser.c | 12 +-
crypto/asymmetric_keys/pkcs7_trust.c |2
crypto/asymmetric_keys/pkcs7_verify.c |2
crypto/asymmetric_keys/public_key.c | 64 +++--
crypto/asymmetric_keys/public_key.h | 36 -
crypto/asymmetric_keys/rsa.c | 213 +++--
crypto/asymmetric_keys/x509_cert_parser.c | 37 +
crypto/asymmetric_keys/x509_public_key.c | 17 +-
crypto/asymmetric_keys/x509_rsakey.asn1 |4 -
include/crypto/public_key.h | 34 +
12 files changed, 134 insertions(+), 296 deletions(-)
delete mode 100644 crypto/asymmetric_keys/public_key.h
delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 4870f28..905d745 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -22,7 +22,7 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
config PUBLIC_KEY_ALGO_RSA
tristate "RSA public-key algorithm"
- select MPILIB
+ select CRYPTO_RSA
help
This option enables support for the RSA algorithm (PKCS#1, RFC3447).
diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
index cd1406f..b78a194 100644
--- a/crypto/asymmetric_keys/Makefile
+++ b/crypto/asymmetric_keys/Makefile
@@ -16,21 +16,18 @@ obj-$(CONFIG_X509_CERTIFICATE_PARSER) += x509_key_parser.o
x509_key_parser-y := \
x509-asn1.o \
x509_akid-asn1.o \
- x509_rsakey-asn1.o \
x509_cert_parser.o \
x509_public_key.o
$(obj)/x509_cert_parser.o: \
$(obj)/x509-asn1.h \
- $(obj)/x509_akid-asn1.h \
- $(obj)/x509_rsakey-asn1.h
+ $(obj)/x509_akid-asn1.h
+
$(obj)/x509-asn1.o: $(obj)/x509-asn1.c $(obj)/x509-asn1.h
$(obj)/x509_akid-asn1.o: $(obj)/x509_akid-asn1.c $(obj)/x509_akid-asn1.h
-$(obj)/x509_rsakey-asn1.o: $(obj)/x509_rsakey-asn1.c $(obj)/x509_rsakey-asn1.h
clean-files+= x509-asn1.c x509-asn1.h
clean-files+= x509_akid-asn1.c x509_akid-asn1.h
-clean-files+= x509_rsakey-asn1.c x509_rsakey-asn1.h
#
# PKCS#7 message handling
diff --git a/crypto/asymmetric_keys/pkcs7_parser.c
b/crypto/asymmetric_keys/pkcs7_parser.c
index 758acab..12912c1 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
#include "pkcs7-asn1.h"
@@ -44,7 +44,7 @@ struct pkcs7_parse_context {
static void pkcs7_free_signed_info(struct pkcs7_signed_info *sinfo)
{
if (sinfo) {
- mpi_free(sinfo->sig.mpi[0]);
+ kfree(sinfo->sig.s);
kfree(sinfo->sig.digest);
kfree(sinfo->signing_cert_id);
kfree(sinfo);
@@ -616,16 +616,14 @@ int pkcs7_sig_note_signature(void *context, size_t hdrlen,
const void *value, size_t vlen)
{
struct pkcs7_parse_context *ctx = context;
- MPI mpi;
BUG_ON(ctx->sinfo->sig.pkey_algo != PKEY_ALGO_RSA);
- mpi = mpi_read_raw_data(value, vlen);
- if (!mpi)
+ ctx->sinfo->sig.s = kmemdup(value, vlen, GFP_KERNEL);
+ if (!ctx->sinfo->sig.s)
return -ENOMEM;
- ctx->sinfo->sig.mpi[0] = mpi;
- ctx->sinfo->sig.nr_mpi = 1;
+ ctx->sinfo->sig.s_size = vlen;
return 0;
}
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index 90d6d47..3bbdcc7 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
/**
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c
b/crypto/asymmetric_keys/pkcs7_verify.c
index 325575c..f5db137 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -16,7 +16,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
/*
diff --git a/crypto/asymmetric_keys/public_key.c
b/crypto/asymmetric_keys/public_key.c
index 6db4c01..b383629 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -18,24 +18,16 @@
#include
#include
#include
-#include "public_key.h"
+#include
MODULE_LICENSE("GPL");
const char *const pkey_algo_name[PKEY_ALGO__LAST] = {
- [PKEY_ALGO_DSA] = "DSA",
- [PKEY_ALGO_RSA] = "RSA",
+ [PKEY_ALGO_DSA] = "dsa",
+ [PKEY_ALGO_RSA] = "rsa",
};
EXPORT_SYMBOL_GPL(pkey_algo_name);
-const struct public_key_algorithm *pkey_algo[PKEY_ALGO__LAST] = {
-#if
[PATCH v5 2/3] integrity: convert digsig to akcipher api
Convert asymmetric_verify to akcipher api.
Signed-off-by: Tadeusz Struk
---
security/integrity/Kconfig |1 +
security/integrity/digsig_asymmetric.c | 10 +++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 73c457b..f0b2463 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -36,6 +36,7 @@ config INTEGRITY_ASYMMETRIC_KEYS
select ASYMMETRIC_KEY_TYPE
select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
select PUBLIC_KEY_ALGO_RSA
+select CRYPTO_RSA
select X509_CERTIFICATE_PARSER
help
This option enables digital signature verification using
diff --git a/security/integrity/digsig_asymmetric.c
b/security/integrity/digsig_asymmetric.c
index 4fec181..5629372 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -92,13 +92,9 @@ int asymmetric_verify(struct key *keyring, const char *sig,
pks.pkey_hash_algo = hdr->hash_algo;
pks.digest = (u8 *)data;
pks.digest_size = datalen;
- pks.nr_mpi = 1;
- pks.rsa.s = mpi_read_raw_data(hdr->sig, siglen);
-
- if (pks.rsa.s)
- ret = verify_signature(key, );
-
- mpi_free(pks.rsa.s);
+ pks.s = hdr->sig;
+ pks.s_size = siglen;
+ ret = verify_signature(key, );
key_put(key);
pr_debug("%s() = %d\n", __func__, ret);
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL REQUEST] one more md fix for 4.4-rc
The following changes since commit 9f7e43278605a0daf4edf7025c52c25e9ace6875: Merge tag 'rtc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux (2015-12-20 10:01:11 -0800) are available in the git repository at: git://neil.brown.name/md tags/md/4.4-rc6-fix for you to fetch changes up to 312045eef985b61d74c28047ecd8eca6719d9516: md: remove check for MD_RECOVERY_NEEDED in action_store. (2015-12-21 11:10:06 +1100) One for md fix for 4.4-rc Fix a regression which causes reshape to not start properly sometimes. NeilBrown (1): md: remove check for MD_RECOVERY_NEEDED in action_store. drivers/md/md.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) signature.asc Description: PGP signature
[PATCH v5 3/3] crypto: public_key: remove MPIs from public_key_signature struct
After digsig_asymmetric.c is converted the MPIs can be now
safely removed from the public_key_signature structure.
Signed-off-by: Tadeusz Struk
---
include/crypto/public_key.h | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 50ac875..a1693ed 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -14,7 +14,6 @@
#ifndef _LINUX_PUBLIC_KEY_H
#define _LINUX_PUBLIC_KEY_H
-#include
#include
enum pkey_algo {
@@ -73,20 +72,9 @@ struct public_key_signature {
u8 *s; /* Signature */
u32 s_size; /* Number of bytes in signature */
u8 *digest;
- u8 digest_size; /* Number of bytes in digest */
- u8 nr_mpi; /* Occupancy of mpi[] */
+ u8 digest_size; /* Number of bytes in digest */
enum pkey_algo pkey_algo : 8;
enum hash_algo pkey_hash_algo : 8;
- union {
- MPI mpi[2];
- struct {
- MPI s; /* m^d mod n */
- } rsa;
- struct {
- MPI r;
- MPI s;
- } dsa;
- };
};
extern struct asymmetric_key_subtype public_key_subtype;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 0/3] crypto: KEYS: convert public key to akcipher api
This patch set converts the module verification and digital signature code to the new akcipher API. RSA implementation has been removed from crypto/asymmetric_keys and the new API is used for cryptographic primitives. There is no need for MPI above the akcipher API anymore. Modules can be verified with software as well as HW RSA implementations. Patches generated against cryptodev-2.6 Changes in v5: - Revert back v4 and add a new patch that removes the MPIs from the public_key_signature struct after the asymmetric_verify funtc in digsig is converted as proposed by Herbert. Changes in v4: - Flatten both patches into one to avoid bisect compilation problems. Changes in v3: - Don't include keys/asymmetric-type.h in crypto/public_key.h Changes in v2: - Fix the whey public_key_signature is setup. The pointer s needs to point to the signature instread of the signature_v2_hdr. - Select CRYPTO_RSA when INTEGRITY_ASYMMETRIC_KEYS is selected. --- Tadeusz Struk (3): crypto: KEYS: convert public key and digsig asym to the akcipher api integrity: convert digsig to akcipher api crypto: public_key: remove MPIs from public_key_signature struct crypto/asymmetric_keys/Kconfig|2 crypto/asymmetric_keys/Makefile |7 - crypto/asymmetric_keys/pkcs7_parser.c | 12 +- crypto/asymmetric_keys/pkcs7_trust.c |2 crypto/asymmetric_keys/pkcs7_verify.c |2 crypto/asymmetric_keys/public_key.c | 64 +++-- crypto/asymmetric_keys/public_key.h | 36 - crypto/asymmetric_keys/rsa.c | 213 +++-- crypto/asymmetric_keys/x509_cert_parser.c | 37 + crypto/asymmetric_keys/x509_public_key.c | 17 +- crypto/asymmetric_keys/x509_rsakey.asn1 |4 - include/crypto/public_key.h | 48 +-- security/integrity/Kconfig|1 security/integrity/digsig_asymmetric.c| 10 - 14 files changed, 139 insertions(+), 316 deletions(-) delete mode 100644 crypto/asymmetric_keys/public_key.h delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1 -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] phy: micrel: Fix finding PHY properties in MAC node for KSZ9031.
From: Henri Roosen
Date: Wed, 23 Dec 2015 11:42:29 +0100
> + do {
> + of_node = dev_walker->of_node;
> + dev_walker = dev_walker->parent;
> +
> + } while (!of_node && dev_walker);
Please remove the unnecessary empty line in this loop.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] crypto: KEYS: convert public key and digsig asym to the akcipher api
On 12/23/2015 12:21 PM, Herbert Xu wrote: > Why not just leave the MPIs in the structure and only remove them > by adding a third patch? Right, I think that's a better way of resolving this. v5 on it's way. Thanks, -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power:bq27xxx: fix register numbers of bq27500
On 12/17/2015 04:12 AM, H. Nikolaus Schaller wrote:
bug: according to data sheet some register numbers are wrong.
tested: no
Signed-off-by: H. Nikolaus Schaller
Indeed they are, good catch.
Acked-by: Andrew F. Davis
---
drivers/power/bq27xxx_battery.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/bq27xxx_battery.c b/drivers/power/bq27xxx_battery.c
index e54a125..f9a5f4f 100644
--- a/drivers/power/bq27xxx_battery.c
+++ b/drivers/power/bq27xxx_battery.c
@@ -198,10 +198,10 @@ static u8 bq27500_regs[] = {
INVALID_REG_ADDR, /* TTECP - NA */
0x0c, /* NAC */
0x12, /* LMD(FCC) */
- 0x1e, /* CYCT */
+ 0x2a, /* CYCT */
INVALID_REG_ADDR, /* AE - NA */
- 0x20, /* SOC(RSOC)*/
- 0x2e, /* DCAP(ILMD) */
+ 0x2c, /* SOC(RSOC)*/
+ 0x3c, /* DCAP(ILMD) */
INVALID_REG_ADDR, /* AP - NA */
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] tools build: Make FEATURE_DUMP include makefile
On 2015/12/24 1:58, Jiri Olsa wrote: hi, Changing the contents of the FEATURE-DUMP file, so it looks like: feature-backtrace=1 feature-dwarf=0 feature-fortify-source=1 feature-sync-compare-and-swap=0 This way it could get included in sub projects, so they won't be forced to redo features detection. changing bpf library to use that, so it's not forced to rerun feature detection if compiled within perf. Also available in: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git thanks, jirka Tested-by: Wang Nan For the whole patch set. Thank you. --- Jiri Olsa (5): tools build feature: Fix feature_check_display_code typo tools build feature: Move dwarf post unwind choice output into perf tools build feature: Introduce feature_ass macro tools build feature: Use value assignment form for FEATURE-DUMP file perf build: Use FEATURE-DUMP in bpf subproject tools/build/Makefile.feature | 41 +++-- tools/lib/bpf/Makefile | 4 tools/perf/Makefile.perf | 2 +- tools/perf/config/Makefile | 4 4 files changed, 36 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] hisilicon/dts: Add hi655x pmic dts node
On 2015/12/23 8:46, Mark Brown wrote: > On Mon, Dec 21, 2015 at 02:20:16PM +0800, chenfeng wrote: > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. > ok, thanks for your advice. >> While doing this in driver code, I found that it seems all the vendor >> chip have the voltage table. So I am wondering can we add this into >> the regulator framework. > >> We can add in the function of_get_regulation_constraints to get the >> vset table. > >> I am not sure this is right or not. > > I'm just not convinced it's a good pattern to move this data out to DT, > like I said in my other mail it's making the ABI bigger and I'm not sure > I see much upside over putting the data in a table in DT rather than in > C code. It's more parsing code and more things we really shouldn't > change in future. > ok. I will send the new version soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: A blocksize problem about dax and ext4
> -Original Message-
> From: Cholerae Hu [mailto:cholerae...@gmail.com]
> Sent: Wednesday, December 23, 2015 8:36 PM
> Subject: Re: A blocksize problem about dax and ext4
...
> xfs will silently disable dax when the fs block size is too small,
> i.e. your mmap() operations are backed by page cache in this case.
> Currently the only indication of whether a mapping is DAX backed or
> not is the presence of the VM_MIXEDMAP flag ("mm" in the VmFlags field
> of /proc//smaps)
>
> Did you mean that I should make the blocksize bigger until the mount
> command tell me that dax is enabled?
To really use DAX, the filesystem block size must match the
system CPU's page size, which is probably 4096 bytes.
---
Robert Elliott, HPE Persistent Memory
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/2] power:bq27xxx: fix reading for bq27000 and bq27010
On 12/17/2015 04:12 AM, H. Nikolaus Schaller wrote:
bug: the driver reports funny capacity values:
root@letux:/sys/class/power_supply/bq27000-battery# cat uevent
POWER_SUPPLY_NAME=bq27000-battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_VOLTAGE_NOW=3702000
POWER_SUPPLY_CURRENT_NOW=-464635
POWER_SUPPLY_CAPACITY=1536 <- over 100% is magic
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TEMP=311
POWER_SUPPLY_TIME_TO_FULL_NOW=10440
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CHARGE_FULL=805450
POWER_SUPPLY_CHARGE_NOW=1068
POWER_SUPPLY_CHARGE_FULL_DESIGN=8844998 <- battery has just 1200 mAh
POWER_SUPPLY_CYCLE_COUNT=21
POWER_SUPPLY_ENERGY_NOW=0
POWER_SUPPLY_POWER_AVG=0
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_MANUFACTURER=Texas Instruments
reason: the state of charge and the design capacity register are single
byte only. The design capacity returns the higer order byte.
tested: GTA04 with Openmoko/FIC HF08x battery (using hdq)
Signed-off-by: H. Nikolaus Schaller
---
drivers/power/bq27xxx_battery.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/power/bq27xxx_battery.c b/drivers/power/bq27xxx_battery.c
index 880233c..e54a125 100644
--- a/drivers/power/bq27xxx_battery.c
+++ b/drivers/power/bq27xxx_battery.c
@@ -471,7 +471,10 @@ static int bq27xxx_battery_read_soc(struct
bq27xxx_device_info *di)
{
int soc;
- soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
+ if (di->chip == BQ27000 || di->chip == BQ27010)
+ soc = bq27xxx_read(di, BQ27XXX_REG_SOC, true);
+ else
+ soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
if (soc < 0)
dev_dbg(di->dev, "error reading State-of-Charge\n");
@@ -536,7 +539,10 @@ static int bq27xxx_battery_read_dcap(struct
bq27xxx_device_info *di)
{
int dcap;
- dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
+ if (di->chip == BQ27000 || di->chip == BQ27010)
+ dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, true);
+ else
+ dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
I'm wondering how the I2C versions will be effected by this change, will
we get the right byte when we only read one? Maybe the fix should be
to still read 2-bytes but mask out the right bits from the result? The
data-sheet doesn't seem clear on this.
Well, it is more right than it was before, I'll look for a bq27200 to
test and make changes if needed some other time, but for now:
Acked-by: Andrew F. Davis
if (dcap < 0) {
dev_dbg(di->dev, "error reading initial last measured
discharge\n");
@@ -544,7 +550,7 @@ static int bq27xxx_battery_read_dcap(struct
bq27xxx_device_info *di)
}
if (di->chip == BQ27000 || di->chip == BQ27010)
- dcap *= BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
+ dcap = (dcap << 8) * BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
else
dcap *= 1000;
--
Andrew F. Davis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CONTACT nkigr...@yahoo.com FOR FINANCIAL HELP
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/11] resource: Add System RAM resource type
On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote: > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote: : > > I agree that we can add new interfaces with the type check. This > > 'type' > > may need some clarification since it is an assigned type, which is > > different from I/O resource type. That is, "System RAM" is an I/O > > resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an > > assigned type to a particular range of System RAM. A range may be > > associated with multiple names, so as multiple assigned types. For > > lack of a better idea, I may call it 'assign_type'. I am open for a > > better name. > > Or assigned_type or named_type or so... > > I think we should avoid calling it "type" completely in order to avoid > confusion with the IORESOURCE_* types and call it "desc" or so to mean > description, sort, etc, because the name is also a description of the > resource to a certain degree... Agreed. I will use 'desc'. > > OK, I will try to convert the existing callers with the new interfaces. > > Either that or add the new interfaces, use them in your use case, add > big fat comments explaining that people should use those from now on > when searching by name and add a check to checkpatch to catch future > mis-uses... Sounds good. I will look into it. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4.2 02/13] perf hist: Save raw_data/size for tracepoint events
The raw_data and raw_size fields are to provide tracepoint specific
information. They will be used by dynamic sort keys later.
Signed-off-by: Namhyung Kim
---
Make a copy using memdup()
tools/perf/util/hist.c | 24
tools/perf/util/sort.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 039bb91d0a92..2dcf38a78f08 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -369,6 +369,25 @@ static struct hist_entry *hist_entry__new(struct
hist_entry *template,
if (symbol_conf.use_callchain)
callchain_init(he->callchain);
+ if (he->raw_data) {
+ he->raw_data = memdup(he->raw_data, he->raw_size);
+
+ if (he->raw_data == NULL) {
+ map__put(he->ms.map);
+ if (he->branch_info) {
+ map__put(he->branch_info->from.map);
+ map__put(he->branch_info->to.map);
+ free(he->branch_info);
+ }
+ if (he->mem_info) {
+ map__put(he->mem_info->iaddr.map);
+ map__put(he->mem_info->daddr.map);
+ }
+ free(he->stat_acc);
+ free(he);
+ return NULL;
+ }
+ }
INIT_LIST_HEAD(>pairs.node);
thread__get(he->thread);
}
@@ -487,6 +506,8 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
.branch_info = bi,
.mem_info = mi,
.transaction = sample->transaction,
+ .raw_data = sample->raw_data,
+ .raw_size = sample->raw_size,
};
return hists__findnew_entry(hists, , al, sample_self);
@@ -801,6 +822,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter *iter,
.sym = al->sym,
},
.parent = iter->parent,
+ .raw_data = sample->raw_data,
+ .raw_size = sample->raw_size,
};
int i;
struct callchain_cursor cursor;
@@ -974,6 +997,7 @@ void hist_entry__delete(struct hist_entry *he)
if (he->srcfile && he->srcfile[0])
free(he->srcfile);
free_callchain(he->callchain);
+ free(he->raw_data);
free(he);
}
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 86f05e7a5566..d29898708dbd 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -122,6 +122,8 @@ struct hist_entry {
struct branch_info *branch_info;
struct hists*hists;
struct mem_info *mem_info;
+ void*raw_data;
+ u32 raw_size;
struct callchain_root callchain[0]; /* must be last member */
};
--
2.6.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/
[PATCH 2/4] f2fs: return early when trying to read null nid
If get_node_page() gets zero nid, we can return early without getting a wrong
page. For example, get_dnode_of_data() can try to do that.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 341de5d..e17128d 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1059,6 +1059,9 @@ struct page *get_node_page(struct f2fs_sb_info *sbi,
pgoff_t nid)
{
struct page *page;
int err;
+
+ if (!nid)
+ return ERR_PTR(-ENOENT);
repeat:
page = grab_cache_page(NODE_MAPPING(sbi), nid);
if (!page)
--
2.5.4 (Apple Git-61)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] f2fs: avoid f2fs_lock_op in f2fs_write_begin
If f2fs_write_begin is to update data, we can bypass calling f2fs_lock_op() in
order to avoid the checkpoint latency in the write syscall.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 43 ++-
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 49092da..d53cf4f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1418,10 +1418,16 @@ static int prepare_write_begin(struct f2fs_sb_info *sbi,
pgoff_t index = page->index;
struct dnode_of_data dn;
struct page *ipage;
+ bool locked = false;
+ struct extent_info ei;
int err = 0;
- f2fs_lock_op(sbi);
-
+ if (f2fs_has_inline_data(inode) ||
+ (pos & PAGE_CACHE_MASK) >= i_size_read(inode)) {
+ f2fs_lock_op(sbi);
+ locked = true;
+ }
+restart:
/* check inline_data */
ipage = get_node_page(sbi, inode->i_ino);
if (IS_ERR(ipage)) {
@@ -1436,22 +1442,41 @@ static int prepare_write_begin(struct f2fs_sb_info *sbi,
read_inline_data(page, ipage);
set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
sync_inode_page();
- goto done;
} else {
err = f2fs_convert_inline_page(, page);
if (err)
- goto err_out;
+ goto out;
+ err = f2fs_get_block(, index);
+ }
+ } else if (locked) {
+ err = f2fs_get_block(, index);
+ } else {
+ if (f2fs_lookup_extent_cache(inode, index, )) {
+ dn.data_blkaddr = ei.blk + index - ei.fofs;
+ } else {
+ bool restart = false;
+
+ /* hole case */
+ err = get_dnode_of_data(, index, LOOKUP_NODE);
+ if (err || (!err && dn.data_blkaddr == NULL_ADDR))
+ restart = true;
+ if (restart) {
+ f2fs_put_dnode();
+ f2fs_lock_op(sbi);
+ locked = true;
+ goto restart;
+ }
}
}
- err = f2fs_get_block(, index);
-done:
+
/* convert_inline_page can make node_changed */
*blk_addr = dn.data_blkaddr;
*node_changed = dn.node_changed;
-err_out:
+out:
f2fs_put_dnode();
unlock_out:
- f2fs_unlock_op(sbi);
+ if (locked)
+ f2fs_unlock_op(sbi);
return err;
}
@@ -1488,7 +1513,7 @@ repeat:
*pagep = page;
- err = prepare_write_begin(sbi, page, pos + len,
+ err = prepare_write_begin(sbi, page, pos, len,
, _balance);
if (err)
goto fail;
--
2.5.4 (Apple Git-61)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] f2fs: introduce prepare_write_begin to clean up
This patch adds prepare_write_begin to clean f2fs_write_begin.
The major role of this function is to convert any inline_data and allocate
or find block address.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 92 ++
1 file changed, 54 insertions(+), 38 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 958d826..49092da 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1410,6 +1410,51 @@ static void f2fs_write_failed(struct address_space
*mapping, loff_t to)
}
}
+static int prepare_write_begin(struct f2fs_sb_info *sbi,
+ struct page *page, loff_t pos, unsigned len,
+ block_t *blk_addr, bool *node_changed)
+{
+ struct inode *inode = page->mapping->host;
+ pgoff_t index = page->index;
+ struct dnode_of_data dn;
+ struct page *ipage;
+ int err = 0;
+
+ f2fs_lock_op(sbi);
+
+ /* check inline_data */
+ ipage = get_node_page(sbi, inode->i_ino);
+ if (IS_ERR(ipage)) {
+ err = PTR_ERR(ipage);
+ goto unlock_out;
+ }
+
+ set_new_dnode(, inode, ipage, ipage, 0);
+
+ if (f2fs_has_inline_data(inode)) {
+ if (pos + len <= MAX_INLINE_DATA) {
+ read_inline_data(page, ipage);
+ set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
+ sync_inode_page();
+ goto done;
+ } else {
+ err = f2fs_convert_inline_page(, page);
+ if (err)
+ goto err_out;
+ }
+ }
+ err = f2fs_get_block(, index);
+done:
+ /* convert_inline_page can make node_changed */
+ *blk_addr = dn.data_blkaddr;
+ *node_changed = dn.node_changed;
+err_out:
+ f2fs_put_dnode();
+unlock_out:
+ f2fs_unlock_op(sbi);
+ return err;
+}
+
static int f2fs_write_begin(struct file *file, struct address_space *mapping,
loff_t pos, unsigned len, unsigned flags,
struct page **pagep, void **fsdata)
@@ -1417,9 +1462,9 @@ static int f2fs_write_begin(struct file *file, struct
address_space *mapping,
struct inode *inode = mapping->host;
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct page *page = NULL;
- struct page *ipage;
pgoff_t index = ((unsigned long long) pos) >> PAGE_CACHE_SHIFT;
- struct dnode_of_data dn;
+ bool need_balance = false;
+ block_t blkaddr = NULL_ADDR;
int err = 0;
trace_f2fs_write_begin(inode, pos, len, flags);
@@ -1443,37 +1488,12 @@ repeat:
*pagep = page;
- f2fs_lock_op(sbi);
-
- /* check inline_data */
- ipage = get_node_page(sbi, inode->i_ino);
- if (IS_ERR(ipage)) {
- err = PTR_ERR(ipage);
- goto unlock_fail;
- }
-
- set_new_dnode(, inode, ipage, ipage, 0);
-
- if (f2fs_has_inline_data(inode)) {
- if (pos + len <= MAX_INLINE_DATA) {
- read_inline_data(page, ipage);
- set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
- sync_inode_page();
- goto put_next;
- }
- err = f2fs_convert_inline_page(, page);
- if (err)
- goto put_fail;
- }
-
- err = f2fs_get_block(, index);
+ err = prepare_write_begin(sbi, page, pos + len,
+ , _balance);
if (err)
- goto put_fail;
-put_next:
- f2fs_put_dnode();
- f2fs_unlock_op(sbi);
+ goto fail;
- if (dn.node_changed && has_not_enough_free_secs(sbi, 0)) {
+ if (need_balance && has_not_enough_free_secs(sbi, 0)) {
unlock_page(page);
f2fs_balance_fs(sbi);
lock_page(page);
@@ -1488,7 +1508,7 @@ put_next:
/* wait for GCed encrypted page writeback */
if (f2fs_encrypted_inode(inode) && S_ISREG(inode->i_mode))
- f2fs_wait_on_encrypted_page_writeback(sbi, dn.data_blkaddr);
+ f2fs_wait_on_encrypted_page_writeback(sbi, blkaddr);
if (len == PAGE_CACHE_SIZE)
goto out_update;
@@ -1504,14 +1524,14 @@ put_next:
goto out_update;
}
- if (dn.data_blkaddr == NEW_ADDR) {
+ if (blkaddr == NEW_ADDR) {
zero_user_segment(page, 0, PAGE_CACHE_SIZE);
} else {
struct f2fs_io_info fio = {
.sbi = sbi,
.type = DATA,
.rw = READ_SYNC,
- .blk_addr = dn.data_blkaddr,
+ .blk_addr = blkaddr,
.page = page,
.encrypted_page = NULL,
};
@@ -1542,10 +1562,6 @@ out_clear:
[PATCH 4/4] f2fs: declare static function
The __f2fs_commit_super is static.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 597b533..75704d9 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1195,7 +1195,7 @@ next:
return 0;
}
-int __f2fs_commit_super(struct f2fs_sb_info *sbi, int block)
+static int __f2fs_commit_super(struct f2fs_sb_info *sbi, int block)
{
struct f2fs_super_block *super = F2FS_RAW_SUPER(sbi);
struct buffer_head *bh;
--
2.5.4 (Apple Git-61)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH 2/4 v2] f2fs: avoid unnecessary f2fs_gc for dir operations
Hi Chao,
Right.
But, in the rename path, we still need to do f2fs_balance_fs, since it produces
another dirty node page in the mean time.
How about this?
>From bbc5bf8f6c940cd75a4d71ce40ce4bd3f647a823 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Tue, 22 Dec 2015 11:56:08 -0800
Subject: [PATCH] f2fs: avoid unnecessary f2fs_gc for dir operations
The f2fs_balance_fs doesn't need to cover f2fs_new_inode or f2fs_find_entry
works.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/namei.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 2c32110..4e27c5c 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -128,8 +128,6 @@ static int f2fs_create(struct inode *dir, struct dentry
*dentry, umode_t mode,
nid_t ino = 0;
int err;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, mode);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -142,6 +140,8 @@ static int f2fs_create(struct inode *dir, struct dentry
*dentry, umode_t mode,
inode->i_mapping->a_ops = _dblock_aops;
ino = inode->i_ino;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
if (err)
@@ -288,12 +288,13 @@ static int f2fs_unlink(struct inode *dir, struct dentry
*dentry)
int err = -ENOENT;
trace_f2fs_unlink_enter(dir, dentry);
- f2fs_balance_fs(sbi);
de = f2fs_find_entry(dir, >d_name, );
if (!de)
goto fail;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = acquire_orphan_inode(sbi);
if (err) {
@@ -341,8 +342,6 @@ static int f2fs_symlink(struct inode *dir, struct dentry
*dentry,
if (len > dir->i_sb->s_blocksize)
return -ENAMETOOLONG;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, S_IFLNK | S_IRWXUGO);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -353,6 +352,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry
*dentry,
inode->i_op = _symlink_inode_operations;
inode->i_mapping->a_ops = _dblock_aops;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
if (err)
@@ -433,8 +434,6 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
struct inode *inode;
int err;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, S_IFDIR | mode);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -444,6 +443,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
inode->i_mapping->a_ops = _dblock_aops;
mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_HIGH_ZERO);
+ f2fs_balance_fs(sbi);
+
set_inode_flag(F2FS_I(inode), FI_INC_LINK);
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
@@ -481,8 +482,6 @@ static int f2fs_mknod(struct inode *dir, struct dentry
*dentry,
struct inode *inode;
int err = 0;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, mode);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -490,6 +489,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry
*dentry,
init_special_inode(inode, inode->i_mode, rdev);
inode->i_op = _special_inode_operations;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
if (err)
@@ -516,9 +517,6 @@ static int __f2fs_tmpfile(struct inode *dir, struct dentry
*dentry,
struct inode *inode;
int err;
- if (!whiteout)
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, mode);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -532,6 +530,8 @@ static int __f2fs_tmpfile(struct inode *dir, struct dentry
*dentry,
inode->i_mapping->a_ops = _dblock_aops;
}
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = acquire_orphan_inode(sbi);
if (err)
@@ -604,8 +604,6 @@ static int f2fs_rename(struct inode *old_dir, struct dentry
*old_dentry,
goto out;
}
- f2fs_balance_fs(sbi);
-
old_entry = f2fs_find_entry(old_dir, _dentry->d_name, _page);
if (!old_entry)
goto out;
@@ -635,6 +633,8 @@ static int f2fs_rename(struct inode *old_dir, struct dentry
*old_dentry,
if (!new_entry)
goto out_whiteout;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = acquire_orphan_inode(sbi);
@@ -666,6 +666,8 @@ static int f2fs_rename(struct inode *old_dir, struct dentry
*old_dentry,
update_inode_page(old_inode);
update_inode_page(new_inode);
} else {
+ f2fs_balance_fs(sbi);
+
Problems with 'serial: 8250: move of_serial code to 8250 directory' in linux-next
Hi Arnd,
I get a number of runtime failures in -next since commit afd7f88f1577
("serial: 8250: move of_serial code to 8250 directory"). Looking into the
commit,
it turns out that you added
obj-$(CONFIG_SERIAL_8250_OF) += 8250_of.o
to drivers/tty/serial/8250/Makefile, but there is no SERIAL_8250_OF Kconfig
option.
As a result, the file is never compiled. I replaced the above with
obj-$(CONFIG_SERIAL_OF_PLATFORM) += 8250_of.o
but that doesn't help, since the file does not compile. I fixed the first error
(linux/nwpserial.h no longer exists), but then the build complains that
8250/8250.h
doesn't exist either. With that, I gave up.
Can you please have a look ? I bisected the problem with
xtensa:generic_kc705_defconfig.
I suspect that other failures (eg with openrisc and possibly some of the arm
failures)
may have the same root cause.
Thanks,
Guenter
---
bisect log:
# bad: [80c75a0f1d81922bf322c0634d1e1a15825a89e6] Add linux-next specific files
for 20151223
# good: [4ef7675344d687a0ef5b0d7c0cee12da005870c0] Linux 4.4-rc6
git bisect start 'HEAD' 'v4.4-rc6'
# good: [52c8be920db8e42d195ca7fe93fe31aa9958100e] Merge remote-tracking branch
'drm/drm-next'
git bisect good 52c8be920db8e42d195ca7fe93fe31aa9958100e
# bad: [d8f8df3c2db6d4d663b5c11f26c6a7df35b35d8c] Merge remote-tracking branch
'tty/tty-next'
git bisect bad d8f8df3c2db6d4d663b5c11f26c6a7df35b35d8c
# good: [29b2e6fc6bbeaddc2dcf4b0afd9c1fac2345eab5] Merge remote-tracking branch
'dt-rh/for-next'
git bisect good 29b2e6fc6bbeaddc2dcf4b0afd9c1fac2345eab5
# good: [8cd6990bf71d89c106e64da0af35d3f4b007c6ec] Merge branch 'x86/platform'
git bisect good 8cd6990bf71d89c106e64da0af35d3f4b007c6ec
# good: [cf3a06027aa2f2f11437d14a523566cae39089eb] Merge remote-tracking branch
'kvm-arm/next'
git bisect good cf3a06027aa2f2f11437d14a523566cae39089eb
# good: [8b775393fab4eb9c248532e19655409674a7fdbd] Merge remote-tracking branch
'leds/for-next'
git bisect good 8b775393fab4eb9c248532e19655409674a7fdbd
# good: [89222e62662237faee90cd8486d23350f26b181d] tty: core: Prefer pr_* to
printk(*)
git bisect good 89222e62662237faee90cd8486d23350f26b181d
# bad: [7ec758718920e5e5876d0d02ece6855128c8eb1e] tty: amba-pl011: add support
for ZTE UART (EXPERIMENTAL)
git bisect bad 7ec758718920e5e5876d0d02ece6855128c8eb1e
# good: [3ac4ae4736d404c436edf3b2ecfd941368f9e247] serial:bfin-uart:Remove
'struct timeval'
git bisect good 3ac4ae4736d404c436edf3b2ecfd941368f9e247
# bad: [b985e9e368f0db4fee940ad86197f413779d4b63] n_tty: Reduce branching in
canon_copy_from_read_buf()
git bisect bad b985e9e368f0db4fee940ad86197f413779d4b63
# bad: [afd7f88f157796e586fc99d62da13a54024e0731] serial: 8250: move of_serial
code to 8250 directory
git bisect bad afd7f88f157796e586fc99d62da13a54024e0731
# good: [4e33870b3bb691996354a8f9e8f69458b4fc34d9] serial: of:
CONFIG_SERIAL_8250 is always set
git bisect good 4e33870b3bb691996354a8f9e8f69458b4fc34d9
# first bad commit: [afd7f88f157796e586fc99d62da13a54024e0731] serial: 8250:
move of_serial code to 8250 directory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: Store breakpoint single step state into pstate
Two 'perf test' fail on arm64:
# perf test overflow
17: Test breakpoint overflow signal handler : FAILED!
18: Test breakpoint overflow sampling: FAILED!
When breakpoint raises, after perf_bp_event, breakpoint_handler()
temporary disables breakpoint and enables single step. Then in
single_step_handler(), reenable breakpoint. Without doing this
the breakpoint would be triggered again.
However, if there's a pending signal and it have signal handler,
control would be transfer to signal handler, so single step handler
would be applied to the first instruction of signal handler. After
the handler return, the instruction triggered the breakpoint would be
executed again. At this time the breakpoint is enabled, so the
breakpoint is triggered again.
There was similar problem on x86, so we have following two commits:
commit 24cda10996f5420ab962f91cd03c15869a3a94b1("x86/signals: Clear RF
EFLAGS bit for signal handler"),
commit 5e219b3c671b34b2d79468fe89c44c0460c0f02b("x86/signals: Propagate
RF EFLAGS bit through the signal restore call").
When breakpoint handler enables single step, task is in a special state
that, the breakpoint should be disabled, the single step should be
enabled, and they should be toggled in single step handler.
This state should be cleared when entering signal handler and restored
after signal return like other program state. Considering the
situation that signal raises inside signal handler, the only safe way
to avoid the problem is to save this state into signal frame, like what
x86 does.
Different from x86 which has an RF EFLAGS bit to control debug
behavior, there's no such bits on ARM64. Creating new fields in signal
frame makes trouble because it is part of user API. Fortunately, on
ARM64, we use a 64 bits pstate but the hardware only utilises the
lowest 32 bits. The other 32 bits can be used by kernel to record this
state.
This patch create two bits in pstate to record the special state caused
by breakpoint and watchpoint. In handle_signal, the state is checked
and the bits are set accordingly, then the hardware is restored.
When signal return, single step can be reenabled based on these bits.
After this patch:
# perf test overflow
17: Test breakpoint overflow signal handler : Ok
18: Test breakpoint overflow sampling: Ok
Signed-off-by: Wang Nan
Cc: AKASHI Takahiro
Cc: Fengguang Wu
Cc: Hanjun Guo
Cc: Jiri Olsa
Cc: Will Deacon
---
v1 -> v2: Fix !CONFIG_HAVE_HW_BREAKPOINT build: add missing 'static inline'.
arch/arm64/include/asm/debug-monitors.h | 9 ++
arch/arm64/include/uapi/asm/ptrace.h| 12
arch/arm64/kernel/hw_breakpoint.c | 50 +
arch/arm64/kernel/signal.c | 2 ++
4 files changed, 73 insertions(+)
diff --git a/arch/arm64/include/asm/debug-monitors.h
b/arch/arm64/include/asm/debug-monitors.h
index 279c85b5..5529060 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -132,11 +132,20 @@ int kernel_active_single_step(void);
#ifdef CONFIG_HAVE_HW_BREAKPOINT
int reinstall_suspended_bps(struct pt_regs *regs);
+u64 signal_toggle_single_step(void);
+void signal_reinstall_single_step(u64 pstate);
#else
static inline int reinstall_suspended_bps(struct pt_regs *regs)
{
return -ENODEV;
}
+static inline u64 signal_toggle_single_step(void)
+{
+ return 0;
+}
+static inline void signal_reinstall_single_step(u64 pstate)
+{
+}
#endif
int aarch32_break_handler(struct pt_regs *regs);
diff --git a/arch/arm64/include/uapi/asm/ptrace.h
b/arch/arm64/include/uapi/asm/ptrace.h
index 208db3d..bfb90f6 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -52,6 +52,18 @@
#define PSR_N_BIT 0x8000
/*
+ * pstat in pt_regs and user_pt_regs are 64 bits. The highest 32 bits
+ * of it can be utilized by other. One user of them is signal handler.
+ */
+#define PSR_LINUX_MASK (0xUL << 32)
+/* Single step and disable breakpoints */
+#define PSR_LINUX_HW_BP_SS (1UL << 32)
+/* Single step and disable watchpoints */
+#define PSR_LINUX_HW_WP_SS (2UL << 32)
+
+#define PSR_LINUX_HW_SS(PSR_LINUX_HW_BP_SS | PSR_LINUX_HW_WP_SS)
+
+/*
* Groups of PSR bits
*/
#define PSR_f 0xff00 /* Flags*/
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index b45c95d..e5a0998 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -954,3 +954,53 @@ int hw_breakpoint_exceptions_notify(struct notifier_block
*unused,
{
return NOTIFY_DONE;
}
+
+u64 signal_toggle_single_step(void)
+{
+ struct debug_info *debug_info = >thread.debug;
+ u64 retval = 0;
+
+ if (likely(!debug_info->bps_disabled && !debug_info->wps_disabled))
+ return 0;
+
+ if
Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support
On Tue, Dec 22, 2015 at 7:25 PM, Zheng, Lv wrote: > Hi, Andy > >> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >> ow...@vger.kernel.org] On Behalf Of Andy Lutomirski >> Sent: Wednesday, December 23, 2015 6:49 AM >> Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support >> >> On Mon, Dec 21, 2015 at 5:03 PM, Chen, Yu C wrote: >> > Hi Andy, >> > thanks for your review, >> > >> >> -Original Message- >> >> From: Andy Lutomirski [mailto:l...@amacapital.net] >> >> Sent: Friday, December 18, 2015 1:00 AM >> >> To: Zheng, Lv >> >> Cc: Chen, Yu C; Moore, Robert; Wysocki, Rafael J; Brown, Len; Andy >> >> Lutomirski; Lv Zheng; linux-kernel@vger.kernel.org; Linux ACPI; H. Peter >> >> Anvin; Borislav Petkov >> >> Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() >> support >> >> >> > [cut] >> >> >> >> I think that hpa or Borislav [cc'd] could address the memory map details >> >> better than I could. However, this functionality seems strange. >> >> >> >> Are these physical addresses or virtual addresses that are being dumped? >> > [Yu] They are virtual addresses to be dumped. >> >> In either case, ISTM that using something iike page_is_ram might be a lot >> >> simpler. >> > [Yu] if i understand correctly, this API is used to check if the address >> > is a valid >> > 'kmalloc' style address, but not 'kmap' or 'vmalloc' address, and >> > page_is_ram >> > might treat the latter as valid address? >> > >> >> I'm a bit puzzled as to why this matters, but I have no fundamental >> objection to doing it that way. > [Lv Zheng] > IMO, using page_is_ram() or something similar, the problem is what we need to > solve in the current approach still need to be solved: > 1. How can we convert a virtual address into a "struct page"? > There is no kernel API to convert any virtual address into struct page. > Even there is such a kernel API to convert kmap/vmalloc addresses, we > still couldn't use it. > Because if we want to validate kmap/vmaloc pages, we need 2 APIs rather > than 1 API while ACPICA only provides 1 API for this purpose. > The 2 APIs should be get/put style to ping the page mappings as the > mappings other than the direct mappings will not be stationary in the kernel > address space. > Fortunately we needn't take care of the mappings other than the direct > mappings (reasons are in the 2nd comment). > So we still need to use the direct mapping APIs here. > 2. How can we ensure the page is a direct mapping page? > I think Yu should confirm if there is such a common kernel API. > If there is such an API, we should use it so that we can remove the arch > specific stuffs. > >> What's the use case, though? > [Lv Zheng] > Fortunately, currently ACPICA only uses this API to validate if a namespace > node, an operand object or a parser object is readable. > See drivers/acpi/acpica/dbdisplay.c and drivers/acpi/acpica/dbcmds.c. > >> That is, what goes wrong if the function just always returns false? > [Lv Zheng] > 1. If it always returns false, then many ACPICA debugger internal object > conversion/dump functionalities won't be functioning. > For example, you can try to type “dump \_SB" in acpidbg shell and it will > return an error: > "Invalid named object at address " > 2. While if this function always returns true (current linux-pm/linux-next > merged stuffs), we can see such a result: > Object () Pathname: \_SB > Name : _SB_ > Type : 06 [Device] > It seems a bit unfortunate to me that the ACPICA debugger lets userspace choose what address to dump rather than dumping by pathname, but given that constraint, I guess this function is needed. Can you do something like checking virt_addr_valid and then using virt_to_pfn and page_is_ram? If that's not enough (e.g. if it doesn't work for vmalloc addresses and you need those), you could try to do something like slow_virt_to_phys, but you'd need to do some extra checks to avoid the BUG in the function. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4.1 02/13] perf hist: Save raw_data/size for tracepoint events
Em Thu, Dec 24, 2015 at 10:05:34AM +0900, Namhyung Kim escreveu:
> The raw_data and raw_size fields are to provide tracepoint specific
> information. They will be used by dynamic sort keys later.
>
> Signed-off-by: Namhyung Kim
> ---
> make a copy of raw_data
>
> tools/perf/util/hist.c | 27 +++
> tools/perf/util/sort.h | 2 ++
> 2 files changed, 29 insertions(+)
>
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index 039bb91d0a92..df5567fff986 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -369,6 +369,28 @@ static struct hist_entry *hist_entry__new(struct
> hist_entry *template,
> if (symbol_conf.use_callchain)
> callchain_init(he->callchain);
>
> + if (he->raw_data) {
> + void *data = malloc(he->raw_size);
if this is really needed, please use memdup(), I.e.:
memdup(he->raw_data, he->raw_size);
> + if (data == NULL) {
> + map__put(he->ms.map);
> + if (he->branch_info) {
> + map__put(he->branch_info->from.map);
> + map__put(he->branch_info->to.map);
> + free(he->branch_info);
> + }
> + if (he->mem_info) {
> + map__put(he->mem_info->iaddr.map);
> + map__put(he->mem_info->daddr.map);
> + }
> + free(he->stat_acc);
> + free(he);
> + return NULL;
> + }
> +
> + memcpy(data, he->raw_data, he->raw_size);
> + he->raw_data = data;
> + }
> INIT_LIST_HEAD(>pairs.node);
> thread__get(he->thread);
> }
> @@ -487,6 +509,8 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
> .branch_info = bi,
> .mem_info = mi,
> .transaction = sample->transaction,
> + .raw_data = sample->raw_data,
> + .raw_size = sample->raw_size,
> };
>
> return hists__findnew_entry(hists, , al, sample_self);
> @@ -801,6 +825,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter
> *iter,
> .sym = al->sym,
> },
> .parent = iter->parent,
> + .raw_data = sample->raw_data,
> + .raw_size = sample->raw_size,
> };
> int i;
> struct callchain_cursor cursor;
> @@ -974,6 +1000,7 @@ void hist_entry__delete(struct hist_entry *he)
> if (he->srcfile && he->srcfile[0])
> free(he->srcfile);
> free_callchain(he->callchain);
> + free(he->raw_data);
> free(he);
> }
>
> diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> index 86f05e7a5566..d29898708dbd 100644
> --- a/tools/perf/util/sort.h
> +++ b/tools/perf/util/sort.h
> @@ -122,6 +122,8 @@ struct hist_entry {
> struct branch_info *branch_info;
> struct hists*hists;
> struct mem_info *mem_info;
> + void*raw_data;
> + u32 raw_size;
> struct callchain_root callchain[0]; /* must be last member */
> };
>
> --
> 2.6.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: [f2fs-dev] [PATCH 3/4 v2] f2fs: record node block allocation in dnode_of_data
> -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Thursday, December 24, 2015 3:00 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH 3/4 v2] f2fs: record node block allocation in > dnode_of_data > > Change log from v1: > - remove redundant set > - adjust memory alignment > > >From 60c6a898094535e850268dd77701255a37cce3d3 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim > Date: Tue, 22 Dec 2015 12:59:54 -0800 > Subject: [PATCH] f2fs: record node block allocation in dnode_of_data > > This patch introduces recording node block allocation in dnode_of_data. > This information helps to figure out whether any node block is allocated > during > specific file operations. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev] [PATCH 2/4 v2] f2fs: avoid unnecessary f2fs_gc for dir operations
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Thursday, December 24, 2015 2:55 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 2/4 v2] f2fs: avoid unnecessary f2fs_gc for
> dir operations
>
> Chang log from v1:
> - add more cases
>
> From 9fea6346f5dd2992525e853e27a4fe899d122379 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim
> Date: Tue, 22 Dec 2015 11:56:08 -0800
> Subject: [PATCH] f2fs: avoid unnecessary f2fs_gc for dir operations
>
> The f2fs_balance_fs doesn't need to cover f2fs_new_inode or f2fs_find_entry
> works.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/namei.c | 34 ++
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 2c32110..e4588f7 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -128,8 +128,6 @@ static int f2fs_create(struct inode *dir, struct dentry
> *dentry, umode_t
> mode,
> nid_t ino = 0;
> int err;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -142,6 +140,8 @@ static int f2fs_create(struct inode *dir, struct dentry
> *dentry, umode_t
> mode,
> inode->i_mapping->a_ops = _dblock_aops;
> ino = inode->i_ino;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -288,12 +288,13 @@ static int f2fs_unlink(struct inode *dir, struct dentry
> *dentry)
> int err = -ENOENT;
>
> trace_f2fs_unlink_enter(dir, dentry);
> - f2fs_balance_fs(sbi);
>
> de = f2fs_find_entry(dir, >d_name, );
> if (!de)
> goto fail;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = acquire_orphan_inode(sbi);
> if (err) {
> @@ -341,8 +342,6 @@ static int f2fs_symlink(struct inode *dir, struct dentry
> *dentry,
> if (len > dir->i_sb->s_blocksize)
> return -ENAMETOOLONG;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, S_IFLNK | S_IRWXUGO);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -353,6 +352,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry
> *dentry,
> inode->i_op = _symlink_inode_operations;
> inode->i_mapping->a_ops = _dblock_aops;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -433,8 +434,6 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
> *dentry, umode_t
> mode)
> struct inode *inode;
> int err;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, S_IFDIR | mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -444,6 +443,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
> *dentry, umode_t
> mode)
> inode->i_mapping->a_ops = _dblock_aops;
> mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_HIGH_ZERO);
>
> + f2fs_balance_fs(sbi);
> +
> set_inode_flag(F2FS_I(inode), FI_INC_LINK);
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> @@ -481,8 +482,6 @@ static int f2fs_mknod(struct inode *dir, struct dentry
> *dentry,
> struct inode *inode;
> int err = 0;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -490,6 +489,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry
> *dentry,
> init_special_inode(inode, inode->i_mode, rdev);
> inode->i_op = _special_inode_operations;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -516,9 +517,6 @@ static int __f2fs_tmpfile(struct inode *dir, struct
> dentry *dentry,
> struct inode *inode;
> int err;
>
> - if (!whiteout)
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -530,6 +528,8 @@ static int __f2fs_tmpfile(struct inode *dir, struct
> dentry *dentry,
> inode->i_op = _file_inode_operations;
> inode->i_fop = _file_operations;
> inode->i_mapping->a_ops = _dblock_aops;
> +
> + f2fs_balance_fs(sbi);
> }
>
> f2fs_lock_op(sbi);
> @@ -604,8 +604,6 @@ static int f2fs_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> goto out;
> }
>
> - f2fs_balance_fs(sbi);
> -
> old_entry = f2fs_find_entry(old_dir, _dentry->d_name, _page);
> if (!old_entry)
> goto out;
> @@ -635,6 +633,8 @@ static int f2fs_rename(struct inode *old_dir, struct
> dentry *old_dentry,
> if
RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled
On Wed, 23 Dec 2015, Hayes Wang wrote: > Oliver Neukum [mailto:oneu...@suse.de] > > Sent: Wednesday, December 23, 2015 4:20 PM > [...] > > No, step (2) does not exist. Calls to suspend() and [reset_]resume() > > always balance. Usually a driver shouldn't care about system suspend. > > The way the driver is currently coded will also fail for Port-Power Off. > > It is different with Windows. The Windows would resume the device before > system suspend, if the system suspend follows the autosuspend. > > Would this be a problem? After system suspend, the device may wake up > the system when receiving any packet, not only magic packet. The wake > events are different for system suspend and autosuspend. However, I > couldn't change the wake event, because the autosuspend occurs first, > and the suspend() is only called once. I don't understand why the wakeup conditions are different. It seems to me that the choice of which packets will generate a wakeup ought to depend on the user's selection, not on the kind of suspend. For instance, if the user says that only a magic packet should cause a wakeup then that should be true for both runtime suspend and system suspend. To put it another way, as far as the device is concerned a suspend is just a suspend -- there's no different between a runtime suspend and a system suspend. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag
Hi Jingoo,
Okay, fine, I would drop this patch, until I found the the root cause.
- Yakir
On 12/23/2015 11:10 PM, Jingoo Han wrote:
On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:
On Rockchip platform, sometimes driver would failed at reading EDID
message, and it's caused by the AUX reply flag wouldn't received under
the 100*10us wait time.
The problem is specific for Rockchip platform.
Also, 1 ms is long time.
The best way is that your hardware engineers find the root cause.
I cannot understand why your engineers cannot find the root cause. :-(
But after expand the wait time a little, the AUX reply flag would be
set, so maybe the wait time is a little critical. Besides the analogix
dp book haven't reminded the standard wait for looking AUX reply flag,
so I thought it's okay to expand the wait time.
And the external wait time won't hurt Exynos DP too much, cause they
wouldn't meet this problem, then driver would received the reply command
very soon, so no more additional wait time would bring to Exynos platform.
Then, when loop time happens on Exynos platform, it will take long time
to return error.
Signed-off-by: Yakir Yang
---
Changes in v12:
- Using another way to expand the AUX reply wait time (Jingoo)
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cba3ffd..8687eea 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct
analogix_dp_device *dp)
{
int reg;
int retval = 0;
- int timeout_loop = 0;
+ unsigned long timeout;
/* Enable AUX CH operation */
reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
@@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct
analogix_dp_device *dp)
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
/* Is AUX CH command reply received? */
- reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
- while (!(reg & RPLY_RECEIV)) {
- timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ timeout = jiffies + msecs_to_jiffies(5);
+ while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
+ if (time_after(jiffies, timeout)) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
- reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
Sorry, I don't like your patch.
The problem happens because of Rockchip platform.
So, you need to add workaround for only Rockchip platform.
Just add new DT property and new variable for the value for wait time.
When, the probe is called, new wait time value is read from Rockchip DT file.
Then, the new wait time value can be written to the new variable.
new DT property: wait-time-aux
new variable: wait_time_aux
If ( ) // New DT
wait_time_aux = New DT;
else
wait_time_aux = 10;
usleep_range(10, 11);
If there is NO new wait time value from DT file, the default value '10' is
used for sleep.
But, if there is new wait time value from DT file, new wait time value
can be used for sleep.
usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);
What I want to say is that there should be NO effect on Exynos platform,
because of the hardware bug of Rockchip platform.
Best regards,
Jingoo Han
}
--
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 02/13] perf hist: Save raw_data/size for tracepoint events
Em Thu, Dec 24, 2015 at 09:45:45AM +0900, Namhyung Kim escreveu:
> Hi Arnaldo,
>
> On Wed, Dec 23, 2015 at 06:43:35PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Dec 23, 2015 at 02:06:59AM +0900, Namhyung Kim escreveu:
> > > The raw_data and raw_size fields are to provide tracepoint specific
> > > information. They will be used by dynamic sort keys later.
> > >
> > > Signed-off-by: Namhyung Kim
> > > ---
> > > tools/perf/util/hist.c | 4
> > > tools/perf/util/sort.h | 2 ++
> > > 2 files changed, 6 insertions(+)
> > >
> > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > > index 039bb91d0a92..c0c92a3daa69 100644
> > > --- a/tools/perf/util/hist.c
> > > +++ b/tools/perf/util/hist.c
> > > @@ -487,6 +487,8 @@ struct hist_entry *__hists__add_entry(struct hists
> > > *hists,
> > > .branch_info = bi,
> > > .mem_info = mi,
> > > .transaction = sample->transaction,
> > > + .raw_data = sample->raw_data,
> > > + .raw_size = sample->raw_size,
> >
> > So, sample->raw_data is just a pointer to perf_event_sample->array, that
> > may be overwritten, no?
>
> I couldn't find where the array data is overwritten. The
> __perf_session__process_events() mmaps with PROT_READ basically. But
> the mmap can be munmapped on 32 bit systems. I'll keep a copy then.
perf top, aka mmap with overwrite mode?
I think we should always think first at how to make such new features to
work on 'perf top', where there is no such thing as a "file", but a
_ring_ buffer, where we reuse that buffer when we fill it up, so we
should not keep any pointers to past events, just use what in the
currently being processed.
Haven't looked, do we need to access it after we add the hist, or just
after the perf_sample is parsed?
> > Looking at the other patches.
>
> Thanks,
> Namhyung
>
> >
> > - Arnaldo
> >
> > > };
> > >
> > > return hists__findnew_entry(hists, , al, sample_self);
> > > @@ -801,6 +803,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter
> > > *iter,
> > > .sym = al->sym,
> > > },
> > > .parent = iter->parent,
> > > + .raw_data = sample->raw_data,
> > > + .raw_size = sample->raw_size,
> > > };
> > > int i;
> > > struct callchain_cursor cursor;
> > > diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> > > index 86f05e7a5566..d29898708dbd 100644
> > > --- a/tools/perf/util/sort.h
> > > +++ b/tools/perf/util/sort.h
> > > @@ -122,6 +122,8 @@ struct hist_entry {
> > > struct branch_info *branch_info;
> > > struct hists*hists;
> > > struct mem_info *mem_info;
> > > + void*raw_data;
> > > + u32 raw_size;
> > > struct callchain_root callchain[0]; /* must be last member */
> > > };
> > >
> > > --
> > > 2.6.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: [PATCH] cpufreq: scpi-cpufreq: signedness bug in scpi_get_dvfs_info()
On Wednesday, December 23, 2015 11:20:04 AM Sudeep Holla wrote:
> Hi Rafael,
>
> On Tue, Dec 15, 2015 at 11:16 AM, Sudeep Holla wrote:
> > From: Dan Carpenter
> >
> > The "domain" variable needs to be signed for the error handling to work.
> >
> > Fixes: 8def31034d03 ('cpufreq: arm_big_little: add SCPI interface driver')
> > Signed-off-by: Dan Carpenter
> > Acked-by: Viresh Kumar
> > Acked-by: Sudeep Holla
> > ---
> > drivers/cpufreq/scpi-cpufreq.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Hi Rafael,
> >
> > This patch seem to have slipped through the cracks somehow. I don't see
> > in patchwork too. So I am resending so that you can pick for your next
> > rc fix if you plan to send one else for -next
> >
>
> This got missed again, can you please ensure to pull this for your next -rc.
> If you have none planned, please pull this for-next.
Applied now, thanks!
I'm going to push it for -rc7.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4.1 02/13] perf hist: Save raw_data/size for tracepoint events
The raw_data and raw_size fields are to provide tracepoint specific
information. They will be used by dynamic sort keys later.
Signed-off-by: Namhyung Kim
---
make a copy of raw_data
tools/perf/util/hist.c | 27 +++
tools/perf/util/sort.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 039bb91d0a92..df5567fff986 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -369,6 +369,28 @@ static struct hist_entry *hist_entry__new(struct
hist_entry *template,
if (symbol_conf.use_callchain)
callchain_init(he->callchain);
+ if (he->raw_data) {
+ void *data = malloc(he->raw_size);
+
+ if (data == NULL) {
+ map__put(he->ms.map);
+ if (he->branch_info) {
+ map__put(he->branch_info->from.map);
+ map__put(he->branch_info->to.map);
+ free(he->branch_info);
+ }
+ if (he->mem_info) {
+ map__put(he->mem_info->iaddr.map);
+ map__put(he->mem_info->daddr.map);
+ }
+ free(he->stat_acc);
+ free(he);
+ return NULL;
+ }
+
+ memcpy(data, he->raw_data, he->raw_size);
+ he->raw_data = data;
+ }
INIT_LIST_HEAD(>pairs.node);
thread__get(he->thread);
}
@@ -487,6 +509,8 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
.branch_info = bi,
.mem_info = mi,
.transaction = sample->transaction,
+ .raw_data = sample->raw_data,
+ .raw_size = sample->raw_size,
};
return hists__findnew_entry(hists, , al, sample_self);
@@ -801,6 +825,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter *iter,
.sym = al->sym,
},
.parent = iter->parent,
+ .raw_data = sample->raw_data,
+ .raw_size = sample->raw_size,
};
int i;
struct callchain_cursor cursor;
@@ -974,6 +1000,7 @@ void hist_entry__delete(struct hist_entry *he)
if (he->srcfile && he->srcfile[0])
free(he->srcfile);
free_callchain(he->callchain);
+ free(he->raw_data);
free(he);
}
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 86f05e7a5566..d29898708dbd 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -122,6 +122,8 @@ struct hist_entry {
struct branch_info *branch_info;
struct hists*hists;
struct mem_info *mem_info;
+ void*raw_data;
+ u32 raw_size;
struct callchain_root callchain[0]; /* must be last member */
};
--
2.6.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: A blocksize problem about dax and ext4
On Wed, Dec 23, 2015 at 4:34 PM, Cholerae Hu wrote:
> The block size is 1024.
> # dumpe2fs -h /dev/pmem0 | grep "Block size"
> dumpe2fs 1.42.13 (17-May-2015)
> Block size: 1024
>
> I tried it out on xfs and I succeeded. There are the prompting messages:
> # mkfs.xfs -f -b size=1024 /dev/pmem0
> meta-data=/dev/pmem0 isize=512agcount=4, agsize=32768 blks
> = sectsz=512 attr=2, projid32bit=1
> = crc=1finobt=1
> data = bsize=1024 blocks=131072, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0 ftype=1
> log =internal log bsize=1024 blocks=2571, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
> # mount -o dax /dev/pmem0 /mnt/mem
>
> The mount command doesn't return any message, and I can successfully read or
> write files in /mnt/mem.
>
xfs will silently disable dax when the fs block size is too small,
i.e. your mmap() operations are backed by page cache in this case.
Currently the only indication of whether a mapping is DAX backed or
not is the presence of the VM_MIXEDMAP flag ("mm" in the VmFlags field
of /proc//smaps)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] extcon next for 4.5
Dear Greg, This is extcon-next pull request for v4.5. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-4.5 for you to fetch changes up to 08a0a4f987a4b5827e4111eccc97a9271d24633e: extcon: add Maxim MAX3355 driver (2015-12-21 11:44:00 +0900) Update extcon for 4.5 Detailed description for patchset: 1. Add new MAX3355 extcon driver - Maxim Integrated MAX3355E chip integrates a charge pump and comparator to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. 2. Update the extcon-arizona driver for jack detection - Add the device binding for the jack detection and add the documentation of extcon-arizona.c. 3. Fix the minor issue of extcon driver - Add IRQF_ONESHOT to interrupt flags of extcon-rt8973. - Fix the return value regmap_irq_get_virq() of extcon-max(14577|77693|77843).c driver by using script[1]. [1] http://permalink.gmane.org/gmane.linux.kernel/2046107 Andrzej Hajda (3): extcon: max14577: fix handling return value of regmap_irq_get_virq extcon: max77693: fix handling return value of regmap_irq_get_virq extcon: max77843: fix handling return value of regmap_irq_get_virq Charles Keepax (11): extcon: arizona: Add device binding to enable ADC mode micdet extcon: arizona: Add device binding for the general purpose switch extcon: arizona: Add device binding for jack detect polarity inversion extcon: arizona: Add device binding for second jack detect pin on GPIO5 extcon: arizona: Update DT binding documentation for mic detection extcon: arizona: Update DT binding documentation for jack detection extcon: arizona: Update naming for second jack detection DT binding extcon: arizona: Update naming for micd-timeout DT to include units extcon: arizona: Add device bindings for the micd configurations extcon: arizona: Update device tree binding for mic detect configurations extcon: arizona: Add DT binding examples Saurabh Sengar (1): extcon: rt8973: Add IRQF_ONESHOT to interrupt flags Sergei Shtylyov (1): extcon: add Maxim MAX3355 driver .../devicetree/bindings/extcon/extcon-arizona.txt | 60 + .../devicetree/bindings/extcon/extcon-max3355.txt | 21 +++ drivers/extcon/Kconfig | 9 ++ drivers/extcon/Makefile| 1 + drivers/extcon/extcon-arizona.c| 71 +- drivers/extcon/extcon-max14577.c | 2 +- drivers/extcon/extcon-max3355.c| 146 + drivers/extcon/extcon-max77693.c | 4 +- drivers/extcon/extcon-max77843.c | 2 +- drivers/extcon/extcon-rt8973a.c| 2 +- 10 files changed, 310 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max3355.txt create mode 100644 drivers/extcon/extcon-max3355.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6.3 4/6] drm: rockchip: Support Synopsys DW MIPI DSI
On 2015年12月23日 11:43, Chris Zhong wrote: Add support for Synopsys DesignWare MIPI DSI controller which is embedded in the rk3288 SoCs. Signed-off-by: Chris Zhong --- Changes in v6.3: - move the mipi_en gate to ockchip_drm_crtc_mode_config Changes in v6.2: - Remove the atomic feature check (Mark Yao) Changes in v6.1: - Add atomic API support (Heiko Stübne) Changes in v6: - Do not use bridge driver (Thierry Reding) - Optimization the phy init sequence Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1196 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + 4 files changed, 1210 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c looks good for me, and it support atomic API, So Acked-by: Mark Yao -- Ｍark Yao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/6] powerpc/mm: any thread in one core can be the first to setup TLB1
On e6500, in the case of cpu hotplug, either thread in one core
may be the first thread initilzing the TLB1. The subsequent threads
must not setup it again.
The code is derived from the comment of Scott Wood.
Signed-off-by: Chenhui Zhao
---
Changes for v4:
* added CONFIG_BOOKE
arch/powerpc/include/asm/cputhreads.h | 8
arch/powerpc/mm/tlb_nohash.c | 4 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h
b/arch/powerpc/include/asm/cputhreads.h
index ba42e46..ea96231 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -94,6 +94,14 @@ static inline int cpu_last_thread_sibling(int cpu)
return cpu | (threads_per_core - 1);
}
+static inline u32 get_tensr(void)
+{
+#ifdef CONFIG_BOOKE
+ if (cpu_has_feature(CPU_FTR_SMT))
+ return mfspr(SPRN_TENSR);
+#endif
+ return 1;
+}
#endif /* _ASM_POWERPC_CPUTHREADS_H */
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index bb04e4d..f466848 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -640,9 +640,7 @@ static void early_init_this_mmu(void)
* transient mapping would cause problems.
*/
#ifdef CONFIG_SMP
- if (cpu != boot_cpuid &&
- (cpu != cpu_first_thread_sibling(cpu) ||
-cpu == cpu_first_thread_sibling(boot_cpuid)))
+ if (hweight32(get_tensr()) > 1)
map = false;
#endif
--
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/
arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'
Hi all,
since commit 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization
and restore"), my arm64 qemu tests of linux-next are failing. After this commit,
qemu does not display any output.
Qemu version is 2.5.0. Linux kernel configuration is arm64:defconfig.
qemu command line is as follows:
qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt
-nographic -smp 1 \
-m 512 -kernel arch/arm64/boot/Image -initrd rootfs.arm64.cpio
-no-reboot \
-append "console=ttyAMA0"
Any idea what might cause this problem and how to fix it (presumably in qemu) ?
Bisect log is attached below. Reverting commit 60792ad349f3 on top of linux-next
fixes the problem.
Thanks,
Guenter
---
# bad: [80c75a0f1d81922bf322c0634d1e1a15825a89e6] Add linux-next specific files
for 20151223
# good: [4ef7675344d687a0ef5b0d7c0cee12da005870c0] Linux 4.4-rc6
git bisect start 'HEAD' 'v4.4-rc6'
# bad: [52c8be920db8e42d195ca7fe93fe31aa9958100e] Merge remote-tracking branch
'drm/drm-next'
git bisect bad 52c8be920db8e42d195ca7fe93fe31aa9958100e
# bad: [ef1ebde6af4d839a07d787440e35f0ae3b02e567] Merge remote-tracking branch
'v4l-dvb/master'
git bisect bad ef1ebde6af4d839a07d787440e35f0ae3b02e567
# bad: [1e4012d4f91fd118167f14c4172bf779a7884d26] Merge remote-tracking branch
'tegra/for-next'
git bisect bad 1e4012d4f91fd118167f14c4172bf779a7884d26
# good: [392fd3291c93094ca65853cca5e168016c4e08b1] Merge branch 'next/dt64'
into for-next
git bisect good 392fd3291c93094ca65853cca5e168016c4e08b1
# bad: [49fc6d2449b0cebd9738694a9c9ee794c3686797] Merge remote-tracking branch
'omap/for-next'
git bisect bad 49fc6d2449b0cebd9738694a9c9ee794c3686797
# bad: [f5a47ef34509cbce244c18bef02b175d0e48dc4f] Merge remote-tracking branch
'at91/at91-next'
git bisect bad f5a47ef34509cbce244c18bef02b175d0e48dc4f
# good: [59f8d523983105e8490603ae1c0798207e9781e6] Merge remote-tracking branch
'arc/for-next'
git bisect good 59f8d523983105e8490603ae1c0798207e9781e6
# good: [40499303a6c59c96da587a91fca617017106e908] Merge branch
'next/defconfig' into for-next
git bisect good 40499303a6c59c96da587a91fca617017106e908
# good: [ea07b401d16052b43782c6389c9c2115aa3077ff] Merge branches 'component'
and 'misc' into for-next
git bisect good ea07b401d16052b43782c6389c9c2115aa3077ff
# bad: [5d7ee87708d4d86fcc32afc9552d05f7625d303d] arm64: perf: add support for
Cortex-A72
git bisect bad 5d7ee87708d4d86fcc32afc9552d05f7625d303d
# good: [9e9caa6a496174e53d7753baa4779717771da4a7] arm64: perf: Add event
descriptions
git bisect good 9e9caa6a496174e53d7753baa4779717771da4a7
# bad: [60792ad349f3c6dc5735aafefe5dc9121c79e320] arm64: kernel: enforce
pmuserenr_el0 initialization and restore
git bisect bad 60792ad349f3c6dc5735aafefe5dc9121c79e320
# good: [aae881ad73460e1b2aea01f079a0541bd5a9136c] arm64: perf: Correct
Cortex-A53/A57 compatible values
git bisect good aae881ad73460e1b2aea01f079a0541bd5a9136c
# first bad commit: [60792ad349f3c6dc5735aafefe5dc9121c79e320] arm64: kernel:
enforce pmuserenr_el0 initialization and restore
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/13] perf hist: Save raw_data/size for tracepoint events
Hi Arnaldo,
On Wed, Dec 23, 2015 at 06:43:35PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 23, 2015 at 02:06:59AM +0900, Namhyung Kim escreveu:
> > The raw_data and raw_size fields are to provide tracepoint specific
> > information. They will be used by dynamic sort keys later.
> >
> > Signed-off-by: Namhyung Kim
> > ---
> > tools/perf/util/hist.c | 4
> > tools/perf/util/sort.h | 2 ++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > index 039bb91d0a92..c0c92a3daa69 100644
> > --- a/tools/perf/util/hist.c
> > +++ b/tools/perf/util/hist.c
> > @@ -487,6 +487,8 @@ struct hist_entry *__hists__add_entry(struct hists
> > *hists,
> > .branch_info = bi,
> > .mem_info = mi,
> > .transaction = sample->transaction,
> > + .raw_data = sample->raw_data,
> > + .raw_size = sample->raw_size,
>
> So, sample->raw_data is just a pointer to perf_event_sample->array, that
> may be overwritten, no?
I couldn't find where the array data is overwritten. The
__perf_session__process_events() mmaps with PROT_READ basically. But
the mmap can be munmapped on 32 bit systems. I'll keep a copy then.
>
> Looking at the other patches.
Thanks,
Namhyung
>
> - Arnaldo
>
> > };
> >
> > return hists__findnew_entry(hists, , al, sample_self);
> > @@ -801,6 +803,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter
> > *iter,
> > .sym = al->sym,
> > },
> > .parent = iter->parent,
> > + .raw_data = sample->raw_data,
> > + .raw_size = sample->raw_size,
> > };
> > int i;
> > struct callchain_cursor cursor;
> > diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> > index 86f05e7a5566..d29898708dbd 100644
> > --- a/tools/perf/util/sort.h
> > +++ b/tools/perf/util/sort.h
> > @@ -122,6 +122,8 @@ struct hist_entry {
> > struct branch_info *branch_info;
> > struct hists*hists;
> > struct mem_info *mem_info;
> > + void*raw_data;
> > + u32 raw_size;
> > struct callchain_root callchain[0]; /* must be last member */
> > };
> >
> > --
> > 2.6.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: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA
On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote: > * Nicolas Pitre [151223 13:45]: > > We fixed a bunch of similar issues where code was located in the .data > > section for ease of use from assembly code. See commit b4e61537 and > > d0776aff for example. > > Thanks hey some assembly fun for the holidays :) I also need to check what > all gets relocated to SRAM here. > > In any case, seems like the $subject patch is too intrusive for v4.5 at > this point. Given Christmas and an unknown time between that and the merge window actually opening, I decided Tuesday would be the last day I take any patches into my tree - and today would be the day that I drop anything that causes problems. So, I've already dropped this, so tomorrow's linux-next should not have this change. You'll still see breakage if people enable RODATA though, but that's no different from previous kernels. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 3/7] mm: add find_get_entries_tag()
> -Original Message-
> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf Of
> Ross Zwisler
> Sent: Wednesday, December 23, 2015 1:39 PM
> Subject: [PATCH v6 3/7] mm: add find_get_entries_tag()
>
...
> diff --git a/mm/filemap.c b/mm/filemap.c
...
> +unsigned find_get_entries_tag(struct address_space *mapping, pgoff_t start,
> + int tag, unsigned int nr_entries,
> + struct page **entries, pgoff_t *indices)
> +{
> + void **slot;
> + unsigned int ret = 0;
...
> + radix_tree_for_each_tagged(slot, >page_tree,
> +, start, tag) {
...
> + indices[ret] = iter.index;
> + entries[ret] = page;
> + if (++ret == nr_entries)
> + break;
> + }
Using >= would provide more safety from buffer overflow
problems in case ret ever jumped ahead by more than one.
---
Robert Elliott, HPE Persistent Memory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc-next v3 4/8] watchdog: mei_wdt: add status debugfs entry
On 12/23/2015 02:48 PM, Winkler, Tomas wrote:
On 12/21/2015 03:17 PM, Tomas Winkler wrote:
Add entry for dumping current watchdog internal state
Signed-off-by: Tomas Winkler
---
V2: new in the series
V3: rebase
drivers/watchdog/mei_wdt.c | 88
++
1 file changed, 88 insertions(+)
diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index 5b28a1e95ac1..ab9aec218d69 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -54,6 +55,24 @@ enum mei_wdt_state {
MEI_WDT_STOPPING,
};
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static const char *mei_wdt_state_str(enum mei_wdt_state state)
+{
+ switch (state) {
+ case MEI_WDT_IDLE:
+ return "IDLE";
+ case MEI_WDT_START:
+ return "START";
+ case MEI_WDT_RUNNING:
+ return "RUNNING";
+ case MEI_WDT_STOPPING:
+ return "STOPPING";
+ default:
+ return "unknown";
+ }
+}
+#endif /* CONFIG_DEBUG_FS */
+
I still don't understand why this code has to be here instead of
further below (at <> mark).
Once it follow closely after enum definition, second in the next patch the
Ifdef is removed since we use the function in debug output and not only in
debugfs.
struct mei_wdt;
/**
@@ -76,6 +95,8 @@ struct mei_wdt_dev {
* @cldev: mei watchdog client device
* @state: watchdog internal state
* @timeout: watchdog current timeout
+ *
+ * @dbgfs_dir: debugfs dir entry
*/
struct mei_wdt {
struct mei_wdt_dev *mwd;
@@ -83,6 +104,10 @@ struct mei_wdt {
struct mei_cl_device *cldev;
enum mei_wdt_state state;
u16 timeout;
+
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+ struct dentry *dbgfs_dir;
+#endif /* CONFIG_DEBUG_FS */
};
/*
@@ -387,6 +412,65 @@ static int mei_wdt_register(struct mei_wdt *wdt)
return 0;
}
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+
<>
+static ssize_t mei_dbgfs_read_state(struct file *file, char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ struct mei_wdt *wdt = file->private_data;
+ const size_t bufsz = 32;
+ char buf[32];
+ ssize_t pos = 0;
+
+ pos += scnprintf(buf + pos, bufsz - pos, "state: %s\n",
+mei_wdt_state_str(wdt->state));
+
Seems to me that "pos = ..." would accomplish exactly the same
without having to pre-initialize pos. I also don't understand the use of
"+ pos" and "- pos" in the parameter field. pos is 0, isn't it ?
When would it ever be non-0 ?
pos = scnprintf(buf, sizeof(buf), "state: %s\n", mei_wdt_state_str(wdt-
state));
What am I missing here ?
Not you are not missing anything, it's just an idiom taken from all my debugfs
function with multiline output.
I don't think that is a good reason for using the more complex code here.
+ return simple_read_from_buffer(ubuf, cnt, ppos, buf, pos);
+}
+
+static const struct file_operations dbgfs_fops_state = {
+ .open = simple_open,
+ .read = mei_dbgfs_read_state,
+ .llseek = generic_file_llseek,
+};
+
+static void dbgfs_unregister(struct mei_wdt *wdt)
+{
+ if (!wdt->dbgfs_dir)
+ return;
+ debugfs_remove_recursive(wdt->dbgfs_dir);
debugfs_remove_recursive() checks if the parameter is NULL,
so it is not necessary to check if it is NULL before the call.
Correct, I can be fixed.
+ wdt->dbgfs_dir = NULL;
+}
+
+static int dbgfs_register(struct mei_wdt *wdt)
+{
+ struct dentry *dir, *f;
+
+ dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ if (!dir)
+ return -ENOMEM;
+
+ wdt->dbgfs_dir = dir;
+ f = debugfs_create_file("state", S_IRUSR, dir, wdt, _fops_state);
+ if (!f)
+ goto err;
+
+ return 0;
+err:
+ dbgfs_unregister(wdt);
+ return -ENODEV;
The error value is ignored by the caller - why bother returning an error in the
first
place ?
A function doesn't take responsibility on how it used.
For an exported function I would agree, but not in a static function.
Thanks,
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: [char-misc-next v3 3/8] watchdog: mei_wdt: implement MEI iAMT watchdog driver
On 12/23/2015 02:38 PM, Winkler, Tomas wrote: On 12/21/2015 11:19 PM, Winkler, Tomas wrote: On 12/21/2015 03:17 PM, Tomas Winkler wrote: Create a driver with the generic watchdog interface for the MEI iAMT watchdog device. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- V2: The watchdog device is no longer dynamically allocated in separate structure V3: Revert back to dynamically allocated watchdog device wrapper Documentation/misc-devices/mei/mei.txt | 12 +- MAINTAINERS| 1 + drivers/watchdog/Kconfig | 15 + drivers/watchdog/Makefile | 1 + drivers/watchdog/mei_wdt.c | 481 + 5 files changed, 504 insertions(+), 6 deletions(-) create mode 100644 drivers/watchdog/mei_wdt.c diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc- devices/mei/mei.txt index 91c1fa34f48b..2b80a0cd621f 100644 --- a/Documentation/misc-devices/mei/mei.txt +++ b/Documentation/misc-devices/mei/mei.txt @@ -231,15 +231,15 @@ IT knows when a platform crashes even when there is a hard failure on the host. The Intel AMT Watchdog is composed of two parts: 1) Firmware feature - receives the heartbeats and sends an event when the heartbeats stop. - 2) Intel MEI driver - connects to the watchdog feature, configures the - watchdog and sends the heartbeats. + 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, + configures the watchdog and sends the heartbeats. -The Intel MEI driver uses the kernel watchdog API to configure the Intel AMT -Watchdog and to send heartbeats to it. The default timeout of the +The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure +the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the watchdog is 120 seconds. -If the Intel AMT Watchdog feature does not exist (i.e. the connection failed), -the Intel MEI driver will disable the sending of heartbeats. +If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate +on the me client bus and watchdog devices won't be exposed. Supported Chipsets diff --git a/MAINTAINERS b/MAINTAINERS index 9bff63cf326e..e655625c2c16 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5666,6 +5666,7 @@ S:Supported F: include/uapi/linux/mei.h F: include/linux/mei_cl_bus.h F: drivers/misc/mei/* +F: drivers/watchdog/mei_wdt.c F: Documentation/misc-devices/mei/* INTEL MIC DRIVERS (mic) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 1c427beffadd..8ac51d69785c 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1154,6 +1154,21 @@ config SBC_EPX_C3_WATCHDOG To compile this driver as a module, choose M here: the module will be called sbc_epx_c3. +config INTEL_MEI_WDT + tristate "Intel MEI iAMT Watchdog" + depends on INTEL_MEI && X86 + select WATCHDOG_CORE + ---help--- + A device driver for the Intel MEI iAMT watchdog. + + The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. + Whenever the OS hangs or crashes, iAMT will send an event + to any subscriber to this event. The watchdog doesn't reset the + the platform. + + To compile this driver as a module, choose M here: + the module will be called mei_wdt. + # M32R Architecture # M68K Architecture diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 53d4827ddfe1..9069c9dd8aa8 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -123,6 +123,7 @@ obj-$(CONFIG_MACHZ_WDT) += machzwd.o obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o +obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o # M32R Architecture diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c new file mode 100644 index ..5b28a1e95ac1 --- /dev/null +++ b/drivers/watchdog/mei_wdt.c @@ -0,0 +1,481 @@ +/* + * Intel Management Engine Interface (Intel MEI) Linux driver + * Copyright (c) 2015, Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include +#include +#include +#include + +#include +#include + +/* + * iAMT Watchdog Device + */ +#define INTEL_AMT_WATCHDOG_ID "iamt_wdt" + +#define MEI_WDT_DEFAULT_TIMEOUT 120 /* seconds */
Re: [v2,3/5] clk: qcom: Add MSM8996 Global Clock Control (GCC) driver
Hi Andy, On Wed, Dec 16, 2015 at 3:30 PM, Andy Gross wrote: > On Mon, Nov 30, 2015 at 05:31:40PM -0800, Stephen Boyd wrote: >> Add support for the global clock controller found on MSM8996 >> based devices. This should allow most non-multimedia device >> drivers to probe and control their clocks. >> >> Signed-off-by: Stephen Boyd >> >> --- > > I saw that this complete set of patches was pulled into clk-next. Would it be > possible for you to host an immutable branch so that I can get the DTS pulled > in > properly with all the dependencies? We already have this in our git tree (as part of our normal topic branch process): git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-msm8996 I'll be sure not to blow it up. Regards, Mike > > Thanks, > > Andy -- Michael Turquette CEO BayLibre - At the Heart of Embedded Linux http://baylibre.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 v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA
* Nicolas Pitre [151223 13:45]: > On Wed, 23 Dec 2015, Tony Lindgren wrote: > > > Hi, > > > > * Laura Abbott [151223 12:31]: > > > > > > Looks like a case similar to Geert's > > > > > > adr r7, kick_counter > > > wait_dll_lock_timed: > > > ldr r4, wait_dll_lock_counter > > > add r4, r4, #1 > > > str r4, [r7, #wait_dll_lock_counter - kick_counter] > > > ldr r4, sdrc_dlla_status > > > /* Wait 20uS for lock */ > > > mov r6, #8 > > > > > > > > > kick_counter and wait_dll_lock_counter are in the text section which is > > > marked read only. > > > They need to be moved to the data section along with a few other > > > variables from what I > > > can tell (maybe those are read only?). > > > > Thanks for looking, yeah so it seem. > > > > > I suspect this is going to be a common issue with suspend/resume code > > > paths since those > > > are hand written assembly. > > > > Yes I suspect we have quite a few cases like this. > > We fixed a bunch of similar issues where code was located in the .data > section for ease of use from assembly code. See commit b4e61537 and > d0776aff for example. Thanks hey some assembly fun for the holidays :) I also need to check what all gets relocated to SRAM here. In any case, seems like the $subject patch is too intrusive for v4.5 at this point. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] x86/efi: show actual ending addresses in efi_print_memmap
Adjust efi_print_memmap to print the real end address of each
range, not 1 byte beyond. This matches other prints like those for
SRAT and nosave memory.
While investigating grub persistent memory corruption issues, it
was helpful to make this table match the ending address convention
used by:
* the kernel's e820 table prints
BIOS-e820: [mem 0x00168000-0x001c7fff] reserved
* the kernel's nosave memory prints
PM: Registered nosave memory: [mem 0x88000-0xc7fff]
* the kernel's ACPI System Resource Affinity Table prints
SRAT: Node 1 PXM 1 [mem 0x48000-0x87fff]
* grub's lsmmap and lsefimmap commands
reserved 00168000-001c7fff 0060 24GiB UC WC WT
WB NV
* the UEFI shell's memmap command
Reserved 7FC0-7FFF 0400
0001
For example, if you grep all the various logs for c7fff, you
won't find the kernel's line if it uses c8000.
Also, change the closing ) to ] to match the opening [.
old:
efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC]
range=[0x00088000-0x000c8000) (16384MB)
new:
efi: mem61: [Persistent Memory | | | | | | | |WB|WT|WC|UC]
range=[0x00088000-0x000c7fff] (16384MB)
Signed-off-by: Robert Elliott
---
Changes in v2:
- Expanded rationale in the commit message
---
arch/x86/platform/efi/efi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ad28540..635a955 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -235,10 +235,10 @@ void __init efi_print_memmap(void)
char buf[64];
md = p;
- pr_info("mem%02u: %s range=[0x%016llx-0x%016llx) (%lluMB)\n",
+ pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%lluMB)\n",
i, efi_md_typeattr_format(buf, sizeof(buf), md),
md->phys_addr,
- md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
+ md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1,
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
}
#endif /* EFI_DEBUG */
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: rsnd: fix usrcnt decrementing bug
Hi Andrzej
> Field usrcnt is unsigned so it cannot be lesser than zero.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>
> Signed-off-by: Andrzej Hajda
> ---
Thank you for your patch. good catch !
I noticed current error case is not good for ssi.c
Can you agree below ?
-
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 7db05fd..e519e30 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -403,6 +403,12 @@ static int rsnd_ssi_quit(struct rsnd_mod *mod,
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
struct device *dev = rsnd_priv_to_dev(priv);
+ if (!ssi->usrcnt) {
+ dev_err(dev, "%s[%d] usrcnt error\n",
+ rsnd_mod_name(mod), rsnd_mod_id(mod));
+ return -EIO;
+ }
+
if (rsnd_ssi_is_parent(mod, io))
goto rsnd_ssi_quit_end;
@@ -422,10 +428,6 @@ rsnd_ssi_quit_end:
ssi->usrcnt--;
- if (ssi->usrcnt < 0)
- dev_err(dev, "%s[%d] usrcnt error\n",
- rsnd_mod_name(mod), rsnd_mod_id(mod));
-
return 0;
}
-
Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A blocksize problem about dax and ext4
On Wed, Dec 23, 2015 at 09:18:05PM +, Elliott, Robert (Persistent Memory) wrote: > > > -Original Message- > > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf Of > > Dan Williams > > Sent: Wednesday, December 23, 2015 11:16 AM > > To: Cholerae Hu > > Cc: linux-nvd...@lists.01.org > > Subject: Re: A blocksize problem about dax and ext4 > > > > On Wed, Dec 23, 2015 at 4:03 AM, Cholerae Hu > > wrote: > ... > > > [root@localhost cholerae]# mount -o dax /dev/pmem0 /mnt/mem > > > mount: wrong fs type, bad option, bad superblock on /dev/pmem0, > > >missing codepage or helper program, or other error > > > > > >In some cases useful info is found in syslog - try > > >dmesg | tail or so. > > > [root@localhost cholerae]# dmesg | tail > ... > > > [ 81.779582] EXT4-fs (pmem0): error: unsupported blocksize for dax > ... > > > What's the fs block size? For example: > > # dumpe2fs -h /dev/pmem0 | grep "Block size" > > dumpe2fs 1.42.9 (28-Dec-2013) > > Block size: 4096 > > Depending on the size of /dev/pmem0 it may have automatically set it > > to a block size less than 4 KiB which is incompatible with "-o dax". > > I noticed a few things while trying that out on both ext4 and xfs. > > $ sudo mkfs.ext4 -F -b 1024 /dev/pmem0 > $ sudo mount -o dax /dev/pmem0 /mnt/ext4-pmem0 > $ sudo mkfs.xfs -f -b size=1024 /dev/pmem0 > $ sudo mount -o dax /dev/pmem0 /mnt/xfs-pmem0 > > [ 199.679195] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at > your own risk > [ 199.724931] EXT4-fs (pmem0): error: unsupported block size 1024 for dax > [ 859.077766] XFS (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your > own risk > [ 859.118106] XFS (pmem0): Filesystem block size invalid for DAX Turning DAX > off. > [ 859.156950] XFS (pmem0): Mounting V4 Filesystem > [ 859.183626] XFS (pmem0): Ending clean mount > > 1. ext4 fails to mount the filesystem, while xfs just disables DAX. > It seems like they should they be the same. I don't really care what is done to ext4 here, but I'm not changing XFS behaviour. I'm expecting mixed dax/non-dax fileystems to be a thing, with DAX turned on by an inode flag on disk. Indeed, I see the mount option going away permanently for XFS, and DAX being controlled completely from on-disk flags. E.g. ext4 encrypted files need to turn off DAX, while clear text files can be accessed using DAX. This should happen completely transparently to the user In the situation of block size < page size, there's things we can do to ensure that XFS will allocate page size aligned/sized extents (extent size hints FTW). This is the same mechanism that we'll use to ensure that extents are aligned/sized for reliable huge page mappings. Hence while DAX /as a global option/ needs to be turned off for sub-page block size filesystems, there's no reason why we can't turn DAX on for files that will always allocate blocks according to DAX constraints. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] mm, x86/vdso: Special IO mapping improvements
Hi Oleg and Kees- I meant to cc you on this in the first place, but I failed. If you have a few minutes, want to take a peek at these and see if you can poke any holes in them? I'm reasonably confident that they're a considerable improvement over the old state of affairs, but they might still not be perfect. Let me know if you want me to email out a fresh copy. This series applies to tip:x86/asm. --Andy On Mon, Dec 14, 2015 at 10:31 AM, Andy Lutomirski wrote: > This applies on top of the earlier vdso pvclock series I sent out. > Once that lands in -tip, this will apply to -tip. > > This series cleans up the hack that is our vvar mapping. We currently > initialize the vvar mapping as a special mapping vma backed by nothing > whatsoever and then we abuse remap_pfn_range to populate it. > > This cheats the mm core, probably breaks under various evil madvise > workloads, and prevents handling faults in more interesting ways. > > To clean it up, this series: > > - Adds a special mapping .fault operation > - Adds a vm_insert_pfn_prot helper > - Uses the new .fault infrastructure in x86's vdso and vvar mappings > - Hardens the HPET mapping, mitigating an HW attack surface that bothers me > > akpm, can you ack patck 1? > > Changes from v1: > - Lots of changelog clarification requested by akpm > - Minor tweaks to style and comments in the first two patches > > Andy Lutomirski (6): > mm: Add a vm_special_mapping .fault method > mm: Add vm_insert_pfn_prot > x86/vdso: Track each mm's loaded vdso image as well as its base > x86,vdso: Use .fault for the vdso text mapping > x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping > x86/vdso: Disallow vvar access to vclock IO for never-used vclocks > > arch/x86/entry/vdso/vdso2c.h| 7 -- > arch/x86/entry/vdso/vma.c | 124 > > arch/x86/entry/vsyscall/vsyscall_gtod.c | 9 ++- > arch/x86/include/asm/clocksource.h | 9 +-- > arch/x86/include/asm/mmu.h | 3 +- > arch/x86/include/asm/vdso.h | 3 - > arch/x86/include/asm/vgtod.h| 6 ++ > include/linux/mm.h | 2 + > include/linux/mm_types.h| 22 +- > mm/memory.c | 25 ++- > mm/mmap.c | 13 ++-- > 11 files changed, 151 insertions(+), 72 deletions(-) > > -- > 2.5.0 > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n
On Wed, Dec 23, 2015 at 03:47:08PM -0800, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > > This is for tip:x86/asm. > > arch/x86/include/asm/pvclock.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h > index 66df22b2e0c9..fdcc04020636 100644 > --- a/arch/x86/include/asm/pvclock.h > +++ b/arch/x86/include/asm/pvclock.h > @@ -4,7 +4,7 @@ > #include > #include > > -#ifdef CONFIG_PARAVIRT_CLOCK > +#ifdef CONFIG_KVM_GUEST > extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void); > #else > static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void) > -- > 2.5.0 Acked-by: Borislav Petkov -- 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/
[PATCH] x86/vsdo: Fix build on PARAVIRT_CLOCK=y, KVM_GUEST=n
Signed-off-by: Andy Lutomirski --- This is for tip:x86/asm. arch/x86/include/asm/pvclock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h index 66df22b2e0c9..fdcc04020636 100644 --- a/arch/x86/include/asm/pvclock.h +++ b/arch/x86/include/asm/pvclock.h @@ -4,7 +4,7 @@ #include #include -#ifdef CONFIG_PARAVIRT_CLOCK +#ifdef CONFIG_KVM_GUEST extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void); #else static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation/kernel-parameters: update KMG units
Since commit e004f3c7780d ("lib/cmdline.c: add size unit t/p/e to
memparse") expanded memparse() to support T, P, and E units in addition
to K, M, and G, all the kernel parameters that use that function became
capable of more than [KMG] mentioned in kernel-parameters.txt.
Expand the introduction to the units and change all existing [KMG]
descriptions to [KMGTPE]. cma only had [MG]; reservelow only had [K].
Add [KMGTPE] for hugepagesz and memory_corruption_check_size, which also
use memparse().
Update two source code files with comments mentioning [KMG].
Signed-off-by: Robert Elliott
---
Documentation/kernel-parameters.txt | 101 +++-
kernel/crash_dump.c | 2 +-
mm/page_alloc.c | 2 +-
3 files changed, 56 insertions(+), 49 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 742f69d..3f77290 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -159,10 +159,16 @@ a fixed number of characters. This limit depends on the
architecture
and is between 256 and 4096 characters. It is defined in the file
./include/asm/setup.h as COMMAND_LINE_SIZE.
-Finally, the [KMG] suffix is commonly described after a number of kernel
-parameter values. These 'K', 'M', and 'G' letters represent the _binary_
-multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
-bytes respectively. Such letter suffixes can also be entirely omitted.
+Finally, the [KMGTPE] suffix is commonly described after a number
+of kernel parameter values. These letters represent the _binary_
+multipliers:
+ 'K' = Ki (2^10)
+ 'M' = Mi (2^20)
+ 'G' = Gi (2^30)
+ 'T' = Ti (2^40)
+ 'P' = Pi (2^50)
+ 'E' = Ei (2^60)
+Such letter suffixes can also be entirely omitted.
acpi= [HW,ACPI,X86,ARM64]
@@ -663,8 +669,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Also note the kernel might malfunction if you disable
some critical bits.
- cma=nn[MG]@[start[MG][-end[MG]]]
- [ARM,X86,KNL]
+ cma=nn[KMGTPE]@[start[KMGTPE][-end[KMGTPE]]] [ARM,X86,KNL]
Sets the size of kernel global memory area for
contiguous memory allocations and optionally the
placement constraint by the physical address range of
@@ -679,7 +684,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
a hypervisor.
Default: yes
- coherent_pool=nn[KMG] [ARM,KNL]
+ coherent_pool=nn[KMGTPE][ARM,KNL]
Sets the size of memory pool for coherent, atomic dma
allocations, by default set to 256K.
@@ -763,7 +768,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format:
,,,[,]
- crashkernel=size[KMG][@offset[KMG]]
+ crashkernel=size[KMGTPE][@offset[KMGTPE]]
[KNL] Using kexec, Linux can switch to a 'crash kernel'
upon panic. This parameter reserves the physical
memory region [offset, offset + size] for that kernel
@@ -775,18 +780,18 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
[KNL] Same as above, but depends on the memory
in the running system. The syntax of range is
start-[end] where start and end are both
- a memory unit (amount[KMG]). See also
+ a memory unit (amount[KMGTPE]). See also
Documentation/kdump/kdump.txt for an example.
- crashkernel=size[KMG],high
- [KNL, x86_64] range could be above 4G. Allow kernel
+ crashkernel=size[KMGTPE],high [KNL, x86_64]
+ range could be above 4G. Allow kernel
to allocate physical memory region from top, so could
be above 4G if system have more than 4G ram installed.
Otherwise memory region will be allocated below 4G, if
available.
It will be ignored if crashkernel=X is specified.
- crashkernel=size[KMG],low
- [KNL, x86_64] range under 4G. When crashkernel=X,high
+ crashkernel=size[KMGTPE],low [KNL, x86_64]
+ range under 4G. When crashkernel=X,high
is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
@@ -,7 +1116,9 @@ bytes respectively. Such letter suffixes can also be
entirely
Re: [PATCH] gpio: Add driver for TI TPIC2810
On Tue, Dec 15, 2015 at 9:10 PM, Andrew F. Davis wrote:
> Add driver for TI TPIC2810 8-Bit LED Driver with I2C Interface.
>
> The TPIC2810 has 8 open-drain outputs that can but used to drive
> LEDs and other low-side switched resistive loads.
>
> Signed-off-by: Andrew F. Davis
This patch will have to be rebased to apply and compile after the release
of kernel v4.5-rc1, as we have too much lined up right now, I see no
big problems
with it but here are some more minor comments.
+static inline struct tpic2810 *to_tpic2810(struct gpio_chip *chip)
> +{
> + return container_of(chip, struct tpic2810, chip);
> +}
We are getting rid of this design pattern, check the gpiochip_get_data()
function that will be introduced in v4.5-rc1 and patches I merge to all
other drivers.
> +static const struct i2c_device_id tpic2810_id_table[] = {
> + { "tpic2810", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(i2c, tpic2810_id_table);
> +
> +static struct i2c_driver tpic2810_driver = {
> + .driver = {
> + .name = "tpic2810",
> + },
> + .probe = tpic2810_probe,
> + .remove = tpic2810_remove,
> + .id_table = tpic2810_id_table,
> +};
> +module_i2c_driver(tpic2810_driver);
No device tree probing? Which platform uses this?
I was expecting an .of_match_table() in .driver.
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] init, Documentation: Remove ramdisk_blocksize mentions
The brd driver has never supported the ramdisk_blocksize kernel
parameter that was in the rd driver it replaced, so remove
mention of this parameter from comments and Documentation.
Commit 9db5579be4bb ("rewrite rd") replaced rd with brd, keeping
a brd_blocksize variable in struct brd_device but never using it.
Commit a2cba2913c76 ("brd: get rid of unused members from struct
brd_device") removed the unused variable.
Commit f5abc8e75815 ("Documentation/blockdev/ramdisk.txt: updates")
removed mentions of ramdisk_blocksize from that file.
Signed-off-by: Robert Elliott
---
Documentation/kernel-parameters.txt | 3 ---
init/do_mounts_rd.c | 7 ---
2 files changed, 10 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 742f69d..461686e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3050,9 +3050,6 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
raid= [HW,RAID]
See Documentation/md.txt.
- ramdisk_blocksize= [RAM]
- See Documentation/blockdev/ramdisk.txt.
-
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
See Documentation/blockdev/ramdisk.txt.
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index e5d059e..8a09b32 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -216,13 +216,6 @@ int __init rd_load_image(char *from)
/*
* NOTE NOTE: nblocks is not actually blocks but
* the number of kibibytes of data to load into a ramdisk.
-* So any ramdisk block size that is a multiple of 1KiB should
-* work when the appropriate ramdisk_blocksize is specified
-* on the command line.
-*
-* The default ramdisk_blocksize is 1KiB and it is generally
-* silly to use anything else, so make sure to use 1KiB
-* blocksize while generating ext2fs ramdisk-images.
*/
if (sys_ioctl(out_fd, BLKGETSIZE, (unsigned long)_blocks) < 0)
rd_blocks = 0;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ext2, ext4: include filesystem block size in error messages
Print the problematic value in messages about the filesystem
block size.
Normalize all of the blocksize messages that use "blocksize" to
use "filesystem block size". This helps distinguish this block size
from the underlying block device's logical block size (i.e.,
sector size) and physical block size.
Example old messages:
EXT2-fs (pmem0): unable to set blocksize
EXT4-fs (pmem0): error: unsupported blocksize for dax
EXT4-fs (pmem0): unsupported blocksize for fs encryption
EXT2-fs (pmem0): bad blocksize %d
Example new message:
EXT4-fs (pmem0): error: unsupported filesystem block size 2048 for dax
Signed-off-by: Robert Elliott
---
fs/ext2/super.c | 17 +++--
fs/ext4/super.c | 33 -
2 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 748d35a..1186a5b 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include "ext2.h"
#include "xattr.h"
@@ -822,7 +823,9 @@ static int ext2_fill_super(struct super_block *sb, void
*data, int silent)
*/
blocksize = sb_min_blocksize(sb, BLOCK_SIZE);
if (!blocksize) {
- ext2_msg(sb, KERN_ERR, "error: unable to set blocksize");
+ ext2_msg(sb, KERN_ERR,
+"error: unable to set filesystem block size "
+__stringify(BLOCK_SIZE));
goto failed_sbi;
}
@@ -921,7 +924,8 @@ static int ext2_fill_super(struct super_block *sb, void
*data, int silent)
if (sbi->s_mount_opt & EXT2_MOUNT_DAX) {
if (blocksize != PAGE_SIZE) {
ext2_msg(sb, KERN_ERR,
- "error: unsupported blocksize for dax");
+"error: unsupported filesystem block size %d for dax",
+blocksize);
goto failed_mount;
}
if (!sb->s_bdev->bd_disk->fops->direct_access) {
@@ -937,7 +941,7 @@ static int ext2_fill_super(struct super_block *sb, void
*data, int silent)
if (!sb_set_blocksize(sb, blocksize)) {
ext2_msg(sb, KERN_ERR,
- "error: bad blocksize %d", blocksize);
+"error: bad filesystem block size %d", blocksize);
goto failed_sbi;
}
@@ -1007,14 +1011,15 @@ static int ext2_fill_super(struct super_block *sb, void
*data, int silent)
if (sb->s_blocksize != bh->b_size) {
if (!silent)
- ext2_msg(sb, KERN_ERR, "error: unsupported blocksize");
+ ext2_msg(sb, KERN_ERR,
+"error: unsupported filesystem block size %lu",
+sb->s_blocksize);
goto failed_mount;
}
if (sb->s_blocksize != sbi->s_frag_size) {
ext2_msg(sb, KERN_ERR,
- "error: fragsize %lu != blocksize %lu"
- "(not supported yet)",
+"error: fragsize %lu != filesystem block size %lu (not supported yet)",
sbi->s_frag_size, sb->s_blocksize);
goto failed_mount;
}
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c9ab67d..9e1c049 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -42,6 +42,7 @@
#include
#include
+#include
#include "ext4.h"
#include "ext4_extents.h" /* Needed for trace points definition */
@@ -1750,8 +1751,9 @@ static int parse_options(char *options, struct
super_block *sb,
BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
if (blocksize < PAGE_CACHE_SIZE) {
- ext4_msg(sb, KERN_ERR, "can't mount with "
-"dioread_nolock if block size != PAGE_SIZE");
+ ext4_msg(sb, KERN_ERR,
+ "can't mount with dioread_nolock if filesystem
block size %d != PAGE_SIZE",
+ blocksize);
return 0;
}
}
@@ -3147,7 +3149,9 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
ret = -EINVAL;
blocksize = sb_min_blocksize(sb, EXT4_MIN_BLOCK_SIZE);
if (!blocksize) {
- ext4_msg(sb, KERN_ERR, "unable to set blocksize");
+ ext4_msg(sb, KERN_ERR,
+"unable to set filesystem block size "
+__stringify(EXT4_MIN_BLOCK_SIZE));
goto out_fail;
}
@@ -3367,14 +3371,15 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
if (blocksize < EXT4_MIN_BLOCK_SIZE ||
blocksize > EXT4_MAX_BLOCK_SIZE) {
ext4_msg(sb, KERN_ERR,
-
Re: [PATCH] netconsole: Initialize after all core networking drivers
On Thursday 12/17 at 17:46 -0800, Calvin Owens wrote:
> On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote:
> > On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote:
> > > With built-in netconsole and IXGBE, configuring netconsole via the kernel
> > > cmdline results in the following panic at boot:
> > >
> > > netpoll: netconsole: device eth0 not up yet, forcing it
> > > usb 2-1: new high-speed USB device number 2 using ehci-pci
> > > ixgbe :03:00.0: registered PHC device on eth0
> > > BUG: unable to handle kernel NULL pointer dereference at
> > > 0810
> > >
> > > Call Trace:
> > > [] ? vxlan_get_rx_port+0x41/0xa0
> > > [] ixgbe_open+0x4e8/0x540
> > > [] __dev_open+0xac/0x120
> > > [] dev_open+0x36/0x70
> > > [] netpoll_setup+0x23c/0x300
> > > [] ? netpoll_parse_options+0x19a/0x200
> > > [] ? option_setup+0x1f/0x1f
> > > [] init_netconsole+0xda/0x262
> > > [] ? option_setup+0x1f/0x1f
> > > [] do_one_initcall+0x88/0x1b0
> > > [] kernel_init_freeable+0x14a/0x1e3
> > > [] ? do_early_param+0x8c/0x8c
> > > [] ? rest_init+0x80/0x80
> > > [] kernel_init+0xe/0xe0
> > > [] ret_from_fork+0x3f/0x70
> > > [] ? rest_init+0x80/0x80
> > >
> > > This happens because IXGBE assumes that vxlan has already been
> > > initialized.
> > > The cleanest way to fix this is to just initialize netconsole after all
> > > the
> > > other core networking stuff has completed.
> > >
> > > Signed-off-by: Calvin Owens
> > > ---
> > > drivers/net/Makefile | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> > > index 900b0c5..31557d0 100644
> > > --- a/drivers/net/Makefile
> > > +++ b/drivers/net/Makefile
> > > @@ -15,7 +15,6 @@ obj-$(CONFIG_MACVTAP) += macvtap.o
> > > obj-$(CONFIG_MII) += mii.o
> > > obj-$(CONFIG_MDIO) += mdio.o
> > > obj-$(CONFIG_NET) += Space.o loopback.o
> > > -obj-$(CONFIG_NETCONSOLE) += netconsole.o
> > > obj-$(CONFIG_PHYLIB) += phy/
> > > obj-$(CONFIG_RIONET) += rionet.o
> > > obj-$(CONFIG_NET_TEAM) += team/
> > > @@ -26,6 +25,7 @@ obj-$(CONFIG_VXLAN) += vxlan.o
> > > obj-$(CONFIG_GENEVE) += geneve.o
> > > obj-$(CONFIG_NLMON) += nlmon.o
> > > obj-$(CONFIG_NET_VRF) += vrf.o
> > > +obj-$(CONFIG_NETCONSOLE) += netconsole.o
> > >
> > > #
> > > # Networking Drivers
> >
> >
> > Looks odd to rely on link order, but we might already rely on this...
> >
> > Have you considered using device_initcall() instead of late_initcall()
> > in vxlan ?
>
> I'll look.
So this does work, but commit 7332a13b038be05c explicitly changed it to
late_initcall() because of dependencies on IPv6:
When vxlan is compiled as builtin, its init code
runs before IPv6 init, this could cause problems
if we create IPv6 socket in the latter patch.
So I guess something like the following patch is needed to go that
route? It's ugly, IMHO the Makefile patch is cleaner...
Stephen / Cong, what do you think?
> As-is though, I think a similar problem would happen if you
> tried to use a virtio_net device with netconsole= cmdline (although that
> is admittedly a bizarre use case). The Makefile patch seemed like the
> best way to ensure this can't recur elsewhere.
I misunderstood this, it works fine as is.
---8<---
From: Calvin Owens
Subject: [PATCH] vxlan: Properly depend on ipv6 and revert to module_init()
Commit 7332a13b038be05c ("vxlan: defer vxlan init as late as possible")
changed vxlan to use late_initcall(), because vxlan relies on ipv6 being
loaded when a new device is opened.
This causes netconsole to panic at boot when configured via the kernel
cmdline on an IXGBE NIC, because ixgbe_open() assumes that vxlan has
already been initialized:
netpoll: netconsole: device eth0 not up yet, forcing it
ixgbe :03:00.0: registered PHC device on eth0
BUG: unable to handle kernel NULL pointer dereference at 0810
Call Trace:
[] ? vxlan_get_rx_port+0x41/0xa0
[] ixgbe_open+0x4e8/0x540
[] __dev_open+0xac/0x120
[] dev_open+0x36/0x70
[] netpoll_setup+0x23c/0x300
[] ? netpoll_parse_options+0x19a/0x200
[] ? option_setup+0x1f/0x1f
[] init_netconsole+0xda/0x262
[] ? option_setup+0x1f/0x1f
[] do_one_initcall+0x88/0x1b0
[] kernel_init_freeable+0x14a/0x1e3
[] ? do_early_param+0x8c/0x8c
[] ? rest_init+0x80/0x80
[] kernel_init+0xe/0xe0
[] ret_from_fork+0x3f/0x70
[] ? rest_init+0x80/0x80
This patch addresses the issue cited in 7332a13b038be05c by making vxlan
actually check if ipv6 is loaded, and reverts it to module_init() so
that it becomes device_initcall() when built-in, eliminating the
netconsole issue.
The ipv6 module is permanent, so there's no need to actually do the
usual module_get/module_put dance: once we find it loaded, we can just
assume that it always will be.
AFAICS, nothing actually ends up calling vxlan_open() during initcalls,
so in the (IPV6=y && VXLAN=y) case we
RE: [char-misc-next v3 6/8] watchdog: mei_wdt: register wd device only if required
next v3 6/8] watchdog: mei_wdt: register wd device only
> if required
>
> On 12/21/2015 03:17 PM, Tomas Winkler wrote:
> > From: Alexander Usyskin
> >
> > For Intel Broadwell and newer platforms, the ME device can inform
> > the host whether the watchdog functionality is activated or not.
> > If the watchdog functionality is not activated then the watchdog interface
> > can be not registered and eliminate unnecessary pings and hence lower the
> > power consumption by avoiding waking up the device.
> > The feature can be deactivated also without reboot
> > in that case the watchdog device should be unregistered at runtime.
> >
> > Signed-off-by: Alexander Usyskin
> > Signed-off-by: Tomas Winkler
> > ---
> > V2: rework unregistration
> > V3: rebase; implement unregistraion also at runtime
> >
> > drivers/watchdog/mei_wdt.c | 183
> +
> > 1 file changed, 169 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> > index ab9aec218d69..3cd80aa75db1 100644
> > --- a/drivers/watchdog/mei_wdt.c
> > +++ b/drivers/watchdog/mei_wdt.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -38,24 +39,30 @@
> >
> > /* Sub Commands */
> > #define MEI_MC_START_WD_TIMER_REQ 0x13
> > +#define MEI_MC_START_WD_TIMER_RES 0x83
> > +#define MEI_WDT_STATUS_SUCCESS 0
> > +#define MEI_WDT_WDSTATE_NOT_REQUIRED 0x1
> > #define MEI_MC_STOP_WD_TIMER_REQ 0x14
> >
> > /**
> >* enum mei_wdt_state - internal watchdog state
> >*
> > + * @MEI_WDT_PROBE: wd in probing stage
> >* @MEI_WDT_IDLE: wd is idle and not opened
> >* @MEI_WDT_START: wd was opened, start was called
> >* @MEI_WDT_RUNNING: wd is expecting keep alive pings
> >* @MEI_WDT_STOPPING: wd is stopping and will move to IDLE
> > + * @MEI_WDT_NOT_REQUIRED: wd device is not required
> >*/
> > enum mei_wdt_state {
> > + MEI_WDT_PROBE,
> > MEI_WDT_IDLE,
> > MEI_WDT_START,
> > MEI_WDT_RUNNING,
> > MEI_WDT_STOPPING,
> > + MEI_WDT_NOT_REQUIRED,
> > };
> >
> > -#if IS_ENABLED(CONFIG_DEBUG_FS)
> > static const char *mei_wdt_state_str(enum mei_wdt_state state)
> > {
> > switch (state) {
> > @@ -71,7 +78,6 @@ static const char *mei_wdt_state_str(enum
> mei_wdt_state state)
> > return "unknown";
> > }
> > }
> > -#endif /* CONFIG_DEBUG_FS */
> >
> > struct mei_wdt;
> >
> > @@ -94,6 +100,10 @@ struct mei_wdt_dev {
> >*
> >* @cldev: mei watchdog client device
> >* @state: watchdog internal state
> > + * @resp_required: ping required response
> > + * @response: ping response completion
> > + * @unregister: unregister worker
> > + * @reg_lock: watchdog device registration lock
> >* @timeout: watchdog current timeout
> >*
> >* @dbgfs_dir: debugfs dir entry
> > @@ -103,6 +113,10 @@ struct mei_wdt {
> >
> > struct mei_cl_device *cldev;
> > enum mei_wdt_state state;
> > + bool resp_required;
> > + struct completion response;
> > + struct work_struct unregister;
> > + struct mutex reg_lock;
> > u16 timeout;
> >
> > #if IS_ENABLED(CONFIG_DEBUG_FS)
> > @@ -139,6 +153,19 @@ struct mei_wdt_start_request {
> > } __packed;
> >
> > /**
> > + * struct mei_wdt_start_response watchdog start/ping response
> > + *
> > + * @hdr: Management Control Command Header
> > + * @status: operation status
> > + * @wdstate: watchdog status bit mask
> > + */
> > +struct mei_wdt_start_response {
> > + struct mei_mc_hdr hdr;
> > + u8 status;
> > + u8 wdstate;
> > +} __packed;
> > +
> > +/**
> >* struct mei_wdt_stop_request - watchdog stop
> >*
> >* @hdr: Management Control Command Header
> > @@ -277,13 +304,18 @@ static int mei_wdt_ops_ping(struct watchdog_device
> *wdd)
> > if (wdt->state != MEI_WDT_START && wdt->state !=
> MEI_WDT_RUNNING)
> > return 0;
> >
> > + if (wdt->resp_required)
> > + init_completion(>response);
> > +
> > + wdt->state = MEI_WDT_RUNNING;
> > ret = mei_wdt_ping(wdt);
> > if (ret)
> > return ret;
> >
> > - wdt->state = MEI_WDT_RUNNING;
>
> The state is now set to RUNNING even if the ping failed.
> Is that on purpose ?
Yes, the state is checked in the response handler.
>
> > + if (wdt->resp_required)
> > + ret = wait_for_completion_killable(>response);
> >
> > - return 0;
> > + return ret;
> > }
> >
> > /**
> > @@ -358,15 +390,22 @@ static struct watchdog_info wd_info = {
> >*/
> > static void mei_wdt_unregister(struct mei_wdt *wdt)
> > {
> > - struct mei_wdt_dev *mwd = wdt->mwd;
> > + struct mei_wdt_dev *mwd;
> >
> > - if (!mwd)
> > - return;
> > + mutex_lock(>reg_lock);
> > +
> > + if (!wdt->mwd)
> > + goto out;
> > +
>
> Is this because the error on registration was ignored ?
> Trying to understand the rationale for this check.
Protection against
Re: [PATCH 1/2] mm, oom: introduce oom reaper
On Tue, Dec 15, 2015 at 11:36 AM, Michal Hocko wrote:
> From: Michal Hocko
>
> This is based on the idea from Mel Gorman discussed during LSFMM 2015 and
> independently brought up by Oleg Nesterov.
>
> The OOM killer currently allows to kill only a single task in a good
> hope that the task will terminate in a reasonable time and frees up its
> memory. Such a task (oom victim) will get an access to memory reserves
> via mark_oom_victim to allow a forward progress should there be a need
> for additional memory during exit path.
>
> It has been shown (e.g. by Tetsuo Handa) that it is not that hard to
> construct workloads which break the core assumption mentioned above and
> the OOM victim might take unbounded amount of time to exit because it
> might be blocked in the uninterruptible state waiting for on an event
> (e.g. lock) which is blocked by another task looping in the page
> allocator.
>
> This patch reduces the probability of such a lockup by introducing a
> specialized kernel thread (oom_reaper) which tries to reclaim additional
> memory by preemptively reaping the anonymous or swapped out memory
> owned by the oom victim under an assumption that such a memory won't
> be needed when its owner is killed and kicked from the userspace anyway.
> There is one notable exception to this, though, if the OOM victim was
> in the process of coredumping the result would be incomplete. This is
> considered a reasonable constrain because the overall system health is
> more important than debugability of a particular application.
>
> A kernel thread has been chosen because we need a reliable way of
> invocation so workqueue context is not appropriate because all the
> workers might be busy (e.g. allocating memory). Kswapd which sounds
> like another good fit is not appropriate as well because it might get
> blocked on locks during reclaim as well.
>
> oom_reaper has to take mmap_sem on the target task for reading so the
> solution is not 100% because the semaphore might be held or blocked for
> write but the probability is reduced considerably wrt. basically any
> lock blocking forward progress as described above. In order to prevent
> from blocking on the lock without any forward progress we are using only
> a trylock and retry 10 times with a short sleep in between.
> Users of mmap_sem which need it for write should be carefully reviewed
> to use _killable waiting as much as possible and reduce allocations
> requests done with the lock held to absolute minimum to reduce the risk
> even further.
>
> The API between oom killer and oom reaper is quite trivial. wake_oom_reaper
> updates mm_to_reap with cmpxchg to guarantee only NULL->mm transition
> and oom_reaper clear this atomically once it is done with the work. This
> means that only a single mm_struct can be reaped at the time. As the
> operation is potentially disruptive we are trying to limit it to the
> ncessary minimum and the reaper blocks any updates while it operates on
> an mm. mm_struct is pinned by mm_count to allow parallel exit_mmap and a
> race is detected by atomic_inc_not_zero(mm_users).
>
> Changes since v2
> - fix mm_count refernce leak reported by Tetsuo
> - make sure oom_reaper_th is NULL after kthread_run fails - Tetsuo
> - use wait_event_freezable rather than open coded wait loop - suggested
> by Tetsuo
> Changes since v1
> - fix the screwed up detail->check_swap_entries - Johannes
> - do not use kthread_should_stop because that would need a cleanup
> and we do not have anybody to stop us - Tetsuo
> - move wake_oom_reaper to oom_kill_process because we have to wait
> for all tasks sharing the same mm to get killed - Tetsuo
> - do not reap mm structs which are shared with unkillable tasks - Tetsuo
>
> Acked-by: Mel Gorman
> Signed-off-by: Michal Hocko
While running xfstests on next-20151223 I hit a pair of kernel BUGs
that bisected to this commit:
1eb3a80d8239 ("mm, oom: introduce oom reaper")
Here is a BUG produced by generic/029 when run against XFS:
[ 235.751723] [ cut here ]
[ 235.752194] kernel BUG at mm/filemap.c:208!
[ 235.752595] invalid opcode: [#1] SMP
[ 235.753036] Modules linked in: nd_pmem nd_btt nd_e820 libnvdimm
[ 235.753681] CPU: 3 PID: 17586 Comm: xfs_io Not tainted
4.4.0-rc6-next-20151223_new_fsync_v6+ #8
[ 235.754535] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140709_153950- 04/01/2014
[ 235.755451] task: 88040bde19c0 ti: 8800bab8 task.ti:
8800bab8
[ 235.756202] RIP: 0010:[] []
__delete_from_page_cache+0x206/0x440
[ 235.757151] RSP: 0018:8800bab83b60 EFLAGS: 00010082
[ 235.757679] RAX: 0021 RBX: ea0007d37e00 RCX: 0006
[ 235.758360] RDX: R
[ANNOUNCE] 4.4-rc6-rt1
Please don't continue reading before christmas eve (or morning, depending on your schedule). If you don't celebrate christmas, well go ahead. Dear RT folks! I'm pleased to announce the v4.4-rc6-rt1 patch set. I tested it on my AMD A10, 64bit. Nothing exploded so far, filesystem is still there. I haven't tested it on anything else. Before someone asks: this does not mean it does *not* work on ARM I simply did not try it. If you are brave then download it, install it and have fun. If something breaks, please report it. If your machine starts blinking like a christmas tree while using the patch then *please* send a photo. Changes since v4.1.15-rt17: - rebase to v4.4-rc6 Known issues (inherited from v4.1-RT): - bcache stays disabled - CPU hotplug is not better than before - The netlink_release() OOPS, reported by Clark, is still on the list, but unsolved due to lack of information - Christoph Mathys reported a stall in cgroup locking code while using Linux containers. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git v4.4-rc6-rt1 The RT patch against 4.4-rc6 can be found here: https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4-rc6-rt1.patch.xz The split quilt queue is available at: https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patches-4.4-rc6-rt1.tar.xz 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 v2 3/3] clocksource/vt8500: Add register R/W functions
From: Roman Volkov
vt8500 timer requires special synchronization for accessing some of its
registers. Define special read and write functions to handle this process
transparently.
Use relaxed read/write, according to the following:
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/117658:
"For accesses to the same device we don't
actually need any barriers on ARM as this is guaranteed by the
architecture."
To perform a read from the Timer Count register, user must write a one
to the Timer Control register and wait for completion flag by polling the
Timer Read Count Active bit.
To perform a write to the Count or Match registers, user must poll the
write completion flag for the corresponding register to ensure that the
previous write completed and then write the actual value.
Signed-off-by: Roman Volkov
---
drivers/clocksource/vt8500_timer.c | 88 --
1 file changed, 66 insertions(+), 22 deletions(-)
diff --git a/drivers/clocksource/vt8500_timer.c
b/drivers/clocksource/vt8500_timer.c
index eb08d96..fd88a5b 100644
--- a/drivers/clocksource/vt8500_timer.c
+++ b/drivers/clocksource/vt8500_timer.c
@@ -38,32 +38,75 @@
#define VT8500_TIMER_OFFSET0x0100
#define VT8500_TIMER_HZ300
-#define TIMER_MATCH_VAL0x
+#define TIMER_MATCH0_VAL 0x
+#define TIMER_MATCH1_VAL 0x0004
+#define TIMER_MATCH2_VAL 0x0008
+#define TIMER_MATCH3_VAL 0x000c
#define TIMER_COUNT_VAL0x0010
#define TIMER_STATUS_VAL 0x0014
#define TIMER_IER_VAL 0x001c /* interrupt enable */
#define TIMER_CTRL_VAL 0x0020
#define TIMER_AS_VAL 0x0024 /* access status */
-#define TIMER_COUNT_R_ACTIVE (1 << 5)/* not ready for read */
-#define TIMER_COUNT_W_ACTIVE (1 << 4)/* not ready for write */
-#define TIMER_MATCH_W_ACTIVE (1 << 0)/* not ready for write */
+/* R/W status flags */
+#define TIMER_COUNT_R_ACTIVE (1 << 5)
+#define TIMER_COUNT_W_ACTIVE (1 << 4)
+#define TIMER_MATCH3_W_ACTIVE (1 << 3)
+#define TIMER_MATCH2_W_ACTIVE (1 << 2)
+#define TIMER_MATCH1_W_ACTIVE (1 << 1)
+#define TIMER_MATCH0_W_ACTIVE (1 << 0)
#define MIN_OSCR_DELTA 16
+#define vt8500_timer_sync(bit) { while (readl_relaxed \
+ (regbase + TIMER_AS_VAL) & bit) \
+ cpu_relax(); }
+
static void __iomem *regbase;
-static cycle_t vt8500_timer_read(struct clocksource *cs)
+static void vt8500_timer_write(u32 value, unsigned long reg)
{
- writel(3, regbase + TIMER_CTRL_VAL);
- while (readl(regbase + TIMER_AS_VAL) & TIMER_COUNT_R_ACTIVE)
- cpu_relax();
- return readl(regbase + TIMER_COUNT_VAL);
+ switch (reg) {
+ case TIMER_COUNT_VAL:
+ vt8500_timer_sync(TIMER_COUNT_W_ACTIVE);
+ break;
+ case TIMER_MATCH0_VAL:
+ vt8500_timer_sync(TIMER_MATCH0_W_ACTIVE);
+ break;
+ case TIMER_MATCH1_VAL:
+ vt8500_timer_sync(TIMER_MATCH1_W_ACTIVE);
+ break;
+ case TIMER_MATCH2_VAL:
+ vt8500_timer_sync(TIMER_MATCH2_W_ACTIVE);
+ break;
+ case TIMER_MATCH3_VAL:
+ vt8500_timer_sync(TIMER_MATCH3_W_ACTIVE);
+ break;
+ }
+
+ writel_relaxed(value, regbase + reg);
+}
+
+static u32 vt8500_timer_read(unsigned long reg)
+{
+ if (reg == TIMER_COUNT_VAL) {
+ vt8500_timer_write(3, TIMER_CTRL_VAL);
+ vt8500_timer_sync(TIMER_COUNT_R_ACTIVE);
+
+ return readl_relaxed(regbase + TIMER_COUNT_VAL);
+ }
+
+ return readl_relaxed(regbase + reg);
+}
+
+static cycle_t vt8500_oscr0_read(struct clocksource *cs)
+{
+ return vt8500_timer_read(TIMER_COUNT_VAL);
}
static struct clocksource clocksource = {
.name = "vt8500_timer",
.rating = 200,
- .read = vt8500_timer_read,
+ .read = vt8500_oscr0_read,
.mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
@@ -71,23 +114,24 @@ static struct clocksource clocksource = {
static int vt8500_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
- cycle_t alarm = clocksource.read() + cycles;
- while (readl(regbase + TIMER_AS_VAL) & TIMER_MATCH_W_ACTIVE)
- cpu_relax();
- writel((unsigned long)alarm, regbase + TIMER_MATCH_VAL);
+ unsigned long alarm = vt8500_timer_read(TIMER_COUNT_VAL) + cycles;
- if ((signed)(alarm - clocksource.read()) <= MIN_OSCR_DELTA)
+ vt8500_timer_write(alarm, TIMER_MATCH0_VAL);
+ if ((signed)(alarm - vt8500_timer_read(
+ TIMER_COUNT_VAL)) <= MIN_OSCR_DELTA) {
return -ETIME;
+ }
- writel(1,
RE: [char-misc-next v3 4/8] watchdog: mei_wdt: add status debugfs entry
>
> On 12/21/2015 03:17 PM, Tomas Winkler wrote:
> > Add entry for dumping current watchdog internal state
> >
> > Signed-off-by: Tomas Winkler
> > ---
> > V2: new in the series
> > V3: rebase
> > drivers/watchdog/mei_wdt.c | 88
> ++
> > 1 file changed, 88 insertions(+)
> >
> > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> > index 5b28a1e95ac1..ab9aec218d69 100644
> > --- a/drivers/watchdog/mei_wdt.c
> > +++ b/drivers/watchdog/mei_wdt.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -54,6 +55,24 @@ enum mei_wdt_state {
> > MEI_WDT_STOPPING,
> > };
> >
> > +#if IS_ENABLED(CONFIG_DEBUG_FS)
> > +static const char *mei_wdt_state_str(enum mei_wdt_state state)
> > +{
> > + switch (state) {
> > + case MEI_WDT_IDLE:
> > + return "IDLE";
> > + case MEI_WDT_START:
> > + return "START";
> > + case MEI_WDT_RUNNING:
> > + return "RUNNING";
> > + case MEI_WDT_STOPPING:
> > + return "STOPPING";
> > + default:
> > + return "unknown";
> > + }
> > +}
> > +#endif /* CONFIG_DEBUG_FS */
> > +
> I still don't understand why this code has to be here instead of
> further below (at <> mark).
Once it follow closely after enum definition, second in the next patch the
Ifdef is removed since we use the function in debug output and not only in
debugfs.
>
> > struct mei_wdt;
> >
> > /**
> > @@ -76,6 +95,8 @@ struct mei_wdt_dev {
> >* @cldev: mei watchdog client device
> >* @state: watchdog internal state
> >* @timeout: watchdog current timeout
> > + *
> > + * @dbgfs_dir: debugfs dir entry
> >*/
> > struct mei_wdt {
> > struct mei_wdt_dev *mwd;
> > @@ -83,6 +104,10 @@ struct mei_wdt {
> > struct mei_cl_device *cldev;
> > enum mei_wdt_state state;
> > u16 timeout;
> > +
> > +#if IS_ENABLED(CONFIG_DEBUG_FS)
> > + struct dentry *dbgfs_dir;
> > +#endif /* CONFIG_DEBUG_FS */
> > };
> >
> > /*
> > @@ -387,6 +412,65 @@ static int mei_wdt_register(struct mei_wdt *wdt)
> > return 0;
> > }
> >
> > +#if IS_ENABLED(CONFIG_DEBUG_FS)
> > +
>
> <>
>
> > +static ssize_t mei_dbgfs_read_state(struct file *file, char __user *ubuf,
> > + size_t cnt, loff_t *ppos)
> > +{
> > + struct mei_wdt *wdt = file->private_data;
> > + const size_t bufsz = 32;
> > + char buf[32];
> > + ssize_t pos = 0;
> > +
> > + pos += scnprintf(buf + pos, bufsz - pos, "state: %s\n",
> > +mei_wdt_state_str(wdt->state));
> > +
> Seems to me that "pos = ..." would accomplish exactly the same
> without having to pre-initialize pos. I also don't understand the use of
> "+ pos" and "- pos" in the parameter field. pos is 0, isn't it ?
> When would it ever be non-0 ?
>
> pos = scnprintf(buf, sizeof(buf), "state: %s\n", mei_wdt_state_str(wdt-
> >state));
>
> What am I missing here ?
Not you are not missing anything, it's just an idiom taken from all my debugfs
function with multiline output.
>
> > + return simple_read_from_buffer(ubuf, cnt, ppos, buf, pos);
> > +}
> > +
> > +static const struct file_operations dbgfs_fops_state = {
> > + .open = simple_open,
> > + .read = mei_dbgfs_read_state,
> > + .llseek = generic_file_llseek,
> > +};
> > +
> > +static void dbgfs_unregister(struct mei_wdt *wdt)
> > +{
> > + if (!wdt->dbgfs_dir)
> > + return;
> > + debugfs_remove_recursive(wdt->dbgfs_dir);
>
> debugfs_remove_recursive() checks if the parameter is NULL,
> so it is not necessary to check if it is NULL before the call.
Correct, I can be fixed.
>
> > + wdt->dbgfs_dir = NULL;
> > +}
> > +
> > +static int dbgfs_register(struct mei_wdt *wdt)
> > +{
> > + struct dentry *dir, *f;
> > +
> > + dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
> > + if (!dir)
> > + return -ENOMEM;
> > +
> > + wdt->dbgfs_dir = dir;
> > + f = debugfs_create_file("state", S_IRUSR, dir, wdt, _fops_state);
> > + if (!f)
> > + goto err;
> > +
> > + return 0;
> > +err:
> > + dbgfs_unregister(wdt);
> > + return -ENODEV;
>
> The error value is ignored by the caller - why bother returning an error in
> the first
> place ?
A function doesn't take responsibility on how it used.
>
> > +}
> > +
> > +#else
> > +
> > +static inline void dbgfs_unregister(struct mei_wdt *wdt) {}
> > +
> > +static inline int dbgfs_register(struct mei_wdt *wdt)
> > +{
> > + return 0;
> > +}
> > +#endif /* CONFIG_DEBUG_FS */
> > +
> > static int mei_wdt_probe(struct mei_cl_device *cldev,
> > const struct mei_cl_device_id *id)
> > {
> > @@ -414,6 +498,8 @@ static int mei_wdt_probe(struct mei_cl_device *cldev,
> > if (ret)
> > goto err_disable;
> >
> > + dbgfs_register(wdt);
> > +
> > return 0;
> >
> > err_disable:
> > @@ -433,6 +519,8 @@ static int mei_wdt_remove(struct mei_cl_device
RE: [lustre-devel] [PATCH] staging: lustre: Remove unused memhog functionality
>On 2015/12/23, 14:40, "Simmons, James A." wrote:
>
>>>From: Niranjan Dighe
>>>
>>>Remove IOC_LIBCFS_MEMHOG ioctl functionality as it is no longer needed
>>>thereby
>>>making functions like - kportal_memhog_alloc(), kportal_memhog_free()
>>>and type -
>>>struct libcfs_device_userstate unused.
>>
>>Actually so much more can be cleaned up. This work is also being done at
>>
>>http://review.whamcloud.com/#/c/17492.
>>
>>I will update that patch and post it here as well.
>
>James, part of that patch is for the userspace tools, which isn't
>applicable here. Also, it probably makes sense to delete the panic injection
>as a
>separate patch, so I think this patch is good as-is for removing memhog.
After looking at the code I agree. At first I thought it would be a simple
cleanup expansion
of this patch but I see a lot more cleanups coming after this. This work is the
first step to
removing the cfs_psdev_* abstraction. I will submit the cleanups soon. For now
this patch
can be merged.
Acked-by: James Simmons
>
>
>Signed-off-by: Niranjan Dighe
>---
> .../lustre/include/linux/libcfs/libcfs_private.h |5 -
> .../lustre/lustre/libcfs/linux/linux-module.c | 14 +-
> drivers/staging/lustre/lustre/libcfs/module.c | 139
>
> 3 files changed, 2 insertions(+), 156 deletions(-)
>
>diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
>b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
>index d6273e1..e044d6f 100644
>--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
>+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
>@@ -391,11 +391,6 @@ int cfs_percpt_atomic_summary(atomic_t **refs);
> * Support for temporary event tracing with minimal Heisenberg effect.
> *
>*/
>
>-struct libcfs_device_userstate {
>- intldu_memhog_pages;
>- struct page *ldu_memhog_root_page;
>-};
>-
> #define MKSTR(ptr) ((ptr)) ? (ptr) : ""
>
> static inline int cfs_size_round4(int val)
>diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
>b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
>index 70a99cf0..eccfe8bd 100644
>--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
>+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
>@@ -98,14 +98,12 @@ int libcfs_ioctl_popdata(void *arg, void *data, int
>size)
> static int
> libcfs_psdev_open(struct inode *inode, struct file *file)
> {
>- struct libcfs_device_userstate **pdu = NULL;
> intrc = 0;
>
> if (!inode)
> return -EINVAL;
>- pdu = (struct libcfs_device_userstate **)>private_data;
> if (libcfs_psdev_ops.p_open != NULL)
>- rc = libcfs_psdev_ops.p_open(0, (void *)pdu);
>+ rc = libcfs_psdev_ops.p_open(0, NULL);
> else
> return -EPERM;
> return rc;
>@@ -115,14 +113,12 @@ libcfs_psdev_open(struct inode *inode, struct file
>*file)
> static int
> libcfs_psdev_release(struct inode *inode, struct file *file)
> {
>- struct libcfs_device_userstate *pdu;
> intrc = 0;
>
> if (!inode)
> return -EINVAL;
>- pdu = file->private_data;
> if (libcfs_psdev_ops.p_close != NULL)
>- rc = libcfs_psdev_ops.p_close(0, (void *)pdu);
>+ rc = libcfs_psdev_ops.p_close(0, NULL);
> else
> rc = -EPERM;
> return rc;
>@@ -152,14 +148,8 @@ static long libcfs_ioctl(struct file *file,
> return -EPERM;
> panic("debugctl-invoked panic");
> return 0;
>- case IOC_LIBCFS_MEMHOG:
>- if (!capable(CFS_CAP_SYS_ADMIN))
>- return -EPERM;
>- /* go thought */
> }
>
>- pfile.off = 0;
>- pfile.private_data = file->private_data;
> if (libcfs_psdev_ops.p_ioctl != NULL)
> rc = libcfs_psdev_ops.p_ioctl(, cmd, (void *)arg);
> else
>diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
>b/drivers/staging/lustre/lustre/libcfs/module.c
>index 329d78c..0067e53 100644
>--- a/drivers/staging/lustre/lustre/libcfs/module.c
>+++ b/drivers/staging/lustre/lustre/libcfs/module.c
>@@ -68,142 +68,16 @@ MODULE_LICENSE("GPL");
>
> static struct dentry *lnet_debugfs_root;
>
>-static void kportal_memhog_free(struct libcfs_device_userstate *ldu)
>-{
>- struct page **level0p = >ldu_memhog_root_page;
>- struct page **level1p;
>- struct page **level2p;
>- intcount1;
>- intcount2;
>-
>- if (*level0p != NULL) {
>-
>- level1p = (struct page **)page_address(*level0p);
>- count1 = 0;
>-
>- while (count1 < PAGE_CACHE_SIZE/sizeof(struct page *) &&
>- *level1p != NULL) {
>-
>- level2p = (struct page **)page_address(*level1p);
>- count2 = 0;
>-
>-
[PATCH net] openvswitch: Fix template leak in error cases.
Commit 5b48bb8506c5 ("openvswitch: Fix helper reference leak") fixed a
reference leak on helper objects, but inadvertently introduced a leak on
the ct template.
Previously, ct_info.ct->general.use was initialized to 0 by
nf_ct_tmpl_alloc() and only incremented when ovs_ct_copy_action()
returned successful. If an error occurred while adding the helper or
adding the action to the actions buffer, the __ovs_ct_free_action()
cleanup would use nf_ct_put() to free the entry; However, this relies on
atomic_dec_and_test(ct_info.ct->general.use). This reference must be
incremented first, or nf_ct_put() will never free it.
Fix the issue by acquiring a reference to the template immediately after
allocation.
Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
Fixes: 5b48bb8506c5 ("openvswitch: Fix helper reference leak")
Signed-off-by: Joe Stringer
---
net/openvswitch/conntrack.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 8fc1bafc99fd..c6d8738d6970 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -683,6 +683,10 @@ int ovs_ct_copy_action(struct net *net, const struct
nlattr *attr,
OVS_NLERR(log, "Failed to allocate conntrack template");
return -ENOMEM;
}
+
+ __set_bit(IPS_CONFIRMED_BIT, _info.ct->status);
+ nf_conntrack_get(_info.ct->ct_general);
+
if (helper) {
err = ovs_ct_add_helper(_info, helper, key, log);
if (err)
@@ -694,8 +698,6 @@ int ovs_ct_copy_action(struct net *net, const struct nlattr
*attr,
if (err)
goto err_free_ct;
- __set_bit(IPS_CONFIRMED_BIT, _info.ct->status);
- nf_conntrack_get(_info.ct->ct_general);
return 0;
err_free_ct:
__ovs_ct_free_action(_info);
--
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/
