Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp540904yba; Sat, 4 May 2019 07:39:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqz9c0AFAzLmQz0nPU5HDKSLr9vbC7y0BEis/RWmB2pQlKnK56HwidIB3KbWsuD/CVf5JB2l X-Received: by 2002:a17:902:7d90:: with SMTP id a16mr18492555plm.122.1556980793428; Sat, 04 May 2019 07:39:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556980793; cv=none; d=google.com; s=arc-20160816; b=Dhkvh1FYsva3mMPD0gXfQwrVq5S4xfN0i+GAp58tW/8B1IH/V3FxQ8/lh9FaczTgDJ Cmqgvahidmh10BG5ntKncevDe87AMoywhYrzHSIWEPTDSSgUhluYsr6LYp602oubmEnE MrKZWXVo3VNdTVlgkdS2HSuD873OkdCq8SBSoBVPZ/2GAkt+CuGQ6wgkx0Gp+eQxBJ3x em1bn01RJ6FNfWPsQekPVz/TvKSEnAJyhiW9515+QEj3j4RJdt/fgTvTuXD89J0b6dk9 XA6t9rXdE9S1TuliIKGRpJS8jiUAU5792I7R7hHLB0HTacIu2QXQOO+MLyTi6MArIDGu sXPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=NQ26DvLWSsC4RlgcZ6mpFGbR8LLToeT5ecKL2M4pgi8=; b=uFAucn7VUOjAZeV1xXqT7Q1BJEUvKsjzSGlvREPV7OAVu/zqIjfp07/RQpuGE4npDJ gELu2bO5eHuqafsZ4O/9AXyAEOH/GJ5wJoPsog7+t0uz/tOrkun3RNzLZ/Xp+AFx6xHz 3RF8E99Kyk9bmEn/fBTpdiErvmAMeQuJ2hs48rkKDptuVZrpJv7tQh2hNMby9dDH8jSi cLUt95NsZvDE31Cfk55HGG6AP10LxOx4MhPD40rvGCeDEJQpur61z5mxCJXxLM8Rqg8f 3GLIyK7hKXMtulO+WSuJ1Z4nboy7s+7ApbyN+lN749vEcvryYi8+7XQ4Wz61n4nnEtkj 2HHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay11si7081328plb.423.2019.05.04.07.39.01; Sat, 04 May 2019 07:39:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727094AbfEDOg2 (ORCPT + 99 others); Sat, 4 May 2019 10:36:28 -0400 Received: from icp-osb-irony-out7.external.iinet.net.au ([203.59.1.107]:44739 "EHLO icp-osb-irony-out7.external.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726070AbfEDOg2 (ORCPT ); Sat, 4 May 2019 10:36:28 -0400 X-Greylist: delayed 557 seconds by postgrey-1.27 at vger.kernel.org; Sat, 04 May 2019 10:36:26 EDT X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AJAACjoM1c/7akqnwNWBkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYQlhBCTYAEBAQEBAQaBCC2DXoVukQG?= =?us-ascii?q?EfQKCKTcGDgEDAQEBBAEBAQEChl8BAQEBAgEjFUEQCw4KAgImAgJXBgEMBgI?= =?us-ascii?q?BAYMegXcFqjtxgS+FR4MegUWBCycBi2R4gQeBOIJrPodOglgEizeBboVolCU?= =?us-ascii?q?JgguSPwYblUiMG5Z2gXgzGggoCIMnkGNgkT8BAQ?= X-IPAS-Result: =?us-ascii?q?A2AJAACjoM1c/7akqnwNWBkBAQEBAQEBAQEBAQEHAQEBA?= =?us-ascii?q?QEBgVQBAQEBAQELAYQlhBCTYAEBAQEBAQaBCC2DXoVukQGEfQKCKTcGDgEDA?= =?us-ascii?q?QEBBAEBAQEChl8BAQEBAgEjFUEQCw4KAgImAgJXBgEMBgIBAYMegXcFqjtxg?= =?us-ascii?q?S+FR4MegUWBCycBi2R4gQeBOIJrPodOglgEizeBboVolCUJgguSPwYblUiMG?= =?us-ascii?q?5Z2gXgzGggoCIMnkGNgkT8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,430,1549900800"; d="scan'208";a="173381743" Received: from 124-170-164-182.dyn.iinet.net.au (HELO [192.168.0.106]) ([124.170.164.182]) by icp-osb-irony-out7.iinet.net.au with ESMTP; 04 May 2019 22:27:06 +0800 Subject: Re: [PATCH 1/6] ARM: ks8695: watchdog: stop using mach/*.h To: Guenter Roeck , Linus Walleij Cc: Arnd Bergmann , arm-soc , Wim Van Sebroeck , Linux ARM , "linux-kernel@vger.kernel.org" , LINUXWATCHDOG References: <20190415202501.941196-1-arnd@arndb.de> <2424c672-e3fb-4c32-4c24-fafc59d03a96@uclinux.org> <20190503170613.GA1783@roeck-us.net> From: Greg Ungerer Message-ID: Date: Sun, 5 May 2019 00:26:53 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190503170613.GA1783@roeck-us.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/5/19 3:06 am, Guenter Roeck wrote: > On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote: >> On Fri, May 3, 2019 at 8:02 AM Greg Ungerer wrote: >> >>> I dug out some old ks8695 based hardware to try this out. >>> I had a lot of trouble getting anything modern working on it. >>> In the end I still don't have a reliable test bed to test this properly. >> >> What is usually used by old ARMv4 systems is OpenWrt or >> OpenEmbedded. Those is the only build systems that reliably >> produce a userspace for these things now, and it is also the >> appropriate size for this kind of systems. No, I can produce a user space environment for the KS8695 as well using the uClinux-dist build system. But that worked even less well than the old root filesystem that I had (which was also built with an older version of that build system). But there is no reason that old root filesystem should not work. And that is the thing that concerns me a bit here. I could mount it ok (it was a CRAMFS), it would run up the shell to a shell prompt, but when I try to run any commands from there they would oops. I didn't debug any further than that. >>> Ultimately though I am left wondering if the ks8695 support in the >>> kernel is useful to anyone the way it is at the moment. With a minimal >>> kernel configuration I can boot up to a shell - but the system is >>> really unreliable if you try to interactively use it. I don't think >>> it is the hardware - it seems to run reliably with the old code >>> it has running from flash on it. I am only testing the new kernel, >>> running with the existing user space root filesystem on it (which >>> dates from 2004 :-) >> >> Personally I think it is a bad sign that this subarch and boards do >> not have active OpenWrt support, they are routers after all (right?) >> and any active use of networking equipment should use a recent >> userspace as well, given all the security bugs that popped up over >> the years. >> >> With IXP4xx, Gemini and EP93xx we have found active users and >> companies selling the chips and reference designs and even >> recommending it for new products (!) at times. If this is not the >> case with KS8695 and no hobbyists are willing to submit it >> to OpenWrt and modernize it to use device tree I think it should be >> deleted from the kernel. >> > > That may be the best approach if indeed no one is using it, > much less maintaining it. Well, I for one don't really use it any more. So I don't have a lot of motivation to maintain it any longer. Regards Greg