Re: [PATCH] Documentation: admin-guide: add earlycon documentation for RISC-V

[Geert Uytterhoeven]

On Wed, Oct 9, 2019 at 9:53 PM Paul Walmsley  wrote:
> Kernels booting on RISC-V can specify "earlycon" with no options on
> the Linux command line, and the generic DT earlycon support will query
> the "chosen/stdout-path" property (if present) to determine which
> early console device to use.  Document this appropriately in the
> admin-guide.
>
> Signed-off-by: Paul Walmsley 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/3] hwmon: Add support for ltc2947

[Sa, Nuno]

Hi Guenter,

I got some feedback about energy max/min...

On Mon, 2019-10-07 at 14:51 +, Sa, Nuno wrote:
> On Mon, 2019-10-07 at 05:44 -0700, Guenter Roeck wrote:
> > On 10/7/19 5:25 AM, Sa, Nuno wrote:
> > > On Fri, 2019-10-04 at 08:06 -0700, Guenter Roeck wrote:
> > > > On Fri, Oct 04, 2019 at 07:45:07AM +, Sa, Nuno wrote:
> > > > [ ... ]
> > > > > > > +static int ltc2947_val_read(struct ltc2947_data *st,
> > > > > > > const
> > > > > > > u8
> > > > > > > reg,
> > > > > > > + const u8 page, const size_t size,
> > > > > > > s64 *val)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > + u64 __val = 0;
> > > > > > > +
> > > > > > > + mutex_lock(&st->lock);
> > > > > > > +
> > > > 
> > > > On a side note, suspend code is supposed to be atomic,
> > > > If this lock is held, the process or thread holding it
> > > > will likely stall suspend since it won't run.
> > > > At the very least, this would have to be a trylock,
> > > > with suspend failing if the lock can not be acquired.
> > > 
> > > Got it. Even more, Now I don't see the point of having the mutex
> > > in
> > > the
> > > PM callbacks (though I saw other drivers doing this). As you
> > > said,
> > > at
> > > the very least the trylock should be used since a frozen task
> > > might
> > > have the mutex locked. Either way, I will drop both the flag and
> > > the
> > > call to mutex_* functions is suspend()/resume().
> > > 
> > > > > > > + if (st->reset) {
> > > > > > > + mutex_unlock(&st->lock);
> > > > > > > + return -EPERM;
> > > > > > 
> > > > > > Not sure what the error here should be, but EPERM is not
> > > > > > correct.
> > > > > > 
> > > > > > Under which conditions would this function be called while
> > > > > > in
> > > > > > suspend ?
> > > > > 
> > > > > Honestly, this is more like a sanity check. I'm not sure if
> > > > > we
> > > > > can
> > > > > get
> > > > > here in suspend mode. Don't userland apps can still run in
> > > > > suspend?
> > > > > I
> > > > > guess so but I'm not 100% sure on this. Do you have any
> > > > > recommendation
> > > > > for the error here?
> > > > > 
> > > > Sorry, I won't accept "just in case" code.
> > > > 
> > > > Having said that, please inform yourself how suspend works.
> > > > Userland
> > > > code
> > > > has to be stopped before any hardware can be disabled. Similar,
> > > > hardware
> > > > has to be re-enabled before userland code can resume.
> > > > Otherwise the kernel would crash all over the place. In many
> > > > cases,
> > > > disabling the hardware means that trying to access hardware
> > > > registers
> > > > will cause an acess fault.
> > > 
> > > Yes, you are right. I did checked the suspend code and all
> > > userland
> > > tasks and kthreads are stopped before the suspend() callback is
> > > called
> > > for the HW devices.
> > > 
> > > > [...]
> > > > 
> > > > > > > +
> > > > > > > +static struct attribute *ltc2947_attrs[] = {
> > > > > > > + &sensor_dev_attr_in0_fault.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_in1_fault.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_curr1_fault.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_temp1_fault.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_power1_input.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_power1_max.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_power1_min.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_power1_input_highest.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_power1_input_lowest.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_power1_fault.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy1_input.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy1_max.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy1_min.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy1_max_alarm.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy1_min_alarm.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy2_input.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy2_max.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy2_min.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy2_max_alarm.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy2_min_alarm.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy1_overflow_alarm.dev_attr.attr,
> > > > > > > + &sensor_dev_attr_energy2_overflow_alarm.dev_attr.attr,
> > > > > 
> > > > > These overflow attributes are kind of an alarm for the energy
> > > > > ones.
> > > > > It
> > > > > tells that the energy registers are about to overflow. I
> > > > > guess
> > > > > that
> > > > > some application can easily find out the maximum values
> > > > > supported
> > > > > on
> > > > > these registers and implement whatever logic they want in the
> > > > > app
> > > > > itself. So, if you prefer I can just drop this ones?
> > > > > 
> > > > I understand the overflow use case. However, the mere presence
> > > > of min/max attributes for energy attributes suggests that this
> > > > is not the min/max use case for hwmon attributes. 

[PATCH bpf] xsk: improve documentation for AF_XDP

[Magnus Karlsson]

Added sections on all the bind flags, libbpf, all the setsockopts and
all the getsockopts. Also updated the document to reflect the latest
features and to correct some spelling errors.

Signed-off-by: Magnus Karlsson 
---
 Documentation/networking/af_xdp.rst | 262 
 1 file changed, 234 insertions(+), 28 deletions(-)

diff --git a/Documentation/networking/af_xdp.rst 
b/Documentation/networking/af_xdp.rst
index 83f7ae5..52e40d72 100644
--- a/Documentation/networking/af_xdp.rst
+++ b/Documentation/networking/af_xdp.rst
@@ -40,13 +40,13 @@ allocates memory for this UMEM using whatever means it 
feels is most
 appropriate (malloc, mmap, huge pages, etc). This memory area is then
 registered with the kernel using the new setsockopt XDP_UMEM_REG. The
 UMEM also has two rings: the FILL ring and the COMPLETION ring. The
-fill ring is used by the application to send down addr for the kernel
+FILL ring is used by the application to send down addr for the kernel
 to fill in with RX packet data. References to these frames will then
 appear in the RX ring once each packet has been received. The
-completion ring, on the other hand, contains frame addr that the
+COMPLETION ring, on the other hand, contains frame addr that the
 kernel has transmitted completely and can now be used again by user
 space, for either TX or RX. Thus, the frame addrs appearing in the
-completion ring are addrs that were previously transmitted using the
+COMPLETION ring are addrs that were previously transmitted using the
 TX ring. In summary, the RX and FILL rings are used for the RX path
 and the TX and COMPLETION rings are used for the TX path.
 
@@ -91,11 +91,16 @@ Concepts
 
 
 In order to use an AF_XDP socket, a number of associated objects need
-to be setup.
+to be setup. These objects and their options are explained in the
+following sections.
 
-Jonathan Corbet has also written an excellent article on LWN,
-"Accelerating networking with AF_XDP". It can be found at
-https://lwn.net/Articles/750845/.
+For an overview on how AF_XDP works, you can also take a look at the
+Linux Plumbers paper from 2018 on the subject:
+http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdf. Do
+NOT consult the paper from 2017 on "AF_PACKET v4", the first attempt
+at AF_XDP. Nearly everything changed since then. Jonathan Corbet has
+also written an excellent article on LWN, "Accelerating networking
+with AF_XDP". It can be found at https://lwn.net/Articles/750845/.
 
 UMEM
 
@@ -113,22 +118,22 @@ the next socket B can do this by setting the 
XDP_SHARED_UMEM flag in
 struct sockaddr_xdp member sxdp_flags, and passing the file descriptor
 of A to struct sockaddr_xdp member sxdp_shared_umem_fd.
 
-The UMEM has two single-producer/single-consumer rings, that are used
+The UMEM has two single-producer/single-consumer rings that are used
 to transfer ownership of UMEM frames between the kernel and the
 user-space application.
 
 Rings
 -
 
-There are a four different kind of rings: Fill, Completion, RX and
+There are a four different kind of rings: FILL, COMPLETION, RX and
 TX. All rings are single-producer/single-consumer, so the user-space
 application need explicit synchronization of multiple
 processes/threads are reading/writing to them.
 
-The UMEM uses two rings: Fill and Completion. Each socket associated
+The UMEM uses two rings: FILL and COMPLETION. Each socket associated
 with the UMEM must have an RX queue, TX queue or both. Say, that there
 is a setup with four sockets (all doing TX and RX). Then there will be
-one Fill ring, one Completion ring, four TX rings and four RX rings.
+one FILL ring, one COMPLETION ring, four TX rings and four RX rings.
 
 The rings are head(producer)/tail(consumer) based rings. A producer
 writes the data ring at the index pointed out by struct xdp_ring
@@ -146,7 +151,7 @@ The size of the rings need to be of size power of two.
 UMEM Fill Ring
 ~~
 
-The Fill ring is used to transfer ownership of UMEM frames from
+The FILL ring is used to transfer ownership of UMEM frames from
 user-space to kernel-space. The UMEM addrs are passed in the ring. As
 an example, if the UMEM is 64k and each chunk is 4k, then the UMEM has
 16 chunks and can pass addrs between 0 and 64k.
@@ -164,8 +169,8 @@ chunks mode, then the incoming addr will be left untouched.
 UMEM Completion Ring
 
 
-The Completion Ring is used transfer ownership of UMEM frames from
-kernel-space to user-space. Just like the Fill ring, UMEM indicies are
+The COMPLETION Ring is used transfer ownership of UMEM frames from
+kernel-space to user-space. Just like the FILL ring, UMEM indices are
 used.
 
 Frames passed from the kernel to user-space are frames that has been
@@ -181,7 +186,7 @@ The RX ring is the receiving side of a socket. Each entry 
in the ring
 is a struct xdp_desc descriptor. The descriptor contains UMEM offset
 (addr) and the length of the data (len).
 
-If 

[PATCH 4.19 097/114] arm64: Provide a command line to disable spectre_v2 mitigation

[Greg Kroah-Hartman]

From: Jeremy Linton 

[ Upstream commit e5ce5e7267ddcbe13ab9ead2542524e1b7993e5a ]

There are various reasons, such as benchmarking, to disable spectrev2
mitigation on a machine. Provide a command-line option to do so.

Signed-off-by: Jeremy Linton 
Reviewed-by: Suzuki K Poulose 
Reviewed-by: Andre Przywara 
Reviewed-by: Catalin Marinas 
Tested-by: Stefan Wahren 
Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/admin-guide/kernel-parameters.txt |8 
 arch/arm64/kernel/cpu_errata.c  |   13 +
 2 files changed, 17 insertions(+), 4 deletions(-)

--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2866,10 +2866,10 @@
(bounds check bypass). With this option data leaks
are possible in the system.
 
-   nospectre_v2[X86,PPC_FSL_BOOK3E] Disable all mitigations for the 
Spectre variant 2
-   (indirect branch prediction) vulnerability. System may
-   allow data leaks with this option, which is equivalent
-   to spectre_v2=off.
+   nospectre_v2[X86,PPC_FSL_BOOK3E,ARM64] Disable all mitigations for
+   the Spectre variant 2 (indirect branch prediction)
+   vulnerability. System may allow data leaks with this
+   option.
 
nospec_store_bypass_disable
[HW] Disable all mitigations for the Speculative Store 
Bypass vulnerability
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -189,6 +189,14 @@ static void qcom_link_stack_sanitization
 : "=&r" (tmp));
 }
 
+static bool __nospectre_v2;
+static int __init parse_nospectre_v2(char *str)
+{
+   __nospectre_v2 = true;
+   return 0;
+}
+early_param("nospectre_v2", parse_nospectre_v2);
+
 static void
 enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
 {
@@ -200,6 +208,11 @@ enable_smccc_arch_workaround_1(const str
if (!entry->matches(entry, SCOPE_LOCAL_CPU))
return;
 
+   if (__nospectre_v2) {
+   pr_info_once("spectrev2 mitigation disabled by command line 
option\n");
+   return;
+   }
+
if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
return;
 

Re: [PATCH] Documentation: networking: device drivers: Remove stray asterisks

[Jonathan Corbet]

On Wed, 9 Oct 2019 15:48:03 -0700
Jakub Kicinski  wrote:

> Hi Jon, I think Dave intended a few more patches to go via the doc
> tree, in particular:
> 
>  docs: networking: devlink-trap: Fix reference to other document
>  docs: networking: phy: Improve phrasing
> 
> Looks like those went missing. Would you mind taking those, or
> would you prefer for them to land in the networking trees?

Not missing, just sitting in a folder waiting for me to get back to
dealing with the queue.  I'll get caught up soon.

jon

Apply For Financial investment at a lower rate 2%

[Coryna Rizky Amelia, SST]

-- 
Hello,

We are private lenders based in UK.
Do you need a loan (credit) as soon as possible. Are you in search of
money to solve your personal needs or finance your business venture,
then get Your desired loan today! Consult us at Sunrise Funding Ltd.

* We offer personal loan & huge capital loan at 2% interest rate to
the general public both locally and internationally.
* Credit amount range from $5,000.00 -- $500,000.00 and above.
* Special $10,000,000.00 Loan offer for huge project also available.
* Loan period of 6 months -- 10 years.
* Loan is granted 24 hours after approval and accredited, directly in
hand or bank account.

Please note that you are advised to contact us for more details via
the following e-mail address below;

EMAIL : sunrisefundinglt...@gmail.com
FIRM : Sunrise Funding Ltd UK.

Re: [PATCH v8 3/5] mfd: ioc3: Add driver for SGI IOC3 chip

[Thomas Bogendoerfer]

On Wed, 9 Oct 2019 20:17:14 -0700
Jakub Kicinski  wrote:

> On Wed,  9 Oct 2019 12:17:10 +0200, Thomas Bogendoerfer wrote:
> [...]
> > +static int ioc3_cad_duo_setup(struct ioc3_priv_data *ipd)
> > +{
> > +   int ret;
> > +
> > +   ret = ioc3_irq_domain_setup(ipd, ipd->pdev->irq);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = ioc3_eth_setup(ipd, true);
> > +   if (ret)
> > +   return ret;
> > +
> > +   return ioc3_kbd_setup(ipd);
> > +}
> 
> None of these setup calls have a "cleanup" or un-setup call. Is this
> really okay? I know nothing about MFD, but does mfd_add_devices() not
> require a remove for example? Doesn't the IRQ handling need cleanup?

good catch, I'll add that.

> > +   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> > +   if (ret) {
> > +   dev_warn(&pdev->dev,
> > +"Failed to set 64-bit DMA mask, trying 32-bit\n");
> > +   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > +   if (ret) {
> > +   dev_err(&pdev->dev, "Can't set DMA mask, aborting\n");
> > +   return ret;
> 
> So failing here we don't care about disabling the pci deivce..

fixed in the next version.

> > +
> > +   /*
> > +* Map all IOC3 registers.  These are shared between subdevices
> > +* so the main IOC3 module manages them.
> > +*/
> > +   regs = pci_ioremap_bar(pdev, 0);
> 
> This doesn't seem unmapped on error paths, nor remove?

will fix.

Thank you for the review.

Thomas.

-- 
SUSE Software Solutions Germany GmbH
HRB 247165 (AG München)
Geschäftsführer: Felix Imendörffer

[PATCH v9 4/5] MIPS: SGI-IP27: fix readb/writeb addressing

[Thomas Bogendoerfer]

Our chosen byte swapping, which is what firmware already uses, is to
do readl/writel by normal lw/sw intructions (data invariance). This
also means we need to mangle addresses for u8 and u16 accesses. The
mangling for 16bit has been done aready, but 8bit one was missing.
Correcting this causes different addresses for accesses to the
SuperIO and local bus of the IOC3 chip. This is fixed by changing
byte order in ioc3 and m48rtc_rtc structs.

Acked-by: Alexandre Belloni 
Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/mach-ip27/mangle-port.h |  4 +--
 arch/mips/include/asm/sn/ioc3.h   | 38 +--
 drivers/rtc/rtc-m48t35.c  | 11 
 drivers/tty/serial/8250/8250_ioc3.c   |  4 +--
 4 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/arch/mips/include/asm/mach-ip27/mangle-port.h 
b/arch/mips/include/asm/mach-ip27/mangle-port.h
index f6e4912ea062..27c56efa519f 100644
--- a/arch/mips/include/asm/mach-ip27/mangle-port.h
+++ b/arch/mips/include/asm/mach-ip27/mangle-port.h
@@ -8,7 +8,7 @@
 #ifndef __ASM_MACH_IP27_MANGLE_PORT_H
 #define __ASM_MACH_IP27_MANGLE_PORT_H
 
-#define __swizzle_addr_b(port) (port)
+#define __swizzle_addr_b(port) ((port) ^ 3)
 #define __swizzle_addr_w(port) ((port) ^ 2)
 #define __swizzle_addr_l(port) (port)
 #define __swizzle_addr_q(port) (port)
@@ -20,6 +20,6 @@
 # define ioswabl(a, x) (x)
 # define __mem_ioswabl(a, x)   cpu_to_le32(x)
 # define ioswabq(a, x) (x)
-# define __mem_ioswabq(a, x)   cpu_to_le32(x)
+# define __mem_ioswabq(a, x)   cpu_to_le64(x)
 
 #endif /* __ASM_MACH_IP27_MANGLE_PORT_H */
diff --git a/arch/mips/include/asm/sn/ioc3.h b/arch/mips/include/asm/sn/ioc3.h
index 78ef760ddde4..3865d3225780 100644
--- a/arch/mips/include/asm/sn/ioc3.h
+++ b/arch/mips/include/asm/sn/ioc3.h
@@ -21,50 +21,50 @@ struct ioc3_serialregs {
 
 /* SUPERIO uart register map */
 struct ioc3_uartregs {
+   u8  iu_lcr;
union {
-   u8  iu_rbr; /* read only, DLAB == 0 */
-   u8  iu_thr; /* write only, DLAB == 0 */
-   u8  iu_dll; /* DLAB == 1 */
+   u8  iu_iir; /* read only */
+   u8  iu_fcr; /* write only */
};
union {
u8  iu_ier; /* DLAB == 0 */
u8  iu_dlm; /* DLAB == 1 */
};
union {
-   u8  iu_iir; /* read only */
-   u8  iu_fcr; /* write only */
+   u8  iu_rbr; /* read only, DLAB == 0 */
+   u8  iu_thr; /* write only, DLAB == 0 */
+   u8  iu_dll; /* DLAB == 1 */
};
-   u8  iu_lcr;
-   u8  iu_mcr;
-   u8  iu_lsr;
-   u8  iu_msr;
u8  iu_scr;
+   u8  iu_msr;
+   u8  iu_lsr;
+   u8  iu_mcr;
 };
 
 struct ioc3_sioregs {
u8  fill[0x141];/* starts at 0x141 */
 
-   u8  uartc;
u8  kbdcg;
+   u8  uartc;
 
-   u8  fill0[0x150 - 0x142 - 1];
+   u8  fill0[0x151 - 0x142 - 1];
 
-   u8  pp_data;
-   u8  pp_dsr;
u8  pp_dcr;
+   u8  pp_dsr;
+   u8  pp_data;
 
-   u8  fill1[0x158 - 0x152 - 1];
+   u8  fill1[0x159 - 0x153 - 1];
 
-   u8  pp_fifa;
-   u8  pp_cfgb;
u8  pp_ecr;
+   u8  pp_cfgb;
+   u8  pp_fifa;
 
-   u8  fill2[0x168 - 0x15a - 1];
+   u8  fill2[0x16a - 0x15b - 1];
 
-   u8  rtcad;
u8  rtcdat;
+   u8  rtcad;
 
-   u8  fill3[0x170 - 0x169 - 1];
+   u8  fill3[0x170 - 0x16b - 1];
 
struct ioc3_uartregsuartb;  /* 0x20170  */
struct ioc3_uartregsuarta;  /* 0x20178  */
diff --git a/drivers/rtc/rtc-m48t35.c b/drivers/rtc/rtc-m48t35.c
index d3a75d447fce..e8194f1f01a8 100644
--- a/drivers/rtc/rtc-m48t35.c
+++ b/drivers/rtc/rtc-m48t35.c
@@ -20,6 +20,16 @@
 
 struct m48t35_rtc {
u8  pad[0x7ff8];/* starts at 0x7ff8 */
+#ifdef CONFIG_SGI_IP27
+   u8  hour;
+   u8  min;
+   u8  sec;
+   u8  control;
+   u8  year;
+   u8  month;
+   u8  date;
+   u8  day;
+#else
u8  control;
u8  sec;
u8  min;
@@ -28,6 +38,7 @@ struct m48t35_rtc {
u8  date;
u8  month;
u8  year;
+#endif
 };
 
 #define M48T35_RTC_SET 0x80
diff --git a/drivers/tty/serial/8250/8250_ioc3.c 
b/drivers/tty/serial/8250/8250_ioc3.c
index 2be6ed2967e0..4c405f1b9c67 100644
--- a/drivers/tty/serial/8250/8250_ioc3.c
+++ b/drivers/tty/serial/8250/8250_ioc3.c
@@ -23,12 +23,12 @@ struct ioc3_8250_data {
 
 static unsigned int ioc3_serial_in(struct uart_port *p, int offset)
 {
-   return readb(p->membase + offset);
+   return readb(p->membase + (offset ^ 3));
 }
 
 static void ioc3_serial_out(struct uart_port *p, int offset, int value)

[PATCH v9 3/5] mfd: ioc3: Add driver for SGI IOC3 chip

[Thomas Bogendoerfer]

SGI IOC3 chip has integrated ethernet, keyboard and mouse interface.
It also supports connecting a SuperIO chip for serial and parallel
interfaces. IOC3 is used inside various SGI systemboards and add-on
cards with different equipped external interfaces.

Support for ethernet and serial interfaces were implemented inside
the network driver. This patchset moves out the not network related
parts to a new MFD driver, which takes care of card detection,
setup of platform devices and interrupt distribution for the subdevices.

Serial portion: Acked-by: Greg Kroah-Hartman 
Acked-for-MFD-by: Lee Jones 

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/sgi-ip27/ip27-timer.c |  20 --
 drivers/mfd/Kconfig |  13 +
 drivers/mfd/Makefile|   1 +
 drivers/mfd/ioc3.c  | 605 
 drivers/net/ethernet/sgi/Kconfig|   5 +-
 drivers/net/ethernet/sgi/ioc3-eth.c | 561 ++---
 drivers/tty/serial/8250/8250_ioc3.c |  98 ++
 drivers/tty/serial/8250/Kconfig |  11 +
 drivers/tty/serial/8250/Makefile|   1 +
 9 files changed, 830 insertions(+), 485 deletions(-)
 create mode 100644 drivers/mfd/ioc3.c
 create mode 100644 drivers/tty/serial/8250/8250_ioc3.c

diff --git a/arch/mips/sgi-ip27/ip27-timer.c b/arch/mips/sgi-ip27/ip27-timer.c
index 9b4b9ac621a3..5631e93ea350 100644
--- a/arch/mips/sgi-ip27/ip27-timer.c
+++ b/arch/mips/sgi-ip27/ip27-timer.c
@@ -188,23 +188,3 @@ void hub_rtc_init(cnodeid_t cnode)
LOCAL_HUB_S(PI_RT_PEND_B, 0);
}
 }
-
-static int __init sgi_ip27_rtc_devinit(void)
-{
-   struct resource res;
-
-   memset(&res, 0, sizeof(res));
-   res.start = XPHYSADDR(KL_CONFIG_CH_CONS_INFO(master_nasid)->memory_base 
+
- IOC3_BYTEBUS_DEV0);
-   res.end = res.start + 32767;
-   res.flags = IORESOURCE_MEM;
-
-   return IS_ERR(platform_device_register_simple("rtc-m48t35", -1,
- &res, 1));
-}
-
-/*
- * kludge make this a device_initcall after ioc3 resource conflicts
- * are resolved
- */
-late_initcall(sgi_ip27_rtc_devinit);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ae24d3ea68ea..a762342065a2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2011,5 +2011,18 @@ config RAVE_SP_CORE
  Select this to get support for the Supervisory Processor
  device found on several devices in RAVE line of hardware.
 
+config SGI_MFD_IOC3
+   tristate "SGI IOC3 core driver"
+   depends on PCI && MIPS && 64BIT
+   select MFD_CORE
+   help
+ This option enables basic support for the SGI IOC3-based
+ controller cards.  This option does not enable any specific
+ functions on such a card, but provides necessary infrastructure
+ for other drivers to utilize.
+
+ If you have an SGI Origin, Octane, or a PCI IOC3 card,
+ then say Y. Otherwise say N.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c1067ea46204..0d89b9e1055f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -256,3 +256,4 @@ obj-$(CONFIG_MFD_ROHM_BD70528)  += rohm-bd70528.o
 obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
 obj-$(CONFIG_MFD_STMFX)+= stmfx.o
 
+obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
diff --git a/drivers/mfd/ioc3.c b/drivers/mfd/ioc3.c
new file mode 100644
index ..4b0bd124fc13
--- /dev/null
+++ b/drivers/mfd/ioc3.c
@@ -0,0 +1,605 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SGI IOC3 multifunction device driver
+ *
+ * Copyright (C) 2018, 2019 Thomas Bogendoerfer 
+ *
+ * Based on work by:
+ *   Stanislaw Skowronek 
+ *   Joshua Kinard 
+ *   Brent Casavant  - IOC4 master driver
+ *   Pat Gefre  - IOC3 serial port IRQ demuxer
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define IOC3_IRQ_SERIAL_A  6
+#define IOC3_IRQ_SERIAL_B  15
+#define IOC3_IRQ_KBD   22
+#define IOC3_IRQ_ETH_DOMAIN23
+
+/* Bitmask for selecting which IRQs are level triggered */
+#define IOC3_LVL_MASK  (BIT(IOC3_IRQ_SERIAL_A) | BIT(IOC3_IRQ_SERIAL_B))
+
+#define M48T35_REG_SIZE32768   /* size of m48t35 registers */
+
+/* 1.2 us latency timer (40 cycles at 33 MHz) */
+#define IOC3_LATENCY   40
+
+struct ioc3_priv_data {
+   struct irq_domain *domain;
+   struct ioc3 __iomem *regs;
+   struct pci_dev *pdev;
+   int domain_irq;
+};
+
+static void ioc3_irq_ack(struct irq_data *d)
+{
+   struct ioc3_priv_data *ipd = irq_data_get_irq_chip_data(d);
+   unsigned int hwirq = irqd_to_hwirq(d);
+
+   writel(BIT(hwirq), &ipd->regs->sio_ir);
+}
+
+static void ioc3_irq_mask(struct irq_data *d)
+{
+   struct ioc3_priv_data *ipd = irq_data_get_irq_chip_data(d);
+   unsigned int hwirq = irqd_to_hwirq(d);
+
+   writel(BIT(hwirq), &ipd->regs->sio_iec);
+}
+
+

[PATCH v9 1/5] nvmem: core: add nvmem_device_find

[Thomas Bogendoerfer]

nvmem_device_find provides a way to search for nvmem devices with
the help of a match function simlair to bus_find_device.

Reviewed-by: Srinivas Kandagatla 
Acked-by: Srinivas Kandagatla 
Signed-off-by: Thomas Bogendoerfer 
---
 Documentation/driver-api/nvmem.rst |  2 ++
 drivers/nvmem/core.c   | 61 +-
 include/linux/nvmem-consumer.h |  9 ++
 3 files changed, 38 insertions(+), 34 deletions(-)

diff --git a/Documentation/driver-api/nvmem.rst 
b/Documentation/driver-api/nvmem.rst
index d9d958d5c824..287e86819640 100644
--- a/Documentation/driver-api/nvmem.rst
+++ b/Documentation/driver-api/nvmem.rst
@@ -129,6 +129,8 @@ To facilitate such consumers NVMEM framework provides below 
apis::
   struct nvmem_device *nvmem_device_get(struct device *dev, const char *name);
   struct nvmem_device *devm_nvmem_device_get(struct device *dev,
   const char *name);
+  struct nvmem_device *nvmem_device_find(void *data,
+   int (*match)(struct device *dev, const void *data));
   void nvmem_device_put(struct nvmem_device *nvmem);
   int nvmem_device_read(struct nvmem_device *nvmem, unsigned int offset,
  size_t bytes, void *buf);
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 057d1ff87d5d..9f1ee9c766ec 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -76,33 +76,6 @@ static struct bus_type nvmem_bus_type = {
.name   = "nvmem",
 };
 
-static struct nvmem_device *of_nvmem_find(struct device_node *nvmem_np)
-{
-   struct device *d;
-
-   if (!nvmem_np)
-   return NULL;
-
-   d = bus_find_device_by_of_node(&nvmem_bus_type, nvmem_np);
-
-   if (!d)
-   return NULL;
-
-   return to_nvmem_device(d);
-}
-
-static struct nvmem_device *nvmem_find(const char *name)
-{
-   struct device *d;
-
-   d = bus_find_device_by_name(&nvmem_bus_type, NULL, name);
-
-   if (!d)
-   return NULL;
-
-   return to_nvmem_device(d);
-}
-
 static void nvmem_cell_drop(struct nvmem_cell *cell)
 {
blocking_notifier_call_chain(&nvmem_notifier, NVMEM_CELL_REMOVE, cell);
@@ -532,13 +505,16 @@ int devm_nvmem_unregister(struct device *dev, struct 
nvmem_device *nvmem)
 }
 EXPORT_SYMBOL(devm_nvmem_unregister);
 
-static struct nvmem_device *__nvmem_device_get(struct device_node *np,
-  const char *nvmem_name)
+static struct nvmem_device *__nvmem_device_get(void *data,
+   int (*match)(struct device *dev, const void *data))
 {
struct nvmem_device *nvmem = NULL;
+   struct device *dev;
 
mutex_lock(&nvmem_mutex);
-   nvmem = np ? of_nvmem_find(np) : nvmem_find(nvmem_name);
+   dev = bus_find_device(&nvmem_bus_type, NULL, data, match);
+   if (dev)
+   nvmem = to_nvmem_device(dev);
mutex_unlock(&nvmem_mutex);
if (!nvmem)
return ERR_PTR(-EPROBE_DEFER);
@@ -587,7 +563,7 @@ struct nvmem_device *of_nvmem_device_get(struct device_node 
*np, const char *id)
if (!nvmem_np)
return ERR_PTR(-ENOENT);
 
-   return __nvmem_device_get(nvmem_np, NULL);
+   return __nvmem_device_get(nvmem_np, device_match_of_node);
 }
 EXPORT_SYMBOL_GPL(of_nvmem_device_get);
 #endif
@@ -613,10 +589,26 @@ struct nvmem_device *nvmem_device_get(struct device *dev, 
const char *dev_name)
 
}
 
-   return __nvmem_device_get(NULL, dev_name);
+   return __nvmem_device_get((void *)dev_name, device_match_name);
 }
 EXPORT_SYMBOL_GPL(nvmem_device_get);
 
+/**
+ * nvmem_device_find() - Find nvmem device with matching function
+ *
+ * @data: Data to pass to match function
+ * @match: Callback function to check device
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *nvmem_device_find(void *data,
+   int (*match)(struct device *dev, const void *data))
+{
+   return __nvmem_device_get(data, match);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_find);
+
 static int devm_nvmem_device_match(struct device *dev, void *res, void *data)
 {
struct nvmem_device **nvmem = res;
@@ -710,7 +702,8 @@ nvmem_cell_get_from_lookup(struct device *dev, const char 
*con_id)
if ((strcmp(lookup->dev_id, dev_id) == 0) &&
(strcmp(lookup->con_id, con_id) == 0)) {
/* This is the right entry. */
-   nvmem = __nvmem_device_get(NULL, lookup->nvmem_name);
+   nvmem = __nvmem_device_get((void *)lookup->nvmem_name,
+  device_match_name);
if (IS_ERR(nvmem)) {
/* Provider may not be registered yet. */
cell = ERR_CAST(nvmem);
@@ -780,7 +773,7 @@ struct nvmem_cell *of_nvmem_cell_get(

[PATCH v9 0/5] Use MFD framework for SGI IOC3 drivers

[Thomas Bogendoerfer]

SGI IOC3 ASIC includes support for ethernet, PS2 keyboard/mouse,
NIC (number in a can), GPIO and a byte  bus. By attaching a
SuperIO chip to it, it also supports serial lines and a parallel
port. The chip is used on a variety of SGI systems with different
configurations. This patchset moves code out of the network driver,
which doesn't belong there, into its new place a MFD driver and
specific platform drivers for the different subfunctions.

Changes in v9:
 - remove generated MFD devices, when driver is removed or in case
   of a mfd device setup error
 - remove irq domain, if setup of mfd devices failed
 - pci_iounmap on exit/error cases
 - added irq domain unmap function

Changes in v8:
 - Re-worked comments in drivers/mfd/ioc3.c
 - Added select CRC16 to ioc3-eth.c
 - Patches 1 and 2 are already taken to mips-next, but
   for completeness of the series they are still included.
   What's missing to get the remaining 3 patches via the MIPS
   tree is an ack from a network maintainer

Changes in v7:
 - added patch to enable ethernet phy for Origin 200 systems
 - depend on 64bit for ioc3 mfd driver

Changes in v6:
 - dropped patches accepted for v5.4-rc1
 - moved serio patch to ip30 patch series
 - adapted nvmem patch

Changes in v5:
 - requested by Jakub I've splited ioc3 ethernet driver changes into
   more steps to make the transition more visible; on the way there 
   I've "checkpatched" the driver and reduced code reorderings
 - dropped all uint16_t and uint32_t
 - added nvmem API extension to the documenation file
 - changed to use request_irq/free_irq in serio driver
 - removed wrong kfree() in serio error path

Changes in v4:
 - added w1 drivers to the series after merge in 5.3 failed because
   of no response from maintainer and other parts of this series
   won't work without that drivers
 - moved ip30 systemboard support to the ip30 series, which will
   deal with rtc oddity Lee found
 - converted to use devm_platform_ioremap_resource
 - use PLATFORM_DEVID_AUTO for serial, ethernet and serio in mfd driver
 - fixed reverse christmas order in ioc3-eth.c
 - formating issue found by Lee
 - re-worked irq request/free in serio driver to avoid crashes during
   probe/remove

Changes in v3:
 - use 1-wire subsystem for handling proms
 - pci-xtalk driver uses prom information to create PCI subsystem
   ids for use in MFD driver
 - changed MFD driver to only use static declared mfd_cells
 - added IP30 system board setup to MFD driver
 - mac address is now read from ioc3-eth driver with nvmem framework

Changes in v2:
 - fixed issue in ioc3kbd.c reported by Dmitry Torokhov
 - merged IP27 RTC removal and 8250 serial driver addition into
   main MFD patch to keep patches bisectable

Thomas Bogendoerfer (5):
  nvmem: core: add nvmem_device_find
  MIPS: PCI: use information from 1-wire PROM for IOC3 detection
  mfd: ioc3: Add driver for SGI IOC3 chip
  MIPS: SGI-IP27: fix readb/writeb addressing
  MIPS: SGI-IP27: Enable ethernet phy on second Origin 200 module

 Documentation/driver-api/nvmem.rst|   2 +
 arch/mips/include/asm/mach-ip27/mangle-port.h |   4 +-
 arch/mips/include/asm/pci/bridge.h|   1 +
 arch/mips/include/asm/sn/ioc3.h   |  47 +-
 arch/mips/pci/pci-ip27.c  |  22 +
 arch/mips/pci/pci-xtalk-bridge.c  | 135 +-
 arch/mips/sgi-ip27/ip27-timer.c   |  20 -
 arch/mips/sgi-ip27/ip27-xtalk.c   |  38 +-
 drivers/mfd/Kconfig   |  13 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/ioc3.c| 605 ++
 drivers/net/ethernet/sgi/Kconfig  |   5 +-
 drivers/net/ethernet/sgi/ioc3-eth.c   | 561 +---
 drivers/nvmem/core.c  |  61 ++-
 drivers/rtc/rtc-m48t35.c  |  11 +
 drivers/tty/serial/8250/8250_ioc3.c   |  98 +
 drivers/tty/serial/8250/Kconfig   |  11 +
 drivers/tty/serial/8250/Makefile  |   1 +
 include/linux/nvmem-consumer.h|   9 +
 19 files changed, 1097 insertions(+), 548 deletions(-)
 create mode 100644 drivers/mfd/ioc3.c
 create mode 100644 drivers/tty/serial/8250/8250_ioc3.c

-- 
2.16.4

[PATCH v9 2/5] MIPS: PCI: use information from 1-wire PROM for IOC3 detection

[Thomas Bogendoerfer]

IOC3 chips in SGI system are conntected to a bridge ASIC, which has
a 1-wire prom attached with part number information. This changeset
uses this information to create PCI subsystem information, which
the MFD driver uses for further platform device setup.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/pci/bridge.h |   1 +
 arch/mips/include/asm/sn/ioc3.h|   9 +++
 arch/mips/pci/pci-xtalk-bridge.c   | 135 -
 arch/mips/sgi-ip27/ip27-xtalk.c|  38 +--
 4 files changed, 175 insertions(+), 8 deletions(-)

diff --git a/arch/mips/include/asm/pci/bridge.h 
b/arch/mips/include/asm/pci/bridge.h
index a92cd30b48c9..3bc630ff9ad4 100644
--- a/arch/mips/include/asm/pci/bridge.h
+++ b/arch/mips/include/asm/pci/bridge.h
@@ -807,6 +807,7 @@ struct bridge_controller {
unsigned long   intr_addr;
struct irq_domain   *domain;
unsigned intpci_int[8];
+   u32 ioc3_sid[8];
nasid_t nasid;
 };
 
diff --git a/arch/mips/include/asm/sn/ioc3.h b/arch/mips/include/asm/sn/ioc3.h
index a947eed48fee..78ef760ddde4 100644
--- a/arch/mips/include/asm/sn/ioc3.h
+++ b/arch/mips/include/asm/sn/ioc3.h
@@ -590,4 +590,13 @@ struct ioc3_etxd {
 
 #define MIDR_DATA_MASK 0x
 
+/* subsystem IDs supplied by card detection in pci-xtalk-bridge */
+#defineIOC3_SUBSYS_IP27_BASEIO6G   0xc300
+#defineIOC3_SUBSYS_IP27_MIO0xc301
+#defineIOC3_SUBSYS_IP27_BASEIO 0xc302
+#defineIOC3_SUBSYS_IP29_SYSBOARD   0xc303
+#defineIOC3_SUBSYS_IP30_SYSBOARD   0xc304
+#defineIOC3_SUBSYS_MENET   0xc305
+#defineIOC3_SUBSYS_MENET4  0xc306
+
 #endif /* MIPS_SN_IOC3_H */
diff --git a/arch/mips/pci/pci-xtalk-bridge.c b/arch/mips/pci/pci-xtalk-bridge.c
index 7b4d40354ee7..dcf6117a17c3 100644
--- a/arch/mips/pci/pci-xtalk-bridge.c
+++ b/arch/mips/pci/pci-xtalk-bridge.c
@@ -11,16 +11,22 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
+#include 
+
+#define CRC16_INIT 0
+#define CRC16_VALID0xb001
 
 /*
  * Most of the IOC3 PCI config register aren't present
  * we emulate what is needed for a normal PCI enumeration
  */
-static int ioc3_cfg_rd(void *addr, int where, int size, u32 *value)
+static int ioc3_cfg_rd(void *addr, int where, int size, u32 *value, u32 sid)
 {
u32 cf, shift, mask;
 
@@ -30,6 +36,9 @@ static int ioc3_cfg_rd(void *addr, int where, int size, u32 
*value)
if (get_dbe(cf, (u32 *)addr))
return PCIBIOS_DEVICE_NOT_FOUND;
break;
+   case 0x2c:
+   cf = sid;
+   break;
case 0x3c:
/* emulate sane interrupt pin value */
cf = 0x0100;
@@ -111,7 +120,8 @@ static int pci_conf0_read_config(struct pci_bus *bus, 
unsigned int devfn,
 */
if (cf == (PCI_VENDOR_ID_SGI | (PCI_DEVICE_ID_SGI_IOC3 << 16))) {
addr = &bridge->b_type0_cfg_dev[slot].f[fn].l[where >> 2];
-   return ioc3_cfg_rd(addr, where, size, value);
+   return ioc3_cfg_rd(addr, where, size, value,
+  bc->ioc3_sid[slot]);
}
 
addr = &bridge->b_type0_cfg_dev[slot].f[fn].c[where ^ (4 - size)];
@@ -149,7 +159,8 @@ static int pci_conf1_read_config(struct pci_bus *bus, 
unsigned int devfn,
 */
if (cf == (PCI_VENDOR_ID_SGI | (PCI_DEVICE_ID_SGI_IOC3 << 16))) {
addr = &bridge->b_type1_cfg.c[(fn << 8) | (where & ~3)];
-   return ioc3_cfg_rd(addr, where, size, value);
+   return ioc3_cfg_rd(addr, where, size, value,
+  bc->ioc3_sid[slot]);
}
 
addr = &bridge->b_type1_cfg.c[(fn << 8) | (where ^ (4 - size))];
@@ -426,6 +437,117 @@ static int bridge_map_irq(const struct pci_dev *dev, u8 
slot, u8 pin)
return irq;
 }
 
+#define IOC3_SID(sid)  (PCI_VENDOR_ID_SGI << 16 | (sid))
+
+static void bridge_setup_ip27_baseio6g(struct bridge_controller *bc)
+{
+   bc->ioc3_sid[2] = IOC3_SID(IOC3_SUBSYS_IP27_BASEIO6G);
+   bc->ioc3_sid[6] = IOC3_SID(IOC3_SUBSYS_IP27_MIO);
+}
+
+static void bridge_setup_ip27_baseio(struct bridge_controller *bc)
+{
+   bc->ioc3_sid[2] = IOC3_SID(IOC3_SUBSYS_IP27_BASEIO);
+}
+
+static void bridge_setup_ip29_baseio(struct bridge_controller *bc)
+{
+   bc->ioc3_sid[2] = IOC3_SID(IOC3_SUBSYS_IP29_SYSBOARD);
+}
+
+static void bridge_setup_ip30_sysboard(struct bridge_controller *bc)
+{
+   bc->ioc3_sid[2] = IOC3_SID(IOC3_SUBSYS_IP30_SYSBOARD);
+}
+
+static void bridge_setup_menet(struct bridge_controller *bc)
+{
+   bc->ioc3_sid[0] = IOC3_SID(IOC3_SUBSYS_MENET);
+   bc->ioc3_sid[1] = IOC3_SID(IOC3_SUBSYS_MENET);
+   bc->ioc3_sid[2] = IOC3_SID(IOC3_SUBSYS_MENET);
+   bc->ioc3_sid[3] = IOC3_SID(IOC3_SUBSYS_M

[PATCH v9 5/5] MIPS: SGI-IP27: Enable ethernet phy on second Origin 200 module

[Thomas Bogendoerfer]

PROM only enables ethernet PHY on first Origin 200 module, so we must
do it ourselves for the second module.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/pci/pci-ip27.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/mips/pci/pci-ip27.c b/arch/mips/pci/pci-ip27.c
index 441eb9383b20..7cc784cb299b 100644
--- a/arch/mips/pci/pci-ip27.c
+++ b/arch/mips/pci/pci-ip27.c
@@ -7,6 +7,11 @@
  * Copyright (C) 1999, 2000, 04 Ralf Baechle (r...@linux-mips.org)
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
  */
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
@@ -31,3 +36,20 @@ int pcibus_to_node(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibus_to_node);
 #endif /* CONFIG_NUMA */
+
+static void ip29_fixup_phy(struct pci_dev *dev)
+{
+   int nasid = pcibus_to_node(dev->bus);
+   u32 sid;
+
+   if (nasid != 1)
+   return; /* only needed on second module */
+
+   /* enable ethernet PHY on IP29 systemboard */
+   pci_read_config_dword(dev, PCI_SUBSYSTEM_VENDOR_ID, &sid);
+   if (sid == ((PCI_VENDOR_ID_SGI << 16) | IOC3_SUBSYS_IP29_SYSBOARD))
+   REMOTE_HUB_S(nasid, MD_LED0, 0x09);
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SGI, PCI_DEVICE_ID_SGI_IOC3,
+   ip29_fixup_phy);
-- 
2.16.4

RE: [PATCH v3] hwspinlock: allow sharing of hwspinlocks

[Fabien DESSENNE]

Hi Bjorn, Suman, and others

Do you have any comments regarding this patch?

BR
Fabien


> -Original Message-
> From: Fabien DESSENNE 
> Sent: mercredi 11 septembre 2019 15:57
> To: Ohad Ben-Cohen ; Bjorn Andersson
> ; Suman Anna ; Jonathan Corbet
> ; linux-remotep...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: Fabien DESSENNE ; linux-stm32@st-md-
> mailman.stormreply.com
> Subject: [PATCH v3] hwspinlock: allow sharing of hwspinlocks
> 
> Allow several clients to request (hwspin_lock_request_specific()) the same 
> lock.
> In addition to that, protect a given lock from being locked
> (hwspin_trylock{_...}()) by more that one client at a time.
> 
> Since the RAW and IN_ATOMIC modes do not implement that protection (unlike
> the default, IRQ and IRQSTATE modes that make use of spin_lock{_irq,
> _irqsave}), protect __hwspin_trylock with the atomic bitop test_and_set_bit().
> This bitop is atomic (SMP-safe), does not disable neither preemption nor
> interrupts, hence it preserves the RAW and IN_ATOMIC modes constraints.
> 
> Signed-off-by: Fabien Dessenne 
> ---
> Changes since v2:
> - Drop the DeviceTree-based implementation.
> - Do not let the choice between exclusive and shared usage : locks are
>   always shared.
> - Add a protection (atomic bitop) working in any modes to allow safe
>   sharing between clients.
> 
> Changes since v1:
> - Removed useless 'status = "okay"' from stm32mp157c.dtsi
> ---
>  Documentation/hwspinlock.txt |  9 ++-
>  drivers/hwspinlock/hwspinlock_core.c | 98 +++--
> ---
>  drivers/hwspinlock/hwspinlock_internal.h |  4 ++
>  3 files changed, 81 insertions(+), 30 deletions(-)
> 
> diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index
> 6f03713..5f6f660 100644
> --- a/Documentation/hwspinlock.txt
> +++ b/Documentation/hwspinlock.txt
> @@ -53,9 +53,8 @@ Should be called from a process context (might sleep).
> 
>struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
> 
> -Assign a specific hwspinlock id and return its address, or NULL -if that
> hwspinlock is already in use. Usually board code will -be calling this 
> function in
> order to reserve specific hwspinlock
> +Assign a specific hwspinlock id and return its address. Usually board
> +code will be calling this function in order to reserve specific
> +hwspinlock
>  ids for predefined purposes.
> 
>  Should be called from a process context (might sleep).
> @@ -449,11 +448,15 @@ of which represents a single hardware lock::
>   * struct hwspinlock - this struct represents a single hwspinlock 
> instance
>   * @bank: the hwspinlock_device structure which owns this lock
>   * @lock: initialized and used by hwspinlock core
> + * @is_locked: whether this lock is currently locked
> + * @reqcount: number of users having requested this lock
>   * @priv: private data, owned by the underlying platform-specific
> hwspinlock drv
>   */
>   struct hwspinlock {
>   struct hwspinlock_device *bank;
>   spinlock_t lock;
> + unsigned long is_locked;
> + unsigned int reqcount;
>   void *priv;
>   };
> 
> diff --git a/drivers/hwspinlock/hwspinlock_core.c
> b/drivers/hwspinlock/hwspinlock_core.c
> index 8862445..e9d3de10 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -29,6 +29,7 @@
> 
>  /* radix tree tags */
>  #define HWSPINLOCK_UNUSED(0) /* tags an hwspinlock as unused */
> +#define HWSPINLOCK_DYN_ASSIGN(1) /* dynamically assigned
> hwspinlock */
> 
>  /*
>   * A radix tree is used to maintain the available hwspinlock instances.
> @@ -96,14 +97,25 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int
> mode, unsigned long *flags)
>   BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
> 
>   /*
> +  * Check if the lock is already taken by another context on the local
> +  * cpu.
> +  * Calling atomic test_and_set_bit_lock() ensures that hwspinlock is
> +  * SMP-safe (so we can take it from additional contexts on the local
> +  * host) in any mode, even those where we do not make use of the local
> +  * spinlock.
> +  */
> +
> + if (test_and_set_bit_lock(0, &hwlock->is_locked))
> + return -EBUSY;
> +
> + /*
>* This spin_lock{_irq, _irqsave} serves three purposes:
>*
>* 1. Disable preemption, in order to minimize the period of time
>*in which the hwspinlock is taken. This is important in order
>*to minimize the possible polling on the hardware interconnect
>*by a remote user of this lock.
> -  * 2. Make the hwspinlock SMP-safe (so we can take it from
> -  *additional contexts on the local host).
> +  * 2. Make the hwspinlock SMP-safe.
>* 3. Ensure that in_atomic/might_sleep checks catch potential
>*problems with hwspinlock us

Re: [PATCH 2/3] hwmon: Add support for ltc2947

[Guenter Roeck]

On Thu, Oct 10, 2019 at 07:13:06AM +, Sa, Nuno wrote:
> 
> Quoting the reply I had:
> 
> "As the LTC2947 is bi-directional, the most likely use for the Min/Max
> Energy thresholds are for monitoring a battery being charged or
> discharged. 
> A limit could be set based around the battery's storage capacity so
> that the battery is protected from being overcharging or fully
> drained."
> 
> So, I'm not sure if this is a valid use case for hwmon subsystem. I'm
> aware there's also the power subsystem. So let me know what do you
> prefer here. Should I just report energyX_input attributes? Or can we
> keep the min/max?
> 
This isn't really a hwmon use case. Having such min/max attributes would
just be confusing.

Guenter

Re: [PATCH 12/12] infiniband: add a Documentation driver-api chapter for Infiniband

[kbuild test robot]

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on rdma/for-next]
[cannot apply to v5.4-rc2 next-20191010]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/rd-dunlab-gmail-com/infiniband-kernel-doc-fixes-driver-api-chapter/20191010-220426
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git for-next
reproduce: make htmldocs

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure 
you have the theme installed to produce pretty HTML output. Falling back to the 
default theme.
   WARNING: dot(1) not found, for better output quality install graphviz from 
http://www.graphviz.org
   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   Error: Cannot open file drivers/dma-buf/reservation.c
   Error: Cannot open file drivers/dma-buf/reservation.c
   Error: Cannot open file drivers/dma-buf/reservation.c
   Error: Cannot open file include/linux/reservation.h
   Error: Cannot open file include/linux/reservation.h
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'quotactl' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'quota_on' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_free_mnt_opts' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_eat_lsm_opts' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_kern_mount' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_show_options' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_add_mnt_opt' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'd_instantiate' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'getprocattr' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'setprocattr' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'locked_down' not described in 'security_list_options'
   include/linux/regulator/machine.h:196: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:223: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   include/linux/spi/spi.h:190: warning: Function parameter or member 
'driver_override' not described in 'spi_device'
   fs/fs-writeback.c:913: warning: Excess function parameter 'nr_pages' 
description in 'cgroup_writeback_by_id'
   fs/direct-io.c:258: warning: Excess function parameter 'offset' description 
in 'dio_complete'
   fs/libfs.c:496: warning: Excess function parameter 'available' description 
in 'simple_write_end'
   fs/posix_acl.c:647: warning: Function parameter or member 'inode' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'acl' not 
described in 'posix_acl_update_mode'
   drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not 
found
   drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found
   drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not 
found
   drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' 
not found
   include/linux/w1.h:277: warning: Function parameter or member 
'of_match_table' not described in 'w1_family'
   drivers/gpio/gpiolib-of.c:92: warning: Excess function parameter 'dev' 
description in 'of_gpio_need_valid_mask'
   include/linux/i2c.h:337: warning: Function para

Re: [PATCH v9 5/5] MIPS: SGI-IP27: Enable ethernet phy on second Origin 200 module

[Sergei Shtylyov]

On 10/10/2019 05:59 PM, Thomas Bogendoerfer wrote:

> PROM only enables ethernet PHY on first Origin 200 module, so we must
> do it ourselves for the second module.
> 
> Signed-off-by: Thomas Bogendoerfer 
> ---
>  arch/mips/pci/pci-ip27.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/mips/pci/pci-ip27.c b/arch/mips/pci/pci-ip27.c
> index 441eb9383b20..7cc784cb299b 100644
> --- a/arch/mips/pci/pci-ip27.c
> +++ b/arch/mips/pci/pci-ip27.c
> @@ -7,6 +7,11 @@
>   * Copyright (C) 1999, 2000, 04 Ralf Baechle (r...@linux-mips.org)
>   * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
>   */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  
>  dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
> @@ -31,3 +36,20 @@ int pcibus_to_node(struct pci_bus *bus)
>  }
>  EXPORT_SYMBOL(pcibus_to_node);
>  #endif /* CONFIG_NUMA */
> +
> +static void ip29_fixup_phy(struct pci_dev *dev)
> +{
> + int nasid = pcibus_to_node(dev->bus);
> + u32 sid;
> +
> + if (nasid != 1)
> + return; /* only needed on second module */
> +
> + /* enable ethernet PHY on IP29 systemboard */
> + pci_read_config_dword(dev, PCI_SUBSYSTEM_VENDOR_ID, &sid);
> + if (sid == ((PCI_VENDOR_ID_SGI << 16) | IOC3_SUBSYS_IP29_SYSBOARD))

   I thought PCI was little endian, thuis vendor ID at offset 0 and device ID
at offset 2?

[...]

MBR, Sergei

[PATCH v6 1/5] dt-bindings: arm: fsl: Add the S32V234-EVB board

[Stefan-Gabriel Mirea]

From: Eddy Petrișor 

Add entry for the NXP S32V234 Customer Evaluation Board to the board/SoC
bindings.

Signed-off-by: Eddy Petrișor 
Signed-off-by: Stefan-Gabriel Mirea 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1b4b4e6573b5..c211f4f82e25 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -335,4 +335,10 @@ properties:
   - fsl,ls2088a-rdb
   - const: fsl,ls2088a
 
+  - description: S32V234 based Boards
+items:
+  - enum:
+  - fsl,s32v234-evb   # S32V234-EVB2 Customer Evaluation 
Board
+  - const: fsl,s32v234
+
 ...
-- 
2.22.0

[PATCH v6 0/5] Add initial support for S32V234-EVB

[Stefan-Gabriel Mirea]

Hello,

NXP's S32V234[1] ("Treerunner") vision microprocessors are targeted for
high-performance, computationally intensive vision and sensor fusion
applications that require automotive safety levels. They include leading
edge Camera Vision modules like APEX-2, ISP and GPU. The S32V234-EVB and
S32V234-SBC boards are available for customer evaluation.

The following patch series introduces minimal enablement support for the
NXP S32V234-EVB2[2] board, which leverages most of the SoC capabilities.
Up to v2, this series also included the fsl_linflexuart driver, which has
been included in Linux 5.4-rc1[3].

In the future, we aim to submit multiple drivers upstream, which can be
found in the kernel of our Auto Linux BSP[4] ("ALB"), starting with basic
pinmuxing, clock and uSDHC drivers.

For validation, you can use the U-Boot bootloader in the ALB[5], which we
build and test with our patched version of the Linaro GCC 6.3.1 2017.05
toolchain for ARM 64-bit, with sources available on [6].

Changes in v6:
* In the patch 'serial: fsl_linflexuart: Be consistent with the name',
  avoid updating the definition PORT_LINFLEXUART; that was an independent
  fix which has been submitted and accepted[9] separately;
* Avoid using 'base64' as 'Content-Transfer-Encoding'.

Changes in v5:
* Remove the patch 'dt-bindings: serial: Document Freescale LINFlexD UART'
  following its acceptance in Linux 5.4-rc1[8];
* Rebase the other patches on v5.4-rc1.

Changes in v4:
* Remove the patch 'serial: fsl_linflexuart: Update compatible string'
  following its acceptance[7];
* Rebase the patch 'serial: fsl_linflexuart: Be consistent with the name'
  on the tty-next branch in Greg's tty git tree.

Changes in v3:
* Remove the patch 'tty: serial: Add linflexuart driver for S32V234'
  following its acceptance[3];
* Replace 'Freescale' with 'NXP' in the ARCH_S32 config definition and the
  'model' property from the device tree;
* Remove the 'fsl-' prefixes from the dtsi and dts file names;
* Move the 'model' property from (fsl-)s32v234.dtsi to s32v234-evb.dts;
* Add newlines between the cpu nodes in s32v234.dtsi;
* Make use of GIC_SPI, GIC_PPI, GIC_CPU_MASK_SIMPLE and IRQ_TYPE_* in the
  'interrupts' tuples;
* Move the 'timer' and 'interrupt-controller' nodes before 'soc' in
  s32v234.dtsi;
* Be consistent with the 'LINFlexD' spelling in documentation, strings and
  comments; add new patch 'serial: fsl_linflexuart: Be consistent with the
  name' to update the LINFlexD driver as well;
* Remove from fsl,s32-linflexuart.txt a statement regarding the limitation
  to UART mode;
* Make the compatible string SoC specific ("fsl,s32v234-linflexuart"); add
  new patch 'serial: fsl_linflexuart: Update compatible string' to update
  the LINFlexD driver as well;
* In the LINFlexD binding documentation, insert a space between label and
  node name and remove the 'status' property.

Changes in v2:
* Update the entry in fsl.yaml to apply to all S32V234 based boards;
* Add chosen node to dts, with a 'stdout-path' property for earlycon;
* Remove linflex_verify_port(), because it was only called from
  uart_set_info(), which was going to always fail at the "baud_base < 9600"
  check, as we are not using uartclk from uart_port yet;
* Fix compatible string used in OF_EARLYCON_DECLARE.

[1] 
https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/s32-automotive-platform/vision-processor-for-front-and-surround-view-camera-machine-learning-and-sensor-fusion:S32V234
[2] 
https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/ultra-reliable-dev-platforms/s32v-mpus-platforms/s32v-vision-and-sensor-fusion-evaluation-system:S32V234EVB
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09864c1cdf5c537bd01bff45181406e422ea988c
[4] https://source.codeaurora.org/external/autobsps32/linux/
[5] https://source.codeaurora.org/external/autobsps32/u-boot/
[6] https://source.codeaurora.org/external/s32ds/compiler/gcc/
[7] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bd3661ea0eb2056852cbc58c5d96bb4df2f164f
[8] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e16feab6cce2b91d2996d4bc4eff01ece577c4a
[9] 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-linus&id=47934ef7f1883209120781b59d78eaf8b83e2fb7

Eddy Petrișor (1):
  dt-bindings: arm: fsl: Add the S32V234-EVB board

Mihaela Martinas (2):
  arm64: Introduce config for S32
  arm64: defconfig: Enable configs for S32V234

Stefan-Gabriel Mirea (1):
  serial: fsl_linflexuart: Be consistent with the name

Stoica Cosmin-Stefan (1):
  arm64: dts: fsl: Add device tree for S32V234-EVB

 .../admin-guide/kernel-parameters.txt |   2 +-
 .../devicetree/bindings/arm/fsl.yaml  |   6 +
 arch/arm64/Kconfig.platforms  |   5 +
 arch/arm64/boot/dts/freescale/Makefile|   2 +
 arch/arm64/boot/dts/freescale/s32v234-evb.dts |  25 ++

[PATCH v6 5/5] arm64: defconfig: Enable configs for S32V234

[Stefan-Gabriel Mirea]

From: Mihaela Martinas 

Enable support for the S32V234 SoC, including the previously added UART
driver.

Signed-off-by: Mihaela Martinas 
Signed-off-by: Adrian.Nitu 
Signed-off-by: Stoica Cosmin-Stefan 
Signed-off-by: Stefan-Gabriel Mirea 
---
 arch/arm64/configs/defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..aa59450557b8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -48,6 +48,7 @@ CONFIG_ARCH_MXC=y
 CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_ROCKCHIP=y
+CONFIG_ARCH_S32=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_STRATIX10=y
 CONFIG_ARCH_SYNQUACER=y
@@ -352,6 +353,8 @@ CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
 CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+CONFIG_SERIAL_FSL_LINFLEXUART=y
+CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE=y
 CONFIG_SERIAL_MVEBU_UART=y
 CONFIG_SERIAL_DEV_BUS=y
 CONFIG_VIRTIO_CONSOLE=y
-- 
2.22.0

[PATCH v6 4/5] arm64: dts: fsl: Add device tree for S32V234-EVB

[Stefan-Gabriel Mirea]

From: Stoica Cosmin-Stefan 

Add initial version of device tree for S32V234-EVB, including nodes for the
4 Cortex-A53 cores, AIPS bus with UART modules, ARM architected timer and
Generic Interrupt Controller (GIC).

Keep SoC level separate from board level to let future boards with this SoC
share common properties, while the dts files will keep board-dependent
properties.

Signed-off-by: Stoica Cosmin-Stefan 
Signed-off-by: Mihaela Martinas 
Signed-off-by: Dan Nica 
Signed-off-by: Larisa Grigore 
Signed-off-by: Phu Luu An 
Signed-off-by: Stefan-Gabriel Mirea 
---
 arch/arm64/boot/dts/freescale/Makefile|   2 +
 arch/arm64/boot/dts/freescale/s32v234-evb.dts |  25 
 arch/arm64/boot/dts/freescale/s32v234.dtsi| 139 ++
 3 files changed, 166 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/s32v234-evb.dts
 create mode 100644 arch/arm64/boot/dts/freescale/s32v234.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 93fce8f0c66d..730209adb2bc 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,3 +32,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
+
+dtb-$(CONFIG_ARCH_S32) += s32v234-evb.dtb
diff --git a/arch/arm64/boot/dts/freescale/s32v234-evb.dts 
b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
new file mode 100644
index ..4b802518cefc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2017 NXP
+ */
+
+/dts-v1/;
+#include "s32v234.dtsi"
+
+/ {
+   model = "NXP S32V234-EVB2 Board";
+   compatible = "fsl,s32v234-evb", "fsl,s32v234";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/s32v234.dtsi 
b/arch/arm64/boot/dts/freescale/s32v234.dtsi
new file mode 100644
index ..37225191ccbf
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2018 NXP
+ */
+
+#include 
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+   compatible = "fsl,s32v234";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster0_l2_cache>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster0_l2_cache>;
+   };
+
+   cpu2: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster1_l2_cache>;
+   };
+
+   cpu3: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x0 0x8000>;
+   next-level-cache = <&cluster1_l2_cache>;
+   };
+
+   cluster0_l2_cache: l2-cache0 {
+   compatible = "cache";
+   };
+
+   cluster1_l2_cache: l2-cache1 {
+   compatible = "cache";
+   };
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   /* clock-frequency might be modified by u-boot, depending on the
+* chip version.
+*/
+   clock-frequency = <1000>;
+   };
+
+   gic: interrupt-controller@7d0010

[PATCH v6 3/5] serial: fsl_linflexuart: Be consistent with the name

[Stefan-Gabriel Mirea]

For consistency reasons, spell the controller name as "LINFlexD" in
comments and documentation.

Signed-off-by: Stefan-Gabriel Mirea 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 +-
 drivers/tty/serial/Kconfig  | 8 
 drivers/tty/serial/fsl_linflexuart.c| 4 ++--
 include/uapi/linux/serial_core.h| 2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index c7ac2f3ac99f..666326d74415 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1101,7 +1101,7 @@
mapped with the correct attributes.
 
linflex,
-   Use early console provided by Freescale LinFlex UART
+   Use early console provided by Freescale LINFlexD UART
serial driver for NXP S32V234 SoCs. A valid base
address must be provided, and the serial port must
already be setup and configured.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 4789b5d62f63..c8e11f62ea19 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1391,19 +1391,19 @@ config SERIAL_FSL_LPUART_CONSOLE
  you can make it the console by answering Y to this option.
 
 config SERIAL_FSL_LINFLEXUART
-   tristate "Freescale linflexuart serial port support"
+   tristate "Freescale LINFlexD UART serial port support"
depends on PRINTK
select SERIAL_CORE
help
- Support for the on-chip linflexuart on some Freescale SOCs.
+ Support for the on-chip LINFlexD UART on some Freescale SOCs.
 
 config SERIAL_FSL_LINFLEXUART_CONSOLE
-   bool "Console on Freescale linflexuart serial port"
+   bool "Console on Freescale LINFlexD UART serial port"
depends on SERIAL_FSL_LINFLEXUART=y
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
help
- If you have enabled the linflexuart serial port on the Freescale
+ If you have enabled the LINFlexD UART serial port on the Freescale
  SoCs, you can make it the console by answering Y to this option.
 
 config SERIAL_CONEXANT_DIGICOLOR
diff --git a/drivers/tty/serial/fsl_linflexuart.c 
b/drivers/tty/serial/fsl_linflexuart.c
index 68d74f2b5106..2d39e13176e1 100644
--- a/drivers/tty/serial/fsl_linflexuart.c
+++ b/drivers/tty/serial/fsl_linflexuart.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * Freescale linflexuart serial port driver
+ * Freescale LINFlexD UART serial port driver
  *
  * Copyright 2012-2016 Freescale Semiconductor, Inc.
  * Copyright 2017-2018 NXP
@@ -933,5 +933,5 @@ static void __exit linflex_serial_exit(void)
 module_init(linflex_serial_init);
 module_exit(linflex_serial_exit);
 
-MODULE_DESCRIPTION("Freescale linflex serial port driver");
+MODULE_DESCRIPTION("Freescale LINFlexD serial port driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 0f4f87a6fd54..49e61963e754 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -290,7 +290,7 @@
 /* Sunix UART */
 #define PORT_SUNIX 121
 
-/* Freescale Linflex UART */
+/* Freescale LINFlexD UART */
 #define PORT_LINFLEXUART   121
 
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.22.0

[PATCH v6 2/5] arm64: Introduce config for S32

[Stefan-Gabriel Mirea]

From: Mihaela Martinas 

Add configuration option for the NXP S32 platform family in
Kconfig.platforms. For starters, the only SoC supported will be Treerunner
(S32V234), with a single execution target: the S32V234-EVB (rev 29288)
board.

Signed-off-by: Mihaela Martinas 
Signed-off-by: Stoica Cosmin-Stefan 
Signed-off-by: Stefan-Gabriel Mirea 
---
 arch/arm64/Kconfig.platforms | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 16d761475a86..17f1c34ec750 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -212,6 +212,11 @@ config ARCH_ROCKCHIP
  This enables support for the ARMv8 based Rockchip chipsets,
  like the RK3368.
 
+config ARCH_S32
+   bool "NXP S32 SoC Family"
+   help
+ This enables support for the NXP S32 family of processors.
+
 config ARCH_SEATTLE
bool "AMD Seattle SoC Family"
help
-- 
2.22.0

Re: [PATCH 1/4] arm64: add support for the AMU extension v1

[Catalin Marinas]

Hi Ionela,

On Tue, Sep 17, 2019 at 02:42:25PM +0100, Ionela Voinescu wrote:
> +#ifdef CONFIG_ARM64_AMU_EXTN
> +
> +/*
> + * This per cpu variable only signals that the CPU implementation supports 
> the
> + * AMU but does not provide information regarding all the events that it
> + * supports.
> + * When this amu_feat per CPU variable is true, the user of this feature can
> + * only rely on the presence of the 4 fixed counters. But this does not
> + * guarantee that the counters are enabled or access to these counters is
> + * provided by code executed at higher exception levels.
> + */
> +DEFINE_PER_CPU(bool, amu_feat) = false;
> +
> +static void cpu_amu_enable(struct arm64_cpu_capabilities const *cap)
> +{
> + if (has_cpuid_feature(cap, SCOPE_LOCAL_CPU)) {
> + pr_info("detected CPU%d: Activity Monitors extension\n",
> + smp_processor_id());
> + this_cpu_write(amu_feat, true);
> + }
> +}

Sorry if I missed anything as I just skimmed through this series. I
can't see the amu_feat used anywhere in these patches, so on its own it
doesn't make much sense.

I also can't see the advantage of allowing mismatched CPU
implementations for this feature. What's the intended use-case?

Thanks.

-- 
Catalin

Re: [PATCH] Documentation: admin-guide: add earlycon documentation for RISC-V

[Jonathan Corbet]

On Thu, 10 Oct 2019 09:10:18 +0200
Geert Uytterhoeven  wrote:

> On Wed, Oct 9, 2019 at 9:53 PM Paul Walmsley  wrote:
> > Kernels booting on RISC-V can specify "earlycon" with no options on
> > the Linux command line, and the generic DT earlycon support will query
> > the "chosen/stdout-path" property (if present) to determine which
> > early console device to use.  Document this appropriately in the
> > admin-guide.
> >
> > Signed-off-by: Paul Walmsley   
> 
> Reviewed-by: Geert Uytterhoeven 

Applied, thanks.

jon

Re: [PATCH 1/3] docs: fix some broken references

[Jonathan Corbet]

On Tue, 24 Sep 2019 10:01:28 -0300
Mauro Carvalho Chehab  wrote:

> There are a number of documentation files that got moved or
> renamed. update their references.
> 
> Signed-off-by: Mauro Carvalho Chehab 

I've applied this set, thanks.

jon

Re: [PATCH] docs: networking: devlink-trap: Fix reference to other document

[Jonathan Corbet]

On Thu,  3 Oct 2019 21:05:36 +0200
Jonathan Neuschäfer  wrote:

> This fixes the following Sphinx warning:
> 
> Documentation/networking/devlink-trap.rst:175: WARNING: unknown document: 
> /devlink-trap-netdevsim
> 
> Fixes: 9e0874570488 ("Documentation: Add description of netdevsim traps")
> Signed-off-by: Jonathan Neuschäfer 

Applied, thanks.

jon

Re: [PATCH] docs: networking: phy: Improve phrasing

[Jonathan Corbet]

On Thu,  3 Oct 2019 22:43:22 +0200
Jonathan Neuschäfer  wrote:

> It's not about times (multiple occurences of an event) but about the
> duration of a time interval.
> 
> Signed-off-by: Jonathan Neuschäfer 

Applied, thanks.

jon

Re: [PATCH] docs: admin-guide: fix printk_ratelimit explanation

[Jonathan Corbet]

On Wed,  2 Oct 2019 13:46:10 +0200
Oleksandr Natalenko  wrote:

> The printk_ratelimit value accepts seconds, not jiffies (though it is
> converted into jiffies internally). Update documentation to reflect
> this.
> 
> Also, remove the statement about allowing 1 message in 5 seconds since
> bursts up to 10 messages are allowed by default.
> 
> Finally, while we are here, mention default value for
> printk_ratelimit_burst too.
> 
> Signed-off-by: Oleksandr Natalenko 

This seems good.  Applied, thanks.

jon

Re: Sphinx parallel build errors

[Jonathan Corbet]

On Wed, 9 Oct 2019 19:30:56 -0700
Kees Cook  wrote:

> I'm wondering if it's actually the addition of
> the MAINTAINERS file parsing -- that's a really big parse and maybe that
> pushed things over the edge?

That does seem like a likely culprit, doesn't it?  Watching a build here,
though, I don't see that any one of the sphinx-build processes balloons to
a horrific size, which is what I would expect if one file were causing the
problem.

In general, the sphinx build doesn't really begin to approach the memory
requirements of, say, firefox or my mail client on my system.

Randy, I'd be curious to know if you see the same behavior with current
mainline.  Also, can you see how many sphinx-build processes you have
running?

Thanks,

jon

Re: Sphinx parallel build errors

[Randy Dunlap]

On 10/10/19 11:48 AM, Jonathan Corbet wrote:
> On Wed, 9 Oct 2019 19:30:56 -0700
> Kees Cook  wrote:
> 
>> I'm wondering if it's actually the addition of
>> the MAINTAINERS file parsing -- that's a really big parse and maybe that
>> pushed things over the edge?
> 
> That does seem like a likely culprit, doesn't it?  Watching a build here,
> though, I don't see that any one of the sphinx-build processes balloons to
> a horrific size, which is what I would expect if one file were causing the
> problem.
> 
> In general, the sphinx build doesn't really begin to approach the memory
> requirements of, say, firefox or my mail client on my system.
> 
> Randy, I'd be curious to know if you see the same behavior with current
> mainline.  Also, can you see how many sphinx-build processes you have
> running?

Yes, I see oom-kills when building docs for 5.4-rc2.
But only after I ran 'gimp *.jpg' for 22 photos.

I can see anywhere from 1 to 4 sphinx-build processes running.

> Thanks,
> 
> jon

-- 
~Randy

[PATCH 19/19] EDAC, Documentation: Describe CPER module definition and DIMM ranks

[Robert Richter]

Update on CPER DIMM naming convention and DIMM ranks.

Signed-off-by: Robert Richter 
---
 Documentation/admin-guide/ras.rst | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/ras.rst 
b/Documentation/admin-guide/ras.rst
index 2b20f5f7380d..26e02a59f0f4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -330,9 +330,12 @@ There can be multiple csrows and multiple channels.
 
 .. [#f4] Nowadays, the term DIMM (Dual In-line Memory Module) is widely
   used to refer to a memory module, although there are other memory
-  packaging alternatives, like SO-DIMM, SIMM, etc. Along this document,
-  and inside the EDAC system, the term "dimm" is used for all memory
-  modules, even when they use a different kind of packaging.
+  packaging alternatives, like SO-DIMM, SIMM, etc. The UEFI
+  specification (Version 2.7) defines a memory module in the Common
+  Platform Error Record (CPER) section to be an SMBIOS Memory Device
+  (Type 17). Along this document, and inside the EDAC system, the term
+  "dimm" is used for all memory modules, even when they use a
+  different kind of packaging.
 
 Memory controllers allow for several csrows, with 8 csrows being a
 typical value. Yet, the actual number of csrows depends on the layout of
@@ -349,12 +352,14 @@ controllers. The following example will assume 2 channels:
||  ``ch0``  |  ``ch1``  |
++===+===+
| ``csrow0`` |  DIMM_A0  |  DIMM_B0  |
-   ++   |   |
-   | ``csrow1`` |   |   |
+   ||   rank0   |   rank0   |
+   ++ - | - |
+   | ``csrow1`` |   rank1   |   rank1   |
++---+---+
| ``csrow2`` |  DIMM_A1  | DIMM_B1   |
-   ++   |   |
-   | ``csrow3`` |   |   |
+   ||   rank0   |   rank0   |
+   ++ - | - |
+   | ``csrow3`` |   rank1   |   rank1   |
++---+---+
 
 In the above example, there are 4 physical slots on the motherboard
@@ -374,11 +379,13 @@ which the memory DIMM is placed. Thus, when 1 DIMM is 
placed in each
 Channel, the csrows cross both DIMMs.
 
 Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
-Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
-will have just one csrow (csrow0). csrow1 will be empty. On the other
-hand, when 2 dual ranked DIMMs are similarly placed, then both csrow0
-and csrow1 will be populated. The pattern repeats itself for csrow2 and
-csrow3.
+In the example above 2 dual ranked DIMMs are similarly placed. Thus,
+both csrow0 and csrow1 are populated. On the other hand, when 2 single
+ranked DIMMs are placed in slots DIMM_A0 and DIMM_B0, then they will
+have just one csrow (csrow0) and csrow1 will be empty. The pattern
+repeats itself for csrow2 and csrow3. Also note that some memory
+controller doesn't have any logic to identify the memory module, see
+``rankX`` directories below.
 
 The representation of the above is reflected in the directory
 tree in EDAC's sysfs interface. Starting in directory
-- 
2.20.1

Re: [PATCH] docs: misc: xilinx_sdfec: Actually add documentation

[Kees Cook]

On Wed, Oct 02, 2019 at 10:03:55AM -0700, Kees Cook wrote:
> From: Derek Kiernan 
> 
> Add SD-FEC driver documentation.
> 
> Signed-off-by: Derek Kiernan 
> Signed-off-by: Dragan Cvetic 
> Link: 
> https://lore.kernel.org/r/1560274185-264438-11-git-send-email-dragan.cve...@xilinx.com
> [kees: extracted from v7 as it was missing in the commit for v8]
> Signed-off-by: Kees Cook 
> ---
> As mentioned[1], this file went missing and causes a warning in ReST
> parsing, so I've extracted the patch and am sending it directly to Jon.
> [1] https://lore.kernel.org/lkml/201909231450.4C6CF32@keescook/
> ---

friendly ping! :)

-Kees

>  Documentation/misc-devices/xilinx_sdfec.rst | 291 
>  1 file changed, 291 insertions(+)
>  create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst
> 
> diff --git a/Documentation/misc-devices/xilinx_sdfec.rst 
> b/Documentation/misc-devices/xilinx_sdfec.rst
> new file mode 100644
> index ..87966e3aa5fe
> --- /dev/null
> +++ b/Documentation/misc-devices/xilinx_sdfec.rst
> @@ -0,0 +1,291 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Xilinx SD-FEC Driver
> +
> +
> +Overview
> +
> +
> +This driver supports SD-FEC Integrated Block for Zynq |Ultrascale+ (TM)| 
> RFSoCs.
> +
> +.. |Ultrascale+ (TM)| unicode:: Ultrascale+ U+2122
> +   .. with trademark sign
> +
> +For a full description of SD-FEC core features, see the `SD-FEC Product 
> Guide (PG256) 
> `_
> +
> +This driver supports the following features:
> +
> +  - Retrieval of the Integrated Block configuration and status information
> +  - Configuration of LDPC codes
> +  - Configuration of Turbo decoding
> +  - Monitoring errors
> +
> +Missing features, known issues, and limitations of the SD-FEC driver are as
> +follows:
> +
> +  - Only allows a single open file handler to any instance of the driver at 
> any time
> +  - Reset of the SD-FEC Integrated Block is not controlled by this driver
> +  - Does not support shared LDPC code table wraparound
> +
> +The device tree entry is described in:
> +`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt 
> `_
> +
> +
> +Modes of Operation
> +--
> +
> +The driver works with the SD-FEC core in two modes of operation:
> +
> +  - Run-time configuration
> +  - Programmable Logic (PL) initialization
> +
> +
> +Run-time Configuration
> +~~
> +
> +For Run-time configuration the role of driver is to allow the software 
> application to do the following:
> +
> + - Load the configuration parameters for either Turbo decode or LDPC 
> encode or decode
> + - Activate the SD-FEC core
> + - Monitor the SD-FEC core for errors
> + - Retrieve the status and configuration of the SD-FEC core
> +
> +Programmable Logic (PL) Initialization
> +~~
> +
> +For PL initialization, supporting logic loads configuration parameters for 
> either
> +the Turbo decode or LDPC encode or decode.  The role of the driver is to 
> allow
> +the software application to do the following:
> +
> + - Activate the SD-FEC core
> + - Monitor the SD-FEC core for errors
> + - Retrieve the status and configuration of the SD-FEC core
> +
> +
> +Driver Structure
> +
> +
> +The driver provides a platform device where the ``probe`` and ``remove``
> +operations are provided.
> +
> +  - probe: Updates configuration register with device-tree entries plus 
> determines the current activate state of the core, for example, is the core 
> bypassed or has the core been started.
> +
> +
> +The driver defines the following driver file operations to provide user
> +application interfaces:
> +
> +  - open: Implements restriction that only a single file descriptor can be 
> open per SD-FEC instance at any time
> +  - release: Allows another file descriptor to be open, that is after 
> current file descriptor is closed
> +  - poll: Provides a method to monitor for SD-FEC Error events
> +  - unlocked_ioctl: Provides the the following ioctl commands that allows 
> the application configure the SD-FEC core:
> +
> + - :c:macro:`XSDFEC_START_DEV`
> + - :c:macro:`XSDFEC_STOP_DEV`
> + - :c:macro:`XSDFEC_GET_STATUS`
> + - :c:macro:`XSDFEC_SET_IRQ`
> + - :c:macro:`XSDFEC_SET_TURBO`
> + - :c:macro:`XSDFEC_ADD_LDPC_CODE_PARAMS`
> + - :c:macro:`XSDFEC_GET_CONFIG`
> + - :c:macro:`XSDFEC_SET_ORDER`
> + - :c:macro:`XSDFEC_SET_BYPASS`
> + - :c:macro:`XSDFEC_IS_ACTIVE`
> + - :c:macro:`XSDFEC_CLEAR_STATS`
> + - :c:macro:`XSDFEC_SET_DEFAULT_CONFIG`
> +
> +
> +Driver Usage
> +
> +
> +
> +Overview
> +
> +
>

Re: [PATCH] docs: misc: xilinx_sdfec: Actually add documentation

[Randy Dunlap]

On 10/10/19 3:35 PM, Kees Cook wrote:
> On Wed, Oct 02, 2019 at 10:03:55AM -0700, Kees Cook wrote:
>> From: Derek Kiernan 
>>
>> Add SD-FEC driver documentation.
>>
>> Signed-off-by: Derek Kiernan 
>> Signed-off-by: Dragan Cvetic 
>> Link: 
>> https://lore.kernel.org/r/1560274185-264438-11-git-send-email-dragan.cve...@xilinx.com
>> [kees: extracted from v7 as it was missing in the commit for v8]
>> Signed-off-by: Kees Cook 
>> ---
>> As mentioned[1], this file went missing and causes a warning in ReST
>> parsing, so I've extracted the patch and am sending it directly to Jon.
>> [1] https://lore.kernel.org/lkml/201909231450.4C6CF32@keescook/
>> ---
> 
> friendly ping! :)
> 
> -Kees
> 
>>  Documentation/misc-devices/xilinx_sdfec.rst | 291 
>>  1 file changed, 291 insertions(+)
>>  create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst
>>
>> diff --git a/Documentation/misc-devices/xilinx_sdfec.rst 
>> b/Documentation/misc-devices/xilinx_sdfec.rst
>> new file mode 100644
>> index ..87966e3aa5fe
>> --- /dev/null
>> +++ b/Documentation/misc-devices/xilinx_sdfec.rst
>> @@ -0,0 +1,291 @@
>> +.. SPDX-License-Identifier: GPL-2.0+
>> +
>> +Xilinx SD-FEC Driver
>> +
>> +
>> +Overview
>> +
>> +
>> +This driver supports SD-FEC Integrated Block for Zynq |Ultrascale+ (TM)| 
>> RFSoCs.
>> +
>> +.. |Ultrascale+ (TM)| unicode:: Ultrascale+ U+2122
>> +   .. with trademark sign
>> +
>> +For a full description of SD-FEC core features, see the `SD-FEC Product 
>> Guide (PG256) 
>> `_
>> +
>> +This driver supports the following features:
>> +
>> +  - Retrieval of the Integrated Block configuration and status information
>> +  - Configuration of LDPC codes
>> +  - Configuration of Turbo decoding
>> +  - Monitoring errors
>> +
>> +Missing features, known issues, and limitations of the SD-FEC driver are as
>> +follows:
>> +
>> +  - Only allows a single open file handler to any instance of the driver at 
>> any time
>> +  - Reset of the SD-FEC Integrated Block is not controlled by this driver
>> +  - Does not support shared LDPC code table wraparound
>> +
>> +The device tree entry is described in:
>> +`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt 
>> `_
>> +
>> +
>> +Modes of Operation
>> +--
>> +
>> +The driver works with the SD-FEC core in two modes of operation:
>> +
>> +  - Run-time configuration
>> +  - Programmable Logic (PL) initialization
>> +
>> +
>> +Run-time Configuration
>> +~~
>> +
>> +For Run-time configuration the role of driver is to allow the software 
>> application to do the following:
>> +
>> +- Load the configuration parameters for either Turbo decode or LDPC 
>> encode or decode
>> +- Activate the SD-FEC core
>> +- Monitor the SD-FEC core for errors
>> +- Retrieve the status and configuration of the SD-FEC core
>> +
>> +Programmable Logic (PL) Initialization
>> +~~
>> +
>> +For PL initialization, supporting logic loads configuration parameters for 
>> either
>> +the Turbo decode or LDPC encode or decode.  The role of the driver is to 
>> allow
>> +the software application to do the following:
>> +
>> +- Activate the SD-FEC core
>> +- Monitor the SD-FEC core for errors
>> +- Retrieve the status and configuration of the SD-FEC core
>> +
>> +
>> +Driver Structure
>> +
>> +
>> +The driver provides a platform device where the ``probe`` and ``remove``
>> +operations are provided.
>> +
>> +  - probe: Updates configuration register with device-tree entries plus 
>> determines the current activate state of the core, for example, is the core 
>> bypassed or has the core been started.
>> +
>> +
>> +The driver defines the following driver file operations to provide user
>> +application interfaces:
>> +
>> +  - open: Implements restriction that only a single file descriptor can be 
>> open per SD-FEC instance at any time
>> +  - release: Allows another file descriptor to be open, that is after 
>> current file descriptor is closed
>> +  - poll: Provides a method to monitor for SD-FEC Error events
>> +  - unlocked_ioctl: Provides the the following ioctl commands that allows 
>> the application configure the SD-FEC core:
>> +
>> +- :c:macro:`XSDFEC_START_DEV`
>> +- :c:macro:`XSDFEC_STOP_DEV`
>> +- :c:macro:`XSDFEC_GET_STATUS`
>> +- :c:macro:`XSDFEC_SET_IRQ`
>> +- :c:macro:`XSDFEC_SET_TURBO`
>> +- :c:macro:`XSDFEC_ADD_LDPC_CODE_PARAMS`
>> +- :c:macro:`XSDFEC_GET_CONFIG`
>> +- :c:macro:`XSDFEC_SET_ORDER`
>> +- :c:macro:`XSDFEC_SET_BYPASS`
>> +- :c:macro:`XSDFEC_IS_ACTIVE`
>> +- :

Re: [PATCH] docs: misc: xilinx_sdfec: Actually add documentation

[Jonathan Corbet]

On Thu, 10 Oct 2019 15:35:41 -0700
Kees Cook  wrote:

> On Wed, Oct 02, 2019 at 10:03:55AM -0700, Kees Cook wrote:
> > From: Derek Kiernan 
> > 
> > Add SD-FEC driver documentation.
> > 
> > Signed-off-by: Derek Kiernan 
> > Signed-off-by: Dragan Cvetic 
> > Link: 
> > https://lore.kernel.org/r/1560274185-264438-11-git-send-email-dragan.cve...@xilinx.com
> > [kees: extracted from v7 as it was missing in the commit for v8]
> > Signed-off-by: Kees Cook 
> > ---
> > As mentioned[1], this file went missing and causes a warning in ReST
> > parsing, so I've extracted the patch and am sending it directly to Jon.
> > [1] https://lore.kernel.org/lkml/201909231450.4C6CF32@keescook/
> > ---  
> 
> friendly ping! :)
> 
> -Kees

It's sitting in my queue.  I was hoping to hear from Derek that it was OK
to add...Derek are you out there?

Thanks,

jon

Re: [PATCH] Documentation: networking: add a chapter for the DIM library

[Jakub Kicinski]

On Thu, 10 Oct 2019 15:55:15 -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Add a Documentation networking chapter for the DIM library.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Tal Gilboa 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: net...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> ---
>  Documentation/networking/index.rst   |1 +
>  Documentation/networking/lib-dim.rst |6 ++
>  2 files changed, 7 insertions(+)
> 
> --- linux-next-20191010.orig/Documentation/networking/index.rst
> +++ linux-next-20191010/Documentation/networking/index.rst
> @@ -33,6 +33,7 @@ Contents:
> scaling
> tls
> tls-offload
> +   lib-dim
>  
>  .. only::  subproject and html
>  
> --- /dev/null
> +++ linux-next-20191010/Documentation/networking/lib-dim.rst
> @@ -0,0 +1,6 @@
> +=
> +Dynamic Interrupt Moderation (DIM) library interfaces
> +=
> +
> +.. kernel-doc:: include/linux/dim.h
> +:internal:
> 
> 

CC: linux-doc, Jake

How does this relate to Documentation/networking/net_dim.txt ?
(note in case you want to edit that one there is a patch with 
updates for that file from Jake I'll be applying shortly)

Re: [PATCH] docs: misc: xilinx_sdfec: Actually add documentation

[Kees Cook]

On Thu, Oct 10, 2019 at 03:38:42PM -0700, Randy Dunlap wrote:
> On 10/10/19 3:35 PM, Kees Cook wrote:
> > On Wed, Oct 02, 2019 at 10:03:55AM -0700, Kees Cook wrote:
> >> From: Derek Kiernan 
> >>
> >> Add SD-FEC driver documentation.
> >>
> >> Signed-off-by: Derek Kiernan 
> >> Signed-off-by: Dragan Cvetic 
> >> Link: 
> >> https://lore.kernel.org/r/1560274185-264438-11-git-send-email-dragan.cve...@xilinx.com
> >> [kees: extracted from v7 as it was missing in the commit for v8]
> >> Signed-off-by: Kees Cook 
> >> ---
> >> As mentioned[1], this file went missing and causes a warning in ReST
> >> parsing, so I've extracted the patch and am sending it directly to Jon.
> >> [1] https://lore.kernel.org/lkml/201909231450.4C6CF32@keescook/
> >> ---
> > 
> > friendly ping! :)
> > 
> > -Kees
> > 
> >>  Documentation/misc-devices/xilinx_sdfec.rst | 291 
> >>  1 file changed, 291 insertions(+)
> >>  create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst
> >>
> >> diff --git a/Documentation/misc-devices/xilinx_sdfec.rst 
> >> b/Documentation/misc-devices/xilinx_sdfec.rst
> >> new file mode 100644
> >> index ..87966e3aa5fe
> >> --- /dev/null
> >> +++ b/Documentation/misc-devices/xilinx_sdfec.rst
> >> @@ -0,0 +1,291 @@
> >> +.. SPDX-License-Identifier: GPL-2.0+
> >> +
> >> +Xilinx SD-FEC Driver
> >> +
> >> +
> >> +Overview
> >> +
> >> +
> >> +This driver supports SD-FEC Integrated Block for Zynq |Ultrascale+ (TM)| 
> >> RFSoCs.
> >> +
> >> +.. |Ultrascale+ (TM)| unicode:: Ultrascale+ U+2122
> >> +   .. with trademark sign
> >> +
> >> +For a full description of SD-FEC core features, see the `SD-FEC Product 
> >> Guide (PG256) 
> >> `_
> >> +
> >> +This driver supports the following features:
> >> +
> >> +  - Retrieval of the Integrated Block configuration and status information
> >> +  - Configuration of LDPC codes
> >> +  - Configuration of Turbo decoding
> >> +  - Monitoring errors
> >> +
> >> +Missing features, known issues, and limitations of the SD-FEC driver are 
> >> as
> >> +follows:
> >> +
> >> +  - Only allows a single open file handler to any instance of the driver 
> >> at any time
> >> +  - Reset of the SD-FEC Integrated Block is not controlled by this driver
> >> +  - Does not support shared LDPC code table wraparound
> >> +
> >> +The device tree entry is described in:
> >> +`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt 
> >> `_
> >> +
> >> +
> >> +Modes of Operation
> >> +--
> >> +
> >> +The driver works with the SD-FEC core in two modes of operation:
> >> +
> >> +  - Run-time configuration
> >> +  - Programmable Logic (PL) initialization
> >> +
> >> +
> >> +Run-time Configuration
> >> +~~
> >> +
> >> +For Run-time configuration the role of driver is to allow the software 
> >> application to do the following:
> >> +
> >> +  - Load the configuration parameters for either Turbo decode or LDPC 
> >> encode or decode
> >> +  - Activate the SD-FEC core
> >> +  - Monitor the SD-FEC core for errors
> >> +  - Retrieve the status and configuration of the SD-FEC core
> >> +
> >> +Programmable Logic (PL) Initialization
> >> +~~
> >> +
> >> +For PL initialization, supporting logic loads configuration parameters 
> >> for either
> >> +the Turbo decode or LDPC encode or decode.  The role of the driver is to 
> >> allow
> >> +the software application to do the following:
> >> +
> >> +  - Activate the SD-FEC core
> >> +  - Monitor the SD-FEC core for errors
> >> +  - Retrieve the status and configuration of the SD-FEC core
> >> +
> >> +
> >> +Driver Structure
> >> +
> >> +
> >> +The driver provides a platform device where the ``probe`` and ``remove``
> >> +operations are provided.
> >> +
> >> +  - probe: Updates configuration register with device-tree entries plus 
> >> determines the current activate state of the core, for example, is the 
> >> core bypassed or has the core been started.
> >> +
> >> +
> >> +The driver defines the following driver file operations to provide user
> >> +application interfaces:
> >> +
> >> +  - open: Implements restriction that only a single file descriptor can 
> >> be open per SD-FEC instance at any time
> >> +  - release: Allows another file descriptor to be open, that is after 
> >> current file descriptor is closed
> >> +  - poll: Provides a method to monitor for SD-FEC Error events
> >> +  - unlocked_ioctl: Provides the the following ioctl commands that allows 
> >> the application configure the SD-FEC core:
> >> +
> >> +  - :c:macro:`XSDFEC_START_DEV`
> >> +  - :c:macro:`XSDFEC_STOP_DEV`
> >> +  - :c:macro:`XSDFEC_GET_STATUS`
> >> +  - :c:macro:`XSDFEC_SET_IRQ

Re: [PATCH] Documentation: networking: add a chapter for the DIM library

[Randy Dunlap]

On 10/10/19 4:20 PM, Jakub Kicinski wrote:
> On Thu, 10 Oct 2019 15:55:15 -0700, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> Add a Documentation networking chapter for the DIM library.
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Tal Gilboa 
>> Cc: "David S. Miller" 
>> Cc: Jakub Kicinski 
>> Cc: net...@vger.kernel.org
>> Cc: linux-r...@vger.kernel.org
>> ---
>>  Documentation/networking/index.rst   |1 +
>>  Documentation/networking/lib-dim.rst |6 ++
>>  2 files changed, 7 insertions(+)
>>
>> --- linux-next-20191010.orig/Documentation/networking/index.rst
>> +++ linux-next-20191010/Documentation/networking/index.rst
>> @@ -33,6 +33,7 @@ Contents:
>> scaling
>> tls
>> tls-offload
>> +   lib-dim
>>  
>>  .. only::  subproject and html
>>  
>> --- /dev/null
>> +++ linux-next-20191010/Documentation/networking/lib-dim.rst
>> @@ -0,0 +1,6 @@
>> +=
>> +Dynamic Interrupt Moderation (DIM) library interfaces
>> +=
>> +
>> +.. kernel-doc:: include/linux/dim.h
>> +:internal:
>>
>>
> 
> CC: linux-doc, Jake
> 
> How does this relate to Documentation/networking/net_dim.txt ?
> (note in case you want to edit that one there is a patch with 
> updates for that file from Jake I'll be applying shortly)
> 

There is also a small patch from Jesse:
https://lore.kernel.org/netdev/20191010193112.15215-1-jesse.brandeb...@intel.com/


-- 
~Randy

Re: [PATCH] Documentation: networking: add a chapter for the DIM library

[Jakub Kicinski]

On Thu, 10 Oct 2019 16:34:59 -0700, Randy Dunlap wrote:
> On 10/10/19 4:20 PM, Jakub Kicinski wrote:
> > On Thu, 10 Oct 2019 15:55:15 -0700, Randy Dunlap wrote:  
> >> From: Randy Dunlap 
> >>
> >> Add a Documentation networking chapter for the DIM library.
> >>
> >> Signed-off-by: Randy Dunlap 
> >> Cc: Tal Gilboa 
> >> Cc: "David S. Miller" 
> >> Cc: Jakub Kicinski 
> >> Cc: net...@vger.kernel.org
> >> Cc: linux-r...@vger.kernel.org
> >> ---
> >>  Documentation/networking/index.rst   |    1 +
> >>  Documentation/networking/lib-dim.rst |6 ++
> >>  2 files changed, 7 insertions(+)
> >>
> >> --- linux-next-20191010.orig/Documentation/networking/index.rst
> >> +++ linux-next-20191010/Documentation/networking/index.rst
> >> @@ -33,6 +33,7 @@ Contents:
> >> scaling
> >> tls
> >> tls-offload
> >> +   lib-dim
> >>  
> >>  .. only::  subproject and html
> >>  
> >> --- /dev/null
> >> +++ linux-next-20191010/Documentation/networking/lib-dim.rst
> >> @@ -0,0 +1,6 @@
> >> +=
> >> +Dynamic Interrupt Moderation (DIM) library interfaces
> >> +=
> >> +
> >> +.. kernel-doc:: include/linux/dim.h
> >> +:internal:
> >>
> >>  
> > 
> > CC: linux-doc, Jake
> > 
> > How does this relate to Documentation/networking/net_dim.txt ?
> > (note in case you want to edit that one there is a patch with 
> > updates for that file from Jake I'll be applying shortly)

Applied now.

> There is also a small patch from Jesse:
> https://lore.kernel.org/netdev/20191010193112.15215-1-jesse.brandeb...@intel.com/

Ack, as Jake said this duplicates part of what his patch covered, tho.

Will you try to convert and integrate the existing file instead, or do
you think the kdoc file should be separate?

Re: [PATCH] Documentation: networking: add a chapter for the DIM library

[Randy Dunlap]

On 10/10/19 4:58 PM, Jakub Kicinski wrote:
> On Thu, 10 Oct 2019 16:34:59 -0700, Randy Dunlap wrote:
>> On 10/10/19 4:20 PM, Jakub Kicinski wrote:
>>> On Thu, 10 Oct 2019 15:55:15 -0700, Randy Dunlap wrote:  
>>>> From: Randy Dunlap 
>>>>
>>>> Add a Documentation networking chapter for the DIM library.
>>>>
>>>> Signed-off-by: Randy Dunlap 
>>>> Cc: Tal Gilboa 
>>>> Cc: "David S. Miller" 
>>>> Cc: Jakub Kicinski 
>>>> Cc: net...@vger.kernel.org
>>>> Cc: linux-r...@vger.kernel.org
>>>> ---
>>>>  Documentation/networking/index.rst   |1 +
>>>>  Documentation/networking/lib-dim.rst |6 ++
>>>>  2 files changed, 7 insertions(+)
>>>>
>>>> --- linux-next-20191010.orig/Documentation/networking/index.rst
>>>> +++ linux-next-20191010/Documentation/networking/index.rst
>>>> @@ -33,6 +33,7 @@ Contents:
>>>> scaling
>>>> tls
>>>> tls-offload
>>>> +   lib-dim
>>>>  
>>>>  .. only::  subproject and html
>>>>  
>>>> --- /dev/null
>>>> +++ linux-next-20191010/Documentation/networking/lib-dim.rst
>>>> @@ -0,0 +1,6 @@
>>>> +=
>>>> +Dynamic Interrupt Moderation (DIM) library interfaces
>>>> +=
>>>> +
>>>> +.. kernel-doc:: include/linux/dim.h
>>>> +:internal:
>>>>
>>>>  
>>>
>>> CC: linux-doc, Jake
>>>
>>> How does this relate to Documentation/networking/net_dim.txt ?
>>> (note in case you want to edit that one there is a patch with 
>>> updates for that file from Jake I'll be applying shortly)
> 
> Applied now.
> 
>> There is also a small patch from Jesse:
>> https://lore.kernel.org/netdev/20191010193112.15215-1-jesse.brandeb...@intel.com/
> 
> Ack, as Jake said this duplicates part of what his patch covered, tho.

Yes, so I noticed.

> Will you try to convert and integrate the existing file instead, or do
> you think the kdoc file should be separate?

I'll take a look at doing that.

thanks.
-- 
~Randy

Re: [PATCH] Documentation: networking: add a chapter for the DIM library

[Jakub Kicinski]

On Thu, 10 Oct 2019 17:01:02 -0700, Randy Dunlap wrote:
> > Will you try to convert and integrate the existing file instead, or do
> > you think the kdoc file should be separate?  
> 
> I'll take a look at doing that.

Thanks!

Re: [PATCH v7 5/8] Input: silead - Switch to firmware_request_platform for retreiving the fw

[Dmitry Torokhov]

On Fri, Oct 04, 2019 at 04:50:53PM +0200, Hans de Goede wrote:
> Unfortunately sofar we have been unable to get permission to redistribute
> Silead touchscreen firmwares in linux-firmware. This means that people
> need to find and install the firmware themselves before the touchscreen
> will work
> 
> Some UEFI/x86 tablets with a Silead touchscreen have a copy of the fw
> embedded in their UEFI boot-services code.
> 
> This commit makes the silead driver use the new firmware_request_platform
> function, which will fallback to looking for such an embedded copy when
> direct filesystem lookup fails. This will make the touchscreen work OOTB
> on devices where there is a fw copy embedded in the UEFI code.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Dmitry Torokhov 

> ---
>  drivers/input/touchscreen/silead.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/silead.c 
> b/drivers/input/touchscreen/silead.c
> index ad8b6a2bfd36..8fa2f3b7cfd8 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -288,7 +288,7 @@ static int silead_ts_load_fw(struct i2c_client *client)
>  
>   dev_dbg(dev, "Firmware file name: %s", data->fw_name);
>  
> - error = request_firmware(&fw, data->fw_name, dev);
> + error = firmware_request_platform(&fw, data->fw_name, dev);
>   if (error) {
>   dev_err(dev, "Firmware request error %d\n", error);
>   return error;
> -- 
> 2.23.0
> 

-- 
Dmitry

Re: [PATCH v7 6/8] Input: icn8505 - Switch to firmware_request_platform for retreiving the fw

[Dmitry Torokhov]

On Fri, Oct 04, 2019 at 04:50:54PM +0200, Hans de Goede wrote:
> Unfortunately sofar we have been unable to get permission to redistribute
> icn8505 touchscreen firmwares in linux-firmware. This means that people
> need to find and install the firmware themselves before the touchscreen
> will work
> 
> Some UEFI/x86 tablets with an icn8505 touchscreen have a copy of the fw
> embedded in their UEFI boot-services code.
> 
> This commit makes the icn8505 driver use the new firmware_request_platform
> function, which will fallback to looking for such an embedded copy when
> direct filesystem lookup fails. This will make the touchscreen work OOTB
> on devices where there is a fw copy embedded in the UEFI code.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Dmitry Torokhov 

Feel free to merge with the rest of the series.

> ---
>  drivers/input/touchscreen/chipone_icn8505.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/chipone_icn8505.c 
> b/drivers/input/touchscreen/chipone_icn8505.c
> index c768186ce856..f9ca5502ac8c 100644
> --- a/drivers/input/touchscreen/chipone_icn8505.c
> +++ b/drivers/input/touchscreen/chipone_icn8505.c
> @@ -288,7 +288,7 @@ static int icn8505_upload_fw(struct icn8505_data *icn8505)
>* we may need it at resume. Having loaded it once will make the
>* firmware class code cache it at suspend/resume.
>*/
> - error = request_firmware(&fw, icn8505->firmware_name, dev);
> + error = firmware_request_platform(&fw, icn8505->firmware_name, dev);
>   if (error) {
>   dev_err(dev, "Firmware request error %d\n", error);
>   return error;
> -- 
> 2.23.0
> 

-- 
Dmitry

RE: [PATCH] Documentation: networking: device drivers: Remove stray asterisks

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Jonathan Neuschäfer
> Sent: Wednesday, October 2, 2019 8:10 AM
> To: linux-doc@vger.kernel.org
> Cc: Jonathan Neuschäfer ; Kirsher, Jeffrey T
> ; David S. Miller ;
> Jonathan Corbet ; Shannon Nelson ;
> Pensando Drivers ; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] Documentation: networking: device drivers: Remove stray
> asterisks
> 
> These asterisks were once references to a line that said:
>   "* Other names and brands may be claimed as the property of others."
> But now, they serve no purpose; they can only irritate the reader.
> 
> Fixes: de3edab4276c ("e1000: update README for e1000")
> Fixes: a3fb65680f65 ("e100.txt: Cleanup license info in kernel doc")
> Fixes: da8c01c4502a ("e1000e.txt: Add e1000e documentation")
> Fixes: f12a84a9f650 ("Documentation: fm10k: Add kernel documentation")
> Fixes: b55c52b1938c ("igb.txt: Add igb documentation")
> Fixes: c4e9b56e2442 ("igbvf.txt: Add igbvf Documentation")
> Fixes: d7064f4c192c ("Documentation/networking/: Update Intel wired LAN
> driver documentation")
> Fixes: c4b8c01112a1 ("ixgbevf.txt: Update ixgbevf documentation")
> Fixes: 1e06edcc2f22 ("Documentation: i40e: Prepare documentation for RST
> conversion")
> Fixes: 105bf2fe6b32 ("i40evf: add driver to kernel build system")
> Fixes: 1fae869bcf3d ("Documentation: ice: Prepare documentation for RST
> conversion")
> Fixes: df69ba43217d ("ionic: Add basic framework for IONIC Network device
> driver")
> Signed-off-by: Jonathan Neuschäfer 
> ---
>  .../networking/device_drivers/intel/e100.rst   | 14 +++---
>  .../networking/device_drivers/intel/e1000.rst  | 12 ++--
>  .../networking/device_drivers/intel/e1000e.rst | 14 +++---
>  .../networking/device_drivers/intel/fm10k.rst  | 10 +-
>  .../networking/device_drivers/intel/i40e.rst   |  8 
>  .../networking/device_drivers/intel/iavf.rst   |  8 
>  .../networking/device_drivers/intel/ice.rst|  6 +++---
>  .../networking/device_drivers/intel/igb.rst| 12 ++--
>  .../networking/device_drivers/intel/igbvf.rst  |  6 +++---
>  .../networking/device_drivers/intel/ixgbe.rst  | 10 +-
>  .../networking/device_drivers/intel/ixgbevf.rst|  6 +++---
>  .../networking/device_drivers/pensando/ionic.rst   |  6 +++---
>  12 files changed, 56 insertions(+), 56 deletions(-)
> 

Tested-by: Aaron Brown 

Re: [PATCH v9 3/5] mfd: ioc3: Add driver for SGI IOC3 chip

[Jakub Kicinski]

On Thu, 10 Oct 2019 16:59:49 +0200, Thomas Bogendoerfer wrote:
>   dev = alloc_etherdev(sizeof(struct ioc3_private));
> - if (!dev) {
> - err = -ENOMEM;
> - goto out_disable;
> - }
> -
> - if (pci_using_dac)
> - dev->features |= NETIF_F_HIGHDMA;

Looks like the NETIF_F_HIGHDMA feature will not longer be set, is that
okay?

> - err = pci_request_regions(pdev, "ioc3");
> - if (err)
> - goto out_free;
> + if (!dev)
> + return -ENOMEM;
>  
>   SET_NETDEV_DEV(dev, &pdev->dev);
>  
>   ip = netdev_priv(dev);
> - ip->dev = dev;
> - ip->dma_dev = &pdev->dev;
> -
> - dev->irq = pdev->irq;
> + ip->dma_dev = pdev->dev.parent;
> + ip->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (!ip->regs) {
> + err = -ENOMEM;
> + goto out_free;
> + }

[TYPO] SafeSetID.rst: Remove spurious '???' characters

[Christian Kujau]

While reading SafeSetID.rst I stumbled across those things. This patch 
removes these spurious '???' characters.

Signed-off-by: Christian Kujau 

diff --git a/Documentation/admin-guide/LSM/SafeSetID.rst 
b/Documentation/admin-guide/LSM/SafeSetID.rst
index 212434ef65ad..7bff07ce4fdd 100644
--- a/Documentation/admin-guide/LSM/SafeSetID.rst
+++ b/Documentation/admin-guide/LSM/SafeSetID.rst
@@ -56,7 +56,7 @@ setid capabilities from the application completely and 
refactor the process
 spawning semantics in the application (e.g. by using a privileged helper 
program
 to do process spawning and UID/GID transitions). Unfortunately, there are a
 number of semantics around process spawning that would be affected by this, 
such
-as fork() calls where the program doesn???t immediately call exec() after the
+as fork() calls where the program doesn't immediately call exec() after the
 fork(), parent processes specifying custom environment variables or command 
line
 args for spawned child processes, or inheritance of file handles across a
 fork()/exec(). Because of this, as solution that uses a privileged helper in
@@ -72,7 +72,7 @@ own user namespace, and only approved UIDs/GIDs could be 
mapped back to the
 initial system user namespace, affectively preventing privilege escalation.
 Unfortunately, it is not generally feasible to use user namespaces in 
isolation,
 without pairing them with other namespace types, which is not always an option.
-Linux checks for capabilities based off of the user namespace that ???owns??? 
some
+Linux checks for capabilities based off of the user namespace that "owns" some
 entity. For example, Linux has the notion that network namespaces are owned by
 the user namespace in which they were created. A consequence of this is that
 capability checks for access to a given network namespace are done by checking

-- 
BOFH excuse #451:

astropneumatic oscillations in the water-cooling

Re: [PATCH 2/2] misc: add support for the cc1101 RF transceiver chip from TI

[Greg Kroah-Hartman]

On Sun, Sep 22, 2019 at 08:03:56AM +0200, Heiko Schocher wrote:
> +struct __attribute__ ((packed)) msg_queue_user {
> + int type; /* CC1101_MSG_SET_ */
> +};
> +
> +/* CC1101_MSG_DEFINE_CONFIG */
> +struct __attribute__ ((packed)) config_param {
> + char addr;
> + char val;
> +};

{sigh}

None of these structures are valid ones to be passing to/from
userspace/kernel at all.  Please fix them up to work properly (i.e. use
the correct types and such).  I think there's a "how to write a correct
ioctl" document in the documentation directory somewhere, you might want
to search for that.

thanks,

greg k-h