* Re: [PATCH v2 27/35] irqchip: Andestech Internal Vector Interrupt Controller driver
From: Greentime Hu @ 2017-11-29 15:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Rob Herring, netdev, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Rick Chen
In-Reply-To: <c7447c93-9905-2840-e2d8-01837b9fdecd-5wv7dgnIgG8@public.gmane.org>
Hi, Marc:
2017-11-28 17:37 GMT+08:00 Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>:
> On 27/11/17 12:28, Greentime Hu wrote:
>> +static void ativic32_ack_irq(struct irq_data *data)
>> +{
>> + __nds32__mtsr_dsb(1 << data->hwirq, NDS32_SR_INT_PEND2);
>
> Consider writing (1 << data->hwirq) as BIT(data->hwirq).
Thanks for this suggestion. I will modify it in the next version patch.
>> +}
>> +
>> +static void ativic32_mask_irq(struct irq_data *data)
>> +{
>> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb(int_mask2 & (~(1 << data->hwirq)), NDS32_SR_INT_MASK2);
>
> Same here.
Thanks for this suggestion. I will modify it in the next version patch.
>> +}
>> +
>> +static void ativic32_mask_ack_irq(struct irq_data *data)
>> +{
>> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb(int_mask2 & (~(1 << data->hwirq)), NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb((1 << data->hwirq), NDS32_SR_INT_PEND2);
>
> This is effectively MASK+ACK, so you're better off just writing it as
> such. And since there is no advantage in your implementation in having
> MASK_ACK over MASK+ACK, I suggest you remove this function completely,
> and rely on the core code which will call them in sequence.
I think mask_ack is still better than mask + ack because we don't need
to do two function call.
We can save a prologue and a epilogue. It will benefit interrupt latency.
>> +
>> +}
>> +
>> +static void ativic32_unmask_irq(struct irq_data *data)
>> +{
>> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb(int_mask2 | (1 << data->hwirq), NDS32_SR_INT_MASK2);
>
> Same BIT() here.
>
Thanks for this suggestion. I will modify it in the next version patch.
>> +}
>> +
>> +static struct irq_chip ativic32_chip = {
>> + .name = "ativic32",
>> + .irq_ack = ativic32_ack_irq,
>> + .irq_mask = ativic32_mask_irq,
>> + .irq_mask_ack = ativic32_mask_ack_irq,
>> + .irq_unmask = ativic32_unmask_irq,
>> +};
>> +
>> +static unsigned int __initdata nivic_map[6] = { 6, 2, 10, 16, 24, 32 };
>> +
>> +static struct irq_domain *root_domain;
>> +static int ativic32_irq_domain_map(struct irq_domain *id, unsigned int virq,
>> + irq_hw_number_t hw)
>> +{
>> +
>> + unsigned long int_trigger_type;
>> + int_trigger_type = __nds32__mfsr(NDS32_SR_INT_TRIGGER);
>> + if (int_trigger_type & (1 << hw))
>
> And here.
>
Thanks for this suggestion. I will modify it in the next version patch.
>> + irq_set_chip_and_handler(virq, &ativic32_chip, handle_edge_irq);
>> + else
>> + irq_set_chip_and_handler(virq, &ativic32_chip, handle_level_irq);
>
> Since you do not express the trigger in DT, you need to tell the core
> about it by calling irqd_set_trigger_type() with the right setting.
>
Since the comments say so, I will add ativic32_set_type() for irq_set_type()
in the next version patch.
/*
* Must only be called inside irq_chip.irq_set_type() functions.
*/
static inline void irqd_set_trigger_type(struct irq_data *d, u32 type)
{
__irqd_to_state(d) &= ~IRQD_TRIGGER_MASK;
__irqd_to_state(d) |= type & IRQD_TRIGGER_MASK;
}
It will be like this.
static int ativic32_set_type(struct irq_data *data, unsigned int flow_type)
{
irqd_set_trigger_type(data, flow_type);
return IRQ_SET_MASK_OK;
}
>> +
>> + return 0;
>> +}
>> +
>> +static struct irq_domain_ops ativic32_ops = {
>> + .map = ativic32_irq_domain_map,
>> + .xlate = irq_domain_xlate_onecell
>> +};
>> +
>> +static int get_intr_src(void)
>
> I'm not sure "int" is the best return type here. I suspect something
> unsigned would be preferable, or even the irq_hw_number_t type.
Thanks for this suggestion. I will modify it in the next version patch.
>> +{
>> + return ((__nds32__mfsr(NDS32_SR_ITYPE)&ITYPE_mskVECTOR) >> ITYPE_offVECTOR)
>
> Spaces around '&'.
>
Thanks for this suggestion. I will modify it in the next version patch.
>> + - NDS32_VECTOR_offINTERRUPT;
>> +}
>> +
>> +asmlinkage void asm_do_IRQ(struct pt_regs *regs)
>> +{
>> + int hwirq = get_intr_src();
>
> irq_hw_number_t.
>
Thanks for this suggestion. I will modify it in the next version patch.
>> + handle_domain_irq(root_domain, hwirq, regs);
>> +}
>> +
>> +int __init ativic32_init_irq(struct device_node *node, struct device_node *parent)
>> +{
>> + unsigned long int_vec_base, nivic;
>> +
>> + if (WARN(parent, "non-root ativic32 are not supported"))
>> + return -EINVAL;
>> +
>> + int_vec_base = __nds32__mfsr(NDS32_SR_IVB);
>> +
>> + if (((int_vec_base & IVB_mskIVIC_VER) >> IVB_offIVIC_VER) == 0)
>> + panic("Unable to use atcivic32 for this cpu.\n");
>> +
>> + nivic = (int_vec_base & IVB_mskNIVIC) >> IVB_offNIVIC;
>> + if (nivic >= (sizeof nivic_map / sizeof nivic_map[0]))
>
> This should be:
> if (nivic >= ARRAY_SIZE(NIVIC_MAP))
>
Thanks for this suggestion. I will modify it in the next version patch.
>> + panic("The number of input for ativic32 is not supported.\n");
>> +
>> + nivic = nivic_map[nivic];
>
> I'd rather you use another variable (nr_ints?).
>
Thanks for this suggestion. I will modify it in the next version patch.
>> +
>> + root_domain = irq_domain_add_linear(node, nivic,
>> + &ativic32_ops, NULL);
>> +
>> + if (!root_domain)
>> + panic("%s: unable to create IRQ domain\n", node->full_name);
>> +
>> + return 0;
>> +}
>> +IRQCHIP_DECLARE(ativic32, "andestech,ativic32", ativic32_init_irq);
>>
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-29 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAK8P3a2d2_jxXehE3xP_G9Tzp6jP4hFmS4CJkh=6bePLEDcdGw@mail.gmail.com>
2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> Hi Arnd,
>>>>
>>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>>>>> +config CPU_CACHE_NONALIASING
>>>>>>>> + bool "Non-aliasing cache"
>>>>>>>> + help
>>>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>>>>> +
>>>>>>>> + If unsure, say Y.
>>>>>>>
>>>>>>> Can you determine this from the CPU type?
>>>>>>
>>>>>> There is no cpu register to determine it. It also depeneds on page
>>>>>> size and way size however page size is configurable by software.
>>>>>> These codes are determined at compile time will be benefit to code
>>>>>> size and performance.
>>>>>> IMHO, I think it would be better to be determined here.
>>>>>
>>>>> I meant determining it at compile time from other Kconfig symbols,
>>>>> if that's possible. Do the CPU cores each have a fixed way-size?
>>>>> If they do, it could be done like
>>>>>
>>>>> menu "CPU selection"
>>>>>
>>>>> config CPU_N15
>>>>> bool "AndesCore N15"
>>>>> select CPU_CACHE_NONALIASING
>>>>>
>>>>> config CPU_N13
>>>>> bool "AndesCore N15"
>>>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>>>>
>>>>> ...
>>>>>
>>>>> endmenu
>>>>>
>>>>> and then you can use the same CPU_... symbols to make other decisions
>>>>> as well, e.g. CPU specific compiler optimizations.
>>>>
>>>> Do you want to support multiple CPU types in a single kernel image
>>>> (I see no "choice" statement above)?
>>>> If yes, you may have a mix of aliasing and non-aliasing caches, so
>>>> you may want to invert the logic, and select CPU_CACHE_ALIASING
>>>> instead.
>>>
>>> Right, my mistake.
>>>
>>
>> Thanks to Arnd and Geert!
>>
>> How about this?
>>
>> choice
>> prompt "CPU type"
>> default CPU_N13
>> config CPU_N15
>> bool "AndesCore N15"
>> select CPU_CACHE_NONALIASING
>> config CPU_N13
>> bool "AndesCore N13"
>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>> config CPU_N10
>> bool "AndesCore N10"
>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>> config CPU_D15
>> bool "AndesCore D15"
>> select CPU_CACHE_NONALIASING
>> select HWZOL
>> config CPU_D10
>> bool "AndesCore D10"
>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>> endchoice
>
> With a 'choice' statement this works, but I would consider that
> suboptimal for another reason: now you cannot build a kernel that
> works on e.g. both N13 and N15.
>
> This is what we had on ARM a long time ago and on MIPS not so long
> ago, but it's really a burden for testing and distribution once you get
> support for more than a handful of machines supported in the mainline
> kernel: If each CPU core is mutually incompatible with the other ones,
> this means you likely end up having one defconfig per CPU core,
> or even one defconfig per SoC or board.
>
> I would always try to get the largest amount of hardware to work
> in the same kernel concurrently.
>
> One way of of this would be to define the "CPU type" as the minimum
> supported CPU, e.g. selecting D15 would result in a kernel that
> only works on D15, while selecting N15 would work on both N15 and
> D15, and selecting D10 would work on both D10 and D15.
>
Hi, Arnd:
Maybe we should keep the original implementation for this reason.
The default value of CPU_CACHE_NONALIASING and ANDES_PAGE_SIZE_8KB is
available for all CPU types for now.
User can use these configs built kernel to boot on almost all nds32 CPUs.
It might be a little bit weird if we config CPU_N10 but run on a N13 CPU.
This might confuse our users.
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 11:57 UTC (permalink / raw)
To: Greentime Hu
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAEbi=3cc8e__DnFKmTSMm9xQMx7CGu+1v3e55w8UekwnTTkw5Q@mail.gmail.com>
On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> Hi Arnd,
>>>
>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>>>> +config CPU_CACHE_NONALIASING
>>>>>>> + bool "Non-aliasing cache"
>>>>>>> + help
>>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>>>> +
>>>>>>> + If unsure, say Y.
>>>>>>
>>>>>> Can you determine this from the CPU type?
>>>>>
>>>>> There is no cpu register to determine it. It also depeneds on page
>>>>> size and way size however page size is configurable by software.
>>>>> These codes are determined at compile time will be benefit to code
>>>>> size and performance.
>>>>> IMHO, I think it would be better to be determined here.
>>>>
>>>> I meant determining it at compile time from other Kconfig symbols,
>>>> if that's possible. Do the CPU cores each have a fixed way-size?
>>>> If they do, it could be done like
>>>>
>>>> menu "CPU selection"
>>>>
>>>> config CPU_N15
>>>> bool "AndesCore N15"
>>>> select CPU_CACHE_NONALIASING
>>>>
>>>> config CPU_N13
>>>> bool "AndesCore N15"
>>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>>>
>>>> ...
>>>>
>>>> endmenu
>>>>
>>>> and then you can use the same CPU_... symbols to make other decisions
>>>> as well, e.g. CPU specific compiler optimizations.
>>>
>>> Do you want to support multiple CPU types in a single kernel image
>>> (I see no "choice" statement above)?
>>> If yes, you may have a mix of aliasing and non-aliasing caches, so
>>> you may want to invert the logic, and select CPU_CACHE_ALIASING
>>> instead.
>>
>> Right, my mistake.
>>
>
> Thanks to Arnd and Geert!
>
> How about this?
>
> choice
> prompt "CPU type"
> default CPU_N13
> config CPU_N15
> bool "AndesCore N15"
> select CPU_CACHE_NONALIASING
> config CPU_N13
> bool "AndesCore N13"
> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
> config CPU_N10
> bool "AndesCore N10"
> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
> config CPU_D15
> bool "AndesCore D15"
> select CPU_CACHE_NONALIASING
> select HWZOL
> config CPU_D10
> bool "AndesCore D10"
> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
> endchoice
With a 'choice' statement this works, but I would consider that
suboptimal for another reason: now you cannot build a kernel that
works on e.g. both N13 and N15.
This is what we had on ARM a long time ago and on MIPS not so long
ago, but it's really a burden for testing and distribution once you get
support for more than a handful of machines supported in the mainline
kernel: If each CPU core is mutually incompatible with the other ones,
this means you likely end up having one defconfig per CPU core,
or even one defconfig per SoC or board.
I would always try to get the largest amount of hardware to work
in the same kernel concurrently.
One way of of this would be to define the "CPU type" as the minimum
supported CPU, e.g. selecting D15 would result in a kernel that
only works on D15, while selecting N15 would work on both N15 and
D15, and selecting D10 would work on both D10 and D15.
Arnd
^ permalink raw reply
* Re: [PATCH v2 19/35] nds32: L2 cache support
From: Greentime Hu @ 2017-11-29 11:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Vincent Chen
In-Reply-To: <CAK8P3a2P+A55TyC_1bCj=sDjLZmpQoMptbZ59yd191fqdUstSA@mail.gmail.com>
Hi, Arnd:
2017-11-27 22:33 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> +
>> +#define L2C_R_REG(offset) __raw_readl(atl2c_base + offset)
>> +#define L2C_W_REG(offset, value) __raw_writel(value, atl2c_base + offset)
>
> __raw_readl() is generally not endian-safe, and might not have the barriers you
> require here. Could you use readl/writel here, and only fall back to
> readl_relaxed()/writel_relaxed() when you absolutely must avoid the barriers?
Thanks for your suggestions.
We will changed it to readl/writel
>> diff --git a/arch/nds32/kernel/atl2c.c b/arch/nds32/kernel/atl2c.c
>> new file mode 100644
>> index 0000000..dd87fc9
>> --- /dev/null
>> +++ b/arch/nds32/kernel/atl2c.c
>> +#include <linux/compiler.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_fdt.h>
>> +#include <linux/of_platform.h>
>> +#include <asm/l2_cache.h>
>
> If this is the only file that includes asm/l2_cache.h, then I'd simply
> move the entire
> contents in here, rather than having a separate file in the global namespace.
>
arch/nds32/mm/proc.c also includes this file so I will keep it.
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-29 11:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAK8P3a3yk7ww+LdQdL+wgz2wYrzXLSsj1PTdfK-qx013jdg4SQ@mail.gmail.com>
2017-11-29 17:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi Arnd,
>>
>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>>> +config CPU_CACHE_NONALIASING
>>>>>> + bool "Non-aliasing cache"
>>>>>> + help
>>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>>> +
>>>>>> + If unsure, say Y.
>>>>>
>>>>> Can you determine this from the CPU type?
>>>>
>>>> There is no cpu register to determine it. It also depeneds on page
>>>> size and way size however page size is configurable by software.
>>>> These codes are determined at compile time will be benefit to code
>>>> size and performance.
>>>> IMHO, I think it would be better to be determined here.
>>>
>>> I meant determining it at compile time from other Kconfig symbols,
>>> if that's possible. Do the CPU cores each have a fixed way-size?
>>> If they do, it could be done like
>>>
>>> menu "CPU selection"
>>>
>>> config CPU_N15
>>> bool "AndesCore N15"
>>> select CPU_CACHE_NONALIASING
>>>
>>> config CPU_N13
>>> bool "AndesCore N15"
>>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>>
>>> ...
>>>
>>> endmenu
>>>
>>> and then you can use the same CPU_... symbols to make other decisions
>>> as well, e.g. CPU specific compiler optimizations.
>>
>> Do you want to support multiple CPU types in a single kernel image
>> (I see no "choice" statement above)?
>> If yes, you may have a mix of aliasing and non-aliasing caches, so
>> you may want to invert the logic, and select CPU_CACHE_ALIASING
>> instead.
>
> Right, my mistake.
>
Thanks to Arnd and Geert!
How about this?
choice
prompt "CPU type"
default CPU_N13
config CPU_N15
bool "AndesCore N15"
select CPU_CACHE_NONALIASING
config CPU_N13
bool "AndesCore N13"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
config CPU_N10
bool "AndesCore N10"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
config CPU_D15
bool "AndesCore D15"
select CPU_CACHE_NONALIASING
select HWZOL
config CPU_D10
bool "AndesCore D10"
select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
endchoice
^ permalink raw reply
* Re: [PATCH 8/8] serdev: ttyport: do not used keyed wakeup in write_wakeup
From: Johan Hovold @ 2017-11-29 9:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Johan Hovold, Rob Herring, Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <20171128193926.GA1696@kroah.com>
On Tue, Nov 28, 2017 at 08:39:26PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 28, 2017 at 04:16:29PM +0100, Johan Hovold wrote:
> > On Tue, Nov 28, 2017 at 04:04:18PM +0100, Greg Kroah-Hartman wrote:
> > > On Fri, Nov 03, 2017 at 03:30:59PM +0100, Johan Hovold wrote:
> > > > Serdev does not use the file abstraction and specifically there will
> > > > never be anyone polling a file descriptor for POLLOUT events.
> > > >
> > > > Just use plain wake_up_interruptible() in the write_wakeup callback and
> > > > document why it's there.
> > > >
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > > > drivers/tty/serdev/serdev-ttyport.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > This patch didn't apply, perhaps because I split this series across my
> > > "for-next" and "for-linus" branches?
> >
> > That's right, this one depends on patch 4/8.
> >
> > Perhaps you can take also this one through tty-linus? Or even better,
> > just take the whole series through tty-linus?
>
> They all didn't feel like patches to go in after -rc1, right?
> Documentation updates? Minor tweaks? Would you want to defend them?
> :)
I agree that it's borderline, but the documentation update (patch 3/8)
is related to the first two bug fixes, where a negative return value
from a serdev driver could have triggered those bugs, so in a sense we
are fixing the docs.
Patch 6 and 8 are clean ups, but the open lock clean up in patch 6 is
related to the close lock fix in patch 5.
Patch 7 avoids a potential crash, albeit something that would not affect
any mainline drivers (as serial-core sets CLOCAL by default).
But I'm perfectly fine with holding them off for 4.16. Perhaps you can
just merge back rc2 and I can resubmit the final patch which didn't
apply after that.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 9:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, Vincent Chen, DTML, Al Viro, David Howells,
Will Deacon, Daniel Lezcano, linux-serial@vger.kernel.org,
Vincent Chen
In-Reply-To: <CAMuHMdViO=+-kGdXFPSW+9PsPbf3sUa5xdaJ_1C-cX2vE1G35Q@mail.gmail.com>
On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Arnd,
>
> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>>> +config CPU_CACHE_NONALIASING
>>>>> + bool "Non-aliasing cache"
>>>>> + help
>>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>>> +
>>>>> + If unsure, say Y.
>>>>
>>>> Can you determine this from the CPU type?
>>>
>>> There is no cpu register to determine it. It also depeneds on page
>>> size and way size however page size is configurable by software.
>>> These codes are determined at compile time will be benefit to code
>>> size and performance.
>>> IMHO, I think it would be better to be determined here.
>>
>> I meant determining it at compile time from other Kconfig symbols,
>> if that's possible. Do the CPU cores each have a fixed way-size?
>> If they do, it could be done like
>>
>> menu "CPU selection"
>>
>> config CPU_N15
>> bool "AndesCore N15"
>> select CPU_CACHE_NONALIASING
>>
>> config CPU_N13
>> bool "AndesCore N15"
>> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>>
>> ...
>>
>> endmenu
>>
>> and then you can use the same CPU_... symbols to make other decisions
>> as well, e.g. CPU specific compiler optimizations.
>
> Do you want to support multiple CPU types in a single kernel image
> (I see no "choice" statement above)?
> If yes, you may have a mix of aliasing and non-aliasing caches, so
> you may want to invert the logic, and select CPU_CACHE_ALIASING
> instead.
Right, my mistake.
Arnd
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Geert Uytterhoeven @ 2017-11-29 9:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, Vincent Chen, DTML, Al Viro, David Howells,
Will Deacon, Daniel Lezcano, linux-serial@vger.kernel.org,
Vincent Chen
In-Reply-To: <CAK8P3a0kvt52UTtEmE+tWHZuH_rmgTxP7+CiD9Ddwe2cJLwXTQ@mail.gmail.com>
Hi Arnd,
On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
>> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>>> +config CPU_CACHE_NONALIASING
>>>> + bool "Non-aliasing cache"
>>>> + help
>>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>>> +
>>>> + If unsure, say Y.
>>>
>>> Can you determine this from the CPU type?
>>
>> There is no cpu register to determine it. It also depeneds on page
>> size and way size however page size is configurable by software.
>> These codes are determined at compile time will be benefit to code
>> size and performance.
>> IMHO, I think it would be better to be determined here.
>
> I meant determining it at compile time from other Kconfig symbols,
> if that's possible. Do the CPU cores each have a fixed way-size?
> If they do, it could be done like
>
> menu "CPU selection"
>
> config CPU_N15
> bool "AndesCore N15"
> select CPU_CACHE_NONALIASING
>
> config CPU_N13
> bool "AndesCore N15"
> select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
>
> ...
>
> endmenu
>
> and then you can use the same CPU_... symbols to make other decisions
> as well, e.g. CPU specific compiler optimizations.
Do you want to support multiple CPU types in a single kernel image
(I see no "choice" statement above)?
If yes, you may have a mix of aliasing and non-aliasing caches, so
you may want to invert the logic, and select CPU_CACHE_ALIASING
instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 8:58 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Vincent Chen
In-Reply-To: <CAEbi=3c=hTCcUOPs+Fc10srzTFsB4MnVxgcFydz12-jH0ZXjog@mail.gmail.com>
On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu <green.hu@gmail.com> wrote:
> 2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>>> +config CPU_CACHE_NONALIASING
>>> + bool "Non-aliasing cache"
>>> + help
>>> + If this CPU is using VIPT data cache and its cache way size is larger
>>> + than page size, say N. If it is using PIPT data cache, say Y.
>>> +
>>> + If unsure, say Y.
>>
>> Can you determine this from the CPU type?
>
> There is no cpu register to determine it. It also depeneds on page
> size and way size however page size is configurable by software.
> These codes are determined at compile time will be benefit to code
> size and performance.
> IMHO, I think it would be better to be determined here.
I meant determining it at compile time from other Kconfig symbols,
if that's possible. Do the CPU cores each have a fixed way-size?
If they do, it could be done like
menu "CPU selection"
config CPU_N15
bool "AndesCore N15"
select CPU_CACHE_NONALIASING
config CPU_N13
bool "AndesCore N15"
select CPU_CACHE_NONALIASING if PAGE_SIZE_16K
...
endmenu
and then you can use the same CPU_... symbols to make other decisions
as well, e.g. CPU specific compiler optimizations.
Arnd
^ permalink raw reply
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Greentime Hu @ 2017-11-29 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Vincent Chen
In-Reply-To: <CAK8P3a1GuH2tgtC5t834-PNeUVYQxreD7seZH8sjraZFtRUWKw@mail.gmail.com>
2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>
>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>> new file mode 100644
>> index 0000000..6b4013f
>> --- /dev/null
>> +++ b/arch/nds32/Kconfig.cpu
>> @@ -0,0 +1,131 @@
>> +comment "Processor Features"
>> +
>> +config CPU_BIG_ENDIAN
>> + bool "Big endian"
>> + def_bool n
>> +
>> +config CPU_LITTLE_ENDIAN
>> + bool "Little endian"
>> + def_bool y
>
> These must be mutually exclusive, you surely get some build error if you try to
> set both here.
>
> You can either make it a 'choice' statement to pick between the two, or you
> can make CPU_LITTLE_ENDIAN a silent option like
>
> config CPU_BIG_ENDIAN
> bool "Big endian"
>
> config CPU_LITTLE_ENDIAN
> def_bool !CPU_BIG_ENDIAN
>
Thanks. I will fix it in the next version patch.
>> +config CPU_CACHE_NONALIASING
>> + bool "Non-aliasing cache"
>> + help
>> + If this CPU is using VIPT data cache and its cache way size is larger
>> + than page size, say N. If it is using PIPT data cache, say Y.
>> +
>> + If unsure, say Y.
>
> Can you determine this from the CPU type?
There is no cpu register to determine it. It also depeneds on page
size and way size however page size is configurable by software.
These codes are determined at compile time will be benefit to code
size and performance.
IMHO, I think it would be better to be determined here.
>> +choice
>> + prompt "Memory split"
>> + depends on MMU
>> + default VMSPLIT_3G
>> + help
>> + Select the desired split between kernel and user memory.
>> +
>> + If you are not absolutely sure what you are doing, leave this
>> + option alone!
>> +
>> + config VMSPLIT_3G
>> + bool "3G/1G user/kernel split"
>> + config VMSPLIT_3G_OPT
>> + bool "3G/1G user/kernel split (for full 1G low memory)"
>> + config VMSPLIT_2G
>> + bool "2G/2G user/kernel split"
>> + config VMSPLIT_1G
>> + bool "1G/3G user/kernel split"
>> +endchoice
>
> I think you mentioned that the 1GB configuration is quite common, how
> about making VMSPLIT_3G_OPT the default here?
We use 1GB in our fpga platform, but I am not sure our customer's
config and their user space program may use bigger memory space.
Anyway, we will discuss it to decide the default value.
Thanks for your suggestion.
^ permalink raw reply
* Re: [PATCH v2 06/35] nds32: MMU fault handling and page table management
From: Greentime Hu @ 2017-11-29 7:24 UTC (permalink / raw)
To: Mark Rutland
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial-u79uwXL29TY76Z2rM5mHXA, Vincent Chen
In-Reply-To: <20171127135136.3gnguzaf6d52tcpd-agMKViyK24J5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
Hi, Mark:
2017-11-27 21:51 GMT+08:00 Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>:
> Hi,
>
> On Mon, Nov 27, 2017 at 08:27:53PM +0800, Greentime Hu wrote:
>> +void do_page_fault(unsigned long entry, unsigned long addr,
>> + unsigned int error_code, struct pt_regs *regs)
>> +{
>
>> + /*
>> + * As per x86, we may deadlock here. However, since the kernel only
>> + * validly references user space from well defined areas of the code,
>> + * we can bug out early if this is from code which shouldn't.
>> + */
>> + if (unlikely(!down_read_trylock(&mm->mmap_sem))) {
>> + if (!user_mode(regs) &&
>> + !search_exception_tables(instruction_pointer(regs)))
>> + goto no_context;
>> +retry:
>> + down_read(&mm->mmap_sem);
>> + } else {
>> + /*
>> + * The above down_read_trylock() might have succeeded in which
>> + * case, we'll have missed the might_sleep() from down_read().
>> + */
>> + might_sleep();
>> + if (IS_ENABLED(CONFIG_DEBUG_VM)) {
>> + if (!user_mode(regs) &&
>> + !search_exception_tables(instruction_pointer(regs)))
>> + goto no_context;
>> + }
>> + }
>
>> + fault = handle_mm_fault(vma, addr, flags);
>> +
>> + /*
>> + * If we need to retry but a fatal signal is pending, handle the
>> + * signal first. We do not need to release the mmap_sem because it
>> + * would already be released in __lock_page_or_retry in mm/filemap.c.
>> + */
>> + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
>> + return;
>
> I believe you can get stuck in a livelock here (with an unkillable
> task), if a uaccess primitive tries to access a region protected by a
> userfaultfd. Please see:
>
> https://lkml.kernel.org/r/1499782590-31366-1-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org
>
> ... for details and a test case.
>
Thanks for your teatcase and patch. It works.
I will apply it to the next version patch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 31/35] earlycon: add reg-offset to physical address before mapping
From: Greentime Hu @ 2017-11-29 5:40 UTC (permalink / raw)
To: Greg KH
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial
In-Reply-To: <20171128142507.GA17797@kroah.com>
2017-11-28 22:25 GMT+08:00 Greg KH <greg@kroah.com>:
> On Mon, Nov 27, 2017 at 08:28:18PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> It will get the wrong virtual address because port->mapbase is not added
>> the correct reg-offset yet. We have to update it before earlycon_map()
>> is called
>> ---
>> drivers/tty/serial/earlycon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> No signed-off-by line?
Sorry I forget it.
Signed-off-by: Greentime Hu <greentime@andestech.com>
I will add it in the next version patch.
^ permalink raw reply
* Re: [PATCH 8/8] serdev: ttyport: do not used keyed wakeup in write_wakeup
From: Greg Kroah-Hartman @ 2017-11-28 19:39 UTC (permalink / raw)
To: Johan Hovold; +Cc: Rob Herring, Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <20171128151629.GA8177@localhost>
On Tue, Nov 28, 2017 at 04:16:29PM +0100, Johan Hovold wrote:
> On Tue, Nov 28, 2017 at 04:04:18PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Nov 03, 2017 at 03:30:59PM +0100, Johan Hovold wrote:
> > > Serdev does not use the file abstraction and specifically there will
> > > never be anyone polling a file descriptor for POLLOUT events.
> > >
> > > Just use plain wake_up_interruptible() in the write_wakeup callback and
> > > document why it's there.
> > >
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > > drivers/tty/serdev/serdev-ttyport.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > This patch didn't apply, perhaps because I split this series across my
> > "for-next" and "for-linus" branches?
>
> That's right, this one depends on patch 4/8.
>
> Perhaps you can take also this one through tty-linus? Or even better,
> just take the whole series through tty-linus?
They all didn't feel like patches to go in after -rc1, right?
Documentation updates? Minor tweaks? Would you want to defend them?
:)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
From: Matt Redfearn @ 2017-11-28 15:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, Ralf Baechle, James Hogan
Cc: Eugeniy Paltsev, linux-serial, linux-mips, Matt Redfearn,
stable # 4 . 14, linux-kernel, Paul Burton, Ingo Molnar,
Frederic Weisbecker
Add a custom serial.h header for MIPS, allowing platforms to override
the asm-generic version if required.
The generic platform uses this header to set BASE_BAUD to 0. The
generic platform supports multiple boards, which may have different
UART clocks. Also one of the boards supported is the Boston FPGA board,
where the UART clock depends on the loaded FPGA bitfile. As such there
is no way that the generic kernel can set a compile time default
BASE_BAUD.
Commit 31cb9a8575ca ("earlycon: initialise baud field of earlycon device
structure") changed the behavior of of_setup_earlycon such that any baud
rate set in the device tree is now set in the earlycon structure. The
UART driver will then calculate a divisor based on BASE_BAUD and set it.
With MIPS generic kernels this resulted in garbage output due to the
incorrect uart clock rate being used to calculate a divisor. This
commit, combined with "serial: 8250_early: Only set divisor if valid clk
& baud" prevents the earlycon code setting a bad divisor and restores
earlycon output.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
---
Changes in v2:
GPL v2
arch/mips/include/asm/Kbuild | 1 -
arch/mips/include/asm/serial.h | 22 ++++++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/include/asm/serial.h
diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
index 7c8aab23bce8..b1f66699677d 100644
--- a/arch/mips/include/asm/Kbuild
+++ b/arch/mips/include/asm/Kbuild
@@ -16,7 +16,6 @@ generic-y += qrwlock.h
generic-y += qspinlock.h
generic-y += sections.h
generic-y += segment.h
-generic-y += serial.h
generic-y += trace_clock.h
generic-y += unaligned.h
generic-y += user.h
diff --git a/arch/mips/include/asm/serial.h b/arch/mips/include/asm/serial.h
new file mode 100644
index 000000000000..1d830c6666c2
--- /dev/null
+++ b/arch/mips/include/asm/serial.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2017 MIPS Tech, LLC
+ *
+ * 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.
+ */
+#ifndef __ASM__SERIAL_H
+#define __ASM__SERIAL_H
+
+#ifdef CONFIG_MIPS_GENERIC
+/*
+ * Generic kernels cannot know a correct value for all platforms at
+ * compile time. Set it to 0 to prevent 8250_early using it
+ */
+#define BASE_BAUD 0
+#else
+#include <asm-generic/serial.h>
+#endif
+
+#endif /* __ASM__SERIAL_H */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
From: Matt Redfearn @ 2017-11-28 15:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ralf Baechle, James Hogan, Eugeniy Paltsev, linux-serial,
linux-mips, stable # 4 . 14, linux-kernel, Paul Burton,
Ingo Molnar, Frederic Weisbecker
In-Reply-To: <20171128143502.GA17699@kroah.com>
On 28/11/17 14:35, Greg Kroah-Hartman wrote:
> On Wed, Nov 22, 2017 at 09:57:29AM +0000, Matt Redfearn wrote:
>> Add a custom serial.h header for MIPS, allowing platforms to override
>> the asm-generic version if required.
>>
>> The generic platform uses this header to set BASE_BAUD to 0. The
>> generic platform supports multiple boards, which may have different
>> UART clocks. Also one of the boards supported is the Boston FPGA board,
>> where the UART clock depends on the loaded FPGA bitfile. As such there
>> is no way that the generic kernel can set a compile time default
>> BASE_BAUD.
>>
>> Commit 31cb9a8575ca ("earlycon: initialise baud field of earlycon device
>> structure") changed the behavior of of_setup_earlycon such that any baud
>> rate set in the device tree is now set in the earlycon structure. The
>> UART driver will then calculate a divisor based on BASE_BAUD and set it.
>> With MIPS generic kernels this resulted in garbage output due to the
>> incorrect uart clock rate being used to calculate a divisor. This
>> commit, combined with "serial: 8250_early: Only set divisor if valid clk
>> & baud" prevents the earlycon code setting a bad divisor and restores
>> earlycon output.
>>
>> Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
>> Cc: stable <stable@vger.kernel.org> # 4.14
>> Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
>>
>> ---
>>
>> arch/mips/include/asm/Kbuild | 1 -
>> arch/mips/include/asm/serial.h | 21 +++++++++++++++++++++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>> create mode 100644 arch/mips/include/asm/serial.h
>>
>> diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
>> index 7c8aab23bce8..b1f66699677d 100644
>> --- a/arch/mips/include/asm/Kbuild
>> +++ b/arch/mips/include/asm/Kbuild
>> @@ -16,7 +16,6 @@ generic-y += qrwlock.h
>> generic-y += qspinlock.h
>> generic-y += sections.h
>> generic-y += segment.h
>> -generic-y += serial.h
>> generic-y += trace_clock.h
>> generic-y += unaligned.h
>> generic-y += user.h
>> diff --git a/arch/mips/include/asm/serial.h b/arch/mips/include/asm/serial.h
>> new file mode 100644
>> index 000000000000..30be5cd8efdb
>> --- /dev/null
>> +++ b/arch/mips/include/asm/serial.h
>> @@ -0,0 +1,21 @@
>> +/*
>> + * This file is subject to the terms and conditions of the GNU General Public
>> + * License. See the file "COPYING" in the main directory of this archive
>> + * for more details.
>
> Which version of the GPL? As it is, this means "GPL v1 and all others".
>
> I doubt you want that :)
Good point - thanks!
Matt
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH 8/8] serdev: ttyport: do not used keyed wakeup in write_wakeup
From: Johan Hovold @ 2017-11-28 15:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Johan Hovold, Rob Herring, Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <20171128150418.GA3341@kroah.com>
On Tue, Nov 28, 2017 at 04:04:18PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 03, 2017 at 03:30:59PM +0100, Johan Hovold wrote:
> > Serdev does not use the file abstraction and specifically there will
> > never be anyone polling a file descriptor for POLLOUT events.
> >
> > Just use plain wake_up_interruptible() in the write_wakeup callback and
> > document why it's there.
> >
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > drivers/tty/serdev/serdev-ttyport.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
>
> This patch didn't apply, perhaps because I split this series across my
> "for-next" and "for-linus" branches?
That's right, this one depends on patch 4/8.
Perhaps you can take also this one through tty-linus? Or even better,
just take the whole series through tty-linus?
Johan
^ permalink raw reply
* Re: [PATCH 8/8] serdev: ttyport: do not used keyed wakeup in write_wakeup
From: Greg Kroah-Hartman @ 2017-11-28 15:04 UTC (permalink / raw)
To: Johan Hovold; +Cc: Rob Herring, Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <20171103143059.20749-9-johan@kernel.org>
On Fri, Nov 03, 2017 at 03:30:59PM +0100, Johan Hovold wrote:
> Serdev does not use the file abstraction and specifically there will
> never be anyone polling a file descriptor for POLLOUT events.
>
> Just use plain wake_up_interruptible() in the write_wakeup callback and
> document why it's there.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/tty/serdev/serdev-ttyport.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
This patch didn't apply, perhaps because I split this series across my
"for-next" and "for-linus" branches?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
From: Greg Kroah-Hartman @ 2017-11-28 14:35 UTC (permalink / raw)
To: Matt Redfearn
Cc: Ralf Baechle, James Hogan, Eugeniy Paltsev, linux-serial,
linux-mips, stable # 4 . 14, linux-kernel, Paul Burton,
Ingo Molnar, Frederic Weisbecker
In-Reply-To: <1511344649-27612-2-git-send-email-matt.redfearn@mips.com>
On Wed, Nov 22, 2017 at 09:57:29AM +0000, Matt Redfearn wrote:
> Add a custom serial.h header for MIPS, allowing platforms to override
> the asm-generic version if required.
>
> The generic platform uses this header to set BASE_BAUD to 0. The
> generic platform supports multiple boards, which may have different
> UART clocks. Also one of the boards supported is the Boston FPGA board,
> where the UART clock depends on the loaded FPGA bitfile. As such there
> is no way that the generic kernel can set a compile time default
> BASE_BAUD.
>
> Commit 31cb9a8575ca ("earlycon: initialise baud field of earlycon device
> structure") changed the behavior of of_setup_earlycon such that any baud
> rate set in the device tree is now set in the earlycon structure. The
> UART driver will then calculate a divisor based on BASE_BAUD and set it.
> With MIPS generic kernels this resulted in garbage output due to the
> incorrect uart clock rate being used to calculate a divisor. This
> commit, combined with "serial: 8250_early: Only set divisor if valid clk
> & baud" prevents the earlycon code setting a bad divisor and restores
> earlycon output.
>
> Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
> Cc: stable <stable@vger.kernel.org> # 4.14
> Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
>
> ---
>
> arch/mips/include/asm/Kbuild | 1 -
> arch/mips/include/asm/serial.h | 21 +++++++++++++++++++++
> 2 files changed, 21 insertions(+), 1 deletion(-)
> create mode 100644 arch/mips/include/asm/serial.h
>
> diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
> index 7c8aab23bce8..b1f66699677d 100644
> --- a/arch/mips/include/asm/Kbuild
> +++ b/arch/mips/include/asm/Kbuild
> @@ -16,7 +16,6 @@ generic-y += qrwlock.h
> generic-y += qspinlock.h
> generic-y += sections.h
> generic-y += segment.h
> -generic-y += serial.h
> generic-y += trace_clock.h
> generic-y += unaligned.h
> generic-y += user.h
> diff --git a/arch/mips/include/asm/serial.h b/arch/mips/include/asm/serial.h
> new file mode 100644
> index 000000000000..30be5cd8efdb
> --- /dev/null
> +++ b/arch/mips/include/asm/serial.h
> @@ -0,0 +1,21 @@
> +/*
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
Which version of the GPL? As it is, this means "GPL v1 and all others".
I doubt you want that :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] serial: 8250: convert to threaded IRQ
From: Greg KH @ 2017-11-28 14:26 UTC (permalink / raw)
To: Denys Zagorui; +Cc: jslaby, linux-serial, linux-kernel
In-Reply-To: <20171115124002.32039-1-dzagorui@cisco.com>
On Wed, Nov 15, 2017 at 02:40:02PM +0200, Denys Zagorui wrote:
> During using virtualization it is common to see
> many "too much work for irq*" messages.
>
> There are fixes proposed erlier:
> - e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 (serial:
> 8250, increase PASS_LIMIT)
> - f4f653e9875e573860e783fecbebde284a8626f5 (serial:
> 8250, disable "too much work" messages
>
> First one doesn't help now, last one was reverted
> (12de375ec493ab1767d4a07dde823e63ae5edc21) in fact
> it doesn't fix anything. So procesing interrupts in
> kthread give us an opportunity to perform rescheduling
> periodically.
>
> Cc: Jiri Slaby <jslaby@suse.com>
> Signed-off-by: Denys Zagorui <dzagorui@cisco.com>
> ---
> drivers/tty/serial/8250/8250_core.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
Always say what changed from v1 below the --- line, otherwise we have no
idea.
v3?
^ permalink raw reply
* Re: [PATCH v2 31/35] earlycon: add reg-offset to physical address before mapping
From: Greg KH @ 2017-11-28 14:25 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial
In-Reply-To: <5b5f07ffd75d509a661398d02d6f1336156554ae.1511785528.git.green.hu@gmail.com>
On Mon, Nov 27, 2017 at 08:28:18PM +0800, Greentime Hu wrote:
> From: Greentime Hu <greentime@andestech.com>
>
> It will get the wrong virtual address because port->mapbase is not added
> the correct reg-offset yet. We have to update it before earlycon_map()
> is called
> ---
> drivers/tty/serial/earlycon.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
No signed-off-by line?
^ permalink raw reply
* Re: [PATCH v2 26/35] dt-bindings: interrupt-controller: Andestech Internal Vector Interrupt Controller
From: Rob Herring @ 2017-11-28 14:05 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, netdev, deanbo422, devicetree, viro, dhowells,
will.deacon, daniel.lezcano, linux-serial, Rick Chen
In-Reply-To: <d2539a0128f8c1cf0b32fd5151fd2f8775e5c511.1511785528.git.green.hu@gmail.com>
On Mon, Nov 27, 2017 at 08:28:13PM +0800, Greentime Hu wrote:
> From: Greentime Hu <greentime@andestech.com>
>
> This patch adds an irqchip driver document for the Andestech Internal Vector
> Interrupt Controller.
>
> Signed-off-by: Rick Chen <rick@andestech.com>
> Signed-off-by: Greentime Hu <greentime@andestech.com>
> ---
> .../interrupt-controller/andestech,ativic32.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 27/35] irqchip: Andestech Internal Vector Interrupt Controller driver
From: Marc Zyngier @ 2017-11-28 9:37 UTC (permalink / raw)
To: Greentime Hu, greentime-MUIXKm3Oiri1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, deanbo422-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
linux-serial-u79uwXL29TY76Z2rM5mHXA
Cc: Rick Chen
In-Reply-To: <e82831165cd9e45a7d03af9c870560a6384e1603.1511785528.git.green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 27/11/17 12:28, Greentime Hu wrote:
> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>
> This patch adds the Andestech Internal Vector Interrupt Controller
> driver. You can find the spec here. Ch4.9 of AndeStar SPA V3 Manual.
> http://www.andestech.com/product.php?cls=9
>
> Signed-off-by: Rick Chen <rick-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
> ---
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-ativic32.c | 119 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 120 insertions(+)
> create mode 100644 drivers/irqchip/irq-ativic32.c
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index b842dfd..201ca9f 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -80,3 +80,4 @@ obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
> obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
> obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
> +obj-$(CONFIG_NDS32) += irq-ativic32.o
> diff --git a/drivers/irqchip/irq-ativic32.c b/drivers/irqchip/irq-ativic32.c
> new file mode 100644
> index 0000000..c4d6f86
> --- /dev/null
> +++ b/drivers/irqchip/irq-ativic32.c
> @@ -0,0 +1,119 @@
> +/*
> + * Copyright (C) 2005-2017 Andes Technology Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqdomain.h>
> +#include <linux/irqchip.h>
> +#include <nds32_intrinsic.h>
> +
> +static void ativic32_ack_irq(struct irq_data *data)
> +{
> + __nds32__mtsr_dsb(1 << data->hwirq, NDS32_SR_INT_PEND2);
Consider writing (1 << data->hwirq) as BIT(data->hwirq).
> +}
> +
> +static void ativic32_mask_irq(struct irq_data *data)
> +{
> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
> + __nds32__mtsr_dsb(int_mask2 & (~(1 << data->hwirq)), NDS32_SR_INT_MASK2);
Same here.
> +}
> +
> +static void ativic32_mask_ack_irq(struct irq_data *data)
> +{
> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
> + __nds32__mtsr_dsb(int_mask2 & (~(1 << data->hwirq)), NDS32_SR_INT_MASK2);
> + __nds32__mtsr_dsb((1 << data->hwirq), NDS32_SR_INT_PEND2);
This is effectively MASK+ACK, so you're better off just writing it as
such. And since there is no advantage in your implementation in having
MASK_ACK over MASK+ACK, I suggest you remove this function completely,
and rely on the core code which will call them in sequence.
> +
> +}
> +
> +static void ativic32_unmask_irq(struct irq_data *data)
> +{
> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
> + __nds32__mtsr_dsb(int_mask2 | (1 << data->hwirq), NDS32_SR_INT_MASK2);
Same BIT() here.
> +}
> +
> +static struct irq_chip ativic32_chip = {
> + .name = "ativic32",
> + .irq_ack = ativic32_ack_irq,
> + .irq_mask = ativic32_mask_irq,
> + .irq_mask_ack = ativic32_mask_ack_irq,
> + .irq_unmask = ativic32_unmask_irq,
> +};
> +
> +static unsigned int __initdata nivic_map[6] = { 6, 2, 10, 16, 24, 32 };
> +
> +static struct irq_domain *root_domain;
> +static int ativic32_irq_domain_map(struct irq_domain *id, unsigned int virq,
> + irq_hw_number_t hw)
> +{
> +
> + unsigned long int_trigger_type;
> + int_trigger_type = __nds32__mfsr(NDS32_SR_INT_TRIGGER);
> + if (int_trigger_type & (1 << hw))
And here.
> + irq_set_chip_and_handler(virq, &ativic32_chip, handle_edge_irq);
> + else
> + irq_set_chip_and_handler(virq, &ativic32_chip, handle_level_irq);
Since you do not express the trigger in DT, you need to tell the core
about it by calling irqd_set_trigger_type() with the right setting.
> +
> + return 0;
> +}
> +
> +static struct irq_domain_ops ativic32_ops = {
> + .map = ativic32_irq_domain_map,
> + .xlate = irq_domain_xlate_onecell
> +};
> +
> +static int get_intr_src(void)
I'm not sure "int" is the best return type here. I suspect something
unsigned would be preferable, or even the irq_hw_number_t type.
> +{
> + return ((__nds32__mfsr(NDS32_SR_ITYPE)&ITYPE_mskVECTOR) >> ITYPE_offVECTOR)
Spaces around '&'.
> + - NDS32_VECTOR_offINTERRUPT;
> +}
> +
> +asmlinkage void asm_do_IRQ(struct pt_regs *regs)
> +{
> + int hwirq = get_intr_src();
irq_hw_number_t.
> + handle_domain_irq(root_domain, hwirq, regs);
> +}
> +
> +int __init ativic32_init_irq(struct device_node *node, struct device_node *parent)
> +{
> + unsigned long int_vec_base, nivic;
> +
> + if (WARN(parent, "non-root ativic32 are not supported"))
> + return -EINVAL;
> +
> + int_vec_base = __nds32__mfsr(NDS32_SR_IVB);
> +
> + if (((int_vec_base & IVB_mskIVIC_VER) >> IVB_offIVIC_VER) == 0)
> + panic("Unable to use atcivic32 for this cpu.\n");
> +
> + nivic = (int_vec_base & IVB_mskNIVIC) >> IVB_offNIVIC;
> + if (nivic >= (sizeof nivic_map / sizeof nivic_map[0]))
This should be:
if (nivic >= ARRAY_SIZE(NIVIC_MAP))
> + panic("The number of input for ativic32 is not supported.\n");
> +
> + nivic = nivic_map[nivic];
I'd rather you use another variable (nr_ints?).
> +
> + root_domain = irq_domain_add_linear(node, nivic,
> + &ativic32_ops, NULL);
> +
> + if (!root_domain)
> + panic("%s: unable to create IRQ domain\n", node->full_name);
> +
> + return 0;
> +}
> +IRQCHIP_DECLARE(ativic32, "andestech,ativic32", ativic32_init_irq);
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 14/35] nds32: System calls handling
From: Arnd Bergmann @ 2017-11-28 9:23 UTC (permalink / raw)
To: Vincent Chen
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Vincent Chen
In-Reply-To: <CAJsyPhyep2xp1tANCUO=p9GwsAFZGcV=EdFnjdem8v3-o--O=Q@mail.gmail.com>
On Tue, Nov 28, 2017 at 3:18 AM, Vincent Chen <deanbo422@gmail.com> wrote:
> 2017-11-27 22:46 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>> diff --git a/arch/nds32/include/uapi/asm/unistd.h b/arch/nds32/include/uapi/asm/unistd.h
>>> new file mode 100644
>>> index 0000000..2bad1e7
>>> --- /dev/null
>>> +++ b/arch/nds32/include/uapi/asm/unistd.h
>>
>>> +
>>> +#define __ARCH_WANT_RENAMEAT
>>> +#define __ARCH_WANT_SYSCALL_OFF_T
>>
>> These two should not be here.
>>
>
> Thanks.
> But, I don't know I should move these two macro to which file.
> In asm-generic/unistd.h, these two are used to decide whether relative
> syscall number is defined or not.
> Therefore, I put these two macros here in order that these two
> definitions are available in user space.
What I meant is that they should not be available to user space.
The C libraries implement the user space interfaces based
on the replacement system calls, e.g. an application calling
the glibc stat() function will end up in the sys_stat64() system
call entry point, not the older sys_newstat().
Arnd
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_bcm: Add support for BCM2E72
From: Marcel Holtmann @ 2017-11-28 8:45 UTC (permalink / raw)
To: Hans de Goede
Cc: Gustavo F. Padovan, Johan Hedberg, Frédéric Danis,
open list:BLUETOOTH DRIVERS, linux-serial, linux-acpi
In-Reply-To: <20171122133728.13116-1-hdegoede@redhat.com>
Hi Hans,
> The Asus T100HA laptop uses an ACPI HID of BCM2E72 for the bluetooth
> part of the SDIO bcm43340 wifi/bt combo chip.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/bluetooth/hci_bcm.c | 1 +
> 1 file changed, 1 insertion(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2 22/35] nds32: Device tree support
From: Greentime Hu @ 2017-11-28 6:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Vincent Chen
In-Reply-To: <CAK8P3a3nczwuuna8BGRQU11hhOFZMqGQqn9i_7D=Tzrc1PizFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-27 22:30 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> @@ -0,0 +1,55 @@
>> +/dts-v1/;
>> +/ {
>> + compatible = "nds32 ae3xx";
>
> The compatible string doesn't seem to match the binding, it should always have
> vendor prefix.
Sorry I forgot to check this.
I will provide a document in bindings like
"Documentation/devicetree/bindings/nds32/andestech-boards".
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + interrupt-parent = <&intc>;
>> +
>> + chosen {
>> + bootargs = "earlycon console=ttyS0,38400n8 debug loglevel=7";
>> + stdout-path = &serial0;
>> + };
>
> I would drop the bootargs here, this is something that should be set by the
> bootloader and is up to the user.
Thanks
I will drop it in the next version patch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox