Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation

c ioremap_nopost() implementation (currently > falling back to ioremap_nocache()) to provide a non-posted writes > ioremap interface to kernel subsystems. NAK. As explained in my reply to patch 0. > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > > Cc: Michael Ellerman &l

Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation

c ioremap_nopost() implementation (currently > falling back to ioremap_nocache()) to provide a non-posted writes > ioremap interface to kernel subsystems. NAK. As explained in my reply to patch 0. > Signed-off-by: Lorenzo Pieralisi > > Cc: Michael Ellerman > > Cc: Bjorn Helgaas >

Re: clear_page, copy_page address align question?

On Tue, 2017-04-11 at 12:08 +0900, Minchan Kim wrote: > Hello, > > When I tested zram in ppc64, I got random corruption. > With investigation, it seems clear_page corrupted the memory. > I passed 64K kmalloced(kmalloc(PAGE_SIZE)) address to clear_page > and turned on slub debug so address is not

Re: clear_page, copy_page address align question?

On Tue, 2017-04-11 at 12:08 +0900, Minchan Kim wrote: > Hello, > > When I tested zram in ppc64, I got random corruption. > With investigation, it seems clear_page corrupted the memory. > I passed 64K kmalloced(kmalloc(PAGE_SIZE)) address to clear_page > and turned on slub debug so address is not

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > A 3 microsecond delay is required, however, to prevent occasional issues  > during heavy FSI bus load stress testing. > A 1 nanosecond delay using ndelay(1) had been specified prior to this  > but after looking more closely at real

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > A 3 microsecond delay is required, however, to prevent occasional issues  > during heavy FSI bus load stress testing. > A 1 nanosecond delay using ndelay(1) had been specified prior to this  > but after looking more closely at real

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:53 +1000, Benjamin Herrenschmidt wrote: > FYI. pdbg in userspace operates without any  delays in practice, the > overhead between the various load/store instructions seems > sufficient. > > The only delay that's needed is when going through the FSI2PIB

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:53 +1000, Benjamin Herrenschmidt wrote: > FYI. pdbg in userspace operates without any  delays in practice, the > overhead between the various load/store instructions seems > sufficient. > > The only delay that's needed is when going through the FSI2PIB

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:41 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > > A 3 microsecond delay is required, however, to prevent occasional > > issues  > > during heavy FSI bus load stress testing. > > A 1 nano

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Mon, 2017-04-10 at 07:41 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote: > > A 3 microsecond delay is required, however, to prevent occasional > > issues  > > during heavy FSI bus load stress testing. > > A 1 nano

Re: tty crash in tty_ldisc_receive_buf()

On Fri, 2017-04-07 at 09:03 -0500, Rob Herring wrote: > Is this with a serial port? There were some changes to serial_core > close in 4.9. It's a combo of serial and hvc actually. Cheers, Ben.

Re: tty crash in tty_ldisc_receive_buf()

On Fri, 2017-04-07 at 09:03 -0500, Rob Herring wrote: > Is this with a serial port? There were some changes to serial_core > close in 4.9. It's a combo of serial and hvc actually. Cheers, Ben.

Re: tty crash in tty_ldisc_receive_buf()

On Thu, 2017-04-06 at 08:28 -0500, Rob Herring wrote: > > Can you try this one [1]. > > Rob > > [1] https://lkml.org/lkml/2017/3/23/569 Unless I missed something, that patch doesn't change barriers or locking, so I don't see how it could fix anything ... Mind you we haven't quite figured out

Re: tty crash in tty_ldisc_receive_buf()

On Thu, 2017-04-06 at 08:28 -0500, Rob Herring wrote: > > Can you try this one [1]. > > Rob > > [1] https://lkml.org/lkml/2017/3/23/569 Unless I missed something, that patch doesn't change barriers or locking, so I don't see how it could fix anything ... Mind you we haven't quite figured out

Re: tty crash in tty_ldisc_receive_buf()

On Thu, 2017-04-06 at 17:04 +1000, Michael Neuling wrote: > We see this usually on boot but can also see it if we kill a getty attached to > tty (which is then respawned by systemd).  It seems like we are flushing data > to > a tty at the same time as it's being torn down and restarted. > > I

Re: tty crash in tty_ldisc_receive_buf()

On Thu, 2017-04-06 at 17:04 +1000, Michael Neuling wrote: > We see this usually on boot but can also see it if we kill a getty attached to > tty (which is then respawned by systemd).  It seems like we are flushing data > to > a tty at the same time as it's being torn down and restarted. > > I

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Tue, 2017-04-04 at 12:32 -0500, Christopher Bostic wrote: > Agreed that there is room for improvement.   I intend to look further  > into your suggestions from here and our private conversation on the  > matter and make changes as appropriate.  I have an open issue to track  > this.  As it

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Tue, 2017-04-04 at 12:32 -0500, Christopher Bostic wrote: > Agreed that there is room for improvement.   I intend to look further  > into your suggestions from here and our private conversation on the  > matter and make changes as appropriate.  I have an open issue to track  > this.  As it

Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Sun, 2017-04-02 at 16:07 +0300, Andy Shevchenko wrote: > > +   port.port.irqflags = IRQF_SHARED; > > This is set by core. You already supplied correct flag for that > below. Are you sure ? Where ? We had a bug the other day because that wasn't being set... Cheers, Ben.

Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Sun, 2017-04-02 at 16:07 +0300, Andy Shevchenko wrote: > > +   port.port.irqflags = IRQF_SHARED; > > This is set by core. You already supplied correct flag for that > below. Are you sure ? Where ? We had a bug the other day because that wasn't being set... Cheers, Ben.

Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Fri, 2017-03-31 at 15:31 +0200, Greg Kroah-Hartman wrote: > DEVICE_ATTR_RW()? > > And why random sysfs files for a uart?  Where have you documented > these? We should stick a file somewhere in Documentation I suppose or at least put that in a comment blob at the head of the file. FYI: The

Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Fri, 2017-03-31 at 15:31 +0200, Greg Kroah-Hartman wrote: > DEVICE_ATTR_RW()? > > And why random sysfs files for a uart?  Where have you documented > these? We should stick a file somewhere in Documentation I suppose or at least put that in a comment blob at the head of the file. FYI: The

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

Allright, I finally found some time for reviewing some of this after splitting the ftgmac100 patch into 54 smaller ones :) On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: .../... > +struct aspeed_i2c_bus { > + struct i2c_adapter adap; > + struct device

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

Allright, I finally found some time for reviewing some of this after splitting the ftgmac100 patch into 54 smaller ones :) On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: .../... > +struct aspeed_i2c_bus { > + struct i2c_adapter adap; > + struct device

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Thu, 2017-03-30 at 13:15 -0500, Christopher Bostic wrote: > > > +static void serial_in(struct fsi_master_gpio *master, struct > > > fsi_gpio_msg *msg, > > > +   uint8_t num_bits) > > > +{ > > > +   uint8_t bit, in_bit; > > > + > > > +   set_sda_input(master); > > >

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

On Thu, 2017-03-30 at 13:15 -0500, Christopher Bostic wrote: > > > +static void serial_in(struct fsi_master_gpio *master, struct > > > fsi_gpio_msg *msg, > > > +   uint8_t num_bits) > > > +{ > > > +   uint8_t bit, in_bit; > > > + > > > +   set_sda_input(master); > > >

Re: [PATCH] macintosh: Do not arbitrarily limit architecture for macintosh drivers.

On Wed, 2017-03-29 at 23:29 +0200, Arnd Bergmann wrote: > Why not move the mac_hid module to drivers/input instead so > it no longer depends on MACINTOSH_DRIVERS? > > For the other mac drivers, it may be helpful to to add '|| > COMPILE_TEST' > to the dependency line here to allow building them on

Re: [PATCH] macintosh: Do not arbitrarily limit architecture for macintosh drivers.

On Wed, 2017-03-29 at 23:29 +0200, Arnd Bergmann wrote: > Why not move the mac_hid module to drivers/input instead so > it no longer depends on MACINTOSH_DRIVERS? > > For the other mac drivers, it may be helpful to to add '|| > COMPILE_TEST' > to the dependency line here to allow building them on

Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller

On Wed, 2017-03-29 at 13:51 -0700, Brendan Higgins wrote: > so maybe instead of setting a hard limit like I did, maybe the best > thing is to just check and see what the base_clk gets set to and if > it gets set to zero, we turn on high speed mode. What do you think? Ah maybe. Did you scope it to

Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller

On Wed, 2017-03-29 at 13:51 -0700, Brendan Higgins wrote: > so maybe instead of setting a hard limit like I did, maybe the best > thing is to just check and see what the base_clk gets set to and if > it gets set to zero, we turn on high speed mode. What do you think? Ah maybe. Did you scope it to

Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller

On Wed, 2017-03-29 at 03:34 -0700, Brendan Higgins wrote: > I think I addressed this on the other email with the actual driver. > Anyway, I thought that this is pretty much the dummy irqchip code is > for; I have seen some other drivers do the same thing. It is true > that > this is a really basic

Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller

On Wed, 2017-03-29 at 03:34 -0700, Brendan Higgins wrote: > I think I addressed this on the other email with the actual driver. > Anyway, I thought that this is pretty much the dummy irqchip code is > for; I have seen some other drivers do the same thing. It is true > that > this is a really basic

Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

On Tue, 2017-03-28 at 10:40 +0100, Marc Zyngier wrote: > On 28/03/17 10:12, Benjamin Herrenschmidt wrote: > > On Tue, 2017-03-28 at 09:32 +0100, Marc Zyngier wrote: > > > I'm a bit concerned by this. It means that you can't even mask an > > > interrupt. Is that really wh

Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

On Tue, 2017-03-28 at 10:40 +0100, Marc Zyngier wrote: > On 28/03/17 10:12, Benjamin Herrenschmidt wrote: > > On Tue, 2017-03-28 at 09:32 +0100, Marc Zyngier wrote: > > > I'm a bit concerned by this. It means that you can't even mask an > > > interrupt. Is that really wh

Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

On Tue, 2017-03-28 at 09:32 +0100, Marc Zyngier wrote: > I'm a bit concerned by this. It means that you can't even mask an > interrupt. Is that really what you intend to do? Or all that the HW can > do? If you cannot mask an interrupt, you're at the mercy of a screaming > device... This is not

Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

On Tue, 2017-03-28 at 09:32 +0100, Marc Zyngier wrote: > I'm a bit concerned by this. It means that you can't even mask an > interrupt. Is that really what you intend to do? Or all that the HW can > do? If you cannot mask an interrupt, you're at the mercy of a screaming > device... This is not

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > +   /* Set AC Timing */ > +   if (clk_freq / 1000 > 1000) { > +   aspeed_i2c_write(bus, aspeed_i2c_read(bus, > + > ASPEED_I2C_FUN_CTRL_REG) | > + 

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > +   /* Set AC Timing */ > +   if (clk_freq / 1000 > 1000) { > +   aspeed_i2c_write(bus, aspeed_i2c_read(bus, > + > ASPEED_I2C_FUN_CTRL_REG) | > + 

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > +/* 0x04 : I2CD Clock and AC Timing Control Register #1 */ > +#define ASPEED_I2CD_TIME_SCL_HIGH_SHIFT16 > +#define ASPEED_I2CD_TIME_SCL_HIGH_MASK GENMASK(19, 16) > +#define

Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > +/* 0x04 : I2CD Clock and AC Timing Control Register #1 */ > +#define ASPEED_I2CD_TIME_SCL_HIGH_SHIFT16 > +#define ASPEED_I2CD_TIME_SCL_HIGH_MASK GENMASK(19, 16) > +#define

Re: [PATCH v6 3/5] i2c: aspeed: added documentation for Aspeed I2C driver

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C busses. > > Signed-off-by: Brendan Higgins > + i2c0: i2c-bus@40 { > + #address-cells = <1>; > + #size-cells = <0>; > +

Re: [PATCH v6 3/5] i2c: aspeed: added documentation for Aspeed I2C driver

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C busses. > > Signed-off-by: Brendan Higgins > + i2c0: i2c-bus@40 { > + #address-cells = <1>; > + #size-cells = <0>; > + #interrupt-cells =

Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

; > Signed-off-by: Brendan Higgins <brendanhigg...@google.com> I do think as I said earlier that is' a tiny bit overkill, I do worry about the overhead of the added layer of indirections on a 400Mhz ARMv9 (AST2400) core but otherwise: Acked-by: Benjamin Herrenschmidt <b...@kernel.crashin

Re: [PATCH v6 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

; > Signed-off-by: Brendan Higgins I do think as I said earlier that is' a tiny bit overkill, I do worry about the overhead of the added layer of indirections on a 400Mhz ARMv9 (AST2400) core but otherwise: Acked-by: Benjamin Herrenschmidt > --- > Added in v6: >   - Pulled "aspeed_i2c_

Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C Interrupt > Controller. It's a little bit overkill ... It's not so much an interrupt controller than a single "summary" register that reflects the state of the interrupts of all the

Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller

On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C Interrupt > Controller. It's a little bit overkill ... It's not so much an interrupt controller than a single "summary" register that reflects the state of the interrupts of all the

Re: linux-next: build failure after merge of the char-misc tree

On Mon, 2017-03-20 at 13:23 +0100, Arnd Bergmann wrote: > On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell > wrote: > > Hi all, > > > > After merging the char-misc tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > >

Re: linux-next: build failure after merge of the char-misc tree

On Mon, 2017-03-20 at 13:23 +0100, Arnd Bergmann wrote: > On Mon, Mar 20, 2017 at 3:44 AM, Stephen Rothwell > wrote: > > Hi all, > > > > After merging the char-misc tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > drivers/misc/aspeed-lpc-ctrl.c: In function

Re: [RFC] powerpc: handle simultanneous interrupts at once

On Fri, 2017-03-10 at 12:11 +0100, Christophe Leroy wrote: > It often happens to have simultanneous interrupts, for instance > when having double Ethernet attachment. With the current > implementation, we suffer the cost of kernel entry/exit for each > interrupt. > > This patch introduces a loop

Re: [RFC] powerpc: handle simultanneous interrupts at once

On Fri, 2017-03-10 at 12:11 +0100, Christophe Leroy wrote: > It often happens to have simultanneous interrupts, for instance > when having double Ethernet attachment. With the current > implementation, we suffer the cost of kernel entry/exit for each > interrupt. > > This patch introduces a loop

Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

On Thu, 2017-03-09 at 16:22 -0600, Larry Finger wrote: > > > Attached is a patch that fixes the crash. At the moment, it has my s- > o-b, but I  > do not feel it right to claim authorship. My role should be a  > Reported-and-tested-by. Please advise. Nah, you wrote the patch, your s-o-b is fine

Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

On Thu, 2017-03-09 at 16:22 -0600, Larry Finger wrote: > > > Attached is a patch that fixes the crash. At the moment, it has my s- > o-b, but I  > do not feel it right to claim authorship. My role should be a  > Reported-and-tested-by. Please advise. Nah, you wrote the patch, your s-o-b is fine

Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev

On Tue, 2017-03-07 at 05:52 +0100, Greg Kroah-Hartman wrote: > On Mon, Mar 06, 2017 at 04:35:48PM -0800, Bart Van Assche wrote: > > The dma mapping operations of several architectures and also of > > several I/O MMU implementations need to translate a struct > > device pointer into a struct

Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev

On Tue, 2017-03-07 at 05:52 +0100, Greg Kroah-Hartman wrote: > On Mon, Mar 06, 2017 at 04:35:48PM -0800, Bart Van Assche wrote: > > The dma mapping operations of several architectures and also of > > several I/O MMU implementations need to translate a struct > > device pointer into a struct

Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

On Mon, 2017-03-06 at 13:46 -0600, Larry Finger wrote: > I was able to create a PPC emulation with debian-8.7.1-powerpc-CD-1.iso  > > following the instructions in https://gmplib.org/~tege/qemu.html. My only  > problem was that "-net tap" fails and I did not find any way to get > networking  >

Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

On Mon, 2017-03-06 at 13:46 -0600, Larry Finger wrote: > I was able to create a PPC emulation with debian-8.7.1-powerpc-CD-1.iso  > > following the instructions in https://gmplib.org/~tege/qemu.html. My only  > problem was that "-net tap" fails and I did not find any way to get > networking  >

Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

On Wed, 2017-03-01 at 21:26 -0600, Larry Finger wrote: > My Powerbook G4 Aluminum generates a fatal splat early in the boot process, > just  > after identifying the driver for the disk. Unfortunately, it turns off almost  > immediately, thus I cannot report the message. After this bug has been  >

Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

On Wed, 2017-03-01 at 21:26 -0600, Larry Finger wrote: > My Powerbook G4 Aluminum generates a fatal splat early in the boot process, > just  > after identifying the driver for the disk. Unfortunately, it turns off almost  > immediately, thus I cannot report the message. After this bug has been  >

Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140

On Mon, 2017-02-20 at 14:04 -0800, Thomas Gleixner wrote: > > HOWEVER. Looking at current upstream code I don't understand the error, > > the DEBUG_SHIRQ code is calling the driver's handler not the flow > > handler so it shouldn't be called handle_fasteoi_irq or am I missing > > something ? > >

Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140

On Mon, 2017-02-20 at 14:04 -0800, Thomas Gleixner wrote: > > HOWEVER. Looking at current upstream code I don't understand the error, > > the DEBUG_SHIRQ code is calling the driver's handler not the flow > > handler so it shouldn't be called handle_fasteoi_irq or am I missing > > something ? > >

Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140

On Mon, 2017-02-20 at 21:55 +1100, Michael Ellerman wrote: > But when we're called for CONFIG_DEBUG_SHIRQ get_irq() is not called, > precisely because we're faking an interrupt. > > I'm not sure if there's a good way to fix it :/ In the irq_replay path we have code to adjust the CPPR stack. We

Re: [next-20170217] WARN @/arch/powerpc/include/asm/xics.h:124 .icp_hv_eoi+0x40/0x140

On Mon, 2017-02-20 at 21:55 +1100, Michael Ellerman wrote: > But when we're called for CONFIG_DEBUG_SHIRQ get_irq() is not called, > precisely because we're faking an interrupt. > > I'm not sure if there's a good way to fix it :/ In the irq_replay path we have code to adjust the CPPR stack. We

Re: [PATCH v6] drivers/misc: Add Aspeed LPC control driver

rather than simply > moving 'zero' upwards. This is caused by the nature of HICR8 being a > mask and the way host LPC addresses are translated. > > Signed-off-by: Cyril Bur <cyril...@gmail.com> Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> Greg, quick Q for

Re: [PATCH v6] drivers/misc: Add Aspeed LPC control driver

rather than simply > moving 'zero' upwards. This is caused by the nature of HICR8 being a > mask and the way host LPC addresses are translated. > > Signed-off-by: Cyril Bur Reviewed-by: Benjamin Herrenschmidt Greg, quick Q for you: We will need to also add a mechanism to poke at a fe

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

On Wed, 2017-02-08 at 10:42 +1100, Cyril Bur wrote: > +struct aspeed_lpc_ctrl_mapping { > +   __u8window_type; > +   __u8window_id; > +   __u16   flags; > +   __u32   addr; > +   __u32   offset; > +   __u32   size; > +}; > + Please document the fields Cheers, Ben.

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

On Wed, 2017-02-08 at 10:42 +1100, Cyril Bur wrote: > +struct aspeed_lpc_ctrl_mapping { > +   __u8window_type; > +   __u8window_id; > +   __u16   flags; > +   __u32   addr; > +   __u32   offset; > +   __u32   size; > +}; > + Please document the fields Cheers, Ben.

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

On Fri, 2017-02-10 at 15:30 +0100, Greg KH wrote: > > Without some other reviewed-by: or at least tested-by lines here, I'm > not going to take this.  Go poke your fellow ppc people to do some > work > here, it shouldn't be up to me to do it for them :( We are reviewing it ;-) We asked for a

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

On Fri, 2017-02-10 at 15:30 +0100, Greg KH wrote: > > Without some other reviewed-by: or at least tested-by lines here, I'm > not going to take this.  Go poke your fellow ppc people to do some > work > here, it shouldn't be up to me to do it for them :( We are reviewing it ;-) We asked for a

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

On Wed, 2017-02-08 at 02:06 +0200, Andy Shevchenko wrote: > > On Wed, Feb 8, 2017 at 1:42 AM, Cyril Bur wrote: > > In order to manage server systems, there is typically another processor > > known as a BMC (Baseboard Management Controller) which is responsible > > for powering

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

On Wed, 2017-02-08 at 02:06 +0200, Andy Shevchenko wrote: > > On Wed, Feb 8, 2017 at 1:42 AM, Cyril Bur wrote: > > In order to manage server systems, there is typically another processor > > known as a BMC (Baseboard Management Controller) which is responsible > > for powering the server and

Re: ibmvtpm byteswapping inconsistency

On Fri, 2017-01-27 at 12:32 -0800, Tyrel Datwyler wrote: > Its possible being the end of the week I'm just a little dense, but > wouldn't be64_to_cpu() imply that we are byte-swapping something that is > already, or supposedly already, in BE format to cpu endianness? Which on > a BE cpu I would

Re: ibmvtpm byteswapping inconsistency

On Fri, 2017-01-27 at 12:32 -0800, Tyrel Datwyler wrote: > Its possible being the end of the week I'm just a little dense, but > wouldn't be64_to_cpu() imply that we are byte-swapping something that is > already, or supposedly already, in BE format to cpu endianness? Which on > a BE cpu I would

Re: ibmvtpm byteswapping inconsistency

On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote: > > The problem is that we are packing an in-memory structure into 2 > > registers and it's expected that this structure is laid out in the > > registers as if it had been loaded by a BE CPU. > > This is only the case if the cpu is BE. If

Re: ibmvtpm byteswapping inconsistency

On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote: > > The problem is that we are packing an in-memory structure into 2 > > registers and it's expected that this structure is laid out in the > > registers as if it had been loaded by a BE CPU. > > This is only the case if the cpu is BE. If

Re: ibmvtpm byteswapping inconsistency

On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote: > On 01/26/2017 12:22 PM, Michal Suchánek wrote: > > Hello, > > > > building ibmvtpm I noticed gcc warning complaining that second word > > of > > struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized. > > > > The structure is defined

Re: ibmvtpm byteswapping inconsistency

On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote: > On 01/26/2017 12:22 PM, Michal Suchánek wrote: > > Hello, > > > > building ibmvtpm I noticed gcc warning complaining that second word > > of > > struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized. > > > > The structure is defined

Re: [PATCH linux v3 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations

On Sat, 2017-01-21 at 10:11 -0800, Guenter Roeck wrote: > > +int occ_i2c_getscom(void *bus, u32 address, u64 *data) > > +{ > > + ssize_t rc; > > + u64 buf; > > + struct i2c_client *client = bus; > > + > > + rc = i2c_master_send(client, (const char *), > > sizeof(u32)); > > + if

Re: [PATCH linux v3 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations

On Sat, 2017-01-21 at 10:11 -0800, Guenter Roeck wrote: > > +int occ_i2c_getscom(void *bus, u32 address, u64 *data) > > +{ > > + ssize_t rc; > > + u64 buf; > > + struct i2c_client *client = bus; > > + > > + rc = i2c_master_send(client, (const char *), > > sizeof(u32)); > > + if

Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface

On Mon, 2017-01-09 at 10:22 +1030, Andrew Jeffery wrote: > Alternatively, in the style of your first para, we could push the > host > CPU state management into the kernel and expose a boot/reboot/power- > off  > API to userspace. That would give us a place to hook calls for > configuring and

Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface

On Mon, 2017-01-09 at 10:22 +1030, Andrew Jeffery wrote: > Alternatively, in the style of your first para, we could push the > host > CPU state management into the kernel and expose a boot/reboot/power- > off  > API to userspace. That would give us a place to hook calls for > configuring and

Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface

On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote: > > Instead of the "online" attribute, what do you think about using the > > "bind"/"unbind" API to probe the device from user space once the system > > is powered on? All the hwmon registration would take place in the probe > > function, it

Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface

On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote: > > Instead of the "online" attribute, what do you think about using the > > "bind"/"unbind" API to probe the device from user space once the system > > is powered on? All the hwmon registration would take place in the probe > > function, it

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote: > > As for multi userspace client, well, swapping an mmap between HW and > > memory backing store is a somewhat solved problem already. > > Hm, I didn't know that, but then all existing drm drivers have fairly > simplistic fbdev mmap

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote: > > As for multi userspace client, well, swapping an mmap between HW and > > memory backing store is a somewhat solved problem already. > > Hm, I didn't know that, but then all existing drm drivers have fairly > simplistic fbdev mmap

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote: > Despite all of this I still see no reason why a driver could not > expose the static, real frambuffers via private ioctls. You can get > all your fancy acceleration that way. Then fix user-space to use this > API. If enough drivers end up

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote: > Despite all of this I still see no reason why a driver could not > expose the static, real frambuffers via private ioctls. You can get > all your fancy acceleration that way. Then fix user-space to use this > API. If enough drivers end up

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > And since I failed to make this clear: There's not really a > fundamental > reason ast and cirrus use the dirty tracking for fbdev. It's just that > doing it that way was the fastest way to get those servers booting, and > ever since no

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > And since I failed to make this clear: There's not really a > fundamental > reason ast and cirrus use the dirty tracking for fbdev. It's just that > doing it that way was the fastest way to get those servers booting, and > ever since no

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote: > Yeah if you have discrete vram then your dumb display driver isn't all > that pretty. We essentially just have the few drivers Dave hacked up to be > able to boot some servers. And there's definitely lots of room for more > shared code for

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote: > Yeah if you have discrete vram then your dumb display driver isn't all > that pretty. We essentially just have the few drivers Dave hacked up to be > able to boot some servers. And there's definitely lots of room for more > shared code for

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote: > What are people using fbcon for that needs acceleration, this is where I get > a bit lost. > > It's a console, if you aren't sshing into the machine. > > It's main purpose should just be for gathering oopses and you've a lot better > chance

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote: > What are people using fbcon for that needs acceleration, this is where I get > a bit lost. > > It's a console, if you aren't sshing into the machine. > > It's main purpose should just be for gathering oopses and you've a lot better > chance

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote: > > With drmfb you basically have to shadow everything into memory & copy > > over everything, and locks you out of simple 2D accel. For a simple text > > console the result is orders of magnitude slower and memory hungry than > > a simple

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote: > > With drmfb you basically have to shadow everything into memory & copy > > over everything, and locks you out of simple 2D accel. For a simple text > > console the result is orders of magnitude slower and memory hungry than > > a simple

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote: > As I mentioned earlier, probably 1 or 2 years ago, Dave made the > argument that shadowing through memory was necessary and precluded 2D > accel, though I don't fully remember the root of the argument. If that &g

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote: > As I mentioned earlier, probably 1 or 2 years ago, Dave made the > argument that shadowing through memory was necessary and precluded 2D > accel, though I don't fully remember the root of the argument. If that &g

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote: > > From memory, David claimed you cannot directly work on the fb with a > > "proper" > > DRM driver. Maybe I misunderstood but then the DRM shines by its complete > absence of useful documentation

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote: > > From memory, David claimed you cannot directly work on the fb with a > > "proper" > > DRM driver. Maybe I misunderstood but then the DRM shines by its complete > absence of useful documentation

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote: > Yeah, small drivers like these we have piles now, things exploded a lot > after atomic landed two years ago. And they seem to shrink with every > release a bit more (since lots more drivers gives you lots more insight > into what other

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote: > Yeah, small drivers like these we have piles now, things exploded a lot > after atomic landed two years ago. And they seem to shrink with every > release a bit more (since lots more drivers gives you lots more insight > into what other

<    5   6   7   8   9   10   11   12   13   14   >