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:	Sat, 19 Apr 2008 12:38:31 +0200
From:	Michal Simek <monstr@...nam.cz>
To:	microblaze-uclinux@...e.uq.edu.au
CC:	Arnd Bergmann <arnd@...db.de>,
	John Williams <john.williams@...alogix.com>,
	jwboyer@...ux.vnet.ibm.com, benh@...nel.crashing.org,
	John Linn <linnj@...inx.com>, git-dev <git-dev@...inx.com>,
	Grant Likely <grant.likely@...retlab.ca>, git <git@...inx.com>,
	linux-kernel@...r.kernel.org, paulus@...ba.org
Subject: Re: [microblaze-uclinux] Re: Microblaze Linux release

Hi Steve

>>> * the consistent.c implementation looks strange. Is any of that code
>>> even used anywhere? What is it good for, considering that you don't
> have
>>> an mmu?
>> We have prepared MMU code. I hope that this code for FDT kernel comes
> soon.
>> This code is written by John Williams. I have never changed it. I see
> that this
>> code solves problems around ucached_shadows stuff.
>>
> http://developer.petalogix.com/wiki/UserGuide/AdvancedTopics/EnablingUnc
> achedShadow
>> JW. Can you comment this?
> 
> It probably makes sense to grab: arch/microblaze/mm/dma-coherent.c from
> git.xilinx.com and drop consistent.c.  I believe this is the more
> 'modern' way to implement this functionality.  I think it's easiest for
> you to just grab this file.

I'll look at it.

>>> * Your dma_mapping.h does BUG() for almost everything. I suspect you
> could
>>> easily replace it with a trivial implementation, like the x86_32
> one.
>> OK. I'll synchronize this.
> 
> This is also in git.xilinx.com.

ok.

>>> * You don't seem to have any code for PCI, so the pci.h and
> pci-bridge.h
>>> files don't make much sense.
>> Yes you are right. I don't have any PCI code but I think that this
> code for MB
>> exists. Steve or John: Do you have any code for PCI?
> 
> I'd recommend dropping anything having to do with PCI: I don't know that
> there is much interest in it on microblaze.

I think I'll do it

> Other comments:
> 
> memset/memmove/memcpy are broken under gcc4.  There are fixed versions
> of this at git.xilinx.com.  Again, it's probably easiest if you just
> grab the files directly.

NO. I fixed it. The problem was different as wrote Jan Engelhardt in previous
email. Changes are in repository. You have in xilinx repository only byte copy
and huge if 1 else endif. This is not acceptable. That's only as my explanation.

> It would also be good to have irq_of_parse_and_map, which drivers will
> need.  I'll send you a patch for this one.

This parts of code is coming with uartlite driver.

Thanks for your comments,
Michal

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ