[PATCH] lib/mpi: Remove unused scalar_copied
On Mon, Sep 28, 2020 at 01:24:38PM -0500, Gustavo A. R. Silva wrote:
>
> I'm reporting the following bug detected by Coverity:
>
> The _scalar_copied_ variable is set to 0 at
>
> lib/mpi/ec.c:1255:
> 1255 int scalar_copied = 0;
>
> and it is never updated before reaching the code below:
>
> lib/mpi/ec.c:1317
> 1317 if (scalar_copied)
>
> 1318 mpi_free(scalar);
>
> This code was introduced by commit d58bb7e55a8a ("lib/mpi: Introduce ec
> implementation to MPI library")
>
> Any ideas on what's the right solution for this?
I think it should be removed.
---8<---
The scalar_copied variable is not as the scalar is never copied
in that block. This patch removes it.
Fixes: d58bb7e55a8a ("lib/mpi: Introduce ec implementation to...")
Reported-by: Gustavo A. R. Silva
Signed-off-by: Herbert Xu
diff --git a/lib/mpi/ec.c b/lib/mpi/ec.c
index c21470122dfc..40f5908e57a4 100644
--- a/lib/mpi/ec.c
+++ b/lib/mpi/ec.c
@@ -1252,7 +1252,6 @@ void mpi_ec_mul_point(MPI_POINT result,
MPI_POINT q1, q2, prd, sum;
unsigned long sw;
mpi_size_t rsize;
- int scalar_copied = 0;
/* Compute scalar point multiplication with Montgomery Ladder.
* Note that we don't use Y-coordinate in the points at all.
@@ -1314,8 +1313,6 @@ void mpi_ec_mul_point(MPI_POINT result,
point_free();
point_free(_);
point_free(_);
- if (scalar_copied)
- mpi_free(scalar);
return;
}
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [v5 01/12] struct device: Add function callback durable_name
On 10/7/20 10:10 PM, Tony Asleson wrote: On 10/1/20 6:48 AM, Greg Kroah-Hartman wrote: On Wed, Sep 30, 2020 at 09:35:52AM -0500, Tony Asleson wrote: On 9/30/20 2:38 AM, Greg Kroah-Hartman wrote: On Tue, Sep 29, 2020 at 05:04:32PM -0500, Tony Asleson wrote: I'm trying to figure out a way to positively identify which storage device an error belongs to over time. "over time" is not the kernel's responsibility. This comes up every 5 years or so. The kernel provides you, at runtime, a mapping between a hardware device and a "logical" device. It can provide information to userspace about this mapping, but once that device goes away, the kernel is free to reuse that logical device again. If you want to track what logical devices match up to what physical device, then do it in userspace, by parsing the log files. I don't understand why people think it's acceptable to ask user space to parse text that is subject to change. What text is changing? The format of of the prefix of dev_*() is well known and has been stable for 15+ years now, right? What is difficult in parsing it? Many of the storage layer messages are using printk, not dev_printk. So that would be the immediate angle of attack ... Thank you for supplying some feedback and asking questions. I've been asking for suggestions and would very much like to have a discussion on how this issue is best solved. I'm not attached to what I've provided. I'm just trying to get towards a solution. Again, solve this in userspace, you have the information there at runtime, why not use it? We usually don't have the needed information if you remove the expectation that user space should parse the human readable portion of the error message. I don't expect that userspace should have to parse any human readable portion, if they don't want to. But if you do want it to, it is pretty trivial to parse what you have today: scsi 2:0:0:0: Direct-Access Generic STORAGE DEVICE 1531 PQ: 0 ANSI: 6 If you really have a unique identifier, then great, parse it today: usb 4-1.3.1: Product: USB3.0 Card Reader usb 4-1.3.1: Manufacturer: Generic usb 4-1.3.1: SerialNumber: 1531 What's keeping that from working now? I believe these examples are using dev_printk. With dev_printk we don't need to parse the text, we can use the meta data. So it looks as most of your usecase would be solved by moving to dev_printk(). Why not work on that instead? I do presume this will have immediate benefits for everybody, and will have approval from everyone. Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
Re: [v2 PATCH] crypto: sun4i-ss - Fix sparse endianness markers
On Thu, Sep 24, 2020 at 03:27:38PM +0200, Corentin Labbe wrote: > > This is an example on next-20200923+BigEndian > alg: ahash: sha1 test failed (wrong result) on test vector \"random: > psize=194 ksize=0\", cfg=\"random: inplace may_sleep use_finup > src_divs=[98.25%@+1124, 1.75%@+5] iv_offset=18\" Hmm, the only way I can see this happening is if it was triggered by tcrypt. Were you using tcrypt by any chance? Ccing Eric in case he has any insight. > === DUMP /proc/crypto === > name : sha1 > driver : sha1-sun4i-ss > module : kernel > priority : 300 > refcnt : 1 > selftest : passed > internal : no > type : ahash > async: no > blocksize: 64 > digestsize : 20 ... > name : sha1 > driver : sha1-generic > module : kernel > priority : 100 > refcnt : 1 > selftest : passed > internal : no > type : shash > blocksize: 64 > digestsize : 20 Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] printk: handle blank console arguments passed in.
On (20/10/08 01:29), Sergey Senozhatsky wrote:
> On (20/10/07 08:57), Guenter Roeck wrote:
> > On 10/7/20 5:30 AM, Sergey Senozhatsky wrote:
>
> [..]
>
> > I can see to options: Link /dev/console to /dev/null if there is no console,
> > or do something like
> >
> > if (IS_ERR(file)) {
> > pr_warn("Warning: unable to open an initial console.\n");
> > file = filp_open("/dev/null", O_RDWR, 0);
> > if (IS_ERR(file))
> > return;
> > }
>
> As far as I can tell, /dev/null does not exist yet on this stage
> (at least not in my system). But generally the idea looks interesting.
Hmm. How about this. console= is undocumented and unspecified - it
may work sometimes or it may kill the system (and theoretically even
corrupt some files, depending on what fd 1 and fd 2 point to). So
maybe we can document console= and handle it in printk, rather than
somewhere deep in init/main.c
IOW add one more flag (yeah, I know) and set it when console_setup()
sees console= boot param. The idea is allow console registration,
but all consoles should be disabled (cleared CON_ENABLED bit). This
would be easier to document, at least.
Schematically:
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 929e86a01148..b71ff9d87693 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -281,6 +281,7 @@ static struct console_cmdline
console_cmdline[MAX_CMDLINECONSOLES];
static int preferred_console = -1;
static bool has_preferred_console;
+static bool mute_consoles = false;
int console_set_on_cmdline;
EXPORT_SYMBOL(console_set_on_cmdline);
@@ -2141,6 +2142,9 @@ static int __add_preferred_console(char *name, int idx,
char *options,
struct console_cmdline *c;
int i;
+ if (mute_consoles)
+ return;
+
/*
* See if this tty is not yet registered, and
* if we have a slot free.
@@ -2189,6 +2193,11 @@ static int __init console_setup(char *str)
char *s, *options, *brl_options = NULL;
int idx;
+ if (str[0] == 0) {
+ mute_consoles = true;
+ return 0;
+ }
+
if (_braille_console_setup(, _options))
return 1;
@@ -2630,6 +2639,9 @@ EXPORT_SYMBOL(console_stop);
void console_start(struct console *console)
{
+ if (mute_consoles)
+ return;
+
console_lock();
console->flags |= CON_ENABLED;
console_unlock();
@@ -2811,6 +2823,9 @@ void register_console(struct console *newcon)
console_drivers->next = newcon;
}
+ if (mute_consoles)
+ newcon->flags &= ~CON_ENABLED;
+
if (newcon->flags & CON_EXTENDED)
nr_ext_console_drivers++;
Re: [PATCH-next 0/4] RDMA: sprintf to sysfs_emit conversions
On Thu, 2020-10-08 at 08:41 +0300, Leon Romanovsky wrote: > On Wed, Oct 07, 2020 at 07:36:23PM -0700, Joe Perches wrote: > > A recent commit added a sysfs_emit and sysfs_emit_at to allow various > > sysfs show functions to ensure that the PAGE_SIZE buffer argument is > > never overrun and always NUL terminated. > > Unfortunately but the sysfs_emit commit is not in rdma-next tree yet. Likely it'll still apply fairly well when the sysfs_emit commit is...
Re: [PATCH] KVM: SVM: Use a separate vmcb for the nested L2 guest
On 08/10/20 00:14, Maxim Levitsky wrote: >> >> +if (svm->vmcb01->control.asid == 0) >> +svm->vmcb01->control.asid = svm->nested.vmcb02->control.asid; > > I think that the above should be done always. The asid field is currently host > controlled only (that is L2 value is ignored, selective ASID tlb flush is not > advertized to the guest and lnvlpga is emulated as invlpg). Yes, in fact I suggested that ASID should be in svm->asid and moved to svm->vmcb->asid in svm_vcpu_run. Then there's no need to special case it in nested code. This should be a patch coming before this one. > > 1. Something wrong with memory types - like guest is using UC memory for > everything. > I can't completely rule that out yet You can print g_pat and see if it is all zeroes. In general I think it's better to be explicit with vmcb01 vs. vmcb02, like Cathy did, but I can see it's a matter of personal preference to some extent. Paolo
Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned
On Mon, Sep 28, 2020 at 12:50:03PM -0700, Linus Torvalds wrote: > On Mon, Sep 28, 2020 at 12:36 PM Linus Torvalds > wrote: > > > > So I'll do the pte wrprotect/restore removal. Anybody willing to do > > and test the sequence count approach? > > So the wrprotect removal is trivial, with most of it being about the comments. > > However, when I look at this, I am - once again - tempted to just add a > > if (__page_mapcount(page) > 1) > return 1; > > there too. Because we know it's a private mapping (shared mappings we > checked for with the "is_cow_mapping()" earlier), and the only case we > really care about is the one where the page is only mapped in the > current mm (because that's what a write pinning will have done, and as > mentioned, a read pinning doesn't do anything wrt fork() right now > anyway). > > So if it's mapped in another mm, the COW clearly hasn't been broken by > a pin, and a read pinned page had already gone through a fork. > > But the more I look at this code, the more I go "ok, I want somebody > to actually test this with the rdma case". > > So I'll attach my suggested patch, but I won't actually commit it. I'd > really like to have this tested, possibly _together_ with the sequence > count addition.. Hi Linus, We tested the suggested patch for last two weeks in our nightly regressions and didn't experience any new failures. It looks like it is safe to use it, but better to take the patch during/after merge window to minimize risk of delaying v5.9. Thanks > >Linus
Re: [PATCH v8 2/6] PCI/DPC: define a function to check and wait till port finish DPC handling
On Thu, Oct 8, 2020 at 2:16 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > Once root port DPC capability is enabled and triggered, at the beginning
> > of DPC is triggered, the DPC status bits are set by hardware and then
> > sends DPC/DLLSC/PDC interrupts to OS DPC and pciehp drivers, it will
> > take the port and software DPC interrupt handler 10ms to 50ms (test data
> > on ICS(Ice Lake SP platform, see
> > https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server)
> > & stable 5.9-rc6) to complete the DPC containment procedure
> This data is based on one particular architecture. So using this
> to create a timed loop in pci_wait_port_outdpc() looks incorrect.
>
> I still recommend looking for some locking model to fix this
> issue (may be atomic state flag or lock).
It is actually a device semaphore. DLLSC/PDC handler needs to wait
for the critical
area is clear to enter by monitoring the DPC triggered status is
cleaned or not.
Another problem is, DPC reset/interrupt is initiated by hardware,
you couldn't place
a software lock between interrupt handler and device resetting.
While device semaphore--- DPC triggered status is the right one to wait for.
Better idea ?
Thanks,
Ethan
> > till the DPC status is cleared at the end of the DPC interrupt handler.
> >
> > We use this function to check if the root port is in DPC handling status
> > and wait till the hardware and software completed the procedure.
> >
> > Signed-off-by: Ethan Zhao
> > Tested-by: Wen Jin
> > Tested-by: Shanshan Zhang
> > ---
> > changes:
> > v2：align ICS code name to public doc.
> > v3: no change.
> > v4: response to Christoph's (Christoph Hellwig )
> > tip, move pci_wait_port_outdpc() to DPC driver and its declaration
> > to pci.h.
> > v5: fix building issue reported by l...@intel.com with some config.
> > v6: move from [1/5] to [2/5].
> > v7: no change.
> > v8: no change.
> >
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/pcie/dpc.c | 27 +++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index fa12f7cbc1a0..455b32187abd 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -455,10 +455,12 @@ void pci_restore_dpc_state(struct pci_dev *dev);
> > void pci_dpc_init(struct pci_dev *pdev);
> > void dpc_process_error(struct pci_dev *pdev);
> > pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
> > +bool pci_wait_port_outdpc(struct pci_dev *pdev);
> > #else
> > static inline void pci_save_dpc_state(struct pci_dev *dev) {}
> > static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
> > static inline void pci_dpc_init(struct pci_dev *pdev) {}
> > +static inline bool pci_wait_port_outdpc(struct pci_dev *pdev) { return
> > false; }
> > #endif
> >
> > #ifdef CONFIG_PCI_ATS
> > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> > index daa9a4153776..2e0e091ce923 100644
> > --- a/drivers/pci/pcie/dpc.c
> > +++ b/drivers/pci/pcie/dpc.c
> > @@ -71,6 +71,33 @@ void pci_restore_dpc_state(struct pci_dev *dev)
> > pci_write_config_word(dev, dev->dpc_cap + PCI_EXP_DPC_CTL, *cap);
> > }
> >
> > +bool pci_wait_port_outdpc(struct pci_dev *pdev)
> > +{
> > + u16 cap = pdev->dpc_cap, status;
> > + u16 loop = 0;
> > +
> > + if (!cap) {
> > + pci_WARN_ONCE(pdev, !cap, "No DPC capability initiated\n");
> > + return false;
> > + }
> > + pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
> > + pci_dbg(pdev, "DPC status %x, cap %x\n", status, cap);
> > +
> > + while (status & PCI_EXP_DPC_STATUS_TRIGGER && loop < 100) {
> > + msleep(10);
> > + loop++;
> > + pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
> > + }
> > +
> > + if (!(status & PCI_EXP_DPC_STATUS_TRIGGER)) {
> > + pci_dbg(pdev, "Out of DPC %x, cost %d ms\n", status, loop*10);
> > + return true;
> > + }
> > +
> > + pci_dbg(pdev, "Timeout to wait port out of DPC status\n");
> > + return false;
> > +}
> > +
> > static int dpc_wait_rp_inactive(struct pci_dev *pdev)
> > {
> > unsigned long timeout = jiffies + HZ;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
>
Re: [PATCH] crypto: xor - Remove unused variable count in do_xor_speed
On Tue, Oct 06, 2020 at 12:58:48PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used
> here [-Wuninitialized]
> count++;
> ^
> crypto/xor.c:86:17: note: initialize the variable 'count' to silence
> this warning
> int i, j, count;
>^
> = 0
> 1 warning generated.
>
> After the refactoring to use ktime that happened in this function, count
> is only assigned, never read. Just remove the variable to get rid of the
> warning.
>
> Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1171
> Signed-off-by: Nathan Chancellor
> ---
> crypto/xor.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] docs: w1: w1_therm: Fix broken xref, mistakes, clarify text
sysfs attribute names are mixed with the same normal text terms.
Use ReST to distinguish.
Fix typos and mistakes.
Signed-off-by: Ivan Zaentsev
---
.../ABI/testing/sysfs-driver-w1_therm | 6 +-
Documentation/w1/slaves/w1_therm.rst | 83 +--
2 files changed, 43 insertions(+), 46 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm
b/Documentation/ABI/testing/sysfs-driver-w1_therm
index 9f05bcdcd762..8873bbb075cb 100644
--- a/Documentation/ABI/testing/sysfs-driver-w1_therm
+++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -146,7 +146,7 @@ Date: July 2020
Contact: Ivan Zaentsev
Description:
(RW) Control optional driver settings.
- Bit masks to read/write (logical OR):
+ Bit masks to read/write (bitwise OR):
1: Enable check for conversion success. If byte 6 of
scratchpad memory is 0xC after conversion, and
@@ -157,7 +157,7 @@ Description:
after the conversion start and wait for 1's. In parasite
power mode this feature is not available.
- *read*: Currently selected features, bitwise OR.
- *write*: Select features, bitwise OR.
+ *read*: Currently selected features.
+ *write*: Select features.
Users: An application using the w1_term device
diff --git a/Documentation/w1/slaves/w1_therm.rst
b/Documentation/w1/slaves/w1_therm.rst
index 00376501a5ef..e39202e2b000 100644
--- a/Documentation/w1/slaves/w1_therm.rst
+++ b/Documentation/w1/slaves/w1_therm.rst
@@ -27,75 +27,72 @@ W1_THERM_DS1825 0x3B
W1_THERM_DS28EA00 0x42
-Support is provided through the sysfs w1_slave file. Each open and
-read sequence will initiate a temperature conversion then provide two
+Support is provided through the sysfs entry ``w1_slave``. Each open and
+read sequence will initiate a temperature conversion, then provide two
lines of ASCII output. The first line contains the nine hex bytes
read along with a calculated crc value and YES or NO if it matched.
If the crc matched the returned values are retained. The second line
displays the retained values along with a temperature in millidegrees
Centigrade after t=.
-Alternatively, temperature can be read using temperature sysfs, it
-return only temperature in millidegrees Centigrade.
+Alternatively, temperature can be read using ``temperature`` sysfs, it
+returns only the temperature in millidegrees Centigrade.
-A bulk read of all devices on the bus could be done writing 'trigger'
-in the therm_bulk_read sysfs entry at w1_bus_master level. This will
-sent the convert command on all devices on the bus, and if parasite
-powered devices are detected on the bus (and strong pullup is enable
+A bulk read of all devices on the bus could be done writing ``trigger``
+to ``therm_bulk_read`` entry at w1_bus_master level. This will
+send the convert command to all devices on the bus, and if parasite
+powered devices are detected on the bus (and strong pullup is enabled
in the module), it will drive the line high during the longer conversion
time required by parasited powered device on the line. Reading
-therm_bulk_read will return 0 if no bulk conversion pending,
+``therm_bulk_read`` will return 0 if no bulk conversion pending,
-1 if at least one sensor still in conversion, 1 if conversion is complete
but at least one sensor value has not been read yet. Result temperature is
-then accessed by reading the temperature sysfs entry of each device, which
+then accessed by reading the ``temperature`` entry of each device, which
may return empty if conversion is still in progress. Note that if a bulk
read is sent but one sensor is not read immediately, the next access to
-temperature on this device will return the temperature measured at the
+``temperature`` on this device will return the temperature measured at the
time of issue of the bulk read command (not the current temperature).
A strong pullup will be applied during the conversion if required.
-``conv_time`` sysfs entry is used to get current conversion time (read), and
+``conv_time`` is used to get current conversion time (read), and
adjust it (write). A temperature conversion time depends on the device type and
it's current resolution. Default conversion time is set by the driver according
to the device datasheet. A conversion time for many original device clones
deviate from datasheet specs. There are three options: 1) manually set the
correct conversion time by writing a value in milliseconds to ``conv_time``; 2)
auto measure and set a conversion time by writing ``1`` to
-``conv_time``; 3) use ``features`` entry to enable poll for conversion
+``conv_time``; 3) use ``features`` to enable poll for conversion
completion. Options 2, 3 can't be used in parasite power mode. To get back to
the default
Re: [PATCH v2 5/5] PCI: dwc: Move dw_pcie_msi_init() from each users to designware host
On 9/24/2020 4:37 PM, Jisheng Zhang wrote:
External email: Use caution opening links or attachments
Currently, dw_pcie_msi_init() allocates and maps page for msi, then
program the PCIE_MSI_ADDR_LO and PCIE_MSI_ADDR_HI. The Root Complex
may lose power during suspend-to-RAM, so when we resume, we want to
redo the latter but not the former. If designware based driver (for
example, pcie-tegra194.c) calls dw_pcie_msi_init() in resume path, the
previous msi page will be leaked. From another side, except
pci-dra7xx.c we can move the dw_pcie_msi_init() from each users to
designware host, I.E move the msi page allocation and mapping to
dw_pcie_host_init() and move the PCIE_MSI_ADDR_* programming to
dw_pcie_setup_rc(). After this moving, we solve the msi page leakage
as well.
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pci-dra7xx.c | 1 +
drivers/pci/controller/dwc/pci-exynos.c | 2 --
drivers/pci/controller/dwc/pci-imx6.c | 3 ---
drivers/pci/controller/dwc/pci-meson.c| 8 ---
drivers/pci/controller/dwc/pcie-artpec6.c | 10
.../pci/controller/dwc/pcie-designware-host.c | 24 ---
.../pci/controller/dwc/pcie-designware-plat.c | 3 ---
drivers/pci/controller/dwc/pcie-designware.h | 5
drivers/pci/controller/dwc/pcie-histb.c | 3 ---
drivers/pci/controller/dwc/pcie-kirin.c | 3 ---
drivers/pci/controller/dwc/pcie-qcom.c| 3 ---
drivers/pci/controller/dwc/pcie-spear13xx.c | 1 -
drivers/pci/controller/dwc/pcie-tegra194.c| 2 --
drivers/pci/controller/dwc/pcie-uniphier.c| 9 +--
14 files changed, 22 insertions(+), 55 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c
b/drivers/pci/controller/dwc/pci-dra7xx.c
index dc387724cf08..d8b74389e353 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -210,6 +210,7 @@ static int dra7xx_pcie_host_init(struct pcie_port *pp)
dra7xx_pcie_establish_link(pci);
dw_pcie_wait_for_link(pci);
dw_pcie_msi_init(pp);
+ dw_pcie_msi_config(pp);
dra7xx_pcie_enable_interrupts(dra7xx);
return 0;
diff --git a/drivers/pci/controller/dwc/pci-exynos.c
b/drivers/pci/controller/dwc/pci-exynos.c
index 8d82c43ae299..9cca0ce79777 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -298,8 +298,6 @@ static void exynos_pcie_msi_init(struct exynos_pcie *ep)
struct pcie_port *pp = >pp;
u32 val;
- dw_pcie_msi_init(pp);
-
/* enable MSI interrupt */
val = exynos_pcie_readl(ep->mem_res->elbi_base, PCIE_IRQ_EN_LEVEL);
val |= IRQ_MSI_ENABLE;
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 5fef2613b223..dba6e351e3df 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -848,9 +848,6 @@ static int imx6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
imx6_pcie_establish_link(imx6_pcie);
- if (IS_ENABLED(CONFIG_PCI_MSI))
- dw_pcie_msi_init(pp);
-
return 0;
}
diff --git a/drivers/pci/controller/dwc/pci-meson.c
b/drivers/pci/controller/dwc/pci-meson.c
index 4f183b96afbb..cd0d9dd8dd61 100644
--- a/drivers/pci/controller/dwc/pci-meson.c
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -377,12 +377,6 @@ static int meson_pcie_establish_link(struct meson_pcie *mp)
return dw_pcie_wait_for_link(pci);
}
-static void meson_pcie_enable_interrupts(struct meson_pcie *mp)
-{
- if (IS_ENABLED(CONFIG_PCI_MSI))
- dw_pcie_msi_init(>pci.pp);
-}
-
static int meson_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
u32 *val)
{
@@ -467,8 +461,6 @@ static int meson_pcie_host_init(struct pcie_port *pp)
if (ret)
return ret;
- meson_pcie_enable_interrupts(mp);
-
return 0;
}
diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c
b/drivers/pci/controller/dwc/pcie-artpec6.c
index 97d50bb50f06..af1e6bb28e7a 100644
--- a/drivers/pci/controller/dwc/pcie-artpec6.c
+++ b/drivers/pci/controller/dwc/pcie-artpec6.c
@@ -346,15 +346,6 @@ static void artpec6_pcie_deassert_core_reset(struct
artpec6_pcie *artpec6_pcie)
usleep_range(100, 200);
}
-static void artpec6_pcie_enable_interrupts(struct artpec6_pcie *artpec6_pcie)
-{
- struct dw_pcie *pci = artpec6_pcie->pci;
- struct pcie_port *pp = >pp;
-
- if (IS_ENABLED(CONFIG_PCI_MSI))
- dw_pcie_msi_init(pp);
-}
-
static int artpec6_pcie_host_init(struct pcie_port *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -368,7 +359,6 @@ static int artpec6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
artpec6_pcie_establish_link(pci);
dw_pcie_wait_for_link(pci);
-
Re: [PATCH] X.509: fix error return value on the failed path
On Mon, Oct 05, 2020 at 10:46:28PM +0800, Tianjia Zhang wrote:
> When memory allocation fails, an appropriate return value
> should be set.
>
> Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
> verification")
> Signed-off-by: Tianjia Zhang
> ---
> crypto/asymmetric_keys/public_key_sm2.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH-next 0/4] RDMA: sprintf to sysfs_emit conversions
On Wed, Oct 07, 2020 at 07:36:23PM -0700, Joe Perches wrote: > A recent commit added a sysfs_emit and sysfs_emit_at to allow various > sysfs show functions to ensure that the PAGE_SIZE buffer argument is > never overrun and always NUL terminated. Unfortunately but the sysfs_emit commit is not in rdma-next tree yet. Thanks
[PATCH v2 4/4] selftests/timens: added selftest for /proc/stat btime
Test that btime value of /proc/stat is as expected in the time namespace
using a simple parser to get btime from /proc/stat.
Signed-off-by: Michael Weiß
---
tools/testing/selftests/timens/procfs.c | 58 -
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/timens/procfs.c
b/tools/testing/selftests/timens/procfs.c
index 7f14f0fdac84..f2519154208a 100644
--- a/tools/testing/selftests/timens/procfs.c
+++ b/tools/testing/selftests/timens/procfs.c
@@ -93,6 +93,33 @@ static int read_proc_uptime(struct timespec *uptime)
return 0;
}
+static int read_proc_stat_btime(unsigned long long *boottime_sec)
+{
+ FILE *proc;
+ char line_buf[2048];
+
+ proc = fopen("/proc/stat", "r");
+ if (proc == NULL) {
+ pr_perror("Unable to open /proc/stat");
+ return -1;
+ }
+
+ while (fgets(line_buf, 2048, proc)) {
+ if (sscanf(line_buf, "btime %llu", boottime_sec) != 1)
+ continue;
+ fclose(proc);
+ return 0;
+ }
+ if (errno) {
+ pr_perror("fscanf");
+ fclose(proc);
+ return -errno;
+ }
+ pr_err("failed to parse /proc/stat");
+ fclose(proc);
+ return -1;
+}
+
static int check_uptime(void)
{
struct timespec uptime_new, uptime_old;
@@ -123,18 +150,47 @@ static int check_uptime(void)
return 0;
}
+static int check_stat_btime(void)
+{
+ unsigned long long btime_new, btime_old;
+ unsigned long long btime_expected;
+
+ if (switch_ns(parent_ns))
+ return pr_err("switch_ns(%d)", parent_ns);
+
+ if (read_proc_stat_btime(_old))
+ return 1;
+
+ if (switch_ns(child_ns))
+ return pr_err("switch_ns(%d)", child_ns);
+
+ if (read_proc_stat_btime(_new))
+ return 1;
+
+ btime_expected = btime_old - TEN_DAYS_IN_SEC;
+ if (btime_new != btime_expected) {
+ pr_fail("btime in /proc/stat: old %llu, new %llu [%llu]",
+ btime_old, btime_new, btime_expected);
+ return 1;
+ }
+
+ ksft_test_result_pass("Passed for /proc/stat btime\n");
+ return 0;
+}
+
int main(int argc, char *argv[])
{
int ret = 0;
nscheck();
- ksft_set_plan(1);
+ ksft_set_plan(2);
if (init_namespaces())
return 1;
ret |= check_uptime();
+ ret |= check_stat_btime();
if (ret)
ksft_exit_fail();
--
2.20.1
[PATCH v2 2/4] time: make getboottime64 aware of time namespace
getboottime64() provides the time stamp of system boot. In case of
time namespaces, the offset to the boot time stamp was not applied
earlier. However, getboottime64 is used e.g., in /proc/stat to print
the system boot time to userspace. In container runtimes which utilize
time namespaces to virtualize boottime of a container, this leaks
information about the host system boot time.
Therefore, we make getboottime64() to respect the time namespace offset
for boottime by subtracting the boottime offset.
Signed-off-by: Michael Weiß
---
kernel/time/timekeeping.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4c47f388a83f..67530cdb389e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2154,6 +2155,8 @@ void getboottime64(struct timespec64 *ts)
{
struct timekeeper *tk = _core.timekeeper;
ktime_t t = ktime_sub(tk->offs_real, tk->offs_boot);
+ /* shift boot time stamp according to the timens offset */
+ t = timens_ktime_to_host(CLOCK_BOOTTIME, t);
*ts = ktime_to_timespec64(t);
}
--
2.20.1
[PATCH v2 1/4] timens: additional helper function to add boottime in nsec
Provide a helper function to apply the boottime offset to u64 types
in nanoseconds.
Signed-off-by: Michael Weiß
---
include/linux/time_namespace.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/time_namespace.h b/include/linux/time_namespace.h
index 5b6031385db0..5372181010f9 100644
--- a/include/linux/time_namespace.h
+++ b/include/linux/time_namespace.h
@@ -77,6 +77,13 @@ static inline void timens_add_boottime(struct timespec64 *ts)
*ts = timespec64_add(*ts, ns_offsets->boottime);
}
+static inline u64 timens_add_boottime_ns(u64 nsec)
+{
+ struct timens_offsets *ns_offsets = >nsproxy->time_ns->offsets;
+
+ return nsec + timespec64_to_ns(_offsets->boottime);
+}
+
ktime_t do_timens_ktime_to_host(clockid_t clockid, ktime_t tim,
struct timens_offsets *offsets);
@@ -130,6 +137,12 @@ static inline int timens_on_fork(struct nsproxy *nsproxy,
static inline void timens_add_monotonic(struct timespec64 *ts) { }
static inline void timens_add_boottime(struct timespec64 *ts) { }
+
+static inline u64 timens_add_boottime_ns(u64 nsec)
+{
+ return nsec;
+}
+
static inline ktime_t timens_ktime_to_host(clockid_t clockid, ktime_t tim)
{
return tim;
--
2.20.1
[PATCH v2 3/4] fs/proc: apply timens offset for start_boottime of processes
Since start_boottime of processes are seconds since boottime and the
boottime stamp is now shifted according to the timens offset, the
offset of the time namespace also needs to be applied before the
process stats are given to userspace.
This avoids that processes shown, e.g., by 'ps' appear as time
travelers in the corresponding time namespace.
Signed-off-by: Michael Weiß
---
fs/proc/array.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 65ec2029fa80..277f654f289e 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -533,8 +534,9 @@ static int do_task_stat(struct seq_file *m, struct
pid_namespace *ns,
priority = task_prio(task);
nice = task_nice(task);
- /* convert nsec -> ticks */
- start_time = nsec_to_clock_t(task->start_boottime);
+ /* apply timens offset for boottime and convert nsec -> ticks */
+ start_time =
+ nsec_to_clock_t(timens_add_boottime_ns(task->start_boottime));
seq_put_decimal_ull(m, "", pid_nr_ns(pid, ns));
seq_puts(m, " (");
--
2.20.1
[PATCH v2 0/4] time namespace aware system boot time
Time namespaces make it possible to virtualize time inside of containers, e.g., it is feasible to reset the uptime of a container to zero by setting the time namespace offset for boottime to the negated current value of the CLOCK_BOOTTIME. However, the boot time stamp provided by getboottime64() does not take care of time namespaces. The resulting boot time stamp 'btime' provided by /proc/stat does not show a plausible time stamp inside the time namespace of a container. We address this by shifting the value returned by getboottime64() by subtracting the boottime offset of the time namespace. (A selftest to check the expected /proc/stat 'btime' inside the namespace is provided.) Further, to avoid to show processes as time travelers inside of the time namespace the boottime offset then needs to be added to the start_bootime provided by the task_struct. v2 Changes: Fixed compile errors with TIME_NS not set in config Reported-by: kernel test robot Michael Weiß (4): timens: additional helper function to add boottime in nsec time: make getboottime64 aware of time namespace fs/proc: apply timens offset for start_boottime of processes selftests/timens: added selftest for /proc/stat btime fs/proc/array.c | 6 ++- include/linux/time_namespace.h | 13 ++ kernel/time/timekeeping.c | 3 ++ tools/testing/selftests/timens/procfs.c | 58 - 4 files changed, 77 insertions(+), 3 deletions(-) -- 2.20.1
Re: [PATCH v8 1/6] PCI/ERR: get device before call device driver to avoid NULL pointer dereference
On Thu, Oct 8, 2020 at 1:24 AM Kuppuswamy, Sathyanarayanan wrote: > > > On 10/7/20 4:31 AM, Ethan Zhao wrote: > > During DPC error injection test we found there is race condition between > > pciehp and DPC driver, NULL pointer dereference caused panic as following > > > > # setpci -s 64:02.0 0x196.w=000a > >// 64:02.0 is rootport has DPC capability > > # setpci -s 65:00.0 0x04.w=0544 > >// 65:00.0 is NVMe SSD populated in above port > > # mount /dev/nvme0n1p1 nvme > > > > (tested on stable 5.8 & ICS(Ice Lake SP platform, see > > https://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(server)) > > > > BUG: kernel NULL pointer dereference, address: 0050 > > ... > > CPU: 12 PID: 513 Comm: irq/124-pcie-dp Not tainted > > 5.8.0-0.0.7.el8.x86_64+ #1 > > RIP: 0010:report_error_detected.cold.4+0x7d/0xe6 > > Code: b6 d0 e8 e8 fe 11 00 e8 16 c5 fb ff be 06 00 00 00 48 89 df e8 d3 > > 65 ff > > ff b8 06 00 00 00 e9 75 fc ff ff 48 8b 43 68 45 31 c9 <48> 8b 50 50 48 83 > > 3a 00 > > 41 0f 94 c1 45 31 c0 48 85 d2 41 0f 94 c0 > > RSP: 0018:ff8e06cf8762fda8 EFLAGS: 00010246 > > RAX: RBX: ff4e3eaacf42a000 RCX: ff4e3eb31f223c01 > > RDX: ff4e3eaacf42a140 RSI: ff4e3eb31f223c00 RDI: ff4e3eaacf42a138 > > RBP: ff8e06cf8762fdd0 R08: 00bf R09: > > R10: 00eb8ebeab53 R11: 93453258 R12: 0002 > > R13: ff4e3eaacf42a130 R14: ff8e06cf8762fe2c R15: ff4e3eab44733828 > > FS: () GS:ff4e3eab1fd0() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0050 CR3: 000f8f80a004 CR4: 00761ee0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > PKRU: 5554 > > Call Trace: > > ? report_normal_detected+0x20/0x20 > > report_frozen_detected+0x16/0x20 > > pci_walk_bus+0x75/0x90 > > ? dpc_irq+0x90/0x90 > > pcie_do_recovery+0x157/0x201 > > ? irq_finalize_oneshot.part.47+0xe0/0xe0 > > dpc_handler+0x29/0x40 > > irq_thread_fn+0x24/0x60 > > ... > > > > Debug shows when port DPC feature was enabled and triggered by errors, > > DLLSC/PDC/DPC interrupts will be sent to pciehp and DPC driver almost > > at the same time, and no delay between them is required by specification. > > so DPC driver and pciehp drivers may handle these interrupts cocurrently. > > > > While DPC driver is doing pci_walk_bus() and calling device driver's > > callback without pci_dev_get() to increase device reference count, the > > device and its driver instance are likely being freed by > > pci_stop_and_removed_bus_device() > > -> pci_dev_put(). > > > > So does pci_dev_get() before using the device instance to avoid NULL > > pointer dereference. > Won't it be better if you get this in pcie_do_recovery()? Don't think so, just like lock, we should keep the scope with lock protected as small as possible. Locking a big area unnecessarily isn't acceptable. Thanks, Ethan > > > > Signed-off-by: Ethan Zhao > > Tested-by: Wen Jin > > Tested-by: Shanshan Zhang > > --- > > Changes: > > v2: revise doc according to Andy's suggestion. > > v3: no change. > > v4: no change. > > v5: no change. > > v6: moved to [1/5] from [3/5] and revised comment according to Lukas' > > suggestion. > > v7: no change. > > v8: no change. > > > > drivers/pci/pcie/err.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c > > index c543f419d8f9..e35c4480c86b 100644 > > --- a/drivers/pci/pcie/err.c > > +++ b/drivers/pci/pcie/err.c > > @@ -52,6 +52,8 @@ static int report_error_detected(struct pci_dev *dev, > > pci_ers_result_t vote; > > const struct pci_error_handlers *err_handler; > > > > + if (!pci_dev_get(dev)) > > + return 0; > > device_lock(>dev); > > if (!pci_dev_set_io_state(dev, state) || > > !dev->driver || > > @@ -76,6 +78,7 @@ static int report_error_detected(struct pci_dev *dev, > > pci_uevent_ers(dev, vote); > > *result = merge_result(*result, vote); > > device_unlock(>dev); > > + pci_dev_put(dev); > > return 0; > > } > > > > @@ -94,6 +97,8 @@ static int report_mmio_enabled(struct pci_dev *dev, void > > *data) > > pci_ers_result_t vote, *result = data; > > const struct pci_error_handlers *err_handler; > > > > + if (!pci_dev_get(dev)) > > + return 0; > > device_lock(>dev); > > if (!dev->driver || > > !dev->driver->err_handler || > > @@ -105,6 +110,7 @@ static int report_mmio_enabled(struct pci_dev *dev, > > void *data) > > *result = merge_result(*result, vote); > > out: > > device_unlock(>dev); > > + pci_dev_put(dev); > > return 0; > > } > > > > @@ -113,6 +119,8 @@ static int report_slot_reset(struct pci_dev
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Wed, Oct 7, 2020 at 12:44 AM Dan Carpenter wrote:
>
> Hi John,
>
> url:
> https://github.com/0day-ci/linux/commits/John-Stultz/dma-buf-Performance-improvements-for-system-heap-a-system-uncached-implementation/20201003-120520
> base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> bcf876870b95592b52519ed4aafcf9d95999bc9c
> config: i386-randconfig-m021-20201002 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
>
> smatch warnings:
> drivers/dma-buf/heaps/system_heap.c:496 system_heap_create() warn: passing
> zero to 'PTR_ERR'
>
> vim +/PTR_ERR +496 drivers/dma-buf/heaps/system_heap.c
>
> efa04fefebbd724 John Stultz 2019-12-03 478 static int
> system_heap_create(void)
> efa04fefebbd724 John Stultz 2019-12-03 479 {
> efa04fefebbd724 John Stultz 2019-12-03 480 struct
> dma_heap_export_info exp_info;
> efa04fefebbd724 John Stultz 2019-12-03 481
> 263e38f82cbb35b Andrew F. Davis 2019-12-16 482 exp_info.name =
> "system";
> efa04fefebbd724 John Stultz 2019-12-03 483 exp_info.ops =
> _heap_ops;
> efa04fefebbd724 John Stultz 2019-12-03 484 exp_info.priv = NULL;
> efa04fefebbd724 John Stultz 2019-12-03 485
> efa04fefebbd724 John Stultz 2019-12-03 486 sys_heap =
> dma_heap_add(_info);
> efa04fefebbd724 John Stultz 2019-12-03 487 if (IS_ERR(sys_heap))
> a2e10cdd2e4d12a John Stultz 2020-10-03 488 return
> PTR_ERR(sys_heap);
> efa04fefebbd724 John Stultz 2019-12-03 489
> 553f4e0fafc5b3b John Stultz 2020-10-03 490 exp_info.name =
> "system-uncached";
> 553f4e0fafc5b3b John Stultz 2020-10-03 491 exp_info.ops =
> _uncached_heap_ops;
> 553f4e0fafc5b3b John Stultz 2020-10-03 492 exp_info.priv = NULL;
> 553f4e0fafc5b3b John Stultz 2020-10-03 493
> 553f4e0fafc5b3b John Stultz 2020-10-03 494 sys_uncached_heap =
> dma_heap_add(_info);
> 553f4e0fafc5b3b John Stultz 2020-10-03 495 if
> (IS_ERR(sys_uncached_heap))
> 553f4e0fafc5b3b John Stultz 2020-10-03 @496 return
> PTR_ERR(sys_heap);
>
> ^
> This should be return PTR_ERR(sys_uncached_heap);
Oh nice! Very impressed that the tool caught that!
Thanks so much for the report! I'll fix it up here shortly.
-john
Re: [PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
On 08/10/2020 06:16, Srinivasa Rao Mandadapu wrote: These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V10: -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to lpass.h changes since V9: -- Removed unused structures lpass_hdmi.h changes since V8: -- Removed redundant structure wrapper for reg map field memebrs -- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true and others as false. changes since V7: -- Fixed typo errors -- Created Separate patch for buffer size change changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (7): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile| 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 249 - sound/soc/qcom/lpass-hdmi.c| 258 ++ sound/soc/qcom/lpass-hdmi.h| 102 ++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- sound/soc/qcom/lpass-platform.c| 395 + sound/soc/qcom/lpass-sc7180.c | 116 +- sound/soc/qcom/lpass.h | 124 ++- 13 files changed, 1240 insertions(+), 143 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h Tested this series on DragonBoard 410c Tested-by: Srinivas Kandagatla Reviewed-by: Srinivas Kandagatla
Re: [PATCH v11 5/7] ASoC: qcom: Add support for lpass hdmi driver
On 08/10/2020 06:17, Srinivasa Rao Mandadapu wrote: From: V Sujith Kumar Reddy Upadate lpass cpu and platform driver to support audio over dp. Also add lpass-hdmi.c and lpass-hdmi.h. Signed-off-by: V Sujith Kumar Reddy Signed-off-by: Srinivasa Rao --- sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 247 - sound/soc/qcom/lpass-hdmi.c | 258 ++ sound/soc/qcom/lpass-hdmi.h | 102 +++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 49 +++-- sound/soc/qcom/lpass-platform.c | 383 --- sound/soc/qcom/lpass.h | 118 +++- 10 files changed, 1075 insertions(+), 97 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h Reviewed-by: Srinivas Kandagatla
Re: [PATCH] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
Em Wed, 7 Oct 2020 19:52:56 -0700 Randy Dunlap escreveu: > On 10/7/20 7:18 PM, Nathan Chancellor wrote: > > On Wed, Oct 07, 2020 at 07:09:54AM +0200, Mauro Carvalho Chehab wrote: > >> As warned by Randy: > >> > >>on x86_64: > >>CONFIG_USB_ROLE_SWITCH=m > >>and HISI_HIKEY_USB=y. > >> > >>ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': > >>hisi_hikey_usb.c:(.text+0x61): undefined reference to > >> `usb_role_switch_unregister' > >>ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to > >> `usb_role_switch_put' > >>ld: drivers/misc/hisi_hikey_usb.o: in function > >> `hub_usb_role_switch_set': > >>hisi_hikey_usb.c:(.text+0xd3): undefined reference to > >> `usb_role_switch_get_drvdata' > >>ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': > >>hisi_hikey_usb.c:(.text+0x54d): undefined reference to > >> `usb_role_switch_set_role' > >>ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': > >>hisi_hikey_usb.c:(.text+0x8a5): undefined reference to > >> `usb_role_switch_get' > >>ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to > >> `usb_role_switch_register' > >>ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to > >> `usb_role_switch_put' > >> > >> Make it dependent on CONFIG_USB_ROLE_SWITCH. > >> > >> Reported-by: Randy Dunlap > >> Signed-off-by: Mauro Carvalho Chehab > >> --- > >> drivers/misc/Kconfig | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > >> index e19e1dcceb41..7cee2b72c09e 100644 > >> --- a/drivers/misc/Kconfig > >> +++ b/drivers/misc/Kconfig > >> @@ -459,6 +459,7 @@ config PVPANIC > >> config HISI_HIKEY_USB > >>tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" > >>depends on (OF && GPIOLIB) || COMPILE_TEST > >> + depends on CONFIG_USB_ROLE_SWITCH > > > > Shouldn't this be > > > > depends on USB_ROLE_SWITCH > > Obviously. Thanks for catching that. > > > ? Now it will never be selectable. Thanks for catching this one! Sent a v2 fixing this. (and double-checked that the driver was built after the changes). Thanks, Mauro
Re: [PATCH v2 0/5] PCI: dwc: improve msi handling
On 10/6/2020 12:06 PM, Jisheng Zhang wrote: External email: Use caution opening links or attachments On Tue, 6 Oct 2020 11:56:34 +0530 Vidya Sagar wrote: Hi, Hi, I would like to verify this series along with the other series "PCI: dwc: fix two MSI issues" on Tegra194. I tried to apply these series on both linux-next and Lorenzo's pci/dwc branches but there seem to be non trivial conflicts. Could you please tell me which branch I can use and apply these series cleanly? This is a fix, so I thought the series would be picked up in v5.9, so the series is patched against v5.9-rcN could you please try v5 https://lkml.org/lkml/2020/9/29/2511 on v5.9-rc7? I tried this series on top of v5.9-rc7 and it worked as expected on Tegra194 platform. Also, I couldn't cleanly apply the other series 'PCI: dwc: fix two MSI issues' on top. Could you please rebase them? Thanks, Vidya Sagar Thanks FWIW, I acknowledge that the existing code does leak MSI target page every time system goes through suspend-resume sequence on Tegra194. Thanks, Vidya Sagar On 9/24/2020 4:35 PM, Jisheng Zhang wrote: External email: Use caution opening links or attachments Improve the msi code: 1. Add proper error handling. 2. Move dw_pcie_msi_init() from each users to designware host to solve msi page leakage in resume path. Since v1: - add proper error handling patches. - solve the msi page leakage by moving dw_pcie_msi_init() from each users to designware host Jisheng Zhang (5): PCI: dwc: Call dma_unmap_page() before freeing the msi page PCI: dwc: Check alloc_page() return value PCI: dwc: Rename dw_pcie_free_msi to dw_pcie_msi_deinit PCI: dwc: Skip PCIE_MSI_INTR0* programming if MSI is disabled PCI: dwc: Move dw_pcie_msi_init() from each users to designware host drivers/pci/controller/dwc/pci-dra7xx.c | 1 + drivers/pci/controller/dwc/pci-exynos.c | 2 - drivers/pci/controller/dwc/pci-imx6.c | 3 -- drivers/pci/controller/dwc/pci-meson.c| 8 drivers/pci/controller/dwc/pcie-artpec6.c | 10 - .../pci/controller/dwc/pcie-designware-host.c | 43 +-- .../pci/controller/dwc/pcie-designware-plat.c | 3 -- drivers/pci/controller/dwc/pcie-designware.h | 9 +++- drivers/pci/controller/dwc/pcie-histb.c | 3 -- drivers/pci/controller/dwc/pcie-kirin.c | 3 -- drivers/pci/controller/dwc/pcie-qcom.c| 3 -- drivers/pci/controller/dwc/pcie-spear13xx.c | 1 - drivers/pci/controller/dwc/pcie-tegra194.c| 2 - drivers/pci/controller/dwc/pcie-uniphier.c| 9 +--- 14 files changed, 38 insertions(+), 62 deletions(-) -- 2.28.0
[PATCH v2] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
As warned by Randy: on x86_64: CONFIG_USB_ROLE_SWITCH=m and HISI_HIKEY_USB=y. ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': hisi_hikey_usb.c:(.text+0x61): undefined reference to `usb_role_switch_unregister' ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to `usb_role_switch_put' ld: drivers/misc/hisi_hikey_usb.o: in function `hub_usb_role_switch_set': hisi_hikey_usb.c:(.text+0xd3): undefined reference to `usb_role_switch_get_drvdata' ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': hisi_hikey_usb.c:(.text+0x54d): undefined reference to `usb_role_switch_set_role' ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': hisi_hikey_usb.c:(.text+0x8a5): undefined reference to `usb_role_switch_get' ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to `usb_role_switch_register' ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to `usb_role_switch_put' Make it dependent on CONFIG_USB_ROLE_SWITCH. Reported-by: Randy Dunlap Signed-off-by: Mauro Carvalho Chehab --- drivers/misc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index e19e1dcceb41..d5ce8082b0a0 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -459,6 +459,7 @@ config PVPANIC config HISI_HIKEY_USB tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" depends on (OF && GPIOLIB) || COMPILE_TEST + depends on USB_ROLE_SWITCH help If you say yes here this adds support for the on-board USB GPIO hub found on HiKey 960/970 boards, which is necessary to support -- 2.26.2
Re: [PATCH] docs: Make automarkup ready for Sphinx 3.1+
Hi Nícolas,
Em Wed, 07 Oct 2020 23:12:25 +
Nícolas F. R. A. Prado escreveu:
> While Sphinx 2 used a single c:type role for struct, union, enum and
> typedef, Sphinx 3 uses a specific role for each one.
> To keep backward compatibility, detect the Sphinx version and use the
> correct roles for that version.
>
> Also, Sphinx 3 is more strict with its C domain and generated warnings,
> exposing issues in the parsing.
> To fix the warnings, make the C regexes use ASCII, ensure the
> expressions only match the beginning of words and skip trying to
> cross-reference C reserved words.
>
> Signed-off-by: Nícolas F. R. A. Prado
> ---
>
> Hi,
>
> after Mauro's series making everything ready for Sphinx 3.1, only the
> automarkup
> was left to be ported.
> This patch makes the needed changes to automarkup so that we can soon flip the
> switch to Sphinx 3.1.
>
> This change was tested both with Sphinx 2.4.4 and Sphinx 3.1.
>
> This change doesn't add any warnings to the Documentation build.
> I tested it with Mauro's series but later rebased it to docs-next, and it can
> be
> accepted independently of that series.
>
> I ended up doing more than one thing in this single patch, but since it was
> all
> changing the same lines and for the same purpose, I felt it would be better to
> keep it as a single commit.
>
Thanks for doing this! That was the last missing part on fully supporting
Sphinx 3.1+.
> Mauro,
> if this patch is ok, the 3rd patch in your series, which disables automarkup
> for
> sphinx 3, should be dropped.
Yeah, sure.
> Although I'm not sure what the implications of your patches adding namespaces
> and using the c:macro for functions are.
With regards to namespaces:
Currently, only the media docs use namespaces, and it declares it at the
beginning of each file that needs it, without overriding it later[1].
[1] btw, the cdomain.py backward compat code doesn't support namespace
changes - as it parses namespaces before handling the C domain tags.
I doubt that we'll need to have a single .rst file using more than
one namespace anyway.
The main usage is to avoid conflicts for uAPI documentation for
syscalls - actually for libc userspace wrappers to syscalls. It documents
things like: open, close, read, write, ioctl, poll, select.
I'm not sure if the automarkup should be aware of it, or if the c.py code
at Sphinx 3.x will add the namespace automatically, but I suspect that
automarkup will need to handle it as well.
One file you could use for checking it is this one:
Documentation/userspace-api/media/v4l/hist-v4l2.rst
It contains a namespace directive and documents what changed without
using any explicit reference (after my patch series + linux-next).
With regards to c:macro vs c:function:
I suspect that automarkup should test both when trying to do
cross-references for function-like calls. E. g. test first if
there is a :c:function, falling back to check for :c:macro.
I would add a "sphinx3_c_func_ref" function that would handle
such special case, e. g. something like:
markup_func_sphinx3 = {RE_doc: markup_doc_ref,
RE_function: sphinx3_c_func_ref,
RE_struct: markup_c_ref,
RE_union: markup_c_ref,
RE_enum: markup_c_ref,
RE_typedef: markup_c_ref}
> All I did here was use the specific roles for sphinx 3 and fix the warnings,
> but
> that was enough to get correct cross-references even after your series.
>
> Thanks,
> Nícolas
>
>
> Documentation/sphinx/automarkup.py | 69 ++
> 1 file changed, 60 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/sphinx/automarkup.py
> b/Documentation/sphinx/automarkup.py
> index a1b0f554cd82..fd1e927408ad 100644
> --- a/Documentation/sphinx/automarkup.py
> +++ b/Documentation/sphinx/automarkup.py
> @@ -22,13 +22,34 @@ from itertools import chain
> # :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
> # bit tries to restrict matches to things that won't create trouble.
> #
> -RE_function = re.compile(r'(([\w_][\w\d_]+)\(\))')
> -RE_type = re.compile(r'(struct|union|enum|typedef)\s+([\w_][\w\d_]+)')
> +RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII)
> +
> +#
> +# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
> +#
> +RE_generic_type =
> re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
> + flags=re.ASCII)
> +
> +#
> +# Sphinx 3 uses a different C role for each one of struct, union, enum and
> +# typedef
> +#
> +RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
> +
> #
> # Detects a reference to a
[PATCH v11 6/7] Asoc: qcom: lpass-platform : Increase buffer size
From: V Sujith Kumar Reddy
Increase buffer size to support audio over DP.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
sound/soc/qcom/lpass-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 49abbb2..36d1512 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -23,7 +23,7 @@ struct lpass_pcm_data {
int i2s_port;
};
-#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_BUFFER_SIZE (24 * 2 * 1024)
#define LPASS_PLATFORM_PERIODS 2
static const struct snd_pcm_hardware lpass_platform_pcm_hardware = {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 5/7] ASoC: qcom: Add support for lpass hdmi driver
From: V Sujith Kumar Reddy
Upadate lpass cpu and platform driver to support audio over dp.
Also add lpass-hdmi.c and lpass-hdmi.h.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/Kconfig | 5 +
sound/soc/qcom/Makefile | 2 +
sound/soc/qcom/lpass-apq8016.c | 4 +-
sound/soc/qcom/lpass-cpu.c | 247 -
sound/soc/qcom/lpass-hdmi.c | 258 ++
sound/soc/qcom/lpass-hdmi.h | 102 +++
sound/soc/qcom/lpass-ipq806x.c | 4 +-
sound/soc/qcom/lpass-lpaif-reg.h | 49 +++--
sound/soc/qcom/lpass-platform.c | 383 ---
sound/soc/qcom/lpass.h | 118 +++-
10 files changed, 1075 insertions(+), 97 deletions(-)
create mode 100644 sound/soc/qcom/lpass-hdmi.c
create mode 100644 sound/soc/qcom/lpass-hdmi.h
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index a7ef626..28e775f 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -12,6 +12,10 @@ config SND_SOC_LPASS_CPU
tristate
select REGMAP_MMIO
+config SND_SOC_LPASS_HDMI
+ tristate
+ select REGMAP_MMIO
+
config SND_SOC_LPASS_PLATFORM
tristate
select REGMAP_MMIO
@@ -30,6 +34,7 @@ config SND_SOC_LPASS_SC7180
tristate
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
+ select SND_SOC_LPASS_HDMI
config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 7972c94..0bd90d7 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -1,12 +1,14 @@
# SPDX-License-Identifier: GPL-2.0
# Platform
snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-hdmi-objs := lpass-hdmi.o
snd-soc-lpass-platform-objs := lpass-platform.o
snd-soc-lpass-ipq806x-objs := lpass-ipq806x.o
snd-soc-lpass-apq8016-objs := lpass-apq8016.o
snd-soc-lpass-sc7180-objs := lpass-sc7180.o
obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_HDMI) += snd-soc-lpass-hdmi.o
obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
obj-$(CONFIG_SND_SOC_LPASS_IPQ806X) += snd-soc-lpass-ipq806x.o
obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 5c8ae22..0aedb3a 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -125,7 +125,7 @@ static struct snd_soc_dai_driver
apq8016_lpass_cpu_dai_driver[] = {
};
static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
- int direction)
+ int direction, unsigned int dai_id)
{
struct lpass_variant *v = drvdata->variant;
int chan = 0;
@@ -151,7 +151,7 @@ static int apq8016_lpass_alloc_dma_channel(struct
lpass_data *drvdata,
return chan;
}
-static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int
chan, unsigned int dai_id)
{
clear_bit(chan, >dma_ch_bit_map);
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 12950d2..ba2aca3 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -478,6 +478,206 @@ static struct regmap_config lpass_cpu_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static int lpass_hdmi_init_bitfields(struct device *dev, struct regmap *map)
+{
+ struct lpass_data *drvdata = dev_get_drvdata(dev);
+ struct lpass_variant *v = drvdata->variant;
+ unsigned int i;
+ struct lpass_hdmi_tx_ctl *tx_ctl;
+ struct regmap_field *legacy_en;
+ struct lpass_vbit_ctrl *vbit_ctl;
+ struct regmap_field *tx_parity;
+ struct lpass_dp_metadata_ctl *meta_ctl;
+ struct lpass_sstream_ctl *sstream_ctl;
+ struct regmap_field *ch_msb;
+ struct regmap_field *ch_lsb;
+ struct lpass_hdmitx_dmactl *tx_dmactl;
+ int rval;
+
+ tx_ctl = devm_kzalloc(dev, sizeof(*tx_ctl), GFP_KERNEL);
+ if (!tx_ctl)
+ return -ENOMEM;
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->soft_reset, tx_ctl->soft_reset);
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->force_reset, tx_ctl->force_reset);
+ drvdata->tx_ctl = tx_ctl;
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->legacy_en, legacy_en);
+ drvdata->hdmitx_legacy_en = legacy_en;
+
+ vbit_ctl = devm_kzalloc(dev, sizeof(*vbit_ctl), GFP_KERNEL);
+ if (!vbit_ctl)
+ return -ENOMEM;
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->replace_vbit,
vbit_ctl->replace_vbit);
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->vbit_stream,
vbit_ctl->vbit_stream);
+ drvdata->vbit_ctl = vbit_ctl;
+
+
+ QCOM_REGMAP_FIELD_ALLOC(dev, map, v->calc_en, tx_parity);
+
[PATCH v11 1/7] ASoC: Add sc7180-lpass binding header hdmi define
From: V Sujith Kumar Reddy Add header defining hdmi dai-id for SC7180 lpass soc in dt bindings. Signed-off-by: V Sujith Kumar Reddy Acked-by: Rob Herring Signed-off-by: Srinivasa Rao --- include/dt-bindings/sound/sc7180-lpass.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/sound/sc7180-lpass.h b/include/dt-bindings/sound/sc7180-lpass.h index 7d988f6..56ecaaf 100644 --- a/include/dt-bindings/sound/sc7180-lpass.h +++ b/include/dt-bindings/sound/sc7180-lpass.h @@ -4,6 +4,7 @@ #define MI2S_PRIMARY 0 #define MI2S_SECONDARY 1 +#define LPASS_DP_RX2 #define LPASS_MCLK00 -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V10: -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to lpass.h changes since V9: -- Removed unused structures lpass_hdmi.h changes since V8: -- Removed redundant structure wrapper for reg map field memebrs -- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true and others as false. changes since V7: -- Fixed typo errors -- Created Separate patch for buffer size change changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (7): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile| 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 249 - sound/soc/qcom/lpass-hdmi.c| 258 ++ sound/soc/qcom/lpass-hdmi.h| 102 ++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- sound/soc/qcom/lpass-platform.c| 395 + sound/soc/qcom/lpass-sc7180.c | 116 +- sound/soc/qcom/lpass.h | 124 ++- 13 files changed, 1240 insertions(+), 143 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 3/7] Asoc:qcom:lpass-cpu:Update dts property read API
From: V Sujith Kumar Reddy
Update dts property read API call with platform get property
by name, as it make code more readable and avoid conflicts
when array of properties to be used.
Signed-off-by: V Sujith Kumar Reddy
Reviewed-by: Srinivas Kandagatla
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/lpass-cpu.c | 2 +-
sound/soc/qcom/lpass-platform.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 0718a0f..12950d2 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -575,7 +575,7 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
platform_device *pdev)
of_lpass_cpu_parse_dai_data(dev, drvdata);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpass-lpaif");
drvdata->lpaif = devm_ioremap_resource(dev, res);
if (IS_ERR((void const __force *)drvdata->lpaif)) {
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 7ac2629..e7cf4e5 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -621,7 +621,7 @@ int asoc_qcom_lpass_platform_register(struct
platform_device *pdev)
struct lpass_variant *v = drvdata->variant;
int ret;
- drvdata->lpaif_irq = platform_get_irq(pdev, 0);
+ drvdata->lpaif_irq = platform_get_irq_byname(pdev, "lpass-irq-lpaif");
if (drvdata->lpaif_irq < 0)
return -ENODEV;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC PATCH v3 2/2] mm: remove extra ZONE_DEVICE struct page refcount
On Thu, Oct 01, 2020 at 11:17:15AM -0700, Ralph Campbell wrote: > ZONE_DEVICE struct pages have an extra reference count that complicates the > code for put_page() and several places in the kernel that need to check the > reference count to see that a page is not being used (gup, compaction, > migration, etc.). Clean up the code so the reference count doesn't need to > be treated specially for ZONE_DEVICE. I was hoping this patch would resolve a page-reference issue that we run into at random times while migrating a page to a device page backed by secure-memory. Unfortunately I continue to see the problem. There is a reference held on that page, which fails the migration. FYI RP
[PATCH v11 4/7] Asoc: qcom: lpass:Update lpaif_dmactl members order
From: V Sujith Kumar Reddy
Update the lpaif_dmactl struct members order to match
HDMI reg map members sequence. Separate Interface reg map
as it is used for I2S control but not for HDMI control,
to make use of bulk API, which makes code more readable.
Signed-off-by: V Sujith Kumar Reddy
Reviewed-by: Srinivas Kandagatla
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/lpass-platform.c | 8
sound/soc/qcom/lpass.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index e7cf4e5..db0d959 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -71,13 +71,13 @@ static int lpass_platform_alloc_dmactl_fields(struct device
*dev,
rd_dmactl = drvdata->rd_dmactl;
wr_dmactl = drvdata->wr_dmactl;
- rval = devm_regmap_field_bulk_alloc(dev, map, _dmactl->bursten,
- >rdma_bursten, 6);
+ rval = devm_regmap_field_bulk_alloc(dev, map, _dmactl->intf,
+ >rdma_intf, 6);
if (rval)
return rval;
- return devm_regmap_field_bulk_alloc(dev, map, _dmactl->bursten,
- >wrdma_bursten, 6);
+ return devm_regmap_field_bulk_alloc(dev, map, _dmactl->intf,
+ >wrdma_intf, 6);
}
static int lpass_platform_pcmops_open(struct snd_soc_component *component,
diff --git a/sound/soc/qcom/lpass.h b/sound/soc/qcom/lpass.h
index 51c9991..7089d4c 100644
--- a/sound/soc/qcom/lpass.h
+++ b/sound/soc/qcom/lpass.h
@@ -31,9 +31,9 @@ struct lpaif_i2sctl {
struct lpaif_dmactl {
+ struct regmap_field *intf;
struct regmap_field *bursten;
struct regmap_field *wpscnt;
- struct regmap_field *intf;
struct regmap_field *fifowm;
struct regmap_field *enable;
struct regmap_field *dyncclk;
@@ -110,17 +110,17 @@ struct lpass_variant {
struct reg_field bitwidth;
/* RD_DMA Register fields */
+ struct reg_field rdma_intf;
struct reg_field rdma_bursten;
struct reg_field rdma_wpscnt;
- struct reg_field rdma_intf;
struct reg_field rdma_fifowm;
struct reg_field rdma_enable;
struct reg_field rdma_dyncclk;
/* WR_DMA Register fields */
+ struct reg_field wrdma_intf;
struct reg_field wrdma_bursten;
struct reg_field wrdma_wpscnt;
- struct reg_field wrdma_intf;
struct reg_field wrdma_fifowm;
struct reg_field wrdma_enable;
struct reg_field wrdma_dyncclk;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 2/7] ASoC: dt-bindings: Add dt binding for lpass hdmi
From: V Sujith Kumar Reddy
Adds bindings for lpass hdmi interface
which can support audio path over dp.
Signed-off-by: V Sujith Kumar Reddy
Reviewed-by: Rob Herring
Signed-off-by: Srinivasa Rao
---
.../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 +++---
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index 09c9bd2..f6f9fb4 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -24,9 +24,10 @@ properties:
- qcom,sc7180-lpass-cpu
reg:
-maxItems: 1
+maxItems: 2
description: LPAIF core registers
-
+ reg-names:
+ maxItems: 2
clocks:
minItems: 3
maxItems: 6
@@ -36,15 +37,16 @@ properties:
maxItems: 6
interrupts:
-maxItems: 1
+maxItems: 2
description: LPAIF DMA buffer interrupt
-
+ interrupt-names:
+maxItems: 2
qcom,adsp:
$ref: /schemas/types.yaml#/definitions/phandle
description: Phandle for the audio DSP node
iommus:
-maxItems: 1
+maxItems: 2
description: Phandle to apps_smmu node with sid mask
power-domains:
@@ -60,10 +62,12 @@ properties:
const: 0
patternProperties:
- "(^mi2s-[0-9a-f]$|mi2s)":
+ "^dai-link@[0-9a-f]$":
type: object
-description: Required properties for each DAI
-
+description: |
+ LPASS CPU dai node for each I2S device. Bindings of each node
+ depends on the specific driver providing the functionality and
+ properties.
properties:
reg:
maxItems: 1
@@ -85,9 +89,11 @@ patternProperties:
required:
- compatible
- reg
+ - reg-names
- clocks
- clock-names
- interrupts
+ - interrupt-names
- '#sound-dai-cells'
additionalProperties: false
@@ -134,13 +140,32 @@ allOf:
then:
properties:
clock-names:
- items:
-- const: pcnoc-sway-clk
-- const: audio-core
-- const: mclk0
-- const: pcnoc-mport-clk
-- const: mi2s-bit-clk0
-- const: mi2s-bit-clk1
+ oneOf:
+ - items: #for I2S
+ - const: pcnoc-sway-clk
+ - const: audio-core
+ - const: mclk0
+ - const: pcnoc-mport-clk
+ - const: mi2s-bit-clk0
+ - const: mi2s-bit-clk1
+ - items: #for HDMI
+ - const: pcnoc-sway-clk
+ - const: audio-core
+ - const: pcnoc-mport-clk
+reg-names:
+ anyOf:
+- items: #for I2S
+ - const: lpass-lpaif
+- items: #for I2S and HDMI
+ - const: lpass-hdmiif
+ - const: lpass-lpaif
+interrupt-names:
+ anyOf:
+- items: #for I2S
+ - const: lpass-irq-lpaif
+- items: #for I2S and HDMI
+ - const: lpass-irq-lpaif
+ - const: lpass-irq-hdmi
required:
- iommus
- power-domains
@@ -152,12 +177,15 @@ examples:
soc {
#address-cells = <2>;
#size-cells = <2>;
-lpass@62f0 {
+lpass@62d8 {
compatible = "qcom,sc7180-lpass-cpu";
-reg = <0 0x62f0 0 0x29000>;
-
-iommus = <_smmu 0x1020 0>;
+reg = <0 0x62d87000 0 0x68000>,
+ <0 0x62f0 0 0x29000>;
+reg-names = "lpass-hdmiif",
+"lpass-lpaif";
+iommus = <_smmu 0x1020 0>,
+ <_smmu 0x1032 0>;
power-domains = <_hm 0>;
clocks = < 131>,
@@ -171,14 +199,16 @@ examples:
"mclk0", "pcnoc-mport-clk",
"mi2s-bit-clk0", "mi2s-bit-clk1";
-interrupts = <0 160 1>;
-
+interrupts = <0 160 1>,
+ <0 268 1>;
+interrupt-names = "lpass-irq-lpaif",
+ "lpass-irq-hdmi";
#sound-dai-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
/* Optional to set different MI2S SD lines */
-mi2s-primary@0 {
+dai-link@0 {
reg = ;
qcom,playback-sd-lines = <1>;
qcom,capture-sd-lines = <0>;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v11 7/7] ASoC: qcom: sc7180: Add support for audio over DP
From: V Sujith Kumar Reddy
Add support for audio playback over DP in lpass
sc7180 platform driver. Update lpass_variant
structure for hdmi data configuaration.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao
---
sound/soc/qcom/lpass-sc7180.c | 116 +-
1 file changed, 102 insertions(+), 14 deletions(-)
diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index a8a3d8f..c6292f9e 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -60,38 +60,65 @@ static struct snd_soc_dai_driver
sc7180_lpass_cpu_dai_driver[] = {
.probe = _qcom_lpass_cpu_dai_probe,
.ops= _qcom_lpass_cpu_dai_ops,
},
+ [LPASS_DP_RX] = {
+ .id = LPASS_DP_RX,
+ .name = "Hdmi",
+ .playback = {
+ .stream_name = "Hdmi Playback",
+ .formats= SNDRV_PCM_FMTBIT_S24,
+ .rates = SNDRV_PCM_RATE_48000,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ .channels_min = 2,
+ .channels_max = 2,
+ },
+ .ops= _qcom_lpass_hdmi_dai_ops,
+ },
};
static int sc7180_lpass_alloc_dma_channel(struct lpass_data *drvdata,
- int direction)
+ int direction, unsigned int dai_id)
{
struct lpass_variant *v = drvdata->variant;
int chan = 0;
- if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
- chan = find_first_zero_bit(>dma_ch_bit_map,
- v->rdma_channels);
+ if (dai_id == LPASS_DP_RX) {
+ if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ chan =
find_first_zero_bit(>hdmi_dma_ch_bit_map,
+ v->hdmi_rdma_channels);
+
+ if (chan >= v->hdmi_rdma_channels)
+ return -EBUSY;
+ }
+ set_bit(chan, >hdmi_dma_ch_bit_map);
+ } else {
+ if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+ chan = find_first_zero_bit(>dma_ch_bit_map,
+ v->rdma_channels);
if (chan >= v->rdma_channels)
return -EBUSY;
- } else {
- chan = find_next_zero_bit(>dma_ch_bit_map,
+ } else {
+ chan = find_next_zero_bit(>dma_ch_bit_map,
v->wrdma_channel_start +
v->wrdma_channels,
v->wrdma_channel_start);
- if (chan >= v->wrdma_channel_start + v->wrdma_channels)
- return -EBUSY;
- }
-
- set_bit(chan, >dma_ch_bit_map);
+ if (chan >= v->wrdma_channel_start + v->wrdma_channels)
+ return -EBUSY;
+ }
+ set_bit(chan, >dma_ch_bit_map);
+ }
return chan;
}
-static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan,
unsigned int dai_id)
{
- clear_bit(chan, >dma_ch_bit_map);
+ if (dai_id == LPASS_DP_RX)
+ clear_bit(chan, >hdmi_dma_ch_bit_map);
+ else
+ clear_bit(chan, >dma_ch_bit_map);
return 0;
}
@@ -144,6 +171,9 @@ static struct lpass_variant sc7180_data = {
.rdma_reg_base = 0xC000,
.rdma_reg_stride= 0x1000,
.rdma_channels = 5,
+ .hdmi_rdma_reg_base = 0x64000,
+ .hdmi_rdma_reg_stride = 0x1000,
+ .hdmi_rdma_channels = 4,
.dmactl_audif_start = 1,
.wrdma_reg_base = 0x18000,
.wrdma_reg_stride = 0x1000,
@@ -163,7 +193,7 @@ static struct lpass_variant sc7180_data = {
.rdma_dyncclk = REG_FIELD_ID(0xC000, 21, 21, 5, 0x1000),
.rdma_bursten = REG_FIELD_ID(0xC000, 20, 20, 5, 0x1000),
.rdma_wpscnt= REG_FIELD_ID(0xC000, 16, 19, 5, 0x1000),
- .rdma_intf = REG_FIELD_ID(0xC000, 12, 15, 5, 0x1000),
+ .rdma_intf = REG_FIELD_ID(0xC000, 12, 15, 5,
0x1000),
.rdma_fifowm= REG_FIELD_ID(0xC000, 1, 5, 5, 0x1000),
.rdma_enable= REG_FIELD_ID(0xC000, 0, 0, 5, 0x1000),
@@ -174,6 +204,64 @@ static struct lpass_variant sc7180_data = {
.wrdma_fifowm = REG_FIELD_ID(0x18000, 1, 5, 4, 0x1000),
.wrdma_enable = REG_FIELD_ID(0x18000, 0, 0, 4, 0x1000),
+ .hdmi_tx_ctl_addr = 0x1000,
+ .hdmi_legacy_addr =
Re: [PATCH] mmc: meson-gx: remove IRQF_ONESHOT
On 7/10/2020 10:32 pm, Jerome Brunet wrote:
With arm64 defconfig on Khadas vim3, no obvious regression. Looks good.
Tested-by: Jerome Brunet
I did not test with RT. Brad, Could you let us know is Thomas's patch
works for you ? Thx
There was a merge conflict in applying against v5.9-rc8-rt12 with
particular this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/kernel/irq/manage.c?h=linux-5.9.y-rt=18df00ef0b2b1513dc8f1a9ed26b11fff2261c30
I did manage to add the patch after attempting to resolve the conflict
which solves the deadlock issue I am seeing with mmc and works fine during
testing (a kernel compilation on preempt_rt configured kernel).
irq_thread in /kernel/irq/manage.c Looks like this (not 100% sure I
should have placed the irq_finalize_oneshot before
add_interrupt_randomness).
Based on this I can provide
Tested-by: Brad Harper
---
static int irq_thread(void *data)
{
struct callback_head on_exit_work;
struct irqaction *action = data;
struct irq_desc *desc = irq_to_desc(action->irq);
irqreturn_t (*handler_fn)(struct irq_desc *desc,
struct irqaction *action);
if (force_irqthreads && test_bit(IRQTF_FORCED_THREAD,
>thread_flags))
handler_fn = irq_forced_thread_fn;
else
handler_fn = irq_thread_fn;
init_task_work(_exit_work, irq_thread_dtor);
task_work_add(current, _exit_work, false);
irq_thread_check_affinity(desc, action);
while (!irq_wait_for_interrupt(action)) {
irqreturn_t action_ret;
irq_thread_check_affinity(desc, action);
action_ret = handler_fn(desc, action);
if (action_ret == IRQ_HANDLED)
atomic_inc(>threads_handled);
if (action_ret == IRQ_WAKE_THREAD)
irq_wake_secondary(desc, action);
irq_finalize_oneshot(desc, action);
if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
migrate_disable();
add_interrupt_randomness(action->irq, 0,
desc->random_ip ^ (unsigned long) action);
migrate_enable();
}
wake_threads_waitq(desc);
}
/*
* This is the regular exit path. __free_irq() is stopping the
* thread via kthread_stop() after calling
* synchronize_hardirq(). So neither IRQTF_RUNTHREAD nor the
* oneshot mask bit can be set.
*/
task_work_cancel(current, irq_thread_dtor);
return 0;
}
---
Re: [PATCH v3 0/3] Support NVIDIA Tegra-based Ouya game console
07.10.2020 19:08, Stephen Warren пишет: ... > The facts[1] that Ouya published the code and that it used GPL-only > symbols certainly does imply that they *should* have published under GPL > or a compatible license, but doesn't mean that they definitely did. The > only way to know that for sure is for there to be evidence in the file > content or git history, such as license headers or Signed-off-by lines. The code wasn't only published, but also was distributed in a binary form to end users. This means that even if Ouya Inc. still existed and they made a mistake by using GPL-only symbols plus GPL-incompatible license for the driver, then they had to resilience the code. Hence either way it's okay to use downstream code as a reference for the upstream driver. This is my understanding.
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Mon, Oct 5, 2020 at 6:45 AM Christoph Hellwig wrote: > > How is this going to deal with VIVT caches? Hrm. That's a good question. I'm not sure I totally have my head around it but, I guess we could make sure to call invalidate_kernel_vmap_range() in begin_cpu_access() and flush_kernel_vmap_range() in end_cpu_access() rather then exiting out early as we do now? Unless you have better guidance? Worse case we could check CONFIG_CPU_CACHE_VIVT and not register the system-uncached heap. thanks -john
Re: [PATCH] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
On Wed, Oct 07, 2020 at 07:18:02PM -0700, Nathan Chancellor wrote:
> On Wed, Oct 07, 2020 at 07:09:54AM +0200, Mauro Carvalho Chehab wrote:
> > As warned by Randy:
> >
> > on x86_64:
> > CONFIG_USB_ROLE_SWITCH=m
> > and HISI_HIKEY_USB=y.
> >
> > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove':
> > hisi_hikey_usb.c:(.text+0x61): undefined reference to
> > `usb_role_switch_unregister'
> > ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to
> > `usb_role_switch_put'
> > ld: drivers/misc/hisi_hikey_usb.o: in function
> > `hub_usb_role_switch_set':
> > hisi_hikey_usb.c:(.text+0xd3): undefined reference to
> > `usb_role_switch_get_drvdata'
> > ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch':
> > hisi_hikey_usb.c:(.text+0x54d): undefined reference to
> > `usb_role_switch_set_role'
> > ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe':
> > hisi_hikey_usb.c:(.text+0x8a5): undefined reference to
> > `usb_role_switch_get'
> > ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to
> > `usb_role_switch_register'
> > ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to
> > `usb_role_switch_put'
> >
> > Make it dependent on CONFIG_USB_ROLE_SWITCH.
> >
> > Reported-by: Randy Dunlap
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/misc/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index e19e1dcceb41..7cee2b72c09e 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -459,6 +459,7 @@ config PVPANIC
> > config HISI_HIKEY_USB
> > tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform"
> > depends on (OF && GPIOLIB) || COMPILE_TEST
> > + depends on CONFIG_USB_ROLE_SWITCH
>
> Shouldn't this be
>
> depends on USB_ROLE_SWITCH
>
> ? Now it will never be selectable.
{sigh}
Yes, that is correct.
Mauro, can you send a fix-up patch for this, as your original is now in
my tree.
thanks,
greg k-h
Re: [v5 01/12] struct device: Add function callback durable_name
On Wed, Oct 07, 2020 at 03:10:17PM -0500, Tony Asleson wrote: > On 10/1/20 6:48 AM, Greg Kroah-Hartman wrote: > > On Wed, Sep 30, 2020 at 09:35:52AM -0500, Tony Asleson wrote: > >> On 9/30/20 2:38 AM, Greg Kroah-Hartman wrote: > >>> On Tue, Sep 29, 2020 at 05:04:32PM -0500, Tony Asleson wrote: > I'm trying to figure out a way to positively identify which storage > device an error belongs to over time. > >>> > >>> "over time" is not the kernel's responsibility. > >>> > >>> This comes up every 5 years or so. The kernel provides you, at runtime, > >>> a mapping between a hardware device and a "logical" device. It can > >>> provide information to userspace about this mapping, but once that > >>> device goes away, the kernel is free to reuse that logical device again. > >>> > >>> If you want to track what logical devices match up to what physical > >>> device, then do it in userspace, by parsing the log files. > >> > >> I don't understand why people think it's acceptable to ask user space to > >> parse text that is subject to change. > > > > What text is changing? The format of of the prefix of dev_*() is well > > known and has been stable for 15+ years now, right? What is difficult > > in parsing it? > > Many of the storage layer messages are using printk, not dev_printk. Ok, then stop right there. Fix that up. Don't try to route around the standard way of displaying log messages by creating a totally different way of doing things. Just use the dev_*() calls, and all will be fine. Kernel log messages are not "ABI" in that they have to be preserved in any specific way, so adding a prefix to them as dev_*() does, will be fine. thanks, greg k-h
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
In file included from include/linux/clk.h:13,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_update_palette':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/kernel.h:47:33: note: in definition of macro 'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/kernel.h:47:48: note: in definition of macro 'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|^~~
In file included from include/linux/bits.h:22,
from include/linux/bitops.h:5,
from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
include/linux/build_bug.h:16:51: error: bit-field '' width not an
integer constant
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
|^
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:453:9: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
453 | priv->dma_hwdescs->palette[i] = color;
|
linux-next: build warning after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: modpost: EXPORT symbol "copy_mc_fragile" [vmlinux] version generation
failed, symbol will not be versioned.
Probably introduced by commit
ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,
kernel}()")
--
Cheers,
Stephen Rothwell
pgp_n7zVbctPr.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] PCI: vmd: Enable ASPM for mobile platforms
> On Oct 7, 2020, at 21:30, Bjorn Helgaas wrote:
>
> On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
>>> On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
>>> On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> On Oct 3, 2020, at 06:18, Bjorn Helgaas wrote:
> On Wed, Sep 30, 2020 at 04:24:54PM +0800, Kai-Heng Feng wrote:
>
> ...
I wonder whether other devices that add PCIe domain have the same
behavior? Maybe it's not a special case at all...
>>>
>>> What other devices are these?
>>
>> Controllers which add PCIe domain.
>
> I was looking for specific examples, not just a restatement of what
> you said before. I'm just curious because there are a lot of
> controllers I'm not familiar with, and I can't think of an example.
>
I understand the end goal is to keep consistency for the entire ASPM
logic. However I can't think of any possible solution right now.
> - If we built with CONFIG_PCIEASPM_POWERSAVE=y, would that solve the
> SoC power state problem?
Yes.
> - What issues would CONFIG_PCIEASPM_POWERSAVE=y introduce?
This will break many systems, at least for the 1st Gen Ryzen
desktops and laptops.
All PCIe ASPM are not enabled by BIOS, and those systems immediately
freeze once ASPM is enabled.
>>>
>>> That indicates a defect in the Linux ASPM code. We should fix that.
>>> It should be safe to use CONFIG_PCIEASPM_POWERSAVE=y on every system.
>>
>> On those systems ASPM are also not enabled on Windows. So I think
>> ASPM are disabled for a reason.
>
> If the platform knows ASPM needs to be disabled, it should be using
> ACPI_FADT_NO_ASPM or _OSC to prevent the OS from using it. And if
> CONFIG_PCIEASPM_POWERSAVE=y means Linux enables ASPM when it
> shouldn't, that's a Linux bug that we need to fix.
Yes that's a bug which fixed by Ian's new patch.
>
>>> Are there bug reports for these? The info we would need to start with
>>> includes "lspci -vv" and dmesg log (with CONFIG_PCIEASPM_DEFAULT=y).
>>> If a console log with CONFIG_PCIEASPM_POWERSAVE=y is available, that
>>> might be interesting, too. We'll likely need to add some
>>> instrumentation and do some experimentation, but in principle, this
>>> should be fixable.
>>
>> Doing this is asking users to use hardware settings that ODM/OEM
>> never tested, and I think the risk is really high.
>
> What? That's not what I said at all. I'm asking for information
> about these hangs so we can fix them. I'm not suggesting that you
> should switch to CONFIG_PCIEASPM_POWERSAVE=y for the distro.
Ah, I thought your suggestion is switching to CONFIG_PCIEASPM_POWERSAVE=y,
because I sense you want to use that to cover the VMD ASPM this patch tries to
solve.
Do we have a conclusion how to enable VMD ASPM with CONFIG_PCIEASPM_DEFAULT=y?
>
> Let's back up. You said:
>
> CONFIG_PCIEASPM_POWERSAVE=y ... will break many systems, at least
> for the 1st Gen Ryzen desktops and laptops.
>
> All PCIe ASPM are not enabled by BIOS, and those systems immediately
> freeze once ASPM is enabled.
>
> These system hangs might be caused by (1) some hardware issue that
> causes a hang when ASPM is enabled even if it is configured correctly
> or (2) Linux configuring ASPM incorrectly.
It's (2) here.
>
> For case (1), the platform should be using ACPI_FADT_NO_ASPM or _OSC
> to prevent the OS from enabling ASPM. Linux should pay attention to
> that even when CONFIG_PCIEASPM_POWERSAVE=y.
>
> If the platform *should* use these mechanisms but doesn't, the
> solution is a quirk, not the folklore that "we can't use
> CONFIG_PCIEASPM_POWERSAVE=y because it breaks some systems."
The platform in question doesn't prevent OS from enabling ASPM.
>
> For case (2), we should fix Linux so it configures ASPM correctly.
>
> We cannot use the build-time CONFIG_PCIEASPM settings to avoid these
> hangs. We need to fix the Linux run-time code so the system operates
> correctly no matter what CONFIG_PCIEASPM setting is used.
>
> We have sysfs knobs to control ASPM (see 72ea91afbfb0 ("PCI/ASPM: Add
> sysfs attributes for controlling ASPM link states")). They can do the
> same thing at run-time as CONFIG_PCIEASPM_POWERSAVE=y does at
> build-time. If those knobs cause hangs on 1st Gen Ryzen systems, we
> need to fix that.
Ian's patch solves the issue, at least for the systems I have.
Kai-Heng
>
> Bjorn
Investment!
Greetings, I want to inform you that my principal's family wishes to make huge financial investment in your home Country on areas of oil and gas, real estate, tourism and hotel,manufacturing and production company,agriculture,fishing, Mining & Trading of natural resources such as crude oil, coal, graphite, coke,refinery,energy etc. We needs a capable, trust worthy and understanding business partner. Highly confidential and trusted partner to manage funds in proxy Three Hundred Million US Dollars(US$300M) for investment purposes. Must be a dedicated and honest business person Please, I will provide more details about the transaction if you are Willing to handle such project and also let you know your entitlement for the solicited role I shall be expecting your quick reply. Email: vpetrus...@gmail.com Best Regards, Petrus Vermeulen.
RE: [PATCH 1/2] usb: cdns3: Rids of duplicate error message
Hi Roger,
>
>On 07/10/2020 06:35, Pawel Laszczak wrote:
>> On failure, the platform_get_irq_byname prints an error message
>> so, patch removes error message related to this function from
>> core.c file.
>>
>> A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
>>
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/cdns3/core.c | 7 +--
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> index a0f73d4711ae..4fd3c742d9d5 100644
>> --- a/drivers/usb/cdns3/core.c
>> +++ b/drivers/usb/cdns3/core.c
>> @@ -469,9 +469,6 @@ static int cdns3_probe(struct platform_device *pdev)
>> if (cdns->dev_irq == -EPROBE_DEFER)
>
>if (cdns->dev_irq < 0 && cdns->dev_irq == -EPROBE_DEFER)
It's the same - cdns->dev_irq == -EPROBE_DEFER < 0
>> return cdns->dev_irq;
>>
>> -if (cdns->dev_irq < 0)
>> -dev_err(dev, "couldn't get peripheral irq\n");
>> -
>> regs = devm_platform_ioremap_resource_byname(pdev, "dev");
>> if (IS_ERR(regs))
>> return PTR_ERR(regs);
>> @@ -481,10 +478,8 @@ static int cdns3_probe(struct platform_device *pdev)
>> if (cdns->otg_irq == -EPROBE_DEFER)
>
>if (cdns->otg_irq < 0 && cdns->otg_irq == -EPROBE_DEFER)
It should be:
if (cdns->dev_irq < 0 || cdns->dev_irq == -EPROBE_DEFER)
or event
if (cdns->dev_irq < 0)
Am I right ?
>
>> return cdns->otg_irq;
>>
>> -if (cdns->otg_irq < 0) {
>> -dev_err(dev, "couldn't get otg irq\n");
>> +if (cdns->otg_irq < 0)
>
>you can then get rid of this if {}.
>
>> return cdns->otg_irq;
>> -}
>>
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
>> if (!res) {
>>
Cheers,
Pawell
[PATCH] misc: rtsx: rts522a support L1 substate
From: Ricky Wu
add rts522a L1 substate functions for kernel 5.4
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rts5227.c | 111 -
drivers/misc/cardreader/rtsx_pcr.c | 30
drivers/misc/cardreader/rtsx_pcr.h | 2 +
include/linux/rtsx_pci.h | 5 ++
4 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cardreader/rts5227.c
b/drivers/misc/cardreader/rts5227.c
index 3a9467aaa435..0d59106c7228 100644
--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -89,10 +89,73 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
+static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
+{
+ struct pci_dev *pdev = pcr->pci;
+ int l1ss;
+ u32 lval;
+ struct rtsx_cr_option *option = >option;
+
+ l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
+ if (!l1ss)
+ return;
+
+ pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, );
+
+ if (CHK_PCI_PID(pcr, 0x522A)) {
+ if (0 == (lval & 0x0F))
+ rtsx_pci_enable_oobs_polling(pcr);
+ else
+ rtsx_pci_disable_oobs_polling(pcr);
+ }
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
+ rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
+ rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
+ rtsx_set_dev_flag(pcr, PM_L1_1_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
+
+ if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
+ rtsx_set_dev_flag(pcr, PM_L1_2_EN);
+ else
+ rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
+
+ if (option->ltr_en) {
+ u16 val;
+
+ pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, );
+ if (val & PCI_EXP_DEVCTL2_LTR_EN) {
+ option->ltr_enabled = true;
+ option->ltr_active = true;
+ rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
+ } else {
+ option->ltr_enabled = false;
+ }
+ }
+
+ if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
+ | PM_L1_1_EN | PM_L1_2_EN))
+ option->force_clkreq_0 = false;
+ else
+ option->force_clkreq_0 = true;
+
+}
+
static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
{
u16 cap;
+ struct rtsx_cr_option *option = >option;
+ rts5227_init_from_cfg(pcr);
rtsx_pci_init_cmd(pcr);
/* Configure GPIO as output */
@@ -114,9 +177,17 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rts5227_fill_driving(pcr, OUTPUT_3V3);
/* Configure force_clock_req */
if (pcr->flags & PCR_REVERSE_SOCKET)
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x30);
+ else
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x00);
+
+ if (option->force_clkreq_0)
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW);
else
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
+ FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH);
+
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
@@ -372,6 +443,28 @@ static int rts522a_switch_output_voltage(struct rtsx_pcr
*pcr, u8 voltage)
return rtsx_pci_send_cmd(pcr, 100);
}
+static void rts522a_set_l1off_cfg_sub_d0(struct rtsx_pcr *pcr, int active)
+{
+ struct rtsx_cr_option *option = >option;
+ int aspm_L1_1, aspm_L1_2;
+ u8 val = 0;
+
+ aspm_L1_1 = rtsx_check_dev_flag(pcr, ASPM_L1_1_EN);
+ aspm_L1_2 = rtsx_check_dev_flag(pcr, ASPM_L1_2_EN);
+
+ if (active) {
+ /* run, latency: 60us */
+ if (aspm_L1_1)
+ val = option->ltr_l1off_snooze_sspwrgate;
+ } else {
+ /* l1off, latency: 300us */
+ if (aspm_L1_2)
+ val = option->ltr_l1off_sspwrgate;
+ }
+
+ rtsx_set_l1off_sub(pcr, val);
+}
+
/* rts522a operations mainly derived from rts5227, except phy/hw init setting.
*/
@@ -389,15 +482,29 @@ static const struct pcr_ops rts522a_pcr_ops = {
.cd_deglitch = NULL,
.conv_clk_and_div_n = NULL,
.force_power_down =
Re: [RFC V2] dt-bindings: mailbox : arm,mhuv2: Add bindings
Updated Morten's email id as he is no longer with ARM. On Wed, 7 Oct 2020 at 20:58, Viresh Kumar wrote: > > This patch adds device tree binding for ARM Message Handling Unit (MHU) > controller version 2. > > Based on earlier work by Morten Borup Petersen. > > Co-developed-by: Morten Borup Petersen > Signed-off-by: Morten Borup Petersen > Signed-off-by: Tushar Khandelwal > Signed-off-by: Viresh Kumar > > --- > Morten/Tushar, > > I have prepared this based on the best of my understanding about the > hardware, but since I haven't worked on the actual hardware yet there > are chances that I may have misunderstood some of it. Please lemme know > if any of my understanding is incorrect. > > Here is the link to the previous attempt by Tushar to get it upstreamed > long back: > > https://lore.kernel.org/lkml/20190717192616.1731-1-tushar.khandel...@arm.com/ > > This is very much a new approach and so I am not pointing out the > differences from the previous one. > > I haven't started with redesigning the driver as of now and would like > to get some feedback on the bindings first. Thanks in advance. > --- > .../bindings/mailbox/arm,mhuv2.yaml | 170 ++ > 1 file changed, 170 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > new file mode 100644 > index ..3cbdc97f1f4c > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > @@ -0,0 +1,170 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/arm,mhuv2.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM MHUv2 Mailbox Controller > + > +maintainers: > + - Morten Borup Petersen > + - Viresh Kumar > + > +description: | > + The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that > has > + between 1 and 124 channel windows (each 32-bit wide) to provide > unidirectional > + communication with remote processor(s), where the number of channel windows > + are implementation dependent. > + > + Given the unidirectional nature of the controller, an MHUv2 mailbox may > only > + be written to or read from. If a pair of MHU controllers is implemented > + between two processing elements to provide bidirectional communication, > these > + must be specified as two separate mailboxes. > + > + If the interrupts property is present in device tree node, then its > treated as > + a receiver mailbox, otherwise a sender. > + > + An MHU controller must be specified along with the supported transport > + protocols. The transport protocols determine the method of data > transmission > + as well as the number of provided mailbox channels. > + > + Following are the possible transport protocols. > + > + - Doorbell: Each transfer is made up of single bit flag, using any one of > the > +bits in a channel window. A channel window can support up to 32 doorbells > +and the entire window shall be used in doorbell mode. Optionally, data > may > +be transmitted through a shared memory region, wherein the MHU is used > +strictly as an interrupt generation mechanism but that is out of the > scope > +of these bindings. > + > + - Single-word: Each transfer is single word, using a single Channel window. > + > + - Multi-word: Each transfer is made of two or more words, using two or more > +channel windows. > + > +# We need a select here so we don't match all nodes with 'arm,primecell' > +select: > + properties: > +compatible: > + contains: > +const: arm,mhuv2 > + required: > +- compatible > + > +properties: > + compatible: > +items: > + - const: arm,mhuv2 > + - const: arm,primecell > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > + > + clock-names: > +items: > + - const: apb_pclk > + > + arm-mhuv2-mode: > +description: | > + The MHUv2 controller may contain up to 124 channel windows (each 32-bit > + wide). The hardware and the DT bindings allows any combination of > those to > + be used for various transport protocols. > + > + This property allows a platform to describe how these channel windows > are > + used in various transport protocols. The entries in this property > shall be > + present as an array of tuples, where each tuple describes details about > + one of the transport protocol being implemented over some channel > + window(s). > + > + The first field of a tuple signifies the transfer protocol, 0 is > reserved > + for doorbell protocol, 1 is reserved for single-word protocol and 2 is > + reserved for multi-word protocol. Using any other value in the first > field > + of a tuple makes it
[tip:ras/core] BUILD SUCCESS 300638101329e8f1569115f3d7197ef5ef754a3a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras/core branch HEAD: 300638101329e8f1569115f3d7197ef5ef754a3a x86/mce: Decode a kernel instruction to determine if it is copying from user elapsed time: 723m configs tested: 115 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig m68kq40_defconfig arm64alldefconfig armrealview_defconfig arm pxa255-idp_defconfig microblaze mmu_defconfig mips bigsur_defconfig powerpc eiger_defconfig mips rbtx49xx_defconfig arm tegra_defconfig powerpcicon_defconfig mipsmalta_qemu_32r6_defconfig armmagician_defconfig powerpc tqm8540_defconfig powerpc maple_defconfig arm zx_defconfig sh rts7751r2dplus_defconfig m68kstmark2_defconfig arm colibri_pxa300_defconfig sh rsk7203_defconfig sh urquell_defconfig powerpc mpc834x_itxgp_defconfig powerpc asp8347_defconfig sh secureedge5410_defconfig arm tango4_defconfig powerpc canyonlands_defconfig h8300 defconfig h8300 h8s-sim_defconfig m68k m5249evb_defconfig xtensasmp_lx200_defconfig armkeystone_defconfig mips pic32mzda_defconfig mips rb532_defconfig arm mv78xx0_defconfig arm assabet_defconfig powerpc tqm8548_defconfig armclps711x_defconfig arm ep93xx_defconfig sh ul2_defconfig sh r7780mp_defconfig microblaze defconfig mips ip22_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20201008 x86_64 randconfig-a003-20201008 x86_64 randconfig-a005-20201008 x86_64 randconfig-a001-20201008 x86_64 randconfig-a002-20201008 x86_64 randconfig-a006-20201008 i386 randconfig-a006-20201008 i386 randconfig-a005-20201008 i386 randconfig-a001-20201008 i386 randconfig-a004-20201008 i386 randconfig-a002-20201008 i386 randconfig-a003-20201008 i386 randconfig-a015-20201008 i386 randconfig-a013-20201008 i386 randconfig-a014-20201008 i386 randconfig-a016-20201008 i386 randconfig-a011-20201008 i386 randconfig-a012-20201008 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig
Re: [PATCH v4 0/2] Control over userfaultfd kernel-fault handling
Hello Lokesh,
On Wed, Oct 07, 2020 at 01:26:55PM -0700, Lokesh Gidra wrote:
> On Wed, Sep 23, 2020 at 11:56 PM Lokesh Gidra wrote:
> >
> > This patch series is split from [1]. The other series enables SELinux
> > support for userfaultfd file descriptors so that its creation and
> > movement can be controlled.
> >
> > It has been demonstrated on various occasions that suspending kernel
> > code execution for an arbitrary amount of time at any access to
> > userspace memory (copy_from_user()/copy_to_user()/...) can be exploited
> > to change the intended behavior of the kernel. For instance, handling
> > page faults in kernel-mode using userfaultfd has been exploited in [2, 3].
> > Likewise, FUSE, which is similar to userfaultfd in this respect, has been
> > exploited in [4, 5] for similar outcome.
> >
> > This small patch series adds a new flag to userfaultfd(2) that allows
> > callers to give up the ability to handle kernel-mode faults with the
> > resulting UFFD file object. It then adds a 'user-mode only' option to
> > the unprivileged_userfaultfd sysctl knob to require unprivileged
> > callers to use this new flag.
> >
> > The purpose of this new interface is to decrease the chance of an
> > unprivileged userfaultfd user taking advantage of userfaultfd to
> > enhance security vulnerabilities by lengthening the race window in
> > kernel code.
> >
> > [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dan...@google.com/
> > [2] https://duasynt.com/blog/linux-kernel-heap-spray
> > [3] https://duasynt.com/blog/cve-2016-6187-heap-off-by-one-exploit
I've looking at those links and I've been trying to verify the link
[3] is relevant.
Specifically I've been trying to verify if 1) current state of the art
modern SLUB randomization techniques already enabled in production and
rightfully wasting some CPU in all enterprise kernels to prevent
things like above to become an issue in practice 2) combined with the
fact different memcg need to share the same kmemcaches (which was
incidentally fixed a few months ago upstream) and 3) further
robustness enhancements against exploits in the slub metadata, may
already render the exploit [3] from 2016 irrelevant in practice.
So I started by trying to reproduce [3] by building 4.5.1 with a
.config with no robustness features and I booted it on fedora-32 or
gentoo userland and I cannot even invoke call_usermodehelper. Calling
socket(22, AF_INET, 0) won't invoke such function. Can you reproduce
on 4.5.1? Which kernel .config should I use to build 4.5.1 in order
for call_usermodehelper to be invoked by the exploit? Could you help
to verify it?
It even has uninitialized variable spawning random perrors so it
doesn't give a warm fuzzy feeling:
int main(int argc, char **argv) {
void *region, *map;
^
pthread_t uffd_thread;
int uffd, msqid, i;
region = (void *)mmap((void *)0x4000, 0x2000, PROT_READ|PROT_WRITE,
MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0);
if (!region) {
perror("mmap");
exit(2);
}
setup_pagefault(region + 0x1000, 0x1000, 1);
printf("my pid = %d\n", getpid());
if (!map) {
perror("mmap");
The whole point of being able to reproduce on 4.5.1 is then to
simulate if the same exploit would also reproduce on current kernels
with all enterprise default robustness features enabled. Or did
anybody already verify it?
Anyway the links I was playing with are all in the cover letter, the
cover letter is not as important as the actual patches. The actual
patches looks fine to me.
The only improvement I can think of is, what about to add a
printk_once to suggest to toggle the sysctl if userfaultfd bails out
because the process lacks the CAP_SYS_PTRACE capability? That would
facilitate the /etc/sysctl.conf or tuned tweaking in case the apps
aren't verbose enough.
It's not relevant anymore with this latest patchset, but about the
previous argument that seccomp couldn't be used in all Android
processes because of performance concern, I'm slightly confused.
https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html
"Android O includes a single seccomp filter installed into zygote, the
process from which all the Android applications are derived. Because
the filter is installed into zygote—and therefore all apps—the Android
security team took extra caution to not break existing apps"
Example:
$ uname -mo
aarch64 Android
$ cat swapoff.c
#include
int main()
{
swapoff("");
}
$ gcc swapoff.c -o swapoff -O2
$ ./swapoff
Bad system call
$
It's hard to imagine what is more performance critical than the zygote
process and the actual apps as above?
It's also hard to imagine what kind of performance concern can arise
by adding seccomp filters also to background system apps that
generally should consume ~0% of CPU.
If performance is really a
RE: [PATCH 2/2] usb: cdns3: Variable ‘length’ set but not used
Siergei,
>
>On 10/7/20 11:15 AM, Roger Quadros wrote:
>
>[...]
>>> Patch removes not used variable 'length' from
>>> cdns3_wa2_descmiss_copy_data function.
>>>
>>> Signed-off-by: Pawel Laszczak
>>
>> Fixes: commit 141e70fef4ee ("usb: cdns3: gadget: need to handle sg case for
>> workaround 2 case")
>
> No "commit" is needed here.
Can you explain why?
I guess it's because commit 141e70fef4ee is quite new and it's not yet included
in any stable kernel version,
or because it's only warning - not error.
Am I right ?
>
>> Acked-by: Roger Quadros
>[...]
>
Regards,
Pawel
Re: [PATCH 2/2] riscv: Fixup static_obj() fail v2
On Wed, 07 Oct 2020 08:08:33 PDT (-0700), guo...@kernel.org wrote:
From: Guo Ren
v1 is commit: 6184358da0004c8fd940afda6c0a0fa4027dc911 which has
been reverted.
When enable LOCKDEP, static_obj() will cause error:
[0.067192] INFO: trying to register non-static key.
[0.067325] the code is fine but needs lockdep annotation.
[0.067449] turning off the locking correctness validator.
[0.067718] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7-dirty #44
[0.067945] Call Trace:
[0.068369] [] walk_stackframe+0x0/0xa4
[0.068506] [] show_stack+0x2a/0x34
[0.068631] [] dump_stack+0x94/0xca
[0.068757] [] register_lock_class+0x5b8/0x5bc
[0.068969] [] __lock_acquire+0x6c/0x1d5c
[0.069101] [] lock_acquire+0xae/0x312
[0.069228] [] _raw_spin_lock_irqsave+0x40/0x5a
[0.069357] [] complete+0x1e/0x50
[0.069479] [] rest_init+0x1b0/0x28a
[0.069660] [] 0xffe016a2
[0.069779] [] 0xffe01b84
[0.069953] [] 0xffe01092
Because some __initdata static variables is before _stext:
static int static_obj(const void *obj)
{
unsigned long start = (unsigned long) &_stext,
end = (unsigned long) &_end,
addr = (unsigned long) obj;
/*
* static variable?
*/
if ((addr >= start) && (addr < end))
return 1;
if (arch_is_kernel_data(addr))
return 1;
We could implement arch_is_kernel_data to fixup it.
Link:
https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guo...@kernel.org/T/#t
Signed-off-by: Guo Ren
Reported-by: Aurelien Jarno
Cc: Palmer Dabbelt
Cc: Atish Patra
Cc: Andreas Schwab
Cc: Aurelien Jarno
---
arch/riscv/include/asm/sections.h | 20
arch/riscv/kernel/setup.c | 9 +
2 files changed, 29 insertions(+)
create mode 100644 arch/riscv/include/asm/sections.h
diff --git a/arch/riscv/include/asm/sections.h
b/arch/riscv/include/asm/sections.h
new file mode 100644
index ..2317b9e
--- /dev/null
+++ b/arch/riscv/include/asm/sections.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_RISCV_SECTIONS_H
+#define _ASM_RISCV_SECTIONS_H
+
+#define arch_is_kernel_data arch_is_kernel_data
+
+#include
+
+extern bool init_mem_is_free;
+
+static inline int arch_is_kernel_data(unsigned long addr)
+{
+ if (init_mem_is_free)
+ return 0;
+
+ return addr >= (unsigned long)__init_begin &&
+ addr < (unsigned long)__init_end;
+}
+#endif /* _ASM_RISCV_SECTIONS_H */
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 2c6dd32..9ebd5eb4 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -112,3 +113,11 @@ static int __init topology_init(void)
return 0;
}
subsys_initcall(topology_init);
+
+bool init_mem_is_free = false;
+
+void free_initmem(void)
+{
+ free_initmem_default(POISON_FREE_INITMEM);
+ init_mem_is_free = true;
+}
I'm a bit confused as to what you're trying to do here. Yesterday I got
another version of this patch set that moves init data around, today a
different one. Yesterday's is tested and simpler, and given it's so late in
the process I'm inclined to take that as I don't want to break anything.
Right now I have
84814460eef9 ("riscv: Fixup bootup failure with HARDENED_USERCOPY")
a78c6f5956a9 ("RISC-V: Make sure memblock reserves the memory containing DT")
549738f15da0 ("Linux 5.9-rc8")
Unless there's some functional bug, that's what I'm going to send out for 5.9
-- I'm not all that worried about lacking the ability to free init data. The
above seems like fine 5.10 material.
Let me know if I'm missing something here.
[PATCH v2 8/8] blk-throttle: Re-use the throtl_set_slice_end()
Re-use throtl_set_slice_end() to remove duplicate code.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index fc5c14f..b771c42 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -808,7 +808,7 @@ static inline void throtl_set_slice_end(struct throtl_grp
*tg, bool rw,
static inline void throtl_extend_slice(struct throtl_grp *tg, bool rw,
unsigned long jiffy_end)
{
- tg->slice_end[rw] = roundup(jiffy_end, tg->td->throtl_slice);
+ throtl_set_slice_end(tg, rw, jiffy_end);
throtl_log(>service_queue,
"[%c] extend slice start=%lu end=%lu jiffies=%lu",
rw == READ ? 'R' : 'W', tg->slice_start[rw],
--
1.8.3.1
[PATCH v2 0/8] Some improvements for blk throttle
Hi, This patch set did some improvements for blk throttle, please help to review. Thanks. Changes from v1: - Add another 4 new patches in this patch set. Baolin Wang (8): blk-throttle: Remove a meaningless parameter for throtl_downgrade_state() blk-throttle: Avoid getting the current time if tg->last_finish_time is 0 blk-throttle: Avoid tracking latency if low limit is invalid blk-throttle: Fix IO hang for a corner case blk-throttle: Move the list operation after list validation blk-throttle: Move service tree validation out of the throtl_rb_first() blk-throttle: Open code __throtl_de/enqueue_tg() blk-throttle: Re-use the throtl_set_slice_end() block/blk-throttle.c | 69 ++-- 1 file changed, 35 insertions(+), 34 deletions(-) -- 1.8.3.1
[PATCH v2 7/8] blk-throttle: Open code __throtl_de/enqueue_tg()
The __throtl_de/enqueue_tg() functions are only be called by
throtl_de/enqueue_tg(), thus we can just open code them to
make code more readable.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 38aed8b..fc5c14f 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -691,29 +691,21 @@ static void tg_service_queue_add(struct throtl_grp *tg)
leftmost);
}
-static void __throtl_enqueue_tg(struct throtl_grp *tg)
-{
- tg_service_queue_add(tg);
- tg->flags |= THROTL_TG_PENDING;
- tg->service_queue.parent_sq->nr_pending++;
-}
-
static void throtl_enqueue_tg(struct throtl_grp *tg)
{
- if (!(tg->flags & THROTL_TG_PENDING))
- __throtl_enqueue_tg(tg);
-}
-
-static void __throtl_dequeue_tg(struct throtl_grp *tg)
-{
- throtl_rb_erase(>rb_node, tg->service_queue.parent_sq);
- tg->flags &= ~THROTL_TG_PENDING;
+ if (!(tg->flags & THROTL_TG_PENDING)) {
+ tg_service_queue_add(tg);
+ tg->flags |= THROTL_TG_PENDING;
+ tg->service_queue.parent_sq->nr_pending++;
+ }
}
static void throtl_dequeue_tg(struct throtl_grp *tg)
{
- if (tg->flags & THROTL_TG_PENDING)
- __throtl_dequeue_tg(tg);
+ if (tg->flags & THROTL_TG_PENDING) {
+ throtl_rb_erase(>rb_node, tg->service_queue.parent_sq);
+ tg->flags &= ~THROTL_TG_PENDING;
+ }
}
/* Call with queue lock held */
--
1.8.3.1
[PATCH v2 3/8] blk-throttle: Avoid tracking latency if low limit is invalid
The IO latency tracking is only for LOW limit, so we should add a
validation to avoid redundant latency tracking if the LOW limit
is not valid.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 7e72102..b0d8f7c 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -2100,7 +2100,7 @@ static void throtl_update_latency_buckets(struct
throtl_data *td)
unsigned long last_latency[2] = { 0 };
unsigned long latency[2];
- if (!blk_queue_nonrot(td->queue))
+ if (!blk_queue_nonrot(td->queue) || !td->limit_valid[LIMIT_LOW])
return;
if (time_before(jiffies, td->last_calculate_time + HZ))
return;
@@ -2338,6 +2338,8 @@ void blk_throtl_bio_endio(struct bio *bio)
if (!blkg)
return;
tg = blkg_to_tg(blkg);
+ if (!tg->td->limit_valid[LIMIT_LOW])
+ return;
finish_time_ns = ktime_get_ns();
tg->last_finish_time = finish_time_ns >> 10;
--
1.8.3.1
[PATCH v2 4/8] blk-throttle: Fix IO hang for a corner case
It can not scale up in throtl_adjusted_limit() if we set bps or iops is 1, which will cause IO hang when enable low limit. Thus we should treat 1 as a illegal value to avoid this issue. Signed-off-by: Baolin Wang --- block/blk-throttle.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index b0d8f7c..0649bce 100644 --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -1687,13 +1687,13 @@ static ssize_t tg_set_limit(struct kernfs_open_file *of, goto out_finish; ret = -EINVAL; - if (!strcmp(tok, "rbps")) + if (!strcmp(tok, "rbps") && val > 1) v[0] = val; - else if (!strcmp(tok, "wbps")) + else if (!strcmp(tok, "wbps") && val > 1) v[1] = val; - else if (!strcmp(tok, "riops")) + else if (!strcmp(tok, "riops") && val > 1) v[2] = min_t(u64, val, UINT_MAX); - else if (!strcmp(tok, "wiops")) + else if (!strcmp(tok, "wiops") && val > 1) v[3] = min_t(u64, val, UINT_MAX); else if (off == LIMIT_LOW && !strcmp(tok, "idle")) idle_time = val; -- 1.8.3.1
[PATCH v2 2/8] blk-throttle: Avoid getting the current time if tg->last_finish_time is 0
We only update the tg->last_finish_time when the low limitaion is
enabled, so we can move the tg->last_finish_time validation a little
forward to avoid getting the unnecessary current time stamp if the
the low limitation is not enabled.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 4007b26..7e72102 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -2077,10 +2077,14 @@ static void throtl_downgrade_check(struct throtl_grp
*tg)
static void blk_throtl_update_idletime(struct throtl_grp *tg)
{
- unsigned long now = ktime_get_ns() >> 10;
+ unsigned long now;
unsigned long last_finish_time = tg->last_finish_time;
- if (now <= last_finish_time || last_finish_time == 0 ||
+ if (last_finish_time == 0)
+ return;
+
+ now = ktime_get_ns() >> 10;
+ if (now <= last_finish_time ||
last_finish_time == tg->checked_last_finish_time)
return;
--
1.8.3.1
[PATCH v2 6/8] blk-throttle: Move service tree validation out of the throtl_rb_first()
The throtl_schedule_next_dispatch() will validate if the service queue
is empty before calling update_min_dispatch_time(), and the
update_min_dispatch_time() will call throtl_rb_first(), which will
validate service queue again.
Thus we can move the service queue validation out of the
throtl_rb_first() to remove the redundant validation in the fast path.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index f1bcb5c..38aed8b 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -638,9 +638,6 @@ static void throtl_pd_free(struct blkg_policy_data *pd)
throtl_rb_first(struct throtl_service_queue *parent_sq)
{
struct rb_node *n;
- /* Service tree is empty */
- if (!parent_sq->nr_pending)
- return NULL;
n = rb_first_cached(_sq->pending_tree);
WARN_ON_ONCE(!n);
@@ -1224,9 +1221,13 @@ static int throtl_select_dispatch(struct
throtl_service_queue *parent_sq)
unsigned int nr_disp = 0;
while (1) {
- struct throtl_grp *tg = throtl_rb_first(parent_sq);
+ struct throtl_grp *tg;
struct throtl_service_queue *sq;
+ if (!parent_sq->nr_pending)
+ break;
+
+ tg = throtl_rb_first(parent_sq);
if (!tg)
break;
--
1.8.3.1
[PATCH v2 1/8] blk-throttle: Remove a meaningless parameter for throtl_downgrade_state()
The throtl_downgrade_state() is always used to change to LIMIT_LOW
limitation, thus remove the latter meaningless parameter which
indicates the limitation index.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 36ba61c..4007b26 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -1970,7 +1970,7 @@ static void throtl_upgrade_state(struct throtl_data *td)
queue_work(kthrotld_workqueue, >dispatch_work);
}
-static void throtl_downgrade_state(struct throtl_data *td, int new)
+static void throtl_downgrade_state(struct throtl_data *td)
{
td->scale /= 2;
@@ -1980,7 +1980,7 @@ static void throtl_downgrade_state(struct throtl_data
*td, int new)
return;
}
- td->limit_index = new;
+ td->limit_index = LIMIT_LOW;
td->low_downgrade_time = jiffies;
}
@@ -2067,7 +2067,7 @@ static void throtl_downgrade_check(struct throtl_grp *tg)
* cgroups
*/
if (throtl_hierarchy_can_downgrade(tg))
- throtl_downgrade_state(tg->td, LIMIT_LOW);
+ throtl_downgrade_state(tg->td);
tg->last_bytes_disp[READ] = 0;
tg->last_bytes_disp[WRITE] = 0;
--
1.8.3.1
[PATCH v2 5/8] blk-throttle: Move the list operation after list validation
We should move the list operation after validation.
Signed-off-by: Baolin Wang
---
block/blk-throttle.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 0649bce..f1bcb5c 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -423,12 +423,13 @@ static void throtl_qnode_add_bio(struct bio *bio, struct
throtl_qnode *qn,
*/
static struct bio *throtl_peek_queued(struct list_head *queued)
{
- struct throtl_qnode *qn = list_first_entry(queued, struct throtl_qnode,
node);
+ struct throtl_qnode *qn;
struct bio *bio;
if (list_empty(queued))
return NULL;
+ qn = list_first_entry(queued, struct throtl_qnode, node);
bio = bio_list_peek(>bios);
WARN_ON_ONCE(!bio);
return bio;
@@ -451,12 +452,13 @@ static struct bio *throtl_peek_queued(struct list_head
*queued)
static struct bio *throtl_pop_queued(struct list_head *queued,
struct throtl_grp **tg_to_put)
{
- struct throtl_qnode *qn = list_first_entry(queued, struct throtl_qnode,
node);
+ struct throtl_qnode *qn;
struct bio *bio;
if (list_empty(queued))
return NULL;
+ qn = list_first_entry(queued, struct throtl_qnode, node);
bio = bio_list_pop(>bios);
WARN_ON_ONCE(!bio);
--
1.8.3.1
Re: [PATCH 2/2] Arm: dts: aspeed-g6: Add sgpio node and pinctrl setting
On Thu, 8 Oct 2020 at 01:51, Billy Tsai wrote:
>
> This patch is used to add sgpiom and sgpios nodes and add pinctrl setting
> for sgpiom1
The code looks good Billy.
Please split the change in two: device tree changes (arch/arm/dts) in
one, and pinctrl in the second, as they go through different
maintainers.
You also need to update the device tree bindings in Documentation with
the new compatible strings:
Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
That should go in it's own patch too.
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -366,6 +366,58 @@
> #interrupt-cells = <2>;
> };
>
> + sgpiom0: sgpiom@1e780500 {
> + #gpio-cells = <2>;
> + gpio-controller;
> + compatible = "aspeed,ast2600-sgpiom";
This is interesting. I didn't realise the sgpio driver we have in the
mainline kernel tree (drivers/gpio/gpio-aspeed-sgpio.c) is for the
sgpio master device. It might be best to update the naming of the
ast2400/ast2500 compatible in the future.
> + reg = <0x1e780500 0x100>;
> + interrupts = ;
> + ngpios = <128>;
> + clocks = < ASPEED_CLK_APB2>;
> + interrupt-controller;
> + bus-frequency = <1200>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_sgpm1_default>;
> + status = "disabled";
> + };
> gpio1: gpio@1e780800 {
> #gpio-cells = <2>;
> gpio-controller;
> @@ -377,6 +429,7 @@
> clocks = < ASPEED_CLK_APB1>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + status = "disabled";
This should be in a different patch set, as it will break all of the
systems that expect GPIO to be enabled (which is all of them).
Considering all of them expect this gpio bank to be enabled, should we
leave it enabled here?
> };
>
> rtc: rtc@1e781000 {
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> index 34803a6c7664..b673a44ffa3b 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> @@ -46,8 +46,10 @@
> #define SCU620 0x620 /* Disable GPIO Internal Pull-Down #4 */
> #define SCU634 0x634 /* Disable GPIO Internal Pull-Down #5 */
> #define SCU638 0x638 /* Disable GPIO Internal Pull-Down #6 */
> +#define SCU690 0x690 /* Multi-function Pin Control #24 */
> #define SCU694 0x694 /* Multi-function Pin Control #25 */
> #define SCU69C 0x69C /* Multi-function Pin Control #27 */
> +#define SCU6D0 0x6D0 /* Multi-function Pin Control #28 */
> #define SCUC20 0xC20 /* PCIE configuration Setting Control */
>
> #define ASPEED_G6_NR_PINS 256
> @@ -81,13 +83,21 @@ FUNC_GROUP_DECL(I2C12, L26, K24);
> #define K26 4
> SIG_EXPR_LIST_DECL_SESG(K26, MACLINK1, MACLINK1, SIG_DESC_SET(SCU410, 4));
> SIG_EXPR_LIST_DECL_SESG(K26, SCL13, I2C13, SIG_DESC_SET(SCU4B0, 4));
> -PIN_DECL_2(K26, GPIOA4, MACLINK1, SCL13);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(K26, SGPM2CLK, SGPM2, SIG_DESC_SET(SCU6D0, 4),
> + SIG_DESC_CLEAR(SCU410, 4), SIG_DESC_CLEAR(SCU4B0,
> 4),
> + SIG_DESC_CLEAR(SCU690, 4));
> +PIN_DECL_3(K26, GPIOA4, SGPM2CLK, MACLINK1, SCL13);
> FUNC_GROUP_DECL(MACLINK1, K26);
>
> #define L24 5
> SIG_EXPR_LIST_DECL_SESG(L24, MACLINK2, MACLINK2, SIG_DESC_SET(SCU410, 5));
> SIG_EXPR_LIST_DECL_SESG(L24, SDA13, I2C13, SIG_DESC_SET(SCU4B0, 5));
> -PIN_DECL_2(L24, GPIOA5, MACLINK2, SDA13);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(L24, SGPM2LD, SGPM2, SIG_DESC_SET(SCU6D0, 5),
> + SIG_DESC_CLEAR(SCU410, 5), SIG_DESC_CLEAR(SCU4B0,
> 5),
> + SIG_DESC_CLEAR(SCU690, 5));
> +PIN_DECL_3(L24, GPIOA5, SGPM2LD, MACLINK2, SDA13);
> FUNC_GROUP_DECL(MACLINK2, L24);
>
> FUNC_GROUP_DECL(I2C13, K26, L24);
> @@ -95,16 +105,26 @@ FUNC_GROUP_DECL(I2C13, K26, L24);
> #define L23 6
> SIG_EXPR_LIST_DECL_SESG(L23, MACLINK3, MACLINK3, SIG_DESC_SET(SCU410, 6));
> SIG_EXPR_LIST_DECL_SESG(L23, SCL14, I2C14, SIG_DESC_SET(SCU4B0, 6));
> -PIN_DECL_2(L23, GPIOA6, MACLINK3, SCL14);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(L23, SGPM2O, SGPM2, SIG_DESC_SET(SCU6D0, 6),
> + SIG_DESC_CLEAR(SCU410, 6), SIG_DESC_CLEAR(SCU4B0,
> 6),
> +
Re: [PATCH] scsi: sd: Use UNMAP in case the device doesn't support WRITE_SAME
Bean, > There exists a storage device that supports READ_CAPACITY, but doesn't > support WRITE_SAME. The problem is that WRITE SAME heuristics doesn't work > for this kind of storage device since its block limits VPD page doesn't > contain the LBP information. Currently we set its provisioning_mode > "writesame_16" and didn't check "no_write_same". There is something odd with what your device is reporting. We support WRITE SAME on a bunch of devices that predate the Logical Block Provisioning VPD page and the various Block Limits parameters being introduced to the spec. Consequently we set the provisioning mode to "writesame_16" if the device reports LBPME=1 in READ CAPACITY(16) and nothing relevant is reported in the VPD pages. That is by design. > If we didn't manually change this default provisioning_mode to "unmap" > through sysfs, provisioning_mode will be set to "disabled" after the > first WRITE_SAME command with the following error occurs: If your device supports UNMAP it *must* report it in the Logical Block Provisioning VPD by setting LBPU=1 and report MAXIMUM UNMAP LBA COUNT and MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT in the Block Limits VPD. Also, "no_write_same" disables attempting to use WRITE SAME to zero block ranges. That's orthogonal to the logic controlling which command to use for performing an unmap operation. An unfortunate choice of naming which can be attributed to the SCSI protocol using the WRITE SAME command for two completely different operations. -- Martin K. Petersen Oracle Linux Engineering
[PATCH] powerpc/smp: Use GFP_ATOMIC while allocating tmp mask
Qian Cai reported a regression where CPU Hotplug fails with the latest
powerpc/next
BUG: sleeping function called from invalid context at mm/slab.h:494
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/88
no locks held by swapper/88/0.
irq event stamp: 18074448
hardirqs last enabled at (18074447): []
tick_nohz_idle_enter+0x9c/0x110
hardirqs last disabled at (18074448): [] do_idle+0x138/0x3b0
do_idle at kernel/sched/idle.c:253 (discriminator 1)
softirqs last enabled at (18074440): []
irq_enter_rcu+0x94/0xa0
softirqs last disabled at (18074439): []
irq_enter_rcu+0x70/0xa0
CPU: 88 PID: 0 Comm: swapper/88 Tainted: GW
5.9.0-rc8-next-20201007 #1
Call Trace:
[c0002a4bfcf0] [c0649e98] dump_stack+0xec/0x144 (unreliable)
[c0002a4bfd30] [c00f6c34] ___might_sleep+0x2f4/0x310
[c0002a4bfdb0] [c0354f94]
slab_pre_alloc_hook.constprop.82+0x124/0x190
[c0002a4bfe00] [c035e9e8] __kmalloc_node+0x88/0x3a0
slab_alloc_node at mm/slub.c:2817
(inlined by) __kmalloc_node at mm/slub.c:4013
[c0002a4bfe80] [c06494d8] alloc_cpumask_var_node+0x38/0x80
kmalloc_node at include/linux/slab.h:577
(inlined by) alloc_cpumask_var_node at lib/cpumask.c:116
[c0002a4bfef0] [c003eedc] start_secondary+0x27c/0x800
update_mask_by_l2 at arch/powerpc/kernel/smp.c:1267
(inlined by) add_cpu_to_masks at arch/powerpc/kernel/smp.c:1387
(inlined by) start_secondary at arch/powerpc/kernel/smp.c:1420
[c0002a4bff90] [c000c468] start_secondary_resume+0x10/0x14
Allocating a temporary mask while performing a CPU Hotplug operation
with CONFIG_CPUMASK_OFFSTACK enabled, leads to calling a sleepable
function from a atomic context. Fix this by allocating the temporary
mask with GFP_ATOMIC flag.
If there is a failure to allocate a mask, scheduler is going to observe
that this CPU's topology is broken. Instead of having to speculate why
the topology is broken, add a WARN_ON_ONCE.
Fixes: 70a94089d7f7 ("powerpc/smp: Optimize update_coregroup_mask")
Fixes: 3ab33d6dc3e9 ("powerpc/smp: Optimize update_mask_by_l2")
Reported-by: Qian Cai
Suggested-by: Qian Cai
Signed-off-by: Srikar Dronamraju
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Nathan Lynch
Cc: Gautham R Shenoy
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Valentin Schneider
Cc: Qian Cai
---
arch/powerpc/kernel/smp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 0dc1b85..1268558 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1264,7 +1264,8 @@ static bool update_mask_by_l2(int cpu)
return false;
}
- alloc_cpumask_var_node(, GFP_KERNEL, cpu_to_node(cpu));
+ /* In CPU-hotplug path, hence use GFP_ATOMIC */
+ WARN_ON_ONCE(!alloc_cpumask_var_node(, GFP_ATOMIC,
cpu_to_node(cpu)));
cpumask_and(mask, cpu_online_mask, cpu_cpu_mask(cpu));
if (has_big_cores)
@@ -1344,7 +1345,8 @@ static void update_coregroup_mask(int cpu)
int coregroup_id = cpu_to_coregroup_id(cpu);
int i;
- alloc_cpumask_var_node(, GFP_KERNEL, cpu_to_node(cpu));
+ /* In CPU-hotplug path, hence use GFP_ATOMIC */
+ WARN_ON_ONCE(!alloc_cpumask_var_node(, GFP_ATOMIC,
cpu_to_node(cpu)));
cpumask_and(mask, cpu_online_mask, cpu_cpu_mask(cpu));
if (shared_caches)
--
1.8.3.1
Re: [PATCH] block: Remove redundant 'return' statement
Hi,
On Mon, Sep 28, 2020 at 08:42:26AM +0800, Baolin Wang wrote:
> Remove redundant 'return' statement for 'void' functions.
>
> Signed-off-by: Baolin Wang
Gentle ping?
> ---
> block/blk-iocost.c| 2 +-
> block/blk-iolatency.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-iocost.c b/block/blk-iocost.c
> index ef9476f..e38c406 100644
> --- a/block/blk-iocost.c
> +++ b/block/blk-iocost.c
> @@ -3343,7 +3343,7 @@ static int __init ioc_init(void)
>
> static void __exit ioc_exit(void)
> {
> - return blkcg_policy_unregister(_policy_iocost);
> + blkcg_policy_unregister(_policy_iocost);
> }
>
> module_init(ioc_init);
> diff --git a/block/blk-iolatency.c b/block/blk-iolatency.c
> index f90429c..81be009 100644
> --- a/block/blk-iolatency.c
> +++ b/block/blk-iolatency.c
> @@ -1046,7 +1046,7 @@ static int __init iolatency_init(void)
>
> static void __exit iolatency_exit(void)
> {
> - return blkcg_policy_unregister(_policy_iolatency);
> + blkcg_policy_unregister(_policy_iolatency);
> }
>
> module_init(iolatency_init);
> --
> 1.8.3.1
Re: KASAN: use-after-free Read in delete_partition
syzbot suspects this issue was fixed by commit: commit 08fc1ab6d748ab1a690fd483f41e2938984ce353 Author: Christoph Hellwig Date: Tue Sep 1 09:59:41 2020 + block: fix locking in bdev_del_partition bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1259b1e790 start commit: f75aef39 Linux 5.9-rc3 git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299 dashboard link: https://syzkaller.appspot.com/bug?extid=b8639c8dcb5ec4483d4f syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15c43c7990 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=173dfa1e90 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: block: fix locking in bdev_del_partition For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[git pull] drm nouveau fixes for 5.9 final
Hi Linus, Karol found two last minute nouveau fixes, they both fix crashes, the TTM one follows what other drivers do already, and the other is for bailing on load on unrecognised chipsets. Thanks, Dave. drm-fixes-2020-10-08: drm nouveau fixes for 5.9 final nouveau: - fix crash in TTM alloc fail path - return error earlier for unknown chipsets The following changes since commit 86fdf61e71046618f6f499542cee12f2348c523c: Merge tag 'drm-misc-fixes-2020-10-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-10-06 12:38:28 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-08 for you to fetch changes up to d10285a25e29f13353bbf7760be8980048c1ef2f: drm/nouveau/mem: guard against NULL pointer access in mem_del (2020-10-07 15:33:09 +1000) drm nouveau fixes for 5.9 final nouveau: - fix crash in TTM alloc fail path - return error earlier for unknown chipsets Karol Herbst (2): drm/nouveau/device: return error for unknown chipsets drm/nouveau/mem: guard against NULL pointer access in mem_del drivers/gpu/drm/nouveau/nouveau_mem.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 1 + 2 files changed, 3 insertions(+)
Re: [PATCH V2] kprobes: Correct a typo in function kprobes_module_callback
On Thu, 8 Oct 2020 03:13:57 +
Zhouyi Zhou wrote:
> There is a tiny typo in comment of function kprobes_module_callback.
>
> Signed-off-by: Zhouyi Zhou
Thanks for reporting!
Acked-by: Masami Hiramatsu
> ---
> kernel/kprobes.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index e995541..9d2042b 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2432,7 +2432,7 @@ static int kprobes_module_callback(struct
> notifier_block *nb,
>within_module_core((unsigned long)p->addr, mod))) {
> /*
>* The vaddr this probe is installed will soon
> - * be vfreed buy not synced to disk. Hence,
> + * be vfreed but not synced to disk. Hence,
>* disarming the breakpoint isn't needed.
>*
>* Note, this will also move any optimized
> probes
> --
> 1.7.1
>
--
Masami Hiramatsu
Re: [PATCH 5/6] ftrace: replace do_for_each_ftrace_rec() with for_ftrace_rec_iter()
On Tue, Oct 06, 2020 at 10:42:17AM -0400, Steven Rostedt wrote: >On Mon, 31 Aug 2020 11:11:03 +0800 >Wei Yang wrote: > >> Now we have two similar infrastructure to iterate ftrace_page and >> dyn_ftrace: >> >> * do_for_each_ftrace_rec() >> * for_ftrace_rec_iter() >> >> The 2nd one, for_ftrace_rec_iter(), looks more generic, so preserve it >> and replace do_for_each_ftrace_rec() with it. >> > >I also didn't pull in this patch. The reason is that the >for_ftrace_rec_iter() is specific for external usage (for archs to use) and >requires two function calls to do the iterations. > >The do_for_each_ftrace_rec() is a faster, light weight version, but for >internal use only. > >I rather keep both, as each has their own, but slightly different, use >cases. > Got it, thanks >-- Steve -- Wei Yang Help you, Help me
Re: [PATCH 1/6] ftrace: define seq_file only for FMODE_READ
On Tue, Oct 06, 2020 at 10:36:38AM -0400, Steven Rostedt wrote:
>On Mon, 31 Aug 2020 11:10:59 +0800
>Wei Yang wrote:
>
>> The purpose of the operation is to get ftrace_iterator, which is embedded
>> in file or seq_file for FMODE_WRITE/FMODE_READ respectively. Since we
>> don't have a seq_file for FMODE_WRITE case, it is meaningless to cast
>> file->private_data to seq_file.
>>
>> Let's move the definition when there is a valid seq_file.
>
>I didn't pull in this patch because I find the original more expressive,
>and there's really no benefit in changing it.
>
Got it, thanks
>-- Steve
>
>
>>
>> Signed-off-by: Wei Yang
>> ---
>> kernel/trace/ftrace.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
>> index edc233122598..12cb535769bc 100644
>> --- a/kernel/trace/ftrace.c
>> +++ b/kernel/trace/ftrace.c
>> @@ -5558,7 +5558,6 @@ static void __init set_ftrace_early_filters(void)
>>
>> int ftrace_regex_release(struct inode *inode, struct file *file)
>> {
>> -struct seq_file *m = (struct seq_file *)file->private_data;
>> struct ftrace_iterator *iter;
>> struct ftrace_hash **orig_hash;
>> struct trace_parser *parser;
>> @@ -5566,6 +5565,7 @@ int ftrace_regex_release(struct inode *inode, struct
>> file *file)
>> int ret;
>>
>> if (file->f_mode & FMODE_READ) {
>> +struct seq_file *m = file->private_data;
>> iter = m->private;
>> seq_release(inode, file);
>> } else
--
Wei Yang
Help you, Help me
Re: [PATCH 1/4] drivers core: Introduce CPU type sysfs interface
On Wed, Oct 07, 2020 at 07:15:46AM +0200, Greg Kroah-Hartman wrote: > On Tue, Oct 06, 2020 at 08:14:47PM -0700, Ricardo Neri wrote: > > On Tue, Oct 06, 2020 at 09:37:44AM +0200, Greg Kroah-Hartman wrote: > > > On Mon, Oct 05, 2020 at 05:57:36PM -0700, Ricardo Neri wrote: > > > > On Sat, Oct 03, 2020 at 10:53:45AM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Oct 02, 2020 at 06:17:42PM -0700, Ricardo Neri wrote: > > > > > > Hybrid CPU topologies combine CPUs of different microarchitectures > > > > > > in the > > > > > > same die. Thus, even though the instruction set is compatible among > > > > > > all > > > > > > CPUs, there may still be differences in features (e.g., some CPUs > > > > > > may > > > > > > have counters that others CPU do not). There may be applications > > > > > > interested in knowing the type of micro-architecture topology of the > > > > > > system to make decisions about process affinity. > > > > > > > > > > > > While the existing sysfs for capacity (/sys/devices/system/cpu/cpuX/ > > > > > > cpu_capacity) may be used to infer the types of micro-architecture > > > > > > of the > > > > > > CPUs in the platform, it may not be entirely accurate. For > > > > > > instance, two > > > > > > subsets of CPUs with different types of micro-architecture may have > > > > > > the > > > > > > same capacity due to power or thermal constraints. > > > > > > > > > > > > Create the new directory /sys/devices/system/cpu/types. Under such > > > > > > directory, create individual subdirectories for each type of CPU > > > > > > micro- > > > > > > architecture. Each subdirectory will have cpulist and cpumap files. > > > > > > This > > > > > > makes it convenient for user space to read all the CPUs of the same > > > > > > type > > > > > > at once without having to inspect each CPU individually. > > > > > > > > > > > > Implement a generic interface using weak functions that > > > > > > architectures can > > > > > > override to indicate a) support for CPU types, b) the CPU type > > > > > > number, and > > > > > > c) a string to identify the CPU vendor and type. > > > > > > > > > > > > For example, an x86 system with one Intel Core and four Intel Atom > > > > > > CPUs > > > > > > would look like this (other architectures have the hooks to use > > > > > > whatever > > > > > > directory naming convention below "types" that meets their needs): > > > > > > > > > > > > user@host:~$: ls /sys/devices/system/cpu/types > > > > > > intel_atom_0 intel_core_0 > > > > > > > > > > > > user@host:~$ ls /sys/devices/system/cpu/types/intel_atom_0 > > > > > > cpulist cpumap > > > > > > > > > > > > user@host:~$ ls /sys/devices/system/cpu/types/intel_core_0 > > > > > > cpulist cpumap > > > > > > > > > > > > user@host:~$ cat /sys/devices/system/cpu/types/intel_atom_0/cpumap > > > > > > 0f > > > > > > > > > > > > user@host:~$ cat /sys/devices/system/cpu/types/intel_atom_0/cpulist > > > > > > 0-3 > > > > > > > > > > > > user@ihost:~$ cat /sys/devices/system/cpu/types/intel_core_0/cpumap > > > > > > 10 > > > > > > > > > > > > user@host:~$ cat /sys/devices/system/cpu/types/intel_core_0/cpulist > > > > > > 4 > > > > > > > > Thank you for the quick and detailed Greg! > > > > > > > > > > > > > > The output of 'tree' sometimes makes it easier to see here, or: > > > > > grep -R . * > > > > > also works well. > > > > > > > > Indeed, this would definitely make it more readable. > > > > > > > > > > > > > > > On non-hybrid systems, the /sys/devices/system/cpu/types directory > > > > > > is not > > > > > > created. Add a hook for this purpose. > > > > > > > > > > Why should these not show up if the system is not "hybrid"? > > > > > > > > My thinking was that on a non-hybrid system, it does not make sense to > > > > create this interface, as all the CPUs will be of the same type. > > > > > > Why not just have this an attribute type in the existing cpuX directory? > > > Why do this have to be a totally separate directory and userspace has to > > > figure out to look in two different spots for the same cpu to determine > > > what it is? > > > > But if the type is located under cpuX, usespace would need to traverse > > all the CPUs and create its own cpu masks. Under the types directory it > > would only need to look once for each type of CPU, IMHO. > > What does a "mask" do? What does userspace care about this? It would only need to consume the cpu masks that sysfs provides; but it would have to implement the extra step of looking at another directory. > You would have to create it by traversing the directories you are creating > anyway, > so it's not much different, right? True, that is a good point, userspace would still end up traversing diretories anyways. > > > > That feels wasteful, it should be much simpler to use the existing > > > object, right? > > > > > > That way, you also show the "type" of all cpus, no matter if they are > > > "hybrid" or not, again, making userspace deal with things
Re: [PATCH v3 7/8] mm/mempolicy: use a standard migration target allocation callback
On Tue, 7 Jul 2020, Qian Cai wrote: > On Tue, Jun 23, 2020 at 03:13:47PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > There is a well-defined migration target allocation callback. > > Use it. > > > > Signed-off-by: Joonsoo Kim > > --- ... > > migrate_pages() starts failing like this apparently using the new > callback on NUMA systems, > > [ 6147.019063][T45242] LTP: starting move_pages12 > [ 6147.475680][T64921] BUG: unable to handle page fault for address: > ffe0 > [ 6147.483301][T64921] #PF: supervisor read access in kernel mode > [ 6147.489170][T64921] #PF: error_code(0x) - not-present page > [ 6147.495040][T64921] PGD 5df817067 P4D 5df817067 PUD 5df819067 PMD 0 > [ 6147.501438][T64921] Oops: [#1] SMP KASAN NOPTI > [ 6147.506348][T64921] CPU: 35 PID: 64921 Comm: move_pages12 Tainted: G > O 5.8.0-rc4-next-20200707 #1 > [ 6147.516586][T64921] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 > Gen10, BIOS A40 07/10/2019 > [ 6147.525866][T64921] RIP: 0010:anon_vma_interval_tree_iter_first+0xa2/0x170 > avc_start_pgoff at mm/interval_tree.c:63 > (inlined by) __anon_vma_interval_tree_iter_first at mm/interval_tree.c:71 > (inlined by) anon_vma_interval_tree_iter_first at mm/interval_tree.c:95 > [ 6147.532787][T64921] Code: 00 00 00 00 fc ff df 48 8b 6d 08 48 8d 7d e0 48 > 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 b3 00 00 00 48 b8 00 00 00 00 00 fc ff df > <48> 8b 6d e0 48 8d bd 98 00 00 00 48 89 f9 48 c1 e9 03 80 3c 01 00 > [ 6147.552370][T64921] RSP: 0018:c9000bfdfa98 EFLAGS: 00010246 > [ 6147.558327][T64921] RAX: dc00 RBX: 888524019b28 RCX: > 1ffc > [ 6147.566205][T64921] RDX: 03ff RSI: 0200 RDI: > ffe0 > [ 6147.574084][T64921] RBP: R08: f94002b1c001 R09: > f94002b1c001 > [ 6147.581962][T64921] R10: ea00158e0007 R11: f94002b1c000 R12: > 0009 > [ 6147.589839][T64921] R13: ea00158e0008 R14: ea00158e R15: > ea00158e > [ 6147.597717][T64921] FS: 7f329cf18b80() GS:1f7c() > knlGS: > [ 6147.606557][T64921] CS: 0010 DS: ES: CR0: 80050033 > [ 6147.613037][T64921] CR2: ffe0 CR3: 00081122a000 CR4: > 003506e0 > [ 6147.620914][T64921] Call Trace: > [ 6147.624078][T64921] rmap_walk_anon+0x141/0xa30 > rmap_walk_anon at mm/rmap.c:1864 > [ 6147.628639][T64921] try_to_unmap+0x209/0x2d0 > try_to_unmap at mm/rmap.c:1763 > [ 6147.633026][T64921] ? rmap_walk_locked+0x140/0x140 > [ 6147.637936][T64921] ? page_remove_rmap+0x1190/0x1190 > [ 6147.643020][T64921] ? page_not_mapped+0x10/0x10 > [ 6147.647668][T64921] ? page_get_anon_vma+0x290/0x290 > [ 6147.652664][T64921] ? page_mapcount_is_zero+0x10/0x10 > [ 6147.657838][T64921] ? hugetlb_page_mapping_lock_write+0x97/0x180 > [ 6147.663972][T64921] migrate_pages+0x1005/0x1fb0 > unmap_and_move_huge_page at mm/migrate.c:1383 > (inlined by) migrate_pages at mm/migrate.c:1468 > [ 6147.668617][T64921] ? remove_migration_pte+0xac0/0xac0 > [ 6147.673875][T64921] move_pages_and_store_status.isra.47+0xd7/0x1a0 > do_move_pages_to_node at mm/migrate.c:1595 > (inlined by) move_pages_and_store_status at mm/migrate.c:1683 > [ 6147.680181][T64921] ? migrate_pages+0x1fb0/0x1fb0 > [ 6147.685002][T64921] __x64_sys_move_pages+0xa5c/0x1100 > [ 6147.690176][T64921] ? trace_hardirqs_on+0x20/0x1b5 > [ 6147.695084][T64921] ? move_pages_and_store_status.isra.47+0x1a0/0x1a0 > [ 6147.701653][T64921] ? rcu_read_lock_sched_held+0xaa/0xd0 > [ 6147.707088][T64921] ? switch_fpu_return+0x196/0x400 > [ 6147.712083][T64921] ? lockdep_hardirqs_on_prepare+0x38c/0x550 > [ 6147.717954][T64921] ? do_syscall_64+0x24/0x310 > [ 6147.722513][T64921] do_syscall_64+0x5f/0x310 > [ 6147.726897][T64921] ? trace_hardirqs_off+0x12/0x1a0 > [ 6147.731894][T64921] ? asm_exc_page_fault+0x8/0x30 > [ 6147.736714][T64921] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 6147.742495][T64921] RIP: 0033:0x7f329c3fe6ed > [ 6147.746791][T64921] Code: Bad RIP value. > [ 6147.750738][T64921] RSP: 002b:7fff5b6b5f88 EFLAGS: 0246 ORIG_RAX: > 0117 > [ 6147.759055][T64921] RAX: ffda RBX: 7f329cf18af8 RCX: > 7f329c3fe6ed > [ 6147.766933][T64921] RDX: 019b0ee0 RSI: 0400 RDI: > fd98 > [ 6147.774809][T64921] RBP: 0400 R08: 019b3f00 R09: > 0004 > [ 6147.782686][T64921] R10: 019b2ef0 R11: 0246 R12: > 0400 > [ 6147.790563][T64921] R13: 019b0ee0 R14: 019b2ef0 R15: > 019b3f00 > [ 6147.798440][T64921] Modules linked in: vfio_pci vfio_virqfd > vfio_iommu_type1 vfio loop kvm_amd ses enclosure kvm irqbypass efivars > acpi_cpufreq nls_ascii nls_cp437 vfat fat efivarfs ip_tables x_tables sd_mod > smartpqi scsi_transport_sas tg3 mlx5_core libphy firmware_class dm_mirror > dm_region_hash dm_log dm_mod
Re: [PATCH V2] kprobes: Correct a typo in function kprobes_module_callback
On 10/7/20 8:13 PM, Zhouyi Zhou wrote:
> There is a tiny typo in comment of function kprobes_module_callback.
>
> Signed-off-by: Zhouyi Zhou
Acked-by: Randy Dunlap
Thanks.
> ---
> kernel/kprobes.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index e995541..9d2042b 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2432,7 +2432,7 @@ static int kprobes_module_callback(struct
> notifier_block *nb,
>within_module_core((unsigned long)p->addr, mod))) {
> /*
>* The vaddr this probe is installed will soon
> - * be vfreed buy not synced to disk. Hence,
> + * be vfreed but not synced to disk. Hence,
>* disarming the breakpoint isn't needed.
>*
>* Note, this will also move any optimized
> probes
>
--
~Randy
Re: [PATCH] scsi: sym53c8xx_2: fix sizeof mismatch
Colin, > An incorrect sizeof is being used, struct sym_ccb ** is not correct, > it should be struct sym_ccb *. Note that since ** is the same size as > * this is not causing any issues. Improve this fix by using the idiom > sizeof(*np->ccbh) as this allows one to not even reference the type of > the pointer. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH V2] kprobes: Correct a typo in function kprobes_module_callback
There is a tiny typo in comment of function kprobes_module_callback.
Signed-off-by: Zhouyi Zhou
---
kernel/kprobes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e995541..9d2042b 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2432,7 +2432,7 @@ static int kprobes_module_callback(struct notifier_block
*nb,
within_module_core((unsigned long)p->addr, mod))) {
/*
* The vaddr this probe is installed will soon
-* be vfreed buy not synced to disk. Hence,
+* be vfreed but not synced to disk. Hence,
* disarming the breakpoint isn't needed.
*
* Note, this will also move any optimized
probes
--
1.7.1
RE: [likely PATCH] MAINTAINERS: CISCO VIC LOW LATENCY NIC DRIVER
> -Original Message- > From: Joe Perches > Sent: Wednesday, October 7, 2020 7:47 PM > To: Christian Benvenuti (benve) ; Nelson Escobar > (neescoba) > Cc: Doug Ledford ; Jason Gunthorpe > ; linux-r...@vger.kernel.org; LKML ker...@vger.kernel.org> > Subject: [likely PATCH] MAINTAINERS: CISCO VIC LOW LATENCY NIC DRIVER > > Parvi Kaustubhi's email bounces. > > Signed-off-by: Joe Perches Thanks Joe. Acked-by: Christian Benvenuti > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9ecb727f0a8f..3647500be78f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4275,7 +4275,6 @@ F: drivers/net/ethernet/cisco/enic/ > CISCO VIC LOW LATENCY NIC DRIVER > M: Christian Benvenuti > M: Nelson Escobar > -M: Parvi Kaustubhi > S: Supported > F: drivers/infiniband/hw/usnic/ >
linux-next: build failure after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: I noticed that the ingenic driver revert I had been waiting for appeared in hte drm-misc tree, so I removed the BROKEN dependency for it, but it produced the above errors, so I have marked it BROKEN again. -- Cheers, Stephen Rothwell pgpf39fK0pSrS.pgp Description: OpenPGP digital signature
Re: [PATCH] scsi: isci: Fix a typo in a comment
Christophe, > s/remtoe/remote/ > and add a missing '.' Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] kprobes: Correct a type error in function kprobes_module_callback
Thanks for the tip!
On Thu, Oct 8, 2020 at 11:06 AM Randy Dunlap wrote:
>
> Hi,
>
> On 10/7/20 7:59 PM, Zhouyi Zhou wrote:
> > There is a tiny type error in comment of function kprobes_module_callback.
>
> Preferable
> typo
> and same in $Subject.
>
> 'type' usually means data type or maybe typedef, or even
> font or typeface.
>
> I suppose you could say a "typing" error (as in using a typewriter
> or keyboard).
>
> >
> > Signed-off-by: Zhouyi Zhou
> > ---
> > kernel/kprobes.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index e995541..9d2042b 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -2432,7 +2432,7 @@ static int kprobes_module_callback(struct
> > notifier_block *nb,
> >within_module_core((unsigned long)p->addr,
> > mod))) {
> > /*
> >* The vaddr this probe is installed will soon
> > - * be vfreed buy not synced to disk. Hence,
> > + * be vfreed but not synced to disk. Hence,
> >* disarming the breakpoint isn't needed.
> >*
> >* Note, this will also move any optimized
> > probes
> >
>
> thanks.
> --
> ~Randy
>
Re: [PATCH] kprobes: Correct a type error in function kprobes_module_callback
Hi,
On 10/7/20 7:59 PM, Zhouyi Zhou wrote:
> There is a tiny type error in comment of function kprobes_module_callback.
Preferable
typo
and same in $Subject.
'type' usually means data type or maybe typedef, or even
font or typeface.
I suppose you could say a "typing" error (as in using a typewriter
or keyboard).
>
> Signed-off-by: Zhouyi Zhou
> ---
> kernel/kprobes.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index e995541..9d2042b 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2432,7 +2432,7 @@ static int kprobes_module_callback(struct
> notifier_block *nb,
>within_module_core((unsigned long)p->addr, mod))) {
> /*
>* The vaddr this probe is installed will soon
> - * be vfreed buy not synced to disk. Hence,
> + * be vfreed but not synced to disk. Hence,
>* disarming the breakpoint isn't needed.
>*
>* Note, this will also move any optimized
> probes
>
thanks.
--
~Randy
[PATCH] kprobes: Correct a type error in function kprobes_module_callback
There is a tiny type error in comment of function kprobes_module_callback.
Signed-off-by: Zhouyi Zhou
---
kernel/kprobes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e995541..9d2042b 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2432,7 +2432,7 @@ static int kprobes_module_callback(struct notifier_block
*nb,
within_module_core((unsigned long)p->addr, mod))) {
/*
* The vaddr this probe is installed will soon
-* be vfreed buy not synced to disk. Hence,
+* be vfreed but not synced to disk. Hence,
* disarming the breakpoint isn't needed.
*
* Note, this will also move any optimized
probes
--
1.7.1
Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps
On Oct 7, 2020, at 2:14 PM, Josh Triplett wrote: > If those aren't the right way to express that, I could potentially > adapt. I had a similar such conversation on linux-ext4 already (about > inline data with 128-bit inodes), which led to me choosing to abandon > 128-byte inodes rather than try to get ext4 to support what I wanted > with them, because I didn't want to be disruptive to ext4 for a niche > use case. In the particular case that motivated this thread, what I was > doing already worked in previous kernels, and it seemed reasonable to > ask for it to continue to work in new kernels, while preserving the > newly added checks in the new kernels. This was discussed in the "Inline data with 128-byte inodes?" thread back in May. While Jan was not necessarily in favour of this, I was actually OK with improving the ext4 code to handle this case better, since it would (at minimum) clean up ext4 to make a clear separation of how it is detecting data in the i_block[] array and the system.data xattr, and I don't think it added any complexity to the code. I even posted a WIP patch to that effect, but didn't get a response back: https://marc.info/?l=linux-ext4=158863275019187 I *do* think that inline_data is an under-appreciated feature that I would be happy to see some improvements with. I don't think that small files are a niche use case, and if we can clean up the inline_data code to work with 128-byte inodes I'm not against that, even though I'm not going to use that combination of features myself. Cheers, Andreas signature.asc Description: Message signed with OpenPGP
Re: [PATCH] misc: Kconfig: add a new dependency for HISI_HIKEY_USB
On 10/7/20 7:18 PM, Nathan Chancellor wrote: > On Wed, Oct 07, 2020 at 07:09:54AM +0200, Mauro Carvalho Chehab wrote: >> As warned by Randy: >> >> on x86_64: >> CONFIG_USB_ROLE_SWITCH=m >> and HISI_HIKEY_USB=y. >> >> ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_remove': >> hisi_hikey_usb.c:(.text+0x61): undefined reference to >> `usb_role_switch_unregister' >> ld: hisi_hikey_usb.c:(.text+0xa4): undefined reference to >> `usb_role_switch_put' >> ld: drivers/misc/hisi_hikey_usb.o: in function >> `hub_usb_role_switch_set': >> hisi_hikey_usb.c:(.text+0xd3): undefined reference to >> `usb_role_switch_get_drvdata' >> ld: drivers/misc/hisi_hikey_usb.o: in function `relay_set_role_switch': >> hisi_hikey_usb.c:(.text+0x54d): undefined reference to >> `usb_role_switch_set_role' >> ld: drivers/misc/hisi_hikey_usb.o: in function `hisi_hikey_usb_probe': >> hisi_hikey_usb.c:(.text+0x8a5): undefined reference to >> `usb_role_switch_get' >> ld: hisi_hikey_usb.c:(.text+0xa08): undefined reference to >> `usb_role_switch_register' >> ld: hisi_hikey_usb.c:(.text+0xa6e): undefined reference to >> `usb_role_switch_put' >> >> Make it dependent on CONFIG_USB_ROLE_SWITCH. >> >> Reported-by: Randy Dunlap >> Signed-off-by: Mauro Carvalho Chehab >> --- >> drivers/misc/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig >> index e19e1dcceb41..7cee2b72c09e 100644 >> --- a/drivers/misc/Kconfig >> +++ b/drivers/misc/Kconfig >> @@ -459,6 +459,7 @@ config PVPANIC >> config HISI_HIKEY_USB >> tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform" >> depends on (OF && GPIOLIB) || COMPILE_TEST >> +depends on CONFIG_USB_ROLE_SWITCH > > Shouldn't this be > > depends on USB_ROLE_SWITCH Obviously. Thanks for catching that. > ? Now it will never be selectable. > >> help >>If you say yes here this adds support for the on-board USB GPIO hub >>found on HiKey 960/970 boards, which is necessary to support >> -- >> 2.26.2 >> > > Cheers, > Nathan > -- ~Randy
Re: Bug in herd7 [Was: Re: Litmus test for question from Al Viro]
On Wed, Oct 07, 2020 at 10:25:37PM -0400, Alan Stern wrote:
> On Wed, Oct 07, 2020 at 03:38:51PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 07, 2020 at 03:40:50PM -0400, Alan Stern wrote:
> > > On Wed, Oct 07, 2020 at 10:50:40AM -0700, Paul E. McKenney wrote:
> > > > And here is the updated version.
> > > >
> > > > Thanx, Paul
> > > >
> > > >
> > > >
> > > > commit b7cd60d4b41ad56b32b36b978488f509c4f7e228
> > > > Author: Alan Stern
> > > > Date: Tue Oct 6 09:38:37 2020 -0700
> > > >
> > > > manual/kernel: Add LB+mb+data litmus test
> > >
> > > Let's change this to:
> > >
> > > manual/kernel: Add LB data dependency test with no intermediate
> > > variable
> > >
> > > Without that extra qualification, people reading just the title would
> > > wonder why we need a simple LB litmus test in the archive.
>
> > I might get this right sooner or later. You never know.
> >
> > Like this?
> >
> > Thanx, Paul
>
> Paul, I think you must need new reading glasses. You completely missed
> the text above.
There are some distractions at the moment.
Please see below. If this is not exactly correct, I will use "git rm"
and let you submit the patch as you wish.
Thanx, Paul
commit dc0119c24b64f9d541b94ba5d17eec0cbc265bfa
Author: Alan Stern
Date: Tue Oct 6 09:38:37 2020 -0700
manual/kernel: Add LB data dependency test with no intermediate variable
Test whether herd7 can detect a data dependency when there is no
intermediate local variable, as in WRITE_ONCE(*x, READ_ONCE(*y)).
Commit 0f3f8188a326 in herdtools fixed an oversight which caused such
dependencies to be missed.
Signed-off-by: Alan Stern
Signed-off-by: Paul E. McKenney
diff --git a/manual/kernel/C-LB+mb+data.litmus
b/manual/kernel/C-LB+mb+data.litmus
new file mode 100644
index 000..e9e24e0
--- /dev/null
+++ b/manual/kernel/C-LB+mb+data.litmus
@@ -0,0 +1,27 @@
+C LB+mb+data
+(*
+ * Result: Never
+ *
+ * Versions of herd7 prior to commit 0f3f8188a326 ("[herd] Fix dependency
+ * definition") recognize data dependencies only when they flow through
+ * an intermediate local variable. Since the dependency in P1 doesn't,
+ * those versions get the wrong answer for this test.
+ *)
+
+{}
+
+P0(int *x, int *y)
+{
+ int r1;
+
+ r1 = READ_ONCE(*x);
+ smp_mb();
+ WRITE_ONCE(*y, r1);
+}
+
+P1(int *x, int *y)
+{
+ WRITE_ONCE(*x, READ_ONCE(*y));
+}
+
+exists (0:r1=1)
Re: [PATCH] scsi: myrb: remove redundant assignment to variable timeout
Jing, > The variable timeout has been initialized with a value '0'. The assignment > before while loop is redundant. So remove it. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] docs: Make automarkup ready for Sphinx 3.1+
On Thu, Oct 08, 2020 at 02:15:24AM +, Nícolas F. R. A. Prado wrote: > > I have a feature request ... could you automarkup NULL as being > > :c:macro? > > Or maybe just anything matching \<[[:upper:]_[:digit:]]*\> > > (i may have my regex syntax confused ... a word composed of any > > arrangement of upper-case, digits and underscores.) > > I think what you are suggesting are two separate things. > > For NULL, what you're interested in is that it appears in a monospaced font, > as > if written ``NULL``, right? As I don't think a cross-reference to "the NULL > macro definition" would make much sense. > > While "anything containing only upper-case, digits and underscores" would > actually be for cross-referencing to the definition of the macro symbol in > question, right? Well, maybe! What I'd really like is to remove all the markup from xarray.rst. Jon managed to get rid of most of it with the (), but there's still markup on: LONG_MAX NULL -EBUSY true XA_MARK_[012] XA_FLAGS_* ENOMEM EINVAL I'm not sure there's much that automarkup can do about ``true``, but all the others fit the all-caps-and-underscore-and-digits pattern. I don't know how much we want errnos to link to anything in particular. So maybe split these into 'well-known' (eg defined by ANSI C or POSIX) definitions and things which are local macros: LONG_MAX NULL -EBUSY ENOMEM EINVAL vs XA_MARK_[012] XA_FLAGS_* I'm willing to add more inline kernel-doc to get this to work better. Or even convert #defines to enums ... whatever gets this working better. > At the moment, this automarkup script is being used only for > cross-referencing, > but it is indeed a generic automarkup script, and could be used for the > formatting of NULL. But we also can't just make every upper-case word written > in monospaced font, as that doesn't always makes sense. > > So if I understood your two requests correctly, I think we could: > 1. Always automatically format NULL using a literal ``. > 2. Try to cross-reference every upper-case word with the macro definition > using > :c:macro, but if the cross-reference doesn't exist, format it normally, since > it's just normal text (this is what we're doing for C references at the > moment). > > What do you think? I think this works well, except that we need to match not just NULL but other well-known ANSI/POSIX keywords. Thanks for entertaining this!
[likely PATCH] MAINTAINERS: CISCO VIC LOW LATENCY NIC DRIVER
Parvi Kaustubhi's email bounces. Signed-off-by: Joe Perches --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9ecb727f0a8f..3647500be78f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4275,7 +4275,6 @@ F:drivers/net/ethernet/cisco/enic/ CISCO VIC LOW LATENCY NIC DRIVER M: Christian Benvenuti M: Nelson Escobar -M: Parvi Kaustubhi S: Supported F: drivers/infiniband/hw/usnic/
Re: [PATCH] scsi: bfa: fix error return in bfad_pci_init()
Jing, > Fix to return error code -ENODEV from the error handling case instead > of 0. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v10 3/3] clk: mediatek: add UART0 clock support
On Wed, 2020-10-07 at 19:00 -0700, Stephen Boyd wrote: > Quoting Hanks Chen (2020-10-03 03:06:47) > > Hi Michael & Stephen, > > > > Please kindly let me know your comments about this patch. > > Thanks > > > > What's the base for this patch? I tried applying to v5.9-rc1 and it > didn't work. Sorry, what does that mean? Do you have encountered a merged conflict or run time failed? I based on kernel-5.8-rc1 to add it and it can boot to kernel shell. Thanks! Hanks Chen
Re: [PATCH -next] scsi: fcoe: simplify the return expression of fcoe_sysfs_setup
Qinglang, > Simplify the return expression. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] snic: simplify the return expression of svnic_cq_alloc
Liu, > Simplify the return expression. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH-next 0/4] RDMA: sprintf to sysfs_emit conversions
A recent commit added a sysfs_emit and sysfs_emit_at to allow various sysfs show functions to ensure that the PAGE_SIZE buffer argument is never overrun and always NUL terminated. Convert the RDMA/InfiniBand subsystem to use these new functions. The first 2 patches exclusively used coccinelle to convert uses. The third and fourth patches were done manually. Compiled allyesconfig and defconfig with all infiniband options selected no warnings, but untested, no hardward Overall object size is reduced total size: allyesconfig x86-64 new: 83640031680968 131520 10176491 9b47eb (TOTALS) old: 83658831681032 131520 10178435 9b4f83 (TOTALS) total size: defconfig x86-64 with all infiniband selected new; 1359153 1312281910 1492291 16c543 (TOTALS) old: 1359422 1312281910 1492560 16c650 (TOTALS) Joe Perches (4): RDMA: Convert sysfs device * show functions to use sysfs_emit() RDMA: Convert sysfs kobject * show functions to use sysfs_emit() RDMA: manual changes for sysfs_emit and neatening RDMA: Convert various random sprintf sysfs _show uses to sysfs_emit drivers/infiniband/core/cm.c | 4 +- drivers/infiniband/core/cma_configfs.c| 4 +- drivers/infiniband/core/sysfs.c | 155 ++ drivers/infiniband/core/ucma.c| 2 +- drivers/infiniband/core/user_mad.c| 6 +- drivers/infiniband/core/uverbs_main.c | 4 +- drivers/infiniband/hw/bnxt_re/main.c | 4 +- drivers/infiniband/hw/cxgb4/provider.c| 13 +- drivers/infiniband/hw/hfi1/sysfs.c| 62 --- drivers/infiniband/hw/i40iw/i40iw_verbs.c | 6 +- drivers/infiniband/hw/mlx4/main.c | 9 +- drivers/infiniband/hw/mlx4/mcg.c | 82 + drivers/infiniband/hw/mlx4/sysfs.c| 70 drivers/infiniband/hw/mlx5/main.c | 13 +- drivers/infiniband/hw/mthca/mthca_provider.c | 33 ++-- drivers/infiniband/hw/ocrdma/ocrdma_main.c| 4 +- drivers/infiniband/hw/qedr/main.c | 10 +- drivers/infiniband/hw/qib/qib_sysfs.c | 91 +- drivers/infiniband/hw/usnic/usnic_ib_sysfs.c | 104 +--- .../infiniband/hw/vmw_pvrdma/pvrdma_main.c| 6 +- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 4 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 7 +- drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 2 +- drivers/infiniband/ulp/rtrs/rtrs-clt-sysfs.c | 60 +++ drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 20 +-- drivers/infiniband/ulp/srp/ib_srp.c | 49 +++--- drivers/infiniband/ulp/srpt/ib_srpt.c | 14 +- 28 files changed, 423 insertions(+), 417 deletions(-) -- 2.26.0
Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver
On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote:
>
> On 27/08/2020 05:06, Neal Liu wrote:
> > MediaTek bus fabric provides TrustZone security support and data
> > protection to prevent slaves from being accessed by unexpected
> > masters.
> > The security violation is logged and sent to the processor for
> > further analysis or countermeasures.
> >
> > Any occurrence of security violation would raise an interrupt, and
> > it will be handled by mtk-devapc driver. The violation
> > information is printed in order to find the murderer.
>
> "The violation information is printed in order to find the responsible
> component."
>
> Nobody got actually killed, right :)
Correct !
>
> >
> > Signed-off-by: Neal Liu
> > ---
> > drivers/soc/mediatek/Kconfig |9 ++
> > drivers/soc/mediatek/Makefile |1 +
> > drivers/soc/mediatek/mtk-devapc.c | 305
> > +
> > 3 files changed, 315 insertions(+)
> > create mode 100644 drivers/soc/mediatek/mtk-devapc.c
> >
> > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> > index 59a56cd..1177c98 100644
> > --- a/drivers/soc/mediatek/Kconfig
> > +++ b/drivers/soc/mediatek/Kconfig
> > @@ -17,6 +17,15 @@ config MTK_CMDQ
> > time limitation, such as updating display configuration during the
> > vblank.
> >
> > +config MTK_DEVAPC
> > + tristate "Mediatek Device APC Support"
> > + help
> > + Say yes here to enable support for Mediatek Device APC driver.
> > + This driver is mainly used to handle the violation which catches
> > + unexpected transaction.
> > + The violation information is logged for further analysis or
> > + countermeasures.
> > +
> > config MTK_INFRACFG
> > bool "MediaTek INFRACFG Support"
> > select REGMAP
> > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> > index 01f9f87..abfd4ba 100644
> > --- a/drivers/soc/mediatek/Makefile
> > +++ b/drivers/soc/mediatek/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> > +obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
> > obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c
> > b/drivers/soc/mediatek/mtk-devapc.c
> > new file mode 100644
> > index 000..0ba61d7
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -0,0 +1,305 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 MediaTek Inc.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define VIO_MOD_TO_REG_IND(m) ((m) / 32)
> > +#define VIO_MOD_TO_REG_OFF(m) ((m) % 32)
> > +
> > +struct mtk_devapc_vio_dbgs {
> > + union {
> > + u32 vio_dbg0;
> > + struct {
> > + u32 mstid:16;
> > + u32 dmnid:6;
> > + u32 vio_w:1;
> > + u32 vio_r:1;
> > + u32 addr_h:4;
> > + u32 resv:4;
> > + } dbg0_bits;
> > + };
> > +
> > + u32 vio_dbg1;
> > +};
> > +
> > +struct mtk_devapc_data {
> > + u32 vio_idx_num;
> > + u32 vio_mask_offset;
> > + u32 vio_sta_offset;
> > + u32 vio_dbg0_offset;
> > + u32 vio_dbg1_offset;
> > + u32 apc_con_offset;
> > + u32 vio_shift_sta_offset;
> > + u32 vio_shift_sel_offset;
> > + u32 vio_shift_con_offset;
> > +};
>
> Please describe the fields of the struct, that will make it easier to
> understand
> the driver.
Okay, I'll try to add more description about this struct. May be like:
struct mtk_devapc_data {
/* numbers of violation index */
u32 vio_idx_num;
/* reg offset */
u32 vio_mask_offset;
u32 vio_sta_offset;
u32 vio_dbg0_offset;
u32 vio_dbg1_offset;
u32 apc_con_offset;
u32 vio_shift_sta_offset;
u32 vio_shift_sel_offset;
u32 vio_shift_con_offset;
};
>
> > +
> > +struct mtk_devapc_context {
> > + struct device *dev;
> > + void __iomem *infra_base;
> > + struct clk *infra_clk;
> > + const struct mtk_devapc_data *data;
> > +};
> > +
> > +static void clear_vio_status(struct mtk_devapc_context *ctx)
> > +{
> > + void __iomem *reg;
> > + int i;
> > +
> > + reg = ctx->infra_base + ctx->data->vio_sta_offset;
> > +
> > + for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++)
> > + writel(GENMASK(31, 0), reg + 4 * i);
> > +
> > + writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), 0),
> > + reg + 4 * i);
> > +}
> > +
> > +static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
> > +{
> > + void __iomem *reg;
> > + u32 val;
> > + int i;
> > +
> > + reg = ctx->infra_base + ctx->data->vio_mask_offset;
> >
Re: [PATCH -next] [SCSI] fnic: simplify the return expression of vnic_wq_copy_alloc
Liu, > Simplify the return expression. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
RE: [PATCH 1/1] clk: aspeed: modify some default clks are critical
> -Original Message-
> From: Joel Stanley
> Sent: Wednesday, October 7, 2020 7:34 PM
> To: Ryan Chen
> Cc: Jae Hyun Yoo ; Andrew Jeffery
> ; Michael Turquette ; Stephen
> Boyd ; linux-...@vger.kernel.org; Linux ARM
> ; linux-aspeed
> ; Linux Kernel Mailing List
> ; BMC-SW
> Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical
>
> On Tue, 29 Sep 2020 at 08:40, Ryan Chen
> wrote:
> >
> > > From: Joel Stanley
> > > Sent: Tuesday, September 29, 2020 4:04 PM
> > > To: Ryan Chen ; Jae Hyun Yoo
> > > ; Andrew Jeffery
> > > Cc: Michael Turquette ; Stephen Boyd
> > > ; linux-...@vger.kernel.org; Linux ARM
> > > ; linux-aspeed
> > > ; Linux Kernel Mailing List
> > > ; BMC-SW
> > > Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are
> > > critical
> > >
> > > On Mon, 28 Sep 2020 at 07:01, Ryan Chen
> > > wrote:
> > > >
> > > > In ASPEED SoC LCLK is LPC clock for all SuperIO device,
> > > > UART1/UART2 are default for Host SuperIO UART device, eSPI clk for
> > > > Host eSPI bus access eSPI slave channel, those clks can't be
> > > > disable should keep default, otherwise will affect Host side access
> SuperIO and SPI slave device.
> > > >
> > > > Signed-off-by: Ryan Chen
> > > > ---
> > > > drivers/clk/clk-aspeed.c | 8 drivers/clk/clk-ast2600.c
> > > > | 8
> > > >
> > > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
> > > > index 411ff5fb2c07..d348c4fd3f9f 100644
> > > > --- a/drivers/clk/clk-aspeed.c
> > > > +++ b/drivers/clk/clk-aspeed.c
> > > > @@ -54,15 +54,15 @@ static const struct aspeed_gate_data
> > > > aspeed_gates[]
> > > = {
> > > > [ASPEED_CLK_GATE_DCLK] ={ 5, -1, "dclk-gate",
> > > NULL, CLK_IS_CRITICAL }, /* DAC */
> > > > [ASPEED_CLK_GATE_REFCLK] = { 6, -1, "refclk-gate",
> > > "clkin", CLK_IS_CRITICAL },
> > > > [ASPEED_CLK_GATE_USBPORT2CLK] = { 7, 3,
> > > > "usb-port2-gate",
> > > NULL, 0 }, /* USB2.0 Host port 2 */
> > > > - [ASPEED_CLK_GATE_LCLK] ={ 8, 5, "lclk-gate",
> > > NULL, 0 }, /* LPC */
> > > > + [ASPEED_CLK_GATE_LCLK] ={ 8, 5, "lclk-gate",
> > > NULL, CLK_IS_CRITICAL }, /* LPC */
> > > > [ASPEED_CLK_GATE_USBUHCICLK] = { 9, 15,
> "usb-uhci-gate",
> > > NULL, 0 }, /* USB1.1 (requires port 2 enabled) */
> > > > [ASPEED_CLK_GATE_D1CLK] = { 10, 13, "d1clk-gate",
> > > NULL, 0 }, /* GFX CRT */
> > > > [ASPEED_CLK_GATE_YCLK] ={ 13, 4, "yclk-gate",
> > > NULL, 0 }, /* HAC */
> > > > [ASPEED_CLK_GATE_USBPORT1CLK] = { 14, 14,
> > > > "usb-port1-gate",
> > > NULL, 0 }, /* USB2 hub/USB2 host port 1/USB1.1 dev */
> > > > - [ASPEED_CLK_GATE_UART1CLK] ={ 15, -1, "uart1clk-gate",
> > > "uart", 0 }, /* UART1 */
> > > > - [ASPEED_CLK_GATE_UART2CLK] ={ 16, -1, "uart2clk-gate",
> > > "uart", 0 }, /* UART2 */
> > > > + [ASPEED_CLK_GATE_UART1CLK] ={ 15, -1, "uart1clk-gate",
> > > "uart", CLK_IS_CRITICAL }, /* UART1 */
> > > > + [ASPEED_CLK_GATE_UART2CLK] ={ 16, -1, "uart2clk-gate",
> > > "uart", CLK_IS_CRITICAL }, /* UART2 */
> > > > [ASPEED_CLK_GATE_UART5CLK] ={ 17, -1,
> "uart5clk-gate",
> > > "uart", 0 }, /* UART5 */
> > > > - [ASPEED_CLK_GATE_ESPICLK] = { 19, -1, "espiclk-gate",
> > > NULL, 0 }, /* eSPI */
> > > > + [ASPEED_CLK_GATE_ESPICLK] = { 19, -1, "espiclk-gate",
> > > NULL, CLK_IS_CRITICAL }, /* eSPI */
> > >
> > > This is fine for systems that have eSPI. For systems that do not use
> > > eSPI, the clocks are not "required".
> > >
> > > I was sent a similar patch by Jae some time ago:
> > >
> > >
> > > https://lore.kernel.org/openbmc/697a184b-ef99-a46e-bf98-4d339b3aafd8
> > > @lin
> > > ux.intel.com/
> > >
> > > Better is to associate drivers with these clocks, and those drivers
> > > will ensure they are left enabled.
> > >
> > > Alternatively, we will need to come up with a device tree binding to
> > > describe the hardware requirement that these clocks are left on.
> > >
> > ASPEED BMC SoC have SuperIO device that default enable, even without
> BMC fw boot.
> > Host can use SUART1/SUART2/GPIO
> > That the reason even Linux kernel boot should not change the SoC default
> > clk,
> that is the impact.
>
> Ok, that makes sense. Linux will not enable these clocks if a driver is loaded
> for them though, so we should load a driver for them.
>
> ESPI: We do not have an upstream driver for eSPI, but once you submit one this
> will solve the eSPI issue.
>
> LPC: The existing LPC driver will enable the clock, so by loading that this
> clock
> will be left enabled.
>
> UART1/UART2: This is harder, as the SUART mode means the BMC does not
> load a driver for these devices. We could add a property to the device tree to
> describe the clocks that must be left on?
That following the example,
BMC is stop in u-boot stage, the eSPI
Re: [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk
Hi Lyude,
> On Oct 8, 2020, at 05:53, Lyude Paul wrote:
>
> Hi! I thought this patch rang a bell, we actually already had some discussion
> about this since there's a couple of other systems this was causing issues
> for.
> Unfortunately it never seems like that patch got sent out. Satadru?
>
> (if I don't hear back from them soon, I'll just send out a patch for this
> myself)
>
> JFYI - the proper fix here is to just drop the
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long
> as
> the backlight supports AUX_SET_CAP, that should be enough for us to control
> it.
Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?
Kai-Heng
>
>
> On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
>> HP DreamColor panel needs to be controlled via AUX interface. However,
>> it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
>> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
>> intel_dp_aux_display_control_capable() test.
>>
>> Skip the test if the panel has force DPCD quirk.
>>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index acbd7eb66cbe..acf2e1c65290 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>> struct intel_panel *panel = _connector->panel;
>> struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
>> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> +bool force_dpcd;
>> +
>> +force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
>> + DP_QUIRK_FORCE_DPCD_BACKLIGHT);
>>
>> if (i915->params.enable_dpcd_backlight == 0 ||
>> -!intel_dp_aux_display_control_capable(intel_connector))
>> +(!force_dpcd &&
>> !intel_dp_aux_display_control_capable(intel_connector)))
>> return -ENODEV;
>>
>> /*
>> @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>> */
>> if (i915->vbt.backlight.type !=
>> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
>> -i915->params.enable_dpcd_backlight != 1 &&
>> -!drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
>> - DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
>> +i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
>> drm_info(>drm,
>> "Panel advertises DPCD backlight support, but "
>> "VBT disagrees. If your backlight controls "
> --
> Sincerely,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
Re: [PATCH 02/14] target/rd: drop double zeroing
Julia, > sg_init_table zeroes its first argument, so the allocation of that argument > doesn't have to. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 2/2] riscv: Fixup static_obj() fail v2
On Thu, Oct 8, 2020 at 3:46 AM Atish Patra wrote:
>
> On Wed, Oct 7, 2020 at 8:09 AM wrote:
> >
> > From: Guo Ren
> >
> > v1 is commit: 6184358da0004c8fd940afda6c0a0fa4027dc911 which has
> > been reverted.
> >
> > When enable LOCKDEP, static_obj() will cause error:
> >
> > [0.067192] INFO: trying to register non-static key.
> > [0.067325] the code is fine but needs lockdep annotation.
> > [0.067449] turning off the locking correctness validator.
> > [0.067718] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7-dirty #44
> > [0.067945] Call Trace:
> > [0.068369] [] walk_stackframe+0x0/0xa4
> > [0.068506] [] show_stack+0x2a/0x34
> > [0.068631] [] dump_stack+0x94/0xca
> > [0.068757] [] register_lock_class+0x5b8/0x5bc
> > [0.068969] [] __lock_acquire+0x6c/0x1d5c
> > [0.069101] [] lock_acquire+0xae/0x312
> > [0.069228] [] _raw_spin_lock_irqsave+0x40/0x5a
> > [0.069357] [] complete+0x1e/0x50
> > [0.069479] [] rest_init+0x1b0/0x28a
> > [0.069660] [] 0xffe016a2
> > [0.069779] [] 0xffe01b84
> > [0.069953] [] 0xffe01092
> >
> > Because some __initdata static variables is before _stext:
> >
> > static int static_obj(const void *obj)
> > {
> > unsigned long start = (unsigned long) &_stext,
> > end = (unsigned long) &_end,
> > addr = (unsigned long) obj;
> >
> > /*
> > * static variable?
> > */
> > if ((addr >= start) && (addr < end))
> > return 1;
> >
> > if (arch_is_kernel_data(addr))
> > return 1;
> >
> > We could implement arch_is_kernel_data to fixup it.
> >
> > Link:
> > https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guo...@kernel.org/T/#t
> > Signed-off-by: Guo Ren
> > Reported-by: Aurelien Jarno
> > Cc: Palmer Dabbelt
> > Cc: Atish Patra
> > Cc: Andreas Schwab
> > Cc: Aurelien Jarno
> > ---
> > arch/riscv/include/asm/sections.h | 20
> > arch/riscv/kernel/setup.c | 9 +
> > 2 files changed, 29 insertions(+)
> > create mode 100644 arch/riscv/include/asm/sections.h
> >
> > diff --git a/arch/riscv/include/asm/sections.h
> > b/arch/riscv/include/asm/sections.h
> > new file mode 100644
> > index ..2317b9e
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/sections.h
>
> You may want to rebase it on top of for-next as UEFI series also adds this
> file.
ok
> .
>
> > @@ -0,0 +1,20 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +#ifndef _ASM_RISCV_SECTIONS_H
> > +#define _ASM_RISCV_SECTIONS_H
> > +
> > +#define arch_is_kernel_data arch_is_kernel_data
> > +
> > +#include
> > +
> > +extern bool init_mem_is_free;
> > +
> > +static inline int arch_is_kernel_data(unsigned long addr)
> > +{
> > + if (init_mem_is_free)
> > + return 0;
> > +
> > + return addr >= (unsigned long)__init_begin &&
> > + addr < (unsigned long)__init_end;
> > +}
> > +#endif /* _ASM_RISCV_SECTIONS_H */
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 2c6dd32..9ebd5eb4 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -112,3 +113,11 @@ static int __init topology_init(void)
> > return 0;
> > }
> > subsys_initcall(topology_init);
> > +
> > +bool init_mem_is_free = false;
> > +
> > +void free_initmem(void)
> > +{
> > + free_initmem_default(POISON_FREE_INITMEM);
> > + init_mem_is_free = true;
> > +}
> > --
> > 2.7.4
> >
>
> Looks good. Much cleaner than the first approach.
> FYI: I am still looking into separating __init text & data so that
> different permissions can be applied to them.
> With this patch, we can just separate it on top of _stext.
>
>
> Reviewed-by: Atish Patra
>
> --
> Regards,
> Atish
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [PATCH -next v2] scsi: qla2xxx: Convert to DEFINE_SHOW_ATTRIBUTE
>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: Bug in herd7 [Was: Re: Litmus test for question from Al Viro]
On Wed, Oct 07, 2020 at 03:38:51PM -0700, Paul E. McKenney wrote: > On Wed, Oct 07, 2020 at 03:40:50PM -0400, Alan Stern wrote: > > On Wed, Oct 07, 2020 at 10:50:40AM -0700, Paul E. McKenney wrote: > > > And here is the updated version. > > > > > > Thanx, Paul > > > > > > > > > > > > commit b7cd60d4b41ad56b32b36b978488f509c4f7e228 > > > Author: Alan Stern > > > Date: Tue Oct 6 09:38:37 2020 -0700 > > > > > > manual/kernel: Add LB+mb+data litmus test > > > > Let's change this to: > > > > manual/kernel: Add LB data dependency test with no intermediate > > variable > > > > Without that extra qualification, people reading just the title would > > wonder why we need a simple LB litmus test in the archive. > I might get this right sooner or later. You never know. > > Like this? > > Thanx, Paul Paul, I think you must need new reading glasses. You completely missed the text above. Alan > > > commit 5b6a4ff2c8ad25fc77f4151e71e6cbd8f3268d7b > Author: Alan Stern > Date: Tue Oct 6 09:38:37 2020 -0700 > > manual/kernel: Add LB+mb+data litmus test > > Test whether herd7 can detect a data dependency when there is no > intermediate local variable, as in WRITE_ONCE(*x, READ_ONCE(*y)). > Commit 0f3f8188a326 in herdtools fixed an oversight which caused such > dependencies to be missed. > > Signed-off-by: Alan Stern > Signed-off-by: Paul E. McKenney
Re: [PATCH] scsi: qla2xxx: initialize value
Tom, > clang static analysis reports this problem: > > qla_nx2.c:694:3: warning: 6th function call argument is > an uninitialized value > ql_log(ql_log_fatal, vha, 0xb090, > ^ Applied to 5.10/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
