Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Warner Losh]

On Tue, Dec 12, 2017 at 10:05 AM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> Please stop dismissing concerns, especially if raised by more
> than one person, as whining, that is not helpful.
>

Except in this case it was totally useless. Totally. It was an emotional
reaction devoid of actual technical merit. Therefore, it's whining.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Rodney W. Grimes]

> On Tue, 12 Dec 2017 07:40:21 -0800 (PST)
> "Rodney W. Grimes"  wrote:
> 
> > > On Tue, 12 Dec 2017 06:18:36 +
> > > Alexey Dokuchaev  wrote:
> > > 
> > > > On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
> > > > > I think this name might confuse people looking for "syscons". Can it 
> > > > > be
> > > > > renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> > > > 
> > > > +1 for rename, it's very confusing now.
> > 
> > ++1 rename it or expect irrate users
> 
>  So where exactly in the confusion ?
> 
>  Is it because your tab completion when doing cd sys/dev/sysc will
> now ask you to type more char ?
>  This is the only place where "syscons" (not syscon) exists.

My appologies, I did not notice that there infact is a delta
of syscon vs syscons.  I thought that the name was an exact
match.  I still not real happy with it, but my objection is
retracted.

> > > > 
> > > > ./danfe
> > > 
> > >  It's not confusing. The spec is clear it's named "syscon" so our
> > > driver must be named syscon, naming it otherwise would be confusing.
> > >  What's confusing is the directory name for "sc" named syscons, it's
> > > config options are named SC_* and the device is named sc.
> > 
> > The spec is wrong for dictating what any implementation must
> > call this, the spec does not own the implementation name space.
> > 
> > It is called called syscons and uses the variables and driver
> > names sc beacuse that is what we did back in the 90's, drivers
> > typically had 2 character names.
> > 
> > >  The only valuable remark in this thread is bde's one saying it's not
> > > documented etc ... and yes we do sucks in this area in the arm world.
> > 
> > Thank you for your dismissal of input from the community, does that
> > mean your gong to ignore them?
> > 
> > >  Anyhow, I caught a discussion between mmel@ and kevans@ on IRC saying
> > > that we will move the driver into extres after adding some standard
> > > stuff common to extres framework.
> > 
> > FYI why is this so bad an idea to call it syscons:
> > man syscons
> > How do you plan to resolve that name space conflict?
> > AND this man page has existed since 1.0,  So 25 years of
> > finger memory, your just not gona do well trying to change that.
> 
>  The new driver name is "syscon" not "syscons", there is no name space
> conflict.

Again, I am sorry, I did not notice this and thought we had a
direct conflict.

> 
>  Again, we will move it to sys/dev/extres, now can we stop whining
> about small details like that and do some actual work please ?

I am glad it is moving, but that was never the reason that
someone raised issue.

Please stop dismissing concerns, especially if raised by more
than one person, as whining, that is not helpful.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Ian Lepore]

On Tue, 2017-12-12 at 07:40 -0800, Rodney W. Grimes wrote:
> > 
> > On Tue, 12 Dec 2017 06:18:36 +
> > Alexey Dokuchaev  wrote:
> > 
> > > 
> > > On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
> > > > 
> > > > I think this name might confuse people looking for "syscons". Can it be
> > > > renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> > > +1 for rename, it's very confusing now.
> ++1 rename it or expect irrate users
> 
> > 
> > > 
> > > 
> > > ./danfe
> >  It's not confusing. The spec is clear it's named "syscon" so our
> > driver must be named syscon, naming it otherwise would be confusing.
> >  What's confusing is the directory name for "sc" named syscons, it's
> > config options are named SC_* and the device is named sc.
> The spec is wrong for dictating what any implementation must
> call this, the spec does not own the implementation name space.
> 
> It is called called syscons and uses the variables and driver
> names sc beacuse that is what we did back in the 90's, drivers
> typically had 2 character names.
> 
> > 
> >  The only valuable remark in this thread is bde's one saying it's not
> > documented etc ... and yes we do sucks in this area in the arm world.
> Thank you for your dismissal of input from the community, does that
> mean your gong to ignore them?
> 
> > 
> >  Anyhow, I caught a discussion between mmel@ and kevans@ on IRC saying
> > that we will move the driver into extres after adding some standard
> > stuff common to extres framework.
> FYI why is this so bad an idea to call it syscons:
>   man syscons
> How do you plan to resolve that name space conflict?
> AND this man page has existed since 1.0,  So 25 years of
> finger memory, your just not gona do well trying to change that.
> 
> 

So a driver named "syscon" that implements the FDT device named
"syscon" is somehow a bad idea because it differs from an existing
driver directory name by only one character, but you're not bothered by
alc/ale, or bce/bfe/bge, or iwi/iwn, or mlx/mly, or any other of the
literally dozens of existing drivers whose directory names differ by
only 1 character.

In addition you defend naming options related to "syscons" as "sc"
because 25 years ago, "drivers typically have 2-character names", and I
guess that fact magically connects "device sc" to "dev/syscons" in
peoples' minds, because... phase of the moon, or what???

This whole discussion feels like it was scripted by Salvador Dali and
produced by David Lynch.

-- Ian

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Warner Losh]

On Tue, Dec 12, 2017 at 8:58 AM, Emmanuel Vadot 
wrote:

>  Again, we will move it to sys/dev/extres, now can we stop whining
> about small details like that and do some actual work please ?


while true; do echo +1 ; done

You have no idea how demotivating chicken !$!% complaining about a name
that's perfectly fine can be. Unless it causes and actual problem, don't
complain. Things are named similar to other things all the time and we
somehow cope when we discover they aren't exactly the same thing.

This whole conversation is the very definition of a bike shed: criticism
about one minor detail on trumped up reasons by people that did none of the
work.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Emmanuel Vadot]

On Tue, 12 Dec 2017 07:40:21 -0800 (PST)
"Rodney W. Grimes"  wrote:

> > On Tue, 12 Dec 2017 06:18:36 +
> > Alexey Dokuchaev  wrote:
> > 
> > > On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
> > > > I think this name might confuse people looking for "syscons". Can it be
> > > > renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> > > 
> > > +1 for rename, it's very confusing now.
> 
> ++1 rename it or expect irrate users

 So where exactly in the confusion ?

 Is it because your tab completion when doing cd sys/dev/sysc will
now ask you to type more char ?
 This is the only place where "syscons" (not syscon) exists.

> > > 
> > > ./danfe
> > 
> >  It's not confusing. The spec is clear it's named "syscon" so our
> > driver must be named syscon, naming it otherwise would be confusing.
> >  What's confusing is the directory name for "sc" named syscons, it's
> > config options are named SC_* and the device is named sc.
> 
> The spec is wrong for dictating what any implementation must
> call this, the spec does not own the implementation name space.
> 
> It is called called syscons and uses the variables and driver
> names sc beacuse that is what we did back in the 90's, drivers
> typically had 2 character names.
> 
> >  The only valuable remark in this thread is bde's one saying it's not
> > documented etc ... and yes we do sucks in this area in the arm world.
> 
> Thank you for your dismissal of input from the community, does that
> mean your gong to ignore them?
> 
> >  Anyhow, I caught a discussion between mmel@ and kevans@ on IRC saying
> > that we will move the driver into extres after adding some standard
> > stuff common to extres framework.
> 
> FYI why is this so bad an idea to call it syscons:
>   man syscons
> How do you plan to resolve that name space conflict?
> AND this man page has existed since 1.0,  So 25 years of
> finger memory, your just not gona do well trying to change that.

 The new driver name is "syscon" not "syscons", there is no name space
conflict.

 Again, we will move it to sys/dev/extres, now can we stop whining
about small details like that and do some actual work please ?

-- 
Emmanuel Vadot  
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Rodney W. Grimes]

> On Tue, 12 Dec 2017 06:18:36 +
> Alexey Dokuchaev  wrote:
> 
> > On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
> > > I think this name might confuse people looking for "syscons". Can it be
> > > renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> > 
> > +1 for rename, it's very confusing now.

++1 rename it or expect irrate users

> > 
> > ./danfe
> 
>  It's not confusing. The spec is clear it's named "syscon" so our
> driver must be named syscon, naming it otherwise would be confusing.
>  What's confusing is the directory name for "sc" named syscons, it's
> config options are named SC_* and the device is named sc.

The spec is wrong for dictating what any implementation must
call this, the spec does not own the implementation name space.

It is called called syscons and uses the variables and driver
names sc beacuse that is what we did back in the 90's, drivers
typically had 2 character names.

>  The only valuable remark in this thread is bde's one saying it's not
> documented etc ... and yes we do sucks in this area in the arm world.

Thank you for your dismissal of input from the community, does that
mean your gong to ignore them?

>  Anyhow, I caught a discussion between mmel@ and kevans@ on IRC saying
> that we will move the driver into extres after adding some standard
> stuff common to extres framework.

FYI why is this so bad an idea to call it syscons:
man syscons
How do you plan to resolve that name space conflict?
AND this man page has existed since 1.0,  So 25 years of
finger memory, your just not gona do well trying to change that.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Emmanuel Vadot]

On Tue, 12 Dec 2017 06:18:36 +
Alexey Dokuchaev  wrote:

> On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
> > I think this name might confuse people looking for "syscons". Can it be
> > renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> 
> +1 for rename, it's very confusing now.
> 
> ./danfe

 It's not confusing. The spec is clear it's named "syscon" so our
driver must be named syscon, naming it otherwise would be confusing.
 What's confusing is the directory name for "sc" named syscons, it's
config options are named SC_* and the device is named sc.

 The only valuable remark in this thread is bde's one saying it's not
documented etc ... and yes we do sucks in this area in the arm world.

 Anyhow, I caught a discussion between mmel@ and kevans@ on IRC saying
that we will move the driver into extres after adding some standard
stuff common to extres framework.

-- 
Emmanuel Vadot  
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Harry Schmalzbauer]

 Bezüglich Alexey Dokuchaev's Nachricht vom 12.12.2017 07:18 (localtime):
> On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
>> I think this name might confuse people looking for "syscons". Can it be
>> renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> +1 for rename, it's very confusing now.

Not that mine would have much weight, but also +1 from here. Stumbled at
any commit log yet – mmdevcon corecon[f] chpcon[f] soccon[f] – just to
throw in seomthing…

-harry
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Alexey Dokuchaev]

On Mon, Dec 11, 2017 at 10:14:04AM -0800, Nathan Whitehorn wrote:
> I think this name might confuse people looking for "syscons". Can it be
> renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?

+1 for rename, it's very confusing now.

./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Bruce Evans]

On Mon, 11 Dec 2017, Nathan Whitehorn wrote:

I think this name might confuse people looking for "syscons". Can it be 
renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?


The wouldn't find it since it is not in any man page, GENERIC, or even
in NOTES.  It is not as bad as some drivers like drm2 that are also not
in conf/files* so they are not puttable in GENERIC or NOTES or even in
the user's config file.

[.. Context lost to top posting]

Bruce
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Ian Lepore]

On Mon, 2017-12-11 at 10:14 -0800, Nathan Whitehorn wrote:
> I think this name might confuse people looking for "syscons". Can it
> be 
> renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?
> -Nathan
> 
> On 12/11/17 10:04, Kyle Evans wrote:
> > 
> > Author: kevans
> > Date: Mon Dec 11 18:04:04 2017
> > New Revision: 326773
> > URL: https://svnweb.freebsd.org/changeset/base/326773
> > 
> > Log:
> >    Add generic 'syscon' driver
> >    

It's definitely not arm-specific.  It's the modern linux/fdt way of
letting drivers access MMIO spaces they don't own (in terms of those
ranges being included in a reg property that would cause us to set up
rman resources for the device).

I'm not sure I would have made a new directory in dev/ for it though...
it's such a trivial little thing I would think it belongs with the
dev/extres stuff.

-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326773 - in head/sys: conf dev/syscon

[Nathan Whitehorn]

I think this name might confuse people looking for "syscons". Can it be 
renamed? Also, if it is ARM-specific, maybe it belongs in sys/arm?

-Nathan

On 12/11/17 10:04, Kyle Evans wrote:

Author: kevans
Date: Mon Dec 11 18:04:04 2017
New Revision: 326773
URL: https://svnweb.freebsd.org/changeset/base/326773

Log:
   Add generic 'syscon' driver
   
   Upstream dts for allwinner will require a syscon driver, since the emac node

   coming in 4.15 will be using xref to /soc/syscon for configuring the emac
   clock. Add a generic syscon driver to attach to /soc/syscon for use by
   if_awg, providing basic read/write functionality to consumers.
   
   syscon driver will also be used by arm64 at least for A64+H5 emac/if_awg.
   
   Written by:	mmel

   Reviewed by: manu
   Differential Revision:   https://reviews.freebsd.org/D13295

Added:
   head/sys/dev/syscon/
   head/sys/dev/syscon/syscon.c   (contents, props changed)
   head/sys/dev/syscon/syscon_if.m   (contents, props changed)
Modified:
   head/sys/conf/files

Modified: head/sys/conf/files
==
--- head/sys/conf/files Mon Dec 11 16:18:05 2017(r326772)
+++ head/sys/conf/files Mon Dec 11 18:04:04 2017(r326773)
@@ -3109,6 +3109,8 @@ dev/stg/tmc18c30_subr.c   optional stg
  dev/stge/if_stge.coptional stge
  dev/sym/sym_hipd.coptional sym\
dependency  "$S/dev/sym/sym_{conf,defs}.h"
+dev/syscon/syscon.coptional fdt syscon
+dev/syscon/syscon_if.m optional fdt syscon
  dev/syscons/blank/blank_saver.c   optional blank_saver
  dev/syscons/daemon/daemon_saver.c optional daemon_saver
  dev/syscons/dragon/dragon_saver.c optional dragon_saver

Added: head/sys/dev/syscon/syscon.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/dev/syscon/syscon.cMon Dec 11 18:04:04 2017
(r326773)
@@ -0,0 +1,185 @@
+/*-
+ * Copyright (c) 2015 Michal Meloun
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * This is a generic syscon driver, whose purpose is to provide access to
+ * various unrelated bits packed in a single register space. It is usually used
+ * as a fallback to more specific driver, but works well enough for simple
+ * access.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "syscon_if.h"
+
+#define SYSCON_LOCK(_sc)   mtx_lock(&(_sc)->mtx)
+#defineSYSCON_UNLOCK(_sc)  mtx_unlock(&(_sc)->mtx)
+#define SYSCON_LOCK_INIT(_sc)  mtx_init(&(_sc)->mtx,\
+   device_get_nameunit((_sc)->dev), "syscon", MTX_DEF)
+#define SYSCON_LOCK_DESTROY(_sc)   mtx_destroy(&(_sc)->mtx);
+#define SYSCON_ASSERT_LOCKED(_sc)  mtx_assert(&(_sc)->mtx, MA_OWNED);
+#define SYSCON_ASSERT_UNLOCKED(_sc)mtx_assert(&(_sc)->mtx, MA_NOTOWNED);
+
+struct syscon_softc {
+   device_tdev;
+   struct resource *mem_res;
+   struct mtx  mtx;
+};
+
+static struct ofw_compat_data compat_data[] = {
+   {"syscon",1},
+   {NULL,  0}
+};
+
+static uint32_t
+syscon_read_4(device_t dev, device_t consumer, bus_size_t offset)
+{
+   struct syscon_softc *sc;
+   uint32_t val;
+
+   sc = device_get_softc(dev);
+
+   SYSCON_LOCK(sc);
+   val = bus_read_4(sc->mem_res, offset);
+   SYSCON_UNLOCK(sc);
+   return (val);
+}
+
+static void
+syscon_write_4(device_t dev, device_t