ber 'irq'
not described in 'msgdma_device'
drivers/dma/altera-msgdma.c:197: warning: Function parameter or member 'csr'
not described in 'msgdma_device'
drivers/dma/altera-msgdma.c:197: warning: Function parameter or member 'desc'
not described in &#
US read in mtk_handle_irq()
Is that read necessary to work properly?
No, its not needed. This read must have "slipped in" from some earlier
patch versions and I forgot to remove it later. Thanks for catching it.
Reviewed-by: Stefan Roese
Thanks,
Stefan
Hi Geert,
On 24.06.19 17:35, Geert Uytterhoeven wrote:
On Mon, Jun 24, 2019 at 5:29 PM Stefan Roese wrote:
On 24.06.19 10:42, Geert Uytterhoeven wrote:
On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese wrote:
This patch adds a check for the GPIOs property existence, before the
GPIO is requested
On 24.06.19 10:42, Geert Uytterhoeven wrote:
CC gpio
This is now commit d99482673f950817 ("serial: mctrl_gpio: Check if GPIO
property exisits before requesting it") in tty-next.
On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese wrote:
This patch adds a check for the GPIOs property
s" is available.
Use MSR / MCR <-> TIOCM wrapper functions.
Signed-off-by: Yegor Yefremov
Signed-off-by: Stefan Roese
Reviewed-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Tested-by: Yegor Yefremov
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed
s" is available.
Use MSR / MCR <-> TIOCM wrapper functions.
Signed-off-by: Yegor Yefremov
Signed-off-by: Stefan Roese
Reviewed-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Tested-by: Yegor Yefremov
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
This patch adds wrapper functions to convert MSR <-> TIOCM and also
MCR <-> TIOCM. These functions are used now in serial8250_do_set_mctrl()
and serial8250_do_get_mctrl().
Signed-off-by: Stefan Roese
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Reviewed-by: Mik
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed
s" is available.
Use MSR / MCR <-> TIOCM wrapper functions.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Reviewed-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Ye
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed
This patch adds wrapper functions to convert MSR <-> TIOCM and also
MCR <-> TIOCM. These functions are used now in serial8250_do_set_mctrl()
and serial8250_do_get_mctrl().
Signed-off-by: Stefan Roese
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Reviewed-by: Mika We
On 17.06.19 11:51, Yegor Yefremov wrote:
@@ -1944,11 +1948,15 @@ unsigned int serial8250_do_get_mctrl(struct uart_port
*port)
{
struct uart_8250_port *up = up_to_u8250p(port);
unsigned int status;
+ unsigned int val = 0;
serial8250_rpm_get(up);
sta
On 14.06.19 11:04, Yegor Yefremov wrote:
On Thu, Jun 13, 2019 at 7:08 PM Andy Shevchenko
wrote:
On Thu, Jun 13, 2019 at 05:45:40PM +0200, Stefan Roese wrote:
This patch adds a check for the GPIOs property existence, before the
GPIO is requested. This fixes an issue seen when the 8250
On 12.06.19 11:16, Andy Shevchenko wrote:
On Wed, Jun 12, 2019 at 10:13:05AM +0200, Stefan Roese wrote:
On 11.06.19 16:48, Andy Shevchenko wrote:
On Tue, Jun 11, 2019 at 04:02:54PM +0200, Stefan Roese wrote:
On 11.06.19 14:44, Andy Shevchenko wrote:
On Tue, Jun 11, 2019 at 12:56:03PM +0200
s" is available.
Use MSR / MCR <-> TIOCM wrapper functions.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
Cc: Greg Kroah-Hartman
---
v6:
- Use newly
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed-off-b
This patch adds wrapper functions to convert MSR <-> TIOCM and also
MCR <-> TIOCM. These functions are used now in serial8250_do_set_mctrl()
and serial8250_do_get_mctrl().
Signed-off-by: Stefan Roese
Suggested-by: Andy Shevchenko
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Yegor
On 11.06.19 16:48, Andy Shevchenko wrote:
On Tue, Jun 11, 2019 at 04:02:54PM +0200, Stefan Roese wrote:
On 11.06.19 14:44, Andy Shevchenko wrote:
On Tue, Jun 11, 2019 at 12:56:03PM +0200, Stefan Roese wrote:
static inline void serial8250_out_MCR(struct uart_8250_port *up, int value
On 11.06.19 14:44, Andy Shevchenko wrote:
On Tue, Jun 11, 2019 at 12:56:03PM +0200, Stefan Roese wrote:
From: Yegor Yefremov
This patch permits the usage for GPIOs to control
the CTS/RTS/DTR/DSR/DCD/RI signals.
static inline void serial8250_out_MCR(struct uart_8250_port *up, int value
s" is available.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Reviewed-by: Mika Westerberg
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
Cc: Greg Kroah-Hartman
---
v5:
- Dropped a few "if (up->gpio
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed-off-b
On 04.06.19 18:52, Andy Shevchenko wrote:
On Mon, Jun 03, 2019 at 10:33:32AM +0200, Stefan Roese wrote:
From: Yegor Yefremov
This patch permits the usage for GPIOs to control
the CTS/RTS/DTR/DSR/DCD/RI signals.
+ if (up->gpios) {
+ mctrl_gpio_set(up->
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed-off-b
s" is available.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Reviewed-by: Mika Westerberg
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
Cc: Greg Kroah-Hartman
Cc: Johan Hovold
---
v4:
- Added Mika's
On 29.05.19 15:44, Johan Hovold wrote:
On Mon, May 27, 2019 at 01:18:04PM +0200, Stefan Roese wrote:
This patch adds a check for the GPIOs property existence, before the
GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
support is added (2nd patch in this patch series) on x86
s" is available.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
Cc: Greg Kroah-Hartman
---
v3:
- Only call mctrl_gpio_init(), if the device has no ACPI companion d
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed-off
On 24.05.19 15:46, Andy Shevchenko wrote:
On Fri, May 24, 2019 at 01:29:34PM +0200, Stefan Roese wrote:
On 24.05.19 13:11, Andy Shevchenko wrote:
On Fri, May 24, 2019 at 1:21 PM Mika Westerberg
wrote:
On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote:
This patch adds a check for
On 24.05.19 13:11, Andy Shevchenko wrote:
On Fri, May 24, 2019 at 1:21 PM Mika Westerberg
wrote:
On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote:
This patch adds a check for the GPIOs property existence, before the
GPIO is requested. This fixes an issue seen when the 8250
From: Yegor Yefremov
This patch permits the usage for GPIOs to control
the CTS/RTS/DTR/DSR/DCD/RI signals.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
Cc: Greg
existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed-off
From: Yegor Yefremov
This patch permits the usage for GPIOs to control
the CTS/RTS/DTR/DSR/DCD/RI signals.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Stefan Roese
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Giulio Benetti
Cc: Yegor Yefremov
Cc: Greg
/357
Signed-off-by: Stefan Roese
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Yegor Yefremov
Cc: Greg Kroah-Hartman
Cc: Giulio Benetti
---
drivers/tty/serial/serial_mctrl_gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/tty/serial/serial_mctrl_gpio.c
b/drivers/tty
small for larger chips.
Tested with Spansion S29GL01GS11TFI flash device.
Signed-off-by: Chris Packham
This hardcoded limit always annoyed me at that time, so thanks for
"fixing" this:
Reviewed-by: Stefan Roese
Thanks,
Stefan
On 14.03.19 14:14, Matthias Brugger wrote:
On 14/03/2019 12:37, Armando Miraglia wrote:
Absolutely!
Please don't top post :)
Cheers,
A.
On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote:
[...]
Would it be possible for you to wait a bit with this minor cleanup?
As I'm p
Hi Armando,
On 14.03.19 12:13, Armando Miraglia wrote:
My answers are in-line below. BTW bare with me as this is my attempt to get my
feet wet in how to contribute to the linux kernel for my own pleasure and
interest :)
On Wed, Mar 13, 2019 at 03:34:54PM +0300, Dan Carpenter wrote:
On Wed, Mar
On 13.03.19 17:46, Matthias Brugger wrote:
On 13/03/2019 17:34, Chuanhong Guo wrote:
Hi!
On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger wrote:
On 13/03/2019 13:24, Armando Miraglia wrote:
[...]
Apart from fixing styling issues it would be usefull to see if we can add
support for mt7621
{
status = -ENOMEM;
goto out_rel_axi_clk;
}
- spi->child[cs].direct_access.size = PAGE_SIZE;
+ dir_acc->size = PAGE_SIZE;
dev_info(&pdev->dev, "CS%d configured for direct access\n", cs);
}
Reviewed-by: Stefan Roese
Thanks,
Stefan
On 19.01.2018 12:10, Oza Pawandeep wrote:
> Clients such as pciehp, dpc are using pcie_wait_link_active, which waits
> till the link becomes active or inactive.
>
> Made generic function and moved it to drivers/pci/pci.c
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/hotplug/pcie
On 25.08.2017 12:40, Mika Westerberg wrote:
On Fri, Aug 25, 2017 at 01:12:51AM -0700, Bin Meng wrote:
The Intel SPI-NOR driver is dependent on LPC_ICH to get the platform
data. Select it in the Kconfig.
Signed-off-by: Bin Meng
---
drivers/mtd/spi-nor/Kconfig | 1 +
1 file changed, 1 insert
into the BAR specified by the MSI-X controller.
Signed-off-by: Stefan Roese
Reviewed-by: Thomas Petazzoni
Cc: Marc Zyngier
Cc: Jason Cooper
Cc: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: Gregory CLEMENT
---
v2:
- Added Reviewed-by tag from Thomas
- Added usual irqchip maintainers
drivers/irqchip
s
Cc: Sebastian Hesselbarth
Cc: Simon Baatz
Cc: Simon Guinot
Cc: Stefan Roese
For the complete patch series:
Acked-by: Stefan Roese
Thanks,
Stefan
("clocksource/drivers/time-armada-370-xp: Convert init function
to return error")
Signed-off-by: Gregory CLEMENT
Tested-by: Stefan Roese
Thanks,
Stefan
On 18.07.2016 22:20, Brian Norris wrote:
On Tue, Jul 19, 2016 at 03:43:17AM +0800, kbuild test robot wrote:
tree: git://git.infradead.org/linux-mtd-next.git master
head: f78921b9020c510ed222a6c2402e2aa126432415
commit: 140623410536905fa6ab737b625decfde6c64a72 [30/33] mtd: spi-nor: Add
drive
On 02.02.2015 17:06, Greg Kroah-Hartman wrote:
On Mon, Feb 02, 2015 at 04:43:14PM +0100, Stefan Roese wrote:
On 21.02.2014 17:18, Michal Simek wrote:
On 02/21/2014 05:12 PM, Felipe Balbi wrote:
On Fri, Feb 21, 2014 at 05:04:26PM +0100, Michal Simek wrote:
On 02/21/2014 05:04 PM, Greg Kroah
On 21.02.2014 17:18, Michal Simek wrote:
On 02/21/2014 05:12 PM, Felipe Balbi wrote:
On Fri, Feb 21, 2014 at 05:04:26PM +0100, Michal Simek wrote:
On 02/21/2014 05:04 PM, Greg Kroah-Hartman wrote:
On Fri, Feb 21, 2014 at 07:38:16AM +0100, Michal Simek wrote:
BTW: u-boot started to use SPDX-Li
On 04.07.2014 15:11, Jean-Michel Hautbois wrote:
2014-07-03 18:12 GMT+02:00 Joe Perches :
trivial:
diff --git a/drivers/misc/lattice-ecp3-config.c
[]
@@ -165,8 +165,8 @@ static void firmware_load(const struct firmware
*fw, void *context)
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = sp
Hi Jean-Michel,
On 04.07.2014 10:24, Jean-Michel Hautbois wrote:
I noticed you (Stefan) are using request_firmware_nowait() call. This
means user needs to explicitly call it using
$ echo 1 > /sys/class/firmware/lattice-ecp3.0/loading
$ cat lattice-ecp3.bit > /sys/class/firmware/lattice-ecp3.0/d
xbuf, rx_len);
> -dev_dbg(&spi->dev, "FPGA Status=%08x\n", *(u32 *)&rxbuf[4]);
> -status = *(u32 *)&rxbuf[4];
> +dev_dbg(&spi->dev, "FPGA Status=%08x\n", be32_to_cpu(*(u32 *)&rxbuf[4]));
> +status = be32_to_cpu(*(u32 *)&rxbuf[4]);
On 03.07.2014 14:37, Jean-Michel Hautbois wrote:
I have a board, with a Freescale i.MX6 chip and a ECP3-35 FPGA on SPI.
I tried to load the firmware using the lattice-ecp3-config driver, but
it fails with this error :
lattice-ecp3 spi32766.3: FPGA bitstream configuration driver registered
lattic
!
>
> The correct assignment is present as well, so we just need
> to remove the wrong one.
>
> Signed-off-by: Arnd Bergmann
> Cc: Stefan Roese
> Cc: Maxime Ripard
> Cc: Richard Genoud
Thanks for fixing this:
Acked-by: Stefan Roese
Thanks,
Stefan
--
To unsubscribe
2 spi1.0: FPGA successfully refreshed!
Signed-off-by: Stefan Roese
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
I know that the re-configuration of the pins (SPI vs GPIO) as described
above could/should be done in a "clean way" via pinctrl. But currently there
is no pinctrl support for
Hi Florian,
On 24.03.2013 20:03, Florian Fainelli wrote:
> Your phylib implementation looks good now, just some minor comments below:
Thanks for the review. I'll try to address your new comments in a few
days (currently swamped).
Thanks,
Stefan
--
To unsubscribe from this list: send the line "u
Hi,
On 02/02/2013 04:38 AM, Stephen Rothwell wrote:
> Hi Artem,
>
> After merging the l2-mtd tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> In file included from drivers/mtd/chips/cfi_cmdset_0002.c:36:0:
> include/linux/of_platform.h:107:13: warning: 'struct
gt; /sys/class/firmware/spi0.0/loading
leads to these messages:
lattice-ecp3 spi0.0: FPGA Lattice ECP3-35 detected
lattice-ecp3 spi0.0: Configuring the FPGA...
lattice-ecp3 spi0.0: FPGA succesfully configured!
Signed-off-by: Stefan Roese
Acked-by: Ming Lei
Reviewed-by: Grant Likely
Cc: Arnd Berg
On 11/26/2012 02:35 AM, Ming Lei wrote:
> On Fri, Nov 23, 2012 at 3:58 PM, Stefan Roese wrote:
>> This patch adds support for bitstream configuration (programming /
>> loading) of the Lattice ECP3 FPGA's via the SPI bus.
>>
>> Here an example on my custom MPC
ta
$ echo 0 > /sys/class/firmware/lattice-ecp3.0/loading
leads to these messages:
lattice-ecp3 spi32766.0: FPGA Lattice ECP3-35 detected
lattice-ecp3 spi32766.0: Configuring the FPGA...
lattice-ecp3 spi32766.0: FPGA succesfully configured!
Signed-off-by: Stefan Roese
Cc: Ming Lei
---
arch/p
On 08/24/2012 01:35 PM, Artem Bityutskiy wrote:
>> @@ -1073,21 +1043,13 @@ static int __devexit spear_smi_remove(struct
>> platform_device *pdev)
>> ret = mtd_device_unregister(&flash->mtd);
>> if (ret)
>> dev_err(&pdev->dev, "error removing mtd\n");
> .devinit.text:stmmac_probe_config_dt()
> The function stmmac_pltfr_probe() references
> the function __devinit stmmac_probe_config_dt().
> This is often because stmmac_pltfr_probe lacks a __devinit
> annotation or the annotation of stmmac_probe_config_dt is wrong.
>
> Sig
/
> @@
> expression x,e;
> statement S1,S2;
> @@
>
> *x = dev_get_platdata(...)
> ... when != x = e
> *if (x < 0) S1 else S2
> //
>
> Signed-off-by: Julia Lawall
Acked-by: Stefan Roese
Thanks,
Stefan
--
To unsubscribe from this list: send the line &
On Monday 10 December 2007, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes it, along wi
On Thursday 24 January 2008, Josh Boyer wrote:
> On Wed, 23 Jan 2008 23:37:33 +0100
>
> Roel Kluin <[EMAIL PROTECTED]> wrote:
> > logical/bitand typo
> >
> > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> > ---
> > diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
> > index ebf9e21..d
I'm seeing this error message when booting an recent arch/ppc kernel on
4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
rootfs still works fine, but this message kind of makes me "nervous".
This is not seen on 4xx arch/powerpc platforms. Here the bootlog:
Linux version 2.6.24
On Thursday 20 December 2007, David Gibson wrote:
> On Wed, Dec 19, 2007 at 11:41:44PM -0500, Jon Smirl wrote:
> > Convert MPC i2c driver from being a platform_driver to an open
> > firmware version. Error returns were improved. Routine names were
> > changed from fsl_ to mpc_ to make them match th
[added linuxppc-dev since it's PPC relevant too]
On Tuesday 30 October 2007, Josh Boyer wrote:
> On Mon, 29 Oct 2007 15:45:03 -0400
>
> [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> > On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> > > I'm tryin
I'm trying to implement support for a board specific watchdog on a PPC440EPx
board with a very short timeout. In this case, the watchdog has to
be "kicked" at least every 100ms, even while booting and the real watchdog
driver not running yet. While looking for trigger places in the kernel
sourc
On Monday 07 May 2007, Grant Likely wrote:
> Tested on Xilinx Virtex ppc405, Katmai 440SPe, and Microblaze
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
Best regards,
Stefan
-
To unsubscribe from this list: send the line &quo
On Friday 04 May 2007 10:24, Robert Schwebel wrote:
> On Tue, May 01, 2007 at 02:35:44PM +0200, Stefan Roese wrote:
> > I'm in the stage of integrating some ADC and DAC drivers for the AMCC
> > 405EZ PPC and looking for the correct location to place these drivers
> > in
On Wednesday 02 May 2007 21:11, Russell King wrote:
> > > Is there a maintainer for this "drivers/mfd" directory?
> >
> > rmk
>
> I wouldn't go that far. There's no real infrastructure there
> to maintain, so I'd actually say that the directory was
> maintainerless. However, I'll own up to the UC
On Tuesday 01 May 2007 23:03, Guennadi Liakhovetski wrote:
> On Tue, 1 May 2007, Stefan Roese wrote:
> > I'm in the stage of integrating some ADC and DAC drivers for the AMCC
> > 405EZ PPC and looking for the correct location to place these drivers in
> > the Linux so
Hi all,
I'm in the stage of integrating some ADC and DAC drivers for the AMCC 405EZ
PPC and looking for the correct location to place these drivers in the Linux
source tree. The drivers are basically character-drivers, so my first thought
is to put them in "drivers/char/adc/foo.c" or "drivers/c
72 matches
Mail list logo
