for staging integration */
> #define GPIO_VBUS 0 /* GPIO_P153 on KZM9D */
> #define INT_VBUS 0 /* IRQ for GPIO_P153 */
> -struct gpio_desc *vbus_gpio;
> -int vbus_irq;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In pe
Hi Carlis,
On Thu, Jan 28, 2021 at 12:03 PM carlis wrote:
> On Thu, 28 Jan 2021 10:42:54 +0100
> Geert Uytterhoeven wrote:
> > On Thu, Jan 28, 2021 at 7:53 AM Kari Argillander
> > wrote:
> > > On Thu, Jan 28, 2021 at 09:42:58AM +0800, carlis wrote:
> > >
)
> > return PTR_ERR(par->gpio.te);
>
> Not exactly. I'm suggesting something like this.
>
> if (IS_ERR(par->gpio.te) == -EPROBE_DEFER) {
> return -EPROBE_DEFER;
>
> if (IS_ERR(par->gpio.te))
> par-gpio.te = NULL;
>
> This like
gt; + } else {
> + dev_info(par->info->device, "%s:%d, TE gpio not specified\n",
> +__func__, __LINE__);
> + }
> /* turn off sleep mode */
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> mdelay(120
"TE_GPIO", par);
> + if (rc) {
> + dev_err(par->info->device, "TE request_irq
> failed.\n");
> + devm_gpiod_put(dev, par->gpio.te);
No need t
o("TE request_irq completion.\n");
> + }
> + } else {
> + pr_info("%s:%d, TE gpio not specified\n",
> + __func__, __LINE__);
> + }
> /* turn off sleep mode */
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MOD
t; but this also fixes the crash...
While this fixes the crash, it does not propagate the error condition
(which may be -EPROBE_DEFER) upstream.
Same for devm_request_irq().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@l
e declare it in native byte order and we reorder just
> + // before/after send/receive it (see bh.c).
> + u16len;
While there's a small penalty associated with always doing the conversion
on big-endian platforms, it will probably be lost in the noise anyway.
Gr{oetje,eet
Hi Alex,
On Thu, Apr 2, 2020 at 5:03 PM Alex Riesen wrote:
> Geert Uytterhoeven, Mon, Mar 30, 2020 10:32:47 +0200:
> > On Thu, Mar 26, 2020 at 11:55 AM Alex Riesen
> > wrote:
> > > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > +++ b/arc
2s>;
> +
> + dai-tdm-slot-num = <8>;
> + dai-tdm-slot-width = <32>;
> + dai-format = "left_j";
> + mclk-fs = <256>;
> + bitclock-master = <_i2s>;
> +
Hi Alex,
On Mon, Mar 23, 2020 at 9:41 AM Alex Riesen
wrote:
> Geert Uytterhoeven, Mon, Mar 23, 2020 09:34:45 +0100:
> > On Fri, Mar 20, 2020 at 5:43 PM Alex Riesen
> > wrote:
> > > As all known variants of the Salvator board have the HDMI decoder
> > > chip (t
t; For the same reason, the CLK_C clock line and I2C configuration (similar
> to the ak4613, on the same interface) are added into the common file.
>
> Signed-off-by: Alexander Riesen
> Reviewed-by: Geert Uytterhoeven
Did I provide a Reviewed-by?
> The driver provides only MCLK
Hi Alex,
On Fri, Mar 20, 2020 at 11:58 AM Alex Riesen
wrote:
> Geert Uytterhoeven, Fri, Mar 20, 2020 09:43:29 +0100:
> > On Thu, Mar 19, 2020 at 6:42 PM Alex Riesen
> > wrote:
> > > This adds an implemention of SoC DAI driver which provides access to the
> > &
Hi Alex,
On Fri, Mar 20, 2020 at 10:03 AM Alex Riesen
wrote:
> Geert Uytterhoeven, Fri, Mar 20, 2020 09:48:14 +0100:
> > On Fri, Mar 20, 2020 at 9:44 AM Alex Riesen
> > wrote:
> > > Laurent Pinchart, Thu, Mar 19, 2020 19:01:25 +0100:
> > > > On Thu, Ma
Hi Alex,
On Fri, Mar 20, 2020 at 9:58 AM Alex Riesen
wrote:
> Geert Uytterhoeven, Fri, Mar 20, 2020 09:43:29 +0100:
> > > +int adv748x_dai_init(struct adv748x_dai *dai)
> > > +{
> > > + int ret;
> > > + struct adv748x_
p
12.288 MHz clock source, without using the I2S port ;-)
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 j
>
> +struct adv748x_dai {
> + struct snd_soc_dai_driver drv;
> + struct clk *mclk;
> + unsigned int freq, fmt, tdm;
> +};
> +
> /**
> * struct adv748x_state - State of ADV748X
> * @dev: (OF) device
> @@ -182,6 +190,7 @@ struct
Hi Alex,
On Thu, Mar 5, 2020 at 3:36 PM Alex Riesen wrote:
> Geert Uytterhoeven, Mon, Mar 02, 2020 17:13:30 +0100:
> > On Mon, Mar 2, 2020 at 5:09 PM Alex Riesen
> > wrote:
> > > Geert Uytterhoeven, Mon, Mar 02, 2020 16:32:32 +0100:
> > > >
> > > &
Hi Alex,
On Mon, Mar 2, 2020 at 5:09 PM Alex Riesen wrote:
> Geert Uytterhoeven, Mon, Mar 02, 2020 16:32:32 +0100:
> > > And this absence of documentation also means that whatever clocks (both
> > > input
> > > in "clocks=" and output in "#clock-cell
Hi Alex,
On Mon, Mar 2, 2020 at 4:07 PM Alex Riesen wrote:
> Geert Uytterhoeven, Mon, Mar 02, 2020 14:47:46 +0100:
> > On Mon, Mar 2, 2020 at 2:40 PM Alex Riesen
> > wrote:
> > > > > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > > &g
Hi Alex,
On Mon, Mar 2, 2020 at 2:40 PM Alex Riesen wrote:
> Geert Uytterhoeven, Mon, Mar 02, 2020 13:28:13 +0100:
> > On Mon, Jan 13, 2020 at 3:24 PM Alex Riesen
> > wrote:
> > > Not sure if all variants of the Salvator board have the HDMI decoder
> > > chip (t
uot;ssi.9", "ssi.8", "ssi.7", "ssi.6",
> + "ssi.5", "ssi.4", "ssi.3", "ssi.2",
> + "ssi.1", "ssi.0",
> + "src
checkpatch.pl says:
WARNING: DT compatible string "bcm,bcm2708" appears un-documented -- check
./Documentation/devicetree/bindings/
The vendor prefix of Broadcom Corporation is "brcm", not "bcm".
Signed-off-by: Geert Uytterhoeven
---
Why do you need these 3
g_format): /fragment@0/__overlay__/spidev@1:reg: property has
invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Add the missing "#{address,size}-cells" to fix this.
Signed-off-by: Geert Uytterhoeven
---
.../staging/pi433/Documentation/devicetree/pi433-overlay.dt
Using overlay sugar syntax makes the DTS overlay files easier to read
(and write).
Signed-off-by: Geert Uytterhoeven
---
Why are there two separate fragments for spi0? Can't they be combined?
Why do you need the spidev@1 entry?
---
.../devicetree/pi433-overlay.dts | 79
!
Geert Uytterhoeven (3):
staging: pi433: overlay: Fix Broadcom vendor prefix
staging: pi433: overlay: Fix reg-related warnings
staging: pi433: overlay: Convert to sugar syntax
.../devicetree/pi433-overlay.dts | 73 +--
1 file changed, 34 insertions(+), 39 deletions
Hi Günter,
On Wed, Feb 5, 2020 at 2:52 PM Guenter Roeck wrote:
> On 2/5/20 1:03 AM, Geert Uytterhoeven wrote:
> > On Wed, Feb 5, 2020 at 4:57 AM Guenter Roeck wrote:
> >> On 2/4/20 7:34 PM, Dan Carpenter wrote:
> >>> On Tue, Feb 04, 2020 at 12:31:16PM -0800, Matth
he build
> failures.
Exactly. These are the "easy" ones, as the all*config builds enable as
much infrastructure as possible. It's much harder if some common
dependency is not fulfilled in some specific config.
Gr{oetje,eeting}s,
mtd, the
other in xfs.
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 journali
| 2 +-
> arch/m68k/Kconfig.debug| 16
> arch/m68k/Kconfig.machine | 8 ----
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32
casts to "u64" by casts to "uintptr_t", which is
either 32-bit or 64-bit, and adding an intermediate cast to "uintptr_t"
where needed.
Exposed by commit 171a9bae68c72f2d ("staging/octeon: Allow test build on
!MIPS").
Signed-off-by: Geert Uytterhoeven
casts to "u64" by casts to "uintptr_t", which is
either 32-bit or 64-bit, and adding an intermediate cast to "uintptr_t"
where needed.
Exposed by commit 171a9bae68c72f2d ("staging/octeon: Allow test build on
!MIPS").
Signed-off-by: Geert Uytterhoeven
to drop this cast as well.
Casts are evil, and usually a sign that you're doing something wrong.
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 hack
w one just for this sleep.
Is this function always called in non-atomic context?
If it may be called in atomic context, replacing the udelay() call by a
usleep*() call will break the driver.
See also "the first and most important question" in
Documentation/timers/timers-how
Signed-off-by: Geert Uytterhoeven
---
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.h
b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.h
index
"git diff" says:
\ No newline at end of file
after modifying the files.
Signed-off-by: Geert Uytterhoeven
---
drivers/staging/mt7621-dts/TODO | 2 +-
drivers/staging/rts5208/TODO| 2 +-
drivers/staging/vt6655/test | 2 +-
3 files changed, 3 insertions(+), 3 deletion
;-)
$ cat $(type -p unhexdump)
#!/bin/sh
sed 's/^[0-9a-f]*//' $1 | xxd -r -p | dd conv=swab
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
R_PTR error
I didn't receive the patch through email, but patchwork does have it:
https://patchwork.ozlabs.org/patch/1096054/
This fixes the crash ("Unable to handle kernel paging request atvirtual
address fffe") I'm seeing with sh_eth on r8a7791/koelsch, so
Tested-by: Geert Uytterhoeve
config is this?
This driver compiles fine with m68k/allmodconfig on v5.0?
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 journal
, struct
> nbu2ss_ep *);
>
>
> /*===*/
> /* Global */
> -struct nbu2ss_udc udc_controller;
> +static struct nbu2ss_udc udc_controller;
What about the "Global" comment?
Perhaps this was intentional?
Gr{oetje,eeting}s,
Geert
--
Geert Uyt
> chip callbacks if applicable is implemented.
>
> Cc: Jonathan Corbet
> Cc: Miguel Ojeda Sandonis
> Cc: Geert Uytterhoeven
> Cc: Sebastien Bourdelin
> Cc: Lukas Wunner
> Cc: Peter Korsgaard
> Cc: Peter Rosin
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc:
latile unsigned long *addr)
{
unsigned long mask = BIT_MASK(nr);
unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
*p |= mask;
}
include/linux/bits.h:
#define BIT_MASK(nr)(1UL << ((nr) % BITS_PER_LONG))
Looks like native endianness to
nctions' API with that additional parameter and update all users.
> Pass NULL if a user bulids an array itself from single GPIOs.
builds
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with t
ear_bit(PIN_CTRL_RS, value_bitmap);
Implied by the assignment above.
> n = 5;
> if (hd->pins[PIN_CTRL_RW]) {
> - values[PIN_CTRL_RW] = 0;
> + __clear_bit(PIN_CTRL_RW, value_bitmap);
> n++;
> }
> + value_bitmap[0] = value_bitmap[0]
ng... We should keep the
> reference until we're done with it. Which apparently is never?
Indeed. The reference must not be released in this function, as it's stored in
a global variable, and used later.
As all users are __init, it could be released when the init section is freeed,
in theory,
As of commit 7124330dabe5b3cb ("m68k/uaccess: Revive 64-bit
get_user()"), the 64-bit Android binder interface builds fine on m68k.
Signed-off-by: Geert Uytterhoeven
---
drivers/android/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/Kconfig
by several individual drivers.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
From: kbuild test robot <l...@intel.com>
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel
e about endianness when talking
to userspace?
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
Hi Mauro,
On Sat, May 5, 2018 at 2:47 PM, Mauro Carvalho Chehab
<mchehab+sams...@kernel.org> wrote:
> Em Tue, 17 Apr 2018 19:49:12 +0200
> Geert Uytterhoeven <ge...@linux-m68k.org> escreveu:
>
>> Remove dependencies on HAS_DMA where a Kconfig symbol depends on ano
Hi Laurent,
On Sun, Apr 22, 2018 at 10:46 AM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote:
>> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
>> > The Renesas Fine Display
Hi Mark,
On Fri, Apr 20, 2018 at 6:48 PM, Mark Brown <broo...@kernel.org> wrote:
> On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
>> The first 6 patches can be applied independently by subsystem
>> maintainers.
>> The last two patches de
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency than the legacy
ARCH_SHMOBILE, hence use the former.
This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Signed-off-by: Geert Uytterhoeven &
ow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.h
b/drivers/net/ethernet/
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
This depends on the driver patches in this series, hence the RFC.
JFTR, after this, the following symbols for drivers supporting only
Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
H_SHMOBILE on ARM and ARM64 in the near
future.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/media/platform/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/staging/emxx_udc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/emxx_udc/Kconfig b/drivers/staging/emxx_udc/Kconfig
index d7577096fb25ae7a..e50e722183648c55 100644
--- a/drivers/
. Removing the ARCH_SHMOBILE Kconfig symbols on ARM and ARM64.
The first 6 patches can be applied independently by subsystem
maintainers.
The last two patches depend on the first 6 patches, and are thus marked
RFC.
Thanks for your comments!
Geert Uytterhoeven (8):
arm: shmobile: Change platform
he legacy ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH
dependency.
This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
sound/soc/sh/Kconfig | 4 ++--
All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
platform dependencies. Hence finish the conversion from ARCH_SHMOBILE
to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
Signed-off-by: Geert Uy
re support for Renesas ARM SoCs was added.
Instead of blindly changing all the #ifdefs, switch the main code block
in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
remaining #ifdefs.
This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Signed-off-by: Geert Uytterhoeven &
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
by several individual drivers.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
- Rebase to v4.17-rc1,
- Handle new VIDEO_RENESAS_CEU symbol,
v2:
- Add Reviewed-by, Acked-by,
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.
Thanks for applying!
Geert Uytterhoeven (20):
ASoC: Remove depends on HAS_DMA in case of platform dependency
ata: Remove depends on HAS_DMA in case of platform dependency
cryp
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
_SOC_STORM and/or
SND_SOC_APQ8016_SBC.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Mark Brown <broo...@kernel.org>
---
v3:
- Add Acked-by,
- Rebase t
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Hi Rob,
On Thu, Apr 5, 2018 at 2:32 AM, Rob Herring <robherri...@gmail.com> wrote:
> On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
>> symbol bad_dma_op
Hi Madalin-cristian,
On Mon, Mar 19, 2018 at 6:27 AM, Madalin-cristian Bucur
<madalin.bu...@nxp.com> wrote:
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
>> On Behalf Of Geert Uytterhoeven
>> Remove
Hi Boris,
On Sun, Mar 18, 2018 at 11:04 PM, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> On Fri, 16 Mar 2018 14:51:47 +0100
> Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>
>> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
>
Hi Alan,
On Mon, Mar 19, 2018 at 5:06 PM, Alan Tull <at...@kernel.org> wrote:
> On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
> This essentially removes this commit
>
> commit 1c8cb409491403036919dd1c6b45013dc8835a44
> Author:
ng}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.
Hi Herbert,
On Fri, Mar 16, 2018 at 4:14 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Fri, Mar 16, 2018 at 02:51:33PM +0100, Geert Uytterhoeven wrote:
>> This patch series:
>> - Removes dependencies on HAS_DMA for symbols that already have
>> pla
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
_SOC_STORM and/or
SND_SOC_APQ8016_SBC.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Drop dependency of SND_
/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2
It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.
Thanks!
Geert Uytterhoeven (21):
ASoC: Remove depends on HAS_DMA in case of platform dependency
a
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
1 - 100 of 224 matches
Mail list logo
