Re: [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory
On Wed 26-07-17 17:06:59, Jerome Glisse wrote: [...] > This does not seems to be an opt-in change ie if i am reading patch 3 > correctly if an altmap is not provided to __add_pages() you fallback > to allocating from begining of zone. This will not work with HMM ie > device private memory. So at very least i would like to see some way > to opt-out of this. Maybe a new argument like bool forbid_altmap ? OK, I see! I will think about how to make a sane api for that. Thanks! -- Michal Hocko SUSE Labs
Re: [PATCH] mm: take memory hotplug lock within numa_zonelist_order_handler()
On Wed 26-07-17 15:25:03, Andrew Morton wrote:
> On Wed, 26 Jul 2017 14:19:52 +0200 Michal Hocko wrote:
>
> > > > Please note that this code has been removed by
> > > > http://lkml.kernel.org/r/20170721143915.14161-2-mho...@kernel.org. It
> > > > will get to linux-next as soon as Andrew releases a new version mmotm
> > > > tree.
> > >
> > > We still would need something for 4.13, no?
> >
> > If this presents a real problem then yes. Has this happened in a real
> > workload or during some artificial test? I mean the code has been like
> > that for ages and nobody noticed/reported any problems.
> >
> > That being said, I do not have anything against your patch. It is
> > trivial to rebase mine on top of yours. I am just not sure it is worth
> > the code churn. E.g. do you think this patch is a stable backport
> > material?
>
> As I understand it, Heiko's patch fixes 4.13-rc1's 3f906ba23689a
> ("mm/memory-hotplug: switch locking to a percpu rwsem") (and should
> have been tagged as such!). So no -stable backport is needed - we just
> need to get 4.13.x fixed.
>
> So I grabbed this for Linusing this week or next, and fixed up your
> for-4.14 patch thusly:
OK. Feel free to add
Acked-by: Michal Hocko
And thanks for the rebase which looks correct.
> From: Michal Hocko
> Subject: mm, page_alloc: rip out ZONELIST_ORDER_ZONE
>
> Patch series "cleanup zonelists initialization", v1.
>
> This is aimed at cleaning up the zonelists initialization code we have
> but the primary motivation was bug report [2] which got resolved but
> the usage of stop_machine is just too ugly to live. Most patches are
> straightforward but 3 of them need a special consideration.
>
> Patch 1 removes zone ordered zonelists completely. I am CCing linux-api
> because this is a user visible change. As I argue in the patch
> description I do not think we have a strong usecase for it these days.
> I have kept sysctl in place and warn into the log if somebody tries to
> configure zone lists ordering. If somebody has a real usecase for it
> we can revert this patch but I do not expect anybody will actually notice
> runtime differences. This patch is not strictly needed for the rest but
> it made patch 6 easier to implement.
>
> Patch 7 removes stop_machine from build_all_zonelists without adding any
> special synchronization between iterators and updater which I _believe_
> is acceptable as explained in the changelog. I hope I am not missing
> anything.
>
> Patch 8 then removes zonelists_mutex which is kind of ugly as well and
> not really needed AFAICS but a care should be taken when double checking
> my thinking.
>
>
> This patch (of 9):
>
> Supporting zone ordered zonelists costs us just a lot of code while the
> usefulness is arguable if existent at all. Mel has already made node
> ordering default on 64b systems. 32b systems are still using
> ZONELIST_ORDER_ZONE because it is considered better to fallback to a
> different NUMA node rather than consume precious lowmem zones.
>
> This argument is, however, weaken by the fact that the memory reclaim has
> been reworked to be node rather than zone oriented. This means that
> lowmem requests have to skip over all highmem pages on LRUs already and so
> zone ordering doesn't save the reclaim time much. So the only advantage
> of the zone ordering is under a light memory pressure when highmem
> requests do not ever hit into lowmem zones and the lowmem pressure doesn't
> need to reclaim.
>
> Considering that 32b NUMA systems are rather suboptimal already and it is
> generally advisable to use 64b kernel on such a HW I believe we should
> rather care about the code maintainability and just get rid of
> ZONELIST_ORDER_ZONE altogether. Keep systcl in place and warn if somebody
> tries to set zone ordering either from kernel command line or the sysctl.
>
> Link: http://lkml.kernel.org/r/20170721143915.14161-2-mho...@kernel.org
> Signed-off-by: Michal Hocko
> Acked-by: Mel Gorman
> Acked-by: Vlastimil Babka
> Cc: Johannes Weiner
> Cc: Joonsoo Kim
> Cc: Shaohua Li
> Cc: Toshi Kani
> Cc:
> Signed-off-by: Andrew Morton
> ---
>
> Documentation/admin-guide/kernel-parameters.txt |2
> Documentation/sysctl/vm.txt |4
> Documentation/vm/numa |7
> include/linux/mmzone.h |2
> kernel/sysctl.c |2
> mm/page_alloc.c | 183 +-
> 6 files changed, 30 insertions(+), 170 deletions(-)
>
> diff -puN
> Documentation/admin-guide/kernel-parameters.txt~mm-page_alloc-rip-out-zonelist_order_zone
> Documentation/admin-guide/kernel-parameters.txt
> ---
> a/Documentation/admin-guide/kernel-parameters.txt~mm-page_alloc-rip-out-zonelist_order_zone
> +++ a/Documentation/admin-guide/kernel-parameters.txt
> @@ -2769,7 +2769,7 @@
> Allowed values are enable and disable
>
> numa_zonelist_order= [KNL
Re: [RFC PATCH] mm: memcg: fix css double put in mem_cgroup_iter
On Thu 27-07-17 11:30:50, Wenwei Tao wrote:
> 2017-07-26 21:44 GMT+08:00 Michal Hocko :
> > On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
[...]
> >> I think there is a css double put in mem_cgroup_iter. Under reclaim,
> >> we call mem_cgroup_iter the first time with prev == NULL, and we get
> >> last_visited memcg from per zone's reclaim_iter then call
> >> __mem_cgroup_iter_next
> >> try to get next alive memcg, __mem_cgroup_iter_next could return NULL
> >> if last_visited is already the last one so we put the last_visited's
> >> memcg css and continue to the next while loop, this time we might not
> >> do css_tryget(&last_visited->css) if the dead_count is changed, but
> >> we still do css_put(&last_visited->css), we put it twice, this could
> >> trigger the BUG_ON at kernel/cgroup.c:893.
> >
> > Yes, I guess your are right and I suspect that this has been silently
> > fixed by 519ebea3bf6d ("mm: memcontrol: factor out reclaim iterator
> > loading and updating"). I think a more appropriate fix is would be.
> > Are you able to reproduce and re-test it?
> > ---
>
> Yes, I think this commit can fix this issue, and I backport this
> commit to 3.10.107 kernel and cannot reproduce this issue. I guess
> this commit might need to be backported to 3.10.y stable kernel.
Please send it to the kernel-stable mailing list. 3.10 seems to be still
maintained.
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 1/5] arm64: tegra: Add BPMP thermal sensor to Tegra186
Good point, so patches 1/5 and 2/5 should be swapped around. Mikko On 27.07.2017 09:47, kbuild test robot wrote: Hi Mikko, [auto build test ERROR on tegra/for-next] [also build test ERROR on v4.13-rc2 next-20170726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mikko-Perttunen/arm64-tegra-Add-BPMP-thermal-sensor-to-Tegra186/20170726-055759 base: https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 Note: the linux-review/Mikko-Perttunen/arm64-tegra-Add-BPMP-thermal-sensor-to-Tegra186/20170726-055759 HEAD 2aebe2225f7f5f03abf6098e07387fa011ec16a8 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): In file included from arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi:1:0, from arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts:5: arch/arm64/boot/dts/nvidia/tegra186.dtsi:7:55: fatal error: dt-bindings/thermal/tegra186-bpmp-thermal.h: No such file or directory #include ^ compilation terminated. vim +7 arch/arm64/boot/dts/nvidia/tegra186.dtsi > 7 #include 8 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] ARM: dts: rockchip: add spdif for rk322x SoCs
This patch add the spdif dt node for rk322x SoCs.
Signed-off-by: Sugar Zhang
---
arch/arm/boot/dts/rk322x.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index f3e4ffd..b3b80e1 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -196,6 +196,20 @@
status = "disabled";
};
+ spdif: spdif@100d {
+ compatible = "rockchip,rk3228-spdif";
+ reg = <0x100d 0x1000>;
+ interrupts = ;
+ clocks = <&cru SCLK_SPDIF>, <&cru HCLK_SPDIF_8CH>;
+ clock-names = "mclk", "hclk";
+ dmas = <&pdma 10>;
+ #dma-cells = <1>;
+ dma-names = "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_tx>;
+ status = "disabled";
+ };
+
i2s2: i2s2@100e {
compatible = "rockchip,rk3228-i2s", "rockchip,rk3066-i2s";
reg = <0x100e 0x4000>;
@@ -835,6 +849,12 @@
};
};
+ spdif {
+ spdif_tx: spdif-tx {
+ rockchip,pins = <3 31 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+
tsadc {
otp_gpio: otp-gpio {
rockchip,pins = <0 24 RK_FUNC_GPIO
&pcfg_pull_none>;
--
2.7.4
Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap
On Wed 26-07-17 18:29:12, Andrea Arcangeli wrote:
> On Wed, Jul 26, 2017 at 07:45:57AM +0200, Michal Hocko wrote:
> > On Tue 25-07-17 21:19:52, Andrea Arcangeli wrote:
> > > On Tue, Jul 25, 2017 at 06:04:00PM +0200, Michal Hocko wrote:
> > > > - down_write(&mm->mmap_sem);
> > > > + if (tsk_is_oom_victim(current))
> > > > + down_write(&mm->mmap_sem);
> > > > free_pgtables(&tlb, vma, FIRST_USER_ADDRESS,
> > > > USER_PGTABLES_CEILING);
> > > > tlb_finish_mmu(&tlb, 0, -1);
> > > >
> > > > @@ -3012,7 +3014,8 @@ void exit_mmap(struct mm_struct *mm)
> > > > }
> > > > mm->mmap = NULL;
> > > > vm_unacct_memory(nr_accounted);
> > > > - up_write(&mm->mmap_sem);
> > > > + if (tsk_is_oom_victim(current))
> > > > + up_write(&mm->mmap_sem);
> > >
> > > How is this possibly safe? mark_oom_victim can run while exit_mmap is
> > > running.
> >
> > I believe it cannot. We always call mark_oom_victim (on !current) with
> > task_lock held and check task->mm != NULL and we call do_exit->mmput after
> > mm is set to NULL under the same lock.
>
> Holding the mmap_sem for writing and setting mm->mmap to NULL to
> filter which tasks already released the mmap_sem for writing post
> free_pgtables still look unnecessary to solve this.
>
> Using MMF_OOM_SKIP as flag had side effects of oom_badness() skipping
> it, but we can use the same tsk_is_oom_victim instead and relay on the
> locking in mark_oom_victim you pointed out above instead of the
> test_and_set_bit of my patch, because current->mm is already NULL at
> that point.
>
> A race at the light of the above now is, because current->mm is NULL by the
> time mmput is called, how can you start the oom_reap_task on a process
> with current->mm NULL that called the last mmput and is blocked
> in exit_aio?
Because we have that mm available. See tsk->signal->oom_mm in
oom_reap_task
> It looks like no false positive can get fixed until this
> is solved first because
>
> Isn't this enough? If this is enough it avoids other modification to
> the exit_mmap runtime that looks unnecessary: mm->mmap = NULL replaced
> by MMF_OOM_SKIP that has to be set anyway by __mmput later and one
> unnecessary branch to call the up_write.
>
[...]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f19efcf75418..bdab595ce25c 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2993,6 +2993,23 @@ void exit_mmap(struct mm_struct *mm)
> /* Use -1 here to ensure all VMAs in the mm are unmapped */
> unmap_vmas(&tlb, vma, 0, -1);
>
> + set_bit(MMF_OOM_SKIP, &mm->flags);
> + if (tsk_is_oom_victim(current)) {
> + /*
> + * Wait for oom_reap_task() to stop working on this
> + * mm. Because MMF_OOM_SKIP is already set before
> + * calling down_read(), oom_reap_task() will not run
> + * on this "mm" post up_write().
> + *
> + * tsk_is_oom_victim() cannot be set from under us
> + * either because current->mm is already set to NULL
> + * under task_lock before calling mmput and oom_mm is
> + * set not NULL by the OOM killer only if current->mm
> + * is found not NULL while holding the task_lock.
> + */
> + down_write(&mm->mmap_sem);
> + up_write(&mm->mmap_sem);
> + }
> free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> tlb_finish_mmu(&tlb, 0, -1);
Yes this will work and it won't depend on the oom_lock. But isn't it
just more ugly than simply doing
if (tsk_is_oom_victim) {
down_write(&mm->mmap_sem);
locked = true;
}
free_pgtables(...)
[...]
if (locked)
down_up(&mm->mmap_sem);
in general I do not like empty locked sections much, to be honest. Now
with the conditional locking my patch looks as follows. It should be
pretty much equivalent to your patch. Would that be acceptable for you
or do you think there is a strong reason to go with yours?
---
>From 2198654be88d11efb1f372e8579761f65e219206 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Thu, 27 Jul 2017 08:48:15 +0200
Subject: [PATCH] mm, oom: allow oom reaper to race with exit_mmap
David has noticed that the oom killer might kill additional tasks while
the exiting oom victim hasn't terminated yet because the oom_reaper marks
the curent victim MMF_OOM_SKIP too early when mm->mm_users dropped down
to 0. The race is as follows
oom_reap_task do_exit
exit_mm
__oom_reap_task_mm
mmput
__mmput
mmget_not_zero # fails
exit_mmap # frees memory
set_bit(MMF_OOM_SKIP)
The victim is still visible to the OOM killer until it is unhashed.
Currently we try to
Re: [PATCH 1/5] dt-bindings: rockchip-thermal: Support the RK3328 SoC compatible
Hi Heiko, Thank you for the quick reply. I will remove the gerrit Change-Ids in my v2 patches. Thanks again, Rocky 在 2017/7/27 14:36, Heiko Stübner 写道: Hi Rocky, Am Dienstag, 25. Juli 2017, 17:09:44 CEST schrieb Rocky Hao: attempt to new compatible for thermal founding on RK3328 SoC. Change-Id: Ie6f6d7b4e545891a0035851a923c0412f584140c Signed-off-by: Rocky Hao generally looks good but you should not have gerrit Change-Ids in patches for mainline. This is true for all patches in this series. Heiko --- Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index 43003aec94bd..e3a6234fb1ac 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be "rockchip,-tsadc" "rockchip,rk3228-tsadc": found on RK3228 SoCs "rockchip,rk3288-tsadc": found on RK3288 SoCs + "rockchip,rk3328-tsadc": found on RK3328 SoCs "rockchip,rk3368-tsadc": found on RK3368 SoCs "rockchip,rk3399-tsadc": found on RK3399 SoCs - reg : physical base address of the controller and length of memory mapped
Re: [PATCH v2 1/5] arm64: tegra: Add BPMP thermal sensor to Tegra186
Hi Mikko, [auto build test ERROR on tegra/for-next] [also build test ERROR on v4.13-rc2 next-20170726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mikko-Perttunen/arm64-tegra-Add-BPMP-thermal-sensor-to-Tegra186/20170726-055759 base: https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 Note: the linux-review/Mikko-Perttunen/arm64-tegra-Add-BPMP-thermal-sensor-to-Tegra186/20170726-055759 HEAD 2aebe2225f7f5f03abf6098e07387fa011ec16a8 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): In file included from arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi:1:0, from arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts:5: >> arch/arm64/boot/dts/nvidia/tegra186.dtsi:7:55: fatal error: >> dt-bindings/thermal/tegra186-bpmp-thermal.h: No such file or directory #include ^ compilation terminated. vim +7 arch/arm64/boot/dts/nvidia/tegra186.dtsi > 7 #include 8 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 1/2] ata: mediatek: add support for MediaTek SATA controller
This adds support the AHCI-compliant Serial ATA controller present
on MediaTek SoCs.
Signed-off-by: Ryder Lee
---
drivers/ata/Kconfig| 10 +++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_mtk.c | 196 +
3 files changed, 207 insertions(+)
create mode 100644 drivers/ata/ahci_mtk.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 948fc86..7d3eb47 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -153,6 +153,16 @@ config AHCI_CEVA
If unsure, say N.
+config AHCI_MTK
+ tristate "MediaTek AHCI SATA support"
+ depends on ARCH_MEDIATEK
+ select MFD_SYSCON
+ help
+ This option enables support for the MediaTek SoC's
+ onboard AHCI SATA controller.
+
+ If unsure, say N.
+
config AHCI_MVEBU
tristate "Marvell EBU AHCI SATA support"
depends on ARCH_MVEBU
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a26ef5a..ff9cd2e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_CEVA) += ahci_ceva.o
libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_DA850) += ahci_da850.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_DM816) += ahci_dm816.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_MTK) += ahci_mtk.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_MVEBU) += ahci_mvebu.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_OCTEON) += ahci_octeon.o
obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
new file mode 100644
index 000..220dce6
--- /dev/null
+++ b/drivers/ata/ahci_mtk.c
@@ -0,0 +1,196 @@
+/*
+ * MeidaTek AHCI SATA driver
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ahci.h"
+
+#define DRV_NAME "ahci"
+
+#define SYS_CFG0x14
+#define SYS_CFG_SATA_MSK GENMASK(31, 30)
+#define SYS_CFG_SATA_ENBIT(31)
+
+struct mtk_ahci_drv_data {
+ struct regmap *mode;
+ struct reset_control *axi_rst;
+ struct reset_control *sw_rst;
+ struct reset_control *reg_rst;
+};
+
+static const struct ata_port_info ahci_port_info = {
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_platform_ops,
+};
+
+static struct scsi_host_template ahci_platform_sht = {
+ AHCI_SHT(DRV_NAME),
+};
+
+static int mtk_ahci_platform_resets(struct ahci_host_priv *hpriv,
+ struct device *dev)
+{
+ struct mtk_ahci_drv_data *drv_data = hpriv->plat_data;
+ int err;
+
+ /* reset AXI bus and phy part */
+ drv_data->axi_rst = devm_reset_control_get_optional(dev, "axi-rst");
+ if (IS_ERR(drv_data->axi_rst) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ drv_data->sw_rst = devm_reset_control_get_optional(dev, "sw-rst");
+ if (IS_ERR(drv_data->sw_rst) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ drv_data->reg_rst = devm_reset_control_get_optional(dev, "reg-rst");
+ if (IS_ERR(drv_data->reg_rst) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ err = reset_control_assert(drv_data->axi_rst);
+ if (err) {
+ dev_err(dev, "assert axi bus failed\n");
+ return err;
+ }
+
+ err = reset_control_assert(drv_data->sw_rst);
+ if (err) {
+ dev_err(dev, "assert phy digital part failed\n");
+ return err;
+ }
+
+ err = reset_control_assert(drv_data->reg_rst);
+ if (err) {
+ dev_err(dev, "assert phy register part failed\n");
+ return err;
+ }
+
+ err = reset_control_deassert(drv_data->reg_rst);
+ if (err) {
+ dev_err(dev, "deassert phy register part failed\n");
+ return err;
+ }
+
+ err = reset_control_deassert(drv_data->sw_rst);
+ if (err) {
+ dev_err(dev, "deassert phy digital part failed\n");
+ return err;
+ }
+
+ err = reset_control_deassert(drv_data->axi_rst);
+ if (err) {
+ dev_err(dev, "deassert axi bus failed\n");
+ retur
[PATCH 0/2] Add support for MediaTek AHCI SATA
Hi, This patch series add support for AHCI compatible SATA controller, and it is compliant with the ahci 1.3 and sata 3.0 specification. This driver is slightly different than ahci_platform.c (eg. reset control, subsystem setting). Ryder Lee (2): ata: mediatek: add support for MediaTek SATA controller dt-bindings: ata: add DT bindings for MediaTek SATA controller Documentation/devicetree/bindings/ata/ahci-mtk.txt | 48 + drivers/ata/Kconfig| 10 ++ drivers/ata/Makefile | 1 + drivers/ata/ahci_mtk.c | 196 + 4 files changed, 255 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt create mode 100644 drivers/ata/ahci_mtk.c -- 1.9.1
[PATCH 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller
Add DT bindings for the onboard SATA controller present on the MediaTek
SoCs.
Signed-off-by: Ryder Lee
---
Documentation/devicetree/bindings/ata/ahci-mtk.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
diff --git a/Documentation/devicetree/bindings/ata/ahci-mtk.txt
b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
new file mode 100644
index 000..a8d11db
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
@@ -0,0 +1,48 @@
+MediaTek Seria ATA controller
+
+Required properties:
+ - compatible : Must be "mediatek,ahci".
+ - reg: Physical base addresses and length of register sets.
+ - interrupts : Interrupt associated with the SATA device.
+ - interrupt-names : Associated name must be: "hostc".
+ - clocks : The phandle for the clock.
+ - clock-names: Associated name must be: "ahb", "axi", "asic", "rbc", "pm"
+ - phys : The phandle for the PHY port.
+ - phy-names : Associated name must be: "sata-phy".
+ - ports-implemented : Mask that indicates which ports that the HBA supports
+ are available for software to use. Useful if PORTS_IMPL
+ is not programmed by the BIOS, which is true with some
+ embedded SOC's.
+Optional properties:
+ - power-domains : A phandle and power domain specifier pair to the power
+domain which is responsible for collapsing and restoring
+power to the peripheral.
+ - resets : Must contain an entry for each entry in reset-names.
+See ../reset/reset.txt for details.
+ - reset-names: Associated names must be: "axi-rst", "sw-rst", "reg-rst".
+ - mediatek,phy-mode : A phandle to the system controller, used to enable
+ SATA function.
+
+Example:
+
+ sata: sata@1a20 {
+ compatible = "mediatek,ahci";
+ reg = <0 0x1a20 0 0x1100>;
+ interrupts = ;
+ interrupt-names = "hostc";
+ clocks = <&pciesys CLK_SATA_AHB_EN>,
+<&pciesys CLK_SATA_AXI_EN>,
+<&pciesys CLK_SATA_ASIC_EN>,
+<&pciesys CLK_SATA_RBC_EN>,
+<&pciesys CLK_SATA_PM_EN>;
+ clock-names = "ahb", "axi", "asic", "rbc", "pm";
+ phys = <&u3port1 PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ ports-implemented = <0x1>;
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ resets = <&pciesys MT7622_SATA_AXI_BUS_RST>,
+<&pciesys MT7622_SATA_PHY_SW_RST>,
+<&pciesys MT7622_SATA_PHY_REG_RST>;
+ reset-names = "axi-rst", "sw-rst", "reg-rst";
+ mediatek,phy-mode = <&pciesys>;
+ };
--
1.9.1
Re: [PATCH 1/5] dt-bindings: rockchip-thermal: Support the RK3328 SoC compatible
Hi Rocky, Am Dienstag, 25. Juli 2017, 17:09:44 CEST schrieb Rocky Hao: > attempt to new compatible for thermal founding on RK3328 SoC. > > Change-Id: Ie6f6d7b4e545891a0035851a923c0412f584140c > Signed-off-by: Rocky Hao generally looks good but you should not have gerrit Change-Ids in patches for mainline. This is true for all patches in this series. Heiko > --- > Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index > 43003aec94bd..e3a6234fb1ac 100644 > --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > @@ -4,6 +4,7 @@ Required properties: > - compatible : should be "rockchip,-tsadc" > "rockchip,rk3228-tsadc": found on RK3228 SoCs > "rockchip,rk3288-tsadc": found on RK3288 SoCs > + "rockchip,rk3328-tsadc": found on RK3328 SoCs > "rockchip,rk3368-tsadc": found on RK3368 SoCs > "rockchip,rk3399-tsadc": found on RK3399 SoCs > - reg : physical base address of the controller and length of memory mapped
Re: [PATCH v3] [media] v4l2: Add support for go2001 PCI codec driver
Hi Thierry,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Thierry-Escande/v4l2-Add-support-for-go2001-PCI-codec-driver/20170727-033126
base: git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/media/pci/go2001/go2001_driver.c: In function 'go2001_buf_init':
>> drivers/media/pci/go2001/go2001_driver.c:274:32: warning: format '%zu'
>> expects argument of type 'size_t', but argument 6 has type 'long unsigned
>> int' [-Wformat=]
go2001_err(gdev, "Plane address/size not aligned %d/%zu\n",
^~~~
vim +274 drivers/media/pci/go2001/go2001_driver.c
240
241 static int go2001_buf_init(struct vb2_buffer *vb)
242 {
243 struct go2001_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
244 struct go2001_dev *gdev = ctx->gdev;
245 struct device *dev = &gdev->pdev->dev;
246 struct go2001_buffer *gbuf = vb_to_go2001_buf(vb);
247 struct go2001_dma_desc *dma_desc;
248 struct go2001_mmap_list_entry *mmap_list;
249 enum dma_data_direction dir;
250 struct scatterlist *sg;
251 struct sg_table *sgt;
252 u64 dma_addr;
253 u32 dma_len;
254 int plane, sgi;
255 int ret;
256
257 go2001_trace(gdev);
258
259 if (WARN_ON(gbuf->mapped))
260 return -EINVAL;
261
262 dir = V4L2_TYPE_IS_OUTPUT(vb->vb2_queue->type) ?
263DMA_TO_DEVICE :
264DMA_FROM_DEVICE;
265
266 for (plane = 0; plane < vb->num_planes; ++plane) {
267 dma_desc = &gbuf->dma_desc[plane];
268 WARN_ON(!IS_ALIGNED(dma_desc->map_addr, 16));
269
270 sgt = vb2_dma_sg_plane_desc(vb, plane);
271
272 if (!IS_ALIGNED(sgt->sgl->offset, 8) ||
273 !IS_ALIGNED(vb2_plane_size(vb, plane), 8)) {
> 274 go2001_err(gdev, "Plane address/size not
> aligned %d/%zu\n",
275 sgt->sgl->offset, vb2_plane_size(vb,
plane));
276
277 ret = -EINVAL;
278 goto err;
279 }
280
281 dma_desc->num_entries = sgt->nents;
282 dma_desc->list_size = dma_desc->num_entries *
283sizeof(struct
go2001_mmap_list_entry);
284 dma_desc->mmap_list = dma_alloc_coherent(dev,
285
dma_desc->list_size,
286
&dma_desc->dma_addr,
287 GFP_KERNEL);
288 if (!dma_desc->mmap_list) {
289 go2001_err(gdev, "Failed allocating HW memory
map\n");
290
291 ret = -ENOMEM;
292 goto err;
293 }
294
295 go2001_dbg(gdev, 3, "Plane %d: mmap list size: %zu\n",
plane,
296 dma_desc->list_size);
297
298 mmap_list = dma_desc->mmap_list;
299 for_each_sg(sgt->sgl, sg, dma_desc->num_entries, sgi) {
300 dma_addr = sg_dma_address(sg);
301 dma_len = sg_dma_len(sg);
302
303 mmap_list[sgi].dma_addr = cpu_to_le64(dma_addr);
304 mmap_list[sgi].size = cpu_to_le32(dma_len);
305
306 go2001_dbg(gdev, 4, "Chunk %d: 0x%08llx, size
%d\n",
307 sgi, dma_addr, dma_len);
308 }
309 }
310
311 ret = go2001_map_buffer(ctx, gbuf);
312 if (ret) {
313 go2001_err(ctx->gdev, "Failed mapping buffer in HW\n");
314 goto err;
315 }
316
317 return 0;
318
319 err:
320 for (; plane > 0; --plane) {
321 dma_desc = &gbuf->dma_desc[plane - 1];
322 dma_free_coherent(d
Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap
On Wed 26-07-17 18:39:28, Andrea Arcangeli wrote: > On Wed, Jul 26, 2017 at 07:45:33AM +0200, Michal Hocko wrote: > > Yes, exit_aio is the only blocking call I know of currently. But I would > > like this to be as robust as possible and so I do not want to rely on > > the current implementation. This can change in future and I can > > guarantee that nobody will think about the oom path when adding > > something to the final __mmput path. > > I think ksm_exit may block too waiting for allocations, the generic > idea is those calls before exit_mmap can cause a problem yes. I thought that ksm used __GFP_NORETRY but haven't checked too deeply. Anyway I guess we agree that enabling oom_reaper to race with the final __mmput is desirable? [...] > > This will work more or less the same to what we have currently. > > > > [victim][oom reaper][oom killer] > > do_exit __oom_reap_task_mm > > mmput > > __mmput > > mmget_not_zero > > test_and_set_bit(MMF_OOM_SKIP) > > > > oom_evaluate_task > ># select > > next victim > > # reap the mm > > unmap_vmas > > > > so we can select a next victim while the current one is still not > > completely torn down. > > How does oom_evaluate_task possibly run at the same time of > test_and_set_bit in __oom_reap_task_mm considering both are running > under the oom_lock? You are absolutely right. This race is impossible. It was just me assuming we are going to get rid of the oom_lock because I have that idea in the back of my head and I would really like to get rid of it. Global locks are nasty and I would prefer dropping it if we can. [...] -- Michal Hocko SUSE Labs
[PATCH 2/2] arm64: dts: Add device node for pmi8994 gpios
Signed-off-by: Vivek Gautam
---
arch/arm64/boot/dts/qcom/pmi8994.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8994.dtsi
b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
index d3879a4e8076..3b04ca63c31e 100644
--- a/arch/arm64/boot/dts/qcom/pmi8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
@@ -8,6 +8,23 @@
reg = <0x2 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ pmi8994_gpios: gpios@c000 {
+ compatible = "qcom,pmi8994-gpio";
+ reg = <0xc000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts = <2 0xc0 0 IRQ_TYPE_NONE>,
+<2 0xc1 0 IRQ_TYPE_NONE>,
+<2 0xc2 0 IRQ_TYPE_NONE>,
+<2 0xc3 0 IRQ_TYPE_NONE>,
+<2 0xc4 0 IRQ_TYPE_NONE>,
+<2 0xc5 0 IRQ_TYPE_NONE>,
+<2 0xc6 0 IRQ_TYPE_NONE>,
+<2 0xc7 0 IRQ_TYPE_NONE>,
+<2 0xc8 0 IRQ_TYPE_NONE>,
+<2 0xc9 0 IRQ_TYPE_NONE>;
+ };
};
pmic@3 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] firmware: dmi: Optimize dmi_matches
Function dmi_matches can me made a bit faster:
* The documented purpose of dmi_initialized is to catch too early
calls to dmi_check_system(). I'm not fully convinced it justifies
slowing down the initialization of all systems out there, but at
least the check should not have been moved from dmi_check_system()
to dmi_matches(). dmi_matches() is being called for every entry of
the table passed to dmi_check_system(), causing the same redundant
check to be performed again and again. So move it back to
dmi_check_system(), reverting this specific portion of commit
d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface
more flexible").
* Don't check for the exact_match flag again when we already know its
value.
Signed-off-by: Jean Delvare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rafael J. Wysocki
Cc: Jeff Garzik
---
Regarding dmi_initialized, I don't think it makes sense to check for
a possible bad initialization order at run time on every system when
it is all decided at build time. If a developer introduces a new call
to dmi_check_system() and it is too early in the initialization
sequence, I believe he/she would notice upon first testing, and a
comment to his/her intention in the source code would serve the same
purpose without the worldwide performance penalty. Would anyone
object to such a change?
drivers/firmware/dmi_scan.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
--- linux-4.12.orig/drivers/firmware/dmi_scan.c 2017-07-27 08:15:38.283519194
+0200
+++ linux-4.12/drivers/firmware/dmi_scan.c 2017-07-27 08:26:23.013053058
+0200
@@ -784,19 +784,20 @@ static bool dmi_matches(const struct dmi
{
int i;
- WARN(!dmi_initialized, KERN_ERR "dmi check: not initialized yet.\n");
-
for (i = 0; i < ARRAY_SIZE(dmi->matches); i++) {
int s = dmi->matches[i].slot;
if (s == DMI_NONE)
break;
if (dmi_ident[s]) {
- if (!dmi->matches[i].exact_match &&
- strstr(dmi_ident[s], dmi->matches[i].substr))
- continue;
- else if (dmi->matches[i].exact_match &&
-!strcmp(dmi_ident[s], dmi->matches[i].substr))
- continue;
+ if (dmi->matches[i].exact_match) {
+ if (!strcmp(dmi_ident[s],
+ dmi->matches[i].substr))
+ continue;
+ } else {
+ if (strstr(dmi_ident[s],
+ dmi->matches[i].substr))
+ continue;
+ }
}
/* No match */
@@ -832,6 +833,8 @@ int dmi_check_system(const struct dmi_sy
int count = 0;
const struct dmi_system_id *d;
+ WARN(!dmi_initialized, KERN_ERR "dmi check: not initialized yet.\n");
+
for (d = list; !dmi_is_end_of_table(d); d++)
if (dmi_matches(d)) {
count++;
--
Jean Delvare
SUSE L3 Support
[PATCH 1/2] pinctrl: qcom: spmi-gpio: Add pmi8994 gpio support
Update the bindings doc and driver for pmi8994-gpio devices.
Signed-off-by: Vivek Gautam
---
- Have been using this patch-set on db820c [1] for extcon with
usb controller. The usb controller uses one of these gpios
for usb-id/vbus detection.
[1] https://github.com/boddob/linux/tree/for-qcomlt/4.13rc2-merged
Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
index 8d893a874634..74932318d41d 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -15,6 +15,7 @@ PMIC's from Qualcomm.
"qcom,pm8921-gpio"
"qcom,pm8941-gpio"
"qcom,pm8994-gpio"
+ "qcom,pmi8994-gpio"
"qcom,pma8084-gpio"
And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
@@ -84,6 +85,7 @@ to specify in a pin configuration subnode:
gpio1-gpio44 for pm8921
gpio1-gpio36 for pm8941
gpio1-gpio22 for pm8994
+ gpio1-gpio10 for pmi8994
gpio1-gpio22 for pma8084
- function:
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 664b641fd776..bf0a6438424b 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -799,6 +799,7 @@ static int pmic_gpio_remove(struct platform_device *pdev)
{ .compatible = "qcom,pm8916-gpio" }, /* 4 GPIO's */
{ .compatible = "qcom,pm8941-gpio" }, /* 36 GPIO's */
{ .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
+ { .compatible = "qcom,pmi8994-gpio" }, /* 10 GPIO's */
{ .compatible = "qcom,pma8084-gpio" }, /* 22 GPIO's */
{ .compatible = "qcom,spmi-gpio" }, /* Generic */
{ },
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier
Hi Baoquan,
At 07/27/2017 02:08 PM, b...@redhat.com wrote:
On 07/26/17 at 08:19pm, Dou Liyang wrote:
Hi Baoquan,
There are two places where we used DMAR table in Linux:
1) In detect_intel_iommu() in ACPI early stage:
...
status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
if (dmar_tbl) {
acpi_put_table(dmar_tbl);
dmar_tbl = NULL;
}
2) In dmar_table_init() in ACPI late stage:
...
status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
...
As we know, dmar_table_init() is called by intel_iommu_init() and
intel_prepare_irq_remapping().
When I invoked acpi_put_table() in the intel_prepare_irq_remapping() in
early stage like 1) shows, kernel will panic.
That's because acpi_put_table() will make the table pointer be NULL,
while dmar_table_init() will skip parse_dmar_table() calling if
dmar_table_initialized is set to 1 in intel_prepare_irq_remapping().
Dmar hardware support interrupt remapping and io remapping separately. But
intel_iommu_init() is called later than intel_prepare_irq_remapping().
So what if make dmar_table_init() a reentrant function? You can just
have a try, but maybe not a good idea, the dmar table will be parsed
twice.
The true reason why the kernel panic is that acpi_put_table() only
released DMAR table structure, but not released the remapping
structures in DMAR table, such as DRHD, RMRR. So the address of
RMRR parsed in early ACPI stage will be used in late ACPI stage in
intel_iommu_init(), which make the kernel panic.
The solution is invoking the intel_iommu_free_dmars() before
dmar_table_init() in intel_iommu_init() to release the RMRR.
Demo code will show at the bottom.
I prefer to invoke acpi_early_init() earlier. But it needs a regression
test[1].
Good work, in fact not only intel iommu matters here, I gues you haven't
tried amd system with a AMD-VI which does the amd iommu work. It's
similar to intel iommu and the same principle but different acpi tables.
Yes, I missed it, I didn't try it in AMD platform. If I want to use
acpi_put_table(), I should consider both the Intel and AMD platform.
So it's fine you want to put acpi_early_init earlier.
Got it.
I am looking for Thinkpad x121e (AMD E-450 APU) to test. I have tested
it in Thinkpad s430, It's OK.
BTY, I am confused how does the ACPI subsystem affect PIT which
will be used to fast calibrate CPU frequency[2].
I checked code, and have no any idea. Add Joey Lee to list, see if he
can help answer this.
Thank you very much.
sincerely,
dou.
Do you have any idea?
[1] https://lkml.org/lkml/2014/3/10/123
[2] https://lkml.org/lkml/2014/3/12/3
drivers/iommu/dmar.c| 27 +++
drivers/iommu/intel-iommu.c | 2 ++
drivers/iommu/intel_irq_remapping.c | 17 -
include/linux/dmar.h| 2 ++
init/main.c | 2 +-
5 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index c8b0329..e6261b7 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -68,6 +68,8 @@ DECLARE_RWSEM(dmar_global_lock);
LIST_HEAD(dmar_drhd_units);
struct acpi_table_header * __initdata dmar_tbl;
+struct acpi_table_header * __initdata dmar_tbl_original;
+
static int dmar_dev_scope_status = 1;
static unsigned long dmar_seq_ids[BITS_TO_LONGS(DMAR_UNITS_SUPPORTED)];
@@ -627,6 +629,7 @@ parse_dmar_table(void)
* fixed map.
*/
dmar_table_detect();
+ dmar_tbl_original = dmar_tbl;
/*
* ACPI tables may not be DMA protected by tboot, so use DMAR copy
@@ -811,26 +814,18 @@ int __init dmar_dev_scope_init(void)
int __init dmar_table_init(void)
{
- static int dmar_table_initialized;
int ret;
- if (dmar_table_initialized == 0) {
- ret = parse_dmar_table();
- if (ret < 0) {
- if (ret != -ENODEV)
- pr_info("Parse DMAR table failure.\n");
- } else if (list_empty(&dmar_drhd_units)) {
- pr_info("No DMAR devices found\n");
- ret = -ENODEV;
- }
-
- if (ret < 0)
- dmar_table_initialized = ret;
- else
- dmar_table_initialized = 1;
+ ret = parse_dmar_table();
+ if (ret < 0) {
+ if (ret != -ENODEV)
+ pr_info("Parse DMAR table failure.\n");
+ } else if (list_empty(&dmar_drhd_units)) {
+ pr_info("No DMAR devices found\n");
+ ret = -ENODEV;
}
- return dmar_table_initialized < 0 ? dmar_table_initialized : 0;
+ return ret;
}
static void warn_invalid_dmar(u64 addr, const char *message)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 687f18f..90f74f4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4832,6 +4832,8 @@ in
[PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone
In the non-cooperative userfaultfd case, the process exit may race with
outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
instead of -EINVAL when mm is already gone will allow uffd monitor to
distinguish this case from other error conditions.
Cc: sta...@vger.kernel.org
Fixes: 96333187ab162 ("userfaultfd_copy: return -ENOSPC in case mm has gone")
Signed-off-by: Mike Rapoport
---
Unfortunately, I've overlooked userfaultfd_zeropage when I updated
userfaultd_copy :(
fs/userfaultfd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index cadcd12a3d35..2d8c2d848668 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -1643,6 +1643,8 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx
*ctx,
ret = mfill_zeropage(ctx->mm, uffdio_zeropage.range.start,
uffdio_zeropage.range.len);
mmput(ctx->mm);
+ } else {
+ return -ENOSPC;
}
if (unlikely(put_user(ret, &user_uffdio_zeropage->zeropage)))
return -EFAULT;
--
2.7.4
Re: [PATCH v4 0/5] selftests: ftrace: ftracetest improvements
On Wed, 26 Jul 2017 15:45:52 -0600 Shuah Khan wrote: > On 07/26/2017 03:25 PM, Steven Rostedt wrote: > > On Mon, 24 Jul 2017 09:39:25 -0600 > > Shuah Khan wrote: > > > > > >>> Masami Hiramatsu (5): > >>> selftests: ftrace: Do not failure if there is unsupported tests > >>> selftests: ftrace: Add --fail-unsupported option > >>> selftests: ftrace: Add more verbosity for immediate log > >>> selftests: ftrace: Output only to console with "--logdir -" > >>> selftests: ftrace: Check given string is not zero-length > >>> > > > >> > >> Hi Steve, > >> > >> Okay to pull these in for 4.14-rc1? Sorry for the delay in responding. > >> > > > > I'm currently traveling, and not really able to test it. But a quick > > look at the changes look fine to me. > > > > Acked-by: Steven Rostedt (VMware) > > > > for the series. And yes please pull it in (if you haven't done so > > already). > > > > Thanks! > > > > -- Steve > > > > > > Hi Steve/Masami, > > Applied the series to linux-kselftest next for 4.14-rc1 Thank you Shuah! -- Masami Hiramatsu
Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks
Hi Viresh, On Wed, Jul 26, 2017 at 10:46 PM, Viresh Kumar wrote: > On 26-07-17, 22:14, Joel Fernandes (Google) wrote: >> Also one more comment about this usecase: >> >> You mentioned in our discussion at [2] sometime back, about the >> question of initial utilization, >> >> "We don't have any such configurable way possible right >> now, but there were discussions on how much utilization should a new >> task be assigned when it first comes up." > > We still initialize it to a value, just that it isn't configurable. > See below.. > >> But, then in your cover letter above, you mentioned "This is verified >> using ftrace". So my question is how has this been verified with >> ftrace if the new initial utilization as you said in [2] is currently >> still under discussion? Basically how could you verify with ftrace >> that the target CPU frequency isn't increasing immediately on spawning >> of a new task remotely, if the initial utilization of a new task isn't >> something we set/configure with current code? Am I missing something? >> >> [2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html > > The statement "new tasks should receive maximum demand initially" is > used to represent tasks which have high demand every time they run. > For example scrolling of a web page or gallery on our phones. Yes, > maybe I can use the work "migrated" (as you suggested later) as the > history of its utilization will move with it then to the new CPU. > > But even without that, if you see the routine > init_entity_runnable_average() in fair.c, the new tasks are > initialized in a way that they are seen as heavy tasks. And so even > for the first time they run, freq should normally increase on the > target CPU (at least with above application).i Ok, but the "heavy" in init_entity_runnable_average means for load, not the util_avg. The util_avg is what's used for frequency scaling IIUC and is set to 0 in that function no? > > The application was written by Steve (all credit goes to him) before > he left Linaro, but I did test it with ftrace. What I saw with ftrace > was that the freq isn't reevaluated for almost an entire tick many > times because we enqueued the task remotely. And that changes with > this series. > >> > The reason being that this patchset only targets a corner case, where >> > following are required to be true to improve performance and that >> > doesn't happen too often with these tests: >> > >> > - Task is migrated to another CPU. >> > - The task has maximum demand initially, and should take the CPU to >> >> Just to make the cover-letter more clear and also confirming with you >> I understand the above usecase, maybe in the future this can reworded >> from "initially" to "before the migration" and "take the CPU" to "take >> the target CPU of the migration" ? > > I can reword it a bit, but the test case wasn't really migrating > anything and was looking only at the initial loads. Ok, I wasn't talking about the synthetic test in the second part of my email above but about the explanation you gave about Galleryfling improvement (that the migration of a task with high utilization doesn't update the target frequency) which makes sense to me so we are on the same page about that. thanks, -Joel
Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks
On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar wrote:
> On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
>> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar
>> wrote:
>> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct
>> > update_util_data *hook, u64 time,
>> > sugov_set_iowait_boost(sg_cpu, time, flags);
>> > sg_cpu->last_update = time;
>> >
>> > - if (!sugov_should_update_freq(sg_policy, time))
>> > + if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
>> > return;
>>
>> Since with the remote callbacks now possible, isn't it unsafe to
>> modify sg_cpu and sg_policy structures without a lock in
>> sugov_update_single?
>>
>> Unlike sugov_update_shared, we don't acquire any lock in
>> sugov_update_single before updating these structures. Did I miss
>> something?
>
> As Peter already mentioned it earlier, the callbacks are called with
> rq locks held and so sugov_update_single() wouldn't get called in
> parallel for a target CPU.
Ah ok, I have to catch up with that discussion since I missed the
whole thing. Now that you will have me on CC, that shouldn't happen,
thanks and sorry about the noise.
> That's the only race you were worried about ?
Yes. So then in that case, makes sense to move raw_spin_lock in
sugov_update_shared further down? (Just discussing, this point is
independent of your patch), Something like:
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 622eed1b7658..9a6c12fb2c16 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -295,8 +295,6 @@ static void sugov_update_shared(struct
update_util_data *hook, u64 time,
sugov_get_util(&util, &max);
- raw_spin_lock(&sg_policy->update_lock);
-
sg_cpu->util = util;
sg_cpu->max = max;
sg_cpu->flags = flags;
@@ -304,6 +302,8 @@ static void sugov_update_shared(struct
update_util_data *hook, u64 time,
sugov_set_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
+ raw_spin_lock(&sg_policy->update_lock);
+
if (sugov_should_update_freq(sg_policy, time)) {
if (flags & SCHED_CPUFREQ_RT_DL)
next_f = sg_policy->policy->cpuinfo.max_freq;
thanks,
-Joel
Re: [PATCH v2] security: fix description of values returned by cap_inode_need_killpriv
On Wed, 26 Jul 2017, Stefan Berger wrote: > cap_inode_need_killpriv returns 1 if security.capability exists and > has a value and inode_killpriv() is required, 0 otherwise. Fix the > description of the return value to reflect this. > > Signed-off-by: Stefan Berger > --- > security/commoncap.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris
Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier
On 07/26/17 at 08:19pm, Dou Liyang wrote:
> Hi Baoquan,
> > > There are two places where we used DMAR table in Linux:
> > >
> > > 1) In detect_intel_iommu() in ACPI early stage:
> > >
> > > ...
> > > status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
> > >
> > > if (dmar_tbl) {
> > > acpi_put_table(dmar_tbl);
> > > dmar_tbl = NULL;
> > > }
> > >
> > > 2) In dmar_table_init() in ACPI late stage:
> > >
> > > ...
> > > status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
> > > ...
> > >
> > > As we know, dmar_table_init() is called by intel_iommu_init() and
> > > intel_prepare_irq_remapping().
> > >
> > > When I invoked acpi_put_table() in the intel_prepare_irq_remapping() in
> > > early stage like 1) shows, kernel will panic.
> >
> > That's because acpi_put_table() will make the table pointer be NULL,
> > while dmar_table_init() will skip parse_dmar_table() calling if
> > dmar_table_initialized is set to 1 in intel_prepare_irq_remapping().
> >
> > Dmar hardware support interrupt remapping and io remapping separately. But
> > intel_iommu_init() is called later than intel_prepare_irq_remapping().
> > So what if make dmar_table_init() a reentrant function? You can just
> > have a try, but maybe not a good idea, the dmar table will be parsed
> > twice.
>
> The true reason why the kernel panic is that acpi_put_table() only
> released DMAR table structure, but not released the remapping
> structures in DMAR table, such as DRHD, RMRR. So the address of
> RMRR parsed in early ACPI stage will be used in late ACPI stage in
> intel_iommu_init(), which make the kernel panic.
>
> The solution is invoking the intel_iommu_free_dmars() before
> dmar_table_init() in intel_iommu_init() to release the RMRR.
> Demo code will show at the bottom.
>
> I prefer to invoke acpi_early_init() earlier. But it needs a regression
> test[1].
Good work, in fact not only intel iommu matters here, I gues you haven't
tried amd system with a AMD-VI which does the amd iommu work. It's
similar to intel iommu and the same principle but different acpi tables.
So it's fine you want to put acpi_early_init earlier.
>
> I am looking for Thinkpad x121e (AMD E-450 APU) to test. I have tested
> it in Thinkpad s430, It's OK.
>
> BTY, I am confused how does the ACPI subsystem affect PIT which
> will be used to fast calibrate CPU frequency[2].
I checked code, and have no any idea. Add Joey Lee to list, see if he
can help answer this.
>
> Do you have any idea?
>
> [1] https://lkml.org/lkml/2014/3/10/123
> [2] https://lkml.org/lkml/2014/3/12/3
>
>
> drivers/iommu/dmar.c| 27 +++
> drivers/iommu/intel-iommu.c | 2 ++
> drivers/iommu/intel_irq_remapping.c | 17 -
> include/linux/dmar.h| 2 ++
> init/main.c | 2 +-
> 5 files changed, 32 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index c8b0329..e6261b7 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -68,6 +68,8 @@ DECLARE_RWSEM(dmar_global_lock);
> LIST_HEAD(dmar_drhd_units);
>
> struct acpi_table_header * __initdata dmar_tbl;
> +struct acpi_table_header * __initdata dmar_tbl_original;
> +
> static int dmar_dev_scope_status = 1;
> static unsigned long dmar_seq_ids[BITS_TO_LONGS(DMAR_UNITS_SUPPORTED)];
>
> @@ -627,6 +629,7 @@ parse_dmar_table(void)
>* fixed map.
>*/
> dmar_table_detect();
> + dmar_tbl_original = dmar_tbl;
>
> /*
>* ACPI tables may not be DMA protected by tboot, so use DMAR copy
> @@ -811,26 +814,18 @@ int __init dmar_dev_scope_init(void)
>
> int __init dmar_table_init(void)
> {
> - static int dmar_table_initialized;
> int ret;
>
> - if (dmar_table_initialized == 0) {
> - ret = parse_dmar_table();
> - if (ret < 0) {
> - if (ret != -ENODEV)
> - pr_info("Parse DMAR table failure.\n");
> - } else if (list_empty(&dmar_drhd_units)) {
> - pr_info("No DMAR devices found\n");
> - ret = -ENODEV;
> - }
> -
> - if (ret < 0)
> - dmar_table_initialized = ret;
> - else
> - dmar_table_initialized = 1;
> + ret = parse_dmar_table();
> + if (ret < 0) {
> + if (ret != -ENODEV)
> + pr_info("Parse DMAR table failure.\n");
> + } else if (list_empty(&dmar_drhd_units)) {
> + pr_info("No DMAR devices found\n");
> + ret = -ENODEV;
> }
>
> - return dmar_table_initialized < 0 ? dmar_table_initialized : 0;
> + return ret;
> }
>
> static void warn_invalid_dmar(u64 addr, const char *message)
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 687f18f..90f74f4 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@
Re: [PATCH][next] clk: ti: check for null return in strrchr to avoid null dereferencing
On 27/07/17 02:56, Colin King wrote:
From: Colin Ian King
strrchr can potentially return a null so the following strlen on the
null pointer can cause a null dereference. Add a check to see if
the string postfix is not null before calling strlen.
Detected by CoverityScan, CID#1452039 ("Dereference null return")
Signed-off-by: Colin Ian King
---
drivers/clk/ti/adpll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
index 255cafb18336..bd7cb9a413c9 100644
--- a/drivers/clk/ti/adpll.c
+++ b/drivers/clk/ti/adpll.c
@@ -222,7 +222,7 @@ static int ti_adpll_setup_clock(struct ti_adpll_data *d,
struct clk *clock,
/* Separate con_id in format "pll040dcoclkldo" to fit MAX_CON_ID */
postfix = strrchr(name, '.');
- if (strlen(postfix) > 1) {
+ if (postfix && strlen(postfix) > 1) {
if (strlen(postfix) > ADPLL_MAX_CON_ID)
dev_warn(d->dev, "clock %s con_id lookup may fail\n",
name);
Looks fine to me.
Acked-by: Tero Kristo
Re: [PATCH] fortify: Use WARN instead of BUG for now
Hi Kees,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kees-Cook/fortify-Use-WARN-instead-of-BUG-for-now/20170727-101839
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from arch/x86/include/asm/page_32.h:34:0,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/thread_info.h:11,
from include/linux/thread_info.h:37,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:80,
from include/linux/spinlock.h:50,
from include/linux/wait.h:8,
from include/linux/wait_bit.h:7,
from include/linux/fs.h:5,
from include/linux/buffer_head.h:11,
from fs/adfs/dir_f.c:12:
In function 'memcpy',
inlined from '__adfs_dir_put' at fs/adfs/dir_f.c:318:2,
inlined from 'adfs_f_update' at fs/adfs/dir_f.c:403:2:
>> include/linux/string.h:308:4: error: call to '__read_overflow2' declared
>> with attribute error: detected read beyond size of object passed as 2nd
>> parameter
__read_overflow2();
^~
vim +/__read_overflow2 +308 include/linux/string.h
6974f0c4 Daniel Micay 2017-07-12 299
6974f0c4 Daniel Micay 2017-07-12 300 __FORTIFY_INLINE void *memcpy(void *p,
const void *q, __kernel_size_t size)
6974f0c4 Daniel Micay 2017-07-12 301 {
6974f0c4 Daniel Micay 2017-07-12 302 size_t p_size =
__builtin_object_size(p, 0);
6974f0c4 Daniel Micay 2017-07-12 303 size_t q_size =
__builtin_object_size(q, 0);
6974f0c4 Daniel Micay 2017-07-12 304 if (__builtin_constant_p(size)) {
6974f0c4 Daniel Micay 2017-07-12 305 if (p_size < size)
6974f0c4 Daniel Micay 2017-07-12 306 __write_overflow();
6974f0c4 Daniel Micay 2017-07-12 307 if (q_size < size)
6974f0c4 Daniel Micay 2017-07-12 @308 __read_overflow2();
acf23d09 Kees Cook2017-07-25 309 } else {
acf23d09 Kees Cook2017-07-25 310 if (p_size < size)
acf23d09 Kees Cook2017-07-25 311
fortify_write_overflow(__func__);
acf23d09 Kees Cook2017-07-25 312 if (q_size < size)
acf23d09 Kees Cook2017-07-25 313
fortify_read_overflow2(__func__);
6974f0c4 Daniel Micay 2017-07-12 314 }
6974f0c4 Daniel Micay 2017-07-12 315 return __builtin_memcpy(p, q, size);
6974f0c4 Daniel Micay 2017-07-12 316 }
6974f0c4 Daniel Micay 2017-07-12 317
:: The code at line 308 was first introduced by commit
:: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the
option of fortified string.h functions
:: TO: Daniel Micay
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ
On Wed, Jul 26, 2017 at 08:57:03PM +0200, Rafael J. Wysocki wrote: > > Should I apply this or will Tony do that? > > So am I suppsed to drop this? Well, as suggested in another mail, I think it'll be best if Tony and I put ourselves as reviewers for the APEI crap and you still collect it. Unless you want to give it to us and we can arrange some pull order to send it to you. What do you prefer? -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Seek a machine named Thinkpad x121e (AMD E-450 APU)
Hi all, Does somebody have the *Thinkpad x121e (AMD E-450 APU)*? I need to do an regression test for a patchset[1]. This test is simple, but really special and only be reproduced in Thinkpad x121e. I have tested it in Thinkpad s430, Lenovo M4340 and Lenovo M4300. Unfortunately, I failed. I did my utmost to look for it, but two weeks passed, I didn't got it. Ask for help here, If you have this machine, please let me know. [1] https://lkml.org/lkml/2017/7/14/20 Thanks, dou.
Re: [PATCH 0/3] EDAC: Convert ghes_edac to a normal module
On Wed, Jul 26, 2017 at 10:48:24AM +0200, Borislav Petkov wrote: > EDAC: Add edac_pr_err/info macros > ACPI/GHES: Add an EDAC notifier chain > EDAC, ghes: Make it a proper module Pushed here: https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=ghes -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks
On 26-07-17, 22:34, Joel Fernandes (Google) wrote: > On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote: > > @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data > > *hook, u64 time, > > sugov_set_iowait_boost(sg_cpu, time, flags); > > sg_cpu->last_update = time; > > > > - if (!sugov_should_update_freq(sg_policy, time)) > > + if (!sugov_should_update_freq(sg_policy, time, hook->cpu)) > > return; > > Since with the remote callbacks now possible, isn't it unsafe to > modify sg_cpu and sg_policy structures without a lock in > sugov_update_single? > > Unlike sugov_update_shared, we don't acquire any lock in > sugov_update_single before updating these structures. Did I miss > something? As Peter already mentioned it earlier, the callbacks are called with rq locks held and so sugov_update_single() wouldn't get called in parallel for a target CPU. That's the only race you were worried about ? -- viresh
Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel
On Thu, Jul 27, 2017 at 10:29 AM, Jassi Brar wrote:
> On Thu, Jul 27, 2017 at 9:25 AM, Anup Patel wrote:
>> On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar wrote:
>>> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel
>>> wrote:
On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar
wrote:
> On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel
> wrote:
>> Hi Jassi,
>>
>> Sorry for the delayed response...
>>
>> On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar
>> wrote:
>>> Hi Anup,
>>>
>>> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel
>>> wrote:
The Broadcom FlexRM ring (i.e. mailbox channel) can handle
larger number of messages queued in one FlexRM ring hence
this patch sets msg_queue_len for each mailbox channel to
be same as RING_MAX_REQ_COUNT.
Signed-off-by: Anup Patel
Reviewed-by: Scott Branden
---
drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c
b/drivers/mailbox/bcm-flexrm-mailbox.c
index 9873818..20055a0 100644
--- a/drivers/mailbox/bcm-flexrm-mailbox.c
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct
platform_device *pdev)
ret = -ENOMEM;
goto fail_free_debugfs_root;
}
- for (index = 0; index < mbox->num_rings; index++)
+ for (index = 0; index < mbox->num_rings; index++) {
+ mbox->controller.chans[index].msg_queue_len =
+ RING_MAX_REQ_COUNT;
mbox->controller.chans[index].con_priv =
&mbox->rings[index];
+ }
>>> While writing mailbox.c I wasn't unaware that there is the option to
>>> choose the queue length at runtime.
>>> The idea was to keep the code as simple as possible. I am open to
>>> making it a runtime thing, but first, please help me understand how
>>> that is useful here.
>>>
>>> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
>>> elements. Any message submitted to mailbox api can be immediately
>>> written onto the ringbuffer if there is some space.
>>> Is there any mechanism to report back to a client driver, if its
>>> message in ringbuffer failed "to be sent"?
>>> If there isn't any, then I think, in flexrm_last_tx_done() you should
>>> simply return true if there is some space left in the rung-buffer,
>>> false otherwise.
>>
>> Yes, we have error code in "struct brcm_message" to report back
>> errors from send_message. In our mailbox clients, we check
>> return value of mbox_send_message() and also the error code
>> in "struct brcm_message".
>>
> I meant after the message has been accepted in the ringbuffer but the
> remote failed to receive it.
Yes, even this case is handled.
In case of IO errors after message has been put in ring buffer, we get
completion message with error code and mailbox client drivers will
receive back "struct brcm_message" with error set.
You can refer flexrm_process_completions() for more details.
> It doesn't seem to be what I suggest. I see two issues in
> flexrm_process_completions()
> 1) It calls mbox_send_message(), which is a big NO for a controller
> driver. Why should you have one more message stored outside of
> ringbuffer?
The "last_pending_msg" in each FlexRM ring was added to fit FlexRM
in Mailbox framework.
We don't have any IRQ for TX done so "txdone_irq" out of the question for
FlexRM. We only have completions for both success or failures (IO errors).
This means we have to use "txdone_poll" for FlexRM. For "txdone_poll",
we have to provide last_tx_done() callback. The last_tx_done() callback
is supposed to return true if last send_data() call succeeded.
To implement last_tx_done() in FlexRM driver, we added "last_pending_msg".
When "last_pending_msg" is NULL it means last call to send_data() succeeded
and when "last_pending_msg" is != NULL it means last call to send_data()
did not go through due to lack of space in FlexRM ring. The IRQ worker
of FlexRM ring will automatically queue the message pointed by
"last_pending_message" and clear it. This is why we have mbox_send_message()
call in flexrm_process_completions().
>
> 2) It calls mbox_chan_received_data() which is for messages received
> from the remote. And not the way to report failed _transmission_, for
> which the api calls back mbox_client.tx_done() . In your client
> driver please populate mbox_client.tx_done() and see which message is
> reported "sent fine" when.
>
>
> There seems no such provision. IIANW, then you should be able to
> consider ever
Re: [Eas-dev] [PATCH V4 2/3] cpufreq: schedutil: Process remote callback for shared policies
On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote:
> This patch updates the schedutil governor to process cpufreq utilization
> update hooks called for remote CPUs where the remote CPU is managed by
> the cpufreq policy of the local CPU.
>
> Based on initial work from Steve Muckle.
>
> Signed-off-by: Viresh Kumar
Reviewed-by: Joel Fernandes
thanks,
-Joel
> ---
> kernel/sched/cpufreq_schedutil.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index bb834747e49b..c3baf70d360c 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,13 +72,12 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>
> / Governor internals ***/
>
> -static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64
> time,
> -int target_cpu)
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64
> time)
> {
> s64 delta_ns;
>
> - /* Don't allow remote callbacks */
> - if (smp_processor_id() != target_cpu)
> + /* Allow remote callbacks only on the CPUs sharing cpufreq policy */
> + if (!cpumask_test_cpu(smp_processor_id(), sg_policy->policy->cpus))
> return false;
>
> if (sg_policy->work_in_progress)
> @@ -159,12 +158,12 @@ static unsigned int get_next_freq(struct sugov_policy
> *sg_policy,
> return cpufreq_driver_resolve_freq(policy, freq);
> }
>
> -static void sugov_get_util(unsigned long *util, unsigned long *max)
> +static void sugov_get_util(unsigned long *util, unsigned long *max, int cpu)
> {
> - struct rq *rq = this_rq();
> + struct rq *rq = cpu_rq(cpu);
> unsigned long cfs_max;
>
> - cfs_max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> + cfs_max = arch_scale_cpu_capacity(NULL, cpu);
>
> *util = min(rq->cfs.avg.util_avg, cfs_max);
> *max = cfs_max;
> @@ -226,7 +225,7 @@ static void sugov_update_single(struct update_util_data
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> - if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> + if (!sugov_should_update_freq(sg_policy, time))
> return;
>
> busy = sugov_cpu_is_busy(sg_cpu);
> @@ -234,7 +233,7 @@ static void sugov_update_single(struct update_util_data
> *hook, u64 time,
> if (flags & SCHED_CPUFREQ_RT_DL) {
> next_f = policy->cpuinfo.max_freq;
> } else {
> - sugov_get_util(&util, &max);
> + sugov_get_util(&util, &max, hook->cpu);
> sugov_iowait_boost(sg_cpu, &util, &max);
> next_f = get_next_freq(sg_policy, util, max);
> /*
> @@ -295,7 +294,7 @@ static void sugov_update_shared(struct update_util_data
> *hook, u64 time,
> unsigned long util, max;
> unsigned int next_f;
>
> - sugov_get_util(&util, &max);
> + sugov_get_util(&util, &max, hook->cpu);
>
> raw_spin_lock(&sg_policy->update_lock);
>
> @@ -306,7 +305,7 @@ static void sugov_update_shared(struct update_util_data
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> - if (sugov_should_update_freq(sg_policy, time, hook->cpu)) {
> + if (sugov_should_update_freq(sg_policy, time)) {
> if (flags & SCHED_CPUFREQ_RT_DL)
> next_f = sg_policy->policy->cpuinfo.max_freq;
Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks
On 26-07-17, 22:14, Joel Fernandes (Google) wrote: > I think you dropped [1] in your cover-letter. May be you meant to add > it at the end of the cover letter? > > I noticed from your v2 that its: > https://pastebin.com/7LkMSRxE Yeah, I missed it. Thanks :) > Also one more comment about this usecase: > > You mentioned in our discussion at [2] sometime back, about the > question of initial utilization, > > "We don't have any such configurable way possible right > now, but there were discussions on how much utilization should a new > task be assigned when it first comes up." We still initialize it to a value, just that it isn't configurable. See below.. > But, then in your cover letter above, you mentioned "This is verified > using ftrace". So my question is how has this been verified with > ftrace if the new initial utilization as you said in [2] is currently > still under discussion? Basically how could you verify with ftrace > that the target CPU frequency isn't increasing immediately on spawning > of a new task remotely, if the initial utilization of a new task isn't > something we set/configure with current code? Am I missing something? > > [2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html The statement "new tasks should receive maximum demand initially" is used to represent tasks which have high demand every time they run. For example scrolling of a web page or gallery on our phones. Yes, maybe I can use the work "migrated" (as you suggested later) as the history of its utilization will move with it then to the new CPU. But even without that, if you see the routine init_entity_runnable_average() in fair.c, the new tasks are initialized in a way that they are seen as heavy tasks. And so even for the first time they run, freq should normally increase on the target CPU (at least with above application). The application was written by Steve (all credit goes to him) before he left Linaro, but I did test it with ftrace. What I saw with ftrace was that the freq isn't reevaluated for almost an entire tick many times because we enqueued the task remotely. And that changes with this series. > > The reason being that this patchset only targets a corner case, where > > following are required to be true to improve performance and that > > doesn't happen too often with these tests: > > > > - Task is migrated to another CPU. > > - The task has maximum demand initially, and should take the CPU to > > Just to make the cover-letter more clear and also confirming with you > I understand the above usecase, maybe in the future this can reworded > from "initially" to "before the migration" and "take the CPU" to "take > the target CPU of the migration" ? I can reword it a bit, but the test case wasn't really migrating anything and was looking only at the initial loads. > > higher OPPs. > > - And the target CPU doesn't call into schedutil until the next tick. > > I found this usecase to be more plausible and can see this patch > series being useful there. > > Could you also keep me in CC on these patches (at joe...@google.com)? > I'm interested in this series. Sure. -- viresh
linux-next: Tree for Jul 27
Hi all, Changes since 20170726: Non-merge commits (relative to Linus' tree): 2581 2620 files changed, 92132 insertions(+), 46797 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu. Below is a summary of the state of the merge. I am currently merging 267 trees (counting Linus' and 41 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fd2b2c57ec20 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig entry) Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in nconfig) Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts files for enabling PAE40 on axs103) Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable iwmmxt_sigframe in uc_regspace[]) Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (029d9252b116 powerpc/mm: Mark __init memory no-execute when STRICT_KERNEL_RWX=y) Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of full_name) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (d94708a55302 bonding: commit link status change after propose) Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.) Merging netfilter/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed connections) Merging wireless-drivers/master (d755cbc26e82 Merge tag 'iwlwifi-for-kalle-2017-07-21' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES) Merging sound-current/for-linus (ba92b1142879 ALSA: hda - Add mute led support for HP ProBook 440 G4) Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for pci_scan_root_bus_bridge() failure correctly) Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1) Merging tty.current/tty-linus (520eccdfe187 Linux 4.13-rc2) Merging usb.current/usb-linus (520eccdfe187 Linux 4.13-rc2) Merging usb-gadget-fixes/fixes (520eccdfe187 Linux 4.13-rc2) Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add support for Qivicon USB ZigBee dongle) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (5771a8c08880 Linux v4.13-rc1) Merging staging.current/staging-linus (055655a9f0fe Merge tag 'iio-fixes-for-4.13a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (520eccdfe187 Linux 4.13-rc2) Merging input-current/for-linus (293b915fd9be Input: trackpoint - assume 3 buttons when buttons detection fails) Merging crypto-current/master (41cdf7a45389 crypto: authencesn - Fix digest_null crash) Merging ide/master (921edf312a6a ide: avoid warning for timings calculation) Merging vfio-fixes/for-linus (bb67b496c338 include/linux/vfio.h: Guard powerpc-speci
Re: [PATCH 09/12] ima: introduce securityfs interfaces for digest lists
Hi Roberto,
[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from security/integrity/ima/ima_fs.c:27:0:
security/integrity/ima/ima.h: In function 'ima_parse_digest_list_metadata':
security/integrity/ima/ima.h:165:10: error: 'ENOTSUP' undeclared (first use
in this function)
return -ENOTSUP;
^~~
security/integrity/ima/ima.h:165:10: note: each undeclared identifier is
reported only once for each function it appears in
>> security/integrity/ima/ima.h:166:1: warning: control reaches end of non-void
>> function [-Wreturn-type]
}
^
vim +166 security/integrity/ima/ima.h
d68a6fe9f Mimi Zohar 2016-12-19 135
3323eec92 Mimi Zohar 2009-02-04 136 /* Internal IMA function definitions
*/
3323eec92 Mimi Zohar 2009-02-04 137 int ima_init(void);
bab739378 Mimi Zohar 2009-02-04 138 int ima_fs_init(void);
3323eec92 Mimi Zohar 2009-02-04 139 int ima_add_template_entry(struct
ima_template_entry *entry, int violation,
9803d413f Roberto Sassu 2013-06-07 140 const char
*op, struct inode *inode,
9803d413f Roberto Sassu 2013-06-07 141 const
unsigned char *filename);
c7c8bb237 Dmitry Kasatkin 2013-04-25 142 int ima_calc_file_hash(struct file
*file, struct ima_digest_data *hash);
11d7646df Dmitry Kasatkin 2014-04-17 143 int ima_calc_buffer_hash(const void
*buf, loff_t len,
11d7646df Dmitry Kasatkin 2014-04-17 144struct
ima_digest_data *hash);
b6f8f16f4 Roberto Sassu 2013-11-08 145 int ima_calc_field_array_hash(struct
ima_field_data *field_data,
b6f8f16f4 Roberto Sassu 2013-11-08 146 struct
ima_template_desc *desc, int num_fields,
c7c8bb237 Dmitry Kasatkin 2013-04-25 147 struct
ima_digest_data *hash);
09ef54359 Dmitry Kasatkin 2013-06-07 148 int __init
ima_calc_boot_aggregate(struct ima_digest_data *hash);
7d802a227 Roberto Sassu 2013-06-07 149 void ima_add_violation(struct file
*file, const unsigned char *filename,
8d94eb9b5 Roberto Sassu 2015-04-11 150 struct
integrity_iint_cache *iint,
3323eec92 Mimi Zohar 2009-02-04 151 const char *op,
const char *cause);
76bb28f61 Dmitry Kasatkin 2012-06-08 152 int ima_init_crypto(void);
3ce1217d6 Roberto Sassu 2013-06-07 153 void ima_putc(struct seq_file *m,
void *data, int datalen);
45b26133b Mimi Zohar 2015-06-11 154 void ima_print_digest(struct
seq_file *m, u8 *digest, u32 size);
a71dc65d3 Roberto Sassu 2013-06-07 155 struct ima_template_desc
*ima_template_desc_current(void);
94c3aac56 Mimi Zohar 2016-12-19 156 int
ima_restore_measurement_entry(struct ima_template_entry *entry);
94c3aac56 Mimi Zohar 2016-12-19 157 int
ima_restore_measurement_list(loff_t bufsize, void *buf);
4b1c19b3d Roberto Sassu 2017-07-25 158 struct ima_digest
*ima_lookup_loaded_digest(u8 *digest);
4b1c19b3d Roberto Sassu 2017-07-25 159 int ima_add_digest_data_entry(u8
*digest);
3580b2df6 Roberto Sassu 2017-07-25 160 #ifdef CONFIG_IMA_DIGEST_LIST
3580b2df6 Roberto Sassu 2017-07-25 161 ssize_t
ima_parse_digest_list_metadata(loff_t size, void *buf);
3580b2df6 Roberto Sassu 2017-07-25 162 #else
3580b2df6 Roberto Sassu 2017-07-25 163 static inline ssize_t
ima_parse_digest_list_metadata(loff_t size, void *buf)
3580b2df6 Roberto Sassu 2017-07-25 164 {
3580b2df6 Roberto Sassu 2017-07-25 @165 return -ENOTSUP;
3580b2df6 Roberto Sassu 2017-07-25 @166 }
3580b2df6 Roberto Sassu 2017-07-25 167 #endif
7b8589cc2 Mimi Zohar 2016-12-19 168 int ima_measurements_show(struct
seq_file *m, void *v);
d158847ae Mimi Zohar 2016-12-19 169 unsigned long
ima_get_binary_runtime_size(void);
a71dc65d3 Roberto Sassu 2013-06-07 170 int ima_init_template(void);
3f23d624d Mimi Zohar 2016-12-19 171 void ima_init_template_list(void);
3323eec92 Mimi Zohar 2009-02-04 172
:: The code at line 166 was first introduced by commit
:: 3580b2df63c2ec47030a481fea2d2c865124aff4 ima: added parser of digest
lists metadata
:: TO: Roberto Sassu
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-a
Re: [f2fs-dev] [PATCH 1/2] f2fs: expose /sys/fs/f2fs/features
On 2017/7/27 5:43, Jaegeuk Kim wrote:
> On 07/26, Chao Yu wrote:
>> On 2017/7/26 9:29, Jaegeuk Kim wrote:
>>> This patch exposes what features are supported by current f2fs build to
>>> sysfs
>>> entry.
>>>
>>> Signed-off-by: Jaegeuk Kim
>>
>> Reviewed-by: Chao Yu
>>
>> Minor thing, can you exchange below function name to follow ext4:
>> f2fs_init_sysfs <-> f2fs_register_sysfs
>> f2fs_exit_sysfs <-> f2fs_unregister_sysfs
>>
>>From 4cf8a3138f3ee171750ae279fefd4de672a0ee29 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim
> Date: Wed, 26 Jul 2017 11:24:13 -0700
> Subject: [PATCH] f2fs: avoid naming confusion of sysfs init
>
> This patch changes the function names of sysfs init to follow ext4.
>
> f2fs_init_sysfs <-> f2fs_register_sysfs
> f2fs_exit_sysfs <-> f2fs_unregister_sysfs
>
> Suggested-by: Chao Yu
> Signed-off-by: Jaegeuk Kim
Reivewed-by: Chao Yu
Thanks,
> ---
> fs/f2fs/f2fs.h | 8
> fs/f2fs/super.c | 10 +-
> fs/f2fs/sysfs.c | 8
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d486539086b6..a1bfd0b9be44 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2820,10 +2820,10 @@ void destroy_extent_cache(void);
> /*
> * sysfs.c
> */
> -int __init f2fs_register_sysfs(void);
> -void f2fs_unregister_sysfs(void);
> -int f2fs_init_sysfs(struct f2fs_sb_info *sbi);
> -void f2fs_exit_sysfs(struct f2fs_sb_info *sbi);
> +int __init f2fs_init_sysfs(void);
> +void f2fs_exit_sysfs(void);
> +int f2fs_register_sysfs(struct f2fs_sb_info *sbi);
> +void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi);
>
> /*
> * crypto support
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 1241739f4d54..12513caabe6e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -649,7 +649,7 @@ static void f2fs_put_super(struct super_block *sb)
>
> kfree(sbi->ckpt);
>
> - f2fs_exit_sysfs(sbi);
> + f2fs_unregister_sysfs(sbi);
>
> sb->s_fs_info = NULL;
> if (sbi->s_chksum_driver)
> @@ -2145,7 +2145,7 @@ static int f2fs_fill_super(struct super_block *sb, void
> *data, int silent)
> goto free_root_inode;
> }
>
> - err = f2fs_init_sysfs(sbi);
> + err = f2fs_register_sysfs(sbi);
> if (err)
> goto free_root_inode;
>
> @@ -2216,7 +2216,7 @@ static int f2fs_fill_super(struct super_block *sb, void
> *data, int silent)
>
> free_sysfs:
> f2fs_sync_inode_meta(sbi);
> - f2fs_exit_sysfs(sbi);
> + f2fs_unregister_sysfs(sbi);
> free_root_inode:
> dput(sb->s_root);
> sb->s_root = NULL;
> @@ -2334,7 +2334,7 @@ static int __init init_f2fs_fs(void)
> err = create_extent_cache();
> if (err)
> goto free_checkpoint_caches;
> - err = f2fs_register_sysfs();
> + err = f2fs_init_sysfs();
> if (err)
> goto free_extent_cache;
> err = register_shrinker(&f2fs_shrinker_info);
> @@ -2373,7 +2373,7 @@ static void __exit exit_f2fs_fs(void)
> f2fs_destroy_root_stats();
> unregister_filesystem(&f2fs_fs_type);
> unregister_shrinker(&f2fs_shrinker_info);
> - f2fs_unregister_sysfs();
> + f2fs_exit_sysfs();
> destroy_extent_cache();
> destroy_checkpoint_caches();
> destroy_segment_manager_caches();
> diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
> index 71191d89917d..5a78b9af92ef 100644
> --- a/fs/f2fs/sysfs.c
> +++ b/fs/f2fs/sysfs.c
> @@ -304,7 +304,7 @@ static const struct file_operations
> f2fs_seq_##_name##_fops = { \
> F2FS_PROC_FILE_DEF(segment_info);
> F2FS_PROC_FILE_DEF(segment_bits);
>
> -int __init f2fs_register_sysfs(void)
> +int __init f2fs_init_sysfs(void)
> {
> f2fs_proc_root = proc_mkdir("fs/f2fs", NULL);
>
> @@ -314,13 +314,13 @@ int __init f2fs_register_sysfs(void)
> return 0;
> }
>
> -void f2fs_unregister_sysfs(void)
> +void f2fs_exit_sysfs(void)
> {
> kset_unregister(f2fs_kset);
> remove_proc_entry("fs/f2fs", NULL);
> }
>
> -int f2fs_init_sysfs(struct f2fs_sb_info *sbi)
> +int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
> {
> struct super_block *sb = sbi->sb;
> int err;
> @@ -351,7 +351,7 @@ int f2fs_init_sysfs(struct f2fs_sb_info *sbi)
> return err;
> }
>
> -void f2fs_exit_sysfs(struct f2fs_sb_info *sbi)
> +void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
> {
> kobject_del(&sbi->s_kobj);
> kobject_put(&sbi->s_kobj);
>
Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks
Hi Viresh,
On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote:
> We do not call cpufreq callbacks from scheduler core for remote
> (non-local) CPUs currently. But there are cases where such remote
> callbacks are useful, specially in the case of shared cpufreq policies.
>
> This patch updates the scheduler core to call the cpufreq callbacks for
> remote CPUs as well.
>
> For now, all the registered utilization update callbacks are updated to
> return early if remote callback is detected. That is, this patch just
> moves the decision making down in the hierarchy.
>
> Later patches would enable remote callbacks for shared policies.
>
> Based on initial work from Steve Muckle.
>
> Signed-off-by: Viresh Kumar
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,10 +72,15 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>
> / Governor internals ***/
>
> -static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64
> time)
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64
> time,
> +int target_cpu)
> {
> s64 delta_ns;
>
> + /* Don't allow remote callbacks */
> + if (smp_processor_id() != target_cpu)
> + return false;
> +
> if (sg_policy->work_in_progress)
> return false;
>
> @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> - if (!sugov_should_update_freq(sg_policy, time))
> + if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> return;
Since with the remote callbacks now possible, isn't it unsafe to
modify sg_cpu and sg_policy structures without a lock in
sugov_update_single?
Unlike sugov_update_shared, we don't acquire any lock in
sugov_update_single before updating these structures. Did I miss
something?
thanks,
-Joel
Re: [PATCH 3/3] EDAC, ghes: Make it a proper module
On Wed, Jul 26, 2017 at 07:24:59PM +, Kani, Toshimitsu wrote: > Using sb_edac does not change the fact that it is FF. I do not think > you'd see normal CEs on your box. I guess we should add some blurb to EDAC to say that on FF systems, error counts are unreliable or even non-existent. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [PATCH v2 04/22] fpga: mgr: add region_id to fpga_image_info
On Wed, Jul 26, 2017 at 01:33:53PM -0500, Alan Tull wrote:
> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao wrote:
>
> Hi Hao,
>
> > This patch adds region_id to fpga_image_info data structure, it
> > allows driver to pass region id information to fpga-mgr via
> > fpga_image_info for fpga reconfiguration function.
> >
> > Signed-off-by: Wu Hao
> > ---
> > include/linux/fpga/fpga-mgr.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> > index 66d0e32..b222a57 100644
> > --- a/include/linux/fpga/fpga-mgr.h
> > +++ b/include/linux/fpga/fpga-mgr.h
> > @@ -95,6 +95,7 @@ struct fpga_image_info {
> > struct sg_table *sgt;
> > const char *buf;
> > size_t count;
> > + int region_id;
>
> Please add a line to document this region_id above where all the other
> struct members are documented.
Hi Alan
Thanks for the comments, I will fix this in the next version.
* @sgt: scatter/gather table containing FPGA image
* @buf: contiguous buffer containing FPGA image
* @count: size of buf
+ * @region_id: id of target region
* @overlay: Device Tree overlay
*/
struct fpga_image_info {
Thanks
Hao
>
> Alan
>
> > #ifdef CONFIG_OF
> > struct device_node *overlay;
> > #endif
> > --
> > 1.8.3.1
> >
Re: [PATCH 06/12] ima: added parser of digest lists metadata
Hi Roberto,
[auto build test ERROR on integrity/next]
[also build test ERROR on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from security/integrity/ima/ima_fs.c:27:0:
security/integrity/ima/ima.h: In function 'ima_parse_digest_list_metadata':
>> security/integrity/ima/ima.h:165:10: error: 'ENOTSUP' undeclared (first use
>> in this function)
return -ENOTSUP;
^~~
security/integrity/ima/ima.h:165:10: note: each undeclared identifier is
reported only once for each function it appears in
vim +/ENOTSUP +165 security/integrity/ima/ima.h
135
136 /* Internal IMA function definitions */
137 int ima_init(void);
138 int ima_fs_init(void);
139 int ima_add_template_entry(struct ima_template_entry *entry, int
violation,
140 const char *op, struct inode *inode,
141 const unsigned char *filename);
142 int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash);
143 int ima_calc_buffer_hash(const void *buf, loff_t len,
144 struct ima_digest_data *hash);
145 int ima_calc_field_array_hash(struct ima_field_data *field_data,
146struct ima_template_desc *desc, int
num_fields,
147struct ima_digest_data *hash);
148 int __init ima_calc_boot_aggregate(struct ima_digest_data *hash);
149 void ima_add_violation(struct file *file, const unsigned char *filename,
150 struct integrity_iint_cache *iint,
151 const char *op, const char *cause);
152 int ima_init_crypto(void);
153 void ima_putc(struct seq_file *m, void *data, int datalen);
154 void ima_print_digest(struct seq_file *m, u8 *digest, u32 size);
155 struct ima_template_desc *ima_template_desc_current(void);
156 int ima_restore_measurement_entry(struct ima_template_entry *entry);
157 int ima_restore_measurement_list(loff_t bufsize, void *buf);
158 struct ima_digest *ima_lookup_loaded_digest(u8 *digest);
159 int ima_add_digest_data_entry(u8 *digest);
160 #ifdef CONFIG_IMA_DIGEST_LIST
161 ssize_t ima_parse_digest_list_metadata(loff_t size, void *buf);
162 #else
163 static inline ssize_t ima_parse_digest_list_metadata(loff_t size, void
*buf)
164 {
> 165 return -ENOTSUP;
166 }
167 #endif
168 int ima_measurements_show(struct seq_file *m, void *v);
169 unsigned long ima_get_binary_runtime_size(void);
170 int ima_init_template(void);
171 void ima_init_template_list(void);
172
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v4 1/3] include: uapi: usb: Introduce USB charger type and state definition
Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.
Signed-off-by: Baolin Wang
---
include/uapi/linux/usb/charger.h | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 include/uapi/linux/usb/charger.h
diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+ UNKNOWN_TYPE,
+ SDP_TYPE,
+ DCP_TYPE,
+ CDP_TYPE,
+ ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+ USB_CHARGER_DEFAULT,
+ USB_CHARGER_PRESENT,
+ USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
--
1.7.9.5
[PATCH v4 2/3] usb: phy: Add USB charger support
This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.
Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.
we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().
Signed-off-by: Baolin Wang
---
drivers/usb/phy/phy.c | 272 +++
include/linux/usb/phy.h | 49 +
2 files changed, 321 insertions(+)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
#include
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
static LIST_HEAD(phy_list);
static LIST_HEAD(phy_bind_list);
static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node
*node)
return ERR_PTR(-EPROBE_DEFER);
}
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+ usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+ usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+ usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+ usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+ usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+ usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+ usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+ usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+ struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+ char uchger_state[50] = { 0 };
+ char *envp[] = { uchger_state, NULL };
+ unsigned int min, max;
+
+ switch (usb_phy->chg_state) {
+ case USB_CHARGER_PRESENT:
+ usb_phy_get_charger_current(usb_phy, &min, &max);
+
+ atomic_notifier_call_chain(&usb_phy->notifier, max, usb_phy);
+ snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+ break;
+ case USB_CHARGER_ABSENT:
+ usb_phy_set_default_current(usb_phy);
+
+ atomic_notifier_call_chain(&usb_phy->notifier, 0, usb_phy);
+ snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+ break;
+ default:
+ dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+ return;
+ }
+
+ kobject_uevent_env(&usb_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+ if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+ usb_phy->chg_type = SDP_TYPE;
+ usb_phy->chg_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+ usb_phy->chg_type = CDP_TYPE;
+ usb_phy->chg_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_DCP) > 0) {
+ usb_phy->chg_type = DCP_TYPE;
+ usb_phy->chg_state = USB_CHARGER_PRESENT;
+
[PATCH v4 3/3] power: wm831x_power: Support USB charger current limit management
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-by: Mark Brown
Signed-off-by: Baolin Wang
Acked-by: Lee Jones
Acked-by: Charles Keepax
---
Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
drivers/power/supply/wm831x_power.c | 72 ++
2 files changed, 73 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..4e3bc07 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
../interrupt-controller/interrupts.txt
Optional sub-nodes:
+ - usb-phy : Contains a phandle to the USB PHY.
- regulators : Contains sub-nodes for each of the regulators supplied by
the device. The regulators are bound using their names listed below:
diff --git a/drivers/power/supply/wm831x_power.c
b/drivers/power/supply/wm831x_power.c
index 7082301..dff6473 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+ struct usb_phy *usb_phy;
+ struct notifier_block usb_notify;
};
static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+ 0,
+ 2,
+ 100,
+ 500,
+ 900,
+ 1500,
+ 1800,
+ 550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+ unsigned long limit, void *data)
+{
+ struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+ unsigned int i, best;
+
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+ if (limit >= wm831x_usb_limits[i] &&
+ wm831x_usb_limits[best] < wm831x_usb_limits[i])
+ best = i;
+ }
+
+ dev_dbg(wm831x_power->wm831x->dev,
+ "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+ wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+ WM831X_USB_ILIM_MASK, best);
+
+ return 0;
+}
+
/*
* Battery properties
*/
@@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
+ power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
+ ret = PTR_ERR_OR_ZERO(power->usb_phy);
+
+ switch (ret) {
+ case 0:
+ power->usb_notify.notifier_call = wm831x_usb_limit_change;
+ ret = usb_register_notifier(power->usb_phy, &power->usb_notify);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to register notifier: %d\n",
+ ret);
+ goto err_bat_irq;
+ }
+ break;
+ case -EINVAL:
+ case -ENODEV:
+ /* ignore missing usb-phy, it's optional */
+ power->usb_phy = NULL;
+ ret = 0;
+ break;
+ default:
+ dev_err(&pdev->dev, "Failed to find USB phy: %d\n", ret);
+ /* fall-through */
+ case -EPROBE_DEFER:
+ goto err_bat_irq;
+ break;
+ }
+
return ret;
err_bat_irq:
@@ -637,6 +704,11 @@ static int wm831x_power_remove(struct platform_device
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
+ if (wm831x_power->usb_phy) {
+ usb_unregister_notifier(wm831x_power->usb_phy,
+ &wm831x_power->usb_notify);
+ }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x,
platform_get_irq_byname(pdev,
--
1.7.9.5
Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks
Hi Viresh, On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote: > > With Android UI and benchmarks the latency of cpufreq response to > certain scheduling events can become very critical. Currently, callbacks > into schedutil are only made from the scheduler if the target CPU of the > event is the same as the current CPU. This means there are certain > situations where a target CPU may not run schedutil for some time. > > One testcase to show this behavior is where a task starts running on > CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the > system is configured such that new tasks should receive maximum demand > initially, this should result in CPU0 increasing frequency immediately. > Because of the above mentioned limitation though this does not occur. > This is verified using ftrace with the sample [1] application. I think you dropped [1] in your cover-letter. May be you meant to add it at the end of the cover letter? I noticed from your v2 that its: https://pastebin.com/7LkMSRxE Also one more comment about this usecase: You mentioned in our discussion at [2] sometime back, about the question of initial utilization, "We don't have any such configurable way possible right now, but there were discussions on how much utilization should a new task be assigned when it first comes up." But, then in your cover letter above, you mentioned "This is verified using ftrace". So my question is how has this been verified with ftrace if the new initial utilization as you said in [2] is currently still under discussion? Basically how could you verify with ftrace that the target CPU frequency isn't increasing immediately on spawning of a new task remotely, if the initial utilization of a new task isn't something we set/configure with current code? Am I missing something? [2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html > > Maybe the ideal solution is to always allow remote callbacks but that > has its own challenges: > > o There is no protection required for single CPU per policy case today, > and adding any kind of locking there, to supply remote callbacks, > isn't really a good idea. > > o If is local CPU isn't part of the same cpufreq policy as the target > CPU, then we wouldn't be able to do fast switching at all and have to > use some kind of bottom half to schedule work on the target CPU to do > real switching. That may be overkill as well. > > > And so this series only allows remote callbacks for target CPUs that > share the cpufreq policy with the local CPU. > > This series is tested with couple of usecases (Android: hackbench, > recentfling, galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey > board (64 bit octa-core, single policy). Only galleryfling showed minor > improvements, while others didn't had much deviation. > > The reason being that this patchset only targets a corner case, where > following are required to be true to improve performance and that > doesn't happen too often with these tests: > > - Task is migrated to another CPU. > - The task has maximum demand initially, and should take the CPU to Just to make the cover-letter more clear and also confirming with you I understand the above usecase, maybe in the future this can reworded from "initially" to "before the migration" and "take the CPU" to "take the target CPU of the migration" ? > higher OPPs. > - And the target CPU doesn't call into schedutil until the next tick. I found this usecase to be more plausible and can see this patch series being useful there. Could you also keep me in CC on these patches (at joe...@google.com)? I'm interested in this series. thanks! -Joel
[PATCH v4 0/3] Introduce USB charger support in USB phy
Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Thus provide a standard USB charger support in USB phy core for doing this in kernel. Now introduce one user with wm831x_power to support and test the usb charger. In future we will also cnvert below power drivers: drivers/power/supply/axp288_charger.c drivers/power/supply/bq24190_charger.c drivers/power/supply/charger-manager.c drivers/power/supply/qcom_smbb.c Changes since v3: - Bail out errors when failed to find usb phy for wm831x_power driver. Changes since v2: - Add DT binding documentation for wm831x_power driver. - Change 'usb-phy' as one optional property for wm831x_power driver. Changes since v1: - Fix building errors. Baolin Wang (3): include: uapi: usb: Introduce USB charger type and state definition usb: phy: Add USB charger support power: wm831x_power: Support USB charger current limit management Documentation/devicetree/bindings/mfd/wm831x.txt |1 + drivers/power/supply/wm831x_power.c | 72 ++ drivers/usb/phy/phy.c| 272 ++ include/linux/usb/phy.h | 49 include/uapi/linux/usb/charger.h | 31 +++ 5 files changed, 425 insertions(+) create mode 100644 include/uapi/linux/usb/charger.h -- 1.7.9.5
Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters
On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote: > Also, if a given configuration disables CONFIG_EDAC there is some hackery > needed to get the perf portion of the driver included. Yes, and we don't do performance counters in EDAC. So you could add a small memory controller driver which does the arbitration or fix the firmware. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [RFT 2/2] ASoC: samsung: Add proper error paths to s3c24xx I2S driver
Hi,
On Thursday 27 July 2017 12:27 AM, Krzysztof Kozlowski wrote:
s3c2412_i2s_probe() might fail so driver has to revert work done by
s3c_i2sv2_probe() (clock enabling). Missing doing this would lead to
clock enable in-balance.
Signed-off-by: Krzysztof Kozlowski
---
Please, kindly test on S3C24xx hardware.
---
sound/soc/samsung/s3c-i2s-v2.c | 9 +
sound/soc/samsung/s3c-i2s-v2.h | 7 +++
sound/soc/samsung/s3c2412-i2s.c | 11 +--
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 9b28046eea8e..df83f2730a53 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -651,6 +651,15 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
}
EXPORT_SYMBOL_GPL(s3c_i2sv2_probe);
+void s3c_i2sv2_cleanup(struct snd_soc_dai *dai,
+ struct s3c_i2sv2_info *i2s)
+{
+ clk_disable(i2s->iis_pclk);
+ clk_put(i2s->iis_pclk);
+ i2s->iis_pclk = NULL;
+}
+EXPORT_SYMBOL_GPL(s3c_i2sv2_cleanup);
+
#ifdef CONFIG_PM
static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
{
diff --git a/sound/soc/samsung/s3c-i2s-v2.h b/sound/soc/samsung/s3c-i2s-v2.h
index 182d80564e37..3fca20f7a853 100644
--- a/sound/soc/samsung/s3c-i2s-v2.h
+++ b/sound/soc/samsung/s3c-i2s-v2.h
@@ -92,6 +92,13 @@ extern int s3c_i2sv2_probe(struct snd_soc_dai *dai,
unsigned long base);
/**
+ * s3c_i2sv2_cleanup - cleanup resources allocated in s3c_i2sv2_probe
+ * @dai: The ASoC DAI structure supplied to the original probe.
+ * @i2s: Our local i2s structure to fill in.
+ */
+extern void s3c_i2sv2_cleanup(struct snd_soc_dai *dai,
+ struct s3c_i2sv2_info *i2s);
+/**
* s3c_i2sv2_register_component - register component and dai with soc core
* @dev: DAI device
* @id: DAI ID
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index bcd1cbdeac93..005cd6db7d07 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,7 +65,8 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
- return PTR_ERR(s3c2412_i2s.iis_cclk);
+ ret = PTR_ERR(s3c2412_i2s.iis_cclk);
+ goto err;
}
/* Set MPLL as the source for IIS CLK */
@@ -73,7 +74,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));
we can use devm_clk_get for "mpll" clock.
ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
if (ret)
- return ret;
+ goto err;
s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;
Now s3c2412_i2s.iis_cclk and s3c2412_i2s.iis_pclk are holding "iis" clock.
Now no one handling "mpll" clock. If we will call s3c2412_i2s_remove.
It's means. we are disabling "iis" clock twice. Which is not correct.
@@ -82,11 +83,17 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
S3C_GPIO_PULL_NONE);
return 0;
+
+err:
+ s3c_i2sv2_cleanup(dai, &s3c2412_i2s);
+
+ return ret;
}
static int s3c2412_i2s_remove(struct snd_soc_dai *dai)
{
clk_disable_unprepare(s3c2412_i2s.iis_cclk);
+ s3c_i2sv2_cleanup(dai, &s3c2412_i2s);
here, We are disabling "iis" clock twice. please check my previous comment.
return 0;
}
~arvind
Warning: You tried to send an email with blocked content
The UCL E-Mail Virus Protection System has been triggered by a message you sent. One or more of the original e-mail attachments have been removed and replaced with this message. * The attachment may have contained a virus or malware * The attachment may have an extension of a type unacceptable for UCL Consider renaming the file extension (eg rename file.ext to file.ex_) to avoid this constraint. The recipient will be required to rename the file back to its original extension. -- UCL E-mail Virus Protection System serviced...@ucl.ac.uk Phone: +44 (0)20 767925000 Internal phone: 25000 --- Additional Information ---: Subject: Sender: linux-kernel@vger.kernel.org Time received: 7/27/2017 5:11:19 AM Message ID:<150113226780.2160.16068305012815993...@safaricombusiness.co.ke> Detections found: EMAIL_983639_j.iliffe.zipJS/Nemucod
blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage
Hi Jens,
I'm seeing the lockdep warning below on shutdown on a Power8 machine
using IPR.
If I'm reading it right it looks like the spin_lock() (non-irq) in
blk_mq_sched_insert_request() is the immediate cause.
Looking at blk_mq_requeue_work() (the caller), it is doing
spin_lock_irqsave(). So is switching blk_mq_sched_insert_request() to
spin_lock_irqsave() the right fix?
cheers
ipr 0001:08:00.0: shutdown
WARNING: inconsistent lock state
4.13.0-rc2-gcc6x-gf74c89b #1 Not tainted
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/28/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(&(&hctx->lock)->rlock){+.?...}, at: []
blk_mq_sched_dispatch_requests+0xa4/0x2a0
{SOFTIRQ-ON-W} state was registered at:
lock_acquire+0xec/0x2e0
_raw_spin_lock+0x44/0x70
blk_mq_sched_insert_request+0x88/0x1f0
blk_mq_requeue_work+0x108/0x180
process_one_work+0x310/0x800
worker_thread+0x88/0x520
kthread+0x164/0x1b0
ret_from_kernel_thread+0x5c/0x74
irq event stamp: 3572314
hardirqs last enabled at (3572314): []
_raw_spin_unlock_irqrestore+0x58/0xb0
hardirqs last disabled at (3572313): []
_raw_spin_lock_irqsave+0x3c/0x90
softirqs last enabled at (3572302): [] irq_enter+0x9c/0xe0
softirqs last disabled at (3572303): [] irq_exit+0x108/0x150
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&hctx->lock)->rlock);
lock(&(&hctx->lock)->rlock);
*** DEADLOCK ***
2 locks held by swapper/28/0:
#0: ((&ipr_cmd->timer)){+.-...}, at: []
call_timer_fn+0x10/0x4b0
#1: (rcu_read_lock){..}, at: []
__blk_mq_run_hw_queue+0xa0/0x2c0
stack backtrace:
CPU: 28 PID: 0 Comm: swapper/28 Not tainted 4.13.0-rc2-gcc6x-gf74c89b #1
Call Trace:
[c01fffe97550] [c0b50818] dump_stack+0xe8/0x160 (unreliable)
[c01fffe97590] [c01586d0] print_usage_bug+0x2d0/0x390
[c01fffe97640] [c0158f34] mark_lock+0x7a4/0x8e0
[c01fffe976f0] [c015a000] __lock_acquire+0x6a0/0x1a70
[c01fffe97860] [c015befc] lock_acquire+0xec/0x2e0
[c01fffe97930] [c0b71514] _raw_spin_lock+0x44/0x70
[c01fffe97960] [c05b60f4] blk_mq_sched_dispatch_requests+0xa4/0x2a0
[c01fffe979c0] [c05acac0] __blk_mq_run_hw_queue+0x100/0x2c0
[c01fffe97a00] [c05ad478] __blk_mq_delay_run_hw_queue+0x118/0x130
[c01fffe97a40] [c05ad61c] blk_mq_start_hw_queues+0x6c/0xa0
[c01fffe97a80] [c0797aac] scsi_kick_queue+0x2c/0x60
[c01fffe97aa0] [c0797cf0] scsi_run_queue+0x210/0x360
[c01fffe97b10] [c079b888] scsi_run_host_queues+0x48/0x80
[c01fffe97b40] [c07b6090] ipr_ioa_bringdown_done+0x70/0x1e0
[c01fffe97bc0] [c07bc860] ipr_reset_ioa_job+0x80/0xf0
[c01fffe97bf0] [c07b4d50] ipr_reset_timer_done+0xd0/0x100
[c01fffe97c30] [c01937bc] call_timer_fn+0xdc/0x4b0
[c01fffe97cf0] [c0193d08] expire_timers+0x178/0x330
[c01fffe97d60] [c01940c8] run_timer_softirq+0xb8/0x120
[c01fffe97de0] [c0b726a8] __do_softirq+0x168/0x6d8
[c01fffe97ef0] [c00df2c8] irq_exit+0x108/0x150
[c01fffe97f10] [c0017bf4] __do_irq+0x2a4/0x4a0
[c01fffe97f90] [c002da50] call_do_irq+0x14/0x24
[c007fad93aa0] [c0017e8c] do_IRQ+0x9c/0x140
[c007fad93af0] [c0008b98] hardware_interrupt_common+0x138/0x140
--- interrupt: 501 at .L1.42+0x0/0x4
LR = arch_local_irq_restore.part.4+0x84/0xb0
[c007fad93de0] [c007ffc1f7d8] 0xc007ffc1f7d8 (unreliable)
[c007fad93e00] [c0988d3c] cpuidle_enter_state+0x1bc/0x530
[c007fad93e60] [c01457cc] call_cpuidle+0x4c/0x90
[c007fad93e80] [c0145b28] do_idle+0x208/0x2f0
[c007fad93ef0] [c0145f8c] cpu_startup_entry+0x3c/0x50
[c007fad93f20] [c0042bc0] start_secondary+0x3b0/0x4b0
[c007fad93f90] [c000ac6c] start_secondary_prolog+0x10/0x14
Re: [greybus-dev] [PATCH] staging: greybus: Remove unnecessary platform_set_drvdata
On 26-07-17, 23:19, Amitoj Kaur Chawla wrote: > Unnecessary platform_set_drvdata() has been removed since the driver > core clears the driver data to NULL after device release or on > probe failure. There is no need to manually clear the device > driver data to NULL. > > The Coccinelle semantic patch used to make this change is as follows: > // > @@ > struct platform_device *pdev; > @@ > - platform_set_drvdata(pdev, NULL); > // > > Signed-off-by: Amitoj Kaur Chawla > --- > drivers/staging/greybus/arche-platform.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/staging/greybus/arche-platform.c > b/drivers/staging/greybus/arche-platform.c > index eced2d2..358b260 100644 > --- a/drivers/staging/greybus/arche-platform.c > +++ b/drivers/staging/greybus/arche-platform.c > @@ -607,7 +607,6 @@ static int arche_platform_remove(struct platform_device > *pdev) > device_remove_file(&pdev->dev, &dev_attr_state); > device_for_each_child(&pdev->dev, NULL, arche_remove_child); > arche_platform_poweroff_seq(arche_pdata); > - platform_set_drvdata(pdev, NULL); > > if (usb3613_hub_mode_ctrl(false)) > dev_warn(arche_pdata->dev, "failed to control hub device\n"); Acked-by: Viresh Kumar -- viresh
Re: [PATCH 08/12] ima: added parser for RPM data type
Hi Roberto,
[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
security/integrity/ima/ima_digest_list.c: In function 'ima_parse_rpm':
>> security/integrity/ima/ima_digest_list.c:147:4: warning: ignoring return
>> value of 'hex2bin', declared with attribute warn_unused_result
>> [-Wunused-result]
hex2bin(digest, datap, digest_len);
^
vim +/hex2bin +147 security/integrity/ima/ima_digest_list.c
98
99 static int ima_parse_rpm(loff_t size, void *buf)
100 {
101 void *bufp = buf, *bufendp = buf + size;
102 struct rpm_hdr *hdr = bufp;
103 u32 tags = be32_to_cpu(hdr->tags);
104 struct rpm_entryinfo *entry;
105 void *datap = bufp + sizeof(*hdr) + tags * sizeof(struct
rpm_entryinfo);
106 int digest_len = hash_digest_size[ima_hash_algo];
107 u8 digest[digest_len];
108 int ret, i, j;
109
110 const unsigned char rpm_header_magic[8] = {
111 0x8e, 0xad, 0xe8, 0x01, 0x00, 0x00, 0x00, 0x00
112 };
113
114 if (size < sizeof(*hdr)) {
115 pr_err("Missing RPM header\n");
116 return -EINVAL;
117 }
118
119 if (memcmp(bufp, rpm_header_magic, sizeof(rpm_header_magic))) {
120 pr_err("Invalid RPM header\n");
121 return -EINVAL;
122 }
123
124 bufp += sizeof(*hdr);
125
126 for (i = 0; i < tags && (bufp + sizeof(*entry)) <= bufendp;
127 i++, bufp += sizeof(*entry)) {
128 entry = bufp;
129
130 if (be32_to_cpu(entry->tag) != RPMTAG_FILEDIGESTS)
131 continue;
132
133 datap += be32_to_cpu(entry->offset);
134
135 for (j = 0; j < be32_to_cpu(entry->count) &&
136 datap < bufendp; j++) {
137 if (strlen(datap) == 0) {
138 datap++;
139 continue;
140 }
141
142 if (datap + digest_len * 2 + 1 > bufendp) {
143 pr_err("RPM header read at invalid
offset\n");
144 return -EINVAL;
145 }
146
> 147 hex2bin(digest, datap, digest_len);
148
149 ret = ima_add_digest_data_entry(digest);
150 if (ret < 0 && ret != -EEXIST)
151 return ret;
152
153 datap += digest_len * 2 + 1;
154 }
155
156 break;
157 }
158
159 return 0;
160 }
161
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
Add binding documentation for Allwinner V3s CSI.
Signed-off-by: Yong Deng
---
.../devicetree/bindings/media/sun6i-csi.txt| 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..f8d83f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,49 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+ - compatible: value must be "allwinner,sun8i-v3s-csi"
+ - reg: base address and size of the memory-mapped region.
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ csi1: csi@01cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+ clock-names = "ahb", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ csi1_ep: endpoint {
+ remote-endpoint = <&adv7611_ep>;
+ bus-width = <16>;
+ data-shift = <0>;
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+ };
+
--
1.8.3.1
[PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patch implement a v4l2 framework driver for it.
Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.
Signed-off-by: Yong Deng
---
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sun6i-csi/Makefile| 3 +
drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 +++
drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 ++
drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 +++
drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
drivers/media/platform/sun6i-csi/sun6i_video.c | 663 ++
drivers/media/platform/sun6i-csi/sun6i_video.h | 61 ++
10 files changed, 2520 insertions(+)
create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d1..8371a87 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
source "drivers/media/platform/rcar-vin/Kconfig"
source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sun6i-csi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..fb2459c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi/
diff --git a/drivers/media/platform/sun6i-csi/Kconfig
b/drivers/media/platform/sun6i-csi/Kconfig
new file mode 100644
index 000..314188a
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+ tristate "Allwinner V3s Camera Sensor Interface driver"
+ depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select VIDEOBUF2_DMA_CONTIG
+ select REGMAP_MMIO
+ select V4L2_FWNODE
+ ---help---
+ Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sun6i-csi/Makefile
b/drivers/media/platform/sun6i-csi/Makefile
new file mode 100644
index 000..a9b527b
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_csi.o sun6i_video.o sun6i_csi_v3s.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sun6i-csi/sun6i_csi.c
b/drivers/media/platform/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..7a4bf53
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,545 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "sun6i_csi.h"
+
+/*
+ * struct sun6i_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sun6i_graph_entity {
+ struct list_headlist;
+ struct device_node *node;
+ struct media_entity *entity;
+
+ struct v4l2_async_
[PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI
Signed-off-by: Yong Deng --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9826a91..b91fa27 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3686,6 +3686,14 @@ M: Jaya Kumar S: Maintained F: sound/pci/cs5535audio/ +CSI DRIVERS FOR ALLWINNER V3s +M: Yong Deng +L: linux-me...@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/platform/sun6i-csi/ +F: Documentation/devicetree/bindings/media/sun6i-csi.txt + CW1200 WLAN driver M: Solomon Peachy S: Maintained -- 1.8.3.1
Re: [PATCH] ASoC: samsung: s3c2412: cleanups / fixes for preparation of clocks.
Hi,
On Thursday 27 July 2017 12:42 AM, Krzysztof Kozlowski wrote:
On Thu, Jul 27, 2017 at 12:28:52AM +0530, Arvind Yadav wrote:
-Use devm_clk_get() to make cleanup paths more simple.
-clk_prepare_enable() can fail here and we must check its return value.
-Add s3c_i2sv2_remove cleanup function of s3c_i2sv2_probe.
-No need to iounmap. Here, mapping done by devm_ioremap_resource.
Signed-off-by: Arvind Yadav
Since I did not hear from you, I just sent fixes for these. We missed
each other by two minutes. :)
Anyway it is good to do one fix at a time, not everything in one commit.
You are changing here a lot so this should be split.
BTW, do you have the s3c24xx hardware? Can you test if issues spotted
here and in my patchset really happen?
Best regards,
Krzysztof
Please drop this patch. Sorry, I don't have s3c24xx hardware.
This is not available. :(
Thanks,
~arvind
---
sound/soc/samsung/s3c-i2s-v2.c | 19 ---
sound/soc/samsung/s3c-i2s-v2.h | 3 +++
sound/soc/samsung/s3c2412-i2s.c | 10 --
3 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 8f42dea..ab4899f 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -625,20 +625,24 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
{
struct device *dev = dai->dev;
unsigned int iismod;
+ int ret;
i2s->dev = dev;
/* record our i2s structure for later use in the callbacks */
snd_soc_dai_set_drvdata(dai, i2s);
- i2s->iis_pclk = clk_get(dev, "iis");
+ i2s->iis_pclk = devm_clk_get(dev, "iis");
if (IS_ERR(i2s->iis_pclk)) {
dev_err(dev, "failed to get iis_clock\n");
- iounmap(i2s->regs);
return -ENOENT;
}
- clk_enable(i2s->iis_pclk);
+ ret = clk_prepare_enable(i2s->iis_pclk);
+ if (ret) {
+ dev_err(dev, "failed to prepare iis_clock\n");
+ return ret;
+ }
/* Mark ourselves as in TXRX mode so we can run through our cleanup
* process without warnings. */
@@ -652,6 +656,15 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
}
EXPORT_SYMBOL_GPL(s3c_i2sv2_probe);
+int s3c_i2sv2_remove(struct snd_soc_dai *dai)
+{
+ struct s3c_i2sv2_info *i2s = to_info(dai);
+
+ clk_disable_unprepare(i2s->iis_pclk);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(s3c_i2sv2_remove);
+
#ifdef CONFIG_PM
static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
{
diff --git a/sound/soc/samsung/s3c-i2s-v2.h b/sound/soc/samsung/s3c-i2s-v2.h
index 182d805..d6844b9 100644
--- a/sound/soc/samsung/s3c-i2s-v2.h
+++ b/sound/soc/samsung/s3c-i2s-v2.h
@@ -91,6 +91,9 @@ extern int s3c_i2sv2_probe(struct snd_soc_dai *dai,
struct s3c_i2sv2_info *i2s,
unsigned long base);
+
+extern int s3c_i2sv2_remove(struct snd_soc_dai *dai);
+
/**
* s3c_i2sv2_register_component - register component and dai with soc core
* @dev: DAI device
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 0a47182..adfbd52d 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,13 +65,18 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
+ s3c_i2sv2_remove(dai);
return PTR_ERR(s3c2412_i2s.iis_cclk);
}
/* Set MPLL as the source for IIS CLK */
- clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));
- clk_prepare_enable(s3c2412_i2s.iis_cclk);
+ clk_set_parent(s3c2412_i2s.iis_cclk, devm_clk_get(dai->dev, "mpll"));
+ ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
+ if (ret) {
+ s3c_i2sv2_remove(dai);
+ return ret;
+ }
s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;
@@ -85,6 +90,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
static int s3c2412_i2s_remove(struct snd_soc_dai *dai)
{
clk_disable_unprepare(s3c2412_i2s.iis_cclk);
+ s3c_i2sv2_remove(dai);
return 0;
}
--
2.7.4
[PATCH v2 0/3] Initial Allwinner V3s CSI Support
Sorry for resend the patch. Delivering to somebody in cc has failed at last time. This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface and CSI1 is used for parallel interface. This is not documented in datasheet but by testing and guess. This patchset implement a v4l2 framework driver and add a binding documentation for it. Currently, the driver only support the parallel interface. And has been tested with a BT1120 signal which generating from FPGA. The following fetures are not support with this patchset: - ISP - MIPI-CSI2 - Master clock for camera sensor - Power regulator for the front end IC sun6i_csi_ops is still there. I seriously thought about it. Without sun6i_csi_ops, the dependency between sun6i_video and sun6i_csi_v3s will be complicated. Comments and criticisms are welcome. Changes in v2: * Change sunxi-csi to sun6i-csi * Rebase to media_tree master branch Yong Deng (3): media: V3s: Add support for Allwinner CSI. dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI) media: MAINTAINERS: add entries for Allwinner V3s CSI .../devicetree/bindings/media/sun6i-csi.txt| 49 ++ MAINTAINERS| 8 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/sun6i-csi/Kconfig | 9 + drivers/media/platform/sun6i-csi/Makefile | 3 + drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 ++ drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 + drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 + drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 + drivers/media/platform/sun6i-csi/sun6i_video.c | 663 + drivers/media/platform/sun6i-csi/sun6i_video.h | 61 ++ 12 files changed, 2577 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt create mode 100644 drivers/media/platform/sun6i-csi/Kconfig create mode 100644 drivers/media/platform/sun6i-csi/Makefile create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h -- 1.8.3.1
Re: [PATCH 02/16] fpga: add FPGA device framework
On Wed, Jul 26, 2017 at 05:29:11PM -0500, Alan Tull wrote: > On Wed, Jul 26, 2017 at 9:20 AM, Alan Tull wrote: > > On Wed, Jul 26, 2017 at 4:50 AM, Wu Hao wrote: > >> On Tue, Jul 25, 2017 at 04:32:10PM -0500, Alan Tull wrote: > >>> On Sat, Apr 1, 2017 at 7:18 AM, Wu Hao wrote: > >>> > >>> Hi Hao, > >>> > >>> > On Fri, Mar 31, 2017 at 12:01:13PM -0700, > >>> > matthew.gerl...@linux.intel.com wrote: > >>> >> On Fri, 31 Mar 2017, Wu Hao wrote: > >>> >> >On Fri, Mar 31, 2017 at 08:09:09AM +0200, Greg KH wrote: > >>> >> >>On Thu, Mar 30, 2017 at 08:08:02PM +0800, Wu Hao wrote: > >>> >> >>>During FPGA device (e.g PCI-based) discovery, platform devices are > >>> >> >>>registered for different FPGA function units. But the device node > >>> >> >>>path > >>> >> >>>isn't quite friendly to applications. > >>> >> >>> > >>> >> >>>Consider this case, applications want to access child device's > >>> >> >>>sysfs file > >>> >> >>>for some information. > >>> >> >>> > >>> >> >>>1) Access using bus-based path (e.g PCI) > >>> >> >>> > >>> >> >>> /sys/bus/pci/devices/x/fpga_func_a.0/sysfs_file > >>> >> >>> > >>> >> >>> From the path, it's clear which PCI device is the parent, but not > >>> >> >>> perfect > >>> >> >>> solution for applications. PCI device BDF is not fixed, > >>> >> >>> application may > >>> >> >>> need to search all PCI device to find the actual FPGA Device. > >>> >> >>> > >>> >> >>>2) Or access using platform device path > >>> >> >>> > >>> >> >>> /sys/bus/platform/devices/fpga_func_a.0/sysfs_file > >>> >> >>> > >>> >> >>> Applications find the actual function by name easily, but no > >>> >> >>> information > >>> >> >>> about which fpga device it belongs to. It's quite confusing if > >>> >> >>> multiple > >>> >> >>> FPGA devices are in one system. > >>> >> >>> > >>> >> >>>'FPGA Device' class is introduced to resolve this problem. Each > >>> >> >>>node under > >>> >> >>>this class represents a fpga device, which may have one or more > >>> >> >>>child > >>> >> >>>devices. Applications only need to search under this FPGA Device > >>> >> >>>class > >>> >> >>>folder to find the child device node it needs. > >>> >> >>> > >>> >> >>>For example, for the platform has 2 fpga devices, each fpga device > >>> >> >>>has > >>> >> >>>3 child devices, the hierarchy looks like this. > >>> >> >>> > >>> >> >>>Two nodes are under /sys/class/fpga/: > >>> >> >>>/sys/class/fpga/fpga.0 > >>> >> >>>/sys/class/fpga/fpga.1 > >>> >> >>> > >>> >> >>>Each node has 1 function A device and 2 function B devices: > >>> >> >>>/sys/class/fpga/fpga.0/func_a.0 > >>> >> >>>/sys/class/fpga/fpga.0/func_b.0 > >>> >> >>>/sys/class/fpga/fpga.0/func_b.1 > >>> >> >>> > >>> >> >>>/sys/class/fpga/fpga.1/func_a.1 > >>> >> >>>/sys/class/fpga/fpga.1/func_b.2 > >>> >> >>>/sys/class/fpga/fpga.1/func_b.3 > >>> >> >>> > >>> >> >>>This following APIs are provided by FPGA device framework: > >>> >> >>>* fpga_dev_create > >>> >> >>> Create fpga device under the given parent device. > >>> >> >>>* fpga_dev_destroy > >>> >> >>> Destroy fpga device > >>> >> >>> > >>> >> >>>The following sysfs files are created: > >>> >> >>>* /sys/class/fpga//name > >>> >> >>> Name of the fpga device. > >>> >> >> > >>> >> >>How does this interact with the existing "fpga class" that is in the > >>> >> >>kernel already? > >>> >> > > >>> >> >The fpga-dev introduced by this patch, is only a container device, and > >>> >> > >>> >> I completely understand the need for a container device. The > >>> >> fpga-region is > >>> >> also primarily a container, and in some cases the fpga-region may > >>> >> represent > >>> >> the entire fpga. Over time this code may become redundant. > >>> > > >>> > Thanks a lot for your review and comments. > >>> > > >>> > I feel that the fpga-region implies that it supports reconfiguration, > >>> > >>> On Arria10, we create base fpga region which does not support full > >>> reconfiguration. It corresponds to the whole FPGA area, which was > >>> loaded with a static FPGA image in the bootloader. The partial > >>> reconfiguration regions are children of the base FPGA region. Any > >>> devices in the FPGA are child devices of either the base region or a > >>> region which is a child of it. > >>> > >>> > but > >>> > in our cases, the Intel FPGA device, doesn't have base fpga-region for > >>> > full reconfiguration, but many accelerators with partial reconfiguration > >>> > support. A fpga-region brings together everything needed for the > >>> > reconfiguration, and a fpga-dev is trying to brings everything on a FPGA > >>> > device together, including fpga-region/bridge/manager, access different > >>> > accelerators and other function units. > >>> > > >>> > I think it's not mandatory to use fpga-dev, as fpga-dev is just trying > >>> > to > >>> > provide one more option here for some complex hardware. > >>> > >>> Now that you've put out v2 which uses fpga-regions, do you still need > >>> fpga-dev class? > >> > >> Hi Alan > >> > >> Thanks for
Re: [PATCH 4/6] dma: bcm-sba-raid: Break sba_process_deferred_requests() into two parts
On Wed, Jul 26, 2017 at 10:45 PM, Vinod Koul wrote:
> On Wed, Jul 26, 2017 at 11:06:42AM +0530, Anup Patel wrote:
>> This patch breaks sba_process_deferred_requests() into two parts
>> sba_process_received_request() and _sba_process_pending_requests()
>> for readability.
>>
>> In addition,
>
> that should be a separate patch then... no?
>
>> we remove redundant SBA_REQUEST_STATE_RECEIVED state
>
> this should be one more...
OK, I will make this separate patch.
>
>> and ensure that all requests in a chained request should be freed
>> only after all have been received.
>
> and then this, right?
OK.
>
>>
>> Signed-off-by: Anup Patel
>> Reviewed-by: Scott Branden
>> ---
>> drivers/dma/bcm-sba-raid.c | 130
>> -
>> 1 file changed, 47 insertions(+), 83 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index db5e3db..b92c756 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -97,9 +97,8 @@ enum sba_request_flags {
>> SBA_REQUEST_STATE_ALLOCED = 0x002,
>> SBA_REQUEST_STATE_PENDING = 0x004,
>> SBA_REQUEST_STATE_ACTIVE= 0x008,
>> - SBA_REQUEST_STATE_RECEIVED = 0x010,
>> - SBA_REQUEST_STATE_COMPLETED = 0x020,
>> - SBA_REQUEST_STATE_ABORTED = 0x040,
>> + SBA_REQUEST_STATE_COMPLETED = 0x010,
>> + SBA_REQUEST_STATE_ABORTED = 0x020,
>
> so we changed this is patch 1, only to change it here. why
>
> so let me stop here again and repeat myself again about splitting stuff up,
> blah blah, good patches, blah blah, read the Documentation blah blah.. and
> hope someones listening :(
OK, I will address your comments.
Regards,
Anup
Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel
On Thu, Jul 27, 2017 at 9:25 AM, Anup Patel wrote:
> On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar wrote:
>> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel wrote:
>>> On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar
>>> wrote:
On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel
wrote:
> Hi Jassi,
>
> Sorry for the delayed response...
>
> On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar
> wrote:
>> Hi Anup,
>>
>> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel
>> wrote:
>>> The Broadcom FlexRM ring (i.e. mailbox channel) can handle
>>> larger number of messages queued in one FlexRM ring hence
>>> this patch sets msg_queue_len for each mailbox channel to
>>> be same as RING_MAX_REQ_COUNT.
>>>
>>> Signed-off-by: Anup Patel
>>> Reviewed-by: Scott Branden
>>> ---
>>> drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c
>>> b/drivers/mailbox/bcm-flexrm-mailbox.c
>>> index 9873818..20055a0 100644
>>> --- a/drivers/mailbox/bcm-flexrm-mailbox.c
>>> +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
>>> @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct
>>> platform_device *pdev)
>>> ret = -ENOMEM;
>>> goto fail_free_debugfs_root;
>>> }
>>> - for (index = 0; index < mbox->num_rings; index++)
>>> + for (index = 0; index < mbox->num_rings; index++) {
>>> + mbox->controller.chans[index].msg_queue_len =
>>> + RING_MAX_REQ_COUNT;
>>> mbox->controller.chans[index].con_priv =
>>> &mbox->rings[index];
>>> + }
>>>
>> While writing mailbox.c I wasn't unaware that there is the option to
>> choose the queue length at runtime.
>> The idea was to keep the code as simple as possible. I am open to
>> making it a runtime thing, but first, please help me understand how
>> that is useful here.
>>
>> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
>> elements. Any message submitted to mailbox api can be immediately
>> written onto the ringbuffer if there is some space.
>> Is there any mechanism to report back to a client driver, if its
>> message in ringbuffer failed "to be sent"?
>> If there isn't any, then I think, in flexrm_last_tx_done() you should
>> simply return true if there is some space left in the rung-buffer,
>> false otherwise.
>
> Yes, we have error code in "struct brcm_message" to report back
> errors from send_message. In our mailbox clients, we check
> return value of mbox_send_message() and also the error code
> in "struct brcm_message".
>
I meant after the message has been accepted in the ringbuffer but the
remote failed to receive it.
>>>
>>> Yes, even this case is handled.
>>>
>>> In case of IO errors after message has been put in ring buffer, we get
>>> completion message with error code and mailbox client drivers will
>>> receive back "struct brcm_message" with error set.
>>>
>>> You can refer flexrm_process_completions() for more details.
>>>
It doesn't seem to be what I suggest. I see two issues in
flexrm_process_completions()
1) It calls mbox_send_message(), which is a big NO for a controller
driver. Why should you have one more message stored outside of
ringbuffer?
2) It calls mbox_chan_received_data() which is for messages received
from the remote. And not the way to report failed _transmission_, for
which the api calls back mbox_client.tx_done() . In your client
driver please populate mbox_client.tx_done() and see which message is
reported "sent fine" when.
There seems no such provision. IIANW, then you should be able to
consider every message as "sent successfully" once it is in the ring
buffer i.e, immediately after mbox_send_message() returns 0.
In that case I would think you don't need more than a couple of
entries out of MBOX_TX_QUEUE_LEN ?
>>>
>>> What I am trying to suggest is that we can take upto 1024 messages
>>> in a FlexRM ring but the MBOX_TX_QUEUE_LEN limits us queuing
>>> more messages. This issue manifest easily when multiple CPUs
>>> queues to same FlexRM ring (i.e. same mailbox channel).
>>>
>> OK then, I guess we have to make the queue length a runtime decision.
>
> Do you agree with approach taken by PATCH5 and PATCH6 to
> make queue length runtime?
>
I agree that we may have to get the queue length from platform, if
MBOX_TX_QUEUE_LEN is limiting performance. That will be easier on both
of us. However I suspect the right fix for _this_ situation is in
flexrm driver. See above.
>>
>> BTW, is it a practical use case that needs to queue upto 1024
>> requests? Or are you just testing?
>
> Yes, we just need bigger queue length for FlexRM but we
> choose 1024 (max lim
Re: [PATCH 2/6] dma: bcm-sba-raid: Peek mbox when we are left with no free requests
On Wed, Jul 26, 2017 at 10:40 PM, Vinod Koul wrote: > On Wed, Jul 26, 2017 at 11:06:40AM +0530, Anup Patel wrote: >> We should peek mbox channels when we are left with no free >> sba_requests in sba_alloc_request() > > and why is the world should we do that, how does that help?? When setting up RAID array on several NVMe disk we observed that sba_alloc_request() start failing (due to no free requests left) and RAID array setup becomes very slow. Doing mbox channel peek when we have no free requests left, improves performance of RAID array setup. This change is inspired from mv_chan_alloc_slot() implemented in drivers/dma/mv_xor.c Regards, Anup
Re: [PATCH 1/6] dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver
On Wed, Jul 26, 2017 at 10:39 PM, Vinod Koul wrote:
> On Wed, Jul 26, 2017 at 11:06:39AM +0530, Anup Patel wrote:
>> This patch improves memory allocation in SBA RAID driver in
>> following ways:
>> 1. Simplify struct sba_request to reduce memory consumption
>
> what is the simplification?? You need to document that
OK, will make it a separate patch with detailed commit description.
>
>> 2. Allocate sba resources before registering dma device
>
> what is the motivation for that
>
> So, reading this log doesnt help me to know what to expect in this patch
OK, this also requires separate patch with detailed commit description.
>
>>
>> Signed-off-by: Anup Patel
>> Reviewed-by: Scott Branden
>> Reviewed-by: Ray Jui
>> Reviewed-by: Vikram Prakash
>> ---
>> drivers/dma/bcm-sba-raid.c | 439
>> +++--
>> 1 file changed, 226 insertions(+), 213 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index e41bbc7..6d15fed 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -48,7 +48,8 @@
>>
>> #include "dmaengine.h"
>>
>> -/* SBA command related defines */
>> +/* == Driver macros and defines = */
>
> why this noise, seems unrelated to the change!
This is just minor beautification. Again, I will put this
in separate patch.
>
>> +
>> #define SBA_TYPE_SHIFT 48
>> #define SBA_TYPE_MASKGENMASK(1, 0)
>> #define SBA_TYPE_A 0x0
>> @@ -82,39 +83,41 @@
>> #define SBA_CMD_WRITE_BUFFER 0xc
>> #define SBA_CMD_GALOIS 0xe
>>
>> -/* Driver helper macros */
>> +#define SBA_MAX_REQ_PER_MBOX_CHANNEL 8192
>> +
>> #define to_sba_request(tx) \
>> container_of(tx, struct sba_request, tx)
>> #define to_sba_device(dchan) \
>> container_of(dchan, struct sba_device, dma_chan)
>>
>> -enum sba_request_state {
>> - SBA_REQUEST_STATE_FREE = 1,
>> - SBA_REQUEST_STATE_ALLOCED = 2,
>> - SBA_REQUEST_STATE_PENDING = 3,
>> - SBA_REQUEST_STATE_ACTIVE = 4,
>> - SBA_REQUEST_STATE_RECEIVED = 5,
>> - SBA_REQUEST_STATE_COMPLETED = 6,
>> - SBA_REQUEST_STATE_ABORTED = 7,
>> +/* = Driver data structures = */
>> +
>> +enum sba_request_flags {
>> + SBA_REQUEST_STATE_FREE = 0x001,
>> + SBA_REQUEST_STATE_ALLOCED = 0x002,
>> + SBA_REQUEST_STATE_PENDING = 0x004,
>> + SBA_REQUEST_STATE_ACTIVE= 0x008,
>> + SBA_REQUEST_STATE_RECEIVED = 0x010,
>> + SBA_REQUEST_STATE_COMPLETED = 0x020,
>> + SBA_REQUEST_STATE_ABORTED = 0x040,
>> + SBA_REQUEST_STATE_MASK = 0x0ff,
>> + SBA_REQUEST_FENCE = 0x100,
>
> how does this help in mem alloctn?
>
>> };
>>
>> struct sba_request {
>> /* Global state */
>> struct list_head node;
>> struct sba_device *sba;
>> - enum sba_request_state state;
>> - bool fence;
>> + u32 flags;
>> /* Chained requests management */
>> struct sba_request *first;
>> struct list_head next;
>> - unsigned int next_count;
>> atomic_t next_pending_count;
>> /* BRCM message data */
>> - void *resp;
>> - dma_addr_t resp_dma;
>> - struct brcm_sba_command *cmds;
>> struct brcm_message msg;
>> struct dma_async_tx_descriptor tx;
>> + /* SBA commands */
>> + struct brcm_sba_command cmds[0];
>> };
>>
>> enum sba_version {
>> @@ -128,11 +131,11 @@ struct sba_device {
>> /* DT configuration parameters */
>> enum sba_version ver;
>> /* Derived configuration parameters */
>> - u32 max_req;
>> u32 hw_buf_size;
>> u32 hw_resp_size;
>> u32 max_pq_coefs;
>> u32 max_pq_srcs;
>> + u32 max_req;
>> u32 max_cmd_per_req;
>> u32 max_xor_srcs;
>> u32 max_resp_pool_size;
>> @@ -152,7 +155,6 @@ struct sba_device {
>> void *cmds_base;
>> dma_addr_t cmds_dma_base;
>> spinlock_t reqs_lock;
>> - struct sba_request *reqs;
>> bool reqs_fence;
>> struct list_head reqs_alloc_list;
>> struct list_head reqs_pending_list;
>> @@ -161,10 +163,9 @@ struct sba_device {
>> struct list_head reqs_completed_list;
>> struct list_head reqs_aborted_list;
>> struct list_head reqs_free_list;
>> - int reqs_free_count;
>> };
>>
>> -/* == SBA command helper routines = */
>> +/* == Command helper routines = */
>
> more noise..
>
>>
>> static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>> {
>> @@ -196,7 +197,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32
>> b1, u32 b0)
>> ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>> }
>>
>> -/* == Channel resource management routines = */
>> +/* == General helper routines = */
Re: [PATCH 0/6] Broadcom SBA-RAID driver improvements
On Wed, Jul 26, 2017 at 10:33 PM, Vinod Koul wrote: > On Wed, Jul 26, 2017 at 11:06:38AM +0530, Anup Patel wrote: >> This patchset does various improvments to Broadcom SBA-RAID >> driver and also adds SBA-RAID DT nodes for Stingray SOC. >> >> The patches are based on "[PATCH v2 0/7] FlexRM driver improvements" >> and can also be found at sba-raid-imp-v1 branch of >> https://github.com/Broadcom/arm64-linux.git > > and i cant apply this series without these? The dependency is only because of last DT patch for stingray. We are going to separate patchset for Stingray DT changes so I will drop PATCH6 and have this part of Stingray DT patchset. > >> >> Anup Patel (6): >> dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver >> dma: bcm-sba-raid: Peek mbox when we are left with no free requests >> dma: bcm-sba-raid: pre-ack async tx descriptor >> dma: bcm-sba-raid: Break sba_process_deferred_requests() into two >> parts >> dma: bcm-sba-raid: Add debugfs support > > why are these tagged dma, I have told you explcitly to fix this!! Sure, I will remove "dma:" tag in next revision. Regards, Anup
Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel
On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar wrote:
> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel wrote:
>> On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar
>> wrote:
>>> On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel wrote:
Hi Jassi,
Sorry for the delayed response...
On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar
wrote:
> Hi Anup,
>
> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel
> wrote:
>> The Broadcom FlexRM ring (i.e. mailbox channel) can handle
>> larger number of messages queued in one FlexRM ring hence
>> this patch sets msg_queue_len for each mailbox channel to
>> be same as RING_MAX_REQ_COUNT.
>>
>> Signed-off-by: Anup Patel
>> Reviewed-by: Scott Branden
>> ---
>> drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c
>> b/drivers/mailbox/bcm-flexrm-mailbox.c
>> index 9873818..20055a0 100644
>> --- a/drivers/mailbox/bcm-flexrm-mailbox.c
>> +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
>> @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct
>> platform_device *pdev)
>> ret = -ENOMEM;
>> goto fail_free_debugfs_root;
>> }
>> - for (index = 0; index < mbox->num_rings; index++)
>> + for (index = 0; index < mbox->num_rings; index++) {
>> + mbox->controller.chans[index].msg_queue_len =
>> + RING_MAX_REQ_COUNT;
>> mbox->controller.chans[index].con_priv =
>> &mbox->rings[index];
>> + }
>>
> While writing mailbox.c I wasn't unaware that there is the option to
> choose the queue length at runtime.
> The idea was to keep the code as simple as possible. I am open to
> making it a runtime thing, but first, please help me understand how
> that is useful here.
>
> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
> elements. Any message submitted to mailbox api can be immediately
> written onto the ringbuffer if there is some space.
> Is there any mechanism to report back to a client driver, if its
> message in ringbuffer failed "to be sent"?
> If there isn't any, then I think, in flexrm_last_tx_done() you should
> simply return true if there is some space left in the rung-buffer,
> false otherwise.
Yes, we have error code in "struct brcm_message" to report back
errors from send_message. In our mailbox clients, we check
return value of mbox_send_message() and also the error code
in "struct brcm_message".
>>> I meant after the message has been accepted in the ringbuffer but the
>>> remote failed to receive it.
>>
>> Yes, even this case is handled.
>>
>> In case of IO errors after message has been put in ring buffer, we get
>> completion message with error code and mailbox client drivers will
>> receive back "struct brcm_message" with error set.
>>
>> You can refer flexrm_process_completions() for more details.
>>
>>> There seems no such provision. IIANW, then you should be able to
>>> consider every message as "sent successfully" once it is in the ring
>>> buffer i.e, immediately after mbox_send_message() returns 0.
>>> In that case I would think you don't need more than a couple of
>>> entries out of MBOX_TX_QUEUE_LEN ?
>>
>> What I am trying to suggest is that we can take upto 1024 messages
>> in a FlexRM ring but the MBOX_TX_QUEUE_LEN limits us queuing
>> more messages. This issue manifest easily when multiple CPUs
>> queues to same FlexRM ring (i.e. same mailbox channel).
>>
> OK then, I guess we have to make the queue length a runtime decision.
Do you agree with approach taken by PATCH5 and PATCH6 to
make queue length runtime?
>
> BTW, is it a practical use case that needs to queue upto 1024
> requests? Or are you just testing?
Yes, we just need bigger queue length for FlexRM but we
choose 1024 (max limit) to avoid changing it again in future.
Regards,
Anup
[PATCH v2 0/3] Initial Allwinner V3s CSI Support
This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface and CSI1 is used for parallel interface. This is not documented in datasheet but by testing and guess. This patchset implement a v4l2 framework driver and add a binding documentation for it. Currently, the driver only support the parallel interface. And has been tested with a BT1120 signal which generating from FPGA. The following fetures are not support with this patchset: - ISP - MIPI-CSI2 - Master clock for camera sensor - Power regulator for the front end IC sun6i_csi_ops is still there. I seriously thought about it. Without sun6i_csi_ops, the dependency between sun6i_video and sun6i_csi_v3s will be complicated. Comments and criticisms are welcome. Changes in v2: * Change sunxi-csi to sun6i-csi * Rebase to media_tree master branch Yong Deng (3): media: V3s: Add support for Allwinner CSI. dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI) media: MAINTAINERS: add entries for Allwinner V3s CSI .../devicetree/bindings/media/sun6i-csi.txt| 49 ++ MAINTAINERS| 8 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/sun6i-csi/Kconfig | 9 + drivers/media/platform/sun6i-csi/Makefile | 3 + drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 ++ drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 + drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 + drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 + drivers/media/platform/sun6i-csi/sun6i_video.c | 663 + drivers/media/platform/sun6i-csi/sun6i_video.h | 61 ++ 12 files changed, 2577 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt create mode 100644 drivers/media/platform/sun6i-csi/Kconfig create mode 100644 drivers/media/platform/sun6i-csi/Makefile create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h -- 1.8.3.1
[PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
Add binding documentation for Allwinner V3s CSI.
Signed-off-by: Yong Deng
---
.../devicetree/bindings/media/sun6i-csi.txt| 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..f8d83f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,49 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+ - compatible: value must be "allwinner,sun8i-v3s-csi"
+ - reg: base address and size of the memory-mapped region.
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ csi1: csi@01cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+ clock-names = "ahb", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ csi1_ep: endpoint {
+ remote-endpoint = <&adv7611_ep>;
+ bus-width = <16>;
+ data-shift = <0>;
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+ };
+
--
1.8.3.1
[PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patch implement a v4l2 framework driver for it.
Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.
Signed-off-by: Yong Deng
---
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sun6i-csi/Makefile| 3 +
drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 +++
drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 ++
drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 +++
drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
drivers/media/platform/sun6i-csi/sun6i_video.c | 663 ++
drivers/media/platform/sun6i-csi/sun6i_video.h | 61 ++
10 files changed, 2520 insertions(+)
create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d1..8371a87 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
source "drivers/media/platform/rcar-vin/Kconfig"
source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sun6i-csi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..fb2459c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi/
diff --git a/drivers/media/platform/sun6i-csi/Kconfig
b/drivers/media/platform/sun6i-csi/Kconfig
new file mode 100644
index 000..314188a
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+ tristate "Allwinner V3s Camera Sensor Interface driver"
+ depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select VIDEOBUF2_DMA_CONTIG
+ select REGMAP_MMIO
+ select V4L2_FWNODE
+ ---help---
+ Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sun6i-csi/Makefile
b/drivers/media/platform/sun6i-csi/Makefile
new file mode 100644
index 000..a9b527b
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_csi.o sun6i_video.o sun6i_csi_v3s.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sun6i-csi/sun6i_csi.c
b/drivers/media/platform/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..7a4bf53
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,545 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "sun6i_csi.h"
+
+/*
+ * struct sun6i_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sun6i_graph_entity {
+ struct list_headlist;
+ struct device_node *node;
+ struct media_entity *entity;
+
+ struct v4l2_async_
Re: [PATCH] cpufreq: intel_pstate: Drop ->get from intel_pstate structure
On 26-07-17, 00:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The ->get callback in the intel_pstate structure was mostly there
> for the scaling_cur_freq sysfs attribute to work, but after commit
> f8475cef9008 (x86: use common aperfmperf_khz_on_cpu() to calculate
> KHz using APERF/MPERF) that attribute uses arch_freq_get_on_cpu()
> provided by the x86 arch code on all processors supported by
> intel_pstate, so it doesn't need the ->get callback from the
> driver any more.
>
> Moreover, the very presence of the ->get callback in the intel_pstate
> structure causes the cpuinfo_cur_freq attribute to be present when
> intel_pstate operates in the active mode, which is bogus, because
> the role of that attribute is to return the current CPU frequency
> as seen by the hardware. For intel_pstate, though, this is just an
> average frequency and not really current, but computed for the
> previous sampling interval (the actual current frequency may be
> way different at the point this value is obtained by reading from
> cpuinfo_cur_freq), and after commit 82b4e03e01bc (intel_pstate: skip
> scheduler hook when in "performance" mode) the value in
> cpuinfo_cur_freq may be stale or just 0, depending on the driver's
> operation mode. In fact, however, on the hardware supported by
> intel_pstate there is no way to read the current CPU frequency
> from it, so the cpuinfo_cur_freq attribute should not be present
> at all when this driver is in use.
>
> For this reason, drop intel_pstate_get() and clear the ->get
> callback pointer pointing to it, so that the cpuinfo_cur_freq is
> not present for intel_pstate in the active mode any more.
>
> Fixes: 82b4e03e01bc (intel_pstate: skip scheduler hook when in "performance"
> mode)
> Reported-by: Huaisheng Ye
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/intel_pstate.c |8
> 1 file changed, 8 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -1674,13 +1674,6 @@ static int intel_pstate_init_cpu(unsigne
> return 0;
> }
>
> -static unsigned int intel_pstate_get(unsigned int cpu_num)
> -{
> - struct cpudata *cpu = all_cpu_data[cpu_num];
> -
> - return cpu ? get_avg_frequency(cpu) : 0;
> -}
> -
> static void intel_pstate_set_update_util_hook(unsigned int cpu_num)
> {
> struct cpudata *cpu = all_cpu_data[cpu_num];
> @@ -1921,7 +1914,6 @@ static struct cpufreq_driver intel_pstat
> .setpolicy = intel_pstate_set_policy,
> .suspend= intel_pstate_hwp_save_state,
> .resume = intel_pstate_resume,
> - .get= intel_pstate_get,
> .init = intel_pstate_cpu_init,
> .exit = intel_pstate_cpu_exit,
> .stop_cpu = intel_pstate_stop_cpu,
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH] cpufreq: docs: Add missing cpuinfo_cur_freq description
On 27-07-17, 02:05, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Add a description of the cpuinfo_cur_freq policy attribute in sysfs > to the cpufreq documentation under Documentation/admin-guide/pm/ as > it is missing after commit 2a0e49279850 (cpufreq: User/admin > documentation update and consolidation) that overlooked it. > > Fixes: 2a0e49279850 (cpufreq: User/admin documentation update and > consolidation) > Signed-off-by: Rafael J. Wysocki > --- > Documentation/admin-guide/pm/cpufreq.rst |8 > 1 file changed, 8 insertions(+) > > Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst > === > --- linux-pm.orig/Documentation/admin-guide/pm/cpufreq.rst > +++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst > @@ -237,6 +237,14 @@ are the following: > This attribute is not present if the scaling driver in use does not > support it. > > +``cpuinfo_cur_freq`` > + Current frequency of the CPUs belonging to this policy as obtained from > + the hardware (in KHz). > + > + This is expected to be the frequency the hardware actually runs at. > + If that frequency cannot be determined, this attribute should not > + be present. > + > ``cpuinfo_max_freq`` > Maximum possible operating frequency the CPUs belonging to this policy > can run at (in kHz). Acked-by: Viresh Kumar -- viresh
Re: [PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller
On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee
>
> Add support for MediaTek new generation controller and update related
> properities.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Honghui Zhang
> ---
> .../devicetree/bindings/pci/mediatek-pcie.txt | 168
> -
> 1 file changed, 161 insertions(+), 7 deletions(-)
>
Sorry for the disturb, I send the wrong patch from my local version for
this patch:
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
controller
And the new right version have been re-send.
thanks.
> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> index a968f25..179329b 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> @@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
> Required properties:
> - compatible: Should contain one of the following string:
> "mediatek,mt2701-pcie"
> + "mediatek,mt2712-pcie"
> + "mediatek,mt7622-pcie"
> "mediatek,mt7623-pcie"
> - device_type: Must be "pci"
> -- reg: Base addresses and lengths of the PCIe controller.
> +- reg: Base addresses and lengths of the PICe subsys and root ports.
> +- reg-names: Names of the above areas to use during resource look-up.
> - #address-cells: Address representation for root ports (must be 3)
> - #size-cells: Size representation for root ports (must be 2)
> - clocks: Must contain an entry for each entry in clock-names.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> - - free_ck :for reference clock of PCIe subsys
> - - sys_ck0 :for clock of Port0
> - - sys_ck1 :for clock of Port1
> - - sys_ck2 :for clock of Port2
> +- clock-names:
> + Mandatory entries:
> + - sys_ckN :transaction layer and data link layer clock
> + Required entries for MT2701/MT7623:
> + - free_ck :for reference clock of PCIe subsys
> + Required entries for MT2712/MT7622:
> + - ahb_ckN :AHB slave interface operating clock for CSR access and RC
> + initiated MMIO access
> + Required entries for MT7622:
> + - axi_ckN :application layer MMIO channel operating clock
> + - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
> + pcie_mac_ck/pcie_pipe_ck is turned off
> + - obff_ckN :OBFF functional block operating clock
> + - pipe_ckN :LTSSM and phy/mac layer operating clock
> + where N starting from 0 to the maximum number of root ports.
> - phys: List of PHY specifiers (used by generic PHY framework).
> - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
>number of PHYs as specified in *phys* property.
> @@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
> - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
>number of root ports.
>
> +Required properties for MT2712/MT7622:
> +-interrupts: A list of interrupt outputs of the controller, must have one
> + entry for each PCIe port
> +
> In addition, the device tree node must have sub-nodes describing each
> PCIe port interface, having the following mandatory properties:
>
> @@ -50,7 +67,7 @@ Required properties:
>property is sufficient.
> - num-lanes: Number of lanes to use for this port.
>
> -Examples:
> +Examples for MT7623:
>
> hifsys: syscon@1a00 {
> compatible = "mediatek,mt7623-hifsys",
> @@ -68,6 +85,7 @@ Examples:
> <0 0x1a142000 0 0x1000>, /* Port0 registers */
> <0 0x1a143000 0 0x1000>, /* Port1 registers */
> <0 0x1a144000 0 0x1000>; /* Port2 registers */
> + reg-names = "subsys", "port0", "port1", "port2";
> #address-cells = <3>;
> #size-cells = <2>;
> #interrupt-cells = <1>;
> @@ -127,3 +145,139 @@ Examples:
> num-lanes = <1>;
> };
> };
> +
> +Examples for MT2712:
> + pcie: pcie@1170 {
> + compatible = "mediatek,generic-pcie-v2";
> + device_type = "pci";
> + reg = <0 0x1170 0 0x1000>,
> + <0 0x112ff000 0 0x1000>;
> + reg-names = "port0", "port1";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + interrupts = ,
> + ;
> + clocks = <&pericfg CLK_PERI_PCIE0>,
> + <&pericfg CLK_PERI_PCIE1>,
> + <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
> + <&topckgen CLK_TOP_PE2_MAC_P1_SEL>;
> + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
> + phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy0", "pcie-phy1";
> + bus-range = <0x00 0xff>;
> + ranges = <0x8200 0 0
Re: [PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller
On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee
>
> Add support for MediaTek new generation controller and update related
> properities.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Honghui Zhang
> ---
> .../devicetree/bindings/pci/mediatek-pcie.txt | 168
> -
> 1 file changed, 161 insertions(+), 7 deletions(-)
>
Sorry about the disturb, I send the wrong local version of this patch.
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
controller
The right version for this patch have been re-send.
thanks.
> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> index a968f25..179329b 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> @@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
> Required properties:
> - compatible: Should contain one of the following string:
> "mediatek,mt2701-pcie"
> + "mediatek,mt2712-pcie"
> + "mediatek,mt7622-pcie"
> "mediatek,mt7623-pcie"
> - device_type: Must be "pci"
> -- reg: Base addresses and lengths of the PCIe controller.
> +- reg: Base addresses and lengths of the PICe subsys and root ports.
> +- reg-names: Names of the above areas to use during resource look-up.
> - #address-cells: Address representation for root ports (must be 3)
> - #size-cells: Size representation for root ports (must be 2)
> - clocks: Must contain an entry for each entry in clock-names.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> - - free_ck :for reference clock of PCIe subsys
> - - sys_ck0 :for clock of Port0
> - - sys_ck1 :for clock of Port1
> - - sys_ck2 :for clock of Port2
> +- clock-names:
> + Mandatory entries:
> + - sys_ckN :transaction layer and data link layer clock
> + Required entries for MT2701/MT7623:
> + - free_ck :for reference clock of PCIe subsys
> + Required entries for MT2712/MT7622:
> + - ahb_ckN :AHB slave interface operating clock for CSR access and RC
> + initiated MMIO access
> + Required entries for MT7622:
> + - axi_ckN :application layer MMIO channel operating clock
> + - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
> + pcie_mac_ck/pcie_pipe_ck is turned off
> + - obff_ckN :OBFF functional block operating clock
> + - pipe_ckN :LTSSM and phy/mac layer operating clock
> + where N starting from 0 to the maximum number of root ports.
> - phys: List of PHY specifiers (used by generic PHY framework).
> - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
>number of PHYs as specified in *phys* property.
> @@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
> - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
>number of root ports.
>
> +Required properties for MT2712/MT7622:
> +-interrupts: A list of interrupt outputs of the controller, must have one
> + entry for each PCIe port
> +
> In addition, the device tree node must have sub-nodes describing each
> PCIe port interface, having the following mandatory properties:
>
> @@ -50,7 +67,7 @@ Required properties:
>property is sufficient.
> - num-lanes: Number of lanes to use for this port.
>
> -Examples:
> +Examples for MT7623:
>
> hifsys: syscon@1a00 {
> compatible = "mediatek,mt7623-hifsys",
> @@ -68,6 +85,7 @@ Examples:
> <0 0x1a142000 0 0x1000>, /* Port0 registers */
> <0 0x1a143000 0 0x1000>, /* Port1 registers */
> <0 0x1a144000 0 0x1000>; /* Port2 registers */
> + reg-names = "subsys", "port0", "port1", "port2";
> #address-cells = <3>;
> #size-cells = <2>;
> #interrupt-cells = <1>;
> @@ -127,3 +145,139 @@ Examples:
> num-lanes = <1>;
> };
> };
> +
> +Examples for MT2712:
> + pcie: pcie@1170 {
> + compatible = "mediatek,generic-pcie-v2";
> + device_type = "pci";
> + reg = <0 0x1170 0 0x1000>,
> + <0 0x112ff000 0 0x1000>;
> + reg-names = "port0", "port1";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + interrupts = ,
> + ;
> + clocks = <&pericfg CLK_PERI_PCIE0>,
> + <&pericfg CLK_PERI_PCIE1>,
> + <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
> + <&topckgen CLK_TOP_PE2_MAC_P1_SEL>;
> + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
> + phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy0", "pcie-phy1";
> + bus-range = <0x00 0xff>;
> + ranges = <0x8200 0 0x2
Re: [RFC PATCH] mm: memcg: fix css double put in mem_cgroup_iter
2017-07-26 21:44 GMT+08:00 Michal Hocko :
> On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
>> From: Wenwei Tao
>>
>> By removing the child cgroup while the parent cgroup is
>> under reclaim, we could trigger the following kernel panic
>> on kernel 3.10:
>>
>> kernel BUG at kernel/cgroup.c:893!
>> invalid opcode: [#1] SMP
>> CPU: 1 PID: 22477 Comm: kworker/1:1 Not tainted 3.10.107 #1
>> Workqueue: cgroup_destroy css_dput_fn
>> task: 8817959a5780 ti: 8817e8886000 task.ti: 8817e8886000
>> RIP: 0010:[] []
>> cgroup_diput+0xc0/0xf0
>> RSP: :8817e8887da0 EFLAGS: 00010246
>> RAX: RBX: 8817a5dd5d40 RCX: dead0200
>> RDX: RSI: 8817973a6910 RDI: 8817f54c2a00
>> RBP: 8817e8887dc8 R08: 8817a5dd5dd0 R09: df9fb35794b01820
>> R10: df9fb35794b01820 R11: 7fa95b1efcda R12: 8817a5dd5d9c
>> R13: 8817f38b3a40 R14: 8817973a6910 R15: 8817973a6910
>> FS: () GS:88181f22()
>> knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 7fa6e6234000 CR3: 00179f19d000 CR4: 000407e0
>> DR0: DR1: DR2:
>> DR3: DR6: 0ff0 DR7: 0400
>> Stack:
>> 8817a5dd5d40 8817a5dd5d9c 8817f38b3a40 8817973a6910
>> 0040 8817e8887df8 811b37c2 8817fa23c000
>> 8817f57dbb80 88181f232ac0 88181f237500 8817e8887e10
>> Call Trace:
>> [] dput+0x1a2/0x2f0
>> [] cgroup_dput.isra.21+0x1c/0x30
>> [] css_dput_fn+0x1d/0x20
>> [] process_one_work+0x17c/0x460
>> [] worker_thread+0x116/0x3b0
>> [] ? manage_workers.isra.25+0x290/0x290
>> [] kthread+0xc0/0xd0
>> [] ? insert_kthread_work+0x40/0x40
>> [] ret_from_fork+0x58/0x90
>> [] ? insert_kthread_work+0x40/0x40
>> Code: 41 5e 41 5f 5d c3 0f 1f 44 00 00 48 8b 7f 78 48 8b 07 a8 01 74 15
>> 48 81 c7 30 01 00 00 48 c7 c6 a0 a7 0c 81 e8 b2 83 02 00 eb c8 <0f> 0b
>> 49 8b 4e 18 48 c7 c2 7e f1 7a 81 be 85 03 00 00 48 c7 c7
>> RIP [] cgroup_diput+0xc0/0xf0
>> RSP
>> ---[ end trace 85eeea5212c44f51 ]---
>>
>>
>> I think there is a css double put in mem_cgroup_iter. Under reclaim,
>> we call mem_cgroup_iter the first time with prev == NULL, and we get
>> last_visited memcg from per zone's reclaim_iter then call
>> __mem_cgroup_iter_next
>> try to get next alive memcg, __mem_cgroup_iter_next could return NULL
>> if last_visited is already the last one so we put the last_visited's
>> memcg css and continue to the next while loop, this time we might not
>> do css_tryget(&last_visited->css) if the dead_count is changed, but
>> we still do css_put(&last_visited->css), we put it twice, this could
>> trigger the BUG_ON at kernel/cgroup.c:893.
>
> Yes, I guess your are right and I suspect that this has been silently
> fixed by 519ebea3bf6d ("mm: memcontrol: factor out reclaim iterator
> loading and updating"). I think a more appropriate fix is would be.
> Are you able to reproduce and re-test it?
> ---
Yes, I think this commit can fix this issue, and I backport this
commit to 3.10.107 kernel
and cannot reproduce this issue. I guess this commit might need to be
backported to 3.10.y
stable kernel.
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 437ae2cbe102..0848ec05c12a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1224,6 +1224,8 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> if (last_visited && last_visited != root &&
> !css_tryget(&last_visited->css))
> last_visited = NULL;
> + } else {
> + last_visited = true;
> }
> }
>
> --
> Michal Hocko
> SUSE Labs
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks
On 26-07-17, 14:00, Saravana Kannan wrote: > No, the alternative is to pass it on to the CPU freq driver and let it > decide what it wants to do. That's the whole point if having a CPU freq > driver -- so that the generic code doesn't need to care about HW specific > details. Which is the point I was making in an earlier email to Viresh's > patch -- we shouldn't be doing any CPU check for the call backs at the > scheduler or ever governor level. > > That would simplify this whole thing by deleting a bunch of code. And having > much simpler checks in those drivers that actually have to deal with their > HW specific details. So what you are saying is that we go and update (almost) every cpufreq driver we have today and make their ->target() callbacks return early if they don't support switching frequency remotely ? Is that really simplifying anything? The core already has most of the data required and I believe that we need to handle it in the governor's code as is handled in this series. To solve the problem that you have been reporting (update from any CPU), we need something like this which I earlier suggested and I will come back to it after this series is gone. Don't want to complicate things here unnecessarily. https://marc.info/?l=linux-kernel&m=148906012827786&w=2 -- viresh
Re: [PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations
On Thu, 2017-07-27 at 11:19 +0800, Honghui Zhang wrote:
> On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> > From: Ryder Lee
> >
> > Introduce a structure "mtk_pcie_soc" to abstract the differences between
> > controller generations, and the .startup() hook is used to encapsulate
> > some SoC-dependent related setting. In doing so, the common code which
> > will be reused by future chips.
> >
> > In addition, we change the approaches to waiting Gen2 training by using
> > readl_poll_timeout() calls.
> >
> > Signed-off-by: Ryder Lee
> > Signed-off-by: Honghui Zhang
> > ---
> > drivers/pci/host/pcie-mediatek.c | 81
> > +++-
> > 1 file changed, 47 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c
> > b/drivers/pci/host/pcie-mediatek.c
> > index 5a9d858..7f952a4 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -16,6 +16,7 @@
> >
>
> Sorry about the disturb, I send the wrong patch for this one.
> I will resend the right version for this last patch.
>
Sorry, I reply to the wrong patch mail.
I meant to re-send the patch:
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
controller, not this one.
This one is the right patch.
tahnks.
> thanks.
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -63,6 +64,18 @@
> > #define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
> > #define PCIE_FC_CREDIT_VAL(x) ((x) << 16)
> >
> > +struct mtk_pcie_port;
> > +
> > +/**
> > + * struct mtk_pcie_soc - differentiate between host generations
> > + * @ops: pointer to configuration access functions
> > + * @startup: pointer to controller setting functions
> > + */
> > +struct mtk_pcie_soc {
> > + struct pci_ops *ops;
> > + int (*startup)(struct mtk_pcie_port *port);
> > +};
> > +
> > /**
> > * struct mtk_pcie_port - PCIe port information
> > * @base: IO mapped register base
> > @@ -96,6 +109,7 @@ struct mtk_pcie_port {
> > * @busn: bus range
> > * @offset: IO / Memory offset
> > * @ports: pointer to PCIe port information
> > + * @soc: pointer to SoC-dependent operations
> > */
> > struct mtk_pcie {
> > struct device *dev;
> > @@ -111,13 +125,9 @@ struct mtk_pcie {
> > resource_size_t io;
> > } offset;
> > struct list_head ports;
> > + const struct mtk_pcie_soc *soc;
> > };
> >
> > -static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
> > -{
> > - return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
> > -}
> > -
> > static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> > {
> > struct device *dev = pcie->dev;
> > @@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
> > .write = pci_generic_config_write,
> > };
> >
> > -static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
> > +static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
> > {
> > struct mtk_pcie *pcie = port->pcie;
> > u32 func = PCI_FUNC(port->index << 3);
> > u32 slot = PCI_SLOT(port->index << 3);
> > u32 val;
> > + int err;
> > +
> > + /* assert port PERST_N */
> > + val = readl(pcie->base + PCIE_SYS_CFG);
> > + val |= PCIE_PORT_PERST(port->index);
> > + writel(val, pcie->base + PCIE_SYS_CFG);
> > +
> > + /* de-assert port PERST_N */
> > + val = readl(pcie->base + PCIE_SYS_CFG);
> > + val &= ~PCIE_PORT_PERST(port->index);
> > + writel(val, pcie->base + PCIE_SYS_CFG);
> > +
> > + /* 100ms timeout value should be enough for Gen1/2 training */
> > + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
> > +!!(val & PCIE_PORT_LINKUP), 20,
> > +100 * USEC_PER_MSEC);
> > + if (err)
> > + return -ETIMEDOUT;
> >
> > /* enable interrupt */
> > val = readl(pcie->base + PCIE_INT_ENABLE);
> > @@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct
> > mtk_pcie_port *port)
> > writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
> >pcie->base + PCIE_CFG_ADDR);
> > writel(val, pcie->base + PCIE_CFG_DATA);
> > -}
> >
> > -static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
> > -{
> > - struct mtk_pcie *pcie = port->pcie;
> > - u32 val;
> > -
> > - /* assert port PERST_N */
> > - val = readl(pcie->base + PCIE_SYS_CFG);
> > - val |= PCIE_PORT_PERST(port->index);
> > - writel(val, pcie->base + PCIE_SYS_CFG);
> > -
> > - /* de-assert port PERST_N */
> > - val = readl(pcie->base + PCIE_SYS_CFG);
> > - val &= ~PCIE_PORT_PERST(port->index);
> > - writel(val, pcie->base + PCIE_SYS_CFG);
> > -
> > - /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
> > - msleep(100);
> > + return 0;
> > }
> >
> > static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
> > {
> > - struct device *dev = port->pcie->dev;
> > + struct mt
Re: [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks
On 26-07-17, 19:42, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:
> > + /* Don't allow remote callbacks */
> > + if (smp_processor_id() != data->cpu)
> > + return;
>
> You can do this check against cpu->cpu, however.
>
> > + /* Don't allow remote callbacks */
> > + if (smp_processor_id() != data->cpu)
> > + return;
>
> And same here.
>
> > +
> > if (flags & SCHED_CPUFREQ_IOWAIT) {
> > cpu->iowait_boost = int_tofp(1);
> > } else if (cpu->iowait_boost) {
> > diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
> > index d2be2ccbb372..8256a8f35f22 100644
> > --- a/include/linux/sched/cpufreq.h
> > +++ b/include/linux/sched/cpufreq.h
> > @@ -16,6 +16,7 @@
> > #ifdef CONFIG_CPU_FREQ
> > struct update_util_data {
> > void (*func)(struct update_util_data *data, u64 time, unsigned int
> > flags);
> > + unsigned int cpu;
>
> So it looks like you don't need this.
>
> schedutil doesn't need it as per patch [2/3].
Hmm, so your comments are exactly same as what Peter suggested few
days back.
sugov_get_util() uses it in 2/3, as we need to know the target CPU
anyway.
But I think it would be better to add the cpu variable in sugov_cpu
structure instead as only schedutil needs it. I will do that change
and send V5.
--
viresh
[PATCH V2 net] Revert "vhost: cache used event for better performance"
This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
was reported to break vhost_net. We want to cache used event and use
it to check for notification. The assumption was that guest won't move
the event idx back, but this could happen in fact when 16 bit index
wraps around after 64K entries.
Signed-off-by: Jason Wang
---
- Changes from V1: tweak commit log
- The patch is needed for -stable.
---
drivers/vhost/vhost.c | 28 ++--
drivers/vhost/vhost.h | 3 ---
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e4613a3..9cb3f72 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -308,7 +308,6 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->avail = NULL;
vq->used = NULL;
vq->last_avail_idx = 0;
- vq->last_used_event = 0;
vq->avail_idx = 0;
vq->last_used_idx = 0;
vq->signalled_used = 0;
@@ -1402,7 +1401,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl,
void __user *argp)
r = -EINVAL;
break;
}
- vq->last_avail_idx = vq->last_used_event = s.num;
+ vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
break;
@@ -2241,6 +2240,10 @@ static bool vhost_notify(struct vhost_dev *dev, struct
vhost_virtqueue *vq)
__u16 old, new;
__virtio16 event;
bool v;
+ /* Flush out used index updates. This is paired
+* with the barrier that the Guest executes when enabling
+* interrupts. */
+ smp_mb();
if (vhost_has_feature(vq, VIRTIO_F_NOTIFY_ON_EMPTY) &&
unlikely(vq->avail_idx == vq->last_avail_idx))
@@ -2248,10 +2251,6 @@ static bool vhost_notify(struct vhost_dev *dev, struct
vhost_virtqueue *vq)
if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
__virtio16 flags;
- /* Flush out used index updates. This is paired
-* with the barrier that the Guest executes when enabling
-* interrupts. */
- smp_mb();
if (vhost_get_avail(vq, flags, &vq->avail->flags)) {
vq_err(vq, "Failed to get flags");
return true;
@@ -2266,26 +2265,11 @@ static bool vhost_notify(struct vhost_dev *dev, struct
vhost_virtqueue *vq)
if (unlikely(!v))
return true;
- /* We're sure if the following conditions are met, there's no
-* need to notify guest:
-* 1) cached used event is ahead of new
-* 2) old to new updating does not cross cached used event. */
- if (vring_need_event(vq->last_used_event, new + vq->num, new) &&
- !vring_need_event(vq->last_used_event, new, old))
- return false;
-
- /* Flush out used index updates. This is paired
-* with the barrier that the Guest executes when enabling
-* interrupts. */
- smp_mb();
-
if (vhost_get_avail(vq, event, vhost_used_event(vq))) {
vq_err(vq, "Failed to get used event idx");
return true;
}
- vq->last_used_event = vhost16_to_cpu(vq, event);
-
- return vring_need_event(vq->last_used_event, new, old);
+ return vring_need_event(vhost16_to_cpu(vq, event), new, old);
}
/* This actually signals the guest, using eventfd. */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index f720958..bb7c29b 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -115,9 +115,6 @@ struct vhost_virtqueue {
/* Last index we used. */
u16 last_used_idx;
- /* Last used evet we've seen */
- u16 last_used_event;
-
/* Used flags */
u16 used_flags;
--
2.7.4
Re: [PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations
On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee
>
> Introduce a structure "mtk_pcie_soc" to abstract the differences between
> controller generations, and the .startup() hook is used to encapsulate
> some SoC-dependent related setting. In doing so, the common code which
> will be reused by future chips.
>
> In addition, we change the approaches to waiting Gen2 training by using
> readl_poll_timeout() calls.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Honghui Zhang
> ---
> drivers/pci/host/pcie-mediatek.c | 81
> +++-
> 1 file changed, 47 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c
> b/drivers/pci/host/pcie-mediatek.c
> index 5a9d858..7f952a4 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -16,6 +16,7 @@
>
Sorry about the disturb, I send the wrong patch for this one.
I will resend the right version for this last patch.
thanks.
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -63,6 +64,18 @@
> #define PCIE_FC_CREDIT_MASK (GENMASK(31, 31) | GENMASK(28, 16))
> #define PCIE_FC_CREDIT_VAL(x)((x) << 16)
>
> +struct mtk_pcie_port;
> +
> +/**
> + * struct mtk_pcie_soc - differentiate between host generations
> + * @ops: pointer to configuration access functions
> + * @startup: pointer to controller setting functions
> + */
> +struct mtk_pcie_soc {
> + struct pci_ops *ops;
> + int (*startup)(struct mtk_pcie_port *port);
> +};
> +
> /**
> * struct mtk_pcie_port - PCIe port information
> * @base: IO mapped register base
> @@ -96,6 +109,7 @@ struct mtk_pcie_port {
> * @busn: bus range
> * @offset: IO / Memory offset
> * @ports: pointer to PCIe port information
> + * @soc: pointer to SoC-dependent operations
> */
> struct mtk_pcie {
> struct device *dev;
> @@ -111,13 +125,9 @@ struct mtk_pcie {
> resource_size_t io;
> } offset;
> struct list_head ports;
> + const struct mtk_pcie_soc *soc;
> };
>
> -static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
> -{
> - return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
> -}
> -
> static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> {
> struct device *dev = pcie->dev;
> @@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
> .write = pci_generic_config_write,
> };
>
> -static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
> +static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
> {
> struct mtk_pcie *pcie = port->pcie;
> u32 func = PCI_FUNC(port->index << 3);
> u32 slot = PCI_SLOT(port->index << 3);
> u32 val;
> + int err;
> +
> + /* assert port PERST_N */
> + val = readl(pcie->base + PCIE_SYS_CFG);
> + val |= PCIE_PORT_PERST(port->index);
> + writel(val, pcie->base + PCIE_SYS_CFG);
> +
> + /* de-assert port PERST_N */
> + val = readl(pcie->base + PCIE_SYS_CFG);
> + val &= ~PCIE_PORT_PERST(port->index);
> + writel(val, pcie->base + PCIE_SYS_CFG);
> +
> + /* 100ms timeout value should be enough for Gen1/2 training */
> + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
> + !!(val & PCIE_PORT_LINKUP), 20,
> + 100 * USEC_PER_MSEC);
> + if (err)
> + return -ETIMEDOUT;
>
> /* enable interrupt */
> val = readl(pcie->base + PCIE_INT_ENABLE);
> @@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct mtk_pcie_port
> *port)
> writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
> pcie->base + PCIE_CFG_ADDR);
> writel(val, pcie->base + PCIE_CFG_DATA);
> -}
>
> -static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
> -{
> - struct mtk_pcie *pcie = port->pcie;
> - u32 val;
> -
> - /* assert port PERST_N */
> - val = readl(pcie->base + PCIE_SYS_CFG);
> - val |= PCIE_PORT_PERST(port->index);
> - writel(val, pcie->base + PCIE_SYS_CFG);
> -
> - /* de-assert port PERST_N */
> - val = readl(pcie->base + PCIE_SYS_CFG);
> - val &= ~PCIE_PORT_PERST(port->index);
> - writel(val, pcie->base + PCIE_SYS_CFG);
> -
> - /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
> - msleep(100);
> + return 0;
> }
>
> static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
> {
> - struct device *dev = port->pcie->dev;
> + struct mtk_pcie *pcie = port->pcie;
> + struct device *dev = pcie->dev;
> int err;
>
> err = clk_prepare_enable(port->sys_ck);
> @@ -250,13 +262,8 @@ static void mtk_pcie_enable_ports(struct mtk_pcie_port
> *port)
> goto err_phy_on;
> }
>
> - mtk_pcie_assert_ports(port);
> -
> - /* if link up, then setup root port configuration space */
> - if (mtk_pcie_link_up(port)) {
> - mtk_pcie_con
[PATCH] staging: greybus: Remove unnecessary platform_set_drvdata
Unnecessary platform_set_drvdata() has been removed since the driver core clears the driver data to NULL after device release or on probe failure. There is no need to manually clear the device driver data to NULL. The Coccinelle semantic patch used to make this change is as follows: // @@ struct platform_device *pdev; @@ - platform_set_drvdata(pdev, NULL); // Signed-off-by: Amitoj Kaur Chawla --- drivers/staging/greybus/arche-platform.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/greybus/arche-platform.c b/drivers/staging/greybus/arche-platform.c index eced2d2..358b260 100644 --- a/drivers/staging/greybus/arche-platform.c +++ b/drivers/staging/greybus/arche-platform.c @@ -607,7 +607,6 @@ static int arche_platform_remove(struct platform_device *pdev) device_remove_file(&pdev->dev, &dev_attr_state); device_for_each_child(&pdev->dev, NULL, arche_remove_child); arche_platform_poweroff_seq(arche_pdata); - platform_set_drvdata(pdev, NULL); if (usb3613_hub_mode_ctrl(false)) dev_warn(arche_pdata->dev, "failed to control hub device\n"); -- 2.7.4
Re: [PATCH 1/1] mm/hugetlb: Make huge_pte_offset() consistent and document behaviour
On 07/26/2017 06:34 AM, Punit Agrawal wrote: > Michal Hocko writes: > >> On Wed 26-07-17 14:33:57, Michal Hocko wrote: >>> On Wed 26-07-17 13:11:46, Punit Agrawal wrote: >> [...] I've been running tests from mce-test suite and libhugetlbfs for similar changes we did on arm64. There could be assumptions that were not exercised but I'm not sure how to check for all the possible usages. Do you have any other suggestions that can help improve confidence in the patch? >>> >>> Unfortunatelly I don't. I just know there were many subtle assumptions >>> all over the place so I am rather careful to not touch the code unless >>> really necessary. >>> >>> That being said, I am not opposing your patch. >> >> Let me be more specific. I am not opposing your patch but we should >> definitely need more reviewers to have a look. I am not seeing any >> immediate problems with it but I do not see a large improvements either >> (slightly less nightmare doesn't make me sleep all that well ;)). So I >> will leave the decisions to others. > > I hear you - I'd definitely appreciate more eyes on the code change and > description. I like the change in semantics for the routine. Like you, I examined all callers of huge_pte_offset() and it appears that they will not be impacted by your change. My only concern is that arch specific versions of huge_pte_offset, may not (yet) follow the new semantic. Someone could potentially introduce a new huge_pte_offset call and depend on the new 'documented' semantics. Yet, an unmodified arch specific version of huge_pte_offset might have different semantics. I have not reviewed all the arch specific instances of the routine to know if this is even possible. Just curious if you examined these, or perhaps you think this is not an issue? -- Mike Kravetz
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller
From: Ryder Lee
Add support for MediaTek new generation controller and update related
properities.
Signed-off-by: Ryder Lee
Signed-off-by: Honghui Zhang
---
.../devicetree/bindings/pci/mediatek-pcie.txt | 168 -
1 file changed, 161 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index a968f25..b9e73bf 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
Required properties:
- compatible: Should contain one of the following string:
"mediatek,mt2701-pcie"
+ "mediatek,mt2712-pcie"
+ "mediatek,mt7622-pcie"
"mediatek,mt7623-pcie"
- device_type: Must be "pci"
-- reg: Base addresses and lengths of the PCIe controller.
+- reg: Base addresses and lengths of the PICe subsys and root ports.
+- reg-names: Names of the above areas to use during resource look-up.
- #address-cells: Address representation for root ports (must be 3)
- #size-cells: Size representation for root ports (must be 2)
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - free_ck :for reference clock of PCIe subsys
- - sys_ck0 :for clock of Port0
- - sys_ck1 :for clock of Port1
- - sys_ck2 :for clock of Port2
+- clock-names:
+ Mandatory entries:
+ - sys_ckN :transaction layer and data link layer clock
+ Required entries for MT2701/MT7623:
+ - free_ck :for reference clock of PCIe subsys
+ Required entries for MT2712/MT7622:
+ - ahb_ckN :AHB slave interface operating clock for CSR access and RC
+ initiated MMIO access
+ Required entries for MT7622:
+ - axi_ckN :application layer MMIO channel operating clock
+ - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
+ pcie_mac_ck/pcie_pipe_ck is turned off
+ - obff_ckN :OBFF functional block operating clock
+ - pipe_ckN :LTSSM and phy/mac layer operating clock
+ where N starting from 0 to the maximum number of root ports.
- phys: List of PHY specifiers (used by generic PHY framework).
- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
number of PHYs as specified in *phys* property.
@@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
number of root ports.
+Required properties for MT2712/MT7622:
+-interrupts: A list of interrupt outputs of the controller, must have one
+entry for each PCIe port
+
In addition, the device tree node must have sub-nodes describing each
PCIe port interface, having the following mandatory properties:
@@ -50,7 +67,7 @@ Required properties:
property is sufficient.
- num-lanes: Number of lanes to use for this port.
-Examples:
+Examples for MT7623:
hifsys: syscon@1a00 {
compatible = "mediatek,mt7623-hifsys",
@@ -68,6 +85,7 @@ Examples:
<0 0x1a142000 0 0x1000>, /* Port0 registers */
<0 0x1a143000 0 0x1000>, /* Port1 registers */
<0 0x1a144000 0 0x1000>; /* Port2 registers */
+ reg-names = "subsys", "port0", "port1", "port2";
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
@@ -127,3 +145,139 @@ Examples:
num-lanes = <1>;
};
};
+
+Examples for MT2712:
+ pcie: pcie@1170 {
+ compatible = "mediatek,mt2712-pcie";
+ device_type = "pci";
+ reg = <0 0x1170 0 0x1000>,
+ <0 0x112ff000 0 0x1000>;
+ reg-names = "port0", "port1";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = ,
+;
+ clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
+<&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
+<&pericfg CLK_PERI_PCIE0>,
+<&pericfg CLK_PERI_PCIE1>;
+ clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
+ phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy0", "pcie-phy1";
+ bus-range = <0x00 0xff>;
+ ranges = <0x8200 0 0x2000 0x0 0x2000 0
0x1000>;
+
+ pcie0: pcie@0,0 {
+ device_type = "pci";
+ reg = <0x 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ num-lanes = <1>;
+ interrupt-map-mask = <0 0
Re: [PATCH] turbostat: Running on virtual machine is not supported
Henrique, I like your suggestion, thanks! BTW. let's discuss (and patch) turbostat on linux-pm, rather than on lkml. thanks, -Len On Tue, Jul 25, 2017 at 11:59 AM, Henrique de Moraes Holschuh wrote: > On Tue, 25 Jul 2017, Prarit Bhargava wrote: >> A common way of determining if the system is a virtual machine is to >> search /proc/cpuinfo flags entry for "hypervisor". turbostat must output >> a proper error message when found. > > Maybe you could output that message only if it fails to both use > /dev/msr and perf *and* it is under a virtual machine? That would have > better forward compatibility, maybe someday /dev/msr or perf will work > inside a VM for what turbostat needs... > > -- > Henrique Holschuh -- Len Brown, Intel Open Source Technology Center
Re: [PATCH 2/2] printk: Add boottime and real timestamps
Hi Prarit,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc2]
[cannot apply to next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Prarit-Bhargava/printk-allow-different-timestamps-for-printk-time/20170727-104148
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/printk/printk.c: In function 'printk_late_init':
>> kernel/printk/printk.c:2746:6: error: 'printk_time_setting' undeclared
>> (first use in this function)
if (printk_time_setting == 0)
^~~
kernel/printk/printk.c:2746:6: note: each undeclared identifier is reported
only once for each function it appears in
>> kernel/printk/printk.c:2747:25: error: 'printk_time' undeclared (first use
>> in this function)
printk_time_setting = printk_time;
^~~
vim +/printk_time_setting +2746 kernel/printk/printk.c
2724
2725 /*
2726 * Some boot consoles access data that is in the init section and which
will
2727 * be discarded after the initcalls have been run. To make sure that no
code
2728 * will access this data, unregister the boot consoles in a late
initcall.
2729 *
2730 * If for some reason, such as deferred probe or the driver being a
loadable
2731 * module, the real console hasn't registered yet at this point, there
will
2732 * be a brief interval in which no messages are logged to the console,
which
2733 * makes it difficult to diagnose problems that occur during this time.
2734 *
2735 * To mitigate this problem somewhat, only unregister consoles whose
memory
2736 * intersects with the init section. Note that code exists elsewhere to
get
2737 * rid of the boot console as soon as the proper console shows up, so
there
2738 * won't be side-effects from postponing the removal.
2739 */
2740 static int __init printk_late_init(void)
2741 {
2742 struct console *con;
2743 int ret;
2744
2745 /* initialize printk_time settings */
> 2746 if (printk_time_setting == 0)
> 2747 printk_time_setting = printk_time;
2748
2749 for_each_console(con) {
2750 if (!keep_bootcon && con->flags & CON_BOOT) {
2751 /*
2752 * Make sure to unregister boot consoles whose
data
2753 * resides in the init section before the init
section
2754 * is discarded. Boot consoles whose data will
stick
2755 * around will automatically be unregistered
when the
2756 * proper console replaces them.
2757 */
2758 if (init_section_intersects(con, sizeof(*con)))
2759 unregister_console(con);
2760 }
2761 }
2762 ret = cpuhp_setup_state_nocalls(CPUHP_PRINTK_DEAD,
"printk:dead", NULL,
2763 console_cpu_notify);
2764 WARN_ON(ret < 0);
2765 ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
"printk:online",
2766 console_cpu_notify, NULL);
2767 WARN_ON(ret < 0);
2768 return 0;
2769 }
2770 late_initcall(printk_late_init);
2771
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v2 2/5] PCI: mediatek: switch to use platform_get_resource_byname()
From: Ryder Lee
This is a transitional patch. We currently use platfarm_get_resource() for
retrieving the IOMEM resources, but there might be some chips don't have
subsys/shared registers part, which depends on platform design, and these
will be introduced in further patches.
Switch this function to use the platform_get_resource_byname() so that the
binding can be agnostic of the resource order.
Signed-off-by: Ryder Lee
---
drivers/pci/host/pcie-mediatek.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 7f952a4..f8e2f68 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -295,7 +295,8 @@ static int mtk_pcie_parse_ports(struct mtk_pcie *pcie,
return err;
}
- regs = platform_get_resource(pdev, IORESOURCE_MEM, index + 1);
+ snprintf(name, sizeof(name), "port%d", index);
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
port->base = devm_ioremap_resource(dev, regs);
if (IS_ERR(port->base)) {
dev_err(dev, "failed to map port%d base\n", index);
@@ -336,12 +337,14 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
struct resource *regs;
int err;
- /* get shared registers */
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pcie->base = devm_ioremap_resource(dev, regs);
- if (IS_ERR(pcie->base)) {
- dev_err(dev, "failed to map shared register\n");
- return PTR_ERR(pcie->base);
+ /* get shared registers, which are optional */
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "subsys");
+ if (regs) {
+ pcie->base = devm_ioremap_resource(dev, regs);
+ if (IS_ERR(pcie->base)) {
+ dev_err(dev, "failed to map shared register\n");
+ return PTR_ERR(pcie->base);
+ }
}
pcie->free_ck = devm_clk_get(dev, "free_ck");
--
2.6.4
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller
From: Ryder Lee
Add support for MediaTek new generation controller and update related
properities.
Signed-off-by: Ryder Lee
Signed-off-by: Honghui Zhang
---
.../devicetree/bindings/pci/mediatek-pcie.txt | 168 -
1 file changed, 161 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index a968f25..179329b 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
Required properties:
- compatible: Should contain one of the following string:
"mediatek,mt2701-pcie"
+ "mediatek,mt2712-pcie"
+ "mediatek,mt7622-pcie"
"mediatek,mt7623-pcie"
- device_type: Must be "pci"
-- reg: Base addresses and lengths of the PCIe controller.
+- reg: Base addresses and lengths of the PICe subsys and root ports.
+- reg-names: Names of the above areas to use during resource look-up.
- #address-cells: Address representation for root ports (must be 3)
- #size-cells: Size representation for root ports (must be 2)
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - free_ck :for reference clock of PCIe subsys
- - sys_ck0 :for clock of Port0
- - sys_ck1 :for clock of Port1
- - sys_ck2 :for clock of Port2
+- clock-names:
+ Mandatory entries:
+ - sys_ckN :transaction layer and data link layer clock
+ Required entries for MT2701/MT7623:
+ - free_ck :for reference clock of PCIe subsys
+ Required entries for MT2712/MT7622:
+ - ahb_ckN :AHB slave interface operating clock for CSR access and RC
+ initiated MMIO access
+ Required entries for MT7622:
+ - axi_ckN :application layer MMIO channel operating clock
+ - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
+ pcie_mac_ck/pcie_pipe_ck is turned off
+ - obff_ckN :OBFF functional block operating clock
+ - pipe_ckN :LTSSM and phy/mac layer operating clock
+ where N starting from 0 to the maximum number of root ports.
- phys: List of PHY specifiers (used by generic PHY framework).
- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
number of PHYs as specified in *phys* property.
@@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
number of root ports.
+Required properties for MT2712/MT7622:
+-interrupts: A list of interrupt outputs of the controller, must have one
+entry for each PCIe port
+
In addition, the device tree node must have sub-nodes describing each
PCIe port interface, having the following mandatory properties:
@@ -50,7 +67,7 @@ Required properties:
property is sufficient.
- num-lanes: Number of lanes to use for this port.
-Examples:
+Examples for MT7623:
hifsys: syscon@1a00 {
compatible = "mediatek,mt7623-hifsys",
@@ -68,6 +85,7 @@ Examples:
<0 0x1a142000 0 0x1000>, /* Port0 registers */
<0 0x1a143000 0 0x1000>, /* Port1 registers */
<0 0x1a144000 0 0x1000>; /* Port2 registers */
+ reg-names = "subsys", "port0", "port1", "port2";
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
@@ -127,3 +145,139 @@ Examples:
num-lanes = <1>;
};
};
+
+Examples for MT2712:
+ pcie: pcie@1170 {
+ compatible = "mediatek,generic-pcie-v2";
+ device_type = "pci";
+ reg = <0 0x1170 0 0x1000>,
+ <0 0x112ff000 0 0x1000>;
+ reg-names = "port0", "port1";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = ,
+;
+ clocks = <&pericfg CLK_PERI_PCIE0>,
+<&pericfg CLK_PERI_PCIE1>,
+<&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
+<&topckgen CLK_TOP_PE2_MAC_P1_SEL>;
+ clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
+ phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy0", "pcie-phy1";
+ bus-range = <0x00 0xff>;
+ ranges = <0x8200 0 0x2000 0x0 0x2000 0
0x1000>;
+
+ pcie0: pcie@0,0 {
+ device_type = "pci";
+ reg = <0x 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ num-lanes = <1>;
+ interrupt-map-mask = <
[PATCH v2 4/5] PCI: mediatek: Add new generation controller support
From: Ryder Lee
Add support for new Gen2 controller which has two root ports and shares
the probing flow with legacy controller. Currently this IP block can be
found on MT7622/MT2712.
Signed-off-by: Ryder Lee
Signed-off-by: Honghui Zhang
---
drivers/pci/host/Kconfig | 5 +-
drivers/pci/host/pcie-mediatek.c | 490 ++-
2 files changed, 489 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 89d61c2..5b1ae9f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -182,14 +182,13 @@ config PCIE_ROCKCHIP
config PCIE_MEDIATEK
bool "MediaTek PCIe controller"
- depends on ARM && (ARCH_MEDIATEK || COMPILE_TEST)
+ depends on (ARM || ARM64) && (ARCH_MEDIATEK || COMPILE_TEST)
depends on OF
depends on PCI
select PCIEPORTBUS
help
Say Y here if you want to enable PCIe controller support on
- MT7623 series SoCs. There is one single root complex with 3 root
- ports available. Each port supports Gen2 lane x1.
+ MediaTek SoCs.
config PCIE_TANGO_SMP8759
bool "Tango SMP8759 PCIe controller (DANGEROUS)"
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index f8e2f68..5fe92ff 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -3,6 +3,7 @@
*
* Copyright (c) 2017 MediaTek Inc.
* Author: Ryder Lee
+ *Honghui Zhang
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -17,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -64,16 +67,77 @@
#define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
#define PCIE_FC_CREDIT_VAL(x) ((x) << 16)
+/* PCIe V2 share registers */
+#define PCIE_SYS_CFG_V20x0
+#define PCIE_CSR_LTSSM_EN(x) BIT(0 + (x) * 8)
+#define PCIE_CSR_ASPM_L1_EN(x) BIT(1 + (x) * 8)
+
+/* PCIe V2 per-port registers */
+#define PCIE_INT_MASK 0x420
+#define INTX_MASK GENMASK(19, 16)
+#define INTX_SHIFT 16
+#define INTX_NUM 4
+#define PCIE_INT_STATUS0x424
+
+#define PCIE_AHB_TRANS_BASE0_L 0x438
+#define PCIE_AHB_TRANS_BASE0_H 0x43c
+#define AHB2PCIE_BASEL(x) ((x) & GENMASK(31, 0))
+#define AHB2PCIE_BASEH(x) (((u64)(x) >> 32) & GENMASK(31, 0))
+#define AHB2PCIE_SIZE(x) ((x) & GENMASK(4, 0))
+#define PCIE_AXI_WINDOW0 0x448
+#define WIN_ENABLE BIT(7)
+
+/* PCIe V2 Configuration Transaction Header */
+#define PCIE_CFG_HEADER0 0x460
+#define PCIE_CFG_HEADER1 0x464
+#define PCIE_CFG_HEADER2 0x468
+#define PCIE_CFG_WDATA 0x470
+#define PCIE_APP_TLP_REQ 0x488
+#define PCIE_CFG_RDATA 0x48c
+#define APP_CFG_REQBIT(0)
+#define APP_CPL_STATUS GENMASK(7, 5)
+
+#define CFG_WRRD_TYPE_04
+#define CFG_WR_FMT 2
+#define CFG_RD_FMT 0
+
+#define CFG_DW0_LENGTH(length) ((length) & GENMASK(9, 0))
+#define CFG_DW0_TYPE(type) (((type) << 24) & GENMASK(28, 24))
+#define CFG_DW0_FMT(fmt) (((fmt) << 29) & GENMASK(31, 29))
+#define CFG_DW2_REGN(regn) ((regn) & GENMASK(11, 2))
+#define CFG_DW2_FUN(fun) (((fun) << 16) & GENMASK(18, 16))
+#define CFG_DW2_DEV(dev) (((dev) << 19) & GENMASK(23, 19))
+#define CFG_DW2_BUS(bus) (((bus) << 24) & GENMASK(31, 24))
+#define CFG_HEADER_DW0(type, fmt) \
+ (CFG_DW0_LENGTH(1) | CFG_DW0_TYPE(type) | CFG_DW0_FMT(fmt))
+#define CFG_HEADER_DW1(where, size) \
+ (GENMASK(((size) - 1), 0) << ((where) & 0x3))
+#define CFG_HEADER_DW2(regn, fun, dev, bus) \
+ (CFG_DW2_REGN(regn) | CFG_DW2_FUN(fun) | \
+ CFG_DW2_DEV(dev) | CFG_DW2_BUS(bus))
+
+#define PCIE_RST_CTRL 0x510
+#define PCIE_PHY_RSTB BIT(0)
+#define PCIE_PIPE_SRSTBBIT(1)
+#define PCIE_MAC_SRSTB BIT(2)
+#define PCIE_CRSTB BIT(3)
+#define PCIE_PERSTBBIT(8)
+#define PCI_LINKDOWN_RST_ENGENMASK(15, 13)
+#define PCIE_LINK_STATUS_V20x804
+#define PCIE_PORT_LINKUP_V2BIT(10)
+
struct mtk_pcie_port;
/**
* struct mtk_pcie_soc - differentiate between host generations
* @ops: pointer to configuration access functions
* @startup: pointer to controller setting functions
+ * @setup_irq: pointer to initialize irq functions
*/
struct mtk_pcie_soc {
struct pci_ops *ops;
int (*startup)(struct mtk_pcie_port *port);
+ int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
};
/**
@@ -82,10 +146,18 @@ struct mtk_pcie_soc {
* @list: port list
* @pcie: pointer to PCIe host info
* @reset: pointer to port reset control
- * @sys_ck: pointer to bus clock
+ * @sys_ck: pointer to transaction/data link layer clock
+ * @ahb_ck: pinter to AHB slave
[PATCH v2 3/5] dt-bindings: PCI: rename and cleanup MediaTek binding text
From: Ryder Lee
In order to accommodate other SoC generations, this patch updates filename
to make it more generic, regroups specific properties by SoCs, and removes
redundant descriptions.
Signed-off-by: Ryder Lee
---
...{mediatek,mt7623-pcie.txt => mediatek-pcie.txt} | 29 +++---
1 file changed, 14 insertions(+), 15 deletions(-)
rename Documentation/devicetree/bindings/pci/{mediatek,mt7623-pcie.txt =>
mediatek-pcie.txt} (91%)
diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
similarity index 91%
rename from Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
rename to Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index fe80dda..a968f25 100644
--- a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -1,18 +1,13 @@
-MediaTek Gen2 PCIe controller which is available on MT7623 series SoCs
-
-PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
-ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
+MediaTek Gen2 PCIe controller
Required properties:
-- compatible: Should contain "mediatek,mt7623-pcie".
+- compatible: Should contain one of the following string:
+ "mediatek,mt2701-pcie"
+ "mediatek,mt7623-pcie"
- device_type: Must be "pci"
- reg: Base addresses and lengths of the PCIe controller.
- #address-cells: Address representation for root ports (must be 3)
- #size-cells: Size representation for root ports (must be 2)
-- #interrupt-cells: Size representation for interrupts (must be 1)
-- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
- Please refer to the standard PCI bus binding document for a more detailed
- explanation.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
@@ -20,12 +15,6 @@ Required properties:
- sys_ck0 :for clock of Port0
- sys_ck1 :for clock of Port1
- sys_ck2 :for clock of Port2
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - pcie-rst0 :port0 reset
- - pcie-rst1 :port1 reset
- - pcie-rst2 :port2 reset
- phys: List of PHY specifiers (used by generic PHY framework).
- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
number of PHYs as specified in *phys* property.
@@ -34,6 +23,16 @@ Required properties:
- bus-range: Range of bus numbers associated with this controller.
- ranges: Ranges for the PCI memory and I/O regions.
+Required properties for MT7623/MT2701:
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+ Please refer to the standard PCI bus binding document for a more detailed
+ explanation.
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
+ number of root ports.
+
In addition, the device tree node must have sub-nodes describing each
PCIe port interface, having the following mandatory properties:
--
2.6.4
[PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations
From: Ryder Lee
Introduce a structure "mtk_pcie_soc" to abstract the differences between
controller generations, and the .startup() hook is used to encapsulate
some SoC-dependent related setting. In doing so, the common code which
will be reused by future chips.
In addition, we change the approaches to waiting Gen2 training by using
readl_poll_timeout() calls.
Signed-off-by: Ryder Lee
Signed-off-by: Honghui Zhang
---
drivers/pci/host/pcie-mediatek.c | 81 +++-
1 file changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 5a9d858..7f952a4 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -63,6 +64,18 @@
#define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
#define PCIE_FC_CREDIT_VAL(x) ((x) << 16)
+struct mtk_pcie_port;
+
+/**
+ * struct mtk_pcie_soc - differentiate between host generations
+ * @ops: pointer to configuration access functions
+ * @startup: pointer to controller setting functions
+ */
+struct mtk_pcie_soc {
+ struct pci_ops *ops;
+ int (*startup)(struct mtk_pcie_port *port);
+};
+
/**
* struct mtk_pcie_port - PCIe port information
* @base: IO mapped register base
@@ -96,6 +109,7 @@ struct mtk_pcie_port {
* @busn: bus range
* @offset: IO / Memory offset
* @ports: pointer to PCIe port information
+ * @soc: pointer to SoC-dependent operations
*/
struct mtk_pcie {
struct device *dev;
@@ -111,13 +125,9 @@ struct mtk_pcie {
resource_size_t io;
} offset;
struct list_head ports;
+ const struct mtk_pcie_soc *soc;
};
-static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
-{
- return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
-}
-
static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
{
struct device *dev = pcie->dev;
@@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
.write = pci_generic_config_write,
};
-static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
+static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
{
struct mtk_pcie *pcie = port->pcie;
u32 func = PCI_FUNC(port->index << 3);
u32 slot = PCI_SLOT(port->index << 3);
u32 val;
+ int err;
+
+ /* assert port PERST_N */
+ val = readl(pcie->base + PCIE_SYS_CFG);
+ val |= PCIE_PORT_PERST(port->index);
+ writel(val, pcie->base + PCIE_SYS_CFG);
+
+ /* de-assert port PERST_N */
+ val = readl(pcie->base + PCIE_SYS_CFG);
+ val &= ~PCIE_PORT_PERST(port->index);
+ writel(val, pcie->base + PCIE_SYS_CFG);
+
+ /* 100ms timeout value should be enough for Gen1/2 training */
+ err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
+!!(val & PCIE_PORT_LINKUP), 20,
+100 * USEC_PER_MSEC);
+ if (err)
+ return -ETIMEDOUT;
/* enable interrupt */
val = readl(pcie->base + PCIE_INT_ENABLE);
@@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct mtk_pcie_port
*port)
writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
pcie->base + PCIE_CFG_ADDR);
writel(val, pcie->base + PCIE_CFG_DATA);
-}
-static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
-{
- struct mtk_pcie *pcie = port->pcie;
- u32 val;
-
- /* assert port PERST_N */
- val = readl(pcie->base + PCIE_SYS_CFG);
- val |= PCIE_PORT_PERST(port->index);
- writel(val, pcie->base + PCIE_SYS_CFG);
-
- /* de-assert port PERST_N */
- val = readl(pcie->base + PCIE_SYS_CFG);
- val &= ~PCIE_PORT_PERST(port->index);
- writel(val, pcie->base + PCIE_SYS_CFG);
-
- /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
- msleep(100);
+ return 0;
}
static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
{
- struct device *dev = port->pcie->dev;
+ struct mtk_pcie *pcie = port->pcie;
+ struct device *dev = pcie->dev;
int err;
err = clk_prepare_enable(port->sys_ck);
@@ -250,13 +262,8 @@ static void mtk_pcie_enable_ports(struct mtk_pcie_port
*port)
goto err_phy_on;
}
- mtk_pcie_assert_ports(port);
-
- /* if link up, then setup root port configuration space */
- if (mtk_pcie_link_up(port)) {
- mtk_pcie_configure_rc(port);
+ if (!pcie->soc->startup(port))
return;
- }
dev_info(dev, "Port%d link down\n", port->index);
@@ -480,7 +487,7 @@ static int mtk_pcie_register_host(struct pci_host_bridge
*host)
host->busnr = pcie->busn.start;
host->dev.parent = pcie->dev;
- host->ops = &mtk_pcie_ops;
+ host->ops = pcie->soc-
[PATCH v2 0/5] PCI: MediaTek: Add support for new generation host controller
From: Honghui Zhang MediaTek's PCIe host controller has two generation HWs, the new generation HW has two root ports, it shares most probing flow with the legacy controller. But the read/write config space logical is different from the lagacy controller. This patchset abstract the common probing flow, and add support for the new generation controller. Changes since v1: - Fix build warnings in arm arch. - Using SoC specific compatible instead of generic compatible. - Add devicetree binding example for mt7622. - Unified the register define names with PCIE_ prefix. - Cleanup some un-necessary condition determine when starup port. - minor code cleanups. Ryder Lee (5): PCI: mediatek: Add a structure to abstract the controller generations PCI: mediatek: switch to use platform_get_resource_byname() dt-bindings: PCI: rename and cleanup MediaTek binding text PCI: mediatek: Add new generation controller support dt-bindings: PCI: add support for new generation controller .../bindings/pci/mediatek,mt7623-pcie.txt | 130 - .../devicetree/bindings/pci/mediatek-pcie.txt | 283 ++ drivers/pci/host/Kconfig | 5 +- drivers/pci/host/pcie-mediatek.c | 588 +++-- 4 files changed, 829 insertions(+), 177 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie.txt -- 2.6.4
Re: [PATCH] f2fs: let __get_victim successfully get a segno in corner case
Hi, Jay,
Sorry for the mistake in last mail, the ovp is 462, and the reserved is 235.
I check the code and have not found problems with p.max_search yet.
Just forget the this patch, since there is still 870 segments below, so
it should
not be the assumed case of this patch.
By the way, I have sent another patch to provide f2fs_balance_fs to
__write_node_page,
similar as that in __write_data_page, to avoid missing f2fs_balance_fs
in node page writeback.
Please check that.
On 2017/7/26 2:55, Jaegeuk Kim wrote:
On 07/14, Yunlong Song wrote:
Suppose that the valid blocks of each section are all over sbi->fggc_threshold,
and even has_not_enough_free_secs is true, f2fs_gc cannot do its job since the
no_fggc_candidate always returns true. As a result, the reserved segments can be
used up, and finally there is no free segment at all, and get_new_segment cannot
get a free segment, filesystem will trap into a wrong status.
To fix this, we record the segno which has a rough minimum cost and return it to
__get_victim to continue f2fs_gc's job.
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 19 ++-
fs/f2fs/segment.h | 17 ++---
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index fa3d2e2..965e783 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -178,6 +178,8 @@ static void select_policy(struct f2fs_sb_info *sbi, int
gc_type,
p->offset = 0;
else
p->offset = SIT_I(sbi)->last_victim[p->gc_mode];
+
+ p->min_cost_r = UINT_MAX;
}
static unsigned int get_max_cost(struct f2fs_sb_info *sbi,
@@ -194,7 +196,7 @@ static unsigned int get_max_cost(struct f2fs_sb_info *sbi,
return 0;
}
-static unsigned int check_bg_victims(struct f2fs_sb_info *sbi)
+static unsigned int check_bg_victims(struct f2fs_sb_info *sbi, struct
victim_sel_policy *p)
{
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
unsigned int secno;
@@ -208,11 +210,12 @@ static unsigned int check_bg_victims(struct f2fs_sb_info
*sbi)
if (sec_usage_check(sbi, secno))
continue;
- if (no_fggc_candidate(sbi, secno))
+ p->cur_segno_r = GET_SEG_FROM_SEC(sbi, secno);
+ if (no_fggc_candidate(sbi, secno, p))
continue;
clear_bit(secno, dirty_i->victim_secmap);
- return GET_SEG_FROM_SEC(sbi, secno);
+ return p->cur_segno_r;
}
return NULL_SEGNO;
}
@@ -332,7 +335,7 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
last_victim = sm->last_victim[p.gc_mode];
if (p.alloc_mode == LFS && gc_type == FG_GC) {
- p.min_segno = check_bg_victims(sbi);
+ p.min_segno = check_bg_victims(sbi, &p);
if (p.min_segno != NULL_SEGNO)
goto got_it;
}
@@ -369,8 +372,9 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
goto next;
if (gc_type == BG_GC && test_bit(secno, dirty_i->victim_secmap))
goto next;
+ p.cur_segno_r = segno;
if (gc_type == FG_GC && p.alloc_mode == LFS &&
- no_fggc_candidate(sbi, secno))
+ no_fggc_candidate(sbi, secno, &p))
goto next;
cost = get_gc_cost(sbi, segno, &p);
@@ -403,6 +407,11 @@ static int get_victim_by_default(struct f2fs_sb_info *sbi,
trace_f2fs_get_victim(sbi->sb, type, gc_type, &p,
sbi->cur_victim_sec,
prefree_segments(sbi), free_segments(sbi));
+ } else if (has_not_enough_free_secs(sbi, 0, 0)) {
+ p.min_segno = p.min_segno_r;
+ if (p.alloc_mode == LFS && gc_type == FG_GC)
+ clear_bit(GET_SEC_FROM_SEG(sbi, p.min_segno),
dirty_i->victim_secmap);
It seems you want to give a victim segment which has valid blocks larger than
fggc_threshold.
fggc: 507
reserve: 462
cnt_full: 25182
over: 25912 (>= fggc)
less: 870 (< fggc)
What is ovp segments?
It looks like there are 870 candidates for FG_GC, and GC with 103 segments must
give 104 free segments in the worst case. Is there a problem on p.max_search?
Thanks,
+ goto got_it;
}
out:
mutex_unlock(&dirty_i->seglist_lock);
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 6b871b4..7d2d0f3 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -169,6 +169,9 @@ struct victim_sel_policy {
unsigned int ofs_unit; /* bitmap search unit */
unsigned int min_cost; /* minimum cost */
unsigned int min_segno; /* segment # having min. cost */
+ unsigned int min_cost_r;/* rough minimum cost */
+ unsigned int min_segno_r; /* segment # h
Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management
Hi,
On 26 July 2017 at 20:08, Sebastian Reichel
wrote:
> Hi,
>
> On Wed, Jul 26, 2017 at 11:05:25AM +0800, Baolin Wang wrote:
>> On 25 July 2017 at 17:59, Sebastian Reichel
>> wrote:
>> > On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
>> >> Integrate with the newly added USB charger interface to limit the current
>> >> we draw from the USB input based on the input device configuration
>> >> identified by the USB stack, allowing us to charge more quickly from high
>> >> current inputs without drawing more current than specified from others.
>> >>
>> >> Signed-off-by: Mark Brown
>> >> Signed-off-by: Baolin Wang
>> >> ---
>> >> Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>> >> drivers/power/supply/wm831x_power.c | 58
>> >> ++
>> >> 2 files changed, 59 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> index 9f8b743..4e3bc07 100644
>> >> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> @@ -31,6 +31,7 @@ Required properties:
>> >> ../interrupt-controller/interrupts.txt
>> >>
>> >> Optional sub-nodes:
>> >> + - usb-phy : Contains a phandle to the USB PHY.
>> >>- regulators : Contains sub-nodes for each of the regulators supplied
>> >> by
>> >> the device. The regulators are bound using their names listed below:
>> >>
>> >> diff --git a/drivers/power/supply/wm831x_power.c
>> >> b/drivers/power/supply/wm831x_power.c
>> >> index 7082301..d3948ab 100644
>> >> --- a/drivers/power/supply/wm831x_power.c
>> >> +++ b/drivers/power/supply/wm831x_power.c
>> >> @@ -13,6 +13,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >>
>> >> #include
>> >> #include
>> >> @@ -31,6 +32,8 @@ struct wm831x_power {
>> >> char usb_name[20];
>> >> char battery_name[20];
>> >> bool have_battery;
>> >> + struct usb_phy *usb_phy;
>> >> + struct notifier_block usb_notify;
>> >> };
>> >>
>> >> static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> >> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply
>> >> *psy,
>> >> POWER_SUPPLY_PROP_VOLTAGE_NOW,
>> >> };
>> >>
>> >> +/* In milliamps */
>> >> +static const unsigned int wm831x_usb_limits[] = {
>> >> + 0,
>> >> + 2,
>> >> + 100,
>> >> + 500,
>> >> + 900,
>> >> + 1500,
>> >> + 1800,
>> >> + 550,
>> >> +};
>> >> +
>> >> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> >> +unsigned long limit, void *data)
>> >> +{
>> >> + struct wm831x_power *wm831x_power = container_of(nb,
>> >> + struct
>> >> wm831x_power,
>> >> + usb_notify);
>> >> + unsigned int i, best;
>> >> +
>> >> + /* Find the highest supported limit */
>> >> + best = 0;
>> >> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> >> + if (limit >= wm831x_usb_limits[i] &&
>> >> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> >> + best = i;
>> >> + }
>> >> +
>> >> + dev_dbg(wm831x_power->wm831x->dev,
>> >> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> >> +
>> >> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> >> + WM831X_USB_ILIM_MASK, best);
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> /*
>> >> * Battery properties
>> >> */
>> >> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device
>> >> *pdev)
>> >> }
>> >> }
>> >>
>> >> + power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev,
>> >> + "usb-phy", 0);
>> >> + if (!IS_ERR(power->usb_phy)) {
>> >> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> >> + ret = usb_register_notifier(power->usb_phy,
>> >> + &power->usb_notify);
>> >> + if (ret) {
>> >> + dev_err(&pdev->dev, "Failed to register notifier:
>> >> %d\n",
>> >> + ret);
>> >> + goto err_bat_irq;
>> >> + }
>> >> + }
>> >
>> > No error handling for power->usb_phy? I think you should bail out
>> > for all errors except for "not defined in DT". Especially I would
>> > expect probe defer handling in case the power supply driver is
>> > loaded before the phy driver.
>>
>> Make sense. So I think I need to change like below:
>>
>> power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
>> if (!IS_ERR(powe
Re: [PATCH 05/11] powerpc/topology: Remove the unused parent_node() macro
Hi Michael,
At 07/27/2017 10:21 AM, Michael Ellerman wrote:
Dou Liyang writes:
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in POWERPC platform is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/include/asm/topology.h | 2 --
1 file changed, 2 deletions(-)
Thanks for doing this series.
It's my pleasure. :)
Sincerely,
dou
Acked-by: Michael Ellerman
cheers
Re: [RFC/RFT PATCH] KVM: nVMX: fixes to nested virt interrupt injection
2017-07-24 22:20 GMT+08:00 Paolo Bonzini :
> There are three issues in nested_vmx_check_exception:
>
> 1) it is not taking PFEC_MATCH/PFEC_MASK into account, as reported
> by Wanpeng Li;
>
> 2) it should rebuild the interruption info and exit qualification fields
> from scratch, as reported by Jim Mattson, because the values from the
> L2->L0 vmexit may be invalid (e.g. if an emulated instruction causes
> a page fault, the EPT misconfig's exit qualification is incorrect).
>
> 3) CR2 and DR6 should not be written for exception intercept vmexits
> (CR2 only for AMD).
>
> This patch fixes the first two and adds a comment about the last,
> outlining the fix.
>
> Cc: Jim Mattson
> Cc: Wanpeng Li
> Signed-off-by: Paolo Bonzini
> ---
> Wanpeng, can you test this on the testcases you had for commit
I didn't observe any issue when testing the latest version of your
patch in kvm/queue.
Regards,
Wanpeng Li
> d4912215d103 ("KVM: nVMX: Fix exception injection", 2017-06-05)?
> Also, do you have a testcase for PFEC matching?
>
> arch/x86/kvm/svm.c | 10
> arch/x86/kvm/vmx.c | 71
> +++---
> 2 files changed, 67 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 4d8141e533c3..1107626938cc 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -2430,6 +2430,16 @@ static int nested_svm_check_exception(struct vcpu_svm
> *svm, unsigned nr,
> svm->vmcb->control.exit_code = SVM_EXIT_EXCP_BASE + nr;
> svm->vmcb->control.exit_code_hi = 0;
> svm->vmcb->control.exit_info_1 = error_code;
> +
> + /*
> +* FIXME: we should not write CR2 when L1 intercepts an L2 #PF
> exception.
> +* The fix is to add the ancillary datum (CR2 or DR6) to structs
> +* kvm_queued_exception and kvm_vcpu_events, so that CR2 and DR6 can
> be
> +* written only when inject_pending_event runs (DR6 would written here
> +* too). This should be conditional on a new capability---if the
> +* capability is disabled, kvm_multiple_exception would write the
> +* ancillary information to CR2 or DR6, for backwards
> ABI-compatibility.
> +*/
> if (svm->vcpu.arch.exception.nested_apf)
> svm->vmcb->control.exit_info_2 =
> svm->vcpu.arch.apf.nested_apf_token;
> else
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index d04092f821b6..b520614f9d46 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -927,6 +927,10 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
> static void copy_vmcs12_to_shadow(struct vcpu_vmx *vmx);
> static void copy_shadow_to_vmcs12(struct vcpu_vmx *vmx);
> static int alloc_identity_pagetable(struct kvm *kvm);
> +static bool vmx_get_nmi_mask(struct kvm_vcpu *vcpu);
> +static void vmx_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked);
> +static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
> + u16 error_code);
>
> static DEFINE_PER_CPU(struct vmcs *, vmxarea);
> static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
> @@ -2432,28 +2436,67 @@ static void skip_emulated_instruction(struct kvm_vcpu
> *vcpu)
> * KVM wants to inject page-faults which it got to the guest. This function
> * checks whether in a nested guest, we need to inject them to L1 or L2.
> */
> +static void nested_vmx_inject_exception_vmexit(struct kvm_vcpu *vcpu,
> + unsigned long exit_qual)
> +{
> + struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
> + unsigned int nr = vcpu->arch.exception.nr;
> + u32 intr_info = nr | INTR_INFO_VALID_MASK;
> +
> + if (vcpu->arch.exception.has_error_code) {
> + vmcs_write32(VM_EXIT_INTR_ERROR_CODE,
> vcpu->arch.exception.error_code);
> + intr_info |= INTR_INFO_DELIVER_CODE_MASK;
> + }
> +
> + if (kvm_exception_is_soft(nr))
> + intr_info |= INTR_TYPE_SOFT_EXCEPTION;
> + else
> + intr_info |= INTR_TYPE_HARD_EXCEPTION;
> +
> + if (!(vmcs12->idt_vectoring_info_field & VECTORING_INFO_VALID_MASK) &&
> + vmx_get_nmi_mask(vcpu))
> + intr_info |= INTR_INFO_UNBLOCK_NMI;
> +
> + nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI, intr_info,
> exit_qual);
> +}
> +
> static int nested_vmx_check_exception(struct kvm_vcpu *vcpu)
> {
> struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
> unsigned int nr = vcpu->arch.exception.nr;
>
> - if (!((vmcs12->exception_bitmap & (1u << nr)) ||
> - (nr == PF_VECTOR && vcpu->arch.exception.nested_apf)))
> - return 0;
> + if (nr == PF_VECTOR) {
> + if (vcpu->arch.exception.nested_apf) {
> + nested_vmx_inject_exception_vmexit(vcpu,
> +
> vcpu->arch.apf.nested_apf_toke
Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG
On 07/27/2017 01:02 AM, Michael S. Tsirkin wrote:
On Wed, Jul 26, 2017 at 11:48:41AM +0800, Wei Wang wrote:
On 07/23/2017 09:45 AM, Michael S. Tsirkin wrote:
On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote:
On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote:
On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote:
On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:
So the way I see it, there are several issues:
- internal wait - forces multiple APIs like kick/kick_sync
note how kick_sync can fail but your code never checks return code
- need to re-write the last descriptor - might not work
for alternative layouts which always expose descriptors
immediately
Probably it wasn't clear. Please let me explain the two functions here:
1) virtqueue_add_chain_desc(vq, head_id, prev_id,..):
grabs a desc from the vq and inserts it to the chain tail (which is indexed
by
prev_id, probably better to call it tail_id). Then, the new added desc
becomes
the tail (i.e. the last desc). The _F_NEXT flag is cleared for each desc
when it's
added to the chain, and set when another desc comes to follow later.
And this only works if there are multiple rings like
avail + descriptor ring.
It won't work e.g. with the proposed new layout where
writing out a descriptor exposes it immediately.
I think it can support the 1.1 proposal, too. But before getting
into that, I think we first need to deep dive into the implementation
and usage of _first/next/last. The usage would need to lock the vq
from the first to the end (otherwise, the returned info about the number
of available desc in the vq, i.e. num_free, would be invalid):
lock(vq);
add_first();
add_next();
add_last();
unlock(vq);
However, I think the case isn't this simple, since we need to check more
things
after each add_xx() step. For example, if only one entry is available at the
time
we start to use the vq, that is, num_free is 0 after add_first(), we
wouldn't be
able to add_next and add_last. So, it would work like this:
start:
...get free page block..
lock(vq)
retry:
ret = add_first(..,&num_free,);
if(ret == -ENOSPC) {
goto retry;
} else if (!num_free) {
add_chain_head();
unlock(vq);
kick & wait;
goto start;
}
next_one:
...get free page block..
add_next(..,&num_free,);
if (!num_free) {
add_chain_head();
unlock(vq);
kick & wait;
goto start;
} if (num_free == 1) {
...get free page block..
add_last(..);
unlock(vq);
kick & wait;
goto start;
} else {
goto next_one;
}
The above seems unnecessary to me to have three different APIs.
That's the reason to combine them into one virtqueue_add_chain_desc().
-- or, do you have a different thought about using the three APIs?
Implementation Reference:
struct desc_iterator {
unsigned int head;
unsigned int tail;
};
add_first(*vq, *desc_iterator, *num_free, ..)
{
if (vq->vq.num_free < 1)
return -ENOSPC;
get_desc(&desc_id);
desc[desc_id].flag &= ~_F_NEXT;
desc_iterator->head = desc_id
desc_iterator->tail = desc_iterator->head;
*num_free = vq->vq.num_free;
}
add_next(vq, desc_iterator, *num_free,..)
{
get_desc(&desc_id);
desc[desc_id].flag &= ~_F_NEXT;
desc[desc_iterator.tail].next = desc_id;
desc[desc_iterator->tail].flag |= _F_NEXT;
desc_iterator->tail = desc_id;
*num_free = vq->vq.num_free;
}
add_last(vq, desc_iterator,..)
{
get_desc(&desc_id);
desc[desc_id].flag &= ~_F_NEXT;
desc[desc_iterator.tail].next = desc_id;
desc_iterator->tail = desc_id;
add_chain_head(); // put the desc_iterator.head to the ring
}
Best,
Wei
OK I thought this over. While we might need these new APIs in
the future, I think that at the moment, there's a way to implement
this feature that is significantly simpler. Just add each s/g
as a separate input buffer.
Should it be an output buffer?
Hypervisor overwrites these pages with zeroes. Therefore it is
writeable by device: DMA_FROM_DEVICE.
Why would the hypervisor need to zero the buffer? I think it may only
need to read out the info(base,size).
I think it should be like this:
the cmd hdr buffer: input, because the hypervisor would write it to
send a cmd to the guest
the payload buffer: output, for the hypervisor to read the info
I think output means from the
driver to device (i.e. DMA_TO_DEVICE).
This part is correct I believe.
This needs zero new APIs.
I know that follow-up patches need to add a header in front
so you might be thinking: how am I going to add this
header? The answer is quite simple - add it as a separate
out header.
Host will be able to distinguish between header and pages
by looking at the direction, and - should we want to add
IN data to header - additionally size (<4K => header).
I think this works
Re: [PATCH v2] security: fix description of values returned by cap_inode_need_killpriv
On Wed, Jul 26, 2017 at 10:27:05PM -0400, Stefan Berger wrote:
> cap_inode_need_killpriv returns 1 if security.capability exists and
> has a value and inode_killpriv() is required, 0 otherwise. Fix the
> description of the return value to reflect this.
>
> Signed-off-by: Stefan Berger
Thanks, Stefan.
Reviewed-by: Serge Hallyn
> ---
> security/commoncap.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 7abebd7..1234269 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -300,10 +300,10 @@ static inline void bprm_clear_caps(struct linux_binprm
> *bprm)
> *
> * Determine if an inode having a change applied that's marked ATTR_KILL_PRIV
> * affects the security markings on that inode, and if it is, should
> - * inode_killpriv() be invoked or the change rejected?
> + * inode_killpriv() be invoked or the change rejected.
> *
> - * Returns 0 if granted; +ve if granted, but inode_killpriv() is required;
> and
> - * -ve to deny the change.
> + * Returns 1 if security.capability has a value, meaning inode_killpriv()
> + * is required, 0 otherwise, meaning inode_killpriv() is not required.
> */
> int cap_inode_need_killpriv(struct dentry *dentry)
> {
> --
> 2.7.4
[PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug
From: Liwei Song
This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common
access width firmware bug") fix the following firmware bug:
[Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
This is due to an 8-bit access width is specified for a 16-bit register,
Rearrange the condition and add 8-bit width check.
Signed-off-by: Liwei Song
---
drivers/acpi/apei/apei-base.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index da370e1..eca3d7a 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -604,12 +604,12 @@ static int apei_check_gar(struct acpi_generic_address
*reg, u64 *paddr,
*access_bit_width = 1UL << (access_size_code + 2);
/* Fixup common BIOS bug */
- if (bit_width == 32 && bit_offset == 0 && (*paddr & 0x03) == 0 &&
- *access_bit_width < 32)
- *access_bit_width = 32;
- else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
- *access_bit_width < 64)
- *access_bit_width = 64;
+ if (*access_bit_width < bit_width && bit_offset == 0) {
+ if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
+ (bit_width == 32 && (*paddr & 0x03) == 0) ||
+ (bit_width == 64 && (*paddr & 0x07) == 0))
+ *access_bit_width = bit_width;
+ }
if ((bit_width + bit_offset) > *access_bit_width) {
pr_warning(FW_BUG APEI_PFX
--
2.7.4
Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters
On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote: > On 07/26/2017 01:08 PM, Greg KH wrote: > > On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote: > > > On 07/26/2017 10:33 AM, Greg KH wrote: > > > > On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote: > > > > > On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote: > > > > > > On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov wrote: > > > > > > > On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote: > > > > > > > > The PMU/EDAC devices are all PCI devices do I need the 'struct > > > > > > > > pci_dev *'. > > > > > > > > I'm not aware of other ways to access these devices. Please > > > > > > > > enlighten > > > > > > > > me if I'm missing something. > > > > > > > > > > > > > > Me enlighten you on Cavium hardware?! You're funny. > > > > > > > > > > > > > > So I don't know whether the PCI hotplug code can run more than one > > > > > > > function upon PCI ID detection. Probably Greg will say, write a > > > > > > > multiplexer wrapper. :-) > > > > > > > > > > > > -ENOCONTEXT > > > > > > > > > > > > Anyway, pci questions are best asked on the linux-pci@vger list. > > > > > > And > > > > > > yes, all PCI devices end up with a 'struct pci_dev *' automatically. > > > > > > > > > > Simple: so they have a PCI ID of a memory contoller and want to > > > > > hotplug > > > > > two drivers for it. And those two drivers should remain independent > > > > > from > > > > > each other. > > > > > > > > Hahahahaha, no. That's crazy, you were right in guessing what my answer > > > > was going to be :) > > > > > > > > > > > > > Just to be clear about the situation, the device is a memory controller. > > > It > > > has two main behaviors we are interested in: > > > > > > A) Error Detection And Correction (EDAC). This should be connected to the > > > kernel's EDAC subsystem. An existing driver > > > (drivers/edac/thunderx_edac.c) > > > does exactly this. > > > > > > B) Performance Counters for actions taken in the corresponding memory. > > > This > > > should be connected to the kernel's perf framework as an uncore-PMU (the > > > subject of this patch set). > > > > > > It is a single PCI device. What should the driver architecture look like > > > to > > > connect it to two different kernel subsystems? > > > > Modify the drivers/edac/thunderx_edac.c code to add support for > > performance counters. > > > > Thanks Greg. This adds some clarity to the situation. > > This technique does slightly complicate the mapping of files and directories > in the kernel source tree to maintainers. > > Also, if a given configuration disables CONFIG_EDAC there is some hackery > needed to get the perf portion of the driver included. Well, you all deserve it for trying to have a single PCI device do multiple things at the same time. There's no real good reason for creating hardware that way, PCI devices are "free", you should go throw a printed copy of the PCI spec at the firmware developers who did this to you. Then get them to fix the firmware so you have multiple PCI devices... good luck! greg k-h
[PATCH v2] security: fix description of values returned by cap_inode_need_killpriv
cap_inode_need_killpriv returns 1 if security.capability exists and
has a value and inode_killpriv() is required, 0 otherwise. Fix the
description of the return value to reflect this.
Signed-off-by: Stefan Berger
---
security/commoncap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 7abebd7..1234269 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -300,10 +300,10 @@ static inline void bprm_clear_caps(struct linux_binprm
*bprm)
*
* Determine if an inode having a change applied that's marked ATTR_KILL_PRIV
* affects the security markings on that inode, and if it is, should
- * inode_killpriv() be invoked or the change rejected?
+ * inode_killpriv() be invoked or the change rejected.
*
- * Returns 0 if granted; +ve if granted, but inode_killpriv() is required; and
- * -ve to deny the change.
+ * Returns 1 if security.capability has a value, meaning inode_killpriv()
+ * is required, 0 otherwise, meaning inode_killpriv() is not required.
*/
int cap_inode_need_killpriv(struct dentry *dentry)
{
--
2.7.4
[PATCH v2 4/5] usb: xhci: Return error when host is dead in xhci_disable_slot()
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead host.
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2df601e..d6b728d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3568,10 +3568,9 @@ int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
state = readl(&xhci->op_regs->status);
if (state == 0x || (xhci->xhc_state & XHCI_STATE_DYING) ||
(xhci->xhc_state & XHCI_STATE_HALTED)) {
- xhci_free_virt_device(xhci, slot_id);
spin_unlock_irqrestore(&xhci->lock, flags);
kfree(command);
- return ret;
+ return -ENODEV;
}
ret = xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
--
2.7.4
[PATCH v2 3/5] usb: xhci: Fix memory leak when xhci_disable_slot() returns error
If xhci_disable_slot() returns success, a disable slot command trb was queued in the command ring. The command completion handler will free the virtual device data structure associated with the slot. On the other hand, when xhci_disable_slot() returns error, the invokers should take the responsibilities to free the slot related data structure. Otherwise, memory leakage happens. Signed-off-by: Lu Baolu --- drivers/usb/host/xhci.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index cb2461a..2df601e 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3547,11 +3547,9 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev) del_timer_sync(&virt_dev->eps[i].stop_cmd_timer); } - xhci_disable_slot(xhci, udev->slot_id); - /* -* Event command completion handler will free any data structures -* associated with the slot. XXX Can free sleep? -*/ + ret = xhci_disable_slot(xhci, udev->slot_id); + if (ret) + xhci_free_virt_device(xhci, udev->slot_id); } int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id) @@ -3697,7 +3695,11 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev) return 1; disable_slot: - return xhci_disable_slot(xhci, udev->slot_id); + ret = xhci_disable_slot(xhci, udev->slot_id); + if (ret) + xhci_free_virt_device(xhci, udev->slot_id); + + return 0; } /* -- 2.7.4
[PATCH v2 2/5] usb: xhci: Fix potential memory leak in xhci_disable_slot()
xhci_disable_slot() allows the invoker to pass a command pointer
as paramenter. Otherwise, it will allocate one. This will cause
memory leak when a command structure was allocated inside of this
function while queuing command trb fails. Another problem comes up
when the invoker passed a command pointer, but xhci_disable_slot()
frees it when it detects a dead host.
This patch fixes these two problems by removing the command parameter
from xhci_disable_slot().
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci.c | 30 +-
drivers/usb/host/xhci.h | 3 +--
3 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 00721e8..c862d53 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -612,7 +612,7 @@ static int xhci_enter_test_mode(struct xhci_hcd *xhci,
xhci_dbg(xhci, "Disable all slots\n");
spin_unlock_irqrestore(&xhci->lock, *flags);
for (i = 1; i <= HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
- retval = xhci_disable_slot(xhci, NULL, i);
+ retval = xhci_disable_slot(xhci, i);
if (retval)
xhci_err(xhci, "Failed to disable slot %d, %d. Enter
test mode anyway\n",
i, retval);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e69073f..cb2461a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3519,11 +3519,6 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
struct xhci_virt_device *virt_dev;
struct xhci_slot_ctx *slot_ctx;
int i, ret;
- struct xhci_command *command;
-
- command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
- if (!command)
- return;
#ifndef CONFIG_USB_DEFAULT_PERSIST
/*
@@ -3539,10 +3534,8 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
/* If the host is halted due to driver unload, we still need to free the
* device.
*/
- if (ret <= 0 && ret != -ENODEV) {
- kfree(command);
+ if (ret <= 0 && ret != -ENODEV)
return;
- }
virt_dev = xhci->devs[udev->slot_id];
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
@@ -3554,22 +3547,21 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
del_timer_sync(&virt_dev->eps[i].stop_cmd_timer);
}
- xhci_disable_slot(xhci, command, udev->slot_id);
+ xhci_disable_slot(xhci, udev->slot_id);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
*/
}
-int xhci_disable_slot(struct xhci_hcd *xhci, struct xhci_command *command,
- u32 slot_id)
+int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
{
+ struct xhci_command *command;
unsigned long flags;
u32 state;
int ret = 0;
- if (!command)
- command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
+ command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
return -ENOMEM;
@@ -3588,7 +3580,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct
xhci_command *command,
slot_id);
if (ret) {
spin_unlock_irqrestore(&xhci->lock, flags);
- xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
+ kfree(command);
return ret;
}
xhci_ring_cmd_db(xhci);
@@ -3663,6 +3655,8 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
return 0;
}
+ xhci_free_command(xhci, command);
+
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
spin_lock_irqsave(&xhci->lock, flags);
ret = xhci_reserve_host_control_ep_resources(xhci);
@@ -3698,18 +3692,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct
usb_device *udev)
pm_runtime_get_noresume(hcd->self.controller);
#endif
-
- xhci_free_command(xhci, command);
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
disable_slot:
- /* Disable slot, if we can do it without mem alloc */
- kfree(command->completion);
- command->completion = NULL;
- command->status = 0;
- return xhci_disable_slot(xhci, command, udev->slot_id);
+ return xhci_disable_slot(xhci, udev->slot_id);
}
/*
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e3e9352..6325d58 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2003,8 +2003,7 @@ int xhci_
[PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. This patch handles USB transaction errors on address command completion events. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb&m=149362010728921&w=2 http://marc.info/?l=linux-usb&m=149252752825755&w=2 Suggested-by: Mathias Nyman Signed-off-by: Lu Baolu --- drivers/usb/host/xhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index d6b728d..95780f8 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, break; case COMP_USB_TRANSACTION_ERROR: dev_warn(&udev->dev, "Device not responding to setup %s.\n", act); + + ret = xhci_disable_slot(xhci, udev->slot_id); + if (!ret) + xhci_alloc_dev(hcd, udev); + ret = -EPROTO; break; case COMP_INCOMPATIBLE_DEVICE_ERROR: -- 2.7.4
