On Mon, Oct 15, 2018 at 1:46 PM Sam Ravnborg wrote:
>
> Hi Andrey.
>
> On Sun, Oct 14, 2018 at 07:21:05PM -0700, Andrey Smirnov wrote:
> > Port corresponding Linux kernel driver. Currently VFxxx SoC is the
> > intended consumer because it doesn't include common i.MX GPT block
> > used as
On Mon, Oct 15, 2018 at 2:19 PM Sam Ravnborg wrote:
>
> Hi Andrey.
>
> Some random nits while browsing the code.
>
> On Sun, Oct 14, 2018 at 07:21:23PM -0700, Andrey Smirnov wrote:
> > Port a very abridged version of MV88E6XXX DSA driver from Linux
> > kernel. Currently only internal MDIO bus
Make sure that there's a space between device name and it's status
string regardless if if device is using "id" field or not.
Before:
barebox@ZII RDU2 Board:/ miitool
mdio0-phy00: mdio:no link
mdio1-phy15: 2188000.ethernet@2188000:10 Mbit, half duplex, no link
mdio1-phy16:
At the moment only ifup stuff turns netif up.
After the commit f0624a701513 ('net: Do not route traffic
to interfaces that are not up') the dhcp command
keeps netif->ifup == false and network subsystem
can't route packets.
How to repropduce the problem on qemu-malta_defconfig:
On 10/15/2018 10:41 AM, Denis OSTERLAND wrote:
>> The faulting zero page problem doesn't occur on mx25 and mx28 as the HAB
>> ROM doesn't live at 0x0:
>>
>> #define HABV4_RVT_IMX28 0x8af8
>>
>> int imx25_hab_get_status(void)
>> {
>> return
Hi,
Am Freitag, den 12.10.2018, 08:23 +0200 schrieb Marc Kleine-Budde:
>
> The faulting zero page problem doesn't occur on mx25 and mx28 as the HAB
> ROM doesn't live at 0x0:
>
> #define HABV4_RVT_IMX28 0x8af8
>
> int imx25_hab_get_status(void)
> {
> return
On Mon, Oct 15, 2018 at 2:26 AM Antony Pavlov wrote:
>
> At the moment only ifup stuff turns netif up.
> After the commit f0624a701513 ('net: Do not route traffic
> to interfaces that are not up') the dhcp command
> keeps netif->ifup == false and network subsystem
> can't route packets.
>
I am
Normally, phy_update_status is in charge of reporting a change in link
status when phy is updated. When using fixed-link, speed and duplex are
initialized directly after registering the phy and there is no driver.
Hence when phy_update_status is called, the check for new values fails
and returns
Hi Andrey.
> > > +
> > > + chip->miibus.read = mv88e6xxx_mdio_read;
> > > + chip->miibus.write = mv88e6xxx_mdio_write;
> >
> > The function pointers are hardcoded here.
> > But we have them in chip->info->ops - where we can
> > have chip specific variants.
> > I assume it would be more
Signed-off-by: Andrey Smirnov
---
drivers/video/rave-sp-backlight.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/rave-sp-backlight.c
b/drivers/video/rave-sp-backlight.c
index 88ec86e73..3a20def66 100644
--- a/drivers/video/rave-sp-backlight.c
+++
Drop explicit type cast and alignement code in favor of PTR_ALIGN
Signed-off-by: Andrey Smirnov
---
common/dummy_malloc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/common/dummy_malloc.c b/common/dummy_malloc.c
index fa4f5d126..ab6712018 100644
---
Add code to check if sbrk() fails as well as setting appropriate
'errno' for users that may rely on it for error reporting.
Signed-off-by: Andrey Smirnov
---
common/dummy_malloc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/dummy_malloc.c b/common/dummy_malloc.c
index
Set errno to ENOMEM on failure so that correct error message can be
displayed by users who rely on errno.
Signed-off-by: Andrey Smirnov
---
common/tlsf_malloc.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/common/tlsf_malloc.c b/common/tlsf_malloc.c
Calloc() implementation for TLSF does not correctly check for malloc()
failure which can result in a NULL pointer exception when trying to
calloc() extra large buffers.
Since both TLSF and dummy malloc implementations of calloc() are
exactly the same, pick implementation for the latter (which
14 matches
Mail list logo
