linux-kernel - Re: [PATCH 0/7] staging: vc04_services: Some dead code removal

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] [day] [month] [year] [list]

Date:   Mon, 29 Oct 2018 10:43:46 +0000
From:   Dave Stevenson <dave.stevenson@...pberrypi.org>
To:     Stefan Wahren <stefan.wahren@...e.com>
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 Stefan

On Sun, 28 Oct 2018 at 08:31, Stefan Wahren <stefan.wahren@...e.com> wrote:
>
> 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?

Yes, probing via DT with the node under soc gave me the correct DMA
addresses (uncached alias). With the platform changes I get the cached
alias.
Both were under 4.14. I'll try again on a later branch.

> > 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.

As an employee of Raspberry Pi Trading my first responsibilty is to
them, and that means LTS releases feeding in to the downstream kernel.
If these drivers can be pushed upstream then that's a win as it avoids
divergence, but it is not my main goal. At least 4.19 and 4.20 aren't
far apart so there are likely to be fewer differences.

I had it all working on 4.14, therefore it made sense to see whether
your changes allowed me to load as a platform driver. It did, but with
this little niggle over cache aliases. I'll try again on a later
kernel and try to get some more info.

  Dave