Re: [PATCH] drm/drv: switch to using devm_add_action_or_reset()
Am 07.12.20 um 02:04 schrieb Tian Tao: switch to using devm_add_action_or_reset() instead of devm_add_action. Signed-off-by: Tian Tao I'm surprised that devm_drm_dev_init() didn't already use devm_add_action_or_reset(). But it doesn't look special, so Acked-by: Thomas Zimmermann --- drivers/gpu/drm/drm_drv.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 7343038..b92f7fd 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -675,11 +675,8 @@ static int devm_drm_dev_init(struct device *parent, if (ret) return ret; - ret = devm_add_action(parent, devm_drm_dev_init_release, dev); - if (ret) - devm_drm_dev_init_release(dev); - - return ret; + return devm_add_action_or_reset(parent, + devm_drm_dev_init_release, dev); } void *__devm_drm_dev_alloc(struct device *parent, -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
Re: [RFC PATCH v3.1 00/27] Add support UHS-II for GL9755
Adrian, On Thu, Dec 03, 2020 at 11:55:23AM +0200, Adrian Hunter wrote: > On 1/12/20 5:09 am, AKASHI Takahiro wrote: > > Adrian, > > > > Thank you for your review comments. > > > > On Thu, Nov 26, 2020 at 10:18:55AM +0200, Adrian Hunter wrote: > >> On 25/11/20 9:41 am, AKASHI Takahiro wrote: > >>> Gentle ping; > >>> > >>> On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote: > This is an interim snapshot of our next version, v4, for enabling > UHS-II on MMC/SD. > > It is focused on 'sdhci' side to address Adrian's comments regarding > "modularising" sdhci-uhs2.c. > The whole aim of this version is to get early feedback from Adrian (and > others) on this issue. Without any consensus about the code structure, > >>> > >>> Any comments so far? > >>> > >> > >> Overall, I like this approach of separating UHS2 from legacy sdhci as much > >> as possible. The only major change, is to drop support for legacy quirks > >> and features that you do not need. The reason for that, is that there may > >> be few drivers that end up with UHS-II support (opting instead for SD > >> Express), so there is no point going to a lot of trouble to support things > >> that never get used. > >> > >> From what I have seen that looks like it includes: > >>- any quirks > > > > GLI driver (gl9755) needs > > * SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC > > * SDHCI_QUIRK2_BROKEN_DDR50 > > but they are managed in sdhci code. > > > >>- SDHCI LED support > >>- external DMA support > > > > Should we add 'depends on !SDHCI_UHS2' to MMC_SDHCI_EXTERNAL_DMA? > > > >> In this regard, the important thing is to have a comment somewhere that > >> lists what is not supported. > >> > >> I have only looked at SDHCI patches so far, and only up to about patch 20, > >> but maybe that gives you enough to go on for a while. > > > > Well, I have almost done. > > Can I expect your comments on the patches #21-#27 as well soon? > > I have made some more comments and that is all for now, except for anything > more you wish to discuss. Thank you. I assume that you don't have any objection against adding extra hooks to sdhci_ops in patch#23 and #25, do you? If so, since we don't have any critical issues to discuss, I hope that my changes will be contained in the new version where a major rework will be done on the core side by Ben. -Takahiro Akashi
Re: [PATCH v3] ath10k: add option for chip-id based BDF selection
Abhishek Kumar wrote: > In some devices difference in chip-id should be enough to pick > the right BDF. Add another support for chip-id based BDF selection. > With this new option, ath10k supports 2 fallback options. > > The board name with chip-id as option looks as follows > board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=320' > > Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2-00696-QCAHLSWMTPL-1 > Tested-on: QCA6174 HW3.2 WLAN.RM.4.4.1-00157-QCARMSWPZ-1 > Signed-off-by: Abhishek Kumar > Reviewed-by: Douglas Anderson > Reviewed-by: Rakesh Pillai > Signed-off-by: Kalle Valo Two new checkpatch (using ath10k-check) warnings: drivers/net/wireless/ath/ath10k/core.c:1509: line length of 92 exceeds 90 columns drivers/net/wireless/ath/ath10k/core.c:1518: line length of 92 exceeds 90 columns Fixed those in the pending branch. -- https://patchwork.kernel.org/project/linux-wireless/patch/20201207231824.v3.1.Ia6b95087ca566f77423f3802a78b946f7b593ff5@changeid/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
RE: [PATCH 2/2] scsi: ufs: Fix wrong print message in dev_err()
> From: Bean Huo > > Change dev_err() print message from "dme-reset" to "dme_enable" in > function > ufshcd_dme_enable(). > > Signed-off-by: Bean Huo Acked-by: Avri Altman
Re: [External] Re: [PATCH v3 7/7] mm: memcontrol: make the slab calculation consistent
On Tue, Dec 8, 2020 at 3:21 PM Pankaj Gupta
wrote:
>
> > Although the ratio of the slab is one, we also should read the ratio
> > from the related memory_stats instead of hard-coding. And the local
> > variable of size is already the value of slab_unreclaimable. So we
> > do not need to read again.
> >
> > We can drop the ratio in struct memory_stat. This can make the code
> > clean and simple. And get rid of the awkward mix of static and runtime
> > initialization of the memory_stats table.
> >
> > Signed-off-by: Muchun Song
> > ---
> > mm/memcontrol.c | 112
> >
> > 1 file changed, 73 insertions(+), 39 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index a40797a27f87..841ea37cc123 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -1511,49 +1511,78 @@ static bool mem_cgroup_wait_acct_move(struct
> > mem_cgroup *memcg)
> >
> > struct memory_stat {
> > const char *name;
> > - unsigned int ratio;
> > unsigned int idx;
> > };
> >
> > static const struct memory_stat memory_stats[] = {
> > - { "anon", PAGE_SIZE, NR_ANON_MAPPED },
> > - { "file", PAGE_SIZE, NR_FILE_PAGES },
> > - { "kernel_stack", 1024, NR_KERNEL_STACK_KB },
> > - { "pagetables", PAGE_SIZE, NR_PAGETABLE },
> > - { "percpu", 1, MEMCG_PERCPU_B },
> > - { "sock", PAGE_SIZE, MEMCG_SOCK },
> > - { "shmem", PAGE_SIZE, NR_SHMEM },
> > - { "file_mapped", PAGE_SIZE, NR_FILE_MAPPED },
> > - { "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
> > - { "file_writeback", PAGE_SIZE, NR_WRITEBACK },
> > + { "anon", NR_ANON_MAPPED },
> > + { "file", NR_FILE_PAGES },
> > + { "kernel_stack", NR_KERNEL_STACK_KB },
> > + { "pagetables", NR_PAGETABLE},
> > + { "percpu", MEMCG_PERCPU_B },
> > + { "sock", MEMCG_SOCK },
> > + { "shmem", NR_SHMEM},
> > + { "file_mapped",NR_FILE_MAPPED },
> > + { "file_dirty", NR_FILE_DIRTY },
> > + { "file_writeback", NR_WRITEBACK},
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > - { "anon_thp", PAGE_SIZE, NR_ANON_THPS },
> > - { "file_thp", PAGE_SIZE, NR_FILE_THPS },
> > - { "shmem_thp", PAGE_SIZE, NR_SHMEM_THPS },
> > + { "anon_thp", NR_ANON_THPS},
> > + { "file_thp", NR_FILE_THPS},
> > + { "shmem_thp", NR_SHMEM_THPS },
> > #endif
> > - { "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
> > - { "active_anon", PAGE_SIZE, NR_ACTIVE_ANON },
> > - { "inactive_file", PAGE_SIZE, NR_INACTIVE_FILE },
> > - { "active_file", PAGE_SIZE, NR_ACTIVE_FILE },
> > - { "unevictable", PAGE_SIZE, NR_UNEVICTABLE },
> > -
> > - /*
> > -* Note: The slab_reclaimable and slab_unreclaimable must be
> > -* together and slab_reclaimable must be in front.
> > -*/
> > - { "slab_reclaimable", 1, NR_SLAB_RECLAIMABLE_B },
> > - { "slab_unreclaimable", 1, NR_SLAB_UNRECLAIMABLE_B },
> > + { "inactive_anon", NR_INACTIVE_ANON},
> > + { "active_anon",NR_ACTIVE_ANON },
> > + { "inactive_file", NR_INACTIVE_FILE},
> > + { "active_file",NR_ACTIVE_FILE },
> > + { "unevictable",NR_UNEVICTABLE },
> > + { "slab_reclaimable", NR_SLAB_RECLAIMABLE_B },
> > + { "slab_unreclaimable", NR_SLAB_UNRECLAIMABLE_B },
> >
> > /* The memory events */
> > - { "workingset_refault_anon", 1, WORKINGSET_REFAULT_ANON },
> > - { "workingset_refault_file", 1, WORKINGSET_REFAULT_FILE },
> > - { "workingset_activate_anon", 1, WORKINGSET_ACTIVATE_ANON },
> > - { "workingset_activate_file", 1, WORKINGSET_ACTIVATE_FILE },
> > - { "workingset_restore_anon", 1, WORKINGSET_RESTORE_ANON },
> > - { "workingset_restore_file", 1, WORKINGSET_RESTORE_FILE },
> > - { "workingset_nodereclaim", 1, WORKINGSET_NODERECLAIM },
> > + { "workingset_refault_anon",WORKINGSET_REFAULT_ANON },
> > + { "workingset_refault_file",WORKINGSET_REFAULT_FILE },
> > + { "workingset_activate_anon", WORKINGSET_ACTIVATE_ANON},
> > + { "workingset_activate_file", WORKINGSET_ACTIVATE_FILE},
> > + { "workingset_restore_anon",WORKINGSET_RESTORE_ANON },
> > + {
RE: [PATCH 1/2] scsi: ufs: Remove an unused macro definition POWER_DESC_MAX_SIZE
> From: Bean Huo > > No user uses POWER_DESC_MAX_SIZE, remove it. > > Signed-off-by: Bean Huo Acked-by: Avri Altman
Re: [PATCH 1/2] dt-bindings: phy: add Amlogic G12A Analog MIPI D-PHY bindings
On 07/12/2020 23:44, Rob Herring wrote:
> On Mon, Nov 23, 2020 at 03:51:56PM +0100, Neil Armstrong wrote:
>> The Amlogic G12A SoCs embeds an Analog MIPI D-PHY to communicate with DSI
>> panels, this adds the bindings.
>>
>> This Analog D-PHY works with a separate Digital MIPI D-PHY.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> .../phy/amlogic,g12a-mipi-dphy-analog.yaml| 40 +++
>> 1 file changed, 40 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>> b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>> new file mode 100644
>> index ..28663552f05b
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>> @@ -0,0 +1,40 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#;
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
>> +
>> +title: Amlogic G12A MIPI analog PHY
>> +
>> +maintainers:
>> + - Neil Armstrong
>> +
>> +description: |+
>> + The Everything-Else Power Domains node should be the child of a syscon
>
> Everything-Else Power Domains node??
Indeed, it's a typo
>
>> + node with the required property:
>> +
>> + - compatible: Should be the following:
>> +"amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"
>> +
>> + Refer to the the bindings described in
>> + Documentation/devicetree/bindings/mfd/syscon.yaml
>> +
>> +properties:
>> + compatible:
>> +const: amlogic,g12a-mipi-dphy-analog
>> +
>> + "#phy-cells":
>> +const: 0
>> +
>> +required:
>> + - compatible
>> + - "#phy-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +mpphy: phy {
>> + compatible = "amlogic,g12a-mipi-dphy-analog";
>> + #phy-cells = <0>;
>> +};
>> --
>> 2.25.1
>>
Re: [PATCH 2/7] net: batman-adv: remove unneeded MODULE_VERSION() usage
On 05.12.20 08:06, Sven Eckelmann wrote: Hi, > Is there some explanation besides an opinion? Some kind goal which you want > to > achieve with it maybe? Just a cleanup. I've been under the impression that this version is just an relic from oot times. > At least for us it was an easy way to query the release cycle information via > batctl. Which made it easier for us to roughly figure out what an reporter/ > inquirer was using - independent of whether he is using the in-kernel version > or a backported version. Is the OOT scenario still valid ? > Loosing this source of information and breaking parts of batctl and other > tools (respondd, ...) is not the end of the world. But I would at least know > why this is now necessary. Okay, if this particular information indeed has a practical value, we should keep it. Taking it as a NAK. Perhaps we should add a comment what it's used for and make sure, the version number is properly maintained. The problem I see w/ those version fields is that we have lots of changes in the kernel tree, w/o the version number being increased - making this information at least doubtful. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH v2 2/4] spi: Add devicetree bindings documentation for Loongson SPI
在 2020/12/8 15:44, Qing Zhang 写道:
Add spi-ls7a binding documentation.
Signed-off-by: Qing Zhang
---
Documentation/devicetree/bindings/spi/spi-ls7a.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-ls7a.txt
Hi Qing,
Please use dt schema instead.
Thanks.
- Jiaxun
diff --git a/Documentation/devicetree/bindings/spi/spi-ls7a.txt
b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
new file mode 100644
index 000..56247b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
@@ -0,0 +1,31 @@
+Binding for LOONGSON LS7A SPI controller
+
+Required properties:
+- compatible: should be
"pci0014,7a0b.0","pci0014,7a0b","pciclass088000","pciclass0880".
+- reg: reference IEEE Std 1275-1994.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- #interrupts: No hardware interrupt.
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ num-chipselects = <0>;
+ spiflash: s25fl016k@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible
="spansion,s25fl016k","jedec,spi-nor";
+ spi-max-frequency=<5000>;
+ reg=<0>;
+ };
+ };
[PATCH] drm/tidss: Use the new api devm_drm_irq_install
Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not needed to be called.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/tidss/tidss_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index 66e3c86e..48e1f9d 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -173,7 +173,7 @@ static int tidss_probe(struct platform_device *pdev)
goto err_runtime_suspend;
}
- ret = drm_irq_install(ddev, irq);
+ ret = devm_irq_install(ddev, irq);
if (ret) {
dev_err(dev, "drm_irq_install failed: %d\n", ret);
goto err_runtime_suspend;
@@ -219,8 +219,6 @@ static int tidss_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(ddev);
- drm_irq_uninstall(ddev);
-
#ifndef CONFIG_PM
/* If we don't have PM, we need to call suspend manually */
dispc_runtime_suspend(tidss->dispc);
--
2.7.4
Re: [PATCH] net: carl9170: remove trailing semicolon in macro definition
t...@redhat.com wrote: > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. e65e8b608f68 carl9170: remove trailing semicolon in macro definition -- https://patchwork.kernel.org/project/linux-wireless/patch/20201127175531.2754461-1-t...@redhat.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v2 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
The SPI controller has the following characteristics:
- Full-duplex synchronous serial data transmission
- Support up to 4 variable length byte transmission
- Main mode support
- Mode failure generates an error flag and issues an interrupt request
- Double buffer receiver
- Serial clock with programmable polarity and phase
- SPI can be controlled in wait mode
- Support boot from SPI
Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
eg:
[root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
Erased 262144 bytes from address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
Copied 13 bytes from 1.img to address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
Copied 13 bytes from address 0x0002 in flash to 2.img
[root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
Signed-off-by: Juxin Gao
Signed-off-by: Qing Zhang
---
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
- Fix unclear indentation
- make conditional statements to improve legibility
- Don't use static inline
- the core handle message queue
- Add a new binding document
- Fix probe part mixed pdev and PCI
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-ls7a.c | 324 +
3 files changed, 332 insertions(+)
create mode 100644 drivers/spi/spi-ls7a.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aadaea0..af7c0d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -413,6 +413,13 @@ config SPI_LP8841_RTC
Say N here unless you plan to run the kernel on an ICP DAS
LP-8x4x industrial computer.
+config SPI_LS7A
+ tristate "Loongson LS7A SPI Controller Support"
+ depends on CPU_LOONGSON64 || COMPILE_TEST
+ help
+ This drivers supports the Loongson LS7A SPI controller in master
+ SPI mode.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea582..d015cf2 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
+obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
new file mode 100644
index 000..21ca1ab
--- /dev/null
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Loongson LS7A SPI Controller driver
+ *
+ * Copyright (C) 2020 Loongson Technology Corporation Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* define spi register */
+#defineSPCR0x00
+#defineSPSR0x01
+#defineFIFO0x02
+#defineSPER0x03
+#definePARA0x04
+#defineSFCS0x05
+#defineTIMI0x06
+
+struct ls7a_spi {
+ spinlock_t lock;
+ struct spi_master *master;
+ void __iomem *base;
+ int cs_active;
+ unsigned int hz;
+ unsigned char spcr, sper;
+ unsigned int mode;
+};
+
+static void ls7a_spi_write_reg(struct ls7a_spi *spi,
+ unsigned char reg,
+ unsigned char data)
+{
+ writeb(data, spi->base + reg);
+}
+
+static char ls7a_spi_read_reg(struct ls7a_spi *spi,
+ unsigned char reg)
+{
+ return readb(spi->base + reg);
+}
+
+static int set_cs(struct ls7a_spi *ls7a_spi, struct spi_device *spi, int val)
+{
+ int cs = ls7a_spi_read_reg(ls7a_spi, SFCS) & ~(0x11 <<
spi->chip_select);
+
+ if (spi->mode & SPI_CS_HIGH)
+ val = !val;
+ ls7a_spi_write_reg(ls7a_spi, SFCS,
+ (val ? (0x11 << spi->chip_select):(0x1 << spi->chip_select)) |
cs);
+
+ return 0;
+}
+
+static int ls7a_spi_do_transfer(struct ls7a_spi *ls7a_spi,
+ struct spi_device *spi,
+ struct spi_transfer *t)
+{
+ unsigned int hz;
+ unsigned int div, div_tmp;
+ unsigned int bit;
+ unsigned long clk;
+ unsigned char val;
+ const char rdiv[12] = {0, 1, 4, 2, 3, 5, 6, 7, 8, 9, 10, 11};
+
+ if (t) {
+ hz = t->speed_hz;
+ if (!hz)
+ hz = spi->max_speed_hz;
+ } else
+ hz = spi->max_speed_hz;
+
+ if (((spi->mode ^
Re: [PATCH next v3 3/3] printk: remove logbuf_lock protection for ringbuffer
On 2020-12-07, John Ogness wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e1f068677a74..f3c0fcc3163f 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
[...]
> int vprintk_store(int facility, int level,
> const struct dev_printk_info *dev_info,
> const char *fmt, va_list args)
> {
> const u32 caller_id = printk_caller_id();
> - static char textbuf[LOG_LINE_MAX];
> struct prb_reserved_entry e;
> enum log_flags lflags = 0;
> struct printk_record r;
> u16 trunc_msg_len = 0;
> - char *text = textbuf;
> + char prefix_buf[8];
> + va_list args2;
> u16 text_len;
> + int ret = 0;
> u64 ts_nsec;
>
> /*
> @@ -1884,35 +1951,21 @@ int vprintk_store(int facility, int level,
>*/
> ts_nsec = local_clock();
>
> + va_copy(args2, args);
> +
> /*
>* The printf needs to come first; we need the syslog
>* prefix which might be passed-in as a parameter.
>*/
> - text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
> + text_len = vsnprintf(_buf[0], sizeof(prefix_buf), fmt, args) + 1;
> + if (text_len > CONSOLE_LOG_MAX)
> + text_len = CONSOLE_LOG_MAX;
LOG_LINE_MAX should be the limit. That was the size of the static
@textbuf.
John Ogness
[PATCH v2 2/4] spi: Add devicetree bindings documentation for Loongson SPI
Add spi-ls7a binding documentation.
Signed-off-by: Qing Zhang
---
Documentation/devicetree/bindings/spi/spi-ls7a.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-ls7a.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-ls7a.txt
b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
new file mode 100644
index 000..56247b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
@@ -0,0 +1,31 @@
+Binding for LOONGSON LS7A SPI controller
+
+Required properties:
+- compatible: should be
"pci0014,7a0b.0","pci0014,7a0b","pciclass088000","pciclass0880".
+- reg: reference IEEE Std 1275-1994.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- #interrupts: No hardware interrupt.
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ num-chipselects = <0>;
+ spiflash: s25fl016k@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible
="spansion,s25fl016k","jedec,spi-nor";
+ spi-max-frequency=<5000>;
+ reg=<0>;
+ };
+ };
--
2.1.0
[PATCH v2 4/4] MIPS: Loongson: Enable Loongson LS7A SPI in loongson3_defconfig
This is now supported, enable for Loongson systems. Signed-off-by: Qing Zhang --- v2: - Modify CONFIG_SPI_LOONGSON to CONFIG_SPI_LS7A --- arch/mips/configs/loongson3_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index 38a817e..28784cb 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -271,6 +271,9 @@ CONFIG_HW_RANDOM=y CONFIG_RAW_DRIVER=m CONFIG_I2C_CHARDEV=y CONFIG_I2C_PIIX4=y +CONFIG_SPI=y +CONFIG_SPI_MASTER=y +CONFIG_SPI_LS7A=y CONFIG_GPIO_LOONGSON=y CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM93=m -- 2.1.0
[PATCH v2 3/4] MIPS: Loongson64: DTS: Add SPI support to LS7A
add spi and amd node support.
Signed-off-by: Qing Zhang
---
v2:
- Add spi about pci device DT
---
arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index f99a7a1..ab8836b 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -405,6 +405,26 @@
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 39
IRQ_TYPE_LEVEL_HIGH>;
};
+
+ spi@16,0 {
+ compatible = "pci0014,7a0b.0",
+ "pci0014,7a0b",
+ "pciclass088000",
+ "pciclass0880";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0xb000 0x0 0x0 0x0 0x0>;
+ num-chipselects = <0>;
+ spiflash: s25fl016k@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible
="spansion,s25fl016k","jedec,spi-nor";
+ spi-max-frequency=<5000>;
+ reg=<0>;
+ };
+ };
};
isa {
--
2.1.0
Re: [PATCH v1 3/7] spi: qspi-tegra: Add support for Tegra210 QSPI controller
On Mon, Dec 07, 2020 at 04:14:53PM -0800, Sowjanya Komatineni wrote: > On 12/6/20 10:16 AM, Lukas Wunner wrote: > > However, be sure to use the devm variant to *allocate* the SPI controller, > > i.e. use devm_spi_alloc_master() instead of spi_alloc_master(). > > Thanks Lukas. I see devm_spi_alloc_master() in 5.4 but not from 5.5 devm_spi_alloc_master() was introduced in v5.10-rc5 with commit 5e844cc37a5c and then backported to 5.9-stable and 5.4-stable. Patches are pending to also backport it to 4.19-stable, 4.14-stable, 4.9-stable and 4.4-stable. If your development branch is based on v5.5, just cherry-pick 5e844cc37a5c and you should be good to go. Thanks, Lukas
Re: [RFC PATCH 0/4] crypto: add CRYPTO_TFM_REQ_DMA flag
On Mon, 7 Dec 2020 at 14:50, Horia Geantă wrote: > > On 11/26/2020 9:09 AM, Ard Biesheuvel wrote: > > On Wed, 25 Nov 2020 at 22:39, Iuliana Prodan wrote: > >> > >> On 11/25/2020 11:16 PM, Ard Biesheuvel wrote: > >>> On Wed, 25 Nov 2020 at 22:14, Iuliana Prodan (OSS) > >>> wrote: > > From: Iuliana Prodan > > Add the option to allocate the crypto request object plus any extra space > needed by the driver into a DMA-able memory. > > Add CRYPTO_TFM_REQ_DMA flag to be used by backend implementations to > indicate to crypto API the need to allocate GFP_DMA memory > for private contexts of the crypto requests. > > >>> > >>> These are always directional DMA mappings, right? So why can't we use > >>> bounce buffering here? > >>> > >> The idea was to avoid allocating any memory in crypto drivers. > >> We want to be able to use dm-crypt with CAAM, which needs DMA-able > >> memory and increasing reqsize is not enough. > > > > But what does 'needs DMA-able memory' mean? DMA operations are > > asynchronous by definition, and so the DMA layer should be able to > > allocate bounce buffers when needed. This will cost some performance > > in cases where the hardware cannot address all of memory directly, but > > this is a consequence of the design, and I don't think we should > > burden the generic API with this. > > > The performance loss due to bounce buffering is non-negligible. > Previous experiments we did showed a 35% gain (when forcing all data, > including I/O buffers, in ZONE_DMA32). > > I don't have the exact numbers for bounce buffering introduced by allowing > only by the control data structures (descriptors etc.) in high memory, > but I don't think it's fair to easily dismiss this topic, > given the big performance drop and relatively low impact > on the generic API. > It is not about the impact on the API. It is about the layering violation: all masters in a system will be affected by DMA addressing limitations, and all will be affected by the performance impact of bounce buffering when it is needed. DMA accessible memory is generally 'owned' by the DMA layer so it can be used for bounce buffering for all masters. If one device starts claiming DMA-able memory for its own use, other masters could be adversely affected, given that they may not be able to do DMA at all (not even via bounce buffers) once a single master uses up all DMA-able memory.
Re: [RFC PATCH v3.1 22/27] mmc: sdhci-uhs2: add add_host() and others to set up the driver
On Thu, Dec 03, 2020 at 11:42:34AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > This is a UHS-II version of sdhci's add_host/remove_host operation.
> > Any sdhci drivers which are capable of handling UHS-II cards must
> > call those functions instead of the corresponding sdhci's.
> >
> > Signed-off-by: Ben Chuang
> > Signed-off-by: AKASHI Takahiro
> > ---
> > drivers/mmc/host/sdhci-uhs2.c | 198 ++
> > drivers/mmc/host/sdhci-uhs2.h | 2 +
> > drivers/mmc/host/sdhci.c | 24 +++--
> > drivers/mmc/host/sdhci.h | 10 ++
> > 4 files changed, 226 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> > index d50134e912f3..5d3362ea138f 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.c
> > +++ b/drivers/mmc/host/sdhci-uhs2.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "sdhci.h"
> > #include "sdhci-uhs2.h"
> > @@ -406,6 +407,15 @@ static inline void sdhci_led_deactivate(struct
> > sdhci_host *host)
> > {
> > }
> > #else
> > +static inline int sdhci_led_register(struct sdhci_host *host)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void sdhci_led_unregister(struct sdhci_host *host)
> > +{
> > +}
> > +
> > static inline void sdhci_led_activate(struct sdhci_host *host)
> > {
> > __sdhci_led_activate(host);
> > @@ -1298,6 +1308,194 @@ static irqreturn_t sdhci_uhs2_thread_irq(int irq,
> > void *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +/*\
> > + *
> > + * Device allocation/registration
> > *
> > + *
> > *
> > +\*/
> > +
> > +static int __sdhci_uhs2_add_host_v4(struct sdhci_host *host, u32 caps1)
> > +{
> > + struct mmc_host *mmc;
> > + u32 max_current_caps2;
> > +
> > + if (host->version < SDHCI_SPEC_400)
> > + return 0;
> > +
> > + mmc = host->mmc;
> > +
> > + /* Support UHS2 */
> > + if (caps1 & SDHCI_SUPPORT_UHS2)
> > + mmc->caps |= MMC_CAP_UHS2;
> > +
> > + max_current_caps2 = sdhci_readl(host, SDHCI_MAX_CURRENT_1);
> > +
> > + if ((caps1 & SDHCI_SUPPORT_VDD2_180) &&
> > + !max_current_caps2 &&
> > + !IS_ERR(mmc->supply.vmmc2)) {
> > + /* UHS2 - VDD2 */
> > + int curr = regulator_get_current_limit(mmc->supply.vmmc2);
> > +
> > + if (curr > 0) {
> > + /* convert to SDHCI_MAX_CURRENT format */
> > + curr = curr / 1000; /* convert to mA */
> > + curr = curr / SDHCI_MAX_CURRENT_MULTIPLIER;
> > + curr = min_t(u32, curr, SDHCI_MAX_CURRENT_LIMIT);
> > + max_current_caps2 = curr;
> > + }
> > + }
> > +
> > + if (caps1 & SDHCI_SUPPORT_VDD2_180) {
> > + mmc->ocr_avail_uhs2 |= MMC_VDD2_165_195;
> > + /*
> > +* UHS2 doesn't require this. Only UHS-I bus needs to set
> > +* max current.
> > +*/
> > + mmc->max_current_180_vdd2 = (max_current_caps2 &
> > + SDHCI_MAX_CURRENT_VDD2_180_MASK) *
> > + SDHCI_MAX_CURRENT_MULTIPLIER;
> > + } else {
> > + mmc->caps &= ~MMC_CAP_UHS2;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int sdhci_uhs2_host_ops_init(struct sdhci_host *host);
> > +
> > +static int __sdhci_uhs2_add_host(struct sdhci_host *host)
>
> Can you leverage __sdhci_add_host() here?
Yes if we can always use sdhci_request_done() instead of
sdhci_uhs2_request_done() and we don't need sdhci_uhs2_thread_irq().
> > +{
> > + unsigned int flags = WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_HIGHPRI;
> > + struct mmc_host *mmc = host->mmc;
> > + int ret;
> > +
> > + if ((mmc->caps2 & MMC_CAP2_CQE) &&
> > + (host->quirks & SDHCI_QUIRK_BROKEN_CQE)) {
> > + mmc->caps2 &= ~MMC_CAP2_CQE;
> > + mmc->cqe_ops = NULL;
> > + }
> > +
> > + /* overwrite ops */
> > + if (mmc->caps & MMC_CAP_UHS2)
> > + sdhci_uhs2_host_ops_init(host);
> > +
> > + host->complete_wq = alloc_workqueue("sdhci", flags, 0);
> > + if (!host->complete_wq)
> > + return -ENOMEM;
> > +
> > + INIT_WORK(>complete_work, sdhci_uhs2_complete_work);
> > +
> > + timer_setup(>timer, sdhci_timeout_timer, 0);
> > + timer_setup(>data_timer, sdhci_timeout_data_timer, 0);
> > +
> > + init_waitqueue_head(>buf_ready_int);
> > +
> > + sdhci_init(host, 0);
> > +
> > + ret = request_threaded_irq(host->irq, sdhci_irq,
> > + sdhci_uhs2_thread_irq,
> > + IRQF_SHARED, mmc_hostname(mmc), host);
> > + if (ret) {
> > + pr_err("%s: Failed
Re: [PATCH next v3 2/3] printk: define CONSOLE_LOG_MAX in printk.h
On 2020-12-07, John Ogness wrote: > CONSOLE_EXT_LOG_MAX for extended console messages is already defined > in printk.h. Define CONSOLE_LOG_MAX there as well so that future > changes can make use of the constant for non-extended console > messages. Actually this patch is not necessary for this series. Also, this patch should probably modify all the "LOG_LINE_MAX + PREFIX_MAX" calls as well. John Ogness
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
From: Martin KaFai Lau
Date: Mon, 7 Dec 2020 22:54:18 -0800
> On Tue, Dec 01, 2020 at 11:44:10PM +0900, Kuniyuki Iwashima wrote:
>
> > @@ -242,8 +244,12 @@ void reuseport_detach_sock(struct sock *sk)
> >
> > reuse->num_socks--;
> > reuse->socks[i] = reuse->socks[reuse->num_socks];
> > + prog = rcu_dereference(reuse->prog);
> >
> > if (sk->sk_protocol == IPPROTO_TCP) {
> > + if (reuse->num_socks && !prog)
> > + nsk = i == reuse->num_socks ? reuse->socks[i -
> > 1] : reuse->socks[i];
> I asked in the earlier thread if the primary use case is to only
> use the bpf prog to pick. That thread did not come to
> a solid answer but did conclude that the sysctl should not
> control the behavior of the BPF_SK_REUSEPORT_SELECT_OR_MIGRATE prog.
>
> From this change here, it seems it is still desired to only depend
> on the kernel to random pick even when no bpf prog is attached.
I wrote this way only to split patches into tcp and bpf parts.
So, in the 10th patch, eBPF prog is run if the type is
BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.
https://lore.kernel.org/netdev/20201201144418.35045-11-kun...@amazon.co.jp/
But, it makes a breakage, so I will move
BPF_SK_REUSEPORT_SELECT_OR_MIGRATE validation into 10th patch so that the
type is only available after 10th patch.
---8<---
case BPF_PROG_TYPE_SK_REUSEPORT:
switch (expected_attach_type) {
case BPF_SK_REUSEPORT_SELECT:
case BPF_SK_REUSEPORT_SELECT_OR_MIGRATE: <- move to 10th.
return 0;
default:
return -EINVAL;
}
---8<---
> If that is the case, a sysctl to guard here for not changing
> the current behavior makes sense.
> It should still only control the non-bpf-pick behavior:
> when the sysctl is on, the kernel will still do a random pick
> when there is no bpf prog attached to the reuseport group.
> Thoughts?
If different applications listen on the same port without eBPF prog, I
think sysctl is necessary. But honestly, I am not sure there is really such
a case and sysctl is necessary.
If patcheset with sysctl is more acceptable, I will add it back in the next
spin.
> > +
> > reuse->num_closed_socks++;
> > reuse->socks[reuse->max_socks -
> > reuse->num_closed_socks] = sk;
> > } else {
> > @@ -264,6 +270,8 @@ void reuseport_detach_sock(struct sock *sk)
> > call_rcu(>rcu, reuseport_free_rcu);
> > out:
> > spin_unlock_bh(_lock);
> > +
> > + return nsk;
> > }
> > EXPORT_SYMBOL(reuseport_detach_sock);
Re: [PATCH v22 01/18] mm: Introduce Data Access MONitor (DAMON)
On Thu, 26 Nov 2020 12:51:57 +0100 SeongJae Park wrote:
> Hi Shakeel,
>
>
> Thanks for the review! :D
>
> On Wed, 25 Nov 2020 07:29:10 -0800 Shakeel Butt wrote:
>
> > On Tue, Oct 20, 2020 at 2:01 AM SeongJae Park wrote:
> > >
> > > From: SeongJae Park
> > >
> > > DAMON is a data access monitoring framework for the Linux kernel. The
> > > core mechanisms of DAMON make it
> > >
> > > - accurate (the monitoring output is useful enough for DRAM level
> > >performance-centric memory management; It might be inappropriate for
> > >CPU Cache levels, though),
> > > - light-weight (the monitoring overhead is normally low enough to be
> > >applied online), and
> > > - scalable (the upper-bound of the overhead is in constant range
> > >regardless of the size of target workloads).
> > >
> > > Using this framework, hence, we can easily write efficient kernel space
> > > data access monitoring applications. For example, the kernel's memory
> > > management mechanisms can make advanced decisions using this.
> > > Experimental data access aware optimization works that incurring high
> > > access monitoring overhead could implemented again on top of this.
> > >
> > > Due to its simple and flexible interface, providing user space interface
> > > would be also easy. Then, user space users who have some special
> > > workloads can write personalized applications for better understanding
> > > and optimizations of their workloads and systems.
> > >
> > > That said, this commit is implementing only basic data structures and
> > > simple manipulation functions of the structures. The core mechanisms of
> > > DAMON will be implemented by following commits.
> > >
> > > Signed-off-by: SeongJae Park
> > > Reviewed-by: Leonard Foerster
> > > Reviewed-by: Varad Gautam
> >
[...]
> > I would suggest to separate
> > the core (damon context) from the target related structs (target,
> > region, addr range).
>
> To be honest, I unsure if I'm fully understanding what specific change you
> want
> to make. So if I'm misunderstanding your point below, please let me know.
>
> Seems like you are concerning for future support of special kind use cases
> that
> don't need targets/regions/addresses, such as page granularity monitoring that
> having interest in only if the pages accessed or not, rather than access
> frequency. In the context, your suggestion makes sense as the region
> abstraction is only burden in the case, as I also mentioned in the cover
> letter. This could be done via idle pages tracking, but DAMON will be able to
> do this faster by reducing the number of user-kernel context switches.
>
> I once considered adding some change in the core part for efficient support of
> such use cases, but resulted in believing that the best way for that is
> implementing another primitive for the case and use it in a controlled way.
>
> In a high level, it should disable the 'adaptive regions adjustment' feature
> and define it's own targets structs other than the damon_target. Then, your
> implementation of the primitive callbacks should use your own targets.
>
> In more detail, the 'adaptive regions adjustment' can be disabled by setting
> the min_nr_regions and max_nr_regions of the damon_ctx with same value, say,
> 0.
> Your own targets structs could be stored in 'damon_callback->private'. Or, we
> could add another 'private' field in damon_ctx for that.
>
> I think this will work, but I also admit that this could look like a hairy
> hack to someone. Fundamentally, this is because the region based
> overhead/accuracy handling is strongly coupled in the design. So, I think
> what
> you are really suggesting is making DAMON more general by default and
> supporting the region based overhead/accuracy handling additionally.
>
> If I'm understanding correctly, how about below like change? Obviously this
> should be cleaned up a lot, but I just want to quickly share my idea and
> discuss. Also note that it's based on the damon/next tree[1].
>
> [1] https://github.com/sjp38/linux/tree/damon/next
>
> +enum damon_type {
> + ARBITRARY_TARGETS,
> + ADAPTIVE_REGIONS,
> +};
> +
> +struct damon_adaptive_regions_ctx {
> + unsigned long min_nr_regions;
> + unsigned long max_nr_regions;
> + struct list_head targets;
> + struct list_head schemes;
> +};
> +
> /**
> * struct damon_ctx - Represents a context for each monitoring. This is the
> * main interface that allows users to set the attributes and get the results
> @@ -243,8 +255,6 @@ struct damon_ctx {
> unsigned long sample_interval;
> unsigned long aggr_interval;
> unsigned long regions_update_interval;
> - unsigned long min_nr_regions;
> - unsigned long max_nr_regions;
>
> struct timespec64 last_aggregation;
> struct timespec64 last_regions_update;
> @@ -253,11 +263,14 @@ struct damon_ctx {
> bool kdamond_stop;
> struct mutex kdamond_lock;
general protection fault in hci_chan_del
Hello, syzbot found the following issue on: HEAD commit:b3298500 Merge tag 'for-5.10/dm-fixes' of git://git.kernel.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=144f0bf750 kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9 dashboard link: https://syzkaller.appspot.com/bug?extid=4c574753a325a601326c compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4c574753a325a6013...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc000b00: [#1] PREEMPT SMP KASAN KASAN: probably user-memory-access in range [0x5800-0x5807] CPU: 1 PID: 30846 Comm: syz-executor.1 Not tainted 5.10.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__list_del_entry_valid+0x81/0xf0 lib/list_debug.c:51 Code: 0f 84 d3 c0 fb 04 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 d4 c0 fb 04 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 51 49 8b 14 24 48 39 ea 0f 85 8b c0 fb 04 49 8d 7d RSP: 0018:c9001653fb50 EFLAGS: 00010206 RAX: dc00 RBX: 0054 RCX: c9000aab6000 RDX: 0b00 RSI: 87df1892 RDI: 888014569f08 RBP: 888014569f00 R08: 0001 R09: 88801a734a77 R10: ed10034e694e R11: 0001 R12: 5800 R13: 30401000 R14: fbfff19608c8 R15: 0067 FS: 7f7eae8b2700() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55c3b4ac8030 CR3: 25fa7000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_del_entry include/linux/list.h:132 [inline] list_del_rcu include/linux/rculist.h:166 [inline] hci_chan_del+0x4e/0x200 net/bluetooth/hci_conn.c:1733 l2cap_conn_del+0x478/0x7b0 net/bluetooth/l2cap_core.c:1900 l2cap_disconn_cfm net/bluetooth/l2cap_core.c:8161 [inline] l2cap_disconn_cfm+0x98/0xd0 net/bluetooth/l2cap_core.c:8154 hci_disconn_cfm include/net/bluetooth/hci_core.h:1441 [inline] hci_conn_hash_flush+0x127/0x260 net/bluetooth/hci_conn.c:1557 hci_dev_do_close+0x569/0x1110 net/bluetooth/hci_core.c:1770 hci_rfkill_set_block+0x19c/0x1d0 net/bluetooth/hci_core.c:2209 rfkill_set_block+0x1f9/0x540 net/rfkill/core.c:341 rfkill_fop_write+0x267/0x500 net/rfkill/core.c:1240 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45de79 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f7eae8b1c68 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0003 RCX: 0045de79 RDX: 0008 RSI: 2000 RDI: 0003 RBP: 0118bf60 R08: R09: R10: R11: 0246 R12: 0118bf2c R13: 0169fb7f R14: 7f7eae8b29c0 R15: 0118bf2c Modules linked in: ---[ end trace 8aa7b596113f27d8 ]--- RIP: 0010:__list_del_entry_valid+0x81/0xf0 lib/list_debug.c:51 Code: 0f 84 d3 c0 fb 04 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 d4 c0 fb 04 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 51 49 8b 14 24 48 39 ea 0f 85 8b c0 fb 04 49 8d 7d RSP: 0018:c9001653fb50 EFLAGS: 00010206 RAX: dc00 RBX: 0054 RCX: c9000aab6000 RDX: 0b00 RSI: 87df1892 RDI: 888014569f08 RBP: 888014569f00 R08: 0001 R09: 88801a734a77 R10: ed10034e694e R11: 0001 R12: 5800 R13: 30401000 R14: fbfff19608c8 R15: 0067 FS: 7f7eae8b2700() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 01590004 CR3: 25fa7000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [RFC PATCH v3.1 21/27] mmc: sdhci-uhs2: add irq() and others
On Tue, Dec 01, 2020 at 06:46:39PM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > This is a UHS-II version of sdhci's request() operation.
> > It handles UHS-II related command interrupts and errors.
> >
> > Signed-off-by: Ben Chuang
> > Signed-off-by: AKASHI Takahiro
> > ---
> > drivers/mmc/host/sdhci-uhs2.c | 247 ++
> > drivers/mmc/host/sdhci-uhs2.h | 3 +
> > drivers/mmc/host/sdhci.c | 112 ---
> > drivers/mmc/host/sdhci.h | 6 +
> > 4 files changed, 319 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> > index 36e52553977a..d50134e912f3 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.c
> > +++ b/drivers/mmc/host/sdhci-uhs2.c
> > @@ -11,6 +11,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -670,6 +671,12 @@ static inline void
> > sdhci_external_dma_pre_transfer(struct sdhci_host *host,
> >struct mmc_command *cmd)
> > {
> > }
> > +
> > +static inline struct dma_chan *sdhci_external_dma_channel(struct
> > sdhci_host *host,
> > + struct mmc_data *data)
> > +{
> > + return NULL;
> > +}
> > #endif /* CONFIG_MMC_SDHCI_EXTERNAL_DMA */
> >
> > static void sdhci_uhs2_finish_data(struct sdhci_host *host)
> > @@ -1051,6 +1058,246 @@ static void sdhci_uhs2_finish_command(struct
> > sdhci_host *host)
> > }
> > }
> >
> > +/*\
> > + *
> > *
> > + * Request done
> > *
> > + *
> > *
> > +\*/
> > +
> > +static bool sdhci_uhs2_request_done(struct sdhci_host *host)
> > +{
> > + unsigned long flags;
> > + struct mmc_request *mrq;
> > + int i;
> > +
> > + /* FIXME: UHS2_INITIALIZED, instead? */
> > + if (!(host->mmc->flags & MMC_UHS2_SUPPORT))
> > + return sdhci_request_done(host);
> > +
> > + spin_lock_irqsave(>lock, flags);
> > +
> > + for (i = 0; i < SDHCI_MAX_MRQS; i++) {
> > + mrq = host->mrqs_done[i];
> > + if (mrq)
> > + break;
> > + }
> > +
> > + if (!mrq) {
> > + spin_unlock_irqrestore(>lock, flags);
> > + return true;
> > + }
> > +
> > + /*
> > +* Always unmap the data buffers if they were mapped by
> > +* sdhci_prepare_data() whenever we finish with a request.
> > +* This avoids leaking DMA mappings on error.
> > +*/
> > + if (host->flags & SDHCI_REQ_USE_DMA) {
> > + struct mmc_data *data = mrq->data;
> > +
> > + if (host->use_external_dma && data &&
> > + (mrq->cmd->error || data->error)) {
> > + struct dma_chan *chan =
> > sdhci_external_dma_channel(host, data);
> > +
> > + host->mrqs_done[i] = NULL;
> > + spin_unlock_irqrestore(>lock, flags);
> > + dmaengine_terminate_sync(chan);
> > + spin_lock_irqsave(>lock, flags);
> > + sdhci_set_mrq_done(host, mrq);
> > + }
> > +
> > + sdhci_request_done_dma(host, mrq);
> > + }
> > +
> > + /*
> > +* The controller needs a reset of internal state machines
> > +* upon error conditions.
> > +*/
> > + if (sdhci_needs_reset(host, mrq)) {
> > + /*
> > +* Do not finish until command and data lines are available for
> > +* reset. Note there can only be one other mrq, so it cannot
> > +* also be in mrqs_done, otherwise host->cmd and host->data_cmd
> > +* would both be null.
> > +*/
> > + if (host->cmd || host->data_cmd) {
> > + spin_unlock_irqrestore(>lock, flags);
> > + return true;
> > + }
> > +
> > + /* Some controllers need this kick or reset won't work here */
> > + if (host->quirks & SDHCI_QUIRK_CLOCK_BEFORE_RESET)
> > + /* This is to force an update */
> > + host->ops->set_clock(host, host->clock);
> > +
> > + sdhci_uhs2_reset(host, SDHCI_UHS2_SW_RESET_SD);
>
> It should be possible to use the ->reset() callback for UHS-II also, then
> this function wouldn't be needed.
The reason that I didn't so is that the second argument is 'u8' for
legacy, and u16 for uhs-2, more importantly that the register to be
accessed here is different and hence that the same bit may have a different
meaning/semantics. I thought that this kind of dependency can be confusing
and should be avoided.
That said, if you really want to use reset
[PATCH rdma-next 0/3] Various fixes collected over time
From: Leon Romanovsky Hi, This is set of various and unrelated fixes that we collected over time. Thanks Avihai Horon (1): RDMA/uverbs: Fix incorrect variable type Jack Morgenstein (2): RDMA/core: Clean up cq pool mechanism RDMA/core: Do not indicate device ready when device enablement fails drivers/infiniband/core/core_priv.h | 3 +-- drivers/infiniband/core/cq.c | 12 ++-- drivers/infiniband/core/device.c | 16 ++-- .../infiniband/core/uverbs_std_types_device.c| 14 +- include/rdma/uverbs_ioctl.h | 10 ++ 5 files changed, 28 insertions(+), 27 deletions(-) -- 2.28.0
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
On Tue, Dec 08, 2020 at 03:31:34PM +0900, Kuniyuki Iwashima wrote: > From: Martin KaFai Lau > Date: Mon, 7 Dec 2020 12:33:15 -0800 > > On Thu, Dec 03, 2020 at 11:14:24PM +0900, Kuniyuki Iwashima wrote: > > > From: Eric Dumazet > > > Date: Tue, 1 Dec 2020 16:25:51 +0100 > > > > On 12/1/20 3:44 PM, Kuniyuki Iwashima wrote: > > > > > This patch lets reuseport_detach_sock() return a pointer of struct > > > > > sock, > > > > > which is used only by inet_unhash(). If it is not NULL, > > > > > inet_csk_reqsk_queue_migrate() migrates TCP_ESTABLISHED/TCP_SYN_RECV > > > > > sockets from the closing listener to the selected one. > > > > > > > > > > Listening sockets hold incoming connections as a linked list of struct > > > > > request_sock in the accept queue, and each request has reference to a > > > > > full > > > > > socket and its listener. In inet_csk_reqsk_queue_migrate(), we only > > > > > unlink > > > > > the requests from the closing listener's queue and relink them to the > > > > > head > > > > > of the new listener's queue. We do not process each request and its > > > > > reference to the listener, so the migration completes in O(1) time > > > > > complexity. However, in the case of TCP_SYN_RECV sockets, we take > > > > > special > > > > > care in the next commit. > > > > > > > > > > By default, the kernel selects a new listener randomly. In order to > > > > > pick > > > > > out a different socket every time, we select the last element of > > > > > socks[] as > > > > > the new listener. This behaviour is based on how the kernel moves > > > > > sockets > > > > > in socks[]. (See also [1]) > > > > > > > > > > Basically, in order to redistribute sockets evenly, we have to use an > > > > > eBPF > > > > > program called in the later commit, but as the side effect of such > > > > > default > > > > > selection, the kernel can redistribute old requests evenly to new > > > > > listeners > > > > > for a specific case where the application replaces listeners by > > > > > generations. > > > > > > > > > > For example, we call listen() for four sockets (A, B, C, D), and > > > > > close the > > > > > first two by turns. The sockets move in socks[] like below. > > > > > > > > > > socks[0] : A <-. socks[0] : D socks[0] : D > > > > > socks[1] : B | => socks[1] : B <-. => socks[1] : C > > > > > socks[2] : C | socks[2] : C --' > > > > > socks[3] : D --' > > > > > > > > > > Then, if C and D have newer settings than A and B, and each socket > > > > > has a > > > > > request (a, b, c, d) in their accept queue, we can redistribute old > > > > > requests evenly to new listeners. > > > > > > > > > > socks[0] : A (a) <-. socks[0] : D (a + d) socks[0] : D (a > > > > > + d) > > > > > socks[1] : B (b) | => socks[1] : B (b) <-. => socks[1] : C (b > > > > > + c) > > > > > socks[2] : C (c) | socks[2] : C (c) --' > > > > > socks[3] : D (d) --' > > > > > > > > > > Here, (A, D) or (B, C) can have different application settings, but > > > > > they > > > > > MUST have the same settings at the socket API level; otherwise, > > > > > unexpected > > > > > error may happen. For instance, if only the new listeners have > > > > > TCP_SAVE_SYN, old requests do not have SYN data, so the application > > > > > will > > > > > face inconsistency and cause an error. > > > > > > > > > > Therefore, if there are different kinds of sockets, we must attach an > > > > > eBPF > > > > > program described in later commits. > > > > > > > > > > Link: > > > > > https://lore.kernel.org/netdev/CAEfhGiyG8Y_amDZ2C8dQoQqjZJMHjTY76b=KBkTKcBtA=dh...@mail.gmail.com/ > > > > > Reviewed-by: Benjamin Herrenschmidt > > > > > Signed-off-by: Kuniyuki Iwashima > > > > > --- > > > > > include/net/inet_connection_sock.h | 1 + > > > > > include/net/sock_reuseport.h | 2 +- > > > > > net/core/sock_reuseport.c | 10 +- > > > > > net/ipv4/inet_connection_sock.c| 30 > > > > > ++ > > > > > net/ipv4/inet_hashtables.c | 9 +++-- > > > > > 5 files changed, 48 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/include/net/inet_connection_sock.h > > > > > b/include/net/inet_connection_sock.h > > > > > index 7338b3865a2a..2ea2d743f8fc 100644 > > > > > --- a/include/net/inet_connection_sock.h > > > > > +++ b/include/net/inet_connection_sock.h > > > > > @@ -260,6 +260,7 @@ struct dst_entry *inet_csk_route_child_sock(const > > > > > struct sock *sk, > > > > > struct sock *inet_csk_reqsk_queue_add(struct sock *sk, > > > > > struct request_sock *req, > > > > > struct sock *child); > > > > > +void inet_csk_reqsk_queue_migrate(struct sock *sk, struct sock *nsk); > > > > > void inet_csk_reqsk_queue_hash_add(struct sock *sk, struct > > > > > request_sock *req, > > > > > unsigned long timeout); > > > > >
Re: [PATCH] usb: dwc2: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On 12/8/2020 11:29 AM, Artur Petrosyan wrote: > On 12/4/2020 12:36, Xu Wang wrote: >> Because clk_prepare_enable() and clk_disable_unprepare() already checked >> NULL clock parameter, so the additional checks are unnecessary, just >> remove them. >> >> Signed-off-by: Xu Wang > > Reviewed-by: Artur Petrosyan > Acked-by: Minas Harutyunyan
Re: [PATCH 1/1] mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
Xiaohui Zhang wrote: > From: Zhang Xiaohui > > mwifiex_cmd_802_11_ad_hoc_start() calls memcpy() without checking > the destination size may trigger a buffer overflower, > which a local user could use to cause denial of service > or the execution of arbitrary code. > Fix it by putting the length check before calling memcpy(). > > Signed-off-by: Zhang Xiaohui Patch applied to wireless-drivers-next.git, thanks. 5c455c5ab332 mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start -- https://patchwork.kernel.org/project/linux-wireless/patch/20201206084801.26479-1-ruc_zhangxiao...@163.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3
Hi Doug,
On Mon, Dec 7, 2020 at 11:15 PM Doug Anderson wrote:
> On Mon, Dec 7, 2020 at 1:55 PM Arnd Bergmann wrote:
> > On Mon, Dec 7, 2020 at 9:23 PM Geert Uytterhoeven
> > wrote:
> > > On Tue, Dec 1, 2020 at 3:06 PM Arnd Bergmann wrote:
> > > > On Tue, Dec 1, 2020 at 12:39 PM Ulf Hansson
> > > > wrote:
> > > > > So, I think we have two options. If people are willing to move to
> > > > > "disk labels" or to patch their DTBs with mmc aliases, things can stay
> > > > > as is. Otherwise, we can revert the async probe parts of the mmc host
> > > > > drivers, but that would still leave us in a fragile situation.
> > > >
> > > > Can you reliably detect whether the mmc aliases in the dt exist?
> > > > If that's possible, maybe the async flag could be masked out to only
> > > > have
> > > > an effect when the device number is known.
> > >
> > > IMHO DT aliases are not a proper solution for this.
> > >
> > > Yes, you can detect reliably if an alias exists in the DT.
> > > The problems start when having multiple devices, some with aliases,
> > > some without. And when devices can appear dynamically (without
> > > aliases, as there is no support for dynamically updating the aliases
> > > list).
> >
> > Actually you hit a problem earlier than that: the async probe is a
> > property of the host controller driver, which may be a pci_driver,
> > platform_driver, usb_driver, or anything else really. To figure out
> > whether to probe it asynchronously, it would have to be the driver
> > core, or each bus type that can host these to understand which
> > device driver is responsible for probing an eMMC device attached
> > to the host.
>
> From what I've seen so far, my current thought on this issue is that
> it's up to Ulf as the MMC maintainer what the next steps are. For me,
> at least, his argument that MMC block numbers have already shuffled
> around several times in the last several years is at least some
> evidence that they weren't exactly stable to begin with. While we
> could go back to the numbers that happened to be chosen as of kernel
> v5.9, if someone was updating from a much older kernel then they may
> have different expectations of what numbers are good / bad I think.
>
> I will also offer one possible suggestion: what about a KConfig option
> here? In theory we could add a KConfig option like
> "CONFIG_MMC_LEGACY_PROBE" or something that. One can argue about what
> the default ought to be, but maybe that would satisfy folks? If you
> were happy giving up a little bit of boot speed to get the v5.9 block
> numbers then you could set this.
This is not limited to MMC.
The same is true for sdX, ethX (e* these days), ttyS*, i2cX, spiX, ...
The rule has always been to handle it by udev, disklabels, ...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 1/6] cpufreq: sun50i: add efuse_xlate to get efuse version.
Please use --thread=shallow while creating the patches, I use the following options normally, so they appear as a thread. git format-patch -C -M --thread=shallow -- viresh
Re: [PATCH] usb: dwc2: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On 12/4/2020 12:36, Xu Wang wrote:
> Because clk_prepare_enable() and clk_disable_unprepare() already checked
> NULL clock parameter, so the additional checks are unnecessary, just
> remove them.
>
> Signed-off-by: Xu Wang
Reviewed-by: Artur Petrosyan
> ---
> drivers/usb/dwc2/platform.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 5f18acac7406..ba2b491c7f82 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -143,11 +143,9 @@ static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg
> *hsotg)
> if (ret)
> return ret;
>
> - if (hsotg->clk) {
> - ret = clk_prepare_enable(hsotg->clk);
> - if (ret)
> - return ret;
> - }
> + ret = clk_prepare_enable(hsotg->clk);
> + if (ret)
> + return ret;
>
> if (hsotg->uphy) {
> ret = usb_phy_init(hsotg->uphy);
> @@ -195,8 +193,7 @@ static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg
> *hsotg)
> if (ret)
> return ret;
>
> - if (hsotg->clk)
> - clk_disable_unprepare(hsotg->clk);
> + clk_disable_unprepare(hsotg->clk);
>
> return 0;
> }
>
Re: Re: [PATCH v15 2/8] mtd: rawnand: rockchip: NFC drivers for RK3308, RK2928 and others
Hi Johan, Yes, I will post NFC code to Uboot，but it may take a while to modify the code for Uboot. -- yifeng >Hi Yifeng, > >Meanwhile, could you post a RFC version for Uboot based on this version >plus comments, so people can test the whole process from programming, >booting and kernel? > >On 11/30/20 1:49 PM, Johan Jonker wrote: >> Hi, >> >> Looks good to me. >> Do the maintainers or someone else have any major issues? >> Could Miquel indicate if a version 16 must be send for that 'ret' >> variable alone or is it OK now? >> >> >> On 11/30/20 11:00 AM, Yifeng Zhao wrote: >>> This driver supports Rockchip NFC (NAND Flash Controller) found on RK3308, >>> RK2928, RKPX30, RV1108 and other SOCs. The driver has been tested using >>> 8-bit NAND interface on the ARM based RK3308 platform. > >[..] > >>> +/** >>> + * struct rk_ecc_cnt_status: represent a ecc status data. > >represent the ECC status data. > >>> + * @err_flag_bit: error flag bit index at register. >>> + * @low: ECC count low bit index at register. >>> + * @low_mask: mask bit. >>> + * @low_bn: ECC count low bit number. >>> + * @high: ECC count high bit index at register. >>> + * @high_mask: mask bit >>> + */ > > >
Re: [PATCH 06/12] arm64: dts: zynqmp: Add label for zynqmp_ipi
Hi Laurent, On 07. 12. 20 23:16, Laurent Pinchart wrote: > Hi Michal, > > On Mon, Dec 07, 2020 at 10:39:25AM +0100, Michal Simek wrote: >> On 06. 12. 20 23:46, Laurent Pinchart wrote: >>> On Wed, Dec 02, 2020 at 03:06:05PM +0100, Michal Simek wrote: Add label which is used by bootloader for adding bootloader specific flag. Signed-off-by: Michal Simek --- U-Boot needs to add u-boot,dm-pre-reloc; property >>> >>> I'm not entirely sure what best practice rules are in this area, but >>> shouldn't U-Boot locate the node by name instead of label ? >> >> Labels are not listed in dt binding and there are two approaches how to >> reference nodes. Via full path with node name or via labels. >> I do normally use labels which are much simple. > > Note that labels require the DTB to be compiled with the -@ option, > otherwise they're not present in the binary. U-Boot is using different concept. You can see that there are a lot of -u-boot.dtsi files in dts folders. These are automatically included to DTS before DTC is called. It means you don't need to build overlay to get merged. > >> And also if you take a look how dtb looks like (convert back to dts) you >> can see that for example aliases are using full path (just ) but >> clocks/gic which is the part of <> is handled via phandles as numbers. >> >> And labels names can vary and shouldn't be the part of binding doc as >> far as I know. But I can be wrong of course. > > The DT bindings should document the interface with the operating system, > and if applicable, the boot loader. If the boot loader requires a > particular label, then it becomes part of the ABI, and I think it should > be documented in the bindings. We have been discussing with Rob some month ago but didn't have a time to do step further. Just keep it short Rob was ok to keep bootloader binding inside Linux repo. There is no hardcoding for a particular name. There is just a need to have any label. U-Boot needs to have one property(e.g. u-boot,dm-pre-reloc;) just to do early allocation. The name is just reference and none is really looking for it. It is just a way how to include it in much easier way. Thanks, Michal
Re: BUG: unable to handle kernel paging request in bpf_lru_populate
On Mon, Dec 7, 2020 at 12:43 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:bcd684aa net/nfc/nci: Support NCI 2.x initial sequence
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12001bd350
> kernel config: https://syzkaller.appspot.com/x/.config?x=3cb098ab0334059f
> dashboard link: https://syzkaller.appspot.com/bug?extid=ec2234240c96fdd26b93
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11f7f2ef50
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=103833f750
>
> The issue was bisected to:
>
> commit b93ef089d35c3386dd197e85afb6399bbd54cfb3
> Author: Martin KaFai Lau
> Date: Mon Nov 16 20:01:13 2020 +
>
> bpf: Fix the irq and nmi check in bpf_sk_storage for tracing usage
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1103b83750
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1303b83750
> console output: https://syzkaller.appspot.com/x/log.txt?x=1503b83750
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ec2234240c96fdd26...@syzkaller.appspotmail.com
> Fixes: b93ef089d35c ("bpf: Fix the irq and nmi check in bpf_sk_storage for
> tracing usage")
I assume this is also
#syz fix: bpf: Avoid overflows involving hash elem_size
> BUG: unable to handle page fault for address: f5200471266c
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 23fff2067 P4D 23fff2067 PUD 101a4067 PMD 32e3a067 PTE 0
> Oops: [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 8503 Comm: syz-executor608 Not tainted 5.10.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:bpf_common_lru_populate kernel/bpf/bpf_lru_list.c:569 [inline]
> RIP: 0010:bpf_lru_populate+0xd8/0x5e0 kernel/bpf/bpf_lru_list.c:614
> Code: 03 4d 01 e7 48 01 d8 48 89 4c 24 10 4d 89 fe 48 89 44 24 08 e8 99 23 eb
> ff 49 8d 7e 12 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <0f> b6 04 18 38 d0 7f
> 08 84 c0 0f 85 80 04 00 00 49 8d 7e 13 41 c6
> RSP: 0018:c9000126fc20 EFLAGS: 00010202
> RAX: 19200471266c RBX: dc00 RCX: 8184e3e2
> RDX: 0002 RSI: 8184e2e7 RDI: c90023893362
> RBP: 00bc R08: 107c R09:
> R10: 107c R11: R12: 0001
> R13: 107c R14: c90023893350 R15: c900234832f0
> FS: 00fe0880() GS:8880b9f0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: f5200471266c CR3: 1ba62000 CR4: 001506e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
> prealloc_init kernel/bpf/hashtab.c:319 [inline]
> htab_map_alloc+0xf6e/0x1230 kernel/bpf/hashtab.c:507
> find_and_alloc_map kernel/bpf/syscall.c:123 [inline]
> map_create kernel/bpf/syscall.c:829 [inline]
> __do_sys_bpf+0xa81/0x5170 kernel/bpf/syscall.c:4374
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x4402e9
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f
> 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7ffe77af23b8 EFLAGS: 0246 ORIG_RAX: 0141
> RAX: ffda RBX: 004002c8 RCX: 004402e9
> RDX: 0040 RSI: 2000 RDI: 0d00
> RBP: 006ca018 R08: R09:
> R10: R11: 0246 R12: 00401af0
> R13: 00401b80 R14: R15:
> Modules linked in:
> CR2: f5200471266c
> ---[ end trace 4f3928bacde7b3ed ]---
> RIP: 0010:bpf_common_lru_populate kernel/bpf/bpf_lru_list.c:569 [inline]
> RIP: 0010:bpf_lru_populate+0xd8/0x5e0 kernel/bpf/bpf_lru_list.c:614
> Code: 03 4d 01 e7 48 01 d8 48 89 4c 24 10 4d 89 fe 48 89 44 24 08 e8 99 23 eb
> ff 49 8d 7e 12 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <0f> b6 04 18 38 d0 7f
> 08 84 c0 0f 85 80 04 00 00 49 8d 7e 13 41 c6
> RSP: 0018:c9000126fc20 EFLAGS: 00010202
> RAX: 19200471266c RBX: dc00 RCX: 8184e3e2
> RDX: 0002 RSI: 8184e2e7 RDI: c90023893362
> RBP: 00bc R08: 107c R09:
> R10: 107c R11: R12: 0001
> R13: 107c R14: c90023893350 R15: c900234832f0
> FS: 00fe0880() GS:8880b9f0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: f5200471266c CR3: 1ba62000 CR4: 001506e0
> DR0: DR1:
Re: [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM
On 08-12-20, 07:22, Nicola Mazzucato wrote:
> On 12/8/20 5:50 AM, Viresh Kumar wrote:
> > On 02-12-20, 17:23, Nicola Mazzucato wrote:
> >>nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> >>if (nr_opp <= 0) {
> >> - dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
> >> - ret = -EPROBE_DEFER;
> >> - goto out_free_opp;
> >> + ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
> >> + if (ret) {
> >> + dev_warn(cpu_dev, "failed to add opps to the device\n");
> >> + goto out_free_cpumask;
> >> + }
> >> +
> >> + ret = dev_pm_opp_set_sharing_cpus(cpu_dev, opp_shared_cpus);
> >> + if (ret) {
> >> + dev_err(cpu_dev, "%s: failed to mark OPPs as shared:
> >> %d\n",
> >> + __func__, ret);
> >> + goto out_free_cpumask;
> >> + }
> >> +
> >
> > Why do we need to call above two after calling
> > dev_pm_opp_get_opp_count() ?
>
> Sorry, I am not sure to understand your question here. If there are no opps
> for
> a device we want to add them to it
Earlier we used to call handle->perf_ops->device_opps_add() and
dev_pm_opp_set_sharing_cpus() before calling dev_pm_opp_get_opp_count(), why is
the order changed now ?
> otherwise no need as they would be duplicated.
I am not sure why they would be duplicated in your case. I though
device_opps_add() is responsible for dynamically adding the OPPs here.
> > And we don't check the return value of
> > the below call anymore, moreover we have to call it twice now.
>
> This second get_opp_count is required such that we register em with the
> correct
> opp number after having added them. Without this the opp_count would not be
> correct.
What if the count is still 0 ? What about deferred probe we were doing earlier ?
--
viresh
Re: KASAN: vmalloc-out-of-bounds Write in pcpu_freelist_populate
On Mon, Dec 7, 2020 at 9:03 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:34da8721 selftests/bpf: Test bpf_sk_storage_get in tcp ite.. > git tree: bpf-next > console output: https://syzkaller.appspot.com/x/log.txt?x=10c3b83750 > kernel config: https://syzkaller.appspot.com/x/.config?x=3cb098ab0334059f > dashboard link: https://syzkaller.appspot.com/bug?extid=942085bfb8f7a276af1c > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+942085bfb8f7a276a...@syzkaller.appspotmail.com I assume this is also #syz fix: bpf: Avoid overflows involving hash elem_size > == > BUG: KASAN: vmalloc-out-of-bounds in pcpu_freelist_push_node > kernel/bpf/percpu_freelist.c:33 [inline] > BUG: KASAN: vmalloc-out-of-bounds in pcpu_freelist_populate+0x1fe/0x260 > kernel/bpf/percpu_freelist.c:114 > Write of size 8 at addr c90119e78020 by task syz-executor.4/27988 > > CPU: 1 PID: 27988 Comm: syz-executor.4 Not tainted 5.10.0-rc6-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x107/0x163 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0x5/0x4c8 mm/kasan/report.c:385 > __kasan_report mm/kasan/report.c:545 [inline] > kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562 > pcpu_freelist_push_node kernel/bpf/percpu_freelist.c:33 [inline] > pcpu_freelist_populate+0x1fe/0x260 kernel/bpf/percpu_freelist.c:114 > prealloc_init kernel/bpf/hashtab.c:323 [inline] > htab_map_alloc+0x981/0x1230 kernel/bpf/hashtab.c:507 > find_and_alloc_map kernel/bpf/syscall.c:123 [inline] > map_create kernel/bpf/syscall.c:829 [inline] > __do_sys_bpf+0xa81/0x5170 kernel/bpf/syscall.c:4374 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x45e0f9 > Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f > 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f679c7a7c68 EFLAGS: 0246 > ORIG_RAX: 0141 > RAX: ffda RBX: 0003 RCX: 0045e0f9 > RDX: 0040 RSI: 2040 RDI: > RBP: 0119c068 R08: R09: > R10: R11: 0246 R12: 0119c034 > R13: 7fffd601c75f R14: 7f679c7a89c0 R15: 0119c034 > > > Memory state around the buggy address: > c90119e77f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > c90119e77f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > >c90119e78000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >^ > c90119e78080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > c90119e78100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > == > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/caabb705b5e550aa%40google.com.
Re: [PATCH 1/2] mm/madvise: allow process_madvise operations on entire memory range
On Mon, Nov 30, 2020 at 11:01 AM Suren Baghdasaryan wrote:
>
> On Wed, Nov 25, 2020 at 3:43 PM Minchan Kim wrote:
> >
> > On Wed, Nov 25, 2020 at 03:23:40PM -0800, Suren Baghdasaryan wrote:
> > > On Wed, Nov 25, 2020 at 3:13 PM Minchan Kim wrote:
> > > >
> > > > On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
> > > > > process_madvise requires a vector of address ranges to be provided for
> > > > > its operations. When an advice should be applied to the entire
> > > > > process,
> > > > > the caller process has to obtain the list of VMAs of the target
> > > > > process
> > > > > by reading the /proc/pid/maps or some other way. The cost of this
> > > > > operation grows linearly with increasing number of VMAs in the target
> > > > > process. Even constructing the input vector can be non-trivial when
> > > > > target process has several thousands of VMAs and the syscall is being
> > > > > issued during high memory pressure period when new allocations for
> > > > > such
> > > > > a vector would only worsen the situation.
> > > > > In the case when advice is being applied to the entire memory space of
> > > > > the target process, this creates an extra overhead.
> > > > > Add PMADV_FLAG_RANGE flag for process_madvise enabling the caller to
> > > > > advise a memory range of the target process. For now, to keep it
> > > > > simple,
> > > > > only the entire process memory range is supported, vec and vlen inputs
> > > > > in this mode are ignored and can be NULL and 0.
> > > > > Instead of returning the number of bytes that advice was successfully
> > > > > applied to, the syscall in this mode returns 0 on success. This is due
> > > > > to the fact that the number of bytes would not be useful for the
> > > > > caller
> > > > > that does not know the amount of memory the call is supposed to
> > > > > affect.
> > > > > Besides, the ssize_t return type can be too small to hold the number
> > > > > of
> > > > > bytes affected when the operation is applied to a large memory range.
> > > >
> > > > Can we just use one element in iovec to indicate entire address rather
> > > > than using up the reserved flags?
> > > >
> > > > struct iovec {
> > > > .iov_base = NULL,
> > > > .iov_len = (~(size_t)0),
> > > > };
> > > >
> > > > Furthermore, it would be applied for other syscalls where have support
> > > > iovec if we agree on it.
> > > >
> > >
> > > The flag also changes the return value semantics. If we follow your
> > > suggestion we should also agree that in this mode the return value
> > > will be 0 on success and negative otherwise instead of the number of
> > > bytes madvise was applied to.
> >
> > Well, return value will depends on the each API. If the operation is
> > desruptive, it should return the right size affected by the API but
> > would be okay with 0 or error, otherwise.
>
> I'm fine with dropping the flag, I just thought with the flag it would
> be more explicit that this is a special mode operating on ranges. This
> way the patch also becomes simpler.
> Andrew, Michal, Christian, what do you think about such API? Should I
> change the API this way / keep the flag / change it in some other way?
Friendly ping to get some feedback on the proposed API please.
[PATCH v4 6/6] arm64: dts: allwinner: a100: Enable cpufreq on a100
Enable cpufreq for all CPU cores on a100.
Signed-off-by: Shuosheng Huang
---
.../allwinner/sun50i-a100-allwinner-perf1.dts| 16
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 6 +++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
index 301793c72cb7..62a770f1a979 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
@@ -21,6 +21,22 @@ chosen {
};
};
+ {
+ cpu-supply = <_dcdc2>;
+};
+
+ {
+ cpu-supply = <_dcdc2>;
+};
+
+ {
+ cpu-supply = <_dcdc2>;
+};
+
+ {
+ cpu-supply = <_dcdc2>;
+};
+
{
vcc-pb-supply = <_dcdc1>;
vcc-pc-supply = <_eldo1>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index 8f370a175ce6..c6ff172bf599 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -26,7 +26,7 @@ cpu0: cpu@0 {
clocks = < CLK_CPUX>;
};
- cpu@1 {
+ cpu1: cpu@1 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x1>;
@@ -34,7 +34,7 @@ cpu@1 {
clocks = < CLK_CPUX>;
};
- cpu@2 {
+ cpu2: cpu@2 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x2>;
@@ -42,7 +42,7 @@ cpu@2 {
clocks = < CLK_CPUX>;
};
- cpu@3 {
+ cpu3: cpu@3 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x3>;
--
2.28.0
Re: + revert-mm-filemap-add-static-for-function-__add_to_page_cache_locked.patch added to -mm tree
a...@linux-foundation.org wrote:
> The patch titled
> Subject: revert "mm/filemap: add static for function
> __add_to_page_cache_locked"
> has been added to the -mm tree. Its filename is
>
> revert-mm-filemap-add-static-for-function-__add_to_page_cache_locked.patch
>
> This patch should soon appear at
>
> https://ozlabs.org/~akpm/mmots/broken-out/revert-mm-filemap-add-static-for-function-__add_to_page_cache_locked.patch
> and later at
>
> https://ozlabs.org/~akpm/mmotm/broken-out/revert-mm-filemap-add-static-for-function-__add_to_page_cache_locked.patch
>
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/process/submit-checklist.rst when testing
> your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> --
> From: Andrew Morton
> Subject: revert "mm/filemap: add static for function
> __add_to_page_cache_locked"
>
> Revert 3351b16af494 ("mm/filemap: add static for function
> __add_to_page_cache_locked") due to build issues with
> CONFIG_DEBUG_INFO_BTF=y.
>
> Link:
> https://lkml.kernel.org/r/caadnvqj6tmzbxvtrobueh6qa0h+q7yaskxrvvvxhqr3kbzd...@mail.gmail.com
> Cc: Michal Kubecek
> Cc: Justin Forbes
> Cc: Alex Shi
> Cc: Souptick Joarder
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: Josef Bacik
> Signed-off-by: Andrew Morton
Thanks.
Tested-by: Greg Thelen
> ---
>
> mm/filemap.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> ---
> a/mm/filemap.c~revert-mm-filemap-add-static-for-function-__add_to_page_cache_locked
> +++ a/mm/filemap.c
> @@ -827,7 +827,7 @@ int replace_page_cache_page(struct page
> }
> EXPORT_SYMBOL_GPL(replace_page_cache_page);
>
> -static noinline int __add_to_page_cache_locked(struct page *page,
> +noinline int __add_to_page_cache_locked(struct page *page,
> struct address_space *mapping,
> pgoff_t offset, gfp_t gfp,
> void **shadowp)
> _
>
> Patches currently in -mm which might be from a...@linux-foundation.org are
>
> revert-mm-filemap-add-static-for-function-__add_to_page_cache_locked.patch
> kthread_worker-document-cpu-hotplug-handling-fix.patch
> mm.patch
> mm-remove-the-unuseful-else-after-a-return-checkpatch-fixes.patch
> mm-prevent-gup_fast-from-racing-with-cow-during-fork-checkpatch-fixes.patch
> mm-swap_state-skip-meaningless-swap-cache-readahead-when-ra_infowin-==-0-fix.patch
> mm-vmallocc-__vmalloc_area_node-avoid-32-bit-overflow.patch
> mm-cma-improve-pr_debug-log-in-cma_release-fix.patch
> mm-vmstat-fix-proc-sys-vm-stat_refresh-generating-false-warnings-fix-2.patch
> lib-cmdline_kunit-add-a-new-test-suite-for-cmdline-api-fix.patch
> ilog2-improve-ilog2-for-constant-arguments-checkpatch-fixes.patch
> lib-test_bitmapc-add-for_each_set_clump-test-cases-checkpatch-fixes.patch
> checkpatch-fix-typo_spelling-check-for-words-with-apostrophe-fix.patch
> resource-fix-kernel-doc-markups-checkpatch-fixes.patch
> linux-next-rejects.patch
> kmap-stupid-hacks-to-make-it-compile.patch
> init-kconfig-dont-assume-scripts-lld-versionsh-is-executable.patch
> set_memory-allow-set_direct_map__noflush-for-multiple-pages-fix.patch
> arch-mm-wire-up-memfd_secret-system-call-were-relevant-fix.patch
> kernel-forkc-export-kernel_thread-to-modules.patch
[PATCH v6] coresight: etm4x: Modify core-commit of cpu to avoid the overflow of HiSilicon ETM
The ETM device can't keep up with the core pipeline when cpu core
is at full speed. This may cause overflow within core and its ETM.
This is a common phenomenon on ETM devices.
On HiSilicon Hip08 platform, a specific feature is added to set
core pipeline. So commit rate can be reduced manually to avoid ETM
overflow.
Reviewed-by: Suzuki K Poulose
Signed-off-by: Qi Liu
---
Change since v1:
- add CONFIG_ETM4X_IMPDEF_FEATURE and CONFIG_ETM4X_IMPDEF_HISILICON
to keep specific feature off platforms which don't use it.
Change since v2:
- remove some unused variable.
Change since v3:
- use read/write_sysreg_s() to access register.
Change since v4:
- rename the call back function to a more generic name, and fix some
compile warnings.
Change since v5:
- add function comments about HISI_HIP08_CORE_COMMIT_REG, and use
explicitly masked values when update register.
drivers/hwtracing/coresight/Kconfig| 9 ++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 98 ++
drivers/hwtracing/coresight/coresight-etm4x.h | 8 ++
3 files changed, 115 insertions(+)
diff --git a/drivers/hwtracing/coresight/Kconfig
b/drivers/hwtracing/coresight/Kconfig
index c119824..1cc3601 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -110,6 +110,15 @@ config CORESIGHT_SOURCE_ETM4X
To compile this driver as a module, choose M here: the
module will be called coresight-etm4x.
+config ETM4X_IMPDEF_FEATURE
+ bool "Control overflow impdef support in CoreSight ETM 4.x driver "
+ depends on CORESIGHT_SOURCE_ETM4X
+ help
+ This control provides overflow implement define for CoreSight
+ ETM 4.x tracer module which could not reduce commit race
+ automatically, and could avoid overflow within ETM tracer module
+ and its cpu core.
+
config CORESIGHT_STM
tristate "CoreSight System Trace Macrocell driver"
depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index abd706b..0cbc92a 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -3,6 +3,7 @@
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include
#include
@@ -28,7 +29,9 @@
#include
#include
#include
+
#include
+#include
#include
#include
@@ -103,6 +106,97 @@ struct etm4_enable_arg {
int rc;
};
+#ifdef CONFIG_ETM4X_IMPDEF_FEATURE
+
+#define HISI_HIP08_AMBA_ID 0x000b6d01
+#define ETM4_AMBA_MASK 0xf
+#define HISI_HIP08_CORE_COMMIT_MASK0x3000
+#define HISI_HIP08_CORE_COMMIT_SHIFT 12
+#define HISI_HIP08_CORE_COMMIT_FULL0b00
+#define HISI_HIP08_CORE_COMMIT_LVL_1 0b01
+#define HISI_HIP08_CORE_COMMIT_REG sys_reg(3, 1, 15, 2, 5)
+
+struct etm4_arch_features {
+ void (*arch_callback)(bool enable);
+};
+
+static bool etm4_hisi_match_pid(unsigned int id)
+{
+ return (id & ETM4_AMBA_MASK) == HISI_HIP08_AMBA_ID;
+}
+
+static void etm4_hisi_config_core_commit(bool enable)
+{
+ u8 commit = enable ? HISI_HIP08_CORE_COMMIT_LVL_1 :
+ HISI_HIP08_CORE_COMMIT_FULL;
+ u64 val;
+
+ /*
+* bit 12 and 13 of HISI_HIP08_CORE_COMMIT_REG are used together
+* to set core-commit, 2'b00 means cpu is at full speed, 2'b01,
+* 2'b10, 2'b11 mean reduce pipeline speed, and 2'b01 means level-1
+* speed(minimun value). So bit 12 and 13 should be cleared together.
+*/
+ val = read_sysreg_s(HISI_HIP08_CORE_COMMIT_REG);
+ val &= ~HISI_HIP08_CORE_COMMIT_MASK;
+ val |= commit << HISI_HIP08_CORE_COMMIT_SHIFT;
+ write_sysreg_s(val, HISI_HIP08_CORE_COMMIT_REG);
+}
+
+static struct etm4_arch_features etm4_features[] = {
+ [ETM4_IMPDEF_HISI_CORE_COMMIT] = {
+ .arch_callback = etm4_hisi_config_core_commit,
+ },
+ {},
+};
+
+static void etm4_enable_arch_specific(struct etmv4_drvdata *drvdata)
+{
+ struct etm4_arch_features *ftr;
+ int bit;
+
+ for_each_set_bit(bit, drvdata->arch_features, ETM4_IMPDEF_FEATURE_MAX) {
+ ftr = _features[bit];
+
+ if (ftr->arch_callback)
+ ftr->arch_callback(true);
+ }
+}
+
+static void etm4_disable_arch_specific(struct etmv4_drvdata *drvdata)
+{
+ struct etm4_arch_features *ftr;
+ int bit;
+
+ for_each_set_bit(bit, drvdata->arch_features, ETM4_IMPDEF_FEATURE_MAX) {
+ ftr = _features[bit];
+
+ if (ftr->arch_callback)
+ ftr->arch_callback(false);
+ }
+}
+
+static void etm4_check_arch_features(struct etmv4_drvdata *drvdata,
+ unsigned int id)
+{
+ if (etm4_hisi_match_pid(id))
+
Re: [PATCH v3 7/7] mm: memcontrol: make the slab calculation consistent
> Although the ratio of the slab is one, we also should read the ratio
> from the related memory_stats instead of hard-coding. And the local
> variable of size is already the value of slab_unreclaimable. So we
> do not need to read again.
>
> We can drop the ratio in struct memory_stat. This can make the code
> clean and simple. And get rid of the awkward mix of static and runtime
> initialization of the memory_stats table.
>
> Signed-off-by: Muchun Song
> ---
> mm/memcontrol.c | 112
>
> 1 file changed, 73 insertions(+), 39 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index a40797a27f87..841ea37cc123 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1511,49 +1511,78 @@ static bool mem_cgroup_wait_acct_move(struct
> mem_cgroup *memcg)
>
> struct memory_stat {
> const char *name;
> - unsigned int ratio;
> unsigned int idx;
> };
>
> static const struct memory_stat memory_stats[] = {
> - { "anon", PAGE_SIZE, NR_ANON_MAPPED },
> - { "file", PAGE_SIZE, NR_FILE_PAGES },
> - { "kernel_stack", 1024, NR_KERNEL_STACK_KB },
> - { "pagetables", PAGE_SIZE, NR_PAGETABLE },
> - { "percpu", 1, MEMCG_PERCPU_B },
> - { "sock", PAGE_SIZE, MEMCG_SOCK },
> - { "shmem", PAGE_SIZE, NR_SHMEM },
> - { "file_mapped", PAGE_SIZE, NR_FILE_MAPPED },
> - { "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
> - { "file_writeback", PAGE_SIZE, NR_WRITEBACK },
> + { "anon", NR_ANON_MAPPED },
> + { "file", NR_FILE_PAGES },
> + { "kernel_stack", NR_KERNEL_STACK_KB },
> + { "pagetables", NR_PAGETABLE},
> + { "percpu", MEMCG_PERCPU_B },
> + { "sock", MEMCG_SOCK },
> + { "shmem", NR_SHMEM},
> + { "file_mapped",NR_FILE_MAPPED },
> + { "file_dirty", NR_FILE_DIRTY },
> + { "file_writeback", NR_WRITEBACK},
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> - { "anon_thp", PAGE_SIZE, NR_ANON_THPS },
> - { "file_thp", PAGE_SIZE, NR_FILE_THPS },
> - { "shmem_thp", PAGE_SIZE, NR_SHMEM_THPS },
> + { "anon_thp", NR_ANON_THPS},
> + { "file_thp", NR_FILE_THPS},
> + { "shmem_thp", NR_SHMEM_THPS },
> #endif
> - { "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
> - { "active_anon", PAGE_SIZE, NR_ACTIVE_ANON },
> - { "inactive_file", PAGE_SIZE, NR_INACTIVE_FILE },
> - { "active_file", PAGE_SIZE, NR_ACTIVE_FILE },
> - { "unevictable", PAGE_SIZE, NR_UNEVICTABLE },
> -
> - /*
> -* Note: The slab_reclaimable and slab_unreclaimable must be
> -* together and slab_reclaimable must be in front.
> -*/
> - { "slab_reclaimable", 1, NR_SLAB_RECLAIMABLE_B },
> - { "slab_unreclaimable", 1, NR_SLAB_UNRECLAIMABLE_B },
> + { "inactive_anon", NR_INACTIVE_ANON},
> + { "active_anon",NR_ACTIVE_ANON },
> + { "inactive_file", NR_INACTIVE_FILE},
> + { "active_file",NR_ACTIVE_FILE },
> + { "unevictable",NR_UNEVICTABLE },
> + { "slab_reclaimable", NR_SLAB_RECLAIMABLE_B },
> + { "slab_unreclaimable", NR_SLAB_UNRECLAIMABLE_B },
>
> /* The memory events */
> - { "workingset_refault_anon", 1, WORKINGSET_REFAULT_ANON },
> - { "workingset_refault_file", 1, WORKINGSET_REFAULT_FILE },
> - { "workingset_activate_anon", 1, WORKINGSET_ACTIVATE_ANON },
> - { "workingset_activate_file", 1, WORKINGSET_ACTIVATE_FILE },
> - { "workingset_restore_anon", 1, WORKINGSET_RESTORE_ANON },
> - { "workingset_restore_file", 1, WORKINGSET_RESTORE_FILE },
> - { "workingset_nodereclaim", 1, WORKINGSET_NODERECLAIM },
> + { "workingset_refault_anon",WORKINGSET_REFAULT_ANON },
> + { "workingset_refault_file",WORKINGSET_REFAULT_FILE },
> + { "workingset_activate_anon", WORKINGSET_ACTIVATE_ANON},
> + { "workingset_activate_file", WORKINGSET_ACTIVATE_FILE},
> + { "workingset_restore_anon",WORKINGSET_RESTORE_ANON },
> + { "workingset_restore_file",WORKINGSET_RESTORE_FILE },
> + { "workingset_nodereclaim", WORKINGSET_NODERECLAIM },
> };
>
> +/* Translate stat items to the correct unit for memory.stat output */
> +static int
[PATCH v4 5/6] arm64: dts: allwinner: a100: Add Add CPU Operating Performance Points table
Add an Operating Performance Points table for the CPU cores to
enable Dynamic Voltage & Frequency Scaling on the A100.
Signed-off-by: Shuosheng Huang
---
.../allwinner/sun50i-a100-allwinner-perf1.dts | 1 +
.../dts/allwinner/sun50i-a100-cpu-opp.dtsi| 90 +++
2 files changed, 91 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
index d34c2bb1079f..301793c72cb7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-a100.dtsi"
+#include "sun50i-a100-cpu-opp.dtsi"
/{
model = "Allwinner A100 Perf1";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
new file mode 100644
index ..e245823d70e8
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (c) 2020 Yangtao Li
+// Copyright (c) 2020 ShuoSheng Huang
+
+/ {
+ cpu_opp_table: cpu-opp-table {
+ compatible = "allwinner,sun50i-h6-operating-points";
+ nvmem-cells = <_speed_grade>;
+ opp-shared;
+
+ opp@40800 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <40800>;
+
+ opp-microvolt-speed0 = <90 90 120>;
+ opp-microvolt-speed1 = <90 90 120>;
+ opp-microvolt-speed2 = <90 90 120>;
+ };
+
+ opp@6 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <6>;
+
+ opp-microvolt-speed0 = <90 90 120>;
+ opp-microvolt-speed1 = <90 90 120>;
+ opp-microvolt-speed2 = <90 90 120>;
+ };
+
+ opp@81600 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <81600>;
+
+ opp-microvolt-speed0 = <94 94 120>;
+ opp-microvolt-speed1 = <90 90 120>;
+ opp-microvolt-speed2 = <90 90 120>;
+ };
+
+ opp@108000 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <108000>;
+
+ opp-microvolt-speed0 = <102 102 120>;
+ opp-microvolt-speed1 = <98 98 120>;
+ opp-microvolt-speed2 = <95 95 120>;
+ };
+
+ opp@12 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <12>;
+
+ opp-microvolt-speed0 = <110 110 120>;
+ opp-microvolt-speed1 = <102 102 120>;
+ opp-microvolt-speed2 = <100 100 120>;
+ };
+
+ opp@132000 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <132000>;
+
+ opp-microvolt-speed0 = <116 116 120>;
+ opp-microvolt-speed1 = <106 106 120>;
+ opp-microvolt-speed2 = <103 103 120>;
+ };
+
+ opp@146400 {
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-hz = /bits/ 64 <146400>;
+
+ opp-microvolt-speed0 = <118 118 120>;
+ opp-microvolt-speed1 = <118 118 120>;
+ opp-microvolt-speed2 = <113 113 120>;
+ };
+ };
+};
+
+ {
+ operating-points-v2 = <_opp_table>;
+};
+
+ {
+ operating-points-v2 = <_opp_table>;
+};
+
+ {
+ operating-points-v2 = <_opp_table>;
+};
+
+ {
+ operating-points-v2 = <_opp_table>;
+};
--
2.28.0
[PATCH v4 4/6] arm64: dts: allwinner: a100: Add CPU speed grade efuse cell
Add CPU speed grade efuse cell for a100.
Signed-off-by: Shuosheng Huang
---
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index a669eb1fc965..8f370a175ce6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -125,6 +125,10 @@ efuse@3006000 {
ths_calibration: calib@14 {
reg = <0x14 8>;
};
+
+ cpu_speed_grade: cpu-speed-grade@1c {
+ reg = <0x1c 0x2>;
+ };
};
pio: pinctrl@300b000 {
--
2.28.0
[PATCH v4 3/6] arm64: dts: allwinner: a100: Add clocks to CPU cores
Add clocks to CPU cores for a100.
Signed-off-by: Shuosheng Huang
---
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index cc321c04f121..a669eb1fc965 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -23,6 +23,7 @@ cpu0: cpu@0 {
device_type = "cpu";
reg = <0x0>;
enable-method = "psci";
+ clocks = < CLK_CPUX>;
};
cpu@1 {
@@ -30,6 +31,7 @@ cpu@1 {
device_type = "cpu";
reg = <0x1>;
enable-method = "psci";
+ clocks = < CLK_CPUX>;
};
cpu@2 {
@@ -37,6 +39,7 @@ cpu@2 {
device_type = "cpu";
reg = <0x2>;
enable-method = "psci";
+ clocks = < CLK_CPUX>;
};
cpu@3 {
@@ -44,6 +47,7 @@ cpu@3 {
device_type = "cpu";
reg = <0x3>;
enable-method = "psci";
+ clocks = < CLK_CPUX>;
};
};
--
2.28.0
Re: [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM
Hi Viresh,
thanks for looking into this. Please find below
On 12/8/20 5:50 AM, Viresh Kumar wrote:
> On 02-12-20, 17:23, Nicola Mazzucato wrote:
>> By design, SCMI performance domains define the granularity of
>> performance controls, they do not describe any underlying hardware
>> dependencies (although they may match in many cases).
>>
>> It is therefore possible to have some platforms where hardware may have
>> the ability to control CPU performance at different granularity and choose
>> to describe fine-grained performance control through SCMI.
>>
>> In such situations, the energy model would be provided with inaccurate
>> information based on controls, while it still needs to know the
>> performance boundaries.
>>
>> To restore correct functionality, retrieve information of CPUs under the
>> same v/f domain from operating-points-v2 in DT, and pass it on to EM.
>>
>> Signed-off-by: Nicola Mazzucato
>> ---
>> drivers/cpufreq/scmi-cpufreq.c | 51 +++---
>> 1 file changed, 35 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
>> index 491a0a24fb1e..f505efcc62b1 100644
>> --- a/drivers/cpufreq/scmi-cpufreq.c
>> +++ b/drivers/cpufreq/scmi-cpufreq.c
>> @@ -127,6 +127,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy
>> *policy)
>> struct cpufreq_frequency_table *freq_table;
>> struct em_data_callback em_cb = EM_DATA_CB(scmi_get_cpu_power);
>> bool power_scale_mw;
>> +cpumask_var_t opp_shared_cpus;
>>
>> cpu_dev = get_cpu_device(policy->cpu);
>> if (!cpu_dev) {
>> @@ -134,30 +135,45 @@ static int scmi_cpufreq_init(struct cpufreq_policy
>> *policy)
>> return -ENODEV;
>> }
>>
>> -ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
>> -if (ret) {
>> -dev_warn(cpu_dev, "failed to add opps to the device\n");
>> -return ret;
>> -}
>> +if (!zalloc_cpumask_var(_shared_cpus, GFP_KERNEL))
>> +return -ENOMEM;
>>
>> ret = scmi_get_sharing_cpus(cpu_dev, policy->cpus);
>> if (ret) {
>> dev_warn(cpu_dev, "failed to get sharing cpumask\n");
>> -return ret;
>> +goto out_free_cpumask;
>> }
>>
>> -ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
>> -if (ret) {
>> -dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n",
>> -__func__, ret);
>> -return ret;
>> +/*
>> + * The OPP 'sharing cpus' info may come from dt through an empty opp
>> + * table and opp-shared. If found, it takes precedence over the SCMI
>> + * domain IDs info.
>> + */
>> +ret = dev_pm_opp_of_get_sharing_cpus(cpu_dev, opp_shared_cpus);
>> +if (ret || !cpumask_weight(opp_shared_cpus)) {
>> +/*
>> + * Either opp-table is not set or no opp-shared was found,
>> + * use the information from SCMI domain IDs.
>> + */
>> +cpumask_copy(opp_shared_cpus, policy->cpus);
>> }
>>
>> nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
>> if (nr_opp <= 0) {
>> -dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
>> -ret = -EPROBE_DEFER;
>> -goto out_free_opp;
>> +ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
>> +if (ret) {
>> +dev_warn(cpu_dev, "failed to add opps to the device\n");
>> +goto out_free_cpumask;
>> +}
>> +
>> +ret = dev_pm_opp_set_sharing_cpus(cpu_dev, opp_shared_cpus);
>> +if (ret) {
>> +dev_err(cpu_dev, "%s: failed to mark OPPs as shared:
>> %d\n",
>> +__func__, ret);
>> +goto out_free_cpumask;
>> +}
>> +
>
> Why do we need to call above two after calling
> dev_pm_opp_get_opp_count() ?
Sorry, I am not sure to understand your question here. If there are no opps for
a device we want to add them to it, otherwise no need as they would be
duplicated.
And we don't check the return value of
> the below call anymore, moreover we have to call it twice now.
This second get_opp_count is required such that we register em with the correct
opp number after having added them. Without this the opp_count would not be
correct.
Hope I have answered your questions.
>
>> +nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
>> }
>>
>> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> @@ -191,15 +207,18 @@ static int scmi_cpufreq_init(struct cpufreq_policy
>> *policy)
>> handle->perf_ops->fast_switch_possible(handle, cpu_dev);
>>
>> power_scale_mw = handle->perf_ops->power_scale_mw_get(handle);
>> -em_dev_register_perf_domain(cpu_dev, nr_opp, _cb, policy->cpus,
>> +em_dev_register_perf_domain(cpu_dev, nr_opp, _cb, opp_shared_cpus,
>>
[PATCH v4 1/6] cpufreq: sun50i: add efuse_xlate to get efuse version.
It's better to use efuse_xlate to extract the differentiated part
regarding different SoC.
Signed-off-by: Shuosheng Huang
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 82 --
1 file changed, 51 insertions(+), 31 deletions(-)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 9907a165135b..3c0531938d1a 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -19,24 +19,51 @@
#define MAX_NAME_LEN 7
-#define NVMEM_MASK 0x7
-#define NVMEM_SHIFT5
+#define SUN50I_H6_NVMEM_MASK 0x7
+#define SUN50I_H6_NVMEM_SHIFT 5
+
+struct sunxi_cpufreq_soc_data {
+ int (*efuse_xlate)(struct nvmem_cell *speedbin_nvmem);
+};
static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
+static int sun50i_h6_efuse_xlate(struct nvmem_cell *speedbin_nvmem)
+{
+ size_t len;
+ u32 *speedbin;
+ u32 efuse_value;
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, );
+ if (IS_ERR(speedbin))
+ return PTR_ERR(speedbin);
+
+ efuse_value = (*(u32 *)speedbin >> SUN50I_H6_NVMEM_SHIFT) &
+ SUN50I_H6_NVMEM_MASK;
+ kfree(speedbin);
+ /*
+* We treat unexpected efuse values as if the SoC was from
+* the slowest bin. Expected efuse values are 1-3, slowest
+* to fastest.
+*/
+ if (efuse_value >= 1 && efuse_value <= 3)
+ return efuse_value - 1;
+ else
+ return 0;
+}
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
- * @versions: Set to the value parsed from efuse
+ * @soc_data: pointer to sunxi_cpufreq_soc_data context
*
* Returns 0 if success.
*/
-static int sun50i_cpufreq_get_efuse(u32 *versions)
+static int sun50i_cpufreq_get_efuse(const struct sunxi_cpufreq_soc_data
*soc_data)
{
struct nvmem_cell *speedbin_nvmem;
struct device_node *np;
struct device *cpu_dev;
- u32 *speedbin, efuse_value;
- size_t len;
+ int versions;
int ret;
cpu_dev = get_cpu_device(0);
@@ -63,43 +90,33 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
return PTR_ERR(speedbin_nvmem);
}
- speedbin = nvmem_cell_read(speedbin_nvmem, );
+ versions = soc_data->efuse_xlate(speedbin_nvmem);
nvmem_cell_put(speedbin_nvmem);
- if (IS_ERR(speedbin))
- return PTR_ERR(speedbin);
-
- efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
- /*
-* We treat unexpected efuse values as if the SoC was from
-* the slowest bin. Expected efuse values are 1-3, slowest
-* to fastest.
-*/
- if (efuse_value >= 1 && efuse_value <= 3)
- *versions = efuse_value - 1;
- else
- *versions = 0;
- kfree(speedbin);
- return 0;
+ return versions;
};
static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
{
+ const struct of_device_id *match;
struct opp_table **opp_tables;
char name[MAX_NAME_LEN];
unsigned int cpu;
- u32 speed = 0;
+ int speed = 0;
int ret;
+ match = dev_get_platdata(>dev);
+ if (!match)
+ return -EINVAL;
+
opp_tables = kcalloc(num_possible_cpus(), sizeof(*opp_tables),
GFP_KERNEL);
if (!opp_tables)
return -ENOMEM;
- ret = sun50i_cpufreq_get_efuse();
- if (ret)
- return ret;
+ speed = sun50i_cpufreq_get_efuse(match->data);
+ if (speed < 0)
+ return speed;
snprintf(name, MAX_NAME_LEN, "speed%d", speed);
@@ -163,8 +180,12 @@ static struct platform_driver sun50i_cpufreq_driver = {
},
};
+static const struct sunxi_cpufreq_soc_data sun50i_h6_data = {
+ .efuse_xlate = sun50i_h6_efuse_xlate,
+};
+
static const struct of_device_id sun50i_cpufreq_match_list[] = {
- { .compatible = "allwinner,sun50i-h6" },
+ { .compatible = "allwinner,sun50i-h6", .data = _h6_data },
{}
};
@@ -198,9 +219,8 @@ static int __init sun50i_cpufreq_init(void)
if (unlikely(ret < 0))
return ret;
- sun50i_cpufreq_pdev =
- platform_device_register_simple("sun50i-cpufreq-nvmem",
- -1, NULL, 0);
+ sun50i_cpufreq_pdev = platform_device_register_data(NULL,
+ "sun50i-cpufreq-nvmem", -1, match, sizeof(*match));
ret = PTR_ERR_OR_ZERO(sun50i_cpufreq_pdev);
if (ret == 0)
return 0;
--
2.28.0
[PATCH v4 2/6] cpufreq: sun50i: add a100 cpufreq support
Add cpufreq nvmem based for allwinner a100 SoC, it's similar to h6.
Signed-off-by: Shuosheng Huang
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 32 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3776d960f405..2ebf5d9cb616 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -102,6 +102,7 @@ static const struct of_device_id whitelist[] __initconst = {
*/
static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "allwinner,sun50i-h6", },
+ { .compatible = "allwinner,sun50i-a100", },
{ .compatible = "calxeda,highbank", },
{ .compatible = "calxeda,ecx-2000", },
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 3c0531938d1a..aead98164373 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -22,6 +22,9 @@
#define SUN50I_H6_NVMEM_MASK 0x7
#define SUN50I_H6_NVMEM_SHIFT 5
+#define SUN50I_A100_NVMEM_MASK 0xf
+#define SUN50I_A100_NVMEM_SHIFT12
+
struct sunxi_cpufreq_soc_data {
int (*efuse_xlate)(struct nvmem_cell *speedbin_nvmem);
};
@@ -52,6 +55,30 @@ static int sun50i_h6_efuse_xlate(struct nvmem_cell
*speedbin_nvmem)
return 0;
}
+static int sun50i_a100_efuse_xlate(struct nvmem_cell *speedbin_nvmem)
+{
+ size_t len;
+ u32 *speedbin;
+ u32 efuse_value;
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, );
+ if (IS_ERR(speedbin))
+ return PTR_ERR(speedbin);
+
+ efuse_value = (*(u16 *)efuse >> SUN50I_A100_NVMEM_SHIFT) &
+ SUN50I_A100_NVMEM_MASK;
+ kfree(speedbin);
+
+ switch (efuse_value) {
+ case 0b100:
+ return 2;
+ case 0b010:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
* @soc_data: pointer to sunxi_cpufreq_soc_data context
@@ -184,8 +211,13 @@ static const struct sunxi_cpufreq_soc_data sun50i_h6_data
= {
.efuse_xlate = sun50i_h6_efuse_xlate,
};
+static const struct sunxi_cpufreq_soc_data sun50i_a100_data = {
+ .efuse_xlate = sun50i_a100_efuse_xlate,
+};
+
static const struct of_device_id sun50i_cpufreq_match_list[] = {
{ .compatible = "allwinner,sun50i-h6", .data = _h6_data },
+ { .compatible = "allwinner,sun50i-a100", .data = _a100_data },
{}
};
--
2.28.0
[PATCH v6 4/5] clk: sifive: Fix the wrong bit field shift
The clk enable bit should be 31 instead of 24. Signed-off-by: Zong Li Reported-by: Pragnesh Patel --- drivers/clk/sifive/sifive-prci.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/sifive/sifive-prci.h b/drivers/clk/sifive/sifive-prci.h index 802fc8fb9c09..da7be9103d4d 100644 --- a/drivers/clk/sifive/sifive-prci.h +++ b/drivers/clk/sifive/sifive-prci.h @@ -59,7 +59,7 @@ /* DDRPLLCFG1 */ #define PRCI_DDRPLLCFG1_OFFSET 0x10 -#define PRCI_DDRPLLCFG1_CKE_SHIFT 24 +#define PRCI_DDRPLLCFG1_CKE_SHIFT 31 #define PRCI_DDRPLLCFG1_CKE_MASK (0x1 << PRCI_DDRPLLCFG1_CKE_SHIFT) /* GEMGXLPLLCFG0 */ @@ -81,7 +81,7 @@ /* GEMGXLPLLCFG1 */ #define PRCI_GEMGXLPLLCFG1_OFFSET 0x20 -#define RCI_GEMGXLPLLCFG1_CKE_SHIFT24 +#define RCI_GEMGXLPLLCFG1_CKE_SHIFT31 #define PRCI_GEMGXLPLLCFG1_CKE_MASK(0x1 << PRCI_GEMGXLPLLCFG1_CKE_SHIFT) /* CORECLKSEL */ -- 2.29.2
[PATCH v6 3/5] clk: sifive: Add a driver for the SiFive FU740 PRCI IP block
Add driver code for the SiFive FU740 PRCI IP block. This IP block
handles reset and clock control for the SiFive FU740 device and
implements SoC-level clock tree controls and dividers.
The link of unmatched as follow, and the U740-C000 manual would
be present in the same page as soon.
https://www.sifive.com/boards/hifive-unmatched
This driver contains bug fixes and contributions from
Henry Styles
Erik Danie
Pragnesh Patel
Signed-off-by: Zong Li
Reviewed-by: Pragnesh Patel
Acked-by: Palmer Dabbelt
Cc: Henry Styles
Cc: Erik Danie
Cc: Pragnesh Patel
---
drivers/clk/sifive/Kconfig| 4 +-
drivers/clk/sifive/Makefile | 1 +
drivers/clk/sifive/fu740-prci.c | 111
drivers/clk/sifive/fu740-prci.h | 21 +++
drivers/clk/sifive/sifive-prci.c | 120 ++
drivers/clk/sifive/sifive-prci.h | 88 +
include/dt-bindings/clock/sifive-fu740-prci.h | 23
7 files changed, 366 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/sifive/fu740-prci.c
create mode 100644 drivers/clk/sifive/fu740-prci.h
create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index ab48cf7e0105..1c14eb20c066 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -13,7 +13,7 @@ config CLK_SIFIVE_PRCI
select CLK_ANALOGBITS_WRPLL_CLN28HPC
help
Supports the Power Reset Clock interface (PRCI) IP block found in
- FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC,
- enable this driver.
+ FU540/FU740 SoCs. If this kernel is meant to run on a SiFive FU540/
+ FU740 SoCs, enable this driver.
endif
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index fe3e2cb4c4d8..2c05798e4ba4 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -2,3 +2,4 @@
obj-y += sifive-prci.o
obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu540-prci.o
+obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu740-prci.o
diff --git a/drivers/clk/sifive/fu740-prci.c b/drivers/clk/sifive/fu740-prci.c
new file mode 100644
index ..41ddd4431497
--- /dev/null
+++ b/drivers/clk/sifive/fu740-prci.c
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 SiFive, Inc.
+ * Copyright (C) 2020 Zong Li
+ */
+
+#include
+#include
+#include "sifive-prci.h"
+
+/* PRCI integration data for each WRPLL instance */
+
+static struct __prci_wrpll_data __prci_corepll_data = {
+ .cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+ .enable_bypass = sifive_prci_coreclksel_use_hfclk,
+ .disable_bypass = sifive_prci_coreclksel_use_final_corepll,
+};
+
+static struct __prci_wrpll_data __prci_ddrpll_data = {
+ .cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+};
+
+static struct __prci_wrpll_data __prci_gemgxlpll_data = {
+ .cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+};
+
+static struct __prci_wrpll_data __prci_dvfscorepll_data = {
+ .cfg0_offs = PRCI_DVFSCOREPLLCFG0_OFFSET,
+ .enable_bypass = sifive_prci_corepllsel_use_corepll,
+ .disable_bypass = sifive_prci_corepllsel_use_dvfscorepll,
+};
+
+static struct __prci_wrpll_data __prci_hfpclkpll_data = {
+ .cfg0_offs = PRCI_HFPCLKPLLCFG0_OFFSET,
+ .enable_bypass = sifive_prci_hfpclkpllsel_use_hfclk,
+ .disable_bypass = sifive_prci_hfpclkpllsel_use_hfpclkpll,
+};
+
+static struct __prci_wrpll_data __prci_cltxpll_data = {
+ .cfg0_offs = PRCI_CLTXPLLCFG0_OFFSET,
+};
+
+/* Linux clock framework integration */
+
+static const struct clk_ops sifive_fu740_prci_wrpll_clk_ops = {
+ .set_rate = sifive_prci_wrpll_set_rate,
+ .round_rate = sifive_prci_wrpll_round_rate,
+ .recalc_rate = sifive_prci_wrpll_recalc_rate,
+};
+
+static const struct clk_ops sifive_fu740_prci_wrpll_ro_clk_ops = {
+ .recalc_rate = sifive_prci_wrpll_recalc_rate,
+};
+
+static const struct clk_ops sifive_fu740_prci_tlclksel_clk_ops = {
+ .recalc_rate = sifive_prci_tlclksel_recalc_rate,
+};
+
+static const struct clk_ops sifive_fu740_prci_hfpclkplldiv_clk_ops = {
+ .recalc_rate = sifive_prci_hfpclkplldiv_recalc_rate,
+};
+
+/* List of clock controls provided by the PRCI */
+struct __prci_clock __prci_init_clocks_fu740[] = {
+ [PRCI_CLK_COREPLL] = {
+ .name = "corepll",
+ .parent_name = "hfclk",
+ .ops = _fu740_prci_wrpll_clk_ops,
+ .pwd = &__prci_corepll_data,
+ },
+ [PRCI_CLK_DDRPLL] = {
+ .name = "ddrpll",
+ .parent_name = "hfclk",
+ .ops = _fu740_prci_wrpll_ro_clk_ops,
+ .pwd = &__prci_ddrpll_data,
+ },
+ [PRCI_CLK_GEMGXLPLL] = {
+ .name = "gemgxlpll",
+ .parent_name = "hfclk",
+ .ops = _fu740_prci_wrpll_clk_ops,
+ .pwd =
[PATCH v6 2/5] clk: sifive: Use common name for prci configuration
Use generic name CLK_SIFIVE_PRCI instead of CLK_SIFIVE_FU540_PRCI. This patch is prepared for fu740 support. Signed-off-by: Zong Li Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Reviewed-by: Pragnesh Patel --- arch/riscv/Kconfig.socs | 2 +- drivers/clk/sifive/Kconfig | 6 +++--- drivers/clk/sifive/Makefile | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs index 8a55f6156661..3284d5c291be 100644 --- a/arch/riscv/Kconfig.socs +++ b/arch/riscv/Kconfig.socs @@ -5,7 +5,7 @@ config SOC_SIFIVE select SERIAL_SIFIVE if TTY select SERIAL_SIFIVE_CONSOLE if TTY select CLK_SIFIVE - select CLK_SIFIVE_FU540_PRCI + select CLK_SIFIVE_PRCI select SIFIVE_PLIC help This enables support for SiFive SoC platform hardware. diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig index f3b4eb9cb0f5..ab48cf7e0105 100644 --- a/drivers/clk/sifive/Kconfig +++ b/drivers/clk/sifive/Kconfig @@ -8,12 +8,12 @@ menuconfig CLK_SIFIVE if CLK_SIFIVE -config CLK_SIFIVE_FU540_PRCI - bool "PRCI driver for SiFive FU540 SoCs" +config CLK_SIFIVE_PRCI + bool "PRCI driver for SiFive SoCs" select CLK_ANALOGBITS_WRPLL_CLN28HPC help Supports the Power Reset Clock interface (PRCI) IP block found in - FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, + FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, enable this driver. endif diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile index 627effe2ece1..fe3e2cb4c4d8 100644 --- a/drivers/clk/sifive/Makefile +++ b/drivers/clk/sifive/Makefile @@ -1,4 +1,4 @@ # SPDX-License-Identifier: GPL-2.0-only obj-y += sifive-prci.o -obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o +obj-$(CONFIG_CLK_SIFIVE_PRCI) += fu540-prci.o -- 2.29.2
[PATCH v6 5/5] clk: sifive: Add clock enable and disable ops
From: Pragnesh Patel
Add new functions "sifive_prci_clock_enable(), sifive_prci_clock_disable()
and sifive_clk_is_enabled()" to enable or disable the PRCI clock
Signed-off-by: Pragnesh Patel
Tested-by: Zong Li
---
drivers/clk/sifive/fu540-prci.c | 6 +++
drivers/clk/sifive/fu740-prci.c | 9
drivers/clk/sifive/sifive-prci.c | 77
drivers/clk/sifive/sifive-prci.h | 10 +
4 files changed, 93 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index 34dc4ea6a3af..3fbee1da9701 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -33,16 +33,19 @@
static struct __prci_wrpll_data __prci_corepll_data = {
.cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_COREPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_coreclksel_use_hfclk,
.disable_bypass = sifive_prci_coreclksel_use_corepll,
};
static struct __prci_wrpll_data __prci_ddrpll_data = {
.cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_DDRPLLCFG1_OFFSET,
};
static struct __prci_wrpll_data __prci_gemgxlpll_data = {
.cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_GEMGXLPLLCFG1_OFFSET,
};
/* Linux clock framework integration */
@@ -51,6 +54,9 @@ static const struct clk_ops sifive_fu540_prci_wrpll_clk_ops =
{
.set_rate = sifive_prci_wrpll_set_rate,
.round_rate = sifive_prci_wrpll_round_rate,
.recalc_rate = sifive_prci_wrpll_recalc_rate,
+ .enable = sifive_prci_clock_enable,
+ .disable = sifive_prci_clock_disable,
+ .is_enabled = sifive_clk_is_enabled,
};
static const struct clk_ops sifive_fu540_prci_wrpll_ro_clk_ops = {
diff --git a/drivers/clk/sifive/fu740-prci.c b/drivers/clk/sifive/fu740-prci.c
index 41ddd4431497..db8300223745 100644
--- a/drivers/clk/sifive/fu740-prci.c
+++ b/drivers/clk/sifive/fu740-prci.c
@@ -12,32 +12,38 @@
static struct __prci_wrpll_data __prci_corepll_data = {
.cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_COREPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_coreclksel_use_hfclk,
.disable_bypass = sifive_prci_coreclksel_use_final_corepll,
};
static struct __prci_wrpll_data __prci_ddrpll_data = {
.cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_DDRPLLCFG1_OFFSET,
};
static struct __prci_wrpll_data __prci_gemgxlpll_data = {
.cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_GEMGXLPLLCFG1_OFFSET,
};
static struct __prci_wrpll_data __prci_dvfscorepll_data = {
.cfg0_offs = PRCI_DVFSCOREPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_DVFSCOREPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_corepllsel_use_corepll,
.disable_bypass = sifive_prci_corepllsel_use_dvfscorepll,
};
static struct __prci_wrpll_data __prci_hfpclkpll_data = {
.cfg0_offs = PRCI_HFPCLKPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_HFPCLKPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_hfpclkpllsel_use_hfclk,
.disable_bypass = sifive_prci_hfpclkpllsel_use_hfpclkpll,
};
static struct __prci_wrpll_data __prci_cltxpll_data = {
.cfg0_offs = PRCI_CLTXPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_CLTXPLLCFG1_OFFSET,
};
/* Linux clock framework integration */
@@ -46,6 +52,9 @@ static const struct clk_ops sifive_fu740_prci_wrpll_clk_ops =
{
.set_rate = sifive_prci_wrpll_set_rate,
.round_rate = sifive_prci_wrpll_round_rate,
.recalc_rate = sifive_prci_wrpll_recalc_rate,
+ .enable = sifive_prci_clock_enable,
+ .disable = sifive_prci_clock_disable,
+ .is_enabled = sifive_clk_is_enabled,
};
static const struct clk_ops sifive_fu740_prci_wrpll_ro_clk_ops = {
diff --git a/drivers/clk/sifive/sifive-prci.c b/drivers/clk/sifive/sifive-prci.c
index f4bab45509b3..4698dba0ac86 100644
--- a/drivers/clk/sifive/sifive-prci.c
+++ b/drivers/clk/sifive/sifive-prci.c
@@ -113,7 +113,7 @@ static u32 __prci_wrpll_pack(const struct wrpll_cfg *c)
}
/**
- * __prci_wrpll_read_cfg() - read the WRPLL configuration from the PRCI
+ * __prci_wrpll_read_cfg0() - read the WRPLL configuration from the PRCI
* @pd: PRCI context
* @pwd: PRCI WRPLL metadata
*
@@ -124,14 +124,14 @@ static u32 __prci_wrpll_pack(const struct wrpll_cfg *c)
* Context: Any context. Caller must prevent the records pointed to by
* @pd and @pwd from changing during execution.
*/
-static void __prci_wrpll_read_cfg(struct __prci_data *pd,
- struct __prci_wrpll_data *pwd)
+static void __prci_wrpll_read_cfg0(struct __prci_data *pd,
+ struct __prci_wrpll_data *pwd)
{
__prci_wrpll_unpack(>c, __prci_readl(pd, pwd->cfg0_offs));
}
/**
- * __prci_wrpll_write_cfg() - write WRPLL configuration into the PRCI
+ * __prci_wrpll_write_cfg0() - write WRPLL configuration into the PRCI
* @pd: PRCI
[PATCH v6 0/5] clk: add driver for the SiFive FU740
Add a driver for the SiFive FU740 PRCI IP block, which handles more clocks than FU540. These patches also refactor the original implementation by spliting the dependent-code of fu540 and fu740 respectively. We also add a separate patch for DT binding documentation of FU740 PRCI: https://patchwork.kernel.org/project/linux-riscv/patch/20201126030043.67390-1-zong...@sifive.com/ Changed in v6: - Modify the patch "Add clock enable and disable ops" by Pragnesh. The changes as follows: - Remove spin lock in enable and disable functions - Call enable_bypass() before PLL output disable Changed in v5: - Fix copyright format - Add a link of documentation in commit message - Modify build dependency for sifive-prci.c - Add enable and disable functions by Pragnesh Patel Changed in v4: - Fix the wrong enable bit field shift for FU540 and FU740. Changed in v3: - Fix the wrong enable bit field shift for FU740. Changed in v2: - Remove the macro definition for __prci_clock_array. - Indicate the functional changes in commit message. - Using option -M and -C to create patches. - Rebase code to kernel v5.10-rc3. Pragnesh Patel (1): clk: sifive: Add clock enable and disable ops Zong Li (4): clk: sifive: Extract prci core to common base clk: sifive: Use common name for prci configuration clk: sifive: Add a driver for the SiFive FU740 PRCI IP block clk: sifive: Fix the wrong bit field shift arch/riscv/Kconfig.socs | 2 +- drivers/clk/sifive/Kconfig| 8 +- drivers/clk/sifive/Makefile | 5 +- drivers/clk/sifive/fu540-prci.c | 585 +- drivers/clk/sifive/fu540-prci.h | 21 + drivers/clk/sifive/fu740-prci.c | 120 drivers/clk/sifive/fu740-prci.h | 21 + drivers/clk/sifive/sifive-prci.c | 571 + drivers/clk/sifive/sifive-prci.h | 299 + include/dt-bindings/clock/sifive-fu740-prci.h | 23 + 10 files changed, 1089 insertions(+), 566 deletions(-) create mode 100644 drivers/clk/sifive/fu540-prci.h create mode 100644 drivers/clk/sifive/fu740-prci.c create mode 100644 drivers/clk/sifive/fu740-prci.h create mode 100644 drivers/clk/sifive/sifive-prci.c create mode 100644 drivers/clk/sifive/sifive-prci.h create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h -- 2.29.2
[PATCH v6 1/5] clk: sifive: Extract prci core to common base
Extract common core of prci driver to an independent file, it could
allow other chips to reuse it. Separate SoCs-dependent code 'fu540'
from prci core, then we can easily add 'fu740' later.
Almost these changes are code movement. The different is adding the
private data for each SoC use, so it needs to get match data in probe
callback function, then use the data for initialization.
Signed-off-by: Zong Li
Reviewed-by: Pragnesh Patel
Acked-by: Palmer Dabbelt
---
drivers/clk/sifive/Makefile | 2 +
drivers/clk/sifive/fu540-prci.c | 579 +-
drivers/clk/sifive/fu540-prci.h | 21 +
.../sifive/{fu540-prci.c => sifive-prci.c}| 396 +++-
drivers/clk/sifive/sifive-prci.h | 201 ++
5 files changed, 322 insertions(+), 877 deletions(-)
create mode 100644 drivers/clk/sifive/fu540-prci.h
copy drivers/clk/sifive/{fu540-prci.c => sifive-prci.c} (41%)
create mode 100644 drivers/clk/sifive/sifive-prci.h
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index 0797f14fef6b..627effe2ece1 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,2 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-y += sifive-prci.o
+
obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index a8901f90a61a..34dc4ea6a3af 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -3,6 +3,7 @@
* Copyright (C) 2018-2019 SiFive, Inc.
* Wesley Terpstra
* Paul Walmsley
+ * Zong Li
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -25,463 +26,43 @@
*/
#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
+#include "sifive-prci.h"
-/*
- * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
- * hfclk and rtcclk
- */
-#define EXPECTED_CLK_PARENT_COUNT 2
-
-/*
- * Register offsets and bitmasks
- */
-
-/* COREPLLCFG0 */
-#define PRCI_COREPLLCFG0_OFFSET0x4
-# define PRCI_COREPLLCFG0_DIVR_SHIFT 0
-# define PRCI_COREPLLCFG0_DIVR_MASK(0x3f <<
PRCI_COREPLLCFG0_DIVR_SHIFT)
-# define PRCI_COREPLLCFG0_DIVF_SHIFT 6
-# define PRCI_COREPLLCFG0_DIVF_MASK(0x1ff <<
PRCI_COREPLLCFG0_DIVF_SHIFT)
-# define PRCI_COREPLLCFG0_DIVQ_SHIFT 15
-# define PRCI_COREPLLCFG0_DIVQ_MASK(0x7 <<
PRCI_COREPLLCFG0_DIVQ_SHIFT)
-# define PRCI_COREPLLCFG0_RANGE_SHIFT 18
-# define PRCI_COREPLLCFG0_RANGE_MASK (0x7 <<
PRCI_COREPLLCFG0_RANGE_SHIFT)
-# define PRCI_COREPLLCFG0_BYPASS_SHIFT 24
-# define PRCI_COREPLLCFG0_BYPASS_MASK (0x1 <<
PRCI_COREPLLCFG0_BYPASS_SHIFT)
-# define PRCI_COREPLLCFG0_FSE_SHIFT25
-# define PRCI_COREPLLCFG0_FSE_MASK (0x1 <<
PRCI_COREPLLCFG0_FSE_SHIFT)
-# define PRCI_COREPLLCFG0_LOCK_SHIFT 31
-# define PRCI_COREPLLCFG0_LOCK_MASK(0x1 <<
PRCI_COREPLLCFG0_LOCK_SHIFT)
-
-/* DDRPLLCFG0 */
-#define PRCI_DDRPLLCFG0_OFFSET 0xc
-# define PRCI_DDRPLLCFG0_DIVR_SHIFT0
-# define PRCI_DDRPLLCFG0_DIVR_MASK (0x3f <<
PRCI_DDRPLLCFG0_DIVR_SHIFT)
-# define PRCI_DDRPLLCFG0_DIVF_SHIFT6
-# define PRCI_DDRPLLCFG0_DIVF_MASK (0x1ff <<
PRCI_DDRPLLCFG0_DIVF_SHIFT)
-# define PRCI_DDRPLLCFG0_DIVQ_SHIFT15
-# define PRCI_DDRPLLCFG0_DIVQ_MASK (0x7 <<
PRCI_DDRPLLCFG0_DIVQ_SHIFT)
-# define PRCI_DDRPLLCFG0_RANGE_SHIFT 18
-# define PRCI_DDRPLLCFG0_RANGE_MASK(0x7 <<
PRCI_DDRPLLCFG0_RANGE_SHIFT)
-# define PRCI_DDRPLLCFG0_BYPASS_SHIFT 24
-# define PRCI_DDRPLLCFG0_BYPASS_MASK (0x1 <<
PRCI_DDRPLLCFG0_BYPASS_SHIFT)
-# define PRCI_DDRPLLCFG0_FSE_SHIFT 25
-# define PRCI_DDRPLLCFG0_FSE_MASK (0x1 <<
PRCI_DDRPLLCFG0_FSE_SHIFT)
-# define PRCI_DDRPLLCFG0_LOCK_SHIFT31
-# define PRCI_DDRPLLCFG0_LOCK_MASK (0x1 <<
PRCI_DDRPLLCFG0_LOCK_SHIFT)
-
-/* DDRPLLCFG1 */
-#define PRCI_DDRPLLCFG1_OFFSET 0x10
-# define PRCI_DDRPLLCFG1_CKE_SHIFT 24
-# define PRCI_DDRPLLCFG1_CKE_MASK (0x1 <<
PRCI_DDRPLLCFG1_CKE_SHIFT)
-
-/* GEMGXLPLLCFG0 */
-#define PRCI_GEMGXLPLLCFG0_OFFSET 0x1c
-# define PRCI_GEMGXLPLLCFG0_DIVR_SHIFT 0
-# define PRCI_GEMGXLPLLCFG0_DIVR_MASK (0x3f <<
PRCI_GEMGXLPLLCFG0_DIVR_SHIFT)
-# define PRCI_GEMGXLPLLCFG0_DIVF_SHIFT 6
-# define PRCI_GEMGXLPLLCFG0_DIVF_MASK (0x1ff <<
PRCI_GEMGXLPLLCFG0_DIVF_SHIFT)
-# define PRCI_GEMGXLPLLCFG0_DIVQ_SHIFT 15
-# define PRCI_GEMGXLPLLCFG0_DIVQ_MASK (0x7 <<
PRCI_GEMGXLPLLCFG0_DIVQ_SHIFT)
-# define PRCI_GEMGXLPLLCFG0_RANGE_SHIFT18
-#
Re: [PATCH v2 1/3] scsi: ufs: Add "wb_on" sysfs node to control WB on/off
On 2020-12-06 18:13, Bean Huo wrote:
From: Bean Huo
Currently UFS WriteBooster driver uses clock scaling up/down to set
WB on/off, for the platform which doesn't support
UFSHCD_CAP_CLK_SCALING,
WB will be always on. Provide a sysfs attribute to enable/disable WB
during runtime. Write 1/0 to "wb_on" sysfs node to enable/disable UFS
WB.
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufs-sysfs.c | 40
drivers/scsi/ufs/ufshcd.c| 3 +--
drivers/scsi/ufs/ufshcd.h| 2 ++
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c
b/drivers/scsi/ufs/ufs-sysfs.c
index 08e72b7eef6a..b3bf7fca00e5 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -189,6 +189,44 @@ static ssize_t auto_hibern8_store(struct device
*dev,
return count;
}
+static ssize_t wb_on_show(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct ufs_hba *hba = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", hba->wb_enabled);
+}
+
+static ssize_t wb_on_store(struct device *dev, struct device_attribute
*attr,
+ const char *buf, size_t count)
+{
+ struct ufs_hba *hba = dev_get_drvdata(dev);
+ unsigned int wb_enable;
+ ssize_t res;
+
+ if (ufshcd_is_clkscaling_supported(hba)) {
+ /* If the platform supports UFSHCD_CAP_AUTO_BKOPS_SUSPEND, turn
+* WB on/off will be done while clock scaling up/down.
+*/
Double check comment line format?
+ dev_warn(dev, "To control WB through wb_on is not allowed!\n");
+ return -EOPNOTSUPP;
+ }
+ if (!ufshcd_is_wb_allowed(hba))
+ return -EOPNOTSUPP;
+
+ if (kstrtouint(buf, 0, _enable))
+ return -EINVAL;
+
+ if (wb_enable != 0 && wb_enable != 1)
+ return -EINVAL;
+
+ pm_runtime_get_sync(hba->dev);
+ res = ufshcd_wb_ctrl(hba, wb_enable);
+ pm_runtime_put_sync(hba->dev);
+
+ return res < 0 ? res : count;
+}
+
static DEVICE_ATTR_RW(rpm_lvl);
static DEVICE_ATTR_RO(rpm_target_dev_state);
static DEVICE_ATTR_RO(rpm_target_link_state);
@@ -196,6 +234,7 @@ static DEVICE_ATTR_RW(spm_lvl);
static DEVICE_ATTR_RO(spm_target_dev_state);
static DEVICE_ATTR_RO(spm_target_link_state);
static DEVICE_ATTR_RW(auto_hibern8);
+static DEVICE_ATTR_RW(wb_on);
static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
_attr_rpm_lvl.attr,
@@ -205,6 +244,7 @@ static struct attribute *ufs_sysfs_ufshcd_attrs[] =
{
_attr_spm_target_dev_state.attr,
_attr_spm_target_link_state.attr,
_attr_auto_hibern8.attr,
+ _attr_wb_on.attr,
NULL
};
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 92d433d5f3ca..30332592e624 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -247,7 +247,6 @@ static inline int ufshcd_config_vreg_hpm(struct
ufs_hba *hba,
static int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag);
static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
-static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
static int ufshcd_wb_toggle_flush_during_h8(struct ufs_hba *hba, bool
set);
static inline void ufshcd_wb_toggle_flush(struct ufs_hba *hba, bool
enable);
static void ufshcd_hba_vreg_set_lpm(struct ufs_hba *hba);
@@ -5307,7 +5306,7 @@ static void
ufshcd_bkops_exception_event_handler(struct ufs_hba *hba)
__func__, err);
}
-static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
+int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
{
int ret;
u8 index;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 61344c49c2cc..c61584dff74a 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -1068,6 +1068,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
u8 *desc_buff, int *buff_len,
enum query_opcode desc_op);
+int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
+
/* Wrapper functions for safely calling variant operations */
static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
{
Re: [PATCH v3 5/6] media: uvcvideo: Use dma_alloc_noncontiguos API
On (20/12/08 13:54), Tomasz Figa wrote: > > In any case, Sergey is going to share a preliminary patch on how the > current API would be used in the V4L2 videobuf2 framework. That should > give us more input on how such a helper could look. HUGE apologies for the previous screw up! I replied in the gmail web-interface and that did not work out as expected (at all, big times). I'm sorry about that! Take two, no html this time around. --- My current WIP (deep WIP) series can be found at [0]. The patch that adds new DMA API support is at the head of the series [1]. New DMA API requires us to have several internal videobuf2 API changes before we can proceed [2]: v4l2 and videobuf2 core do not pass enough information to the vb2 allocators now. Previously, if user space requests non-coherent allocation v4l2 would set queue dma_attr bit, videobuf2 core would pass queue->dma_attrs to vb2 allocator, which would those dma_attrs for dma_alloc(). So everything was transparent (sort of). Since we don't have that dma_attr flag anymore, there is no way for v4l2 to pass the request information (coherent or non-coherent) to the vb2 allocator. Hence we need to rework the vb2 allocator API. I currently pass vb2 pointer, but we decided to rework it again and to pass dedicated VB2_ALLOC_FLAGS from the videobuf2 core to the allocator. This is still in my private tree and not completely ready, will push those patches to github later. Another thing to notice is that the new API requires us to have two execution branches in allocators - one for the current API; and one for the new API (if it's supported and if user-space requested non-coherent allocation). [0] https://github.com/sergey-senozhatsky/linux-next-ss/commits/master [1] https://github.com/sergey-senozhatsky/linux-next-ss/commit/a45f48b483daee59594c62e4aaf01790aab960c8 [2] https://github.com/sergey-senozhatsky/linux-next-ss/commit/b784145101c398da7fe9e2608b6001e58e05a9b5 -ss
Re: [PATCH v4 1/4] dt-bindings/opp: Update documentation for opp-shared
Hi Viresh, thanks for your comments. I will update subject and content as you suggested. Regards, Nicola On 12/8/20 4:29 AM, Viresh Kumar wrote: > Subject should rather be: > > dt-bindings: opp: Allow empty OPP tables > > On 02-12-20, 17:23, Nicola Mazzucato wrote: >> Currently the optional property opp-shared is used within an opp table >> to tell that a set of devices share their clock/voltage lines (and the >> opp points). >> It is therefore possible to use an empty opp table to convey only that >> information, useful in situations where the opp points are provided via >> other means (hardware. firmware, etc). >> >> Update the documentation to remark this additional case and provide an >> example. >> >> Signed-off-by: Nicola Mazzucato >> --- >> Documentation/devicetree/bindings/opp/opp.txt | 53 +++ >> 1 file changed, 53 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/opp/opp.txt >> b/Documentation/devicetree/bindings/opp/opp.txt >> index 9847dfeeffcb..a5f1f993eab9 100644 >> --- a/Documentation/devicetree/bindings/opp/opp.txt >> +++ b/Documentation/devicetree/bindings/opp/opp.txt >> @@ -72,6 +72,9 @@ Optional properties: >>switch their DVFS state together, i.e. they share clock/voltage/current >> lines. >>Missing property means devices have independent clock/voltage/current >> lines, >>but they share OPP tables. >> + This optional property can be used without any OPP nodes when its only >> purpose >> + is to describe a dependency of clock/voltage/current lines among a set of >> + devices. > > And instead of this, we should rather update "OPP nodes:" section like > this: > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > b/Documentation/devicetree/bindings/opp/opp.txt > index 9847dfeeffcb..28077ce3a845 100644 > --- a/Documentation/devicetree/bindings/opp/opp.txt > +++ b/Documentation/devicetree/bindings/opp/opp.txt > @@ -63,11 +63,13 @@ This describes the OPPs belonging to a device. This node > can have following > - compatible: Allow OPPs to express their compatibility. It should be: >"operating-points-v2". > > +Optional properties: > - OPP nodes: One or more OPP nodes describing voltage-current-frequency >combinations. Their name isn't significant but their phandle can be used to > - reference an OPP. > + reference an OPP. These are mandatory except for the case where the OPP > table > + is present only to indicate dependency between devices using the opp-shared > + property. > > -Optional properties: > - opp-shared: Indicates that device nodes using this OPP Table Node's phandle >switch their DVFS state together, i.e. they share clock/voltage/current > lines. >Missing property means devices have independent clock/voltage/current > lines, >
[PATCH] media: vidtv: fix some warnings
As reported by sparse:
drivers/media/test-drivers/vidtv/vidtv_ts.h:47:47: warning: array of
flexible structures
drivers/media/test-drivers/vidtv/vidtv_channel.c:458:54: warning:
incorrect type in argument 3 (different base types)
drivers/media/test-drivers/vidtv/vidtv_channel.c:458:54:expected
unsigned short [usertype] service_id
drivers/media/test-drivers/vidtv/vidtv_channel.c:458:54:got
restricted __be16 [usertype] service_id
drivers/media/test-drivers/vidtv/vidtv_s302m.c:471
vidtv_s302m_encoder_init() warn: possible memory leak of 'e'
Address such warnings.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/test-drivers/vidtv/vidtv_psi.h | 2 +-
drivers/media/test-drivers/vidtv/vidtv_s302m.c | 4 +++-
drivers/media/test-drivers/vidtv/vidtv_ts.h| 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.h
b/drivers/media/test-drivers/vidtv/vidtv_psi.h
index 340c9fb8d583..d9c71f88ab9e 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_psi.h
+++ b/drivers/media/test-drivers/vidtv/vidtv_psi.h
@@ -743,7 +743,7 @@ struct vidtv_psi_table_eit {
struct vidtv_psi_table_eit
*vidtv_psi_eit_table_init(u16 network_id,
u16 transport_stream_id,
- u16 service_id);
+ __be16 service_id);
/**
* struct vidtv_psi_eit_write_args - Arguments for writing an EIT section
diff --git a/drivers/media/test-drivers/vidtv/vidtv_s302m.c
b/drivers/media/test-drivers/vidtv/vidtv_s302m.c
index ce7dd6cafc8b..d79b65854627 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_s302m.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_s302m.c
@@ -467,8 +467,10 @@ struct vidtv_encoder
e->is_video_encoder = false;
ctx = kzalloc(priv_sz, GFP_KERNEL);
- if (!ctx)
+ if (!ctx) {
+ kfree(e);
return NULL;
+ }
e->ctx = ctx;
ctx->last_duration = 0;
diff --git a/drivers/media/test-drivers/vidtv/vidtv_ts.h
b/drivers/media/test-drivers/vidtv/vidtv_ts.h
index 10838a2b8389..f5e8e1f37f05 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_ts.h
+++ b/drivers/media/test-drivers/vidtv/vidtv_ts.h
@@ -44,7 +44,7 @@ struct vidtv_mpeg_ts {
u8 adaptation_field:1;
u8 scrambling:2;
} __packed;
- struct vidtv_mpeg_ts_adaption adaption[];
+ struct vidtv_mpeg_ts_adaption *adaption;
} __packed;
/**
--
2.28.0
Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On 08.12.20 03:36, Jason Wang wrote: Hi, > So we endup with two solutions (without a prompt): > > 1) using select, user may end up with driver without transport IMHO not an entirely unusual situation in other places of the kernel, eg. one can enable USB devices, w/o having an usb host adapter enabled. And even if some USB-HA driver is enabled, the actualy machine doesn't necessarily have the corresponding device. > 2) using depends, user need to enable at least one transport > > 2) looks a little bit better I admit. So, all virtio devices should depend on TRANSPORT_A || TRANSPORT_B || TRANSPORT_C || ... ? (and also change all these places if another transport is added) ? --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings
On Mon, Dec 7, 2020 at 7:12 PM Robin Murphy wrote:
>
> On 2020-12-02 10:29, Laurentiu Tudor wrote:
> > Hi Robin,
> >
> > Sorry for the late reply, we had a few days of over here. Comments inline.
> >
> > On 11/25/2020 8:10 PM, Robin Murphy wrote:
> >> On 2020-11-25 15:50, laurentiu.tu...@nxp.com wrote:
> >>> From: Laurentiu Tudor
> >>>
> >>> Add a NXP specific hook to preserve SMMU mappings present at
> >>> boot time (created by the boot loader). These are needed for
> >>> MC firmware present on some NXP chips to continue working
> >>> across kernel boot and SMMU initialization.
> >>>
> >>> Signed-off-by: Laurentiu Tudor
> >>> ---
> >>>drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 33 ++
> >>>1 file changed, 33 insertions(+)
> >>>
> >>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> >>> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> >>> index 7fed89c9d18a..ca07d9d4be69 100644
> >>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> >>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
> >>> @@ -187,6 +187,36 @@ static const struct arm_smmu_impl
> >>> mrvl_mmu500_impl = {
> >>>.reset = arm_mmu500_reset,
> >>>};
> >>>+static int nxp_cfg_probe(struct arm_smmu_device *smmu)
> >>> +{
> >>> +int i, cnt = 0;
> >>> +u32 smr;
> >>> +
> >>> +for (i = 0; i < smmu->num_mapping_groups; i++) {
> >>> +smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
> >>> +
> >>> +if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
> >>
> >> I bet this is fun over kexec...
> >
> > Right. I haven't even considered kexec.
> >
> >> Note that the Qualcomm special case got a bit of a free pass since it
> >> involves working around a totally broken hypervisor, plus gets to play
> >> the "nobody sane will run an enterprise distro on their phone" card to
> >> an extent; I don't think the likes of Layerscape kit get it quite so
> >> easy ;)
> >
> > I agree that this is not ideal, but the plan here was to have something
> > to boot vanilla kernel OOB on our chips, which is something on my mind
> > for quite a while now. I do realize that we won't get away with it
> > in the long run.
> >
> >>> +smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
> >>> +smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
> >>> +smmu->smrs[i].valid = true;
> >>> +
> >>> +smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
> >>> +smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
> >>> +smmu->s2crs[i].cbndx = 0xff;
> >>> +
> >>> +cnt++;
> >>> +}
> >>> +}
> >>> +
> >>> +dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt,
> >>> + cnt == 1 ? "" : "s");
> >>
> >> That gets you around the initial SMMU reset, but what happens for the
> >> arbitrarily long period of time between the MC device getting attached
> >> to a default domain and the MC driver actually probing and (presumably)
> >> being able to map and reinitialise its firmware?
> >
> > Perhaps I'm missing something, but won't the MC firmware live based on
> > this bypass mapping created by the bootloader and that gets preserved?
>
> All you're doing here is effectively forcing "arm-smmu.disable_bypass=0"
> for the specific streams identified by the boot-time SMR state. Once
> iommu_probe_device() gets called and the SMMU driver becomes aware of
> those streams, that initial state becomes moot.
>
> What I just now realise, however, is that in this specific case you
> probably do get away with it as a dirty trick because there is no
> visible association between the MC *platform device* and the SMMU. Thus
> as it stands today, nobody will be calling iommu_probe_device() for any
> of the relevant streams until the MC driver has probed and can start
> creating the fsl_mc_bus devices and interpreting the iommu-map -
> presumably by that point the platform driver has had plenty of time to
> quiesce DMA and grovel the physical address of the firmware region out
> of the hardware, such that it can then be remapped from the perspective
> of the new fsl_mc_bus device to continue.
>
> >>> +
> >>> +return 0;
> >>> +}
> >>> +
> >>> +static const struct arm_smmu_impl nxp_impl = {
> >>> +.cfg_probe = nxp_cfg_probe,
> >>> +};
> >>
> >> I believe you're mostly using MMU-500, so you probably don't want to
> >> simply throw out the relevant errata workarounds.
> >>
> >>>struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device
> >>> *smmu)
> >>>{
> >>> @@ -226,5 +256,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
> >>> arm_smmu_device *smmu)
> >>>if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
> >>>smmu->impl = _mmu500_impl;
> >>>+if (of_property_read_bool(np, "nxp,keep-boot-mappings"))
> >>> +smmu->impl = _impl;
> >>
> >> Normally you'd get a "what about ACPI?" here, but given the number of
> >> calls and email threads we've had specifically about trying to make ACPI
> >>
RE: [PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and merge exynos-asv
> -Original Message- > From: Krzysztof Kozlowski > Sent: Tuesday, December 8, 2020 12:35 AM > To: Krzysztof Kozlowski ; linux-arm- > ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: Sylwester Nawrocki ; Marek Szyprowski > ; Bartlomiej Zolnierkiewicz > ; Arnd Bergmann ; Chanwoo > Choi ; Alim Akhtar ; > Pankaj Dubey > Subject: [PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and > merge exynos-asv > > The Exynos Chip ID driver on Exynos SoCs has so far only informational > purpose - to expose the SoC device in sysfs. No other drivers depend on it > so there is really no benefit of initializing it early. > One of the intention behind initializing Exynos Chip ID driver in early stage was to simplify code in arch/arm/mach-exynos specifically calls such as soc_is_exynos. But there were lot of resistance from community to add any such calls (or exported function) from mach-exynos files to the driver file. Whereas some other SoC code is using the same, e.g. tegra_get_chip_id being called from mach-tegra files to drivers/soc/tegra/. Unfortunately we could not accept similar solution for Exynos SoC and hence could not get rid of soc_is_exynosxXXX and similar macros from various file in mach-exynos and eventually converting those files into a full-fledged driver files. Any opinion how can we achieve this if we convert Exynos Chip ID driver to a regular driver? Thanks, Pankaj Dubey > The code would be the most flexible if converted to a regular driver. > However there is already another driver - Exynos ASV (Adaptive Supply > Voltage) - which binds to the device node of Chip ID. > > The solution is to convert the Exynos Chip ID to a built in driver and merge > the Exynos ASV into it. > > This has several benefits: > 1. Although the Exynos ASV driver binds to a device node present in all >Exynos DTS (generic compatible), it fails to probe except on the >supported ones (only Exynos5422). This means that the regular boot >process has a planned/expected device probe failure. > >Merging the ASV into Chip ID will remove this probe failure because >the final driver will always bind, just with disabled ASV features. > > 2. Allows to use dev_info() as the SoC bus is present (since >core_initcall). > > 3. Could speed things up because of execution of Chip ID code in a SMP >environment (after bringing up secondary CPUs, unlike early_initcall), >This reduces the amount of work to be done early, when the kernel has >to bring up critical devices. > > 5. Makes the Chip ID code defer-probe friendly, > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/mach-exynos/Kconfig| 1 - > drivers/soc/samsung/Kconfig | 12 ++--- > drivers/soc/samsung/Makefile| 3 +- > drivers/soc/samsung/exynos-asv.c| 45 + > drivers/soc/samsung/exynos-asv.h| 2 + > drivers/soc/samsung/exynos-chipid.c | 75 - > 6 files changed, 70 insertions(+), 68 deletions(-) > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach- > exynos/Kconfig index 56d272967fc0..5a48abac6af4 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -13,7 +13,6 @@ menuconfig ARCH_EXYNOS > select ARM_GIC > select EXYNOS_IRQ_COMBINER > select COMMON_CLK_SAMSUNG > - select EXYNOS_ASV > select EXYNOS_CHIPID > select EXYNOS_THERMAL > select EXYNOS_PMU > diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig > index fc7f48a92288..5745d7e5908e 100644 > --- a/drivers/soc/samsung/Kconfig > +++ b/drivers/soc/samsung/Kconfig > @@ -7,21 +7,19 @@ menuconfig SOC_SAMSUNG > > if SOC_SAMSUNG > > -config EXYNOS_ASV > - bool "Exynos Adaptive Supply Voltage support" if COMPILE_TEST > - depends on (ARCH_EXYNOS && EXYNOS_CHIPID) || COMPILE_TEST > - select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS > - > # There is no need to enable these drivers for ARMv8 config > EXYNOS_ASV_ARM > bool "Exynos ASV ARMv7-specific driver extensions" if > COMPILE_TEST > - depends on EXYNOS_ASV > + depends on EXYNOS_CHIPID > > config EXYNOS_CHIPID > - bool "Exynos Chipid controller driver" if COMPILE_TEST > + bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST > depends on ARCH_EXYNOS || COMPILE_TEST > + select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS > select MFD_SYSCON > select SOC_BUS > + help > + Support for Samsung Exynos SoC ChipID and Adaptive Supply > Voltage. > > config EXYNOS_PMU > bool "Exynos PMU controller driver" if COMPILE_TEST diff --git > a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile index > 59e8e9453f27..0c523a8de4eb 100644 > --- a/drivers/soc/samsung/Makefile > +++ b/drivers/soc/samsung/Makefile > @@ -1,9 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > > -obj-$(CONFIG_EXYNOS_ASV) += exynos-asv.o >
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
On Tue, Dec 01, 2020 at 11:44:10PM +0900, Kuniyuki Iwashima wrote:
> @@ -242,8 +244,12 @@ void reuseport_detach_sock(struct sock *sk)
>
> reuse->num_socks--;
> reuse->socks[i] = reuse->socks[reuse->num_socks];
> + prog = rcu_dereference(reuse->prog);
>
> if (sk->sk_protocol == IPPROTO_TCP) {
> + if (reuse->num_socks && !prog)
> + nsk = i == reuse->num_socks ? reuse->socks[i -
> 1] : reuse->socks[i];
I asked in the earlier thread if the primary use case is to only
use the bpf prog to pick. That thread did not come to
a solid answer but did conclude that the sysctl should not
control the behavior of the BPF_SK_REUSEPORT_SELECT_OR_MIGRATE prog.
>From this change here, it seems it is still desired to only depend
on the kernel to random pick even when no bpf prog is attached.
If that is the case, a sysctl to guard here for not changing
the current behavior makes sense.
It should still only control the non-bpf-pick behavior:
when the sysctl is on, the kernel will still do a random pick
when there is no bpf prog attached to the reuseport group.
Thoughts?
> +
> reuse->num_closed_socks++;
> reuse->socks[reuse->max_socks -
> reuse->num_closed_socks] = sk;
> } else {
> @@ -264,6 +270,8 @@ void reuseport_detach_sock(struct sock *sk)
> call_rcu(>rcu, reuseport_free_rcu);
> out:
> spin_unlock_bh(_lock);
> +
> + return nsk;
> }
> EXPORT_SYMBOL(reuseport_detach_sock);
[PATCH v2 5/5] clk: qcom: gcc: Add clock driver for SM8350
From: Vivek Aknurwar
This adds Global Clock controller (GCC) driver for SM8350 SoC
Signed-off-by: Vivek Aknurwar
Signed-off-by: Jeevan Shriram
[vkoul: rebase and tidy up for upstream]
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/Kconfig |9 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-sm8350.c | 3996 +
3 files changed, 4006 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-sm8350.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 3a965bd326d5..5015dd9332cd 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -437,6 +437,15 @@ config SM_GCC_8250
Say Y if you want to use peripheral devices such as UART,
SPI, I2C, USB, SD/UFS, PCIe etc.
+config SM_GCC_8350
+ tristate "SM8350 Global Clock Controller"
+ select QCOM_GDSC
+ help
+ Support for the global clock controller on SM8350 devices.
+ Say Y if you want to use peripheral devices such as UART,
+ SPI, I2C, USB, SD/UFS, PCIe etc.
+
+
config SM_GPUCC_8150
tristate "SM8150 Graphics Clock Controller"
select SM_GCC_8150
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 11ae86febe87..915794872e38 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
obj-$(CONFIG_SM_DISPCC_8250) += dispcc-sm8250.o
obj-$(CONFIG_SM_GCC_8150) += gcc-sm8150.o
obj-$(CONFIG_SM_GCC_8250) += gcc-sm8250.o
+obj-$(CONFIG_SM_GCC_8350) += gcc-sm8350.o
obj-$(CONFIG_SM_GPUCC_8150) += gpucc-sm8150.o
obj-$(CONFIG_SM_GPUCC_8250) += gpucc-sm8250.o
obj-$(CONFIG_SM_VIDEOCC_8150) += videocc-sm8150.o
diff --git a/drivers/clk/qcom/gcc-sm8350.c b/drivers/clk/qcom/gcc-sm8350.c
new file mode 100644
index ..94ee9ef563af
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sm8350.c
@@ -0,0 +1,3996 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020 Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "common.h"
+#include "reset.h"
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_GCC_GPLL0_OUT_EVEN,
+ P_GCC_GPLL0_OUT_MAIN,
+ P_GCC_GPLL4_OUT_MAIN,
+ P_GCC_GPLL9_OUT_MAIN,
+ P_PCIE_0_PIPE_CLK,
+ P_PCIE_1_PIPE_CLK,
+ P_SLEEP_CLK,
+ P_UFS_CARD_RX_SYMBOL_0_CLK,
+ P_UFS_CARD_RX_SYMBOL_1_CLK,
+ P_UFS_CARD_TX_SYMBOL_0_CLK,
+ P_UFS_PHY_RX_SYMBOL_0_CLK,
+ P_UFS_PHY_RX_SYMBOL_1_CLK,
+ P_UFS_PHY_TX_SYMBOL_0_CLK,
+ P_USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK,
+ P_USB3_UNI_PHY_SEC_GCC_USB30_PIPE_CLK,
+};
+
+static struct clk_alpha_pll gcc_gpll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr = {
+ .enable_reg = 0x52018,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_gpll0",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_lucid_5lpe_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_gcc_gpll0_out_even[] = {
+ { 0x1, 2 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv gcc_gpll0_out_even = {
+ .offset = 0x0,
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_gcc_gpll0_out_even,
+ .num_post_div = ARRAY_SIZE(post_div_table_gcc_gpll0_out_even),
+ .width = 4,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gcc_gpll0_out_even",
+ .parent_data = &(const struct clk_parent_data){
+ .hw = _gpll0.clkr.hw,
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_postdiv_lucid_5lpe_ops,
+ },
+};
+
+static struct clk_alpha_pll gcc_gpll4 = {
+ .offset = 0x76000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr = {
+ .enable_reg = 0x52018,
+ .enable_mask = BIT(4),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_gpll4",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ .name = "bi_tcxo",
+ },
+ .num_parents = 1,
+
[PATCH v2 4/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
From: Vivek Aknurwar
Lucid 5LPE is a slightly different Lucid PLL with different offsets and
porgramming sequence so add support for these
Signed-off-by: Vivek Aknurwar
Signed-off-by: Jeevan Shriram
[vkoul: rebase and tidy up for upstream]
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/clk-alpha-pll.c | 223 +++
drivers/clk/qcom/clk-alpha-pll.h | 4 +
2 files changed, 227 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 564431130a76..6a399663d564 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -146,6 +146,12 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
/* LUCID PLL specific settings and offsets */
#define LUCID_PCAL_DONEBIT(27)
+/* LUCID 5LPE PLL specific settings and offsets */
+#define LUCID_5LPE_PCAL_DONE BIT(11)
+#define LUCID_5LPE_ENABLE_VOTE_RUN BIT(21)
+#define LUCID_5LPE_PLL_LATCH_INPUT BIT(14)
+#define LUCID_5LPE_ALPHA_PLL_ACK_LATCH BIT(13)
+
#define pll_alpha_width(p) \
((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
@@ -1561,3 +1567,220 @@ const struct clk_ops clk_alpha_pll_postdiv_lucid_ops = {
.set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_lucid_ops);
+
+static int alpha_pll_lucid_5lpe_enable(struct clk_hw *hw)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
+ if (ret)
+ return ret;
+
+ /* If in FSM mode, just vote for it */
+ if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
+ ret = clk_enable_regmap(hw);
+ if (ret)
+ return ret;
+ return wait_for_pll_enable_lock(pll);
+ }
+
+ /* Check if PLL is already enabled */
+ ret = trion_pll_is_enabled(pll, pll->clkr.regmap);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_RESET_N,
PLL_RESET_N);
+ if (ret)
+ return ret;
+
+ /* Set operation mode to RUN */
+ regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_RUN);
+
+ ret = wait_for_pll_enable_lock(pll);
+ if (ret)
+ return ret;
+
+ /* Enable the PLL outputs */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
PLL_OUT_MASK, PLL_OUT_MASK);
+ if (ret)
+ return ret;
+
+ /* Enable the global PLL outputs */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL,
PLL_OUTCTRL);
+ if (ret)
+ return ret;
+
+ /* Ensure that the write above goes through before returning. */
+ mb();
+ return ret;
+}
+
+static void alpha_pll_lucid_5lpe_disable(struct clk_hw *hw)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
+ if (ret)
+ return;
+
+ /* If in FSM mode, just unvote it */
+ if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
+ clk_disable_regmap(hw);
+ return;
+ }
+
+ /* Disable the global PLL output */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL,
0);
+ if (ret)
+ return;
+
+ /* Disable the PLL outputs */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
PLL_OUT_MASK, 0);
+ if (ret)
+ return;
+
+ /* Place the PLL mode in STANDBY */
+ regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_STANDBY);
+}
+
+/*
+ * The Lucid 5LPE PLL requires a power-on self-calibration which happens
+ * when the PLL comes out of reset. Calibrate in case it is not completed.
+ */
+static int alpha_pll_lucid_5lpe_prepare(struct clk_hw *hw)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ struct clk_hw *p;
+ u32 regval;
+ int ret;
+
+ /* Return early if calibration is not needed. */
+ regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
+ if (regval & LUCID_5LPE_PCAL_DONE)
+ return 0;
+
+ p = clk_hw_get_parent(hw);
+ if (!p)
+ return -EINVAL;
+
+ ret = alpha_pll_lucid_5lpe_enable(hw);
+ if (ret)
+ return ret;
+
+ alpha_pll_lucid_5lpe_disable(hw);
+
+ return 0;
+}
+
+static int alpha_pll_lucid_5lpe_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long prate)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ unsigned long rrate;
+ u32 regval, l;
+ u64 a;
+ int ret;
+
+ rrate = alpha_pll_round_rate(rate, prate, , ,
ALPHA_REG_16BIT_WIDTH);
+
+
[PATCH v2 1/5] dt-bindings: clock: Add RPMHCC bindings for SM8350
Add bindings and update documentation for clock rpmh driver on SM8350. Reviewed-by: Bjorn Andersson Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index a46a3a799a70..3037eb98c810 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -21,6 +21,7 @@ properties: - qcom,sdm845-rpmh-clk - qcom,sm8150-rpmh-clk - qcom,sm8250-rpmh-clk + - qcom,sm8350-rpmh-clk clocks: maxItems: 1 -- 2.26.2
[PATCH v2 3/5] dt-bindings: clock: Add SM8350 GCC clock bindings
Add device tree bindings for global clock controller on SM8350 SoCs.
Signed-off-by: Vinod Koul
---
.../bindings/clock/qcom,gcc-sm8350.yaml | 68 +
include/dt-bindings/clock/qcom,gcc-sm8350.h | 261 ++
2 files changed, 329 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
new file mode 100644
index ..2b0939f81162
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller Binding for SM8350
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on SM8350.
+
+ See also:
+ - dt-bindings/clock/qcom,gcc-sm8350.h
+
+properties:
+ compatible:
+const: qcom,gcc-sm8350
+
+ clocks:
+items:
+ - description: Board XO source
+ - description: Sleep clock source
+
+ clock-names:
+items:
+ - const: bi_tcxo
+ - const: sleep_clk
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+clock-controller@10 {
+ compatible = "qcom,gcc-sm8350";
+ reg = <0x0010 0x1f>;
+ clocks = < RPMH_CXO_CLK>,
+ <_clk>;
+ clock-names = "bi_tcxo", "sleep_clk";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
+
+...
diff --git a/include/dt-bindings/clock/qcom,gcc-sm8350.h
b/include/dt-bindings/clock/qcom,gcc-sm8350.h
new file mode 100644
index ..2462f64f6e75
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gcc-sm8350.h
@@ -0,0 +1,261 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020, Linaro Limited
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GCC_SM8350_H
+#define _DT_BINDINGS_CLK_QCOM_GCC_SM8350_H
+
+/* GCC HW clocks */
+#define CORE_BI_PLL_TEST_SE0
+#define PCIE_0_PIPE_CLK1
+#define PCIE_1_PIPE_CLK2
+#define UFS_CARD_RX_SYMBOL_0_CLK 3
+#define UFS_CARD_RX_SYMBOL_1_CLK 4
+#define UFS_CARD_TX_SYMBOL_0_CLK 5
+#define UFS_PHY_RX_SYMBOL_0_CLK6
+#define UFS_PHY_RX_SYMBOL_1_CLK7
+#define UFS_PHY_TX_SYMBOL_0_CLK8
+#define USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK9
+#define USB3_UNI_PHY_SEC_GCC_USB30_PIPE_CLK10
+
+/* GCC clocks */
+#define GCC_AGGRE_NOC_PCIE_0_AXI_CLK 11
+#define GCC_AGGRE_NOC_PCIE_1_AXI_CLK 12
+#define GCC_AGGRE_NOC_PCIE_TBU_CLK 13
+#define GCC_AGGRE_UFS_CARD_AXI_CLK 14
+#define GCC_AGGRE_UFS_CARD_AXI_HW_CTL_CLK 15
+#define GCC_AGGRE_UFS_PHY_AXI_CLK 16
+#define GCC_AGGRE_UFS_PHY_AXI_HW_CTL_CLK 17
+#define GCC_AGGRE_USB3_PRIM_AXI_CLK18
+#define GCC_AGGRE_USB3_SEC_AXI_CLK 19
+#define GCC_BOOT_ROM_AHB_CLK 20
+#define GCC_CAMERA_AHB_CLK 21
+#define GCC_CAMERA_HF_AXI_CLK 22
+#define GCC_CAMERA_SF_AXI_CLK 23
+#define GCC_CAMERA_XO_CLK 24
+#define GCC_CFG_NOC_USB3_PRIM_AXI_CLK 25
+#define GCC_CFG_NOC_USB3_SEC_AXI_CLK 26
+#define GCC_DDRSS_GPU_AXI_CLK 27
+#define GCC_DDRSS_PCIE_SF_TBU_CLK 28
+#define GCC_DISP_AHB_CLK 29
+#define GCC_DISP_HF_AXI_CLK30
+#define GCC_DISP_SF_AXI_CLK31
+#define GCC_DISP_XO_CLK32
+#define GCC_GP1_CLK33
+#define GCC_GP1_CLK_SRC34
+#define GCC_GP2_CLK
[PATCH v2 0/5] Add clock drivers for SM8350
This adds rpmhcc and gcc clock controller drivers for the controllers found
in SM8350 SoC
Changes in v2:
- Add r-b from Bjorn
- Add the gcc_qupv3_wrap_1_{m|s}_ahb_clk and gcc_qupv3_wrap1_s5_clk
Vinod Koul (3):
dt-bindings: clock: Add RPMHCC bindings for SM8350
clk: qcom: rpmh: add support for SM8350 rpmh clocks
dt-bindings: clock: Add SM8350 GCC clock bindings
Vivek Aknurwar (2):
clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
clk: qcom: gcc: Add clock driver for SM8350
.../bindings/clock/qcom,gcc-sm8350.yaml | 68 +
.../bindings/clock/qcom,rpmhcc.yaml |1 +
drivers/clk/qcom/Kconfig |9 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/clk-alpha-pll.c | 223 +
drivers/clk/qcom/clk-alpha-pll.h |4 +
drivers/clk/qcom/clk-rpmh.c | 34 +
drivers/clk/qcom/gcc-sm8350.c | 3996 +
include/dt-bindings/clock/qcom,gcc-sm8350.h | 261 ++
include/dt-bindings/clock/qcom,rpmh.h |8 +
10 files changed, 4605 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
create mode 100644 drivers/clk/qcom/gcc-sm8350.c
create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8350.h
--
2.26.2
[PATCH v2 2/5] clk: qcom: rpmh: add support for SM8350 rpmh clocks
This adds the RPMH clocks present in SM8350 SoC
Reviewed-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/clk-rpmh.c | 34 +++
include/dt-bindings/clock/qcom,rpmh.h | 8 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
index e2c669b08aff..64cab4403a17 100644
--- a/drivers/clk/qcom/clk-rpmh.c
+++ b/drivers/clk/qcom/clk-rpmh.c
@@ -432,6 +432,39 @@ static const struct clk_rpmh_desc clk_rpmh_sm8250 = {
.num_clks = ARRAY_SIZE(sm8250_rpmh_clocks),
};
+DEFINE_CLK_RPMH_VRM(sm8350, div_clk1, div_clk1_ao, "divclka1", 2);
+DEFINE_CLK_RPMH_VRM(sm8350, rf_clk4, rf_clk4_ao, "rfclka4", 1);
+DEFINE_CLK_RPMH_VRM(sm8350, rf_clk5, rf_clk5_ao, "rfclka5", 1);
+DEFINE_CLK_RPMH_BCM(sm8350, pka, "PKA0");
+DEFINE_CLK_RPMH_BCM(sm8350, hwkm, "HK0");
+
+static struct clk_hw *sm8350_rpmh_clocks[] = {
+ [RPMH_CXO_CLK] = _bi_tcxo.hw,
+ [RPMH_CXO_CLK_A]= _bi_tcxo_ao.hw,
+ [RPMH_DIV_CLK1] = _div_clk1.hw,
+ [RPMH_DIV_CLK1_A] = _div_clk1_ao.hw,
+ [RPMH_LN_BB_CLK1] = _ln_bb_clk1.hw,
+ [RPMH_LN_BB_CLK1_A] = _ln_bb_clk1_ao.hw,
+ [RPMH_LN_BB_CLK2] = _ln_bb_clk2.hw,
+ [RPMH_LN_BB_CLK2_A] = _ln_bb_clk2_ao.hw,
+ [RPMH_RF_CLK1] = _rf_clk1.hw,
+ [RPMH_RF_CLK1_A]= _rf_clk1_ao.hw,
+ [RPMH_RF_CLK3] = _rf_clk3.hw,
+ [RPMH_RF_CLK3_A]= _rf_clk3_ao.hw,
+ [RPMH_RF_CLK4] = _rf_clk4.hw,
+ [RPMH_RF_CLK4_A]= _rf_clk4_ao.hw,
+ [RPMH_RF_CLK5] = _rf_clk5.hw,
+ [RPMH_RF_CLK5_A]= _rf_clk5_ao.hw,
+ [RPMH_IPA_CLK] = _ipa.hw,
+ [RPMH_PKA_CLK] = _pka.hw,
+ [RPMH_HWKM_CLK] = _hwkm.hw,
+};
+
+static const struct clk_rpmh_desc clk_rpmh_sm8350 = {
+ .clks = sm8350_rpmh_clocks,
+ .num_clks = ARRAY_SIZE(sm8350_rpmh_clocks),
+};
+
static struct clk_hw *of_clk_rpmh_hw_get(struct of_phandle_args *clkspec,
void *data)
{
@@ -519,6 +552,7 @@ static const struct of_device_id clk_rpmh_match_table[] = {
{ .compatible = "qcom,sdm845-rpmh-clk", .data = _rpmh_sdm845},
{ .compatible = "qcom,sm8150-rpmh-clk", .data = _rpmh_sm8150},
{ .compatible = "qcom,sm8250-rpmh-clk", .data = _rpmh_sm8250},
+ { .compatible = "qcom,sm8350-rpmh-clk", .data = _rpmh_sm8350},
{ }
};
MODULE_DEVICE_TABLE(of, clk_rpmh_match_table);
diff --git a/include/dt-bindings/clock/qcom,rpmh.h
b/include/dt-bindings/clock/qcom,rpmh.h
index 2e6c54e65455..6dbe5d398bf0 100644
--- a/include/dt-bindings/clock/qcom,rpmh.h
+++ b/include/dt-bindings/clock/qcom,rpmh.h
@@ -21,5 +21,13 @@
#define RPMH_IPA_CLK 12
#define RPMH_LN_BB_CLK113
#define RPMH_LN_BB_CLK1_A 14
+#define RPMH_DIV_CLK1 15
+#define RPMH_DIV_CLK1_A16
+#define RPMH_RF_CLK4 17
+#define RPMH_RF_CLK4_A 18
+#define RPMH_RF_CLK5 19
+#define RPMH_RF_CLK5_A 20
+#define RPMH_PKA_CLK 21
+#define RPMH_HWKM_CLK 22
#endif
--
2.26.2
Re: [PATCH] MIPS: KASLR: Fix sync_icache() trapped in loop when synci_step is zero
On Thu, 3 Dec 2020, Jinyang He wrote: > Thus, only one synci operation is required when synci_step is 0 > on Loongson64 platform. I guess that some other platforms have > similar implementations on synci, so add judgment conditions in > `while` to ensure that at least all platforms perform synci > operations once. For those platforms that do not need synci, > they just do one more operation similar to nop. This is non-compliant and looks to me like a risky choice for what was invented to guarantee portability across all MIPS systems. Compliant software will fail with Loongson64 processors unless patched like this piece, and you don't really have control over all user software out there (I would expect issues with JIT engines and the like). If only a single SYNCI operation is ever required why wasn't SYNCI_Step set to some large value instead that would in reality prevent looping over SYNCI from happening? Maciej
Re: [PATCH 2/2] xen: don't use page->lru for ZONE_DEVICE memory
On 07.12.20 21:48, Jason Andryuk wrote:
On Mon, Dec 7, 2020 at 8:30 AM Juergen Gross wrote:
Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated
memory") introduced usage of ZONE_DEVICE memory for foreign memory
mappings.
Unfortunately this collides with using page->lru for Xen backend
private page caches.
Fix that by using page->zone_device_data instead.
Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory")
Signed-off-by: Juergen Gross
Would it make sense to add BUG_ON(is_zone_device_page(page)) and the
opposite as appropriate to cache_enq?
No, I don't think so. At least in the CONFIG_ZONE_DEVICE case the
initial list in a PV dom0 is populated from extra memory (basically
the same, but not marked as zone device memory explicitly).
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] RDMA/restrack: update kernel documentation for ib_create_named_qp()
On Mon, Dec 07, 2020 at 06:32:55PM +0100, Lukas Bulwahn wrote:
> Commit 66f57b871efc ("RDMA/restrack: Support all QP types") extends
> ib_create_qp() to a named ib_create_named_qp(), which takes the caller's
> name as argument, but it did not add the new argument description to the
> function's kerneldoc.
>
> make htmldocs warns:
>
> ./drivers/infiniband/core/verbs.c:1206: warning: Function parameter or
> member 'caller' not described in 'ib_create_named_qp'
>
> Add a description for this new argument based on the description of the
> same argument in other related functions.
>
> Signed-off-by: Lukas Bulwahn
> ---
Thanks,
Reviewed-by: Leon Romanovsky
Re: [RFC PATCH v2 0/2] add simple copy support
On 12/7/20 11:12 PM, Douglas Gilbert wrote: On 2020-12-07 9:56 a.m., Hannes Reinecke wrote: On 12/7/20 3:11 PM, Christoph Hellwig wrote: So, I'm really worried about: a) a good use case. GC in f2fs or btrfs seem like good use cases, as does accelating dm-kcopyd. I agree with Damien that lifting dm-kcopyd to common code would also be really nice. I'm not 100% sure it should be a requirement, but it sure would be nice to have I don't think just adding an ioctl is enough of a use case for complex kernel infrastructure. b) We had a bunch of different attempts at SCSI XCOPY support form IIRC Martin, Bart and Mikulas. I think we need to pull them into this discussion, and make sure whatever we do covers the SCSI needs. And we shouldn't forget that the main issue which killed all previous implementations was a missing QoS guarantee. It's nice to have simply copy, but if the implementation is _slower_ than doing it by hand from the OS there is very little point in even attempting to do so. I can't see any provisions for that in the TPAR, leading me to the assumption that NVMe simple copy will suffer from the same issue. So if we can't address this I guess this attempt will fail, too. I have been doing quite a lot of work and testing in my sg driver rewrite in the copy and compare area. The baselines for performance are dd and io_uring-cp (in liburing). There are lots of ways to improve on them. Here are some: - the user data need never pass through the user space (could mmap it out during the READ if there is a good reason). Only the metadata (e.g. NVMe or SCSI commands) needs to come from the user space and errors, if any, reported back to the user space. - break a large copy (or compare) into segments, with each segment a "comfortable" size for the OS to handle, say 256 KB - there is one constraint: the READ in each segment must complete before its paired WRITE can commence - extra constraint for some zoned disks: WRITEs must be issued in order (assuming they are applied in that order, if not, need to wait until each WRITE completes) - arrange for READ WRITE pair in each segment to share the same bio - have multiple slots each holding a segment (i.e. a bio and metadata to process a READ-WRITE pair) - re-use each slot's bio for the following READ-WRITE pair - issue the READs in each slot asynchronously and do an interleaved (io)poll for completion. Then issue the paired WRITE asynchronously - the above "slot" algorithm runs in one thread, so there can be multiple threads doing the same algorithm. Segment manager needs to be locked (or use an atomics) so that each segment (identified by its starting LBAs) is issued once and only once when the next thread wants a segment to copy Running multiple threads gives diminishing or even worsening returns. Runtime metrics on lock contention and storage bus capacity may help choosing the number of threads. A simpler approach might be add more threads until the combined throughput increase is less than 10% say. The 'compare' that I mention is based on the SCSI VERIFY(BYTCHK=1) command (or NVMe NVM Compare command). Using dd logic, a disk to disk compare can be implemented with not much more work than changing the WRITE to a VERIFY command. This is a different approach to the Linux cmp utility which READs in both sides and does a memcmp() type operation. Using ramdisks (from the scsi_debug driver) the compare operation (max ~ 10 GB/s) was actually faster than the copy (max ~ 7 GB/s). I put this down to WRITE operations taking a write lock over the store while the VERIFY only needs a read lock so many VERIFY operations can co-exist on the same store. Unfortunately on real SAS and NVMe SSDs that I tested the performance of the VERIFY and NVM Compare commands is underwhelming. For comparison, using scsi_debug ramdisks, dd copy throughput was < 1 GB/s and io_uring-cp was around 2-3 GB/s. The system was Ryzen 3600 based. Which is precisely my concern. Simple copy might be efficient for one particular implementation, but it might be completely off the board for others. But both will be claiming to support it, and us having no idea whether choosing simple copy will speed up matters or not. Without having a programmatic way to figure out the speed of the implementation we have to detect the performance ourselves, like the benchmarking loop RAID5 does. I was hoping to avoid that, and just ask the device/controller; but that turned out to be in vain. Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
RE: [PATCH bpf-next v4 07/11] bpf: Add instructions for atomic_[cmp]xchg
Brendan Jackman wrote:
> This adds two atomic opcodes, both of which include the BPF_FETCH
> flag. XCHG without the BPF_FETCH flag would naturally encode
> atomic_set. This is not supported because it would be of limited
> value to userspace (it doesn't imply any barriers). CMPXCHG without
> BPF_FETCH woulud be an atomic compare-and-write. We don't have such
> an operation in the kernel so it isn't provided to BPF either.
>
> There are two significant design decisions made for the CMPXCHG
> instruction:
>
> - To solve the issue that this operation fundamentally has 3
>operands, but we only have two register fields. Therefore the
>operand we compare against (the kernel's API calls it 'old') is
>hard-coded to be R0. x86 has similar design (and A64 doesn't
>have this problem).
>
>A potential alternative might be to encode the other operand's
>register number in the immediate field.
>
> - The kernel's atomic_cmpxchg returns the old value, while the C11
>userspace APIs return a boolean indicating the comparison
>result. Which should BPF do? A64 returns the old value. x86 returns
>the old value in the hard-coded register (and also sets a
>flag). That means return-old-value is easier to JIT.
>
> Signed-off-by: Brendan Jackman
> ---
Sorry if this is a dup, client crashed while I sent the previous version
and don't see it on the list.
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3608,11 +3608,14 @@ static int check_mem_access(struct bpf_verifier_env
> *env, int insn_idx, u32 regn
>
> static int check_atomic(struct bpf_verifier_env *env, int insn_idx, struct
> bpf_insn *insn)
> {
> + int load_reg;
> int err;
>
> switch (insn->imm) {
> case BPF_ADD:
> case BPF_ADD | BPF_FETCH:
> + case BPF_XCHG:
> + case BPF_CMPXCHG:
> break;
> default:
> verbose(env, "BPF_ATOMIC uses invalid atomic opcode %02x\n",
> insn->imm);
> @@ -3634,6 +3637,13 @@ static int check_atomic(struct bpf_verifier_env *env,
> int insn_idx, struct bpf_i
> if (err)
> return err;
>
> + if (insn->imm == BPF_CMPXCHG) {
> + /* Check comparison of R0 with memory location */
> + err = check_reg_arg(env, BPF_REG_0, SRC_OP);
> + if (err)
> + return err;
> + }
> +
Need to think a bit more on this, but do we need to update is_reg64() here
as well?
> if (is_pointer_value(env, insn->src_reg)) {
> verbose(env, "R%d leaks addr into mem\n", insn->src_reg);
> return -EACCES;
> @@ -3664,8 +3674,13 @@ static int check_atomic(struct bpf_verifier_env *env,
> int insn_idx, struct bpf_i
> if (!(insn->imm & BPF_FETCH))
> return 0;
>
> - /* check and record load of old value into src reg */
> - err = check_reg_arg(env, insn->src_reg, DST_OP);
> + if (insn->imm == BPF_CMPXCHG)
> + load_reg = BPF_REG_0;
> + else
> + load_reg = insn->src_reg;
> +
> + /* check and record load of old value */
> + err = check_reg_arg(env, load_reg, DST_OP);
> if (err)
> return err;
>
Thanks,
John
Re: [PATCH v2 10/19] dt-bindings: dma: ti: Add document for K3 BCDMA
Hi Rob, On 07/12/2020 21.42, Rob Herring wrote: > On Tue, Nov 17, 2020 at 12:56:47PM +0200, Peter Ujfalusi wrote: >> New binding document for >> Texas Instruments K3 Block Copy DMA (BCDMA). >> >> BCDMA is introduced as part of AM64. >> >> Signed-off-by: Peter Ujfalusi >> --- >> .../devicetree/bindings/dma/ti/k3-bcdma.yaml | 175 ++ >> 1 file changed, 175 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> >> diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> new file mode 100644 >> index ..c6d76641ebec >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> @@ -0,0 +1,175 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings >> + >> +maintainers: >> + - Peter Ujfalusi >> + >> +description: | >> + The Block Copy DMA (BCDMA) is intended to perform similar functions as >> the TR >> + mode channels of K3 UDMA-P. >> + BCDMA includes block copy channels and Split channels. >> + >> + Block copy channels mainly used for memory to memory transfers, but with >> + optional triggers a block copy channel can service peripherals by >> accessing >> + directly to memory mapped registers or area. >> + >> + Split channels can be used to service PSI-L based peripherals. >> + The peripherals can be PSI-L native or legacy, non PSI-L native >> peripherals >> + with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric >> and the >> + legacy peripheral. >> + >> + PDMAs can be configured via BCDMA split channel's peer registers to match >> with >> + the configuration of the legacy peripheral. >> + >> +allOf: >> + - $ref: /schemas/dma/dma-controller.yaml# >> + >> +properties: >> + "#dma-cells": >> +const: 3 >> +description: | >> + cell 1: type of the BCDMA channel to be used to service the >> peripheral: >> +0 - split channel >> +1 - block copy channel using global trigger 1 >> +2 - block copy channel using global trigger 2 >> +3 - block copy channel using local trigger >> + >> + cell 2: parameter for the channel: >> +if cell 1 is 0 (split channel): >> + PSI-L thread ID of the remote (to BCDMA) end. >> + Valid ranges for thread ID depends on the data movement direction: >> + for source thread IDs (rx): 0 - 0x7fff >> + for destination thread IDs (tx): 0x8000 - 0x >> + >> + Please refer to the device documentation for the PSI-L thread map >> and >> + also the PSI-L peripheral chapter for the correct thread ID. >> +if cell 1 is 1 or 2 (block copy channel using global trigger): >> + Unused, ignored >> + >> + The trigger must be configured for the channel externally to >> BCDMA, >> + channels using global triggers should not be requested directly, >> but >> + via DMA event router. >> +if cell 1 is 3 (block copy channel using local trigger): >> + bchan number of the locally triggered channel >> + >> + cell 3: ASEL value for the channel >> + >> + compatible: >> +enum: >> + - ti,am64-dmss-bcdma > > Typically, we put 'compatible' first. OK. >> + "#address-cells": >> +const: 2 >> + >> + "#size-cells": >> +const: 2 > > These apply to child nodes, but you don't have any. True, I forgot to remove these. >> + >> + reg: >> +maxItems: 5 >> + >> + reg-names: >> +items: >> + - const: gcfg >> + - const: bchanrt >> + - const: rchanrt >> + - const: tchanrt >> + - const: ringrt >> + >> + msi-parent: true >> + >> + ti,asel: >> +$ref: /schemas/types.yaml#/definitions/uint32 >> +description: ASEL value for non slave channels >> + >> + ti,sci-rm-range-bchan: >> +$ref: /schemas/types.yaml#/definitions/uint32-array >> +description: | >> + Array of BCDMA block-copy channel resource subtypes for resource >> + allocation for this host >> +minItems: 1 >> +# Should be enough >> +maxItems: 255 >> +items: >> + maximum: 0x3f >> + >> + ti,sci-rm-range-tchan: >> +$ref: /schemas/types.yaml#/definitions/uint32-array >> +description: | >> + Array of BCDMA split tx channel resource subtypes for resource >> allocation >> + for this host >> +minItems: 1 >> +# Should be enough >> +maxItems: 255 >> +items: >> + maximum: 0x3f >> + >> + ti,sci-rm-range-rchan: >> +$ref: /schemas/types.yaml#/definitions/uint32-array >> +description: | >> + Array of BCDMA split rx channel resource subtypes for resource >> allocation >> + for this host >> +minItems: 1 >> +# Should be enough >> +maxItems:
RE: [PATCH bpf-next v4 07/11] bpf: Add instructions for atomic_[cmp]xchg
Brendan Jackman wrote:
> This adds two atomic opcodes, both of which include the BPF_FETCH
> flag. XCHG without the BPF_FETCH flag would naturally encode
> atomic_set. This is not supported because it would be of limited
> value to userspace (it doesn't imply any barriers). CMPXCHG without
> BPF_FETCH woulud be an atomic compare-and-write. We don't have such
> an operation in the kernel so it isn't provided to BPF either.
>
> There are two significant design decisions made for the CMPXCHG
> instruction:
>
> - To solve the issue that this operation fundamentally has 3
>operands, but we only have two register fields. Therefore the
>operand we compare against (the kernel's API calls it 'old') is
>hard-coded to be R0. x86 has similar design (and A64 doesn't
>have this problem).
>
>A potential alternative might be to encode the other operand's
>register number in the immediate field.
>
> - The kernel's atomic_cmpxchg returns the old value, while the C11
>userspace APIs return a boolean indicating the comparison
>result. Which should BPF do? A64 returns the old value. x86 returns
>the old value in the hard-coded register (and also sets a
>flag). That means return-old-value is easier to JIT.
Just a nit as it looks like perhaps we get one more spin here. Would
be nice to be explicit about what the code does here. The above reads
like it could go either way. Just an extra line "So we use ...' would
be enough.
>
> Signed-off-by: Brendan Jackman
> ---
One question below.
> arch/x86/net/bpf_jit_comp.c| 8
> include/linux/filter.h | 22 ++
> include/uapi/linux/bpf.h | 4 +++-
> kernel/bpf/core.c | 20
> kernel/bpf/disasm.c| 15 +++
> kernel/bpf/verifier.c | 19 +--
> tools/include/linux/filter.h | 22 ++
> tools/include/uapi/linux/bpf.h | 4 +++-
> 8 files changed, 110 insertions(+), 4 deletions(-)
>
[...]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index f8c4e809297d..f5f4460b3e4e 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3608,11 +3608,14 @@ static int check_mem_access(struct bpf_verifier_env
> *env, int insn_idx, u32 regn
>
> static int check_atomic(struct bpf_verifier_env *env, int insn_idx, struct
> bpf_insn *insn)
> {
> + int load_reg;
> int err;
>
> switch (insn->imm) {
> case BPF_ADD:
> case BPF_ADD | BPF_FETCH:
> + case BPF_XCHG:
> + case BPF_CMPXCHG:
> break;
> default:
> verbose(env, "BPF_ATOMIC uses invalid atomic opcode %02x\n",
> insn->imm);
> @@ -3634,6 +3637,13 @@ static int check_atomic(struct bpf_verifier_env *env,
> int insn_idx, struct bpf_i
> if (err)
> return err;
>
> + if (insn->imm == BPF_CMPXCHG) {
> + /* Check comparison of R0 with memory location */
> + err = check_reg_arg(env, BPF_REG_0, SRC_OP);
> + if (err)
> + return err;
> + }
> +
I need to think a bit more about it, but do we need to update is_reg64()
at all for these?
> if (is_pointer_value(env, insn->src_reg)) {
> verbose(env, "R%d leaks addr into mem\n", insn->src_reg);
> return -EACCES;
> @@ -3664,8 +3674,13 @@ static int check_atomic(struct bpf_verifier_env *env,
> int insn_idx, struct bpf_i
> if (!(insn->imm & BPF_FETCH))
> return 0;
>
> - /* check and record load of old value into src reg */
> - err = check_reg_arg(env, insn->src_reg, DST_OP);
> + if (insn->imm == BPF_CMPXCHG)
> + load_reg = BPF_REG_0;
> + else
> + load_reg = insn->src_reg;
> +
> + /* check and record load of old value */
> + err = check_reg_arg(env, load_reg, DST_OP);
> if (err)
> return err;
Re: [PATCH v2 07/17] driver core: Add fwnode_init()
On Mon, Dec 07, 2020 at 12:36:43PM -0800, Saravana Kannan wrote: > On Mon, Dec 7, 2020 at 11:54 AM Leon Romanovsky wrote: > > > > On Mon, Dec 07, 2020 at 11:25:15AM -0800, Saravana Kannan wrote: > > > On Sat, Dec 5, 2020 at 11:26 PM Leon Romanovsky wrote: > > > > > > > > On Fri, Nov 20, 2020 at 06:02:22PM -0800, Saravana Kannan wrote: > > > > > There are multiple locations in the kernel where a struct > > > > > fwnode_handle > > > > > is initialized. Add fwnode_init() so that we have one way of > > > > > initializing a fwnode_handle. > > > > > > > > > > Signed-off-by: Saravana Kannan > > > > > --- > > > > > drivers/acpi/property.c | 2 +- > > > > > drivers/acpi/scan.c | 2 +- > > > > > drivers/base/swnode.c | 2 +- > > > > > drivers/firmware/efi/efi-init.c | 8 > > > > > include/linux/fwnode.h | 6 ++ > > > > > include/linux/of.h | 2 +- > > > > > kernel/irq/irqdomain.c | 2 +- > > > > > 7 files changed, 15 insertions(+), 9 deletions(-) > > > > > > > > In this series, I didn't find any extension of fwnode_init() to be it > > > > more > > > > than simple assignment. This change looks to me like unnecessary churn > > > > and > > > > obfuscation rather than improvement. > > > > > > > > "...ops = &...;" is pretty standard in the kernel to initialize ops > > > > structures. > > > > > > Subsequent patches make fwnode_init() do more stuff. > > > > But not in this series, right? > > In this series. The very next patch - Patch 8/17 :) Thanks, sorry for the noise. > > -Saravana
Re: INFO: rcu detected stall in __se_sys_mount
On Mon, Dec 7, 2020 at 9:06 PM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6 > Author: David Howells > Date: Fri Oct 16 12:21:14 2020 + > > afs: Fix cell removal > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=162cebcf50 > start commit: c85fb28b Merge tag 'arm64-fixes' of git://git.kernel.org/p.. > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=de7f697da23057c7 > dashboard link: https://syzkaller.appspot.com/bug?extid=3f2db34df769d77edf8c > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11df5d4f90 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=157851e050 > > If the result looks correct, please mark the issue as fixed by replying with: > > #syz fix: afs: Fix cell removal > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection #syz fix: afs: Fix cell removal
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
From: Martin KaFai Lau Date: Mon, 7 Dec 2020 12:33:15 -0800 > On Thu, Dec 03, 2020 at 11:14:24PM +0900, Kuniyuki Iwashima wrote: > > From: Eric Dumazet > > Date: Tue, 1 Dec 2020 16:25:51 +0100 > > > On 12/1/20 3:44 PM, Kuniyuki Iwashima wrote: > > > > This patch lets reuseport_detach_sock() return a pointer of struct sock, > > > > which is used only by inet_unhash(). If it is not NULL, > > > > inet_csk_reqsk_queue_migrate() migrates TCP_ESTABLISHED/TCP_SYN_RECV > > > > sockets from the closing listener to the selected one. > > > > > > > > Listening sockets hold incoming connections as a linked list of struct > > > > request_sock in the accept queue, and each request has reference to a > > > > full > > > > socket and its listener. In inet_csk_reqsk_queue_migrate(), we only > > > > unlink > > > > the requests from the closing listener's queue and relink them to the > > > > head > > > > of the new listener's queue. We do not process each request and its > > > > reference to the listener, so the migration completes in O(1) time > > > > complexity. However, in the case of TCP_SYN_RECV sockets, we take > > > > special > > > > care in the next commit. > > > > > > > > By default, the kernel selects a new listener randomly. In order to pick > > > > out a different socket every time, we select the last element of > > > > socks[] as > > > > the new listener. This behaviour is based on how the kernel moves > > > > sockets > > > > in socks[]. (See also [1]) > > > > > > > > Basically, in order to redistribute sockets evenly, we have to use an > > > > eBPF > > > > program called in the later commit, but as the side effect of such > > > > default > > > > selection, the kernel can redistribute old requests evenly to new > > > > listeners > > > > for a specific case where the application replaces listeners by > > > > generations. > > > > > > > > For example, we call listen() for four sockets (A, B, C, D), and close > > > > the > > > > first two by turns. The sockets move in socks[] like below. > > > > > > > > socks[0] : A <-. socks[0] : D socks[0] : D > > > > socks[1] : B | => socks[1] : B <-. => socks[1] : C > > > > socks[2] : C | socks[2] : C --' > > > > socks[3] : D --' > > > > > > > > Then, if C and D have newer settings than A and B, and each socket has a > > > > request (a, b, c, d) in their accept queue, we can redistribute old > > > > requests evenly to new listeners. > > > > > > > > socks[0] : A (a) <-. socks[0] : D (a + d) socks[0] : D (a + > > > > d) > > > > socks[1] : B (b) | => socks[1] : B (b) <-. => socks[1] : C (b + > > > > c) > > > > socks[2] : C (c) | socks[2] : C (c) --' > > > > socks[3] : D (d) --' > > > > > > > > Here, (A, D) or (B, C) can have different application settings, but they > > > > MUST have the same settings at the socket API level; otherwise, > > > > unexpected > > > > error may happen. For instance, if only the new listeners have > > > > TCP_SAVE_SYN, old requests do not have SYN data, so the application will > > > > face inconsistency and cause an error. > > > > > > > > Therefore, if there are different kinds of sockets, we must attach an > > > > eBPF > > > > program described in later commits. > > > > > > > > Link: > > > > https://lore.kernel.org/netdev/CAEfhGiyG8Y_amDZ2C8dQoQqjZJMHjTY76b=KBkTKcBtA=dh...@mail.gmail.com/ > > > > Reviewed-by: Benjamin Herrenschmidt > > > > Signed-off-by: Kuniyuki Iwashima > > > > --- > > > > include/net/inet_connection_sock.h | 1 + > > > > include/net/sock_reuseport.h | 2 +- > > > > net/core/sock_reuseport.c | 10 +- > > > > net/ipv4/inet_connection_sock.c| 30 ++ > > > > net/ipv4/inet_hashtables.c | 9 +++-- > > > > 5 files changed, 48 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/include/net/inet_connection_sock.h > > > > b/include/net/inet_connection_sock.h > > > > index 7338b3865a2a..2ea2d743f8fc 100644 > > > > --- a/include/net/inet_connection_sock.h > > > > +++ b/include/net/inet_connection_sock.h > > > > @@ -260,6 +260,7 @@ struct dst_entry *inet_csk_route_child_sock(const > > > > struct sock *sk, > > > > struct sock *inet_csk_reqsk_queue_add(struct sock *sk, > > > > struct request_sock *req, > > > > struct sock *child); > > > > +void inet_csk_reqsk_queue_migrate(struct sock *sk, struct sock *nsk); > > > > void inet_csk_reqsk_queue_hash_add(struct sock *sk, struct > > > > request_sock *req, > > > >unsigned long timeout); > > > > struct sock *inet_csk_complete_hashdance(struct sock *sk, struct sock > > > > *child, > > > > diff --git a/include/net/sock_reuseport.h b/include/net/sock_reuseport.h > > > > index 0e558ca7afbf..09a1b1539d4c 100644 > > > > --- a/include/net/sock_reuseport.h > > > > +++ b/include/net/sock_reuseport.h > > > > @@ -31,7
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
From: Martin KaFai Lau
Date: Mon, 7 Dec 2020 12:14:38 -0800
> On Sun, Dec 06, 2020 at 01:03:07AM +0900, Kuniyuki Iwashima wrote:
> > From: Martin KaFai Lau
> > Date: Fri, 4 Dec 2020 17:42:41 -0800
> > > On Tue, Dec 01, 2020 at 11:44:10PM +0900, Kuniyuki Iwashima wrote:
> > > [ ... ]
> > > > diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
> > > > index fd133516ac0e..60d7c1f28809 100644
> > > > --- a/net/core/sock_reuseport.c
> > > > +++ b/net/core/sock_reuseport.c
> > > > @@ -216,9 +216,11 @@ int reuseport_add_sock(struct sock *sk, struct
> > > > sock *sk2, bool bind_inany)
> > > > }
> > > > EXPORT_SYMBOL(reuseport_add_sock);
> > > >
> > > > -void reuseport_detach_sock(struct sock *sk)
> > > > +struct sock *reuseport_detach_sock(struct sock *sk)
> > > > {
> > > > struct sock_reuseport *reuse;
> > > > + struct bpf_prog *prog;
> > > > + struct sock *nsk = NULL;
> > > > int i;
> > > >
> > > > spin_lock_bh(_lock);
> > > > @@ -242,8 +244,12 @@ void reuseport_detach_sock(struct sock *sk)
> > > >
> > > > reuse->num_socks--;
> > > > reuse->socks[i] = reuse->socks[reuse->num_socks];
> > > > + prog = rcu_dereference(reuse->prog);
> > > Is it under rcu_read_lock() here?
> >
> > reuseport_lock is locked in this function, and we do not modify the prog,
> > but is rcu_dereference_protected() preferable?
> >
> > ---8<---
> > prog = rcu_dereference_protected(reuse->prog,
> > lockdep_is_held(_lock));
> > ---8<---
> It is not only reuse->prog. Other things also require rcu_read_lock(),
> e.g. please take a look at __htab_map_lookup_elem().
>
> The TCP_LISTEN sk (selected by bpf to be the target of the migration)
> is also protected by rcu.
Thank you, I will use rcu_read_lock() and rcu_dereference() in v3 patchset.
> I am surprised there is no WARNING in the test.
> Do you have the needed DEBUG_LOCK* config enabled?
Yes, DEBUG_LOCK* was 'y', but rcu_dereference() without rcu_read_lock()
does not show warnings...
> > > > if (sk->sk_protocol == IPPROTO_TCP) {
> > > > + if (reuse->num_socks && !prog)
> > > > + nsk = i == reuse->num_socks ?
> > > > reuse->socks[i - 1] : reuse->socks[i];
> > > > +
> > > > reuse->num_closed_socks++;
> > > > reuse->socks[reuse->max_socks -
> > > > reuse->num_closed_socks] = sk;
> > > > } else {
> > > > @@ -264,6 +270,8 @@ void reuseport_detach_sock(struct sock *sk)
> > > > call_rcu(>rcu, reuseport_free_rcu);
> > > > out:
> > > > spin_unlock_bh(_lock);
> > > > +
> > > > + return nsk;
> > > > }
> > > > EXPORT_SYMBOL(reuseport_detach_sock);
> > > >
> > > > diff --git a/net/ipv4/inet_connection_sock.c
> > > > b/net/ipv4/inet_connection_sock.c
> > > > index 1451aa9712b0..b27241ea96bd 100644
> > > > --- a/net/ipv4/inet_connection_sock.c
> > > > +++ b/net/ipv4/inet_connection_sock.c
> > > > @@ -992,6 +992,36 @@ struct sock *inet_csk_reqsk_queue_add(struct sock
> > > > *sk,
> > > > }
> > > > EXPORT_SYMBOL(inet_csk_reqsk_queue_add);
> > > >
> > > > +void inet_csk_reqsk_queue_migrate(struct sock *sk, struct sock *nsk)
> > > > +{
> > > > + struct request_sock_queue *old_accept_queue, *new_accept_queue;
> > > > +
> > > > + old_accept_queue = _csk(sk)->icsk_accept_queue;
> > > > + new_accept_queue = _csk(nsk)->icsk_accept_queue;
> > > > +
> > > > + spin_lock(_accept_queue->rskq_lock);
> > > > + spin_lock(_accept_queue->rskq_lock);
> > > I am also not very thrilled on this double spin_lock.
> > > Can this be done in (or like) inet_csk_listen_stop() instead?
> >
> > It will be possible to migrate sockets in inet_csk_listen_stop(), but I
> > think it is better to do it just after reuseport_detach_sock() becuase we
> > can select a different listener (almost) every time at a lower cost by
> > selecting the moved socket and pass it to inet_csk_reqsk_queue_migrate()
> > easily.
> I don't see the "lower cost" point. Please elaborate.
In reuseport_select_sock(), we pass sk_hash of the request socket to
reciprocal_scale() and generate a random index for socks[] to select
a different listener every time.
On the other hand, we do not have request sockets in unhash path and
sk_hash of the listener is always 0, so we have to generate a random number
in another way. In reuseport_detach_sock(), we can use the index of the
moved socket, but we do not have it in inet_csk_listen_stop(), so we have
to generate a random number in inet_csk_listen_stop().
I think it is at lower cost to use the index of the moved socket.
> > sk_hash of the listener is 0, so we would have to generate a random number
> > in inet_csk_listen_stop().
> If I read it correctly, it is also passing 0 as the sk_hash to
> bpf_run_sk_reuseport() from reuseport_detach_sock().
>
> Also, how is the
[PATCH 5/6] mmc: core: simplify hs200 tuning
Since the host->ops->prepare_hs400_tuning had been moved to
mmc_select_hs400() the tuning for hs200 can simplify and
the function mmc_hs200_tuning() can be removed.
Signed-off-by: Chris Ruehl
---
drivers/mmc/core/mmc.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f11562b58e89..6ef6029b6948 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1485,26 +1485,6 @@ static int mmc_select_timing(struct mmc_card *card)
return 0;
}
-/*
- * Execute tuning sequence to seek the proper bus operating
- * conditions for HS200 and HS400, which sends CMD21 to the device.
- */
-static int mmc_hs200_tuning(struct mmc_card *card)
-{
- struct mmc_host *host = card->host;
-
- /*
-* Timing should be adjusted to the HS400 target
-* operation frequency for tuning process
-*/
- if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
- host->ios.bus_width == MMC_BUS_WIDTH_8)
- if (host->ops->prepare_hs400_tuning)
- host->ops->prepare_hs400_tuning(host, >ios);
-
- return mmc_execute_tuning(card);
-}
-
/*
* Handle the detection and initialisation of a card.
*
@@ -1726,7 +1706,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
if (mmc_card_hs200(card)) {
host->doing_init_tune = 1;
- err = mmc_hs200_tuning(card);
+ err = mmc_execute_tuning(card);
host->doing_init_tune = 0;
--
2.20.1
[PATCH 3/6] mmc: core: add enhanced strobe to mmc_select_hs400()
Function mmc_select_hs400() and mmc_select_hs400es have almost
identical code it seems okay to merge them.
Add the function calls for enhanced strobe to mmc_select_hs400 and
add a bool variable to the function call to enable them if HS400ES
is selected.
mmc_select_hs400es() becomes obsolate and can be removed.
Signed-off-by: Chris Ruehl
---
drivers/mmc/core/mmc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index e7b4de3d4f47..84c09d9e0317 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1333,7 +1333,7 @@ static int mmc_select_hs400es(struct mmc_card *card)
return err;
}
-static int mmc_select_hs400(struct mmc_card *card)
+static int mmc_select_hs400(struct mmc_card *card, bool enhancedstrobe)
{
struct mmc_host *host = card->host;
unsigned int max_dtr;
@@ -1409,9 +1409,12 @@ static int mmc_select_hs400(struct mmc_card *card)
host->ops->hs400_prepare_ddr(host);
/* Switch card to DDR */
+ val = EXT_CSD_DDR_BUS_WIDTH_8;
+ if (enhancedstrobe)
+ val |= EXT_CSD_BUS_WIDTH_STROBE;
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_BUS_WIDTH,
-EXT_CSD_DDR_BUS_WIDTH_8,
+val,
card->ext_csd.generic_cmd6_time);
if (err) {
pr_err("%s: switch to bus width for hs400 failed, err:%d\n",
@@ -1451,6 +1454,13 @@ static int mmc_select_hs400(struct mmc_card *card)
if (host->ops->hs400_complete)
host->ops->hs400_complete(host);
+ if (enhancedstrobe) {
+ /* Controller enable enhanced strobe function */
+ host->ios.enhanced_strobe = true;
+ if (host->ops->hs400_enhanced_strobe)
+ host->ops->hs400_enhanced_strobe(host, >ios);
+ }
+
err = mmc_switch_status(card, true);
if (err)
goto out_err;
@@ -1465,7 +1475,7 @@ static int mmc_select_hs400(struct mmc_card *card)
int mmc_hs200_to_hs400(struct mmc_card *card)
{
- return mmc_select_hs400(card);
+ return mmc_select_hs400(card, false);
}
/*
@@ -1549,9 +1559,9 @@ static int mmc_select_timing(struct mmc_card *card)
goto bus_speed;
if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400ES)
- err = mmc_select_hs400es(card);
+ err = mmc_select_hs400(card, true);
else if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400)
- err = mmc_select_hs400(card);
+ err = mmc_select_hs400(card, false);
else if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS200)
err = mmc_select_hs200(card);
else if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS)
--
2.20.1
[PATCH 2/6] mmc: core: make hs400 independent from hs200 init
Move mmc_select_hs400() out from hs200 init path and make hs400
independent.
The patch makes quite some changes and needs to be reviewed carefully.
In function mmc_select_timing() call for mmc_select_hs400().
HS400 requires a host bus with of 8bit, if not supported we
return with -ENOTSUPP, there is no retry.
If the host controller can't switch to 8bit (dts: bus-width = <4>)
it can't recover on next power-up init failed.
Have the controller set to HS mode, make the hs400 tuning prepare
if any and run mmc tuning before switching to HS400.
This patch resolve the problem if hs400-1_8v is set but extended
strobe is not.
{ // eMMC
bus-width = <8>;
mmc-hs400-1_8v;
// mmc-hs400-enhanced-strobe;
non-removable;
status = "okay";
};
[1.775721] mmc1: CQHCI version 5.10
[1.802342] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] using
ADMA
[2.007581] mmc1: mmc_select_hs200 failed, error -110
[2.007589] mmc1: error -110 whilst initialising MMC card
[2.413559] mmc1: mmc_select_hs200 failed, error -110
[2.413562] mmc1: error -110 whilst initialising MMC card
[3.183343] mmc1: Command Queue Engine enabled
[3.183355] mmc1: new HS400 MMC card at address 0001
[3.197163] mmcblk1: mmc1:0001 DG4008 7.28 GiB
[3.197256] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB
[3.197360] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB
[3.197360] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB
[3.197479] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev
(242:0)
[1.743386] mmc1: CQHCI version 5.10
[1.769952] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] using
ADMA
[1.846223] mmc1: Command Queue Engine enabled
[1.846230] mmc1: new HS400 MMC card at address 0001
[1.846557] mmcblk1: mmc1:0001 DG4008 7.28 GiB
[1.846650] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB
[1.846742] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB
[1.846825] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev
(242:0)
Tested with rk3399 customized board.
Signed-off-by: Chris Ruehl
---
drivers/mmc/core/mmc.c | 61 +++---
1 file changed, 52 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 5477786aded8..e7b4de3d4f47 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1337,15 +1337,46 @@ static int mmc_select_hs400(struct mmc_card *card)
{
struct mmc_host *host = card->host;
unsigned int max_dtr;
- int err = 0;
+ int err = -EINVAL;
u8 val;
/*
-* HS400 mode requires 8-bit bus width
+* HS400 mode requires host 8-bit bus width
*/
- if (!(card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
- host->ios.bus_width == MMC_BUS_WIDTH_8))
- return 0;
+ if (!(host->caps & MMC_CAP_8_BIT_DATA)) {
+ pr_err("%s: host not support hs400 8bit\n",
+ mmc_hostname(host));
+ return -EOPNOTSUPP;
+ }
+
+ /*
+* Below is a change from previous logic.
+* mmc_avail_type vccq voltage set in dts, it can be 1_2v or 1_8v
+* but not both.
+*/
+ if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_2V) {
+ err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120);
+ } else if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_8V) {
+ err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180);
+ } else {
+ pr_err("%s: hs400 unsupported vccq voltage, err:%d\n",
+ mmc_hostname(host), -EOPNOTSUPP);
+ return -EOPNOTSUPP;
+ }
+
+ /* Failed set 1_2v or 1_8v try again during next card power cycle */
+ if (err)
+ return err;
+
+ mmc_select_driver_type(card);
+
+ err = mmc_select_bus_width(card);
+ if (err != MMC_BUS_WIDTH_8) {
+ pr_err("%s: switch to 8bit bus width failed, err:%d\n",
+ mmc_hostname(host), err);
+ err = err < 0 ? err : -EOPNOTSUPP;
+ goto out_err;
+ }
/* Switch card to HS mode */
val = EXT_CSD_TIMING_HS;
@@ -1388,6 +1419,18 @@ static int mmc_select_hs400(struct mmc_card *card)
return err;
}
+ /* HS400 prepare and execute tuning */
+ host->doing_init_tune = 1;
+ if (host->ops->prepare_hs400_tuning)
+ host->ops->prepare_hs400_tuning(host, >ios);
+ err = mmc_execute_tuning(card);
+ host->doing_init_tune = 0;
+ if (err) {
+ pr_err("%s: hs400 tuning failed, err:%d\n",
+ mmc_hostname(host), err);
+ return err;
+ }
+
/* Switch card to HS400 */
val = EXT_CSD_TIMING_HS400 |
card->drive_strength << EXT_CSD_DRV_STR_SHIFT;
@@ -1496,7
[PATCH 4/6] mmc: core: remove mmc_select_hs400es()
Enhanced strobe function had been merged in mmc_select_hs400();
mmc_select_hs400es() is obsolate and removed.
Signed-off-by: Chris Ruehl
---
drivers/mmc/core/mmc.c | 94 --
1 file changed, 94 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 84c09d9e0317..f11562b58e89 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1239,100 +1239,6 @@ static void mmc_select_driver_type(struct mmc_card
*card)
mmc_set_driver_type(card->host, drv_type);
}
-static int mmc_select_hs400es(struct mmc_card *card)
-{
- struct mmc_host *host = card->host;
- int err = -EINVAL;
- u8 val;
-
- if (!(host->caps & MMC_CAP_8_BIT_DATA)) {
- err = -ENOTSUPP;
- goto out_err;
- }
-
- if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_2V)
- err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120);
-
- if (err && card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400_1_8V)
- err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180);
-
- /* If fails try again during next card power cycle */
- if (err)
- goto out_err;
-
- err = mmc_select_bus_width(card);
- if (err != MMC_BUS_WIDTH_8) {
- pr_err("%s: switch to 8bit bus width failed, err:%d\n",
- mmc_hostname(host), err);
- err = err < 0 ? err : -ENOTSUPP;
- goto out_err;
- }
-
- /* Switch card to HS mode */
- err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS,
- card->ext_csd.generic_cmd6_time, 0,
- false, true);
- if (err) {
- pr_err("%s: switch to hs for hs400es failed, err:%d\n",
- mmc_hostname(host), err);
- goto out_err;
- }
-
- mmc_set_timing(host, MMC_TIMING_MMC_HS);
- err = mmc_switch_status(card, true);
- if (err)
- goto out_err;
-
- mmc_set_clock(host, card->ext_csd.hs_max_dtr);
-
- /* Switch card to DDR with strobe bit */
- val = EXT_CSD_DDR_BUS_WIDTH_8 | EXT_CSD_BUS_WIDTH_STROBE;
- err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_BUS_WIDTH,
-val,
-card->ext_csd.generic_cmd6_time);
- if (err) {
- pr_err("%s: switch to bus width for hs400es failed, err:%d\n",
- mmc_hostname(host), err);
- goto out_err;
- }
-
- mmc_select_driver_type(card);
-
- /* Switch card to HS400 */
- val = EXT_CSD_TIMING_HS400 |
- card->drive_strength << EXT_CSD_DRV_STR_SHIFT;
- err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_HS_TIMING, val,
- card->ext_csd.generic_cmd6_time, 0,
- false, true);
- if (err) {
- pr_err("%s: switch to hs400es failed, err:%d\n",
- mmc_hostname(host), err);
- goto out_err;
- }
-
- /* Set host controller to HS400 timing and frequency */
- mmc_set_timing(host, MMC_TIMING_MMC_HS400);
-
- /* Controller enable enhanced strobe function */
- host->ios.enhanced_strobe = true;
- if (host->ops->hs400_enhanced_strobe)
- host->ops->hs400_enhanced_strobe(host, >ios);
-
- err = mmc_switch_status(card, true);
- if (err)
- goto out_err;
-
- return 0;
-
-out_err:
- pr_err("%s: %s failed, error %d\n", mmc_hostname(card->host),
- __func__, err);
- return err;
-}
-
static int mmc_select_hs400(struct mmc_card *card, bool enhancedstrobe)
{
struct mmc_host *host = card->host;
--
2.20.1
[PATCH 0/6] mmc: core: hs400(es) fix probe/init
Fix the probe if hs400-1_8v / hs400-1_2v is used in the dts and mmc-hs400-enhanced-strobe isn't set. That was the first attemped, but it turns out that some more cleanups and simplifications can be done. * move mmc_select_hs400() in between hs200 & hs400es (preparation) * make mmc_select_hs400() independent and move it out of the hs200. Run hs400 tuning inside mmc_select_hs400(); * merge hs400 with hs400es function * remove mmc_select_hs400es function * remove mmc_hs200_tuning() * cleanup host->caps2 for hs400-1_8(2)v Signed-off-by: Chris Ruehl --- Replace patch set [PATCH 0/3] mmc: core: hs400 fix probe
[PATCH 1/6] mmc: core: prepare hs400 update, code order
This patch didn't change functionality just move
mmc_select_hs400() and mmc_hs200_to_hs400() between
mmc_select_hs400es() and mmc_select_hs200.
fix checkpatch --script warings.
Signed-off-by: Chris Ruehl
---
drivers/mmc/core/mmc.c | 184 -
1 file changed, 92 insertions(+), 92 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index ff3063ce2acd..5477786aded8 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1142,98 +1142,6 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
return err;
}
-static int mmc_select_hs400(struct mmc_card *card)
-{
- struct mmc_host *host = card->host;
- unsigned int max_dtr;
- int err = 0;
- u8 val;
-
- /*
-* HS400 mode requires 8-bit bus width
-*/
- if (!(card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
- host->ios.bus_width == MMC_BUS_WIDTH_8))
- return 0;
-
- /* Switch card to HS mode */
- val = EXT_CSD_TIMING_HS;
- err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_HS_TIMING, val,
- card->ext_csd.generic_cmd6_time, 0,
- false, true);
- if (err) {
- pr_err("%s: switch to high-speed from hs200 failed, err:%d\n",
- mmc_hostname(host), err);
- return err;
- }
-
- /* Prepare host to downgrade to HS timing */
- if (host->ops->hs400_downgrade)
- host->ops->hs400_downgrade(host);
-
- /* Set host controller to HS timing */
- mmc_set_timing(host, MMC_TIMING_MMC_HS);
-
- /* Reduce frequency to HS frequency */
- max_dtr = card->ext_csd.hs_max_dtr;
- mmc_set_clock(host, max_dtr);
-
- err = mmc_switch_status(card, true);
- if (err)
- goto out_err;
-
- if (host->ops->hs400_prepare_ddr)
- host->ops->hs400_prepare_ddr(host);
-
- /* Switch card to DDR */
- err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_BUS_WIDTH,
-EXT_CSD_DDR_BUS_WIDTH_8,
-card->ext_csd.generic_cmd6_time);
- if (err) {
- pr_err("%s: switch to bus width for hs400 failed, err:%d\n",
- mmc_hostname(host), err);
- return err;
- }
-
- /* Switch card to HS400 */
- val = EXT_CSD_TIMING_HS400 |
- card->drive_strength << EXT_CSD_DRV_STR_SHIFT;
- err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_HS_TIMING, val,
- card->ext_csd.generic_cmd6_time, 0,
- false, true);
- if (err) {
- pr_err("%s: switch to hs400 failed, err:%d\n",
-mmc_hostname(host), err);
- return err;
- }
-
- /* Set host controller to HS400 timing and frequency */
- mmc_set_timing(host, MMC_TIMING_MMC_HS400);
- mmc_set_bus_speed(card);
-
- if (host->ops->hs400_complete)
- host->ops->hs400_complete(host);
-
- err = mmc_switch_status(card, true);
- if (err)
- goto out_err;
-
- return 0;
-
-out_err:
- pr_err("%s: %s failed, error %d\n", mmc_hostname(card->host),
- __func__, err);
- return err;
-}
-
-int mmc_hs200_to_hs400(struct mmc_card *card)
-{
- return mmc_select_hs400(card);
-}
-
int mmc_hs400_to_hs200(struct mmc_card *card)
{
struct mmc_host *host = card->host;
@@ -1425,6 +1333,98 @@ static int mmc_select_hs400es(struct mmc_card *card)
return err;
}
+static int mmc_select_hs400(struct mmc_card *card)
+{
+ struct mmc_host *host = card->host;
+ unsigned int max_dtr;
+ int err = 0;
+ u8 val;
+
+ /*
+* HS400 mode requires 8-bit bus width
+*/
+ if (!(card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
+ host->ios.bus_width == MMC_BUS_WIDTH_8))
+ return 0;
+
+ /* Switch card to HS mode */
+ val = EXT_CSD_TIMING_HS;
+ err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_HS_TIMING, val,
+ card->ext_csd.generic_cmd6_time, 0,
+ false, true);
+ if (err) {
+ pr_err("%s: switch to high-speed from hs200 failed, err:%d\n",
+ mmc_hostname(host), err);
+ return err;
+ }
+
+ /* Prepare host to downgrade to HS timing */
+ if (host->ops->hs400_downgrade)
+ host->ops->hs400_downgrade(host);
+
+ /* Set host controller to HS timing */
+ mmc_set_timing(host, MMC_TIMING_MMC_HS);
+
+ /* Reduce frequency to HS frequency */
+ max_dtr = card->ext_csd.hs_max_dtr;
+ mmc_set_clock(host, max_dtr);
+
+ err =
[PATCH 6/6] mmc: core: with mmc-hs400-1_8(2)v not add MMC_CAP2_HS200* to host->caps2
When set mmc-hs400-1_8(2)v in dts, hs200 capabilities are not checked in the mmc logic. Thus cleanup and remove MMC_CAP2_HS200_1_8V_SDR / MMC_CAP2_HS200_1_2V_SDR from host->caps2. Signed-off-by: Chris Ruehl --- drivers/mmc/core/host.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index 96b2ca1f1b06..46fde60a2372 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -295,9 +295,9 @@ int mmc_of_parse(struct mmc_host *host) if (device_property_read_bool(dev, "mmc-hs200-1_2v")) host->caps2 |= MMC_CAP2_HS200_1_2V_SDR; if (device_property_read_bool(dev, "mmc-hs400-1_8v")) - host->caps2 |= MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR; + host->caps2 |= MMC_CAP2_HS400_1_8V; if (device_property_read_bool(dev, "mmc-hs400-1_2v")) - host->caps2 |= MMC_CAP2_HS400_1_2V | MMC_CAP2_HS200_1_2V_SDR; + host->caps2 |= MMC_CAP2_HS400_1_2V; if (device_property_read_bool(dev, "mmc-hs400-enhanced-strobe")) host->caps2 |= MMC_CAP2_HS400_ES; if (device_property_read_bool(dev, "no-sdio")) -- 2.20.1
RE: [PATCH v2 3/4] soc: samsung: exynos-chipid: order list of SoCs by name
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey
> Subject: [PATCH v2 3/4] soc: samsung: exynos-chipid: order list of SoCs by
> name
>
> Bring some order to the list of SoCs. No functional change.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/soc/samsung/exynos-chipid.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/samsung/exynos-chipid.c
> b/drivers/soc/samsung/exynos-chipid.c
> index 8d4d05086906..b4cd0cc00f45 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -20,6 +20,7 @@ static const struct exynos_soc_id {
> const char *name;
> unsigned int id;
> } soc_ids[] = {
> + /* List ordered by SoC name */
> { "EXYNOS3250", 0xE3472000 },
> { "EXYNOS4210", 0x4320 }, /* EVT0 revision */
> { "EXYNOS4210", 0x4321 },
> @@ -29,10 +30,10 @@ static const struct exynos_soc_id {
> { "EXYNOS5260", 0xE526 },
> { "EXYNOS5410", 0xE541 },
> { "EXYNOS5420", 0xE542 },
> + { "EXYNOS5433", 0xE5433000 },
> { "EXYNOS5440", 0xE544 },
> { "EXYNOS5800", 0xE5422000 },
> { "EXYNOS7420", 0xE742 },
> - { "EXYNOS5433", 0xE5433000 },
> };
>
> static const char * __init product_id_to_soc_id(unsigned int product_id)
> --
> 2.25.1
Reviewed-by: Pankaj Dubey
RE: [PATCH v2 2/4] soc: samsung: exynos-asv: handle reading revision register error
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey ; sta...@vger.kernel.org
> Subject: [PATCH v2 2/4] soc: samsung: exynos-asv: handle reading revision
> register error
>
> If regmap_read() fails, the product_id local variable will contain random
value
> from the stack. Do not try to parse such value and fail the ASV driver
probe.
>
> Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage
> driver")
> Cc:
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/soc/samsung/exynos-asv.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/samsung/exynos-asv.c
> b/drivers/soc/samsung/exynos-asv.c
> index f653e3533f0f..5daeadc36382 100644
> --- a/drivers/soc/samsung/exynos-asv.c
> +++ b/drivers/soc/samsung/exynos-asv.c
> @@ -129,7 +129,13 @@ static int exynos_asv_probe(struct platform_device
> *pdev)
> return PTR_ERR(asv->chipid_regmap);
> }
>
> - regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID,
> _id);
> + ret = regmap_read(asv->chipid_regmap,
> EXYNOS_CHIPID_REG_PRO_ID,
> + _id);
> + if (ret < 0) {
> + dev_err(>dev, "Cannot read revision from
> ChipID: %d\n",
> + ret);
> + return -ENODEV;
> + }
>
> switch (product_id & EXYNOS_MASK) {
> case 0xE5422000:
> --
> 2.25.1
Reviewed-by: Pankaj Dubey
Re: [PATCH V5 5/5] PCI: tegra: Disable LTSSM during L2 entry
On 12/8/2020 2:07 AM, Bjorn Helgaas wrote:
External email: Use caution opening links or attachments
[+cc Jingoo, Gustavo]
On Thu, Dec 03, 2020 at 07:04:51PM +0530, Vidya Sagar wrote:
PCIe cards like Marvell SATA controller and some of the Samsung NVMe
drives don't support taking the link to L2 state. When the link doesn't
go to L2 state, Tegra194 requires the LTSSM to be disabled to allow PHY
to start the next link up process cleanly during suspend/resume sequence.
Failing to disable LTSSM results in the PCIe link not coming up in the
next resume cycle.
Is this a Tegra194-specific issue, or will other DWC-based controllers
need a similar change?
This is a Tegra194 specific issue.
Thanks,
Vidya Sagar
Tested-by: Thierry Reding
Signed-off-by: Vidya Sagar
Acked-by: Thierry Reding
---
V5:
* Added Tested-by and Acked-by from Thierry Reding
V4:
* New patch in this series
drivers/pci/controller/dwc/pcie-tegra194.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
b/drivers/pci/controller/dwc/pcie-tegra194.c
index f4109d71f20b..5597b2a49598 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1506,6 +1506,14 @@ static void tegra_pcie_dw_pme_turnoff(struct
tegra_pcie_dw *pcie)
data &= ~APPL_PINMUX_PEX_RST;
appl_writel(pcie, data, APPL_PINMUX);
+ /*
+ * Some cards do not go to detect state even after de-asserting
+ * PERST#. So, de-assert LTSSM to bring link to detect state.
+ */
+ data = readl(pcie->appl_base + APPL_CTRL);
+ data &= ~APPL_CTRL_LTSSM_EN;
+ writel(data, pcie->appl_base + APPL_CTRL);
+
err = readl_poll_timeout_atomic(pcie->appl_base + APPL_DEBUG,
data,
((data &
@@ -1513,14 +1521,8 @@ static void tegra_pcie_dw_pme_turnoff(struct
tegra_pcie_dw *pcie)
APPL_DEBUG_LTSSM_STATE_SHIFT) ==
LTSSM_STATE_PRE_DETECT,
1, LTSSM_TIMEOUT);
- if (err) {
+ if (err)
dev_info(pcie->dev, "Link didn't go to detect state\n");
- } else {
- /* Disable LTSSM after link is in detect state */
- data = appl_readl(pcie, APPL_CTRL);
- data &= ~APPL_CTRL_LTSSM_EN;
- appl_writel(pcie, data, APPL_CTRL);
- }
}
/*
* DBI registers may not be accessible after this as PLL-E would be
--
2.17.1
[PATCH] x86/platform: classmate-laptop: add WiFi media button
From: Carlo Caione
The WiFi media button on the Quanta NL3 reports keycodes 0x8b and 0x9b
to the platform driver. Add the mapping to support these codes.
Signed-off-by: Carlo Caione
Reviewed-by: Chris Chiu
---
drivers/platform/x86/classmate-laptop.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/platform/x86/classmate-laptop.c
b/drivers/platform/x86/classmate-laptop.c
index af063f690846..3e03e8d3a07f 100644
--- a/drivers/platform/x86/classmate-laptop.c
+++ b/drivers/platform/x86/classmate-laptop.c
@@ -1023,6 +1023,8 @@ static int cmpc_keys_codes[] = {
KEY_CAMERA,
KEY_BACK,
KEY_FORWARD,
+ KEY_UNKNOWN,
+ KEY_WLAN, /* NL3: 0x8b (press), 0x9b (release) */
KEY_MAX
};
--
2.20.1
Re: [f2fs-dev] [PATCH v3] f2fs: fix race of pending_pages in decompression
On Tue, Dec 08, 2020 at 08:51:45AM +0900, Daeho Jeong wrote: > > I am trying to review this but it is very hard, as the f2fs compression > > code is > > very hard to understand. > > > > It looks like a 'struct decompress_io_ctx' represents the work to > > decompress a > > particular cluster. Since the compressed data of the cluster can be read > > using > > multiple bios, there is a reference count of how many pages are remaining > > to be > > read before all the cluster's pages have been read and decompression can > > start. > > > > What I don't understand is why that reference counting needs to work > > differently > > depending on whether verity is enabled or not. Shouldn't it be exactly the > > same? > > > > There also seems to be some confusion about the scope of STEP_VERITY. > > Before > > f2fs compression was added, it was a per-bio thing. But now in a compressed > > file, it's really a per-cluster thing, since all decompressed pages in a > > compressed cluster are verified (or not verified) at once. > > > > Wouldn't it make a lot more sense to, when a cluster needs both compression > > and > > verity, *not* set STEP_VERITY on the bios, but rather set a similar flag in > > the > > decompress_io_ctx? > > > > Eric, > > Decompression and verity can be executed in different thread contexts > in different timing, so we need separate counts for each. > > We already use STEP_VERITY for non-compression case, so I think using > this flag in here looks more making sense. > > Thanks, That didn't really answer my questions. I gave up trying to review this patch as the compression post-read handling is just way too weird and hard to understand. I wrote a patch to clean it all up instead, please take a look: https://lkml.kernel.org/r/20201208060328.2237091-1-ebigg...@kernel.org - Eric
Re: [PATCH v12 0/5] Simplify PCIe native ownership
Hi Bjorn, On 11/30/20 5:11 PM, Kuppuswamy, Sathyanarayanan wrote: Hi Bjorn, On 11/25/20 7:48 PM, Kuppuswamy, Sathyanarayanan wrote: Along with above patch, you also left following two cleanup patches. Is this intentional? Following fixes have no dependency on pcie_ports_dpc_native change. [PATCH v11 4/5] PCI/portdrv: Remove redundant pci_aer_available() check in DPC enable logic [PATCH v11 5/5] PCI/DPC: Move AER/DPC dependency checks out of DPC driver Any comment? If you want me to add these patches in my re-submission, please let me know. Gentle ping. Any comments? -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
[PATCH] ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140
Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing,
thus the heaset functions are not working.
Add quirk for this model to select the correct input map, jack-detect
options and channel map to enable jack sensing and headset microphone.
This device uses IN1 for its internal MIC and JD2 for jack-detect.
Signed-off-by: Chris Chiu
---
sound/soc/intel/boards/bytcr_rt5640.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c
b/sound/soc/intel/boards/bytcr_rt5640.c
index f790514a147d..cd6f7caa43c8 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -421,6 +421,18 @@ static const struct dmi_system_id byt_rt5640_quirk_table[]
= {
BYT_RT5640_SSP0_AIF1 |
BYT_RT5640_MCLK_EN),
},
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ARCHOS"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ARCHOS 140 CESIUM"),
+ },
+ .driver_data = (void *)(BYT_RT5640_IN1_MAP |
+ BYT_RT5640_JD_SRC_JD2_IN4N |
+ BYT_RT5640_OVCD_TH_2000UA |
+ BYT_RT5640_OVCD_SF_0P75 |
+ BYT_RT5640_SSP0_AIF1 |
+ BYT_RT5640_MCLK_EN),
+ },
{
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER
INC."),
--
2.20.1
RE: [PATCH v10 3/7] i3c: master: add i3c_secondary_master_register
>I'm not sure about the logic here. Why would the secondary master >initialize the bus? If you make a distinction between primary and >secondary, then the primary should be the owner of the bus and it should >have enumerated it already. You should populate the bus structure with >info provided by the primary master not from DT? Here the bus initialization means programming HW for communicating over I3C bus and initializing i3c_master_controller object, which is needed for both primary and secondary masters. Yes, primary master is initial bus master, it assign addresses to each device detected on I3C bus in DAA and broadcast the list through DEFSLVS, which is used by secondary masters during their remaining initialization. Initial approach was to allow secondary master to get information about devices on bus from DEFSLVS only, but it was later decided that secondary master should parse DT as well for any I2C and I3C device information. Regards, Parshuram Thombare
RE: [PATCH v2 1/4] soc: samsung: exynos-asv: don't defer early on not-supported SoCs
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey ; sta...@vger.kernel.org
> Subject: [PATCH v2 1/4] soc: samsung: exynos-asv: don't defer early on
not-
> supported SoCs
>
> From: Marek Szyprowski
>
> Check if the SoC is really supported before gathering the needed
resources.
> This fixes endless deferred probe on some SoCs other than
> Exynos5422 (like Exynos5410).
>
> Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage
> driver")
> Cc:
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/soc/samsung/exynos-asv.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/samsung/exynos-asv.c
> b/drivers/soc/samsung/exynos-asv.c
> index 8abf4dfaa5c5..f653e3533f0f 100644
> --- a/drivers/soc/samsung/exynos-asv.c
> +++ b/drivers/soc/samsung/exynos-asv.c
> @@ -119,11 +119,6 @@ static int exynos_asv_probe(struct platform_device
> *pdev)
> u32 product_id = 0;
> int ret, i;
>
> - cpu_dev = get_cpu_device(0);
> - ret = dev_pm_opp_get_opp_count(cpu_dev);
> - if (ret < 0)
> - return -EPROBE_DEFER;
> -
> asv = devm_kzalloc(>dev, sizeof(*asv), GFP_KERNEL);
> if (!asv)
> return -ENOMEM;
> @@ -144,6 +139,11 @@ static int exynos_asv_probe(struct platform_device
> *pdev)
> return -ENODEV;
> }
>
> + cpu_dev = get_cpu_device(0);
> + ret = dev_pm_opp_get_opp_count(cpu_dev);
> + if (ret < 0)
> + return -EPROBE_DEFER;
> +
> ret = of_property_read_u32(pdev->dev.of_node, "samsung,asv-
> bin",
> >of_bin);
> if (ret < 0)
> --
> 2.25.1
Reviewed-by: Pankaj Dubey
[PATCH] [v10] wireless: Initial driver submission for pureLiFi STA devices
This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC and LiFi-XL USB devices. This driver implementation has been based on the zd1211rw driver. Driver is based on 802.11 softMAC Architecture and uses native 802.11 for configuration and management. The driver is compiled and tested in ARM, x86 architectures and compiled in powerpc architecture. Signed-off-by: Srinivasan Raju --- v10: - Addressed review comment on readability - Changed firmware names to match products v9: - Addressed review comments on style and content defects - Used kmemdup instead of alloc and memcpy v7 , v8: - Magic numbers removed and used IEEE80211 macors - usb.c is split into two files firmware.c and dbgfs.c - Other code style and timer function fixes (mod_timer) v6: - Code style fix patch from Joe Perches v5: - Code refactoring for clarity and redundnacy removal - Fix warnings from kernel test robot v4: - Code refactoring based on kernel code guidelines - Remove multi level macors and use kernel debug macros v3: - Code style fixes kconfig fix v2: - Driver submitted to wireless-next - Code style fixes and copyright statement fix v1: - Driver submitted to staging --- MAINTAINERS |5 + drivers/net/wireless/Kconfig |1 + drivers/net/wireless/Makefile|1 + drivers/net/wireless/purelifi/Kconfig| 27 + drivers/net/wireless/purelifi/Makefile |3 + drivers/net/wireless/purelifi/chip.c | 93 ++ drivers/net/wireless/purelifi/chip.h | 81 ++ drivers/net/wireless/purelifi/dbgfs.c| 150 +++ drivers/net/wireless/purelifi/firmware.c | 384 drivers/net/wireless/purelifi/intf.h | 38 + drivers/net/wireless/purelifi/mac.c | 873 ++ drivers/net/wireless/purelifi/mac.h | 189 drivers/net/wireless/purelifi/usb.c | 1075 ++ drivers/net/wireless/purelifi/usb.h | 199 14 files changed, 3119 insertions(+) create mode 100644 drivers/net/wireless/purelifi/Kconfig create mode 100644 drivers/net/wireless/purelifi/Makefile create mode 100644 drivers/net/wireless/purelifi/chip.c create mode 100644 drivers/net/wireless/purelifi/chip.h create mode 100644 drivers/net/wireless/purelifi/dbgfs.c create mode 100644 drivers/net/wireless/purelifi/firmware.c create mode 100644 drivers/net/wireless/purelifi/intf.h create mode 100644 drivers/net/wireless/purelifi/mac.c create mode 100644 drivers/net/wireless/purelifi/mac.h create mode 100644 drivers/net/wireless/purelifi/usb.c create mode 100644 drivers/net/wireless/purelifi/usb.h diff --git a/MAINTAINERS b/MAINTAINERS index c80f87d7258c..17955b8497df 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14108,6 +14108,11 @@ T: git git://linuxtv.org/media_tree.git F: Documentation/admin-guide/media/pulse8-cec.rst F: drivers/media/cec/usb/pulse8/ +PUREILIFI USB DRIVER +M: Srinivasan Raju +S: Supported +F: drivers/net/wireless/purelifi + PVRUSB2 VIDEO4LINUX DRIVER M: Mike Isely L: pvru...@isely.net (subscribers-only) diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index 170a64e67709..b87da3139f94 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -48,6 +48,7 @@ source "drivers/net/wireless/st/Kconfig" source "drivers/net/wireless/ti/Kconfig" source "drivers/net/wireless/zydas/Kconfig" source "drivers/net/wireless/quantenna/Kconfig" +source "drivers/net/wireless/purelifi/Kconfig" config PCMCIA_RAYCS tristate "Aviator/Raytheon 2.4GHz wireless support" diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile index 80b324499786..e9fc770026f0 100644 --- a/drivers/net/wireless/Makefile +++ b/drivers/net/wireless/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_WLAN_VENDOR_ST) += st/ obj-$(CONFIG_WLAN_VENDOR_TI) += ti/ obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/ obj-$(CONFIG_WLAN_VENDOR_QUANTENNA) += quantenna/ +obj-$(CONFIG_WLAN_VENDOR_PURELIFI) += purelifi/ # 16-bit wireless PCMCIA client drivers obj-$(CONFIG_PCMCIA_RAYCS) += ray_cs.o diff --git a/drivers/net/wireless/purelifi/Kconfig b/drivers/net/wireless/purelifi/Kconfig new file mode 100644 index ..f6630791df9d --- /dev/null +++ b/drivers/net/wireless/purelifi/Kconfig @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0 +config WLAN_VENDOR_PURELIFI + bool "pureLiFi devices" + default y + help + If you have a pureLiFi device, say Y. + + Note that the answer to this question doesn't directly affect the + kernel: saying N will just cause the configurator to skip all the + questions about these cards. If you say Y, you will be asked for + your specific card in the following questions. + +if WLAN_VENDOR_PURELIFI + +config PURELIFI + + tristate "pureLiFi device support" + depends on CFG80211 && MAC80211 && USB + help + This driver makes the adapter appear as a
Re: [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM
On 02-12-20, 17:23, Nicola Mazzucato wrote:
> By design, SCMI performance domains define the granularity of
> performance controls, they do not describe any underlying hardware
> dependencies (although they may match in many cases).
>
> It is therefore possible to have some platforms where hardware may have
> the ability to control CPU performance at different granularity and choose
> to describe fine-grained performance control through SCMI.
>
> In such situations, the energy model would be provided with inaccurate
> information based on controls, while it still needs to know the
> performance boundaries.
>
> To restore correct functionality, retrieve information of CPUs under the
> same v/f domain from operating-points-v2 in DT, and pass it on to EM.
>
> Signed-off-by: Nicola Mazzucato
> ---
> drivers/cpufreq/scmi-cpufreq.c | 51 +++---
> 1 file changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 491a0a24fb1e..f505efcc62b1 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -127,6 +127,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy
> *policy)
> struct cpufreq_frequency_table *freq_table;
> struct em_data_callback em_cb = EM_DATA_CB(scmi_get_cpu_power);
> bool power_scale_mw;
> + cpumask_var_t opp_shared_cpus;
>
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> @@ -134,30 +135,45 @@ static int scmi_cpufreq_init(struct cpufreq_policy
> *policy)
> return -ENODEV;
> }
>
> - ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
> - if (ret) {
> - dev_warn(cpu_dev, "failed to add opps to the device\n");
> - return ret;
> - }
> + if (!zalloc_cpumask_var(_shared_cpus, GFP_KERNEL))
> + return -ENOMEM;
>
> ret = scmi_get_sharing_cpus(cpu_dev, policy->cpus);
> if (ret) {
> dev_warn(cpu_dev, "failed to get sharing cpumask\n");
> - return ret;
> + goto out_free_cpumask;
> }
>
> - ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
> - if (ret) {
> - dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n",
> - __func__, ret);
> - return ret;
> + /*
> + * The OPP 'sharing cpus' info may come from dt through an empty opp
> + * table and opp-shared. If found, it takes precedence over the SCMI
> + * domain IDs info.
> + */
> + ret = dev_pm_opp_of_get_sharing_cpus(cpu_dev, opp_shared_cpus);
> + if (ret || !cpumask_weight(opp_shared_cpus)) {
> + /*
> + * Either opp-table is not set or no opp-shared was found,
> + * use the information from SCMI domain IDs.
> + */
> + cpumask_copy(opp_shared_cpus, policy->cpus);
> }
>
> nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> if (nr_opp <= 0) {
> - dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
> - ret = -EPROBE_DEFER;
> - goto out_free_opp;
> + ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
> + if (ret) {
> + dev_warn(cpu_dev, "failed to add opps to the device\n");
> + goto out_free_cpumask;
> + }
> +
> + ret = dev_pm_opp_set_sharing_cpus(cpu_dev, opp_shared_cpus);
> + if (ret) {
> + dev_err(cpu_dev, "%s: failed to mark OPPs as shared:
> %d\n",
> + __func__, ret);
> + goto out_free_cpumask;
> + }
> +
Why do we need to call above two after calling
dev_pm_opp_get_opp_count() ? And we don't check the return value of
the below call anymore, moreover we have to call it twice now.
> + nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> }
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> @@ -191,15 +207,18 @@ static int scmi_cpufreq_init(struct cpufreq_policy
> *policy)
> handle->perf_ops->fast_switch_possible(handle, cpu_dev);
>
> power_scale_mw = handle->perf_ops->power_scale_mw_get(handle);
> - em_dev_register_perf_domain(cpu_dev, nr_opp, _cb, policy->cpus,
> + em_dev_register_perf_domain(cpu_dev, nr_opp, _cb, opp_shared_cpus,
> power_scale_mw);
>
> - return 0;
> + ret = 0;
ret is already 0 here.
> + goto out_free_cpumask;
>
> out_free_priv:
> kfree(priv);
> out_free_opp:
> dev_pm_opp_remove_all_dynamic(cpu_dev);
> +out_free_cpumask:
> + free_cpumask_var(opp_shared_cpus);
>
> return ret;
> }
> --
> 2.27.0
--
viresh
[PATCH v1] scsi: ufs: Ensure WriteBooster to be re-enabled after device reset
UFS 3.1 specification mentions that below WriteBooster flags will be
set to default value, say disabled, after power cycle or any type
of reset event. Thus we need to reset those flag variables kept
in struct hba to align the device status and ensure WriteBooster
related functions being configured properly after device reset.
Without this fix, WriteBooster will not be enabled successfully
by ufshcd_wb_ctrl() after device reset because hba->wb_enabled
remains as true.
Flags required to be reset to default values:
- fWriteBoosterEn: hba->wb_enabled
- fWriteBoosterBufferFlushEn: hba->wb_buf_flush_enabled
- fWriteBoosterBufferFlushDuringHibernate: No variable mapped
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 7a7e056a33a9..c22887bee788 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -1218,8 +1218,11 @@ static inline void ufshcd_vops_device_reset(struct
ufs_hba *hba)
if (hba->vops && hba->vops->device_reset) {
int err = hba->vops->device_reset(hba);
- if (!err)
+ if (!err) {
ufshcd_set_ufs_dev_active(hba);
+ hba->wb_enabled = false;
+ hba->wb_buf_flush_enabled = false;
+ }
if (err != -EOPNOTSUPP)
ufshcd_update_reg_hist(>ufs_stats.dev_reset, err);
}
--
2.18.0
RE: [PATCH v10 2/7] i3c: master: use i3c_master_register only for main master
>This looks a bit confusing. Here you're rolling back detailss in >i3c_primary_master_register() that were factored out in >i3c_master_init(). If i3c_master_init() is successful, then you >shouldn't be undoing its things openly in i3c_primary_master_register(). >Instead, there should be another function that does the reverse of >i3c_master_init() here. Every function do its cleanup in case of failures. And if any failure occur after successful i3c_master_init(), we have function i3c_master_bus_cleanup() which does the major cleanup. Regards, Parshuram Thombare
Re: [RFC PATCH] drm/panel: Make backlight attachment lazy
Hi Bjorn,
On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote:
> Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
> means of generating a PWM signal for backlight control of the attached
> panel. The provided PWM chip is typically controlled by the
> pwm-backlight driver, which if tied to the panel will provide DPMS.
>
> But with the current implementation the panel will refuse to probe
> because the bridge driver has yet to probe and register the PWM chip,
> and the bridge driver will refuse to probe because it's unable to find
> the panel.
>
> Mitigate this catch-22 situation by allowing the panel driver to probe
> and retry the attachment of the backlight as the panel is turned on or
> off.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/gpu/drm/drm_panel.c | 47 +++--
> include/drm/drm_panel.h | 8 +++
> 2 files changed, 43 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index f634371c717a..7487329bd22d 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -43,6 +43,34 @@ static LIST_HEAD(panel_list);
> * take look at drm_panel_bridge_add() and devm_drm_panel_bridge_add().
> */
>
> +#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +static int drm_panel_of_backlight_lazy(struct drm_panel *panel)
> +{
> + struct backlight_device *backlight;
> +
> + if (!panel || !panel->dev)
> + return -EINVAL;
> +
> + backlight = devm_of_find_backlight(panel->dev);
> +
> + if (IS_ERR(backlight)) {
> + if (PTR_ERR(backlight) == -EPROBE_DEFER) {
> + panel->backlight_init_pending = true;
> + return 0;
> + }
> +
> + return PTR_ERR(backlight);
Use dev_err_probe()
> + }
> +
> + panel->backlight = backlight;
> + panel->backlight_init_pending = false;
> +
> + return 0;
> +}
> +#else
> +static int drm_panel_of_backlight_lazy(struct drm_panel *panel) { return 0; }
> +#endif
> +
> /**
> * drm_panel_init - initialize a panel
> * @panel: DRM panel
> @@ -161,6 +189,9 @@ int drm_panel_enable(struct drm_panel *panel)
> return ret;
> }
>
> + if (panel->backlight_init_pending)
> + drm_panel_of_backlight_lazy(panel);
> +
> ret = backlight_enable(panel->backlight);
> if (ret < 0)
> DRM_DEV_INFO(panel->dev, "failed to enable backlight: %d\n",
> @@ -187,6 +218,9 @@ int drm_panel_disable(struct drm_panel *panel)
> if (!panel)
> return -EINVAL;
>
> + if (panel->backlight_init_pending)
> + drm_panel_of_backlight_lazy(panel);
> +
> ret = backlight_disable(panel->backlight);
> if (ret < 0)
> DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
> @@ -328,18 +362,7 @@ EXPORT_SYMBOL(of_drm_get_panel_orientation);
> */
> int drm_panel_of_backlight(struct drm_panel *panel)
> {
> - struct backlight_device *backlight;
> -
> - if (!panel || !panel->dev)
> - return -EINVAL;
> -
> - backlight = devm_of_find_backlight(panel->dev);
> -
> - if (IS_ERR(backlight))
> - return PTR_ERR(backlight);
> -
> - panel->backlight = backlight;
> - return 0;
> + return drm_panel_of_backlight_lazy(panel);
Could you update the drm_panel_of_backlight() implementation (and
do not forget the documentation) and avoid drm_panel_of_backlight_lazy()?
Sam
> }
> EXPORT_SYMBOL(drm_panel_of_backlight);
> #endif
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 33605c3f0eba..b126abebb2f3 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -149,6 +149,14 @@ struct drm_panel {
>*/
> struct backlight_device *backlight;
>
> + /**
> + * @backlight_init_pending
> + *
> + * Backlight driver is not yet available so further attempts to
> + * initialize @backlight is necessary.
> + */
> + bool backlight_init_pending;
> +
We have not done so today for other fields, but it would be good
to document this is for drm_panel use only and drivers shall not touch.
Sam
[PATCH v2] firmware_loader: Align .builtin_fw to 8
arm64 references the start address of .builtin_fw (__start_builtin_fw)
with a pair of R_AARCH64_ADR_PREL_PG_HI21/R_AARCH64_LDST64_ABS_LO12_NC
relocations. The compiler is allowed to emit the
R_AARCH64_LDST64_ABS_LO12_NC relocation because struct builtin_fw in
include/linux/firmware.h is 8-byte aligned.
The R_AARCH64_LDST64_ABS_LO12_NC relocation requires the address to be a
multiple of 8, which may not be the case if .builtin_fw is empty.
Unconditionally align .builtin_fw to fix the linker error. 32-bit
architectures could use ALIGN(4) but that would add unnecessary
complexity, so just use ALIGN(8).
Fixes: 5658c76 ("firmware: allow firmware files to be built into kernel image")
Link: https://github.com/ClangBuiltLinux/linux/issues/1204
Reported-by: kernel test robot
Signed-off-by: Fangrui Song
Acked-by: Arnd Bergmann
---
Change in v2:
* Use output section alignment instead of inappropriate ALIGN_FUNCTION()
---
include/asm-generic/vmlinux.lds.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index b2b3d81b1535..b97c628ad91f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -459,7 +459,7 @@
} \
\
/* Built-in firmware blobs */ \
- .builtin_fw: AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \
+ .builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) ALIGN(8) {\
__start_builtin_fw = .; \
KEEP(*(.builtin_fw))\
__end_builtin_fw = .; \
--
2.29.2.576.ga3fc446d84-goog
