lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 28 Oct 2018 09:31:34 +0100 (CET)
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Dave Stevenson <dave.stevenson@...pberrypi.org>
Cc:     Peter Robinson <pbrobinson@...il.com>, devel@...verdev.osuosl.org,
        tuomas.tynkkynen@....fi, Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        nsaenzjulienne@...e.de
Subject: Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

Hi Dave,

> Dave Stevenson <dave.stevenson@...pberrypi.org> hat am 26. Oktober 2018 um 19:15 geschrieben:
> 
> 
> Thanks Stefan.
> I've picked up your latest patches which mean I can get the driver
> loaded via the (almost) approved method.
> I do seem to still have issues with not getting the expected address
> ranges, so the driver/VPU was trying to map cached alias memory. As
> your patches only came through yesterday I haven't had a chance to dig
> through why yet. I've done a temporary hack to ensure we always map
> the uncached alias, but that can't persist.

does it mean with DT probing it worked before and with platform change it's broken?
Or anything else cause this regression in 4.19?

> The networking issue has been resolved :-)
> 
> I've pushed where I've got to to
> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b
> It's a touch messy due to integrating in your patches in the last 24
> hours. It needs a full rebase so that my changes are on top of yours
> rather than haphazard.
> As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree
> and jump to either that or directly on staging. I'll see where I get
> to early next week.

Sorry, but there is no need for a quick shot against a downstream 4.14. I assumed you make your changes against upstream linux-next + Phil's and my patches.

You can use https://github.com/anholt/linux/commits/bcm2835-audio until 4.20-rc1 is out.
Using 4.14 or 4.19 doesn't make any sense to me.

Regards
Stefan

> 
>   Dave

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ