[PATCH 2/2] boards: samx6: Adjust to latest get_runtime_offset()

[Andrey Smirnov]

Latest version of get_runtime_offset() returns positive offset that
needs to be added to rather than substracted from original pointer.

Cc: Michael Grzeschik 
Signed-off-by: Andrey Smirnov 
---

Sascha:

This one obviously needs to go into master as well. Sorry for the
noise if this has already been fixed.

Thanks,
Andrey Smirnov

 arch/arm/boards/kontron-samx6i/lowlevel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boards/kontron-samx6i/lowlevel.c 
b/arch/arm/boards/kontron-samx6i/lowlevel.c
index 4113ddbb4..5c3500704 100644
--- a/arch/arm/boards/kontron-samx6i/lowlevel.c
+++ b/arch/arm/boards/kontron-samx6i/lowlevel.c
@@ -47,7 +47,7 @@ static void __noreturn start_imx6_samx6i_common(void 
*fdt_blob_fixed_offset)
if (IS_ENABLED(CONFIG_DEBUG_LL))
setup_uart();
 
-   fdt = fdt_blob_fixed_offset - get_runtime_offset();
+   fdt = fdt_blob_fixed_offset + get_runtime_offset();
 
barebox_arm_entry(0x1000, size, fdt);
 }
-- 
2.14.3


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 1/2] i.MX53/TX53: Adjust to latest get_runtime_offset()

[Andrey Smirnov]

Latest version of get_runtime_offset() returns positive offset that
needs to be added to rather than substracted from original pointer.

Cc: Michael Grzeschik 
Signed-off-by: Andrey Smirnov 
---

Sascha:

This one obviously needs to go into master as well. Sorry for the
noise if this has already been fixed.

Thanks,
Andrey Smirnov

 arch/arm/boards/karo-tx53/lowlevel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boards/karo-tx53/lowlevel.c 
b/arch/arm/boards/karo-tx53/lowlevel.c
index cb324b200..a0bce8a78 100644
--- a/arch/arm/boards/karo-tx53/lowlevel.c
+++ b/arch/arm/boards/karo-tx53/lowlevel.c
@@ -47,7 +47,7 @@ static void __imx53_tx53_init(int is_xx30)
if (IS_ENABLED(CONFIG_DEBUG_LL))
setup_uart();
 
-   fdt = fdt_blob_fixed_offset - get_runtime_offset();
+   fdt = fdt_blob_fixed_offset + get_runtime_offset();
 
imx53_barebox_entry(fdt);
 }
-- 
2.14.3


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/3] console: Add simplified 'serdev' framework from Linux kernel

[Andrey Smirnov]

On Mon, Apr 2, 2018 at 11:54 PM, Sascha Hauer  wrote:
> Hi Andrey,
>
> Some comments inside.
>
>
> On Mon, Mar 26, 2018 at 06:09:14AM -0700, Andrey Smirnov wrote:
>> Port 'serdev' UART-slave deivce framework found in recent Linux
>> kernels (post 4.13) in order to be able to port 'serdev' slave drivers
>> from Linux.
>>
>> Signed-off-by: Andrey Smirnov 
>> @@ -323,6 +324,17 @@ int console_register(struct console_device *newcdev)
>>   dev->parent = newcdev->dev;
>>   platform_device_register(dev);
>>
>> + newcdev->open_count = 0;
>> +
>> + /*
>> +  * If our console deive is a serdev, we skip the creation of
>
> s/deive/device/

Will fix in v2.

>
>> +  * corresponding entry in /dev as well as registration in
>> +  * console_list and just go straigh to populating child
>
> s/straigh/straight/

Ditto.

>
>> +  * devices.
>> +  */
>> + if (serdev_node)
>> + return of_platform_populate(serdev_node, NULL, dev);
>
> How is this going to be used? A serdev driver binds to the serdev_node
> and then it probably needs to get a pointer to the console device,
> right? How does the driver accomplish this?
>

Serdev slave driver doesn't hold explicit pointer to console device,
instead accessing it via point to serdev_device. The latter could
obtained by calling to_serdev_device(dev->parent), where dev is
device_d given to slave driver's probe function.


>> +/**
>> + * struct serdev_device - Basic representation of an serdev device
>> + *
>> + * @dev: Corresponding device
>> + * @fifo:Circular buffer used for console draining
>> + * @buf: Buffer used to pass Rx data to consumers
>> + * @poller   Async poller used to poll this serdev
>> + * @polling_interval:Async poller periodicity
>> + * @polling_window:  Duration of a single busy loop poll
>> + * @receive_buf: Function called with data received from device;
>> + *   returns number of bytes accepted;
>> + */
>> +struct serdev_device {
>> + struct device_d *dev;
>> + struct kfifo *fifo;
>> + unsigned char *buf;
>> + struct poller_async poller;
>> + uint64_t polling_interval;
>> + uint64_t polling_window;
>> +
>> + int (*receive_buf)(struct serdev_device *, const unsigned char *,
>> +size_t);
>> +};
>> +
>> +int serdev_device_open(struct serdev_device *);
>> +unsigned int serdev_device_set_baudrate(struct serdev_device *, unsigned 
>> int);
>> +int serdev_device_write(struct serdev_device *, const unsigned char *,
>> + size_t, unsigned long);
>
> So a serdev driver uses serdev_device_write() to send characters out. To
> receive characters it has to implement serdev_device->receive_buf,
> right?

Right. I tried to implement exactly the same API that Linux's serdev
API provides.

> What kind of devices did you implement this for?

I ported serdev in support of porting the driver for RAVE SP which is
a small microcontroller device found many ZII board including RDU2. It
implement a whole bunch of various functionality including watchdog,
parameter EEPROM, sensor access, backlight control, button input event
generation, etc.

> For devices which send data without request (GPS?) this seems the way to go. 
> For
> others a synchronous receive function might be good, no?
>

I didn't implement anything like that mostly because Linux serdev API
doesn't and any ported driver wouldn't have any need for those
functions. But in general, I am not sure how useful synchronous
receive function would be. In my experience, devices like that usually
implement some binary transport protocol with packetization/escape
sequences on top of UART, which usually requires a state machine
operating with byte granularity as the data comes in to parse
responses correctly and synchronous APIs are not extremely useful for
that kind of a use-case.

FWIW, since serdev API is integrated into poller infrastructure it is
pretty trivial to write blocking code with it. Here's how I use it in
my driver to implement request-response type of a function:

rave_sp_write(sp, data, data_size);
/*
* is_timeout will implicitly poll serdev via poller
* infrastructure
*/
while (!is_timeout(start, SECOND) && !reply.received)
   ;


Thanks,
Andrey Smirnov

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/3] serial: Check result of console_unregister()

[Andrey Smirnov]

On Tue, Apr 3, 2018 at 12:04 AM, Sascha Hauer  wrote:
> On Mon, Mar 26, 2018 at 06:09:15AM -0700, Andrey Smirnov wrote:
>> In order to allow 'serdev' devices to prevent parent console device
>> removal and correspondign memory deallocation add code to all serial
>> driver to check result of console_unregister() and bail out early if
>> it is unsuccessful.
>>
>> One example of a use-case for this would be a reset handler relying on
>> a serdev device for transport. Without this patch underlying console
>> device would be removed and de-allocated before reset handler is even
>> run thus leading to unpredictable behaviour and crashes.
>
> Can't we make this sure at driver core level?

I need to be able to prevent serial driver's "remove" function from
ever executing to prevent any de-initialization/memory freeing from
happening. The simplest way to solve this in driver core that comes to
my mind is implementing simple reference counting API that children
could use to force driver core to bail out on removing parents if they
are still in use. Does that sound like a reasonable idea?

> So if a device decides not
> to return -EBUSY in the remove callback then the parent devices won't be
> removed?

Remove callback currently returns void, we could change it to return
int and use it to implement a sort of implicit refcounting, but doing
so would result in quite a bit of code churn since all of the current
drivers would have to be converted to return int in their .remove
callbacks. Would you rather I do this or explicit refcounting?

Thanks,
Andrey Smirnov

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v2] ARM: Add Advantech imx6 board support

[Christoph Fritz]

Add support for Advantech i.MX6 SOM named ROM-7421.

Signed-off-by: Christoph Fritz 
---
Changes since v0:
 - distinguish between MMC environment names in pr_notice() board.c
 - rework eMMC partition layout and don't use its hw-bootpartition for now
 - purge writing clock registers
 - rework and simplify lowlevel.c init and use imx6q_barebox_entry(fdt)
 - s/linux,stdout-path/stdout-path in dts
 - rework and simplify spi nor partition layout
 - remove additional pinctrl subnode from dts
 - remove setting of explicit ARCH_TEXT_BASE in Kconfig
 - use bitop Macro for ar8035_phy_fixup()
 - use imx_setup_pad() for early debug uart
---
 arch/arm/boards/Makefile   |   1 +
 arch/arm/boards/advantech-mx6/Makefile |   2 +
 arch/arm/boards/advantech-mx6/board.c  | 101 +
 .../flash-header-advantech-rom-7421.imxcfg |  66 ++
 arch/arm/boards/advantech-mx6/lowlevel.c   |  56 +
 arch/arm/configs/imx_v7_defconfig  |   1 +
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/imx6dl-advantech-rom-7421.dts | 225 +
 arch/arm/mach-imx/Kconfig  |   5 +
 images/Makefile.imx|   5 +
 10 files changed, 463 insertions(+)
 create mode 100644 arch/arm/boards/advantech-mx6/Makefile
 create mode 100644 arch/arm/boards/advantech-mx6/board.c
 create mode 100644 
arch/arm/boards/advantech-mx6/flash-header-advantech-rom-7421.imxcfg
 create mode 100644 arch/arm/boards/advantech-mx6/lowlevel.c
 create mode 100755 arch/arm/dts/imx6dl-advantech-rom-7421.dts

diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index ca187cc..521f37d 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -1,4 +1,5 @@
 # keep sorted by CONFIG_* macro name.
+obj-$(CONFIG_MACH_ADVANTECH_ROM_742X)  += advantech-mx6/
 obj-$(CONFIG_MACH_AFI_GF)  += afi-gf/
 obj-$(CONFIG_MACH_ANIMEO_IP)   += animeo_ip/
 obj-$(CONFIG_MACH_ARCHOSG9)+= archosg9/
diff --git a/arch/arm/boards/advantech-mx6/Makefile 
b/arch/arm/boards/advantech-mx6/Makefile
new file mode 100644
index 000..01c7a25
--- /dev/null
+++ b/arch/arm/boards/advantech-mx6/Makefile
@@ -0,0 +1,2 @@
+obj-y += board.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/advantech-mx6/board.c 
b/arch/arm/boards/advantech-mx6/board.c
new file mode 100644
index 000..4a30a84
--- /dev/null
+++ b/arch/arm/boards/advantech-mx6/board.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2018 Christoph Fritz 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int ar8035_phy_fixup(struct phy_device *dev)
+{
+   u16 val;
+
+   /* Ar803x phy SmartEEE feature cause link status generates glitch,
+* which cause ethernet link down/up issue, so disable SmartEEE
+*/
+   phy_write(dev, 0xd, 0x3);
+   phy_write(dev, 0xe, 0x805d);
+   phy_write(dev, 0xd, 0x4003);
+
+   val = phy_read(dev, 0xe);
+   phy_write(dev, 0xe, val & ~BIT(8));
+
+   /* To enable AR8031 ouput a 125MHz clk from CLK_25M */
+   phy_write(dev, 0xd, 0x7);
+   phy_write(dev, 0xe, 0x8016);
+   phy_write(dev, 0xd, 0x4007);
+
+   val = phy_read(dev, 0xe);
+   val &= 0xffe3;
+   val |= 0x18;
+   phy_write(dev, 0xe, val);
+
+   /* introduce tx clock delay */
+   phy_write(dev, 0x1d, 0x5);
+   val = phy_read(dev, 0x1e);
+   val |= 0x0100;
+   phy_write(dev, 0x1e, val);
+
+   return 0;
+}
+
+static int advantech_mx6_devices_init(void)
+{
+   int ret;
+   char *environment_path, *envdev;
+
+   if (!of_machine_is_compatible("advantech,imx6dl-rom-7421"))
+   return 0;
+
+   phy_register_fixup_for_uid(0x004dd072, 0xffef, ar8035_phy_fixup);
+
+   switch (bootsource_get()) {
+   case BOOTSOURCE_MMC:
+   environment_path = basprintf("/chosen/environment-sd%d",
+bootsource_get_instance() + 1);
+   if (bootsource_get_instance() + 1 == 4)
+   envdev = "eMMC";
+   else if (bootsource_get_instance() + 1 == 2)
+   envdev = "microSD";
+   else
+   envdev = "MMC";
+   break;
+   case BOOTSOURCE_SPI:
+   envdev = "SPI";
+

Re: [PATCH] ARM: Add Advantech imx6 board support

[Christoph Fritz]

Hi Andrey,

 thanks for your input, I'll integrate your suggestions and send a v2
patch.

Thanks
  -- Christoph


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: Add Advantech imx6 board support

[Christoph Fritz]

Hi Sascha,

On Fri, 2018-04-06 at 21:21 +0200, Sascha Hauer wrote:
> Hi Christoph,
> 
> On Thu, Apr 05, 2018 at 03:15:49PM +0200, Christoph Fritz wrote:
> > +   phy_register_fixup_for_uid(0x004dd072, 0xffef, ar8035_phy_fixup);
> > +
> > +   switch (bootsource_get()) {
> > +   case BOOTSOURCE_MMC:
> > +   environment_path = basprintf("/chosen/environment-sd%d",
> > +bootsource_get_instance() + 1);
> > +   envdev = "MMC";
> > +   break;
> > +   case BOOTSOURCE_SPI:
> > +   default:
> > +   environment_path = basprintf("/chosen/environment-sd4");
> > +   envdev = "MMC";
> > +   break;
> > +   }
> > +
> > +   if (environment_path) {
> > +   ret = of_device_enable_path(environment_path);
> > +   if (ret < 0)
> > +   pr_warn("Failed to enable env partition '%s' (%d)\n",
> > +   environment_path, ret);
> > +   free(environment_path);
> > +   }
> > +
> > +   pr_notice("Using environment in %s\n", envdev);
> 
> This is always "MMC", not very informative. Maybe "eMMC" and "external
> SD"?

I'll fix that.

> 
> > +
> > +   imx6_bbu_internal_mmc_register_handler("mmc3", "/dev/mmc3",
> > +   BBU_HANDLER_FLAG_DEFAULT);
> 
> That would be the eMMC, right? For this I can recommend putting barebox
> into the boot partitions of the eMMC. Normally there are two of them
> and with imx6_bbu_internal_mmcboot_register_handler() you even get a
> robust barebox A/B update mechanism.

I'm currently using here a hybrid u-boot into barebox boot and can't use
the eMMC SLC boot-partitions without changes on the u-boot side. That's
why I kept this config.

If you really want me to go for the boot0 partition, I can adapt this in
this mainline barebox setup?

> > +
> > +   return 0;
> > +}
> > +device_initcall(advantech_mx6_devices_init);
> > diff --git 
> > a/arch/arm/boards/advantech-mx6/flash-header-advantech-rom-7421.imxcfg 
> > b/arch/arm/boards/advantech-mx6/flash-header-advantech-rom-7421.imxcfg
> > new file mode 100644
> > index 000..611e06b
> > --- /dev/null
> > +++ b/arch/arm/boards/advantech-mx6/flash-header-advantech-rom-7421.imxcfg
> > @@ -0,0 +1,73 @@
> > +soc imx6
> > +loadaddr 0x1000
> > +dcdofs 0x400
> > +
> > +wm 32 0x020e0774 0x000C
> 
> [...]
> 
> > +wm 32 0x021b0004 0x0002556D
> > +wm 32 0x021b0404 0x00011006
> > +wm 32 0x021b001c 0x
> 
> > +wm 32 0x020c4068 0x00C03F3F
> > +wm 32 0x020c406c 0x0030FC03
> > +wm 32 0x020c4070 0x0FFFC000
> > +wm 32 0x020c4074 0x3FF0
> > +wm 32 0x020c4078 0x00FFF300
> > +wm 32 0x020c407c 0x0FC3
> > +wm 32 0x020c4080 0x03FF
> 
> Please remove writing these clock registers here. The registers get
> overwritten in a few moments by barebox anyway. Often enough these gate
> settings disable the USB clocks and then booting this image from USB is
> no longer possible.

I'll fix that.

> 
> > +wm 32 0x020e0010 0xF0CF
> > +wm 32 0x020e0018 0x007F007F
> > +wm 32 0x020e001c 0x007F007F
> > diff --git a/arch/arm/boards/advantech-mx6/lowlevel.c 
> > b/arch/arm/boards/advantech-mx6/lowlevel.c
> > new file mode 100644
> > index 000..5efb91a
> > --- /dev/null
> > +++ b/arch/arm/boards/advantech-mx6/lowlevel.c
> > @@ -0,0 +1,58 @@
> > +/*
> > + * Copyright (C) 2018 Christoph Fritz 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static inline void setup_uart(void)
> > +{
> > +   void __iomem *iomuxbase = (void *)MX6_IOMUXC_BASE_ADDR;
> > +
> > +   writel(0x3, iomuxbase + 0x4c);
> > +
> > +   imx6_ungate_all_peripherals();
> > +   imx6_uart_setup_ll();
> > +
> > +   putc_ll('>');
> > +}
> > +
> > +extern char __dtb_imx6dl_advantech_rom_7421_start[];
> > +
> > +BAREBOX_IMD_TAG_STRING(advantech_imx6dl_memsize_512M, IMD_TYPE_PARAMETER,
> > +  "memsize=512", 0);
> > +
> > +ENTRY_FUNCTION(start_advantech_imx6dl_rom_7421, r0, r1, r2)
> > +{
> > +   void *fdt;
> > +
> > +   imx6_cpu_lowlevel_init();
> > +
> > +   arm_setup_stack(0x0092 - 8);
> > +
> > +   IMD_USED(advantech_imx6dl_memsize_512M);
> > +
> > +   if (IS_ENABLED(CONFIG_DEBUG_LL))
> > +   setup_uart();
> > +
> > +   fdt = __dtb_imx6dl_advantech_rom_7421_start - get_runtime_offset();
> 
> Since "a43e2bbc46 ARM: return 

[RESEND] doc: bcm283x: update documentation for Raspberry Pi

[Roland Hieber]

The old way does not seem to work for RPi 3, as the UART pins are
mapped differently and the NOOBS bootcode does not seem to read a
config.txt.

Signed-off-by: Roland Hieber 
---
 Documentation/boards/bcm2835.rst | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)
---
Although Sascha said he had applied the patch, I cannot find traces of
it in the current master. It probably got lost, so I'm resending it.
Note that this patch is independent of Lucas' RPi patch series and also
applies to the current state of RPi support.

 - Roland

diff --git a/Documentation/boards/bcm2835.rst b/Documentation/boards/bcm2835.rst
index 13cebb01c4..1a78cfba3c 100644
--- a/Documentation/boards/bcm2835.rst
+++ b/Documentation/boards/bcm2835.rst
@@ -1,17 +1,35 @@
-Broadcom BCM2835
+Broadcom BCM283x
 
 
 Raspberry Pi
 
 
-  1. Prepare a card with a FAT filesystem. Download a tiny NOOBS LITE
- zip archive and unpack it into FAT partition.
- See http://www.raspberrypi.org/help/noobs-setup/ for details.
+  1. Prepare an SD or microSD card with a FAT filesystem of at least 30 MB in 
size.
+   
+  2. Download the `Raspberry Pi firmware`_ (120 MB), unzip it, and copy the
+ contents of the ``boot/`` folder to your card.
 
-  2. Compile ``barebox.bin`` image (use ``rpi_defconfig``).
- Copy it to the SD/microSD card and name it ``recovery.img``.
+  3. Use ``make rpi_defconfig; make`` to build barebox. This will create the 
following images:
 
-  3. Connect to board's UART (115200 8N1);
+ - ``images/barebox-raspberry-pi-1.img`` for the BCM2835/ARM1176JZF-S 
(Raspberry Pi 1)
+ - ``images/barebox-raspberry-pi-2.img`` for the BCM2836/CORTEX-A7 
(Raspberry Pi 2)
+ - ``images/barebox-raspberry-pi-3.img`` for the BCM2837/CORTEX-A53 
(Raspberry Pi 3, Raspberry Pi Zero)
+
+ Copy the respective image for your model to your SD card and name it
+ ``barebox.img``.
+
+  4. Create a text file ``config.txt`` on the SD card with the following 
content::
+
+ kernel=barebox.img
+ enable_uart=1
+ dtoverlay=pi3-miniuart-bt
+
+ (For more information, refer to the `documentation for config.txt`_.)
+
+  5. Connect to board's UART (115200 8N1);
  Use PIN6 (GND), PIN8 (UART_TX), PIN10 (UART_RX) pins.
 
-  4. Turn board's power on.
+  6. Turn board's power on.
+
+.. _Raspberry Pi firmware: 
https://codeload.github.com/raspberrypi/firmware/zip/80e1fbeb78f9df06701d28c0ed3a3060a3f557ef
+.. _documentation for config.txt: 
https://www.raspberrypi.org/documentation/configuration/config-txt/
-- 
2.11.0


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] video: IPUv3-LDB: demote dual-channel message to info level

[Sascha Hauer]

On Fri, Apr 06, 2018 at 05:49:29PM +0200, Lucas Stach wrote:
> Dual channel mode is a valid mode of operation, so there is no reason to
> print this at the warning level.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/video/imx-ipu-v3/imx-ldb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks

Sascha

> 
> diff --git a/drivers/video/imx-ipu-v3/imx-ldb.c 
> b/drivers/video/imx-ipu-v3/imx-ldb.c
> index 33dbade87007..9b4524274c4e 100644
> --- a/drivers/video/imx-ipu-v3/imx-ldb.c
> +++ b/drivers/video/imx-ipu-v3/imx-ldb.c
> @@ -347,7 +347,7 @@ static int imx_ldb_probe(struct device_d *dev)
>   return -EINVAL;
>  
>   if (dual && i > 0) {
> - dev_warn(dev, "dual-channel mode, ignoring second 
> output\n");
> + dev_info(dev, "dual-channel mode, ignoring second 
> output\n");
>   continue;
>   }
>  
> -- 
> 2.16.1
> 
> 
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] fb: reject enable request when framebuffer has no mode

[Sascha Hauer]

On Fri, Apr 06, 2018 at 05:23:23PM +0200, Lucas Stach wrote:
> If no display is connected or the display modes are incompatible with
> the scanout hardware we might end up with a registered framebuffer with
> no modes. Trying to enable such a framebuffer will blow up with NULL
> ptr dereferences in various places, so just don't do it.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/video/fb.c | 3 +++
>  1 file changed, 3 insertions(+)

Applied, thanks

Sascha

> 
> diff --git a/drivers/video/fb.c b/drivers/video/fb.c
> index 004df1e604d6..599ac5b75e0a 100644
> --- a/drivers/video/fb.c
> +++ b/drivers/video/fb.c
> @@ -124,6 +124,9 @@ static int fb_enable_set(struct param_d *param, void 
> *priv)
>   struct fb_info *info = priv;
>   int enable;
>  
> + if (!info->mode)
> + return -EINVAL;
> +
>   enable = info->p_enable;
>  
>   if (enable)
> -- 
> 2.16.1
> 
> 
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 61/78] ARM: aarch64: mmu: Make zero page faulting

[Sascha Hauer]

Hi Andrey,

On Tue, Mar 20, 2018 at 09:53:56PM -0700, Andrey Smirnov wrote:
> On Fri, Mar 16, 2018 at 5:53 AM, Sascha Hauer  wrote:
> > Make zero page faulting which allows us to catch NULL pointer derefs.
> >
> > Signed-off-by: Sascha Hauer 
> > ---
> >  arch/arm/cpu/mmu_64.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/cpu/mmu_64.c b/arch/arm/cpu/mmu_64.c
> > index 20f6c387f3..094bc0ac62 100644
> > --- a/arch/arm/cpu/mmu_64.c
> > +++ b/arch/arm/cpu/mmu_64.c
> > @@ -316,6 +316,8 @@ static int mmu_init(void)
> > for_each_memory_bank(bank)
> > create_sections(bank->start, bank->start, bank->size, 
> > CACHED_MEM);
> >
> > +   create_sections(0x0, 0x0, 0x1000, 0x0);
> 
> Sascha:
> 
> Maybe add commit message as comment to the line above as well?

Sorry, somehow I ended up ignoring this mail. I added a separate patch
adding a comment.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] net: on ifup -a only detect devices when necessary

[Sascha Hauer]

On Fri, Apr 06, 2018 at 09:33:37PM +0200, Lucas Stach wrote:
> Am Freitag, den 06.04.2018, 15:16 +0200 schrieb Sascha Hauer:
> > For network boot we once used to hardcode eth0, but in latest changes
> > this was changed to work with different network devices and the 'ifup
> > eth0' was replaced with 'ifup -a' which lead to the result that we
> > now
> > detect all devices in order to eventually also bring up USB network
> > adapters. In most of the cases this is not desired. When a board has
> > internal network support this is likely to be used. With this patch
> > we only detect all devices when we do not have a network device
> > already.
> > For the unusual case in which a USB network adapter shall be used
> > even when an internal network interface is present we introduce the
> > global variable "global.net.ifup_force_detect" which can be used to
> > force detection of devices.
> 
> This may warrant some more documentation. Without the code change and
> the above commit message, the variable doc isn't too verbose about what
> it does exactly.

You're right. I added the following to the docs:

 
+--+--++
 | global.net.ifup_force_detect | boolean  | Set to true if your network 
device is not  |
 |  |  | detected automatically during 
start (i.e. for  |
 |  |  | USB network adapters)  
|
 
+--+--++

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox