Re: [PATCH] drm/rockchip: Set line flag config register in vop_crtc_enable
On 2017年04月27日 14:54, Jeffy Chen wrote:
We need to set vop config done after update line flag config, it's a
new requirement for chips newer than rk3368.
Since we would only use line flag irq for vact_end, let's move it to
vop_crtc_enable.
Signed-off-by: Jeffy Chen
looks good for me:
Acked-by: Mark Yao
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 4 ++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 +---
3 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d8fa7a9..9bfdbc6 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -115,8 +115,8 @@ static void analogix_dp_psr_work(struct work_struct *work)
vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + crtc->mode.vdisplay;
- ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
- PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+ ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
+PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
dev_err(dp->dev, "line flag interrupt did not arrive\n");
return;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index a48fcce..47905fa 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -62,8 +62,7 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct device *dev);
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
-int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
- unsigned int mstimeout);
+int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout);
extern struct platform_driver cdn_dp_driver;
extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 3f7a82d..40a5e6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -468,7 +468,7 @@ static bool vop_line_flag_irq_is_enabled(struct vop *vop)
return !!line_flag_irq;
}
-static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
+static void vop_line_flag_irq_enable(struct vop *vop)
{
unsigned long flags;
@@ -477,7 +477,6 @@ static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
spin_lock_irqsave(&vop->irq_lock, flags);
- VOP_CTRL_SET(vop, line_flag_num[0], line_num);
VOP_INTR_SET_TYPE(vop, clear, LINE_FLAG_INTR, 1);
VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
@@ -981,6 +980,8 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
+ VOP_CTRL_SET(vop, line_flag_num[0], vact_end);
+
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
VOP_CTRL_SET(vop, standby, 0);
@@ -1507,19 +1508,16 @@ static void vop_win_init(struct vop *vop)
}
/**
- * rockchip_drm_wait_line_flag - acqiure the give line flag event
+ * rockchip_drm_wait_vact_end
* @crtc: CRTC to enable line flag
- * @line_num: interested line number
* @mstimeout: millisecond for timeout
*
- * Driver would hold here until the interested line flag interrupt have
- * happened or timeout to wait.
+ * Wait for vact_end line flag irq or timeout.
*
* Returns:
* Zero on success, negative errno on failure.
*/
-int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
- unsigned int mstimeout)
+int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout)
{
struct vop *vop = to_vop(crtc);
unsigned long jiffies_left;
@@ -1527,14 +1525,14 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc,
unsigned int line_num,
if (!crtc || !vop->is_enabled)
return -ENODEV;
- if (line_num > crtc->mode.vtotal || mstimeout <= 0)
+ if (mstimeout <= 0)
return -EINVAL;
if (vop_line_flag_irq_is_enabled(vop))
return -EBUSY;
reinit_completion(&vop->line_flag_completion);
- vop_line_flag_irq_enable(vop, line_num);
+ vop_line_flag_irq_enable(vop);
jiffies_left = wait_for_completion_timeout(&vop->line_flag_completion,
msecs_to_jiffies(mstimeout));
@@ -1547,7 +1545,7 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc,
unsigned int line_num,
return 0;
}
-EXPORT_SYMBOL(rockchip_drm_wait_line_flag);
+EXPO
Re: [PATCH 1/2] sched/fair: Fix how load gets propagated from cfs_rq to its sched_entity
On 27 April 2017 at 00:40, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 26, 2017 at 06:51:23PM +0200, Vincent Guittot wrote:
>> > It's not temporary. The weight of a group is its shares, which is its
>> > load fraction of the configured weight of the group. Assuming UP, if
>> > you configure a group to the weight of 1024 and have any task running
>> > full-tilt in it, the group will converge to the load of 1024. The
>> > problem is that the propagation logic is currently doing something
>> > completely different and temporarily push down the load whenever it
>> > triggers.
>>
>> Ok, I see your point and agree that there is an issue when propagating
>> load_avg of a task group which has tasks with lower weight than the share
>> but your proposal has got issue because it uses runnable_load_avg instead
>> of load_avg and this makes propagation of loadavg_avg incorrect, something
>> like below which keeps using load_avg solve the problem
>>
>> + if (gcfs_rq->load.weight) {
>> + long shares = scale_load_down(calc_cfs_shares(gcfs_rq,
>> gcfs_rq->tg));
>> +
>> + load = min(gcfs_rq->avg.load_avg *
>> +shares / scale_load_down(gcfs_rq->load.weight),
>> shares);
>>
>> I have run schbench with the change above on v4.11-rc8 and latency are ok
>
> Hmm... so, I'll test this but this wouldn't solve the problem of
> root's runnable_load_avg being out of sync with the approximate sum of
> all task loads, which is the cause of the latencies that I'm seeing.
>
> Are you saying that with the above change, you're not seeing the
> higher latency issue that you reported in the other reply?
yes I don't have any latency regression like v4.11-rc8 with the above
change that uses load_avg but fix the propagation for of a task with a
lower weight than task group share.
>
> Thanks.
>
> --
> tejun
Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
On 27/04/17 03:45 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in
>>> another thread?
>>
>> Right.
>>
>>
>>> What about dumb bos? You've mentioned the swap flag isn't used for
>>> those. Which implies they are in little endian byte order (both gpu and
>>> cpu view).
>>
>> Right, AFAICT from looking at the code.
>
> Ok.
>
> And I also don't see an easy way to make them big endian (cpu view)
> using swapping with the existing drm interfaces, given we apply a format
> when we put the bo into use as framebuffer, not when creating it. So
> userspace can: (1) create dumb bo, (2) map bo, (3) write something bo,
> (4) create fb + attach to crtc. And at (3) we don't know the format
> yet, so we can't configure swapping accordingly.
>
> So just not using the swapping indeed looks like the only sensible
> option. Which in turn implies there is no BGRA support for dumb
> bos. Hmm, I can see the problem. Userspace expectation appears to be
> that ADDFB configures a native endian framebuffer, which the driver
> simply can't do on bigendian.
... with pre-R600 GPUs.
> So, what can/should the driver do here? Throw errors for ADDFB and
> force userspace to use ADDFB2? From a design point of view the best
> option, but in the other hand I suspect that could break the xorg radeon
> driver ...
Yes, it would.
One thing we could do is provide a way for userspace to query the
effective format(s) as seen by the GPU and/or CPU.
It might also make sense for the radeon driver to set the
RADEON_TILING_SWAP_{16,32}BIT flags for dumb BOs. I wonder about the
status of apps using dumb BOs directly wrt this discussion.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Re: [PATCH v2] clk: sunxi-ng: Fix dependency on SUNXI_CCU_GATE
On Wed, Apr 26, 2017 at 01:53:19PM +0200, Corentin Labbe wrote:
> When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got
> the following build error:
> drivers/built-in.o: In function `ccu_pll_notifier_cb':
> drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to
> `ccu_gate_helper_disable'
> drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference to
> `ccu_gate_helper_enable'
>
> The problem is the function ccu_pll_notifier_cb in ccu_common.c need
> some function from ccu_gate.c which is not compiled since SUNXI_CCU_GATE
> is not selected.
>
> This patch remove SUNXI_CCU_GATE and compile ccu_gate.c unconditionnaly
> since all other combination of options select SUNXI_CCU_GATE finally.
>
> Fixes: 02ae2bc6febd ("clk: sunxi-ng: Add clk notifier to gate then ungate PLL
> clocks")
> Signed-off-by: Corentin Labbe
I think Chen-Yu had some comments that you didn't address.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out
Minchan Kim writes: > On Tue, Apr 25, 2017 at 08:56:56PM +0800, Huang, Ying wrote: >> From: Huang Ying >> >> In this patch, splitting huge page is delayed from almost the first >> step of swapping out to after allocating the swap space for the >> THP (Transparent Huge Page) and adding the THP into the swap cache. >> This will batch the corresponding operation, thus improve THP swap out >> throughput. >> >> This is the first step for the THP swap optimization. The plan is to >> delay splitting the THP step by step and avoid splitting the THP >> finally. >> >> The advantages of the THP swap support include: >> >> - Batch the swap operations for the THP and reduce lock >> acquiring/releasing, including allocating/freeing the swap space, >> adding/deleting to/from the swap cache, and writing/reading the swap >> space, etc. This will help to improve the THP swap performance. >> >> - The THP swap space read/write will be 2M sequential IO. It is >> particularly helpful for the swap read, which usually are 4k random >> IO. This will help to improve the THP swap performance. >> >> - It will help the memory fragmentation, especially when the THP is >> heavily used by the applications. The 2M continuous pages will be >> free up after the THP swapping out. >> >> - It will improve the THP utilization on the system with the swap >> turned on. Because the speed for khugepaged to collapse the normal >> pages into the THP is quite slow. After the THP is split during the >> swapping out, it will take quite long time for the normal pages to >> collapse back into the THP after being swapped in. The high THP >> utilization helps the efficiency of the page based memory management >> too. >> >> There are some concerns regarding THP swap in, mainly because possible >> enlarged read/write IO size (for swap in/out) may put more overhead on >> the storage device. To deal with that, the THP swap in should be >> turned on only when necessary. For example, it can be selected via >> "always/never/madvise" logic, to be turned on globally, turned off >> globally, or turned on only for VMA with MADV_HUGEPAGE, etc. >> >> In this patch, one swap cluster is used to hold the contents of each >> THP swapped out. So, the size of the swap cluster is changed to that >> of the THP (Transparent Huge Page) on x86_64 architecture (512). For >> other architectures which want such THP swap optimization, >> ARCH_USES_THP_SWAP_CLUSTER needs to be selected in the Kconfig file >> for the architecture. In effect, this will enlarge swap cluster size >> by 2 times on x86_64. Which may make it harder to find a free cluster >> when the swap space becomes fragmented. So that, this may reduce the >> continuous swap space allocation and sequential write in theory. The >> performance test in 0day shows no regressions caused by this. > > What about other architecures? > > I mean THP page size on every architectures would be various. > If THP page size is much bigger than 2M, the architecture should > have big swap cluster size for supporting THP swap-out feature. > It means fast empty-swap cluster consumption so that it can suffer > from fragmentation easily which causes THP swap void and swap slot > allocations slow due to not being able to use per-cpu. > > What I suggested was contiguous multiple swap cluster allocations > to meet THP page size. If some of architecure's THP size is 64M > and SWAP_CLUSTER_SIZE is 2M, it should allocate 32 contiguos > swap clusters. For that, swap layer need to manage clusters sort > in order which would be more overhead in CONFIG_THP_SWAP case > but I think it's tradeoff. With that, every architectures can > support THP swap easily without arch-specific something. That may be a good solution for other architectures. But I am afraid I am not the right person to work on that. Because I don't know the requirement of other architectures, and I have no other architectures machines to work on and measure the performance. And the swap clusters aren't sorted in order now intentionally to avoid cache line false sharing between the spinlock of struct swap_cluster_info. If we want to sort clusters in order, we need a solution for that. > If (PAGE_SIZE * 512) swap cluster size were okay for most of > architecture, just increase it. It's orthogonal work regardless of > THP swapout. Then, we don't need to manage swap clusters sort > in order in x86_64 which SWAP_CLUSTER_SIZE is equal to > THP_PAGE_SIZE. It's just a bonus by side-effect. Andrew suggested to make swap cluster size = huge page size (or turn on THP swap optimization) only if we enabled CONFIG_THP_SWAP. So that, THP swap optimization will not be turned on unintentionally. We may adjust default swap cluster size, but I don't think it need to be in this patchset. > AFAIR, I suggested it but cannot remember why we cannot go with > this way. > >> >> In the future of THP swap optimization, some information of the >> swapped o
Re: [linux-sunxi] Re: [PATCH v5 02/11] clk: sunxi-ng: add support for DE2 CCU
On Mon, Apr 24, 2017 at 06:26:51PM +0800, icen...@aosc.io wrote:
> 在 2017-04-24 16:51，Maxime Ripard 写道：
> > Hi,
> >
> > On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
> > > +static const struct of_device_id sunxi_de2_clk_ids[] = {
> > > + {
> > > + .compatible = "allwinner,sun8i-a83t-de2-clk",
> > > + .data = &sun8i_a83t_de2_clk_desc,
> > > + },
> > > + {
> > > + .compatible = "allwinner,sun50i-h5-de2-clk",
> > > + .data = &sun50i_a64_de2_clk_desc,
> > > + },
> > > + /*
> > > + * The Allwinner A64 SoC needs some bit to be poke in syscon to make
> > > + * DE2 really working.
> > > + * So there's currently no A64 compatible here.
> > > + * H5 shares the same reset line with A64, so here H5 is using the
> > > + * clock description of A64.
> > > + */
> > > + { }
> > > +};
> >
> > So that A64 driver would require more than just what you defined in
> > the binding in order to operate?
>
> Yes. When trying to do A64 driver, I will send out first a patch to
> add the needed binding bit.
Then remove the A64 compatible from the binding document.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH] drm/i915/gvt: fix typo: "supporte" -> "support"
On 2017.04.25 10:05:12 +0100, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to typo in WARN_ONCE message
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 0ad1a508e2af..c995e540ff96 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -1244,7 +1244,7 @@ static int dma_ctrl_write(struct intel_vgpu *vgpu,
> unsigned int offset,
> mode = vgpu_vreg(vgpu, offset);
>
> if (GFX_MODE_BIT_SET_IN_MASK(mode, START_DMA)) {
> - WARN_ONCE(1, "VM(%d): iGVT-g doesn't supporte GuC\n",
> + WARN_ONCE(1, "VM(%d): iGVT-g doesn't support GuC\n",
> vgpu->id);
> return 0;
> }
> --
applied, thanks!
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
Re: [PATCH 2/2] x86/KASLR: Use old ident map page table if physical randomization failed
On 04/26/17 at 12:12pm, Kees Cook wrote: > On Wed, Apr 26, 2017 at 3:39 AM, Baoquan He wrote: > > Dave found when kdump kernel will reset to bios immediately if kaslr > > is enabled and physical randomization failed to faind a new position > > for kernel. But nokaslr works in this case. > > > > The reason is kaslr will install a new page table for ident mapping, > > while it missed to consider building ident mapping for original area > > of kernel if kaslr failed on physical randomization. > > > > In fact bootloaders including kexec/kdump have built ident mapping > > for original place of kernel. We can only install new ident mapping > > page table when physical kaslr succeeds. Otherwise we just keep the > > old page table unchanged just like nokaslr does. > > > > Signed-off-by: Baoquan He > > Signed-off-by: Dave Young > > Cc: "H. Peter Anvin" > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: x...@kernel.org > > Cc: Kees Cook > > Cc: Yinghai Lu > > Cc: Borislav Petkov > > Cc: Dave Jiang > > Cc: Thomas Garnier > > Nice catch! > > Acked-by: Kees Cook Thanks, Kees. Seems I forget telling this only happens in kexec/kdump kernel. Since the ident mapping has been built for kexec/kdump in 1st kernel for the whole memory by calling init_pgtable(). Here if physical randomizaiton failed, it won't build ident mapping for the original area of kernel but change to new page table '_pgtable'. Then kernel will reset to bios immediately caused by no ident mapping. While normal kernel won't be impacted because it comes here via startup_32() and cr3 will be _pgtable already. In startup_32() ident mapping is built for 0~4G area. In kaslr We just append to the existing area instead of entirely overwriting it for on-demand ident mapping building. So ident mapping for the original area of kernel is still there. I will post v2 with a improved patch log, and with your Acked-by. > > -Kees > > > --- > > arch/x86/boot/compressed/kaslr.c | 10 -- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/boot/compressed/kaslr.c > > b/arch/x86/boot/compressed/kaslr.c > > index e5eb0c3..7a8b443 100644 > > --- a/arch/x86/boot/compressed/kaslr.c > > +++ b/arch/x86/boot/compressed/kaslr.c > > @@ -650,10 +650,16 @@ void choose_random_location(unsigned long input, > > add_identity_map(random_addr, output_size); > > *output = random_addr; > > } > > + > > + /* > > +* This actually loads the identity pagetable on x86_64. > > +* And this should only be done only if a new position > > +* is found. Otherwise we should keep the old page table > > +* to make it be like nokaslr case. > > +*/ > > + finalize_identity_maps(); > > } > > > > - /* This actually loads the identity pagetable on x86_64. */ > > - finalize_identity_maps(); > > > > /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */ > > if (IS_ENABLED(CONFIG_X86_64)) > > -- > > 2.5.5 > > > > > > -- > Kees Cook > Pixel Security
Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption
On 04/21/17 at 02:55pm, Dave Hansen wrote: > On 04/18/2017 02:22 PM, Tom Lendacky wrote: > > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > > determine if SME is active. > > > > A new directory will be created: > > /sys/kernel/mm/sme/ > > > > And two entries within the new directory: > > /sys/kernel/mm/sme/active > > /sys/kernel/mm/sme/encryption_mask > > Why do they care, and what will they be doing with this information? Since kdump will copy old memory but need this to know if the old memory was encrypted or not. With this sysfs file we can know the previous SME status and pass to kdump kernel as like a kernel param. Tom, have you got chance to try if it works or not? Thanks Dave
[PATCH 2/3] arm64: ls1012a: dts: add ftm0 nodes
From: Zhang Ying-22455
Signed-off-by: Zhang Ying-22455
---
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index cffebb4..3b65d67 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -127,6 +127,14 @@
clocks = <&sysclk>;
};
+ ftm0: ftm0@29d {
+ compatible = "fsl,ftm-alarm";
+ reg = <0x0 0x29d 0x0 0x1>;
+ interrupts = <0 86 0x4>;
+ big-endian;
+ fsl,rcpm-wakeup = <&rcpm 0x0002>;
+ };
+
i2c0: i2c@218 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
--
2.1.0.27.g96db324
[PATCH 1/3] arm64: ls1046a: dts: add ftm0 nodes
From: Zhang Ying-22455
Signed-off-by: Zhang Ying-22455
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 4a164b8..1a8f1f4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -537,6 +537,14 @@
status = "disabled";
};
+ ftm0: ftm0@29d {
+ compatible = "fsl,ftm-alarm";
+ reg = <0x0 0x29d 0x0 0x1>;
+ interrupts = ;
+ big-endian;
+ fsl,rcpm-wakeup = <&rcpm 0x0002>;
+ };
+
wdog0: watchdog@2ad {
compatible = "fsl,imx21-wdt";
reg = <0x0 0x2ad 0x0 0x1>;
--
2.1.0.27.g96db324
[PATCH 3/3] arm64: ls2080a: dts: add ftm0 nodes
From: Zhang Ying-22455
Signed-off-by: Zhang Ying-22455
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e5935f2..e32e477 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -827,6 +827,12 @@
reg = <0x0 0x0400 0x0 0x0100>;
interrupts = <0 12 4>;
};
+
+ ftm0: ftm0@280 {
+ compatible = "fsl,ftm-alarm";
+ reg = <0x0 0x280 0x0 0x1>;
+ interrupts = <0 44 4>;
+ };
};
ddr1: memory-controller@108 {
--
2.1.0.27.g96db324
Re: [RFC PATCHv2 3/3] drm/vgem: Enable dmabuf import interfaces
On Wed, Apr 26, 2017 at 02:12:30PM -0700, Laura Abbott wrote:
> Enable the GEM dma-buf import interfaces in addition to the export
> interfaces. This lets vgem be used as a test source for other allocators
> (e.g. Ion).
>
> Signed-off-by: Laura Abbott
> ---
> v2: Don't require vgem allocated buffers to existing in memory before
> importing.
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 133
> +++-
> drivers/gpu/drm/vgem/vgem_drv.h | 2 +
> 2 files changed, 106 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 1b02e56..73a619a 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -34,6 +34,9 @@
> #include
> #include
> #include
> +
> +#include
> +
> #include "vgem_drv.h"
>
> #define DRIVER_NAME "vgem"
> @@ -46,6 +49,12 @@ static void vgem_gem_free_object(struct drm_gem_object
> *obj)
> {
> struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
>
> + if (vgem_obj->pages)
> + drm_free_large(vgem_obj->pages);
Just drm_free_large(vgem_obj->pages); NULL -> kfree() which is NULL safe.
The series lgtm, doesn't compromise on any of the existing tests.
All 3,
Reviewed-by: Chris Wilson
You could always get Joonas to nitpick over style...
> +
> + if (obj->import_attach)
> + drm_prime_gem_destroy(obj, vgem_obj->table);
> +
> drm_gem_object_release(obj);
> kfree(vgem_obj);
> }
> @@ -56,26 +65,48 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> struct drm_vgem_gem_object *obj = vma->vm_private_data;
> /* We don't use vmf->pgoff since that has the fake offset */
> unsigned long vaddr = vmf->address;
> - struct page *page;
> -
> - page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
> -(vaddr - vma->vm_start) >> PAGE_SHIFT);
> - if (!IS_ERR(page)) {
> - vmf->page = page;
> - return 0;
> - } else switch (PTR_ERR(page)) {
> - case -ENOSPC:
> - case -ENOMEM:
> - return VM_FAULT_OOM;
> - case -EBUSY:
> - return VM_FAULT_RETRY;
> - case -EFAULT:
> - case -EINVAL:
> - return VM_FAULT_SIGBUS;
> - default:
> - WARN_ON_ONCE(PTR_ERR(page));
> - return VM_FAULT_SIGBUS;
> + int ret;
> + loff_t num_pages;
> + pgoff_t page_offset;
> + page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> +
> + num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
> +
> + if (page_offset > num_pages)
> + return VM_FAULT_SIGBUS;
> +
> + if (obj->pages) {
> + get_page(obj->pages[page_offset]);
> + vmf->page = obj->pages[page_offset];
> + ret = 0;
> + } else {
> + struct page *page;
> +
> + page = shmem_read_mapping_page(
> + file_inode(obj->base.filp)->i_mapping,
> + page_offset);
> + if (!IS_ERR(page)) {
> + vmf->page = page;
> + ret = 0;
> + } else switch (PTR_ERR(page)) {
> + case -ENOSPC:
> + case -ENOMEM:
> + ret = VM_FAULT_OOM;
> + break;
> + case -EBUSY:
> + ret = VM_FAULT_RETRY;
> + break;
> + case -EFAULT:
> + case -EINVAL:
> + ret = VM_FAULT_SIGBUS;
> + break;
> + default:
> + WARN_ON(PTR_ERR(page));
> + ret = VM_FAULT_SIGBUS;
break;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Re: [PATCH] iio: core: Fix suspicious sizeof usage
On Thu, Apr 27, 2017 at 06:32:22AM +0100, Jonathan Cameron wrote:
> On 25/04/17 02:16, Orson Zhai wrote:
> > Pointer size is variours in different system, say 32bit for 4 and 64bit
> > for 8. The 'sizeof(infomask)' may lead to wrong bit numbers.
> >
> > Signed-off-by: Orson Zhai
> That's certainly been there a while. oops.
>
> Anyhow, whilst clearly garbage, it doesn't actually have an effect
> at the moment due to the relatively small number of bits that can be
> set and the fact this is limited by 32 bit platforms anyway.
>
> So applied to the togreg branch of iio.git and pushed out as
> testing for the auto builders to play with it.
Thank you!
-Orson
>
> Thanks,
>
> Jonathan
> > ---
> > drivers/iio/industrialio-core.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index 3ff91e0..795f53c 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1089,7 +1089,7 @@ static int iio_device_add_info_mask_type(struct
> > iio_dev *indio_dev,
> > {
> > int i, ret, attrcount = 0;
> >
> > - for_each_set_bit(i, infomask, sizeof(infomask)*8) {
> > + for_each_set_bit(i, infomask, sizeof(*infomask)*8) {
> > if (i >= ARRAY_SIZE(iio_chan_info_postfix))
> > return -EINVAL;
> > ret = __iio_add_chan_devattr(iio_chan_info_postfix[i],
> > @@ -1118,7 +1118,7 @@ static int iio_device_add_info_mask_type_avail(struct
> > iio_dev *indio_dev,
> > int i, ret, attrcount = 0;
> > char *avail_postfix;
> >
> > - for_each_set_bit(i, infomask, sizeof(infomask) * 8) {
> > + for_each_set_bit(i, infomask, sizeof(*infomask) * 8) {
> > avail_postfix = kasprintf(GFP_KERNEL,
> > "%s_available",
> > iio_chan_info_postfix[i]);
> >
>
Re: [PATCH v3 2/2] mfd: axp20x-i2c: Document that this must be builtin on x86
On Fri, 21 Apr 2017, Hans de Goede wrote: > On x86 the axp288 PMIC provides an ACPI OpRegion handler, which must be > available before other drivers using it are loaded, which can only be > ensured if the mfd, OpRegionr and i2c-bus drivers are built in. > > Since the axp20x mfd code is used on non X86 too we cannot simply change > this into a bool, I've tried some Kconfig magic with if x86 but I could > not get this working correctly, so this commit just documents that this > should be builtin on x86, which fixes errors like these during boot: > > mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA > ACPI Error: No handler for Region [REGS] (93543b0cc3a8) > [UserDefinedRegion] > ACPI Error: Region UserDefinedRegion (ID=143) has no handler > (20170119/exfldio-2 > ACPI Error: Method parse/execution failed [\_SB.PCI0.I2C7.PMI5.GET] (Node > 93 > ACPI Error: Method parse/execution failed [\_SB.PCI0.SHC1._PS0] (Node > 93543b > acpi 80860F14:02: Failed to change power state to D0 > > Signed-off-by: Hans de Goede > --- > Changes in v2: > -Fix Kconfig depends and selects to fix warning reported by kbuild test robot > -Improve commit msg (add example of ACPI errors this avoids) > Changes in v3: > -Since the axp20x mfd code is used on ARM too where it does not necessarily > need to be builtin settle for simply documenting the need to have this > builtin on x86 > --- > drivers/mfd/Kconfig | 5 + > 1 file changed, 5 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 4eb044e..1717372 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -156,6 +156,11 @@ config MFD_AXP20X_I2C > components like regulators or the PEK (Power Enable Key) under the > corresponding menus. > > + Note on x86 this provides an ACPI OpRegion, so this must be 'y' > + (builtin) and not a module, as the OpRegion must be available as > + soon as possible. For the same reason the i2c bus driver options > + I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_BAYTRAIL must be 'y' too. > + > config MFD_AXP20X_RSB > tristate "X-Powers AXP series PMICs with RSB" > select MFD_AXP20X -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[git pull] vfs.git fixes
* fix orangefs handling of faults on write() - I'd missed that one
back when orangefs was going through review.
* readdir counterpart of "9p: cope with bogus responses from server
in p9_client_{read,write}" - server might be lying or broken, and we'd better
not overrun the kmalloc'ed buffer we are copying the results into.
* NFS O_DIRECT read/write can leave iov_iter advanced by too much;
that's what had been causing iov_iter_pipe() warnings davej had been seeing.
* statx_timestamp.tv_nsec type fix (s32 -> u32). That one really
should go in before 4.11.
The following changes since commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3:
Linux 4.11-rc7 (2017-04-16 13:00:18 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
for you to fetch changes up to 1741937d475d91ed95abb37f07e8571e23b9a7fe:
uapi: change the type of struct statx_timestamp.tv_nsec to unsigned
(2017-04-26 21:19:05 -0400)
Al Viro (3):
orangefs_bufmap_copy_from_iovec(): fix EFAULT handling
p9_client_readdir() fix
fix nfs O_DIRECT advancing iov_iter too much
Dmitry V. Levin (1):
uapi: change the type of struct statx_timestamp.tv_nsec to unsigned
fs/nfs/direct.c | 27 ++-
fs/orangefs/orangefs-bufmap.c | 4 +---
include/uapi/linux/stat.h | 8 ++--
net/9p/client.c | 4
4 files changed, 25 insertions(+), 18 deletions(-)
Re: [Xen-devel] xen_exit_mmap() questions
>>> On 27.04.17 at 02:55, wrote: > The point of CR3 loading here, I believe, is to make sure the hypervisor > knows that the (v)CPU is no longer using the the mm's cr3 (we are > loading swapper_pgdir here). Correct, or else there would still be a non-zero refcount for the page tables hanging off of that CR3, disallowing those pages to become writable, and in turn disallowing the use of direct writes instead of hypercalls to clear the individual entries (or to be precise, direct writes would still be allowed, but their use would be even slower than using hypercalls because they would trap into the hypervisor for emulation). Jan
Re: [PATCH v4 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr
On 04/26/2017 12:41 PM, Dave Young wrote:
> Ccing ppc list
> On 04/20/17 at 07:39pm, Xunlei Pang wrote:
>> vmcoreinfo_max_size stands for the vmcoreinfo_data, the
>> correct one we should use is vmcoreinfo_note whose total
>> size is VMCOREINFO_NOTE_SIZE.
>>
>> Like explained in commit 77019967f06b ("kdump: fix exported
>> size of vmcoreinfo note"), it should not affect the actual
>> function, but we better fix it, also this change should be
>> safe and backward compatible.
>>
>> After this, we can get rid of variable vmcoreinfo_max_size,
>> let's use the corresponding macros directly, fewer variables
>> means more safety for vmcoreinfo operation.
>>
>> Cc: Mahesh Salgaonkar
>> Cc: Hari Bathini
>> Signed-off-by: Xunlei Pang
Reviewed-by: Mahesh Salgaonkar
Thanks,
-Mahesh.
>> ---
>> v3->v4:
>> -Rebased on the latest linux-next
>>
>> arch/powerpc/kernel/fadump.c | 3 +--
>> include/linux/crash_core.h | 1 -
>> kernel/crash_core.c | 3 +--
>> 3 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
>> index 466569e..7bd6cd0 100644
>> --- a/arch/powerpc/kernel/fadump.c
>> +++ b/arch/powerpc/kernel/fadump.c
>> @@ -893,8 +893,7 @@ static int fadump_create_elfcore_headers(char *bufp)
>>
>> phdr->p_paddr = fadump_relocate(paddr_vmcoreinfo_note());
>> phdr->p_offset = phdr->p_paddr;
>> -phdr->p_memsz = vmcoreinfo_max_size;
>> -phdr->p_filesz = vmcoreinfo_max_size;
>> +phdr->p_memsz = phdr->p_filesz = VMCOREINFO_NOTE_SIZE;
>>
>> /* Increment number of program headers. */
>> (elf->e_phnum)++;
>> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
>> index ba283a2..7d6bc7b 100644
>> --- a/include/linux/crash_core.h
>> +++ b/include/linux/crash_core.h
>> @@ -55,7 +55,6 @@
>>
>> extern u32 *vmcoreinfo_note;
>> extern size_t vmcoreinfo_size;
>> -extern size_t vmcoreinfo_max_size;
>>
>> Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
>>void *data, size_t data_len);
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 0321f04..43cdb00 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -16,7 +16,6 @@
>> /* vmcoreinfo stuff */
>> static unsigned char *vmcoreinfo_data;
>> size_t vmcoreinfo_size;
>> -size_t vmcoreinfo_max_size = VMCOREINFO_BYTES;
>> u32 *vmcoreinfo_note;
>>
>> /*
>> @@ -343,7 +342,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>> r = vscnprintf(buf, sizeof(buf), fmt, args);
>> va_end(args);
>>
>> -r = min(r, vmcoreinfo_max_size - vmcoreinfo_size);
>> +r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>>
>> memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
>>
>> --
>> 1.8.3.1
>>
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>
> Reviewed-by: Dave Young
>
> Thanks
> Dave
>
[PATCH 3/4] Add new Alps U1 Touchpad device
From: Masaki Ota
-Add new Alps U1 Touchpad device ID
-Laptop names that use this Touchpad:HP Elitebook x360 1030 G2
Signed-off-by: Masaki Ota
---
drivers/hid/hid-alps.c | 3 +++
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 0a6c54f..e7ae3a7 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -771,6 +771,7 @@ static int alps_probe(struct hid_device *hdev, const struct
hid_device_id *id)
data->dev_type = T4;
break;
case HID_DEVICE_ID_ALPS_U1_DUAL:
+ case HID_DEVICE_ID_ALPS_U1:
data->dev_type = U1;
break;
default:
@@ -795,6 +796,8 @@ static const struct hid_device_id alps_id[] = {
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
+ USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) },
{ }
};
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9c3cb2e..779e26c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1775,6 +1775,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0b9726d..2b50d12 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -75,6 +75,7 @@
#define USB_VENDOR_ID_ALPS_JP 0x044E
#define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
+#define HID_DEVICE_ID_ALPS_U1 0x1215
#define HID_DEVICE_ID_ALPS_T4_BTNLESS 0x120C
#define USB_VENDOR_ID_AMI 0x046b
--
2.7.4
[PATCH 2/4] Support Alps HID I2C T4 Touchpad device
From: Masaki Ota
-Support Alps HID I2C T4 Touchpad device.
-Laptop names that use this Touchpad:HP Zbook Studio, Elitebook Folio G1,
Elitebook 1030 G1, Elitebook 1040 G3.
Signed-off-by: Masaki Ota
---
drivers/hid/hid-alps.c | 345 ++---
drivers/hid/hid-core.c | 3 +-
drivers/hid/hid-ids.h | 1 +
3 files changed, 327 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 984e452..0a6c54f 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -52,10 +52,32 @@
#define ADDRESS_U1_PAD_BTN 0x00800052
#define ADDRESS_U1_SP_BTN 0x0080009F
+#define T4_INPUT_REPORT_LENsizeof(struct t4_input_report)
+#define T4_FEATURE_REPORT_LEN T4_INPUT_REPORT_LEN
+#define T4_FEATURE_REPORT_ID 7
+#define T4_CMD_REGISTER_READ 0x08
+#define T4_CMD_REGISTER_WRITE 0x07
+
+#define T4_ADDRESS_BASE0xC2C0
+#define PRM_SYS_CONFIG_1 (T4_ADDRESS_BASE + 0x0002)
+#define T4_PRM_FEED_CONFIG_1 (T4_ADDRESS_BASE + 0x0004)
+#define T4_PRM_FEED_CONFIG_4 (T4_ADDRESS_BASE + 0x001A)
+#define T4_PRM_ID_CONFIG_3 (T4_ADDRESS_BASE + 0x00B0)
+
+
+#define T4_FEEDCFG4_ADVANCED_ABS_ENABLE0x01
+#define T4_I2C_ABS 0x78
+
+#define T4_COUNT_PER_ELECTRODE 256
#define MAX_TOUCHES5
+enum dev_num {
+ U1,
+ T4,
+ UNKNOWN,
+};
/**
- * struct u1_dev
+ * struct u1_data
*
* @input: pointer to the kernel input device
* @input2: pointer to the kernel input2 device
@@ -74,11 +96,12 @@
* @btn_cnt: number of buttons
* @sp_btn_cnt: number of stick buttons
*/
-struct u1_dev {
+struct alps_dev {
struct input_dev *input;
struct input_dev *input2;
struct hid_device *hdev;
+ enum dev_num dev_type;
u8 max_fingers;
u8 has_sp;
u8 sp_btn_info;
@@ -92,6 +115,145 @@ struct u1_dev {
u32 sp_btn_cnt;
};
+struct t4_contact_data {
+ u8 palm;
+ u8 x_lo;
+ u8 x_hi;
+ u8 y_lo;
+ u8 y_hi;
+};
+
+struct t4_input_report {
+ u8 reportID;
+ u8 numContacts;
+ struct t4_contact_data contact[5];
+ u8 button;
+ u8 track[5];
+ u8 zx[5], zy[5];
+ u8 palmTime[5];
+ u8 kilroy;
+ u16 timeStamp;
+};
+
+static u16 t4_calc_check_sum(u8 *buffer,
+ unsigned long offset, unsigned long length)
+{
+ u16 sum1 = 0xFF, sum2 = 0xFF;
+ unsigned long i = 0;
+
+ if (offset + length >= 50)
+ return 0;
+
+ while (length > 0) {
+ u32 tlen = length > 20 ? 20 : length;
+
+ length -= tlen;
+
+ do {
+ sum1 += buffer[offset + i];
+ sum2 += sum1;
+ i++;
+ } while (--tlen > 0);
+
+ sum1 = (sum1 & 0xFF) + (sum1 >> 8);
+ sum2 = (sum2 & 0xFF) + (sum2 >> 8);
+ }
+
+ sum1 = (sum1 & 0xFF) + (sum1 >> 8);
+ sum2 = (sum2 & 0xFF) + (sum2 >> 8);
+
+ return(sum2 << 8 | sum1);
+}
+
+static int t4_read_write_register(struct hid_device *hdev, u32 address,
+ u8 *read_val, u8 write_val, bool read_flag)
+{
+ int ret;
+ u16 check_sum;
+ u8 *input;
+ u8 *readbuf;
+
+ input = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
+ if (!input)
+ return -ENOMEM;
+
+ input[0] = T4_FEATURE_REPORT_ID;
+ if (read_flag) {
+ input[1] = T4_CMD_REGISTER_READ;
+ input[8] = 0x00;
+ } else {
+ input[1] = T4_CMD_REGISTER_WRITE;
+ input[8] = write_val;
+ }
+ put_unaligned_le32(address, input + 2);
+ input[6] = 1;
+ input[7] = 0;
+
+ /* Calculate the checksum */
+ check_sum = t4_calc_check_sum(input, 1, 8);
+ input[9] = (u8)check_sum;
+ input[10] = (u8)(check_sum >> 8);
+ input[11] = 0;
+
+ ret = hid_hw_raw_request(hdev, T4_FEATURE_REPORT_ID, input,
+ T4_FEATURE_REPORT_LEN,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+
+ if (ret < 0) {
+ dev_err(&hdev->dev, "failed to read command (%d)\n", ret);
+ goto exit;
+ }
+
+ if (read_flag) {
+ readbuf = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
+ if (!readbuf) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ ret = hid_hw_raw_request(hdev, T4_FEATURE_REPORT_ID, readbuf,
+ T4_FEATURE_REPORT_LEN,
+ HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
+ if (ret < 0) {
+ dev_err(&hdev->dev, "failed read register (%d)
[PATCH 0/4] Support new Alps HID I2C Touchpad device
Hi, Benjamin, I modified the patch and added the code that supports Alps USB Touchpad as PATCH 4/4. Best Regards, Masaki Ota
[PATCH 1/4] Replace Alps U1 Touchpad code
>From Masaki Ota
- Separate U1 device initialization from common initialization.
Signed-off-by: Masaki Ota
---
drivers/hid/hid-alps.c | 188 ++---
1 file changed, 99 insertions(+), 89 deletions(-)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index ed9c0ea..984e452 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -55,24 +55,22 @@
#define MAX_TOUCHES5
/**
- * struct u1_data
+ * struct u1_dev
*
* @input: pointer to the kernel input device
* @input2: pointer to the kernel input2 device
* @hdev: pointer to the struct hid_device
*
- * @dev_ctrl: device control parameter
* @dev_type: device type
- * @sen_line_num_x: number of sensor line of X
- * @sen_line_num_y: number of sensor line of Y
- * @pitch_x: sensor pitch of X
- * @pitch_y: sensor pitch of Y
- * @resolution: resolution
- * @btn_info: button information
+ * @max_fingers: total number of fingers
+ * @has_sp: boolean of sp existense
+ * @sp_btn_info: button information
* @x_active_len_mm: active area length of X (mm)
* @y_active_len_mm: active area length of Y (mm)
* @x_max: maximum x coordinate value
* @y_max: maximum y coordinate value
+ * @x_min: minimum x coordinate value
+ * @y_min: minimum y coordinate value
* @btn_cnt: number of buttons
* @sp_btn_cnt: number of stick buttons
*/
@@ -81,19 +79,15 @@ struct u1_dev {
struct input_dev *input2;
struct hid_device *hdev;
- u8 dev_ctrl;
- u8 dev_type;
- u8 sen_line_num_x;
- u8 sen_line_num_y;
- u8 pitch_x;
- u8 pitch_y;
- u8 resolution;
- u8 btn_info;
+ u8 max_fingers;
+ u8 has_sp;
u8 sp_btn_info;
u32 x_active_len_mm;
u32 y_active_len_mm;
u32 x_max;
u32 y_max;
+ u32 x_min;
+ u32 y_min;
u32 btn_cnt;
u32 sp_btn_cnt;
};
@@ -255,108 +249,149 @@ static int alps_post_resume(struct hid_device *hdev)
}
#endif /* CONFIG_PM */
-static int alps_input_configured(struct hid_device *hdev, struct hid_input *hi)
+static int u1_init(struct hid_device *hdev, struct u1_dev *pri_data)
{
- struct u1_dev *data = hid_get_drvdata(hdev);
- struct input_dev *input = hi->input, *input2;
- struct u1_dev devInfo;
int ret;
- int res_x, res_y, i;
-
- data->input = input;
-
- hid_dbg(hdev, "Opening low level driver\n");
- ret = hid_hw_open(hdev);
- if (ret)
- return ret;
-
- /* Allow incoming hid reports */
- hid_device_io_start(hdev);
+ u8 tmp, dev_ctrl, sen_line_num_x, sen_line_num_y;
+ u8 pitch_x, pitch_y, resolution;
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
- &devInfo.dev_ctrl, 0, true);
+ &dev_ctrl, 0, true);
if (ret < 0) {
dev_err(&hdev->dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
- devInfo.dev_ctrl &= ~U1_DISABLE_DEV;
- devInfo.dev_ctrl |= U1_TP_ABS_MODE;
+ dev_ctrl &= ~U1_DISABLE_DEV;
+ dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
- NULL, devInfo.dev_ctrl, false);
+ NULL, dev_ctrl, false);
if (ret < 0) {
dev_err(&hdev->dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
- &devInfo.sen_line_num_x, 0, true);
+ &sen_line_num_x, 0, true);
if (ret < 0) {
dev_err(&hdev->dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
- &devInfo.sen_line_num_y, 0, true);
+ &sen_line_num_y, 0, true);
if (ret < 0) {
dev_err(&hdev->dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
- &devInfo.pitch_x, 0, true);
+ &pitch_x, 0, true);
if (ret < 0) {
dev_err(&hdev->dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
- &devInfo.pitch_y, 0, true);
+ &pitch_y, 0, true);
if (ret < 0) {
dev_err(&hdev->dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
- &devInfo.resolution, 0, true);
+ &resolution, 0, true);
if (ret < 0) {
[PATCH 4/4] Add Alps T4 USB Touchpad device ID
From: Masaki Ota
-Support Alps T4 USB Touchpad device
-Laptop names that use this Touchpad:Elite x2 1012 G1 Tablet, HP Pro x2 612 G2
Signed-off-by: Masaki Ota
---
drivers/hid/hid-alps.c | 37 ++---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index e7ae3a7..d2d34c4 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -444,6 +444,7 @@ static int alps_raw_event(struct hid_device *hdev,
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
+ case HID_DEVICE_ID_ALPS_T4_USB:
ret = t4_raw_event(hdata, data, size);
break;
default:
@@ -598,13 +599,29 @@ static int T4_init(struct hid_device *hdev, struct
alps_dev *pri_data)
int ret;
u8 tmp, sen_line_num_x, sen_line_num_y;
- ret = t4_read_write_register(hdev, T4_PRM_ID_CONFIG_3, &tmp, 0, true);
- if (ret < 0) {
- dev_err(&hdev->dev, "failed T4_PRM_ID_CONFIG_3 (%d)\n", ret);
- goto exit;
+ if (hdev->product == HID_DEVICE_ID_ALPS_T4_BTNLESS) {
+ ret = t4_read_write_register(hdev,
+ T4_PRM_ID_CONFIG_3, &tmp, 0, true);
+ if (ret < 0) {
+ dev_err(&hdev->dev,
+ "failed T4_PRM_ID_CONFIG_3 (%d)\n", ret);
+ goto exit;
+ }
+ sen_line_num_x =
+ 16 + ((tmp & 0x0F) | (tmp & 0x08 ? 0xF0 : 0));
+ sen_line_num_y =
+ 12 + (((tmp & 0xF0) >> 4) | (tmp & 0x80 ? 0xF0 : 0));
+ ret = t4_read_write_register(hdev,
+ PRM_SYS_CONFIG_1, &tmp, 0, true);
+ if (ret < 0) {
+ dev_err(&hdev->dev,
+ "failed PRM_SYS_CONFIG_1 (%d)\n", ret);
+ goto exit;
+ }
+ } else {
+ sen_line_num_x = 20;
+ sen_line_num_y = 12;
}
- sen_line_num_x = 16 + ((tmp & 0x0F) | (tmp & 0x08 ? 0xF0 : 0));
- sen_line_num_y = 12 + (((tmp & 0xF0) >> 4) | (tmp & 0x80 ? 0xF0 : 0));
pri_data->x_max = sen_line_num_x * T4_COUNT_PER_ELECTRODE;
pri_data->x_min = T4_COUNT_PER_ELECTRODE;
@@ -613,11 +630,6 @@ static int T4_init(struct hid_device *hdev, struct
alps_dev *pri_data)
pri_data->x_active_len_mm = pri_data->y_active_len_mm = 0;
pri_data->btn_cnt = 1;
- ret = t4_read_write_register(hdev, PRM_SYS_CONFIG_1, &tmp, 0, true);
- if (ret < 0) {
- dev_err(&hdev->dev, "failed PRM_SYS_CONFIG_1 (%d)\n", ret);
- goto exit;
- }
tmp |= 0x02;
ret = t4_read_write_register(hdev, PRM_SYS_CONFIG_1, NULL, tmp, false);
if (ret < 0) {
@@ -768,6 +780,7 @@ static int alps_probe(struct hid_device *hdev, const struct
hid_device_id *id)
switch (hdev->product) {
case HID_DEVICE_ID_ALPS_T4_BTNLESS:
+ case HID_DEVICE_ID_ALPS_T4_USB:
data->dev_type = T4;
break;
case HID_DEVICE_ID_ALPS_U1_DUAL:
@@ -799,6 +812,8 @@ static const struct hid_device_id alps_id[] = {
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) },
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
+ USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_USB) },
{ }
};
MODULE_DEVICE_TABLE(hid, alps_id);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 779e26c..13ded46 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1777,6 +1777,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS)
},
+ { HID_USB_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICTRACKPAD) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2b50d12..71c2a02 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -76,6 +76,7 @@
#define USB_VENDOR_ID_ALPS_JP 0x044E
#define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
#define HID_DEVICE_ID_ALPS_U1 0x1215
+#define HID_DEVICE_ID_ALPS_T4_USB 0x1216
#define HID_DEVICE_ID_ALPS_T4_BTNLESS 0x120C
#define USB_VENDOR_ID_AMI 0x046b
--
2.7.4
Re: [RFC PATCHv2 0/3] dma_buf import support for vgem
On Wed, Apr 26, 2017 at 02:12:27PM -0700, Laura Abbott wrote: > Hi, > > This is v2 of my proposal to add dma_buf import functions for vgem. > Big changes from v1: > > - A device is required for dma_buf attach to work. The existing vgem driver > intentionally does not use one as it provides a good way to test the DRM > framework. This approach instead puts a dummy platform device in the existing > drm_device->platformdev field and uses that for attaching. > - Native vgem buffers can still be faulted in a page at a time without > requiring the entire buffer be resident in memory. > > I'm still marking this as RFC as I haven't had a chance to finish > a userspace test that can be integrated into igt. Note, that it will be good to cc:intel-gfx@ so that our CI does run it over the existing vgem tests. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v2] x86/KASLR: Use old ident map page table if physical randomization failed
Dave found kdump kernel with kaslr enabled will reset to bios immediately if physical randomization failed to find a new position for kernel. But kernel with 'nokaslr' option works in this case. The reason is kaslr will install a new page table for ident mapping, while it missed to consider building ident mapping for original area of kernel if kaslr failed on physical randomization. This only happens in kexec/kdump kernel. Since ident mapping has been built for kexec/kdump in 1st kernel for the whole memory by calling init_pgtable(). Here if physical randomizaiton failed, it won't build ident mapping for the original area of kernel but change to new page table '_pgtable'. Then kernel will reset to bios immediately caused by no ident mapping. While normal kernel won't be impacted because it comes here via startup_32() and cr3 will be _pgtable already. In startup_32() ident mapping is built for 0~4G area. In kaslr We just append to the existing area instead of entirely overwriting it for on-demand ident mapping building. So ident mapping for the original area of kernel is still there. So for fixing it, We just switch to the new ident mapping page table when physical kaslr succeeds. Otherwise we keep the old page table unchanged just like nokaslr does. Signed-off-by: Baoquan He Signed-off-by: Dave Young Acked-by: Kees Cook Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org Cc: Kees Cook Cc: Yinghai Lu Cc: Borislav Petkov Cc: Dave Jiang Cc: Thomas Garnier --- v1->v2: No code change, just improve patch log to make it clearer. arch/x86/boot/compressed/kaslr.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c index e5eb0c3..7a8b443 100644 --- a/arch/x86/boot/compressed/kaslr.c +++ b/arch/x86/boot/compressed/kaslr.c @@ -650,10 +650,16 @@ void choose_random_location(unsigned long input, add_identity_map(random_addr, output_size); *output = random_addr; } + + /* +* This actually loads the identity pagetable on x86_64. +* And this should only be done only if a new position +* is found. Otherwise we should keep the old page table +* to make it be like nokaslr case. +*/ + finalize_identity_maps(); } - /* This actually loads the identity pagetable on x86_64. */ - finalize_identity_maps(); /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */ if (IS_ENABLED(CONFIG_X86_64)) -- 2.5.5
Re: [PATCH 2/2] dax: fix data corruption due to stale mmap reads
On Wed 26-04-17 16:52:36, Ross Zwisler wrote: > On Wed, Apr 26, 2017 at 10:52:35AM +0200, Jan Kara wrote: > > On Tue 25-04-17 16:59:36, Ross Zwisler wrote: > > > On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote: > > > <> > > > > Hum, but now thinking more about it I have hard time figuring out why > > > > write > > > > vs fault cannot actually still race: > > > > > > > > CPU1 - write(2) CPU2 - read fault > > > > > > > > dax_iomap_pte_fault() > > > > ->iomap_begin() - sees hole > > > > dax_iomap_rw() > > > > iomap_apply() > > > > ->iomap_begin - allocates blocks > > > > dax_iomap_actor() > > > > invalidate_inode_pages2_range() > > > > - there's nothing to invalidate > > > > grab_mapping_entry() > > > > - we add zero page in the > > > > radix > > > > tree & map it to page tables > > > > > > > > Similarly read vs write fault may end up racing in a wrong way and try > > > > to > > > > replace already existing exceptional entry with a hole page? > > > > > > Yep, this race seems real to me, too. This seems very much like the > > > issues > > > that exist when a thread is doing direct I/O. One thread is doing I/O to > > > an > > > intermediate buffer (page cache for direct I/O case, zero page for us), > > > and > > > the other is going around it directly to media, and they can get out of > > > sync. > > > > > > IIRC the direct I/O code looked something like: > > > > > > 1/ invalidate existing mappings > > > 2/ do direct I/O to media > > > 3/ invalidate mappings again, just in case. Should be cheap if there > > > weren't > > >any conflicting faults. This makes sure any new allocations we made > > > are > > >faulted in. > > > > Yeah, the problem is people generally expect weird behavior when they mix > > direct and buffered IO (or let alone mmap) however everyone expects > > standard read(2) and write(2) to be completely coherent with mmap(2). > > Yep, fair enough. > > > > I guess one option would be to replicate that logic in the DAX I/O path, > > > or we > > > could try and enhance our locking so page faults can't race with I/O since > > > both can allocate blocks. > > > > In the abstract way, the problem is that we have radix tree (and page > > tables) cache block mapping information and the operation: "read block > > mapping information, store it in the radix tree" is not serialized in any > > way against other block allocations so the information we store can be out > > of date by the time we store it. > > > > One way to solve this would be to move ->iomap_begin call in the fault > > paths under entry lock although that would mean I have to redo how ext4 > > handles DAX faults because with current code it would create lock inversion > > wrt transaction start. > > I don't think this alone is enough to save us. The I/O path doesn't currently > take any DAX radix tree entry locks, so our race would just become: > > CPU1 - write(2) CPU2 - read fault > > dax_iomap_pte_fault() > grab_mapping_entry() // newly moved > ->iomap_begin() - sees hole > dax_iomap_rw() > iomap_apply() > ->iomap_begin - allocates blocks > dax_iomap_actor() > invalidate_inode_pages2_range() > - there's nothing to invalidate > - we add zero page in the radix > tree & map it to page tables > > In their current form I don't think we want to take DAX radix tree entry locks > in the I/O path because that would effectively serialize I/O over a given > radix tree entry. For a 2MiB entry, for example, all I/O to that 2MiB range > would be serialized. Note that invalidate_inode_pages2_range() will see the entry created by grab_mapping_entry() on CPU2 and block waiting for its lock and this is exactly what stops the race. The invalidate_inode_pages2_range() effectively makes sure there isn't any page fault in progress for given range... Also note that writes to a file are serialized by i_rwsem anyway (and at least serialization of writes to the overlapping range is required by POSIX) so this doesn't add any more serialization than we already have. > > Another solution would be to grab i_mmap_sem for write when doing write > > fault of a page and similarly have it grabbed for writing when doing > > write(2). This would scale rather poorly but if we later replaced it with a > > range lock (Davidlohr has already posted a nice implementation of it) it > > won't be as bad. But I guess option 1) is better... > > The best idea I had for handling this sounds similar, which would be to > convert the radix tree
Re: [PATCH v4 2/4] zram: implement deduplication in zram
Hello, On (04/27/17 15:57), Joonsoo Kim wrote: [..] > I tested with your benchmark and found that contention happens > since the data page is perfectly the same. All the written data (2GB) > is de-duplicated. yes, a statically filled buffer to guarantee that compression/decompression numbers/impact will be stable. otherwise the test results are "apples vs oranges" :) > I tried to optimize it with read-write lock but I failed since > there is another contention, which cannot be fixed simply. That is > zsmalloc. We need to map the object and compare the content of the > compressed page to check de-duplication. Zsmalloc pins the object > by using bit spinlock when mapping. So, parallel readers to the same > object contend here. > > I think that this case is so artificial and, in practice, there > would be no case that the same data page is repeatedly and parallel > written as like this. So, I'd like to keep current code. How do you > think about it, Sergey? I agree. thanks for taking a look! I see no blockers for the patch set. ok, in general, seems that (correct me if I'm wrong) a) the higher the dedup ratio the slower zram _can_ perform. because dedup can create parallel access scenarios where they previously never existed: different offset writes now can compete for the same dedupped zsmalloc object. and... tricky and probably over exaggerated b) the lower the dedup ratio the slower zram _can_ perform. think of almost full zram device with dedup ratio of just 3-5%. tree lookups are serialized by the hash->lock. a balanced tree gives us slow lookup complexity growth, it's still there but can leave with it. at the same time low dedup ratio means that we have wasted CPU cycles on checksum calculation (potentially for millions of pages if zram device in question is X gigabytes in size), this can't go unnoticed. it's just I was slightly confused by the performance numbers that you have observed. some tests were : It shows performance degradation roughly 13% and save 24% memory. Maybe, : it is due to overhead of calculating checksum and comparison. while others were : There is no performance degradation and save 23% memory. I understand that you didn't perform direct io, flush, fsync, etc. and there is a whole bunch of factors that could have affected your tests, e.g. write back, etc. etc. but the numbers are still very unstable. may be now we will have a bit better understanding :) > Just note, if we do parallel read (direct-io) to the same offset, > zsmalloc contention would happen regardless deduplication feature. > It seems that it's fundamental issue in zsmalloc. that's a good find. -ss
Re: [PATCH v4 0/4] zram: implement deduplication in zram
On (04/26/17 09:52), js1...@gmail.com wrote: > From: Joonsoo Kim > > Changes from v3 > o fix module build problem > o make zram_dedup_enabled() statically return false if CONFIG_ZRAM_DEDUP=n the entire patch set Reviewed-by: Sergey Senozhatsky -ss
Re: [PATCH -v3 0/13] mm: make movable onlining suck less
Hi all, Andrew prefers to take this after the merge window so I will repost the full series then. Any feedback is still highly appreciated of course. -- Michal Hocko SUSE Labs
Re: [PATCH 07/13] mm: consider zone which is not fully populated to have holes
I plan to fold the following into this patch. --- >From 2cdb8e398eaeddf8b743bddb421dc5d9e49e442d Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 27 Apr 2017 09:53:01 +0200 Subject: [PATCH] fold me "mm: consider zone which is not fully populated to have holes" - clarify pfn_valid semantic - requested by Joonsoo --- include/linux/mmzone.h | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index aa8cc03287b0..f8c9453635e5 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -1268,10 +1268,15 @@ unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long); #ifdef CONFIG_ARCH_HAS_HOLES_MEMORYMODEL /* * pfn_valid() is meant to be able to tell if a given PFN has valid memmap - * associated with it or not. In FLATMEM, it is expected that holes always - * have valid memmap as long as there is valid PFNs either side of the hole. - * In SPARSEMEM, it is assumed that a valid section has a memmap for the - * entire section. + * associated with it or not. This means that a struct page exists for this + * pfn. The caller cannot assume the page is fully initialized in general. + * Hotplugable pages might not have been onlined yet. pfn_to_online_page() + * will ensure the struct page is fully online and initialized. Special pages + * (e.g. ZONE_DEVICE) are never onlined and should be treated accordingly. + * + * In FLATMEM, it is expected that holes always have valid memmap as long as + * there is valid PFNs either side of the hole. In SPARSEMEM, it is assumed + * that a valid section has a memmap for the entire section. * * However, an ARM, and maybe other embedded architectures in the future * free memmap backing holes to save memory on the assumption the memmap is -- 2.11.0 -- Michal Hocko SUSE Labs
Re: [PATCH 08/13] mm, compaction: skip over holes in __reset_isolation_suitable
On Fri 21-04-17 14:05:11, Michal Hocko wrote: > From: Michal Hocko > > __reset_isolation_suitable walks the whole zone pfn range and it tries > to jump over holes by checking the zone for each page. It might still > stumble over offline pages, though. Skip those by checking PageReserved. ups, forgot to update the changelog here. s@PageReserved@pfn_to_online_page()@ > Signed-off-by: Michal Hocko > --- > mm/compaction.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 613c59e928cb..fb548e4c7bd4 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -236,10 +236,9 @@ static void __reset_isolation_suitable(struct zone *zone) > > cond_resched(); > > - if (!pfn_valid(pfn)) > + page = pfn_to_online_page(pfn); > + if (!page) > continue; > - > - page = pfn_to_page(pfn); > if (zone != page_zone(page)) > continue; > > -- > 2.11.0 > -- Michal Hocko SUSE Labs
Re: [PATCH v6 2/5] firmware: add extensible driver data API
On Thu, Apr 27, 2017 at 08:44:27AM +0300, Luca Coelho wrote:
> On Thu, 2017-04-27 at 05:16 +0200, Luis R. Rodriguez wrote:
> > > > @@ -1460,6 +1471,128 @@ void release_firmware(const struct firmware *fw)
> > > > }
> > > > EXPORT_SYMBOL(release_firmware);
> > > >
> > > > +static int _driver_data_request_api(struct driver_data_params *params,
> > > > + struct device *device,
> > > > + const char *name)
> > > > +{
> > > > + struct driver_data_priv_params *priv_params = ¶ms->priv_params;
> > > > + const struct driver_data_req_params *req_params =
> > > > ¶ms->req_params;
> > > > + int ret;
> > > > + char *try_name;
> > > > + u8 api_max;
> > > > +
> > > > + if (priv_params->retry_api) {
> > > > + if (!priv_params->api)
> > > > + return -ENOENT;
> > > > + api_max = priv_params->api - 1;
> > > > + } else
> > > > + api_max = req_params->api_max;
> > >
> > > Braces.
> >
> > Not sure what you mean here, the else is a 1 liner so I skip the brace.
>
> It's really a nitpick, but the CodingStyle[1] says:
>
> "Do not unnecessarily use braces where a single statement will do.
> [...]
> This does not apply if only one branch of a conditional statement is a
> single statement; in the latter case use braces in both branches:
>
> if (condition) {
> do_this();
> do_that();
> } else {
> otherwise();
> }"
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n175
Heh, alright. Added the brace.
Luis
Re: [PATCH v2] clk: sunxi-ng: Fix dependency on SUNXI_CCU_GATE
On Thu, Apr 27, 2017 at 09:04:36AM +0200, Maxime Ripard wrote:
> On Wed, Apr 26, 2017 at 01:53:19PM +0200, Corentin Labbe wrote:
> > When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got
> > the following build error:
> > drivers/built-in.o: In function `ccu_pll_notifier_cb':
> > drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to
> > `ccu_gate_helper_disable'
> > drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference to
> > `ccu_gate_helper_enable'
> >
> > The problem is the function ccu_pll_notifier_cb in ccu_common.c need
> > some function from ccu_gate.c which is not compiled since SUNXI_CCU_GATE
> > is not selected.
> >
> > This patch remove SUNXI_CCU_GATE and compile ccu_gate.c unconditionnaly
> > since all other combination of options select SUNXI_CCU_GATE finally.
> >
> > Fixes: 02ae2bc6febd ("clk: sunxi-ng: Add clk notifier to gate then ungate
> > PLL clocks")
> > Signed-off-by: Corentin Labbe
>
> I think Chen-Yu had some comments that you didn't address.
>
I have changed subject as requested
[PATCH v5 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section
As Eric said,
"what we need to do is move the variable vmcoreinfo_note out
of the kernel's .bss section. And modify the code to regenerate
and keep this information in something like the control page.
Definitely something like this needs a page all to itself, and ideally
far away from any other kernel data structures. I clearly was not
watching closely the data someone decided to keep this silly thing
in the kernel's .bss section."
This patch allocates extra pages for these vmcoreinfo_XXX variables,
one advantage is that it enhances some safety of vmcoreinfo, because
vmcoreinfo now is kept far away from other kernel data structures.
Cc: Juergen Gross
Suggested-by: Eric Biederman
Tested-by: Michael Holzheu
Reviewed-by: Juergen Gross
Signed-off-by: Xunlei Pang
---
v4->v5:
Changed VMCOREINFO_BYTES definition to PAGE_SIZE according to Dave's comment
v3->v4:
-Rebased on the latest linux-next
-Handle S390 vmcoreinfo_note properly
-Handle the newly-added xen/mmu_pv.c
arch/ia64/kernel/machine_kexec.c | 5 -
arch/s390/kernel/machine_kexec.c | 1 +
arch/s390/kernel/setup.c | 6 --
arch/x86/kernel/crash.c | 2 +-
arch/x86/xen/mmu_pv.c| 4 ++--
include/linux/crash_core.h | 4 ++--
kernel/crash_core.c | 26 ++
kernel/ksysfs.c | 2 +-
8 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index 599507b..c14815d 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,8 +163,3 @@ void arch_crash_save_vmcoreinfo(void)
#endif
}
-phys_addr_t paddr_vmcoreinfo_note(void)
-{
- return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
-}
-
diff --git a/arch/s390/kernel/machine_kexec.c b/arch/s390/kernel/machine_kexec.c
index 49a6bd4..3d0b14a 100644
--- a/arch/s390/kernel/machine_kexec.c
+++ b/arch/s390/kernel/machine_kexec.c
@@ -246,6 +246,7 @@ void arch_crash_save_vmcoreinfo(void)
VMCOREINFO_SYMBOL(lowcore_ptr);
VMCOREINFO_SYMBOL(high_memory);
VMCOREINFO_LENGTH(lowcore_ptr, NR_CPUS);
+ mem_assign_absolute(S390_lowcore.vmcore_info, paddr_vmcoreinfo_note());
}
void machine_shutdown(void)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 3ae756c..3d1d808 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -496,11 +496,6 @@ static void __init setup_memory_end(void)
pr_notice("The maximum memory size is %luMB\n", memory_end >> 20);
}
-static void __init setup_vmcoreinfo(void)
-{
- mem_assign_absolute(S390_lowcore.vmcore_info, paddr_vmcoreinfo_note());
-}
-
#ifdef CONFIG_CRASH_DUMP
/*
@@ -939,7 +934,6 @@ void __init setup_arch(char **cmdline_p)
#endif
setup_resources();
- setup_vmcoreinfo();
setup_lowcore();
smp_fill_possible_mask();
cpu_detect_mhz_feature();
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 22217ec..44404e2 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -457,7 +457,7 @@ static int prepare_elf64_headers(struct crash_elf_data *ced,
bufp += sizeof(Elf64_Phdr);
phdr->p_type = PT_NOTE;
phdr->p_offset = phdr->p_paddr = paddr_vmcoreinfo_note();
- phdr->p_filesz = phdr->p_memsz = sizeof(vmcoreinfo_note);
+ phdr->p_filesz = phdr->p_memsz = VMCOREINFO_NOTE_SIZE;
(ehdr->e_phnum)++;
#ifdef CONFIG_X86_64
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 9d9ae66..35543fa 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2723,8 +2723,8 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
phys_addr_t paddr_vmcoreinfo_note(void)
{
if (xen_pv_domain())
- return virt_to_machine(&vmcoreinfo_note).maddr;
+ return virt_to_machine(vmcoreinfo_note).maddr;
else
- return __pa_symbol(&vmcoreinfo_note);
+ return __pa(vmcoreinfo_note);
}
#endif /* CONFIG_KEXEC_CORE */
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index eb71a70..ec9d415 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -14,7 +14,7 @@
CRASH_CORE_NOTE_NAME_BYTES + \
CRASH_CORE_NOTE_DESC_BYTES)
-#define VMCOREINFO_BYTES (4096)
+#define VMCOREINFO_BYTES PAGE_SIZE
#define VMCOREINFO_NOTE_NAME "VMCOREINFO"
#define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
#define VMCOREINFO_NOTE_SIZE ((CRASH_CORE_NOTE_HEAD_BYTES * 2) + \
@@ -53,7 +53,7 @@
#define VMCOREINFO_PHYS_BASE(value) \
vmcoreinfo_append_str("PHYS_BASE=%lx\n", (unsigned long)value)
-extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
+extern u32 *vmcoreinfo_note;
extern size_t vmcoreinfo_size;
extern size_t vmcoreinfo_max_size;
diff --git a
[PATCH v5 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr
vmcoreinfo_max_size stands for the vmcoreinfo_data, the
correct one we should use is vmcoreinfo_note whose total
size is VMCOREINFO_NOTE_SIZE.
Like explained in commit 77019967f06b ("kdump: fix exported
size of vmcoreinfo note"), it should not affect the actual
function, but we better fix it, also this change should be
safe and backward compatible.
After this, we can get rid of variable vmcoreinfo_max_size,
let's use the corresponding macros directly, fewer variables
means more safety for vmcoreinfo operation.
Cc: Hari Bathini
Reviewed-by: Mahesh Salgaonkar
Reviewed-by: Dave Young
Signed-off-by: Xunlei Pang
---
v4->v5:
No change.
v3->v4:
-Rebased on the latest linux-next
arch/powerpc/kernel/fadump.c | 3 +--
include/linux/crash_core.h | 1 -
kernel/crash_core.c | 3 +--
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 466569e..7bd6cd0 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -893,8 +893,7 @@ static int fadump_create_elfcore_headers(char *bufp)
phdr->p_paddr = fadump_relocate(paddr_vmcoreinfo_note());
phdr->p_offset = phdr->p_paddr;
- phdr->p_memsz = vmcoreinfo_max_size;
- phdr->p_filesz = vmcoreinfo_max_size;
+ phdr->p_memsz = phdr->p_filesz = VMCOREINFO_NOTE_SIZE;
/* Increment number of program headers. */
(elf->e_phnum)++;
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index ec9d415..4555c09 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -55,7 +55,6 @@
extern u32 *vmcoreinfo_note;
extern size_t vmcoreinfo_size;
-extern size_t vmcoreinfo_max_size;
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 2837d61..c2fd0d2 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -16,7 +16,6 @@
/* vmcoreinfo stuff */
static unsigned char *vmcoreinfo_data;
size_t vmcoreinfo_size;
-size_t vmcoreinfo_max_size = VMCOREINFO_BYTES;
u32 *vmcoreinfo_note;
/*
@@ -343,7 +342,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
r = vscnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
- r = min(r, vmcoreinfo_max_size - vmcoreinfo_size);
+ r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
--
1.8.3.1
[PATCH v5 3/3] kdump: Protect vmcoreinfo data under the crash memory
Currently vmcoreinfo data is updated at boot time subsys_initcall(),
it has the risk of being modified by some wrong code during system
is running.
As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
when using "crash", "makedumpfile", etc utility to parse this vmcore,
we probably will get "Segmentation fault" or other unexpected errors.
E.g. 1) wrong code overwrites vmcoreinfo_data; 2) further crashes the
system; 3) trigger kdump, then we obviously will fail to recognize the
crash context correctly due to the corrupted vmcoreinfo.
Now except for vmcoreinfo, all the crash data is well protected(including
the cpu note which is fully updated in the crash path, thus its correctness
is guaranteed). Given that vmcoreinfo data is a large chunk prepared for
kdump, we better protect it as well.
To solve this, we relocate and copy vmcoreinfo_data to the crash memory
when kdump is loading via kexec syscalls. Because the whole crash memory
will be protected by existing arch_kexec_protect_crashkres() mechanism,
we naturally protect vmcoreinfo_data from write(even read) access under
kernel direct mapping after kdump is loaded.
Since kdump is usually loaded at the very early stage after boot, we can
trust the correctness of the vmcoreinfo data copied.
On the other hand, we still need to operate the vmcoreinfo safe copy when
crash happens to generate vmcoreinfo_note again, we rely on vmap() to map
out a new kernel virtual address and update to use this new one instead in
the following crash_save_vmcoreinfo().
BTW, we do not touch vmcoreinfo_note, because it will be fully updated
using the protected vmcoreinfo_data after crash which is surely correct
just like the cpu crash note.
Tested-by: Michael Holzheu
Signed-off-by: Xunlei Pang
---
v4->v5:
- Moved vunmap(image->vmcoreinfo_data_copy) above to avoid confusion.
- No functional change.
v3->v4:
-Rebased on the latest linux-next
-Copy vmcoreinfo after machine_kexec_prepare()
include/linux/crash_core.h | 2 +-
include/linux/kexec.h | 2 ++
kernel/crash_core.c| 17 -
kernel/kexec.c | 8
kernel/kexec_core.c| 39 +++
kernel/kexec_file.c| 8
6 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 4555c09..e9de6b4 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -23,6 +23,7 @@
typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
+void crash_update_vmcoreinfo_safecopy(void *ptr);
void crash_save_vmcoreinfo(void);
void arch_crash_save_vmcoreinfo(void);
__printf(1, 2)
@@ -54,7 +55,6 @@
vmcoreinfo_append_str("PHYS_BASE=%lx\n", (unsigned long)value)
extern u32 *vmcoreinfo_note;
-extern size_t vmcoreinfo_size;
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index c9481eb..3ea8275 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -181,6 +181,7 @@ struct kimage {
unsigned long start;
struct page *control_code_page;
struct page *swap_page;
+ void *vmcoreinfo_data_copy; /* locates in the crash memory */
unsigned long nr_segments;
struct kexec_segment segment[KEXEC_SEGMENT_MAX];
@@ -250,6 +251,7 @@ extern void *kexec_purgatory_get_symbol_addr(struct kimage
*image,
int kexec_should_crash(struct task_struct *);
int kexec_crash_loaded(void);
void crash_save_cpu(struct pt_regs *regs, int cpu);
+extern int kimage_crash_copy_vmcoreinfo(struct kimage *image);
extern struct kimage *kexec_image;
extern struct kimage *kexec_crash_image;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index c2fd0d2..4a4a4ba 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -15,9 +15,12 @@
/* vmcoreinfo stuff */
static unsigned char *vmcoreinfo_data;
-size_t vmcoreinfo_size;
+static size_t vmcoreinfo_size;
u32 *vmcoreinfo_note;
+/* trusted vmcoreinfo, e.g. we can make a copy in the crash memory */
+static unsigned char *vmcoreinfo_data_safecopy;
+
/*
* parsing the "crashkernel" commandline
*
@@ -323,11 +326,23 @@ static void update_vmcoreinfo_note(void)
final_note(buf);
}
+void crash_update_vmcoreinfo_safecopy(void *ptr)
+{
+ if (ptr)
+ memcpy(ptr, vmcoreinfo_data, vmcoreinfo_size);
+
+ vmcoreinfo_data_safecopy = ptr;
+}
+
void crash_save_vmcoreinfo(void)
{
if (!vmcoreinfo_note)
return;
+ /* Use the safe copy to generate vmcoreinfo note if have */
+ if (vmcoreinfo_data_safecopy)
+ vmcoreinfo_data = vmcoreinfo_data_safecopy;
+
vmcoreinfo_append_str("CRASHTIME=%ld\n", get_seconds());
update_vmcoreinfo_note();
}
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a..e62ec4d 100644
--- a/kernel/kexec.c
+++ b/kernel/k
Re: [PATCH] perf/x86/intel/pt: Allow disabling branch tracing
On 06/02/17 19:19, Andi Kleen wrote: > On Mon, Feb 06, 2017 at 06:05:29PM +0200, Alexander Shishkin wrote: >> Andi Kleen writes: >> >>> Alexander Shishkin writes: >>> Now that Intel PT supports more types of trace content than just branch tracing, it may be useful to allow the user to disable branch tracing when it is not needed. The special case is BDW, where not setting BranchEn is not supported. This is slightly trickier than necessary, because up to this moment the driver has been setting BranchEn automatically and the userspace assumes as much. Instead of reversing the semantics of BranchEn, we introduce a 'passthrough' bit, which will forego the default and allow the user to set BranchEn to their heart's content. >>> >>> cpu/passthrough=1,branchen=1/ seems far uglier/more complicanted to me >>> than the original cpu/nobranch=1/ >> >> It's /passthrough=1,branch=0/ or simply /passthrough=1/. > > Ok, but still you have to list exactly to which flags passthrough > applies to, and it will only ever be branchen. It doesn't have to be that bad. For Intel PT, perf tools already provides default config which the user must override. So, when 'passthrough' is supported, the default config would include 'passthrough=1,branch=1'. So then the user would only have to put 'branch=0' when they want no branches.
Re: [PATCH] drivers: input: joystick: Add PSX (Play Station 1/2) pad with SPI driver.
Hi,
Thank you for making the changes. I have some more comments though.
On Tue, Apr 25, 2017 at 11:44:22PM +0900, AZO wrote:
> PSX pads can be connected directry SPI bus.
>
> Signed-off-by: AZO
Please use your real name on the signoffs (apologies in advance in case
it is your proper name).
> ---
> drivers/input/joystick/Kconfig | 16 +
> drivers/input/joystick/Makefile | 1 +
> drivers/input/joystick/psxpad-spi.c | 671
>
> 3 files changed, 688 insertions(+)
> create mode 100644 drivers/input/joystick/psxpad-spi.c
>
> diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
> index 4215b538..f49645f7 100644
> --- a/drivers/input/joystick/Kconfig
> +++ b/drivers/input/joystick/Kconfig
> @@ -330,4 +330,20 @@ config JOYSTICK_MAPLE
> To compile this as a module choose M here: the module will be called
> maplecontrol.
>
> +config JOYSTICK_PSXPAD_SPI
> + tristate "PSX (Play Station 1/2) pad with SPI Bus Driver"
> + depends on INPUT_POLLDEV && SPI
INPUT_POLLDEV is meant to be "selected", so:
depends on SPI
select INPUT_POLLDEV
> + help
> + Say Y here if you connect PSX (PS1/2) pad with SPI Interface.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called psxpad-spi.
> +
> +config JOYSTICK_PSXPAD_SPI_FF
> + bool "PSX pad with SPI Bus rumble support"
> + depends on JOYSTICK_PSXPAD_SPI && INPUT
No need to depend on INPUT, everything here is already depending on it.
> + select INPUT_FF_MEMLESS
> + help
> + Say Y here if you want to take advantage of PSX pad rumble features.
> +
> endif
> diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
> index 92dc0de9..496fd56b 100644
> --- a/drivers/input/joystick/Makefile
> +++ b/drivers/input/joystick/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_JOYSTICK_INTERACT) += interact.o
> obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
> obj-$(CONFIG_JOYSTICK_MAGELLAN) += magellan.o
> obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
> +obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)+= psxpad-spi.o
> obj-$(CONFIG_JOYSTICK_SIDEWINDER)+= sidewinder.o
> obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
> obj-$(CONFIG_JOYSTICK_SPACEORB) += spaceorb.o
> diff --git a/drivers/input/joystick/psxpad-spi.c
> b/drivers/input/joystick/psxpad-spi.c
> new file mode 100644
> index ..3d2bee6d
> --- /dev/null
> +++ b/drivers/input/joystick/psxpad-spi.c
> @@ -0,0 +1,671 @@
> +/*
> + * PSX (Play Station 1/2) pad (SPI Interface)
> + *
> + * Copyright (C) 2017 AZO
> + * Licensed under the GPL-2 or later.
> + *
> + * PSX pad plug (not socket)
> + * 123 456 789
> + * (...|...|...)
> + *
> + * 1: DAT -> MISO (pullup with 1k owm to 3.3V)
> + * 2: CMD -> MOSI
> + * 3: 9V (for motor, if not use N.C.)
> + * 4: GND
> + * 5: 3.3V
> + * 6: Attention -> CS(SS)
> + * 7: SCK -> SCK
> + * 8: N.C.
> + * 9: ACK -> N.C.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +//#define PSXPAD_ENABLE_ANALOG2
Why support for the "analog 2" packets is optional?
> +#ifdef CONFIG_JOYSTICK_PSXPAD_SPI_FF
> +#define PSXPAD_ENABLE_FF
> +#endif /* CONFIG_JOYSTICK_PSXPAD_SPI_FF */
Why do we need this indirection?
> +
> +enum {
> + PSXPAD_SPI_SPEED_125KHZ = 0,
> + PSXPAD_SPI_SPEED_250KHZ,
> + PSXPAD_SPI_SPEED_500KHZ,
> + PSXPAD_SPI_SPEED_UNKNOWN
> +};
I do not believe this definitions are needed. Just set speed explicitly
at spi_setup() time and be done.
> +
> +#define PSXPAD_DEFAULT_SPI_DELAY 100
> +#define PSXPAD_DEFAULT_SPI_SPEED PSXPAD_SPI_SPEED_125KHZ
> +#define PSXPAD_DEFAULT_INTERVAL 16
> +#define PSXPAD_DEFAULT_INTERVAL_MIN 8
> +#define PSXPAD_DEFAULT_INTERVAL_MAX 32
> +#define PSXPAD_DEFAULT_ADMODEtrue
Not used.
> +#define PSXPAD_DEFAULT_INPUT_PHYSIZE 32
> +
> +#define REVERSE_BIT(x) x) & 0x80) >> 7) | (((x) & 0x40) >> 5) | (((x) &
> 0x20) >> 3) | (((x) & 0x10) >> 1) | (((x) & 0x08) << 1) | (((x) & 0x04) << 3)
> | (((x) & 0x02) << 5) | (((x) & 0x01) << 7))
> +
> +enum {
> + PSXPAD_KEYSTATE_TYPE_DIGITAL = 0,
> + PSXPAD_KEYSTATE_TYPE_ANALOG1,
> + PSXPAD_KEYSTATE_TYPE_ANALOG2,
> + PSXPAD_KEYSTATE_TYPE_UNKNOWN
> +};
> +
> +static const u8 PSX_CMD_INIT_PRESSURE[] = {0x01, 0x40, 0x00, 0x00,
> 0x02, 0x00, 0x00, 0x00, 0x00};
> +static const u8 PSX_CMD_ALL_PRESSURE[] = {0x01, 0x4F, 0x00, 0xFF,
> 0xFF, 0x03, 0x00, 0x00, 0x00};
> +static const u8 PSX_CMD_POLL[] = {0x01, 0x42, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00};
> +static const u8 PSX_CMD_ENTER_CFG[] = {0x01, 0x43, 0x00, 0x01, 0x00, 0x00,
> 0x00, 0x00, 0x00};
> +static const u8 PSX_CMD_EXIT_CFG[] = {0x01, 0x43, 0x00,
[PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
Hi Geert, this is 5th round of gpio/pincontroller for RZ/A1 devices. I have updated the pin controller driver to use the newly introduced "pinctrl_enable()" function. This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt, the pin controller does not start. I have incorporated your comments on the device tree bindings documentation, and added to pinctrl-generic.h header file two macros to unpack generic properties and their arguments. Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board. Thanks j v1 -> v2: - change pin configuration flags as suggested by Chris - gpio set direction function fixed as suggested by Chris - add some more example on pin configuration flag usage to dt-binding doc - fix gpio-controller names to remove unit address as suggested by Geert - some comments chopped here and there to make the driver less verbose v2 -> v3: - fix grammar and syntax in comment and documentation - fix code style (reverse xmas tree ordering in variable declaration) - use irqsave/irqrestore in spinlock lock/unlock - use devm_ version of kasprintf (memory returned was not properly free) - use bitops.h operation ffs and fls to make sure a single bit is set in pmx mask - Add Geert's reviewed-by to DTS patches v3 -> v4: - use "pinmux" property in pmx sub-nodes in place of "renesas,pins" - use pinconf standard properties to set pin mux additional flags - add "bi-directional" and "output-enable" to pinconf generic properties - perform pmx function parsing at dt_node_to_map() time - change DT bindings to use GENERIC_PINCONF - change DT bindings to allow sub-nodes to have "pinmux" property specified - several renames (register names, DT parse functions, set_mux() function) v4 -> v5: - use pinctrl_enable() function in pin controller registration function - update bindings documentation to incorporate Geert's comments - add generic properties unpack macros Jacopo Mondi (10): pinctrl: generic: Add bi-directional and output-enable pinctrl: generic: Add macros to unpack properties pinctrl: Renesas RZ/A1 pin and gpio controller dt-bindings: pinctrl: Add RZ/A1 bindings doc arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header arm: dts: r7s72100: Add pin controller node arm: dts: genmai: Add SCIF2 pin group arm: dts: genmai: Add RIIC2 pin group arm: dts: genmai: Add user led device nodes arm: dts: genmai: Add ethernet pin group .../bindings/pinctrl/pinctrl-bindings.txt | 2 + .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 219 + arch/arm/boot/dts/r7s72100-genmai.dts | 76 ++ arch/arm/boot/dts/r7s72100.dtsi| 78 ++ drivers/pinctrl/Kconfig| 11 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinconf-generic.c | 3 + drivers/pinctrl/pinctrl-rza1.c | 995 + include/dt-bindings/pinctrl/r7s72100-pinctrl.h | 16 + include/linux/pinctrl/pinconf-generic.h| 7 +- 10 files changed, 1407 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-rza1.c create mode 100644 include/dt-bindings/pinctrl/r7s72100-pinctrl.h -- 2.7.4
[PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
Add bi-directional and output-enable pin configuration properties.
bi-directional allows to specify when a pin shall operate in input and
output mode at the same time. This is particularly useful in platforms
where input and output buffers have to be manually enabled.
output-enable is just syntactic sugar to specify that a pin shall
operate in output mode, ignoring the provided argument.
This pairs with input-enable pin configuration option.
Signed-off-by: Jacopo Mondi
---
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 2 ++
drivers/pinctrl/pinconf-generic.c | 3 +++
include/linux/pinctrl/pinconf-generic.h| 3 +++
3 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index bf3f7b0..f2ed458 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -222,6 +222,7 @@ bias-bus-hold - latch weakly
bias-pull-up - pull up the pin
bias-pull-down - pull down the pin
bias-pull-pin-default - use pin-default pull state
+bi-directional - pin supports simultaneous input/output operations
drive-push-pull- drive actively high and low
drive-open-drain - drive with open drain
drive-open-source - drive with open source
@@ -234,6 +235,7 @@ input-debounce - debounce mode with debound
time X
power-source - select between different power supplies
low-power-enable - enable low power mode
low-power-disable - disable low power mode
+output-enable - enable output on pin regardless of output value
output-low - set the pin to output mode with low level
output-high- set the pin to output mode with high level
slew-rate - set the slew rate
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index ce3335a..03e6808 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -35,6 +35,7 @@ static const struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
"input bias pull to pin specific state", NULL,
false),
PCONFDUMP(PIN_CONFIG_BIAS_PULL_UP, "input bias pull up", NULL, false),
+ PCONFDUMP(PIN_CONFIG_BIDIRECTIONAL, "bi-directional pin operations",
NULL, false),
PCONFDUMP(PIN_CONFIG_DRIVE_OPEN_DRAIN, "output drive open drain", NULL,
false),
PCONFDUMP(PIN_CONFIG_DRIVE_OPEN_SOURCE, "output drive open source",
NULL, false),
PCONFDUMP(PIN_CONFIG_DRIVE_PUSH_PULL, "output drive push pull", NULL,
false),
@@ -160,6 +161,7 @@ static const struct pinconf_generic_params dt_params[] = {
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
{ "bias-pull-pin-default", PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 1 },
{ "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
+ { "bi-directional", PIN_CONFIG_BIDIRECTIONAL, 1 },
{ "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
{ "drive-open-source", PIN_CONFIG_DRIVE_OPEN_SOURCE, 0 },
{ "drive-push-pull", PIN_CONFIG_DRIVE_PUSH_PULL, 0 },
@@ -172,6 +174,7 @@ static const struct pinconf_generic_params dt_params[] = {
{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
+ { "output-enable", PIN_CONFIG_OUTPUT, 1, },
{ "output-high", PIN_CONFIG_OUTPUT, 1, },
{ "output-low", PIN_CONFIG_OUTPUT, 0, },
{ "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
diff --git a/include/linux/pinctrl/pinconf-generic.h
b/include/linux/pinctrl/pinconf-generic.h
index 7620eb1..279e3c5 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -42,6 +42,8 @@
* @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high
* impedance to VDD). If the argument is != 0 pull-up is enabled,
* if it is 0, pull-up is total, i.e. the pin is connected to VDD.
+ * @PIN_CONFIG_BIDIRECTIONAL: the pin will be configured to allow simultaneous
+ * input and output operations.
* @PIN_CONFIG_DRIVE_OPEN_DRAIN: the pin will be driven with open drain (open
* collector) which means it is usually wired with other output ports
* which are then pulled up with an external resistor. Setting this
@@ -96,6 +98,7 @@ enum pin_config_param {
PIN_CONFIG_BIAS_PULL_DOWN,
PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
PIN_CONFIG_BIAS_PULL_UP,
+ PIN_CONFIG_BIDIRECTIONAL,
PIN_CONFIG_DRIVE_OPEN_DRAIN,
PIN_CONFIG_DRIVE_OPEN_SOURCE,
PIN_CONFIG_DRIVE_PUSH_PULL,
--
2.7.4
[PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties
Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
unpack generic properties and their arguments
Signed-off-by: Jacopo Mondi
---
include/linux/pinctrl/pinconf-generic.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/pinctrl/pinconf-generic.h
b/include/linux/pinctrl/pinconf-generic.h
index 279e3c5..2cd2a03 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -118,7 +118,9 @@ enum pin_config_param {
/*
* Helpful configuration macro to be used in tables etc.
*/
-#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
+#define PIN_CONF_PACKED(p, a) (((a) << 8) | ((unsigned long) (p) & 0xffUL))
+#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
+#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)
/*
* The following inlines stuffs a configuration parameter and data value
--
2.7.4
[PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
Add dt-bindings for Renesas r7s72100 pin controller header file. Signed-off-by: Jacopo Mondi --- include/dt-bindings/pinctrl/r7s72100-pinctrl.h | 16 1 file changed, 16 insertions(+) create mode 100644 include/dt-bindings/pinctrl/r7s72100-pinctrl.h diff --git a/include/dt-bindings/pinctrl/r7s72100-pinctrl.h b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h new file mode 100644 index 000..6b609fe --- /dev/null +++ b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h @@ -0,0 +1,16 @@ +/* + * Defines macros and constants for Renesas RZ/A1 pin controller pin + * muxing functions. + */ +#ifndef __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H +#define __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H + +#define RZA1_PINS_PER_PORT 16 + +/* + * Create the pin index from its bank and position numbers and store in + * the upper 16 bits the alternate function identifier + */ +#define RZA1_PINMUX(b, p, f) ((b) * RZA1_PINS_PER_PORT + (p) | (f << 16)) + +#endif /* __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H */ -- 2.7.4
[PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc
Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
controller.
Signed-off-by: Jacopo Mondi
---
.../bindings/pinctrl/renesas,rza1-pinctrl.txt | 219 +
1 file changed, 219 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
new file mode 100644
index 000..5a1106d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
@@ -0,0 +1,219 @@
+Renesas RZ/A1 combined Pin and GPIO controller
+
+The Renesas SoCs of the RZ/A1 family feature a combined Pin and GPIO
controller,
+named "Ports" in the hardware reference manual.
+Pin multiplexing and GPIO configuration is performed on a per-pin basis
+writing configuration values to per-port register sets.
+Each "port" features up to 16 pins, each of them configurable for GPIO
+function (port mode) or in alternate function mode.
+Up to 8 different alternate function modes exist for each single pin.
+
+Pin controller node
+---
+
+Required properties:
+ - compatible
+this shall be "renesas,r7s72100-ports".
+
+ - reg
+address base and length of the memory area where the pin controller
+hardware is mapped to.
+
+Example:
+Pin controller node for RZ/A1H SoC (r7s72100)
+
+pinctrl: pin-controller@fcfe3000 {
+ compatible = "renesas,r7s72100-ports";
+
+ reg = <0xfcfe3000 0x4230>;
+};
+
+Sub-nodes
+-
+
+The child nodes of the pin controller node describe a pin multiplexing
+function or a GPIO controller alternatively.
+
+- Pin multiplexing sub-nodes:
+ A pin multiplexing sub-node describes how to configure a set of
+ (or a single) pin in some desired alternate function mode.
+ A single sub-node may define several pin configurations.
+ Some alternate functions require special pin configuration flags to be
+ supplied along with the alternate function configuration number.
+ When the hardware reference manual specifies a pin function to be either
+ "bi-directional" or "software IO driven", use the generic properties from
+ the header file to instruct the
+ pin controller to perform the desired pin configuration operations.
+ Please refer to pinctrl-bindings.txt to get to know more on generic
+ pin properties usage.
+
+ The allowed generic formats for a pin multiplexing sub-node are the
+ following ones:
+
+ node-1 {
+ pinmux = , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ node-2 {
+ sub-node-1 {
+ pinmux = , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ sub-node-2 {
+ pinmux = , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ ...
+
+ sub-node-n {
+ pinmux = , , ... ;
+ GENERIC_PINCONFIG;
+ };
+ };
+
+ Use the second format when pins part of the same logical group need to have
+ different generic pin configuration flags applied.
+
+ Client sub-nodes shall refer to pin multiplexing sub-nodes using the phandle
+ of the most external one.
+
+ Eg.
+
+ client-1 {
+ ...
+ pinctrl-0 = <&node-1>;
+ ...
+ };
+
+ client-2 {
+ ...
+ pinctrl-0 = <&node-2>;
+ ...
+ };
+
+ Required properties:
+- pinmux:
+ integer array representing pin number and pin multiplexing configuration.
+ When a pin has to be configured in alternate function mode, use this
+ property to identify the pin by its global index, and provide its
+ alternate function configuration number along with it.
+ When multiple pins are required to be configured as part of the same
+ alternate function they shall be specified as members of the same
+ argument list of a single "pinmux" property.
+ Helper macros to ease assembling the pin index from its position
+ (port where it sits on and pin number) and alternate function identifier
+ are provided by the pin controller header file at:
+
+ Integers values in "pinmux" argument list are assembled as:
+ ((PORT * 16 + PIN) | MUX_FUNC << 16)
+
+ Optional generic properties:
+- bi-directional:
+ for pins requiring bi-directional operations.
+- input-enable:
+ for pins requiring software driven IO input operations.
+- output-enable:
+ for pins requiring software driven IO output operations.
+
+ The hardware reference manual specifies when a pin has to be configured to
+ work in bi-directional mode and when the IO direction has to be specified
+ by software.
+
+ Example:
+ A serial communication interface with a TX output pin and an RX input pin.
+
+ &pinctrl {
+ scif2_pins: serial2 {
+ pinmux = , ;
+ };
+ };
+
+ Pin #0 on port #3 is configured as alternate function #6.
+ Pin #2 on port #3 is configured as alternate function #4.
+
+ Example 2:
+ I2c master: both SDA and SCL pins need bi-directional operations
[PATCH v5 03/10] pinctrl: Renesas RZ/A1 pin and gpio controller
Add combined gpio and pin controller driver for Renesas RZ/A1
r7s72100 SoC.
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/Kconfig| 11 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-rza1.c | 995 +
3 files changed, 1007 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-rza1.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af..8eb84a9 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -163,6 +163,17 @@ config PINCTRL_ROCKCHIP
select GENERIC_IRQ_CHIP
select MFD_SYSCON
+config PINCTRL_RZA1
+ bool "Renesas RZ/A1 gpio and pinctrl driver"
+ depends on OF
+ depends on ARCH_R7S72100 || COMPILE_TEST
+ select GPIOLIB
+ select GENERIC_PINCTRL_GROUPS
+ select GENERIC_PINMUX_FUNCTIONS
+ select GENERIC_PINCONF
+ help
+ This selects pinctrl driver for Renesas RZ/A1 platforms.
+
config PINCTRL_SINGLE
tristate "One-register-per-pin type device tree based pinctrl driver"
depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f43..0c2328d2 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PINCTRL_PALMAS) += pinctrl-palmas.o
obj-$(CONFIG_PINCTRL_PIC32)+= pinctrl-pic32.o
obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o
obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
+obj-$(CONFIG_PINCTRL_RZA1) += pinctrl-rza1.o
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_SIRF) += sirf/
obj-$(CONFIG_PINCTRL_SX150X) += pinctrl-sx150x.o
diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
new file mode 100644
index 000..b0f044d
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-rza1.c
@@ -0,0 +1,995 @@
+/*
+ * Combined GPIO and pin controller support for Renesas RZ/A1 (r7s72100) SoC
+ *
+ * Copyright (C) 2017 Jacopo Mondi
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/*
+ * This pincontroller/gpio combined driver support Renesas devices of RZ/A1
+ * family.
+ * This includes SoCs which are sub- or super- sets of this particular line,
+ * as RZ/A1H (r7s721000), RZ/A1M (r7s721010) and RZ/A1L (r7s721020) are.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "devicetree.h"
+#include "pinconf.h"
+#include "pinmux.h"
+
+#define DRIVER_NAME"pinctrl-rza1"
+
+#define RZA1_P_REG 0x
+#define RZA1_PPR_REG 0x0200
+#define RZA1_PM_REG0x0300
+#define RZA1_PMC_REG 0x0400
+#define RZA1_PFC_REG 0x0500
+#define RZA1_PFCE_REG 0x0600
+#define RZA1_PFCEA_REG 0x0a00
+#define RZA1_PIBC_REG 0x4000
+#define RZA1_PBDC_REG 0x4100
+#define RZA1_PIPC_REG 0x4200
+
+#define RZA1_ADDR(mem, reg, port) ((mem) + (reg) + ((port) * 4))
+
+#define RZA1_NPORTS12
+#define RZA1_PINS_PER_PORT 16
+#define RZA1_NPINS (RZA1_PINS_PER_PORT * RZA1_NPORTS)
+#define RZA1_PIN_ID_TO_PORT(id)((id) / RZA1_PINS_PER_PORT)
+#define RZA1_PIN_ID_TO_PIN(id) ((id) % RZA1_PINS_PER_PORT)
+
+/*
+ * Use 16 lower bits [15:0] for pin identifier
+ * Use 16 higher bits [31:16] for pin mux function
+ */
+#define MUX_PIN_ID_MASKGENMASK(15, 0)
+#define MUX_FUNC_MASK GENMASK(31, 16)
+
+#define MUX_FUNC_OFFS 16
+#define MUX_FUNC(pinconf) \
+ ((pinconf & MUX_FUNC_MASK) >> MUX_FUNC_OFFS)
+#define MUX_FUNC_PFC_MASK BIT(0)
+#define MUX_FUNC_PFCE_MASK BIT(1)
+#define MUX_FUNC_PFCEA_MASKBIT(2)
+
+/* Pin mux flags: translated from pinconf standard properties */
+#define MUX_FLAGS_BIDIRBIT(0)
+#define MUX_FLAGS_SWIO_INPUT BIT(1)
+#define MUX_FLAGS_SWIO_OUTPUT BIT(2)
+
+/**
+ * rza1_mux_conf - describes a pin multiplexing operation
+ *
+ * @id: the pin identifier from 0 to RZA1_NPINS
+ * @port: the port where pin sits on
+ * @pin: pin id
+ * @mux_func: alternate function id number
+ * @mux_flags: alternate function flags
+ * @value: output value to set the pin to
+ */
+struct rza1_mux_conf {
+ u16 id;
+ u8 port;
+ u8 pin;
+ u8 mux_func;
+ u8 mux_flags;
+ u8 value;
+};
+
+/**
+ * rza1_port - describes a pin port
+ *
+ * This is mostly useful to lock register writes per-bank and not globally.
+ *
+ * @lock: protect access to HW registers
+ * @id: port number
+ * @base: logical address base
+ * @pin
[PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group
Add pin configuration subnode for SCIF2 serial debug interface.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r7s72100-genmai.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 118a8e2..c28d74b 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "r7s72100.dtsi"
+#include
/ {
model = "Genmai";
@@ -36,6 +37,14 @@
};
};
+&pinctrl {
+
+ scif2_pins: serial2 {
+ /* P3_0 as TxD2; P3_2 as RxD2 */
+ pinmux = , ;
+ };
+};
+
&extal_clk {
clock-frequency = <1333>;
};
@@ -60,6 +69,9 @@
};
&scif2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&scif2_pins>;
+
status = "okay";
};
--
2.7.4
[PATCH v5 08/10] arm: dts: genmai: Add RIIC2 pin group
Add pin configuration subnode for RIIC2 interface.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r7s72100-genmai.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
b/arch/arm/boot/dts/r7s72100-genmai.dts
index c28d74b..9add1b6 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -43,6 +43,12 @@
/* P3_0 as TxD2; P3_2 as RxD2 */
pinmux = , ;
};
+
+ i2c2_pins: i2c2 {
+ /* RIIC2: P1_4 as SCL, P1_5 as SDA */
+ pinmux = , ;
+ bi-directional;
+ };
};
&extal_clk {
@@ -61,6 +67,9 @@
status = "okay";
clock-frequency = <40>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
eeprom@50 {
compatible = "renesas,24c128";
reg = <0x50>;
--
2.7.4
[PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
Add pin configuration subnode for ETHER ethernet controller.
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100-genmai.dts | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
b/arch/arm/boot/dts/r7s72100-genmai.dts
index f7c512e..328f4c9 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -63,6 +63,34 @@
pinmux = , ;
bi-directional;
};
+
+ ether_pins: ether {
+ pins {
+ /* Ethernet on Ports 1,2,3,5 */
+ pinmux = ,/* P1_14 = ET_COL */
+, /* P5_9 = ET_MDC */
+, /* P3_4 = ET_RXCLK */
+, /* P3_5 = ET_RXER */
+, /* P3_6 = ET_RXDV */
+, /* P2_0 = ET_TXCLK */
+, /* P2_1 = ET_TXER */
+, /* P2_2 = ET_TXEN */
+, /* P2_3 = ET_CRS */
+, /* P2_4 = ET_TXD0 */
+, /* P2_5 = ET_TXD1 */
+, /* P2_6 = ET_TXD2 */
+, /* P2_7 = ET_TXD3 */
+, /* P2_8 = ET_RXD0 */
+, /* P2_9 = ET_RXD1 */
+,/* P2_10 = ET_RXD2 */
+;/* P2_11 = ET_RXD3 */
+ };
+
+ pins_bidir {
+ pinmux = ;/* P3_3 = ET_MDIO */
+ bi-directional;
+ };
+ };
};
&extal_clk {
@@ -77,6 +105,19 @@
status = "okay";
};
+ðer {
+ pinctrl-names = "default";
+ pinctrl-0 = <ðer_pins>;
+
+ status = "okay";
+
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
&i2c2 {
status = "okay";
clock-frequency = <40>;
--
2.7.4
[PATCH v5 09/10] arm: dts: genmai: Add user led device nodes
Add device nodes for user leds on Genmai board.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r7s72100-genmai.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 9add1b6..f7c512e 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "r7s72100.dtsi"
+#include
#include
/ {
@@ -35,6 +36,19 @@
#address-cells = <1>;
#size-cells = <1>;
};
+
+ leds {
+ status = "okay";
+ compatible = "gpio-leds";
+
+ led1 {
+ gpios = <&port4 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led2 {
+ gpios = <&port4 11 GPIO_ACTIVE_LOW>;
+ };
+ };
};
&pinctrl {
--
2.7.4
[PATCH v5 06/10] arm: dts: r7s72100: Add pin controller node
Add pin controller node with 12 gpio controller sub-nodes to
r7s72100 dtsi.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r7s72100.dtsi | 78 +
1 file changed, 78 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index b8aa256..9342ff4 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -180,6 +180,84 @@
};
};
+ pinctrl: pin-controller@fcfe3000 {
+ compatible = "renesas,r7s72100-ports";
+
+ reg = <0xfcfe3000 0x4230>;
+
+ port0: gpio-0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 0 6>;
+ };
+
+ port1: gpio-1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 16 16>;
+ };
+
+ port2: gpio-2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 32 16>;
+ };
+
+ port3: gpio-3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 48 16>;
+ };
+
+ port4: gpio-4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 64 16>;
+ };
+
+ port5: gpio-5 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 80 11>;
+ };
+
+ port6: gpio-6 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 96 16>;
+ };
+
+ port7: gpio-7 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 112 16>;
+ };
+
+ port8: gpio-8 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 128 16>;
+ };
+
+ port9: gpio-9 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 144 8>;
+ };
+
+ port10: gpio-10 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 160 16>;
+ };
+
+ port11: gpio-11 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 176 16>;
+ };
+ };
+
scif0: serial@e8007000 {
compatible = "renesas,scif-r7s72100", "renesas,scif";
reg = <0xe8007000 64>;
--
2.7.4
Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
> @@ -371,7 +371,7 @@ static void reap_tx_dxes(struct wcn36xx *wcn,
> struct wcn36xx_dxe_ch *ch)
> info = IEEE80211_SKB_CB(ctl->skb);
> if (!(info->flags &
> IEEE80211_TX_CTL_REQ_TX_STATUS)) {
> /* Keep frame until TX status comes
> */
> - ieee80211_free_txskb(wcn->hw, ctl-
> >skb);
> + ieee80211_tx_status(wcn->hw, ctl-
> >skb);
>
I don't think this is a good idea. This code intentionally checked if
TX status was requested, and if not then it doesn't go to the effort of
building it.
As it is with your patch, it'll go and report the TX status without any
TX status information - which is handled in wcn36xx_dxe_tx_ack_ind()
for those frames needing it.
johannes
[PATCH v2 2/2] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support.
This patch adds balanced acpi_get_table()/acpi_put_table() support for
sysfs table dumping code so that no need to call
acpi_get_validated_table().
Since ACPICA does not use all of the tables, this can help to reduce some
usless memory mappings by utilizing the new table handling APIs.
The original sysfs dumpable ACPI table implementation forces tables to be
mapped after a read operation and never unmaps them again whatever there
are no users in the kernel interested in these tables. With new balanced
table handling APIs, tables are unmapped after the read operation.
Signed-off-by: Lv Zheng
---
drivers/acpi/sysfs.c | 51 ---
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 1b5ee1e..c3bb6ce 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -333,21 +333,34 @@ static ssize_t acpi_table_show(struct file *filp, struct
kobject *kobj,
container_of(bin_attr, struct acpi_table_attr, attr);
struct acpi_table_header *table_header = NULL;
acpi_status status;
+ ssize_t len;
status = acpi_get_table(table_attr->name, table_attr->instance,
&table_header);
if (ACPI_FAILURE(status))
return -ENODEV;
+ len = memory_read_from_buffer(buf, count, &offset,
+ table_header, table_header->length);
+ acpi_put_table(table_header);
+ return len;
+}
+
+static bool acpi_table_has_multiple_instances(char *signature)
+{
+ acpi_status status;
+ struct acpi_table_header *header;
- return memory_read_from_buffer(buf, count, &offset,
- table_header, table_header->length);
+ status = acpi_get_table(signature, 2, &header);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_put_table(header);
+ return true;
}
static int acpi_table_attr_init(struct kobject *tables_obj,
struct acpi_table_attr *table_attr,
struct acpi_table_header *table_header)
{
- struct acpi_table_header *header = NULL;
struct acpi_table_attr *attr = NULL;
char instance_str[ACPI_INST_SIZE];
@@ -368,9 +381,9 @@ static int acpi_table_attr_init(struct kobject *tables_obj,
ACPI_MOVE_NAME(table_attr->filename, table_header->signature);
table_attr->filename[ACPI_NAME_SIZE] = '\0';
- if (table_attr->instance > 1 || (table_attr->instance == 1 &&
-!acpi_get_table
-(table_header->signature, 2,
&header))) {
+ if (table_attr->instance > 1 ||
+ (table_attr->instance == 1 &&
+acpi_table_has_multiple_instances(table_header->signature))) {
snprintf(instance_str, sizeof(instance_str), "%u",
table_attr->instance);
strcat(table_attr->filename, instance_str);
@@ -419,11 +432,11 @@ acpi_status acpi_sysfs_table_handler(u32 event, void
*table, void *context)
static int acpi_tables_sysfs_init(void)
{
- struct acpi_table_attr *table_attr;
+ struct acpi_table_attr *table_attr = NULL;
struct acpi_table_header *table_header = NULL;
int table_index;
acpi_status status;
- int ret;
+ int ret = 0;
tables_kobj = kobject_create_and_add("tables", acpi_kobj);
if (!tables_kobj)
@@ -435,24 +448,32 @@ static int acpi_tables_sysfs_init(void)
for (table_index = 0;; table_index++) {
status = acpi_get_table_by_index(table_index, &table_header);
-
if (status == AE_BAD_PARAMETER)
break;
-
if (ACPI_FAILURE(status))
- continue;
+ goto next_table;
table_attr = kzalloc(sizeof(*table_attr), GFP_KERNEL);
- if (!table_attr)
- return -ENOMEM;
+ if (!table_attr) {
+ ret = -ENOMEM;
+ goto next_table;
+ }
ret = acpi_table_attr_init(tables_kobj,
table_attr, table_header);
+ if (ret)
+ goto next_table;
+ list_add_tail(&table_attr->node, &acpi_table_attr_list);
+
+next_table:
+ acpi_put_table(table_header);
if (ret) {
- kfree(table_attr);
+ if (table_attr) {
+ kfree(table_attr);
+ table_attr = NULL;
+ }
return ret;
}
- list_add_tail(&table_attr->node, &acpi_table_attr_list);
}
kobject_uevent(tables_kobj, KOBJ_ADD);
--
2.7.4
[PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling
In the Linux kernel side, acpi_get_table() clones haven't been fully
balanced by acpi_put_table() invocations. In ACPICA side, due to the design
change, there are also unbalanced acpi_get_table_by_index() invocations
requiring special care to be cleaned up.
So it is not a good timing to report acpi_get_table() counting errors for
this period. The strict balanced validation count check should only be
enabled after confirming that all invocations are safe and compliant to
their designed purposes.
Thus this patch removes the fatal error along with lthe error report to
fix this issue. Reported by Dan Williams, fixed by Lv Zheng.
Fixes: 174cc7187e6f ("ACPICA: Tables: Back port acpi_get_table_with_size() and
early_acpi_os_unmap_memory() from Linux kernel")
Reported-by: Dan Williams
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/tbutils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 5a968a7..8175c70 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -418,11 +418,13 @@ acpi_tb_get_table(struct acpi_table_desc *table_desc,
table_desc->validation_count++;
if (table_desc->validation_count == 0) {
+ table_desc->validation_count--;
+#if 0
ACPI_ERROR((AE_INFO,
"Table %p, Validation count is zero after
increment\n",
table_desc));
- table_desc->validation_count--;
return_ACPI_STATUS(AE_LIMIT);
+#endif
}
*out_table = table_desc->pointer;
--
2.7.4
Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem
On 2017-04-26 11:32:36 [+0100], Mark Rutland wrote: > > So we could end up calling static_branch_enable_cpuslocked() > > without actually holding the lock. Should we do a cpu_hotplug_begin/done in > > setup_cpu_feature_capabilities ? I agree it doesn't look that nice. > > Thoughts ? > > I agree that's hideous, but it looks like the only choice given the > hotplug rwsem cahnges. :/ would work for you to provide a locked and unlocked version? > I can spin a v2 with that and the typo fixes. > > Thanks, > Mark. Sebastian
Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg
On 27 April 2017 at 02:30, Tejun Heo wrote: > Hello, Vincent. > > On Wed, Apr 26, 2017 at 12:21:52PM +0200, Vincent Guittot wrote: >> > This is from the follow-up patch. I was confused. Because we don't >> > propagate decays, we still should decay the runnable_load_avg; >> > otherwise, we end up accumulating errors in the counter. I'll drop >> > the last patch. >> >> Ok, the runnable_load_avg goes back to 0 when I drop patch 3. But i >> see runnable_load_avg sometimes significantly higher than load_avg >> which is normally not possible as load_avg = runnable_load_avg + >> sleeping task's load_avg > > So, while load_avg would eventually converge on runnable_load_avg + > blocked load_avg given stable enough workload for long enough, > runnable_load_avg jumping above load avg temporarily is expected, No, it's not. Look at load_avg/runnable_avg at root domain when only task are involved, runnable_load_avg will never be higher than load_avg because load_avg = /sum load_avg of tasks attached to the cfs_rq runnable_load_avg = /sum load_avg of tasks attached and enqueued to the cfs_rq load_avg = runnable_load_avg + blocked tasks and as a result runnable_load_avg is always lower than load_avg. And with the propagate load/util_avg patchset, we can even reflect task migration directly at root domain whereas we had to wait for the util/load_avg and runnable_load_avg to converge to the new value before Just to confirm one of my assumption, the latency regression was already there in previous kernel versions and is not a result of propagate load/util_avg patchset, isn't it ? > AFAICS. That's the whole point of it, a sum closely tracking what's > currently on the cpu so that we can pick the cpu which has the most on > it now. It doesn't make sense to try to pick threads off of a cpu > which is generally loaded but doesn't have much going on right now, > after all. The only interest of runnable_load_avg is to be null when a cfs_rq is idle whereas load_avg is not but not to be higher than load_avg. The root cause is that load_balance only looks at "load" but not number of task currently running and that's probably the main problem: runnable_load_avg has been added because load_balance fails to filter idle group and idle rq. We should better add a new type in group_classify to tag group that are idle and the same in find_busiest_queue more. > >> Then, I just have the opposite behavior on my platform. I see a >> increase of latency at p99 with your patches. >> My platform is a hikey : 2x4 cores ARM and I have used schbench -m 2 >> -t 4 -s 1 -c 15000 -r 30 so I have 1 worker thread per CPU which >> is similar to what you are doing on your platform >> >> With v4.11-rc8. I have run 10 times the test and get consistent results > ... >> *99.th: 539 > ... >> With your patches i see an increase of the latency for p99. I run 10 >> *99.th: 2034 > > I see. This is surprising given that at least the purpose of the > patch is restoring cgroup behavior to match !cgroup one. I could have > totally messed it up tho. Hmm... there are several ways forward I > guess. > > * Can you please double check that the higher latencies w/ the patch > is reliably reproducible? The test machines that I use have > variable management load. They never dominate the machine but are > enough to disturb the results so that to drawing out a reliable > pattern takes a lot of repeated runs. I'd really appreciate if you > could double check that the pattern is reliable with different run > patterns (ie. instead of 10 consecutive runs after another, > interleaved). I always let time between 2 consecutive run and the 10 consecutive runs take around 2min to execute Then I have run several time these 10 consecutive test and results stay the same > > * Is the board something easily obtainable? It'd be the eaisest for > me to set up the same environment and reproduce the problem. I > looked up hikey boards on amazon but couldn't easily find 2x4 core It is often named hikey octo cores but I use 2x4 cores just to point out that there are 2 clusters which is important for scheduler topology and behavior > ones. If there's something I can easily buy, please point me to it. > If there's something I can loan, that'd be great too. It looks like most of web site are currently out of stock > > * If not, I'll try to clean up the debug patches I have and send them > your way to get more visiblity but given these things tend to be > very iterative, it might take quite a few back and forth. Yes, that could be usefull. Even a trace of regression could be useful I can also push on my git tree the debug patch that i use for tracking load metrics if you want. It's ugly but it does the job Thanks > > Thanks! > > -- > tejun
Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg
On 27 April 2017 at 00:52, Tejun Heo wrote: > Hello, > > On Wed, Apr 26, 2017 at 08:12:09PM +0200, Vincent Guittot wrote: >> On 24 April 2017 at 22:14, Tejun Heo wrote: >> Can the problem be on the load balance side instead ? and more >> precisely in the wakeup path ? >> After looking at the trace, it seems that task placement happens at >> wake up path and if it fails to select the right idle cpu at wake up, >> you will have to wait for a load balance which is alreayd too late > > Oh, I was tracing most of scheduler activities and the ratios of > wakeups picking idle CPUs were about the same regardless of cgroup > membership. I can confidently say that the latency issue that I'm > seeing is from load balancer picking the wrong busiest CPU, which is > not to say that there can be other problems. ok. Is there any trace that you can share ? your behavior seems different of mine > >> > another queued wouldn't report the correspondingly higher >> >> It will as load_avg includes the runnable_load_avg so whatever load is >> in runnable_load_avg will be in load_avg too. But at the contrary, >> runnable_load_avg will not have the blocked that is going to wake up >> soon in the case of schbench > > Decaying contribution of blocked tasks don't affect the busiest CPU > selection. Without cgroup, runnable_load_avg is immediately increased > and decreased as tasks enter and leave the queue and otherwise we end > up with CPUs which are idle when there are threads queued on different > CPUs accumulating scheduling latencies. > > The patch doesn't change how the busiest CPU is picked. It already > uses runnable_load_avg. The change that cgroup causes is that it > blocks updates to runnable_load_avg from newly scheduled or sleeping > tasks. > > The issue isn't about whether runnable_load_avg or load_avg should be > used but the unexpected differences in the metrics that the load I think that's the root of the problem. I explain a bit more my view on the other thread > balancer uses depending on whether cgroup is used or not. > >> One last thing, the load_avg of an idle CPU can stay blocked for a >> while (until a load balance happens that will update blocked load) and >> can be seen has "busy" whereas it is not. Could it be a reason of your >> problem ? > > AFAICS, the load balancer doesn't use load_avg. > > Thanks. > > -- > tejun
[PATCH 1/2] sched: Staticize pick_next_task_dl() and build_sched_domain()
pick_next_task_dl() and build_sched_domain() aren't used outside
deadline.c and topology.c.
Make them static.
Signed-off-by: Viresh Kumar
---
kernel/sched/deadline.c | 2 +-
kernel/sched/topology.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a2ce59015642..ce9679a633f5 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1168,7 +1168,7 @@ static struct sched_dl_entity *pick_next_dl_entity(struct
rq *rq,
return rb_entry(left, struct sched_dl_entity, rb_node);
}
-struct task_struct *
+static struct task_struct *
pick_next_task_dl(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
struct sched_dl_entity *dl_se;
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 1b0b4fb12837..09a56ca76bd1 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1351,7 +1351,7 @@ static void __sdt_free(const struct cpumask *cpu_map)
}
}
-struct sched_domain *build_sched_domain(struct sched_domain_topology_level *tl,
+static struct sched_domain *build_sched_domain(struct
sched_domain_topology_level *tl,
const struct cpumask *cpu_map, struct sched_domain_attr *attr,
struct sched_domain *child, int cpu)
{
--
2.12.0.432.g71c3a4f4ba37
[PATCH 2/2] sched: topology: Initialize span_weight from sd_init()
Most of the sched domain structure gets initialized from sd_init() and
it looks reasonable to initialize span_weight too from it.
Currently it is getting initialized from build_sched_domains(), which
doesn't looks to be the ideal place for doing so.
With this change we need to additionally reset span_weight for a special
error case, but that looks reasonable as span_weight must be updated
every time domain span is updated.
Signed-off-by: Viresh Kumar
---
kernel/sched/topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 09a56ca76bd1..691b290a679e 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -892,6 +892,7 @@ sd_init(struct sched_domain_topology_level *tl,
.last_balance = jiffies,
.balance_interval = sd_weight,
+ .span_weight= sd_weight,
.smt_gain = 0,
.max_newidle_lb_cost= 0,
.next_decay_max_lb_cost = jiffies,
@@ -1373,6 +1374,7 @@ static struct sched_domain *build_sched_domain(struct
sched_domain_topology_leve
cpumask_or(sched_domain_span(sd),
sched_domain_span(sd),
sched_domain_span(child));
+ sd->span_weight = cpumask_weight(sched_domain_span(sd));
}
}
@@ -1417,7 +1419,6 @@ build_sched_domains(const struct cpumask *cpu_map, struct
sched_domain_attr *att
/* Build the groups for the domains */
for_each_cpu(i, cpu_map) {
for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) {
- sd->span_weight = cpumask_weight(sched_domain_span(sd));
if (sd->flags & SD_OVERLAP) {
if (build_overlap_sched_groups(sd, i))
goto error;
--
2.12.0.432.g71c3a4f4ba37
Re: [PATCH] mm, zone_device: replace {get, put}_zone_device_page() with a single reference
On Wed, Apr 26, 2017 at 05:55:31PM -0700, Dan Williams wrote:
> Kirill points out that the calls to {get,put}_dev_pagemap() can be
> removed from the mm fast path if we take a single get_dev_pagemap()
> reference to signify that the page is alive and use the final put of the
> page to drop that reference.
>
> This does require some care to make sure that any waits for the
> percpu_ref to drop to zero occur *after* devm_memremap_page_release(),
> since it now maintains its own elevated reference.
>
> Cc Ingo Molnar
> Cc: Jérôme Glisse
> Cc: Logan Gunthorpe
> Cc: Andrew Morton
> Suggested-by: Kirill Shutemov
> Signed-off-by: Dan Williams
> ---
>
> This patch might fix the regression that we found with the conversion to
> generic get_user_pages_fast() in the x86/mm branch pending for 4.12
> (commit 2947ba054a4d "x86/mm/gup: Switch GUP to the generic
> get_user_page_fast() implementation"). I'll test tomorrow, but in case
> someone can give it a try before I wake up, here's an early version.
+ Ingo.
This works for me with and without GUP revert.
Tested-by: Kirill A. Shutemov
> drivers/dax/pmem.c|2 +-
> drivers/nvdimm/pmem.c | 13 +++--
There's a trivial conflict in drivers/nvdimm/pmem.c when applied to
tip/master.
> include/linux/mm.h| 14 --
> kernel/memremap.c | 22 +-
> mm/swap.c | 10 ++
> 5 files changed, 31 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
> index d4ca19bd74eb..9f2a0b4fd801 100644
> --- a/drivers/dax/pmem.c
> +++ b/drivers/dax/pmem.c
> @@ -43,6 +43,7 @@ static void dax_pmem_percpu_exit(void *data)
> struct dax_pmem *dax_pmem = to_dax_pmem(ref);
>
> dev_dbg(dax_pmem->dev, "%s\n", __func__);
> + wait_for_completion(&dax_pmem->cmp);
> percpu_ref_exit(ref);
> }
>
> @@ -53,7 +54,6 @@ static void dax_pmem_percpu_kill(void *data)
>
> dev_dbg(dax_pmem->dev, "%s\n", __func__);
> percpu_ref_kill(ref);
> - wait_for_completion(&dax_pmem->cmp);
> }
>
> static int dax_pmem_probe(struct device *dev)
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index 3b3dab73d741..6be0c1253fcd 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -243,6 +244,11 @@ static void pmem_release_queue(void *q)
> blk_cleanup_queue(q);
> }
>
> +static void pmem_freeze_queue(void *q)
> +{
> + blk_mq_freeze_queue_start(q);
> +}
> +
> static void pmem_release_disk(void *__pmem)
> {
> struct pmem_device *pmem = __pmem;
> @@ -301,6 +307,9 @@ static int pmem_attach_disk(struct device *dev,
> if (!q)
> return -ENOMEM;
>
> + if (devm_add_action_or_reset(dev, pmem_release_queue, q))
> + return -ENOMEM;
> +
> pmem->pfn_flags = PFN_DEV;
> if (is_nd_pfn(dev)) {
> addr = devm_memremap_pages(dev, &pfn_res, &q->q_usage_counter,
> @@ -320,10 +329,10 @@ static int pmem_attach_disk(struct device *dev,
> pmem->size, ARCH_MEMREMAP_PMEM);
>
> /*
> - * At release time the queue must be dead before
> + * At release time the queue must be frozen before
>* devm_memremap_pages is unwound
>*/
> - if (devm_add_action_or_reset(dev, pmem_release_queue, q))
> + if (devm_add_action_or_reset(dev, pmem_freeze_queue, q))
> return -ENOMEM;
>
> if (IS_ERR(addr))
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 00a8fa7e366a..ce17b35257ac 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -758,19 +758,11 @@ static inline enum zone_type page_zonenum(const struct
> page *page)
> }
>
> #ifdef CONFIG_ZONE_DEVICE
> -void get_zone_device_page(struct page *page);
> -void put_zone_device_page(struct page *page);
> static inline bool is_zone_device_page(const struct page *page)
> {
> return page_zonenum(page) == ZONE_DEVICE;
> }
> #else
> -static inline void get_zone_device_page(struct page *page)
> -{
> -}
> -static inline void put_zone_device_page(struct page *page)
> -{
> -}
> static inline bool is_zone_device_page(const struct page *page)
> {
> return false;
> @@ -786,9 +778,6 @@ static inline void get_page(struct page *page)
>*/
> VM_BUG_ON_PAGE(page_ref_count(page) <= 0, page);
> page_ref_inc(page);
> -
> - if (unlikely(is_zone_device_page(page)))
> - get_zone_device_page(page);
> }
>
> static inline void put_page(struct page *page)
> @@ -797,9 +786,6 @@ static inline void put_page(struct page *page)
>
> if (put_page_testzero(page))
> __put_page(page);
> -
> - if (unlikely(is_zone_device_page(page)))
> - put_zone_device_page(page);
> }
>
> #if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
> diff --git a/kernel/memr
Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
wrote:
> Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
> unpack generic properties and their arguments
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 03/10] pinctrl: Renesas RZ/A1 pin and gpio controller
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
wrote:
> Add combined gpio and pin controller driver for Renesas RZ/A1
> r7s72100 SoC.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 04/10] dt-bindings: pinctrl: Add RZ/A1 bindings doc
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> controller.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
wrote:
> Add dt-bindings for Renesas r7s72100 pin controller header file.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h
> @@ -0,0 +1,16 @@
> +#define RZA1_PINMUX(b, p, f) ((b) * RZA1_PINS_PER_PORT + (p) | (f << 16))
... | (f) << 16)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
Hi Jacopo,
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
wrote:
>this is 5th round of gpio/pincontroller for RZ/A1 devices.
>
> I have updated the pin controller driver to use the newly introduced
> "pinctrl_enable()" function.
> This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> the pin controller does not start.
>
> I have incorporated your comments on the device tree bindings documentation,
> and added to pinctrl-generic.h header file two macros to unpack generic
> properties and their arguments.
>
> Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
Thanks for the update!
> Jacopo Mondi (10):
> pinctrl: generic: Add bi-directional and output-enable
Already applied by LinusW.
> pinctrl: generic: Add macros to unpack properties
LinusW: do you want me to queue this together with the driver for v4.13,
or will you take this single patch for v4.12?
> pinctrl: Renesas RZ/A1 pin and gpio controller
> dt-bindings: pinctrl: Add RZ/A1 bindings doc
Will queue in sh-pfc-for-v4.13.
> arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> arm: dts: r7s72100: Add pin controller node
> arm: dts: genmai: Add SCIF2 pin group
> arm: dts: genmai: Add RIIC2 pin group
> arm: dts: genmai: Add user led device nodes
> arm: dts: genmai: Add ethernet pin group
These are for Simon.
Does applying the DTS changes before the driver introduce regressions?
If no, Simon can queue them for v4.13.
If yes, they'll have to wait for v4.14.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH V2] x86/tboot: add an option to disable iommu force on
On Thu, Apr 27, 2017 at 08:51:42AM +0200, Ingo Molnar wrote: > > + tboot_noforce [Default Off] > > + Do not force the Intel IOMMU enabled under tboot. > > + By default, tboot will force Intel IOMMU on, which > > + could harm performance of some high-throughput > > + devices like 40GBit network cards, even if identity > > + mapping is enabled. > > + Note that using this option lowers the security > > + provided by tboot because it makes the system > > + vulnerable to DMA attacks. > > So what's the purpose of this kernel option? > > It sure isn't the proper solution for correctly architectured > hardware/firmware > (which can just choose not to expose the IOMMU!), and for one-time hacks for > special embedded systems or for debugging why not just add an iommu=off > option to > force it off? I guess that tboot requires an IOMMU to be present in order to work. It will do initial IOMMU setup and hands the hardware over to Linux later on. The problem solved here is that someone wants tboot for security reasons, but doesn't want the performance penalty of having the IOMMU enabled and can live with the risk of an DMA attack. Regards, Joerg
Re: [PATCH 2/3] selinux: add checksum to policydb
2017-04-26 20:30 GMT+02:00 Stephen Smalley : > This seems like an odd place to trigger the computation. I noticed that the policy as exposed via /sys/fs/selinux/policy can also be modified in security_set_bools(). So in order to limit the places from where to compute the policy checksum, I moved the call to checksum computation to selinux_lsm_notifier_avc_callback(). That being said, maybe the hash of /sys/fs/selinux/policy is not the checksum we want. See your comments and my answers below. > Why aren't you > just computing it when the policy is loaded directly in > security_load_policy()? You already have the (data, len) on entry to > that function. Just compute it at load time, save it, and be done. No > need for a notifier then for your use case unless I am missing > something. You are right. Getting from the Lustre client code the SELinux internally computed checksum is cheap, so no need to be notified every time the policy changes, and no need to store the checksum in Lustre at that time. I will drop the "Implement LSM notification system" patch from this series, as I cannot justify its usefulness from a Lustre client standpoint anymore. > I suppose the question is which checksum do you want - the hash of the > policy file that was written to /sys/fs/selinux/load by userspace, or > the hash of the policy file that the kernel generates on demand if you > open /sys/fs/selinux/policy. Those can differ in non-semantic ways due > to ordering differences, for example. I think the former is more > likely to be of interest to userspace (e.g. to compare the hash value > against the hash of the policy file), and is cheaper since you already > have a (data, len) pair on entry to security_load_policy() that you can > hash immediately rather than requiring the kernel to regenerate the > image from the policydb. OK, I understand now why I was seeing differences between the checksum computed on a (data, len) pair on entry to security_load_policy(), and the checksum computed on a (data, len) pair got from security_read_policy(). I thought it was a problem to have a difference between the internally computed checksum and the one a user can get by calling sha256sum on /sys/fs/selinux/policy. But now I see it makes sense to reflect what was loaded by userspace. So I will simplify this patch accordingly.
Re: [PATCH] net: hso: register netdev later to avoid a race condition
On Wed, Apr 26, 2017 at 07:26:40PM +0200, Andreas Kemnade wrote:
> If the netdev is accessed before the urbs are initialized,
> there will be NULL pointer dereferences. That is avoided by
> registering it when it is fully initialized.
> Reported-by: H. Nikolaus Schaller
> Signed-off-by: Andreas Kemnade
> ---
> drivers/net/usb/hso.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index 93411a3..00067a0 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -2534,13 +2534,6 @@ static struct hso_device *hso_create_net_device(struct
> usb_interface *interface,
> SET_NETDEV_DEV(net, &interface->dev);
> SET_NETDEV_DEVTYPE(net, &hso_type);
>
> - /* registering our net device */
> - result = register_netdev(net);
> - if (result) {
> - dev_err(&interface->dev, "Failed to register device\n");
> - goto exit;
> - }
> -
> /* start allocating */
> for (i = 0; i < MUX_BULK_RX_BUF_COUNT; i++) {
> hso_net->mux_bulk_rx_urb_pool[i] = usb_alloc_urb(0, GFP_KERNEL);
> @@ -2560,6 +2553,13 @@ static struct hso_device *hso_create_net_device(struct
> usb_interface *interface,
>
> add_net_device(hso_dev);
>
> + /* registering our net device */
> + result = register_netdev(net);
> + if (result) {
> + dev_err(&interface->dev, "Failed to register device\n");
> + goto exit;
This all looks good, but you should consider cleaning up the error
handling of this function as a follow-up as we should not be
deregistering netdevs that have never been registered (e.g. if a
required endpoint is missing or if registration fails for some reason).
But just to be clear, this problem existed also before this change.
> + }
> +
> hso_log_port(hso_dev);
>
> hso_create_rfkill(hso_dev, interface);
Reviewed-by: Johan Hovold
Thanks,
Johan
Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta
Sricharan,
On Wed, Apr 26, 2017 at 06:15:08PM +0200, Ralph Sennhauser wrote:
> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time
> for platform/amba/pci bus devices") causes a kernel panic as in the log
> below on an armada-385. Reverting the commit fixes the issue.
Any insight here? I tend to revert the patch in my tree, or is there a
quick and easy fix?
Joerg
Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta
Hi Joerg,
On 4/27/2017 2:14 PM, Joerg Roedel wrote:
> Sricharan,
>
> On Wed, Apr 26, 2017 at 06:15:08PM +0200, Ralph Sennhauser wrote:
>> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time
>> for platform/amba/pci bus devices") causes a kernel panic as in the log
>> below on an armada-385. Reverting the commit fixes the issue.
>
> Any insight here? I tend to revert the patch in my tree, or is there a
> quick and easy fix?
I am checking on this manually to see what could be going wrong in the
driver. From logs i could not conclude directly. I will need some
more testing help (i will ask for) to root cause this.
Regards,
Sricharan
>
>
>
> Joerg
>
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
Re: ipsec doesn't route TCP with 4.11 kernel
On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote: > (Cc'ing netdev and IPSec maintainers) > > On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman wrote: > > I'm not sure how to describe this. > > > > 4.11rc2 worked, after that, no. We had some recent IPsec GRO changes, this could influence TCP. But these changes were introduced before rc2. If I read this correct, the regression was introduced between rc2 and rc3, right? > > > > My ipsec tunnel comes up ok. When talking about IPsec, I guess you use ESP, right? > > ICMP works. UDP works. But TCP, the > > sender [which is the ipsec client] does not reach the destination. > > > > Its not a routing rule issue (since ICMP/UDP work). > > Its not a traffic selector just selecting TCP (I think) since ipsec > > status shows just a subnet, no protocol. > > > > Using tcpdump: > > # iptables -t mangle -I PREROUTING -m policy --pol ipsec --dir in -j > > NFLOG --nflog-group 5 > > # iptables -t mangle -I POSTROUTING -m policy --pol ipsec --dir out -j > > NFLOG --nflog-group 5 > > # tcpdump -s 0 -n -i nflog:5 > > > > I see that it thinks it is sending the TCP packet, but the server end > > does not receive. > > > > Does anyone have any suggestion to try? If it is a GRO issue, then it is on the receive side, could you do tcpdump on the receiving interface to see what you get there? What shows /proc/net/xfrm_stat? Can you do 'ip -s x s' to see if the SAs are used? Do you have INET_ESP_OFFLOAD enabled?
Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing
Hi Eric,
On 04/27/2017 12:52 AM, Eric Biggers wrote:
> Hi David,
>
> On Wed, Apr 26, 2017 at 01:48:10PM +0200, David Oberhollenzer wrote:
>> On 04/25/2017 07:54 PM, Eric Biggers wrote:
>>> Did you test that this change actually does anything? Unlike ext4 and f2fs,
>>> ubifs calls fscrypt_setup_filename() from its rename methods rather than
>>> through
>>> a helper function ${FS}_find_entry(). Therefore it's able to pass in
>>> lookup=0,
>>> which means that the key is required. So it should already be failing with
>>> ENOKEY. You can verify this by running xfstests generic/419.
>>
>> Actually, running xfstests was how this cropped up in the first place.
>>
>> The UBIFS rename and xrename functions allready call
>> fscrypt_setup_filename with lookup=0, however there are other tests
>> before that call and moving them around causes generic/419 to fail
>> at a different place where EPERM was expected.
Sorry, I perhaps replied a little to hastily and mixed up the
test numbers.
I just double checked and read up on the IRC backlog,
it actually _was_ 398 (see below).
> Are you sure? I just tried rebasing my ubifs support patches for xfstests and
> xfstests-bld onto the latest xfstests and xfstests-bld respectively, then
> building a new kvm-xfstests appliance and the latest kernel from Linus's tree.
I used this kernel tree: git://git.infradead.org/linux-ubifs.git
Plus the following patches: https://lkml.org/lkml/2017/2/9/675
Using xfstests-dev: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
Inside a Debian VM with scratch and test UBI volumes on nandsim.
> $ kvm-xfstests -c ubifs -g encrypt
> [15:39:00] - output mismatch (see
> /results/ubifs/results-default/generic/397.out.bad)
> --- tests/generic/397.out 2017-04-26 14:37:27.0 -0700
> +++ /results/ubifs/results-default/generic/397.out.bad2017-04-26
> 15:39:00.807418574 -0700
> @@ -10,4 +10,12 @@
> mkdir: cannot create directory 'SCRATCH_MNT/edir/0123456789abcdef':
> Required key not available
> ln: failed to create symbolic link 'SCRATCH_MNT/edir/newlink': Required
> key not available
> ln: failed to create symbolic link 'SCRATCH_MNT/edir/0123456789abcdef':
> Required key not available
> -stat: cannot stat 'SCRATCH_MNT/edir': No such file or directory
> +rm: cannot remove '/vdc/edir': Directory not empty
> + File: 'SCRATCH_MNT/edir'
> + Size: 632 Blocks: 0 IO Block: 4096 directory
> ...
> (Run 'diff -u tests/generic/397.out
> /results/ubifs/results-default/generic/397.out.bad' to see the entire diff)
> ...
This is fixed by the first patch in https://lkml.org/lkml/2017/2/9/675
> What's happening with generic/398 is that it's trying cross-rename to exchange
> an unencrypted file with an encrypted one. The tests expects ENOKEY, but
> there
> are actually two separate reasons why this operation is expected to fail:
>
> (1) It's trying to link a file into an encrypted directory with the
> directory's
> key being available (ENOKEY)
> (2) It's trying to place an unencrypted file into an encrypted directory,
> which
> violates the policy that all files in an encrypted directory have the same
> encryption policy (EPERM)
Sorry again for the mix up. This is specifically what this patch is
trying to address.
> Personally I think that maybe the generic/398 test should just be updated to
> accept either error code, given that there are two valid reasons for the
> operation to fail.
But if there are different error codes with clearly outlined reasons
for returning each, wouldn't it be preferable to test that instead of
allowing an implementation to return arbitrary error codes?
To my understanding, that is what the test is trying to do there and at
least the ext4 rename and cross rename functions seem to care about
properly distinguishing between those cases.
David
Re: [PATCH 1/2] sched/fair: Fix how load gets propagated from cfs_rq to its sched_entity
On 27 April 2017 at 00:27, Tejun Heo wrote:
> Hello, Vincent.
>
> On Wed, Apr 26, 2017 at 06:14:17PM +0200, Vincent Guittot wrote:
>> > + if (gcfs_rq->load.weight) {
>> > + long shares = calc_cfs_shares(gcfs_rq, gcfs_rq->tg);
>> >
>> > + load = min(gcfs_rq->runnable_load_avg *
>> > + shares / gcfs_rq->load.weight, shares);
>>
>> There is a unit problem above:
>> runnable_load_avg and shares are not in the same range but
>> runnable_load_avg and scale_load_down(gcfs_rq->load.weight) are so
>> you should use
>> gcfs_rq->runnable_load_avg * scale_load_down(shares) /
>> scale_load_down(gcfs_rq->load.weight).
>
> But the only difference there is that we lose accuracy in calculation;
> otherwise, the end results are the same, no?
Yes the end result is the same, it was mainly to point out the range
difference and explain why we need scale_load_down(shares) for the 2nd
argument of min.
This should also explain the warning issue you mentioned earlier
>
>> Hopefully both scale_load_down cancel between them
>> But the min should be then tested with scale_load_down(shares) and not
>> only shares
>
> Ah, that's right. The min should be against scaled down shares.
>
> Thanks.
>
> --
> tejun
4.11.0-rc8+/x86_64 desktop lockup until applications closed
I came home yesterday to discover my desktop KDE/plasma session locked up until I could shutdown firefox and chromium from a console login. The desktop then became responsive and I could then restart firefox and chromium. the 4GiB swap space was nearly full, but the OOM killer apparently didn't run. dmesg showed: [55363.482931] QXcbEventReader: page allocation stalls for 10048ms, order:0, mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null) [55363.482942] QXcbEventReader cpuset=/ mems_allowed=0 [55363.482948] CPU: 2 PID: 4092 Comm: QXcbEventReader Not tainted 4.11.0-rc8+ #2670 [55363.482950] Hardware name: System manufacturer System Product Name/M3A78 PRO, BIOS 170101/27/2011 [55363.482951] Call Trace: [55363.482959] ? dump_stack+0x5c/0x84 [55363.482962] ? warn_alloc+0x112/0x1b0 [55363.482964] ? __alloc_pages_slowpath+0x836/0xde0 [55363.482967] ? ktime_get+0x51/0xd0 [55363.482979] ? scsi_request_fn+0x3d/0x690 [scsi_mod] [55363.482981] ? __alloc_pages_nodemask+0x1eb/0x230 [55363.482984] ? alloc_pages_vma+0xc4/0x280 [55363.482987] ? __read_swap_cache_async+0x189/0x280 [55363.482990] ? read_swap_cache_async+0x24/0x60 [55363.482991] ? swapin_readahead+0x10d/0x1c0 [55363.482994] ? do_swap_page+0x272/0x720 [55363.482997] ? __handle_mm_fault+0x773/0x10f0 [55363.482999] ? handle_mm_fault+0xe7/0x260 [55363.483002] ? __do_page_fault+0x2d4/0x630 [55363.483005] ? page_fault+0x28/0x30 [55363.483008] ? copy_user_generic_string+0x2c/0x40 [55363.483011] ? copy_page_to_iter+0x91/0x2d0 [55363.483014] ? skb_copy_datagram_iter+0x146/0x270 [55363.483016] ? unix_stream_read_actor+0x1a/0x30 [55363.483018] ? unix_stream_read_generic+0x2f8/0x8c0 [55363.483020] ? _raw_spin_lock+0x13/0x40 [55363.483022] ? _raw_spin_unlock_irq+0x1d/0x40 [55363.483024] ? free_swap_slot+0x4e/0x110 [55363.483026] ? _raw_spin_unlock+0x16/0x40 [55363.483028] ? unix_stream_recvmsg+0x81/0xa0 [55363.483029] ? unix_state_double_unlock+0x40/0x40 [55363.483031] ? SYSC_recvfrom+0xe3/0x170 [55363.483034] ? handle_mm_fault+0xe7/0x260 [55363.483036] ? __do_page_fault+0x301/0x630 [55363.483038] ? entry_SYSCALL_64_fastpath+0x1e/0xad [55363.483040] Mem-Info: [55363.483044] active_anon:1479559 inactive_anon:281161 isolated_anon:299 active_file:49213 inactive_file:42134 isolated_file:0 unevictable:4651 dirty:108 writeback:188 unstable:0 slab_reclaimable:11225 slab_unreclaimable:20186 mapped:204768 shmem:145888 pagetables:39859 bounce:0 free:25470 free_pcp:0 free_cma:0 [55363.483050] Node 0 active_anon:5918236kB inactive_anon:1124644kB active_file:196852kB inactive_file:168536kB unevictable:18604kB isolated(anon):1196kB isolated(file):0kB mapped:819072kB dirty:432kB writeback:752kB shmem:583552kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no [55363.483052] Node 0 DMA free:15904kB min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15904kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [55363.483056] lowmem_reserve[]: 0 3150 7885 7885 [55363.483059] Node 0 DMA32 free:45556kB min:26948kB low:33684kB high:40420kB active_anon:2273532kB inactive_anon:542768kB active_file:99788kB inactive_file:89940kB unevictable:32kB writepending:440kB present:3391168kB managed:3314260kB mlocked:32kB slab_reclaimable:8800kB slab_unreclaimable:25976kB kernel_stack:7992kB pagetables:68028kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [55363.483063] lowmem_reserve[]: 0 0 4734 4734 [55363.483066] Node 0 Normal free:40420kB min:40500kB low:50624kB high:60748kB active_anon:3644668kB inactive_anon:581672kB active_file:97068kB inactive_file:78784kB unevictable:18572kB writepending:0kB present:4980736kB managed:4848692kB mlocked:18572kB slab_reclaimable:36100kB slab_unreclaimable:54768kB kernel_stack:13544kB pagetables:91408kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [55363.483069] lowmem_reserve[]: 0 0 0 0 [55363.483072] Node 0 DMA: 0*4kB 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15904kB [55363.483081] Node 0 DMA32: 422*4kB (UME) 847*8kB (UME) 734*16kB (UME) 338*32kB (UME) 108*64kB (UME) 23*128kB (UME) 9*256kB (M) 3*512kB (M) 2*1024kB (M) 0*2048kB 0*4096kB = 46768kB [55363.483090] Node 0 Normal: 1293*4kB (UME) 1451*8kB (UME) 845*16kB (UME) 293*32kB (UME) 36*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 41980kB [55363.483099] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [55363.483100] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [55363.483101] 251525 total pagecache pages [55363.483104] 10025 pages in swa
[PATCH] usb: gadget: udc-xilinx: clean up a variable name
"ep->udc->lock" and "udc->lock" are the same thing. It confuses Smatch
if we don't use the same name consistently.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/udc/udc-xilinx.c
b/drivers/usb/gadget/udc/udc-xilinx.c
index 588e2531b8b8..de207a90571e 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -1151,7 +1151,7 @@ static int xudc_ep_dequeue(struct usb_ep *_ep, struct
usb_request *_req)
break;
}
if (&req->usb_req != _req) {
- spin_unlock_irqrestore(&ep->udc->lock, flags);
+ spin_unlock_irqrestore(&udc->lock, flags);
return -EINVAL;
}
xudc_done(ep, req, -ECONNRESET);
Cgroups, burst
Hey, Is there an easy way to burst CPU resources with cgroups when needed? For example I want to restrict 20% of CPU per process and for example i want to allow process to use 100% of CPU for 30 sec (burst). I mean i want restrict CPU usage at 20% per process, not per group. Restrict resources per group I can do this way: echo 1 > cpu.cfs.quota_us echo 5 > cpu.cfs_period_us But I want to restrict usage per process, and if there is a possibility to burst it. Or maybe is there a function that will indicate when app will consume all resources? Then I will just switch her PID to another cgroup (that will have 100% CPU) for 30 seconds and then back to previous cgroup.
RE: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support
> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Thursday, April 27, 2017 3:55 AM > To: Sreekanth Reddy > Cc: Martin K. Petersen; j...@kernel.org; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org; Christoph Hellwig > Subject: Re: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor > Post Queue (RDPQ) Array support > > > Sreekanth, > > > We need to satisfy this condition on those system where 32 bit dma > > consistent mask is not supported and it only supports 64 bit dma > > consistent mask. So on these system we can't set > > pci_set_consistent_dma_mask() to DMA_BIT_MASK(32). > > Which systems are you talking about? > > It seems a bit unrealistic to require all devices to support 64-bit DMA. Martin - We have found all devices to support 64-bit DMA on certain ARM64 platform. I discussed @linux-arm-kern. Below is a thread. http://marc.info/?l=linux-arm-kernel&m=148880763816046&w=2 For ARM64, it is not supporting SWIOTLB and that is a reason we need to make all DMA pool above 4GB. Ea. If I map crash kernel above 4GB in x86_64 platform, they owner DMA 32 bit mask since arch specific code in x86_64 support SWIOTLB. Same settings on ARM64 platform fails DAM 32 bit mask. In one particular setup of ARM64, I also see below 4GB is mapped to SoC and kernel component mapped above 4GB region. Can we add in MR/IT driver below logic to meet this requirement ? - Driver will attempt DMA buffer above 4GB and check the start and end address of the physical address. If DMA buffer cross the "Same 4GB region" ( I mean High Address should be constant for that region.), driver will hold that region and attempt one more allocation. If second allocation is also not meeting "Same 4GB region", we will give up driver load. Before we attempt above logic, we would like to understand if we have any other reliable method ways to handle this in Linux. Most of the time, we are going to get "same 4GB region", so we are OK to have this corner case to detect and bail out driver load. There is no report of issue from field, but wanted to protect failure for future. Thanks, Kashyap > > -- > Martin K. PetersenOracle Linux Engineering
Re: [PATCH] iio:ad5064: Add support for ltc2633 and similar devices
On 04/27/2017 07:52 AM, Jonathan Cameron wrote:
> On 26/04/17 10:44, Mike Looijmans wrote:
>> The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar
>> to the AD5064 device, in particular the LTC2627.
>>
>> This patch adds support for those devices. Only the LTC2633 has been
>> tested, which is the 2-channel variant. The LTC2631 is the 1-channel,
>> and the LTC2635 the 4-channel version. The actual DAC resolution depends
>> on the exact chip type and can be 12, 10 or 8 bits, using the upper bits
>> so this has no effect on the register map. The internal reference is set
>> to 2.5V on "L" versions, and it's 4.096V for "H" versions.
>>
>> Datasheets:
>> LTC2631: http://www.linear.com/docs/26553
>> LTC2633: http://www.linear.com/docs/39529
>> LTC2635: http://www.linear.com/docs/28754
>>
>> Signed-off-by: Mike Looijmans
Ah, its always good if somebody manages to clear an item from your TODO list
before you :)
> Looks fine to me, but I'd like to give time for Lars to take a look
> as it is his driver.
Patch looks good, but I'd prefer it if we had different entries in the
device table for different resolutions. So you don't have to manually shift
the output value by 12 when you are using the 8-bit version. This is how it
has been done for other DAC drivers and it would be good to stay consistent.
Maybe even include the reset-to-midscale/reset-to-gnd designator of the part
number in the compatible string.
http://cds.linear.com/docs/en/datasheet/2631fc.pdf#page=3
> Jonathan
>> ---
>> drivers/iio/dac/Kconfig | 3 ++-
>> drivers/iio/dac/ad5064.c | 58
>> ++--
>> 2 files changed, 58 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>> index d3084028..31ffb67 100644
>> --- a/drivers/iio/dac/Kconfig
>> +++ b/drivers/iio/dac/Kconfig
>> @@ -13,7 +13,8 @@ config AD5064
>>AD5045, AD5064, AD5064-1, AD5065, AD5625, AD5625R, AD5627, AD5627R,
>>AD5628, AD5629R, AD5645R, AD5647R, AD5648, AD5665, AD5665R, AD5666,
>>AD5667, AD5667R, AD5668, AD5669R, LTC2606, LTC2607, LTC2609, LTC2616,
>> - LTC2617, LTC2619, LTC2626, LTC2627, LTC2629 Digital to Analog
>> Converter.
>> + LTC2617, LTC2619, LTC2626, LTC2627, LTC2629, LTC2631, LTC2633, LTC2635
>> + Digital to Analog Converter.
>>
>>To compile this driver as a module, choose M here: the
>>module will be called ad5064.
>> diff --git a/drivers/iio/dac/ad5064.c b/drivers/iio/dac/ad5064.c
>> index 6803e4a..b440180 100644
>> --- a/drivers/iio/dac/ad5064.c
>> +++ b/drivers/iio/dac/ad5064.c
>> @@ -2,8 +2,8 @@
>> * AD5024, AD5025, AD5044, AD5045, AD5064, AD5064-1, AD5065, AD5625,
>> AD5625R,
>> * AD5627, AD5627R, AD5628, AD5629R, AD5645R, AD5647R, AD5648, AD5665,
>> AD5665R,
>> * AD5666, AD5667, AD5667R, AD5668, AD5669R, LTC2606, LTC2607, LTC2609,
>> LTC2616,
>> - * LTC2617, LTC2619, LTC2626, LTC2627, LTC2629 Digital to analog converters
>> - * driver
>> + * LTC2617, LTC2619, LTC2626, LTC2627, LTC2629, LTC2631, LTC2633, LTC2635
>> + * Digital to analog converters driver
>> *
>> * Copyright 2011 Analog Devices Inc.
>> *
>> @@ -168,6 +168,12 @@ enum ad5064_type {
>> ID_LTC2626,
>> ID_LTC2627,
>> ID_LTC2629,
>> +ID_LTC2631_L,
>> +ID_LTC2631_H,
>> +ID_LTC2633_L,
>> +ID_LTC2633_H,
>> +ID_LTC2635_L,
>> +ID_LTC2635_H,
>> };
>>
>> static int ad5064_write(struct ad5064_state *st, unsigned int cmd,
>> @@ -724,6 +730,48 @@ static int ad5064_write_raw(struct iio_dev *indio_dev,
>> .num_channels = 4,
>> .regmap_type = AD5064_REGMAP_LTC,
>> },
>> +[ID_LTC2631_L] = {
>> +.shared_vref = true,
>> +.internal_vref = 250,
>> +.channels = ltc2627_channels,
>> +.num_channels = 1,
>> +.regmap_type = AD5064_REGMAP_LTC,
>> +},
>> +[ID_LTC2631_H] = {
>> +.shared_vref = true,
>> +.internal_vref = 4096000,
>> +.channels = ltc2627_channels,
>> +.num_channels = 1,
>> +.regmap_type = AD5064_REGMAP_LTC,
>> +},
>> +[ID_LTC2633_L] = {
>> +.shared_vref = true,
>> +.internal_vref = 250,
>> +.channels = ltc2627_channels,
>> +.num_channels = 2,
>> +.regmap_type = AD5064_REGMAP_LTC,
>> +},
>> +[ID_LTC2633_H] = {
>> +.shared_vref = true,
>> +.internal_vref = 4096000,
>> +.channels = ltc2627_channels,
>> +.num_channels = 2,
>> +.regmap_type = AD5064_REGMAP_LTC,
>> +},
>> +[ID_LTC2635_L] = {
>> +.shared_vref = true,
>> +.internal_vref = 250,
>> +.channels = ltc2627_channels,
>> +.num_channels = 4,
>> +.regmap_type = AD5064_REGMAP_LTC,
>> +},
>> +[ID_LTC2635_H] = {
>> +.shared_vref = true,
>> +
Re: [RFC] tty: pty -- Add ability to setup next pty number for ptmx open
On Fri, Mar 17, 2017 at 1:56 PM, Cyrill Gorcunov wrote: > When we restore PTY terminals we do iterate over open() calls to reach > the index used at checkpoint time (say application opened a number of > terminals, then closed all other except last one) which of course very > inconvenient. > > The problem get more notable in scope of controlling terminal represented > by /dev/tty device: current CRIU restore scheme is lazy, we don't open > files immedeately after the forks but rather defer until the whole > process tree is created, then every process opens own files in async > way and in result /dev/tty is not propagated into children because > it is not yet opened. > Gentlemen, ping?
Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
Hey Dave, David Laight and I have been discussing offlist. It occurred to both of us that this could just be turned into a loop because perhaps this is actually just tail-recursive. Upon further inspection, however, the way the current algorithm works, it's possible that each of the fraglist skbs has its own fraglist, which would make this into tree recursion, which is why in the first place I wanted to place that limit on it. If that's the case, then the patch I proposed above is the best way forward. However, perhaps there's the chance that fraglist skbs having separate fraglists are actually forbidden? Is this the case? Are there other parts of the API that enforce this contract? Is it something we could safely rely on here? If you say yes, I'll send a v7 that makes this into a non-recursive loop. Regards, Jason
Re: 4.11.0-rc8+/x86_64 desktop lockup until applications closed
On Thu 27-04-17 18:36:38, Arthur Marsh wrote: [...] > [55363.482931] QXcbEventReader: page allocation stalls for 10048ms, order:0, > mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null) Are there more of these stalls? [...] > [55363.483040] Mem-Info: > [55363.483044] active_anon:1479559 inactive_anon:281161 isolated_anon:299 > active_file:49213 inactive_file:42134 isolated_file:0 > unevictable:4651 dirty:108 writeback:188 unstable:0 > slab_reclaimable:11225 slab_unreclaimable:20186 > mapped:204768 shmem:145888 pagetables:39859 bounce:0 > free:25470 free_pcp:0 free_cma:0 There is still quite some page cache to reclaim on the inactive list. So a progress should have been made. Maybe there was a peak memory consumption which holded this request back? [...] > [55363.483059] Node 0 DMA32 free:45556kB min:26948kB low:33684kB > high:40420kB active_anon:2273532kB inactive_anon:542768kB > active_file:99788kB inactive_file:89940kB unevictable:32kB > writepending:440kB present:3391168kB managed:3314260kB mlocked:32kB > slab_reclaimable:8800kB slab_unreclaimable:25976kB kernel_stack:7992kB > pagetables:68028kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > [55363.483063] lowmem_reserve[]: 0 0 4734 4734 This zone is not usable due to lowmem_reserve > [55363.483066] Node 0 Normal free:40420kB min:40500kB low:50624kB > high:60748kB active_anon:3644668kB inactive_anon:581672kB > active_file:97068kB inactive_file:78784kB unevictable:18572kB > writepending:0kB present:4980736kB managed:4848692kB mlocked:18572kB > slab_reclaimable:36100kB slab_unreclaimable:54768kB kernel_stack:13544kB > pagetables:91408kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > [55363.483069] lowmem_reserve[]: 0 0 0 0 and this one is below min watermark already. > [55363.483106] Free swap = 498568kB > [55363.483107] Total swap = 4194288kB Still ~10% of swap is free so not entirely bad. The question is whether this is reproducible. If yes then I would suggest watching /proc/vmstat (every second) and if this doesn't show anything then try to collect vmscan tracepoints $ mount -t tracefs none /debug/trace/ $ echo 1 > /debug/trace/events/vmscan/enable $ cat /debug/trace/trace_pipe > log -- Michal Hocko SUSE Labs
[PATCH 0/4] hwmon-NCT: Fine-tuning for four function implementations
From: Markus Elfring Date: Thu, 27 Apr 2017 11:18:22 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Use devm_kcalloc() in nct6683_create_attr_group() Adjust five checks for null pointers Use devm_kcalloc() in nct6775_create_attr_group() Adjust seven checks for null pointers drivers/hwmon/nct6683.c | 15 +++ drivers/hwmon/nct6775.c | 19 +-- 2 files changed, 16 insertions(+), 18 deletions(-) -- 2.12.2
[PATCH 1/4] hwmon-nct6683: Use devm_kcalloc() in nct6683_create_attr_group()
From: Markus Elfring Date: Thu, 27 Apr 2017 10:10:36 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "devm_kcalloc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/hwmon/nct6683.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c index 8b0bc4fc06e8..dd14a98cc6dd 100644 --- a/drivers/hwmon/nct6683.c +++ b/drivers/hwmon/nct6683.c @@ -426,13 +426,12 @@ nct6683_create_attr_group(struct device *dev, if (group == NULL) return ERR_PTR(-ENOMEM); - attrs = devm_kzalloc(dev, sizeof(*attrs) * (repeat * count + 1), + attrs = devm_kcalloc(dev, repeat * count + 1, sizeof(*attrs), GFP_KERNEL); if (attrs == NULL) return ERR_PTR(-ENOMEM); - su = devm_kzalloc(dev, sizeof(*su) * repeat * count, - GFP_KERNEL); + su = devm_kcalloc(dev, repeat * count, sizeof(*su), GFP_KERNEL); if (su == NULL) return ERR_PTR(-ENOMEM); -- 2.12.2
[PATCH 2/4] hwmon-nct6683: Adjust five checks for null pointers
From: Markus Elfring
Date: Thu, 27 Apr 2017 10:22:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written …
Thus fix the affected source code places.
Signed-off-by: Markus Elfring
---
drivers/hwmon/nct6683.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c
index dd14a98cc6dd..4deb46ce8834 100644
--- a/drivers/hwmon/nct6683.c
+++ b/drivers/hwmon/nct6683.c
@@ -423,16 +423,16 @@ nct6683_create_attr_group(struct device *dev,
return ERR_PTR(-EINVAL);
group = devm_kzalloc(dev, sizeof(*group), GFP_KERNEL);
- if (group == NULL)
+ if (!group)
return ERR_PTR(-ENOMEM);
attrs = devm_kcalloc(dev, repeat * count + 1, sizeof(*attrs),
GFP_KERNEL);
- if (attrs == NULL)
+ if (!attrs)
return ERR_PTR(-ENOMEM);
su = devm_kcalloc(dev, repeat * count, sizeof(*su), GFP_KERNEL);
- if (su == NULL)
+ if (!su)
return ERR_PTR(-ENOMEM);
group->attrs = attrs;
@@ -440,7 +440,7 @@ nct6683_create_attr_group(struct device *dev,
for (i = 0; i < repeat; i++) {
t = tg->templates;
- for (j = 0; *t != NULL; j++) {
+ for (j = 0; *t; j++) {
snprintf(su->name, sizeof(su->name),
(*t)->dev_attr.attr.name, tg->base + i);
if ((*t)->s2) {
@@ -1179,7 +1179,7 @@ static void nct6683_setup_sensors(struct nct6683_data
*data)
if (reg >= NUM_MON_LABELS)
continue;
/* Skip if disabled or reserved */
- if (nct6683_mon_label[reg] == NULL)
+ if (!nct6683_mon_label[reg])
continue;
if (reg < MON_VOLTAGE_START) {
data->temp_index[data->temp_num] = i;
--
2.12.2
[PATCH 3/4] hwmon-nct6775: Use devm_kcalloc() in nct6775_create_attr_group()
From: Markus Elfring Date: Thu, 27 Apr 2017 10:35:36 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "devm_kcalloc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/hwmon/nct6775.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c index 2458b406f6aa..d552ab7901a7 100644 --- a/drivers/hwmon/nct6775.c +++ b/drivers/hwmon/nct6775.c @@ -1073,13 +1073,12 @@ nct6775_create_attr_group(struct device *dev, if (group == NULL) return ERR_PTR(-ENOMEM); - attrs = devm_kzalloc(dev, sizeof(*attrs) * (repeat * count + 1), + attrs = devm_kcalloc(dev, repeat * count + 1, sizeof(*attrs), GFP_KERNEL); if (attrs == NULL) return ERR_PTR(-ENOMEM); - su = devm_kzalloc(dev, sizeof(*su) * repeat * count, - GFP_KERNEL); + su = devm_kcalloc(dev, repeat * count, sizeof(*su), GFP_KERNEL); if (su == NULL) return ERR_PTR(-ENOMEM); -- 2.12.2
[PATCH 4/4] hwmon-nct6775: Adjust seven checks for null pointers
From: Markus Elfring
Date: Thu, 27 Apr 2017 10:55:24 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written …
Thus fix the affected source code places.
Signed-off-by: Markus Elfring
---
drivers/hwmon/nct6775.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c
index d552ab7901a7..fe8713fb548c 100644
--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -1070,16 +1070,16 @@ nct6775_create_attr_group(struct device *dev,
return ERR_PTR(-EINVAL);
group = devm_kzalloc(dev, sizeof(*group), GFP_KERNEL);
- if (group == NULL)
+ if (!group)
return ERR_PTR(-ENOMEM);
attrs = devm_kcalloc(dev, repeat * count + 1, sizeof(*attrs),
GFP_KERNEL);
- if (attrs == NULL)
+ if (!attrs)
return ERR_PTR(-ENOMEM);
su = devm_kcalloc(dev, repeat * count, sizeof(*su), GFP_KERNEL);
- if (su == NULL)
+ if (!su)
return ERR_PTR(-ENOMEM);
group->attrs = attrs;
@@ -1087,7 +1087,7 @@ nct6775_create_attr_group(struct device *dev,
for (i = 0; i < repeat; i++) {
t = tg->templates;
- while (*t != NULL) {
+ while (*t) {
snprintf(su->name, sizeof(su->name),
(*t)->dev_attr.attr.name, tg->base + i);
if ((*t)->s2) {
@@ -3000,11 +3000,11 @@ static umode_t nct6775_pwm_is_visible(struct kobject
*kobj,
if ((nr >= 14 && nr <= 18) || nr == 21) /* weight */
if (!data->REG_WEIGHT_TEMP_SEL[pwm])
return 0;
- if (nr == 19 && data->REG_PWM[3] == NULL) /* pwm_max */
+ if (nr == 19 && !data->REG_PWM[3]) /* pwm_max */
return 0;
- if (nr == 20 && data->REG_PWM[4] == NULL) /* pwm_step */
+ if (nr == 20 && !data->REG_PWM[4]) /* pwm_step */
return 0;
- if (nr == 21 && data->REG_PWM[6] == NULL) /* weight_duty_base */
+ if (nr == 21 && !data->REG_PWM[6]) /* weight_duty_base */
return 0;
if (nr >= 22 && nr <= 35) { /* auto point */
--
2.12.2
Re: [PATCH] net: macb: fix phy interrupt parsing
Le 26/04/2017 à 12:06, Alexandre Belloni a écrit :
> Since 83a77e9ec415, the phydev irq is explicitly set to PHY_POLL when
> there is no pdata. It doesn't work on DT enabled platforms because the
> phydev irq is already set by libphy before.
>
> Fixes: 83a77e9ec415 ("net: macb: Added PCI wrapper for Platform Driver.")
Means 4.10+
> Signed-off-by: Alexandre Belloni
Acked-by: Nicolas Ferre
Seems a good candidate for net stable.
Bye,
> ---
> drivers/net/ethernet/cadence/macb.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index e131ecd17ab9..004223a866fe 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -432,15 +432,17 @@ static int macb_mii_probe(struct net_device *dev)
> }
>
> pdata = dev_get_platdata(&bp->pdev->dev);
> - if (pdata && gpio_is_valid(pdata->phy_irq_pin)) {
> - ret = devm_gpio_request(&bp->pdev->dev, pdata->phy_irq_pin,
> - "phy int");
> - if (!ret) {
> - phy_irq = gpio_to_irq(pdata->phy_irq_pin);
> - phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
> + if (pdata) {
> + if (gpio_is_valid(pdata->phy_irq_pin)) {
> + ret = devm_gpio_request(&bp->pdev->dev,
> + pdata->phy_irq_pin, "phy int");
> + if (!ret) {
> + phy_irq = gpio_to_irq(pdata->phy_irq_pin);
> + phydev->irq = (phy_irq < 0) ? PHY_POLL :
> phy_irq;
> + }
> + } else {
> + phydev->irq = PHY_POLL;
> }
> - } else {
> - phydev->irq = PHY_POLL;
> }
>
> /* attach the mac to the phy */
>
--
Nicolas Ferre
Re: [PATCH 1/7] mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at
On Mon, Apr 17, 2017 at 10:41:40PM +0530, Aneesh Kumar K.V wrote: > The right interface to use to set a hugetlb pte entry is set_huge_pte_at. Use > that instead of set_pte_at. > > Signed-off-by: Aneesh Kumar K.V Reviewed-by: Naoya Horiguchi
Re: [PATCH 2/7] mm/follow_page_mask: Split follow_page_mask to smaller functions.
On Mon, Apr 17, 2017 at 10:41:41PM +0530, Aneesh Kumar K.V wrote: > Makes code reading easy. No functional changes in this patch. In a followup > patch, we will be updating the follow_page_mask to handle hugetlb hugepd > format > so that archs like ppc64 can switch to the generic version. This split helps > in doing that nicely. > > Signed-off-by: Aneesh Kumar K.V Reviewed-by: Naoya Horiguchi
pull-request: wireless-drivers-next 2017-04-27
Hi Dave, here's a pull request for net-next, more info in the tag below. This should be the last pull request to net-next for 4.12. Please let me know if there are any problems. Kalle The following changes since commit 7acedaf5c4355f812cfef883ac28bf15f7d9205e: net: move xdp_prog field in RX cache lines (2017-04-25 16:25:36 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-04-27 for you to fetch changes up to 47d272f0f9887343f4e4d31bb22910b141b96654: Merge tag 'iwlwifi-next-for-kalle-2017-04-26' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2017-04-26 14:21:00 +0300) wireless-drivers-next patches for 4.12 Few remaining patches for 4.12 submitted during the last week. Major changes: iwlwifi * the firmware for 7265D and 3168 NICs is frozen at version 29 * more support for the upcoming A000 series Colin Ian King (1): orinoco: fix spelling mistake: "Registerred" -> "Registered" Dor Shaish (1): iwlwifi: mvm: freeze 7265D and 3168 on API version 29 Haim Dreyfuss (1): iwlwifi: mvm: Ignore wifi mcc update in the driver while associated James Hughes (2): brcmfmac: Ensure pointer correctly set if skb data location changes brcmfmac: Make skb header writable before use Johannes Berg (6): iwlwifi: mvm: make iwl_run_unified_mvm_ucode() static iwlwifi: mvm: avoid variable shadowing iwlwifi: pcie: remove superfluous trans->dev assignment iwlwifi: don't leak memory on allocation failure iwlwifi: remove module loading failure message iwlwifi: pcie: apply no-reclaim logic only to group 0 Kalle Valo (1): Merge tag 'iwlwifi-next-for-kalle-2017-04-26' of git://git.kernel.org/.../iwlwifi/iwlwifi-next Larry Finger (1): rtlwifi: rtl8821ae: setup 8812ae RFE according to device type Liad Kaufman (2): iwlwifi: pcie: support debug applying on a000 hw iwlwifi: gen2: support nmi triggering from host Maksim Salau (1): orinoco_usb: Fix buffer on stack Mordechai Goodstein (1): iwlwifi: mvm: scan: avoid "big" prints Pan Bian (3): mt7601u: check return value of alloc_skb libertas: check return value of alloc_workqueue rndis_wlan: add return value validation Sara Sharon (12): iwlwifi: mvm: support new rate flags iwlwifi: mvm: don't reserve queue in TVQM mode iwlwifi: mvm: map cab_queue to different txq_id iwlwifi: mvm: move internally to use bigger INVALID_TXQ iwlwifi: mvm: remove color definition iwlwifi: mvm: use defines instead of variables for shared dwell times iwlwifi: mvm: remove references to queue_info in new TX path iwlwifi: mvm: support station type API iwlwifi: move to 512 queues iwlwifi: rename wait_for_tx_queues_empty iwlwifi: mvm: memset binding before setting values iwlwifi: adjust NVM parsing APIs for new a000 method Sharon Dvir (2): iwlwifi: mvm: check if returned value is NULL iwlwifi: mvm: handle possible BIOS bug .../wireless/broadcom/brcm80211/brcmfmac/core.c| 23 +-- drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 2 +- drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 2 +- drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +- drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +- drivers/net/wireless/intel/iwlwifi/iwl-config.h| 2 +- drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 15 +- drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 2 + drivers/net/wireless/intel/iwlwifi/iwl-io.c| 3 + drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 32 ++- drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 16 +- drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 1 + drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 10 +- drivers/net/wireless/intel/iwlwifi/mvm/binding.c | 4 +- .../net/wireless/intel/iwlwifi/mvm/fw-api-mac.h| 5 +- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rs.h | 28 ++- .../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h| 38 ++-- drivers/net/wireless/intel/iwlwifi/mvm/fw.c| 161 --- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 11 +- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 37 ++-- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 10 +- drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 9 +- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 9 +- drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 11 +- drivers/net/wireless/intel/iwlwifi/mvm/rx.c| 4 +- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 +- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 86 +++- drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 229 +++
Re: [PATCH V2] cpuidle: check dev before usage in cpuidle_use_deepest_state
On Thu, 2017-04-27 at 01:47 +, Li, Fei wrote:
> In case of there is no cpuidle devices registered, dev will be null,
> and
> panic will be triggered like below;
> In this patch, add checking of dev before usage, like that done in
> cpuidle_idle_call.
>
> Panic without fix:
> [ 184.961328] BUG: unable to handle kernel NULL pointer dereference
> at
> (null)
> [ 184.961328] IP: cpuidle_use_deepest_state+0x30/0x60
> ...
> [ 184.961328] play_idle+0x8d/0x210
> [ 184.961328] ? __schedule+0x359/0x8e0
> [ 184.961328] ? _raw_spin_unlock_irqrestore+0x28/0x50
> [ 184.961328] ? kthread_queue_delayed_work+0x41/0x80
> [ 184.961328] clamp_idle_injection_func+0x64/0x1e0
FWIW:
Reviewed-by: Andy Shevchenko
P.S. V2 is mistakenly left from internal review AFAIU.
>
> Fixes: bb8313b603eb8 ("cpuidle: Allow enforcing deepest idle state
> selection")
> Signed-off-by: Li, Fei
> Tested-by: Shi, Feng
> ---
> drivers/cpuidle/cpuidle.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 548b90b..2706be7 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -111,7 +111,8 @@ void cpuidle_use_deepest_state(bool enable)
>
> preempt_disable();
> dev = cpuidle_get_device();
> - dev->use_deepest_state = enable;
> + if (dev)
> + dev->use_deepest_state = enable;
> preempt_enable();
> }
>
--
Andy Shevchenko
Intel Finland Oy
Re: [PATCH 3/7] mm/hugetlb: export hugetlb_entry_migration helper
On Mon, Apr 17, 2017 at 10:41:42PM +0530, Aneesh Kumar K.V wrote: > We will be using this later from the ppc64 code. Change the return type to > bool. > > Signed-off-by: Aneesh Kumar K.V Reviewed-by: Naoya Horiguchi
Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
On 26/04/17 14:55, Mark Brown wrote: > On Wed, Apr 26, 2017 at 10:02:39AM +0530, Rajendra Nayak wrote: >>> On 17/04/17 06:27, Viresh Kumar wrote: > > If we are looking this power-domains with performance as just some > *advanced regulators*, I don't like the complexity added. > >> + Mark > >> I don;t see any public discussions on why we ruled out using regulators to >> support this but maybe there were some offline discussions on this. > >> Mark, this is a long thread, so just summarizing here to give you the >> context. > >> At qualcomm, we have an external M3 core (running its own firmware) which >> controls >> a few voltage rails (including AVS on those). The devices vote for the >> voltage levels Thanks for explicitly mentioning this, but ... >> (or performance levels) they need by passing an integer value to the M3 (not >> actual you contradict here, is it just voltage or performance(i.e. frequency) or both ? We need clarity there to choose the right representation. >> voltage values). Since that didn't fit well with the existing regulator apis >> it was > > As I'm getting fed up of saying: if the values you are setting are not > voltages and do not behave like voltages then the hardware should not be > represented as a voltage regulator since if they are represented as > voltage regulators things will expect to be able to control them as > voltage regulators. This hardware is quite clearly providing OPPs > directly, I would expect this to be handled in the OPP code somehow. I agree with you that we need to be absolutely sure on what it actually represents. But as more and more platform are pushing such power controls to dedicated M3 or similar processors, we need abstraction. Though we are controlling hardware, we do so indirectly. Since there were discussions around device tree representing hardware vs platform, I tend to think, we are moving towards platform(something similar to ACPI). -- Regards, Sudeep
Linux 4.10.13
I'm announcing the release of the 4.10.13 kernel. All users of the 4.10 kernel series must upgrade. The updated 4.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/powerpc/kernel/entry_64.S|6 +- arch/s390/include/asm/pgtable.h |2 arch/x86/kernel/cpu/mcheck/mce-genpool.c |2 arch/x86/kernel/cpu/mcheck/mce-internal.h |2 arch/x86/kernel/cpu/mcheck/mce.c | 17 + arch/x86/kernel/cpu/mcheck/mce_amd.c |2 drivers/acpi/power.c |1 drivers/dax/Kconfig |1 drivers/dax/dax.c | 13 ++-- drivers/hid/wacom_wac.c |2 drivers/input/mouse/elantech.c|8 ++ drivers/mmc/host/dw_mmc.c | 23 +--- drivers/mmc/host/sdhci-esdhc-imx.c|1 drivers/mtd/ubi/upd.c |8 +- fs/cifs/cifsglob.h|1 fs/cifs/smb1ops.c | 10 +++ fs/cifs/smb2pdu.c |5 - fs/ubifs/dir.c| 10 ++- kernel/trace/ring_buffer.c| 16 - kernel/trace/trace.c |8 +- mm/migrate.c |2 net/mac80211/rx.c | 86 +++--- security/keys/gc.c|2 security/keys/keyctl.c| 20 +++--- security/keys/process_keys.c | 44 +-- 26 files changed, 195 insertions(+), 99 deletions(-) Arnd Bergmann (1): ACPI / power: Avoid maybe-uninitialized warning Christian Borntraeger (1): s390/mm: fix CMMA vs KSM vs others Dan Williams (1): device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation David Howells (2): KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings KEYS: Change the name of the dead type to ".dead" to prevent user access Douglas Anderson (1): mmc: dw_mmc: Don't allow Runtime PM for SDIO cards Eric Biggers (1): KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings Felix Fietkau (1): ubifs: Fix RENAME_WHITEOUT support Germano Percossi (1): CIFS: remove bad_network_name flag Greg Kroah-Hartman (1): Linux 4.10.13 Haibo Chen (1): mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card Jason Gerecke (1): HID: wacom: Treat HID_DG_TOOLSERIALNUMBER as unsigned Johannes Berg (2): mac80211: reject ToDS broadcast data frames mac80211: fix MU-MIMO follow-MAC mode Rabin Vincent (1): mm: prevent NR_ISOLATE_* stats from going negative Ravi Bangoria (1): powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction Richard Weinberger (1): ubifs: Fix O_TMPFILE corner case in ubifs_link() Sachin Prabhu (1): cifs: Do not send echoes before Negotiate is complete Sebastian Siewior (1): ubi/upd: Always flush after prepared for an update Shawn Lin (1): mmc: dw_mmc: silent verbose log when calling from PM context Steven Rostedt (VMware) (2): tracing: Allocate the snapshot buffer before enabling probe ring-buffer: Have ring_buffer_iter_empty() return true when empty Thorsten Leemhuis (1): Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled Vishal Verma (1): x86/mce: Make the MCE notifier a blocking one Yazen Ghannam (1): x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs signature.asc Description: PGP signature
Re: Linux 4.10.13
diff --git a/Makefile b/Makefile
index 9689d3f644ea..8285f4de02d1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 10
-SUBLEVEL = 12
+SUBLEVEL = 13
EXTRAVERSION =
NAME = Fearless Coyote
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 6432d4bf08c8..767ef6d68c9e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -689,7 +689,7 @@ resume_kernel:
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
- lwz r3,GPR1(r1)
+ ld r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception
frame */
mr r4,r1 /* src: current exception frame */
mr r1,r3 /* Reroute the trampoline frame to r1 */
@@ -703,8 +703,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
- /* Do real store operation to complete stwu */
- lwz r5,GPR1(r1)
+ /* Do real store operation to complete stdu */
+ ld r5,GPR1(r1)
std r8,0(r5)
/* Clear _TIF_EMULATE_STACK_STORE flag */
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 0362cd5fa187..0cea7026e4ff 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1029,6 +1029,8 @@ int get_guest_storage_key(struct mm_struct *mm, unsigned
long addr,
static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t entry)
{
+ if (pte_present(entry))
+ pte_val(entry) &= ~_PAGE_UNUSED;
if (mm_has_pgste(mm))
ptep_set_pte_at(mm, addr, ptep, entry);
else
diff --git a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
index 93d824ec3120..040af1939460 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
@@ -85,7 +85,7 @@ void mce_gen_pool_process(void)
head = llist_reverse_order(head);
llist_for_each_entry_safe(node, tmp, head, llnode) {
mce = &node->mce;
- atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
+ blocking_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node));
}
}
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index cd74a3f00aea..de20902ecf23 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -13,7 +13,7 @@ enum severity_level {
MCE_PANIC_SEVERITY,
};
-extern struct atomic_notifier_head x86_mce_decoder_chain;
+extern struct blocking_notifier_head x86_mce_decoder_chain;
#define ATTR_LEN 16
#define INITIAL_CHECK_INTERVAL 5 * 60 /* 5 minutes */
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 036fc03aefbd..fcf8b8d6ebfb 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -123,7 +123,7 @@ static void (*quirk_no_way_out)(int bank, struct mce *m,
struct pt_regs *regs);
* CPU/chipset specific EDAC code can register a notifier call here to print
* MCE errors in a human-readable form.
*/
-ATOMIC_NOTIFIER_HEAD(x86_mce_decoder_chain);
+BLOCKING_NOTIFIER_HEAD(x86_mce_decoder_chain);
/* Do initial initialization of a struct mce */
void mce_setup(struct mce *m)
@@ -223,7 +223,7 @@ void mce_register_decode_chain(struct notifier_block *nb)
if (nb != &mce_srao_nb && nb->priority == INT_MAX)
nb->priority -= 1;
- atomic_notifier_chain_register(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_register(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_register_decode_chain);
@@ -231,7 +231,7 @@ void mce_unregister_decode_chain(struct notifier_block *nb)
{
atomic_dec(&num_notifiers);
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_unregister_decode_chain);
@@ -324,18 +324,7 @@ static void __print_mce(struct mce *m)
static void print_mce(struct mce *m)
{
- int ret = 0;
-
__print_mce(m);
-
- /*
-* Print out human-readable details about the MCE error,
-* (if the CPU has an implementation for that)
-*/
- ret = atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, m);
- if (ret == NOTIFY_STOP)
- return;
-
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog --ascii'\n");
}
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index a5fd137417a2..b44a25d77a84 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -60,7 +60,7 @@ static const char * const th_nam
Re: Linux 4.9.25
diff --git a/Makefile b/Makefile
index 50436f502d81..8e18c63388c4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 24
+SUBLEVEL = 25
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 6432d4bf08c8..767ef6d68c9e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -689,7 +689,7 @@ resume_kernel:
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
- lwz r3,GPR1(r1)
+ ld r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception
frame */
mr r4,r1 /* src: current exception frame */
mr r1,r3 /* Reroute the trampoline frame to r1 */
@@ -703,8 +703,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
- /* Do real store operation to complete stwu */
- lwz r5,GPR1(r1)
+ /* Do real store operation to complete stdu */
+ ld r5,GPR1(r1)
std r8,0(r5)
/* Clear _TIF_EMULATE_STACK_STORE flag */
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 0362cd5fa187..0cea7026e4ff 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1029,6 +1029,8 @@ int get_guest_storage_key(struct mm_struct *mm, unsigned
long addr,
static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t entry)
{
+ if (pte_present(entry))
+ pte_val(entry) &= ~_PAGE_UNUSED;
if (mm_has_pgste(mm))
ptep_set_pte_at(mm, addr, ptep, entry);
else
diff --git a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
index 93d824ec3120..040af1939460 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
@@ -85,7 +85,7 @@ void mce_gen_pool_process(void)
head = llist_reverse_order(head);
llist_for_each_entry_safe(node, tmp, head, llnode) {
mce = &node->mce;
- atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
+ blocking_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node));
}
}
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index cd74a3f00aea..de20902ecf23 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -13,7 +13,7 @@ enum severity_level {
MCE_PANIC_SEVERITY,
};
-extern struct atomic_notifier_head x86_mce_decoder_chain;
+extern struct blocking_notifier_head x86_mce_decoder_chain;
#define ATTR_LEN 16
#define INITIAL_CHECK_INTERVAL 5 * 60 /* 5 minutes */
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index a7fdf453d895..22cda29d654e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -120,7 +120,7 @@ static void (*quirk_no_way_out)(int bank, struct mce *m,
struct pt_regs *regs);
* CPU/chipset specific EDAC code can register a notifier call here to print
* MCE errors in a human-readable form.
*/
-ATOMIC_NOTIFIER_HEAD(x86_mce_decoder_chain);
+BLOCKING_NOTIFIER_HEAD(x86_mce_decoder_chain);
/* Do initial initialization of a struct mce */
void mce_setup(struct mce *m)
@@ -213,13 +213,13 @@ void mce_register_decode_chain(struct notifier_block *nb)
if (nb != &mce_srao_nb && nb->priority == INT_MAX)
nb->priority -= 1;
- atomic_notifier_chain_register(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_register(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_register_decode_chain);
void mce_unregister_decode_chain(struct notifier_block *nb)
{
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_unregister_decode_chain);
@@ -272,8 +272,6 @@ struct mca_msr_regs msr_ops = {
static void print_mce(struct mce *m)
{
- int ret = 0;
-
pr_emerg(HW_ERR "CPU %d: Machine Check Exception: %Lx Bank %d:
%016Lx\n",
m->extcpu, m->mcgstatus, m->bank, m->status);
@@ -309,14 +307,6 @@ static void print_mce(struct mce *m)
m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid,
cpu_data(m->extcpu).microcode);
- /*
-* Print out human-readable details about the MCE error,
-* (if the CPU has an implementation for that)
-*/
- ret = atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, m);
- if (ret == NOTIFY_STOP)
- return;
-
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog --ascii'\n");
}
diff --git a/arch/x86/kernel/c
Linux 4.9.25
I'm announcing the release of the 4.9.25 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/powerpc/kernel/entry_64.S|6 +- arch/s390/include/asm/pgtable.h |2 arch/x86/kernel/cpu/mcheck/mce-genpool.c |2 arch/x86/kernel/cpu/mcheck/mce-internal.h |2 arch/x86/kernel/cpu/mcheck/mce.c | 16 + arch/x86/kernel/cpu/mcheck/mce_amd.c |2 drivers/acpi/power.c |1 drivers/dax/Kconfig |1 drivers/dax/dax.c | 13 ++-- drivers/input/mouse/elantech.c|8 ++ drivers/mmc/host/sdhci-esdhc-imx.c|1 drivers/mtd/ubi/upd.c |8 +- fs/cifs/cifsglob.h|1 fs/cifs/smb1ops.c | 10 +++ fs/cifs/smb2pdu.c |5 - fs/ubifs/dir.c| 10 ++- kernel/trace/ring_buffer.c| 16 - kernel/trace/trace.c |8 +- mm/migrate.c |2 net/mac80211/rx.c | 86 +++--- security/keys/gc.c|2 security/keys/keyctl.c| 20 +++--- security/keys/process_keys.c | 44 +-- 24 files changed, 178 insertions(+), 90 deletions(-) Arnd Bergmann (1): ACPI / power: Avoid maybe-uninitialized warning Christian Borntraeger (1): s390/mm: fix CMMA vs KSM vs others Dan Williams (1): device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation David Howells (2): KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings KEYS: Change the name of the dead type to ".dead" to prevent user access Eric Biggers (1): KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings Felix Fietkau (1): ubifs: Fix RENAME_WHITEOUT support Germano Percossi (1): CIFS: remove bad_network_name flag Greg Kroah-Hartman (1): Linux 4.9.25 Haibo Chen (1): mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card Johannes Berg (2): mac80211: reject ToDS broadcast data frames mac80211: fix MU-MIMO follow-MAC mode Rabin Vincent (1): mm: prevent NR_ISOLATE_* stats from going negative Ravi Bangoria (1): powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction Richard Weinberger (1): ubifs: Fix O_TMPFILE corner case in ubifs_link() Sachin Prabhu (1): cifs: Do not send echoes before Negotiate is complete Sebastian Siewior (1): ubi/upd: Always flush after prepared for an update Steven Rostedt (VMware) (2): tracing: Allocate the snapshot buffer before enabling probe ring-buffer: Have ring_buffer_iter_empty() return true when empty Thorsten Leemhuis (1): Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled Vishal Verma (1): x86/mce: Make the MCE notifier a blocking one Yazen Ghannam (1): x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs signature.asc Description: PGP signature
Linux 4.4.64
I'm announcing the release of the 4.4.64 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/kvm/mmu.c | 12 +++ arch/powerpc/kernel/entry_64.S |6 - arch/s390/include/asm/pgtable.h |2 arch/x86/include/asm/pmem.h | 45 --- arch/x86/kernel/cpu/mcheck/mce_amd.c |2 block/genhd.c|1 drivers/acpi/power.c |1 drivers/hv/channel.c | 16 ++-- drivers/hv/connection.c |8 +- drivers/hv/hv.c |5 - drivers/hv/hv_balloon.c | 136 +-- drivers/input/mouse/elantech.c |8 ++ drivers/mmc/host/sdhci-esdhc-imx.c |1 drivers/mtd/ubi/upd.c|8 +- fs/cifs/cifsglob.h |1 fs/cifs/smb1ops.c| 10 ++ fs/cifs/smb2pdu.c|5 - kernel/trace/ring_buffer.c | 16 +++- kernel/trace/trace.c |8 +- net/mac80211/rx.c| 21 + net/tipc/node.c | 24 ++ net/vmw_vsock/vmci_transport.c |4 - security/keys/gc.c |2 security/keys/keyctl.c | 20 ++--- security/keys/process_keys.c | 44 ++- tools/hv/hv_kvp_daemon.c |2 27 files changed, 282 insertions(+), 128 deletions(-) Arnd Bergmann (1): ACPI / power: Avoid maybe-uninitialized warning Christian Borntraeger (1): s390/mm: fix CMMA vs KSM vs others Dan Williams (2): x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions block: fix del_gendisk() vs blkdev_ioctl crash David Howells (2): KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings KEYS: Change the name of the dead type to ".dead" to prevent user access Eric Biggers (1): KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings Germano Percossi (1): CIFS: remove bad_network_name flag Greg Kroah-Hartman (1): Linux 4.4.64 Haibo Chen (1): mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card Johannes Berg (1): mac80211: reject ToDS broadcast data frames Jon Paul Maloy (1): tipc: fix crash during node removal Jorgen Hansen (1): VSOCK: Detach QP check should filter out non matching QPs. K. Y. Srinivasan (1): Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg() Ravi Bangoria (1): powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction Sachin Prabhu (1): cifs: Do not send echoes before Negotiate is complete Sebastian Siewior (1): ubi/upd: Always flush after prepared for an update Steven Rostedt (VMware) (2): tracing: Allocate the snapshot buffer before enabling probe ring-buffer: Have ring_buffer_iter_empty() return true when empty Suzuki K Poulose (1): kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd Thorsten Leemhuis (1): Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled Vitaly Kuznetsov (6): Drivers: hv: don't leak memory in vmbus_establish_gpadl() Drivers: hv: get rid of timeout in vmbus_open() Tools: hv: kvp: ensure kvp device fd is closed on exec Drivers: hv: balloon: keep track of where ha_region starts Drivers: hv: balloon: account for gaps in hot add regions hv: don't reset hv_context.tsc_page on crash Yazen Ghannam (1): x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs signature.asc Description: PGP signature
Re: Linux 4.4.64
diff --git a/Makefile b/Makefile
index ec52973043f6..17708f5dc169 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 63
+SUBLEVEL = 64
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index f91ee2f27b41..01cf10556081 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -300,6 +300,14 @@ static void unmap_range(struct kvm *kvm, pgd_t *pgdp,
next = kvm_pgd_addr_end(addr, end);
if (!pgd_none(*pgd))
unmap_puds(kvm, pgd, addr, next);
+ /*
+* If we are dealing with a large range in
+* stage2 table, release the kvm->mmu_lock
+* to prevent starvation and lockup detector
+* warnings.
+*/
+ if (kvm && (next != end))
+ cond_resched_lock(&kvm->mmu_lock);
} while (pgd++, addr = next, addr != end);
}
@@ -738,6 +746,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
*/
static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
{
+ assert_spin_locked(&kvm->mmu_lock);
unmap_range(kvm, kvm->arch.pgd, start, size);
}
@@ -824,7 +833,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
if (kvm->arch.pgd == NULL)
return;
+ spin_lock(&kvm->mmu_lock);
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ spin_unlock(&kvm->mmu_lock);
+
kvm_free_hwpgd(kvm_get_hwpgd(kvm));
if (KVM_PREALLOC_LEVEL > 0)
kfree(kvm->arch.pgd);
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index edba294620db..f6fd0332c3a2 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -716,7 +716,7 @@ resume_kernel:
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
- lwz r3,GPR1(r1)
+ ld r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception
frame */
mr r4,r1 /* src: current exception frame */
mr r1,r3 /* Reroute the trampoline frame to r1 */
@@ -730,8 +730,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
- /* Do real store operation to complete stwu */
- lwz r5,GPR1(r1)
+ /* Do real store operation to complete stdu */
+ ld r5,GPR1(r1)
std r8,0(r5)
/* Clear _TIF_EMULATE_STACK_STORE flag */
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 024f85f947ae..e2c0e4eab037 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -829,6 +829,8 @@ static inline void set_pte_at(struct mm_struct *mm,
unsigned long addr,
{
pgste_t pgste;
+ if (pte_present(entry))
+ pte_val(entry) &= ~_PAGE_UNUSED;
if (mm_has_pgste(mm)) {
pgste = pgste_get_lock(ptep);
pgste_val(pgste) &= ~_PGSTE_GPS_ZERO;
diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
index d8ce3ec816ab..bd8ce6bcdfc9 100644
--- a/arch/x86/include/asm/pmem.h
+++ b/arch/x86/include/asm/pmem.h
@@ -72,8 +72,8 @@ static inline void arch_wmb_pmem(void)
* @size: number of bytes to write back
*
* Write back a cache range using the CLWB (cache line write back)
- * instruction. This function requires explicit ordering with an
- * arch_wmb_pmem() call. This API is internal to the x86 PMEM implementation.
+ * instruction. Note that @size is internally rounded up to be cache
+ * line size aligned.
*/
static inline void __arch_wb_cache_pmem(void *vaddr, size_t size)
{
@@ -87,15 +87,6 @@ static inline void __arch_wb_cache_pmem(void *vaddr, size_t
size)
clwb(p);
}
-/*
- * copy_from_iter_nocache() on x86 only uses non-temporal stores for iovec
- * iterators, so for other types (bvec & kvec) we must do a cache write-back.
- */
-static inline bool __iter_needs_pmem_wb(struct iov_iter *i)
-{
- return iter_is_iovec(i) == false;
-}
-
/**
* arch_copy_from_iter_pmem - copy data from an iterator to PMEM
* @addr: PMEM destination address
@@ -114,8 +105,36 @@ static inline size_t arch_copy_from_iter_pmem(void __pmem
*addr, size_t bytes,
/* TODO: skip the write-back by always using non-temporal stores */
len = copy_from_iter_nocache(vaddr, bytes, i);
- if (__iter_needs_pmem_wb(i))
- __arch_wb_cache_pmem(vaddr, bytes);
+ /*
+* In the iovec case on x86_64 copy_from_iter_nocache() uses
+* non-temporal stores for the bulk of the transfer, but we need
+* to manually flush if the transfer is unaligned. A cached
+* memory copy is used when destination or size is not naturally
+* aligned. That is:
+* - Require 8-byte alignment when size is 8 bytes or larger.
+* - Require 4-byte alignment
Re: [stable 3.18 PATCH] clk: at91: usb: fix determine_rate prototype again
On Fri, Apr 21, 2017 at 02:45:23PM +0200, Arnd Bergmann wrote:
> We had an incorrect backport of
> 4591243102fa ("clk: at91: usb: propagate rate modification to the parent clk")
> that was fixed incorrectly in linux-3.18.y by
> 76723e7ed589 ("clk: at91: usb: fix determine_rate prototype")
>
> as shown by this warning:
>
> drivers/clk/at91/clk-usb.c:155:20: warning: initialization from incompatible
> pointer type [-Wincompatible-pointer-types]
> drivers/clk/at91/clk-usb.c:193:20: warning: initialization from incompatible
> pointer type [-Wincompatible-pointer-types]
>
> This should fix it properly.
>
> Cc: Boris Brezillon
> Signed-off-by: Arnd Bergmann
> ---
> This should be applied to 3.18.y directly
Thanks for this, now applied.
greg k-h
Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
Hi Jacopo,
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
wrote:
> Add pin configuration subnode for ETHER ethernet controller.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
> --- a/arch/arm/boot/dts/r7s72100-genmai.dts
> +++ b/arch/arm/boot/dts/r7s72100-genmai.dts
> @@ -77,6 +105,19 @@
> status = "okay";
> };
>
> +ðer {
> + pinctrl-names = "default";
> + pinctrl-0 = <ðer_pins>;
> +
> + status = "okay";
> +
> + renesas,no-ether-link;
> + phy-handle = <&phy0>;
> + phy0: ethernet-phy@0 {
> + reg = <0>;
Shouldn't the interrupt (connected to P1_15) be described?
> + };
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH, 3.18-stable regression] gadgetfs: fix uninitialized variable in error handling
On Fri, Apr 21, 2017 at 03:06:12PM +0200, Arnd Bergmann wrote:
> gcc warns about a bug in 3.18.y:
>
> drivers/usb/gadget/legacy/inode.c:648:10: warning: 'value' may be used
>
> This is caused by the backport of f01d35a15fa0416 from 4.0 to 3.18:
> c81fc59be42c6e0 gadgetfs: use-after-free in ->aio_read()
>
> The backported patch was buggy, but the mainline code was rewritten
> in a larger patch directly following this one in a way that fixed the
> bug.
>
> For stable, we should need only a one-line change to make sure we
> return an proper error code. It is very unlikely that anybody ever
> ran into the out-of-memory case here in practice, but the compiler
> is right in theory.
>
> Fixes: c81fc59be42c ("gadgetfs: use-after-free in ->aio_read()")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/usb/gadget/legacy/inode.c | 1 +
> 1 file changed, 1 insertion(+)
Now queued up, thanks!
greg k-h
