RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: ARM: add __always_inline to functions called from __get_user_check()
> Am 19.10.2019 um 03:59 schrieb Masahiro Yamada > : > > On Fri, Oct 18, 2019 at 7:06 PM H. Nikolaus Schaller > wrote: >> >> Hi, >> I wonder what happened to your patch. We were "hit" by it in v5.4-rc1 and >> after finding, it made our OMAP based device bootable again (using our >> own defconfig which optimizes for SIZE). >> >> But it does not seem to have arrived in linux-next > > It is in linux-next. Ah, now I found it. It has a "8908/1:" in its title so that search by (full) subject could not find it. Thanks! > > >> and should IMHO >> be fixed during the v5.4 release candidate cycle. > > I agree. > > > Masahiro BR and thanks, Nikolaus
broonie-spi/for-next boot bisection: v5.4-rc3-73-gc673f2d99c3d on jetson-tk1
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* *
* If you do send a fix, please include this trailer:*
* Reported-by: "kernelci.org bot" *
* *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
broonie-spi/for-next boot bisection: v5.4-rc3-73-gc673f2d99c3d on jetson-tk1
Summary:
Start: c673f2d99c3d Merge remote-tracking branch 'spi/topic/ptp' into
spi-next
Details:https://kernelci.org/boot/id/5daa485f59b5142f647525a0
Plain log:
https://storage.kernelci.org//broonie-spi/for-next/v5.4-rc3-73-gc673f2d99c3d/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/boot-tegra124-jetson-tk1.txt
HTML log:
https://storage.kernelci.org//broonie-spi/for-next/v5.4-rc3-73-gc673f2d99c3d/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/boot-tegra124-jetson-tk1.html
Result: 3e5ec1db8bfe spi: Fix SPI_CS_HIGH setting when using native and
GPIO CS
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: broonie-spi
URL:https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Branch: for-next
Target: jetson-tk1
CPU arch: arm
Lab:lab-collabora
Compiler: gcc-8
Config: multi_v7_defconfig+CONFIG_SMP=n
Test suite: boot
Breaking commit found:
---
commit 3e5ec1db8bfee845d9f8560d1c64aeaccd586398
Author: Gregory CLEMENT
Date: Fri Oct 18 17:29:29 2019 +0200
spi: Fix SPI_CS_HIGH setting when using native and GPIO CS
When improving the CS GPIO support at core level, the SPI_CS_HIGH
has been enabled for all the CS lines used for a given SPI controller.
However, the SPI framework allows to have on the same controller native
CS and GPIO CS. The native CS may not support the SPI_CS_HIGH, so they
should not be setup automatically.
With this patch the setting is done only for the CS that will use a
GPIO as CS
Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Cc:
Signed-off-by: Gregory CLEMENT
Link:
https://lore.kernel.org/r/20191018152929.3287-1-gregory.clem...@bootlin.com
Signed-off-by: Mark Brown
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index f8b4654a57d3..d07517151340 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1711,15 +1711,7 @@ static int of_spi_parse_dt(struct spi_controller *ctlr,
struct spi_device *spi,
spi->mode |= SPI_3WIRE;
if (of_property_read_bool(nc, "spi-lsb-first"))
spi->mode |= SPI_LSB_FIRST;
-
- /*
-* For descriptors associated with the device, polarity inversion is
-* handled in the gpiolib, so all chip selects are "active high" in
-* the logical sense, the gpiolib will invert the line if need be.
-*/
- if (ctlr->use_gpio_descriptors)
- spi->mode |= SPI_CS_HIGH;
- else if (of_property_read_bool(nc, "spi-cs-high"))
+ if (of_property_read_bool(nc, "spi-cs-high"))
spi->mode |= SPI_CS_HIGH;
/* Device DUAL/QUAD mode */
@@ -1783,6 +1775,14 @@ static int of_spi_parse_dt(struct spi_controller *ctlr,
struct spi_device *spi,
}
spi->chip_select = value;
+ /*
+* For descriptors associated with the device, polarity inversion is
+* handled in the gpiolib, so all gpio chip selects are "active high"
+* in the logical sense, the gpiolib will invert the line if need be.
+*/
+ if ((ctlr->use_gpio_descriptors) && ctlr->cs_gpiods[spi->chip_select])
+ spi->mode |= SPI_CS_HIGH;
+
/* Device speed */
rc = of_property_read_u32(nc, "spi-max-frequency", );
if (rc) {
---
Git bisection log:
---
git bisect start
# good: [4f5cafb5cb8471e54afdc9054d973535614f7675] Linux 5.4-rc3
git bisect good 4f5cafb5cb8471e54afdc9054d973535614f7675
# bad: [c673f2d99c3d644733cc1b0ceabdec47047bbe80] Merge remote-tracking branch
'spi/topic/ptp' into spi-next
git bisect bad c673f2d99c3d644733cc1b0ceabdec47047bbe80
# good: [b2c98153f45fc17b9fcb241000f2d131ddea6030] spi: introduce spi_delay
struct as "value + unit" & spi_delay_exec()
git bisect good b2c98153f45fc17b9fcb241000f2d131ddea6030
# good: [4f3d957718e7f0ac2b033dbf48c7cddecd0a8dd3] spi: pxa2xx: No need to keep
[PATCH] PCI: Warn about host bridge device when its numa node is NO_NODE
As the disscusion in [1]: A PCI device really _MUST_ have a node assigned. It is possible to have a PCI bridge shared between two nodes, such that the PCI devices have equidistance. But the moment you scale this out, you either get devices that are 'local' to a package while having multiple packages, or if you maintain a single bridge in a big system, things become so slow it all doesn't matter anyway. Assigning a node (one of the shared) is, in the generic ase of multiple packages, the better solution over assigning all nodes. As pci_device_add() will assign the pci device' node according to the bus the device is on, which is decided by pcibus_to_node(). Currently different arch may implement the pcibus_to_node() based on bus->sysdata or bus device' node, which has the same node as the bridge device. And for devices behind another bridge case, the child bus device is setup with proper parent bus device and inherit its parent' sysdata in pci_alloc_child_bus(), so the pcie device under the child bus should have the same node as the parent bridge when device_add() is called, which will set the node to its parent's node when the child device' node is NUMA_NO_NODE. So this patch only warns about the case when a host bridge device is registered with a node of NO_NODE in pci_register_host_bridge(). And it only warns about that when there are more than one numa nodes in the system. [1] https://lore.kernel.org/lkml/1568724534-146242-1-git-send-email-linyunsh...@huawei.com/ Signed-off-by: Yunsheng Lin --- drivers/pci/probe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 3d5271a..22be96a 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -927,6 +927,9 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) list_add_tail(>node, _root_buses); up_write(_bus_sem); + if (nr_node_ids > 1 && dev_to_node(bus->bridge) == NUMA_NO_NODE) + dev_err(bus->bridge, FW_BUG "No node assigned on NUMA capable HW by BIOS. Please contact your vendor for updates.\n"); + return 0; unregister: -- 2.8.1
[PATCH 1/2] lib/bsearch.c: introduce bsearch_idx
many existing bsearch implementations don't want to have the pointer to the
found element, but the index position, or if the searched element doesn't
exist, the index position the search element would be placed in the array.
Signed-off-by: Thomas Meyer
---
include/linux/bsearch.h | 7 +
lib/bsearch.c | 62 +
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/include/linux/bsearch.h b/include/linux/bsearch.h
index 62b1eb3488584..0c40c8b39b881 100644
--- a/include/linux/bsearch.h
+++ b/include/linux/bsearch.h
@@ -7,4 +7,11 @@
void *bsearch(const void *key, const void *base, size_t num, size_t size,
int (*cmp)(const void *key, const void *elt));
+struct bsearch_result { size_t idx; bool found; };
+
+struct bsearch_result bsearch_idx(const void *key, const void *base,
+ size_t num,
+ size_t size,
+ int (*cmp)(const void *key, const void *elt));
+
#endif /* _LINUX_BSEARCH_H */
diff --git a/lib/bsearch.c b/lib/bsearch.c
index 8baa839681628..5c46d0ec1e473 100644
--- a/lib/bsearch.c
+++ b/lib/bsearch.c
@@ -10,8 +10,8 @@
#include
#include
-/*
- * bsearch - binary search an array of elements
+/**
+ * bsearch() - binary search an array of elements
* @key: pointer to item being searched for
* @base: pointer to first element to search
* @num: number of elements
@@ -27,28 +27,68 @@
* could compare the string with the struct's name field. However, if
* the key and elements in the array are of the same type, you can use
* the same comparison function for both sort() and bsearch().
+ *
+ * Return: Either a pointer to the search element or NULL if not found.
*/
void *bsearch(const void *key, const void *base, size_t num, size_t size,
int (*cmp)(const void *key, const void *elt))
{
- const char *pivot;
+ struct bsearch_result idx = bsearch_idx(key, base, num, size, cmp);
+
+ if (idx.found == true)
+ return (void *)base + idx.idx * size;
+
+ return NULL;
+}
+EXPORT_SYMBOL(bsearch);
+NOKPROBE_SYMBOL(bsearch);
+
+/**
+ * bsearch_idx() - binary search an array of elements
+ * @key: pointer to item being searched for
+ * @base: pointer to first element to search
+ * @num: number of elements
+ * @size: size of each element
+ * @cmp: pointer to comparison function
+ *
+ * This function does a binary search on the given array. The
+ * contents of the array should already be in ascending sorted order
+ * under the provided comparison function.
+ *
+ * Returns an index position and a bool if an exact match was found
+ * if an exact match was found the idx is the index in the base array.
+ * if no exact match was found the idx will point the the next higher index
+ * entry in the base array. this can also be base[num], i.e. after the actual
+ * allocated array.
+ */
+struct bsearch_result bsearch_idx(const void *key, const void *base,
+ size_t num,
+ size_t size,
+ int (*cmp)(const void *key, const void *elt))
+{
+ struct bsearch_result res = { .found = false };
int result;
+ size_t base_idx = 0;
+ size_t pivot_idx;
while (num > 0) {
- pivot = base + (num >> 1) * size;
- result = cmp(key, pivot);
+ pivot_idx = base_idx + (num >> 1);
+ result = cmp(key, base + pivot_idx * size);
- if (result == 0)
- return (void *)pivot;
+ if (result == 0) {
+ res.idx = pivot_idx;
+ res.found = true;
+ return res;
+ }
if (result > 0) {
- base = pivot + size;
+ base_idx = pivot_idx + 1;
num--;
}
num >>= 1;
}
- return NULL;
+ res.idx = base_idx;
+ return res;
}
-EXPORT_SYMBOL(bsearch);
-NOKPROBE_SYMBOL(bsearch);
+EXPORT_SYMBOL(bsearch_idx);
--
2.21.0
[PATCH 2/2] xfs: replace homemade binary search
use newly introduced bsearch_idx instead.
Signed-off-by: Thomas Meyer
---
fs/xfs/libxfs/xfs_dir2_block.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_dir2_block.c b/fs/xfs/libxfs/xfs_dir2_block.c
index 9595ced393dce..e484ec68944fb 100644
--- a/fs/xfs/libxfs/xfs_dir2_block.c
+++ b/fs/xfs/libxfs/xfs_dir2_block.c
@@ -20,6 +20,7 @@
#include "xfs_error.h"
#include "xfs_trace.h"
#include "xfs_log.h"
+#include
/*
* Local function prototypes.
@@ -314,6 +315,19 @@ xfs_dir2_block_compact(
xfs_dir2_data_freescan(args->dp, hdr, needlog);
}
+static int cmp_hashval(const void *key, const void *elt)
+{
+ xfs_dahash_t _search_key = *(xfs_dahash_t *)key;
+ xfs_dahash_t _curren_key = be32_to_cpu((
+ (xfs_dir2_leaf_entry_t *) elt)->hashval);
+
+ if (_search_key == _curren_key)
+ return 0;
+ else if (_search_key < _curren_key)
+ return -1;
+ return 1;
+}
+
/*
* Add an entry to a block directory.
*/
@@ -331,19 +345,17 @@ xfs_dir2_block_addname(
xfs_dir2_data_unused_t *dup; /* block unused entry */
int error; /* error return value */
xfs_dir2_data_unused_t *enddup=NULL; /* unused at end of data */
- xfs_dahash_thash; /* hash value of found entry */
- int high; /* high index for binary srch */
int highstale; /* high stale index */
int lfloghigh=0;/* last final leaf to log */
int lfloglow=0; /* first final leaf to log */
int len;/* length of the new entry */
- int low;/* low index for binary srch */
int lowstale; /* low stale index */
int mid=0; /* midpoint for binary srch */
int needlog;/* need to log header */
int needscan; /* need to rescan freespace */
__be16 *tagp; /* pointer to tag value */
xfs_trans_t *tp;/* transaction structure */
+ struct bsearch_result idx;/* bsearch result */
trace_xfs_dir2_block_addname(args);
@@ -420,15 +432,9 @@ xfs_dir2_block_addname(
/*
* Find the slot that's first lower than our hash value, -1 if none.
*/
- for (low = 0, high = be32_to_cpu(btp->count) - 1; low <= high; ) {
- mid = (low + high) >> 1;
- if ((hash = be32_to_cpu(blp[mid].hashval)) == args->hashval)
- break;
- if (hash < args->hashval)
- low = mid + 1;
- else
- high = mid - 1;
- }
+ idx = bsearch_idx(>hashval, blp, be32_to_cpu(btp->count) - 1,
+ sizeof(xfs_dir2_leaf_entry_t), cmp_hashval);
+ mid = idx.idx;
while (mid >= 0 && be32_to_cpu(blp[mid].hashval) >= args->hashval) {
mid--;
}
--
2.21.0
[tip: perf/core] perf/core: Fix !CONFIG_PERF_EVENTS build warnings and failures
The following commit has been merged into the perf/core branch of tip:
Commit-ID: ae79d5588a04aec9dc4b0c6df700d131447306e0
Gitweb:
https://git.kernel.org/tip/ae79d5588a04aec9dc4b0c6df700d131447306e0
Author:Ingo Molnar
AuthorDate:Sat, 19 Oct 2019 09:15:27 +02:00
Committer: Ingo Molnar
CommitterDate: Sat, 19 Oct 2019 09:15:27 +02:00
perf/core: Fix !CONFIG_PERF_EVENTS build warnings and failures
sparc64 runs into this warning:
include/linux/security.h:1913:52: warning: 'struct perf_event' declared
inside parameter list will not be visible outside of this definition or
declaration
which is escalated to a build error in some of the .c files due to -Werror.
Fix it via a forward declaration, like we do for perf_event_attr, the stub
inlines
don't actually need to know the structure of this struct.
Fixes: da97e18458fb: ("perf_event: Add support for LSM and SELinux checks")
Cc: "Joel Fernandes (Google)"
Cc: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Alexander Shishkin
Cc: Mark Rutland
Cc: Namhyung Kim
Signed-off-by: Ingo Molnar
---
include/linux/security.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/security.h b/include/linux/security.h
index 4df79ff..0a86bfe 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1896,6 +1896,7 @@ static inline void security_bpf_prog_free(struct
bpf_prog_aux *aux)
#ifdef CONFIG_PERF_EVENTS
struct perf_event_attr;
+struct perf_event;
#ifdef CONFIG_SECURITY
extern int security_perf_event_open(struct perf_event_attr *attr, int type);
Re: [PATCH 2/2] mfd: mfd-core: Honour Device Tree's request to disable a child-device
Good morning Robin,
It's been a while. I hope that you are well.
Thanks for taking an interest.
On Fri, 18 Oct 2019, Robin Murphy wrote:
> On 18/10/2019 13:26, Lee Jones wrote:
> > Until now, MFD has assumed all child devices passed to it (via
> > mfd_cells) are to be registered. It does not take into account
> > requests from Device Tree and the like to disable child devices
> > on a per-platform basis.
> >
> > Well now it does.
> >
> > Reported-by: Barry Song
> > Reported-by: Stephan Gerhold
> > Signed-off-by: Lee Jones
> > ---
> > drivers/mfd/mfd-core.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index eafdadd58e8b..24c139633524 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -182,6 +182,11 @@ static int mfd_add_device(struct device *parent, int
> > id,
> > if (parent->of_node && cell->of_compatible) {
> > for_each_child_of_node(parent->of_node, np) {
> > if (of_device_is_compatible(np, cell->of_compatible)) {
> > + if (!of_device_is_available(np)) {
> > + /* Ignore disabled devices error free */
> > + ret = 0;
> > + goto fail_alias;
> > + }
>
> Is it possible for a device to have multiple children of the same type? If
> so, it seems like this might not work as desired if, say, the first child
> was disabled but subsequent ones weren't.
>
> It might make sense to use for_each_available_child_of_node() for the outer
> loop, then check afterwards if anything was found.
The subsystem in its current guise doesn't reliably support the
situation you describe. We have no way to track which child nodes have
been through this process previously, thus mfd-core will always choose
the first child node with a matching compatible string.
If you have any suggests in terms of adding support for multiple
children with matching compatible strings, I'd be very receptive.
> > pdev->dev.of_node = np;
> > pdev->dev.fwnode = >fwnode;
> > break;
> >
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] mfd: mfd-core: Allocate reference counting memory directly to the platform device
On Fri, 18 Oct 2019, Daniel Thompson wrote: > On Fri, Oct 18, 2019 at 01:26:46PM +0100, Lee Jones wrote: > > MFD provides reference counting (for the 2 consumers who actually use it!) > > via mfd_cell's 'usage_count' member. However, since MFD cells become > > read-only (const), MFD needs to allocate writable memory and assign it to > > 'usage_count' before first registration. It currently does this by > > allocating enough memory for all requested child devices (yes, even disabled > > ones - but we'll get to that) and assigning the base pointer plus sub-device > > index to each device in the cell. > > > > The difficulty comes when trying to free that memory. During the removal of > > the parent device, MFD unregisters each child device, keeping a tally on the > > lowest memory location pointed to by a child device's 'usage_count'. Once > > all of the children are unregistered, the lowest memory location must be the > > base address of the previously allocated array, right? > > > > Well yes, until we try to honour the disabling of devices via Device Tree > > for instance. If the first child device in the provided batch is disabled, > > simply skipping registration (and consequentially deregistration) will mean > > that the first device's 'usage_count' pointer will not be accounted for when > > attempting to find the base. In which case, MFD will assume the first non- > > disabled 'usage_count' pointer is the base and subsequently attempt to > > erroneously free it. > > > > We can avoid all of this hoop jumping by simply allocating memory to each > > single child device before it is considered read-only. We can then free > > it on a per-device basis during deregistration. > > > > Signed-off-by: Lee Jones > > --- > > drivers/mfd/mfd-core.c | 42 ++ > > 1 file changed, 18 insertions(+), 24 deletions(-) > > > > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c > > index 23276a80e3b4..eafdadd58e8b 100644 > > --- a/drivers/mfd/mfd-core.c > > +++ b/drivers/mfd/mfd-core.c > > @@ -404,7 +398,7 @@ int mfd_clone_cell(const char *cell, const char > > **clones, size_t n_clones) > > cell_entry.name = clones[i]; > > /* don't give up if a single call fails; just report error */ > > if (mfd_add_device(pdev->dev.parent, -1, _entry, > > - cell_entry.usage_count, NULL, 0, NULL)) > > + NULL, 0, NULL)) > > I think this change is broken. > > Cloned cells are supposed to share the same reference counter as their > template and this change results in each clone having its own counter. > That means the "the 2 consumers who actually use it" will both end up > calling cs5535_mfd_res_enable() (and whichever loses the race will fail > to probe). > > To be honest it might be easier to move the request_region() into > cs5535_mfd_probe() and rip out the entire reference counting mechanism > since at that point it would be unused (the other callers of > mfd_cell_enable() look safe w/o a counter). Thanks for the review. Great point(s). I will fix this and submit a v2 shortly. > > dev_err(dev, "failed to create platform device '%s'\n", > > clones[i]); > > } -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [tip: x86/asm] x86/asm/ftrace: Mark function_hook as function
On Fri, Oct 18, 2019 at 04:31:25PM -0400, Steven Rostedt wrote: > Still looks ugly ;-) See below. I think it's not so bad. It is only built-tested on 64-bit and objtool complains about something again: arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x0: unreachable instruction but I think it is the better thing to do. > I do the talks hoping someone else will finally sit down and write the > documentation! Well, you can put down the outline of the doc and flesh out section by section gradually. Besides, you have all the text in your slides so it is actually more or less a copy+paste. --- diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst index 29ccd6e61fe5..f55c2bb74d00 100644 --- a/Documentation/asm-annotations.rst +++ b/Documentation/asm-annotations.rst @@ -117,9 +117,9 @@ This section covers ``SYM_FUNC_*`` and ``SYM_CODE_*`` enumerated above. So in most cases, developers should write something like in the following example, having some asm instructions in between the macros, of course:: -SYM_FUNC_START(function_hook) +SYM_FUNC_START(memset) ... asm insns ... -SYM_FUNC_END(function_hook) +SYM_FUNC_END(memset) In fact, this kind of annotation corresponds to the now deprecated ``ENTRY`` and ``ENDPROC`` macros. diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S index 8ed1f5d371f0..77be7e7e5e59 100644 --- a/arch/x86/kernel/ftrace_32.S +++ b/arch/x86/kernel/ftrace_32.S @@ -12,18 +12,16 @@ #include #include -# define function_hook __fentry__ -EXPORT_SYMBOL(__fentry__) - #ifdef CONFIG_FRAME_POINTER # define MCOUNT_FRAME 1 /* using frame = true */ #else # define MCOUNT_FRAME 0 /* using frame = false */ #endif -SYM_FUNC_START(function_hook) +SYM_CODE_START(__fentry__) ret -SYM_FUNC_END(function_hook) +SYM_CODE_END(__fentry__) +EXPORT_SYMBOL(__fentry__) SYM_CODE_START(ftrace_caller) diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 69c8d1b9119e..3029fe4f8547 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -14,9 +14,6 @@ .code64 .section .entry.text, "ax" -# define function_hook __fentry__ -EXPORT_SYMBOL(__fentry__) - #ifdef CONFIG_FRAME_POINTER /* Save parent and function stack frames (rip and rbp) */ # define MCOUNT_FRAME_SIZE(8+16*2) @@ -132,9 +129,10 @@ EXPORT_SYMBOL(__fentry__) #ifdef CONFIG_DYNAMIC_FTRACE -SYM_FUNC_START(function_hook) +SYM_CODE_START(__fentry__) retq -SYM_FUNC_END(function_hook) +SYM_CODE_END(__fentry__) +EXPORT_SYMBOL(__fentry__) SYM_FUNC_START(ftrace_caller) /* save_mcount_regs fills in first two parameters */ @@ -248,7 +246,7 @@ SYM_FUNC_END(ftrace_regs_caller) #else /* ! CONFIG_DYNAMIC_FTRACE */ -SYM_FUNC_START(function_hook) +SYM_CODE_START(__fentry__) cmpq $ftrace_stub, ftrace_trace_function jnz trace @@ -279,7 +277,8 @@ trace: restore_mcount_regs jmp fgraph_trace -SYM_FUNC_END(function_hook) +SYM_CODE_END(__fentry__) +EXPORT_SYMBOL(__fentry__) #endif /* CONFIG_DYNAMIC_FTRACE */ #ifdef CONFIG_FUNCTION_GRAPH_TRACER -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
Re: [PATCH] random: make try_to_generate_entropy() more robust
* Linus Torvalds wrote:
> On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel wrote:
> >
> > We can generate entropy on almost any CPU, even if it doesn't provide a
> > high-resolution timer for random_get_entropy(). As long as the CPU is
> > not idle, it changed the register file every few cycles. As long as the
> > ALU isn't fully synchronized with the timer, the drift between the
> > register file and the timer is enough to generate entropy from.
>
> > static void entropy_timer(struct timer_list *t)
> > {
> > + struct pt_regs *regs = get_irq_regs();
> > +
> > + /*
> > + * Even if we don't have a high-resolution timer in our system,
> > + * the register file itself is a high-resolution timer. It
> > + * isn't monotonic or particularly useful to read the current
> > + * time. But it changes with every retired instruction, which
> > + * is enough to generate entropy from.
> > + */
> > + mix_pool_bytes(_pool, regs, sizeof(*regs));
>
> Ok, so I still like this conceptually, but I'm not entirely sure that
> get_irq_regs() works reliably in a timer. It's done from softirq
> TIMER_SOFTIRQ context, so not necessarily _in_ an interrupt.
>
> Now, admittedly this code doesn't really need "reliably". The odd
> occasional hickup would arguably just add more noise. And I think the
> code works fine. get_irq_regs() will return a pointer to the last
> interrupt or exception frame on the current CPU, and I guess it's all
> fine. But let's bring in Thomas, who was not only active in the
> randomness discussion, but might also have stronger opinions on this
> get_irq_regs() usage.
>
> Thomas, opinions? Using the register state (while we're doing the
> whole entropy load with scheduling etc) looks like a good source of
> high-entropy data outside of just the TSC, so it does seem like a very
> valid model. But I want to run it past more people first, and Thomas
> is the obvious victim^Wchoice.
Not Thomas, but one potential problem I can see is that our
set_irq_regs() use (on x86) is fundamentally nested, we restore whatever
context we interrupt:
dagon:~/tip> git grep set_irq_regs arch/x86
arch/x86/include/asm/irq_regs.h:static inline struct pt_regs
*set_irq_regs(struct pt_regs *new_regs)
arch/x86/kernel/apic/apic.c:struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/apic/apic.c:set_irq_regs(old_regs);
arch/x86/kernel/cpu/acrn.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/cpu/acrn.c: set_irq_regs(old_regs);
arch/x86/kernel/cpu/mshyperv.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/cpu/mshyperv.c: set_irq_regs(old_regs);
arch/x86/kernel/cpu/mshyperv.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/cpu/mshyperv.c: set_irq_regs(old_regs);
arch/x86/kernel/irq.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/irq.c: set_irq_regs(old_regs);
arch/x86/kernel/irq.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/irq.c: set_irq_regs(old_regs);
arch/x86/kernel/irq.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/irq.c: set_irq_regs(old_regs);
arch/x86/kernel/irq.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/irq.c: set_irq_regs(old_regs);
arch/x86/kernel/irq.c: struct pt_regs *old_regs = set_irq_regs(regs);
arch/x86/kernel/irq.c: set_irq_regs(old_regs);
But from a softirq or threaded irq context that 'interrupted' regs
context might potentially be NULL.
NULL isn't a good thing to pass to mix_pool_bytes(), because the first
use of 'in' (='bytes') in _mix_pool_bytes() is a dereference without a
NULL check AFAICS:
w = rol32(*bytes++, input_rotate);
So at minimum I'd only mix this entropy into the pool if 'regs' is
non-zero. This would automatically do the right thing and not crash the
kernel on weird irq execution models such as threaded-only or -rt.
If irq-regs _is_ set, then I think we can generally rely on it to either
be a valid regs pointer or NULL, inside an IRQ handler execution
instance.
( Furthermore, if we are mixing in regs, then we might as well mix in a
few bytes of the interrupted stack as well if it's a kernel stack,
which would normally carry quite a bit of variation as well (such as
return addresses). Often it has more entropy than just register
contents, and it's also cache-hot, so a cheap source of entropy. But
that would require a second mix_pool_bytes() call and further
examination. Such an approach too would obviously require a non-NULL
'regs' pointer. :-) ]
Thanks,
Ingo
[bug?] LTP pt_test failing after 38bb8d77d0b9 "perf/x86/intel/pt: Split ToPA metadata and page layout"
Hi,
All variants of pt_test:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/tracing/pt_test/pt_test.c
started failing after:
38bb8d77d0b9 ("perf/x86/intel/pt: Split ToPA metadata and page layout")
with following error on console/dmesg:
pt: ToPA ERROR encountered, trying to recover
on Broadwell-EP:
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
stepping: 1
Regards,
Jan
Re: [PATCH -next] Bluetooth: btusb: Remove return statement in btintel_reset_to_bootloader
Hi Nathan,
> When building with Clang and CONFIG_BT_INTEL unset, the following error
> occurs:
>
> In file included from drivers/bluetooth/hci_ldisc.c:34:
> drivers/bluetooth/btintel.h:188:2: error: void function
> 'btintel_reset_to_bootloader' should not return a value [-Wreturn-type]
>return -EOPNOTSUPP;
>^ ~~~
> 1 error generated.
>
> Remove the unneeded return statement to fix this.
>
> Fixes: b9a2562f4918 ("Bluetooth: btusb: Trigger Intel FW download error
> recovery")
> Link: https://github.com/ClangBuiltLinux/linux/issues/743
> Reported-by:
> Reported-by: Stephen Rothwell
> Signed-off-by: Nathan Chancellor
> ---
> drivers/bluetooth/btintel.h | 1 -
> 1 file changed, 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
[PATCH net-next 2/8] net: hns3: optimized MAC address in management table.
From: Guojia Liao
mac_addr_hi32 and mac_addr_lo16 are used to store the MAC address
for management table. But using array of mac_addr[ETH_ALEN] would
be more general and not need to care about the big-endian mode of
the CPU.
Signed-off-by: Guojia Liao
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 4 ++--
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 3578832..919911f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -5,6 +5,7 @@
#define __HCLGE_CMD_H
#include
#include
+#include
#define HCLGE_CMDQ_TX_TIMEOUT 3
@@ -712,8 +713,7 @@ struct hclge_mac_mgr_tbl_entry_cmd {
u8 flags;
u8 resp_code;
__le16 vlan_tag;
- __le32 mac_addr_hi32;
- __le16 mac_addr_lo16;
+ u8 mac_addr[ETH_ALEN];
__le16 rsv1;
__le16 ethter_type;
__le16 egress_port;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 8a3a4fd..ffdb8ce 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -325,8 +325,7 @@ static const struct hclge_mac_mgr_tbl_entry_cmd
hclge_mgr_table[] = {
{
.flags = HCLGE_MAC_MGR_MASK_VLAN_B,
.ethter_type = cpu_to_le16(ETH_P_LLDP),
- .mac_addr_hi32 = cpu_to_le32(htonl(0x0180C200)),
- .mac_addr_lo16 = cpu_to_le16(htons(0x000E)),
+ .mac_addr = {0x01, 0x80, 0xc2, 0x00, 0x00, 0x0e},
.i_port_bitmap = 0x1,
},
};
--
2.7.4
[PATCH net-next 7/8] net: hns3: do not allocate linear data for fraglist skb
From: Yunsheng Lin
Currently, napi_alloc_skb() is used to allocate skb for fraglist
when the head skb is not enough to hold the remaining data, and
the remaining data is added to the frags part of the fraglist skb,
leaving the linear part unused.
So this patch passes length of 0 to allocate fraglist skb with
zero size of linear data.
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1c5e0d2..0fdd684 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2863,8 +2863,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring,
struct hns3_desc *desc,
return -ENXIO;
if (unlikely(ring->frag_num >= MAX_SKB_FRAGS)) {
- new_skb = napi_alloc_skb(>tqp_vector->napi,
-HNS3_RX_HEAD_SIZE);
+ new_skb = napi_alloc_skb(>tqp_vector->napi, 0);
if (unlikely(!new_skb)) {
hns3_rl_err(ring_to_netdev(ring),
"alloc rx fraglist skb fail\n");
--
2.7.4
[PATCH net-next 1/8] net: hns3: remove struct hns3_nic_ring_data in hns3_enet module
From: Yunsheng Lin
Only the queue_index field in struct hns3_nic_ring_data is
used, other field is unused and unnecessary for hns3 driver,
so this patch removes it and move the queue_index field to
hns3_enet_ring.
This patch also removes an unused struct hns_queue declaration.
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 24 ++--
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 139 +++--
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 16 +--
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 33 +++--
4 files changed, 74 insertions(+), 138 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
index 28961a6..fe5bc6f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
@@ -16,15 +16,14 @@ static int hns3_dbg_queue_info(struct hnae3_handle *h,
const char *cmd_buf)
{
struct hns3_nic_priv *priv = h->priv;
- struct hns3_nic_ring_data *ring_data;
struct hns3_enet_ring *ring;
u32 base_add_l, base_add_h;
u32 queue_num, queue_max;
u32 value, i = 0;
int cnt;
- if (!priv->ring_data) {
- dev_err(>pdev->dev, "ring_data is NULL\n");
+ if (!priv->ring) {
+ dev_err(>pdev->dev, "priv->ring is NULL\n");
return -EFAULT;
}
@@ -44,7 +43,6 @@ static int hns3_dbg_queue_info(struct hnae3_handle *h,
return -EINVAL;
}
- ring_data = priv->ring_data;
for (i = queue_num; i < queue_max; i++) {
/* Each cycle needs to determine whether the instance is reset,
* to prevent reference to invalid memory. And need to ensure
@@ -54,7 +52,7 @@ static int hns3_dbg_queue_info(struct hnae3_handle *h,
test_bit(HNS3_NIC_STATE_RESETTING, >state))
return -EPERM;
- ring = ring_data[(u32)(i + h->kinfo.num_tqps)].ring;
+ ring = >ring[(u32)(i + h->kinfo.num_tqps)];
base_add_h = readl_relaxed(ring->tqp->io_base +
HNS3_RING_RX_RING_BASEADDR_H_REG);
base_add_l = readl_relaxed(ring->tqp->io_base +
@@ -86,7 +84,7 @@ static int hns3_dbg_queue_info(struct hnae3_handle *h,
HNS3_RING_RX_RING_PKTNUM_RECORD_REG);
dev_info(>pdev->dev, "RX(%d) RING PKTNUM: %u\n", i, value);
- ring = ring_data[i].ring;
+ ring = >ring[i];
base_add_h = readl_relaxed(ring->tqp->io_base +
HNS3_RING_TX_RING_BASEADDR_H_REG);
base_add_l = readl_relaxed(ring->tqp->io_base +
@@ -130,7 +128,6 @@ static int hns3_dbg_queue_info(struct hnae3_handle *h,
static int hns3_dbg_queue_map(struct hnae3_handle *h)
{
struct hns3_nic_priv *priv = h->priv;
- struct hns3_nic_ring_data *ring_data;
int i;
if (!h->ae_algo->ops->get_global_queue_id)
@@ -143,15 +140,12 @@ static int hns3_dbg_queue_map(struct hnae3_handle *h)
u16 global_qid;
global_qid = h->ae_algo->ops->get_global_queue_id(h, i);
- ring_data = >ring_data[i];
- if (!ring_data || !ring_data->ring ||
- !ring_data->ring->tqp_vector)
+ if (!priv->ring || !priv->ring[i].tqp_vector)
continue;
dev_info(>pdev->dev,
" %4d%4d%4d\n",
-i, global_qid,
-ring_data->ring->tqp_vector->vector_irq);
+i, global_qid, priv->ring[i].tqp_vector->vector_irq);
}
return 0;
@@ -160,7 +154,6 @@ static int hns3_dbg_queue_map(struct hnae3_handle *h)
static int hns3_dbg_bd_info(struct hnae3_handle *h, const char *cmd_buf)
{
struct hns3_nic_priv *priv = h->priv;
- struct hns3_nic_ring_data *ring_data;
struct hns3_desc *rx_desc, *tx_desc;
struct device *dev = >pdev->dev;
struct hns3_enet_ring *ring;
@@ -183,8 +176,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
return -EINVAL;
}
- ring_data = priv->ring_data;
- ring = ring_data[q_num].ring;
+ ring = >ring[q_num];
value = readl_relaxed(ring->tqp->io_base + HNS3_RING_TX_RING_TAIL_REG);
tx_index = (cnt == 1) ? value : tx_index;
@@ -214,7 +206,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
dev_info(dev, "(TX)vld_ra_ri: %u\n", tx_desc->tx.bdtp_fe_sc_vld_ra_ri);
dev_info(dev, "(TX)mss: %u\n", tx_desc->tx.mss);
- ring = ring_data[q_num + h->kinfo.num_tqps].ring;
+
[PATCH net-next 5/8] net: hns3: make struct hns3_enet_ring cacheline aligned
From: Yunsheng Lin
Since struct hns3_enet_ring is a frequently used in critical data
path, so make it cacheline aligned as struct hns3_enet_tqp_vector.
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 8a88002..0725dc5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -435,7 +435,7 @@ struct hns3_enet_ring {
int pending_buf;
struct sk_buff *skb;
struct sk_buff *tail_skb;
-};
+} cacheline_internodealigned_in_smp;
enum hns3_flow_level_range {
HNS3_FLOW_LOW = 0,
--
2.7.4
[PATCH net-next 3/8] net: hns3: minor optimization for barrier in IO path
From: Yunsheng Lin
Currently, the TX and RX ring in a queue is bounded to the
same IRQ, there may be unnecessary barrier op when only one of
the ring need to be processed.
This patch adjusts the location of rmb() in hns3_clean_tx_ring()
and adds a checking in hns3_clean_rx_ring() to avoid unnecessary
barrier op when there is nothing to do for the ring.
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 635bdda..089cd58 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2485,11 +2485,12 @@ void hns3_clean_tx_ring(struct hns3_enet_ring *ring)
int head;
head = readl_relaxed(ring->tqp->io_base + HNS3_RING_TX_RING_HEAD_REG);
- rmb(); /* Make sure head is ready before touch any data */
if (is_ring_empty(ring) || head == ring->next_to_clean)
return; /* no data to poll */
+ rmb(); /* Make sure head is ready before touch any data */
+
if (unlikely(!is_valid_clean_head(ring, head))) {
netdev_err(netdev, "wrong head (%d, %d-%d)\n", head,
ring->next_to_use, ring->next_to_clean);
@@ -3105,11 +3106,14 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
int err, num;
num = readl_relaxed(ring->tqp->io_base + HNS3_RING_RX_RING_FBDNUM_REG);
- rmb(); /* Make sure num taken effect before the other data is touched */
-
num -= unused_count;
unused_count -= ring->pending_buf;
+ if (num <= 0)
+ goto out;
+
+ rmb(); /* Make sure num taken effect before the other data is touched */
+
while (recv_pkts < budget && recv_bds < num) {
/* Reuse or realloc buffers */
if (unused_count >= RCB_NOF_ALLOC_RX_BUFF_ONCE) {
--
2.7.4
[PATCH net-next 6/8] net: hns3: minor cleanup for hns3_handle_rx_bd()
From: Yunsheng Lin
Since commit e55970950556 ("net: hns3: Add handling of GRO Pkts
not fully RX'ed in NAPI poll"), ring->skb is used to record the
current SKB when processing the RX BD in hns3_handle_rx_bd(),
so the parameter out_skb is unnecessary.
This patch also adjusts the err checking to reduce duplication
in hns3_handle_rx_bd(), and "err == -ENXIO" is rare case, so put
it in the unlikely annotation.
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 38 +
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 422fa4d..1c5e0d2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2831,10 +2831,10 @@ static int hns3_alloc_skb(struct hns3_enet_ring *ring,
unsigned int length,
}
static int hns3_add_frag(struct hns3_enet_ring *ring, struct hns3_desc *desc,
-struct sk_buff **out_skb, bool pending)
+bool pending)
{
- struct sk_buff *skb = *out_skb;
- struct sk_buff *head_skb = *out_skb;
+ struct sk_buff *skb = ring->skb;
+ struct sk_buff *head_skb = skb;
struct sk_buff *new_skb;
struct hns3_desc_cb *desc_cb;
struct hns3_desc *pre_desc;
@@ -3017,8 +3017,7 @@ static int hns3_handle_bdinfo(struct hns3_enet_ring
*ring, struct sk_buff *skb)
return 0;
}
-static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
-struct sk_buff **out_skb)
+static int hns3_handle_rx_bd(struct hns3_enet_ring *ring)
{
struct sk_buff *skb = ring->skb;
struct hns3_desc_cb *desc_cb;
@@ -3056,12 +3055,12 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring
*ring,
if (!skb) {
ret = hns3_alloc_skb(ring, length, ring->va);
- *out_skb = skb = ring->skb;
+ skb = ring->skb;
if (ret < 0) /* alloc buffer fail */
return ret;
if (ret > 0) { /* need add frag */
- ret = hns3_add_frag(ring, desc, , false);
+ ret = hns3_add_frag(ring, desc, false);
if (ret)
return ret;
@@ -3072,7 +3071,7 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
ALIGN(ring->pull_len, sizeof(long)));
}
} else {
- ret = hns3_add_frag(ring, desc, , true);
+ ret = hns3_add_frag(ring, desc, true);
if (ret)
return ret;
@@ -3090,8 +3089,6 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
}
skb_record_rx_queue(skb, ring->tqp->tqp_index);
- *out_skb = skb;
-
return 0;
}
@@ -3100,7 +3097,6 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
{
#define RCB_NOF_ALLOC_RX_BUFF_ONCE 16
int unused_count = hns3_desc_unused(ring);
- struct sk_buff *skb = ring->skb;
int recv_pkts = 0;
int recv_bds = 0;
int err, num;
@@ -3123,27 +3119,19 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
}
/* Poll one pkt */
- err = hns3_handle_rx_bd(ring, );
- if (unlikely(!skb)) /* This fault cannot be repaired */
+ err = hns3_handle_rx_bd(ring);
+ /* Do not get FE for the packet or failed to alloc skb */
+ if (unlikely(!ring->skb || err == -ENXIO)) {
goto out;
-
- if (err == -ENXIO) { /* Do not get FE for the packet */
- goto out;
- } else if (unlikely(err)) { /* Do jump the err */
- recv_bds += ring->pending_buf;
- unused_count += ring->pending_buf;
- ring->skb = NULL;
- ring->pending_buf = 0;
- continue;
+ } else if (likely(!err)) {
+ rx_fn(ring, ring->skb);
+ recv_pkts++;
}
- rx_fn(ring, skb);
recv_bds += ring->pending_buf;
unused_count += ring->pending_buf;
ring->skb = NULL;
ring->pending_buf = 0;
-
- recv_pkts++;
}
out:
--
2.7.4
[PATCH net-next 4/8] net: hns3: introduce ring_to_netdev() in enet module
From: Yunsheng Lin
There are a few places that need to access the netdev of a ring
through ring->tqp->handle->kinfo.netdev, and ring->tqp is a struct
which both in enet and hclge modules, it is better to use the
struct that is only used in enet module.
This patch adds the ring_to_netdev() to access the netdev of ring
through ring->tqp_vector->napi.dev.
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 14 +++---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 ++
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 089cd58..422fa4d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2478,7 +2478,7 @@ static int is_valid_clean_head(struct hns3_enet_ring
*ring, int h)
void hns3_clean_tx_ring(struct hns3_enet_ring *ring)
{
- struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
+ struct net_device *netdev = ring_to_netdev(ring);
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct netdev_queue *dev_queue;
int bytes, pkts;
@@ -2560,7 +2560,7 @@ static void hns3_nic_alloc_rx_buffers(struct
hns3_enet_ring *ring,
ring->stats.sw_err_cnt++;
u64_stats_update_end(>syncp);
- hns3_rl_err(ring->tqp_vector->napi.dev,
+ hns3_rl_err(ring_to_netdev(ring),
"alloc rx buffer failed: %d\n",
ret);
break;
@@ -2669,7 +2669,7 @@ static int hns3_gro_complete(struct sk_buff *skb, u32
l234info)
static void hns3_rx_checksum(struct hns3_enet_ring *ring, struct sk_buff *skb,
u32 l234info, u32 bd_base_info, u32 ol_info)
{
- struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
+ struct net_device *netdev = ring_to_netdev(ring);
int l3_type, l4_type;
int ol4_type;
@@ -2785,7 +2785,7 @@ static int hns3_alloc_skb(struct hns3_enet_ring *ring,
unsigned int length,
{
#define HNS3_NEED_ADD_FRAG 1
struct hns3_desc_cb *desc_cb = >desc_cb[ring->next_to_clean];
- struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
+ struct net_device *netdev = ring_to_netdev(ring);
struct sk_buff *skb;
ring->skb = napi_alloc_skb(>tqp_vector->napi, HNS3_RX_HEAD_SIZE);
@@ -2866,7 +2866,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring,
struct hns3_desc *desc,
new_skb = napi_alloc_skb(>tqp_vector->napi,
HNS3_RX_HEAD_SIZE);
if (unlikely(!new_skb)) {
- hns3_rl_err(ring->tqp_vector->napi.dev,
+ hns3_rl_err(ring_to_netdev(ring),
"alloc rx fraglist skb fail\n");
return -ENXIO;
}
@@ -2942,7 +2942,7 @@ static void hns3_set_rx_skb_rss_type(struct
hns3_enet_ring *ring,
static int hns3_handle_bdinfo(struct hns3_enet_ring *ring, struct sk_buff *skb)
{
- struct net_device *netdev = ring->tqp->handle->kinfo.netdev;
+ struct net_device *netdev = ring_to_netdev(ring);
enum hns3_pkt_l2t_type l2_frame_type;
u32 bd_base_info, l234info, ol_info;
struct hns3_desc *desc;
@@ -4224,7 +4224,7 @@ static int hns3_clear_rx_ring(struct hns3_enet_ring *ring)
/* if alloc new buffer fail, exit directly
* and reclear in up flow.
*/
- netdev_warn(ring->tqp->handle->kinfo.netdev,
+ netdev_warn(ring_to_netdev(ring),
"reserve buffer map failed, ret =
%d\n",
ret);
return ret;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 3322284..8a88002 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -607,6 +607,8 @@ static inline bool hns3_nic_resetting(struct net_device
*netdev)
#define ring_to_dev(ring) ((ring)->dev)
+#define ring_to_netdev(ring) ((ring)->tqp_vector->napi.dev)
+
#define ring_to_dma_dir(ring) (HNAE3_IS_TX_RING(ring) ? \
DMA_TO_DEVICE : DMA_FROM_DEVICE)
--
2.7.4
[PATCH net-next 0/8] net: hns3: add some cleanups & optimizations
This patchset includes some cleanups and optimizations for the HNS3 ethernet driver. [patch 1/8] removes unused and unnecessary structures. [patch 2/8] uses a ETH_ALEN u8 array to replace two mac_addr_* field in struct hclge_mac_mgr_tbl_entry_cmd. [patch 3/8] optimizes the barrier used in the IO path. [patch 4/8] introduces macro ring_to_netdev() to get netdevive from struct hns3_enet_ring variable. [patch 5/8] makes struct hns3_enet_ring to be cacheline aligned [patch 6/8] adds a minor cleanup for hns3_handle_rx_bd(). [patch 7/8] removes linear data allocating for fraglist SKB. [patch 8/8] clears hardware error when resetting. --- note: In previous patchset, there are some bugfixes which needs below new feature, which is only in 'net-next' but not in 'net' now: net: hns3: support tx-scatter-gather-fraglist feature net: hns3: add support for spoof check setting So, these bugfixes will be upstreamed when the patch needed is on 'net' tree. --- Guojia Liao (1): net: hns3: optimized MAC address in management table. Jian Shen (1): net: hns3: log and clear hardware error after reset complete Yunsheng Lin (6): net: hns3: remove struct hns3_nic_ring_data in hns3_enet module net: hns3: minor optimization for barrier in IO path net: hns3: introduce ring_to_netdev() in enet module net: hns3: make struct hns3_enet_ring cacheline aligned net: hns3: minor cleanup for hns3_handle_rx_bd() net: hns3: do not allocate linear data for fraglist skb drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 24 +-- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 204 - drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 20 +- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 33 ++-- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 4 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 6 +- 6 files changed, 111 insertions(+), 180 deletions(-) -- 2.7.4
[PATCH net-next 8/8] net: hns3: log and clear hardware error after reset complete
From: Jian Shen When device is resetting, the CMDQ service may be stopped until reset completed. If a new RAS error occurs at this moment, it will no be able to clear the RAS source. This patch fixes it by clear the RAS source after reset complete. Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c index ffdb8ce..95c3897 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -9781,6 +9781,9 @@ static int hclge_reset_ae_dev(struct hnae3_ae_dev *ae_dev) return ret; } + /* Log and clear the hw errors those already occurred */ + hclge_handle_all_hns_hw_errors(ae_dev); + /* Re-enable the hw error interrupts because * the interrupts get disabled on global reset. */ -- 2.7.4
Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal throttle messages
On Fri, Oct 18, 2019 at 01:38:32PM -0700, Luck, Tony wrote: > Sorry to have caused confusion. Ditto. But us causing confusion is fine - this way we can talk about what we really wanna do! :-))) > The thoughts behind that statement are that we currently have an issue > with too many noisy high severity messages. The interim solution we > are going with is to downgrade the severity. But if we apply a time > based filter to remove most of the noise by not printing at all, maybe > what we have left is a very small number of high severity messages. > > But that's completely up for debate. Well, I think those messages being pr_warn are fine if one wants to inspect dmesg for signs of overheating and the platform is hitting some thermal limits. And if the time-based filter is not too accurate, that's fine too, I guess, as long as we don't flood dmesg. What I don't like is the command line parameter and us putting the onus on the user to decide although we have all that info in the kernel already and we can do that decision automatically. > I agree it is a good thing to look at. I'm not so sure we will find > a good enough method that works all the way from tablet to server, > so we might end up with "#define MAX_THERM_TIME 8000" ... but some > study of options would either turn up a good heuristic, or provide > evidence for why that is either hard, or no better than a constant. Yeah, I still think a simple avg filter which starts from a sufficiently high value and improves it over time, should be good enough. Hell, even the trivial formula we use in the CMCI interrupt for polling, might work, where we either double the interval or halve it, depending on recent history. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 2/2] xfs: replace homemade binary search
On Sat, Oct 19, 2019 at 09:20:33AM +0200, Thomas Meyer wrote: > use newly introduced bsearch_idx instead. > > Signed-off-by: Thomas Meyer What is the point? This adds more code, and makes it slower by adding an indirect function call.
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: [PATCH linux-kselftest/test v4] lib/list-test: add a test for the 'list' doubly linked list
On Fri, Oct 18, 2019 at 02:55:49PM -0700, David Gow wrote:
> Add a KUnit test for the kernel doubly linked list implementation in
> include/linux/list.h
>
> Each test case (list_test_x) is focused on testing the behaviour of the
> list function/macro 'x'. None of the tests pass invalid lists to these
> macros, and so should behave identically with DEBUG_LIST enabled and
> disabled.
>
> Note that, at present, it only tests the list_ types (not the
> singly-linked hlist_), and does not yet test all of the
> list_for_each_entry* macros (and some related things like
> list_prepare_entry).
>
> Signed-off-by: David Gow
> ---
>
> The changes from v3 are mostly to do with naming:
> - The Kconfig entry has been renamed from LIST_TEST to LIST_KUNIT_TEST,
> which matches the SYSCTL_KUNIT_TEST entry,
> - The Kconfig description was updated to better match other KUnit tests,
> specifying that the test is not intended for use in a production
> kernel. A now-redundant mention of the test running a boot was
> removed.
> - The MAINTAINERS entry refers to a "KUNIT TEST" rather than a "UNIT
> TEST"
> - The module name has changed from "list-test" to "list-kunit-test".
>
> Earlier versions of the test can be found:
> v3:
> https://lore.kernel.org/linux-kselftest/20191016215707.95317-1-david...@google.com/
> v2:
> https://lore.kernel.org/linux-kselftest/20191010185631.26541-1-david...@google.com/
> v1:
> https://lore.kernel.org/linux-kselftest/20191007213633.92565-1-david...@google.com/
>
> MAINTAINERS | 5 +
> lib/Kconfig.debug | 18 ++
> lib/Makefile | 3 +
> lib/list-test.c | 740 ++
> 4 files changed, 766 insertions(+)
> create mode 100644 lib/list-test.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7ef985e01457..7ced1b69a3d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9504,6 +9504,11 @@ F: Documentation/misc-devices/lis3lv02d.rst
> F: drivers/misc/lis3lv02d/
> F: drivers/platform/x86/hp_accel.c
>
> +LIST KUNIT TEST
> +M: David Gow
> +S: Maintained
> +F: lib/list-test.c
> +
> LIVE PATCHING
> M: Josh Poimboeuf
> M: Jiri Kosina
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index a3017a5dadcd..7991b78eb1f3 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1961,6 +1961,24 @@ config SYSCTL_KUNIT_TEST
>
> If unsure, say N.
>
> +config LIST_KUNIT_TEST
> + bool "KUnit Test for Kernel Linked-list structures"
> + depends on KUNIT
> + help
> + This builds the linked list KUnit test suite.
> + It tests that the API and basic functionality of the list_head type
> + and associated macros.
> +
> + KUnit tests run during boot and output the results to the debug log
> + in TAP format (http://testanything.org/). Only useful for kernel devs
> + running the KUnit test harness, and not intended for inclusion into a
> + production build.
> +
> + For more information on KUnit and unit tests in general please refer
> + to the KUnit documentation in Documentation/dev-tools/kunit/.
> +
> + If unsure, say N.
> +
> config TEST_UDELAY
> tristate "udelay test driver"
> help
> diff --git a/lib/Makefile b/lib/Makefile
> index bba1fd5485f7..890e581d00c4 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -292,3 +292,6 @@ obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
> obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
> obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
> obj-$(CONFIG_OBJAGG) += objagg.o
> +
> +# KUnit tests
> +obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> diff --git a/lib/list-test.c b/lib/list-test.c
> new file mode 100644
> index ..75ba3ddac959
> --- /dev/null
> +++ b/lib/list-test.c
> @@ -0,0 +1,740 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for the Kernel Linked-list structures.
> + *
> + * Copyright (C) 2019, Google LLC.
> + * Author: David Gow
> + */
> +#include
> +
> +#include
> +
> +struct list_test_struct {
> + int data;
> + struct list_head list;
> +};
> +
> +static void list_test_list_init(struct kunit *test)
> +{
> + /* Test the different ways of initialising a list. */
> + struct list_head list1 = LIST_HEAD_INIT(list1);
> + struct list_head list2;
> + LIST_HEAD(list3);
> + struct list_head *list4;
> + struct list_head *list5;
> +
> + INIT_LIST_HEAD();
> +
> + list4 = kzalloc(sizeof(*list4), GFP_KERNEL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, list4);
Why not just use GFP_KERNEL | GFP_NOFAIL and remove the check?
kzalloc() can't return error pointers. If this were an IS_ERR_OR_NULL()
check then it would generate a static checker warning, but static
checkers don't know about KUNIT_ASSERT_NOT_ERR_OR_NULL() yet so you're
safe.
But generally NULL is a special case of success. A common situation is
where the user deliberately disables a feature, that means it's not an
error but we also don't have a valid
Re: [PATCH] PCI: Warn about host bridge device when its numa node is NO_NODE
On Sat, Oct 19, 2019 at 02:45:43PM +0800, Yunsheng Lin wrote: > + if (nr_node_ids > 1 && dev_to_node(bus->bridge) == NUMA_NO_NODE) > + dev_err(bus->bridge, FW_BUG "No node assigned on NUMA capable > HW by BIOS. Please contact your vendor for updates.\n"); > + The whole idea of mentioning a BIOS in architeture indepent code doesn't make sense at all.
Re: [PATCH 1/2] platform/x86: huawei-wmi: Stricter battery thresholds set
On Fri, Oct 18, 2019 at 06:42:13PM -0400, Ayman Bagabas wrote: > Check if battery thresholds are within 0 and 100. > --- Thanks! Don't forget to add your Signed-off-by: though. regards, dan carpenter
[PATCH] irq/irqdomain: __irq_domain_alloc_fwnode comment
Commit b977fcf477c1 ("irqdomain/debugfs: Use PAs to generate fwnode names")
changed the parameter of __irq_domain_alloc_fwnode(), but didn't
change the comment meanwhile.
This patch can fix this.
Signed-off-by: Yi Wang
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 132672b..dd822fd 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -51,7 +51,7 @@ static inline void debugfs_remove_domain_dir(struct
irq_domain *d) { }
* @type: Type of irqchip_fwnode. See linux/irqdomain.h
* @name: Optional user provided domain name
* @id:Optional user provided id if name != NULL
- * @data: Optional user-provided data
+ * @pa:Optional user-provided physical address
*
* Allocate a struct irqchip_fwid, and return a poiner to the embedded
* fwnode_handle (or NULL on failure).
--
1.8.3.1
Re: [PATCH 39/46] power: tosa: simplify probe function
Hi Arnd,
On Fri, Oct 18, 2019 at 05:41:54PM +0200, Arnd Bergmann wrote:
> We have three power supplies that need similar initialization.
> As a preparation for the gpio lookup table conversion, split
> out the initialization into a separate function.
>
> Cc: Sebastian Reichel
> Cc: linux...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
> ---
Assuming, that the whole series goes through ARM:
Reviewed-by: Sebastian Reichel
Acked-by: Sebastian Reichel
If the series doesn't make it into 5.5, I can also apply
this cleanup patch.
-- Sebastian
> drivers/power/supply/tosa_battery.c | 50 ++---
> 1 file changed, 24 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/power/supply/tosa_battery.c
> b/drivers/power/supply/tosa_battery.c
> index 32cc31cd4761..b26b0eca33e1 100644
> --- a/drivers/power/supply/tosa_battery.c
> +++ b/drivers/power/supply/tosa_battery.c
> @@ -343,12 +343,24 @@ static int tosa_bat_resume(struct platform_device *dev)
> #define tosa_bat_resume NULL
> #endif
>
> +static int tosa_power_supply_register(struct device *dev,
> + struct tosa_bat *bat,
> + const struct power_supply_desc *desc)
> +{
> + struct power_supply_config cfg = {
> + .drv_data = bat,
> + };
> +
> + mutex_init(>work_lock);
> + bat->psy = power_supply_register(dev, desc, );
> +
> + return PTR_ERR_OR_ZERO(bat->psy);
> +}
> +
> +
> static int tosa_bat_probe(struct platform_device *dev)
> {
> int ret;
> - struct power_supply_config main_psy_cfg = {},
> -jacket_psy_cfg = {},
> -bu_psy_cfg = {};
>
> if (!machine_is_tosa())
> return -ENODEV;
> @@ -357,36 +369,22 @@ static int tosa_bat_probe(struct platform_device *dev)
> if (ret)
> return ret;
>
> - mutex_init(_bat_main.work_lock);
> - mutex_init(_bat_jacket.work_lock);
> -
> INIT_WORK(_work, tosa_bat_work);
>
> - main_psy_cfg.drv_data = _bat_main;
> - tosa_bat_main.psy = power_supply_register(>dev,
> - _bat_main_desc,
> - _psy_cfg);
> - if (IS_ERR(tosa_bat_main.psy)) {
> - ret = PTR_ERR(tosa_bat_main.psy);
> + ret = tosa_power_supply_register(>dev, _bat_main,
> + _bat_main_desc);
> + if (ret)
> goto err_psy_reg_main;
> - }
>
> - jacket_psy_cfg.drv_data = _bat_jacket;
> - tosa_bat_jacket.psy = power_supply_register(>dev,
> - _bat_jacket_desc,
> - _psy_cfg);
> - if (IS_ERR(tosa_bat_jacket.psy)) {
> - ret = PTR_ERR(tosa_bat_jacket.psy);
> + ret = tosa_power_supply_register(>dev, _bat_jacket,
> + _bat_jacket_desc);
> + if (ret)
> goto err_psy_reg_jacket;
> - }
>
> - bu_psy_cfg.drv_data = _bat_bu;
> - tosa_bat_bu.psy = power_supply_register(>dev, _bat_bu_desc,
> - _psy_cfg);
> - if (IS_ERR(tosa_bat_bu.psy)) {
> - ret = PTR_ERR(tosa_bat_bu.psy);
> + ret = tosa_power_supply_register(>dev, _bat_bu,
> + _bat_bu_desc);
> + if (ret)
> goto err_psy_reg_bu;
> - }
>
> ret = request_irq(gpio_to_irq(TOSA_GPIO_BAT0_CRG),
> tosa_bat_gpio_isr,
> --
> 2.20.0
>
signature.asc
Description: PGP signature
Re: [PATCH 40/46] ARM: pxa: tosa: use gpio lookup for battery
Hi,
On Fri, Oct 18, 2019 at 05:41:55PM +0200, Arnd Bergmann wrote:
> The battery driver uses a lot of GPIO lines, hardcoded from a
> machine header file.
>
> Change it to use a gpiod lookup table instead.
>
> Cc: Sebastian Reichel
> Cc: linux...@vger.kernel.org
> Signed-off-by: Arnd Bergmann
> ---
That's a nice cleanup patch :) I assume, that this is also
merged together with the whole series through ARM, so:
Reviewed-by: Sebastian Reichel
Acked-by: Sebastian Reichel
-- Sebastian
> arch/arm/mach-pxa/tosa.c| 23 +
> drivers/power/supply/tosa_battery.c | 147
> 2 files changed, 109 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
> index 8329a2969b2b..ef3bbf6d158e 100644
> --- a/arch/arm/mach-pxa/tosa.c
> +++ b/arch/arm/mach-pxa/tosa.c
> @@ -365,6 +365,28 @@ static struct pxaficp_platform_data
> tosa_ficp_platform_data = {
> .shutdown = tosa_irda_shutdown,
> };
>
> +static struct gpiod_lookup_table tosa_battery_gpio_table = {
> + .dev_id = "wm97xx-battery",
> + .table = {
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_CHARGE_OFF -
> TOSA_TC6393XB_GPIO_BASE,"main charge off", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_CHARGE_OFF_JC -
> TOSA_TC6393XB_GPIO_BASE, "jacket charge off", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_BAT_SW_ON -
> TOSA_TC6393XB_GPIO_BASE, "battery switch", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_BAT0_V_ON -
> TOSA_TC6393XB_GPIO_BASE, "main battery", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_BAT1_V_ON -
> TOSA_TC6393XB_GPIO_BASE, "jacket battery", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_BAT1_TH_ON -
> TOSA_TC6393XB_GPIO_BASE,"main battery temp", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_BAT0_TH_ON -
> TOSA_TC6393XB_GPIO_BASE,"jacket battery temp", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("tc6393xb", TOSA_GPIO_BU_CHRG_ON -
> TOSA_TC6393XB_GPIO_BASE,"backup battery", GPIO_ACTIVE_HIGH ),
> +
> + GPIO_LOOKUP("gpio-pxa", TOSA_GPIO_BAT0_CRG, "main battery
> full", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("gpio-pxa", TOSA_GPIO_BAT1_CRG, "jacket
> battery full", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("gpio-pxa", TOSA_GPIO_BAT0_LOW, "main battery
> low", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("gpio-pxa", TOSA_GPIO_BAT1_LOW, "jacket
> battery low", GPIO_ACTIVE_HIGH ),
> + GPIO_LOOKUP("gpio-pxa", TOSA_GPIO_JACKET_DETECT, "jacket
> detect", GPIO_ACTIVE_HIGH ),
> + { },
> + },
> +};
> +
> +
> /*
> * Tosa AC IN
> */
> @@ -946,6 +968,7 @@ static void __init tosa_init(void)
> /* enable batt_fault */
> PMCR = 0x01;
>
> + gpiod_add_lookup_table(_battery_gpio_table);
> gpiod_add_lookup_table(_mci_gpio_table);
> gpiod_add_lookup_table(_audio_gpio_table);
> pxa_set_mci_info(_mci_platform_data);
> diff --git a/drivers/power/supply/tosa_battery.c
> b/drivers/power/supply/tosa_battery.c
> index b26b0eca33e1..d10320f348d0 100644
> --- a/drivers/power/supply/tosa_battery.c
> +++ b/drivers/power/supply/tosa_battery.c
> @@ -15,11 +15,16 @@
> #include
>
> #include
> -#include
>
> static DEFINE_MUTEX(bat_lock); /* protects gpio pins */
> static struct work_struct bat_work;
>
> +struct tosa_gpio {
> + const char *con;
> + enum gpiod_flags flags;
> + struct gpio_desc *desc;
> +};
> +
> struct tosa_bat {
> int status;
> struct power_supply *psy;
> @@ -28,38 +33,42 @@ struct tosa_bat {
> struct mutex work_lock; /* protects data */
>
> bool (*is_present)(struct tosa_bat *bat);
> - int gpio_full;
> - int gpio_charge_off;
> + struct tosa_gpio gpio_full;
> + struct tosa_gpio gpio_charge_off;
>
> int technology;
>
> - int gpio_bat;
> + struct tosa_gpio gpio_bat;
> int adc_bat;
> int adc_bat_divider;
> int bat_max;
> int bat_min;
>
> - int gpio_temp;
> + struct tosa_gpio gpio_temp;
> int adc_temp;
> int adc_temp_divider;
> };
>
> static struct tosa_bat tosa_bat_main;
> static struct tosa_bat tosa_bat_jacket;
> +static struct tosa_gpio gpiod_jacket_det = { "jacket detect", GPIOD_IN };
> +static struct tosa_gpio gpiod_battery_switch = { "battery switch",
> GPIOD_OUT_LOW };
> +static struct tosa_gpio gpiod_main_battery_low = { "main battery low",
> GPIOD_IN };
> +static struct tosa_gpio gpiod_jacket_battery_low = { "jacket battery low",
> GPIOD_IN };
>
> static unsigned long tosa_read_bat(struct tosa_bat *bat)
> {
> unsigned long value = 0;
>
> - if (bat->gpio_bat < 0 || bat->adc_bat < 0)
> + if (!bat->gpio_bat.desc || bat->adc_bat < 0)
> return 0;
>
>
Re: [PATCH 6/6 v2] MMC: JZ4740: Add support for LPM.
Hi Uffe,
On 2019年10月18日 16:52, Ulf Hansson wrote:
On Sat, 12 Oct 2019 at 07:19, Zhou Yanjie wrote:
add support for low power mode of Ingenic's MMC/SD Controller.
Signed-off-by: Zhou Yanjie
I couldn't find a proper coverletter for the series, please provide
that next time as it really helps review.
I'm sorry, maybe some problems with my git send-email cause cover
later not to be sent out, next time I will pay attention to this problem.
Additionally, it seems like
you forgot to change the prefix of the patches to "mmc: jz4740" (or at
least you chosed upper case letters), but I will take care of that
this time. So, I have applied the series for next, thanks!
I'm very sorry, I have misunderstood, before I thought jz4740 as a proper
noun needs to be capitalized, I will pay attention to this next time.
I also have a general question. Should we perhaps rename the driver
from jz4740_mmc.c to ingenic.c (and the file for the DT bindings, the
Kconfig, etc), as that seems like a more appropriate name? No?
I am very much in favor of this proposal. Now jz4740_mmc.c is not only used
for the JZ4740 processor, it is also used for JZ4725, JZ4760, JZ4770, JZ4780
and X1000, and now Ingenic's processor is no longer named after JZ47xx,
it is divided into three product lines: M, T, and X. It is easy to cause
some
misunderstandings by using jz4740_mmc.c. At the same time, I think that
some register names also need to be adjusted. For example, the STLPPL
register name has only appeared in JZ4730 and JZ4740, and this register
in all subsequent processors is called CTRL. This time I was confused by
the STLPPL when I added drivers for the JZ4760's and X1000's LPM.
I also can send a patch to rename it if you need.
Best regards!
Kind regards
Uffe
---
drivers/mmc/host/jz4740_mmc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 44a04fe..4cbe7fb 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -43,6 +43,7 @@
#define JZ_REG_MMC_RESP_FIFO 0x34
#define JZ_REG_MMC_RXFIFO 0x38
#define JZ_REG_MMC_TXFIFO 0x3C
+#define JZ_REG_MMC_LPM 0x40
#define JZ_REG_MMC_DMAC0x44
#define JZ_MMC_STRPCL_EXIT_MULTIPLE BIT(7)
@@ -102,6 +103,12 @@
#define JZ_MMC_DMAC_DMA_SEL BIT(1)
#define JZ_MMC_DMAC_DMA_EN BIT(0)
+#defineJZ_MMC_LPM_DRV_RISING BIT(31)
+#defineJZ_MMC_LPM_DRV_RISING_QTR_PHASE_DLY BIT(31)
+#defineJZ_MMC_LPM_DRV_RISING_1NS_DLY BIT(30)
+#defineJZ_MMC_LPM_SMP_RISING_QTR_OR_HALF_PHASE_DLY BIT(29)
+#defineJZ_MMC_LPM_LOW_POWER_MODE_EN BIT(0)
+
#define JZ_MMC_CLK_RATE 2400
enum jz4740_mmc_version {
@@ -860,6 +867,22 @@ static int jz4740_mmc_set_clock_rate(struct
jz4740_mmc_host *host, int rate)
}
writew(div, host->base + JZ_REG_MMC_CLKRT);
+
+ if (real_rate > 2500) {
+ if (host->version >= JZ_MMC_X1000) {
+ writel(JZ_MMC_LPM_DRV_RISING_QTR_PHASE_DLY |
+ JZ_MMC_LPM_SMP_RISING_QTR_OR_HALF_PHASE_DLY |
+ JZ_MMC_LPM_LOW_POWER_MODE_EN,
+ host->base + JZ_REG_MMC_LPM);
+ } else if (host->version >= JZ_MMC_JZ4760) {
+ writel(JZ_MMC_LPM_DRV_RISING |
+ JZ_MMC_LPM_LOW_POWER_MODE_EN,
+ host->base + JZ_REG_MMC_LPM);
+ } else if (host->version >= JZ_MMC_JZ4725B)
+ writel(JZ_MMC_LPM_LOW_POWER_MODE_EN,
+ host->base + JZ_REG_MMC_LPM);
+ }
+
return real_rate;
}
--
2.7.4
Re: [PATCH] mtd: rawnand: brcmnand: Fix sparse warning in has_flash_dma()
Hi Florian,
Florian Fainelli wrote on Fri, 18 Oct 2019
16:38:44 -0700:
> Sparse rightfully complained about has_flash_dma():
> +drivers/mtd/nand/brcmnand/brcmnand.c:951:40: warning: Using plain integer as
> NULL pointer [sparse]
I don't get why would sparse complain about this... Anyway I prefer
the !!() alternative if you don't mind. Otherwise the "!=
NULL" comparison feels wrong.
>
> Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB
> NAND controller")
> Signed-off-by: Florian Fainelli
> ---
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> index 15ef30b368a5..73f7a0945399 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -909,7 +909,7 @@ static inline void brcmnand_set_wp(struct
> brcmnand_controller *ctrl, bool en)
>
> static inline bool has_flash_dma(struct brcmnand_controller *ctrl)
> {
> - return ctrl->flash_dma_base;
> + return ctrl->flash_dma_base != NULL;
> }
>
> static inline void disable_ctrl_irqs(struct brcmnand_controller *ctrl)
Thanks,
Miquèl
Re: [PATCH 11/46] ARM: pxa: cmx270: use platform device for nand
Hi Arnd,
Arnd Bergmann wrote on Fri, 18 Oct 2019 17:41:26 +0200:
> The driver traditionally hardcodes the MMIO register address and
> the GPIO numbers from data defined in platform header files.
>
> To make it indepdendent of that, use a memory resource for the
> registers, and a gpio lookup table to replace the gpio numbers.
Looks good to me besides the typo s/indepdendent/independent/.
Acked-by: Miquel Raynal
>
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Marek Vasut
> Cc: Vignesh Raghavendra
> Cc: linux-...@lists.infradead.org
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-pxa/cm-x270.c| 25 +
> drivers/mtd/nand/raw/cmx270_nand.c | 88 +++---
> 2 files changed, 56 insertions(+), 57 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/cm-x270.c b/arch/arm/mach-pxa/cm-x270.c
> index 9baad11314f2..6d80400d8887 100644
> --- a/arch/arm/mach-pxa/cm-x270.c
> +++ b/arch/arm/mach-pxa/cm-x270.c
> @@ -40,6 +40,10 @@
> #define GPIO19_WLAN_STRAP(19)
> #define GPIO102_WLAN_RST (102)
>
> +/* NAND GPIOS */
> +#define GPIO_NAND_CS (11)
> +#define GPIO_NAND_RB (89)
> +
> static unsigned long cmx270_pin_config[] = {
> /* AC'97 */
> GPIO28_AC97_BITCLK,
> @@ -403,6 +407,26 @@ static void __init cmx270_init_spi(void)
> static inline void cmx270_init_spi(void) {}
> #endif
>
> +static struct gpiod_lookup_table cmx270_nand_gpio_table = {
> + .dev_id = "cmx270-nand",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", GPIO_NAND_CS, "cs", GPIO_ACTIVE_HIGH),
> + GPIO_LOOKUP("gpio-pxa", GPIO_NAND_RB, "rb", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> +static struct resource cmx270_nand_resources[] __initdata = {
> + DEFINE_RES_MEM(PXA_CS1_PHYS, 12),
> +};
> +
> +static void __init cmx270_init_nand(void)
> +{
> + platform_device_register_simple("cmx270-nand", -1,
> + cmx270_nand_resources, 1);
> + gpiod_add_lookup_table(_nand_gpio_table);
> +}
> +
> void __init cmx270_init(void)
> {
> pxa2xx_mfp_config(ARRAY_AND_SIZE(cmx270_pin_config));
> @@ -416,4 +440,5 @@ void __init cmx270_init(void)
> cmx270_init_ohci();
> cmx270_init_2700G();
> cmx270_init_spi();
> + cmx270_init_nand();
> }
> diff --git a/drivers/mtd/nand/raw/cmx270_nand.c
> b/drivers/mtd/nand/raw/cmx270_nand.c
> index 7af3d0bdcdb8..31cb20858c46 100644
> --- a/drivers/mtd/nand/raw/cmx270_nand.c
> +++ b/drivers/mtd/nand/raw/cmx270_nand.c
> @@ -15,18 +15,17 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> +#include
>
> #include
> #include
> #include
>
> -#include
> -
> -#define GPIO_NAND_CS (11)
> -#define GPIO_NAND_RB (89)
> +static struct gpio_desc *gpiod_nand_cs;
> +static struct gpio_desc *gpiod_nand_rb;
>
> /* MTD structure for CM-X270 board */
> static struct mtd_info *cmx270_nand_mtd;
> @@ -70,14 +69,14 @@ static void cmx270_read_buf(struct nand_chip *this,
> u_char *buf, int len)
>
> static inline void nand_cs_on(void)
> {
> - gpio_set_value(GPIO_NAND_CS, 0);
> + gpiod_set_value(gpiod_nand_cs, 0);
> }
>
> static void nand_cs_off(void)
> {
> dsb();
>
> - gpio_set_value(GPIO_NAND_CS, 1);
> + gpiod_set_value(gpiod_nand_cs, 1);
> }
>
> /*
> @@ -120,48 +119,41 @@ static int cmx270_device_ready(struct nand_chip *this)
> {
> dsb();
>
> - return (gpio_get_value(GPIO_NAND_RB));
> + return (gpiod_get_value(gpiod_nand_rb));
> }
>
> /*
> * Main initialization routine
> */
> -static int __init cmx270_init(void)
> +static int cmx270_probe(struct platform_device *pdev)
> {
> struct nand_chip *this;
> + struct device *dev = >dev;
> int ret;
>
> - if (!(machine_is_armcore() && cpu_is_pxa27x()))
> - return -ENODEV;
> -
> - ret = gpio_request(GPIO_NAND_CS, "NAND CS");
> + gpiod_nand_cs = devm_gpiod_get(dev, "cs", GPIOD_OUT_HIGH);
> + ret = PTR_ERR_OR_ZERO(gpiod_nand_cs);
> if (ret) {
> pr_warn("CM-X270: failed to request NAND CS gpio\n");
> return ret;
> }
>
> - gpio_direction_output(GPIO_NAND_CS, 1);
> -
> - ret = gpio_request(GPIO_NAND_RB, "NAND R/B");
> + gpiod_nand_rb = devm_gpiod_get(dev, "rb", GPIOD_IN);
> + ret = PTR_ERR_OR_ZERO(gpiod_nand_rb);
> if (ret) {
> pr_warn("CM-X270: failed to request NAND R/B gpio\n");
> - goto err_gpio_request;
> + return ret;
> }
>
> - gpio_direction_input(GPIO_NAND_RB);
> -
> /* Allocate memory for MTD device structure and private data */
> - this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> - if (!this) {
> - ret = -ENOMEM;
> - goto err_kzalloc;
> - }
> + this = devm_kzalloc(dev, sizeof(struct nand_chip), GFP_KERNEL);
> + if (!this)
> +
Re: [PATCH] lib/vdso: Use __arch_use_vsyscall() to indicate fallback
On Sat, 19 Oct 2019, Huacai Chen wrote: > On Fri, Oct 18, 2019 at 11:15 AM Andy Lutomirski wrote: > > > > On Thu, Oct 17, 2019 at 7:57 PM Huacai Chen wrote: > > > > > > In do_hres(), we currently use whether the return value of __arch_get_ > > > hw_counter() is negtive to indicate fallback, but this is not a good > > > idea. Because: > > > > > > 1, ARM64 returns ULL_MAX but MIPS returns 0 when clock_mode is invalid; > > > 2, For a 64bit counter, a "negtive" value of counter is actually valid. > > > > s/negtive/negative > > > > What's the actual bug? Is it that MIPS is returning 0 but the check > > is < 0? Sounds like MIPS should get fixed. > My original bug is what Vincenzo said, MIPS has a boot failure if no > valid clock_mode, and surely MIPS need to fix. However, when I try to > fix it, I found that clock_getres() has another problem, because > __cvdso_clock_getres_common() get vd[CS_HRES_COARSE].hrtimer_res, but > hrtimer_res is set in update_vdso_data() which relies on > __arch_use_vsyscall(). __arch_use_vsyscall() is a pointless exercise TBH. The VDSO data should be updated unconditionally so all the trivial interfaces like time() and getres() just work independently of the functions which depend on the underlying clocksource. This functions have a fallback operation already: Let __arch_get_hw_counter() return U64_MAX and the syscall fallback is invoked. __arch_use_vsyscall() should just be removed. Thanks, tglx
Re: [PATCH 00/46] ARM: pxa: towards multiplatform support
On Sat, Oct 19, 2019 at 3:03 AM Guenter Roeck wrote: > > On 10/18/19 8:40 AM, Arnd Bergmann wrote: > > > > Hi PXA maintainers, > > > > I'm in the process of getting the old ARM platforms to all build > > in a single kernel. The largest part of that work is changing all > > the device drivers to no longer require mach/*.h header files. > > > > This series does it for arch/pxa/. > > > > As with the omap1 and s3c24xx series I sent before, I don't > > expect this all to be correct in the first version, though > > a lot of the patches are fairly simple and I did exhaustive > > compile-time testing on them. > > > > Please test if you have the hardware, or review! > > > > I don't get very far. > > $ make-arm pxa_defconfig > arch/arm/Kconfig:677: can't open file "arch/arm/plat-pxa/Kconfig" > scripts/kconfig/Makefile:90: recipe for target 'pxa_defconfig' failed > make[1]: *** [pxa_defconfig] Error 1 > Makefile:567: recipe for target 'pxa_defconfig' failed > make: *** [pxa_defconfig] Error 2 > $ git describe > v5.4-rc3-52-gfcc4181cd625 > > Also: > > $ git grep plat-pxa > Documentation/arm/marvel.rst: arch/arm/plat-pxa > Documentation/arm/marvel.rst: arch/arm/plat-pxa > Documentation/arm/marvel.rst: directory. The plat-pxa/ would therefore > disappear. > arch/arm/Kconfig:source "arch/arm/plat-pxa/Kconfig" > arch/arm/mach-mmp/Makefile:ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := > -I$(srctree)/arch/arm/plat-pxa/include > drivers/gpio/gpio-pxa.c: * linux/arch/arm/plat-pxa/gpio.c > drivers/soc/pxa/mfp.c: * linux/arch/arm/plat-pxa/mfp.c > > Did I pick the wrong tree ? > > Guenter
clk: X1000: Add support for the X1000.
1.Add the clock bindings for X1000 from Ingenic. 2.Add support for the clocks provided by the CGU in the Ingenic X1000 SoC.
Re: (was Fair Trade O.S.) Varanger O-S
Lessened the licence strictness and updated this with a mixed licence point of view, as long as it respects the optimized commerciality of it. Politicans here want it aswell, and that is what I wanted since the 90s, and probably many here. (the whole spotify debate etc.) The Com directory giving full access to all commercial files, without unnecessary usernames, for easy finding ones interests aswell, making this more commercial than ever. :Com/Category/Subcategory/Country/12.500 km2 zone/Person/Groupings Optimized principles overall giving a good O.S. This is the sensible conclusion, and what should happen with Source Available type systems. Best Greetings, Ywe Cærlyn Lead & Philosophy Varanger O.S https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
[PATCH 1/2] dt-bindings: clock: Add X1000 bindings.
Add the clock bindings for the X1000 Soc from Ingenic. Signed-off-by: Zhou Yanjie --- .../devicetree/bindings/clock/ingenic,cgu.txt | 1 + include/dt-bindings/clock/x1000-cgu.h | 41 ++ 2 files changed, 42 insertions(+) create mode 100644 include/dt-bindings/clock/x1000-cgu.h diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.txt b/Documentation/devicetree/bindings/clock/ingenic,cgu.txt index ba5a442..75598e6 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.txt +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.txt @@ -11,6 +11,7 @@ Required properties: * ingenic,jz4725b-cgu * ingenic,jz4770-cgu * ingenic,jz4780-cgu + * ingenic,x1000-cgu - reg : The address & length of the CGU registers. - clocks : List of phandle & clock specifiers for clocks external to the CGU. Two such external clocks should be specified - first the external crystal diff --git a/include/dt-bindings/clock/x1000-cgu.h b/include/dt-bindings/clock/x1000-cgu.h new file mode 100644 index ..f0a1496 --- /dev/null +++ b/include/dt-bindings/clock/x1000-cgu.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * This header provides clock numbers for the ingenic,x1000-cgu DT binding. + * + * They are roughly ordered as: + * - external clocks + * - PLLs + * - muxes/dividers in the order they appear in the x1000 programmers manual + * - gates in order of their bit in the CLKGR* registers + */ + +#ifndef __DT_BINDINGS_CLOCK_X1000_CGU_H__ +#define __DT_BINDINGS_CLOCK_X1000_CGU_H__ + +#define X1000_CLK_EXCLK0 +#define X1000_CLK_RTCLK1 +#define X1000_CLK_APLL 2 +#define X1000_CLK_MPLL 3 +#define X1000_CLK_SCLKA4 +#define X1000_CLK_CPUMUX 5 +#define X1000_CLK_CPU 6 +#define X1000_CLK_L2CACHE 7 +#define X1000_CLK_AHB0 8 +#define X1000_CLK_AHB2PMUX 9 +#define X1000_CLK_AHB2 10 +#define X1000_CLK_PCLK 11 +#define X1000_CLK_DDR 12 +#define X1000_CLK_MAC 13 +#define X1000_CLK_MSCMUX 14 +#define X1000_CLK_MSC0 15 +#define X1000_CLK_MSC1 16 +#define X1000_CLK_SSIPLL 17 +#define X1000_CLK_SSIMUX 18 +#define X1000_CLK_SFC 19 +#define X1000_CLK_UART020 +#define X1000_CLK_UART121 +#define X1000_CLK_UART222 +#define X1000_CLK_SSI 23 +#define X1000_CLK_PDMA 24 + +#endif /* __DT_BINDINGS_CLOCK_X1000_CGU_H__ */ -- 2.7.4
Re: [PATCH 00/46] ARM: pxa: towards multiplatform support
On Sat, Oct 19, 2019 at 3:03 AM Guenter Roeck wrote: > On 10/18/19 8:40 AM, Arnd Bergmann wrote: > > I don't get very far. > > $ make-arm pxa_defconfig > arch/arm/Kconfig:677: can't open file "arch/arm/plat-pxa/Kconfig" > scripts/kconfig/Makefile:90: recipe for target 'pxa_defconfig' failed > > Did I pick the wrong tree ? It seems that one line got lost in a rebase and ended up in a different patch that was not part of the series. I updated the git tree now. Arnd
[PATCH 2/2] clk: Ingenic: Add CGU driver for X1000.
Add support for the clocks provided by the CGU in the Ingenic X1000
SoC, making use of the cgu code to do the heavy lifting.
Signed-off-by: Zhou Yanjie
---
drivers/clk/ingenic/Kconfig | 10 ++
drivers/clk/ingenic/Makefile| 1 +
drivers/clk/ingenic/x1000-cgu.c | 253
3 files changed, 264 insertions(+)
create mode 100644 drivers/clk/ingenic/x1000-cgu.c
diff --git a/drivers/clk/ingenic/Kconfig b/drivers/clk/ingenic/Kconfig
index fe8db93..2aebf0d 100644
--- a/drivers/clk/ingenic/Kconfig
+++ b/drivers/clk/ingenic/Kconfig
@@ -45,4 +45,14 @@ config INGENIC_CGU_JZ4780
If building for a JZ4780 SoC, you want to say Y here.
+config INGENIC_CGU_X1000
+ bool "Ingenic X1000 CGU driver"
+ default MACH_X1000
+ select INGENIC_CGU_COMMON
+ help
+ Support the clocks provided by the CGU hardware on Ingenic X1000
+ and compatible SoCs.
+
+ If building for a X1000 SoC, you want to say Y here.
+
endmenu
diff --git a/drivers/clk/ingenic/Makefile b/drivers/clk/ingenic/Makefile
index 250570a..0f0e784 100644
--- a/drivers/clk/ingenic/Makefile
+++ b/drivers/clk/ingenic/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_INGENIC_CGU_JZ4740)+= jz4740-cgu.o
obj-$(CONFIG_INGENIC_CGU_JZ4725B) += jz4725b-cgu.o
obj-$(CONFIG_INGENIC_CGU_JZ4770) += jz4770-cgu.o
obj-$(CONFIG_INGENIC_CGU_JZ4780) += jz4780-cgu.o
+obj-$(CONFIG_INGENIC_CGU_X1000)+= x1000-cgu.o
diff --git a/drivers/clk/ingenic/x1000-cgu.c b/drivers/clk/ingenic/x1000-cgu.c
new file mode 100644
index ..c9d744c
--- /dev/null
+++ b/drivers/clk/ingenic/x1000-cgu.c
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * X1000 SoC CGU driver
+ * Copyright (c) 2019 Zhou Yanjie
+ */
+
+#include
+#include
+#include
+#include
+#include "cgu.h"
+
+/* CGU register offsets */
+#define CGU_REG_CPCCR 0x00
+#define CGU_REG_APLL 0x10
+#define CGU_REG_MPLL 0x14
+#define CGU_REG_CLKGR 0x20
+#define CGU_REG_OPCR 0x24
+#define CGU_REG_DDRCDR 0x2c
+#define CGU_REG_MACPHYCDR 0x54
+#define CGU_REG_I2SCDR 0x60
+#define CGU_REG_LPCDR 0x64
+#define CGU_REG_MSC0CDR0x68
+#define CGU_REG_I2SCDR10x70
+#define CGU_REG_SSICDR 0x74
+#define CGU_REG_CIMCDR 0x7c
+#define CGU_REG_PCMCDR 0x84
+#define CGU_REG_MSC1CDR0xa4
+#define CGU_REG_CMP_INTR 0xb0
+#define CGU_REG_CMP_INTRE 0xb4
+#define CGU_REG_DRCG 0xd0
+#define CGU_REG_CLOCKSTATUS0xd4
+#define CGU_REG_PCMCDR10xe0
+#define CGU_REG_MACPHYC0xe8
+
+/* bits within the OPCR register */
+#define OPCR_SPENDN0 (1 << 7)
+#define OPCR_SPENDN1 (1 << 6)
+
+static struct ingenic_cgu *cgu;
+
+static const s8 pll_od_encoding[8] = {
+ 0x0, 0x1, -1, 0x2, -1, -1, -1, 0x3,
+};
+
+static const struct ingenic_cgu_clk_info x1000_cgu_clocks[] = {
+
+ /* External clocks */
+
+ [X1000_CLK_EXCLK] = { "ext", CGU_CLK_EXT },
+ [X1000_CLK_RTCLK] = { "rtc", CGU_CLK_EXT },
+
+ /* PLLs */
+
+ [X1000_CLK_APLL] = {
+ "apll", CGU_CLK_PLL,
+ .parents = { X1000_CLK_EXCLK, -1, -1, -1 },
+ .pll = {
+ .reg = CGU_REG_APLL,
+ .m_shift = 24,
+ .m_bits = 7,
+ .m_offset = 1,
+ .n_shift = 18,
+ .n_bits = 5,
+ .n_offset = 1,
+ .od_shift = 16,
+ .od_bits = 2,
+ .od_max = 8,
+ .od_encoding = pll_od_encoding,
+ .bypass_bit = 9,
+ .enable_bit = 8,
+ .stable_bit = 10,
+ },
+ },
+
+ [X1000_CLK_MPLL] = {
+ "mpll", CGU_CLK_PLL,
+ .parents = { X1000_CLK_EXCLK, -1, -1, -1 },
+ .pll = {
+ .reg = CGU_REG_MPLL,
+ .m_shift = 24,
+ .m_bits = 7,
+ .m_offset = 1,
+ .n_shift = 18,
+ .n_bits = 5,
+ .n_offset = 1,
+ .od_shift = 16,
+ .od_bits = 2,
+ .od_max = 8,
+ .od_encoding = pll_od_encoding,
+ .bypass_bit = 6,
+ .enable_bit = 7,
+ .stable_bit = 0,
+ },
+ },
+
+ /* Muxes & dividers */
+
+ [X1000_CLK_SCLKA] = {
+ "sclk_a", CGU_CLK_MUX,
+ .parents = { -1, X1000_CLK_EXCLK, X1000_CLK_APLL, -1 },
+ .mux = { CGU_REG_CPCCR, 30, 2 },
+ },
+
+ [X1000_CLK_CPUMUX] = {
+ "cpu_mux", CGU_CLK_MUX,
+
Re: [PATCH] random: make try_to_generate_entropy() more robust
On Sat, 19 Oct 2019, Ingo Molnar wrote: > * Linus Torvalds wrote: > > On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel wrote: > > But from a softirq or threaded irq context that 'interrupted' regs > context might potentially be NULL. > > NULL isn't a good thing to pass to mix_pool_bytes(), because the first > use of 'in' (='bytes') in _mix_pool_bytes() is a dereference without a > NULL check AFAICS: > > w = rol32(*bytes++, input_rotate); > > So at minimum I'd only mix this entropy into the pool if 'regs' is > non-zero. This would automatically do the right thing and not crash the > kernel on weird irq execution models such as threaded-only or -rt. You don't even need threaded-only or RT. The timer is fired in the softirq which very well can happen from thread context in mainline. Thanks, tglx
Re: [PATCH] power: supply: rt5033_battery: Fix the usage of potential uninitialized variable
Hi,
On Tue, Oct 15, 2019 at 09:57:37AM -0700, Yizhuo wrote:
> In function rt5033_battery_get_present(), variable "val" could be
> uninitialized if regmap_read() returns -EINVAL. However, "val" is
> used to decide the return value, which is potentially unsafe.
>
> Signed-off-by: Yizhuo
> ---
The patch looks good, but your name in author and Signed-off-by line
look incomplete (only one name). Please resend with full name as
patch author and Signed-off-by.
Thanks,
-- Sebastian
> drivers/power/supply/rt5033_battery.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/rt5033_battery.c
> b/drivers/power/supply/rt5033_battery.c
> index d8667a9fc49b..6a617531698c 100644
> --- a/drivers/power/supply/rt5033_battery.c
> +++ b/drivers/power/supply/rt5033_battery.c
> @@ -26,8 +26,14 @@ static int rt5033_battery_get_present(struct i2c_client
> *client)
> {
> struct rt5033_battery *battery = i2c_get_clientdata(client);
> u32 val;
> + int ret;
>
> - regmap_read(battery->regmap, RT5033_FUEL_REG_CONFIG_L, );
> + ret = regmap_read(battery->regmap, RT5033_FUEL_REG_CONFIG_L, );
> + if (ret) {
> + dev_err(>dev,
> + "Failed to read RT5033_FUEL_REG_CONFIG_L.\n");
> + return false;
> + }
>
> return (val & RT5033_FUEL_BAT_PRESENT) ? true : false;
> }
> --
> 2.17.1
>
signature.asc
Description: PGP signature
Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500
On Sat, 2019-10-19 at 01:31 +, Vijay Khemka wrote: > Thanks Ben, > I will try to add some trace and test whatever possible and test it. > As we > don't have tcpdump into our image and I have limited understanding of > networking stack so if you get some time to verify ipv6, it will be > really > helpful. > You only need tcpdump (or wireshark) on the *other end* of the link, could even be your laptop, to look at what the generated frames look like and compare with your traces. Cheers, Ben.
Re: [PATCH 00/46] ARM: pxa: towards multiplatform support
Arnd Bergmann writes: > On Fri, Oct 18, 2019 at 9:17 PM Arnd Bergmann wrote: >> On Fri, Oct 18, 2019 at 9:04 PM Robert Jarzmik >> wrote: >> > Arnd Bergmann writes: >> > >> > > Hi PXA maintainers, >> > > >> > > I'm in the process of getting the old ARM platforms to all build >> > > in a single kernel. The largest part of that work is changing all >> > > the device drivers to no longer require mach/*.h header files. >> > > >> > > This series does it for arch/pxa/. >> > > >> > > As with the omap1 and s3c24xx series I sent before, I don't >> > > expect this all to be correct in the first version, though >> > > a lot of the patches are fairly simple and I did exhaustive >> > > compile-time testing on them. >> > > >> > > Please test if you have the hardware, or review! >> > >> > Hi Arnd, >> > >> > Would you have a git tree I can pull from ? >> > That would make my life easier than applying manually 46 patches... >> >> I've now pushed it to >> >> git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git >> pxa-multiplatform > > Sorry for the duplication, I had some problems with email configuration > so my reply got rejected, let's see if it goes through this time. I have it now, thanks, I'll test and review as soon as I can. Cheers. -- Robert
Re: [PATCH] random: make try_to_generate_entropy() more robust
On Fri, 18 Oct 2019, Linus Torvalds wrote:
> On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel wrote:
> >
> > We can generate entropy on almost any CPU, even if it doesn't provide a
> > high-resolution timer for random_get_entropy(). As long as the CPU is
> > not idle, it changed the register file every few cycles. As long as the
> > ALU isn't fully synchronized with the timer, the drift between the
> > register file and the timer is enough to generate entropy from.
>
> > static void entropy_timer(struct timer_list *t)
> > {
> > + struct pt_regs *regs = get_irq_regs();
> > +
> > + /*
> > + * Even if we don't have a high-resolution timer in our system,
> > + * the register file itself is a high-resolution timer. It
> > + * isn't monotonic or particularly useful to read the current
> > + * time. But it changes with every retired instruction, which
> > + * is enough to generate entropy from.
> > + */
> > + mix_pool_bytes(_pool, regs, sizeof(*regs));
>
> Ok, so I still like this conceptually, but I'm not entirely sure that
> get_irq_regs() works reliably in a timer. It's done from softirq
> TIMER_SOFTIRQ context, so not necessarily _in_ an interrupt.
>
> Now, admittedly this code doesn't really need "reliably". The odd
> occasional hickup would arguably just add more noise. And I think the
> code works fine. get_irq_regs() will return a pointer to the last
> interrupt or exception frame on the current CPU, and I guess it's all
> fine. But let's bring in Thomas, who was not only active in the
> randomness discussion, but might also have stronger opinions on this
> get_irq_regs() usage.
>
> Thomas, opinions? Using the register state (while we're doing the
> whole entropy load with scheduling etc) looks like a good source of
> high-entropy data outside of just the TSC, so it does seem like a very
> valid model. But I want to run it past more people first, and Thomas
> is the obvious victim^Wchoice.
The idea is good, but as Ingo pointed out this needs very careful checking
of 'regs'. get_irq_regs() is really only valid from interrupt context up to
the point where the old irq regs (default NULL) are restored, i.e. after
irq_exit() from where softirqs are invoked.
One slightly related thing I was looking into is that the mixing of
interrupt entropy is always done from hard interrupt context. That has a
few issues:
1) It's pretty visible in profiles for high frequency interrupt
scenarios.
2) The regs content can be pretty boring non-deterministic when the
interrupt hits idle.
Not an issue in the try_to_generate_entropy() case probably, but
that still needs some careful investigation.
For #1 I was looking into a trivial storage model with a per cpu ring
buffer, where each entry contains the entropy data of one interrupt and let
some thread or whatever handle the mixing later.
That would allow to filter out 'constant' data (#) but it would also give
Joerns approach a way to get to some 'random' register content independent
of the context in which the timer softirq is running in.
Thanks,
tglx
Re: [PATCH v2] rtlwifi: Fix potential overflow on P2P code
Laura Abbott writes:
> Nicolas Waisman noticed that even though noa_len is checked for
> a compatible length it's still possible to overrun the buffers
> of p2pinfo since there's no check on the upper bound of noa_num.
> Bound noa_num against P2P_MAX_NOA_NUM.
>
> Reported-by: Nicolas Waisman
> Signed-off-by: Laura Abbott
> ---
> v2: Use P2P_MAX_NOA_NUM instead of erroring out.
> ---
> drivers/net/wireless/realtek/rtlwifi/ps.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c
> b/drivers/net/wireless/realtek/rtlwifi/ps.c
> index 70f04c2f5b17..fff8dda14023 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> @@ -754,6 +754,9 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void
> *data,
> return;
> } else {
> noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM)
> + noa_num = P2P_MAX_NOA_NUM;
> +
> }
> noa_index = ie[3];
> if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==
> @@ -848,6 +851,9 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw,
> void *data,
> return;
> } else {
> noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM)
> + noa_num = P2P_MAX_NOA_NUM;
IMHO using min() would be cleaner, but I'm fine with this as well. Up to
you.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rtlwifi: Fix potential overflow on P2P code
Pkshih writes: > On Fri, 2019-10-18 at 07:43 -0400, Laura Abbott wrote: >> Nicolas Waisman noticed that even though noa_len is checked for >> a compatible length it's still possible to overrun the buffers >> of p2pinfo since there's no check on the upper bound of noa_num. >> Bound noa_num against P2P_MAX_NOA_NUM. >> >> Reported-by: Nicolas Waisman >> Signed-off-by: Laura Abbott > > Acked-by: Ping-Ke Shih > and Please CC to stable > Cc: Stable # 4.4+ > > --- > > Hi Kalle, > > This bug was existing since v3.10, and directory of wireless drivers were > moved at v4.4. Do I need send another patch to fix this issue for longterm > kernel v3.16.75? Yeah, I think you need to send a separate patch to the stable list (after this commit is in Linus' tree). -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v8 0/5] arm64: ftrace with regs
Hi Mark! On Fri, 18 Oct 2019 18:41:02 +0100 Mark Rutland wrote: > In the process of reworking this I spotted some issues that will get > in the way of livepatching. Notably: > > * When modules can be loaded far away from the kernel, we'll > potentially need a PLT for each function within a module, if each can > be patched to a unique function. Currently we have a fixed number, > which is only sufficient for the two ftrace entry trampolines. > > IIUC, the new code being patched in is itself a module, in which > case we'd need a PLT for each function in the main kernel image. When no live patching is involved, obviously all cases need to have been handled so far. And when a live patching module comes in, there are calls in and out of the new patch code: Calls going into the live patch are not aware of this. They are caught by an active ftrace intercept, and the actual call into the LP module is done in klp_arch_set_pc, by manipulating the intercept (call site) return address (in case thread lives in the "new world", for completeness' sake). This is an unsigned long write in C. All calls going _out_ from the KLP module are newly generated, as part of the KLP module building process, and are thus aware of them being "extern" -- a PLT entry should be generated and accounted for in the KLP module. > We have a few options here, e.g. changing which memory size model we > use, or reserving space for a PLT before each function using > -f patchable-function-entry=N,M. Nonetheless I'm happy I once added the ,M option here. You never know :) > * There are windows where backtracing will miss the callsite's caller, > as its address is not live in the LR or existing chain of frame > records. Thus we cannot claim to have a reliable stacktrace. > > I suspect we'll have to teach the stacktrace code to handle this as > a special-case. Yes, that's where I had to step back. The unwinder needs to stop where the chain is even questionable. In _all_ cases. Missing only one race condition means a lurking inconsistency. OTOH it's not a problem to report "not reliable" when in doubt; the thread in question will then get woken up and unwind itself. It is only an optimisation to let all kernel threads which are guaranteed to not contain any patched functions sleep on. > I'll try to write these up, as similar probably applies to other > architectures with a link register. I thought I'd quickly give you my feedback upfront here. Torsten
Re: [PATCH 0/9] OpenPandora: make wl1251 connected to mmc3 sdio port of OpenPandora work again
"H. Nikolaus Schaller" writes:
> Here we have a set of scattered patches to make the OpenPandora WiFi work
> again.
>
> v4.7 did break the pdata-quirks which made the mmc3 interface
> fail completely, because some code now assumes device tree
> based instantiation.
>
> Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting
> DMA channel")
>
> v4.11 did break the sdio qirks for wl1251 which made the driver no longer
> load, although the device was found as an sdio client.
>
> Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
>
> To solve these issues:
> * we convert mmc3 and wl1251 initialization from pdata-quirks
> to device tree
> * we make the wl1251 driver read properties from device tree
> * we fix the mmc core vendor ids and quirks
> * we fix the wl1251 (and wl1271) driver to use only vendor ids
> from header file instead of (potentially conflicting) local
> definitions
>
>
> H. Nikolaus Schaller (9):
> Documentation: dt: wireless: update wl1251 for sdio
> net: wireless: ti: wl1251 add device tree support
> DTS: ARM: pandora-common: define wl1251 as child node of mmc3
> mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid
> of pandora_wl1251_init_card
> omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251
> mmc: sdio: fix wl1251 vendor id
> mmc: core: fix wl1251 sdio quirks
> net: wireless: ti: wl1251 use new SDIO_VENDOR_ID_TI_WL1251 definition
> net: wireless: ti: remove local VENDOR_ID and DEVICE_ID definitions
I didn't get patches 3-7 so I don't know what they have, but what's the
plan how these should be applied? Normally wl1251 patches go via
wireless-drivers-next but are you planning something else?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
TRADING ACCOUNT
Dear sir , I am M HUREL Vincent , purchasing and sales manager of ABB FRANCE . Our Company specialised in Supplying computer hardware and Electronic . We want to extend our supplier list because of concurrency in prices on the international market . We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices .we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? Could you inform us of the steps to follow to open an account with you ? Waiting your feedback Cordially M HUREL Vincent ABB FRANCE 5 BOULEVARD D OSNY 95800 Cergy REG N° 335 146 312 VAT N° FR 95 335146312 TEL +33183777972 TEL D : +33756981277 FAX +33143381547 https://new.abb.com
Re: [PATCH v6 05/10] KVM: arm64: Support stolen time reporting via shared structure
On Fri, 11 Oct 2019 13:59:25 +0100,
Steven Price wrote:
>
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> User space allocates memory which is placed at an IPA also chosen by user
> space. The hypervisor then updates the shared structure using
> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
> reporting the stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price
> ---
> arch/arm/include/asm/kvm_host.h | 20 +++
> arch/arm64/include/asm/kvm_host.h | 21 +++-
> arch/arm64/kvm/Kconfig| 1 +
> include/linux/kvm_types.h | 2 ++
> virt/kvm/arm/arm.c| 11 ++
> virt/kvm/arm/hypercalls.c | 3 ++
> virt/kvm/arm/pvtime.c | 56 +++
> 7 files changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 5a0c3569ebde..5c401482d62d 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -39,6 +39,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -329,6 +330,25 @@ static inline long kvm_hypercall_pv_features(struct
> kvm_vcpu *vcpu)
> return SMCCC_RET_NOT_SUPPORTED;
> }
>
> +static inline long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + return SMCCC_RET_NOT_SUPPORTED;
> +}
> +
> +static inline int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline void kvm_arm_pvtime_vcpu_init(struct kvm_vcpu_arch *vcpu_arch)
> +{
> +}
> +
> +static inline bool kvm_arm_is_pvtime_enabled(struct kvm_vcpu_arch *vcpu_arch)
> +{
> + return false;
> +}
> +
> void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
> struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> diff --git a/arch/arm64/include/asm/kvm_host.h
> b/arch/arm64/include/asm/kvm_host.h
> index 93b46d9526d0..1697e63f6dd8 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -44,6 +44,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -338,8 +339,14 @@ struct kvm_vcpu_arch {
> /* True when deferrable sysregs are loaded on the physical CPU,
>* see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> bool sysregs_loaded_on_cpu;
> -};
>
> + /* Guest PV state */
> + struct {
> + u64 steal;
> + u64 last_steal;
> + gpa_t base;
> + } steal;
> +};
nit: Please keep an empty line at the end of the structure.
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> @@ -479,6 +486,18 @@ int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> +long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
> +
> +static inline void kvm_arm_pvtime_vcpu_init(struct kvm_vcpu_arch *vcpu_arch)
> +{
> + vcpu_arch->steal.base = GPA_INVALID;
> +}
> +
> +static inline bool kvm_arm_is_pvtime_enabled(struct kvm_vcpu_arch *vcpu_arch)
> +{
> + return (vcpu_arch->steal.base != GPA_INVALID);
> +}
>
> void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
>
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a67121d419a2..d8b88e40d223 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> select HAVE_KVM_VCPU_RUN_PID_CHANGE
> + select SCHEDSTATS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index bde5374ae021..1c88e69db3d9 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
[5.3.*] nvme issue
Linux-guru's, When I boot this workstation, the nvme disks appear in /dev/ without their partitions. fdisk shows there are partitions but cannot write a new partitions table, mentions a busy disk. These processes are busy with the nvme disks: root 236 2 0 13:08 ?00:00:00 [nvme-wq] root 237 2 0 13:08 ?00:00:00 [nvme-reset-wq] root 238 2 0 13:08 ?00:00:00 [nvme-delete-wq] If I kill these, (re)write a partition table the partitions appear in /dev/ and can be used. How do I prevent this situation from occurring? I want my partitions visible. (fedora 30, kernel 5.3.7, etc, etc) Also: a `make install` of the kernel does not put the current /etc/crypttab in the ramdisk. How to force this so that the crypttab is updated? Kind reghards, Udo
Re: [PATCH 0/9] OpenPandora: make wl1251 connected to mmc3 sdio port of OpenPandora work again
Hi,
> Am 19.10.2019 um 13:06 schrieb Kalle Valo :
>
> "H. Nikolaus Schaller" writes:
>
>> Here we have a set of scattered patches to make the OpenPandora WiFi work
>> again.
>>
>> v4.7 did break the pdata-quirks which made the mmc3 interface
>> fail completely, because some code now assumes device tree
>> based instantiation.
>>
>> Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting
>> DMA channel")
>>
>> v4.11 did break the sdio qirks for wl1251 which made the driver no longer
>> load, although the device was found as an sdio client.
>>
>> Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
>>
>> To solve these issues:
>> * we convert mmc3 and wl1251 initialization from pdata-quirks
>> to device tree
>> * we make the wl1251 driver read properties from device tree
>> * we fix the mmc core vendor ids and quirks
>> * we fix the wl1251 (and wl1271) driver to use only vendor ids
>> from header file instead of (potentially conflicting) local
>> definitions
>>
>>
>> H. Nikolaus Schaller (9):
>> Documentation: dt: wireless: update wl1251 for sdio
>> net: wireless: ti: wl1251 add device tree support
>> DTS: ARM: pandora-common: define wl1251 as child node of mmc3
>> mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid
>>of pandora_wl1251_init_card
>> omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251
>> mmc: sdio: fix wl1251 vendor id
>> mmc: core: fix wl1251 sdio quirks
>> net: wireless: ti: wl1251 use new SDIO_VENDOR_ID_TI_WL1251 definition
>> net: wireless: ti: remove local VENDOR_ID and DEVICE_ID definitions
>
> I didn't get patches 3-7
oh sorry. I don't know why.
Here they are all: https://patchwork.kernel.org/cover/11199599/
> so I don't know what they have, but what's the
> plan how these should be applied? Normally wl1251 patches go via
> wireless-drivers-next but are you planning something else?
Well, I have no plan for that except that all should end up fixed in mainline
and stable.
The issue is that multiple subsystems are involved (net/wireless, mmc and
arm/omap)
and all patches should be ideally be applied in combination.
BR and thanks,
Nikolaus
Re: [PATCH 0/9] OpenPandora: make wl1251 connected to mmc3 sdio port of OpenPandora work again
"H. Nikolaus Schaller" writes:
> Hi,
>
>> Am 19.10.2019 um 13:06 schrieb Kalle Valo :
>>
>> "H. Nikolaus Schaller" writes:
>>
>>> Here we have a set of scattered patches to make the OpenPandora WiFi work
>>> again.
>>>
>>> v4.7 did break the pdata-quirks which made the mmc3 interface
>>> fail completely, because some code now assumes device tree
>>> based instantiation.
>>>
>>> Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for
>>> requesting DMA channel")
>>>
>>> v4.11 did break the sdio qirks for wl1251 which made the driver no longer
>>> load, although the device was found as an sdio client.
>>>
>>> Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
>>>
>>> To solve these issues:
>>> * we convert mmc3 and wl1251 initialization from pdata-quirks
>>> to device tree
>>> * we make the wl1251 driver read properties from device tree
>>> * we fix the mmc core vendor ids and quirks
>>> * we fix the wl1251 (and wl1271) driver to use only vendor ids
>>> from header file instead of (potentially conflicting) local
>>> definitions
>>>
>>>
>>> H. Nikolaus Schaller (9):
>>> Documentation: dt: wireless: update wl1251 for sdio
>>> net: wireless: ti: wl1251 add device tree support
>>> DTS: ARM: pandora-common: define wl1251 as child node of mmc3
>>> mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid
>>>of pandora_wl1251_init_card
>>> omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251
>>> mmc: sdio: fix wl1251 vendor id
>>> mmc: core: fix wl1251 sdio quirks
>>> net: wireless: ti: wl1251 use new SDIO_VENDOR_ID_TI_WL1251 definition
>>> net: wireless: ti: remove local VENDOR_ID and DEVICE_ID definitions
>>
>> I didn't get patches 3-7
>
> oh sorry. I don't know why.
>
> Here they are all: https://patchwork.kernel.org/cover/11199599/
Thanks.
>> so I don't know what they have, but what's the
>> plan how these should be applied? Normally wl1251 patches go via
>> wireless-drivers-next but are you planning something else?
>
> Well, I have no plan for that except that all should end up fixed in mainline
> and stable.
>
> The issue is that multiple subsystems are involved (net/wireless, mmc and
> arm/omap)
> and all patches should be ideally be applied in combination.
Ok, I then assume someone else is going to handle these, wl1251 rarely
has any changes so the chance of conflicts is small anyway, and I'll
drop the wl1251 patches from my patchwork.
For wl1251 patches 1, 2, 8 and 9:
Acked-by: Kalle Valo
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Your Immediate Attention Is Required.
Zenith Bank of Nigeria Plc Headquarters Plot 84, Ajose Adeogun Street Victoria Island Lagos, Nigeria ISIN CODE : NGZENBNK9 Dear Sir, I am Mr.Uche Akpu, The Director foreign Operations Zenith Bank of Nigeria Plc. We have worked out your outstanding payment of $2.5M approved by the Central Bank of Nigeria unfortunately Mr.David Kimberly. of 1301 ST.Anthony Lane Peteiluma CA, USA is claiming that you are lying in your sick bed and about dying. Is it true that you are sick?Please,do confirm if the payment will be released to him as your next of kin as he claimed. I shall feed you with further modalities regarding the payment of your fund as soon as I hear from you on email: directorzenith2...@gmail.com .Urgently Waiting for your confirmation. Yrs,Faithfully, Mr.Uche Akpu.
[PATCHv2 1/3] soc: qcom: llcc: Add configuration data for SC7180
From: Vivek Gautam
Add LLCC configuration data for SC7180 SoC which controls
LLCC behaviour.
Signed-off-by: Vivek Gautam
Signed-off-by: Sai Prakash Ranjan
---
drivers/soc/qcom/llcc-qcom.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
index 4bd982a294ce..429b5a60a1ba 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -91,7 +91,14 @@ struct qcom_llcc_config {
int size;
};
-static struct llcc_slice_config sdm845_data[] = {
+static const struct llcc_slice_config sc7180_data[] = {
+ { LLCC_CPUSS,1, 256, 1, 0, 0xf, 0x0, 0, 0, 0, 1, 1 },
+ { LLCC_MDM, 8, 128, 1, 0, 0xf, 0x0, 0, 0, 0, 1, 0 },
+ { LLCC_GPUHTW, 11, 128, 1, 0, 0xf, 0x0, 0, 0, 0, 1, 0 },
+ { LLCC_GPU, 12, 128, 1, 0, 0xf, 0x0, 0, 0, 0, 1, 0 },
+};
+
+static const struct llcc_slice_config sdm845_data[] = {
{ LLCC_CPUSS,1, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 1 },
{ LLCC_VIDSC0, 2, 512, 2, 1, 0x0, 0x0f0, 0, 0, 1, 1, 0 },
{ LLCC_VIDSC1, 3, 512, 2, 1, 0x0, 0x0f0, 0, 0, 1, 1, 0 },
@@ -112,6 +119,11 @@ static struct llcc_slice_config sdm845_data[] = {
{ LLCC_AUDHW,22, 1024, 1, 1, 0xffc, 0x2, 0, 0, 1, 1, 0 },
};
+static const struct qcom_llcc_config sc7180_cfg = {
+ .sct_data = sc7180_data,
+ .size = ARRAY_SIZE(sc7180_data),
+};
+
static const struct qcom_llcc_config sdm845_cfg = {
.sct_data = sdm845_data,
.size = ARRAY_SIZE(sdm845_data),
@@ -485,6 +497,7 @@ static int qcom_llcc_probe(struct platform_device *pdev)
}
static const struct of_device_id qcom_llcc_of_match[] = {
+ { .compatible = "qcom,sc7180-llcc", .data = _cfg },
{ .compatible = "qcom,sdm845-llcc", .data = _cfg },
{ }
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCHv2 0/3] Add LLCC support for SC7180 SoC
LLCC behaviour is controlled by the configuration data set in the llcc-qcom driver, add the same for SC7180 SoC. Also convert the existing bindings to json-schema and add the compatible for SC7180 SoC. v2: * Convert bindings to YAML and add compatible for SC7180 * Address Stephen's comments on const Sai Prakash Ranjan (2): dt-bindings: msm: Convert LLCC bindings to YAML dt-bindings: msm: Add LLCC for SC7180 Vivek Gautam (1): soc: qcom: llcc: Add configuration data for SC7180 .../devicetree/bindings/arm/msm/qcom,llcc.txt | 41 -- .../bindings/arm/msm/qcom,llcc.yaml | 55 +++ drivers/soc/qcom/llcc-qcom.c | 15 - 3 files changed, 69 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCHv2 2/3] dt-bindings: msm: Convert LLCC bindings to YAML
Convert LLCC bindings to DT schema format using json-schema.
Signed-off-by: Sai Prakash Ranjan
---
.../devicetree/bindings/arm/msm/qcom,llcc.txt | 41 --
.../bindings/arm/msm/qcom,llcc.yaml | 54 +++
2 files changed, 54 insertions(+), 41 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
deleted file mode 100644
index eaee06b2d8f2..
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-== Introduction==
-
-LLCC (Last Level Cache Controller) provides last level of cache memory in SOC,
-that can be shared by multiple clients. Clients here are different cores in the
-SOC, the idea is to minimize the local caches at the clients and migrate to
-common pool of memory. Cache memory is divided into partitions called slices
-which are assigned to clients. Clients can query the slice details, activate
-and deactivate them.
-
-Properties:
-- compatible:
- Usage: required
- Value type:
- Definition: must be "qcom,sdm845-llcc"
-
-- reg:
- Usage: required
- Value Type:
- Definition: The first element specifies the llcc base start address and
- the size of the register region. The second element
specifies
- the llcc broadcast base address and size of the register
region.
-
-- reg-names:
-Usage: required
-Value Type:
-Definition: Register region names. Must be "llcc_base",
"llcc_broadcast_base".
-
-- interrupts:
- Usage: required
- Definition: The interrupt is associated with the llcc edac device.
- It's used for llcc cache single and double bit error
detection
- and reporting.
-
-Example:
-
- cache-controller@110 {
- compatible = "qcom,sdm845-llcc";
- reg = <0x110 0x20>, <0x130 0x5> ;
- reg-names = "llcc_base", "llcc_broadcast_base";
- interrupts = ;
- };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
new file mode 100644
index ..5ac90d101807
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/msm/qcom,llcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Last Level Cache Controller
+
+maintainers:
+ - Rishabh Bhatnagar
+ - Sai Prakash Ranjan
+
+description: |
+ LLCC (Last Level Cache Controller) provides last level of cache memory in
SoC,
+ that can be shared by multiple clients. Clients here are different cores in
the
+ SoC, the idea is to minimize the local caches at the clients and migrate to
+ common pool of memory. Cache memory is divided into partitions called slices
+ which are assigned to clients. Clients can query the slice details, activate
+ and deactivate them.
+
+properties:
+ compatible:
+enum:
+ - qcom,sdm845-llcc
+
+ reg:
+items:
+ - description: LLCC base register region
+ - description: LLCC broadcast base register region
+
+ reg-names:
+items:
+ - const: llcc_base
+ - const: llcc_broadcast_base
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+examples:
+ - |
+#include
+
+cache-controller@110 {
+ compatible = "qcom,sdm845-llcc";
+ reg = <0x110 0x20>, <0x130 0x5> ;
+ reg-names = "llcc_base", "llcc_broadcast_base";
+ interrupts = ;
+};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCHv2 3/3] dt-bindings: msm: Add LLCC for SC7180
Add LLCC compatible for SC7180 SoC. Signed-off-by: Sai Prakash Ranjan --- Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index 5ac90d101807..558749065b97 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -21,6 +21,7 @@ description: | properties: compatible: enum: + - qcom,sc7180-llcc - qcom,sdm845-llcc reg: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[BUG -tip] kmemleak and stacktrace cause page faul
Hi! I'm not sure if I've CC'ed proper persons, so please sorry if I did. Anyway, today's -tip (07b4dbf1d830) refused to boot [0.024793] No NUMA configuration found [0.025406] Faking a node at [mem 0x-0x7ffdefff] [0.026462] NODE_DATA(0) allocated [mem 0x7ffdb000-0x7ffdefff] [0.027246] BUG: unable to handle page fault for address: 1ff0 [0.028160] #PF: supervisor read access in kernel mode [0.028992] #PF: error_code(0x) - not-present page [0.029820] PGD 0 P4D 0 [0.030226] Oops: [#1] PREEMPT SMP PTI [0.031069] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.0-rc3-00258-g07b4dbf1d830 #93 [0.032317] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014 [0.034163] RIP: 0010:get_stack_info+0xb3/0x148 [0.034903] Code: 04 d5 84 48 01 82 66 85 c0 74 25 8b 0c d5 80 48 01 82 0f b7 14 d5 86 48 01 82 48 01 f1 89 13 48 01 c8 48 89 4b 08 48 89 43 10 <48> 8b 40 f0 eb 2b 65 48 8b 05 1f f4 f9 7e 48 8d 90 00 c0 ff ff 48 [0.037579] RSP: :82603be0 EFLAGS: 00010006 I nailed it down to the following kmemleak code create_object ... object->trace_len = __save_stack_trace(object->trace); if I drop this line out it boots fine. Just wanted to share the observation, probably it is known issue already. Sidenote: The last -tip kernel which I've been working with is dated Sep 18 so the changes which cause the problem should be introduced last month.
Re: [5.3.*] nvme issue
On 19-10-2019 13:22, Udo van den Heuvel wrote: > When I boot this workstation, the nvme disks appear in /dev/ without > their partitions. # ls -l /dev/nv* crw--- 1 root root 251, 0 Oct 19 13:43 /dev/nvme0 brw-rw 1 root disk 259, 1 Oct 19 13:43 /dev/nvme0n1 crw--- 1 root root 251, 1 Oct 19 13:43 /dev/nvme1 brw-rw 1 root disk 259, 0 Oct 19 13:43 /dev/nvme1n1 crw--- 1 root root 10, 144 Oct 19 13:43 /dev/nvram # partprobe /dev/nvme0n1 # partprobe /dev/nvme1n1 # ls -l /dev/nv* crw--- 1 root root 251, 0 Oct 19 13:43 /dev/nvme0 brw-rw 1 root disk 259, 1 Oct 19 13:46 /dev/nvme0n1 brw-rw 1 root disk 259, 2 Oct 19 13:46 /dev/nvme0n1p1 brw-rw 1 root disk 259, 3 Oct 19 13:46 /dev/nvme0n1p2 crw--- 1 root root 251, 1 Oct 19 13:43 /dev/nvme1 brw-rw 1 root disk 259, 0 Oct 19 13:46 /dev/nvme1n1 brw-rw 1 root disk 259, 4 Oct 19 13:46 /dev/nvme1n1p1 brw-rw 1 root disk 259, 5 Oct 19 13:46 /dev/nvme1n1p2 crw--- 1 root root 10, 144 Oct 19 13:43 /dev/nvram # The partitions should have appeared sooner? (during boot) Any idea on how to fix this? Kind regards, Udo
Kernel 5.3 / 5.4
Hi list, since the kernels 5.3 and 5.4 the system has become choppy when HD usage is high. Any ideas? Thank you! [0.00] Linux version 5.4.0-050400rc3-generic (kernel@gloin) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #201910132031 SMP Mon Oct 14 00:33:41 UTC 2019 [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.4.0-050400rc3-generic root=UUID=45f4cc67-0672-4e1f-af62-1dc36cfa9f6c ro quiet splash vt.handoff=7 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Hygon HygonGenuine [0.00] Centaur CentaurHauls [0.00] zhaoxin Shanghai [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x902d] usable [0.00] BIOS-e820: [mem 0x902e-0x902e0fff] ACPI NVS [0.00] BIOS-e820: [mem 0x902e1000-0x9030afff] reserved [0.00] BIOS-e820: [mem 0x9030b000-0x903b8fff] usable [0.00] BIOS-e820: [mem 0x903b9000-0x90cb9fff] reserved [0.00] BIOS-e820: [mem 0x90cba000-0xa6ecefff] usable [0.00] BIOS-e820: [mem 0xa6ecf000-0xa78befff] reserved [0.00] BIOS-e820: [mem 0xa78bf000-0xa7f7efff] ACPI NVS [0.00] BIOS-e820: [mem 0xa7f7f000-0xa7ffefff] ACPI data [0.00] BIOS-e820: [mem 0xa7fff000-0xa7ff] usable [0.00] BIOS-e820: [mem 0xa800-0xa80f] reserved [0.00] BIOS-e820: [mem 0xa880-0xad7f] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfd00-0xfe7f] reserved [0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed84000-0xfed84fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffa0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0002517f] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 3.0 present. [0.00] DMI: Acer TravelMate P259-M/Lyra_SK, BIOS V1.49 12/11/2018 [0.00] tsc: Detected 2000.000 MHz processor [0.002647] tsc: Detected 1999.968 MHz TSC [0.002647] e820: update [mem 0x-0x0fff] usable ==> reserved [0.002649] e820: remove [mem 0x000a-0x000f] usable [0.002658] last_pfn = 0x251800 max_arch_pfn = 0x4 [0.002662] MTRR default type: uncachable [0.002663] MTRR fixed ranges enabled: [0.002665] 0-9 write-back [0.002666] A-B uncachable [0.002667] C-F write-protect [0.002667] MTRR variable ranges enabled: [0.002669] 0 base 00 mask 7C write-back [0.002671] 1 base 00A800 mask 7FF800 uncachable [0.002672] 2 base 00B000 mask 7FF000 uncachable [0.002672] 3 base 00C000 mask 7FC000 uncachable [0.002673] 4 disabled [0.002674] 5 disabled [0.002674] 6 disabled [0.002675] 7 disabled [0.002675] 8 disabled [0.002676] 9 disabled [0.003056] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.003211] total RAM covered: 14976M [0.003674] Found optimal setting for mtrr clean up [0.003675] gran_size: 64K chunk_size: 64K num_reg: 5 lose cover RAM: 0G [0.003995] e820: update [mem 0xa800-0x] usable ==> reserved [0.003998] last_pfn = 0xa8000 max_arch_pfn = 0x4 [0.014210] found SMP MP-table at [mem 0x000fe1b0-0x000fe1bf] [0.014301] check: Scanning
Re: [PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit tests for policy unpack
On Fri, 18 Oct 2019, Luis Chamberlain wrote: > On Thu, Oct 17, 2019 at 05:18:16PM -0700, Brendan Higgins wrote: > > From: Mike Salvatore > > > > In order to write the tests against the policy unpacking code, some > > static functions needed to be exposed for testing purposes. One of the > > goals of this patch is to establish a pattern for which testing these > > kinds of functions should be done in the future. > > And you'd run into the same situation expressed elsewhere with kunit of > an issue of the kunit test as built-in working but if built as a module > then it would not work, given the lack of exports. Symbols namespaces > should resolve this [0], and we'd be careful where a driver imports this > namespace. > > [0] https://lwn.net/Articles/798254/ > Thanks for the link! Looks interesting for us definitely! WRT adding tests, I think what we're aiming at is a set of best practices to advise test developers using KUnit, while attempting to minimize side-effects of any changes we need to make to support testability. One aspect of this we probably have to consider is inlining of code. For cases like this where the functions are small and are called in a small number of cases, any testability changes we make may push a previously-inlined function to not be inlined, with potential performance side-effects for the subsystem. In such cases, I wonder if the right answer would be to suggest actually defining the functions as inline in the header file? That way the compiler still gets to decide (as opposed to __always_inline), and we don't perturb performance too much. Thanks! Alan > Luis >
[PATCH] scripts: prune-kernel : prune kernels generalized way
This patch will remove old kernel from the system in a selective way.
Signed-off-by: Bhaskar Chowdhury
---
scripts/prune-kernel | 86
1 file changed, 72 insertions(+), 14 deletions(-)
diff --git a/scripts/prune-kernel b/scripts/prune-kernel
index e8aa940bc0a9..9d839a4e4539 100755
--- a/scripts/prune-kernel
+++ b/scripts/prune-kernel
@@ -5,17 +5,75 @@
# again, /boot and /lib/modules/ eventually fill up.
# Dumb script to purge that stuff:
-for f in "$@"
-do
-if rpm -qf "/lib/modules/$f" >/dev/null; then
-echo "keeping $f (installed from rpm)"
-elif [ $(uname -r) = "$f" ]; then
-echo "keeping $f (running kernel) "
-else
-echo "removing $f"
-rm -f "/boot/initramfs-$f.img" "/boot/System.map-$f"
-rm -f "/boot/vmlinuz-$f" "/boot/config-$f"
-rm -rf "/lib/modules/$f"
-new-kernel-pkg --remove $f
-fi
-done
+#for f in "$@"
+#do
+# if rpm -qf "/lib/modules/$f" >/dev/null; then
+#echo "keeping $f (installed from rpm)"
+#elif [ $(uname -r) = "$f" ]; then
+#echo "keeping $f (running kernel) "
+#else
+#echo "removing $f"
+#rm -f "/boot/initramfs-$f.img" "/boot/System.map-$f"
+#rm -f "/boot/vmlinuz-$f" "/boot/config-$f"
+#rm -rf "/lib/modules/$f"
+#new-kernel-pkg --remove $f
+# fi
+#done
+boot_dir=/boot
+modules_dir=/lib/modules
+
+function remove_old_kernel(){
+ cd $boot_dir
+ rm -If vmlinuz-$kernel_version System.map-$kernel_version
config-$kernel_version
+}
+
+function remove_old_modules_dir(){
+ cd $modules_dir
+ rm -rf $modules_version
+}
+
+printf "\n\n Enlist the installed kernels \n\n"
+
+
+find $boot_dir -name "vmlinuz-*" -type f -exec ls -1 {} \;
+
+printf "\n\n\n Please give the kernel version to remove: %s"
+read kernel_version
+
+if [[ $kernel_version == "" ]];then
+ exit 1
+else
+ remove_old_kernel
+fi
+
+printf "\n\n Enlist the installed modules directory \n\n"
+
+find $modules_dir -maxdepth 0 -type d -exec ls -1 {} \;
+
+printf "\n\n Please give the full modules directory name to remove: %s"
+read modules_version
+
+if [[ $modules_version == "" ]];then
+ printf "You have forgotten to give the modules dir to remove"
+else
+ remove_old_modules_dir
+fi
+
+printf "\n\n\n Removed kernel version:$kernel_version and associated
modules:$modules_version ...Done \n"
+
+while :
+ do
+printf "\n\n Do you want to remove another?[YN]: %s"
+read response
+ if [[ $response == "Y" ]];then
+printf "Please give another version to remove: %s"
+read kernel_version
+remove_old_kernel
+printf "Please give the full modules directory name to remove: %s"
+read modules_version
+remove_old_modules_dir
+printf "\n\n\n Removed kernel version:$kernel_version and associated
modules:$modules_version ..Done \n\n"
+ elif [[ $response == "N" ]];then
+exit 1
+fi
+ done
--
2.21.0
Re: [PATCH 1/3] binder: Fix race between mmap() and binder_alloc_print_pages()
On Fri Oct 18, 2019 at 10:56 PM Jann Horn wrote:
> binder_alloc_print_pages() iterates over
> alloc->pages[0..alloc->buffer_size-1] under alloc->mutex.
> binder_alloc_mmap_handler() writes alloc->pages and alloc->buffer_size
> without holding that lock, and even writes them before the last bailout
> point.
>
> Unfortunately we can't take the alloc->mutex in the ->mmap() handler
> because mmap_sem can be taken while alloc->mutex is held.
> So instead, we have to locklessly check whether the binder_alloc has been
> fully initialized with binder_alloc_get_vma(), like in
> binder_alloc_new_buf_locked().
>
> Fixes: 8ef4665aa129 ("android: binder: Add page usage in binder stats")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jann Horn
Ok, I see a smp_wmb() in binder_alloc_set_vma() which is called in
binder_alloc_mmap_handler() paired with a smp_rmb() in
binder_alloc_get_vma(). That makes sense to me.
Acked-by: Christian Brauner
Re: [PATCH 3/3] binder: Handle start==NULL in binder_update_page_range()
On Fri Oct 18, 2019 at 10:56 PM Jann Horn wrote:
> The old loop wouldn't stop when reaching `start` if `start==NULL`, instead
> continuing backwards to index -1 and crashing.
>
> Luckily you need to be highly privileged to map things at NULL, so it's not
> a big problem.
>
> Fix it by adjusting the loop so that the loop variable is always in bounds.
>
> This patch is deliberately minimal to simplify backporting, but IMO this
> function could use a refactor. The jump labels in the second loop body are
> horrible (the error gotos should be jumping to free_range instead), and
> both loops would look nicer if they just iterated upwards through indices.
> And the up_read()+mmput() shouldn't be duplicated like that.
>
> Cc: sta...@vger.kernel.org
> Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
> Signed-off-by: Jann Horn
Acked-by: Christian Brauner
Re: [PATCH] MAINTAINERS: mtd/ubi/ubifs: Remove inactive maintainers
On Thu, 2019-10-17 at 16:22 +0200, Miquel Raynal wrote: > Despite their substantial personal investment in the MTD/UBI/UBIFS a > few years back, David, Brian, Artem and Adrian are not actively > maintaining the subsystem anymore. We warmly salute them for all the > work they have achieved and will of course still welcome their > participation and reviews. > > That said, Marek retired himself a few weeks ago quoting Harald [1]: > > It matters who has which title and when. Should somebody not > be an active maintainer, make sure he's not listed as such. > > For this same reason, let’s trim the maintainers list with the > actually active ones over the past two years. > > [1] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/ > > Cc: David Woodhouse > Cc: Brian Norris > Cc: Artem Bityutskiy > Cc: Adrian Hunter > Cc: Marek Vasut > Cc: Miquel Raynal > Cc: Richard Weinberger > Cc: Vignesh Raghavendra > Cc: Tudor Ambarus > Signed-off-by: Miquel Raynal Acked-by: Artem Bityutskiy
Re: [PATCH 09/46] watchdog: sa1100: use platform device registration
On 10/18/19 8:41 AM, Arnd Bergmann wrote:
Rather than relying on machine specific headers to
pass down the reboot status and the register locations,
use resources and platform_data.
Aside from this, keep the changes to a minimum.
Cc: Wim Van Sebroeck
Cc: Guenter Roeck
Cc: linux-watch...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/devices.c | 11 +++
arch/arm/mach-pxa/include/mach/regs-ost.h | 2 +
arch/arm/mach-pxa/include/mach/reset.h| 2 +-
arch/arm/mach-pxa/pxa25x.c| 2 +-
arch/arm/mach-pxa/pxa27x.c| 2 +-
arch/arm/mach-pxa/pxa3xx.c| 2 +-
arch/arm/mach-pxa/reset.c | 3 -
arch/arm/mach-sa1100/generic.c| 6 +-
arch/arm/mach-sa1100/include/mach/reset.h | 1 -
drivers/watchdog/sa1100_wdt.c | 87 ---
10 files changed, 83 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 233035e6a2ff..fb9b4f6d32de 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+#include
#include "devices.h"
#include "generic.h"
@@ -1110,3 +1112,12 @@ void __init pxa2xx_set_dmac_info(struct mmp_dma_platdata *dma_pdata)
{
pxa_register_device(_pxa_dma, dma_pdata);
}
+
+void __init pxa_register_wdt(unsigned int reset_status)
+{
+ struct resource res = DEFINE_RES_MEM(OST_PHYS, OST_LEN);
+
+ reset_status &= RESET_STATUS_WATCHDOG;
+ platform_device_register_resndata(NULL, "sa1100_wdt", -1, , 1,
+ _status, sizeof(reset_status));
+}
diff --git a/arch/arm/mach-pxa/include/mach/regs-ost.h
b/arch/arm/mach-pxa/include/mach/regs-ost.h
index 109d0ed264df..c8001cfc8d6b 100644
--- a/arch/arm/mach-pxa/include/mach/regs-ost.h
+++ b/arch/arm/mach-pxa/include/mach/regs-ost.h
@@ -7,6 +7,8 @@
/*
* OS Timer & Match Registers
*/
+#define OST_PHYS 0x40A0
+#define OST_LEN0x0020
#define OSMR0 io_p2v(0x40A0) /* */
#define OSMR1 io_p2v(0x40A4) /* */
diff --git a/arch/arm/mach-pxa/include/mach/reset.h
b/arch/arm/mach-pxa/include/mach/reset.h
index e1c4d100fd45..963dd190bc13 100644
--- a/arch/arm/mach-pxa/include/mach/reset.h
+++ b/arch/arm/mach-pxa/include/mach/reset.h
@@ -8,8 +8,8 @@
#define RESET_STATUS_GPIO (1 << 3) /* GPIO Reset */
#define RESET_STATUS_ALL (0xf)
-extern unsigned int reset_status;
extern void clear_reset_status(unsigned int mask);
+extern void pxa_register_wdt(unsigned int reset_status);
/**
* init_gpio_reset() - register GPIO as reset generator
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 305047ebd2f1..dfc90b41fba3 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -240,7 +240,7 @@ static int __init pxa25x_init(void)
if (cpu_is_pxa25x()) {
- reset_status = RCSR;
+ pxa_register_wdt(RCSR);
pxa25x_init_pm();
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index a81ac88ecbfd..38fdd22c4dc5 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -337,7 +337,7 @@ static int __init pxa27x_init(void)
if (cpu_is_pxa27x()) {
- reset_status = RCSR;
+ pxa_register_wdt(RCSR);
pxa27x_init_pm();
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index fc84aed99481..7c569fa2a6da 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -463,7 +463,7 @@ static int __init pxa3xx_init(void)
if (cpu_is_pxa3xx()) {
- reset_status = ARSR;
+ pxa_register_wdt(ARSR);
/*
* clear RDH bit every time after reset
diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
index af78405aa4e9..fcb791c5ae3e 100644
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -11,9 +11,6 @@
#include
#include
-unsigned int reset_status;
-EXPORT_SYMBOL(reset_status);
-
static void do_hw_reset(void);
static int reset_gpio = -1;
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 4dfb7554649d..6c21f214cd60 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -39,9 +39,6 @@
#include "generic.h"
#include
-unsigned int reset_status;
-EXPORT_SYMBOL(reset_status);
-
#define NR_FREQS 16
/*
@@ -319,10 +316,13 @@ static struct platform_device *sa11x0_devices[]
__initdata = {
static int __init sa1100_init(void)
{
+ struct resource wdt_res = DEFINE_RES_MEM(0x9000, 0x20);
pm_power_off = sa1100_power_off;
regulator_has_full_constraints();
+ platform_device_register_simple("sa1100_wdt", -1, _res, 1);
+
return platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));
Wouldn't it be better to add the
Re: [PATCH 2/3] binder: Prevent repeated use of ->mmap() via NULL mapping
On Fri Oct 18, 2019 at 10:56 PM Jann Horn wrote:
> binder_alloc_mmap_handler() attempts to detect the use of ->mmap() on a
> binder_proc whose binder_alloc has already been initialized by checking
> whether alloc->buffer is non-zero.
>
> Before commit 880211667b20 ("binder: remove kernel vm_area for buffer
> space"), alloc->buffer was a kernel mapping address, which is always
> non-zero, but since that commit, it is a userspace mapping address.
>
> A sufficiently privileged user can map /dev/binder at NULL, tricking
> binder_alloc_mmap_handler() into assuming that the binder_proc has not been
> mapped yet. This leads to memory unsafety.
> Luckily, no context on Android has such privileges, and on a typical Linux
> desktop system, you need to be root to do that.
>
> Fix it by using the mapping size instead of the mapping address to
> distinguish the mapped case. A valid VMA can't have size zero.
>
> Fixes: 880211667b20 ("binder: remove kernel vm_area for buffer space")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jann Horn
Acked-by: Christian Brauner
[PATCH v1 4/5] staging: wfx: correct misspelled words
Correct misspelled words: retrieved and auxiliary. Issue detected by checkpatch tool. Signed-off-by: Jules Irenge --- drivers/staging/wfx/data_tx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c index 619ab2cac5fc..a02692f3210d 100644 --- a/drivers/staging/wfx/data_tx.c +++ b/drivers/staging/wfx/data_tx.c @@ -32,7 +32,7 @@ static int wfx_get_hw_rate(struct wfx_dev *wdev, } return rate->idx + 14; } - // WFx only support 2GHz, else band information should be retreived + // WFx only support 2GHz, else band information should be retrieved // from ieee80211_tx_info return wdev->hw->wiphy->bands[NL80211_BAND_2GHZ]->bitrates[rate->idx].hw_value; } @@ -664,7 +664,7 @@ static int wfx_tx_inner(struct wfx_vif *wvif, struct ieee80211_sta *sta, req->ht_tx_parameters = wfx_tx_get_tx_parms(wvif->wdev, tx_info); req->tx_flags.retry_policy_index = wfx_tx_get_rate_id(wvif, tx_info); - // Auxilliary operations + // Auxiliary operations wfx_tx_manage_pm(wvif, hdr, tx_priv, sta); wfx_tx_queue_put(wvif->wdev, >wdev->tx_queue[queue_id], skb); wfx_bh_request_tx(wvif->wdev); -- 2.21.0
Re: coccinelle: api/devm_platform_ioremap_resource: remove useless script
> What are the additional effects?
I suggest to take another look at the commit
7945f929f1a77a1c8887a97ca07f87626858ff42
("drivers: provide devm_platform_ioremap_resource()" from 2019-02-20)
which triggered the discussed software evolution.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/base/platform.c
> What is the end goal of converting all the existing drivers to
> devm_platform_ioremap_resource?
It was accepted by well-known Linux developers to put two function calls
into another wrapper function.
> This is not an evolution, it is unnecessary churn. Those patches have no
> benefit and eat up very valuable reviewer time.
I am curious if other contributors would like to describe more variants
of software development opinions in affected areas.
>> How will such feedback influence the development and integration of
>> further scripts for the semantic patch language (Coccinelle software)?
>
> There are a few other scripts that have no added value when applied to
> existing code, like ptr_ret.cocci.
Would you like to clarify concerns around such source code transformation
approaches in more detail?
Regards,
Markus
[PATCH v1 1/5] staging: wfx: fix warnings of no space is necessary
Fix warnings of no space is necessary after a cast.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge
---
drivers/staging/wfx/bh.c | 8
drivers/staging/wfx/bus_sdio.c | 6 +++---
drivers/staging/wfx/bus_spi.c | 2 +-
drivers/staging/wfx/data_rx.c | 8
drivers/staging/wfx/data_tx.c | 20 ++--
drivers/staging/wfx/data_tx.h | 4 ++--
6 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
index 3355183fc86c..573216b08042 100644
--- a/drivers/staging/wfx/bh.c
+++ b/drivers/staging/wfx/bh.c
@@ -69,13 +69,13 @@ static int rx_helper(struct wfx_dev *wdev, size_t read_len,
int *is_cnf)
if (wfx_data_read(wdev, skb->data, alloc_len))
goto err;
- piggyback = le16_to_cpup((u16 *) (skb->data + alloc_len - 2));
+ piggyback = le16_to_cpup((u16 *)(skb->data + alloc_len - 2));
_trace_piggyback(piggyback, false);
- hif = (struct hif_msg *) skb->data;
+ hif = (struct hif_msg *)skb->data;
WARN(hif->encrypted & 0x1, "unsupported encryption type");
if (hif->encrypted == 0x2) {
- if (wfx_sl_decode(wdev, (void *) hif)) {
+ if (wfx_sl_decode(wdev, (void *)hif)) {
dev_kfree_skb(skb);
// If frame was a confirmation, expect trouble in next
// exchange. However, it is harmless to fail to decode
@@ -102,7 +102,7 @@ static int rx_helper(struct wfx_dev *wdev, size_t read_len,
int *is_cnf)
if (!(hif->id & HIF_ID_IS_INDICATION)) {
(*is_cnf)++;
if (hif->id == HIF_CNF_ID_MULTI_TRANSMIT)
- release_count = le32_to_cpu(((struct
hif_cnf_multi_transmit *) hif->body)->num_tx_confs);
+ release_count = le32_to_cpu(((struct
hif_cnf_multi_transmit *)hif->body)->num_tx_confs);
else
release_count = 1;
WARN(wdev->hif.tx_buffers_used < release_count, "corrupted
buffer counter");
diff --git a/drivers/staging/wfx/bus_sdio.c b/drivers/staging/wfx/bus_sdio.c
index f97360513150..184e20dfdd62 100644
--- a/drivers/staging/wfx/bus_sdio.c
+++ b/drivers/staging/wfx/bus_sdio.c
@@ -38,7 +38,7 @@ static int wfx_sdio_copy_from_io(void *priv, unsigned int
reg_id,
int ret;
WARN(reg_id > 7, "chip only has 7 registers");
- WARN(((uintptr_t) dst) & 3, "unaligned buffer size");
+ WARN(((uintptr_t)dst) & 3, "unaligned buffer size");
WARN(count & 3, "unaligned buffer address");
/* Use queue mode buffers */
@@ -59,14 +59,14 @@ static int wfx_sdio_copy_to_io(void *priv, unsigned int
reg_id,
int ret;
WARN(reg_id > 7, "chip only has 7 registers");
- WARN(((uintptr_t) src) & 3, "unaligned buffer size");
+ WARN(((uintptr_t)src) & 3, "unaligned buffer size");
WARN(count & 3, "unaligned buffer address");
/* Use queue mode buffers */
if (reg_id == WFX_REG_IN_OUT_QUEUE)
sdio_addr |= bus->buf_id_tx << 7;
// FIXME: discards 'const' qualifier for src
- ret = sdio_memcpy_toio(bus->func, sdio_addr, (void *) src, count);
+ ret = sdio_memcpy_toio(bus->func, sdio_addr, (void *)src, count);
if (!ret && reg_id == WFX_REG_IN_OUT_QUEUE)
bus->buf_id_tx = (bus->buf_id_tx + 1) % 32;
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index f65f7d75e731..effd07957753 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -90,7 +90,7 @@ static int wfx_spi_copy_to_io(void *priv, unsigned int addr,
struct wfx_spi_priv *bus = priv;
u16 regaddr = (addr << 12) | (count / 2);
// FIXME: use a bounce buffer
- u16 *src16 = (void *) src;
+ u16 *src16 = (void *)src;
int ret, i;
struct spi_message m;
struct spi_transfer t_addr = {
diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 3a79089c8501..3a79ab93e97e 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -29,7 +29,7 @@ static int wfx_handle_pspoll(struct wfx_vif *wvif, struct
sk_buff *skb)
rcu_read_lock();
sta = ieee80211_find_sta(wvif->vif, pspoll->ta);
if (sta)
- link_id = ((struct wfx_sta_priv *) >drv_priv)->link_id;
+ link_id = ((struct wfx_sta_priv *)>drv_priv)->link_id;
rcu_read_unlock();
if (link_id)
pspoll_mask = BIT(link_id);
@@ -102,8 +102,8 @@ void wfx_rx_cb(struct wfx_vif *wvif, struct hif_ind_rx
*arg, struct sk_buff *skb
{
int link_id = arg->rx_flags.peer_sta_id;
struct ieee80211_rx_status *hdr = IEEE80211_SKB_RXCB(skb);
- struct ieee80211_hdr *frame = (struct ieee80211_hdr *) skb->data;
- struct ieee80211_mgmt *mgmt = (struct ieee80211_mgmt *) skb->data;
+
[PATCH v1 2/5] staging: wfx: fix warning of line over 80 characters
Fix warning of lines over 80 characters.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge
---
drivers/staging/wfx/bh.c | 17 --
drivers/staging/wfx/bus.h | 6 +-
drivers/staging/wfx/bus_sdio.c | 3 +-
drivers/staging/wfx/bus_spi.c | 9 ++-
drivers/staging/wfx/data_rx.c | 15 +++--
drivers/staging/wfx/data_tx.c | 101 ++---
6 files changed, 102 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
index 573216b08042..955ed3a1dd73 100644
--- a/drivers/staging/wfx/bh.c
+++ b/drivers/staging/wfx/bh.c
@@ -32,7 +32,8 @@ static void device_wakeup(struct wfx_dev *wdev)
// completion without consume it (a kind of
// wait_for_completion_done_timeout()). So we have to emulate
// it.
- if (wait_for_completion_timeout(>hif.ctrl_ready,
msecs_to_jiffies(2) + 1))
+ if (wait_for_completion_timeout(>hif.ctrl_ready,
+ msecs_to_jiffies(2) + 1))
complete(>hif.ctrl_ready);
else
dev_err(wdev->dev, "timeout while wake up chip\n");
@@ -179,8 +180,9 @@ static void tx_helper(struct wfx_dev *wdev, struct hif_msg
*hif)
wdev->hif.tx_seqnum = (wdev->hif.tx_seqnum + 1) % (HIF_COUNTER_MAX + 1);
if (wfx_is_secure_command(wdev, hif->id)) {
- len = round_up(len - sizeof(hif->len), 16) + sizeof(hif->len)
- + sizeof(struct hif_sl_msg_hdr) + sizeof(struct
hif_sl_tag);
+ len = round_up(len - sizeof(hif->len), 16) + sizeof(hif->len) +
+ sizeof(struct hif_sl_msg_hdr) +
+ sizeof(struct hif_sl_tag);
// AES support encryption in-place. However, mac80211 access to
// 802.11 header after frame was sent (to get MAC addresses).
// So, keep origin buffer clear.
@@ -241,7 +243,8 @@ static void ack_sdio_data(struct wfx_dev *wdev)
config_reg_read(wdev, _reg);
if (cfg_reg & 0xFF) {
- dev_warn(wdev->dev, "chip reports errors: %02x\n", cfg_reg &
0xFF);
+ dev_warn(wdev->dev, "chip reports errors: %02x\n",
+cfg_reg & 0xFF);
config_reg_write_bits(wdev, 0xFF, 0x00);
}
}
@@ -268,11 +271,13 @@ static void bh_work(struct work_struct *work)
if (last_op_is_rx)
ack_sdio_data(wdev);
- if (!wdev->hif.tx_buffers_used && !work_pending(work) &&
!atomic_read(>scan_in_progress)) {
+ if (!wdev->hif.tx_buffers_used && !work_pending(work) &&
+ !atomic_read(>scan_in_progress)) {
device_release(wdev);
release_chip = true;
}
- _trace_bh_stats(stats_ind, stats_req, stats_cnf,
wdev->hif.tx_buffers_used, release_chip);
+ _trace_bh_stats(stats_ind, stats_req, stats_cnf,
+ wdev->hif.tx_buffers_used, release_chip);
}
/*
diff --git a/drivers/staging/wfx/bus.h b/drivers/staging/wfx/bus.h
index eb77abc09ec2..62d6ecabe4cb 100644
--- a/drivers/staging/wfx/bus.h
+++ b/drivers/staging/wfx/bus.h
@@ -21,8 +21,10 @@
#define WFX_REG_FRAME_OUT 0x7
struct hwbus_ops {
- int (*copy_from_io)(void *bus_priv, unsigned int addr, void *dst,
size_t count);
- int (*copy_to_io)(void *bus_priv, unsigned int addr, const void *src,
size_t count);
+ int (*copy_from_io)(void *bus_priv, unsigned int addr,
+ void *dst, size_t count);
+ int (*copy_to_io)(void *bus_priv, unsigned int addr,
+ const void *src, size_t count);
void (*lock)(void *bus_priv);
void (*unlock)(void *bus_priv);
size_t (*align_size)(void *bus_priv, size_t size);
diff --git a/drivers/staging/wfx/bus_sdio.c b/drivers/staging/wfx/bus_sdio.c
index 184e20dfdd62..375e07d6d9ae 100644
--- a/drivers/staging/wfx/bus_sdio.c
+++ b/drivers/staging/wfx/bus_sdio.c
@@ -180,7 +180,8 @@ static int wfx_sdio_probe(struct sdio_func *func,
}
bus->of_irq = irq_of_parse_and_map(np, 0);
} else {
- dev_warn(>dev, "device is not declared in DT, features
will be limited\n");
+ dev_warn(>dev,
+"device is not declared in DT, features will be
limited\n");
// FIXME: ignore VID/PID and only rely on device tree
// return -ENODEV;
}
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index effd07957753..ab0cda1e124f 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -178,11 +178,14 @@ static int wfx_spi_probe(struct spi_device *func)
return ret;
// Trace below is also displayed by spi_setup() if compiled with DEBUG
dev_dbg(>dev, "SPI params: CS=%d, mode=%d bits/word=%d
speed=%d\n",
-
[PATCH v1 5/5] staging: wfx: fix warnings of alignment should match open parenthesis
: Fix warnings of alignment should match open parenthesis.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge
---
drivers/staging/wfx/data_rx.c | 2 +-
drivers/staging/wfx/data_tx.c | 2 +-
drivers/staging/wfx/debug.c | 14 --
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 52fb0f255dcd..e7fcce8d0cc4 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -77,7 +77,7 @@ static int wfx_drop_encrypt_data(struct wfx_dev *wdev, struct
hif_ind_rx *arg, s
break;
default:
dev_err(wdev->dev, "unknown encryption type %d\n",
-arg->rx_flags.encryp);
+ arg->rx_flags.encryp);
return -EIO;
}
diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index a02692f3210d..ea4205ac2149 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -40,7 +40,7 @@ static int wfx_get_hw_rate(struct wfx_dev *wdev,
/* TX policy cache implementation */
static void wfx_tx_policy_build(struct wfx_vif *wvif, struct tx_policy *policy,
- struct ieee80211_tx_rate *rates)
+ struct ieee80211_tx_rate *rates)
{
int i;
size_t count;
diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
index 761ad9b4f27e..0a9ca109039c 100644
--- a/drivers/staging/wfx/debug.c
+++ b/drivers/staging/wfx/debug.c
@@ -141,10 +141,11 @@ static int wfx_rx_stats_show(struct seq_file *seq, void
*v)
mutex_lock(>rx_stats_lock);
seq_printf(seq, "Timestamp: %dus\n", st->date);
seq_printf(seq, "Low power clock: frequency %uHz, external %s\n",
- st->pwr_clk_freq,
- st->is_ext_pwr_clk ? "yes" : "no");
- seq_printf(seq, "Num. of frames: %d, PER (x10e4): %d, Throughput:
%dKbps/s\n",
- st->nb_rx_frame, st->per_total, st->throughput);
+ st->pwr_clk_freq,
+ st->is_ext_pwr_clk ? "yes" : "no");
+ seq_printf(seq,
+ "N. of frames: %d, PER (x10e4): %d, Throughput: %dKbps/s\n",
+ st->nb_rx_frame, st->per_total, st->throughput);
seq_puts(seq, " Num. of PER RSSI SNR CFO\n");
seq_puts(seq, "frames (x10e4)(dBm) (dB)(kHz)\n");
for (i = 0; i < ARRAY_SIZE(channel_names); i++) {
@@ -160,8 +161,9 @@ static int wfx_rx_stats_show(struct seq_file *seq, void *v)
}
DEFINE_SHOW_ATTRIBUTE(wfx_rx_stats);
-static ssize_t wfx_send_pds_write(struct file *file, const char __user
*user_buf,
-size_t count, loff_t *ppos)
+static ssize_t wfx_send_pds_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
{
struct wfx_dev *wdev = file->private_data;
char *buf;
--
2.21.0
[PATCH v1 0/5] staging: wfx: fix checkpatch warnings
Fix checkpatch warnings. Jules Irenge (5): staging: wfx: fix warnings of no space is necessary staging: wfx: fix warning of line over 80 characters staging: wfx: fix warnings of logical continuation staging: wfx: correct misspelled words staging: wfx: fix warnings of alignment should match open parenthesis drivers/staging/wfx/bh.c | 25 --- drivers/staging/wfx/bus.h | 6 +- drivers/staging/wfx/bus_sdio.c | 9 +-- drivers/staging/wfx/bus_spi.c | 11 +-- drivers/staging/wfx/data_rx.c | 35 + drivers/staging/wfx/data_tx.c | 127 + drivers/staging/wfx/data_tx.h | 4 +- drivers/staging/wfx/debug.c| 14 ++-- 8 files changed, 143 insertions(+), 88 deletions(-) -- 2.21.0
[PATCH v1 3/5] staging: wfx: fix warnings of logical continuation
Fix check warnings of logical continuations
should be on the previous line.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge
---
drivers/staging/wfx/data_rx.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 522592d71aac..52fb0f255dcd 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -163,14 +163,14 @@ void wfx_rx_cb(struct wfx_vif *wvif, struct hif_ind_rx
*arg,
}
/* Filter block ACK negotiation: fully controlled by firmware */
- if (ieee80211_is_action(frame->frame_control)
- && arg->rx_flags.match_uc_addr
- && mgmt->u.action.category == WLAN_CATEGORY_BACK)
+ if (ieee80211_is_action(frame->frame_control) &&
+ arg->rx_flags.match_uc_addr &&
+ mgmt->u.action.category == WLAN_CATEGORY_BACK)
goto drop;
- if (ieee80211_is_beacon(frame->frame_control)
- && !arg->status && wvif->vif
- && ether_addr_equal(ieee80211_get_SA(frame),
- wvif->vif->bss_conf.bssid)) {
+ if (ieee80211_is_beacon(frame->frame_control) &&
+ !arg->status && wvif->vif &&
+ ether_addr_equal(ieee80211_get_SA(frame),
+wvif->vif->bss_conf.bssid)) {
const u8 *tim_ie;
u8 *ies = mgmt->u.beacon.variable;
size_t ies_len = skb->len - (ies - skb->data);
--
2.21.0
[PATCH] MAINTAINERS: Add mailing list for Realtek SoCs
Document linux-realtek-soc mailing list to be CC'ed on patches. Signed-off-by: Andreas Färber --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index c7b48525822a..8be71b3d25e7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2168,6 +2168,7 @@ F: Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt ARM/REALTEK ARCHITECTURE M: Andreas Färber L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-realtek-...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm64/boot/dts/realtek/ F: Documentation/devicetree/bindings/arm/realtek.yaml -- 2.16.4
[PATCH v3] clk/ti/adpll: allocate room for terminating null
The buffer allocated in ti_adpll_clk_get_name doesn't account for the
terminating null. This patch switches to devm_kasprintf to avoid
overflowing.
Signed-off-by: Stephen Kitt
---
Changes since v2:
- Move "adpll" into the format string and drop base_name entirely.
Changes since v1:
- Use devm_kasprintf instead of manually allocating the target
buffer.
---
drivers/clk/ti/adpll.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
index fdfb90058504..bb2f2836dab2 100644
--- a/drivers/clk/ti/adpll.c
+++ b/drivers/clk/ti/adpll.c
@@ -194,15 +194,8 @@ static const char *ti_adpll_clk_get_name(struct
ti_adpll_data *d,
if (err)
return NULL;
} else {
- const char *base_name = "adpll";
- char *buf;
-
- buf = devm_kzalloc(d->dev, 8 + 1 + strlen(base_name) + 1 +
- strlen(postfix), GFP_KERNEL);
- if (!buf)
- return NULL;
- sprintf(buf, "%08lx.%s.%s", d->pa, base_name, postfix);
- name = buf;
+ name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.adpll.%s",
+ d->pa, postfix);
}
return name;
--
2.20.1
Re: [PATCH 44/46] ARM: mmp: remove tavorevb board support
On Fri, 2019-10-18 at 17:41 +0200, Arnd Bergmann wrote:
> There are two tavorevb boards in the kernel, one using a PXA930 chip in
> mach-pxa, and one using the later PXA910 chip in mach-mmp. They use the
> same board number, which is generally a bad idea, and in a multiplatform
> kernel, we can end up with funny link errors like this one resulting
> from two boards gettting controlled by the same Kconfig symbol:
>
> arch/arm/mach-mmp/tavorevb.o: In function `tavorevb_init':
> tavorevb.c:(.init.text+0x4c): undefined reference to `pxa910_device_uart1'
> tavorevb.c:(.init.text+0x50): undefined reference to `pxa910_device_gpio'
> tavorevb.o:(.arch.info.init+0x54): undefined reference to `pxa910_init_irq'
> tavorevb.o:(.arch.info.init+0x58): undefined reference to `pxa910_timer_init'
>
> The mach-pxa TavorEVB seems much more complete than the mach-mmp one
> that supports only uart, gpio and ethernet. Further, I could find no
> information about the board on the internet aside from references to
> the Linux kernel, so I assume this was never available outside of Marvell
> and can be removed entirely.
>
> There is a third board named TavorEVB in the Kconfig description,
> but this refers to the "TTC_DKB" machine. The two are clearly
> related, so I change the Kconfig description to just list both
> names.
>
> Cc: Lubomir Rintel
> Signed-off-by: Arnd Bergmann
Reviewed-by: Lubomir Rintel
In fact, I'd love to see more non-DT boards go from mach-mmp. There are
good indications nobody is looking after MMP2-based "Jasper", "Flint"
and "Brownstone" and they probably weren't seen outside Marvell either.
The latter has a DTS file.
Would anybody miss them?
Thanks
Lubo
> ---
> arch/arm/mach-mmp/Kconfig| 10 +---
> arch/arm/mach-mmp/Makefile | 1 -
> arch/arm/mach-mmp/tavorevb.c | 113 ---
> 3 files changed, 1 insertion(+), 123 deletions(-)
> delete mode 100644 arch/arm/mach-mmp/tavorevb.c
>
> diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
> index 0440109e973b..fc8cbe0064ae 100644
> --- a/arch/arm/mach-mmp/Kconfig
> +++ b/arch/arm/mach-mmp/Kconfig
> @@ -39,16 +39,8 @@ config MACH_AVENGERS_LITE
> Say 'Y' here if you want to support the Marvell PXA168-based
> Avengers Lite Development Board.
>
> -config MACH_TAVOREVB
> - bool "Marvell's PXA910 TavorEVB Development Board"
> - depends on ARCH_MULTI_V5
> - select CPU_PXA910
> - help
> - Say 'Y' here if you want to support the Marvell PXA910-based
> - TavorEVB Development Board.
> -
> config MACH_TTC_DKB
> - bool "Marvell's PXA910 TavorEVB Development Board"
> + bool "Marvell's PXA910 TavorEVB/TTC_DKB Development Board"
> depends on ARCH_MULTI_V5
> select CPU_PXA910
> help
> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> index 8f267c7bc6e8..0dc07e1f3196 100644
> --- a/arch/arm/mach-mmp/Makefile
> +++ b/arch/arm/mach-mmp/Makefile
> @@ -27,7 +27,6 @@ endif
> obj-$(CONFIG_MACH_ASPENITE) += aspenite.o
> obj-$(CONFIG_MACH_ZYLONITE2) += aspenite.o
> obj-$(CONFIG_MACH_AVENGERS_LITE)+= avengers_lite.o
> -obj-$(CONFIG_MACH_TAVOREVB) += tavorevb.o
> obj-$(CONFIG_MACH_TTC_DKB) += ttc_dkb.o
> obj-$(CONFIG_MACH_BROWNSTONE)+= brownstone.o
> obj-$(CONFIG_MACH_FLINT) += flint.o
> diff --git a/arch/arm/mach-mmp/tavorevb.c b/arch/arm/mach-mmp/tavorevb.c
> deleted file mode 100644
> index 3261d2322198..
> --- a/arch/arm/mach-mmp/tavorevb.c
> +++ /dev/null
> @@ -1,113 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * linux/arch/arm/mach-mmp/tavorevb.c
> - *
> - * Support for the Marvell PXA910-based TavorEVB Development Platform.
> - */
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include "addr-map.h"
> -#include "mfp-pxa910.h"
> -#include "pxa910.h"
> -#include "irqs.h"
> -
> -#include "common.h"
> -
> -static unsigned long tavorevb_pin_config[] __initdata = {
> - /* UART2 */
> - GPIO47_UART2_RXD,
> - GPIO48_UART2_TXD,
> -
> - /* SMC */
> - SM_nCS0_nCS0,
> - SM_ADV_SM_ADV,
> - SM_SCLK_SM_SCLK,
> - SM_SCLK_SM_SCLK,
> - SM_BE0_SM_BE0,
> - SM_BE1_SM_BE1,
> -
> - /* DFI */
> - DF_IO0_ND_IO0,
> - DF_IO1_ND_IO1,
> - DF_IO2_ND_IO2,
> - DF_IO3_ND_IO3,
> - DF_IO4_ND_IO4,
> - DF_IO5_ND_IO5,
> - DF_IO6_ND_IO6,
> - DF_IO7_ND_IO7,
> - DF_IO8_ND_IO8,
> - DF_IO9_ND_IO9,
> - DF_IO10_ND_IO10,
> - DF_IO11_ND_IO11,
> - DF_IO12_ND_IO12,
> - DF_IO13_ND_IO13,
> - DF_IO14_ND_IO14,
> - DF_IO15_ND_IO15,
> - DF_nCS0_SM_nCS2_nCS0,
> - DF_ALE_SM_WEn_ND_ALE,
> - DF_CLE_SM_OEn_ND_CLE,
> - DF_WEn_DF_WEn,
> - DF_REn_DF_REn,
> - DF_RDY0_DF_RDY0,
> -};
> -
> -static struct pxa_gpio_platform_data pxa910_gpio_pdata = {
> - .irq_base = MMP_GPIO_TO_IRQ(0),
> -};
> -
> -static struct smc91x_platdata
Re: [PATCH v1 1/5] staging: wfx: fix warnings of no space is necessary
On Sat, Oct 19, 2019 at 03:07:15PM +0100, Jules Irenge wrote:
> diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
> index 3355183fc86c..573216b08042 100644
> --- a/drivers/staging/wfx/bh.c
> +++ b/drivers/staging/wfx/bh.c
> @@ -69,13 +69,13 @@ static int rx_helper(struct wfx_dev *wdev, size_t
> read_len, int *is_cnf)
> if (wfx_data_read(wdev, skb->data, alloc_len))
> goto err;
>
> - piggyback = le16_to_cpup((u16 *) (skb->data + alloc_len - 2));
> + piggyback = le16_to_cpup((u16 *)(skb->data + alloc_len - 2));
> _trace_piggyback(piggyback, false);
>
> - hif = (struct hif_msg *) skb->data;
> + hif = (struct hif_msg *)skb->data;
> WARN(hif->encrypted & 0x1, "unsupported encryption type");
> if (hif->encrypted == 0x2) {
> - if (wfx_sl_decode(wdev, (void *) hif)) {
> + if (wfx_sl_decode(wdev, (void *)hif)) {
In the future you may want to go through and remove the (void *) casts.
It's not required here.
> diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
> index f65f7d75e731..effd07957753 100644
> --- a/drivers/staging/wfx/bus_spi.c
> +++ b/drivers/staging/wfx/bus_spi.c
> @@ -90,7 +90,7 @@ static int wfx_spi_copy_to_io(void *priv, unsigned int addr,
> struct wfx_spi_priv *bus = priv;
> u16 regaddr = (addr << 12) | (count / 2);
> // FIXME: use a bounce buffer
> - u16 *src16 = (void *) src;
> + u16 *src16 = (void *)src;
Here we are just getting rid of the constness. Apparently we are doing
that so we can modify it without GCC pointing out the bug!! I don't
know the code but this seems very wrong.
> int ret, i;
> struct spi_message m;
> struct spi_transfer t_addr = {
regards,
dan carpenter
Re: [PATCH v2] clk/ti/adpll: allocate room for terminating null
On Thu, 17 Oct 2019 08:48:53 -0700, Stephen Boyd wrote:
> Quoting Stephen Kitt (2019-09-27 11:05:59)
> > The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> > terminating null. This patch switches to ka_sprintf to avoid
> > overflowing.
> >
> > Signed-off-by: Stephen Kitt
> > ---
> > drivers/clk/ti/adpll.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
> > index fdfb90058504..021cf9e2b4db 100644
> > --- a/drivers/clk/ti/adpll.c
> > +++ b/drivers/clk/ti/adpll.c
> > @@ -195,14 +195,8 @@ static const char *ti_adpll_clk_get_name(struct
> > ti_adpll_data *d, return NULL;
> > } else {
> > const char *base_name = "adpll";
>
> This is used once.
>
> > - char *buf;
> > -
> > - buf = devm_kzalloc(d->dev, 8 + 1 + strlen(base_name) + 1 +
> > - strlen(postfix), GFP_KERNEL);
> > - if (!buf)
> > - return NULL;
> > - sprintf(buf, "%08lx.%s.%s", d->pa, base_name, postfix);
> > - name = buf;
> > + name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.%s.%s",
>
> So why not make this "%08lx.adpll.%s"?
Thanks for the review! I hesitated to do this because I thought the purely
formatting string "%08lx.%s.%s" made the resulting code easier to understand
than a combined "%08lx.adpll.%s". I’ll follow up with a v3 which merges the
"adpll" string into the format string.
Regards,
Stephen
pgpURlvLzUhji.pgp
Description: OpenPGP digital signature
Re: [PATCH] random: make try_to_generate_entropy() more robust
On Sat, Oct 19, 2019 at 12:49:52PM +0200, Thomas Gleixner wrote:
>
> One slightly related thing I was looking into is that the mixing of
> interrupt entropy is always done from hard interrupt context. That has a
> few issues:
>
> 1) It's pretty visible in profiles for high frequency interrupt
>scenarios.
>
> 2) The regs content can be pretty boring non-deterministic when the
>interrupt hits idle.
>
>Not an issue in the try_to_generate_entropy() case probably, but
>that still needs some careful investigation.
>
> For #1 I was looking into a trivial storage model with a per cpu ring
> buffer, where each entry contains the entropy data of one interrupt and let
> some thread or whatever handle the mixing later.
Or you can sum up all regs.
unsigned long regsum(struct pt_regs *regs)
{
unsigned long *r = (void *)regs;
unsigned long sum = r[0];
int i;
for (i = 1; i < sizeof(*regs) / sizeof(*r); i++) {
sum += r[i];
}
return sum;
}
Takes 1 cycle per register in the current form, half as much if the
compiler can be convinced to unroll the loop. That's cheaper than
rdtsc() on most/all CPUs.
If interrupt volume is high, the regsum should be good enough. The
final mixing can be amortized as well. Once the pool is initialized,
you can mix new entropy once per jiffy or so and otherwise just add to a
percpu counter or something like that.
> That would allow to filter out 'constant' data (#) but it would also give
> Joerns approach a way to get to some 'random' register content independent
> of the context in which the timer softirq is running in.
Jörn
--
Given two functions foo_safe() and foo_fast(), the shorthand foo()
should be an alias for foo_safe(), never foo_fast().
-- me
Re: [PATCH] MAINTAINERS: Add mailing list for Realtek SoCs
Am 19.10.19 um 16:13 schrieb Andreas Färber: > Document linux-realtek-soc mailing list to be CC'ed on patches. > > Signed-off-by: Andreas Färber > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c7b48525822a..8be71b3d25e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2168,6 +2168,7 @@ F: > Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt > ARM/REALTEK ARCHITECTURE > M: Andreas Färber > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +L: linux-realtek-...@lists.infradead.org (moderated for non-subscribers) > S: Maintained > F: arch/arm64/boot/dts/realtek/ > F: Documentation/devicetree/bindings/arm/realtek.yaml Applied to linux-realtek.git v5.5/arm64: https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-realtek.git/log/?h=v5.5/arm64 Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 2/2] dt-bindings: iio: adc: Add DT docs for AD7292
Hi Rob
Thanks for the review.
I'm having some trouble with the DTC.
I installed the DT tool from https://github.com/robherring/dt-schema.
Running make -k dt_binding_check goes through all the checks (CHKDT), producing
the .example.dts files but then gives errors like:
DTC Documentation/devicetree/bindings/arm/calxeda.example.dt.yaml
FATAL ERROR: Unknown output format "yaml"
make[1]: *** [scripts/Makefile.lib:314:
Documentation/devicetree/bindings/arm/calxeda.example.dt.yaml] Error 1
make[1]: *** Deleting file
'Documentation/devicetree/bindings/arm/calxeda.example.dt.yaml'
My pip3 installation has:
jsonschema jsonschema-3.1.2.dev6+g0d827f3
rfc3987 1.3.8
$HOME/.local/bin is listed in my shell's PATH variable.
I was trying to follow the documentation at:
Documentation/devicetree/writing-schema.rst
Are there any other DTC dependencies that I am missing?
On 10/17, Rob Herring wrote:
> On Tue, Oct 15, 2019 at 11:52:23PM -0300, Marcelo Schmitt wrote:
> > Add a device tree binding doc for AD7292 monitor and control system.
> >
> > Signed-off-by: Marcelo Schmitt
> > ---
> > .../bindings/iio/adc/adi,ad7292.yaml | 107 ++
> > MAINTAINERS | 1 +
> > 2 files changed, 108 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
> > b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
> > new file mode 100644
> > index ..40028332d9e2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
> > @@ -0,0 +1,107 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/adc/adi,ad7292.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices AD7292 10-Bit Monitor and Control System
> > +
> > +maintainers:
> > + - Marcelo Schmitt
> > +
> > +description: |
> > + Analog Devices AD7292 10-Bit Monitor and Control System with ADC, DACs,
> > + Temperature Sensor, and GPIOs
> > +
> > + Specifications about the part can be found at:
> > +
> > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7292.pdf
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - adi,ad7292
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + vref-supply:
> > +description: |
> > + The regulator supply for ADC and DAC reference voltage.
> > +maxItems: 1
>
> Not necessary, regulator supplies are always 1 item, so drop maxItems.
>
> > +
> > + spi-cpha:
> > +description: |
> > + See Documentation/devicetree/bindings/spi/spi-controller.yaml
> > +maxItems: 1
>
> This is just wrong because spi-cpha is a boolean. Just 'spi-cpha: true'
> is sufficient. If this device needs this property, then it should
> probably be required.
>
> > +
> > + '#address-cells':
> > +const: 1
> > +
> > + '#size-cells':
> > +const: 0
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +patternProperties:
> > + "^channel@[0-7]$":
> > +type: object
> > +description: |
> > + Represents the external channels which are connected to the ADC.
> > + See Documentation/devicetree/bindings/iio/adc/adc.txt.
> > +
> > +properties:
> > + reg:
> > +description: |
> > + The channel number. It can have up to 8 channels numbered from 0
> > to 7.
> > +maxItems: 1
> > +
> > + diff-channels:
> > +description: see Documentation/devicetree/bindings/iio/adc/adc.txt
> > +maxItems: 1
> > +
> > +required:
> > + - reg
> > +
> > +examples:
> > + - |
> > +spi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ad7292: ad7292@0 {
>
> adc@0
>
> > +compatible = "adi,ad7292";
> > +reg = <0>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +spi-max-frequency = <2500>;
> > +vref-supply = <_vref>;
> > +spi-cpha;
> > +
> > +channel@0 {
> > + reg = <0>;
> > + diff-channels = <0 1>;
> > +};
> > +channel@2 {
> > + reg = <2>;
> > +};
> > +channel@3 {
> > + reg = <3>;
> > +};
> > +channel@4 {
> > + reg = <4>;
> > +};
> > +channel@5 {
> > + reg = <5>;
> > +};
> > +channel@6 {
> > + reg = <6>;
> > +};
> > +channel@7 {
> > + reg = <7>;
> > +};
> > + };
> > +}
>
> Missing ';'. Make sure this builds with 'make -k dt_binding_check'. The
> '-k' is due to some other breakage ATM.
>
> Rob
Re: [PATCH v1 1/5] staging: wfx: fix warnings of no space is necessary
On Sat, 19 Oct 2019, Dan Carpenter wrote:
> On Sat, Oct 19, 2019 at 03:07:15PM +0100, Jules Irenge wrote:
> > diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
> > index 3355183fc86c..573216b08042 100644
> > --- a/drivers/staging/wfx/bh.c
> > +++ b/drivers/staging/wfx/bh.c
> > @@ -69,13 +69,13 @@ static int rx_helper(struct wfx_dev *wdev, size_t
> > read_len, int *is_cnf)
> > if (wfx_data_read(wdev, skb->data, alloc_len))
> > goto err;
> >
> > - piggyback = le16_to_cpup((u16 *) (skb->data + alloc_len - 2));
> > + piggyback = le16_to_cpup((u16 *)(skb->data + alloc_len - 2));
> > _trace_piggyback(piggyback, false);
> >
> > - hif = (struct hif_msg *) skb->data;
> > + hif = (struct hif_msg *)skb->data;
> > WARN(hif->encrypted & 0x1, "unsupported encryption type");
> > if (hif->encrypted == 0x2) {
> > - if (wfx_sl_decode(wdev, (void *) hif)) {
> > + if (wfx_sl_decode(wdev, (void *)hif)) {
>
> In the future you may want to go through and remove the (void *) casts.
> It's not required here.
>
> > diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
> > index f65f7d75e731..effd07957753 100644
> > --- a/drivers/staging/wfx/bus_spi.c
> > +++ b/drivers/staging/wfx/bus_spi.c
> > @@ -90,7 +90,7 @@ static int wfx_spi_copy_to_io(void *priv, unsigned int
> > addr,
> > struct wfx_spi_priv *bus = priv;
> > u16 regaddr = (addr << 12) | (count / 2);
> > // FIXME: use a bounce buffer
> > - u16 *src16 = (void *) src;
> > + u16 *src16 = (void *)src;
>
> Here we are just getting rid of the constness. Apparently we are doing
> that so we can modify it without GCC pointing out the bug!! I don't
> know the code but this seems very wrong.
>
Checkpatch was complaining about space between type cast and the
variable. I just get rid of the space. Well I don't know whether this was
false positive one.
Thanks for the feedback. I will update the patch.
Regards,
Jules
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: [Outreachy kernel] Re: [PATCH v1 1/5] staging: wfx: fix warnings of no space is necessary
On Sat, 19 Oct 2019, Jules Irenge wrote:
>
>
> On Sat, 19 Oct 2019, Dan Carpenter wrote:
>
> > On Sat, Oct 19, 2019 at 03:07:15PM +0100, Jules Irenge wrote:
> > > diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
> > > index 3355183fc86c..573216b08042 100644
> > > --- a/drivers/staging/wfx/bh.c
> > > +++ b/drivers/staging/wfx/bh.c
> > > @@ -69,13 +69,13 @@ static int rx_helper(struct wfx_dev *wdev, size_t
> > > read_len, int *is_cnf)
> > > if (wfx_data_read(wdev, skb->data, alloc_len))
> > > goto err;
> > >
> > > - piggyback = le16_to_cpup((u16 *) (skb->data + alloc_len - 2));
> > > + piggyback = le16_to_cpup((u16 *)(skb->data + alloc_len - 2));
> > > _trace_piggyback(piggyback, false);
> > >
> > > - hif = (struct hif_msg *) skb->data;
> > > + hif = (struct hif_msg *)skb->data;
> > > WARN(hif->encrypted & 0x1, "unsupported encryption type");
> > > if (hif->encrypted == 0x2) {
> > > - if (wfx_sl_decode(wdev, (void *) hif)) {
> > > + if (wfx_sl_decode(wdev, (void *)hif)) {
> >
> > In the future you may want to go through and remove the (void *) casts.
> > It's not required here.
> >
> > > diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
> > > index f65f7d75e731..effd07957753 100644
> > > --- a/drivers/staging/wfx/bus_spi.c
> > > +++ b/drivers/staging/wfx/bus_spi.c
> > > @@ -90,7 +90,7 @@ static int wfx_spi_copy_to_io(void *priv, unsigned int
> > > addr,
> > > struct wfx_spi_priv *bus = priv;
> > > u16 regaddr = (addr << 12) | (count / 2);
> > > // FIXME: use a bounce buffer
> > > - u16 *src16 = (void *) src;
> > > + u16 *src16 = (void *)src;
> >
> > Here we are just getting rid of the constness. Apparently we are doing
> > that so we can modify it without GCC pointing out the bug!! I don't
> > know the code but this seems very wrong.
> >
> Checkpatch was complaining about space between type cast and the
> variable. I just get rid of the space. Well I don't know whether this was
> false positive one.
I think you missed the point. It would be good to trace through the core
and try to figure out where this src value comes from. Is it really
const? Or is the const declaration there just to satisfy the type
checker, and is the actual data provided not const. This function is
stored in a hwbus_ops structure. It would be good to see what other
drivers that store a function in the same field of such a structure do,
and to see where the function is actually called (via a function pointer)
and where the argument comes from.
julia
Re: [PATCH -next] CIFS: remove set but not used variables 'cinode' and 'netfid'
tentatively pushed to cifs-2.6.git for-next pending more testing of the flock patch it modified. On Fri, Oct 18, 2019 at 1:07 AM YueHaibing wrote: > > Fixes gcc '-Wunused-but-set-variable' warning: > > fs/cifs/file.c: In function 'cifs_flock': > fs/cifs/file.c:1704:8: warning: > variable 'netfid' set but not used [-Wunused-but-set-variable] > > fs/cifs/file.c:1702:24: warning: > variable 'cinode' set but not used [-Wunused-but-set-variable] > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing > --- > fs/cifs/file.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/fs/cifs/file.c b/fs/cifs/file.c > index 936e03892e2a..02a81dc6861a 100644 > --- a/fs/cifs/file.c > +++ b/fs/cifs/file.c > @@ -1699,9 +1699,7 @@ int cifs_flock(struct file *file, int cmd, struct > file_lock *fl) > bool posix_lck = false; > struct cifs_sb_info *cifs_sb; > struct cifs_tcon *tcon; > - struct cifsInodeInfo *cinode; > struct cifsFileInfo *cfile; > - __u16 netfid; > __u32 type; > > rc = -EACCES; > @@ -1716,8 +1714,6 @@ int cifs_flock(struct file *file, int cmd, struct > file_lock *fl) > cifs_read_flock(fl, , , , _flag, > tcon->ses->server); > cifs_sb = CIFS_FILE_SB(file); > - netfid = cfile->fid.netfid; > - cinode = CIFS_I(file_inode(file)); > > if (cap_unix(tcon->ses) && > (CIFS_UNIX_FCNTL_CAP & le64_to_cpu(tcon->fsUnixInfo.Capability)) > && > > > -- Thanks, Steve
Re: [PATCH v3 2/3] mm/vmalloc: respect passed gfp_mask when do preloading
> > > > > > This is explaining what but it doesn't say why. I would go with > > > " > > > Allocation functions should comply with the given gfp_mask as much as > > > possible. The preallocation code in alloc_vmap_area doesn't follow that > > > pattern and it is using a hardcoded GFP_KERNEL. Although this doesn't > > > really make much difference because vmalloc is not GFP_NOWAIT compliant > > > in general (e.g. page table allocations are GFP_KERNEL) there is no > > > reason to spread that bad habit and it is good to fix the antipattern. > > > " > > I can go with that, agree. I am not sure if i need to update the patch > > and send v4. Or maybe Andrew can directly update it in his tree. > > > > Andrew, should i send or can update? > > I updated the changelog with Michal's words prior to committing. You > were cc'ed :) > Ah, i saw the email stating that the patch has been added to the "mm" tree, but i did not check the commit message. Now i see everything is sorted out :) Thank you! -- Vlad Rezki
Re: [PATCH] scripts: prune-kernel : prune kernels generalized way
On Sat, Oct 19, 2019 at 06:37:22PM +0530, Bhaskar Chowdhury wrote:
> This patch will remove old kernel from the system in a selective way.
Please don't comment out code, just delete it, git's there to keep the
old code.
There's some redundant code that should be inside a loop.
A little more detail in the changelog might be useful to those of us who
are lazy about reading bash script
Looks like this just prompts for each individual delete? Actually it
looks like it requires the user to enter the module path and kernel
version for each one which makes it not much more convenient use than a
bare "ls" and "rm".
I personally use this in unattended scripts. I mean, I don't really
care what we do with this, as I use my own copy of the script, so
whatever's useful to more people is fine.
But if somebody does actually use it as-is, it'd be nicer to keep the
current behavior and add an option ("-i" or something) for the
interactive behavior.
--b.
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> scripts/prune-kernel | 86
> 1 file changed, 72 insertions(+), 14 deletions(-)
>
> diff --git a/scripts/prune-kernel b/scripts/prune-kernel
> index e8aa940bc0a9..9d839a4e4539 100755
> --- a/scripts/prune-kernel
> +++ b/scripts/prune-kernel
> @@ -5,17 +5,75 @@
> # again, /boot and /lib/modules/ eventually fill up.
> # Dumb script to purge that stuff:
>
> -for f in "$@"
> -do
> -if rpm -qf "/lib/modules/$f" >/dev/null; then
> -echo "keeping $f (installed from rpm)"
> -elif [ $(uname -r) = "$f" ]; then
> -echo "keeping $f (running kernel) "
> -else
> -echo "removing $f"
> -rm -f "/boot/initramfs-$f.img" "/boot/System.map-$f"
> -rm -f "/boot/vmlinuz-$f" "/boot/config-$f"
> -rm -rf "/lib/modules/$f"
> -new-kernel-pkg --remove $f
> -fi
> -done
> +#for f in "$@"
> +#do
> +# if rpm -qf "/lib/modules/$f" >/dev/null; then
> +#echo "keeping $f (installed from rpm)"
> +#elif [ $(uname -r) = "$f" ]; then
> +#echo "keeping $f (running kernel) "
> +#else
> +#echo "removing $f"
> +#rm -f "/boot/initramfs-$f.img" "/boot/System.map-$f"
> +#rm -f "/boot/vmlinuz-$f" "/boot/config-$f"
> +#rm -rf "/lib/modules/$f"
> +#new-kernel-pkg --remove $f
> +# fi
> +#done
> +boot_dir=/boot
> +modules_dir=/lib/modules
> +
> +function remove_old_kernel(){
> + cd $boot_dir
> + rm -If vmlinuz-$kernel_version System.map-$kernel_version
> config-$kernel_version
> +}
> +
> +function remove_old_modules_dir(){
> + cd $modules_dir
> + rm -rf $modules_version
> +}
> +
> +printf "\n\n Enlist the installed kernels \n\n"
> +
> +
> +find $boot_dir -name "vmlinuz-*" -type f -exec ls -1 {} \;
> +
> +printf "\n\n\n Please give the kernel version to remove: %s"
> +read kernel_version
> +
> +if [[ $kernel_version == "" ]];then
> + exit 1
> +else
> + remove_old_kernel
> +fi
> +
> +printf "\n\n Enlist the installed modules directory \n\n"
> +
> +find $modules_dir -maxdepth 0 -type d -exec ls -1 {} \;
> +
> +printf "\n\n Please give the full modules directory name to remove: %s"
> +read modules_version
> +
> +if [[ $modules_version == "" ]];then
> + printf "You have forgotten to give the modules dir to remove"
> +else
> + remove_old_modules_dir
> +fi
> +
> +printf "\n\n\n Removed kernel version:$kernel_version and associated
> modules:$modules_version ...Done \n"
> +
> +while :
> + do
> +printf "\n\n Do you want to remove another?[YN]: %s"
> +read response
> + if [[ $response == "Y" ]];then
> + printf "Please give another version to remove: %s"
> + read kernel_version
> + remove_old_kernel
> + printf "Please give the full modules directory name to remove: %s"
> + read modules_version
> + remove_old_modules_dir
> + printf "\n\n\n Removed kernel version:$kernel_version and associated
> modules:$modules_version ..Done \n\n"
> + elif [[ $response == "N" ]];then
> + exit 1
> +fi
> + done
> --
> 2.21.0
Re: [PATCH v2 3/4] gpio: Add RDA Micro GPIO controller support
Hi Linus,
Thanks for the review! Please see comments inline.
On Wed, Oct 16, 2019 at 02:41:32PM +0200, Linus Walleij wrote:
> Hi Manivannan!
>
> Thanks for your patch!
>
> On Tue, Oct 15, 2019 at 7:30 PM Manivannan Sadhasivam
> wrote:
>
> > Add support for GPIO controller from RDA Micro.
> >
> > Signed-off-by: Manivannan Sadhasivam
>
> Please use a little bit more verbose commit message, who
> made this hardware and what is it for. If you know!
>
okay.
> > +config GPIO_RDA
> > + bool "RDA Micro GPIO controller support"
> > + depends on ARCH_RDA || COMPILE_TEST
> > + depends on OF_GPIO
> > + select GPIOLIB_IRQCHIP
>
> select GPIO_GENERIC
>
hmm.. I don't think this driver can use it. Please see the justification
below.
> > +#include
>
> Do you need this or just ?
>
I need this for for_each_set_bit() macro.
> > +#define RDA_GPIO_OEN_VAL 0x00
> > +#define RDA_GPIO_OEN_SET_OUT 0x04
> > +#define RDA_GPIO_OEN_SET_IN0x08
> > +#define RDA_GPIO_VAL 0x0c
> > +#define RDA_GPIO_SET 0x10
> > +#define RDA_GPIO_CLR 0x14
> > +#define RDA_GPIO_INT_CTRL_SET 0x18
> > +#define RDA_GPIO_INT_CTRL_CLR 0x1c
> > +#define RDA_GPIO_INT_CLR 0x20
> > +#define RDA_GPIO_INT_STATUS0x24
>
> This is a very clear cut MMIO GPIO so use GPIO_GENERIC with this
> hardware.
>
So, I'd be happy to use gpio-mmio driver if applicable. In fact, I looked into
that while starting to write this driver since most of the `set*` APIs are
like dups. But one thing which blocked me was, `gpio_get` API.
As you can see in this driver, there are 2 separate registers needs to be
read in order to get the value. RDA_GPIO_VAL needs to be read when the pin
is in input state and RDA_GPIO_SET needs to be read when the pin is in output
state.
The MMIO driver relies on a single `dat` register to read the GPIO state and
this won't fit for this driver and hence my justification for not using it.
> > +static void rda_gpio_update(struct gpio_chip *chip, unsigned int offset,
> > + u16 reg, int val)
>
> Maybe keep this if it saves code from the IRQ callbacks,
> inline it to register writes if it doesn't get called much.
>
It is being called from multiple places, so I'd like to keep it as a normal
function.
> > +static int rda_gpio_direction_input(struct gpio_chip *chip, unsigned int
> > offset)
> > +static int rda_gpio_direction_output(struct gpio_chip *chip,
> > +unsigned int offset, int value)
> > +static int rda_gpio_get(struct gpio_chip *chip, unsigned int offset)
> > +static void rda_gpio_set(struct gpio_chip *chip, unsigned int offset, int
> > value)
>
> This can all be replaces by select GPIO_GENERIC and passing
> the right offsets into bgpio_init(). Look at for example
> gpio-ftgpio010.c and the documentation for bgpio_init()
> in gpio-mmio.c for help.
>
> This will also implement get/set_multiple for you for
> free!
>
> > +static void rda_gpio_irq_mask(struct irq_data *data)
> > +static void rda_gpio_irq_ack(struct irq_data *data)
>
> Looks good
>
> > +static int rda_gpio_set_irq(struct gpio_chip *chip, u32 offset,
> > + unsigned int flow_type)
>
> Maybe _setup_irq()? Not sure, just that the name doesn't
> obviously imply how it is used as it is called from two
> places.
>
Well, this routine sets the irq_type. But it has multiple usecase.
Like, it is being used to unmask as irq and also to set irq type.
So to be in a equillibrium state, I went for rda_gpio_set_irq().
> The rest of the IRQ code looks good!
>
> > +static int rda_gpio_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct gpio_irq_chip *irq_chip;
>
> Since irq_chip is the name of a struct in the kernel I usually
> just call this "girq" as in "GPIO irq chip".
>
Ah, a name change again... will do ;-)
> > + struct rda_gpio *rda_gpio;
> > + u32 ngpios;
> > + int ret;
>
> Create a struct device *dev = >dev; helper variable
> to make the following code easier to read. (The pointer
> >dev is used in many places...)
>
okay.
> > + /*
> > +* Not all ports have interrupt capability. For instance, on
> > +* RDA8810PL, GPIOC doesn't support interrupt. So we must handle
> > +* those also.
> > +*/
> > + rda_gpio->irq = platform_get_irq(pdev, 0);
> > +
> > + rda_gpio->base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(rda_gpio->base))
> > + return PTR_ERR(rda_gpio->base);
> > +
> > + spin_lock_init(_gpio->lock);
> > +
> > + rda_gpio->chip.label = dev_name(>dev);
> > + rda_gpio->chip.ngpio = ngpios;
> > + rda_gpio->chip.base = -1;
> > + rda_gpio->chip.parent = >dev;
> > + rda_gpio->chip.of_node = np;
> > + rda_gpio->chip.get =
[PATCH] fs/dax: Fix pmd vs pte conflict detection
Check for NULL entries before checking the entry order, otherwise NULL
is misinterpreted as a present pte conflict. The 'order' check needs to
happen before the locked check as an unlocked entry at the wrong order
must fallback to lookup the correct order.
Reported-by: Jeff Smits
Reported-by: Doug Nelson
Cc:
Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
Cc: Jan Kara
Cc: Matthew Wilcox (Oracle)
Signed-off-by: Dan Williams
---
fs/dax.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index a71881e77204..08160011d94c 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -221,10 +221,11 @@ static void *get_unlocked_entry(struct xa_state *xas,
unsigned int order)
for (;;) {
entry = xas_find_conflict(xas);
+ if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
+ return entry;
if (dax_entry_order(entry) < order)
return XA_RETRY_ENTRY;
- if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) ||
- !dax_is_locked(entry))
+ if (!dax_is_locked(entry))
return entry;
wq = dax_entry_waitqueue(xas, entry, );
Re: [PATCH 2/6] ARM: ep93xx: enable SPARSE_IRQ
Hello Arnd,
On Fri, 18 Oct 2019 18:29:15 +0200
Arnd Bergmann wrote:
> Without CONFIG_SPARSE_IRQ, we rely on mach/irqs.h to define NR_IRQS
> globally. Do the minimal conversion by setting .nr_irqs in each
> machine descriptor.
>
> Only the vision_ep9307 machine has extra IRQs for GPIOs, so make
> .nr_irqs the original value there, while using the plain NR_EP93XX_IRQS
> everywhere else.
This patch causes multiple problems on EDB9302:
1. WARNINGs during gpiochip registration, for instance:
[ cut here ]
WARNING: CPU: 0 PID: 1 at kernel/irq/chip.c:1013 __irq_do_set_handler+0x94/0x188
CPU: 0 PID: 1 Comm: swapper Tainted: GW 5.4.0-rc3 #1
Hardware name: Cirrus Logic EDB9302 Evaluation Board
[] (unwind_backtrace) from [] (show_stack+0x10/0x18)
[] (show_stack) from [] (dump_stack+0x18/0x24)
[] (dump_stack) from [] (__warn+0xa4/0xc8)
[] (__warn) from [] (warn_slowpath_fmt+0xa8/0xb8)
[] (warn_slowpath_fmt) from []
(__irq_do_set_handler+0x94/0x188)
[] (__irq_do_set_handler) from []
(irq_set_chained_handler_and_data+0x48/0x7c)
[] (irq_set_chained_handler_and_data) from []
(gpiochip_add_data_with_key+0x6d4/0xabc)
[] (gpiochip_add_data_with_key) from []
(devm_gpiochip_add_data+0x40/0x88)
[] (devm_gpiochip_add_data) from []
(ep93xx_gpio_probe+0x1ac/0x280)
[] (ep93xx_gpio_probe) from []
(platform_drv_probe+0x28/0x6c)
[] (platform_drv_probe) from [] (really_probe+0x1c8/0x340)
[] (really_probe) from [] (bus_for_each_drv+0x58/0xc0)
[] (bus_for_each_drv) from [] (__device_attach+0xb4/0x104)
[] (__device_attach) from [] (bus_probe_device+0x8c/0x94)
[] (bus_probe_device) from [] (device_add+0x3d0/0x59c)
[] (device_add) from [] (platform_device_add+0x100/0x20c)
[] (platform_device_add) from []
(ep93xx_init_devices+0x16c/0x20c)
[] (ep93xx_init_devices) from []
(edb93xx_init_machine+0xc/0x84)
[] (edb93xx_init_machine) from []
(customize_machine+0x20/0x38)
[] (customize_machine) from [] (do_one_initcall+0x78/0x1a0)
[] (do_one_initcall) from []
(kernel_init_freeable+0x104/0x1b8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xf8)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
Exception stack(0xc4433fb0 to 0xc4433ff8)
3fa0:
3fc0:
3fe0: 0013
---[ end trace 8f9e35e2d6224882 ]---
2. Broken sound (I2S), this looks like below in the log:
ep93xx-i2s ep93xx-i2s: Missing dma channel for stream: 0
CS4271: ASoC: pcm constructor failed: -22
edb93xx-audio edb93xx-audio: ASoC: can't create pcm CS4271 HiFi :-22
And /proc/interrupts has two entries less. Without patch:
# cat /proc/interrupts
CPU0
7: 0 VIC 7 Edge i2s-pcm-out
8: 0 VIC 8 Edge i2s-pcm-in
39: 2 VIC 7 Edge eth0
51: 7532 VIC 19 Edge ep93xx timer
52:144 VIC 20 Edge uart-pl010
53: 4 VIC 21 Edge ep93xx-spi
60: 0 VIC 28 Edge ep93xx-i2s
Err: 0
With patch:
# cat /proc/interrupts
CPU0
39:146 VIC 7 Edge eth0
51: 162161 VIC 19 Edge ep93xx timer
52:139 VIC 20 Edge uart-pl010
53: 4 VIC 21 Edge ep93xx-spi
60: 0 VIC 28 Edge ep93xx-i2s
Err: 0
I will try to look into I2S problem...
> ---
> It's been a while since I did this, no idea what else is needed
> here or if this is correct at all.
>
> Cc: Hartley Sweeten
> Cc: Alexander Sverdlin
> Cc: Hubert Feurstein
> Cc: Lukasz Majewski
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/Kconfig | 2 ++
> arch/arm/mach-ep93xx/adssphere.c | 1 +
> arch/arm/mach-ep93xx/edb93xx.c | 8
> arch/arm/mach-ep93xx/gesbc9312.c | 1 +
> arch/arm/mach-ep93xx/{include/mach => }/irqs.h | 7 ---
> arch/arm/mach-ep93xx/micro9.c | 4
> arch/arm/mach-ep93xx/simone.c | 1 +
> arch/arm/mach-ep93xx/snappercl15.c | 1 +
> arch/arm/mach-ep93xx/soc.h | 1 +
> arch/arm/mach-ep93xx/ts72xx.c | 3 ++-
> arch/arm/mach-ep93xx/vision_ep9307.c | 1 +
> 11 files changed, 22 insertions(+), 8 deletions(-)
> rename arch/arm/mach-ep93xx/{include/mach => }/irqs.h (94%)
--
Alexander Sverdlin.
[PATCH] net: fix sk_page_frag() recursion from memory reclaim
>From f0335a5d14d3596d36e3ffddb2fd4fa0dc6ca9c2 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Sat, 19 Oct 2019 09:10:57 -0700
sk_page_frag() optimizes skb_frag allocations by using per-task
skb_frag cache when it knows it's the only user. The condition is
determined by seeing whether the socket allocation mask allows
blocking - if the allocation may block, it obviously owns the task's
context and ergo exclusively owns current->task_frag.
Unfortunately, this misses recursion through memory reclaim path.
Please take a look at the following backtrace.
[2] RIP: 0010:tcp_sendmsg_locked+0xccf/0xe10
...
tcp_sendmsg+0x27/0x40
sock_sendmsg+0x30/0x40
sock_xmit.isra.24+0xa1/0x170 [nbd]
nbd_send_cmd+0x1d2/0x690 [nbd]
nbd_queue_rq+0x1b5/0x3b0 [nbd]
__blk_mq_try_issue_directly+0x108/0x1b0
blk_mq_request_issue_directly+0xbd/0xe0
blk_mq_try_issue_list_directly+0x41/0xb0
blk_mq_sched_insert_requests+0xa2/0xe0
blk_mq_flush_plug_list+0x205/0x2a0
blk_flush_plug_list+0xc3/0xf0
[1] blk_finish_plug+0x21/0x2e
_xfs_buf_ioapply+0x313/0x460
__xfs_buf_submit+0x67/0x220
xfs_buf_read_map+0x113/0x1a0
xfs_trans_read_buf_map+0xbf/0x330
xfs_btree_read_buf_block.constprop.42+0x95/0xd0
xfs_btree_lookup_get_block+0x95/0x170
xfs_btree_lookup+0xcc/0x470
xfs_bmap_del_extent_real+0x254/0x9a0
__xfs_bunmapi+0x45c/0xab0
xfs_bunmapi+0x15/0x30
xfs_itruncate_extents_flags+0xca/0x250
xfs_free_eofblocks+0x181/0x1e0
xfs_fs_destroy_inode+0xa8/0x1b0
destroy_inode+0x38/0x70
dispose_list+0x35/0x50
prune_icache_sb+0x52/0x70
super_cache_scan+0x120/0x1a0
do_shrink_slab+0x120/0x290
shrink_slab+0x216/0x2b0
shrink_node+0x1b6/0x4a0
do_try_to_free_pages+0xc6/0x370
try_to_free_mem_cgroup_pages+0xe3/0x1e0
try_charge+0x29e/0x790
mem_cgroup_charge_skmem+0x6a/0x100
__sk_mem_raise_allocated+0x18e/0x390
__sk_mem_schedule+0x2a/0x40
[0] tcp_sendmsg_locked+0x8eb/0xe10
tcp_sendmsg+0x27/0x40
sock_sendmsg+0x30/0x40
___sys_sendmsg+0x26d/0x2b0
__sys_sendmsg+0x57/0xa0
do_syscall_64+0x42/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
In [0], tcp_send_msg_locked() was using current->page_frag when it
called sk_wmem_schedule(). It already calculated how many bytes can
be fit into current->page_frag. Due to memory pressure,
sk_wmem_schedule() called into memory reclaim path which called into
xfs and then IO issue path. Because the filesystem in question is
backed by nbd, the control goes back into the tcp layer - back into
tcp_sendmsg_locked().
nbd sets sk_allocation to (GFP_NOIO | __GFP_MEMALLOC) which makes
sense - it's in the process of freeing memory and wants to be able to,
e.g., drop clean pages to make forward progress. However, this
confused sk_page_frag() called from [2]. Because it only tests
whether the allocation allows blocking which it does, it now thinks
current->page_frag can be used again although it already was being
used in [0].
After [2] used current->page_frag, the offset would be increased by
the used amount. When the control returns to [0],
current->page_frag's offset is increased and the previously calculated
number of bytes now may overrun the end of allocated memory leading to
silent memory corruptions.
Fix it by updating sk_page_frag() to test __GFP_MEMALLOC and not use
current->task_frag if set.
Signed-off-by: Tejun Heo
Cc: Josef Bacik
Cc: sta...@vger.kernel.org
---
include/net/sock.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 2c53f1a1d905..4e2ca38acc3c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2233,12 +2233,21 @@ struct sk_buff *sk_stream_alloc_skb(struct sock *sk,
int size, gfp_t gfp,
* sk_page_frag - return an appropriate page_frag
* @sk: socket
*
- * If socket allocation mode allows current thread to sleep, it means its
- * safe to use the per task page_frag instead of the per socket one.
+ * Use the per task page_frag instead of the per socket one for
+ * optimization when we know there can be no other users.
+ *
+ * 1. The socket allocation mode allows current thread to sleep. This is
+ *the sleepable context which owns the task page_frag.
+ *
+ * 2. The socket allocation mode doesn't indicate that the socket is being
+ *used to reclaim memory. Memory reclaim may nest inside other socket
+ *operations and end up recursing into sk_page_frag() while it's
+ *already in use.
*/
static inline struct page_frag *sk_page_frag(struct sock *sk)
{
- if (gfpflags_allow_blocking(sk->sk_allocation))
+ if (gfpflags_allow_blocking(sk->sk_allocation) &&
+ !(sk->sk_allocation & __GFP_MEMALLOC))
return >task_frag;
return >sk_frag;
--
2.17.1
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: [PATCH 05/10] libperf: Add _GNU_SOURCE define to compilation
On Fri, Oct 18, 2019 at 03:07:38PM -0300, Arnaldo Carvalho de Melo wrote: > > Why? it's passed when the library is compiled with perf, but not when you compile it standalone.. and 2 '-D_GNU_SOURCE' on command line are ok jirka > > > Em Thu, Oct 17, 2019 at 12:59:13PM +0200, Jiri Olsa escreveu: > > Link: http://lkml.kernel.org/n/tip-m7t1e9kgea4jc3piyvjju...@git.kernel.org > > Signed-off-by: Jiri Olsa > > --- > > tools/perf/lib/Makefile | 1 + > > tools/perf/lib/tests/Makefile | 2 ++ > > 2 files changed, 3 insertions(+) > > > > diff --git a/tools/perf/lib/Makefile b/tools/perf/lib/Makefile > > index 0f233638ef1f..20396f68fcad 100644 > > --- a/tools/perf/lib/Makefile > > +++ b/tools/perf/lib/Makefile > > @@ -73,6 +73,7 @@ override CFLAGS += -Werror -Wall > > override CFLAGS += -fPIC > > override CFLAGS += $(INCLUDES) > > override CFLAGS += -fvisibility=hidden > > +override CFLAGS += -D_GNU_SOURCE > > > > all: > > > > diff --git a/tools/perf/lib/tests/Makefile b/tools/perf/lib/tests/Makefile > > index a43cd08c5c03..78c3d8c83c53 100644 > > --- a/tools/perf/lib/tests/Makefile > > +++ b/tools/perf/lib/tests/Makefile > > @@ -12,6 +12,8 @@ else > >CFLAGS := -g -Wall > > endif > > > > +CFLAGS += -D_GNU_SOURCE > > + > > all: > > > > include $(srctree)/tools/scripts/Makefile.include > > -- > > 2.21.0 > > -- > > - Arnaldo
Re: [PATCH 07/10] libperf: Add tests_mmap_cpus test
On Fri, Oct 18, 2019 at 03:16:31PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 18, 2019 at 03:14:29PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Thu, Oct 17, 2019 at 12:59:15PM +0200, Jiri Olsa escreveu: > > > Adding mmaping tests that generates prctl call on > > > every cpu validates it gets all the related events > > > in ring buffer. > > > > So _here_ we need _GNU_SOURCE, for this specific test: > > Added, to this test: > > [acme@quaco perf]$ git diff > diff --git a/tools/perf/lib/tests/test-evlist.c > b/tools/perf/lib/tests/test-evlist.c > index d8c52ebfa53a..741bc1bb4524 100644 > --- a/tools/perf/lib/tests/test-evlist.c > +++ b/tools/perf/lib/tests/test-evlist.c > @@ -1,6 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0 > -#include > +#define _GNU_SOURCE // needed for sched.h to get sched_[gs]etaffinity and > CPU_(ZERO,SET) > #include > +#include > #include > #include > #include > [acme@quaco perf]$ > > We can go the big hammer way if this is more generally needed, but first > lets try to use it only when needed, ok? ok, thanks FYI so it's quite easy now to separate the lib and move it under tools/lib/perf.. I'll post it together with docs/tutorial update jirka
