[RFC PATCH 1/5] fsi/scom: Add mutex around FSI2PIB accesses

Otherwise, multiple clients can open the driver and attempt to access the PIB at the same time, thus clobbering each other in the process. Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-scom.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) diff

[RFC PATCH 1/5] fsi/scom: Add mutex around FSI2PIB accesses

Otherwise, multiple clients can open the driver and attempt to access the PIB at the same time, thus clobbering each other in the process. Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-scom.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) diff

[RFC PATCH 0/5] FSI scom driver overhaul

The current FSI scom driver is a bit too simplistic (and buggy). This fixes a locking bug, cleans a few things up, then overhaul the driver more thoroughly by providing proper support for the different type of SCOM accesses (direct and indirect), handling errors properly in the read/write

[RFC PATCH 0/5] FSI scom driver overhaul

The current FSI scom driver is a bit too simplistic (and buggy). This fixes a locking bug, cleans a few things up, then overhaul the driver more thoroughly by providing proper support for the different type of SCOM accesses (direct and indirect), handling errors properly in the read/write

[GIT PULL] FSI updates

changes up to 9f4a8a2d7f9d71093f41c4bb0ef8707e8145bad3: fsi/sbefifo: Add driver for the SBE FIFO (2018-06-12 14:05:39 +1000) Andrew Jeffery (2): fsi: gpio: Trace busy count fsi: gpio: Remove unused 'id' variable Benjamin Herrenschmidt (8): fsi/fsi-m

[GIT PULL] FSI updates

changes up to 9f4a8a2d7f9d71093f41c4bb0ef8707e8145bad3: fsi/sbefifo: Add driver for the SBE FIFO (2018-06-12 14:05:39 +1000) Andrew Jeffery (2): fsi: gpio: Trace busy count fsi: gpio: Remove unused 'id' variable Benjamin Herrenschmidt (8): fsi/fsi-m

[PATCH] drivers/of: Add devm_of_iomap()

shortcomings, such as not returning the size of the resource found (which can be necessary) and not being "managed". This adds a devm_of_iomap() that provides all of these and should probably replace uses of the above in most drivers. Signed-off-by: Benjamin Herrenschmidt --- I'm cooking a driver

[PATCH] drivers/of: Make of_io_request_and_map() "name" argument optional

These days of_address_to_resource() puts a reasonable name in the resource struct, thus make the "name" argument an optional override. Signed-off-by: Benjamin Herrenschmidt --- Just something I noticed ... we should probably update the callers to stop passing stupid names..

[PATCH] drivers/of: Add devm_of_iomap()

shortcomings, such as not returning the size of the resource found (which can be necessary) and not being "managed". This adds a devm_of_iomap() that provides all of these and should probably replace uses of the above in most drivers. Signed-off-by: Benjamin Herrenschmidt --- I'm cooking a driver

[PATCH] drivers/of: Make of_io_request_and_map() "name" argument optional

These days of_address_to_resource() puts a reasonable name in the resource struct, thus make the "name" argument an optional override. Signed-off-by: Benjamin Herrenschmidt --- Just something I noticed ... we should probably update the callers to stop passing stupid names..

Re: [PATCH 00/15] fsi: Overall improvements and new SBE fifo driver

(Greg, see below) On Tue, 2018-05-29 at 22:00 +0930, Joel Stanley wrote: > On 29 May 2018 at 11:00, Benjamin Herrenschmidt > wrote: > > This series brings in a number of improvements to our FSI stack > > (one of the service interfaces for communicating between a BMC chip

Re: [PATCH 00/15] fsi: Overall improvements and new SBE fifo driver

(Greg, see below) On Tue, 2018-05-29 at 22:00 +0930, Joel Stanley wrote: > On 29 May 2018 at 11:00, Benjamin Herrenschmidt > wrote: > > This series brings in a number of improvements to our FSI stack > > (one of the service interfaces for communicating between a BMC chip

Re: [PATCH v9 2/7] i2c: Add FSI-attached I2C master algorithm

On Mon, 2018-06-04 at 22:21 +0300, Andy Shevchenko wrote: > > +#define I2C_INT_ENABLE 0xff80 > > +#define I2C_INT_ERR0xfcc0 > > Now it looks like a flags combinations. > For me as for reader would be better to see quickly a decoded line. > > My proposal is to

Re: [PATCH v9 2/7] i2c: Add FSI-attached I2C master algorithm

On Mon, 2018-06-04 at 22:21 +0300, Andy Shevchenko wrote: > > +#define I2C_INT_ENABLE 0xff80 > > +#define I2C_INT_ERR0xfcc0 > > Now it looks like a flags combinations. > For me as for reader would be better to see quickly a decoded line. > > My proposal is to

Re: [PATCH v9 3/7] i2c: fsi: Add port structures

On Mon, 2018-06-04 at 22:17 +0300, Andy Shevchenko wrote: > > > +static int fsi_i2c_remove(struct device *dev) > > +{ > > + struct fsi_i2c_master *i2c = dev_get_drvdata(dev); > > + struct fsi_i2c_port *port; > > + > > + list_for_each_entry(port, >ports, list) { > > +

Re: [PATCH v9 3/7] i2c: fsi: Add port structures

On Mon, 2018-06-04 at 22:17 +0300, Andy Shevchenko wrote: > > > +static int fsi_i2c_remove(struct device *dev) > > +{ > > + struct fsi_i2c_master *i2c = dev_get_drvdata(dev); > > + struct fsi_i2c_port *port; > > + > > + list_for_each_entry(port, >ports, list) { > > +

Re: [PATCH v8 0/7] i2c: Add FSI-attached I2C master algorithm

On Thu, 2018-05-31 at 09:29 +0300, Andy Shevchenko wrote: > > If you have specific issues with how this is done, please express them > > clearly. It's quite possible that there's some better way to do what > > Eddie is doing here, but without *construtive* feedback this is > > pointless. > > It

Re: [PATCH v8 0/7] i2c: Add FSI-attached I2C master algorithm

On Thu, 2018-05-31 at 09:29 +0300, Andy Shevchenko wrote: > > If you have specific issues with how this is done, please express them > > clearly. It's quite possible that there's some better way to do what > > Eddie is doing here, but without *construtive* feedback this is > > pointless. > > It

Re: [PATCH v8 0/7] i2c: Add FSI-attached I2C master algorithm

On Thu, 2018-05-31 at 00:31 +0300, Andy Shevchenko wrote: > On Thu, May 31, 2018 at 12:07 AM, Eddie James > wrote: > > This series adds an algorithm for an I2C master physically located on an FSI > > slave device. The I2C master has multiple ports, each of which may be > > connected > > to an

Re: [PATCH v8 0/7] i2c: Add FSI-attached I2C master algorithm

On Thu, 2018-05-31 at 00:31 +0300, Andy Shevchenko wrote: > On Thu, May 31, 2018 at 12:07 AM, Eddie James > wrote: > > This series adds an algorithm for an I2C master physically located on an FSI > > slave device. The I2C master has multiple ports, each of which may be > > connected > > to an

Re: [PATCH v7 3/7] drivers/i2c: Add port structure to FSI algorithm

On Thu, 2018-05-31 at 00:27 +0300, Andy Shevchenko wrote: > On Wed, May 30, 2018 at 6:47 PM, Eddie James > wrote: > > On 05/29/2018 06:19 PM, Andy Shevchenko wrote: > > > On Wed, May 30, 2018 at 1:24 AM, Eddie James > > > wrote: > > > > static int fsi_i2c_probe(struct device *dev) > > > > {

Re: [PATCH v7 3/7] drivers/i2c: Add port structure to FSI algorithm

On Thu, 2018-05-31 at 00:27 +0300, Andy Shevchenko wrote: > On Wed, May 30, 2018 at 6:47 PM, Eddie James > wrote: > > On 05/29/2018 06:19 PM, Andy Shevchenko wrote: > > > On Wed, May 30, 2018 at 1:24 AM, Eddie James > > > wrote: > > > > static int fsi_i2c_probe(struct device *dev) > > > > {

Re: [PATCH v7 3/7] drivers/i2c: Add port structure to FSI algorithm

On Wed, 2018-05-30 at 10:47 -0500, Eddie James wrote: > > > + if (!list_empty(>ports)) { > > > > My gosh, this is done already in list_for_each*() > > No, list_for_each_entry does NOT check if the list is empty or if the > first entry is NULL. NULL is never valid for a list. It does

Re: [PATCH v7 3/7] drivers/i2c: Add port structure to FSI algorithm

On Wed, 2018-05-30 at 10:47 -0500, Eddie James wrote: > > > + if (!list_empty(>ports)) { > > > > My gosh, this is done already in list_for_each*() > > No, list_for_each_entry does NOT check if the list is empty or if the > first entry is NULL. NULL is never valid for a list. It does

[PATCH 04/15] fsi/fsi-master-gpio: Sample input data on different clock phase

it. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 4295a46780cb..d6508bbad1fb 100644 --- a/drivers/fsi

[PATCH 04/15] fsi/fsi-master-gpio: Sample input data on different clock phase

it. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 4295a46780cb..d6508bbad1fb 100644 --- a/drivers/fsi

[PATCH 10/15] fsi/gpio: Use relative-addressing commands

-by: Jeremy Kerr Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 102 ++ 1 file changed, 91 insertions(+), 11 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index

[PATCH 10/15] fsi/gpio: Use relative-addressing commands

-by: Jeremy Kerr Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 102 ++ 1 file changed, 91 insertions(+), 11 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index

[PATCH 01/15] fsi: gpio: Trace busy count

-by: Eddie James Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 3 +++ include/trace/events/fsi_master_gpio.h | 16 2 files changed, 19 insertions(+) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 3f487449a277

[PATCH 01/15] fsi: gpio: Trace busy count

-by: Eddie James Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 3 +++ include/trace/events/fsi_master_gpio.h | 16 2 files changed, 19 insertions(+) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 3f487449a277

[PATCH 14/15] fsi: scom: Remove PIB reset during probe

From: Eddie James The PIB reset causes problems for the running P9 chip. The reset shouldn't be performed by this driver. Signed-off-by: Eddie James Reviewed-by: Christopher Bostic Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-scom.c | 8 1 file changed, 8 deletions

[PATCH 14/15] fsi: scom: Remove PIB reset during probe

From: Eddie James The PIB reset causes problems for the running P9 chip. The reset shouldn't be performed by this driver. Signed-off-by: Eddie James Reviewed-by: Christopher Bostic Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-scom.c | 8 1 file changed, 8 deletions

[PATCH 02/15] fsi: gpio: Remove unused 'id' variable

From: Andrew Jeffery Signed-off-by: Andrew Jeffery Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 2a49b167effe..20b334f1827d

[PATCH 02/15] fsi: gpio: Remove unused 'id' variable

From: Andrew Jeffery Signed-off-by: Andrew Jeffery Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 2a49b167effe..20b334f1827d

[PATCH 09/15] fsi/gpio: Include command build in locked section

From: Jeremy Kerr For implementing relative addressing mode, we'll need to build a command that is coherent with CFAM state. To do that, include the build_command_* functions in the locked section of read/write/term. Signed-off-by: Jeremy Kerr Signed-off-by: Benjamin Herrenschmidt

[PATCH 09/15] fsi/gpio: Include command build in locked section

From: Jeremy Kerr For implementing relative addressing mode, we'll need to build a command that is coherent with CFAM state. To do that, include the build_command_* functions in the locked section of read/write/term. Signed-off-by: Jeremy Kerr Signed-off-by: Benjamin Herrenschmidt

[PATCH 15/15] fsi/sbefifo: Add driver for the SBE FIFO

le 4 bytes containing the value 0x52534554 in big endian will trigger a reset request. No read is necessary, the write() call will return when the reset has been acknowledged or times out. - The command is limited to 4K bytes. Signed-off-by: Benjamin Herrenschmidt --- --- drivers/f

[PATCH 15/15] fsi/sbefifo: Add driver for the SBE FIFO

le 4 bytes containing the value 0x52534554 in big endian will trigger a reset request. No read is necessary, the write() call will return when the reset has been acknowledged or times out. - The command is limited to 4K bytes. Signed-off-by: Benjamin Herrenschmidt --- --- drivers/f

[PATCH 07/15] fsi/fsi-master-gpio: Reduce dpoll clocks

performances negatively in some cases. Reduces it in half to 50 clocks which seems to still be solid. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/fsi/fsi-master

[PATCH 07/15] fsi/fsi-master-gpio: Reduce dpoll clocks

performances negatively in some cases. Reduces it in half to 50 clocks which seems to still be solid. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/fsi/fsi-master

[PATCH 08/15] fsi/fsi-master-gpio: Delay sampling of FSI data input

encountered during heavy activity on the LPC bus. This is fixed by introducing a dummy GPIO read before the actual data read. It slows down SBEFIFO by about 15% (less than any delay primitive) and the end result is so far solid. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic

[PATCH 08/15] fsi/fsi-master-gpio: Delay sampling of FSI data input

encountered during heavy activity on the LPC bus. This is fixed by introducing a dummy GPIO read before the actual data read. It slows down SBEFIFO by about 15% (less than any delay primitive) and the end result is so far solid. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic

[PATCH] dt-bindings: fsi-master-gpio: Document "no-gpio-delays" property

Support for this is being added to the driver but the original patch forgot to add this documentation. Signed-off-by: Benjamin Herrenschmidt --- Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings

[PATCH] dt-bindings: fsi-master-gpio: Document "no-gpio-delays" property

Support for this is being added to the driver but the original patch forgot to add this documentation. Signed-off-by: Benjamin Herrenschmidt --- Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings

Re: [PATCH 05/15] fsi/fsi-master-gpio: Add "no-gpio-delays" option

On Tue, 2018-05-29 at 11:30 +1000, Benjamin Herrenschmidt wrote: > This adds support for an optional device-tree property that > makes the driver skip all the delays around clocking the > GPIOs and set it in the device-tree of common POWER9 based > OpenPower platforms. > > Th

Re: [PATCH 05/15] fsi/fsi-master-gpio: Add "no-gpio-delays" option

On Tue, 2018-05-29 at 11:30 +1000, Benjamin Herrenschmidt wrote: > This adds support for an optional device-tree property that > makes the driver skip all the delays around clocking the > GPIOs and set it in the device-tree of common POWER9 based > OpenPower platforms. > > Th

[PATCH 03/15] fsi: gpio: Use a mutex to protect transfers

-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 86 ++- 1 file changed, 64 insertions(+), 22 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 20b334f1827d..4295a46780cb 100644 --- a/drivers/fsi/fsi-master-gpio.c

[PATCH 03/15] fsi: gpio: Use a mutex to protect transfers

-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 86 ++- 1 file changed, 64 insertions(+), 22 deletions(-) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 20b334f1827d..4295a46780cb 100644 --- a/drivers/fsi/fsi-master-gpio.c

[PATCH 12/15] fsi/fsi-master-gpio: More error handling cleanup

Remove calls to the empty and useless fsi_master_gpio_error() function, and report CRC errors as "FSI_ERR_NO_SLAVE" when reading an all 1's response. Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 26 +- 1 file changed, 5 inserti

[PATCH 12/15] fsi/fsi-master-gpio: More error handling cleanup

Remove calls to the empty and useless fsi_master_gpio_error() function, and report CRC errors as "FSI_ERR_NO_SLAVE" when reading an all 1's response. Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 26 +- 1 file changed, 5 inserti

[PATCH 13/15] fsi/master-gpio: Replace bit_bit lock with IRQ disable/enable

. To reflect this, this change converts bit_lock to just the local_irq_save/restore operation. Signed-off-by: Jeremy Kerr Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 48 +-- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git

[PATCH 13/15] fsi/master-gpio: Replace bit_bit lock with IRQ disable/enable

. To reflect this, this change converts bit_lock to just the local_irq_save/restore operation. Signed-off-by: Jeremy Kerr Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/fsi-master-gpio.c | 48 +-- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git

[PATCH 05/15] fsi/fsi-master-gpio: Add "no-gpio-delays" option

frequency (25Mhz typically). In this case, the delays are unnecessary and due to the low precision of the timers, actually quite harmful in terms of performance. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 1 + .../boot/dts

[PATCH 05/15] fsi/fsi-master-gpio: Add "no-gpio-delays" option

frequency (25Mhz typically). In this case, the delays are unnecessary and due to the low precision of the timers, actually quite harmful in terms of performance. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 1 + .../boot/dts

[PATCH 11/15] fsi/fsi-master-gpio: Implement CRC error recovery

requests a resend of the response without actually re-executing the command (which could otherwise have unwanted side effects such as dequeuing a FIFO twice). Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- Note: This was actually tested by removing some of my fixes

[PATCH 11/15] fsi/fsi-master-gpio: Implement CRC error recovery

requests a resend of the response without actually re-executing the command (which could otherwise have unwanted side effects such as dequeuing a FIFO twice). Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- Note: This was actually tested by removing some of my fixes

[PATCH 06/15] fsi/fsi-master-gpio: Reduce turnaround clocks

the driver performance. This changes it to 20 (which gives the HW a bit of margin still just in case). Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fsi/fsi-maste

[PATCH 00/15] fsi: Overall improvements and new SBE fifo driver

This series brings in a number of improvements to our FSI stack (one of the service interfaces for communicating between a BMC chip and our POWER processors). The GPIO based "Soft FSI" performance is significantly improved, and it's reliability as well. The SBE fifo driver provides the interface

[PATCH 06/15] fsi/fsi-master-gpio: Reduce turnaround clocks

the driver performance. This changes it to 20 (which gives the HW a bit of margin still just in case). Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic --- drivers/fsi/fsi-master-gpio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fsi/fsi-maste

[PATCH 00/15] fsi: Overall improvements and new SBE fifo driver

This series brings in a number of improvements to our FSI stack (one of the service interfaces for communicating between a BMC chip and our POWER processors). The GPIO based "Soft FSI" performance is significantly improved, and it's reliability as well. The SBE fifo driver provides the interface

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Tue, 2018-05-29 at 09:48 +1000, Benjamin Herrenschmidt wrote: > > Well it's not supposed to be much slower for the static case. > > > > vhost has a cache so should be fine. > > > > A while ago Paolo implemented a translation cache which should be > > perf

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Tue, 2018-05-29 at 09:48 +1000, Benjamin Herrenschmidt wrote: > > Well it's not supposed to be much slower for the static case. > > > > vhost has a cache so should be fine. > > > > A while ago Paolo implemented a translation cache which should be > > perf

Re: [PATCH] usb/gadget: aspeed-vhub: add USB_LIBCOMPOSITE dependency

hadn't realized these functions were part of an optional library. > Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") > Signed-off-by: Arnd Bergmann Acked-by: Benjamin Herrenschmidt > --- > drivers/usb/gadget/udc/aspeed-vhub/Kconfig | 1 + > 1 file

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Fri, 2018-05-25 at 20:45 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > >

Re: [PATCH] usb/gadget: aspeed-vhub: add USB_LIBCOMPOSITE dependency

hadn't realized these functions were part of an optional library. > Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") > Signed-off-by: Arnd Bergmann Acked-by: Benjamin Herrenschmidt > --- > drivers/usb/gadget/udc/aspeed-vhub/Kconfig | 1 + > 1 file

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Fri, 2018-05-25 at 20:45 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > >

Re: [PATCH] powerpc/64: Fix build failure with GCC 8.1

On Mon, 2018-05-28 at 16:37 +, Christophe Leroy wrote: > CC arch/powerpc/kernel/nvram_64.o > arch/powerpc/kernel/nvram_64.c: In function 'nvram_create_partition': > arch/powerpc/kernel/nvram_64.c:1042:2: error: 'strncpy' specified bound 12 > equals destination size

Re: [PATCH] powerpc/64: Fix build failure with GCC 8.1

On Mon, 2018-05-28 at 16:37 +, Christophe Leroy wrote: > CC arch/powerpc/kernel/nvram_64.o > arch/powerpc/kernel/nvram_64.c: In function 'nvram_create_partition': > arch/powerpc/kernel/nvram_64.c:1042:2: error: 'strncpy' specified bound 12 > equals destination size

Re: [PATCH] powerpc/64s: Clear PCR on boot

On Sat, 2018-05-26 at 20:45 -0700, Guenter Roeck wrote: > > I already have a patch, or at least one that does the trick for me. > Getting qemu patched was not the problem. I just want to be sure that > the problem is indeed a qemu problem. Hey Guenter ! It's not quite the right patch though.

Re: [PATCH] powerpc/64s: Clear PCR on boot

On Sat, 2018-05-26 at 20:45 -0700, Guenter Roeck wrote: > > I already have a patch, or at least one that does the trick for me. > Getting qemu patched was not the problem. I just want to be sure that > the problem is indeed a qemu problem. Hey Guenter ! It's not quite the right patch though.

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side

Re: set_fs(KERNEL_DS) vs iovec

On Tue, 2018-05-22 at 03:20 -0700, Christoph Hellwig wrote: > On Tue, May 22, 2018 at 03:08:35PM +1000, Benjamin Herrenschmidt wrote: > > Hence my question: Is is still acceptable these days to use > > set_fs(KERNEL_DS) for simple cases like this ? > > Not at all. &

Re: set_fs(KERNEL_DS) vs iovec

On Tue, 2018-05-22 at 03:20 -0700, Christoph Hellwig wrote: > On Tue, May 22, 2018 at 03:08:35PM +1000, Benjamin Herrenschmidt wrote: > > Hence my question: Is is still acceptable these days to use > > set_fs(KERNEL_DS) for simple cases like this ? > > Not at all. &

set_fs(KERNEL_DS) vs iovec

Hi guys ! I was helping with a small driver when I stumbled upon a comment from a reviwer pointing to an old lwn article talking about deprecating set_fs due to security concerns: https://lwn.net/Articles/722267/ Now, this is a very simple driver running on a small/slow ARM SoC, which reads

set_fs(KERNEL_DS) vs iovec

Hi guys ! I was helping with a small driver when I stumbled upon a comment from a reviwer pointing to an old lwn article talking about deprecating set_fs due to security concerns: https://lwn.net/Articles/722267/ Now, this is a very simple driver running on a small/slow ARM SoC, which reads

Lockdep complaint in jffs2

Hi David ! I noticed this on my BMC when building OpenBMC with Lockdep... something worth investigating/digging ? Cheers, Ben. 24.068677] == [ 24.074871] WARNING: possible circular locking dependency detected [ 24.081065]

Lockdep complaint in jffs2

Hi David ! I noticed this on my BMC when building OpenBMC with Lockdep... something worth investigating/digging ? Cheers, Ben. 24.068677] == [ 24.074871] WARNING: possible circular locking dependency detected [ 24.081065]

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Thu, 2018-05-17 at 15:21 +0200, Christophe LEROY wrote: > > > +static inline int __memcmp8(const void *p, const void *q, int off) > > > +{ > > > + s64 tmp = be64_to_cpu(*(u64*)(p + off)) - be64_to_cpu(*(u64*)(q + > > > off)); > > > > I always assumed 64bits unaligned access would

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Thu, 2018-05-17 at 15:21 +0200, Christophe LEROY wrote: > > > +static inline int __memcmp8(const void *p, const void *q, int off) > > > +{ > > > + s64 tmp = be64_to_cpu(*(u64*)(p + off)) - be64_to_cpu(*(u64*)(q + > > > off)); > > > > I always assumed 64bits unaligned access would

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

On Thu, 2018-05-17 at 22:10 +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs > > in order to use multiple word instructions in functions entry/exit > > True, though that could be a lot simpler

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

On Thu, 2018-05-17 at 22:10 +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs > > in order to use multiple word instructions in functions entry/exit > > True, though that could be a lot simpler because the MULTIPLEWORD

Re: [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock

On Wed, 2018-05-09 at 11:50 +0800, Lei YU wrote: > On Wed, May 9, 2018 at 11:43 AM, Guenter Roeck wrote: > > > > I am not going to accept this change, period. This is not one, it is five > > steps > > backward. If "aspeed_set_clock_source(priv->regmap, 0)" changes the clock >

Re: [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock

On Wed, 2018-05-09 at 11:50 +0800, Lei YU wrote: > On Wed, May 9, 2018 at 11:43 AM, Guenter Roeck wrote: > > > > I am not going to accept this change, period. This is not one, it is five > > steps > > backward. If "aspeed_set_clock_source(priv->regmap, 0)" changes the clock > > speed, > > or the

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote: > This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' > is > the 'release barrier' instruction, if I interpreted that right. The closest to one we got. The semantics are that it orders all load/store pairs to

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote: > This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' > is > the 'release barrier' instruction, if I interpreted that right. The closest to one we got. The semantics are that it orders all load/store pairs to

[BUG ?] lockdep report from nbd on 4.16

Hi ! I was playing with nbd on some little ARM bmc here with lockdep enabled and I get the following report. I don't have the bandwidth to dig into it this week to check if it's a false positive so I'm posting it here instead. Cheers, Ben. # nbd-client pasglop /dev/nbd0 Warning: the oldstyle

[BUG ?] lockdep report from nbd on 4.16

Hi ! I was playing with nbd on some little ARM bmc here with lockdep enabled and I get the following report. I don't have the bandwidth to dig into it this week to check if it's a false positive so I'm posting it here instead. Cheers, Ben. # nbd-client pasglop /dev/nbd0 Warning: the oldstyle

Re: [PATCH 08/15] powerpc/powernv: implement opal_put_chars_atomic

that is used, the better chance there > is that a crash can be debugged. Same comment I already had :-) "atomic" in Linux tends to mean something else (ie, atomic context), so I'd rather have something like opal_put_chars_sync() or such... > Cc: Benjamin Herrenschmidt <b...@ke

Re: [PATCH 08/15] powerpc/powernv: implement opal_put_chars_atomic

that is used, the better chance there > is that a crash can be debugged. Same comment I already had :-) "atomic" in Linux tends to mean something else (ie, atomic context), so I'd rather have something like opal_put_chars_sync() or such... > Cc: Benjamin Herrenschmidt >

Re: [PATCH] locking/rwsem: Synchronize task state & waiter->task of readers

On Tue, 2018-04-10 at 13:22 -0400, Waiman Long wrote: > It was observed occasionally in PowerPC systems that there was reader > who had not been woken up but that its waiter->task had been cleared. > > One probable cause of this missed wakeup may be the fact that the > waiter->task and the task

Re: [PATCH] locking/rwsem: Synchronize task state & waiter->task of readers

On Tue, 2018-04-10 at 13:22 -0400, Waiman Long wrote: > It was observed occasionally in PowerPC systems that there was reader > who had not been woken up but that its waiter->task had been cleared. > > One probable cause of this missed wakeup may be the fact that the > waiter->task and the task

Re: How to expose various BMC chip controls ?

On Tue, 2018-04-10 at 15:06 +0200, Arnd Bergmann wrote: > On Tue, Apr 10, 2018 at 2:57 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > On Tue, 2018-04-10 at 13:29 +0200, Arnd Bergmann wrote: > > > In the cases where an ad-hoc interface is needed, I ca

Re: How to expose various BMC chip controls ?

On Tue, 2018-04-10 at 15:06 +0200, Arnd Bergmann wrote: > On Tue, Apr 10, 2018 at 2:57 PM, Benjamin Herrenschmidt > wrote: > > On Tue, 2018-04-10 at 13:29 +0200, Arnd Bergmann wrote: > > > In the cases where an ad-hoc interface is needed, I can see > > > two o

Re: How to expose various BMC chip controls ?

On Tue, 2018-04-10 at 13:29 +0200, Arnd Bergmann wrote: > > Any better idea ? It's a fairly simple problem, and the above solution > > would be very little code, but I just don't want us to go down a rabbit > > hole if some of you have religious objections to some of it :) > > I think the hard

Re: How to expose various BMC chip controls ?

On Tue, 2018-04-10 at 13:29 +0200, Arnd Bergmann wrote: > > Any better idea ? It's a fairly simple problem, and the above solution > > would be very little code, but I just don't want us to go down a rabbit > > hole if some of you have religious objections to some of it :) > > I think the hard

How to expose various BMC chip controls ?

Hi Folks ! I would like to discuss something we need to solve for BMC chips before we start implementing a solution that you'll reject upstream :-) So quick recap: the BMC chip is the management controller of your server, typically some kind of specialized ARM SoC which controls a variety of

How to expose various BMC chip controls ?

Hi Folks ! I would like to discuss something we need to solve for BMC chips before we start implementing a solution that you'll reject upstream :-) So quick recap: the BMC chip is the management controller of your server, typically some kind of specialized ARM SoC which controls a variety of

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Fri, 2018-04-06 at 00:16 -0700, Christoph Hellwig wrote: > On Fri, Apr 06, 2018 at 08:23:10AM +0530, Anshuman Khandual wrote: > > On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote: > > > On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: > > > > &g

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Fri, 2018-04-06 at 00:16 -0700, Christoph Hellwig wrote: > On Fri, Apr 06, 2018 at 08:23:10AM +0530, Anshuman Khandual wrote: > > On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote: > > > On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: > > > > &g

<    1   2   3   4   5   6   7   8   9   10   >