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]
Message-ID: <48924BBB91ABDE4D9335632A6B179DD6A74236@MIPSMAIL01.mipstec.com>
Date:   Thu, 2 Nov 2017 13:47:05 +0000
From:   Miodrag Dinic <Miodrag.Dinic@...s.com>
To:     Paul Burton <Paul.Burton@...s.com>,
        Aleksandar Markovic <aleksandar.markovic@...rk.com>
CC:     "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        Goran Ferenc <Goran.Ferenc@...s.com>,
        Aleksandar Markovic <Aleksandar.Markovic@...s.com>,
        "David S. Miller" <davem@...emloft.net>,
        Douglas Leung <Douglas.Leung@...s.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        James Hogan <James.Hogan@...s.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Miodrag Dinic <miodrag.dinic@...tec.com>,
        Paul Burton <paul.burton@...tec.com>,
        Petar Jovanovic <Petar.Jovanovic@...s.com>,
        "Raghu Gandham" <Raghu.Gandham@...s.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: RE: [PATCH v6 5/5] MIPS: ranchu: Add Ranchu as a new generic-based
 board

Hi Paul,

thank you for the review. Please find the answers in-lined:

> > +#include <linux/of_address.h>
> > +
> > +#include <asm/machine.h>
> 
> You should also include asm/mipsregs.h for read_c0_count(), even though it's
> presumably being pulled in indirectly as-is.

Thanks, we will address this in V7.

> > +#include <asm/time.h>
> > +
> > +#define GOLDFISH_TIMER_LOW           0x00
> > +#define GOLDFISH_TIMER_HIGH          0x04
> > +
> > +static __init uint64_t read_rtc_time(void __iomem *base)
> > +{
> > +     u64 time_low;
> > +     u64 time_high;
> > +
> > +     time_low = readl(base + GOLDFISH_TIMER_LOW);
> > +     time_high = readl(base + GOLDFISH_TIMER_HIGH);
> > +
> > +     return (time_high << 32) | time_low;
> > +}
> > +
> > +static __init unsigned int ranchu_measure_hpt_freq(void)
> > +{
> > +     u64 rtc_start, rtc_current, rtc_delta;
> > +     unsigned int start, count;
> > +     struct device_node *np;
> > +     void __iomem *rtc_base;
> > +
> > +     np = of_find_compatible_node(NULL, NULL, "google,goldfish-rtc");
> > +     if (!np)
> > +             panic("%s(): Failed to find 'google,goldfish-rtc' dt node!",
> > +                   __func__);
> > +
> > +     rtc_base = of_iomap(np, 0);
> > +     if (!rtc_base)
> > +             panic("%s(): Failed to ioremap Goldfish RTC base!", __func__);
> > +
> > +     /*
> > +      * poll the nanosecond resolution RTC for 1 second
> > +      * to calibrate the CPU frequency
> > +      */
> > +     rtc_start = read_rtc_time(rtc_base);
> > +     start = read_c0_count();
> > +
> > +     do {
> > +             rtc_current = read_rtc_time(rtc_base);
> > +             rtc_delta = rtc_current - rtc_start;
> > +     } while (rtc_delta < NSEC_PER_SEC);
> > +
> > +     count = read_c0_count() - start;
> > +
> > +     count += 5000;  /* round */
> > +     count -= count % 10000;
> > +
> > +     return count;
> > +}
> 
> Would it be possible to have the emulator write the frequency into the
> devicetree, as the frequency of a fixed-clock used as the CPU's clock? If that
> were possible then there'd be no need for this board setup code at all. Not a
> big deal, but it'd be nice.

Well, yes I think that would be possible, but since this will be run on the emulator,
fixed-clock may not be the best because the point of this code is to make emulator
calibrate itself according to speed of the host which runs the emulation.
We may consider more advanced approach on this issue in the future, but for now
this works fine for us.

> > +
> > +static const struct of_device_id ranchu_of_match[];
> > +
> > +MIPS_MACHINE(ranchu) = {
> > +     .matches = ranchu_of_match,
> > +     .measure_hpt_freq = ranchu_measure_hpt_freq,
> > +};
> > +
> > +static const struct of_device_id ranchu_of_match[] = {
> > +     {
> > +             .compatible = "mti,ranchu",
> > +             .data = &__mips_mach_ranchu,
> > +     },
> > +};
> 
> Could you move ranchu_of_match before the MIPS_MACHINE & drop the forward
> declaration? That would feel tidier to me. It could also be marked as
> __initdata.

We can not remove the forward declaration because we need to define
__mips_mach_ranchu (which is done by MIPS_MACHINE(ranchu)) before ranchu_of_match.

Kind regards,
Miodrag

________________________________________
From: Paul Burton [paul.burton@...s.com]
Sent: Wednesday, November 1, 2017 6:58 PM
To: Aleksandar Markovic
Cc: linux-mips@...ux-mips.org; Miodrag Dinic; Goran Ferenc; Aleksandar Markovic; David S. Miller; Douglas Leung; Greg Kroah-Hartman; James Hogan; linux-kernel@...r.kernel.org; Mauro Carvalho Chehab; Miodrag Dinic; Paul Burton; Petar Jovanovic; Raghu Gandham; Ralf Baechle; Randy Dunlap
Subject: Re: [PATCH v6 5/5] MIPS: ranchu: Add Ranchu as a new generic-based board

Hi Aleksandar,

On Mon, Oct 30, 2017 at 12:56:36PM +0100, Aleksandar Markovic wrote:
> diff --git a/arch/mips/generic/board-ranchu.c b/arch/mips/generic/board-ranchu.c
> new file mode 100644
> index 0000000..0397752
> --- /dev/null
> +++ b/arch/mips/generic/board-ranchu.c
> @@ -0,0 +1,79 @@
> +/*
> + * Support code for virtual Ranchu board for MIPS.
> + *
> + * Author: Miodrag Dinic <miodrag.dinic@...s.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/of_address.h>
> +
> +#include <asm/machine.h>

You should also include asm/mipsregs.h for read_c0_count(), even though it's
presumably being pulled in indirectly as-is.

> +#include <asm/time.h>
> +
> +#define GOLDFISH_TIMER_LOW           0x00
> +#define GOLDFISH_TIMER_HIGH          0x04
> +
> +static __init uint64_t read_rtc_time(void __iomem *base)
> +{
> +     u64 time_low;
> +     u64 time_high;
> +
> +     time_low = readl(base + GOLDFISH_TIMER_LOW);
> +     time_high = readl(base + GOLDFISH_TIMER_HIGH);
> +
> +     return (time_high << 32) | time_low;
> +}
> +
> +static __init unsigned int ranchu_measure_hpt_freq(void)
> +{
> +     u64 rtc_start, rtc_current, rtc_delta;
> +     unsigned int start, count;
> +     struct device_node *np;
> +     void __iomem *rtc_base;
> +
> +     np = of_find_compatible_node(NULL, NULL, "google,goldfish-rtc");
> +     if (!np)
> +             panic("%s(): Failed to find 'google,goldfish-rtc' dt node!",
> +                   __func__);
> +
> +     rtc_base = of_iomap(np, 0);
> +     if (!rtc_base)
> +             panic("%s(): Failed to ioremap Goldfish RTC base!", __func__);
> +
> +     /*
> +      * poll the nanosecond resolution RTC for 1 second
> +      * to calibrate the CPU frequency
> +      */
> +     rtc_start = read_rtc_time(rtc_base);
> +     start = read_c0_count();
> +
> +     do {
> +             rtc_current = read_rtc_time(rtc_base);
> +             rtc_delta = rtc_current - rtc_start;
> +     } while (rtc_delta < NSEC_PER_SEC);
> +
> +     count = read_c0_count() - start;
> +
> +     count += 5000;  /* round */
> +     count -= count % 10000;
> +
> +     return count;
> +}

Would it be possible to have the emulator write the frequency into the
devicetree, as the frequency of a fixed-clock used as the CPU's clock? If that
were possible then there'd be no need for this board setup code at all. Not a
big deal, but it'd be nice.

> +
> +static const struct of_device_id ranchu_of_match[];
> +
> +MIPS_MACHINE(ranchu) = {
> +     .matches = ranchu_of_match,
> +     .measure_hpt_freq = ranchu_measure_hpt_freq,
> +};
> +
> +static const struct of_device_id ranchu_of_match[] = {
> +     {
> +             .compatible = "mti,ranchu",
> +             .data = &__mips_mach_ranchu,
> +     },
> +};

Could you move ranchu_of_match before the MIPS_MACHINE & drop the forward
declaration? That would feel tidier to me. It could also be marked as
__initdata.

In general though, with those & James' comments addressed, I think this is
looking good.

Thanks,
    Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ