[PATCH] ASoC: da7219: read fmw property to get mclk for non-dts systems
Non-dts based systems can use ACPI DSDT to pass on the mclk
to da7219.
This enables da7219 mclk to be linked to system clock.
Enable/Disable of the mclk is already handled in the codec so
platform drivers don't have to explicitly do handling of mclk.
Signed-off-by: Akshu Agrawal
---
include/sound/da7219.h| 2 ++
sound/soc/codecs/da7219.c | 7 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/sound/da7219.h b/include/sound/da7219.h
index 1bfcb16..df7ddf4 100644
--- a/include/sound/da7219.h
+++ b/include/sound/da7219.h
@@ -38,6 +38,8 @@ struct da7219_pdata {
const char *dai_clks_name;
+ const char *mclk_name;
+
/* Mic */
enum da7219_micbias_voltage micbias_lvl;
enum da7219_mic_amp_in_sel mic_amp_in_sel;
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 980a6a8..47ffb35 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -1624,6 +1624,8 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct
snd_soc_component *compone
dev_warn(dev, "Using default clk name: %s\n",
pdata->dai_clks_name);
+ device_property_read_string(dev, "dlg,mclk-name", &pdata->mclk_name);
+
if (device_property_read_u32(dev, "dlg,micbias-lvl", &of_val32) >= 0)
pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, of_val32);
else
@@ -1905,7 +1907,10 @@ static int da7219_probe(struct snd_soc_component
*component)
da7219_handle_pdata(component);
/* Check if MCLK provided */
- da7219->mclk = devm_clk_get(component->dev, "mclk");
+ if (da7219->pdata->mclk_name)
+ da7219->mclk = clk_get(NULL, da7219->pdata->mclk_name);
+ if (!da7219->mclk)
+ da7219->mclk = devm_clk_get(codec->dev, "mclk");
if (IS_ERR(da7219->mclk)) {
if (PTR_ERR(da7219->mclk) != -ENOENT) {
ret = PTR_ERR(da7219->mclk);
--
1.9.1
[PATCH] ASoC: da7219: read fmw property to get mclk for non-dts systems
Non-dts based systems can use ACPI DSDT to pass on the mclk
to da7219.
This enables da7219 mclk to be linked to system clock.
Enable/Disable of the mclk is already handled in the codec so
platform drivers don't have to explicitly do handling of mclk.
Signed-off-by: Akshu Agrawal
---
include/sound/da7219.h| 2 ++
sound/soc/codecs/da7219.c | 7 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/sound/da7219.h b/include/sound/da7219.h
index 1bfcb16..df7ddf4 100644
--- a/include/sound/da7219.h
+++ b/include/sound/da7219.h
@@ -38,6 +38,8 @@ struct da7219_pdata {
const char *dai_clks_name;
+ const char *mclk_name;
+
/* Mic */
enum da7219_micbias_voltage micbias_lvl;
enum da7219_mic_amp_in_sel mic_amp_in_sel;
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 980a6a8..47ffb35 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -1624,6 +1624,8 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct
snd_soc_component *compone
dev_warn(dev, "Using default clk name: %s\n",
pdata->dai_clks_name);
+ device_property_read_string(dev, "dlg,mclk-name", &pdata->mclk_name);
+
if (device_property_read_u32(dev, "dlg,micbias-lvl", &of_val32) >= 0)
pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, of_val32);
else
@@ -1905,7 +1907,10 @@ static int da7219_probe(struct snd_soc_component
*component)
da7219_handle_pdata(component);
/* Check if MCLK provided */
- da7219->mclk = devm_clk_get(component->dev, "mclk");
+ if (da7219->pdata->mclk_name)
+ da7219->mclk = clk_get(NULL, da7219->pdata->mclk_name);
+ if (!da7219->mclk)
+ da7219->mclk = devm_clk_get(codec->dev, "mclk");
if (IS_ERR(da7219->mclk)) {
if (PTR_ERR(da7219->mclk) != -ENOENT) {
ret = PTR_ERR(da7219->mclk);
--
1.9.1
Re: [PATCH] video: fbdev: omap2: remove rfbi
On 27/04/18 21:12, Aaro Koskinen wrote: >> You should be targeting omapdrm driver instead, fbdev subsystem is closed >> for the new hardware support. > > AFAIK, based on N950 display support discussion, it's impossible to get > anything new into omapdrm for a long time. And based on Tomi's comments, > restoring RFBI support with omapfb should be a minor thing. I was perhaps a bit vague, but I didn't say it should be a minor thing. I meant that there should be no architectural obstacles in omapfb, and I think all the generic plumbing to enable N800 display is there in omapfb. That said, it still needs a real amount of work with the rfbi driver, the encoder driver and the panel driver on N800 (the encoder and the panel driver are not in mainline anymore). Also, if I remember right, omapfb doesn't support automatic updates (or "flushing") with manual update displays. omapfb was designed to depend on the userspace to flush the framebuffer. This may limit its uses. I personally do think that it would be better to target omapdrm, on top of the manual update series, but as discussed, the schedule to support manual update is still unclear. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 2/2] soc: mediatek: add a fixed wait for SRAM stable
On Fri, 2018-04-27 at 11:46 +0200, Matthias Brugger wrote:
> Hi Sean,
>
> On 04/23/2018 11:39 AM, Sean Wang wrote:
> > On Mon, 2018-04-23 at 11:31 +0200, Matthias Brugger wrote:
> >>
> >> On 04/23/2018 10:36 AM, sean.w...@mediatek.com wrote:
> >>> From: Sean Wang
> >>>
> >>> MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes
> >>> stable, which is not like the behavior the other power domains should
> >>> have. Therefore, it's necessary for such a power domain to have a fixed
> >>> and well-predefined duration to wait until its managed SRAM can be allowed
> >>> to access by all functions running on the top.
> >>>
> >>> v1 -> v2:
> >>> - use MTK_SCPD_FWAIT_SRAM flag as an indication requiring force waiting.
> >>>
> >>> Signed-off-by: Sean Wang
> >>> Cc: Matthias Brugger
> >>> Cc: Ulf Hansson
> >>> Cc: Weiyi Lu
> >>> ---
> >>> drivers/soc/mediatek/mtk-scpsys.c | 24 ++--
> >>> 1 file changed, 18 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> >>> b/drivers/soc/mediatek/mtk-scpsys.c
> >>> index b1b45e4..d4f1a63 100644
> >>> --- a/drivers/soc/mediatek/mtk-scpsys.c
> >>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> >>> @@ -32,6 +32,7 @@
> >>> #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> >>>
> >>> #define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
> >>> +#define MTK_SCPD_FWAIT_SRAM BIT(1)
> >>> #define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data->caps & (_x))
> >>>
> >>> #define SPM_VDE_PWR_CON 0x0210
> >>> @@ -237,11 +238,22 @@ static int scpsys_power_on(struct generic_pm_domain
> >>> *genpd)
> >>> val &= ~scpd->data->sram_pdn_bits;
> >>> writel(val, ctl_addr);
> >>>
> >>> - /* wait until SRAM_PDN_ACK all 0 */
> >>> - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> >>> - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >>> - if (ret < 0)
> >>> - goto err_pwr_ack;
> >>> + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> >>> + if (!MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
>
> After having another look on the patch, could you change the order of the if:
> So that we check for the existence of the MTK_SCPD_FWAIT_SRAM and sleep and in
> the else branch we to the readl_poll_timeout.
>
> I think in the future this will make the code easier to understand as you can
> easily oversee the '!' negation in the if.
>
> Regards,
> Matthias
>
Initial thought on the patch is that I would like to save a branch
instruction for a most possibly executed block. Or would it be better to
add a compiler to branch prediction information? something like that
/* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
if (unlikely(MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM))) {
/*
* Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
* MT7622_POWER_DOMAIN_WB and thus just a trivial setup
is
* applied here.
*/
usleep_range(12000, 12100);
...
>
> >>> + ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> >>> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >>> + if (ret < 0)
> >>> + goto err_pwr_ack;
> >>> + } else {
> >>> + /*
> >>> + * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> >>> + * MT7622_POWER_DOMAIN_WB and thus just a trivial setup is
> >>> + * applied here. If there're more domains which need to force
> >>> + * waiting for its own pre-defined value, the duration should
> >>> + * be coded in the caps field.
> >>> + */
> >>
> >> I would say, if necessary in the future we can add a switch statement here.
> >> Other then that the patches look good. If you are OK, I'll just delete the
> >> last
> >> sentence when applying the patch.
> >>
> >
> > yes, it's okay for me.
> >
> >> Regards,
> >> Matthias
> >>
> >>> + usleep_range(12000, 12100);
> >>> + };
> >>>
> >>> if (scpd->data->bus_prot_mask) {
> >>> ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> >>> @@ -785,7 +797,7 @@ static const struct scp_domain_data
> >>> scp_domain_data_mt7622[] = {
> >>> .sram_pdn_ack_bits = 0,
> >>> .clk_id = {CLK_NONE},
> >>> .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
> >>> - .caps = MTK_SCPD_ACTIVE_WAKEUP,
> >>> + .caps = MTK_SCPD_ACTIVE_WAKEUP | MTK_SCPD_FWAIT_SRAM,
> >>> },
> >>> };
> >>>
> >>>
> >
> >
[PATCH] clk: x86: Add ST oscout platform clock
Stoney SoC provides oscout clock. This clock can support 25Mhz and
48Mhz of frequency.
The clock is available for general system use.
Signed-off-by: Akshu Agrawal
---
drivers/clk/x86/Makefile | 1 +
drivers/clk/x86/clk-st.c | 80
include/linux/platform_data/clk-st.h | 32 +++
3 files changed, 113 insertions(+)
create mode 100644 drivers/clk/x86/clk-st.c
create mode 100644 include/linux/platform_data/clk-st.h
diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile
index 1367afb..f7ebae1 100644
--- a/drivers/clk/x86/Makefile
+++ b/drivers/clk/x86/Makefile
@@ -1,3 +1,4 @@
clk-x86-lpss-objs := clk-lpt.o
obj-$(CONFIG_X86_INTEL_LPSS) += clk-x86-lpss.o
obj-$(CONFIG_PMC_ATOM) += clk-pmc-atom.o
+obj-$(CONFIG_X86) += clk-st.o
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c
new file mode 100644
index 000..6ac0dc5
--- /dev/null
+++ b/drivers/clk/x86/clk-st.c
@@ -0,0 +1,80 @@
+/*
+ * clock framework for AMD Stoney based clocks
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* Clock Driving Strength 2 register */
+#define CLKDRVSTR2 0x28
+/* Clock Control 1 register */
+#define MISCCLKCNTL1 0x40
+/* Auxiliary clock1 enable bit */
+#define OSCCLKENB 2
+/* 25Mhz auxiliary output clock freq bit */
+#define OSCOUT1CLK25MHZ16
+
+static const char * const clk_oscout1_parents[] = { "clk48MHz", "clk25MHz" };
+
+static int st_clk_probe(struct platform_device *pdev)
+{
+ struct st_clk_data *st_data;
+ struct clk *clk_48m;
+ struct clk *clk_25m;
+ struct clk *clk_oscout1_mux;
+ struct clk *clk_oscout1;
+
+ st_data = dev_get_platdata(&pdev->dev);
+ if (!st_data || !st_data->base)
+ return -EINVAL;
+
+ clk_48m = clk_register_fixed_rate(NULL, "clk48MHz", NULL, 0,
+ 4800);
+ clk_25m = clk_register_fixed_rate(NULL, "clk25MHz", NULL, 0,
+ 2500);
+
+ clk_oscout1_mux = clk_register_mux(NULL, "oscout1_mux",
+ clk_oscout1_parents, ARRAY_SIZE(clk_oscout1_parents),
+ 0, st_data->base + CLKDRVSTR2, OSCOUT1CLK25MHZ, 3, 0, NULL);
+
+ clk_set_parent(clk_oscout1_mux, clk_25m);
+
+ clk_oscout1 = clk_register_gate(NULL, "oscout1", "oscout1_mux",
+ 0, st_data->base + MISCCLKCNTL1, OSCCLKENB,
+ CLK_GATE_SET_TO_DISABLE, NULL);
+
+ clk_register_clkdev(clk_oscout1, "oscout1", NULL);
+
+ return 0;
+}
+
+static struct platform_driver st_clk_driver = {
+ .driver = {
+ .name = "clk-st",
+ },
+ .probe = st_clk_probe,
+};
+builtin_platform_driver(st_clk_driver);
diff --git a/include/linux/platform_data/clk-st.h
b/include/linux/platform_data/clk-st.h
new file mode 100644
index 000..5ede980
--- /dev/null
+++ b/include/linux/platform_data/clk-st.h
@@ -0,0 +1,32 @@
+/*
+ * clock framework for AMD Stoney based clock
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE
[PATCH 1/2] ARM: dts: stm32: add qspi support for stm32mp157c
From: Ludovic Barre
This patch adds qspi support on stm32mp157c,
read in memory mapped, write in indirect mode.
Signed-off-by: Ludovic Barre
---
arch/arm/boot/dts/stm32mp157c.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index bfcf84b..7714949 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -5,6 +5,7 @@
*/
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -167,6 +168,16 @@
#reset-cells = <1>;
};
+ qspi: qspi@58003000 {
+ compatible = "st,stm32f469-qspi";
+ reg = <0x58003000 0x1000>, <0x7000 0x1000>;
+ reg-names = "qspi", "qspi_mm";
+ interrupts = ;
+ clocks = <&rcc QSPI_K>;
+ resets = <&rcc QSPI_R>;
+ status = "disabled";
+ };
+
usart1: serial@5c00 {
compatible = "st,stm32h7-uart";
reg = <0x5c00 0x400>;
--
2.7.4
[PATCH 0/2] ARM: dts: stm32: add qspi support for stm32mp157c
From: Ludovic Barre This patch series adds qspi support for stm32mp157c SoC and its eval board. Ludovic Barre (2): ARM: dts: stm32: add qspi support for stm32mp157c ARM: dts: stm32: add flash nor support on stm32mp157c eval board arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 45 +++ arch/arm/boot/dts/stm32mp157c-ev1.dts | 25 + arch/arm/boot/dts/stm32mp157c.dtsi| 11 3 files changed, 81 insertions(+) -- 2.7.4
[PATCH] ACPI: APD: Add AMD misc clock handler support
AMD SoC exposes clock for general purpose use. The clock registration
is done in clk-st driver. The MMIO mapping are passed on to the
clock driver for accessing the registers.
The misc clock handler will create MMIO mappings to access the
clock registers and enable the clock driver to expose the clock
for use of drivers which will connect to it.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index d553b00..6328031 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -72,6 +73,54 @@ static int acpi_apd_setup(struct apd_private_data *pdata)
}
#ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
+
+static int misc_check_res(struct acpi_resource *ares, void *data)
+{
+ struct resource res;
+
+ return !acpi_dev_resource_memory(ares, &res);
+}
+
+static int st_misc_setup(struct apd_private_data *pdata)
+{
+ struct acpi_device *adev = pdata->adev;
+ struct platform_device *clkdev;
+ struct st_clk_data *clk_data;
+ struct resource_entry *rentry;
+ struct list_head resource_list;
+ int ret;
+
+ clk_data = devm_kzalloc(&adev->dev, sizeof(*clk_data), GFP_KERNEL);
+ if (!clk_data)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&resource_list);
+ ret = acpi_dev_get_resources(adev, &resource_list, misc_check_res,
+NULL);
+ if (ret < 0) {
+ devm_kfree(&adev->dev, clk_data);
+ return -ENOMEM;
+ }
+
+ list_for_each_entry(rentry, &resource_list, node) {
+ clk_data->base = ioremap(rentry->res->start,
+resource_size(rentry->res));
+ break;
+ }
+
+ acpi_dev_free_resource_list(&resource_list);
+
+ clkdev = platform_device_register_data(&adev->dev, "clk-st",
+ PLATFORM_DEVID_NONE, clk_data,
+ sizeof(*clk_data));
+ if (IS_ERR(clkdev)) {
+ kfree(clk_data);
+ return PTR_ERR(clkdev);
+ }
+
+ return 0;
+}
+
static const struct apd_device_desc cz_i2c_desc = {
.setup = acpi_apd_setup,
.fixed_clk_rate = 13300,
@@ -94,6 +143,10 @@ static int acpi_apd_setup(struct apd_private_data *pdata)
.fixed_clk_rate = 4800,
.properties = uart_properties,
};
+
+static const struct apd_device_desc st_misc_desc = {
+ .setup = st_misc_setup,
+};
#endif
#ifdef CONFIG_ARM64
@@ -179,6 +232,7 @@ static int acpi_apd_create_device(struct acpi_device *adev,
{ "AMD0020", APD_ADDR(cz_uart_desc) },
{ "AMDI0020", APD_ADDR(cz_uart_desc) },
{ "AMD0030", },
+ { "AMD0040", APD_ADDR(st_misc_desc)},
#endif
#ifdef CONFIG_ARM64
{ "APMC0D0F", APD_ADDR(xgene_i2c_desc) },
--
1.9.1
[PATCH 2/2] ARM: dts: stm32: add flash nor support on stm32mp157c eval board
From: Ludovic Barre
This patch adds flash nor on qspi. Each flash is
connected in quad mode and has its own chip select.
Signed-off-by: Ludovic Barre
---
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 45 +++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 25 +
2 files changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 6f044100..9d4c553 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -146,6 +146,51 @@
gpio-ranges = <&pinctrl 0 160 8>;
};
+ qspi_clk_pins_a: qspi-clk-0 {
+ pins {
+ pinmux = ;
/* QSPI_CLK */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ };
+
+ qspi_bk1_pins_a: qspi-bk1-0 {
+ pins1 {
+ pinmux = ,
/* QSPI_BK1_IO0 */
+,
/* QSPI_BK1_IO1 */
+,
/* QSPI_BK1_IO2 */
+;
/* QSPI_BK1_IO3 */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ pins2 {
+ pinmux = ;
/* QSPI_BK1_NCS */
+ bias-pull-up;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ };
+
+ qspi_bk2_pins_a: qspi-bk2-0 {
+ pins1 {
+ pinmux = ,
/* QSPI_BK2_IO0 */
+,
/* QSPI_BK2_IO1 */
+,
/* QSPI_BK2_IO2 */
+;
/* QSPI_BK2_IO3 */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ pins2 {
+ pinmux = ;
/* QSPI_BK2_NCS */
+ bias-pull-up;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ };
+
uart4_pins_a: uart4@0 {
pins1 {
pinmux = ;
/* UART4_TX */
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts
b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 57e6dbc..96c2aee 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -19,3 +19,28 @@
serial0 = &uart4;
};
};
+
+&qspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a &qspi_bk2_pins_a>;
+ reg = <0x58003000 0x1000>, <0x7000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash0: mx66l51235l@0 {
+ reg = <0>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <10800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+ flash1: mx66l51235l@1 {
+ reg = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <10800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
--
2.7.4
Re: [v2 1/1] i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()
On Fri, Apr 27, 2018 at 02:06:58PM +0200, Wolfram Sang wrote: > On Thu, Apr 19, 2018 at 03:29:22PM +0300, Alexander Popov wrote: > > i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which > > returns ZERO_SIZE_PTR if i2c_msg.len is zero. > > > > Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case > > of I2C_M_RD | I2C_M_RECV_LEN transfer. That causes a kernel oops in > > case of zero len. > > > > Let's check the len against zero before dereferencing buf pointer. > > > > This issue was triggered by syzkaller. > > > > Signed-off-by: Alexander Popov > > Applied to for-current with the arithmetic expression changed to '< 1' > to keep in sync with the previous one. Will push out soon, so you can > double check if you are interested. Thanks, I like it. An added bonus is also that you don't need to think about the type of msgs[i].len and what happens if it is negative. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support
On Fri, Apr 27, 2018 at 01:21:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patchset removes unused MERAM support (last user was removed > 3 years ago) from shmobile fbdev & drm drivers and then removes > MERAM driver itself. > > If it is okay to merge this patches I would like patch #1 to go > through fbdev tree and patch #2 to go through drm tree. Once they > are both upstream (v4.18) I will apply patch #3 to fbdev tree. Nice to see this cleanup, thanks. Reviewed-by: Simon Horman
Re: [PATCH 03/11] ASoC: amd: added byte count register offset variables to rtd
On Monday 30 April 2018 03:09 AM, Daniel Kurtz wrote:
Hi Vijendar,
On Thu, Apr 26, 2018 at 5:14 AM Vijendar Mukunda
wrote:
Added byte count register offset variables to audio_substream_data
structure. Modified dma pointer callback.
Signed-off-by: Vijendar Mukunda
Please fix the small indentation nits, otherwise this one is:
Reviewed-by: Daniel Kurtz
---
sound/soc/amd/acp-pcm-dma.c | 36 +++-
sound/soc/amd/acp.h | 2 ++
2 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f18ed9a..019f696 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -793,12 +793,18 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
rtd->destination = TO_ACP_I2S_1;
rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
+ rtd->byte_cnt_high_reg_offset =
+ mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH;
Indent relative to line above with 2 tabs.
we will fix it and will post fresh patch.
+ rtd->byte_cnt_low_reg_offset =
mmACP_I2S_TRANSMIT_BYTE_CNT_LOW;
} else {
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
rtd->destination = FROM_ACP_I2S_1;
rtd->dma_dscr_idx_1 = CAPTURE_START_DMA_DESCR_CH14;
rtd->dma_dscr_idx_2 = CAPTURE_START_DMA_DESCR_CH15;
+ rtd->byte_cnt_high_reg_offset =
+ mmACP_I2S_RECEIVED_BYTE_CNT_HIGH;
here too.
we will fix it and will post fresh patch.
+ rtd->byte_cnt_low_reg_offset =
mmACP_I2S_RECEIVED_BYTE_CNT_LOW;
}
size = params_buffer_bytes(params);
@@ -834,26 +840,15 @@ static int acp_dma_hw_free(struct snd_pcm_substream
*substream)
return snd_pcm_lib_free_pages(substream);
}
-static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+static u64 acp_get_byte_count(struct audio_substream_data *rtd)
{
- union acp_dma_count playback_dma_count;
- union acp_dma_count capture_dma_count;
- u64 bytescount = 0;
+ union acp_dma_count byte_count;
- if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
- playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
- mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
- playback_dma_count.bcount.low = acp_reg_read(acp_mmio,
- mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
- bytescount = playback_dma_count.bytescount;
- } else {
- capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
- mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
- capture_dma_count.bcount.low = acp_reg_read(acp_mmio,
- mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
- bytescount = capture_dma_count.bytescount;
- }
- return bytescount;
+ byte_count.bcount.high = acp_reg_read(rtd->acp_mmio,
+
rtd->byte_cnt_high_reg_offset);
+ byte_count.bcount.low = acp_reg_read(rtd->acp_mmio,
+
rtd->byte_cnt_low_reg_offset);
+ return byte_count.bytescount;
}
static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream
*substream)
@@ -869,7 +864,7 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
snd_pcm_substream *substream)
return -EINVAL;
buffersize = frames_to_bytes(runtime, runtime->buffer_size);
- bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
+ bytescount = acp_get_byte_count(rtd);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->i2ssp_renderbytescount)
@@ -925,8 +920,7 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
- bytescount = acp_get_byte_count(rtd->acp_mmio,
- substream->stream);
+ bytescount = acp_get_byte_count(rtd);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (rtd->i2ssp_renderbytescount == 0)
rtd->i2ssp_renderbytescount = bytescount;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 5e25428..3b076c6 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -90,6 +90,8 @@ struct audio_substream_data {
u16 destination;
u16 dma_dscr_idx_1;
u16 dma_dscr_idx_2;
+ u32 byte_cnt_high_reg_offset;
+ u32 byte_cnt_low_reg_offset;
uint64_t size;
u64 i2ssp_renderbytescount;
u64 i2ssp_capturebytescount;
--
2.
[PATCH 2/3] nds32: To refine readability of INT_MASK_INITAIAL_VAL
Refine readability of INT_MASK_INITAIAL_VAL with meaningful macro instead of magic number. Signed-off-by: Greentime Hu --- arch/nds32/include/asm/bitfield.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/nds32/include/asm/bitfield.h b/arch/nds32/include/asm/bitfield.h index c73f71d67744..28b7d797fd59 100644 --- a/arch/nds32/include/asm/bitfield.h +++ b/arch/nds32/include/asm/bitfield.h @@ -336,7 +336,7 @@ #define INT_MASK_mskIDIVZE ( 0x1 << INT_MASK_offIDIVZE ) #define INT_MASK_mskDSSIM ( 0x1 << INT_MASK_offDSSIM ) -#define INT_MASK_INITAIAL_VAL 0x10003 +#define INT_MASK_INITAIAL_VAL (INT_MASK_mskDSSIM|INT_MASK_mskIDIVZE) /** * ir15: INT_PEND (Interrupt Pending Register) -- 1.9.5
[PATCH 1/3] nds32: Fix the virtual address may map too much range by tlbop issue.
We use tlbop to map virtual address in the first beginning, however it may map too much if DRAM size is not that big. We have to invalidate the mapping when the page table is created. Signed-off-by: Greentime Hu --- arch/nds32/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c index ba910e9e4ecb..2f5b2ccebe47 100644 --- a/arch/nds32/kernel/setup.c +++ b/arch/nds32/kernel/setup.c @@ -293,6 +293,9 @@ void __init setup_arch(char **cmdline_p) /* paging_init() sets up the MMU and marks all pages as reserved */ paging_init(); + /* invalidate all TLB entries because the new mapping is created */ + __nds32__tlbop_flua(); + /* use generic way to parse */ parse_early_param(); -- 1.9.5
[PATCH 3/3] nds32: To fix a cache inconsistency issue by setting correct cacheability of NTC
The nds32 architecture will use physical memory when interrupt or exception comes and it will use the setting of NTC0-4. The original implementation didn't consider the DRAM start address may start from 1GB, 2GB or 3GB to cause this issue. It will write the data to DRAM if it is running in physical address however kernel will read the data with virtaul address through data cache. In this case, the data of DRAM is latest. This fix will set the correct cacheability to let kernel write/read the latest data in cache instead of DRAM. Signed-off-by: Greentime Hu --- arch/nds32/include/asm/bitfield.h | 1 + arch/nds32/kernel/head.S | 28 +++- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/arch/nds32/include/asm/bitfield.h b/arch/nds32/include/asm/bitfield.h index 28b7d797fd59..8e84fc385b94 100644 --- a/arch/nds32/include/asm/bitfield.h +++ b/arch/nds32/include/asm/bitfield.h @@ -396,6 +396,7 @@ #define MMU_CTL_D8KB 1 #define MMU_CTL_UNA( 0x1 << MMU_CTL_offUNA ) +#define MMU_CTL_CACHEABLE_NON 0 #define MMU_CTL_CACHEABLE_WB 2 #define MMU_CTL_CACHEABLE_WT 3 diff --git a/arch/nds32/kernel/head.S b/arch/nds32/kernel/head.S index 71f57bd70f3b..c5fdae174ced 100644 --- a/arch/nds32/kernel/head.S +++ b/arch/nds32/kernel/head.S @@ -57,14 +57,32 @@ _nodtb: isb mtsr$r4, $L1_PPTB ! load page table pointer\n" -/* set NTC0 cacheable/writeback, mutliple page size in use */ +#ifdef CONFIG_CPU_DCACHE_DISABLE + #define MMU_CTL_NTCC MMU_CTL_CACHEABLE_NON +#else + #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH + #define MMU_CTL_NTCC MMU_CTL_CACHEABLE_WT + #else + #define MMU_CTL_NTCC MMU_CTL_CACHEABLE_WB + #endif +#endif + +/* set NTC cacheability, mutliple page size in use */ mfsr$r3, $MMU_CTL - li $r0, #~MMU_CTL_mskNTC0 - and $r3, $r3, $r0 +#if CONFIG_MEMORY_START >= 0xc000 + ori $r3, $r3, (MMU_CTL_NTCC << MMU_CTL_offNTC3) +#elif CONFIG_MEMORY_START >= 0x8000 + ori $r3, $r3, (MMU_CTL_NTCC << MMU_CTL_offNTC2) +#elif CONFIG_MEMORY_START >= 0x4000 + ori $r3, $r3, (MMU_CTL_NTCC << MMU_CTL_offNTC1) +#else + ori $r3, $r3, (MMU_CTL_NTCC << MMU_CTL_offNTC0) +#endif + #ifdef CONFIG_ANDES_PAGE_SIZE_4KB - ori $r3, $r3, #(MMU_CTL_mskMPZIU|(MMU_CTL_CACHEABLE_WB << MMU_CTL_offNTC0)) + ori $r3, $r3, #(MMU_CTL_mskMPZIU) #else - ori $r3, $r3, #(MMU_CTL_mskMPZIU|(MMU_CTL_CACHEABLE_WB << MMU_CTL_offNTC0)|MMU_CTL_D8KB) + ori $r3, $r3, #(MMU_CTL_mskMPZIU|MMU_CTL_D8KB) #endif #ifdef CONFIG_HW_SUPPORT_UNALIGNMENT_ACCESS li $r0, #MMU_CTL_UNA -- 1.9.5
Re: [RESEND PATCH v4.9, 1/1] mmc: sdhci-dwc-mshc-pci: synopsys dwc mshc support
Hi Adrian, Yes, this patch was meant for linux stable. Thank you pointing me the corresponding rules. We are planning to port our driver to mainline. We will submit the patch for mainline when it's ready. Thanks, Prabu On 4/26/2018 3:27 PM, Adrian Hunter wrote: > On 12/04/18 18:47, Prabu Thangamuthu wrote: >> This patch is intended for linux-4.9.y branch. > Do you mean linux stable? That means you need to follow stable kernel rules: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_Documentation_process_stable-2Dkernel-2Drules.rst&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=Hr8lNh6yuL8thqr0BTH-LcNHR7jkWxQSt_H5NZCoTxI&m=cNM2NjAiX5xnDfckYjMch_0XeHrBjgCHYbcQHjkmVn8&s=D44hBUjJ0oaWFI_OdPQkcDHl5Ou8XJR7tMYW-H3TOhk&e= >
Re: [PATCH 04/11] ASoC: amd: removed separate byte count variables for playback and capture
On Monday 30 April 2018 03:11 AM, Daniel Kurtz wrote:
Hi Vijendar,
On Thu, Apr 26, 2018 at 5:15 AM Vijendar Mukunda
wrote:
Removed separate byte count variables for playback and capture.
Signed-off-by: Vijendar Mukunda
Reviewed-by: Daniel Kurtz
---
sound/soc/amd/acp-pcm-dma.c | 19 +--
sound/soc/amd/acp.h | 3 +--
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 019f696..5f34be1 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -866,13 +866,8 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
snd_pcm_substream *substream)
buffersize = frames_to_bytes(runtime, runtime->buffer_size);
bytescount = acp_get_byte_count(rtd);
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- if (bytescount > rtd->i2ssp_renderbytescount)
- bytescount = bytescount -
rtd->i2ssp_renderbytescount;
- } else {
- if (bytescount > rtd->i2ssp_capturebytescount)
- bytescount = bytescount -
rtd->i2ssp_capturebytescount;
- }
+ if (bytescount > rtd->bytescount)
+ bytescount = bytescount - rtd->bytescount;
nit, this could be:
bytescount -= rtd->bytescount;
we will fix it and will share fresh patch.
pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
}
@@ -921,9 +916,9 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
bytescount = acp_get_byte_count(rtd);
+ if (rtd->bytescount == 0)
+ rtd->bytescount = bytescount;
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- if (rtd->i2ssp_renderbytescount == 0)
- rtd->i2ssp_renderbytescount = bytescount;
acp_dma_start(rtd->acp_mmio, rtd->ch1, false);
while (acp_reg_read(rtd->acp_mmio,
mmACP_DMA_CH_STS) &
BIT(rtd->ch1)) {
@@ -934,9 +929,6 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
}
cpu_relax();
}
- } else {
- if (rtd->i2ssp_capturebytescount == 0)
- rtd->i2ssp_capturebytescount = bytescount;
}
acp_dma_start(rtd->acp_mmio, rtd->ch2, true);
ret = 0;
@@ -947,12 +939,11 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
acp_dma_stop(rtd->acp_mmio, rtd->ch1);
ret = acp_dma_stop(rtd->acp_mmio, rtd->ch2);
- rtd->i2ssp_renderbytescount = 0;
} else {
acp_dma_stop(rtd->acp_mmio, rtd->ch2);
ret = acp_dma_stop(rtd->acp_mmio, rtd->ch1);
- rtd->i2ssp_capturebytescount = 0;
}
+ rtd->bytescount = 0;
break;
default:
ret = -EINVAL;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 3b076c6..82470bc 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -93,8 +93,7 @@ struct audio_substream_data {
u32 byte_cnt_high_reg_offset;
u32 byte_cnt_low_reg_offset;
uint64_t size;
- u64 i2ssp_renderbytescount;
- u64 i2ssp_capturebytescount;
+ u64 bytescount;
void __iomem *acp_mmio;
};
--
2.7.4
Re: [PATCH v3 11/12] KVM: arm/arm64: Implement KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION
Hi Christoffer,
On 04/24/2018 11:06 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:57AM +0200, Eric Auger wrote:
>> Now all the internals are ready to handle multiple redistributor
>> regions, let's allow the userspace to register them.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v2 -> v3:
>> - early exit if vgic_v3_rdist_region_from_index() fails
>> ---
>> virt/kvm/arm/vgic/vgic-kvm-device.c | 42
>> +++--
>> virt/kvm/arm/vgic/vgic-mmio-v3.c| 4 ++--
>> virt/kvm/arm/vgic/vgic.h| 9 +++-
>> 3 files changed, 50 insertions(+), 5 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> index e7b5a86..00e03d3 100644
>> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> @@ -65,7 +65,8 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64
>> *addr, bool write)
>> {
>> int r = 0;
>> struct vgic_dist *vgic = &kvm->arch.vgic;
>> -phys_addr_t *addr_ptr, alignment;
>> +phys_addr_t *addr_ptr = NULL;
>> +phys_addr_t alignment;
>> uint64_t undef_value = VGIC_ADDR_UNDEF;
>
> nit: mussed this one before, type should be u64
>
>>
>> mutex_lock(&kvm->lock);
>> @@ -92,7 +93,7 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64
>> *addr, bool write)
>> if (r)
>> break;
>> if (write) {
>> -r = vgic_v3_set_redist_base(kvm, *addr);
>> +r = vgic_v3_set_redist_base(kvm, 0, *addr, 0);
>> goto out;
>> }
>> rdreg = list_first_entry(&vgic->rd_regions,
>> @@ -103,6 +104,42 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type,
>> u64 *addr, bool write)
>> addr_ptr = &rdreg->base;
>> break;
>> }
>> +case KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION:
>> +{
>> +struct vgic_redist_region *rdreg;
>> +uint8_t index;
>> +
>
> we tend to use u8, u32, etc. in the kernel.
>
>> +r = vgic_check_type(kvm, KVM_DEV_TYPE_ARM_VGIC_V3);
>> +if (r)
>> +break;
>> +
>> +index = *addr & KVM_VGIC_V3_RDIST_INDEX_MASK;
>> +
>> +if (write) {
>> +gpa_t base = *addr & KVM_VGIC_V3_RDIST_BASE_MASK;
>> +uint32_t count = (*addr & KVM_VGIC_V3_RDIST_COUNT_MASK)
>> +>> KVM_VGIC_V3_RDIST_COUNT_SHIFT;
>> +uint8_t flags = (*addr & KVM_VGIC_V3_RDIST_FLAGS_MASK)
>> +>> KVM_VGIC_V3_RDIST_FLAGS_SHIFT;
>> +
>> +if (!count || flags)
>> +r = -EINVAL;
>> +else
>> +r = vgic_v3_set_redist_base(kvm, index,
>> +base, count);
>> +goto out;
>> +}
>> +
>> +rdreg = vgic_v3_rdist_region_from_index(kvm, index);
>> +if (!rdreg) {
>> +r = -ENODEV;
>> +goto out;
>> +}
>> +
>> +*addr_ptr = rdreg->base & index &
>> +(uint64_t)rdreg->count << KVM_VGIC_V3_RDIST_COUNT_SHIFT;
>
> This looks fairly broken, isn't this a clear null pointer dereference?
>
> (If we're making this ioctl read-only using the parameter as both in/out
> for set/get, that should also be documented in the API text, then you
> should consider writing a small test along with your userspace
> implementation to actually test that functionality - otherwise we should
> just make this write-only and omit the index part. It could be said
> that retrieving what the kernel actually has is a reasonable debug
> feature.)
>
> I think you want (notice the | instead of & as well):
>
> *addr = index;
> *addr |= rdreg->base;
> *addr |= (u64)rdreg->count << KVM_VGIC_V3_RDIST_COUNT_SHIFT;
> goto out;
>
> It is then debatable if the addr_ptr construct gets too convoluted when
> not used in every case, and if the logic should be embedded into each
> case, and the addr_ptr variable dropped. Meh, I don't mind leaving it
> for now.
Please apologize, I skipped this email while respinning into v4. Those
are definitively 2 bugs and I fixed them as you suggested above. As for
the documentation, I added:
"
The characteristics of a specific redistributor region can be read
by presetting the index field in the attr data.
Errors:
../..
-ENOENT: Attempt to read the characteristics of a non existing
redistributor region
"
Currently testing the read path with a hacked qemu ;-)
Thanks
Eric
>
>
>> +break;
>> +}
>> default:
>> r = -ENODEV;
>> }
>> @@ -674,6 +711,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>>
Re: [PATCH] spi: mediatek: Use of_device_get_match_data()
Hi Mark, Is it okay with you? On Mon, 2018-04-16 at 10:33 +0800, Ryder Lee (李庚?V) wrote: > The usage of of_device_get_match_data() reduce the code size a bit. > > Also, the only way to call mtk_spi_probe() is to match an entry in > mtk_spi_of_match[], so of_id cannot be NULL. > > Signed-off-by: Ryder Lee > --- > drivers/spi/spi-mt65xx.c | 12 +++- > 1 file changed, 3 insertions(+), 9 deletions(-) >
Re: [PATCH v2 06/11] arm64: dts: r8a77965: Add FCPF and FCPV instances
On Fri, Apr 27, 2018 at 05:57:17PM +0100, Kieran Bingham wrote: > The FCPs handle the interface between various IP cores and memory. Add > the instances related to the FDPs and VSP2s. > > Based on a similar patch of the R8A7796 device tree > by Laurent Pinchart . > > Signed-off-by: Takeshi Kihara > [Kieran: Rebase to top of tree] > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied.
Re: [PATCH v2 07/11] arm64: dts: r8a77965: Add VSP instances
On Fri, Apr 27, 2018 at 05:57:18PM +0100, Kieran Bingham wrote: > The r8a77965 has 4 VSP instances. > > Based on a similar patch of the R8A7796 device tree > by Laurent Pinchart . > > Signed-off-by: Takeshi Kihara > [Kieran: Rebased to top of tree, fixed sort orders] > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied.
Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces
On 4/29/2018 2:24 AM, Kani, Toshi wrote: On Sat, 2018-04-28 at 11:02 +0200, j...@8bytes.org wrote: On Fri, Apr 27, 2018 at 02:31:51PM +, Kani, Toshi wrote: So, we can add the step 2 on top of this patch. 1. Clear pud/pmd entry. 2. System wide TLB flush <-- TO BE ADDED BY NEW PATCH 3. Free its underlining pmd/pte page. This still lacks the page-table synchronization and will thus not fix the BUG_ON being triggered. The BUG_ON issue is specific to PAE that it syncs at the pmd level. x86/64 does not have this issue since it syncs at the pgd or p4d level. We do not need to revert this patch. We can make the above change I mentioned. Please note that we are not in the merge window anymore and that any fix needs to be simple and obviously correct. Understood. Changing the x86/32 sync point is risky. So, I am going to revert the free page handling for PAE. Will this affect pmd_free_pte_page() & pud_free_pmd_page() 's existence or its parameters ? I'm asking because, I've similar change for arm64 and ready to send v9 patches. I'm thinking to share my v9 patches in any case. If you are going to do TLB invalidation within these APIs, my first patch will help. Thanks, -Toshi ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Chintan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 08/11] arm64: dts: r8a77965: Populate the DU instance placeholder
On Fri, Apr 27, 2018 at 05:57:19PM +0100, Kieran Bingham wrote: > The DU entity node has been previously added but only as a placeholder. > Populate the node with the properties to use the device. > > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied.
Re: [PATCH v2 09/11] arm64: dts: r8a77965: Add HDMI encoder instance
On Fri, Apr 27, 2018 at 05:57:20PM +0100, Kieran Bingham wrote: > Add the HDMI encoder to the R8A77965 DT in disabled state. > > Based on a similar patch of the R8A7796 device tree > by Laurent Pinchart . > > Signed-off-by: Takeshi Kihara > [Kieran: Rebase to top of tree] > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied.
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
On Sat, Apr 28, 2018 at 12:34:26AM +0300, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Friday, 27 April 2018 19:57:21 EEST Kieran Bingham wrote: > > The DU1 external dot clock is provided by the fixed frequency clock > > generator X21, while the DU0 and DU3 clocks are provided by the > > programmable Versaclock5 clock generator. > > > > Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board > > and hook it up to the HDMI connector. > > > > Based on patches from Takeshi Kihara > > > > Signed-off-by: Kieran Bingham > > Reviewed-by: Laurent Pinchart Thanks, applied.
Re: [PATCH v2 01/17] dt-bindings: power: reset: mt6323: add bindings for MT6323 power controller
On Fri, 2018-04-27 at 15:02 -0500, Rob Herring wrote:
> On Wed, Apr 25, 2018 at 05:32:27PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Adding device-tree binding for the power controller which is a tiny
> > circuit block present as a part of MT6323 PMIC and is responsible for
> > externally powering off or on a remote SoC the PMIC is connected to.
> >
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Sean Wang
> > ---
> > .../bindings/power/reset/mt6323-poweroff.txt | 20
> >
> > 1 file changed, 20 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
> > b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
> > new file mode 100644
> > index 000..6f7c590
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
> > @@ -0,0 +1,20 @@
> > +Device Tree Bindings for Power Controller on MediaTek PMIC
> > +
> > +The power controller which could be found on PMIC is responsible for
> > externally
> > +powering off or on the remote MediaTek SoC through the circuit BBPU.
> > +
> > +Required properties:
> > +- compatible: Should be one of follows
> > + "mediatek,mt6323-pwrc": for MT6323 PMIC
> > +
> > +Example:
> > +
> > + pmic {
> > + compatible = "mediatek,mt6323";
> > +
> > + ...
> > +
> > + power-controller {
> > + compatible = "mediatek,mt6323-pwrc";
>
> Why do you need this in DT? It doesn't define any resources. The parent
> can just as well register a reset or poweroff handler.
>
> Rob
>
Yes, those binding can be removed.
I tend to use platform_device_register_data embedded in mfd driver
to probe the existent poweroff driver in the next version.
> > + };
> > + }
> > --
> > 2.7.4
> >
[PATCH 01/12] gpio: 74xx-mmio: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-74xx-mmio.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-74xx-mmio.c b/drivers/gpio/gpio-74xx-mmio.c
index 0475e8ec96d0..49616ec815ee 100644
--- a/drivers/gpio/gpio-74xx-mmio.c
+++ b/drivers/gpio/gpio-74xx-mmio.c
@@ -105,27 +105,22 @@ static int mmio_74xx_dir_out(struct gpio_chip *gc,
unsigned int gpio, int val)
static int mmio_74xx_gpio_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id;
struct mmio_74xx_gpio_priv *priv;
struct resource *res;
void __iomem *dat;
int err;
- of_id = of_match_device(mmio_74xx_gpio_ids, &pdev->dev);
- if (!of_id)
- return -ENODEV;
-
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
+ priv->flags = (uintptr_t)of_device_get_match_data(&pdev->dev);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dat = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dat))
return PTR_ERR(dat);
- priv->flags = (uintptr_t) of_id->data;
-
err = bgpio_init(&priv->gc, &pdev->dev,
DIV_ROUND_UP(MMIO_74XX_BIT_CNT(priv->flags), 8),
dat, NULL, NULL, NULL, NULL, 0);
--
2.17.0
[PATCH 11/12] gpio: vf610: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-vf610.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-vf610.c b/drivers/gpio/gpio-vf610.c
index 4610cc2938ad..d4ad6d0e02a2 100644
--- a/drivers/gpio/gpio-vf610.c
+++ b/drivers/gpio/gpio-vf610.c
@@ -254,8 +254,6 @@ static struct irq_chip vf610_gpio_irq_chip = {
static int vf610_gpio_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id = of_match_device(vf610_gpio_dt_ids,
- &pdev->dev);
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct vf610_gpio_port *port;
@@ -267,7 +265,7 @@ static int vf610_gpio_probe(struct platform_device *pdev)
if (!port)
return -ENOMEM;
- port->sdata = of_id->data;
+ port->sdata = of_device_get_match_data(dev);
iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
port->base = devm_ioremap_resource(dev, iores);
if (IS_ERR(port->base))
--
2.17.0
[PATCH 09/12] gpio: syscon: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-syscon.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 537cec7583fc..2512acd99027 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -182,20 +182,15 @@ MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
static int syscon_gpio_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- const struct of_device_id *of_id;
struct syscon_gpio_priv *priv;
struct device_node *np = dev->of_node;
int ret;
- of_id = of_match_device(syscon_gpio_ids, dev);
- if (!of_id)
- return -ENODEV;
-
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
- priv->data = of_id->data;
+ priv->data = of_device_get_match_data(dev);
if (priv->data->compatible) {
priv->syscon = syscon_regmap_lookup_by_compatible(
--
2.17.0
[PATCH 02/12] gpio: dwapb: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-dwapb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 226977f78482..c25fa72d499f 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -684,13 +684,7 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
gpio->flags = 0;
if (dev->of_node) {
- const struct of_device_id *of_devid;
-
- of_devid = of_match_device(dwapb_of_match, dev);
- if (of_devid) {
- if (of_devid->data)
- gpio->flags = (uintptr_t)of_devid->data;
- }
+ gpio->flags = (uintptr_t)of_device_get_match_data(dev);
} else if (has_acpi_companion(dev)) {
const struct acpi_device_id *acpi_id;
--
2.17.0
[PATCH 12/12] gpio: xlp: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-xlp.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-xlp.c b/drivers/gpio/gpio-xlp.c
index e74bd43a6974..8e4275eaa7d7 100644
--- a/drivers/gpio/gpio-xlp.c
+++ b/drivers/gpio/gpio-xlp.c
@@ -322,14 +322,7 @@ static int xlp_gpio_probe(struct platform_device *pdev)
return irq;
if (pdev->dev.of_node) {
- const struct of_device_id *of_id;
-
- of_id = of_match_device(xlp_gpio_of_ids, &pdev->dev);
- if (!of_id) {
- dev_err(&pdev->dev, "Unable to match OF ID\n");
- return -ENODEV;
- }
- soc_type = (uintptr_t) of_id->data;
+ soc_type = (uintptr_t)of_device_get_match_data(&pdev->dev);
} else {
const struct acpi_device_id *acpi_id;
--
2.17.0
[PATCH 07/12] gpio: pca953x: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-pca953x.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index d2ead4b1cf61..9a06b8a4f5be 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -810,13 +810,11 @@ static int pca953x_probe(struct i2c_client *client,
chip->driver_data = i2c_id->driver_data;
} else {
const struct acpi_device_id *acpi_id;
- const struct of_device_id *match;
+ struct device *dev = &client->dev;
- match = of_match_device(pca953x_dt_ids, &client->dev);
- if (match) {
- chip->driver_data = (int)(uintptr_t)match->data;
- } else {
- acpi_id = acpi_match_device(pca953x_acpi_ids,
&client->dev);
+ chip->driver_data = (uintptr_t)of_device_get_match_data(dev);
+ if (!chip->driver_data) {
+ acpi_id = acpi_match_device(pca953x_acpi_ids, dev);
if (!acpi_id) {
ret = -ENODEV;
goto err_exit;
--
2.17.0
[PATCH 10/12] gpio: ts4900: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-ts4900.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-ts4900.c b/drivers/gpio/gpio-ts4900.c
index 5bd21725e604..1da8d0586329 100644
--- a/drivers/gpio/gpio-ts4900.c
+++ b/drivers/gpio/gpio-ts4900.c
@@ -128,15 +128,10 @@ MODULE_DEVICE_TABLE(of, ts4900_gpio_of_match_table);
static int ts4900_gpio_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- const struct of_device_id *match;
struct ts4900_gpio_priv *priv;
u32 ngpio;
int ret;
- match = of_match_device(ts4900_gpio_of_match_table, &client->dev);
- if (!match)
- return -EINVAL;
-
if (of_property_read_u32(client->dev.of_node, "ngpios", &ngpio))
ngpio = DEFAULT_PIN_NUMBER;
@@ -148,7 +143,7 @@ static int ts4900_gpio_probe(struct i2c_client *client,
priv->gpio_chip.label = "ts4900-gpio";
priv->gpio_chip.ngpio = ngpio;
priv->gpio_chip.parent = &client->dev;
- priv->input_bit = (uintptr_t)match->data;
+ priv->input_bit = (uintptr_t)of_device_get_match_data(&client->dev);
priv->regmap = devm_regmap_init_i2c(client, &ts4900_regmap_config);
if (IS_ERR(priv->regmap)) {
--
2.17.0
[PATCH 06/12] gpio: palmas: Use of_device_get_match_data()
From: Thierry Reding Use of_device_get_match_data() instead of open-coding it. Signed-off-by: Thierry Reding --- drivers/gpio/gpio-palmas.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpio/gpio-palmas.c b/drivers/gpio/gpio-palmas.c index 3d818195e351..ceb2fef2c8ae 100644 --- a/drivers/gpio/gpio-palmas.c +++ b/drivers/gpio/gpio-palmas.c @@ -159,13 +159,9 @@ static int palmas_gpio_probe(struct platform_device *pdev) struct palmas_platform_data *palmas_pdata; struct palmas_gpio *palmas_gpio; int ret; - const struct of_device_id *match; const struct palmas_device_data *dev_data; - match = of_match_device(of_palmas_gpio_match, &pdev->dev); - if (!match) - return -ENODEV; - dev_data = match->data; + dev_data = of_device_get_match_data(&pdev->dev); if (!dev_data) dev_data = &palmas_dev_data; -- 2.17.0
[PATCH 08/12] gpio: pxa: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-pxa.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index f480fb896963..3c1f65bc0fa8 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -579,15 +579,9 @@ static int pxa_gpio_probe_dt(struct platform_device *pdev,
struct pxa_gpio_chip *pchip)
{
int nr_gpios;
- const struct of_device_id *of_id =
- of_match_device(pxa_gpio_dt_ids, &pdev->dev);
const struct pxa_gpio_id *gpio_id;
- if (!of_id || !of_id->data) {
- dev_err(&pdev->dev, "Failed to find gpio controller\n");
- return -EFAULT;
- }
- gpio_id = of_id->data;
+ gpio_id = of_device_get_match_data(&pdev->dev);
gpio_type = gpio_id->type;
nr_gpios = gpio_id->gpio_nums;
--
2.17.0
[PATCH 05/12] gpio: mxs: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-mxs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
index 435def22445d..5ad8d4db74db 100644
--- a/drivers/gpio/gpio-mxs.c
+++ b/drivers/gpio/gpio-mxs.c
@@ -290,8 +290,6 @@ MODULE_DEVICE_TABLE(of, mxs_gpio_dt_ids);
static int mxs_gpio_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id =
- of_match_device(mxs_gpio_dt_ids, &pdev->dev);
struct device_node *np = pdev->dev.of_node;
struct device_node *parent;
static void __iomem *base;
@@ -306,7 +304,7 @@ static int mxs_gpio_probe(struct platform_device *pdev)
port->id = of_alias_get_id(np, "gpio");
if (port->id < 0)
return port->id;
- port->devid = (enum mxs_gpio_id) of_id->data;
+ port->devid = (enum mxs_gpio_id)of_device_get_match_data(&pdev->dev);
port->dev = &pdev->dev;
port->irq = platform_get_irq(pdev, 0);
if (port->irq < 0)
--
2.17.0
Re: [PATCH v2 1/2] dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740
On Thu, Apr 26, 2018 at 08:24:42PM +0200, Jacopo Mondi wrote:
> Add R-Mobile A1 R8A7740 SoC to the list of compatible values for the CEU
> unit.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Simon Horman
> ---
> Documentation/devicetree/bindings/media/renesas,ceu.txt | 7 ---
> drivers/media/platform/renesas-ceu.c| 1 +
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> index 3fc66df..8a7a616 100644
> --- a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -2,14 +2,15 @@ Renesas Capture Engine Unit (CEU)
> --
>
> The Capture Engine Unit is the image capture interface found in the Renesas
> -SH Mobile and RZ SoCs.
> +SH Mobile, R-Mobile and RZ SoCs.
>
> The interface supports a single parallel input with data bus width of 8 or 16
> bits.
>
> Required properties:
> -- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
> - and RZ/A1M SoCs.
> +- compatible: Shall be one of the following values:
> + "renesas,r7s72100-ceu" for CEU units found in RZ/A1H and RZ/A1M SoCs
> + "renesas,r8a7740-ceu" for CEU units found in R-Mobile A1 R8A7740 SoCs
Nit: I think you can drop R8A7740 as I believe that by adding it to
R-Mobile A1 you have constructed a tautology (I mean "R-Mobile A1" =
"R8A7740" as far as I know).
> - reg: Registers address base and size.
> - interrupts: The interrupt specifier.
>
> diff --git a/drivers/media/platform/renesas-ceu.c
> b/drivers/media/platform/renesas-ceu.c
> index 6599dba..c964a56 100644
> --- a/drivers/media/platform/renesas-ceu.c
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -1545,6 +1545,7 @@ static const struct ceu_data ceu_data_sh4 = {
> #if IS_ENABLED(CONFIG_OF)
> static const struct of_device_id ceu_of_match[] = {
> { .compatible = "renesas,r7s72100-ceu", .data = &ceu_data_rz },
> + { .compatible = "renesas,r8a7740-ceu", .data = &ceu_data_rz },
> { }
> };
> MODULE_DEVICE_TABLE(of, ceu_of_match);
> --
> 2.7.4
>
[PATCH 03/12] gpio: ge: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-ge.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-ge.c b/drivers/gpio/gpio-ge.c
index 1fe2d3418f2f..4c43562434cf 100644
--- a/drivers/gpio/gpio-ge.c
+++ b/drivers/gpio/gpio-ge.c
@@ -52,8 +52,6 @@ MODULE_DEVICE_TABLE(of, gef_gpio_ids);
static int __init gef_gpio_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id =
- of_match_device(gef_gpio_ids, &pdev->dev);
struct gpio_chip *gc;
void __iomem *regs;
int ret;
@@ -82,7 +80,7 @@ static int __init gef_gpio_probe(struct platform_device *pdev)
}
gc->base = -1;
- gc->ngpio = (u16)(uintptr_t)of_id->data;
+ gc->ngpio = (u16)of_device_get_match_data(&pdev->dev);
gc->of_gpio_n_cells = 2;
gc->of_node = pdev->dev.of_node;
--
2.17.0
[PATCH 04/12] gpio: ingenic: Use of_device_get_match_data()
From: Thierry Reding
Use of_device_get_match_data() instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/gpio/gpio-ingenic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-ingenic.c b/drivers/gpio/gpio-ingenic.c
index 15fb2bc796a8..e738e384a5ca 100644
--- a/drivers/gpio/gpio-ingenic.c
+++ b/drivers/gpio/gpio-ingenic.c
@@ -285,8 +285,6 @@ MODULE_DEVICE_TABLE(of, ingenic_gpio_of_match);
static int ingenic_gpio_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- const struct of_device_id *of_id = of_match_device(
- ingenic_gpio_of_match, dev);
struct ingenic_gpio_chip *jzgc;
u32 bank;
int err;
@@ -323,7 +321,7 @@ static int ingenic_gpio_probe(struct platform_device *pdev)
jzgc->gc.parent = dev;
jzgc->gc.of_node = dev->of_node;
jzgc->gc.owner = THIS_MODULE;
- jzgc->version = (enum jz_version)of_id->data;
+ jzgc->version = (enum jz_version)of_device_get_match_data(dev);
jzgc->gc.set = ingenic_gpio_set;
jzgc->gc.get = ingenic_gpio_get;
--
2.17.0
[PATCH v9 0/4] Fix issues with huge mapping in ioremap for ARM64
This series of patches takes Toshi Kani 's
patches ("fix memory leak/panic in ioremap huge pages") as base
and re-bring huge_vmap back for arm64.
This series of patches are tested on 4.16 kernel with Cortex-A75
based SoC.
The test used for verifying these patches is a stress test on
ioremap/unmap which tries to re-use same io-address but changes
size of mapping randomly i.e. 4K to 2M to 16K etc. The same test
used to reproduce 3rd level translation fault without these fixes
(and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP
mappings" being part of the tree).
These patches can also go into '-stable' branch (if accepted)
for 4.6 onwards.
>From V8->V9:
- Used __TLBI_VADDR macros in new TLB flush API
>From V7->V8:
- Properly fixed compilation issue in x86 file
>From V6->V7:
- Fixed compilation issue in x86 case
- V6 patches were not properly enumarated
>From V5->V6:
- Use __flush_tlb_kernel_pgtable() for both PUD and PMD. Remove
"bool tlb_inv" based variance as it is not need now
- Re-naming for consistency
>From V4->V5:
- Add new API __flush_tlb_kernel_pgtable(unsigned long addr)
for kernel addresses
>From V3->V4:
- Add header for 'addr' in x86 implementation
- Re-order pmd/pud clear and table free
- Avoid redundant TLB invalidatation in one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya (4):
ioremap: Update pgtable free interfaces with addr
arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
arm64: Implement page table free interfaces
Revert "arm64: Enforce BBM for huge IO/VMAP mappings"
arch/arm64/include/asm/tlbflush.h | 6 ++
arch/arm64/mm/mmu.c | 37 +
arch/x86/mm/pgtable.c | 8 +---
include/asm-generic/pgtable.h | 8
lib/ioremap.c | 4 ++--
5 files changed, 42 insertions(+), 21 deletions(-)
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
[PATCH v9 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya
---
arch/arm64/include/asm/tlbflush.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
b/arch/arm64/include/asm/tlbflush.h
index dfc61d7..a4a1901 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -218,6 +218,13 @@ static inline void __flush_tlb_pgtable(struct mm_struct
*mm,
dsb(ish);
}
+static inline void __flush_tlb_kernel_pgtable(unsigned long kaddr)
+{
+ unsigned long addr = __TLBI_VADDR(kaddr, 0);
+
+ __tlbi(vaae1is, addr);
+ dsb(ish);
+}
#endif
#endif
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
[PATCH v9 1/4] ioremap: Update pgtable free interfaces with addr
This patch ("mm/vmalloc: Add interfaces to free unmapped
page table") adds following 2 interfaces to free the page
table in case we implement huge mapping.
pud_free_pmd_page() and pmd_free_pte_page()
Some architectures (like arm64) needs to do proper TLB
maintanance after updating pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 8 +---
include/asm-generic/pgtable.h | 8
lib/ioremap.c | 4 ++--
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..da98828 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -973,12 +973,12 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ffc8c13..37e3cba 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -718,11 +718,12 @@ int pmd_clear_huge(pmd_t *pmd)
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
+ * @addr: Virtual address associated with pud.
*
* Context: The pud range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
pmd_t *pmd;
int i;
@@ -733,7 +734,7 @@ int pud_free_pmd_page(pud_t *pud)
pmd = (pmd_t *)pud_page_vaddr(*pud);
for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i]))
+ if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
return 0;
pud_clear(pud);
@@ -745,11 +746,12 @@ int pud_free_pmd_page(pud_t *pud)
/**
* pmd_free_pte_page - Clear pmd entry and free pte page.
* @pmd: Pointer to a PMD.
+ * @addr: Virtual address associated with pmd.
*
* Context: The pmd range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
pte_t *pte;
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index f59639a..b081794 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1019,8 +1019,8 @@ static inline int p4d_clear_huge(p4d_t *p4d)
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
-int pud_free_pmd_page(pud_t *pud);
-int pmd_free_pte_page(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud, unsigned long addr);
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1046,11 +1046,11 @@ static inline int pmd_clear_huge(pmd_t *pmd)
{
return 0;
}
-static inline int pud_free_pmd_page(pud_t *pud)
+static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return 0;
}
-static inline int pmd_free_pte_page(pmd_t *pmd)
+static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return 0;
}
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bba..517f585 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -92,7 +92,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long
addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
- pmd_free_pte_page(pmd)) {
+ pmd_free_pte_page(pmd, addr)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -119,7 +119,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned
long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
- pud_free_pmd_page(pud)) {
+ pud_free_pmd_page(pud, addr)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
[PATCH v9 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings"
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0f651db..170009b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -935,10 +935,6 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t
prot)
pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
- /* ioremap_page_range doesn't honour BBM */
- if (pud_present(READ_ONCE(*pudp)))
- return 0;
-
BUG_ON(phys & ~PUD_MASK);
set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot));
return 1;
@@ -949,10 +945,6 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t
prot)
pgprot_t sect_prot = __pgprot(PMD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
- /* ioremap_page_range doesn't honour BBM */
- if (pmd_present(READ_ONCE(*pmdp)))
- return 0;
-
BUG_ON(phys & ~PMD_MASK);
set_pmd(pmdp, pfn_pmd(__phys_to_pfn(phys), sect_prot));
return 1;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
[PATCH v9 3/4] arm64: Implement page table free interfaces
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya
---
arch/arm64/mm/mmu.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index da98828..0f651db 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#define NO_BLOCK_MAPPINGS BIT(0)
#define NO_CONT_MAPPINGS BIT(1)
@@ -973,12 +974,32 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud, unsigned long addr)
+int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
{
- return pud_none(*pud);
+ pmd_t *table;
+
+ if (pmd_present(READ_ONCE(*pmdp))) {
+ table = __va(pmd_val(*pmdp));
+ pmd_clear(pmdp);
+ __flush_tlb_kernel_pgtable(addr);
+ free_page((unsigned long) table);
+ }
+ return 1;
}
-int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
+int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
{
- return pmd_none(*pmd);
+ pmd_t *table;
+ int i;
+
+ if (pud_present(READ_ONCE(*pudp))) {
+ table = __va(pud_val(*pudp));
+ for (i = 0; i < PTRS_PER_PMD; i++)
+ pmd_free_pte_page(&table[i], addr + (i * PMD_SIZE));
+
+ pud_clear(pudp);
+ __flush_tlb_kernel_pgtable(addr);
+ free_page((unsigned long) table);
+ }
+ return 1;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
Re: [PATCH v1 2/4] pinctrl: tegra20: Provide CDEV1/2 clock muxes
On Fri, Apr 27, 2018 at 02:58:16AM +0300, Dmitry Osipenko wrote:
> Muxing of pins MCLK1/2 determine the muxing of the corresponding clocks.
> Make pinctrl driver to provide clock muxes for the CDEV1/2 pingroups, so
> that main clk-controller driver could get an actual parent clock for the
> CDEV1/2 clocks.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/pinctrl/tegra/pinctrl-tegra.c | 11 -
> drivers/pinctrl/tegra/pinctrl-tegra.h | 11 +
> drivers/pinctrl/tegra/pinctrl-tegra20.c | 30 -
> 3 files changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
> b/drivers/pinctrl/tegra/pinctrl-tegra.c
> index 72c718e66ebb..49c7c1499bc3 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> @@ -33,17 +33,6 @@
> #include "../pinctrl-utils.h"
> #include "pinctrl-tegra.h"
>
> -struct tegra_pmx {
> - struct device *dev;
> - struct pinctrl_dev *pctl;
> -
> - const struct tegra_pinctrl_soc_data *soc;
> - const char **group_pins;
> -
> - int nbanks;
> - void __iomem **regs;
> -};
> -
> static inline u32 pmx_readl(struct tegra_pmx *pmx, u32 bank, u32 reg)
> {
> return readl(pmx->regs[bank] + reg);
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.h
> b/drivers/pinctrl/tegra/pinctrl-tegra.h
> index 33b17cb1471e..aa33c20766c4 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra.h
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.h
> @@ -16,6 +16,17 @@
> #ifndef __PINMUX_TEGRA_H__
> #define __PINMUX_TEGRA_H__
>
> +struct tegra_pmx {
> + struct device *dev;
> + struct pinctrl_dev *pctl;
> +
> + const struct tegra_pinctrl_soc_data *soc;
> + const char **group_pins;
> +
> + int nbanks;
> + void __iomem **regs;
> +};
> +
> enum tegra_pinconf_param {
> /* argument: tegra_pinconf_pull */
> TEGRA_PINCONF_PARAM_PULL,
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra20.c
> b/drivers/pinctrl/tegra/pinctrl-tegra20.c
> index 7e38ee9bae78..f31e39d797f9 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra20.c
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra20.c
> @@ -19,6 +19,7 @@
> * more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -2231,9 +2232,36 @@ static const struct tegra_pinctrl_soc_data
> tegra20_pinctrl = {
> .drvtype_in_mux = false,
> };
>
> +static const char *cdev1_parents[4] = {
No need to have 4 here, just cdev1_parents[] will do.
> + "cdev1_osc_div", "pll_a_out0", "pll_m_out1", "audio",
> +};
> +
> +static const char *cdev2_parents[4] = {
> + "cdev2_osc_div", "hclk", "pclk", "pll_p_out4",
> +};
> +
Same here.
> +static void tegra20_pinctrl_register_clock_muxes(struct platform_device
> *pdev)
> +{
> + struct tegra_pmx *pmx = platform_get_drvdata(pdev);
> +
> + clk_register_mux(NULL, "cdev1_mux", cdev1_parents, 4, 0,
> + pmx->regs[1] + 0x8, 2, 2, CLK_MUX_READ_ONLY, NULL);
> +
> + clk_register_mux(NULL, "cdev2_mux", cdev2_parents, 4, 0,
> + pmx->regs[1] + 0x8, 4, 2, CLK_MUX_READ_ONLY, NULL);
> +}
> +
> static int tegra20_pinctrl_probe(struct platform_device *pdev)
> {
> - return tegra_pinctrl_probe(pdev, &tegra20_pinctrl);
> + int err;
> +
> + err = tegra_pinctrl_probe(pdev, &tegra20_pinctrl);
> + if (err)
> + return err;
> +
> + tegra20_pinctrl_register_clock_muxes(pdev);
> +
> + return 0;
> }
>
> static const struct of_device_id tegra20_pinctrl_of_match[] = {
Apart from these nitpicks:
Acked-By: Peter De Schrijver
Re: [PATCH v1 3/4] clk: tegra20: Set correct parents for CDEV1/2 clocks
On Fri, Apr 27, 2018 at 02:58:17AM +0300, Dmitry Osipenko wrote:
> Parents of CDEV1/2 clocks are determined by muxing of the corresponding
> pins. Pinctrl driver now provides the CDEV1/2 clock muxes and hence
> CDEV1/2 clocks could have correct parents. Set CDEV1/2 parents to the
> corresponding muxes to fix the parents.
>
> Signed-off-by: Dmitry Osipenko
Acked-By: Peter De Schrijver
> ---
> drivers/clk/tegra/clk-tegra20.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> index 16cf4108f2ff..7e8b6de86d89 100644
> --- a/drivers/clk/tegra/clk-tegra20.c
> +++ b/drivers/clk/tegra/clk-tegra20.c
> @@ -844,14 +844,12 @@ static void __init tegra20_periph_clk_init(void)
>CLK_DIVIDER_POWER_OF_TWO, NULL);
>
> /* cdev1 */
> - clk = clk_register_fixed_rate(NULL, "cdev1_fixed", NULL, 0, 2600);
> - clk = tegra_clk_register_periph_gate("cdev1", "cdev1_fixed", 0,
> + clk = tegra_clk_register_periph_gate("cdev1", "cdev1_mux", 0,
> clk_base, 0, 94, periph_clk_enb_refcnt);
> clks[TEGRA20_CLK_CDEV1] = clk;
>
> /* cdev2 */
> - clk = clk_register_fixed_rate(NULL, "cdev2_fixed", NULL, 0, 2600);
> - clk = tegra_clk_register_periph_gate("cdev2", "cdev2_fixed", 0,
> + clk = tegra_clk_register_periph_gate("cdev2", "cdev2_mux", 0,
> clk_base, 0, 93, periph_clk_enb_refcnt);
> clks[TEGRA20_CLK_CDEV2] = clk;
>
> --
> 2.17.0
>
Re: [PATCH v1 1/4] clk: tegra20: Add DEV1/DEV2 OSC dividers
On Fri, Apr 27, 2018 at 02:58:15AM +0300, Dmitry Osipenko wrote:
> CDEV1/CDEV2 clocks could have corresponding oscillator clock divider as
> a parent. Add these dividers in order to be able to provide that parent
> option.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/clk/tegra/clk-tegra20.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> index 0ee56dd04cec..16cf4108f2ff 100644
> --- a/drivers/clk/tegra/clk-tegra20.c
> +++ b/drivers/clk/tegra/clk-tegra20.c
> @@ -26,6 +26,8 @@
> #include "clk.h"
> #include "clk-id.h"
>
> +#define MISC_CLK_ENB 0x48
> +
> #define OSC_CTRL 0x50
> #define OSC_CTRL_OSC_FREQ_MASK (3<<30)
> #define OSC_CTRL_OSC_FREQ_13MHZ (0<<30)
> @@ -831,6 +833,16 @@ static void __init tegra20_periph_clk_init(void)
> periph_clk_enb_refcnt);
> clks[TEGRA20_CLK_PEX] = clk;
>
> + /* cdev1 OSC divider */
> + clk_register_divider(NULL, "cdev1_osc_div", "clk_m",
> + 0, clk_base + MISC_CLK_ENB, 20, 2,
> + CLK_DIVIDER_POWER_OF_TWO, NULL);
> +
I don't know if this divider can be changed glitchlessly so to be safe,
I would mark this readonly, so add the CLK_DIVIDER_READ_ONLY flag.
> + /* cdev2 OSC divider */
> + clk_register_divider(NULL, "cdev2_osc_div", "clk_m",
> + 0, clk_base + MISC_CLK_ENB, 22, 2,
> + CLK_DIVIDER_POWER_OF_TWO, NULL);
> +
> /* cdev1 */
> clk = clk_register_fixed_rate(NULL, "cdev1_fixed", NULL, 0, 2600);
> clk = tegra_clk_register_periph_gate("cdev1", "cdev1_fixed", 0,
> --
> 2.17.0
>
Peter.
Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC
On Thu, Apr 26, 2018 at 10:57:31AM -0700, Dave Hansen wrote:
> On 04/06/2018 06:09 PM, Ram Pai wrote:
> > Well :). my point is add this code and delete the other
> > code that you add later in that function.
>
> I don't think I'm understanding what your suggestion was. I looked at
> the code and I honestly do not think I can remove any of it.
>
> For the plain (non-explicit pkey_mprotect()) case, there are exactly
> four paths through __arch_override_mprotect_pkey(), resulting in three
> different results.
>
> 1. New prot==PROT_EXEC, no pkey-exec support -> do not override
> 2. New prot!=PROT_EXEC, old VMA not PROT_EXEC-> do not override
> 3. New prot==PROT_EXEC, w/ pkey-exec support -> override to exec pkey
> 4. New prot!=PROT_EXEC, old VMA is PROT_EXEC -> override to default
>
> I don't see any redundancy there, or any code that we can eliminate or
> simplify. It was simpler before, but that's what where bug was.
Your code is fine. But than the following code accomplishes the same
outcome; arguably with a one line change. Its not a big deal. Just
trying to clarify my comment.
int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot, int
pkey)
{
/*
* Is this an mprotect_pkey() call? If so, never
* override the value that came from the user.
*/
if (pkey != -1)
return pkey;
/*
* Look for a protection-key-drive execute-only mapping
* which is now being given permissions that are not
* execute-only. Move it back to the default pkey.
*/
if (vma_is_pkey_exec_only(vma) && (prot != PROT_EXEC)) <
return ARCH_DEFAULT_PKEY;
/*
* The mapping is execute-only. Go try to get the
* execute-only protection key. If we fail to do that,
* fall through as if we do not have execute-only
* support.
*/
if (prot == PROT_EXEC) {
pkey = execute_only_pkey(vma->vm_mm);
if (pkey > 0)
return pkey;
}
/*
* This is a vanilla, non-pkey mprotect (or we failed to
* setup execute-only), inherit the pkey from the VMA we
* are working on.
*/
return vma_pkey(vma);
}
--
Ram Pai
KASAN: use-after-free in loopback_active_get
We report the crash:
KASAN: use-after-free in loopback_active_get
This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this report.
Our analysis shows that the race occurs when invoking two syscalls concurrently,
ioctl$SNDRV_CTL_IOCTL_ELEM_READ and syz_open_dev$audion.
kernel config:
https://kiwi.cs.purdue.ed/static/race-fuzzer/KASAN_use-after-free_in_loopback_active_get.config
Analysis:
When there is a race between sound/drivers/aloop.c:895
(loopback_active_get) and sound/drivers/aloop.c:678 (free_cable), the
retrieved cable pointer in loopback_active_get() may point to the
freed memory region. When loopback_active_get() dereferences this
pointer, use-after-free occurs.
Possible CPU execution:
CPU0CPU1
loopback_active_get() free_cable()
struct loopback_cable *cable = ...
loopback->cables[substream->number][dev] = NULL;
kfree(cable);
cable->running <-- Use-after-free
Call Sequence:
CPU0
loopback_active_get
snd_ctl_elem_read
snd_ctl_elem_read_user
snd_ctl_ioctl
CPU1
free_cable
loopback_close
snd_pcm_release_substream
snd_pcm_release_substream
snd_pcm_oss_release_file
snd_pcm_oss_release_file
snd_pcm_oss_release
We observed that snd_pcm_oss_release() is called during the open("/dev/audio1")
syscall. In our configuration, the function do_dentry_open() returns -EINVAL
since below if statement is evaluated as true.
if ((f->f_flags & O_DIRECT)
(!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO))
Therefore, fput() is called and snd_pcm_oss_release() is called as a pending
work before returning to the user space. But we suspect that the insufficient
locking between snd_ctl_ioctl() and snd_pcm_oss_release(), not the vfs_layer,
is the cause of the crash.
Read of size 4 at addr 88023aa4899c by task syz-executor0/27703
CPU: 0 PID: 27703 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x182/0x24c lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
__asan_load4+0x78/0x80 mm/kasan/kasan.c:698
loopback_active_get+0x71/0xb0 sound/drivers/aloop.c:900
snd_ctl_elem_read+0x14e/0x190 sound/core/control.c:896
snd_ctl_elem_read_user sound/core/control.c:914 [inline]
snd_ctl_ioctl+0xaf7/0xce0 sound/core/control.c:1560
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x179/0xf40 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
__do_sys_ioctl fs/ioctl.c:708 [inline]
__se_sys_ioctl fs/ioctl.c:706 [inline]
__x64_sys_ioctl+0x43/0x50 fs/ioctl.c:706
do_syscall_64+0x17a/0x530 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x453bc9
RSP: 002b:7fc5fba5eaf8 EFLAGS: 0212 ORIG_RAX: 0010
RAX: ffda RBX: 00708020 RCX: 00453bc9
RDX: 20003b38 RSI: c4c85512 RDI: 0005
RBP: 25a0 R08: R09:
R10: R11: 0212 R12: 004aed78
R13: R14: 0005 R15: c4c85512
Allocated by task 27704:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:512 [inline]
kzalloc include/linux/slab.h:701 [inline]
loopback_open+0x4d2/0x720 sound/drivers/aloop.c:704
snd_pcm_open_substream+0x174/0x250 sound/core/pcm_native.c:2391
snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2423 [inline]
snd_pcm_oss_open+0x799/0xfc0 sound/core/oss/pcm_oss.c:2505
soundcore_open+0x2db/0x3e0 sound/sound_core.c:597
chrdev_open+0x1c6/0x450 fs/char_dev.c:417
do_dentry_open+0x520/0x7c0 fs/open.c:784
vfs_open+0xc5/0x120 fs/open.c:906
do_last fs/namei.c:3365 [inline]
path_openat+0x1133/0x31a0 fs/namei.c:3501
do_filp_open+0x15a/0x1e0 fs/namei.c:3535
do_sys_open+0x464/0x540 fs/open.c:1093
__do_sys_open fs/open.c: [inline]
__se_sys_open fs/open.c:1106 [inline]
__x64_sys_open+0x4c/0x60 fs/open.c:1106
do_syscall_64+0x17a/0x530 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 27704:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inl
Re: [PATCH net-next] can: dev: use skb_put_zero to simplfy code
On 04/28/2018 09:49 AM, YueHaibing wrote: > use helper skb_put_zero to replace the pattern of skb_put() && memset() > > Signed-off-by: YueHaibing Applied to linux-can-next. Tnx, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] can: cc770: fix spelling mistake: "comptibility" -> "compatibility"
On 04/29/2018 12:16 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in module parameter description text > > Signed-off-by: Colin Ian King Added to linux-can-next. Thnx, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
Quoting Jani Nikula (2018-04-27 12:20:55)
> On Wed, 25 Apr 2018, Ian W MORRISON wrote:
> > Can I ask if this is on anyone's radar as I'm concerned this patch will
> > stall otherwise?
>
> Pushed to drm-intel-next-queued, thanks for the patch.
>
> I opted to drop the Cc: stable for now. This doesn't mean it can't be
> backported later on, I'm just punting on that call right now to make
> some forward progress here.
>
> Joonas, please do pick f6d3e06f0747 ("drm/i915/glk: Add MODULE_FIRMWARE
> for Geminilake") to drm-intel-fixes to queue it to v4.17.
Done. That's the only drm-intel-fixes patch there seems to be for -rc4.
Regards, Joonas
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
Re: [PATCH v8 05/13] ACPI/PPTT: Add Processor Properties Topology Table parsing
On Friday, April 27, 2018 6:20:44 PM CEST Jeremy Linton wrote: > Hi, > > Thanks for taking a look at this. > > On 04/27/2018 06:02 AM, Rafael J. Wysocki wrote: > > On Thu, Apr 26, 2018 at 1:31 AM, Jeremy Linton > > wrote: > >> ACPI 6.2 adds a new table, which describes how processing units > >> are related to each other in tree like fashion. Caches are > >> also sprinkled throughout the tree and describe the properties > >> of the caches in relation to other caches and processing units. > >> > >> Add the code to parse the cache hierarchy and report the total > >> number of levels of cache for a given core using > >> acpi_find_last_cache_level() as well as fill out the individual > >> cores cache information with cache_setup_acpi() once the > >> cpu_cacheinfo structure has been populated by the arch specific > >> code. > >> > >> An additional patch later in the set adds the ability to report > >> peers in the topology using find_acpi_cpu_topology() > >> to report a unique ID for each processing unit at a given level > >> in the tree. These unique id's can then be used to match related > >> processing units which exist as threads, within a given > >> package, etc. > >> > >> Signed-off-by: Jeremy Linton > >> Acked-by: Sudeep Holla > >> --- > >> drivers/acpi/pptt.c | 518 > >> > >> 1 file changed, 518 insertions(+) > >> create mode 100644 drivers/acpi/pptt.c > >> > >> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > >> new file mode 100644 > >> index ..cced71ef851a > >> --- /dev/null > >> +++ b/drivers/acpi/pptt.c > >> @@ -0,0 +1,518 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * pptt.c - parsing of Processor Properties Topology Table > >> + * > >> + * Copyright (C) 2018, ARM > >> + * > >> + * This file implements parsing of Processor Properties Topology Table > >> (PPTT) > >> + * which is optionally used to describe the processor and cache topology. > >> + * Due to the relative pointers used throughout the table, this doesn't > >> + * leverage the existing subtable parsing in the kernel. > >> + * > >> + * The PPTT structure is an inverted tree, with each node potentially > >> + * holding one or two inverted tree data structures describing > >> + * the caches available at that level. Each cache structure optionally > >> + * contains properties describing the cache at a given level which can be > >> + * used to override hardware probed values. > >> + */ > >> +#define pr_fmt(fmt) "ACPI PPTT: " fmt > >> + > >> +#include > >> +#include > >> +#include > >> + > >> +/** > >> + * fetch_pptt_subtable() - Find/Verify that the PPTT ref is a valid > >> subtable > > > > The parens above are at least redundant (if not harmful). Everywhere > > else in a similar context too. > > The kerneldoc ones? I guess i'm confused the kernel doc example in > doc-guide/kernel-doc has > > * function_name() - Brief description of function. Well, OK, the parens not harmful, then, but it works without them.
Re: [PATCH 1/1] tools: power/acpi, revert to LD = gcc
On Tuesday, April 24, 2018 9:43:44 AM CEST Jiri Slaby wrote:
> Commit 7ed1c1901fe5 (tools: fix cross-compile var clobbering) removed
> setting of LD to $(CROSS_COMPILE)gcc. This broke build of acpica
> (acpidump) in power/acpi:
> ld: unrecognized option '-D_LINUX'
>
> The tools pass CFLAGS to the linker (incl. -D_LINUX), so revert this
> particular change and let LD be $(CC) again. Note that the old behaviour
> was a bit different, it used $(CROSS_COMPILE)gcc which was eliminated by
> the commit 7ed1c1901fe5. We use $(CC) for that reason.
>
> Signed-off-by: Jiri Slaby
> Cc: Martin Kelly
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Robert Moore
> Cc: Erik Schmauss
> Cc: linux-a...@vger.kernel.org
> Cc: de...@acpica.org
> ---
> tools/power/acpi/Makefile.config | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/power/acpi/Makefile.config
> b/tools/power/acpi/Makefile.config
> index 2cccbba64418..f304be71c278 100644
> --- a/tools/power/acpi/Makefile.config
> +++ b/tools/power/acpi/Makefile.config
> @@ -56,6 +56,7 @@ INSTALL_SCRIPT = ${INSTALL_PROGRAM}
> # to compile vs uClibc, that can be done here as well.
> CROSS = #/usr/i386-linux-uclibc/usr/bin/i386-uclibc-
> CROSS_COMPILE ?= $(CROSS)
> +LD = $(CC)
> HOSTCC = gcc
>
> # check if compiler option is supported
>
Applied, thanks!
Re: [PATCH v2] ACPI / button: make module loadable when booted in non-ACPI mode
On Monday, April 23, 2018 11:16:56 AM CEST Ard Biesheuvel wrote:
> Modules such as nouveau.ko and i915.ko have a link time dependency on
> acpi_lid_open(), and due to its use of acpi_bus_register_driver(),
> the button.ko module that provides it is only loadable when booted in
> ACPI mode. However, the ACPI button driver can be built into the core
> kernel as well, in which case the dependency can always be satisfied,
> and the dependent modules can be loaded regardless of whether the
> system was booted in ACPI mode or not.
>
> So let's fix this asymmetry by making the ACPI button driver loadable
> as a module even if not booted in ACPI mode, so it can provide the
> acpi_lid_open() symbol in the same way as when built into the kernel.
>
> Signed-off-by: Ard Biesheuvel
> ---
> v2: invert acpi_disabled logic and move comment into
> __acpi_bus_register_driver
>
> Could we perhaps get this into -stable as well? It is not a classic
> regression, but it completely breaks, e.g., Fedora when booting in
> DT mode on an ARM system.
>
> drivers/acpi/button.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index e1eee7a60fad..f33242e4fe6c 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -635,4 +635,26 @@ module_param_call(lid_init_state,
> NULL, 0644);
> MODULE_PARM_DESC(lid_init_state, "Behavior for reporting LID initial state");
>
> -module_acpi_driver(acpi_button_driver);
> +static int __acpi_bus_register_driver(struct acpi_driver *driver)
> +{
> + /*
> + * Modules such as nouveau.ko and i915.ko have a link time dependency
> + * on acpi_lid_open(), and would therefore not be loadable on ACPI
> + * capable kernels booted in non-ACPI mode if we use the ordinary
> + * acpi_bus_[un]register_driver routines here (which only work when
> + * booted in ACPI mode) and build this driver as a module. So provide
> + * our own versions instead.
> + */
> + if (acpi_disabled)
> + return 0;
> + return acpi_bus_register_driver(driver);
> +}
> +
> +static void __acpi_bus_unregister_driver(struct acpi_driver *driver)
> +{
> + if (!acpi_disabled)
> + acpi_bus_unregister_driver(driver);
> +}
> +
> +module_driver(acpi_button_driver, __acpi_bus_register_driver,
> + __acpi_bus_unregister_driver);
>
Applied (with some minor modifications) and merged into 4.17-rc3, thanks!
Re: [PATCH v3 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation
Hi Rob,
On 27 April 2018 at 22:51, Rob Herring wrote:
> On Thu, Apr 26, 2018 at 05:12:33PM +0800, Baolin Wang wrote:
>> From: Xiaotong Lu
>>
>> This patch adds the binding documentation for Spreadtrum SC27xx series
>> vibrator device.
>>
>> Signed-off-by: Xiaotong Lu
>> Signed-off-by: Baolin Wang
>> ---
>> Changes since v2:
>> - No updates.
>>
>> Changes since v1:
>> - No updates.
>> ---
>> .../bindings/input/sprd,sc27xx-vibra.txt | 12
>> 1 file changed, 12 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>>
>> diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>> b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>> new file mode 100644
>> index 000..92ead29
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>> @@ -0,0 +1,12 @@
>> +Spreadtrum SC27xx PMIC Vibrator
>> +
>> +Required properties:
>> +- compatible: should be "sprd,sc27xx-vibrator".
>> +- reg: address of vibrator control register.
>> +
>> +Example :
>> +
>> +vibrator@eb4 {
>> + compatible = "sprd,sc27xx-vibrator";
>> + reg = <0xeb4>;
>
> What bus is this on? A mmio bus needs a length. Is this part of some
> other block?
>
It's on one PMIC bus mapped by regmap-spi. Will add the PMIC part in
next version:
sc2731_pmic: pmic@0 {
compatible = "sprd,sc2731";
reg = <0>;
spi-max-frequency = <2600>;
interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
#address-cells = <1>;
#size-cells = <0>;
vibrator@eb4 {
compatible = "sprd,sc27xx-vibrator";
reg = <0xeb4>;
};
};
Is that OK for you? Thanks.
--
Baolin.wang
Best Regards
Re: [PATCH 02/11] ASoC: amd: dma config parameters changes
On Monday 30 April 2018 03:19 AM, Daniel Kurtz wrote:
Hi Vijendar,
On Thu, Apr 26, 2018 at 5:14 AM Vijendar Mukunda
wrote:
Added dma configuration parameters to rtd structure.
Moved dma configuration parameters intialization to
hw_params callback.
Removed hard coding in prepare and trigger callbacks.
Signed-off-by: Vijendar Mukunda
---
sound/soc/amd/acp-pcm-dma.c | 97
+
sound/soc/amd/acp.h | 5 +++
2 files changed, 41 insertions(+), 61 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 9c026c4..f18ed9a 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -321,19 +321,12 @@ static void config_acp_dma(void __iomem *acp_mmio,
u32 asic_type)
{
u32 pte_offset, sram_bank;
- u16 ch1, ch2, destination, dma_dscr_idx;
if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK) {
pte_offset = ACP_PLAYBACK_PTE_OFFSET;
- ch1 = SYSRAM_TO_ACP_CH_NUM;
- ch2 = ACP_TO_I2S_DMA_CH_NUM;
sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
- destination = TO_ACP_I2S_1;
-
} else {
pte_offset = ACP_CAPTURE_PTE_OFFSET;
- ch1 = SYSRAM_TO_ACP_CH_NUM;
- ch2 = ACP_TO_I2S_DMA_CH_NUM;
Wait... since this is the capture stream, shouldn't the channels have been:
ch1 = ACP_TO_SYSRAM_CH_NUM; /* 14 */
ch2 = I2S_TO_ACP_DMA_CH_NUM; /* 15 */
Is this an existing bug? Why does everything still work if these are wrong?
You are correct. We Will fix it and share fresh patch.
switch (asic_type) {
case CHIP_STONEY:
sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
@@ -341,30 +334,19 @@ static void config_acp_dma(void __iomem *acp_mmio,
default:
sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
}
- destination = FROM_ACP_I2S_1;
}
-
acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
pte_offset);
- if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
- dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
- else
- dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
-
/* Configure System memory <-> ACP SRAM DMA descriptors */
set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
- rtd->direction, pte_offset, ch1,
- sram_bank, dma_dscr_idx,
asic_type);
-
- if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
- dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH13;
- else
- dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH15;
+ rtd->direction, pte_offset,
+ rtd->ch1, sram_bank,
+ rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
rtd->direction, sram_bank,
- destination, ch2, dma_dscr_idx,
- asic_type);
+ rtd->destination, rtd->ch2,
+ rtd->dma_dscr_idx_2, asic_type);
}
/* Start a given DMA channel transfer */
@@ -804,6 +786,21 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
acp_reg_write(val, adata->acp_mmio,
mmACP_I2S_16BIT_RESOLUTION_EN);
}
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
+ rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
+ rtd->destination = TO_ACP_I2S_1;
+ rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
+ rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
+ } else {
+ rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
+ rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
+ rtd->destination = FROM_ACP_I2S_1;
+ rtd->dma_dscr_idx_1 = CAPTURE_START_DMA_DESCR_CH14;
+ rtd->dma_dscr_idx_2 = CAPTURE_START_DMA_DESCR_CH15;
+ }
+
I think you should do this initialization in acp_dma_open(), where the
audio_substream_data is kzalloc'ed and otherwise initialized to match the
provided snd_pcm_substream.
The idea to move initialization from acp_dma_open() to
acp_dma_hw_params() callback is to exchange platform data between
machine driver and dma driver.
So that during initialization we can use data from machine driver and do
platform specific initialization where and when required.
In Current scenario, by the time new stream open call invoked, dma
Re: [PATCH v4 10/15] memory: tegra: Introduce memory client hot reset
On Fri, Apr 13, 2018 at 02:33:49PM +0300, Dmitry Osipenko wrote: > In order to reset busy HW properly, memory controller needs to be > involved, otherwise it is possible to get corrupted memory or hang machine > if HW was reset during DMA. Introduce memory client 'hot reset' that will > be used for resetting of busy HW. > > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/mc.c | 210 ++ > drivers/memory/tegra/mc.h | 2 + > include/soc/tegra/mc.h| 33 ++ > 3 files changed, 245 insertions(+) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH v4 09/15] memory: tegra: Squash tegra20-mc into common tegra-mc driver
On Mon, Apr 09, 2018 at 10:28:31PM +0300, Dmitry Osipenko wrote: > Tegra30+ has some minor differences in registers / bits layout compared > to Tegra20. Let's squash Tegra20 driver into the common tegra-mc driver > in a preparation for the upcoming MC hot reset controls implementation, > avoiding code duplication. > > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/Kconfig | 10 -- > drivers/memory/Makefile| 1 - > drivers/memory/tegra/Makefile | 1 + > drivers/memory/tegra/mc.c | 120 +-- > drivers/memory/tegra/mc.h | 11 ++ > drivers/memory/tegra/tegra20.c | 178 + > drivers/memory/tegra20-mc.c| 254 > - > include/soc/tegra/mc.h | 2 +- > 8 files changed, 299 insertions(+), 278 deletions(-) > create mode 100644 drivers/memory/tegra/tegra20.c > delete mode 100644 drivers/memory/tegra20-mc.c I've applied this now and squashed in patch "memory: tegra: Remove handling of MC_GART_ERROR_REQ on Tegra20". Thanks, Thierry signature.asc Description: PGP signature
Re: [PATCH v4 12/15] memory: tegra: Add Tegra124 memory controller hot resets
On Fri, Apr 13, 2018 at 02:33:51PM +0300, Dmitry Osipenko wrote: > Define the table of memory controller hot resets for Tegra124. > > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/tegra124.c | 42 + > 1 file changed, 42 insertions(+) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH v4 11/15] memory: tegra: Add Tegra210 memory controller hot resets
On Sat, Apr 28, 2018 at 11:18:38AM +0300, Dmitry Osipenko wrote:
> On 27.04.2018 12:39, Thierry Reding wrote:
> > On Fri, Apr 13, 2018 at 02:33:50PM +0300, Dmitry Osipenko wrote:
> >> From: Thierry Reding
> >>
> >> Define the table of memory controller hot resets for Tegra210.
> >>
> >> Signed-off-by: Thierry Reding
> >> ---
> >> drivers/memory/tegra/tegra210.c | 45 +
> >> 1 file changed, 45 insertions(+)
> >>
> >> diff --git a/drivers/memory/tegra/tegra210.c
> >> b/drivers/memory/tegra/tegra210.c
> >> index b729f49ffc8f..d00a77160407 100644
> >> --- a/drivers/memory/tegra/tegra210.c
> >> +++ b/drivers/memory/tegra/tegra210.c
> >> @@ -1080,6 +1080,48 @@ static const struct tegra_smmu_soc
> >> tegra210_smmu_soc = {
> >>.num_asids = 128,
> >> };
> >>
> >> +#define TEGRA210_MC_RESET(_name, _control, _status, _bit) \
> >> + { \
> >> + .name = #_name, \
> >> + .id = TEGRA210_MC_RESET_##_name,\
> >> + .control = _control,\
> >> + .status = _status, \
> >> + .bit = _bit,\
> >> + }
> >> +
> >> +static const struct tegra_mc_reset tegra210_mc_resets[] = {
> >> + TEGRA210_MC_RESET(AFI, 0x200, 0x204, 0),
> >> + TEGRA210_MC_RESET(AVPC, 0x200, 0x204, 1),
> >> + TEGRA210_MC_RESET(DC,0x200, 0x204, 2),
> >> + TEGRA210_MC_RESET(DCB, 0x200, 0x204, 3),
> >> + TEGRA210_MC_RESET(HC,0x200, 0x204, 6),
> >> + TEGRA210_MC_RESET(HDA, 0x200, 0x204, 7),
> >> + TEGRA210_MC_RESET(ISP2, 0x200, 0x204, 8),
> >> + TEGRA210_MC_RESET(MPCORE,0x200, 0x204, 9),
> >> + TEGRA210_MC_RESET(NVENC, 0x200, 0x204, 11),
> >> + TEGRA210_MC_RESET(PPCS, 0x200, 0x204, 14),
> >> + TEGRA210_MC_RESET(SATA, 0x200, 0x204, 15),
> >> + TEGRA210_MC_RESET(VI,0x200, 0x204, 17),
> >> + TEGRA210_MC_RESET(VIC, 0x200, 0x204, 18),
> >> + TEGRA210_MC_RESET(XUSB_HOST, 0x200, 0x204, 19),
> >> + TEGRA210_MC_RESET(XUSB_DEV, 0x200, 0x204, 20),
> >> + TEGRA210_MC_RESET(A9AVP, 0x200, 0x204, 21),
> >> + TEGRA210_MC_RESET(TSEC, 0x200, 0x204, 22),
> >> + TEGRA210_MC_RESET(SDMMC1,0x200, 0x204, 29),
> >> + TEGRA210_MC_RESET(SDMMC2,0x200, 0x204, 30),
> >> + TEGRA210_MC_RESET(SDMMC3,0x200, 0x204, 31),
> >> + TEGRA210_MC_RESET(SDMMC4,0x970, 0x974, 0),
> >> + TEGRA210_MC_RESET(ISP2B, 0x970, 0x974, 1),
> >> + TEGRA210_MC_RESET(GPU, 0x970, 0x974, 2),
> >> + TEGRA210_MC_RESET(NVDEC, 0x970, 0x974, 5),
> >> + TEGRA210_MC_RESET(APE, 0x970, 0x974, 6),
> >> + TEGRA210_MC_RESET(SE,0x970, 0x974, 7),
> >> + TEGRA210_MC_RESET(NVJPG, 0x970, 0x974, 8),
> >> + TEGRA210_MC_RESET(AXIAP, 0x970, 0x974, 11),
> >> + TEGRA210_MC_RESET(ETR, 0x970, 0x974, 12),
> >> + TEGRA210_MC_RESET(TSECB, 0x970, 0x974, 13),
> >> +};
> >
> > Isn't this missing an include for the definitions? There is an include
> > for dt-bindings/memory/tegra20-mc.h for the Tegra20 driver, but none of
> > the others have it.
>
> Those drivers already have dt-bindings included.
You're right. Patch applied, thanks.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH v4 13/15] memory: tegra: Add Tegra114 memory controller hot resets
On Fri, Apr 13, 2018 at 02:33:52PM +0300, Dmitry Osipenko wrote: > Define the table of memory controller hot resets for Tegra114. > > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/tegra114.c | 33 + > 1 file changed, 33 insertions(+) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH v4 15/15] memory: tegra: Add Tegra20 memory controller hot resets
On Fri, Apr 13, 2018 at 02:33:54PM +0300, Dmitry Osipenko wrote: > Define the table of memory controller hot resets for Tegra20 and add > specific to Tegra20 hot reset operations. > > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/tegra20.c | 118 + > 1 file changed, 118 insertions(+) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH v4 14/15] memory: tegra: Add Tegra30 memory controller hot resets
On Fri, Apr 13, 2018 at 02:33:53PM +0300, Dmitry Osipenko wrote: > Define the table of memory controller hot resets for Tegra30. > > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/tegra30.c | 33 + > 1 file changed, 33 insertions(+) Applied, thanks. Thierry signature.asc Description: PGP signature
[PATCH] serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version
From: Daniel Wagner
Commit 40f70c03e33a ("serial: sh-sci: add locking to console write
function to avoid SMP lockup") copied the strategy to avoid locking
problems in conjuncture with the console from the UART8250
driver. Instead using directly spin_{try}lock_irqsave(),
local_irq_save() followed by spin_{try}lock() was used. While this is
correct on mainline, for -rt it is a problem. spin_{try}lock() will
check if it is running in a valid context. Since the local_irq_save()
has already been executed, the context has changed and
spin_{try}lock() will complain. The reason why spin_{try}lock()
complains is that on -rt the spin locks are turned into mutexes and
therefore can sleep. Sleeping with interrupts disabled is not valid.
BUG: sleeping function called from invalid context at
/home/wagi/work/rt/v4.4-cip-rt/kernel/locking/rtmutex.c:995
in_atomic(): 0, irqs_disabled(): 128, pid: 778, name: irq/76-eth0
CPU: 0 PID: 778 Comm: irq/76-eth0 Not tainted
4.4.126-test-cip22-rt14-00403-gcd03665c8318 #12
Hardware name: Generic RZ/G1 (Flattened Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
r7:c06b01f0 r6:60010193 r5: r4:c06b01f0
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (___might_sleep+0x134/0x194)
r7:60010113 r6:c06d3559 r5: r4:e000
[] (___might_sleep) from [] (rt_spin_lock+0x20/0x74)
r5:c06f4d60 r4:c06f4d60
[] (rt_spin_lock) from [] (serial_console_write+0x100/0x118)
r5:c06f4d60 r4:c06f4d60
[] (serial_console_write) from []
(call_console_drivers.constprop.15+0x10c/0x124)
r10:c06d2894 r9:c04e18b0 r8:0028 r7: r6:c06d3559 r5:c06d2798
r4:c06b9914 r3:c02576e4
[] (call_console_drivers.constprop.15) from []
(console_unlock+0x32c/0x430)
r10:c06d30d8 r9:0028 r8:c06dd518 r7:0005 r6: r5:c06d2798
r4:c06d2798 r3:0028
[] (console_unlock) from [] (vprintk_emit+0x394/0x4f0)
r10:c06d2798 r9:c06d30ee r8:0006 r7:0005 r6:c06a78fc r5:0027
r4:0003
[] (vprintk_emit) from [] (vprintk+0x28/0x30)
r10:c060bd46 r9:1000 r8:c06b9a90 r7:c06b9a90 r6:c06b994c r5:c06b9a3c
r4:c0062fa8
[] (vprintk) from [] (vprintk_default+0x10/0x14)
[] (vprintk_default) from [] (printk+0x78/0x84)
[] (printk) from [] (credit_entropy_bits+0x17c/0x2cc)
r3:0001 r2:decade60 r1:c061a5ee r0:c061a523
r4:0006
[] (credit_entropy_bits) from []
(add_interrupt_randomness+0x160/0x178)
r10:466e7196 r9:1f536000 r8:fffeef74 r7: r6:c06b9a60 r5:c06b9a3c
r4:dfbcf680
[] (add_interrupt_randomness) from []
(irq_thread+0x1e8/0x248)
r10:c006537c r9:c06cdf21 r8:c0064fcc r7:df791c24 r6:df791c00 r5:e000
r4:df525180
[] (irq_thread) from [] (kthread+0x108/0x11c)
r10: r9: r8:c0065184 r7:df791c00 r6: r5:df791d00
r4:decac000
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
r8: r7: r6: r5:c003fa9c r4:df791d00
Cc: Shinya Kuribayashi
Signed-off-by: Daniel Wagner
---
drivers/tty/serial/sh-sci.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index cf8d0955657d..3900711b60fc 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2516,13 +2516,12 @@ static void serial_console_write(struct console *co,
const char *s,
unsigned long flags;
int locked = 1;
- local_irq_save(flags);
if (port->sysrq)
locked = 0;
else if (oops_in_progress)
- locked = spin_trylock(&port->lock);
+ locked = spin_trylock_irqsave(&port->lock, flags);
else
- spin_lock(&port->lock);
+ spin_lock_irqsave(&port->lock, flags);
/* first save the SCSCR then disable the interrupts */
ctrl = serial_port_in(port, SCSCR);
@@ -2539,8 +2538,7 @@ static void serial_console_write(struct console *co,
const char *s,
serial_port_out(port, SCSCR, ctrl);
if (locked)
- spin_unlock(&port->lock);
- local_irq_restore(flags);
+ spin_unlock_irqrestore(&port->lock, flags);
}
static int serial_console_setup(struct console *co, char *options)
--
2.14.3
Re: KASAN: use-after-free in loopback_active_get
On Mon, 30 Apr 2018 09:53:14 +0200,
DaeRyong Jeong wrote:
>
> We report the crash:
> KASAN: use-after-free in loopback_active_get
>
> This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
> version of Syzkaller), which we describe more at the end of this report.
> Our analysis shows that the race occurs when invoking two syscalls
> concurrently,
> ioctl$SNDRV_CTL_IOCTL_ELEM_READ and syz_open_dev$audion.
>
> kernel config:
> https://kiwi.cs.purdue.ed/static/race-fuzzer/KASAN_use-after-free_in_loopback_active_get.config
>
> Analysis:
>
> When there is a race between sound/drivers/aloop.c:895
> (loopback_active_get) and sound/drivers/aloop.c:678 (free_cable), the
> retrieved cable pointer in loopback_active_get() may point to the
> freed memory region. When loopback_active_get() dereferences this
> pointer, use-after-free occurs.
>
> Possible CPU execution:
>
> CPU0 CPU1
> loopback_active_get() free_cable()
>
> struct loopback_cable *cable = ...
>
> loopback->cables[substream->number][dev] = NULL;
> kfree(cable);
> cable->running <-- Use-after-free
>
>
> Call Sequence:
> CPU0
> loopback_active_get
> snd_ctl_elem_read
> snd_ctl_elem_read_user
> snd_ctl_ioctl
>
> CPU1
> free_cable
> loopback_close
> snd_pcm_release_substream
> snd_pcm_release_substream
> snd_pcm_oss_release_file
> snd_pcm_oss_release_file
> snd_pcm_oss_release
>
>
> We observed that snd_pcm_oss_release() is called during the
> open("/dev/audio1")
> syscall. In our configuration, the function do_dentry_open() returns -EINVAL
> since below if statement is evaluated as true.
> if ((f->f_flags & O_DIRECT)
> (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO))
> Therefore, fput() is called and snd_pcm_oss_release() is called as a pending
> work before returning to the user space. But we suspect that the insufficient
> locking between snd_ctl_ioctl() and snd_pcm_oss_release(), not the vfs_layer,
> is the cause of the crash.
Right, it must be a race between ALSA ctl API ioctl access and the PCM
release. It's irrelevant with whether it's a delayed release or not,
but just a simple fact that it misses the loopback->cable_lock at
accessing.
The patch below should fix the issue. Could you check it?
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ALSA: aloop: Add missing cable lock to ctl API callbacks
Some control API callbacks in aloop driver are too lazy to take the
loopback->cable_lock and it results in possible races of cable access
while it's being freed. It eventually lead to a UAF, as reported by
fuzzer recently.
This patch covers such control API callbacks and add the proper mutex
locks.
Reported-by: DaeRyong Jeong
Cc:
Signed-off-by: Takashi Iwai
---
sound/drivers/aloop.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c
index 58e349fc893f..eab7f594ebe7 100644
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -831,9 +831,11 @@ static int loopback_rate_shift_get(struct snd_kcontrol
*kcontrol,
{
struct loopback *loopback = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&loopback->cable_lock);
ucontrol->value.integer.value[0] =
loopback->setup[kcontrol->id.subdevice]
[kcontrol->id.device].rate_shift;
+ mutex_unlock(&loopback->cable_lock);
return 0;
}
@@ -865,9 +867,11 @@ static int loopback_notify_get(struct snd_kcontrol
*kcontrol,
{
struct loopback *loopback = snd_kcontrol_chip(kcontrol);
+ mutex_lock(&loopback->cable_lock);
ucontrol->value.integer.value[0] =
loopback->setup[kcontrol->id.subdevice]
[kcontrol->id.device].notify;
+ mutex_unlock(&loopback->cable_lock);
return 0;
}
@@ -879,12 +883,14 @@ static int loopback_notify_put(struct snd_kcontrol
*kcontrol,
int change = 0;
val = ucontrol->value.integer.value[0] ? 1 : 0;
+ mutex_lock(&loopback->cable_lock);
if (val != loopback->setup[kcontrol->id.subdevice]
[kcontrol->id.device].notify) {
loopback->setup[kcontrol->id.subdevice]
[kcontrol->id.device].notify = val;
change = 1;
}
+ mutex_unlock(&loopback->cable_lock);
return change;
}
@@ -892,15 +898,18 @@ static int loopback_active_get(struct snd_kcontrol
*kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
struct loopback *loopback = snd_kcontrol_chip(kcontrol);
- struct loopback_cable *cable = loopback->cables
- [kcontrol->id.sub
Re: [PATCH 06/11] ASoC: amd: sram bank update changes
On Monday 30 April 2018 03:17 AM, Daniel Kurtz wrote:
On Thu, Apr 26, 2018 at 5:16 AM Vijendar Mukunda
wrote:
Added sram bank variable to audio_substream_data structure.
Signed-off-by: Vijendar Mukunda
Move initialization to acp_dma_open(), otherwise this is:
Reviewed-by: Daniel Kurtz
As explained in Patch 2 review comments, initialization part we moved
to acp_dma_hw_params() callback.
---
sound/soc/amd/acp-pcm-dma.c | 20 +---
sound/soc/amd/acp.h | 20 ++--
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index cb22653..b7bffc7 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -320,29 +320,16 @@ static void config_acp_dma(void __iomem *acp_mmio,
struct audio_substream_data *rtd,
u32 asic_type)
{
- u32 sram_bank;
-
- if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
- sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
- else {
- switch (asic_type) {
- case CHIP_STONEY:
- sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
- break;
- default:
- sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
- }
- }
acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
rtd->pte_offset);
/* Configure System memory <-> ACP SRAM DMA descriptors */
set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
rtd->direction, rtd->pte_offset,
- rtd->ch1, sram_bank,
+ rtd->ch1, rtd->sram_bank,
rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
- rtd->direction, sram_bank,
+ rtd->direction, rtd->sram_bank,
rtd->destination, rtd->ch2,
rtd->dma_dscr_idx_2, asic_type);
}
@@ -795,6 +782,7 @@ static int acp_dma_hw_params(struct snd_pcm_substream
*substream,
}
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
+ rtd->sram_bank = ACP_SRAM_BANK_1_ADDRESS;
rtd->destination = TO_ACP_I2S_1;
rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
@@ -805,9 +793,11 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
switch (adata->asic_type) {
case CHIP_STONEY:
rtd->pte_offset = ACP_ST_CAPTURE_PTE_OFFSET;
+ rtd->sram_bank = ACP_SRAM_BANK_2_ADDRESS;
break;
default:
rtd->pte_offset = ACP_CAPTURE_PTE_OFFSET;
+ rtd->sram_bank = ACP_SRAM_BANK_5_ADDRESS;
}
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 2f48d1d..62695ed 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -19,12 +19,19 @@
#define ACP_PHYSICAL_BASE 0x14000
-/* Playback SRAM address (as a destination in dma descriptor) */
-#define ACP_SHARED_RAM_BANK_1_ADDRESS 0x4002000
-
-/* Capture SRAM address (as a source in dma descriptor) */
-#define ACP_SHARED_RAM_BANK_5_ADDRESS 0x400A000
-#define ACP_SHARED_RAM_BANK_3_ADDRESS 0x4006000
+/*
+ * In case of I2S SP controller instance, Stoney uses SRAM bank 1 for
+ * playback and SRAM Bank 2 for capture where as in case of BT I2S
+ * Instance, Stoney uses SRAM Bank 3 for playback & SRAM Bank 4 will
+ * be used for capture. Carrizo uses I2S SP controller instance. SRAM
Banks
+ * 1, 2, 3, 4 will be used for playback & SRAM Banks 5, 6, 7, 8 will be
used
+ * for capture scenario.
+ */
+#define ACP_SRAM_BANK_1_ADDRESS0x4002000
+#define ACP_SRAM_BANK_2_ADDRESS0x4004000
+#define ACP_SRAM_BANK_3_ADDRESS0x4006000
+#define ACP_SRAM_BANK_4_ADDRESS0x4008000
+#define ACP_SRAM_BANK_5_ADDRESS0x400A000
#define ACP_DMA_RESET_TIME 1
#define ACP_CLOCK_EN_TIME_OUT_VALUE0x00FF
@@ -95,6 +102,7 @@ struct audio_substream_data {
u16 dma_dscr_idx_1;
u16 dma_dscr_idx_2;
u32 pte_offset;
+ u32 sram_bank;
u32 byte_cnt_high_reg_offset;
u32 byte_cnt_low_reg_offset;
uint64_t size;
--
2.7.4
Re: [PATCH 05/11] ASoC: amd: pte offset related dma driver changes
On Monday 30 April 2018 03:18 AM, Daniel Kurtz wrote:
On Thu, Apr 26, 2018 at 5:16 AM Vijendar Mukunda
wrote:
Added pte offset variable in audio_substream_data structure.
Added Stoney related PTE offset macros in acp header file.
Modified hw_params callback to assign the pte offset value
based on asic_type.
Signed-off-by: Vijendar Mukunda
---
sound/soc/amd/acp-pcm-dma.c | 26 +++---
sound/soc/amd/acp.h | 5 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 5f34be1..cb22653 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -320,13 +320,11 @@ static void config_acp_dma(void __iomem *acp_mmio,
struct audio_substream_data *rtd,
u32 asic_type)
{
- u32 pte_offset, sram_bank;
+ u32 sram_bank;
- if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK) {
- pte_offset = ACP_PLAYBACK_PTE_OFFSET;
+ if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
- } else {
- pte_offset = ACP_CAPTURE_PTE_OFFSET;
+ else {
switch (asic_type) {
case CHIP_STONEY:
sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
@@ -336,10 +334,10 @@ static void config_acp_dma(void __iomem *acp_mmio,
}
}
acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
- pte_offset);
+ rtd->pte_offset);
/* Configure System memory <-> ACP SRAM DMA descriptors */
set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
- rtd->direction, pte_offset,
+ rtd->direction, rtd->pte_offset,
rtd->ch1, sram_bank,
rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
@@ -788,6 +786,13 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
}
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ switch (adata->asic_type) {
+ case CHIP_STONEY:
+ rtd->pte_offset = ACP_ST_PLAYBACK_PTE_OFFSET;
+ break;
+ default:
+ rtd->pte_offset = ACP_PLAYBACK_PTE_OFFSET;
+ }
As in patch 2, I believe this would be better done in acp_dma_open().
Why does Stoney use a different PTE_OFFSET? Please answer this question in
the commit message.
-Dan
We will modify commit message and post the fresh patch.
-Vijendar
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
rtd->destination = TO_ACP_I2S_1;
@@ -797,6 +802,13 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH;
rtd->byte_cnt_low_reg_offset =
mmACP_I2S_TRANSMIT_BYTE_CNT_LOW;
} else {
+ switch (adata->asic_type) {
+ case CHIP_STONEY:
+ rtd->pte_offset = ACP_ST_CAPTURE_PTE_OFFSET;
+ break;
+ default:
+ rtd->pte_offset = ACP_CAPTURE_PTE_OFFSET;
+ }
rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
rtd->destination = FROM_ACP_I2S_1;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 82470bc..2f48d1d 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -10,6 +10,10 @@
#define ACP_PLAYBACK_PTE_OFFSET10
#define ACP_CAPTURE_PTE_OFFSET 0
+/* Playback and Capture Offset for Stoney */
+#define ACP_ST_PLAYBACK_PTE_OFFSET 0x04
+#define ACP_ST_CAPTURE_PTE_OFFSET 0x00
+
#define ACP_GARLIC_CNTL_DEFAULT0x0FB4
#define ACP_ONION_CNTL_DEFAULT 0x0FB4
@@ -90,6 +94,7 @@ struct audio_substream_data {
u16 destination;
u16 dma_dscr_idx_1;
u16 dma_dscr_idx_2;
+ u32 pte_offset;
u32 byte_cnt_high_reg_offset;
u32 byte_cnt_low_reg_offset;
uint64_t size;
--
2.7.4
Re: [PATCH v2 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
Hi Vinod,
On 27 April 2018 at 14:24, Vinod Koul wrote:
> On Thu, Apr 19, 2018 at 10:00:49AM +0800, Baolin Wang wrote:
>
>> +/*
>> + * struct sprd_dma_config - DMA configuration structure
>> + * @src_addr: the physical address where DMA slave data should be read
>> + * @dst_addr: the physical address where DMA slave data should be written
>> + * @fragment_len: specify one fragment transfer length
>> + * @block_len: specify one block transfer length
>> + * @transcation_len: specify one transcation transfer length
>> + * @src_step: source transfer step
>> + * @dst_step: destination transfer step
>> + * @src_datawidth: source transfer data width
>> + * @dst_datawidth: destination transfer data width
>> + * @wrap_ptr: wrap pointer address, once the transfer address reaches the
>> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to' address.
>> + * @wrap_to: wrap jump to address
>> + * @req_mode: specify the DMA request mode
>> + * @int_mode: specify the DMA interrupt type
>> + * @slave_id: slave channel requester id
>> + */
>> +struct sprd_dma_config {
>
> can you please not duplicate the dma_slave_config here. If you want to save
> your own values then please embed dma_slave_config here
Thanks for your suggestion. Will fix this in next version.
--
Baolin.wang
Best Regards
Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation
On Sun, Apr 29, 2018 at 02:08:07PM -0700, Wesley Terpstra wrote: > On Sun, Apr 29, 2018 at 2:01 PM, Andreas Färber wrote: > > "pwm0" sounds like a zero-indexed instance of some pwm block. If 0 is > > the version here, I'd suggest to make it "pwm-0" for example - you might > > want to take a look at the Xilinx bindings, which use a strict x.yy suffix. > > That's fine. I'll change it to pwm-0.00 in the next patch series. This should match the version that you use. If you're internal versioning uses single digits, or a single version number, then I think there's no need to use 0.00, because that would just be confusing. However I think it'd be good to make sure it is discernible as a version number. Perhaps something like sifive,pwm-v0. That seems to be a fairly common scheme. Thierry signature.asc Description: PGP signature
Re: [PATCH] PM / Sleep: only update last time for active wakeup sources
On Friday, April 27, 2018 12:25:53 AM CEST Doug Berger wrote:
> On 04/25/2018 11:30 PM, Rafael J. Wysocki wrote:
> > On Thu, Apr 26, 2018 at 1:40 AM, Doug Berger wrote:
> >> When wakelock support was added, the wakeup_source_add() function
> >> was updated to set the last_time value of the wakeup source. This
> >> has the unintended side effect of producing confusing output from
> >> pm_print_active_wakeup_sources() when a wakeup source is added
> >> prior to a sleep that is blocked by a different wakeup source.
> >>
> >> The function pm_print_active_wakeup_sources() will search for the
> >> most recently active wakeup source when no active source is found.
> >> If a wakeup source is added after a different wakeup source blocks
> >> the system from going to sleep it may have a later last_time value
> >> than the blocking source and be output as the last active wakeup
> >> source even if it has never actually been active.
> >>
> >> It looks to me like the change to wakeup_source_add() was made to
> >> prevent the wakelock garbage collection from accidentally dropping
> >> a wakelock during the narrow window between adding the wakelock to
> >> the wakelock list in wakelock_lookup_add() and the activation of
> >> the wakeup source in pm_wake_lock().
> >>
> >> This commit changes the behavior so that only the last_time of the
> >> wakeup source used by a wakelock is initialized prior to adding it
> >> to the wakeup source list. This preserves the meaning of the
> >> last_time value as the last time the wakeup source was active and
> >> allows a wakeup source that has never been active to have a
> >> last_time value of 0.
> >>
> >> Fixes: b86ff982 ("PM / Sleep: Add user space interface for manipulating
> >> wakeup sources, v3")
> >> Signed-off-by: Doug Berger
> >> ---
> >> drivers/base/power/wakeup.c | 1 -
> >> kernel/power/wakelock.c | 1 +
> >> 2 files changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> >> index ea01621..230160e 100644
> >> --- a/drivers/base/power/wakeup.c
> >> +++ b/drivers/base/power/wakeup.c
> >> @@ -183,7 +183,6 @@ void wakeup_source_add(struct wakeup_source *ws)
> >> spin_lock_init(&ws->lock);
> >> timer_setup(&ws->timer, pm_wakeup_timer_fn, 0);
> >> ws->active = false;
> >> - ws->last_time = ktime_get();
> >
> > If it is not initialized here, max_time may not be updated correctly later
> > on.
> >
> > If you don't want to initialize it to ktime_get() (to avoid the issue
> > you're trying to avoid), initialize it to something special and then
> > check for that explicitly in wakeup_source_deactivate() when computing
> > max_time.
> >
>
> I'm a little confused by your meaning. If you are concerned that the
> duration calculation in wakeup_source_deactivate() may be compromised by
> not initializing last_time in wakeup_source_add() and that an incorrect
> duration could find its way into the comparison and update of max_time
> then I don't believe that is a realizable concern.
>
> As far as I can see there are no execution paths to
> wakeup_source_deactivate() that don't require a call to
> wakeup_source_activate() earlier in the path. The call to
> wakeup_source_activate() will set the last_time to its proper value for
> use by wakeup_source_deactivate().
You're right, so this isn't a concern.
> So it should be safe to leave last_time at its initial 0 value in
> wakeup_source_add() without impacting wakeup_source_deactivate() or
> print_wakeup_source_stats().
>
> This is the behavior of your original implementation of wakeup sources.
> It wasn't changed until the wakelock support was added and as I said it
> only appears to be necessary to protect against the timing hazard with
> the garbage collecting thread possibly finding the wakeup_source from
> the wakelock list before the pm_wake_lock() function has the opportunity
> to activate the associated wakeup source.
>
> >>
> >> spin_lock_irqsave(&events_lock, flags);
> >> list_add_rcu(&ws->entry, &wakeup_sources);
> >> diff --git a/kernel/power/wakelock.c b/kernel/power/wakelock.c
> >> index dfba59b..4210152 100644
> >> --- a/kernel/power/wakelock.c
> >> +++ b/kernel/power/wakelock.c
> >> @@ -188,6 +188,7 @@ static struct wakelock *wakelock_lookup_add(const char
> >> *name, size_t len,
> >> return ERR_PTR(-ENOMEM);
> >> }
> >> wl->ws.name = wl->name;
> >> + wl->ws.last_time = ktime_get();
>
> This proposed change forces an early initialization of the last_time for
> wakelocks only to protect against accidental garbage collection between
> wakelock_lookup_add() and the subsequent call of __pm_wakeup_event() or
> __pm_stay_awake() where last_time will be initialized again.
>
>
> >> wakeup_source_add(&wl->ws);
> >> rb_link_node(&wl->node, parent, node);
> >> rb_insert_color(&wl->node, &wakelocks_tree);
> >> --
> >> 2.7.4
> >>
>
> Thank you for
[PATCH 10/12] ARM: davinci: neuros-osd2: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-neuros-osd2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c
b/arch/arm/mach-davinci/board-neuros-osd2.c
index 06e7f592b62b..353f9e5a1454 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -87,6 +87,7 @@ static struct mtd_partition
davinci_ntosd2_nandflash_partition[] = {
};
static struct davinci_nand_pdata davinci_ntosd2_nandflash_data = {
+ .core_chipsel = 0,
.parts = davinci_ntosd2_nandflash_partition,
.nr_parts = ARRAY_SIZE(davinci_ntosd2_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
--
2.17.0
[PATCH 09/12] ARM: davinci: dm646x-evm: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-dm646x-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index d672804df817..37c9e0ee4dcc 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -84,6 +84,7 @@ static struct davinci_aemif_timing
dm6467tevm_nandflash_timing = {
};
static struct davinci_nand_pdata davinci_nand_data = {
+ .core_chipsel = 0,
.mask_cle = 0x8,
.mask_ale = 0x4,
.parts = davinci_nand_partitions,
--
2.17.0
[PATCH 12/12] ARM: davinci: aemif: stop using pdev->id as nand chipselect
From: Bartosz Golaszewski All platforms now use the core_chipsel field in platform_data. Stop using pdev->id in the aemif code. Signed-off-by: Bartosz Golaszewski --- arch/arm/mach-davinci/aemif.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c index ff8b7e76b6e9..e4ab3f3a2a1f 100644 --- a/arch/arm/mach-davinci/aemif.c +++ b/arch/arm/mach-davinci/aemif.c @@ -189,7 +189,7 @@ int davinci_aemif_setup(struct platform_device *pdev) * Setup Async configuration register in case we did not boot * from NAND and so bootloader did not bother to set it up. */ - val = davinci_aemif_readl(base, A1CR_OFFSET + pdev->id * 4); + val = davinci_aemif_readl(base, A1CR_OFFSET + pdata->core_chipsel * 4); /* * Extended Wait is not valid and Select Strobe mode is not * used @@ -198,13 +198,13 @@ int davinci_aemif_setup(struct platform_device *pdev) if (pdata->options & NAND_BUSWIDTH_16) val |= 0x1; - davinci_aemif_writel(base, A1CR_OFFSET + pdev->id * 4, val); + davinci_aemif_writel(base, A1CR_OFFSET + pdata->core_chipsel * 4, val); clkrate = clk_get_rate(clk); if (pdata->timing) - ret = davinci_aemif_setup_timing(pdata->timing, base, pdev->id, -clkrate); + ret = davinci_aemif_setup_timing(pdata->timing, base, +pdata->core_chipsel, clkrate); if (ret < 0) dev_dbg(&pdev->dev, "NAND timing values setup fail\n"); -- 2.17.0
[PATCH 07/12] ARM: davinci: dm644x-evm: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-dm644x-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 190a28cc91bd..f76e22069e4b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -152,6 +152,7 @@ static struct davinci_aemif_timing
davinci_evm_nandflash_timing = {
};
static struct davinci_nand_pdata davinci_evm_nandflash_data = {
+ .core_chipsel = 0,
.parts = davinci_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(davinci_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
--
2.17.0
[PATCH 08/12] ARM: davinci: mityomapl138: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-mityomapl138.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
b/arch/arm/mach-davinci/board-mityomapl138.c
index f442784eded3..2cce0d7d2f2a 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -400,6 +400,7 @@ static struct mtd_partition
mityomapl138_nandflash_partition[] = {
};
static struct davinci_nand_pdata mityomapl138_nandflash_data = {
+ .core_chipsel = 1,
.parts = mityomapl138_nandflash_partition,
.nr_parts = ARRAY_SIZE(mityomapl138_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
--
2.17.0
[PATCH 11/12] mtd: nand: davinci: stop using pdev->id as chipselect
From: Bartosz Golaszewski All platform now use the core_chipsel field in platform data. Stop using pdev->id in the driver. Signed-off-by: Bartosz Golaszewski --- drivers/mtd/nand/raw/davinci_nand.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c index 7255a0d94374..cd12e5abafde 100644 --- a/drivers/mtd/nand/raw/davinci_nand.c +++ b/drivers/mtd/nand/raw/davinci_nand.c @@ -545,7 +545,7 @@ static struct davinci_nand_pdata return ERR_PTR(-ENOMEM); if (!of_property_read_u32(pdev->dev.of_node, "ti,davinci-chipselect", &prop)) - pdev->id = prop; + pdata->core_chipsel = prop; else return ERR_PTR(-EINVAL); @@ -627,7 +627,7 @@ static int nand_davinci_probe(struct platform_device *pdev) return -ENODEV; /* which external chipselect will we be managing? */ - if (pdev->id < 0 || pdev->id > 3) + if (pdata->core_chipsel < 0 || pdata->core_chipsel > 3) return -ENODEV; info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL); @@ -683,7 +683,7 @@ static int nand_davinci_probe(struct platform_device *pdev) info->ioaddr= (uint32_t __force) vaddr; info->current_cs= info->ioaddr; - info->core_chipsel = pdev->id; + info->core_chipsel = pdata->core_chipsel; info->mask_chipsel = pdata->mask_chipsel; /* use nandboot-capable ALE/CLE masks by default */ -- 2.17.0
[PATCH 04/12] ARM: davinci: dm355-evm: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-dm355-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index ea03ddcd35f5..ecd67a978aad 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -77,6 +77,7 @@ static struct mtd_partition davinci_nand_partitions[] = {
};
static struct davinci_nand_pdata davinci_nand_data = {
+ .core_chipsel = 0,
.mask_chipsel = BIT(14),
.parts = davinci_nand_partitions,
.nr_parts = ARRAY_SIZE(davinci_nand_partitions),
--
2.17.0
Re: [PATCH 1/2] cpufreq: brcmstb-avs-cpufreq: remove development debug support
On Wednesday, April 18, 2018 5:56:42 PM CEST Markus Mayer wrote:
> From: Markus Mayer
>
> This debug code was helpful while developing the driver, but it isn't
> being used for anything anymore.
>
> Signed-off-by: Markus Mayer
> ---
> drivers/cpufreq/Kconfig.arm | 10 --
> drivers/cpufreq/brcmstb-avs-cpufreq.c | 323
> +-
> 2 files changed, 1 insertion(+), 332 deletions(-)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 7f56fe5183f2..de55c7d57438 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -71,16 +71,6 @@ config ARM_BRCMSTB_AVS_CPUFREQ
>
> Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
>
> -config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
> - bool "Broadcom STB AVS CPUfreq driver sysfs debug capability"
> - depends on ARM_BRCMSTB_AVS_CPUFREQ
> - help
> - Enabling this option turns on debug support via sysfs under
> - /sys/kernel/debug/brcmstb-avs-cpufreq. It is possible to read all and
> - write some AVS mailbox registers through sysfs entries.
> -
> - If in doubt, say N.
> -
> config ARM_EXYNOS5440_CPUFREQ
> tristate "SAMSUNG EXYNOS5440"
> depends on SOC_EXYNOS5440
> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> index 6cdac1aaf23c..b07559b9ed99 100644
> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> @@ -49,13 +49,6 @@
> #include
> #include
>
> -#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
> -#include
> -#include
> -#include
> -#include
> -#endif
> -
> /* Max number of arguments AVS calls take */
> #define AVS_MAX_CMD_ARGS 4
> /*
> @@ -182,88 +175,11 @@ struct private_data {
> void __iomem *base;
> void __iomem *avs_intr_base;
> struct device *dev;
> -#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
> - struct dentry *debugfs;
> -#endif
> struct completion done;
> struct semaphore sem;
> struct pmap pmap;
> };
>
> -#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
> -
> -enum debugfs_format {
> - DEBUGFS_NORMAL,
> - DEBUGFS_FLOAT,
> - DEBUGFS_REV,
> -};
> -
> -struct debugfs_data {
> - struct debugfs_entry *entry;
> - struct private_data *priv;
> -};
> -
> -struct debugfs_entry {
> - char *name;
> - u32 offset;
> - fmode_t mode;
> - enum debugfs_format format;
> -};
> -
> -#define DEBUGFS_ENTRY(name, mode, format){ \
> - #name, AVS_MBOX_##name, mode, format \
> -}
> -
> -/*
> - * These are used for debugfs only. Otherwise we use AVS_MBOX_PARAM()
> directly.
> - */
> -#define AVS_MBOX_PARAM1 AVS_MBOX_PARAM(0)
> -#define AVS_MBOX_PARAM2 AVS_MBOX_PARAM(1)
> -#define AVS_MBOX_PARAM3 AVS_MBOX_PARAM(2)
> -#define AVS_MBOX_PARAM4 AVS_MBOX_PARAM(3)
> -
> -/*
> - * This table stores the name, access permissions and offset for each
> hardware
> - * register and is used to generate debugfs entries.
> - */
> -static struct debugfs_entry debugfs_entries[] = {
> - DEBUGFS_ENTRY(COMMAND, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(STATUS, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(VOLTAGE0, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(TEMP0, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(PV0, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(MV0, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(PARAM1, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(PARAM2, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(PARAM3, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(PARAM4, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(REVISION, 0, DEBUGFS_REV),
> - DEBUGFS_ENTRY(PSTATE, 0, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(HEARTBEAT, 0, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(MAGIC, S_IWUSR, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(SIGMA_HVT, 0, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(SIGMA_SVT, 0, DEBUGFS_NORMAL),
> - DEBUGFS_ENTRY(VOLTAGE1, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(TEMP1, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(PV1, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(MV1, 0, DEBUGFS_FLOAT),
> - DEBUGFS_ENTRY(FREQUENCY, 0, DEBUGFS_NORMAL),
> -};
> -
> -static int brcm_avs_target_index(struct cpufreq_policy *, unsigned int);
> -
> -static char *__strtolower(char *s)
> -{
> - char *p;
> -
> - for (p = s; *p; p++)
> - *p = tolower(*p);
> -
> - return s;
> -}
> -
> -#endif /* CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG */
> -
> static void __iomem *__map_region(const char *name)
> {
> struct device_node *np;
> @@ -516,238 +432,6 @@ brcm_avs_get_freq_table(struct device *dev, struct
> private_data *priv)
> return table;
> }
>
> -#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
> -
> -#define MANT(x) (unsigned int)(abs((x)) / 1000)
> -#define FRAC(x) (unsigned int)(abs((x)) - abs((x)) / 1000 * 1000)
> -
> -static int brcm_avs_debug_show(struct seq_file *s, void *data)
> -{
>
[PATCH 06/12] ARM: davinci: dm365-evm: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-dm365-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 36b69a131cfa..307e88d99dd3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -138,6 +138,7 @@ static struct mtd_partition davinci_nand_partitions[] = {
};
static struct davinci_nand_pdata davinci_nand_data = {
+ .core_chipsel = 0,
.mask_chipsel = BIT(14),
.parts = davinci_nand_partitions,
.nr_parts = ARRAY_SIZE(davinci_nand_partitions),
--
2.17.0
[PATCH 05/12] ARM: davinci: dm355-leopard: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-dm355-leopard.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 09f82160bbed..0fdf1d03eb11 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -72,6 +72,7 @@ static struct mtd_partition davinci_nand_partitions[] = {
};
static struct davinci_nand_pdata davinci_nand_data = {
+ .core_chipsel = 0,
.mask_chipsel = BIT(14),
.parts = davinci_nand_partitions,
.nr_parts = ARRAY_SIZE(davinci_nand_partitions),
--
2.17.0
[PATCH 01/12] mtd: nand: davinci: store the core chipselect number in platform data
From: Bartosz Golaszewski
We have the 'ti,davinci-chipselect' property in the device tree, but
when using platform data the driver silently uses the id field of
struct platform_device as the chipselect. This is confusing and we
almost broke the nand support again recently after converting the
platform to common clock framework (which changed the device id in the
clock lookup - the problem is gone now that we no longer acquire the
clock in the nand driver.
This patch adds a new filed - core_chipsel - to the platform_data.
Subsequent patches will convert the platforms to using this new field.
Signed-off-by: Bartosz Golaszewski
---
include/linux/platform_data/mtd-davinci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/mtd-davinci.h
b/include/linux/platform_data/mtd-davinci.h
index f1a2cf655bdb..879a59f97dac 100644
--- a/include/linux/platform_data/mtd-davinci.h
+++ b/include/linux/platform_data/mtd-davinci.h
@@ -56,6 +56,8 @@ struct davinci_nand_pdata { /* platform_data */
uint32_tmask_ale;
uint32_tmask_cle;
+ uint32_tcore_chipsel;
+
/* for packages using two chipselects */
uint32_tmask_chipsel;
--
2.17.0
[PATCH 03/12] ARM: davinci: da850-evm: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-da850-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 78a670aafea0..9f8041a0cf67 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -244,6 +244,7 @@ static struct davinci_aemif_timing
da850_evm_nandflash_timing = {
};
static struct davinci_nand_pdata da850_evm_nandflash_data = {
+ .core_chipsel = 1,
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
--
2.17.0
Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation
On Sun, Apr 29, 2018 at 01:51:34PM -0700, Wesley Terpstra wrote: > On Sat, Apr 28, 2018 at 10:54 PM, Thierry Reding > wrote: > > On Fri, Apr 27, 2018 at 03:59:56PM -0700, Wesley W. Terpstra wrote: > >> +Unlike most other PWM controllers, the SiFive PWM controller currently > >> only > >> +supports one period for all channels in the PWM. This is set globally in > >> DTS. > >> +The period also has significant restrictions on the values it can achieve, > >> +which the driver rounds to the nearest achievable frequency. > > > > How about you encode this in the driver rather than DT? We have several > > drivers with similar restrictions and they usually allow the first PWM > > channel to choose an arbitrary period and return an error if subsequent > > channels request a period that can't be supported. > > > > I think something similar could work with that second restriction. Why > > not return an error if the exact period can't be set? Or perhaps allow > > some percentage of deviation. > > Interesting. There are two ways to use this PWM. In one mode you use > all channels of the PWM as outputs. This is the mode the driver > supports because the HiFive Unleashed board uses all channels > connected to LEDs. > > In this case, the PWM period must always be a power-of-two reduction > from the core bus clock frequency. The core bus clock frequency can > vary. Therefore, even if the caller's frequency can be achieved at the > time of the method call, it may not remain achievable. You might say > this is a ridiculous PWM design, and I'd agree with you, but sadly > this is what is found in these chips. So effectively, the only thing > we can guarantee is that the period is within a multiple of sqrt(2) > from the requested period, except even that is not true due to > saturation restrictions that could push the period even further from > what you ask. > > In the other mode (where you sacrifice one of the output channels), > you have finer control of the period, but it still affects all > channels. This mode might be a better fit for your proposed API, > except that the driver would still be subject to saturation > restrictions on the period. And those restrictions will change as the > core bus frequency is changed, which means that again, even if your > target period can be achieved (common to all channels) at invocation, > it might not be achievable later. > > IMO the only real control this PWM can offer reliably is the duty > cycle, which is why I've written it how I have. > > If you see a better solution to the above problems, I am open to > suggestions. I don't like the idea of specifying something in DT that is completely approximate because it doesn't give users any kind of control over what is considered acceptable. In some cases an approximation to within 10% might be acceptable, in other cases users may only want to allow 5%. In this case there's even no way to catch or report a deviation from the desired value. How about you allow users to specify a valid frequency range with something like: frequency-range = ; or period-range = ; That would on one hand give users a way of specifying the valid range of frequencies and give your driver enough data to reject a change if it'd result in a frequency outside of the configured range. You would also have the possibility to react if a change in core bus clock frequency causes the PWM period to go out of range. I wonder if there's a mechanism that allows the clock change to be prevented (via a PRE_CHANGE notifier perhaps?), but if not at least you could disable the PWM if it was fed with an invalid range. Rob, any additional thoughts from you on this matter? Thierry signature.asc Description: PGP signature
[PATCH 02/12] ARM: davinci: da830-evm: specify the chipselect in davinci_nand_pdata
From: Bartosz Golaszewski
We now have the core_chipsel field in davinci_nand_pdata. Use it
instead of the platform_device id number.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-da830-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index d283faefaf97..7cfb6f7e39e7 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -304,6 +304,7 @@ static struct davinci_aemif_timing
da830_evm_nandflash_timing = {
};
static struct davinci_nand_pdata da830_evm_nand_pdata = {
+ .core_chipsel = 1,
.parts = da830_evm_nand_partitions,
.nr_parts = ARRAY_SIZE(da830_evm_nand_partitions),
.ecc_mode = NAND_ECC_HW,
--
2.17.0
[PATCH 00/12] mtd: nand: davinci: stop using pdev->id as chipselect
From: Bartosz Golaszewski We have the 'ti,davinci-chipselect' property in the device tree, but when using platform data the driver silently uses the id field of struct platform_device as the chipselect. This is confusing and we almost broke the nand support again recently after converting the platform to common clock framework (which changed the device id in the clock lookup - the problem is gone now that we no longer acquire the clock in the nand driver. This series adds a new field to davinci-nand platform data, then makes all board use it and finally modifies the two drivers that make use of it. Bartosz Golaszewski (12): mtd: nand: davinci: store the core chipselect number in platform data ARM: davinci: da830-evm: specify the chipselect in davinci_nand_pdata ARM: davinci: da850-evm: specify the chipselect in davinci_nand_pdata ARM: davinci: dm355-evm: specify the chipselect in davinci_nand_pdata ARM: davinci: dm355-leopard: specify the chipselect in davinci_nand_pdata ARM: davinci: dm365-evm: specify the chipselect in davinci_nand_pdata ARM: davinci: dm644x-evm: specify the chipselect in davinci_nand_pdata ARM: davinci: mityomapl138: specify the chipselect in davinci_nand_pdata ARM: davinci: dm646x-evm: specify the chipselect in davinci_nand_pdata ARM: davinci: neuros-osd2: specify the chipselect in davinci_nand_pdata mtd: nand: davinci: stop using pdev->id as chipselect ARM: davinci: aemif: stop using pdev->id as nand chipselect arch/arm/mach-davinci/aemif.c | 8 arch/arm/mach-davinci/board-da830-evm.c | 1 + arch/arm/mach-davinci/board-da850-evm.c | 1 + arch/arm/mach-davinci/board-dm355-evm.c | 1 + arch/arm/mach-davinci/board-dm355-leopard.c | 1 + arch/arm/mach-davinci/board-dm365-evm.c | 1 + arch/arm/mach-davinci/board-dm644x-evm.c| 1 + arch/arm/mach-davinci/board-dm646x-evm.c| 1 + arch/arm/mach-davinci/board-mityomapl138.c | 1 + arch/arm/mach-davinci/board-neuros-osd2.c | 1 + drivers/mtd/nand/raw/davinci_nand.c | 6 +++--- include/linux/platform_data/mtd-davinci.h | 2 ++ 12 files changed, 18 insertions(+), 7 deletions(-) -- 2.17.0
[PATCH v3 0/3] ASoc: TAS6424: Add support for mute, standby, and faster power on
mute and standby pins are available on the codec. If they are connected, they should be managed by the driver, instead of relying on gpio hogs or on the initial state of the GPIOs. This series also includes a patch to improve the start-up time of the channels by disabling built-in DC diagnostics. Those diagnosdtics basically serve to detect : - wires shorted together - wire shorted to ground or vbat - wire disconnected This is not useful for all platforms and the addition to the startup time is quite noticeable (230ms). The diagnostics can be enabled/disabled using a dedicated ALSA control. Changes in v3: - use SOC_SINGLE_STROBE() to register the "auto diagniostics switch" control Changes in v2: - use a ALSA control to enable/disable the auto diagnostics instead of relying on a DTS property. - fixed typos - use gpios (plural) instead of gpio in the documentation of the bindings Jean-Jacques Hiblot (3): ASoC: tas6424: Add support for the standby pin ASoC: tas6424: Add support for the mute pin ASoC: tas6424: Allow disabling auto diagnostics for faster power-on .../devicetree/bindings/sound/ti,tas6424.txt | 2 + sound/soc/codecs/tas6424.c | 72 +- sound/soc/codecs/tas6424.h | 4 ++ 3 files changed, 75 insertions(+), 3 deletions(-) -- 2.7.4
Re: [PATCH v2] init: Fix false positives in W+X checking
On Fri, Apr 27, 2018 at 03:55:45PM -0600, Jeffrey Hugo wrote:
> load_module() creates W+X mappings via __vmalloc_node_range() (from
> layout_and_allocate()->move_module()->module_alloc()) by using
> PAGE_KERNEL_EXEC. These mappings are later cleaned up via
> "call_rcu_sched(&freeinit->rcu, do_free_init)" from do_init_module().
>
> This is a problem because call_rcu_sched() queues work, which can be run
> after debug_checkwx() is run, resulting in a race condition. If hit, the
> race results in a nasty splat about insecure W+X mappings, which results
> in a poor user experience as these are not the mappings that
> debug_checkwx() is intended to catch.
>
> This issue is observed on multiple arm64 platforms, and has been
> artificially triggered on an x86 platform.
>
> Address the race by flushing the queued work before running the
> arch-defined mark_rodata_ro() which then calls debug_checkwx().
>
> Reported-by: Timur Tabi
> Reported-by: Jan Glauber
> Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings")
> Signed-off-by: Jeffrey Hugo
> ---
>
> v1:
> -was "arm64: mm: Fix false positives in W+X checking" (see [1])
> -moved to common code based on review and confirmation of issue on x86
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573776.html
>
> init/main.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index b795aa3..499d957 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1034,6 +1034,13 @@ static int __init set_debug_rodata(char *str)
> static void mark_readonly(void)
> {
> if (rodata_enabled) {
> + /*
> + * load_module() results in W+X mappings, which are cleaned up
> + * with call_rcu_sched(). Let's make sure that queued work is
> + * flushed so that we don't hit false positives looking for
> + * insecure pages which are W+X.
> + */
> + rcu_barrier_sched();
> mark_rodata_ro();
> rodata_test();
> } else
Acked-by: Will Deacon
Thanks for solving this for all architectures, Jeffrey.
Will
[PATCH v3 2/3] ASoC: tas6424: Add support for the mute pin
mute can be connected to GPIO. In that case we have to drive it to the
correct value
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Rob Herring
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 37 +-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/ti,tas6424.txt
b/Documentation/devicetree/bindings/sound/ti,tas6424.txt
index df71e41..eacb54f 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas6424.txt
+++ b/Documentation/devicetree/bindings/sound/ti,tas6424.txt
@@ -7,6 +7,7 @@ Required properties:
- reg: I2C slave address
- sound-dai-cells: must be equal to 0
- standby-gpios: GPIO used to shut the TAS6424 down.
+ - mute-gpios: GPIO used to mute all the outputs
Example:
diff --git a/sound/soc/codecs/tas6424.c b/sound/soc/codecs/tas6424.c
index 5abb17f..89fd0c1 100644
--- a/sound/soc/codecs/tas6424.c
+++ b/sound/soc/codecs/tas6424.c
@@ -45,6 +45,7 @@ struct tas6424_data {
unsigned int last_fault2;
unsigned int last_warn;
struct gpio_desc *standby_gpio;
+ struct gpio_desc *mute_gpio;
};
/*
@@ -251,10 +252,16 @@ static int tas6424_set_dai_tdm_slot(struct snd_soc_dai
*dai,
static int tas6424_mute(struct snd_soc_dai *dai, int mute)
{
struct snd_soc_component *component = dai->component;
+ struct tas6424_data *tas6424 = snd_soc_component_get_drvdata(component);
unsigned int val;
dev_dbg(component->dev, "%s() mute=%d\n", __func__, mute);
+ if (tas6424->mute_gpio) {
+ gpiod_set_value_cansleep(tas6424->mute_gpio, mute);
+ return 0;
+ }
+
if (mute)
val = TAS6424_ALL_STATE_MUTE;
else
@@ -289,6 +296,7 @@ static int tas6424_power_on(struct snd_soc_component
*component)
{
struct tas6424_data *tas6424 = snd_soc_component_get_drvdata(component);
int ret;
+ u8 chan_states;
ret = regulator_bulk_enable(ARRAY_SIZE(tas6424->supplies),
tas6424->supplies);
@@ -305,7 +313,18 @@ static int tas6424_power_on(struct snd_soc_component
*component)
return ret;
}
- snd_soc_component_write(component, TAS6424_CH_STATE_CTRL,
TAS6424_ALL_STATE_MUTE);
+ if (tas6424->mute_gpio) {
+ gpiod_set_value_cansleep(tas6424->mute_gpio, 0);
+ /*
+* channels are muted via the mute pin. Don't also mute
+* them via the registers so that subsequent register
+* access is not necessary to un-mute the channels
+*/
+ chan_states = TAS6424_ALL_STATE_PLAY;
+ } else {
+ chan_states = TAS6424_ALL_STATE_MUTE;
+ }
+ snd_soc_component_write(component, TAS6424_CH_STATE_CTRL, chan_states);
/* any time we come out of HIZ, the output channels automatically run DC
* load diagnostics, wait here until this completes
@@ -645,6 +664,22 @@ static int tas6424_i2c_probe(struct i2c_client *client,
tas6424->standby_gpio = NULL;
}
+ /*
+* Get control of the mute pin and set it HIGH in order to start with
+* all the output muted.
+* Note: The actual pin polarity is taken care of in the GPIO lib
+* according the polarity specified in the DTS.
+*/
+ tas6424->mute_gpio = devm_gpiod_get_optional(dev, "mute",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(tas6424->mute_gpio)) {
+ if (PTR_ERR(tas6424->mute_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(dev, "failed to get nmute GPIO: %ld\n",
+ PTR_ERR(tas6424->mute_gpio));
+ tas6424->mute_gpio = NULL;
+ }
+
for (i = 0; i < ARRAY_SIZE(tas6424->supplies); i++)
tas6424->supplies[i].supply = tas6424_supply_names[i];
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(tas6424->supplies),
--
2.7.4
[PATCH v3 3/3] ASoC: tas6424: Allow disabling auto diagnostics for faster power-on
The TAS6424 incorporates both DC-load and AC-load diagnostics which are
used to determine the status of the load. The DC diagnostics runs when any
channel is directed to leave the Hi-Z state and enter the MUTE or PLAY
state.
The DC diagnostics are turned on by default but, if a fast startup without
diagnostics is required, the diagnostics can be disabled using a dedicated
ALSA control.
Signed-off-by: Jean-Jacques Hiblot
---
sound/soc/codecs/tas6424.c | 13 +++--
sound/soc/codecs/tas6424.h | 4
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/tas6424.c b/sound/soc/codecs/tas6424.c
index 89fd0c1..12d1e35 100644
--- a/sound/soc/codecs/tas6424.c
+++ b/sound/soc/codecs/tas6424.c
@@ -64,6 +64,8 @@ static const struct snd_kcontrol_new tas6424_snd_controls[] =
{
TAS6424_CH3_VOL_CTRL, 0, 0xff, 0, dac_tlv),
SOC_SINGLE_TLV("Speaker Driver CH4 Playback Volume",
TAS6424_CH4_VOL_CTRL, 0, 0xff, 0, dac_tlv),
+ SOC_SINGLE_STROBE("Auto Diagnostics switch", TAS6424_DC_DIAG_CTRL1,
+ TAS6424_LDGBYPASS_SHIFT, 1),
};
static int tas6424_dac_event(struct snd_soc_dapm_widget *w,
@@ -297,6 +299,11 @@ static int tas6424_power_on(struct snd_soc_component
*component)
struct tas6424_data *tas6424 = snd_soc_component_get_drvdata(component);
int ret;
u8 chan_states;
+ int no_auto_diags = 0;
+ unsigned int reg_val;
+
+ if (!regmap_read(tas6424->regmap, TAS6424_DC_DIAG_CTRL1, ®_val))
+ no_auto_diags = reg_val & TAS6424_LDGBYPASS_MASK;
ret = regulator_bulk_enable(ARRAY_SIZE(tas6424->supplies),
tas6424->supplies);
@@ -327,9 +334,11 @@ static int tas6424_power_on(struct snd_soc_component
*component)
snd_soc_component_write(component, TAS6424_CH_STATE_CTRL, chan_states);
/* any time we come out of HIZ, the output channels automatically run DC
-* load diagnostics, wait here until this completes
+* load diagnostics if autodiagnotics are enabled. wait here until this
+* completes.
*/
- msleep(230);
+ if (!no_auto_diags)
+ msleep(230);
return 0;
}
diff --git a/sound/soc/codecs/tas6424.h b/sound/soc/codecs/tas6424.h
index 4305883..b5958c4 100644
--- a/sound/soc/codecs/tas6424.h
+++ b/sound/soc/codecs/tas6424.h
@@ -111,6 +111,10 @@
TAS6424_CH3_STATE_DIAG | \
TAS6424_CH4_STATE_DIAG)
+/* TAS6424_DC_DIAG_CTRL1 */
+#define TAS6424_LDGBYPASS_SHIFT0
+#define TAS6424_LDGBYPASS_MASK BIT(TAS6424_LDGBYPASS_SHIFT)
+
/* TAS6424_GLOB_FAULT1_REG */
#define TAS6424_FAULT_CLOCKBIT(4)
#define TAS6424_FAULT_PVDD_OV BIT(3)
--
2.7.4
[PATCH v3 1/3] ASoC: tas6424: Add support for the standby pin
The standby pin can be connected to a GPIO. In that case we have to drive
it to the correct values for the TAS6424 to operate properly.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Rob Herring
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 22 ++
2 files changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/ti,tas6424.txt
b/Documentation/devicetree/bindings/sound/ti,tas6424.txt
index 1c4ada0..df71e41 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas6424.txt
+++ b/Documentation/devicetree/bindings/sound/ti,tas6424.txt
@@ -6,6 +6,7 @@ Required properties:
- compatible: "ti,tas6424" - TAS6424
- reg: I2C slave address
- sound-dai-cells: must be equal to 0
+ - standby-gpios: GPIO used to shut the TAS6424 down.
Example:
diff --git a/sound/soc/codecs/tas6424.c b/sound/soc/codecs/tas6424.c
index 4f3a16c..5abb17f 100644
--- a/sound/soc/codecs/tas6424.c
+++ b/sound/soc/codecs/tas6424.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,6 +44,7 @@ struct tas6424_data {
unsigned int last_fault1;
unsigned int last_fault2;
unsigned int last_warn;
+ struct gpio_desc *standby_gpio;
};
/*
@@ -627,6 +629,22 @@ static int tas6424_i2c_probe(struct i2c_client *client,
return ret;
}
+ /*
+* Get control of the standby pin and set it LOW to take the codec
+* out of the stand-by mode.
+* Note: The actual pin polarity is taken care of in the GPIO lib
+* according the polarity specified in the DTS.
+*/
+ tas6424->standby_gpio = devm_gpiod_get_optional(dev, "standby",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tas6424->standby_gpio)) {
+ if (PTR_ERR(tas6424->standby_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(dev, "failed to get standby GPIO: %ld\n",
+ PTR_ERR(tas6424->standby_gpio));
+ tas6424->standby_gpio = NULL;
+ }
+
for (i = 0; i < ARRAY_SIZE(tas6424->supplies); i++)
tas6424->supplies[i].supply = tas6424_supply_names[i];
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(tas6424->supplies),
@@ -671,6 +689,10 @@ static int tas6424_i2c_remove(struct i2c_client *client)
cancel_delayed_work_sync(&tas6424->fault_check_work);
+ /* put the codec in stand-by */
+ if (tas6424->standby_gpio)
+ gpiod_set_value_cansleep(tas6424->standby_gpio, 1);
+
ret = regulator_bulk_disable(ARRAY_SIZE(tas6424->supplies),
tas6424->supplies);
if (ret < 0) {
--
2.7.4
Re: [PATCH v3 4/6] rpmsg: Guard against null endpoint ops in destroy
Hello Chris,
On 04/27/2018 12:59 AM, Chris Lew wrote:
> In RPMSG GLINK the chrdev device will allocate an ept as part of the
> rpdev creation. This device will not register endpoint ops even though
> it has an allocated ept. Protect against the case where the device is
> being destroyed.
>
> Signed-off-by: Chris Lew
> ---
>
> Changes since v1:
> - New change
>
> drivers/rpmsg/rpmsg_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index 920a02f0462c..7bfe36afccc5 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -88,7 +88,7 @@ struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device
> *rpdev,
> */
> void rpmsg_destroy_ept(struct rpmsg_endpoint *ept)
> {
> - if (ept)
> + if (ept && ept->ops)
> ept->ops->destroy_ept(ept);
> }
> EXPORT_SYMBOL(rpmsg_destroy_ept);
>
Would make sense that you also add test on ept->ops->destroy_ept. I
guess that ops may not be null while destroy_ept pointer is.
Regards
Arnaud
Re: [PATCH] gpio: pcie-idio-24: Fix off-by-one error in get_multiple loop
On Fri, Apr 20, 2018 at 3:50 PM, William Breathitt Gray
wrote:
> The PCIe-IDIO-24 features 8 bits of TTL GPIO which may be configured for
> output or input. This patch fixes an off-by-one error in the loop
> conditional for the get_multiple callback so that the TTL GPIO are
> handled.
>
> Fixes: ca37081595a2 ("gpio: pcie-idio-24: Implement get_multiple/set_multiple
> callbacks")
> Signed-off-by: William Breathitt Gray
Patch applied for fixes.
Yours,
Linus Walleij
Re: [PATCH v3 05/14] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath
On Sat, Apr 28, 2018 at 02:45:37PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 26, 2018 at 05:55:19PM +0100, Will Deacon wrote:
> > On Thu, Apr 26, 2018 at 05:53:35PM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 26, 2018 at 11:34:19AM +0100, Will Deacon wrote:
> > > > @@ -290,58 +312,50 @@ void queued_spin_lock_slowpath(struct qspinlock
> > > > *lock, u32 val)
> > > > }
> > > >
> > > > /*
> > > > +* If we observe any contention; queue.
> > > > +*/
> > > > + if (val & ~_Q_LOCKED_MASK)
> > > > + goto queue;
> > > > +
> > > > + /*
> > > > * trylock || pending
> > > > *
> > > > * 0,0,0 -> 0,0,1 ; trylock
> > > > * 0,0,1 -> 0,1,1 ; pending
> > > > */
> > > > + val = atomic_fetch_or_acquire(_Q_PENDING_VAL, &lock->val);
> > > > + if (!(val & ~_Q_LOCKED_MASK)) {
> > > > /*
> > > > +* we're pending, wait for the owner to go away.
> > > > +*
> > > > +* *,1,1 -> *,1,0
> > >
> > > Tail must be 0 here, right?
> >
> > Not necessarily. If we're concurrently setting pending with another slowpath
> > locker, they could queue in the tail behind us, so we can't mess with those
> > upper bits.
>
> Could be my brain just entirely stopped working; but I read that as:
>
> !(val & ~0xFF) := !(val & 0xFF00)
>
> which then pretty much mandates the top bits are empty, no?
Only if there isn't a concurrent locker. For example:
T0:
// fastpath fails to acquire the lock, returns val == _Q_LOCKED_VAL
if (val & ~_Q_LOCKED_MASK)
goto queue;
// Fallthrough
T1:
// fastpath fails to acquire the lock, returns val == _Q_LOCKED_VAL
if (val & ~_Q_LOCKED_MASK)
goto queue;
// Fallthrough
T0:
val = atomic_fetch_or_acquire(_Q_PENDING_VAL, &lock->val);
// val == _Q_LOCKED_VAL
T1:
val = atomic_fetch_or_acquire(_Q_PENDING_VAL, &lock->val);
// val == _Q_PENDING_VAL | _Q_LOCKED_VAL
// Queue into tail
T0:
// Spins for _Q_LOCKED_MASK to go to zero, but tail is *non-zero*
So it's really down to whether the state transitions in the comments refer
to the lockword in memory, or the local "val" variable. I think the former
is more instructive, because the whole thing is concurrent.
Will
Re: [PATCH] Bluetooth: Add a new 13d3:3496 QCA_ROME device
Hi Joao Paulo, > Without this patch we can't establish a SCO connection with this > adapter. > > This adapter is named "IMC Networks" under lsusb. > > T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3496 Rev= 0.01 > C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms > I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms > I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms > I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms > I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms > > Signed-off-by: João Paulo Rechi Vita > --- > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] ACPI: APD: Add AMD misc clock handler support
Hi Akshu, Thank you for the patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.17-rc3 next-20180426] [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/Akshu-Agrawal/ACPI-APD-Add-AMD-misc-clock-handler-support/20180430-152810 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next config: x86_64-acpi-redef (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> drivers//acpi/acpi_apd.c:14:10: fatal error: linux/platform_data/clk-st.h: >> No such file or directory #include ^~ compilation terminated. vim +14 drivers//acpi/acpi_apd.c > 14 #include 15 #include 16 #include 17 #include 18 #include 19 #include 20 #include 21 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [alsa-devel] [PATCH] ASoC: da7219: read fmw property to get mclk for non-dts systems
Hi Akshu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.17-rc3 next-20180426]
[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/Akshu-Agrawal/ASoC-da7219-read-fmw-property-to-get-mclk-for-non-dts-systems/20180430-151717
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
config: x86_64-randconfig-s1-04301236 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
sound/soc//codecs/da7219.c: In function 'da7219_probe':
>> sound/soc//codecs/da7219.c:1913:31: error: 'codec' undeclared (first use in
>> this function)
da7219->mclk = devm_clk_get(codec->dev, "mclk");
^
sound/soc//codecs/da7219.c:1913:31: note: each undeclared identifier is
reported only once for each function it appears in
vim +/codec +1913 sound/soc//codecs/da7219.c
1867
1868 static int da7219_probe(struct snd_soc_component *component)
1869 {
1870 struct da7219_priv *da7219 =
snd_soc_component_get_drvdata(component);
1871 unsigned int rev;
1872 int ret;
1873
1874 mutex_init(&da7219->ctrl_lock);
1875 mutex_init(&da7219->pll_lock);
1876
1877 /* Regulator configuration */
1878 ret = da7219_handle_supplies(component);
1879 if (ret)
1880 return ret;
1881
1882 ret = regmap_read(da7219->regmap, DA7219_CHIP_REVISION, &rev);
1883 if (ret) {
1884 dev_err(component->dev, "Failed to read chip revision:
%d\n", ret);
1885 goto err_disable_reg;
1886 }
1887
1888 switch (rev & DA7219_CHIP_MINOR_MASK) {
1889 case 0:
1890 ret = regmap_register_patch(da7219->regmap,
da7219_rev_aa_patch,
1891
ARRAY_SIZE(da7219_rev_aa_patch));
1892 if (ret) {
1893 dev_err(component->dev, "Failed to register AA
patch: %d\n",
1894 ret);
1895 goto err_disable_reg;
1896 }
1897 break;
1898 default:
1899 break;
1900 }
1901
1902 /* Handle DT/ACPI/Platform data */
1903 da7219->pdata = dev_get_platdata(component->dev);
1904 if (!da7219->pdata)
1905 da7219->pdata = da7219_fw_to_pdata(component);
1906
1907 da7219_handle_pdata(component);
1908
1909 /* Check if MCLK provided */
1910 if (da7219->pdata->mclk_name)
1911 da7219->mclk = clk_get(NULL, da7219->pdata->mclk_name);
1912 if (!da7219->mclk)
> 1913 da7219->mclk = devm_clk_get(codec->dev, "mclk");
1914 if (IS_ERR(da7219->mclk)) {
1915 if (PTR_ERR(da7219->mclk) != -ENOENT) {
1916 ret = PTR_ERR(da7219->mclk);
1917 goto err_disable_reg;
1918 } else {
1919 da7219->mclk = NULL;
1920 }
1921 }
1922
1923 /* Default PC counter to free-running */
1924 snd_soc_component_update_bits(component, DA7219_PC_COUNT,
DA7219_PC_FREERUN_MASK,
1925 DA7219_PC_FREERUN_MASK);
1926
1927 /* Default gain ramping */
1928 snd_soc_component_update_bits(component, DA7219_MIXIN_L_CTRL,
1929 DA7219_MIXIN_L_AMP_RAMP_EN_MASK,
1930 DA7219_MIXIN_L_AMP_RAMP_EN_MASK);
1931 snd_soc_component_update_bits(component, DA7219_ADC_L_CTRL,
DA7219_ADC_L_RAMP_EN_MASK,
1932 DA7219_ADC_L_RAMP_EN_MASK);
1933 snd_soc_component_update_bits(component, DA7219_DAC_L_CTRL,
DA7219_DAC_L_RAMP_EN_MASK,
1934 DA7219_DAC_L_RAMP_EN_MASK);
1935 snd_soc_component_update_bits(component, DA7219_DAC_R_CTRL,
DA7219_DAC_R_RAMP_EN_MASK,
1936 DA7219_DAC_R_RAMP_EN_MASK);
1937 snd_soc_component_update_bits(component, DA7219_HP_L_CTRL,
1938 DA7219_HP_L_AMP_RAMP_EN_MASK,
1939 DA7219_HP_L_AMP_RAMP_EN_MASK);
1940 snd_soc_component_update_bits(component, DA7219_HP_R_CTRL,
1941 DA7219_HP_R_AMP_RAMP
Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices
On 30/04/2018 06:36, Lee Jones wrote:
On Fri, 27 Apr 2018, John Garry wrote:
On 26/04/2018 15:23, John Garry wrote:
On 26/04/2018 15:08, Mika Westerberg wrote:
On Thu, Apr 26, 2018 at 02:49:49PM +0100, John Garry wrote:
diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
index 2d4611e..b04425b 100644
--- a/drivers/bus/hisi_lpc.c
+++ b/drivers/bus/hisi_lpc.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include "../tty/serial/8250/8250.h"
#define DRV_NAME "hisi-lpc"
@@ -345,6 +347,7 @@ static void hisi_lpc_comm_outs(void *hostdata,
unsigned
long pio,
#define MFD_CHILD_NAME_LEN (ACPI_ID_LEN +
sizeof(MFD_CHILD_NAME_PREFIX) -
1)
struct hisi_lpc_mfd_cell {
+struct plat_serial8250_port serial8250_port;
struct mfd_cell_acpi_match acpi_match;
char name[MFD_CHILD_NAME_LEN];
char pnpid[ACPI_ID_LEN];
@@ -513,10 +516,31 @@ static int hisi_lpc_acpi_probe(struct device
*hostdev)
dev_warn(&child->dev, "set resource fail (%d)\n", ret);
return ret;
}
+if (!strcmp(acpi_device_hid(child), "HISI1031")) {
Hi Mika,
Hmm, there is a way in struct mfd_cell to match child devices using _HID
so is there something preventing you from using that?
Not that I know about. Can you describe this method? I guess I also
don't need to set the mfd_cell pnpid either for this special case device.
So we using the mfd_cell to match child devices using _HID. At a glance, I
don't actually see other drivers to use mfd_cell_acpi_match.pnpid .
Anyway we don't use static tables as we need to update the resources of the
cell dynamically. However I do look at a driver like intel_quark_i2c_gpio.c,
and this dynamically modifies the value of global mfd_cell array here:
https://elixir.bootlin.com/linux/latest/source/drivers/mfd/intel_quark_i2c_gpio.c#L266
I know the cell array is only used at probe time, but this did not look to
be good standard practice to me.
Lots of drivers do this to supply dynamic data. If there is no other
sane way of providing such data, it's fine to do. Although each
situation should be dealt with on a case-by-case basis.
Hi Lee,
Thanks for your input.
I do see others drivers which use dynamic mem for the mfd_cells (like
cros_ec_dev.c), so what we're doing in this driver already is not
totally unchartered territory. But creating the MFD cells from the ACPI
table could be ...
Anyway, I'll cc you in my next patchset and maybe you can kindly check it.
Cheers,
John
Re: [PATCH 1/2] drm/vc4: Skip ULPS latching when we're in that ULPS state already.
On Tue, 31 Oct 2017 12:32:57 -0700 Eric Anholt wrote: > It seems that trying to go from unlatched to unlatched will time out > waiting for STOP, and we can just skip that. > > Signed-off-by: Eric Anholt Reviewed-by: Boris Brezillon > --- > drivers/gpu/drm/vc4/vc4_dsi.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c > index 94085f8bcd68..8aa897835118 100644 > --- a/drivers/gpu/drm/vc4/vc4_dsi.c > +++ b/drivers/gpu/drm/vc4/vc4_dsi.c > @@ -753,6 +753,11 @@ static void vc4_dsi_ulps(struct vc4_dsi *dsi, bool ulps) >(dsi->lanes > 2 ? DSI1_STAT_PHY_D2_STOP : 0) | >(dsi->lanes > 3 ? DSI1_STAT_PHY_D3_STOP : 0)); > int ret; > + bool ulps_currently_enabled = (DSI_PORT_READ(PHY_AFEC0) & > +DSI_PORT_BIT(PHY_AFEC0_LATCH_ULPS)); > + > + if (ulps == ulps_currently_enabled) > + return; > > DSI_PORT_WRITE(STAT, stat_ulps); > DSI_PORT_WRITE(PHYC, DSI_PORT_READ(PHYC) | phyc_ulps); -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
[PATCH] Input: serio - add writing multiple bytes at once
The current version only supports forwarding a single byte to the tty
layer.
This patch adds serio_write_length() to allow a serport driver writing
multiple bytes at once. The patch also includes a fallback to
serio_write_length() when a driver did not register a single byte function.
Signed-off-by: David Engraf
---
drivers/input/serio/serport.c | 7 ---
include/linux/serio.h | 13 -
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index f8ead9f9c77e..209343f636a3 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -45,10 +45,11 @@ struct serport {
* Callback functions from the serio code.
*/
-static int serport_serio_write(struct serio *serio, unsigned char data)
+static int serport_serio_write_length(struct serio *serio,
+ const unsigned char *data, int count)
{
struct serport *serport = serio->port_data;
- return -(serport->tty->ops->write(serport->tty, &data, 1) != 1);
+ return -(serport->tty->ops->write(serport->tty, data, count) != count);
}
static int serport_serio_open(struct serio *serio)
@@ -176,7 +177,7 @@ static ssize_t serport_ldisc_read(struct tty_struct * tty,
struct file * file, u
snprintf(serio->phys, sizeof(serio->phys), "%s/serio0", tty_name(tty));
serio->id = serport->id;
serio->id.type = SERIO_RS232;
- serio->write = serport_serio_write;
+ serio->write_length = serport_serio_write_length;
serio->open = serport_serio_open;
serio->close = serport_serio_close;
serio->port_data = serport;
diff --git a/include/linux/serio.h b/include/linux/serio.h
index 138a5efe863a..6f5cb92d0f22 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -35,6 +35,8 @@ struct serio {
spinlock_t lock;
int (*write)(struct serio *, unsigned char);
+ int (*write_length)(struct serio *serio, const unsigned char *data,
+ int count);
int (*open)(struct serio *);
void (*close)(struct serio *);
int (*start)(struct serio *);
@@ -122,12 +124,21 @@ void serio_unregister_driver(struct serio_driver *drv);
module_driver(__serio_driver, serio_register_driver, \
serio_unregister_driver)
+static inline int serio_write_length(struct serio *serio,
+const unsigned char *data, int count)
+{
+ if (serio->write_length)
+ return serio->write_length(serio, data, count);
+ else
+ return -1;
+}
+
static inline int serio_write(struct serio *serio, unsigned char data)
{
if (serio->write)
return serio->write(serio, data);
else
- return -1;
+ return serio_write_length(serio, &data, 1);
}
static inline void serio_drv_write_wakeup(struct serio *serio)
--
2.14.1
