linux-kernel - Re: [PATCH] MIPS: Add basic support for Loongson1B

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]

Message-ID: <20110915070752.GU15003@mails.so.argh.org>
Date:	Thu, 15 Sep 2011 09:07:53 +0200
From:	Andreas Barth <aba@....so.argh.org>
To:	Kelvin Cheung <keguang.zhang@...il.com>
Cc:	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org,
	ralf@...ux-mips.org, wuzhangjin@...il.com, r0bertz@...too.org,
	chenj@...ote.com
Subject: Re: [PATCH] MIPS: Add basic support for Loongson1B

* Kelvin Cheung (keguang.zhang@...il.com) [110915 05:28]:
> >> > Doesn't any of the existing clock drivers work?
> >> >
> >> > Is this clock part of the CPU? Otherwise it would make sense to move
> >> > it out to the generic drivers section.
> >
> > What's the answer to this questions?
> 
> I just did what other platform did, such as ar7, ath79, bcm63xx and
> jz4740. Could you have a look at their clock.c/clk.c?

Just it was done before doesn't mean it should be done again.

In an ideal world, a new platform would mean to just add
autodetection, the device tree, and the possibility of optimizing for
the CPU. Any drivers should be with the drivers, not with the
platform.  We're not there yet, but we should at least try to make
things as generic as possible.

(Or to quote someone else: Didn't the mips maintainer learn anything
from the arm mess?)


> I did not just duplicate code, modified exactly. The prom-routines of
> loongson platform does not fit loongson1.For instance, the
> "cpu_clock_freq" parameter is not needed. The cpu freq. could be get
> from the PLL register directly. Moreover, the routines does not
> include the parameter "ethaddr", which is useful for embedded system.

So why not make this optional? Or depend on the system type for what
you return?




Andi
--
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/