Re: [PATCH 4/4] MMC: Ingenic: Add support for JZ4760 and support for LPM.
Hi Uffe, On 2019年10月03日 18:00, Ulf Hansson wrote: On Thu, 5 Sep 2019 at 09:40, Zhou Yanjie wrote: 1.add support for probing mmc driver on the JZ4760 Soc from Ingenic. 2.add support for Low Power Mode of Ingenic's MMC/SD Controller. Normally we try to make "one" change per patch, unless there are some good reasons not to. In this case, it seems like you should rather split this patch into two separate pieces. Can you please do that? OK,I'll split it in v2. Additionally, please change the prefix for the commit message header to start with "mmc: jz4740:" sure, it will be change in v2. [...] Kind regards Uffe Thanks and best regards!
Re: staging: vt6655: Fix memory leak in vt6655_probe
>>> In vt6655_probe, if vnt_init() fails the cleanup code needs to be called >>> like other error handling cases. The call to device_free_info() is >>> added. >> >> Please improve this change description. > > It is fine as-is, please do not confuse people. Would you like to clarify a known guideline once more? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=43b815c6a8e7dbccb5b8bd9c4b099c24bc22d135#n151 “… Describe your changes in imperative mood, …” Regards, Markus
[PATCH v3 6/8] drivers: provide devm_platform_ioremap_resource_byname()
From: Bartosz Golaszewski
Provide a variant of devm_platform_ioremap_resource() that allows to
lookup resources from platform devices by name rather than by index.
Signed-off-by: Bartosz Golaszewski
---
.../driver-api/driver-model/devres.rst| 1 +
drivers/base/platform.c | 20 +++
include/linux/platform_device.h | 3 +++
3 files changed, 24 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst
b/Documentation/driver-api/driver-model/devres.rst
index 480b78ca3871..4ab193319d8c 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -319,6 +319,7 @@ IOMAP
devm_ioremap_resource_wc()
devm_platform_ioremap_resource() : calls devm_ioremap_resource() for
platform device
devm_platform_ioremap_resource_wc()
+ devm_platform_ioremap_resource_byname()
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d481b8a7d4fc..265d34253865 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -95,6 +95,26 @@ void __iomem *devm_platform_ioremap_resource_wc(struct
platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, index);
return devm_ioremap_resource_wc(>dev, res);
}
+
+/**
+ * devm_platform_ioremap_resource_byname - call devm_ioremap_resource for
+ *a platform device, retrieve the
+ *resource by name
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ * resource management
+ * @name: name of the resource
+ */
+void __iomem *
+devm_platform_ioremap_resource_byname(struct platform_device *pdev,
+ const char *name)
+{
+ struct resource *res;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
+ return devm_ioremap_resource(>dev, res);
+}
+EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname);
#endif /* CONFIG_HAS_IOMEM */
static int __platform_get_irq(struct platform_device *dev, unsigned int num)
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 83930790c701..fea5563f6fcf 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -60,6 +60,9 @@ devm_platform_ioremap_resource(struct platform_device *pdev,
extern void __iomem *
devm_platform_ioremap_resource_wc(struct platform_device *pdev,
unsigned int index);
+extern void __iomem *
+devm_platform_ioremap_resource_byname(struct platform_device *pdev,
+ const char *name);
extern int platform_get_irq(struct platform_device *, unsigned int);
extern int platform_get_irq_optional(struct platform_device *, unsigned int);
extern int platform_irq_count(struct platform_device *);
--
2.23.0
[PATCH v3 4/8] drivers: platform: provide devm_platform_ioremap_resource_wc()
From: Bartosz Golaszewski
Provide a write-combined variant of devm_platform_ioremap_resource().
Signed-off-by: Bartosz Golaszewski
---
.../driver-api/driver-model/devres.rst| 1 +
drivers/base/platform.c | 19 ++-
include/linux/platform_device.h | 3 +++
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/driver-api/driver-model/devres.rst
b/Documentation/driver-api/driver-model/devres.rst
index e605bb9df6e1..480b78ca3871 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -318,6 +318,7 @@ IOMAP
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_ioremap_resource_wc()
devm_platform_ioremap_resource() : calls devm_ioremap_resource() for
platform device
+ devm_platform_ioremap_resource_wc()
devm_iounmap()
pcim_iomap()
pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b6c6c7d97d5b..d481b8a7d4fc 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -60,6 +60,7 @@ struct resource *platform_get_resource(struct platform_device
*dev,
}
EXPORT_SYMBOL_GPL(platform_get_resource);
+#ifdef CONFIG_HAS_IOMEM
/**
* devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
* device
@@ -68,7 +69,6 @@ EXPORT_SYMBOL_GPL(platform_get_resource);
*resource management
* @index: resource index
*/
-#ifdef CONFIG_HAS_IOMEM
void __iomem *devm_platform_ioremap_resource(struct platform_device *pdev,
unsigned int index)
{
@@ -78,6 +78,23 @@ void __iomem *devm_platform_ioremap_resource(struct
platform_device *pdev,
return devm_ioremap_resource(>dev, res);
}
EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource);
+
+/**
+ * devm_platform_ioremap_resource_wc - write-combined variant of
+ * devm_platform_ioremap_resource()
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ *resource management
+ * @index: resource index
+ */
+void __iomem *devm_platform_ioremap_resource_wc(struct platform_device *pdev,
+ unsigned int index)
+{
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, index);
+ return devm_ioremap_resource_wc(>dev, res);
+}
#endif /* CONFIG_HAS_IOMEM */
static int __platform_get_irq(struct platform_device *dev, unsigned int num)
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 1b5cec067533..83930790c701 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -57,6 +57,9 @@ platform_find_device_by_driver(struct device *start,
extern void __iomem *
devm_platform_ioremap_resource(struct platform_device *pdev,
unsigned int index);
+extern void __iomem *
+devm_platform_ioremap_resource_wc(struct platform_device *pdev,
+ unsigned int index);
extern int platform_get_irq(struct platform_device *, unsigned int);
extern int platform_get_irq_optional(struct platform_device *, unsigned int);
extern int platform_irq_count(struct platform_device *);
--
2.23.0
Re: [PATCH] lib: test_user_copy: style cleanup
On Sun, Oct 06, 2019 at 10:30:28AM +1100, Aleksa Sarai wrote:
> While writing the tests for copy_struct_from_user(), I used a construct
> that Linus doesn't appear to be too fond of:
>
> On 2019-10-04, Linus Torvalds wrote:
> > Hmm. That code is ugly, both before and after the fix.
> >
> > This just doesn't make sense for so many reasons:
> >
> > if ((ret |= test(umem_src == NULL, "kmalloc failed")))
> >
> > where the insanity comes from
> >
> > - why "|=" when you know that "ret" was zero before (and it had to
> >be, for the test to make sense)
> >
> > - why do this as a single line anyway?
> >
> > - don't do the stupid "double parenthesis" to hide a warning. Make it
> >use an actual comparison if you add a layer of parentheses.
>
> So instead, use a bog-standard check that isn't nearly as ugly.
>
> Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in
> test_copy_struct_from_user")
> Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Signed-off-by: Aleksa Sarai
I assume the comment diff is a line length/alignment thing? The commit
message does not mention it.
Regardless, thank you for providing the fix that I should have.
Reviewed-by: Nathan Chancellor
Re: [PATCH net] net: dsa: b53: Do not clear existing mirrored port mask
On Sat, 5 Oct 2019 15:05:18 -0700, Florian Fainelli
wrote:
> Clearing the existing bitmask of mirrored ports essentially prevents us
> from capturing more than one port at any given time. This is clearly
> wrong, do not clear the bitmask prior to setting up the new port.
>
> Reported-by: Hubert Feurstein
> Fixes: ed3af5fd08eb ("net: dsa: b53: Add support for port mirroring")
> Signed-off-by: Florian Fainelli
Reviewed-by: Vivien Didelot
[PATCH] pwm: Fix kerneldoc for apply operation
As the @state passed to apply() is now const the comment in the
kerneldoc about drivers being expected to adjust the parameters is no
longer valid. Update it to reflect the API change.
Fixes: 71523d1812ac ("pwm: Ensure pwm_apply_state() doesn't modify the state
argument")
Signed-off-by: Bjorn Andersson
---
include/linux/pwm.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index b2c9c460947d..8bc86f645d0d 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -243,10 +243,7 @@ pwm_set_relative_duty_cycle(struct pwm_state *state,
unsigned int duty_cycle,
* @request: optional hook for requesting a PWM
* @free: optional hook for freeing a PWM
* @capture: capture and report PWM signal
- * @apply: atomically apply a new PWM config. The state argument
- *should be adjusted with the real hardware config (if the
- *approximate the period or duty_cycle value, state should
- *reflect it)
+ * @apply: atomically apply a new PWM config.
* @get_state: get the current PWM state. This function is only
*called once per PWM device when the PWM chip is
*registered.
--
2.18.0
[PATCH] z3fold: add inter-page compaction
From: Vitaly Wool
For each page scheduled for compaction (e. g. by z3fold_free()),
try to apply inter-page compaction before running the traditional/
existing intra-page compaction. That means, if the page has only one
buddy, we treat that buddy as a new object that we aim to place into
an existing z3fold page. If such a page is found, that object is
transferred and the old page is freed completely. The transferred
object is named "foreign" and treated slightly differently thereafter.
Namely, we increase "foreign handle" counter for the new page. Pages
with non-zero "foreign handle" count become unmovable. This patch
implements "foreign handle" detection when a handle is freed to
decrement the foreign handle counter accordingly, so a page may as
well become movable again as the time goes by.
As a result, we almost always have exactly 3 objects per page and
significantly better average compression ratio.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 363 +---
1 file changed, 291 insertions(+), 72 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 6d3d3f698ebb..25713a4a7186 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -90,6 +91,7 @@ struct z3fold_buddy_slots {
*/
unsigned long slot[BUDDY_MASK + 1];
unsigned long pool; /* back link + flags */
+ rwlock_t lock;
};
#define HANDLE_FLAG_MASK (0x03)
@@ -124,6 +126,7 @@ struct z3fold_header {
unsigned short start_middle;
unsigned short first_num:2;
unsigned short mapped_count:2;
+ unsigned short foreign_handles:2;
};
/**
@@ -178,6 +181,19 @@ enum z3fold_page_flags {
PAGE_CLAIMED, /* by either reclaim or free */
};
+/*
+ * handle flags, go under HANDLE_FLAG_MASK
+ */
+enum z3fold_handle_flags {
+ HANDLES_ORPHANED = 0,
+};
+
+/*
+ * Forward declarations
+ */
+static struct z3fold_header *__z3fold_alloc(struct z3fold_pool *, size_t,
bool);
+static void compact_page_work(struct work_struct *w);
+
/*
* Helpers
*/
@@ -191,8 +207,6 @@ static int size_to_chunks(size_t size)
#define for_each_unbuddied_list(_iter, _begin) \
for ((_iter) = (_begin); (_iter) < NCHUNKS; (_iter)++)
-static void compact_page_work(struct work_struct *w);
-
static inline struct z3fold_buddy_slots *alloc_slots(struct z3fold_pool *pool,
gfp_t gfp)
{
@@ -204,6 +218,7 @@ static inline struct z3fold_buddy_slots *alloc_slots(struct
z3fold_pool *pool,
if (slots) {
memset(slots->slot, 0, sizeof(slots->slot));
slots->pool = (unsigned long)pool;
+ rwlock_init(>lock);
}
return slots;
@@ -219,27 +234,108 @@ static inline struct z3fold_buddy_slots
*handle_to_slots(unsigned long handle)
return (struct z3fold_buddy_slots *)(handle & ~(SLOTS_ALIGN - 1));
}
+/* Lock a z3fold page */
+static inline void z3fold_page_lock(struct z3fold_header *zhdr)
+{
+ spin_lock(>page_lock);
+}
+
+/* Try to lock a z3fold page */
+static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
+{
+ return spin_trylock(>page_lock);
+}
+
+/* Unlock a z3fold page */
+static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
+{
+ spin_unlock(>page_lock);
+}
+
+
+static inline struct z3fold_header *__get_z3fold_header(unsigned long handle,
+ bool lock)
+{
+ struct z3fold_buddy_slots *slots;
+ struct z3fold_header *zhdr;
+ int locked = 0;
+
+ if (!(handle & (1 << PAGE_HEADLESS))) {
+ slots = handle_to_slots(handle);
+ do {
+ unsigned long addr;
+
+ read_lock(>lock);
+ addr = *(unsigned long *)handle;
+ zhdr = (struct z3fold_header *)(addr & PAGE_MASK);
+ if (lock)
+ locked = z3fold_page_trylock(zhdr);
+ read_unlock(>lock);
+ if (locked)
+ break;
+ cpu_relax();
+ } while (lock);
+ } else {
+ zhdr = (struct z3fold_header *)(handle & PAGE_MASK);
+ }
+
+ return zhdr;
+}
+
+/* Returns the z3fold page where a given handle is stored */
+static inline struct z3fold_header *handle_to_z3fold_header(unsigned long h)
+{
+ return __get_z3fold_header(h, false);
+}
+
+/* return locked z3fold page if it's not headless */
+static inline struct z3fold_header *get_z3fold_header(unsigned long h)
+{
+ return __get_z3fold_header(h, true);
+}
+
+static inline void put_z3fold_header(struct z3fold_header *zhdr)
+{
+ struct page *page = virt_to_page(zhdr);
+
+ if (!test_bit(PAGE_HEADLESS, >private))
+
Running BOINC Project (SETI@home) for 48 Hours Killed My Galax GeForce GTX 1650 4 GB GDDR5 GPU
Subject: Running BOINC Project (SETI@home) for 48 Hours Killed My Galax GeForce GTX 1650 4 GB GDDR5 GPU Good day from Singapore, I bought my Galax GeForce GTX1650 4 GB GDDR5 GPU on 29th September 2019 Sunday. REFERENCES: [1] http://lkml.iu.edu/hypermail/linux/kernel/1909.3/04148.html [2] http://lists.linuxfromscratch.org/pipermail/lfs-chat/2019-September/029039.html [3] https://lists.freebsd.org/pipermail/freebsd-chat/2019-September/007361.html [4] https://lkml.org/lkml/2019/10/1/200 [5] http://lists.linuxfromscratch.org/pipermail/lfs-chat/2019-October/029040.html [6] https://lists.freebsd.org/pipermail/freebsd-chat/2019-October/007363.html At the time of this writing, it is 5th October 2019 Saturday. Over the past 48 hours, I have been running BOINC project (SETI@home) on my Windows 10 Home Edition home desktop computer. This morning, my home desktop computer suddenly gave me a Blue Screen of Death (BSOD) with the error code: "Windows System Exception". I thought my Windows 10 had become corrupted. ***Every time Windows 10 boots up, it would show me a BLANK SCREEN after a few seconds.*** I have tried the following resolution methods for about 2 hours on a Saturday morning but NOTHING worked. 1. I tried to perform Windows Startup Repair but it would not run. 2. I tried to start Windows in SAFE mode but it would show me a BLANK SCREEN as well. 3. I tried to start Windows in SAFE mode with Networking but it would show me a BLANK SCREEN as well. 4. I tried to start Windows with low video resolution but it would show me a BLANK SCREEN as well. 5. I tried to start Windows with Driver Signature Signing disabled but it would show me a BLANK SCREEN as well. 6. I tried to run "sfc /scannow" on a command prompt but it would not run. 7. I tried to uninstall Windows quality updates but it would still show me a BLANK SCREEN. 8. I tried to uninstall Windows feature update but it would still show me a BLANK SCREEN. 9. I tried to perform System Restore but Windows would still show me a BLANK SCREEN. In short, none of the resolution methods which I have tried above worked. Exasperated, I tried to reset Windows 10 while retaining personal data. After resetting Windows 10, I *successfully* booted into Windows with a Basic Microsoft Display Adapter Driver. Then I tried to install NVIDIA drivers. When NVIDIA drivers started to load, my Windows showed me a BLANK SCREEN AGAIN. At this point, I realized that my Galax GeForce GTX 1650 4 GB GDDR5 GPU has been killed/fried by BOINC project (SETI@home). On 5th October 2019 Saturday afternoon, I took my Galax GeForce GTX 1650 4 GB GDDR5 GPU to the 4th story computer shop in Sim Lim Square in Singapore for a 7-day 1-to-1 exchange, citing that the Galax GPU has malfunctioned. The shop keeper gave me a MSI GeForce GTX 1650 Ventus XS OC 4 GB GDDR5 GPU as replacement but I have to top up SGD$10. When I brought the replacement MSI GeForce GTX 1650 Ventus XS OC 4 GB GDDR5 GPU home, I plugged it into my home desktop computer and Windows 10 booted up *SUCCESSFULLY*. I proceeded to reinstall NVIDIA drivers again. Everything went well and everything is working fine now. Conclusion: BOINC project (SETI@home) fried my Galax GeForce GTX1650 4 GB GDDR5 GPU after 48 hours. Now I am actually afraid of running SETI@home again for fear of frying my replacement MSI GeForce GTX 1650 4 GB GDDR5 GPU again. Question: Will BOINC project (SETI@home) be able to work towards ensuring that it will not fry anyone's GPU again? I had my whole Saturday wasted. It was only Saturday evening when I returned home and got everything working again. Thank you very much. EXTERNAL LINKS: [1] https://boinc.berkeley.edu/forum_thread.php?id=13147 [2] https://groups.google.com/a/ssl.berkeley.edu/forum/#!topic/boinc_dev/BcDXSjPv314 [3] https://groups.google.com/a/ssl.berkeley.edu/forum/#!topic/boinc_alpha/Pc8ew5y0yRQ [4] https://groups.google.com/forum/#!topic/boinc_admin/J6FelluHIGk [5] https://setiathome.berkeley.edu/forum_thread.php?id=84727#2014337 -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017) and in Taiwan (5 Aug 2019): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: [PATCH] arm64: dts: imx8mn: Add "fsl,imx8mq-src" as src's fallback compatible
On Tue, Sep 10, 2019 at 10:39:19AM -0400, Anson Huang wrote: > i.MX8MN can reuse i.MX8MQ's src driver, add "fsl,imx8mq-src" as > src's fallback compatible to enable it. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH] arm64: dts: ls1028a: Add FlexSPI support for NXP LS1028
On Tue, Sep 10, 2019 at 05:50:51PM +0530, Ashish Kumar wrote:
> Add fspi node property for LS1028A SoC for FlexSPI driver.
> Property added for FlexSPI controller and for the connected
> slave device for the LS1028ARDB and LS1028AQDS target.
> RDB and QDS is having one SPI-NOR flash device, mt35xu02g
> connected at CS0.
> This flash device "mt35xu02g" is tested for octal read
>
> Signed-off-by: Xiaowei Bao
> Signed-off-by: Ashish Kumar
When you send a patch series, the patches should be numbered properly
and preferably with a cover-letter.
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 15 +++
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 15 +++
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi| 13 +
> 3 files changed, 43 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index 5e14e5a..5d46993 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -103,6 +103,21 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
Have a newline between properties and child node..
> + flash0: mt35xu02g@0 {
Use a generic node name and specific label name.
> + compatible = "micron,mt35xu02g", "jedec,spi-nor";
"micron,mt35xu02g" is undocumented.
Shawn
> + #address-cells = <1>;
> + #size-cells = <1>;
> + m25p,fast-read;
> + spi-max-frequency = <5000>;
> + reg = <0>;
> + /* The following setting enables 1-1-8 (CMD-ADDR-DATA) mode */
> + spi-rx-bus-width = <8>; /* 8 SPI Rx lines */
> + spi-tx-bus-width = <1>; /* 1 SPI Tx line */
> + };
> +};
> +
> {
> status = "okay";
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index 1a69221..f33cb2e 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -96,6 +96,21 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> + flash0: mt35xu02g@0 {
> + compatible = "micron,mt35xu02g", "jedec,spi-nor";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + m25p,fast-read;
> + spi-max-frequency = <5000>;
> + reg = <0>;
> + /* The following setting enables 1-1-8 (CMD-ADDR-DATA) mode */
> + spi-rx-bus-width = <8>; /* 8 SPI Rx lines */
> + spi-tx-bus-width = <1>; /* 1 SPI Tx line */
> + };
> +};
> +
> {
> status = "okay";
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index b139b29..4aa1825 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -174,6 +174,19 @@
> clocks = <>;
> };
>
> + fspi: spi@20c {
> + compatible = "nxp,lx2160a-fspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x20c 0x0 0x1>,
> + <0x0 0x2000 0x0 0x1000>;
> + reg-names = "fspi_base", "fspi_mmap";
> + interrupts = ;
> + clocks = < 4 3>, < 4 3>;
> + clock-names = "fspi_en", "fspi";
> + status = "disabled";
> + };
> +
> i2c0: i2c@200 {
> compatible = "fsl,vf610-i2c";
> #address-cells = <1>;
> --
> 2.7.4
>
Re: [PATCH v1] usb: dwc3: enable otg mode for dwc3 usb ip on layerscape
On Sat, Oct 5, 2019 at 9:56 PM Shawn Guo wrote: > > On Mon, Sep 09, 2019 at 05:02:44PM +0800, Yinbo Zhu wrote: > > layerscape otg function should be supported HNP SRP and ADP protocol > > accroing to rm doc, but dwc3 code not realize it and use id pin to > > detect who is host or device(0 is host 1 is device) this patch is to > > enable OTG mode on ls1028ardb ls1088ardb and ls1046ardb in dts > > > > Signed-off-by: Yinbo Zhu > > The patch prefix should be something like: 'arm64: dts: ...' > > @Leo, do you agree with the changes? No. The USB mode of operation should be defined at board level. > > Shawn > > > --- > > arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 2 +- > > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +- > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > > index 7975519b4f56..5810d0400dbc 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > > @@ -320,7 +320,7 @@ > > compatible = "fsl,ls1028a-dwc3", "snps,dwc3"; > > reg = <0x0 0x311 0x0 0x1>; > > interrupts = ; > > - dr_mode = "host"; > > + dr_mode = "otg"; > > snps,dis_rxdet_inp3_quirk; > > snps,quirk-frame-length-adjustment = <0x20>; > > snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>; > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > index b0ef08b090dd..ecce6151b9b0 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > @@ -582,7 +582,7 @@ > > compatible = "snps,dwc3"; > > reg = <0x0 0x300 0x0 0x1>; > > interrupts = ; > > - dr_mode = "host"; > > + dr_mode = "otg"; > > snps,quirk-frame-length-adjustment = <0x20>; > > snps,dis_rxdet_inp3_quirk; > > snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>; > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > > index dacd8cf03a7f..4b5413f7c90c 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > > @@ -385,7 +385,7 @@ > > compatible = "snps,dwc3"; > > reg = <0x0 0x311 0x0 0x1>; > > interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>; > > - dr_mode = "host"; > > + dr_mode = "otg"; > > snps,quirk-frame-length-adjustment = <0x20>; > > snps,dis_rxdet_inp3_quirk; > > status = "disabled"; > > -- > > 2.17.1 > >
Re: [PATCH v1] usb: dwc3: enable otg mode for dwc3 usb ip on layerscape
On Mon, Sep 09, 2019 at 05:02:44PM +0800, Yinbo Zhu wrote: > layerscape otg function should be supported HNP SRP and ADP protocol > accroing to rm doc, but dwc3 code not realize it and use id pin to > detect who is host or device(0 is host 1 is device) this patch is to > enable OTG mode on ls1028ardb ls1088ardb and ls1046ardb in dts > > Signed-off-by: Yinbo Zhu The patch prefix should be something like: 'arm64: dts: ...' @Leo, do you agree with the changes? Shawn > --- > arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 2 +- > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +- > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > index 7975519b4f56..5810d0400dbc 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi > @@ -320,7 +320,7 @@ > compatible = "fsl,ls1028a-dwc3", "snps,dwc3"; > reg = <0x0 0x311 0x0 0x1>; > interrupts = ; > - dr_mode = "host"; > + dr_mode = "otg"; > snps,dis_rxdet_inp3_quirk; > snps,quirk-frame-length-adjustment = <0x20>; > snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>; > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > index b0ef08b090dd..ecce6151b9b0 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > @@ -582,7 +582,7 @@ > compatible = "snps,dwc3"; > reg = <0x0 0x300 0x0 0x1>; > interrupts = ; > - dr_mode = "host"; > + dr_mode = "otg"; > snps,quirk-frame-length-adjustment = <0x20>; > snps,dis_rxdet_inp3_quirk; > snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>; > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > index dacd8cf03a7f..4b5413f7c90c 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi > @@ -385,7 +385,7 @@ > compatible = "snps,dwc3"; > reg = <0x0 0x311 0x0 0x1>; > interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>; > - dr_mode = "host"; > + dr_mode = "otg"; > snps,quirk-frame-length-adjustment = <0x20>; > snps,dis_rxdet_inp3_quirk; > status = "disabled"; > -- > 2.17.1 >
Re: DM3730 Bluetooth Performance differences between SERIAL_8250_OMAP vs SERIAL_OMAP
On Sat, Oct 5, 2019 at 8:23 PM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 10:45 PM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 11:51 AM Adam Ford wrote:
> > >
> > > On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
> > > >
> > > > On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
> > > > wrote:
> > > > >
> > > > > Hi Adam,
> > > > >
> > > > > On Fri, Oct 4, 2019 at 12:39 PM Adam Ford wrote:
> > > > > >
> > > > > > On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
> > > > > > >
> > > > > > > I am running Kernel 5.3.2 trying to troubleshoot some intermittent
> > > > > > > Bluetooth issues, and I think I have narrowed it down to the
> > > > > > > serial
> > > > > > > driver in use.
> > > > > >
> > > > > > I should have also noted that it's using UART2 with CTS and RTS on
> > > > > > the
> > > > > > DM3730 (omap3630) and its configured with a baud rate of 3M.
> > > > > > I tried slowing it to 115200, but that didn't help. I tried
> > > > > > disabling
> > > > > > the DMA hooks from the device tree, and that didn't help.
> > > > > >
> > > > > > > By default, omap2plus_defconfig enables both SERIAL_8250_OMAP and
> > > > > > > SERIAL_OMAP. I have my console device configured as ttyS0, and
> > > > > > > all
> > > > > > > appears fine. When I enable Bluetooth, however, I get
> > > > > > > intermittent
> > > > > > > errors on an DM3730 / OMAP3630.
> > > > > > >
> > > > > > > Using the 8250 driver for Blueotooth I get intermittent frame
> > > > > > > errors
> > > > > > > and data loss.
> > > > > > >
> > > > > > > Scanning ...
> > > > > > > [ 28.482452] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > > > [ 36.162170] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > > > F4:4E:FC:C9:2F:57 BluJax
> > > > > > > # l2ping F4:4E:FC:C9:2F:57
> > > > > > > Ping: F4:4E:FC:C9:2F:57 from 00:18:30:49:7D:63 (data size 44) ...
> > > > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 0 time 8.27ms
> > > > > > > no response from F4:4E:FC:C9:2F:57: id 1
> > > > > > > ^C2 sent, 1 received, 50% loss
> > > > > > >
> > > > > > > (after a fairly long hang, I hit control-c)
> > > > > > >
> > > > > > > However, disabling the 8250 driver and using the only SERIAL_OMAP
> > > > > > > and
> > > > > > > the console routed to ttyO0, the Bluetooth works well, so I
> > > > > > > believe it
> > > > > > > to be a serial driver issue and not a Bluetooth error.
> > > > > > >
> > > > > > > # hcitool scan
> > > > > > > Scanning ...
> > > > > > > F4:4E:FC:C9:2F:57 BluJax
> > > > > > > ^C
> > > > > > > # l2ping F4:4E:FC:C9:2F:57
> > > > > > > Ping: F4:4E:FC:C9:2F:57 from 00:18:30:49:7D:63 (data size 44) ...
> > > > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 0 time 6.90ms
> > > > > > > ...
> > > > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 14 time 28.29ms
> > > > > > > ^C15 sent, 15 received, 0% loss
> > > > > > > #
> > > > > > >
> > > > > > > 0% loss and regular, repeatable communication without any Frame
> > > > > > > reassembly errors.
> > > > > > >
> > > > > >
> > > > > > I tried disabling SERIAL_OMAP and using only SERIAL_8250_OMAP, but
> > > > > > that didn't help. Because the issue goes away when I disable
> > > > > > SERIAL_8250_OMAP, I am wondering if something is either being
> > > > > > misconfigured or some IRQ or DMA integration is missing that may be
> > > > > > present with the older SERIAL_OMAP driver.
> > > > > >
> > > > > > > Any suggestions on how to troubleshoot or what might cause the
> > > > > > > difference between the two drivers?
> > > > >
> > > > > Can it be related to this issue [1]? Can you confirm that 5.2 is
> > > > > working as expected with the 8250 driver?
> > > > >
> > > > > [1] https://marc.info/?l=linux-serial=156965039008649=2
> > > >
> > > > I reverted the whole 8250 directory to d99482673f95 ("serial:
> > > > mctrl_gpio: Check if GPIO property exisits before requesting it") and
> > > > it is somewhat better, but it's not as good as the stock OMAP serial
> > > > driver. I get some frame errors and eventually, I get some timeouts,
> > > > but it's not as bad. I'll try to implement the RTS and CTS as gpio
> > > > pins and change the device tree accordingly. It might shed some light
> > > > on the situation.
> > >
Yegor,
Can you take a look at [1]? I am still investigating the DMA issue
that I have where the serial port does not correctly work with DMA
enabled, but I submitted a patch that appears to fix my serial port
issue (as long as 8250 DMA is off).
I tested this against 5.4-rc1, and Tony submitted a different patch
that seems to help as well [2] that seems to help with the 5.2 and 5.3
kernels.
thanks
adam
[1] - https://patchwork.kernel.org/patch/11175969/
And for trees prior to 5.4-rc1):
[2] - https://patchwork.kernel.org/patch/11054387/
> > > I tried to manually setup RTS and CTS pins as GPIO, but that didn't
> > > work, so I changed it back.
> > >
> > > It looks like the clocking is correct. I don't know enough about the
> > > DMA or the IRQ to know
[PATCH] serial: 8250_omap: Fix gpio check for auto RTS and CTS
There are two checks to see if the manual gpio is configured, but
these the check is seeing if the structure is NULL instead it
should check to see if there are CTS and/or RTS pins defined.
This patch uses checks for those individual pins instead of
checking for the structure itself.
Signed-off-by: Adam Ford
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index c68e2b3a1634..836e736ae188 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -141,7 +141,7 @@ static void omap8250_set_mctrl(struct uart_port *port,
unsigned int mctrl)
serial8250_do_set_mctrl(port, mctrl);
- if (!up->gpios) {
+ if (!mctrl_gpio_to_gpiod(up->gpios, UART_GPIO_RTS)) {
/*
* Turn off autoRTS if RTS is lowered and restore autoRTS
* setting if RTS is raised
@@ -456,7 +456,8 @@ static void omap_8250_set_termios(struct uart_port *port,
up->port.status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS | UPSTAT_AUTOXOFF);
if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW &&
- !up->gpios) {
+ !mctrl_gpio_to_gpiod(up->gpios, UART_GPIO_RTS) &&
+ !mctrl_gpio_to_gpiod(up->gpios, UART_GPIO_CTS)) {
/* Enable AUTOCTS (autoRTS is enabled when RTS is raised) */
up->port.status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
priv->efr |= UART_EFR_CTS;
--
2.17.1
Re: [PATCH v3 3/3] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Mon, Aug 12, 2019 at 3:50 AM Rikard Falkeborn
wrote:
>
> GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> as the first argument and the low bit as the second argument. Mixing
> them will return a mask with zero bits set.
>
> Recent commits show getting this wrong is not uncommon, see e.g.
> commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and
> commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK
> macro").
>
> To prevent such mistakes from appearing again, add compile time sanity
> checking to the arguments of GENMASK() and GENMASK_ULL(). If both
> arguments are known at compile time, and the low bit is higher than the
> high bit, break the build to detect the mistake immediately.
>
> Since GENMASK() is used in declarations, BUILD_BUG_ON_ZERO() must be
> used instead of BUILD_BUG_ON().
>
> __builtin_constant_p does not evaluate is argument, it only checks if it
> is a constant or not at compile time, and __builtin_choose_expr does not
> evaluate the expression that is not chosen. Therefore, GENMASK(x++, 0)
> does only evaluate x++ once.
>
> Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
> available in assembly") made the macros in linux/bits.h available in
> assembly. Since BUILD_BUG_OR_ZERO() is not asm compatible, disable the
> checks if the file is included in an asm file.
>
> Signed-off-by: Rikard Falkeborn
Reviewed-by: Masahiro Yamada
> ---
> Changes in v3:
> - Changed back to shorter macro argument names
> - Remove casts and use 0 instead of UL(0) in GENMASK_INPUT_CHECK(),
> since all results in GENMASK_INPUT_CHECK() are now ints. Update
> commit message to reflect that.
>
> Changes in v2:
> - Add comment about why inputs are not checked when used in asm file
> - Use UL(0) instead of 0
> - Extract mask creation in a separate macro to improve readability
> - Use high and low instead of h and l (part of this was extracted to a
> separate patch)
> - Updated commit message
>
> Joe Perches sent a series to fix the existing misuses of GENMASK() that
> needs to be merged before this to avoid build failures. Currently, 5 of
> the patches are not in Linus tree, and 2 are not in linux-next. There is
> also a patch pending by Nathan Chancellor that also needs to be merged
> before this patch is merged to avoid build failures.
>
> include/linux/bits.h | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/bits.h b/include/linux/bits.h
> index 669d69441a62..4ba0fb609239 100644
> --- a/include/linux/bits.h
> +++ b/include/linux/bits.h
> @@ -18,12 +18,29 @@
> * position @h. For example
> * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> */
> -#define GENMASK(h, l) \
> +#ifndef __ASSEMBLY__
> +#include
> +#define GENMASK_INPUT_CHECK(h, l) \
> + (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> + __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> +#else
> +/*
> + * BUILD_BUG_ON_ZERO is not available in h files included from asm files,
> + * disable the input check if that is the case.
> + */
> +#define GENMASK_INPUT_CHECK(h, l) 0
> +#endif
> +
> +#define __GENMASK(h, l) \
> (((~UL(0)) - (UL(1) << (l)) + 1) & \
> (~UL(0) >> (BITS_PER_LONG - 1 - (h
> +#define GENMASK(h, l) \
> + (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
>
> -#define GENMASK_ULL(h, l) \
> +#define __GENMASK_ULL(h, l) \
> (((~ULL(0)) - (ULL(1) << (l)) + 1) & \
> (~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h
> +#define GENMASK_ULL(h, l) \
> + (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l))
>
> #endif /* __LINUX_BITS_H */
> --
> 2.22.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] x86/mm: determine whether the fault address is canonical
On Fri, Oct 04, 2019 at 08:14:25AM -0700, Dave Hansen wrote:
> On 10/4/19 7:59 AM, Andy Lutomirski wrote:
> >> @@ -123,7 +125,8 @@ __visible bool ex_handler_uaccess(const struct
> >> exception_table_entry *fixup,
> >> unsigned long error_code,
> >> unsigned long fault_addr)
> >> {
> >> - WARN_ONCE(trapnr == X86_TRAP_GP, "General protection fault in user
> >> access. Non-canonical address?");
> >> + WARN_ONCE(trapnr == X86_TRAP_GP, "General protection fault at %s
> >> address in user access.",
> >> + is_canonical_addr(fault_addr) ? "canonical" :
> >> "non-canonical");
> > Unless the hardware behaves rather differently from the way I think it
> > does, fault_addr is garbage for anything other than #PF and sometimes
> > for #DF. (And maybe the virtualization faults?) I don't believe that
> > #GP fills in CR2.
>
> For #GP, we do:
>
> do_general_protection(struct pt_regs *regs, long error_code)
> {
> ...
> if (!user_mode(regs)) {
> if (fixup_exception(regs, X86_TRAP_GP, error_code, 0))
> return;
>
> Where the 0 is 'fault_addr'. I'm not sure any other way that
> ex_handler_uaccess() can get called with trapnr == X86_TRAP_GP. 0 is
> canonical last I checked, which would make this patch a bit academic. :)
My fault. I thought the 'fault_addr' is filled with a valid value. So we really
don't know the answer without decoding the instruction which causes this #GP. :)
--
Cheers,
Changbin Du
Re: [PATCH v3 2/3] linux/build_bug.h: Change type to int
On Mon, Aug 12, 2019 at 3:50 AM Rikard Falkeborn
wrote:
>
> Having BUILD_BUG_ON_ZERO produce a value of type size_t leads to awkward
> casts in cases where the result needs to be signed, or of smaller type
> than size_t. To avoid this, cast the value to int instead and rely on
> implicit type conversions when a larger or unsigned type is needed.
>
> Suggested-by: Masahiro Yamada
> Signed-off-by: Rikard Falkeborn
Reviewed-by: Masahiro Yamada
> Changes in v3:
> - This patch is new in v3
>
> include/linux/build_bug.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
> index 0fe5426f2bdc..e3a0be2c90ad 100644
> --- a/include/linux/build_bug.h
> +++ b/include/linux/build_bug.h
> @@ -9,11 +9,11 @@
> #else /* __CHECKER__ */
> /*
> * Force a compilation error if condition is true, but also produce a
> - * result (of value 0 and type size_t), so the expression can be used
> + * result (of value 0 and type int), so the expression can be used
> * e.g. in a structure initializer (or where-ever else comma expressions
> * aren't permitted).
> */
> -#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
> +#define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> #endif /* __CHECKER__ */
>
> /* Force a compilation error if a constant expression is not a power of 2 */
> --
> 2.22.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] hugetlb: remove unused hstate in hugetlb_fault_mutex_hash()
Hi Wei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Wei-Yang/hugetlb-remove-unused-hstate-in-hugetlb_fault_mutex_hash/20191005-090034
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-42-g38eda53-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
mm/userfaultfd.c:262:17: sparse: sparse: undefined identifier 'h'
mm/userfaultfd.c:273:75: sparse: sparse: undefined identifier 'h'
mm/userfaultfd.c:300:69: sparse: sparse: undefined identifier 'h'
>> mm/userfaultfd.c:262:17: sparse: sparse: incorrect type in argument 1
>> (different base types) @@expected struct hstate *h @@got hstate *h @@
>> mm/userfaultfd.c:262:17: sparse:expected struct hstate *h
>> mm/userfaultfd.c:262:17: sparse:got bad type
mm/userfaultfd.c:273:75: sparse: sparse: incorrect type in argument 1
(different base types) @@expected struct hstate *h @@got hstate *h @@
mm/userfaultfd.c:273:75: sparse:expected struct hstate *h
mm/userfaultfd.c:273:75: sparse:got bad type
mm/userfaultfd.c:300:69: sparse: sparse: incorrect type in argument 1
(different base types) @@expected struct hstate *h @@got hstate *h @@
mm/userfaultfd.c:300:69: sparse:expected struct hstate *h
mm/userfaultfd.c:300:69: sparse:got bad type
vim +262 mm/userfaultfd.c
c1a4de99fada21 Andrea Arcangeli 2015-09-04 167
60d4d2d2b40e44 Mike Kravetz 2017-02-22 168 #ifdef CONFIG_HUGETLB_PAGE
60d4d2d2b40e44 Mike Kravetz 2017-02-22 169 /*
60d4d2d2b40e44 Mike Kravetz 2017-02-22 170 * __mcopy_atomic processing
for HUGETLB vmas. Note that this routine is
60d4d2d2b40e44 Mike Kravetz 2017-02-22 171 * called with mmap_sem held,
it will release mmap_sem before returning.
60d4d2d2b40e44 Mike Kravetz 2017-02-22 172 */
60d4d2d2b40e44 Mike Kravetz 2017-02-22 173 static __always_inline ssize_t
__mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 174
struct vm_area_struct *dst_vma,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 175
unsigned long dst_start,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 176
unsigned long src_start,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 177
unsigned long len,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 178
bool zeropage)
60d4d2d2b40e44 Mike Kravetz 2017-02-22 179 {
1c9e8def43a345 Mike Kravetz 2017-02-22 180 int vm_alloc_shared =
dst_vma->vm_flags & VM_SHARED;
1c9e8def43a345 Mike Kravetz 2017-02-22 181 int vm_shared =
dst_vma->vm_flags & VM_SHARED;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 182 ssize_t err;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 183 pte_t *dst_pte;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 184 unsigned long src_addr,
dst_addr;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 185 long copied;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 186 struct page *page;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 187 unsigned long
vma_hpagesize;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 188 pgoff_t idx;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 189 u32 hash;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 190 struct address_space
*mapping;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 191
60d4d2d2b40e44 Mike Kravetz 2017-02-22 192 /*
60d4d2d2b40e44 Mike Kravetz 2017-02-22 193 * There is no default
zero huge page for all huge page sizes as
60d4d2d2b40e44 Mike Kravetz 2017-02-22 194 * supported by
hugetlb. A PMD_SIZE huge pages may exist as used
60d4d2d2b40e44 Mike Kravetz 2017-02-22 195 * by THP. Since we
can not reliably insert a zero page, this
60d4d2d2b40e44 Mike Kravetz 2017-02-22 196 * feature is not
supported.
60d4d2d2b40e44 Mike Kravetz 2017-02-22 197 */
60d4d2d2b40e44 Mike Kravetz 2017-02-22 198 if (zeropage) {
60d4d2d2b40e44 Mike Kravetz 2017-02-22 199
up_read(_mm->mmap_sem);
60d4d2d2b40e44 Mike Kravetz 2017-02-22 200 return -EINVAL;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 201
Re: [PATCH V2 1/2] clk: imx8mm: Move 1443X/1416X PLL clock structure to common place
On Fri, Sep 06, 2019 at 09:34:05AM -0400, Anson Huang wrote: > Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM, > i.MX8MN and later i.MX8M SoCs, moving these PLL definitions > to pll14xx driver can save a lot of duplicated code on each > platform. > > Meanwhile, no need to define PLL clock structure for every > module which uses same type of PLL, e.g., audio/video/dram use > 1443X PLL, arm/gpu/vpu/sys use 1416X PLL, define 2 PLL clock > structure for each group is enough. > > Signed-off-by: Anson Huang Applied both, thanks.
Re: [RFC PATCH] media: vimc: vimc_pix_map_fmt_info() can be static
Hi Carlos,
On 10/5/19 9:28 PM, kbuild test robot wrote:
>
> Fixes: 4d124d159dff ("media: vimc: get pixformat info from v4l2_format_info
> to avoid code repetition")
Usually, the Fixes flag is used for something that is already accepted in
mainline.
If you want to fix anything in the previous version of the patch you sent, you
should update the last patch
and re-send it as a new version, i.e. [PATCH v2], adding a change log just
after the 3 dashes to explain
what you changed.
Check this example:
https://www.spinics.net/lists/linux-media/msg158251.html
Let me know if you need help!
And thanks for working on this :)
Helen
> Signed-off-by: kbuild test robot
> ---
> vimc-common.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
> b/drivers/media/platform/vimc/vimc-common.c
> index 9ea698810e1a1..c37442aba70b1 100644
> --- a/drivers/media/platform/vimc/vimc-common.c
> +++ b/drivers/media/platform/vimc/vimc-common.c
> @@ -118,7 +118,7 @@ static struct vimc_pix_map_fmt vimc_pix_map_fmt_list[] = {
> },
> };
>
> -struct vimc_pix_map vimc_pix_map_fmt_info(struct vimc_pix_map_fmt *vfmt)
> +static struct vimc_pix_map vimc_pix_map_fmt_info(struct vimc_pix_map_fmt
> *vfmt)
> {
>
> struct vimc_pix_map vpix = {
>
[Patch v2 3/3] mm/mmap.c: extract __vma_unlink_list as counter part for __vma_link_list
Just make the code a little easy to read.
Signed-off-by: Wei Yang
---
Note: For nommu part, the code is not tested.
---
v2: rebase on top of 5.4-rc1
---
mm/internal.h | 1 +
mm/mmap.c | 12 +---
mm/nommu.c| 8 +---
mm/util.c | 14 ++
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 8e596fa8a7de..f93fd474dac3 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -291,6 +291,7 @@ static inline bool is_data_mapping(vm_flags_t flags)
/* mm/util.c */
void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
struct vm_area_struct *prev);
+void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma);
#ifdef CONFIG_MMU
extern long populate_vma_page_range(struct vm_area_struct *vma,
diff --git a/mm/mmap.c b/mm/mmap.c
index 2ca805209c47..3ab5d20289be 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -686,18 +686,8 @@ static __always_inline void __vma_unlink_common(struct
mm_struct *mm,
struct vm_area_struct *vma,
struct vm_area_struct *ignore)
{
- struct vm_area_struct *prev, *next;
-
vma_rb_erase_ignore(vma, >mm_rb, ignore);
- next = vma->vm_next;
- prev = vma->vm_prev;
- if (prev)
- prev->vm_next = next;
- else
- mm->mmap = next;
- if (next)
- next->vm_prev = prev;
-
+ __vma_unlink_list(mm, vma);
/* Kill the cache */
vmacache_invalidate(mm);
}
diff --git a/mm/nommu.c b/mm/nommu.c
index 2bb923210128..21ddf689d4fa 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -673,13 +673,7 @@ static void delete_vma_from_mm(struct vm_area_struct *vma)
/* remove from the MM's tree and list */
rb_erase(>vm_rb, >mm_rb);
- if (vma->vm_prev)
- vma->vm_prev->vm_next = vma->vm_next;
- else
- mm->mmap = vma->vm_next;
-
- if (vma->vm_next)
- vma->vm_next->vm_prev = vma->vm_prev;
+ __vma_unlink_list(mm, vma);
}
/*
diff --git a/mm/util.c b/mm/util.c
index 023defd39a0d..988d11e6c17c 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -288,6 +288,20 @@ void __vma_link_list(struct mm_struct *mm, struct
vm_area_struct *vma,
next->vm_prev = vma;
}
+void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma)
+{
+ struct vm_area_struct *prev, *next;
+
+ next = vma->vm_next;
+ prev = vma->vm_prev;
+ if (prev)
+ prev->vm_next = next;
+ else
+ mm->mmap = next;
+ if (next)
+ next->vm_prev = prev;
+}
+
/* Check if the vma is being used as a stack by this task */
int vma_is_stack_for_current(struct vm_area_struct *vma)
{
--
2.17.1
drivers/staging/octeon/ethernet-defines.h:30:38: error: 'CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE' undeclared; did you mean 'CPU_CAVIUM_OCTEON_PLUS'?
Hi Matthew,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 2d00aee21a5d4966e086d98f9d710afb92fb14e8
commit: 171a9bae68c72f2d1260c3825203760856e6793b staging/octeon: Allow test
build on !MIPS
date: 10 weeks ago
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 171a9bae68c72f2d1260c3825203760856e6793b
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from arch/mips/include/asm/octeon/octeon.h:11:0,
from drivers/staging/octeon/octeon-ethernet.h:19,
from drivers/staging/octeon/ethernet-rx.c:26:
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr':
arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
cvmx_write_csr((__force uint64_t)csr_addr, val);
^
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr':
arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
return cvmx_read_csr((__force uint64_t) csr_addr);
^
In file included from drivers/staging/octeon/octeon-ethernet.h:27:0,
from drivers/staging/octeon/ethernet-rx.c:26:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of
'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST'
undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
^~~~
CVMX_CIU_SOFT_RST
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared
identifier is reported only once for each function it appears in
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable
'pip_sft_rst' [-Wunused-variable]
union cvmx_pip_sft_rst pip_sft_rst;
^~~
In file included from drivers/staging/octeon/ethernet-rx.c:27:0:
drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_poll':
>> drivers/staging/octeon/ethernet-defines.h:30:38: error:
>> 'CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE' undeclared (first use in this function);
>> did you mean 'CPU_CAVIUM_OCTEON_PLUS'?
#define USE_ASYNC_IOBDMA(CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE > 0)
^
drivers/staging/octeon/ethernet-rx.c:190:6: note: in expansion of macro
'USE_ASYNC_IOBDMA'
if (USE_ASYNC_IOBDMA) {
^~~~
drivers/staging/octeon/ethernet-rx.c: In function 'cvm_oct_rx_initialize':
drivers/staging/octeon/ethernet-rx.c:472:25: error: 'OCTEON_IRQ_WORKQ0'
undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'?
oct_rx_group[i].irq = OCTEON_IRQ_WORKQ0 + i;
^
OCTEON_IS_MODEL
--
In file included from arch/mips/include/asm/octeon/octeon.h:11:0,
from drivers/staging/octeon/octeon-ethernet.h:19,
from drivers/staging/octeon/ethernet-tx.c:25:
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr':
arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
cvmx_write_csr((__force uint64_t)csr_addr, val);
^
arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr':
arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
return cvmx_read_csr((__force uint64_t) csr_addr);
^
In file included from drivers/staging/octeon/octeon-ethernet.h:27:0,
from drivers/staging/octeon/ethernet-tx.c:25:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of
'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST'
undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
[Patch v2 1/3] mm/mmap.c: prev could be retrieved from vma->vm_prev
Currently __vma_unlink_common handles two cases:
* has_prev
* or not
When has_prev is false, it is obvious prev is calculated from
vma->vm_prev in __vma_unlink_common.
When has_prev is true, the prev is passed through from __vma_unlink_prev
in __vma_adjust for non-case 8. And at the beginning next is calculated
from vma->vm_next, which implies vma is next->vm_prev.
The above statement sounds a little complicated, while to think in
another point of view, no matter whether vma and next is swapped, the
mmap link list still preserves its property. It is proper to access
vma->vm_prev.
Signed-off-by: Wei Yang
---
v2: rebase on top of 5.4-rc1
---
mm/mmap.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 338213aed65a..c61403f25833 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -684,23 +684,17 @@ static void __insert_vm_struct(struct mm_struct *mm,
struct vm_area_struct *vma)
static __always_inline void __vma_unlink_common(struct mm_struct *mm,
struct vm_area_struct *vma,
- struct vm_area_struct *prev,
- bool has_prev,
struct vm_area_struct *ignore)
{
- struct vm_area_struct *next;
+ struct vm_area_struct *prev, *next;
vma_rb_erase_ignore(vma, >mm_rb, ignore);
next = vma->vm_next;
- if (has_prev)
+ prev = vma->vm_prev;
+ if (prev)
prev->vm_next = next;
- else {
- prev = vma->vm_prev;
- if (prev)
- prev->vm_next = next;
- else
- mm->mmap = next;
- }
+ else
+ mm->mmap = next;
if (next)
next->vm_prev = prev;
@@ -712,7 +706,7 @@ static inline void __vma_unlink_prev(struct mm_struct *mm,
struct vm_area_struct *vma,
struct vm_area_struct *prev)
{
- __vma_unlink_common(mm, vma, prev, true, vma);
+ __vma_unlink_common(mm, vma, vma);
}
/*
@@ -900,7 +894,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long
start,
* "next" (which is stored in post-swap()
* "vma").
*/
- __vma_unlink_common(mm, next, NULL, false, vma);
+ __vma_unlink_common(mm, next, vma);
if (file)
__remove_shared_vm_struct(next, file, mapping);
} else if (insert) {
--
2.17.1
[Patch v2 2/3] mm/mmap.c: __vma_unlink_prev is not necessary now
The third parameter of __vma_unlink_common could differentiate these two
types. __vma_unlink_prev is not necessary now.
Signed-off-by: Wei Yang
---
v2: rebase on top of 5.4-rc1
---
mm/mmap.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index c61403f25833..2ca805209c47 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -702,13 +702,6 @@ static __always_inline void __vma_unlink_common(struct
mm_struct *mm,
vmacache_invalidate(mm);
}
-static inline void __vma_unlink_prev(struct mm_struct *mm,
-struct vm_area_struct *vma,
-struct vm_area_struct *prev)
-{
- __vma_unlink_common(mm, vma, vma);
-}
-
/*
* We cannot adjust vm_start, vm_end, vm_pgoff fields of a vma that
* is already present in an i_mmap tree without adjusting the tree.
@@ -883,7 +876,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long
start,
* us to remove next before dropping the locks.
*/
if (remove_next != 3)
- __vma_unlink_prev(mm, next, vma);
+ __vma_unlink_common(mm, next, next);
else
/*
* vma is not before next if they've been
--
2.17.1
Re: [PATCH] media: vimc: get pixformat info from v4l2_format_info to avoid code repetition
Hi Carlos,
Thank you for the patch, please see my comments below.
On 10/5/19 6:11 PM, Carlos E. C. Barbosa wrote:
> From: "Carlos E.C. Barbosa"
>
> As the info found in vim_pix_map members are already available in
> v4l2_format_info those were removed and their calls remapped to it.
>
> Signed-off-by: Carlos E. C. Barbosa
> ---
> drivers/media/platform/vimc/vimc-capture.c | 20 ++--
> drivers/media/platform/vimc/vimc-common.c | 107 +
> drivers/media/platform/vimc/vimc-common.h | 27 --
> drivers/media/platform/vimc/vimc-debayer.c | 6 +-
> drivers/media/platform/vimc/vimc-scaler.c | 26 +++--
> drivers/media/platform/vimc/vimc-sensor.c | 25 ++---
> 6 files changed, 105 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-capture.c
> b/drivers/media/platform/vimc/vimc-capture.c
> index 602f80323031..8be2f81d5da3 100644
> --- a/drivers/media/platform/vimc/vimc-capture.c
> +++ b/drivers/media/platform/vimc/vimc-capture.c
> @@ -85,7 +85,7 @@ static int vimc_cap_try_fmt_vid_cap(struct file *file, void
> *priv,
> struct v4l2_format *f)
> {
> struct v4l2_pix_format *format = >fmt.pix;
> - const struct vimc_pix_map *vpix;
> + struct vimc_pix_map vpix;
I think you could keep vpix a pointer (please see below).
>
> format->width = clamp_t(u32, format->width, VIMC_FRAME_MIN_WIDTH,
> VIMC_FRAME_MAX_WIDTH) & ~1;
> @@ -94,12 +94,12 @@ static int vimc_cap_try_fmt_vid_cap(struct file *file,
> void *priv,
>
> /* Don't accept a pixelformat that is not on the table */
> vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
> - if (!vpix) {
If vpix is a pointer, then this still need to be checked.
> + if (!vpix.info) {
This is nice to cache the info inside the vpix.
What you could to is to have info to be of type const struct v4l2_format_info
directly.
Something like this:
struct vimc_pix_map_fmt {
unsigned int code;
u32 pixelformat;
const struct v4l2_format_info *info;
};
Then, if (!vpix->info), you fill the pointer, to cache it.
But this means that vimc_pix_map_fmt_list[] can't be const anymore, so I'm not
entirely sure,
maybe it is better to call v4l2_format_info() always? hmm, not sure.
In any case, I don't think vimc_pix_map is necessary (please see below).
> format->pixelformat = fmt_default.pixelformat;
> vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
> }
> /* TODO: Add support for custom bytesperline values */
> - format->bytesperline = format->width * vpix->bpp;
> + format->bytesperline = format->width * vpix.info->bpp[0];
> format->sizeimage = format->bytesperline * format->height;
>
> if (format->field == V4L2_FIELD_ANY)
> @@ -146,12 +146,12 @@ static int vimc_cap_s_fmt_vid_cap(struct file *file,
> void *priv,
> static int vimc_cap_enum_fmt_vid_cap(struct file *file, void *priv,
>struct v4l2_fmtdesc *f)
> {
> - const struct vimc_pix_map *vpix = vimc_pix_map_by_index(f->index);
> + const struct vimc_pix_map vpix = vimc_pix_map_by_index(f->index);
>
> - if (!vpix)
> + if (!vpix.info)
> return -EINVAL;
>
> - f->pixelformat = vpix->pixelformat;
> + f->pixelformat = vpix.info->format;
>
> return 0;
> }
> @@ -159,14 +159,14 @@ static int vimc_cap_enum_fmt_vid_cap(struct file *file,
> void *priv,
> static int vimc_cap_enum_framesizes(struct file *file, void *fh,
> struct v4l2_frmsizeenum *fsize)
> {
> - const struct vimc_pix_map *vpix;
> + struct vimc_pix_map vpix;
>
> if (fsize->index)
> return -EINVAL;
>
> /* Only accept code in the pix map table */
> vpix = vimc_pix_map_by_code(fsize->pixel_format);
> - if (!vpix)
> + if (!vpix.info)
> return -EINVAL;
>
> fsize->type = V4L2_FRMSIZE_TYPE_CONTINUOUS;
> @@ -387,7 +387,7 @@ struct vimc_ent_device *vimc_cap_add(struct vimc_device
> *vimc,
>const char *vcfg_name)
> {
> struct v4l2_device *v4l2_dev = >v4l2_dev;
> - const struct vimc_pix_map *vpix;
> + struct vimc_pix_map vpix;
> struct vimc_cap_device *vcap;
> struct video_device *vdev;
> struct vb2_queue *q;
> @@ -443,7 +443,7 @@ struct vimc_ent_device *vimc_cap_add(struct vimc_device
> *vimc,
> /* Set default frame format */
> vcap->format = fmt_default;
> vpix = vimc_pix_map_by_pixelformat(vcap->format.pixelformat);
> - vcap->format.bytesperline = vcap->format.width * vpix->bpp;
> + vcap->format.bytesperline = vcap->format.width * vpix.info->bpp[0];
> vcap->format.sizeimage = vcap->format.bytesperline *
>vcap->format.height;
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
>
Re: DM3730 Bluetooth Performance differences between SERIAL_8250_OMAP vs SERIAL_OMAP
On Fri, Oct 4, 2019 at 10:45 PM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 11:51 AM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
> > >
> > > On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
> > > wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > On Fri, Oct 4, 2019 at 12:39 PM Adam Ford wrote:
> > > > >
> > > > > On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
> > > > > >
> > > > > > I am running Kernel 5.3.2 trying to troubleshoot some intermittent
> > > > > > Bluetooth issues, and I think I have narrowed it down to the serial
> > > > > > driver in use.
> > > > >
> > > > > I should have also noted that it's using UART2 with CTS and RTS on the
> > > > > DM3730 (omap3630) and its configured with a baud rate of 3M.
> > > > > I tried slowing it to 115200, but that didn't help. I tried disabling
> > > > > the DMA hooks from the device tree, and that didn't help.
> > > > >
> > > > > > By default, omap2plus_defconfig enables both SERIAL_8250_OMAP and
> > > > > > SERIAL_OMAP. I have my console device configured as ttyS0, and all
> > > > > > appears fine. When I enable Bluetooth, however, I get intermittent
> > > > > > errors on an DM3730 / OMAP3630.
> > > > > >
> > > > > > Using the 8250 driver for Blueotooth I get intermittent frame errors
> > > > > > and data loss.
> > > > > >
> > > > > > Scanning ...
> > > > > > [ 28.482452] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > > [ 36.162170] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > > F4:4E:FC:C9:2F:57 BluJax
> > > > > > # l2ping F4:4E:FC:C9:2F:57
> > > > > > Ping: F4:4E:FC:C9:2F:57 from 00:18:30:49:7D:63 (data size 44) ...
> > > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 0 time 8.27ms
> > > > > > no response from F4:4E:FC:C9:2F:57: id 1
> > > > > > ^C2 sent, 1 received, 50% loss
> > > > > >
> > > > > > (after a fairly long hang, I hit control-c)
> > > > > >
> > > > > > However, disabling the 8250 driver and using the only SERIAL_OMAP
> > > > > > and
> > > > > > the console routed to ttyO0, the Bluetooth works well, so I believe
> > > > > > it
> > > > > > to be a serial driver issue and not a Bluetooth error.
> > > > > >
> > > > > > # hcitool scan
> > > > > > Scanning ...
> > > > > > F4:4E:FC:C9:2F:57 BluJax
> > > > > > ^C
> > > > > > # l2ping F4:4E:FC:C9:2F:57
> > > > > > Ping: F4:4E:FC:C9:2F:57 from 00:18:30:49:7D:63 (data size 44) ...
> > > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 0 time 6.90ms
> > > > > > ...
> > > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 14 time 28.29ms
> > > > > > ^C15 sent, 15 received, 0% loss
> > > > > > #
> > > > > >
> > > > > > 0% loss and regular, repeatable communication without any Frame
> > > > > > reassembly errors.
> > > > > >
> > > > >
> > > > > I tried disabling SERIAL_OMAP and using only SERIAL_8250_OMAP, but
> > > > > that didn't help. Because the issue goes away when I disable
> > > > > SERIAL_8250_OMAP, I am wondering if something is either being
> > > > > misconfigured or some IRQ or DMA integration is missing that may be
> > > > > present with the older SERIAL_OMAP driver.
> > > > >
> > > > > > Any suggestions on how to troubleshoot or what might cause the
> > > > > > difference between the two drivers?
> > > >
> > > > Can it be related to this issue [1]? Can you confirm that 5.2 is
> > > > working as expected with the 8250 driver?
> > > >
> > > > [1] https://marc.info/?l=linux-serial=156965039008649=2
> > >
> > > I reverted the whole 8250 directory to d99482673f95 ("serial:
> > > mctrl_gpio: Check if GPIO property exisits before requesting it") and
> > > it is somewhat better, but it's not as good as the stock OMAP serial
> > > driver. I get some frame errors and eventually, I get some timeouts,
> > > but it's not as bad. I'll try to implement the RTS and CTS as gpio
> > > pins and change the device tree accordingly. It might shed some light
> > > on the situation.
> >
> > I tried to manually setup RTS and CTS pins as GPIO, but that didn't
> > work, so I changed it back.
> >
> > It looks like the clocking is correct. I don't know enough about the
> > DMA or the IRQ to know if it's working correctly.
> >
> > I was wondering if the problem is in the handshaking or not.
> > I added " uart-has-rtscts;" to by uart node thinking it might help,
> > but it did not.
> >
> > >
> > 8250_omap.c has some checks to see if we can enable autoRTS:
> >
> > if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW &&
> > !up->gpios) {
> > /* Enable AUTOCTS (autoRTS is enabled when RTS is raised) */
> > ...
> > }
> >
> > Based on this, I would expect up->gpios to always be zero if we want
> > auto RTS CTS.
> >
> > I threw some debug code into the serial driver to look at the status
> > of the various flags that go into setting up auto RTS/CTS.
> >
> > [ 13.837005] termios->c_cflag & CRTSCTS = 8000
> > [ 13.841888] up->port.flags & UPF_HARD_FLOW = 30
> > [ 13.846801] up->gpios = ce3f3cc0
> > [ 17.166595]
Re: [PATCH] soc: imx: imx-scu: Getting UID from SCU should have response
On Wed, Sep 04, 2019 at 03:13:14PM -0400, Anson Huang wrote:
> The SCU firmware API for getting UID should have response,
> otherwise, the message stored in function stack could be
> released and then the response data received from SCU will be
> stored into that released stack and cause kernel NULL pointer
> dump.
>
> Fixes: 73feb4d0f8f1 ("soc: imx-scu: Add SoC UID(unique identifier) support")
> Signed-off-by: Anson Huang
Applied, thanks.
Re: [PATCH v3 1/1] ARM: dts: colibri: introduce dts with UHS-I support enabled
On Wed, Sep 04, 2019 at 02:09:18PM +0300, Igor Opaniuk wrote:
> From: Igor Opaniuk
>
> Introduce DTS for Colibri iMX6S/DL V1.1x re-design, where UHS-I support was
> added. Provide proper configuration for VGEN3, which allows that rail to
> be automatically switched to 1.8 volts for proper UHS-I operation mode.
>
> Signed-off-by: Igor Opaniuk
> ---
>
> v3:
> - change hierarchy according to Marco's suggestions [Marco Felsch]
> - adjust compatible string adding v1.1 [Stefan Agner]
>
> v2:
> - rework hierarchy of dts files, and a separate dtsi for Colibri
> iMX6S/DL V1.1x re-design, where UHS-I was added [Marcel Ziswiler]
> - add comments about vgen3 power rail [Marcel Ziswiler]
> - fix other minor issues, addressing Marcel's comments. [Marcel Ziswiler]
>
> arch/arm/boot/dts/Makefile| 1 +
> .../boot/dts/imx6dl-colibri-v1_1-eval-v3.dts | 59 +++
> arch/arm/boot/dts/imx6qdl-colibri.dtsi| 11 +++-
> 3 files changed, 70 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx6dl-colibri-v1_1-eval-v3.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9159fa2cea90..87dfc3db4343 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -401,6 +401,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-aristainetos2_4.dtb \
> imx6dl-aristainetos2_7.dtb \
> imx6dl-colibri-eval-v3.dtb \
> + imx6dl-colibri-v1_1-eval-v3.dtb \
> imx6dl-cubox-i.dtb \
> imx6dl-cubox-i-emmc-som-v15.dtb \
> imx6dl-cubox-i-som-v15.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-v1_1-eval-v3.dts
> b/arch/arm/boot/dts/imx6dl-colibri-v1_1-eval-v3.dts
> new file mode 100644
> index ..92fcf4e62ba2
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-v1_1-eval-v3.dts
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0 OR X11
> +/*
> + * Copyright 2019 Toradex AG
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6dl-colibri-eval-v3.dts"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S V1.1 on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-v1_1-eval-v3",
> + "toradex,colibri_imx6dl-v1_1",
> + "toradex,colibri_imx6dl-eval-v3",
> + "toradex,colibri_imx6dl",
Please make sure these compatibles are documented.
> + "fsl,imx6dl";
> +};
> +
> + {
> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD0x170b1
> + MX6QDL_PAD_SD1_CLK__SD1_CLK0x100b1
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170b1
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170b1
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170b1
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170b1
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD0x170f1
> + MX6QDL_PAD_SD1_CLK__SD1_CLK0x100f1
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f1
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f1
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f1
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f1
> + >;
> + };
> +};
> +
> +/* Colibri MMC */
> + {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <_usdhc1 _mmc_cd>;
> + pinctrl-1 = <_usdhc1_100mhz _mmc_cd>;
> + pinctrl-2 = <_usdhc1_200mhz _mmc_cd>;
> + vmmc-supply = <_module_3v3>;
> + vqmmc-supply = <_reg>;
> + enable-sdio-wakeup;
Check out Documentation/devicetree/bindings/power/wakeup-source.txt
Shawn
> + keep-power-in-suspend;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + status = "okay";
> + /delete-property/no-1-8-v;
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> index 1beac22266ed..27097ab5eaab 100644
> --- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> @@ -215,7 +215,16 @@
> regulator-always-on;
> };
>
> - /* vgen3: unused */
> + /*
> + * +V3.3_1.8_SD1 coming off VGEN3 and supplying
> + * the i.MX 6 NVCC_SD1.
> + */
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
>
> vgen4_reg: vgen4 {
> regulator-min-microvolt = <180>;
> --
> 2.17.1
>
Re: [PATCH] mm/page_isolation: fix a deadlock with printk()
> On Oct 5, 2019, at 8:44 PM, Andrew Morton wrote: > > There is no "console_lock". Please be much more specific. > >> It is easier to avoid, >> >> zone_lock -> console_lock >> >> rather than fixing the opposite. > > "ease" isn't the main objective. A more important question is "what > makes sense". We should be able to call printk() from anywhere, any > time under any conditions. That can't be done 100% but it is the > objective. printk() should be robust and not being able to call > printk() while holding zone->lock isn't robust! > > btw, this: > > : It is unsafe to call printk() while zone->lock was held, i.e., > : > :zone->lock --> console_sem > > doesn't make a lot of sense. console_sem is a sleeping lock so > attempting to acquire it (with down()!) under spinlock is a huge bug. > Again, please be careful with the descriptions. Sorry, It is console_owner_lock.
[PATCH v3 4/4] HID: logitech: Support WirelessDeviceStatus connect events
This patch makes WirelessDeviceStatus (0x1d4b) events get detected as
connection events on devices with HIDPP_QUIRK_WIRELESS_DEVICE_STATUS.
This quirk is currently an alias for HIDPP_QUIRK_CLASS_BLUETOOTH since
the added Bluetooth devices do not support regular connect events.
Signed-off-by: Mazin Rezk
---
drivers/hid/hid-logitech-hidpp.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 64ac94c581aa..4a6e41c2c9fc 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -84,6 +84,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
/* Just an alias for now, may possibly be a catch-all in the future */
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS HIDPP_QUIRK_CLASS_BLUETOOTH
+#define HIDPP_QUIRK_WIRELESS_DEVICE_STATUS HIDPP_QUIRK_CLASS_BLUETOOTH
#define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
@@ -406,9 +407,22 @@ static inline bool hidpp_match_error(struct hidpp_report
*question,
(answer->fap.params[0] == question->fap.funcindex_clientid);
}
-static inline bool hidpp_report_is_connect_event(struct hidpp_report *report)
+#define HIDPP_PAGE_WIRELESS_DEVICE_STATUS 0x1d4b
+
+static inline bool hidpp_report_is_connect_event(struct hidpp_device *hidpp,
+struct hidpp_report *report)
{
- return (report->report_id == REPORT_ID_HIDPP_SHORT) &&
+ if (hidpp->quirks & HIDPP_QUIRK_WIRELESS_DEVICE_STATUS) {
+ /* If feature is invalid, skip array check */
+ if (report->fap.feature_index > hidpp->feature_count)
+ return false;
+
+ return (hidpp->features[report->fap.feature_index] ==
+HIDPP_PAGE_WIRELESS_DEVICE_STATUS);
+ }
+
+ return ((report->report_id == REPORT_ID_HIDPP_SHORT) ||
+ (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)) &&
(report->rap.sub_id == 0x41);
}
@@ -3159,7 +3173,7 @@ static int hidpp_raw_hidpp_event(struct hidpp_device
*hidpp, u8 *data,
}
}
- if (unlikely(hidpp_report_is_connect_event(report))) {
+ if (unlikely(hidpp_report_is_connect_event(hidpp, report))) {
atomic_set(>connected,
!(report->rap.params[0] & (1 << 6)));
if (schedule_work(>work) == 0)
--
2.23.0
[PATCH v3 3/4] HID: logitech: Add feature 0x0001: FeatureSet
This patch adds support for the 0x0001 (FeatureSet) feature. This feature
is used to look up the feature ID of a feature index on a device and list
the total count of features on the device.
I also added the hidpp20_get_features function which iterates through all
feature indexes on the device and stores a map of them in features an
hidpp_device struct. This function runs when an HID++ 2.0 device is probed.
Signed-off-by: Mazin Rezk
---
drivers/hid/hid-logitech-hidpp.c | 92
1 file changed, 92 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index a0efa8a43213..64ac94c581aa 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -190,6 +190,9 @@ struct hidpp_device {
struct hidpp_battery battery;
struct hidpp_scroll_counter vertical_wheel_counter;
+
+ u16 *features;
+ u8 feature_count;
};
/* HID++ 1.0 error codes */
@@ -911,6 +914,84 @@ static int hidpp_root_get_protocol_version(struct
hidpp_device *hidpp)
return 0;
}
+/* --
*/
+/* 0x0001: FeatureSet
*/
+/* --
*/
+
+#define HIDPP_PAGE_FEATURESET 0x0001
+
+#define CMD_FEATURESET_GET_COUNT 0x00
+#define CMD_FEATURESET_GET_FEATURE 0x11
+
+static int hidpp20_featureset_get_feature(struct hidpp_device *hidpp,
+ u8 featureset_index, u8 feature_index, u16 *feature_id)
+{
+ struct hidpp_report response;
+ int ret;
+
+ ret = hidpp_send_fap_command_sync(hidpp, featureset_index,
+ CMD_FEATURESET_GET_FEATURE, _index, 1, );
+
+ if (ret)
+ return ret;
+
+ *feature_id = (response.fap.params[0] << 8) | response.fap.params[1];
+
+ return ret;
+}
+
+static int hidpp20_featureset_get_count(struct hidpp_device *hidpp,
+ u8 feature_index, u8 *count)
+{
+ struct hidpp_report response;
+ int ret;
+
+ ret = hidpp_send_fap_command_sync(hidpp, feature_index,
+ CMD_FEATURESET_GET_COUNT, NULL, 0, );
+
+ if (ret)
+ return ret;
+
+ *count = response.fap.params[0];
+
+ return ret;
+}
+
+static int hidpp20_get_features(struct hidpp_device *hidpp)
+{
+ int ret;
+ u8 featureset_index, featureset_type;
+ u8 i;
+
+ hidpp->feature_count = 0;
+
+ ret = hidpp_root_get_feature(hidpp, HIDPP_PAGE_FEATURESET,
+_index, _type);
+
+ if (ret == -ENOENT) {
+ hid_warn(hidpp->hid_dev, "Unable to retrieve feature set.");
+ return 0;
+ }
+
+ if (ret)
+ return ret;
+
+ ret = hidpp20_featureset_get_count(hidpp, featureset_index,
+ >feature_count);
+
+ if (ret)
+ return ret;
+
+ hidpp->features = devm_kzalloc(>hid_dev->dev,
+ hidpp->feature_count * sizeof(u16), GFP_KERNEL);
+
+ for (i = 0; i < hidpp->feature_count && !ret; i++)
+ ret = hidpp20_featureset_get_feature(hidpp, featureset_index,
+ i, &(hidpp->features[i]));
+
+ return ret;
+}
+
/* --
*/
/* 0x0005: GetDeviceNameType
*/
/* --
*/
@@ -3625,6 +3706,17 @@ static int hidpp_probe(struct hid_device *hdev, const
struct hid_device_id *id)
hidpp_overwrite_name(hdev);
}
+ /* Cache feature indexes and IDs to check reports faster */
+ if (hidpp->protocol_major >= 2) {
+ if (hidpp20_get_features(hidpp)) {
+ hid_err(hdev, "%s:hidpp20_get_features returned
error\n",
+ __func__);
+ goto hid_hw_init_fail;
+ }
+ } else {
+ hidpp->feature_count = 0;
+ }
+
if (connected && (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)) {
ret = wtp_get_config(hidpp);
if (ret)
--
2.23.0
[PATCH v3 2/4] HID: logitech: Support HID++ devices without short reports
This patch allows the hid-logitech-hidpp module to support devices that do
not have support for Short HID++ reports. So far, it seems that Bluetooth
HID++ 2.0 devices are missing short reports.
This has been tested and confirmed with the MX Master and MX Master 2S and
is therefore likely the case with the other Bluetooth devices.
Signed-off-by: Mazin Rezk
---
drivers/hid/hid-logitech-hidpp.c | 37 ++--
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 85fd0c17cc2f..a0efa8a43213 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -71,6 +71,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_QUIRK_HIDPP_WHEELS BIT(29)
#define HIDPP_QUIRK_HIDPP_EXTRA_MOUSE_BTNS BIT(30)
#define HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS BIT(31)
+#define HIDPP_QUIRK_CLASS_BLUETOOTHBIT(5)
/* These are just aliases for now */
#define HIDPP_QUIRK_KBD_SCROLL_WHEEL HIDPP_QUIRK_HIDPP_WHEELS
@@ -81,6 +82,9 @@ MODULE_PARM_DESC(disable_tap_to_click,
HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
HIDPP_QUIRK_HI_RES_SCROLL_X2121)
+/* Just an alias for now, may possibly be a catch-all in the future */
+#define HIDPP_QUIRK_MISSING_SHORT_REPORTS HIDPP_QUIRK_CLASS_BLUETOOTH
+
#define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
#define HIDPP_CAPABILITY_HIDPP10_BATTERY BIT(0)
@@ -340,6 +344,12 @@ static int hidpp_send_rap_command_sync(struct hidpp_device
*hidpp_dev,
struct hidpp_report *message;
int ret, max_count;
+ /* Force long reports on devices that do not support short reports */
+ if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
+ report_id == REPORT_ID_HIDPP_SHORT)
+ report_id = REPORT_ID_HIDPP_LONG;
+
+
switch (report_id) {
case REPORT_ID_HIDPP_SHORT:
max_count = HIDPP_REPORT_SHORT_LENGTH - 4;
@@ -3482,6 +3492,12 @@ static bool hidpp_validate_report(struct hid_device
*hdev, int id,
static bool hidpp_validate_device(struct hid_device *hdev)
{
+ struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+ /* Skip the short report check if the device does not support it */
+ if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
+ return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
+HIDPP_REPORT_LONG_LENGTH, false);
+
return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
HIDPP_REPORT_SHORT_LENGTH, false) &&
hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
@@ -3775,22 +3791,29 @@ static const struct hid_device_id hidpp_devices[] = {
.driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
{ /* MX Anywhere 2 mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb013),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb018),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{ /* MX Anywhere 2S mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01a),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{ /* MX Master mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb017),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{ /* MX Master 2S mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb019),
- .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
+HIDPP_QUIRK_CLASS_BLUETOOTH },
{}
};
--
2.23.0
[PATCH v3 1/4] HID: logitech: Add MX Mice over Bluetooth
This patch adds support for several MX mice over Bluetooth. The device IDs
have been copied from the libratbag device database and their features
have been based on their DJ device counterparts.
Signed-off-by: Mazin Rezk
---
drivers/hid/hid-logitech-hidpp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 0179f7ed77e5..85fd0c17cc2f 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3773,6 +3773,24 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* MX5500 keyboard over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
.driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
+ { /* MX Anywhere 2 mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb013),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb018),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ { /* MX Anywhere 2S mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01a),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ { /* MX Master mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb017),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
+ { /* MX Master 2S mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb019),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
{}
};
--
2.23.0
Re: arm64: ls1028a-qds: correct bus of rtc
On Wed, Sep 04, 2019 at 04:51:04PM +0800, Biwen Li wrote:
> The rtc is on i2c2 bus(hardware), not on i2c1 channel 3,
> so correct it
>
> Signed-off-by: Biwen Li
This looks a like a fix. Do we need a Fixes tag for it?
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index de6ef39f3118..6c0540ad9c59 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -133,11 +133,6 @@
> vcc-supply = <_3v3>;
> };
>
> - rtc@51 {
> - compatible = "nxp,pcf2129";
> - reg = <0x51>;
> - };
> -
> eeprom@56 {
> compatible = "atmel,24c512";
> reg = <0x56>;
> @@ -166,6 +161,14 @@
> };
> };
>
> + {
> + status = "okay";
Please have a newline between properties and child node.
Shawn
> + rtc@51 {
> + compatible = "nxp,pcf2129";
> + reg = <0x51>;
> + };
> +};
> +
> {
> status = "okay";
> };
> --
> 2.17.1
>
[PATCH] clk: qcom: mmcc8974: add frequency table for gfx3d
From: Jonathan Marek
Add frequency table for the gfx3d clock that's needed in order to
support the GPU upstream on msm8974-based systems.
Signed-off-by: Jonathan Marek
Signed-off-by: Brian Masney
---
drivers/clk/qcom/mmcc-msm8974.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index bcb0a397ef91..e70abfe2a792 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++ b/drivers/clk/qcom/mmcc-msm8974.c
@@ -452,10 +452,17 @@ static struct clk_rcg2 mdp_clk_src = {
},
};
+static struct freq_tbl ftbl_gfx3d_clk_src[] = {
+ F(3750, P_GPLL0, 16, 0, 0),
+ F(53300, P_MMPLL0, 1.5, 0, 0),
+ { }
+};
+
static struct clk_rcg2 gfx3d_clk_src = {
.cmd_rcgr = 0x4000,
.hid_width = 5,
.parent_map = mmcc_xo_mmpll0_1_2_gpll0_map,
+ .freq_tbl = ftbl_gfx3d_clk_src,
.clkr.hw.init = &(struct clk_init_data){
.name = "gfx3d_clk_src",
.parent_names = mmcc_xo_mmpll0_1_2_gpll0,
--
2.21.0
Re: [PATCH] mm/page_isolation: fix a deadlock with printk()
> On Oct 5, 2019, at 7:29 PM, Andrew Morton wrote:
>
>> -> #2 (&(>lock)->rlock){-.-.}:
>> lock_acquire+0x21a/0x468
>> _raw_spin_lock+0x54/0x68
>> get_page_from_freelist+0x8b6/0x2d28
>> __alloc_pages_nodemask+0x246/0x658
>> __get_free_pages+0x34/0x78
>> sclp_init+0x106/0x690
>> sclp_register+0x2e/0x248
>> sclp_rw_init+0x4a/0x70
>> sclp_console_init+0x4a/0x1b8
>> console_init+0x2c8/0x410
>> start_kernel+0x530/0x6a0
>> startup_continue+0x70/0xd0
>
> This appears to be the core of our problem?
There are more.
[ 297.425908] WARNING: possible circular locking dependency detected
[ 297.425908] 5.3.0-next-20190917 #8 Not tainted
[ 297.425909] --
[ 297.425910] test.sh/8653 is trying to acquire lock:
[ 297.425911] 865a4460 (console_owner){-.-.}, at:
console_unlock+0x207/0x750
[ 297.425914] but task is already holding lock:
[ 297.425915] 3fff3c58 (&(>lock)->rlock){-.-.}, at:
__offline_isolated_pages+0x179/0x3e0
[ 297.425919] which lock already depends on the new lock.
[ 297.425920] the existing dependency chain (in reverse order) is:
[ 297.425922] -> #3 (&(>lock)->rlock){-.-.}:
[ 297.425925]__lock_acquire+0x5b3/0xb40
[ 297.425925]lock_acquire+0x126/0x280
[ 297.425926]_raw_spin_lock+0x2f/0x40
[ 297.425927]rmqueue_bulk.constprop.21+0xb6/0x1160
[ 297.425928]get_page_from_freelist+0x898/0x22c0
[ 297.425928]__alloc_pages_nodemask+0x2f3/0x1cd0
[ 297.425929]alloc_pages_current+0x9c/0x110
[ 297.425930]allocate_slab+0x4c6/0x19c0
[ 297.425931]new_slab+0x46/0x70
[ 297.425931]___slab_alloc+0x58b/0x960
[ 297.425932]__slab_alloc+0x43/0x70
[ 297.425933]__kmalloc+0x3ad/0x4b0
[ 297.425933]__tty_buffer_request_room+0x100/0x250
[ 297.425934]tty_insert_flip_string_fixed_flag+0x67/0x110
[ 297.425935]pty_write+0xa2/0xf0
[ 297.425936]n_tty_write+0x36b/0x7b0
[ 297.425936]tty_write+0x284/0x4c0
[ 297.425937]__vfs_write+0x50/0xa0
[ 297.425938]vfs_write+0x105/0x290
[ 297.425939]redirected_tty_write+0x6a/0xc0
[ 297.425939]do_iter_write+0x248/0x2a0
[ 297.425940]vfs_writev+0x106/0x1e0
[ 297.425941]do_writev+0xd4/0x180
[ 297.425941]__x64_sys_writev+0x45/0x50
[ 297.425942]do_syscall_64+0xcc/0x76c
[ 297.425943]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 297.425944] -> #2 (&(>lock)->rlock){-.-.}:
[ 297.425946]__lock_acquire+0x5b3/0xb40
[ 297.425947]lock_acquire+0x126/0x280
[ 297.425948]_raw_spin_lock_irqsave+0x3a/0x50
[ 297.425949]tty_port_tty_get+0x20/0x60
[ 297.425949]tty_port_default_wakeup+0xf/0x30
[ 297.425950]tty_port_tty_wakeup+0x39/0x40
[ 297.425951]uart_write_wakeup+0x2a/0x40
[ 297.425952]serial8250_tx_chars+0x22e/0x440
[ 297.425952]serial8250_handle_irq.part.8+0x14a/0x170
[ 297.425953]serial8250_default_handle_irq+0x5c/0x90
[ 297.425954]serial8250_interrupt+0xa6/0x130
[ 297.425955]__handle_irq_event_percpu+0x78/0x4f0
[ 297.425955]handle_irq_event_percpu+0x70/0x100
[ 297.425956]handle_irq_event+0x5a/0x8b
[ 297.425957]handle_edge_irq+0x117/0x370
[ 297.425958]do_IRQ+0x9e/0x1e0
[ 297.425958]ret_from_intr+0x0/0x2a
[ 297.425959]cpuidle_enter_state+0x156/0x8e0
[ 297.425960]cpuidle_enter+0x41/0x70
[ 297.425960]call_cpuidle+0x5e/0x90
[ 297.425961]do_idle+0x333/0x370
[ 297.425962]cpu_startup_entry+0x1d/0x1f
[ 297.425962]start_secondary+0x290/0x330
[ 297.425963]secondary_startup_64+0xb6/0xc0
[ 297.425964] -> #1 (_lock_key){-.-.}:
[ 297.425967]__lock_acquire+0x5b3/0xb40
[ 297.425967]lock_acquire+0x126/0x280
[ 297.425968]_raw_spin_lock_irqsave+0x3a/0x50
[ 297.425969]serial8250_console_write+0x3e4/0x450
[ 297.425970]univ8250_console_write+0x4b/0x60
[ 297.425970]console_unlock+0x501/0x750
[ 297.425971]vprintk_emit+0x10d/0x340
[ 297.425972]vprintk_default+0x1f/0x30
[ 297.425972]vprintk_func+0x44/0xd4
[ 297.425973]printk+0x9f/0xc5
[ 297.425974]register_console+0x39c/0x520
[ 297.425975]univ8250_console_init+0x23/0x2d
[ 297.425975]console_init+0x338/0x4cd
[ 297.425976]start_kernel+0x534/0x724
[ 297.425977]x86_64_start_reservations+0x24/0x26
[ 297.425977]x86_64_start_kernel+0xf4/0xfb
[ 297.425978]secondary_startup_64+0xb6/0xc0
[ 297.425979] -> #0 (console_owner){-.-.}:
[ 297.425982]check_prev_add+0x107/0xea0
[ 297.425982]validate_chain+0x8fc/0x1200
[ 297.425983]__lock_acquire+0x5b3/0xb40
[ 297.425984]lock_acquire+0x126/0x280
[ 297.425984]
Re: [PATCH v3 0/3] tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations
On Thu, Oct 03, 2019 at 09:46:20PM +0300, Jarkko Sakkinen wrote: commit db4d8cb9c9f2af71c4d087817160d866ed572cc9 upstream This backport is for v4.14 and v4.19 The backport requires non-racy behaviour from TPM 1.x sysfs code. Thus, the dependecies for that are included. NOTE: 1/3 is only needed for v4.14. I've queued these for 4.19 and 4.14, thanks! -- Thanks, Sasha
Re: [PATCH] mm/page_isolation: fix a deadlock with printk()
On Sat, 5 Oct 2019 20:10:47 -0400 Qian Cai wrote:
>
>
> >> the existing dependency chain (in reverse order) is:
> >>
> >> -> #2 (&(>lock)->rlock){-.-.}:
> >> lock_acquire+0x21a/0x468
> >> _raw_spin_lock+0x54/0x68
> >> get_page_from_freelist+0x8b6/0x2d28
> >> __alloc_pages_nodemask+0x246/0x658
> >> __get_free_pages+0x34/0x78
> >> sclp_init+0x106/0x690
> >> sclp_register+0x2e/0x248
> >> sclp_rw_init+0x4a/0x70
> >> sclp_console_init+0x4a/0x1b8
> >> console_init+0x2c8/0x410
> >> start_kernel+0x530/0x6a0
> >> startup_continue+0x70/0xd0
> >
> > This appears to be the core of our problem?
>
> No, that is just one of those many places could form the lock chain.
>
> console_lock -> other locks -> zone_lock
>
> Another example is,
>
> https://lore.kernel.org/lkml/1568823006.5576.178.ca...@lca.pw/
There is no "console_lock". Please be much more specific.
> It is easier to avoid,
>
> zone_lock -> console_lock
>
> rather than fixing the opposite.
"ease" isn't the main objective. A more important question is "what
makes sense". We should be able to call printk() from anywhere, any
time under any conditions. That can't be done 100% but it is the
objective. printk() should be robust and not being able to call
printk() while holding zone->lock isn't robust!
btw, this:
: It is unsafe to call printk() while zone->lock was held, i.e.,
:
: zone->lock --> console_sem
doesn't make a lot of sense. console_sem is a sleeping lock so
attempting to acquire it (with down()!) under spinlock is a huge bug.
Again, please be careful with the descriptions.
Re: [GIT PULL] ARM: SoC fixes
The pull request you sent on Sat, 5 Oct 2019 15:41:04 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/43b815c6a8e7dbccb5b8bd9c4b099c24bc22d135 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
On Mon, Sep 23, 2019 at 02:34:07AM +, Anson Huang wrote: > Hi, Pavel > > > Subject: Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding > > > > On Tue 2019-09-03 10:03:40, Anson Huang wrote: > > > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system > > > controller, the system controller is in charge of system power, clock > > > and power key event etc. management, Linux kernel has to communicate > > > with system controller via MU (message unit) IPC to get power key > > > event, add binding doc for i.MX system controller power key driver. > > > > > > Signed-off-by: Anson Huang > > > --- > > > Changes since V1: > > > - remove "wakeup-source" property, as it is NOT needed for SCU > > interrupt; > > > - remove "status" in example. > > > --- > > > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 > > ++ > > > 1 file changed, 14 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > index c149fad..f93e2e4 100644 > > > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > @@ -157,6 +157,15 @@ Required properties: > > > Optional properties: > > > - timeout-sec: contains the watchdog timeout in seconds. > > > > > > +Power key bindings based on SCU Message Protocol > > > + > > > + > > > +Required properties: > > > +- compatible: should be: > > > + "fsl,imx8qxp-sc-pwrkey" > > > + followed by "fsl,imx-sc-pwrkey"; > > > +- linux,keycodes: See > > > +Documentation/devicetree/bindings/input/keys.txt > > > > Note you have keycode_s_ here, but keycode in the example and in the dts > > patch. > > NOT quite understand your point, could you please provide more details? The property being used in driver, DTS, and DT example in the bindings are all 'linux,keycode' rather than 'linux,keycodes'. Shawn
Re: [PATCH] media: vimc: get pixformat info from v4l2_format_info to avoid code repetition
Hi "Carlos, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [cannot apply to v5.4-rc1 next-20191004] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Carlos-E-C-Barbosa/media-vimc-get-pixformat-info-from-v4l2_format_info-to-avoid-code-repetition/20191006-053120 base: git://linuxtv.org/media_tree.git master reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-42-g38eda53-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/media/platform/vimc/vimc-common.c:121:21: sparse: sparse: symbol >> 'vimc_pix_map_fmt_info' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[RFC PATCH] media: vimc: vimc_pix_map_fmt_info() can be static
Fixes: 4d124d159dff ("media: vimc: get pixformat info from v4l2_format_info to
avoid code repetition")
Signed-off-by: kbuild test robot
---
vimc-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vimc/vimc-common.c
b/drivers/media/platform/vimc/vimc-common.c
index 9ea698810e1a1..c37442aba70b1 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -118,7 +118,7 @@ static struct vimc_pix_map_fmt vimc_pix_map_fmt_list[] = {
},
};
-struct vimc_pix_map vimc_pix_map_fmt_info(struct vimc_pix_map_fmt *vfmt)
+static struct vimc_pix_map vimc_pix_map_fmt_info(struct vimc_pix_map_fmt *vfmt)
{
struct vimc_pix_map vpix = {
Re: [PATCH V2] arm64: dts: imx8mn-ddr4-evk: Enable GPIO LED
On Tue, Sep 03, 2019 at 09:27:57AM -0400, Anson Huang wrote: > i.MX8MN DDR4 EVK board has a GPIO LED to indicate status, > add support for it. > > Signed-off-by: Anson Huang Applied, thanks.
Re: MAP_FIXED_NOREPLACE appears to break older i386 binaries
Duh.
I only looked at recent issues in this area, and overlooked your
sentence in between the two ELF section dumps, and it appears that you
have already biseced it to something else:
On Sat, Oct 5, 2019 at 4:32 PM Russell King - ARM Linux admin
wrote:
>
> Seems we've broken older i386 binaries with commit ad55eac74f20
> ("elf: enforce MAP_FIXED on overlaying elf segments"). Maybe the
> MAP_FIXED_NOREPLACE stuff needs to have an on/off switch?
I guess the "can you send people binaries for testing" ends up being
the right thing to do, and Michal can figure it out.
Sorry for the noise.
Linus
Re: [PATCH 5/5 v5] irqchip: Ingenic: Add process for more than one irq at the same time.
Le mer., oct. 2, 2019 at 19:25, Zhou Yanjie a
écrit :
Add process for the situation that more than one irq is coming to
a single chip at the same time. The original code will only respond
to the lowest setted bit in JZ_REG_INTC_PENDING, and then exit the
interrupt dispatch function. After exiting the interrupt dispatch
function, since the second interrupt has not yet responded, the
interrupt dispatch function is again entered to process the second
interrupt. This creates additional unnecessary overhead, and the
more interrupts that occur at the same time, the more overhead is
added. The improved method in this patch is to check whether there
are still unresponsive interrupts after processing the lowest
setted bit interrupt. If there are any, the processing will be
processed according to the bit in JZ_REG_INTC_PENDING, and the
interrupt dispatch function will be exited until all processing
is completed.
Signed-off-by: Zhou Yanjie
Looks good to me.
Reviewed-by: Paul Cercueil
---
drivers/irqchip/irq-ingenic.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-ingenic.c
b/drivers/irqchip/irq-ingenic.c
index 06ab3ad..c1be3d5 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2009-2010, Lars-Peter Clausen
- * JZ4740 platform IRQ support
+ * Ingenic XBurst platform IRQ support
*/
#include
@@ -37,18 +37,23 @@ static irqreturn_t intc_cascade(int irq, void
*data)
struct ingenic_intc_data *intc = irq_get_handler_data(irq);
struct irq_domain *domain = intc->domain;
struct irq_chip_generic *gc;
- uint32_t irq_reg;
+ uint32_t pending;
unsigned i;
for (i = 0; i < intc->num_chips; i++) {
gc = irq_get_domain_generic_chip(domain, i * 32);
- irq_reg = irq_reg_readl(gc, JZ_REG_INTC_PENDING);
- if (!irq_reg)
+ pending = irq_reg_readl(gc, JZ_REG_INTC_PENDING);
+ if (!pending)
continue;
- irq = irq_find_mapping(domain, __fls(irq_reg) + (i * 32));
- generic_handle_irq(irq);
+ while (pending) {
+ int bit = __fls(pending);
+
+ irq = irq_find_mapping(domain, bit + (i * 32));
+ generic_handle_irq(irq);
+ pending &= ~BIT(bit);
+ }
}
return IRQ_HANDLED;
--
2.7.4
Re: [PATCH 1/5 v5] irqchip: ingenic: Drop redundant irq_suspend / irq_resume functions
Hi Zhou,
Le mer., oct. 2, 2019 at 19:25, Zhou Yanjie a
écrit :
From: Paul Cercueil
The same behaviour can be obtained by using the
IRQCHIP_MASK_ON_SUSPEND
flag on the IRQ chip.
Signed-off-by: Paul Cercueil
If you sumbit a patchset that contains someone else's patches you need
to add your Signed-off-by too.
---
drivers/irqchip/irq-ingenic.c | 24 +---
include/linux/irqchip/ingenic.h | 14 --
2 files changed, 1 insertion(+), 37 deletions(-)
delete mode 100644 include/linux/irqchip/ingenic.h
diff --git a/drivers/irqchip/irq-ingenic.c
b/drivers/irqchip/irq-ingenic.c
index f126255..06fa810 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -50,26 +49,6 @@ static irqreturn_t intc_cascade(int irq, void
*data)
return IRQ_HANDLED;
}
-static void intc_irq_set_mask(struct irq_chip_generic *gc, uint32_t
mask)
-{
- struct irq_chip_regs *regs = >chip_types->regs;
-
- writel(mask, gc->reg_base + regs->enable);
- writel(~mask, gc->reg_base + regs->disable);
-}
-
-void ingenic_intc_irq_suspend(struct irq_data *data)
-{
- struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
- intc_irq_set_mask(gc, gc->wake_active);
-}
-
-void ingenic_intc_irq_resume(struct irq_data *data)
-{
- struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
- intc_irq_set_mask(gc, gc->mask_cache);
-}
-
static struct irqaction intc_cascade_action = {
.handler = intc_cascade,
.name = "SoC intc cascade interrupt",
@@ -127,8 +106,7 @@ static int __init ingenic_intc_of_init(struct
device_node *node,
ct->chip.irq_mask = irq_gc_mask_disable_reg;
ct->chip.irq_mask_ack = irq_gc_mask_disable_reg;
ct->chip.irq_set_wake = irq_gc_set_wake;
- ct->chip.irq_suspend = ingenic_intc_irq_suspend;
- ct->chip.irq_resume = ingenic_intc_irq_resume;
+ ct->chip.flags = IRQCHIP_MASK_ON_SUSPEND;
irq_setup_generic_chip(gc, IRQ_MSK(32), 0, 0,
IRQ_NOPROBE | IRQ_LEVEL);
diff --git a/include/linux/irqchip/ingenic.h
b/include/linux/irqchip/ingenic.h
deleted file mode 100644
index 1465588..000
--- a/include/linux/irqchip/ingenic.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2010, Lars-Peter Clausen
- */
-
-#ifndef __LINUX_IRQCHIP_INGENIC_H__
-#define __LINUX_IRQCHIP_INGENIC_H__
-
-#include
-
-extern void ingenic_intc_irq_suspend(struct irq_data *data);
-extern void ingenic_intc_irq_resume(struct irq_data *data);
-
-#endif
--
2.7.4
Re: [PATCH] arm64: dts: lx2160a: add tmu device node
On Tue, Sep 03, 2019 at 11:31:32AM +0800, Yuantian Tang wrote:
> Add the TMU (Thermal Monitoring Unit) device node to enable
> TMU feature.
>
> Signed-off-by: Yuantian Tang
> ---
> .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 108 +++---
> 1 file changed, 92 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index 39d497df769e..e70ddd01cd84 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -6,6 +6,7 @@
>
> #include
> #include
> +#include
>
> /memreserve/ 0x8000 0x0001;
>
> @@ -24,7 +25,7 @@
> #size-cells = <0>;
>
> // 8 clusters having 2 Cortex-A72 cores each
> - cpu@0 {
> + cpu0: cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -38,9 +39,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@1 {
> + cpu1: cpu@1 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -54,9 +56,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@100 {
> + cpu100: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -70,9 +73,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@101 {
> + cpu101: cpu@101 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -86,9 +90,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@200 {
> + cpu200: cpu@200 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -102,9 +107,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@201 {
> + cpu201: cpu@201 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -118,9 +124,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@300 {
> + cpu300: cpu@300 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -134,9 +141,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@301 {
> + cpu301: cpu@301 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -150,9 +158,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@400 {
> + cpu400: cpu@400 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
> enable-method = "psci";
> @@ -166,9 +175,10 @@
> i-cache-sets = <192>;
> next-level-cache = <_l2>;
> cpu-idle-states = <_pw20>;
> + #cooling-cells = <2>;
> };
>
> - cpu@401 {
> + cpu401: cpu@401 {
> device_type = "cpu";
> compatible = "arm,cortex-a72";
>
Re: MAP_FIXED_NOREPLACE appears to break older i386 binaries
On Sat, Oct 5, 2019 at 4:32 PM Russell King - ARM Linux admin
wrote:
>
> Under a 4.19 kernel (debian stable), I am surprised to find that some
> previously working i386 binaries no longer work, whereas others are
> fine. ls, for example, dies with a SEGV, but bash is fine.
Hmm. Is this with some recent stable kernel update? Or has it been
going on for a while and you only noticed now for some reason?
If it's recent, I'd be inclined to blame bbdc6076d2e5 ("binfmt_elf:
move brk out of mmap when doing direct loader exec") which afaik made
it into 4.19.75 and might be in that debian-stable.
And if it's that, then I think that it should be fixed by 7be3cb019db1
("binfmt_elf: Do not move brk for INTERP-less ET_EXEC") which is in
the current queue.
Adding Kees to the cc, in case he goes "No, silly Linus, you're being
stupid", or can confirm that yeah, that was the behavior for the
problem case.
Kees, original report with more information at
https://lore.kernel.org/lkml/20191005233227.gb25...@shell.armlinux.org.uk/
And if that isn't the case, maybe you can send over one of the broken
binaries in private email for testing?
Linus
MAP_FIXED_NOREPLACE appears to break older i386 binaries
Under a 4.19 kernel (debian stable), I am surprised to find that some
previously working i386 binaries no longer work, whereas others are
fine. ls, for example, dies with a SEGV, but bash is fine.
Looking at the kernel log reveals:
[13117.361000] 20899 (ls): Uhuuh, elf segment at 08065000 requested but
the memory is mapped already
[13120.367221] 20935 (vdir): Uhuuh, elf segment at 08065000 requested
but the memory is mapped already
[13122.891253] 20936 (ls): Uhuuh, elf segment at 08065000 requested but
the memory is mapped already
[13137.719143] 20940 (ls): Uhuuh, elf segment at 08065000 requested but
the memory is mapped already
[13139.202469] 20978 (ls): Uhuuh, elf segment at 08065000 requested but
the memory is mapped already
[13158.093533] 21007 (ls): Uhuuh, elf segment at 08065000 requested but
the memory is mapped already
[13221.920939] 21021 (objdump): Uhuuh, elf segment at 080a1000
requested but the memory is mapped already
Looking at /bin/ls:
Program Header:
PHDR off0x0034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x0120 memsz 0x0120 flags r-x
INTERP off0x0154 vaddr 0x08048154 paddr 0x08048154 align 2**0
filesz 0x0013 memsz 0x0013 flags r--
LOAD off0x vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x0001d620 memsz 0x0001d620 flags r-x
LOAD off0x0001d950 vaddr 0x08065950 paddr 0x08065950 align 2**12
filesz 0x0a50 memsz 0x16e4 flags rw-
DYNAMIC off0x0001dec4 vaddr 0x08065ec4 paddr 0x08065ec4 align 2**2
filesz 0x0100 memsz 0x0100 flags rw-
NOTE off0x0168 vaddr 0x08048168 paddr 0x08048168 align 2**2
filesz 0x0044 memsz 0x0044 flags r--
EH_FRAME off0x00018e68 vaddr 0x08060e68 paddr 0x08060e68 align 2**2
filesz 0x0774 memsz 0x0774 flags r--
STACK off0x vaddr 0x paddr 0x align 2**4
filesz 0x memsz 0x flags rw-
RELRO off0x0001d950 vaddr 0x08065950 paddr 0x08065950 align 2**0
filesz 0x06b0 memsz 0x06b0 flags r--
Note that the executable part of ls extends from 0x08048000 for
0x0001d620 bytes in memory and file, which takes that up to
0x08065620. The rw data section starts at 0x08065950.
Seems we've broken older i386 binaries with commit ad55eac74f20
("elf: enforce MAP_FIXED on overlaying elf segments"). Maybe the
MAP_FIXED_NOREPLACE stuff needs to have an on/off switch?
Here's the objdump -h output for the same binary:
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 0013 08048154 08048154 0154 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 0020 08048168 08048168 0168 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .note.gnu.build-id 0024 08048188 08048188 0188 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .gnu.hash 003c 080481ac 080481ac 01ac 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynsym 0840 080481e8 080481e8 01e8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .gnu.liblist 00c8 08048a28 08048a28 0a28 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version 0108 08049020 08049020 1020 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version_r 00c0 08049128 08049128 1128 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rel.dyn 0048 080491e8 080491e8 11e8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rel.plt 0390 08049230 08049230 1230 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .init 0023 080495c0 080495c0 15c0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .plt 0730 080495f0 080495f0 15f0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .text 00013274 08049d20 08049d20 1d20 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .fini 0014 0805cf94 0805cf94 00014f94 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .rodata 3ea8 0805cfc0 0805cfc0 00014fc0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
15 .eh_frame_hdr 0774 08060e68 08060e68 00018e68 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 .eh_frame 341c 080615dc 080615dc 000195dc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .dynstr 064c 080649f8 080649f8 0001c9f8 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .gnu.conflict 05dc 08065044 08065044 0001d044 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
19 .init_array 0004 08065950 08065950 0001d950
[PATCH] lib: test_user_copy: style cleanup
While writing the tests for copy_struct_from_user(), I used a construct
that Linus doesn't appear to be too fond of:
On 2019-10-04, Linus Torvalds wrote:
> Hmm. That code is ugly, both before and after the fix.
>
> This just doesn't make sense for so many reasons:
>
> if ((ret |= test(umem_src == NULL, "kmalloc failed")))
>
> where the insanity comes from
>
> - why "|=" when you know that "ret" was zero before (and it had to
>be, for the test to make sense)
>
> - why do this as a single line anyway?
>
> - don't do the stupid "double parenthesis" to hide a warning. Make it
>use an actual comparison if you add a layer of parentheses.
So instead, use a bog-standard check that isn't nearly as ugly.
Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in
test_copy_struct_from_user")
Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
Signed-off-by: Aleksa Sarai
---
lib/test_user_copy.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
index e365ace06538..ad2372727b1b 100644
--- a/lib/test_user_copy.c
+++ b/lib/test_user_copy.c
@@ -52,13 +52,14 @@ static int test_check_nonzero_user(char *kmem, char __user
*umem, size_t size)
size_t zero_end = size - zero_start;
/*
-* We conduct a series of check_nonzero_user() tests on a block of
memory
-* with the following byte-pattern (trying every possible [start,end]
-* pair):
+* We conduct a series of check_nonzero_user() tests on a block of
+* memory with the following byte-pattern (trying every possible
+* [start,end] pair):
*
* [ 00 ff 00 ff ... 00 00 00 00 ... ff 00 ff 00 ]
*
-* And we verify that check_nonzero_user() acts identically to
memchr_inv().
+* And we verify that check_nonzero_user() acts identically to
+* memchr_inv().
*/
memset(kmem, 0x0, size);
@@ -93,11 +94,13 @@ static int test_copy_struct_from_user(char *kmem, char
__user *umem,
size_t ksize, usize;
umem_src = kmalloc(size, GFP_KERNEL);
- if ((ret |= test(umem_src == NULL, "kmalloc failed")))
+ ret = test(umem_src == NULL, "kmalloc failed");
+ if (ret)
goto out_free;
expected = kmalloc(size, GFP_KERNEL);
- if ((ret |= test(expected == NULL, "kmalloc failed")))
+ ret = test(expected == NULL, "kmalloc failed");
+ if (ret)
goto out_free;
/* Fill umem with a fixed byte pattern. */
--
2.23.0
Re: [PATCH] mm/page_isolation: fix a deadlock with printk()
On Fri, 4 Oct 2019 12:42:26 -0400 Qian Cai wrote:
> It is unsafe to call printk() while zone->lock was held, i.e.,
>
> zone->lock --> console_sem
>
> because the console could always allocate some memory in different code
> paths and form locking chains in an opposite order,
>
> console_sem --> * --> zone->lock
>
> As the result, it triggers lockdep splats like below and in [1]. It is
> fine to take zone->lock after has_unmovable_pages() (which has
> dump_stack()) in set_migratetype_isolate(). While at it, remove a
> problematic printk() in __offline_isolated_pages() only for debugging as
> well which will always disable lockdep on debug kernels.
>
> The problem is probably there forever, but neither many developers will
> run memory offline with the lockdep enabled nor admins in the field are
> lucky enough yet to hit a perfect timing which required to trigger a
> real deadlock. In addition, there aren't many places that call printk()
> while zone->lock was held.
>
> WARNING: possible circular locking dependency detected
> --
> test.sh/1724 is trying to acquire lock:
> 52059ec0 (console_owner){-...}, at: console_unlock+0x
> 01: 328/0xa30
>
> but task is already holding lock:
> 6ffd89c8 (&(>lock)->rlock){-.-.}, at: start_iso
> 01: late_page_range+0x216/0x538
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&(>lock)->rlock){-.-.}:
>lock_acquire+0x21a/0x468
>_raw_spin_lock+0x54/0x68
>get_page_from_freelist+0x8b6/0x2d28
>__alloc_pages_nodemask+0x246/0x658
>__get_free_pages+0x34/0x78
>sclp_init+0x106/0x690
>sclp_register+0x2e/0x248
>sclp_rw_init+0x4a/0x70
>sclp_console_init+0x4a/0x1b8
>console_init+0x2c8/0x410
>start_kernel+0x530/0x6a0
>startup_continue+0x70/0xd0
This appears to be the core of our problem? At initialization time,
the sclp driver registers an inappropriate dependency with lockdep. It
does this by calling into the page allocator while holding sclp_lock.
But we don't *want* to teach lockdep that sclp_lock nests outside
zone->lock. We want the opposite.
So can we address this class of problem by declaring "thou shalt not
call the page allocator while holding a lock which can be taken on the
prink path?". And then declare sclp to be defective.
And I think sclp is kinda buggy-but-lucky anyway: if console output is
directed to sclp device #0 and we're then trying to initialize sclp
device #1 then any printk which happens during that initialization will
deadlock. The driver escapes this by only supporting a single device
system-wide but it's not a model which drivers should generally follow.
(And if sclp will only ever support a single device system-wide, why
the heck does it need to take sclp_lock() on the device initialization
path??)
Re: [PATCH v15 13/14] gpio: max3191x: Utilize the for_each_set_clump8 macro
Hi William,
I love your patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-for_each_set_clump8-macro/20191006-032112
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpio/gpio-max3191x.c: In function 'max3191x_get_multiple':
>> drivers/gpio/gpio-max3191x.c:258:31: error: 'offset' undeclared (first use
>> in this function); did you mean 'off_t'?
bitmap_set_value8(bits, in, offset);
^~
off_t
drivers/gpio/gpio-max3191x.c:258:31: note: each undeclared identifier is
reported only once for each function it appears in
vim +258 drivers/gpio/gpio-max3191x.c
231
232 static int max3191x_get_multiple(struct gpio_chip *gpio, unsigned long
*mask,
233 unsigned long *bits)
234 {
235 struct max3191x_chip *max3191x = gpiochip_get_data(gpio);
236 const unsigned int wordlen = max3191x_wordlen(max3191x);
237 int ret;
238 unsigned long bit;
239 unsigned long gpio_mask;
240 unsigned long in;
241
242 mutex_lock(>lock);
243 ret = max3191x_readout_locked(max3191x);
244 if (ret)
245 goto out_unlock;
246
247 bitmap_zero(bits, gpio->ngpio);
248 for_each_set_clump8(bit, gpio_mask, mask, gpio->ngpio) {
249 unsigned int chipnum = bit / MAX3191X_NGPIO;
250
251 if (max3191x_chip_is_faulting(max3191x, chipnum)) {
252 ret = -EIO;
253 goto out_unlock;
254 }
255
256 in = ((u8 *)max3191x->xfer.rx_buf)[chipnum * wordlen];
257 in &= gpio_mask;
> 258 bitmap_set_value8(bits, in, offset);
259 }
260
261 out_unlock:
262 mutex_unlock(>lock);
263 return ret;
264 }
265
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[rcu:dev.2019.10.02a 24/24] net/sched/act_sample.c:105:2: error: implicit declaration of function 'rcu_swap_protected'; did you mean '_pcp_protect'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.10.02a
head: 06250c65ccb8bd7cbaffe62ed0cc638c0f15b49c
commit: 06250c65ccb8bd7cbaffe62ed0cc638c0f15b49c [24/24] rcu: Remove
rcu_swap_protected()
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 06250c65ccb8bd7cbaffe62ed0cc638c0f15b49c
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
net/sched/act_sample.c: In function 'tcf_sample_init':
>> net/sched/act_sample.c:105:2: error: implicit declaration of function
>> 'rcu_swap_protected'; did you mean '_pcp_protect'?
>> [-Werror=implicit-function-declaration]
rcu_swap_protected(s->psample_group, psample_group,
^~
_pcp_protect
cc1: some warnings being treated as errors
vim +105 net/sched/act_sample.c
5c5670fae43027 Yotam Gigi 2017-01-23 35
5c5670fae43027 Yotam Gigi 2017-01-23 36 static int
tcf_sample_init(struct net *net, struct nlattr *nla,
5c5670fae43027 Yotam Gigi 2017-01-23 37 struct
nlattr *est, struct tc_action **a, int ovr,
85d0966fa57e0e Davide Caratti 2019-03-20 38 int bind,
bool rtnl_held, struct tcf_proto *tp,
789871bb2a0381 Vlad Buslov2018-07-05 39 struct
netlink_ext_ack *extack)
5c5670fae43027 Yotam Gigi 2017-01-23 40 {
5c5670fae43027 Yotam Gigi 2017-01-23 41 struct tc_action_net *tn =
net_generic(net, sample_net_id);
5c5670fae43027 Yotam Gigi 2017-01-23 42 struct nlattr
*tb[TCA_SAMPLE_MAX + 1];
5c5670fae43027 Yotam Gigi 2017-01-23 43 struct psample_group
*psample_group;
7be8ef2cdbfe41 Dmytro Linkin 2019-08-01 44 u32 psample_group_num, rate,
index;
e8c87c643ef360 Davide Caratti 2019-03-20 45 struct tcf_chain *goto_ch =
NULL;
5c5670fae43027 Yotam Gigi 2017-01-23 46 struct tc_sample *parm;
5c5670fae43027 Yotam Gigi 2017-01-23 47 struct tcf_sample *s;
5c5670fae43027 Yotam Gigi 2017-01-23 48 bool exists = false;
0190c1d452a91c Vlad Buslov2018-07-05 49 int ret, err;
5c5670fae43027 Yotam Gigi 2017-01-23 50
5c5670fae43027 Yotam Gigi 2017-01-23 51 if (!nla)
5c5670fae43027 Yotam Gigi 2017-01-23 52 return -EINVAL;
8cb081746c031f Johannes Berg 2019-04-26 53 ret =
nla_parse_nested_deprecated(tb, TCA_SAMPLE_MAX, nla,
8cb081746c031f Johannes Berg 2019-04-26 54
sample_policy, NULL);
5c5670fae43027 Yotam Gigi 2017-01-23 55 if (ret < 0)
5c5670fae43027 Yotam Gigi 2017-01-23 56 return ret;
5c5670fae43027 Yotam Gigi 2017-01-23 57 if (!tb[TCA_SAMPLE_PARMS] ||
!tb[TCA_SAMPLE_RATE] ||
5c5670fae43027 Yotam Gigi 2017-01-23 58
!tb[TCA_SAMPLE_PSAMPLE_GROUP])
5c5670fae43027 Yotam Gigi 2017-01-23 59 return -EINVAL;
5c5670fae43027 Yotam Gigi 2017-01-23 60
5c5670fae43027 Yotam Gigi 2017-01-23 61 parm =
nla_data(tb[TCA_SAMPLE_PARMS]);
7be8ef2cdbfe41 Dmytro Linkin 2019-08-01 62 index = parm->index;
7be8ef2cdbfe41 Dmytro Linkin 2019-08-01 63 err = tcf_idr_check_alloc(tn,
, a, bind);
0190c1d452a91c Vlad Buslov2018-07-05 64 if (err < 0)
0190c1d452a91c Vlad Buslov2018-07-05 65 return err;
0190c1d452a91c Vlad Buslov2018-07-05 66 exists = err;
5c5670fae43027 Yotam Gigi 2017-01-23 67 if (exists && bind)
5c5670fae43027 Yotam Gigi 2017-01-23 68 return 0;
5c5670fae43027 Yotam Gigi 2017-01-23 69
5c5670fae43027 Yotam Gigi 2017-01-23 70 if (!exists) {
7be8ef2cdbfe41 Dmytro Linkin 2019-08-01 71 ret =
tcf_idr_create(tn, index, est, a,
34043d250f5136 Davide Caratti 2018-09-14 72
_sample_ops, bind, true);
0190c1d452a91c Vlad Buslov2018-07-05 73 if (ret) {
7be8ef2cdbfe41 Dmytro Linkin 2019-08-01 74
tcf_idr_cleanup(tn, index);
5c5670fae43027 Yotam Gigi 2017-01-23 75 return ret;
0190c1d452a91c Vlad Buslov2018-07-05 76 }
5c5670fae43027 Yotam Gigi 2017-01-23 77 ret = ACT_P_CREATED;
4e8ddd7f1758ca Vlad Buslov2018-07-05 78 } else if (!ovr) {
65a206c01e8e7f Chris Mi 2017-08-30 79 tcf_idr_release(*a,
bind);
5c5670fae43027 Yotam Gigi 2017-01-23 80 return -EEXIST;
5c5670fae43027 Yotam Gigi 2017-01-23 81 }
e8c87c643ef360 Davide Caratti 2019-03-20 82 err =
tcf_action_check_ctrlact(parm->action, tp, _ch, extack);
e8c87c643ef360 Davide Caratti 2019-03-20 83 if (err < 0)
e8c87c643ef360 Davide Caratti
Re: [PATCH AUTOSEL 4.14 08/23] ARM: 8875/1: Kconfig: default to AEABI w/ Clang
On Sun, Sep 29, 2019 at 11:08:52AM -0700, Nathan Chancellor wrote: On Sun, Sep 29, 2019 at 01:35:18PM -0400, Sasha Levin wrote: From: Nick Desaulniers [ Upstream commit a05b9608456e0d4464c6f7ca8572324ace57a3f4 ] Clang produces references to __aeabi_uidivmod and __aeabi_idivmod for arm-linux-gnueabi and arm-linux-gnueabihf targets incorrectly when AEABI is not selected (such as when OABI_COMPAT is selected). While this means that OABI userspaces wont be able to upgraded to kernels built with Clang, it means that boards that don't enable AEABI like s3c2410_defconfig will stop failing to link in KernelCI when built with Clang. Link: https://github.com/ClangBuiltLinux/linux/issues/482 Link: https://groups.google.com/forum/#!msg/clang-built-linux/yydsAAux5hk/GxjqJSW-AQAJ Suggested-by: Arnd Bergmann Signed-off-by: Nick Desaulniers Reviewed-by: Arnd Bergmann Reviewed-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Sasha Levin --- arch/arm/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cf69aab648fbd..f0080864b9ce8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1595,8 +1595,9 @@ config ARM_PATCH_IDIV code to do integer division. config AEABI - bool "Use the ARM EABI to compile the kernel" if !CPU_V7 && !CPU_V7M && !CPU_V6 && !CPU_V6K - default CPU_V7 || CPU_V7M || CPU_V6 || CPU_V6K + bool "Use the ARM EABI to compile the kernel" if !CPU_V7 && \ + !CPU_V7M && !CPU_V6 && !CPU_V6K && !CC_IS_CLANG + default CPU_V7 || CPU_V7M || CPU_V6 || CPU_V6K || CC_IS_CLANG help This option allows for the kernel to be compiled using the latest ARM ABI (aka EABI). This is only useful if you are using a user -- 2.20.1 Hi Sasha, This patch will not do anything for 4.14 because CC_IS_CLANG is not defined in this tree. The Kconfig patches that make this symbol possible were not merged until 4.18. I would recommend dropping it (unless Nick has an idea to make this work). I've dropped it from 4.14 and older, thanks! -- Thanks, Sasha
Re: [PATCH AUTOSEL 4.19 12/33] MIPS: lantiq: update the clock alias' for the mainline PCIe PHY driver
On Sun, Sep 29, 2019 at 07:40:28PM +0200, Martin Blumenstingl wrote: Hi Sasha, On Sun, Sep 29, 2019 at 7:34 PM Sasha Levin wrote: From: Martin Blumenstingl [ Upstream commit ed90302be64a53d9031c8ce05428c358b16a5d96 ] The mainline PCIe PHY driver has it's own devicetree node. Update the clock alias so the mainline driver finds the clocks. the mainline PCIe PHY driver only made it into Linux 5.4 I am pointing this out because OpenWrt uses an out-of-tree PCIe driver with Linux 4.19 and this patch will break that if we don't do additional work there thus I would like to understand why this got queued as backport for various -stable kernels It went through the automatic selection process, where we attempt to identify fixes that were not tagged for stable. I've dropped this patch from all stable trees, thank you. -- Thanks, Sasha
Re: [PATCH AUTOSEL 5.2 17/42] MIPS: lantiq: update the clock alias' for the mainline PCIe PHY driver
On Sun, Sep 29, 2019 at 07:39:49PM +0200, Hauke Mehrtens wrote: On 9/29/19 7:32 PM, Sasha Levin wrote: From: Martin Blumenstingl [ Upstream commit ed90302be64a53d9031c8ce05428c358b16a5d96 ] The mainline PCIe PHY driver has it's own devicetree node. Update the clock alias so the mainline driver finds the clocks. The first PCIe PHY is located at 0x1f106800 and exists on VRX200, ARX300 and GRX390. The second PCIe PHY is located at 0x1f700400 and exists on ARX300 and GRX390. The third PCIe PHY is located at 0x1f106a00 and exists onl on GRX390. Lantiq's board support package (called "UGW") names these registers "PDI". Signed-off-by: Martin Blumenstingl Signed-off-by: Paul Burton Cc: linux-m...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: j...@phrozen.org Cc: kis...@ti.com Cc: r...@linux-mips.org Cc: robh...@kernel.org Cc: linux-kernel@vger.kernel.org Cc: ha...@hauke-m.de Cc: mark.rutl...@arm.com Cc: m...@dev.tdt.de Signed-off-by: Sasha Levin --- arch/mips/lantiq/xway/sysctrl.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) Hi Sasha, This change only makes sense with the new upstream PCIe phy driver which was added to kernel 5.4 [0], older kernel versions do not have this PCIe PHY driver. I would not backport these changes to older kernel versions. I'll drop it, thank you! -- Thanks, Sasha
Re: [PATCH AUTOSEL 5.3 20/49] firmware: bcm47xx_nvram: Correct size_t printf format
On Sun, Sep 29, 2019 at 12:39:05PM -0700, Florian Fainelli wrote:
On 9/29/2019 10:30 AM, Sasha Levin wrote:
From: Florian Fainelli
[ Upstream commit feb4eb060c3aecc3c5076bebe699cd09f1133c41 ]
When building on a 64-bit host, we will get warnings like those:
drivers/firmware/broadcom/bcm47xx_nvram.c:103:3: note: in expansion of macro
'pr_err'
pr_err("nvram on flash (%i bytes) is bigger than the reserved space in memory,
will just copy the first %i bytes\n",
^~
drivers/firmware/broadcom/bcm47xx_nvram.c:103:28: note: format string is
defined here
pr_err("nvram on flash (%i bytes) is bigger than the reserved space in memory,
will just copy the first %i bytes\n",
~^
%li
Use %zu instead for that purpose.
This is not a fix that should be backported as it was done only to allow
the driver to the made buildable with COMPILE_TEST. Please drop it from
your auto-selection.
Now dropped, thank you!
--
Thanks,
Sasha
Re: [PATCH 0/3] net: phy: switch to using fwnode_gpiod_get_index
From: Dmitry Torokhov Date: Fri, 4 Oct 2019 16:13:53 -0700 > This series switches phy drivers form using fwnode_get_named_gpiod() and > gpiod_get_from_of_node() that are scheduled to be removed in favor > of fwnode_gpiod_get_index() that behaves more like standard > gpiod_get_index() and will potentially handle secondary software > nodes in cases we need to augment platform firmware. > > This depends on the new code that can be bound in > ib-fwnode-gpiod-get-index immutable branch of Linus' Walleij tree: > > git pull > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > ib-fwnode-gpiod-get-index > > I hope that it would be possible to pull in this immutable branch and > not wait until after 5.5 merge window. For series: Acked-by: David S. Miller
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c: Linux 5.4-rc1 (2019-09-30 10:35:40 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes for you to fetch changes up to 60c1b3e25728e0485f08e72e61c3cad5331925a3: ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support (2019-10-04 10:18:55 -0700) ARM: SoC fixes A few fixes this time around: - Fixup of some clock specifications for DRA7 (device-tree fix) - Removal of some dead/legacy CPU OPP/PM code for OMAP that throws warnings at boot - A few more minor fixups for OMAPs, most around display - Enable STM32 QSPI as =y since their rootfs sometimes comes from there - Switch CONFIG_REMOTEPROC to =y since it went from tristate to bool - Fix of thermal zone definition for ux500 (5.4 regression) Adam Ford (1): ARM: omap2plus_defconfig: Enable DRM_TI_TFP410 H. Nikolaus Schaller (1): DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again Keerthy (1): arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to y Linus Walleij (1): ARM: dts: ux500: Fix up the CPU thermal zone Olof Johansson (1): Merge tag 'omap-for-v5.4/fixes-rc1-signed' of git://git.kernel.org/.../tmlind/linux-omap into arm/fixes Patrice Chotard (1): ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support Peter Ujfalusi (1): ARM: dts: am4372: Set memory bandwidth limit for DISPC Tony Lindgren (8): clk: ti: dra7: Fix mcasp8 clock bits ARM: dts: Fix wrong clocks for dra7 mcasp Merge branch 'fixes-merge-window-pt2' into fixes ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules ARM: dts: Fix gpio0 flags for am335x-icev2 ARM: OMAP2+: Fix missing reset done flag for am3 and am43 ARM: OMAP2+: Add missing LCDC midlemode for am335x ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() arch/arm/boot/dts/am335x-icev2.dts | 2 +- arch/arm/boot/dts/am33xx-l4.dtsi | 6 +- arch/arm/boot/dts/am4372.dtsi | 2 + arch/arm/boot/dts/dra7-l4.dtsi | 48 +- arch/arm/boot/dts/omap3-gta04.dtsi | 1 + arch/arm/boot/dts/ste-dbx5x0.dtsi | 11 ++- arch/arm/configs/davinci_all_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig| 4 +- arch/arm/configs/omap2plus_defconfig | 5 +- .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 3 +- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 5 +- arch/arm/mach-omap2/pm.c | 100 - arch/arm64/configs/defconfig | 2 +- drivers/clk/ti/clk-7xx.c | 6 +- 14 files changed, 53 insertions(+), 144 deletions(-)
Re: [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages()
> On Oct 5, 2019, at 5:22 PM, Andrew Morton wrote: > > Apparently some console drivers can do memory allocation on the printk() > path. > > This behavior is daft, IMO. Have we identified which ones and looked > into fixing them? Not necessary that simple. It is more of 2+ CPUs required to trigger the deadlock. Please see my v2 patch I sent which has all the information. Especially, the thread link included there which contains a few lockdep splat traces and the s390 one in the patch description.
[PATCH net] net: dsa: b53: Do not clear existing mirrored port mask
Clearing the existing bitmask of mirrored ports essentially prevents us
from capturing more than one port at any given time. This is clearly
wrong, do not clear the bitmask prior to setting up the new port.
Reported-by: Hubert Feurstein
Fixes: ed3af5fd08eb ("net: dsa: b53: Add support for port mirroring")
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_common.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 526ba2ab66f1..cc3536315eff 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1845,7 +1845,6 @@ int b53_mirror_add(struct dsa_switch *ds, int port,
loc = B53_EG_MIR_CTL;
b53_read16(dev, B53_MGMT_PAGE, loc, );
- reg &= ~MIRROR_MASK;
reg |= BIT(port);
b53_write16(dev, B53_MGMT_PAGE, loc, reg);
--
2.17.1
[rcu:dev.2019.10.02a 24/24] security/safesetid/securityfs.c:182:2: error: implicit declaration of function 'rcu_swap_protected'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.10.02a
head: 06250c65ccb8bd7cbaffe62ed0cc638c0f15b49c
commit: 06250c65ccb8bd7cbaffe62ed0cc638c0f15b49c [24/24] rcu: Remove
rcu_swap_protected()
config: i386-randconfig-a002-201940 (attached as .config)
compiler: gcc-6 (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
reproduce:
git checkout 06250c65ccb8bd7cbaffe62ed0cc638c0f15b49c
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
security/safesetid/securityfs.c: In function 'handle_policy_update':
>> security/safesetid/securityfs.c:182:2: error: implicit declaration of
>> function 'rcu_swap_protected' [-Werror=implicit-function-declaration]
rcu_swap_protected(safesetid_setuid_rules, pol,
^~
cc1: some warnings being treated as errors
vim +/rcu_swap_protected +182 security/safesetid/securityfs.c
4f72123da57965 Jann Horn2019-04-11 109
03638e62f55f27 Jann Horn2019-04-10 110 static ssize_t
handle_policy_update(struct file *file,
03638e62f55f27 Jann Horn2019-04-10 111
const char __user *ubuf, size_t len)
03638e62f55f27 Jann Horn2019-04-10 112 {
03638e62f55f27 Jann Horn2019-04-10 113 struct setuid_ruleset *pol;
03638e62f55f27 Jann Horn2019-04-10 114 char *buf, *p, *end;
03638e62f55f27 Jann Horn2019-04-10 115 int err;
03638e62f55f27 Jann Horn2019-04-10 116
03638e62f55f27 Jann Horn2019-04-10 117 pol = kmalloc(sizeof(struct
setuid_ruleset), GFP_KERNEL);
03638e62f55f27 Jann Horn2019-04-10 118 if (!pol)
03638e62f55f27 Jann Horn2019-04-10 119 return -ENOMEM;
fbd9acb2dc2aa5 Jann Horn2019-04-11 120 pol->policy_str = NULL;
03638e62f55f27 Jann Horn2019-04-10 121 hash_init(pol->rules);
03638e62f55f27 Jann Horn2019-04-10 122
03638e62f55f27 Jann Horn2019-04-10 123 p = buf = memdup_user_nul(ubuf,
len);
03638e62f55f27 Jann Horn2019-04-10 124 if (IS_ERR(buf)) {
03638e62f55f27 Jann Horn2019-04-10 125 err = PTR_ERR(buf);
03638e62f55f27 Jann Horn2019-04-10 126 goto out_free_pol;
03638e62f55f27 Jann Horn2019-04-10 127 }
fbd9acb2dc2aa5 Jann Horn2019-04-11 128 pol->policy_str = kstrdup(buf,
GFP_KERNEL);
fbd9acb2dc2aa5 Jann Horn2019-04-11 129 if (pol->policy_str == NULL) {
fbd9acb2dc2aa5 Jann Horn2019-04-11 130 err = -ENOMEM;
fbd9acb2dc2aa5 Jann Horn2019-04-11 131 goto out_free_buf;
fbd9acb2dc2aa5 Jann Horn2019-04-11 132 }
03638e62f55f27 Jann Horn2019-04-10 133
03638e62f55f27 Jann Horn2019-04-10 134 /* policy lines, including the
last one, end with \n */
03638e62f55f27 Jann Horn2019-04-10 135 while (*p != '\0') {
03638e62f55f27 Jann Horn2019-04-10 136 struct setuid_rule
*rule;
03638e62f55f27 Jann Horn2019-04-10 137
03638e62f55f27 Jann Horn2019-04-10 138 end = strchr(p, '\n');
03638e62f55f27 Jann Horn2019-04-10 139 if (end == NULL) {
03638e62f55f27 Jann Horn2019-04-10 140 err = -EINVAL;
03638e62f55f27 Jann Horn2019-04-10 141 goto
out_free_buf;
03638e62f55f27 Jann Horn2019-04-10 142 }
03638e62f55f27 Jann Horn2019-04-10 143 *end = '\0';
03638e62f55f27 Jann Horn2019-04-10 144
03638e62f55f27 Jann Horn2019-04-10 145 rule =
kmalloc(sizeof(struct setuid_rule), GFP_KERNEL);
03638e62f55f27 Jann Horn2019-04-10 146 if (!rule) {
03638e62f55f27 Jann Horn2019-04-10 147 err = -ENOMEM;
03638e62f55f27 Jann Horn2019-04-10 148 goto
out_free_buf;
03638e62f55f27 Jann Horn2019-04-10 149 }
03638e62f55f27 Jann Horn2019-04-10 150
03638e62f55f27 Jann Horn2019-04-10 151 err =
parse_policy_line(file, p, rule);
03638e62f55f27 Jann Horn2019-04-10 152 if (err)
03638e62f55f27 Jann Horn2019-04-10 153 goto
out_free_rule;
03638e62f55f27 Jann Horn2019-04-10 154
03638e62f55f27 Jann Horn2019-04-10 155 if
(_setuid_policy_lookup(pol, rule->src_uid, rule->dst_uid) ==
03638e62f55f27 Jann Horn2019-04-10 156 SIDPOL_ALLOWED) {
03638e62f55f27 Jann Horn2019-04-10 157 pr_warn("bad
policy: duplicate entry\n");
03638e62f55f27 Jann Horn2019-04-10 158 err = -EEXIST;
03638e62f55f27 Jann Horn2019-04-10 159 goto
out_free_rule;
03638e62f55f27 Jann Horn2019-04-10 160 }
03638e62f55f27 Jann Horn2019-04-10 161
4f72123da57965 Jann Horn2019-04-11 162 insert_rule(pol, rule);
03638e62f55f27 Jann Horn
[usb:usb-next 32/37] drivers/usb/typec/hd3ss3220.c:123:13: sparse: sparse: symbol 'hd3ss3220_irq' was not declared. Should it be static?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next head: 905eccc6a509d2818e3dd1304c55dc5291b7ea88 commit: 1c48c759ef4bb9031b3347277f04484e07e27d97 [32/37] usb: typec: driver for TI HD3SS3220 USB Type-C DRP port controller reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-42-g38eda53-dirty git checkout 1c48c759ef4bb9031b3347277f04484e07e27d97 make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/usb/typec/hd3ss3220.c:123:13: sparse: sparse: symbol 'hd3ss3220_irq' >> was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] nvme-pci: Shutdown when removing dead controller
> What is the bad CSTS bit? CSTS.RDY?
The reset will be triggered by the result of nvme_should_reset():
1196 static bool nvme_should_reset(struct nvme_dev *dev, u32 csts)
1197 {
1198
1199 ⇥ /* If true, indicates loss of adapter communication, possibly by a
1200 ⇥* NVMe Subsystem reset.
1201 ⇥*/
1202 ⇥ bool nssro = dev->subsystem && (csts & NVME_CSTS_NSSRO);
This csts value is set in nvme_timeout:
1240 static enum blk_eh_timer_return nvme_timeout(struct request *req,
bool reserved)
1241 {
...
1247 ⇥ u32 csts = readl(dev->bar + NVME_REG_CSTS);
...
1256 ⇥ /*
1257 ⇥* Reset immediately if the controller is failed
1258 ⇥*/
1259 ⇥ if (nvme_should_reset(dev, csts)) {
1260 ⇥ ⇥ nvme_warn_reset(dev, csts);
1261 ⇥ ⇥ nvme_dev_disable(dev, false);
1262 ⇥ ⇥ nvme_reset_ctrl(>ctrl);
Again, here's the message printed by nvme_warn_reset:
Aug 26 15:01:27 testhost kernel: nvme nvme4: controller is down; will
reset: CSTS=0x3, PCI_STATUS=0x10
>From include/linux/nvme.h:
105 ⇥ NVME_REG_CSTS⇥ = 0x001c,⇥ /* Controller Status */
- Tyler
[RFC PATCH usb] usb: typec: hd3ss3220_irq() can be static
Fixes: 1c48c759ef4b ("usb: typec: driver for TI HD3SS3220 USB Type-C DRP port
controller")
Signed-off-by: kbuild test robot
---
hd3ss3220.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/typec/hd3ss3220.c b/drivers/usb/typec/hd3ss3220.c
index b8f247e792b87..1900910c637e3 100644
--- a/drivers/usb/typec/hd3ss3220.c
+++ b/drivers/usb/typec/hd3ss3220.c
@@ -120,7 +120,7 @@ static void hd3ss3220_set_role(struct hd3ss3220 *hd3ss3220)
}
}
-irqreturn_t hd3ss3220_irq(struct hd3ss3220 *hd3ss3220)
+static irqreturn_t hd3ss3220_irq(struct hd3ss3220 *hd3ss3220)
{
int err;
+ printf-add-support-for-printing-symbolic-error-codes.patch added to -mm tree
The patch titled
Subject: vsprintf: add support for printing symbolic error codes
has been added to the -mm tree. Its filename is
printf-add-support-for-printing-symbolic-error-codes.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/printf-add-support-for-printing-symbolic-error-codes.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/printf-add-support-for-printing-symbolic-error-codes.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: Rasmus Villemoes
Subject: vsprintf: add support for printing symbolic error codes
It has been suggested several times to extend vsnprintf() to be able to
convert the numeric value of ENOSPC to print "ENOSPC". This is yet
another attempt. Rather than adding another %p extension, simply teach
plain %p to convert ERR_PTRs. While the primary use case is
if (IS_ERR(foo)) {
pr_err("Sorry, can't do that: %p
", foo);
return PTR_ERR(foo);
}
It is also more helpful to get a symbolic error code (or, worst case, a
decimal number) in case an ERR_PTR is accidentally passed to some
%p, rather than the (efault) that check_pointer() would result
in.
With my embedded hat on, I've made it possible to remove this.
I've tested that the #ifdeffery in errcode.c is sufficient to make this
compile on arm, arm64, mips, powerpc, s390, x86 - I'm sure the 0day bot
will tell me which ones I've missed.
The symbols to include have been found by massaging the output of
find arch include -iname 'errno*.h' | xargs grep -E 'define\s*E'
In the cases where some common aliasing exists (e.g. EAGAIN=EWOULDBLOCK
on all platforms, EDEADLOCK=EDEADLK on most), I've moved the more popular
one (in terms of 'git grep -w Efoo | wc) to the bottom so that one takes
precedence.
Link: http://lkml.kernel.org/r/20190917065959.5560-1-li...@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes
Acked-by: Uwe Kleine-König
Cc: Jonathan Corbet
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Cc: Joe Perches
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Jani Nikula
Cc: Linux Kernel Mailing List
Cc: Pavel Machek
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Andrea Arcangeli
Signed-off-by: Andrew Morton
---
Documentation/core-api/printk-formats.rst |8
include/linux/errcode.h | 16 +
lib/Kconfig.debug |8
lib/Makefile |1
lib/errcode.c | 212
lib/test_printf.c | 14 +
lib/vsprintf.c| 26 ++
7 files changed, 285 insertions(+)
---
a/Documentation/core-api/printk-formats.rst~printf-add-support-for-printing-symbolic-error-codes
+++ a/Documentation/core-api/printk-formats.rst
@@ -66,6 +66,14 @@ might be printed instead of the unreacha
(efault) data on invalid address
(einval) invalid data on a valid address
+Error pointers, i.e. pointers for which IS_ERR() is true, are handled
+as follows: If CONFIG_SYMBOLIC_ERRCODE is set, an appropriate symbolic
+constant is printed. For example, '"%p", PTR_ERR(-ENOSPC)' results in
+"ENOSPC", while '"%p", PTR_ERR(-EWOULDBLOCK)' results in "EAGAIN"
+(since EAGAIN == EWOULDBLOCK, and the former is the most common). If
+CONFIG_SYMBOLIC_ERRCODE is not set, ERR_PTRs are printed as their
+decimal representation ("-28" and "-11" for the two examples).
+
Plain Pointers
--
--- /dev/null
+++ a/include/linux/errcode.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_ERRCODE_H
+#define _LINUX_ERRCODE_H
+
+#include
+
+#ifdef CONFIG_SYMBOLIC_ERRCODE
+const char *errcode(int err);
+#else
+static inline const char *errcode(int err)
+{
+ return NULL;
+}
+#endif
+
+#endif /* _LINUX_ERRCODE_H */
--- /dev/null
+++ a/lib/errcode.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+
+/*
+ * Ensure these tables to not accidentally become gigantic if some
+ * huge errno makes it in. On most architectures, the first table will
+ * only have about 140 entries, but mips and parisc have more sparsely
+ * allocated errnos (with EHWPOISON = 257 on parisc, and EDQUOT = 1133
+ * on mips), so this wastes a bit of space on those - though we
+ * special case the EDQUOT case.
+ */
+#define E(err) [err + BUILD_BUG_ON_ZERO(err <= 0 || err > 300)] = #err
+static const char *codes_0[] = {
+ E(E2BIG),
+ E(EACCES),
+ E(EADDRINUSE),
+ E(EADDRNOTAVAIL),
+ E(EADV),
+
Re: [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages()
On Fri, 4 Oct 2019 16:41:50 +0200 Michal Hocko wrote: > > > This is just insane. The hotplug code is in no way special wrt printk. > > > It is never called from the printk code AFAIK and thus there is no real > > > reason why this particular code should be any special. Not to mention > > > it calls printk indirectly from a code that is shared with other code > > > paths. > > > > Basically, printk() while holding the zone_lock will be problematic as > > console > > is doing the opposite as it always needs to allocate some memory. Then, it > > will > > always find some way to form this chain, > > > > console_lock -> * -> zone_lock. > > So this is not as much a hotplug specific problem but zone->lock -> > printk -> alloc chain that is a problem, right? Who is doing an > allocation from this atomic context? I do not see any atomic allocation > in kernel/printk/printk.c. Apparently some console drivers can do memory allocation on the printk() path. This behavior is daft, IMO. Have we identified which ones and looked into fixing them?
[PATCH] media: vimc: get pixformat info from v4l2_format_info to avoid code repetition
From: "Carlos E.C. Barbosa"
As the info found in vim_pix_map members are already available in
v4l2_format_info those were removed and their calls remapped to it.
Signed-off-by: Carlos E. C. Barbosa
---
drivers/media/platform/vimc/vimc-capture.c | 20 ++--
drivers/media/platform/vimc/vimc-common.c | 107 +
drivers/media/platform/vimc/vimc-common.h | 27 --
drivers/media/platform/vimc/vimc-debayer.c | 6 +-
drivers/media/platform/vimc/vimc-scaler.c | 26 +++--
drivers/media/platform/vimc/vimc-sensor.c | 25 ++---
6 files changed, 105 insertions(+), 106 deletions(-)
diff --git a/drivers/media/platform/vimc/vimc-capture.c
b/drivers/media/platform/vimc/vimc-capture.c
index 602f80323031..8be2f81d5da3 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -85,7 +85,7 @@ static int vimc_cap_try_fmt_vid_cap(struct file *file, void
*priv,
struct v4l2_format *f)
{
struct v4l2_pix_format *format = >fmt.pix;
- const struct vimc_pix_map *vpix;
+ struct vimc_pix_map vpix;
format->width = clamp_t(u32, format->width, VIMC_FRAME_MIN_WIDTH,
VIMC_FRAME_MAX_WIDTH) & ~1;
@@ -94,12 +94,12 @@ static int vimc_cap_try_fmt_vid_cap(struct file *file, void
*priv,
/* Don't accept a pixelformat that is not on the table */
vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
- if (!vpix) {
+ if (!vpix.info) {
format->pixelformat = fmt_default.pixelformat;
vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
}
/* TODO: Add support for custom bytesperline values */
- format->bytesperline = format->width * vpix->bpp;
+ format->bytesperline = format->width * vpix.info->bpp[0];
format->sizeimage = format->bytesperline * format->height;
if (format->field == V4L2_FIELD_ANY)
@@ -146,12 +146,12 @@ static int vimc_cap_s_fmt_vid_cap(struct file *file, void
*priv,
static int vimc_cap_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- const struct vimc_pix_map *vpix = vimc_pix_map_by_index(f->index);
+ const struct vimc_pix_map vpix = vimc_pix_map_by_index(f->index);
- if (!vpix)
+ if (!vpix.info)
return -EINVAL;
- f->pixelformat = vpix->pixelformat;
+ f->pixelformat = vpix.info->format;
return 0;
}
@@ -159,14 +159,14 @@ static int vimc_cap_enum_fmt_vid_cap(struct file *file,
void *priv,
static int vimc_cap_enum_framesizes(struct file *file, void *fh,
struct v4l2_frmsizeenum *fsize)
{
- const struct vimc_pix_map *vpix;
+ struct vimc_pix_map vpix;
if (fsize->index)
return -EINVAL;
/* Only accept code in the pix map table */
vpix = vimc_pix_map_by_code(fsize->pixel_format);
- if (!vpix)
+ if (!vpix.info)
return -EINVAL;
fsize->type = V4L2_FRMSIZE_TYPE_CONTINUOUS;
@@ -387,7 +387,7 @@ struct vimc_ent_device *vimc_cap_add(struct vimc_device
*vimc,
const char *vcfg_name)
{
struct v4l2_device *v4l2_dev = >v4l2_dev;
- const struct vimc_pix_map *vpix;
+ struct vimc_pix_map vpix;
struct vimc_cap_device *vcap;
struct video_device *vdev;
struct vb2_queue *q;
@@ -443,7 +443,7 @@ struct vimc_ent_device *vimc_cap_add(struct vimc_device
*vimc,
/* Set default frame format */
vcap->format = fmt_default;
vpix = vimc_pix_map_by_pixelformat(vcap->format.pixelformat);
- vcap->format.bytesperline = vcap->format.width * vpix->bpp;
+ vcap->format.bytesperline = vcap->format.width * vpix.info->bpp[0];
vcap->format.sizeimage = vcap->format.bytesperline *
vcap->format.height;
diff --git a/drivers/media/platform/vimc/vimc-common.c
b/drivers/media/platform/vimc/vimc-common.c
index a3120f4f7a90..9ea698810e1a 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -14,186 +14,167 @@
* NOTE: non-bayer formats need to come first (necessary for enum_mbus_code
* in the scaler)
*/
-static const struct vimc_pix_map vimc_pix_map_list[] = {
+static struct vimc_pix_map_fmt vimc_pix_map_fmt_list[] = {
/* TODO: add all missing formats */
/* RGB formats */
{
.code = MEDIA_BUS_FMT_BGR888_1X24,
.pixelformat = V4L2_PIX_FMT_BGR24,
- .bpp = 3,
- .bayer = false,
},
{
.code = MEDIA_BUS_FMT_RGB888_1X24,
.pixelformat = V4L2_PIX_FMT_RGB24,
- .bpp = 3,
- .bayer = false,
},
{
.code = MEDIA_BUS_FMT_ARGB_1X32,
[PATCH 2/3] usb: dwc3: Switch to platform_get_irq_byname_optional()
The dwc3 code to get the "peripheral" / "host" / "otg" IRQ first tries platform_get_irq_byname() and then falls back to the IRQ at index 0 if the platform_get_irq_byname(). In this case we do not want platform_get_irq_byname() to print an error on failure, so switch to platform_get_irq_byname_optional() instead which does not print an error. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037 Signed-off-by: Hans de Goede --- drivers/usb/dwc3/drd.c| 4 ++-- drivers/usb/dwc3/gadget.c | 4 ++-- drivers/usb/dwc3/host.c | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c index 726100d1ac0d..b1f76628b313 100644 --- a/drivers/usb/dwc3/drd.c +++ b/drivers/usb/dwc3/drd.c @@ -139,14 +139,14 @@ static int dwc3_otg_get_irq(struct dwc3 *dwc) struct platform_device *dwc3_pdev = to_platform_device(dwc->dev); int irq; - irq = platform_get_irq_byname(dwc3_pdev, "otg"); + irq = platform_get_irq_byname_optional(dwc3_pdev, "otg"); if (irq > 0) goto out; if (irq == -EPROBE_DEFER) goto out; - irq = platform_get_irq_byname(dwc3_pdev, "dwc_usb3"); + irq = platform_get_irq_byname_optional(dwc3_pdev, "dwc_usb3"); if (irq > 0) goto out; diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 8adb59f8e4f1..13c97ff21dba 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3264,14 +3264,14 @@ static int dwc3_gadget_get_irq(struct dwc3 *dwc) struct platform_device *dwc3_pdev = to_platform_device(dwc->dev); int irq; - irq = platform_get_irq_byname(dwc3_pdev, "peripheral"); + irq = platform_get_irq_byname_optional(dwc3_pdev, "peripheral"); if (irq > 0) goto out; if (irq == -EPROBE_DEFER) goto out; - irq = platform_get_irq_byname(dwc3_pdev, "dwc_usb3"); + irq = platform_get_irq_byname_optional(dwc3_pdev, "dwc_usb3"); if (irq > 0) goto out; diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index 8deea8c91e03..534a49609779 100644 --- a/drivers/usb/dwc3/host.c +++ b/drivers/usb/dwc3/host.c @@ -16,14 +16,14 @@ static int dwc3_host_get_irq(struct dwc3 *dwc) struct platform_device *dwc3_pdev = to_platform_device(dwc->dev); int irq; - irq = platform_get_irq_byname(dwc3_pdev, "host"); + irq = platform_get_irq_byname_optional(dwc3_pdev, "host"); if (irq > 0) goto out; if (irq == -EPROBE_DEFER) goto out; - irq = platform_get_irq_byname(dwc3_pdev, "dwc_usb3"); + irq = platform_get_irq_byname_optional(dwc3_pdev, "dwc_usb3"); if (irq > 0) goto out; -- 2.23.0
[PATCH 1/3] driver core: platform: Add platform_get_irq_byname_optional()
Some drivers (e.g dwc3) first try to get an IRQ byname and then fall
back to the one at index 0. In this case we do not want the error(s)
printed by platform_get_irq_byname(). This commit adds a new
platform_get_irq_byname_optional(), which does not print errors, for this.
While at it also improve the kdoc text for platform_get_irq_byname() a bit.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037
Signed-off-by: Hans de Goede
---
drivers/base/platform.c | 46 -
include/linux/platform_device.h | 2 ++
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b6c6c7d97d5b..b230beb6ccb4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,12 +241,8 @@ struct resource *platform_get_resource_byname(struct
platform_device *dev,
}
EXPORT_SYMBOL_GPL(platform_get_resource_byname);
-/**
- * platform_get_irq_byname - get an IRQ for a device by name
- * @dev: platform device
- * @name: IRQ name
- */
-int platform_get_irq_byname(struct platform_device *dev, const char *name)
+static int __platform_get_irq_byname(struct platform_device *dev,
+const char *name)
{
struct resource *r;
@@ -262,11 +258,47 @@ int platform_get_irq_byname(struct platform_device *dev,
const char *name)
if (r)
return r->start;
- dev_err(>dev, "IRQ %s not found\n", name);
return -ENXIO;
}
+
+/**
+ * platform_get_irq_byname - get an IRQ for a device by name
+ * @dev: platform device
+ * @name: IRQ name
+ *
+ * Get an IRQ like platform_get_irq(), but then by name rather then by index.
+ *
+ * Return: IRQ number on success, negative error number on failure.
+ */
+int platform_get_irq_byname(struct platform_device *dev, const char *name)
+{
+ int ret;
+
+ ret = __platform_get_irq_byname(dev, name);
+ if (ret < 0 && ret != -EPROBE_DEFER)
+ dev_err(>dev, "IRQ %s not found\n", name);
+
+ return ret;
+}
EXPORT_SYMBOL_GPL(platform_get_irq_byname);
+/**
+ * platform_get_irq_byname_optional - get an optional IRQ for a device by name
+ * @dev: platform device
+ * @name: IRQ name
+ *
+ * Get an optional IRQ by name like platform_get_irq_byname(). Except that it
+ * does not print an error message if an IRQ can not be obtained.
+ *
+ * Return: IRQ number on success, negative error number on failure.
+ */
+int platform_get_irq_byname_optional(struct platform_device *dev,
+const char *name)
+{
+ return __platform_get_irq_byname(dev, name);
+}
+EXPORT_SYMBOL_GPL(platform_get_irq_byname_optional);
+
/**
* platform_add_devices - add a numbers of platform devices
* @devs: array of platform devices to add
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 1b5cec067533..f2688404d1cd 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -64,6 +64,8 @@ extern struct resource *platform_get_resource_byname(struct
platform_device *,
unsigned int,
const char *);
extern int platform_get_irq_byname(struct platform_device *, const char *);
+extern int platform_get_irq_byname_optional(struct platform_device *dev,
+ const char *name);
extern int platform_add_devices(struct platform_device **, int);
struct platform_device_info {
--
2.23.0
[PATCH 0/3] Add platform_get_irq_byname_optional() and use it in the dwc3 driver
Hi All, Here is a fix for the false-positive dev_err in platform_get_irq_byname() discussed recently and reported here: https://bugzilla.kernel.org/show_bug.cgi?id=205037 Since patch 2 depends on patch 1, I think it might be best to merge all three patches through the same tree ... Regards, Hans
[PATCH 3/3] usb: dwc3: Remove dev_err() on platform_get_irq() failure
Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to
platform_get_irq*()"), platform_get_irq() will call dev_err() itself on
failure, so there is no need for the driver to also do this.
Signed-off-by: Hans de Goede
---
drivers/usb/dwc3/drd.c| 3 ---
drivers/usb/dwc3/gadget.c | 3 ---
drivers/usb/dwc3/host.c | 3 ---
3 files changed, 9 deletions(-)
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index b1f76628b313..c946d64142ad 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -157,9 +157,6 @@ static int dwc3_otg_get_irq(struct dwc3 *dwc)
if (irq > 0)
goto out;
- if (irq != -EPROBE_DEFER)
- dev_err(dwc->dev, "missing OTG IRQ\n");
-
if (!irq)
irq = -EINVAL;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 13c97ff21dba..86dc1db788a9 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3282,9 +3282,6 @@ static int dwc3_gadget_get_irq(struct dwc3 *dwc)
if (irq > 0)
goto out;
- if (irq != -EPROBE_DEFER)
- dev_err(dwc->dev, "missing peripheral IRQ\n");
-
if (!irq)
irq = -EINVAL;
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 534a49609779..5567ed2cddbe 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -34,9 +34,6 @@ static int dwc3_host_get_irq(struct dwc3 *dwc)
if (irq > 0)
goto out;
- if (irq != -EPROBE_DEFER)
- dev_err(dwc->dev, "missing host IRQ\n");
-
if (!irq)
irq = -EINVAL;
--
2.23.0
[PATCH] staging: greybus: add blank line after declarations
Fix CHECK: add blank line after declarations
Signed-off-by: Gabriela Bittencourt
---
drivers/staging/greybus/control.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/greybus/control.h
b/drivers/staging/greybus/control.h
index 3a29ec05f631..5a45d55349a1 100644
--- a/drivers/staging/greybus/control.h
+++ b/drivers/staging/greybus/control.h
@@ -24,6 +24,7 @@ struct gb_control {
char *vendor_string;
char *product_string;
};
+
#define to_gb_control(d) container_of(d, struct gb_control, dev)
struct gb_control *gb_control_create(struct gb_interface *intf);
--
2.20.1
linux-next: no release on Monday
Hi all, There will be no linux-next release on Monday Oct 7. -- Cheers, Stephen Rothwell pgpiamCdZiFmz.pgp Description: OpenPGP digital signature
Linux 3.16.75
I'm announcing the release of the 3.16.75 kernel. All users of the 3.16 kernel series should upgrade. The updated 3.16.y git tree can be found at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.16.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git The diff from 3.16.74 is attached to this message. Ben. Makefile | 2 +- arch/arm64/kvm/guest.c| 49 --- arch/mips/mm/tlbex.c | 29 ++--- arch/powerpc/perf/core-book3s.c | 8 ++- arch/powerpc/perf/power8-pmu.c| 3 + arch/s390/crypto/aes_s390.c | 10 +-- arch/s390/crypto/des_s390.c | 9 +-- arch/x86/kernel/apic/apic.c | 3 +- arch/x86/kernel/cpu/bugs.c| 11 +++- block/blk-mq-tag.c| 2 +- crypto/crypto_user.c | 3 + drivers/ata/libata-core.c | 9 ++- drivers/gpio/Kconfig | 1 + drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 + drivers/gpu/drm/gma500/intel_bios.c | 3 + drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/hwmon/pmbus/pmbus_core.c | 34 -- drivers/i2c/busses/i2c-acorn.c| 1 + drivers/i2c/i2c-dev.c | 1 + drivers/input/misc/uinput.c | 22 ++- drivers/md/bcache/bset.c | 16 - drivers/md/bcache/bset.h | 34 +- drivers/misc/genwqe/card_dev.c| 2 + drivers/misc/genwqe/card_utils.c | 4 ++ drivers/net/bonding/bond_main.c | 6 +- drivers/net/can/flexcan.c | 2 +- drivers/net/ethernet/dec/tulip/de4x5.c| 1 - drivers/net/ethernet/emulex/benet/be_ethtool.c| 30 ++--- drivers/net/ethernet/mellanox/mlx4/mcg.c | 2 +- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 3 +- drivers/parisc/ccio-dma.c | 4 +- drivers/parisc/sba_iommu.c| 3 +- drivers/s390/net/qeth_l2_main.c | 2 +- drivers/s390/scsi/zfcp_ext.h | 1 + drivers/s390/scsi/zfcp_scsi.c | 9 +++ drivers/s390/scsi/zfcp_sysfs.c| 55 +++-- drivers/s390/scsi/zfcp_unit.c | 8 ++- drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +- drivers/scsi/ufs/ufshcd-pltfrm.c | 11 ++-- drivers/scsi/vmw_pvscsi.c | 6 +- drivers/spi/spi-bitbang.c | 2 +- drivers/staging/usbip/stub_dev.c | 75 --- drivers/target/target_core_iblock.c | 2 +- drivers/tty/serial/max310x.c | 2 +- drivers/tty/serial/sh-sci.c | 7 +++ drivers/usb/core/config.c | 4 +- drivers/usb/core/quirks.c | 6 ++ drivers/usb/host/xhci.c | 2 +- drivers/usb/misc/rio500.c | 17 - drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 3 + drivers/usb/storage/unusual_realtek.h | 5 ++ fs/btrfs/file.c | 12 fs/btrfs/reada.c | 7 +++ fs/cifs/cifsfs.c | 1 + fs/cifs/cifsglob.h| 5 ++ fs/cifs/file.c| 12 +++- fs/cifs/smb2maperror.c| 2 +- fs/configfs/dir.c | 14 ++--- fs/ocfs2/dcache.c | 12 include/linux/sched.h | 4 ++ kernel/cpu.c | 3 + kernel/cred.c | 9 +++ kernel/events/core.c | 5 +- kernel/events/ring_buffer.c | 33 -- kernel/ptrace.c | 20 +- kernel/signal.c | 2 + kernel/trace/trace.c | 10 +-- lib/mpi/mpi-pow.c | 6 +- mm/huge_memory.c | 2 + net/can/af_can.c | 24 +++- net/core/dev.c| 2 +- net/core/neighbour.c | 7 +++ net/core/pktgen.c | 11 net/ipv4/igmp.c | 53
[PATCH RESEND v5 0/1] intel_cht_int33fe: Split code to USB Micro-B and Type-C variants
Patch to support INT33FE ACPI pseudo-device on hardware with USB Micro-B
connector.
v5:
- Spelling corrections in Kconfig, commit description and comments;
- Micro-B code: Remove warning at fuel gauge registration failure and
use PTR_ERR_OR_ZERO() for simplicity.
v4:
- Micro-B variant: Don't print error to the kernel log if i2c_acpi_new_device()
has returned -EPROBE_DEFER.
v3:
- Rename TypeB variant to Micro-B (we have only one such device for now and it
has Micro-B connector)
- Rebase on current linus/master
- Remove empty lines and replace "TypeC" by "Type-C"
v2:
Instead of defining two separated modules with two separated config
options, compile {common,typeb,typec} sources into one .ko module.
Call needed variant-specific probe function based after of hardware type
detection in common code.
Yauhen Kharuzhy (1):
platform/x86/intel_cht_int33fe: Split code to USB Micro-B and Type-C
variants
drivers/platform/x86/Kconfig | 10 +-
drivers/platform/x86/Makefile | 4 +
.../platform/x86/intel_cht_int33fe_common.c | 147 ++
.../platform/x86/intel_cht_int33fe_common.h | 41 +
.../platform/x86/intel_cht_int33fe_microb.c | 57 +++
...ht_int33fe.c => intel_cht_int33fe_typec.c} | 78 +-
6 files changed, 265 insertions(+), 72 deletions(-)
create mode 100644 drivers/platform/x86/intel_cht_int33fe_common.c
create mode 100644 drivers/platform/x86/intel_cht_int33fe_common.h
create mode 100644 drivers/platform/x86/intel_cht_int33fe_microb.c
rename drivers/platform/x86/{intel_cht_int33fe.c => intel_cht_int33fe_typec.c}
(82%)
--
2.23.0.rc1
[PATCH RESEND v5 1/1] platform/x86/intel_cht_int33fe: Split code to USB Micro-B and Type-C variants
Existing intel_cht_int33fe ACPI pseudo-device driver assumes that
hardware has Type-C connector and register related devices described as
I2C connections in the _CRS resource.
There is at least one hardware (Lenovo Yoga Book YB1-91L/F) with Micro-B
USB connector exists. It has INT33FE device in the DSDT table but
there are only two I2C connection described: PMIC and BQ27452 battery
fuel gauge.
Splitting existing INT33FE driver allow to maintain code for USB Micro-B
(or AB) connector variant separately and make it simpler.
Split driver to intel_cht_int33fe_common.c and
intel_cht_int33fe_{microb,typec}.c. Compile all this sources to one .ko
module to make user experience easier.
Signed-off-by: Yauhen Kharuzhy
---
drivers/platform/x86/Kconfig | 10 +-
drivers/platform/x86/Makefile | 4 +
.../platform/x86/intel_cht_int33fe_common.c | 147 ++
.../platform/x86/intel_cht_int33fe_common.h | 41 +
.../platform/x86/intel_cht_int33fe_microb.c | 57 +++
...ht_int33fe.c => intel_cht_int33fe_typec.c} | 78 +-
6 files changed, 265 insertions(+), 72 deletions(-)
create mode 100644 drivers/platform/x86/intel_cht_int33fe_common.c
create mode 100644 drivers/platform/x86/intel_cht_int33fe_common.h
create mode 100644 drivers/platform/x86/intel_cht_int33fe_microb.c
rename drivers/platform/x86/{intel_cht_int33fe.c => intel_cht_int33fe_typec.c}
(82%)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1b67bb578f9f..e9e5aa791caf 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -930,14 +930,20 @@ config INTEL_CHT_INT33FE
This driver add support for the INT33FE ACPI device found on
some Intel Cherry Trail devices.
+ There are two kinds of INT33FE ACPI device possible: for hardware
+ with USB Type-C and Micro-B connectors. This driver supports both.
+
The INT33FE ACPI device has a CRS table with I2cSerialBusV2
- resources for 3 devices: Maxim MAX17047 Fuel Gauge Controller,
+ resources for Fuel Gauge Controller and (in the Type-C variant)
FUSB302 USB Type-C Controller and PI3USB30532 USB switch.
This driver instantiates i2c-clients for these, so that standard
i2c drivers for these chips can bind to the them.
If you enable this driver it is advised to also select
- CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m.
+ CONFIG_BATTERY_BQ27XXX=m or CONFIG_BATTERY_BQ27XXX_I2C=m for Micro-B
+ device and CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m
+ for Type-C device.
+
config INTEL_INT0002_VGPIO
tristate "Intel ACPI INT0002 Virtual GPIO driver"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 415104033060..216d3b6fd6a7 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -61,6 +61,10 @@ obj-$(CONFIG_TOSHIBA_BT_RFKILL) += toshiba_bluetooth.o
obj-$(CONFIG_TOSHIBA_HAPS) += toshiba_haps.o
obj-$(CONFIG_TOSHIBA_WMI) += toshiba-wmi.o
obj-$(CONFIG_INTEL_CHT_INT33FE)+= intel_cht_int33fe.o
+intel_cht_int33fe-objs := intel_cht_int33fe_common.o \
+ intel_cht_int33fe_typec.o \
+ intel_cht_int33fe_microb.o
+
obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o
obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o
diff --git a/drivers/platform/x86/intel_cht_int33fe_common.c
b/drivers/platform/x86/intel_cht_int33fe_common.c
new file mode 100644
index ..42dd11623f56
--- /dev/null
+++ b/drivers/platform/x86/intel_cht_int33fe_common.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common code for Intel Cherry Trail ACPI INT33FE pseudo device drivers
+ * (USB Micro-B and Type-C connector variants).
+ *
+ * Copyright (c) 2019 Yauhen Kharuzhy
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "intel_cht_int33fe_common.h"
+
+#define EXPECTED_PTYPE 4
+
+static int cht_int33fe_i2c_res_filter(struct acpi_resource *ares, void *data)
+{
+ struct acpi_resource_i2c_serialbus *sb;
+ int *count = data;
+
+ if (i2c_acpi_get_i2c_resource(ares, ))
+ (*count)++;
+
+ return 1;
+}
+
+static int cht_int33fe_count_i2c_clients(struct device *dev)
+{
+ struct acpi_device *adev;
+ LIST_HEAD(resource_list);
+ int count = 0;
+
+ adev = ACPI_COMPANION(dev);
+ if (!adev)
+ return -EINVAL;
+
+ acpi_dev_get_resources(adev, _list,
+ cht_int33fe_i2c_res_filter, );
+
+ acpi_dev_free_resource_list(_list);
+
+ return count;
+}
+
+static int cht_int33fe_check_hw_type(struct device *dev)
+{
+ unsigned long long ptyp;
+ acpi_status status;
+ int ret;
+
+ status =
Re: [PATCH 3.16 00/87] 3.16.75-rc1 review
On Fri, 2019-10-04 at 16:09 -0700, Guenter Roeck wrote: > On Wed, Oct 02, 2019 at 08:06:50PM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.16.75 release. > > There are 87 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri Oct 04 19:06:50 UTC 2019. > > Anything received after that time might be too late. > > > For v3.16.74-85-g811e39a80ea5: > > Build results: > total: 136 pass: 136 fail: 0 > Qemu test results: > total: 229 pass: 229 fail: 0 Great, thanks. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Re: [PATCH 5.4 regression fix] Input: soc_button_array - partial revert of support for newer surface devices
Hi, On 05-10-2019 17:01, Maximilian Luz wrote: Hi, again On 10/5/19 3:20 PM, Hans de Goede wrote: Ok, on x86 the GPIO drivers really should all be builtin because various ACPI methods including device D0 / D3 (power-on/off) methods may depend on them. So normally this should never happen. If this (-EPROBE_DEFER on surface devices) somehow still is happening please let me know and we will figure something out. I have never personally experienced this, only received reports which indicated this and that the change (as well as manually reloading soc_button_array) fixed it. I will come back to you if I hear anything in regards to this again. I have now also tested your patch on the Surface Book 2. Does not cause any issues as far as I can tell. Tested-by: Maximilian Luz And if that is needed/wanted Acked-by: Maximilian Luz Great, thank you. Regards, Hans
[Spam]spende
Lieber Freund, Ich bin Frau Mavis Wanczyk, Bürgerin von Massachusetts, Vereinigte Staaten von Amerika, die Mega-Gewinnerin des Powerball-Jackpots in Höhe von 758,7 Millionen US-Dollar. Ich spende an 5 zufällige Personen. Wenn Sie diese E-Mail erhalten, wird Ihre E-Mail zu einer von mir verteilten Kugel wenig von meinem Vermögen an eine Reihe von Wohltätigkeitsorganisationen und Organisationen. Ich habe mich freiwillig entschlossen, den Betrag von 5.800.000,00 € an Sie als einen der ausgewählten 5 zu spenden, um meine Gewinne zu überprüfen. Weitere Informationen finden Sie auf meiner YouTube-Seite unten. HIER: http://Money.cnn.com/2017/08/23/News/Powerball-700-Million-Jackpot/Index.html Dies ist Ihr Spendencode: [MW530342019] Antworte auf diese E-Mail mit dem DONOR CODE:maviswan...@gmail.com Ich hoffe, Sie und Ihre Familie glücklich zu machen.Grüße Frau Mavis Wanczyk
Re: [PATCH] clk: at91: avoid sleeping early
On 24/09/2019 13:20:15-0700, Stephen Boyd wrote:
> Quoting Uwe (2019-09-24 05:21:47)
> > On Fri, Sep 20, 2019 at 05:39:06PM +0200, Alexandre Belloni wrote:
> > > Note that this was already discussed a while ago and Arnd said this
> > > approach was
> > > reasonable:
> > > https://lore.kernel.org/lkml/6120818.MyeJZ74hYa@wuerfel/
> > >
> > > drivers/clk/at91/clk-main.c | 5 -
> > > drivers/clk/at91/sckc.c | 20
> > > 2 files changed, 20 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> > > index f607ee702c83..ccd48e7a3d74 100644
> > > --- a/drivers/clk/at91/clk-main.c
> > > +++ b/drivers/clk/at91/clk-main.c
> > > @@ -293,7 +293,10 @@ static int clk_main_probe_frequency(struct regmap
> > > *regmap)
> > > regmap_read(regmap, AT91_CKGR_MCFR, );
> > > if (mcfr & AT91_PMC_MAINRDY)
> > > return 0;
> > > - usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
> > > + if (system_state < SYSTEM_RUNNING)
> > > + udelay(MAINF_LOOP_MIN_WAIT);
> > > + else
> > > + usleep_range(MAINF_LOOP_MIN_WAIT,
> > > MAINF_LOOP_MAX_WAIT);
> >
> > Given that this construct is introduced several times, I wonder if we
> > want something like:
> >
> > static inline void early_usleep_range(unsigned long min, unsigned
> > long max)
> > {
> > if (system_state < SYSTEM_RUNNING)
> > udelay(min);
> > else
> > usleep_range(min, max);
> > }
> >
>
> Maybe, but I think the intent is to not encourage this behavior? So
> providing a wrapper will make it "easy" and then we'll have to tell
> users to stop calling it. Another idea would be to make usleep_range()
> "do the right thing" and call udelay if the system isn't running. And
> another idea from tlgx[1] is to pull the delay logic into another clk op
> that we can call to see when the enable or prepare is done. That may be
> possible by introducing another clk_ops callback that when present
> indicates we should sleep or delay for so much time while waiting for
> the prepare or enable to complete.
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.11.1606061448010.28031@nanos
>
Do you want me to implement that now or are you planning to apply the
patch in the meantime ?
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [GIT PULL] Kbuild fixes for v5.4-rc2
The pull request you sent on Sat, 5 Oct 2019 17:21:15 +0900: > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > tags/kbuild-fixes-v5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2d00aee21a5d4966e086d98f9d710afb92fb14e8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] s390 updates for 5.4-rc2
The pull request you sent on Sat, 5 Oct 2019 17:38:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.4-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6fe137cbe3e85e832a169006e8ccc04cec69c653 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] SCSI fixes for 5.4-rc1
The pull request you sent on Fri, 04 Oct 2019 21:44:15 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/126195c972a2adba8cae12a65cdee155440a4525 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT] Networking
The pull request you sent on Fri, 04 Oct 2019 18:47:16 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9819a30c11ea439e5e3c81f5539c4d42d6c76314 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v2] mm/swap: piggyback lru_add_drain_all() calls
On Sat, Oct 5, 2019 at 10:35 PM Andrew Morton wrote:
>
> On Fri, 04 Oct 2019 16:09:22 +0300 Konstantin Khlebnikov
> wrote:
>
> > This is very slow operation. There is no reason to do it again if somebody
> > else already drained all per-cpu vectors while we waited for lock.
> >
> > Piggyback on drain started and finished while we waited for lock:
> > all pages pended at the time of our enter were drained from vectors.
> >
> > Callers like POSIX_FADV_DONTNEED retry their operations once after
> > draining per-cpu vectors when pages have unexpected references.
> >
> > ...
> >
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -708,9 +708,10 @@ static void lru_add_drain_per_cpu(struct work_struct
> > *dummy)
> > */
> > void lru_add_drain_all(void)
> > {
> > + static seqcount_t seqcount = SEQCNT_ZERO(seqcount);
> > static DEFINE_MUTEX(lock);
> > static struct cpumask has_work;
> > - int cpu;
> > + int cpu, seq;
> >
> > /*
> >* Make sure nobody triggers this path before mm_percpu_wq is fully
> > @@ -719,7 +720,19 @@ void lru_add_drain_all(void)
> > if (WARN_ON(!mm_percpu_wq))
> > return;
> >
> > + seq = raw_read_seqcount_latch();
> > +
> > mutex_lock();
> > +
> > + /*
> > + * Piggyback on drain started and finished while we waited for lock:
> > + * all pages pended at the time of our enter were drained from
> > vectors.
> > + */
> > + if (__read_seqcount_retry(, seq))
> > + goto done;
> > +
> > + raw_write_seqcount_latch();
> > +
> > cpumask_clear(_work);
> >
> > for_each_online_cpu(cpu) {
> > @@ -740,6 +753,7 @@ void lru_add_drain_all(void)
> > for_each_cpu(cpu, _work)
> > flush_work(_cpu(lru_add_drain_work, cpu));
> >
> > +done:
> > mutex_unlock();
> > }
>
> I'm not sure this works as intended.
>
> Suppose CPU #30 is presently executing the for_each_online_cpu() loop
> and has reached CPU #15's per-cpu data.
>
> Now CPU #2 comes along, adds some pages to its per-cpu vectors then
> calls lru_add_drain_all(). AFAICT the code will assume that CPU #30
> has flushed out all of the pages which CPU #2 just added, but that
> isn't the case.
>
> Moving the raw_write_seqcount_latch() to the point where all processing
> has completed might fix?
>
>
No, raw_write_seqcount_latch() should be exactly before draining.
Here seqcount works as generation of pages that could be in vectors.
And all steps are serialized by mutex: only after taking lock we could be
sure that all previous generations are gone.
Here CPU #2 will see same generation at entry and after taking lock.
So it will drain own pages.
Please forgive me if my request is not acceptable by your kind person.
-- Dear Sir/ Madam, Please forgive me if my request is not acceptable by your kind person. I am Mr.Francis Hashim, Working at One of the bank here in (Burkina Faso) as the Independent Non-Executive Director & Audit Committee. During our last banking Audits we discovered an abandoned account belongs to one of our Foreign Deceased Customer, Late Mr. Wang Jian, The Co-founder and Co-chairman of HNA Group, a Chinese conglomerate with significant real estate ownerships across the U.S., died in an accident while on a business trip in France on Tuesday. Please go through this link:https://observer.com/2018/07/wang-jian-hna-founder-dies-tragic-fall/ I am writing to request your assistance in transferring the sum of $15.000.000.00 (Fifteen Million United States Dollars) into your account as the Late Mr. Wang Jian Foreign Business Partner. Meanwhile, before I contacted you I have done personal investigation in locating any of Late Mr. Wang Jian relatives who knows about the account, but I came out unsuccessful. I will like to bring to your notice that I have made all the necessary arrangements with my colleagues to transfer the funds into your nominated bank account without any problem. Upon your consideration and acceptance of this offer, I am willing to offer you 40% for your assistant, while 60% for me which I am planning to invest into a profitable business venture in your country. More details information will be forwarded to you to breakdown explaining comprehensively what require of you. Reply me on my private E-Mail Address: francishashi...@gmail.com Waiting for your urgent reply, Best Regards Mr.Francis Hashim.
Re: [PATCH v3 0/3] Add compile time sanity check of GENMASK inputs
On Sun, Aug 11, 2019 at 08:49:35PM +0200, Rikard Falkeborn wrote: > Hello, > > A new attempt to try to add build time validity checks of GENMASK (and > GENMASK_ULL) inputs. There main differences from v2: > > Remove a define of BUILD_BUG_ON in x86/boot to avoid a compiler warning > about redefining BUILD_BUG_ON. Instead, use the common one from > include/. > > Drop patch 2 in v2 where GENMASK arguments where made more verbose. > > Add a cast in the BUILD_BUG_ON_ZERO macro change the type to int to > avoid the somewhat clumpsy casts of BUILD_BUG_ON_ZERO. The second patch > in this series adds such a cast to BUILD_BUG_ON_ZERO, which makes it > possible to avoid casts when using BUILD_BUG_ON_ZERO in patch 3. > > I have checked all users of BUILD_BUG_ON_ZERO and I did not find a case > where adding a cast to int would affect existing users but I'd feel much > more comfortable if someone else double (or tripple) checked (there are > ~80 instances plus ~10 copies in tools). Perhaps I should have CC:d > maintainers of files using BUILD_BUG_ON_ZERO? > > Finally, use __builtin_constant_p instead of __is_constexpr. This avoids > pulling in kernel.h in bits.h. > > Joe Perches sent a patch series to fix existing misuses, currently there > are five such misuses (which patches pending) left in Linus tree and two > (with patches pending) in linux-next. Those patches should fix all > "simple" misuses of GENMASK (cases where the arguments are numerical > constants). Pushing v2 to linux-next also revealed an arm-specific > misuse where GENMASK was used in another macro (and also broke the > arm-builds). There is a patch to fix that by Nathan Chancellor (not in > linux-next yet). Those patches should be merged before the last patch of > this series to avoid breaking builds. > Ping. The current status is that patch 1 has been merged into Linus tree through the x86 tree. The patches mentioned about actually fixing the existing misuses have all been merged except two of Joe Perches patches [0], [1], but those patches fixes misuse in unused macros, and will not affect anyones build. I have testbuilt the two remaining patches rebased on top of Linus tree and on linux-next for aarch64 and x86 without seeing any problems (when v2 of the series went into linux-next, those were the only archs where any problems were spotted (build warning on x86, build error on aarch64)). [0] https://lore.kernel.org/lkml/cddd7ad7e9f81dec1e86c106f04229d21fc21920.1562734889.git@perches.com/ [1] https://lore.kernel.org/lkml/d149d2851f9aa2425c927cb8e311e20c4b83e186.1562734889.git@perches.com/ Rikard
Re: [PATCH] rculist: Describe variadic macro argument in a Sphinx-compatible way
On Sat, Oct 05, 2019 at 09:31:23PM +0200, Jonathan Neuschäfer wrote:
> On Sat, Oct 05, 2019 at 06:33:30AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 05, 2019 at 01:23:28AM +0200, Jonathan Neuschäfer wrote:
> > > On Fri, Oct 04, 2019 at 03:24:39PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote:
> > > > > Without this patch, Sphinx shows "variable arguments" as the
> > > > > description
> > > > > of the cond argument, rather than the intended description, and prints
> > > > > the following warnings:
> > > > >
> > > > > ./include/linux/rculist.h:374: warning: Excess function parameter
> > > > > 'cond' description in 'list_for_each_entry_rcu'
> > > > > ./include/linux/rculist.h:651: warning: Excess function parameter
> > > > > 'cond' description in 'hlist_for_each_entry_rcu'
> > >
> > > Hmm, small detail that I didn't realize before: It's actually the
> > > kernel-doc script, not Sphinx, that can't deal with variadic macro
> > > arguments and thus requires this patch.
> > >
> > > So it may also be possible to fix the script instead. (I have not
> > > looked into how much work that would be.)
> >
> > OK, thank you for letting me know. I will keep your patch for the
> > moment, but please let me know if the fix can be elsewhere.
> >
> > Thanx, Paul
>
> Turns out the actual fix in scripts/kernel-doc is easy enough:
>
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1449,6 +1449,10 @@ sub push_parameter() {
> # handles unnamed variable parameters
> $param = "...";
> }
> + elsif ($param =~ /\w\.\.\.$/) {
> + # for named variable parameters of the form `x...`, remove the
> dots
> + $param =~ s/\.\.\.$//;
> + }
> if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq
> "") {
> $parameterdescs{$param} = "variable arguments";
> }
>
> ... but there are other macros in the code base that are documented
> using the 'x...' syntax, so I guess it's best to take my initial patch
> (or something similar) now, and I'll fix kernel-doc later, in a longer
> patchset that also cleans up the fallout.
You got it! ;-)
Thanx, Paul
Re: [PATCH v2] mm/swap: piggyback lru_add_drain_all() calls
On Fri, 04 Oct 2019 16:09:22 +0300 Konstantin Khlebnikov
wrote:
> This is very slow operation. There is no reason to do it again if somebody
> else already drained all per-cpu vectors while we waited for lock.
>
> Piggyback on drain started and finished while we waited for lock:
> all pages pended at the time of our enter were drained from vectors.
>
> Callers like POSIX_FADV_DONTNEED retry their operations once after
> draining per-cpu vectors when pages have unexpected references.
>
> ...
>
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -708,9 +708,10 @@ static void lru_add_drain_per_cpu(struct work_struct
> *dummy)
> */
> void lru_add_drain_all(void)
> {
> + static seqcount_t seqcount = SEQCNT_ZERO(seqcount);
> static DEFINE_MUTEX(lock);
> static struct cpumask has_work;
> - int cpu;
> + int cpu, seq;
>
> /*
>* Make sure nobody triggers this path before mm_percpu_wq is fully
> @@ -719,7 +720,19 @@ void lru_add_drain_all(void)
> if (WARN_ON(!mm_percpu_wq))
> return;
>
> + seq = raw_read_seqcount_latch();
> +
> mutex_lock();
> +
> + /*
> + * Piggyback on drain started and finished while we waited for lock:
> + * all pages pended at the time of our enter were drained from vectors.
> + */
> + if (__read_seqcount_retry(, seq))
> + goto done;
> +
> + raw_write_seqcount_latch();
> +
> cpumask_clear(_work);
>
> for_each_online_cpu(cpu) {
> @@ -740,6 +753,7 @@ void lru_add_drain_all(void)
> for_each_cpu(cpu, _work)
> flush_work(_cpu(lru_add_drain_work, cpu));
>
> +done:
> mutex_unlock();
> }
I'm not sure this works as intended.
Suppose CPU #30 is presently executing the for_each_online_cpu() loop
and has reached CPU #15's per-cpu data.
Now CPU #2 comes along, adds some pages to its per-cpu vectors then
calls lru_add_drain_all(). AFAICT the code will assume that CPU #30
has flushed out all of the pages which CPU #2 just added, but that
isn't the case.
Moving the raw_write_seqcount_latch() to the point where all processing
has completed might fix?
Re: [PATCH] rculist: Describe variadic macro argument in a Sphinx-compatible way
On Sat, Oct 05, 2019 at 06:33:30AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 05, 2019 at 01:23:28AM +0200, Jonathan Neuschäfer wrote:
> > On Fri, Oct 04, 2019 at 03:24:39PM -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote:
> > > > Without this patch, Sphinx shows "variable arguments" as the description
> > > > of the cond argument, rather than the intended description, and prints
> > > > the following warnings:
> > > >
> > > > ./include/linux/rculist.h:374: warning: Excess function parameter
> > > > 'cond' description in 'list_for_each_entry_rcu'
> > > > ./include/linux/rculist.h:651: warning: Excess function parameter
> > > > 'cond' description in 'hlist_for_each_entry_rcu'
> >
> > Hmm, small detail that I didn't realize before: It's actually the
> > kernel-doc script, not Sphinx, that can't deal with variadic macro
> > arguments and thus requires this patch.
> >
> > So it may also be possible to fix the script instead. (I have not
> > looked into how much work that would be.)
>
> OK, thank you for letting me know. I will keep your patch for the
> moment, but please let me know if the fix can be elsewhere.
>
> Thanx, Paul
Turns out the actual fix in scripts/kernel-doc is easy enough:
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1449,6 +1449,10 @@ sub push_parameter() {
# handles unnamed variable parameters
$param = "...";
}
+ elsif ($param =~ /\w\.\.\.$/) {
+ # for named variable parameters of the form `x...`, remove the
dots
+ $param =~ s/\.\.\.$//;
+ }
if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq
"") {
$parameterdescs{$param} = "variable arguments";
}
... but there are other macros in the code base that are documented
using the 'x...' syntax, so I guess it's best to take my initial patch
(or something similar) now, and I'll fix kernel-doc later, in a longer
patchset that also cleans up the fallout.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
Re: [PATCH 3/3] tools/memory-model/Documentation: Add plain accesses and data races to explanation.txt
On Thu, Oct 03, 2019 at 12:13:30PM +0200, Andrea Parri wrote: > On Tue, Oct 01, 2019 at 01:40:19PM -0400, Alan Stern wrote: > > This patch updates the Linux Kernel Memory Model's explanation.txt > > file by adding a section devoted to the model's handling of plain > > accesses and data-race detection. > > > > Signed-off-by: Alan Stern > > For the entire series, > > Acked-by: Andrea Parri Applied and promoted to from lkmm-dev to lkmm, thank you both! Thanx, Paul
Re: [PATCH 0/7] regulator: switch to using [devm_]fwnode_gpiod_get_index
On Sat, Oct 5, 2019 at 1:10 AM Dmitry Torokhov wrote: > This series swiches regulator drivers form using > [devm_]gpiod_get_from_of_node() that is scheduled to be removed in favor > of [devm_]fwnode_gpiod_get_index() that behaves more like standard > [devm_]gpiod_get_index() and will potentially handle secondary software > nodes in cases we need to augment platform firmware. The series: Reviewed-by: Linus Walleij Too bad with the build robots being unable to parse the pull deps. Now they hammer out complaints. Yours, Linus Walleij
Re: [PATCH] rtlwifi: fix memory leak in rtl_usb_probe
Oh! It's duplicate, thanks for catching that.
On Sat, Oct 5, 2019 at 11:08 AM Markus Elfring wrote:
>
> > In rtl_usb_probe, a new hw is allocated via ieee80211_alloc_hw(). This
> > allocation should be released in case of allocation failure for
> > rtlpriv->usb_data.
> >
> > Fixes: a7959c1394d4 ("rtlwifi: Preallocate USB read buffers and eliminate
> > kalloc in read routine")
>
> Which event did trigger the sending of this patch variant
> after a similar change was integrated already?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=3f93616951138a598d930dcaec40f2bfd9ce43bb
> https://lore.kernel.org/lkml/20191001092047.71e8460...@smtp.codeaurora.org/
> https://lore.kernel.org/patchwork/comment/1331936/
>
> Regards,
> Markus
--
Navid.
Re: [PATCH v15 00/14] Introduce the for_each_set_clump8 macro
On Sat, Oct 05, 2019 at 02:36:54PM -0400, William Breathitt Gray wrote: > Changes in v15: > - Move find_next_clump8 to lib/find_bit.c since it requires round_down > (I want this to be static inline like the others, but I need help) > - Utilize for_each_set_clump8 in pisosr, max3191x, and pca953x > > While adding GPIO get_multiple/set_multiple callback support for various > drivers, I noticed a pattern of looping manifesting that would be useful > standardized as a macro. > > This patchset introduces the for_each_set_clump8 macro and utilizes it > in several GPIO drivers. The for_each_set_clump macro8 facilitates a > for-loop syntax that iterates over a memory region entire groups of set > bits at a time. > > For example, suppose you would like to iterate over a 32-bit integer 8 > bits at a time, skipping over 8-bit groups with no set bit, where > represents the current 8-bit group: > > Example:1010 00110011 > First loop: 1010 > Second loop:1010 00110011 > Third loop: 00110011 > > Each iteration of the loop returns the next 8-bit group that has at > least one set bit. > > The for_each_set_clump8 macro has four parameters: > > * start: set to the bit offset of the current clump > * clump: set to the current clump value > * bits: bitmap to search within > * size: bitmap size in number of bits > > In this version of the patchset, the for_each_set_clump macro has been > reimplemented and simplified based on the suggestions provided by Rasmus > Villemoes and Andy Shevchenko in the version 4 submission. > > In particular, the function of the for_each_set_clump macro has been > restricted to handle only 8-bit clumps; the drivers that use the > for_each_set_clump macro only handle 8-bit ports so a generic > for_each_set_clump implementation is not necessary. Thus, a solution for > large clumps (i.e. those larger than the width of a bitmap word) can be > postponed until a driver appears that actually requires such a generic > for_each_set_clump implementation. > > For what it's worth, a semi-generic for_each_set_clump (i.e. for clumps > smaller than the width of a bitmap word) can be implemented by simply > replacing the hardcoded '8' and '0xFF' instances with respective > variables. I have not yet had a need for such an implementation, and > since it falls short of a true generic for_each_set_clump function, I > have decided to forgo such an implementation for now. > > In addition, the bitmap_get_value8 and bitmap_set_value8 functions are > introduced to get and set 8-bit values respectively. Their use is based > on the behavior suggested in the patchset version 4 review. > > William Breathitt Gray (14): > bitops: Introduce the for_each_set_clump8 macro > lib/test_bitmap.c: Add for_each_set_clump8 test cases > gpio: 104-dio-48e: Utilize for_each_set_clump8 macro > gpio: 104-idi-48: Utilize for_each_set_clump8 macro > gpio: gpio-mm: Utilize for_each_set_clump8 macro > gpio: ws16c48: Utilize for_each_set_clump8 macro > gpio: pci-idio-16: Utilize for_each_set_clump8 macro > gpio: pcie-idio-24: Utilize for_each_set_clump8 macro > gpio: uniphier: Utilize for_each_set_clump8 macro > gpio: 74x164: Utilize the for_each_set_clump8 macro > thermal: intel: intel_soc_dts_iosf: Utilize for_each_set_clump8 macro > gpio: pisosr: Utilize the for_each_set_clump8 macro > gpio: max3191x: Utilize the for_each_set_clump8 macro > gpio: pca953x: Utilize the for_each_set_clump8 macro > > drivers/gpio/gpio-104-dio-48e.c| 73 -- > drivers/gpio/gpio-104-idi-48.c | 36 ++- > drivers/gpio/gpio-74x164.c | 19 ++-- > drivers/gpio/gpio-gpio-mm.c| 73 -- > drivers/gpio/gpio-max3191x.c | 19 ++-- > drivers/gpio/gpio-pca953x.c| 17 ++-- > drivers/gpio/gpio-pci-idio-16.c| 75 +- > drivers/gpio/gpio-pcie-idio-24.c | 109 - > drivers/gpio/gpio-pisosr.c | 12 +-- > drivers/gpio/gpio-uniphier.c | 16 ++- > drivers/gpio/gpio-ws16c48.c| 73 -- > drivers/thermal/intel/intel_soc_dts_iosf.c | 29 +++--- > drivers/thermal/intel/intel_soc_dts_iosf.h | 2 - > include/asm-generic/bitops/find.h | 50 ++ > include/linux/bitops.h | 5 + > lib/find_bit.c | 14 +++ > lib/test_bitmap.c | 65 > 17 files changed, 325 insertions(+), 362 deletions(-) > > -- > 2.23.0 This patchset only implements for_each_set_clump8 which restricts the looping to 8 bits at a time. The drivers/gpio/gpio-thunderx.c file has a set_multiple callback that loops 64 bits at a time. That would be one case where a more general for_each_set_clump
[PATCH v15 07/14] gpio: pci-idio-16: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Reviewed-by: Linus Walleij
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pci-idio-16.c | 75 -
1 file changed, 27 insertions(+), 48 deletions(-)
diff --git a/drivers/gpio/gpio-pci-idio-16.c b/drivers/gpio/gpio-pci-idio-16.c
index 5aa136a6a3e0..6c117e57078c 100644
--- a/drivers/gpio/gpio-pci-idio-16.c
+++ b/drivers/gpio/gpio-pci-idio-16.c
@@ -100,45 +100,23 @@ static int idio_16_gpio_get_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct idio_16_gpio *const idio16gpio = gpiochip_get_data(chip);
- size_t i;
- const unsigned int gpio_reg_size = 8;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
- unsigned long port_state;
+ unsigned long offset;
+ unsigned long gpio_mask;
void __iomem *ports[] = {
>reg->out0_7, >reg->out8_15,
>reg->in0_7, >reg->in8_15,
};
+ void __iomem *port_addr;
+ unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports); i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
-
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
+ for_each_set_clump8(offset, gpio_mask, mask, ARRAY_SIZE(ports) * 8) {
+ port_addr = ports[offset / 8];
+ port_state = ioread8(port_addr) & gpio_mask;
- /* read bits from current gpio port */
- port_state = ioread8(ports[i]);
-
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, port_state, offset);
}
return 0;
@@ -178,30 +156,31 @@ static void idio_16_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct idio_16_gpio *const idio16gpio = gpiochip_get_data(chip);
+ unsigned long offset;
+ unsigned long gpio_mask;
+ void __iomem *ports[] = {
+ >reg->out0_7, >reg->out8_15,
+ };
+ size_t index;
+ void __iomem *port_addr;
+ unsigned long bitmask;
unsigned long flags;
- unsigned int out_state;
+ unsigned long out_state;
- raw_spin_lock_irqsave(>lock, flags);
+ for_each_set_clump8(offset, gpio_mask, mask, ARRAY_SIZE(ports) * 8) {
+ index = offset / 8;
+ port_addr = ports[index];
- /* process output lines 0-7 */
- if (*mask & 0xFF) {
- out_state = ioread8(>reg->out0_7) & ~*mask;
- out_state |= *mask & *bits;
- iowrite8(out_state, >reg->out0_7);
- }
+ bitmask = bitmap_get_value8(bits, offset) & gpio_mask;
+
+ raw_spin_lock_irqsave(>lock, flags);
- /* shift to next output line word */
- *mask >>= 8;
+ out_state = ioread8(port_addr) & ~gpio_mask;
+ out_state |= bitmask;
+ iowrite8(out_state, port_addr);
- /* process output lines 8-15 */
- if (*mask & 0xFF) {
- *bits >>= 8;
- out_state = ioread8(>reg->out8_15) & ~*mask;
- out_state |= *mask & *bits;
- iowrite8(out_state, >reg->out8_15);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
-
- raw_spin_unlock_irqrestore(>lock, flags);
}
static void idio_16_irq_ack(struct irq_data *data)
--
2.23.0
[PATCH v15 01/14] bitops: Introduce the for_each_set_clump8 macro
This macro iterates for each 8-bit group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to the
bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value8 and bitmap_set_value8 functions are introduced to
respectively get and set an 8-bit value in a bitmap memory region.
Suggested-by: Andy Shevchenko
Suggested-by: Rasmus Villemoes
Suggested-by: Lukas Wunner
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Andy Shevchenko
Cc: Linus Walleij
Signed-off-by: William Breathitt Gray
---
include/asm-generic/bitops/find.h | 50 +++
include/linux/bitops.h| 5
lib/find_bit.c| 14 +
3 files changed, 69 insertions(+)
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 8a1ee10014de..5277e72882ff 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -80,4 +80,54 @@ extern unsigned long find_first_zero_bit(const unsigned long
*addr,
#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+/**
+ * bitmap_get_value8 - get an 8-bit value within a memory region
+ * @addr: address to the bitmap memory region
+ * @start: bit offset of the 8-bit value; must be a multiple of 8
+ *
+ * Returns the 8-bit value located at the @start bit offset within the @addr
+ * memory region.
+ */
+static inline unsigned long bitmap_get_value8(const unsigned long *addr,
+ unsigned long start)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned long offset = start % BITS_PER_LONG;
+
+ return (addr[index] >> offset) & 0xFF;
+}
+
+/**
+ * bitmap_set_value8 - set an 8-bit value within a memory region
+ * @addr: address to the bitmap memory region
+ * @value: the 8-bit value; values wider than 8 bits may clobber bitmap
+ * @start: bit offset of the 8-bit value; must be a multiple of 8
+ */
+static inline void bitmap_set_value8(unsigned long *addr, unsigned long value,
+unsigned long start)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned long offset = start % BITS_PER_LONG;
+
+ addr[index] &= ~(0xFF << offset);
+ addr[index] |= value << offset;
+}
+
+/**
+ * find_next_clump8 - find next 8-bit clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+extern unsigned long find_next_clump8(unsigned long *clump,
+ const unsigned long *addr,
+ unsigned long size, unsigned long offset);
+
+#define find_first_clump8(clump, bits, size) \
+ find_next_clump8((clump), (bits), (size), 0)
+
#endif /*_ASM_GENERIC_BITOPS_FIND_H_ */
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index cf074bce3eb3..fb94a10f7853 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -40,6 +40,11 @@ extern unsigned long __sw_hweight64(__u64 w);
(bit) < (size);\
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
+#define for_each_set_clump8(start, clump, bits, size) \
+ for ((start) = find_first_clump8(&(clump), (bits), (size)); \
+(start) < (size); \
+(start) = find_next_clump8(&(clump), (bits), (size), (start) + 8))
+
static inline int get_bitmask_order(unsigned int count)
{
int order;
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 5c51eb45178a..e35a76b291e6 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -214,3 +214,17 @@ EXPORT_SYMBOL(find_next_bit_le);
#endif
#endif /* __BIG_ENDIAN */
+
+unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
+ unsigned long size, unsigned long offset)
+{
+ offset = find_next_bit(addr, size, offset);
+ if (offset == size)
+ return size;
+
+ offset = round_down(offset, 8);
+ *clump = bitmap_get_value8(addr, offset);
+
+ return offset;
+}
+EXPORT_SYMBOL(find_next_clump8);
--
2.23.0
[PATCH v15 00/14] Introduce the for_each_set_clump8 macro
Changes in v15: - Move find_next_clump8 to lib/find_bit.c since it requires round_down (I want this to be static inline like the others, but I need help) - Utilize for_each_set_clump8 in pisosr, max3191x, and pca953x While adding GPIO get_multiple/set_multiple callback support for various drivers, I noticed a pattern of looping manifesting that would be useful standardized as a macro. This patchset introduces the for_each_set_clump8 macro and utilizes it in several GPIO drivers. The for_each_set_clump macro8 facilitates a for-loop syntax that iterates over a memory region entire groups of set bits at a time. For example, suppose you would like to iterate over a 32-bit integer 8 bits at a time, skipping over 8-bit groups with no set bit, where represents the current 8-bit group: Example:1010 00110011 First loop: 1010 Second loop:1010 00110011 Third loop: 00110011 Each iteration of the loop returns the next 8-bit group that has at least one set bit. The for_each_set_clump8 macro has four parameters: * start: set to the bit offset of the current clump * clump: set to the current clump value * bits: bitmap to search within * size: bitmap size in number of bits In this version of the patchset, the for_each_set_clump macro has been reimplemented and simplified based on the suggestions provided by Rasmus Villemoes and Andy Shevchenko in the version 4 submission. In particular, the function of the for_each_set_clump macro has been restricted to handle only 8-bit clumps; the drivers that use the for_each_set_clump macro only handle 8-bit ports so a generic for_each_set_clump implementation is not necessary. Thus, a solution for large clumps (i.e. those larger than the width of a bitmap word) can be postponed until a driver appears that actually requires such a generic for_each_set_clump implementation. For what it's worth, a semi-generic for_each_set_clump (i.e. for clumps smaller than the width of a bitmap word) can be implemented by simply replacing the hardcoded '8' and '0xFF' instances with respective variables. I have not yet had a need for such an implementation, and since it falls short of a true generic for_each_set_clump function, I have decided to forgo such an implementation for now. In addition, the bitmap_get_value8 and bitmap_set_value8 functions are introduced to get and set 8-bit values respectively. Their use is based on the behavior suggested in the patchset version 4 review. William Breathitt Gray (14): bitops: Introduce the for_each_set_clump8 macro lib/test_bitmap.c: Add for_each_set_clump8 test cases gpio: 104-dio-48e: Utilize for_each_set_clump8 macro gpio: 104-idi-48: Utilize for_each_set_clump8 macro gpio: gpio-mm: Utilize for_each_set_clump8 macro gpio: ws16c48: Utilize for_each_set_clump8 macro gpio: pci-idio-16: Utilize for_each_set_clump8 macro gpio: pcie-idio-24: Utilize for_each_set_clump8 macro gpio: uniphier: Utilize for_each_set_clump8 macro gpio: 74x164: Utilize the for_each_set_clump8 macro thermal: intel: intel_soc_dts_iosf: Utilize for_each_set_clump8 macro gpio: pisosr: Utilize the for_each_set_clump8 macro gpio: max3191x: Utilize the for_each_set_clump8 macro gpio: pca953x: Utilize the for_each_set_clump8 macro drivers/gpio/gpio-104-dio-48e.c| 73 -- drivers/gpio/gpio-104-idi-48.c | 36 ++- drivers/gpio/gpio-74x164.c | 19 ++-- drivers/gpio/gpio-gpio-mm.c| 73 -- drivers/gpio/gpio-max3191x.c | 19 ++-- drivers/gpio/gpio-pca953x.c| 17 ++-- drivers/gpio/gpio-pci-idio-16.c| 75 +- drivers/gpio/gpio-pcie-idio-24.c | 109 - drivers/gpio/gpio-pisosr.c | 12 +-- drivers/gpio/gpio-uniphier.c | 16 ++- drivers/gpio/gpio-ws16c48.c| 73 -- drivers/thermal/intel/intel_soc_dts_iosf.c | 29 +++--- drivers/thermal/intel/intel_soc_dts_iosf.h | 2 - include/asm-generic/bitops/find.h | 50 ++ include/linux/bitops.h | 5 + lib/find_bit.c | 14 +++ lib/test_bitmap.c | 65 17 files changed, 325 insertions(+), 362 deletions(-) -- 2.23.0
[PATCH v15 06/14] gpio: ws16c48: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Reviewed-by: Linus Walleij
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-ws16c48.c | 73 ++---
1 file changed, 20 insertions(+), 53 deletions(-)
diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index e0ef66b6a237..51aaa5c17fce 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -126,42 +126,19 @@ static int ws16c48_gpio_get_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct ws16c48_gpio *const ws16c48gpio = gpiochip_get_data(chip);
- const unsigned int gpio_reg_size = 8;
- size_t i;
- const size_t num_ports = chip->ngpio / gpio_reg_size;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
+ unsigned long offset;
+ unsigned long gpio_mask;
+ unsigned int port_addr;
unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < num_ports; i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
+ for_each_set_clump8(offset, gpio_mask, mask, chip->ngpio) {
+ port_addr = ws16c48gpio->base + offset / 8;
+ port_state = inb(port_addr) & gpio_mask;
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
-
- /* read bits from current gpio port */
- port_state = inb(ws16c48gpio->base + i);
-
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, port_state, offset);
}
return 0;
@@ -195,39 +172,29 @@ static void ws16c48_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct ws16c48_gpio *const ws16c48gpio = gpiochip_get_data(chip);
- unsigned int i;
- const unsigned int gpio_reg_size = 8;
- unsigned int port;
- unsigned int iomask;
- unsigned int bitmask;
+ unsigned long offset;
+ unsigned long gpio_mask;
+ size_t index;
+ unsigned int port_addr;
+ unsigned long bitmask;
unsigned long flags;
- /* set bits are evaluated a gpio register size at a time */
- for (i = 0; i < chip->ngpio; i += gpio_reg_size) {
- /* no more set bits in this mask word; skip to the next word */
- if (!mask[BIT_WORD(i)]) {
- i = (BIT_WORD(i) + 1) * BITS_PER_LONG - gpio_reg_size;
- continue;
- }
-
- port = i / gpio_reg_size;
+ for_each_set_clump8(offset, gpio_mask, mask, chip->ngpio) {
+ index = offset / 8;
+ port_addr = ws16c48gpio->base + index;
/* mask out GPIO configured for input */
- iomask = mask[BIT_WORD(i)] & ~ws16c48gpio->io_state[port];
- bitmask = iomask & bits[BIT_WORD(i)];
+ gpio_mask &= ~ws16c48gpio->io_state[index];
+ bitmask = bitmap_get_value8(bits, offset) & gpio_mask;
raw_spin_lock_irqsave(>lock, flags);
/* update output state data and set device gpio register */
- ws16c48gpio->out_state[port] &= ~iomask;
- ws16c48gpio->out_state[port] |= bitmask;
- outb(ws16c48gpio->out_state[port], ws16c48gpio->base + port);
+ ws16c48gpio->out_state[index] &= ~gpio_mask;
+ ws16c48gpio->out_state[index] |= bitmask;
+ outb(ws16c48gpio->out_state[index], port_addr);
raw_spin_unlock_irqrestore(>lock, flags);
-
- /* prepare for next gpio register set */
- mask[BIT_WORD(i)] >>= gpio_reg_size;
- bits[BIT_WORD(i)] >>= gpio_reg_size;
}
}
--
2.23.0
