Re: ioctl number change / backwards compatibility doubt

2022-03-16 Thread Greg KH
On Sat, Mar 12, 2022 at 01:05:46PM +1300, Paulo Miguel Almeida wrote:
> On Mon, Jan 24, 2022 at 07:20:45AM +0100, Greg KH wrote:
> > On Mon, Jan 24, 2022 at 05:49:06PM +1300, Paulo Miguel Almeida wrote:
> > > On Sun, Jan 23, 2022 at 12:04:48PM +0100, Greg KH wrote:
> > > 
> > > when you told me to look for the userspace tool that interfaced with the
> > > ioctl, my interpretation was that you were referring to something akin
> > > to what /usr/bin/uname utility is to the syscall uname. Please correct me 
> > > if I'm wrong.
> > > 
> > > re: what calls the ioctl created by the driver.
> > > 
> > > I'm led to believe that users of this driver make ioctl sycall
> > > invocations directly from their application's source code like this:
> > > 
> > > #include "pi433_if.h" /* userspace driver header */
> > > #include /* ioctl */
> > > 
> > > int file_desc = open("/dev/pi433.0", O_RDWR);
> > > struct pi433_tx_cfg tx_cfg = {
> > >   .frequency = 43300,
> > >   .bit_rate = 4800,
> > >   ...
> > > };
> > > 
> > > int ret_val = ioctl(file_desc, PI433_IOC_WR_TX_CFG, tx_cfg);
> > > 
> > 
> > Yes, sorry for the confusion, this is what I am referring to.  Where is
> > that userspace code as that is the code you will be needing to change if
> > you want to change this ioctl interface.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Hi Greg, 
> 
> The original author replied my email with that question.  He sent me
> some the code used to interface with char device, however, the source
> code he provided me is already incompatible with the current version of
> the driver:
> 
> #include "rfxx.h" (file header name has changed)
> 
> int main(int argc, char *argv[])
> {
>   ...
>   struct rfxx_send_config sendConfig; (struct name has changed)
>   ...
> fd = open("/dev/rf69_0.0", O_RDWR); *(char device name changed)*
>   ...
>   sendConfig.data_mode = packet; *(property doesn't exist)*
> ...
>   (IOCTL call has a different name)
>   ret = ioctl(fd, RFXX_IOC_WR_SEND_CONFIG, );
> if (ret == -1)
>   ...
> }
> 
> Assuming that I tweak these tools he provided me with and publish them,
> will I then be able to tweak the structures passed back and forth via
> ioctl? (do I need to change ioctl number in this case?) 
> 
> The reason why I'm asking this is because given the fact that other
> developers could have written similar code for interfacing with the
> driver (and that we will never know because code is proprietary), I
> won't be sure that I've changed all occurences at the same time, right?
> 
> All in all, please correct if there are gaps in this train of thought.
> 
> - If a change doesn't break *compiled* code (such as struct renaming) 
> then it's 'okay' to make the change ? (this has happened in the this
> driver before)

For staging drivers, the user/kernel api usually needs to be changed, so
yes, as long as you can change the tools that are being used to talk to
this api, you should be fine.

thanks,

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


RE: arm64 cache policy setting

2022-03-16 Thread Chan Kim


Hello, JeongHwan,
I'm relatively new to arm64 but there is MAIR (memory attribute indirection
register) which contains bytes holding cacheability, shareability and
protection information and the actual page table contains the 'index' for
the byte in this MAIR. 
For example in linux-5.10-0 which I'm seeing now, in pgattr_change_is_safe
function (to check if changing attribute is safe?), there is this code.

/*
 * Changing the memory type between Normal and Normal-Tagged is safe
 * since Tagged is considered a permission attribute from the
 * mismatched attribute aliases perspective.
 */
if (((old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
 (old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)) &&
((new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
 (new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)))
mask |= PTE_ATTRINDX_MASK;
it uses these index operation and actual cache policies are defined by the
MT_NORMAL (memory type normal) etc.
Hope this answers your question.

Chan
> -Original Message-
> From: JeongHwan Kim 
> Sent: Wednesday, March 16, 2022 11:32 AM
> To: kernelnewbies@kernelnewbies.org
> Subject: arm64 cache policy setting
> 
> Hi, everyone
> 
> 
> In Kernel version 5.16, ARM mmu routine, I can find "cachepolicy" kernel
> parameter to change cache policy.
> 
> But, I cannot find it in ARM64 source code.
> 
> Is there any method for setting cache policy in ARM64?
> 
> 
> Thanks in advance.
> 
> J.Hwan Kim
> 
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies





___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


[PATCH] dogs -

2022-03-16 Thread Jim Cromie
In an attempt to solve frictions in:
https://lore.kernel.org/lkml/20220311044756.425777-3-jim.cro...@gmail.com/

And inspired by https://lwn.net/Articles/383362/

defines DOGS macro - an initialization expression, ie list of breeds,
each contained by C, an inner macro, undefd when DOGS is defined.

C gets 2 defs for 2 tasks:
(each with preceding undef to reinforce the pattern)
- initialize enum dog_enums = DOGS: C(a) DRM_UT_##a (must form a real token)
- stringify each dog in DOGS: C(a) #a

Then tries to repeat this macro-pattern in DEFINE_DYNAMIC_DEBUG_CLASSBITS.
DOGS --> DRM_DEBUG_CATS
C -> C  reused for clarity

Its close, but not quite right:
- want to pass in init-construct once
- expand it 2x, with 2 different defs for C()
- cant nest #defines, cant redef for 2nd expansion.

Is there a way to do this ?

theres also some aspirational stuff in there, maybe it communicates /
explains things better than this commit msg.

Signed-off-by: Jim Cromie 
---
 play/c-code/dogs.c | 149 +
 1 file changed, 149 insertions(+)
 create mode 100644 play/c-code/dogs.c

diff --git a/play/c-code/dogs.c b/play/c-code/dogs.c
new file mode 100644
index 000..7094982
--- /dev/null
+++ b/play/c-code/dogs.c
@@ -0,0 +1,149 @@
+
+// see https://lwn.net/Articles/383362/
+
+#define DOGS { C(JACK_RUSSELL), C(BULL_TERRIER), C(ITALIAN_GREYHOUND) }
+
+#undef C
+#define C(a) ENUM_##a
+enum dog_enums DOGS;
+
+#undef C
+#define C(a) #a
+
+char *dog_strings[] = DOGS;
+char *dog_to_string(enum dog_enums dog)
+{
+  return dog_strings[dog];
+}
+
+
+// self-documenting help composition
+#define DOCS { \
+  _doc_( CORE, "extra core info"), \
+  _doc_( DRIVER, "extra driver info"), \
+  _doc_( KMS, "extra kms"),\
+}
+
+// 2 decomposers
+#define _sym_(_sym, _help) DRM_synth_##_sym
+#define _help_(_sym, _help)"enables " #_sym " messages - " _help
+
+// use sym to enumerate the symbols into the enum
+#undef _doc_
+#define _doc_ _sym_
+enum cat_enums DOCS;
+
+// use -help- to initialize the doc-strings
+#undef _doc_
+#define _doc_ _help_
+char *doc_helps[] = DOCS;
+char *doc_to_string(enum cat_enums cat)
+{
+  return doc_helps[cat];
+}
+
+#define FLAGS_LEN 8
+struct dyndbg_classbits_param {
+   unsigned long *bits;/* ref to shared state */
+   const char flags[FLAGS_LEN];/* toggle these flags on bit-changes */
+   const int classes[];/* indexed by bitpos */
+};
+
+#define _DPRINTK_SITE_UNCLASSED 15
+
+#include 
+#include 
+
+#define OP(s, state, x) BOOST_PP_CAT(state, x)
+#define SEQ (b)(o)(o)(s)(t)
+
+enum foo {
+  BOOST_PP_SEQ_FOLD_LEFT(OP, BOOST_PP_SEQ_HEAD(SEQ), BOOST_PP_SEQ_TAIL(SEQ))
+};
+
+// local copy
+enum drm_debug_category {
+  DRM_UT_CORE,
+  DRM_UT_DRIVER,
+  DRM_UT_KMS,
+  DRM_UT_PRIME,
+  DRM_UT_ATOMIC,
+  DRM_UT_VBL,
+  DRM_UT_STATE,
+  DRM_UT_LEASE,
+  DRM_UT_DP,
+  DRM_UT_DRMRES,
+  DRM_UT_DEFAULT
+};
+
+#define DRM_UT_DEFAULT 15
+#define DRM_DEBUG_CATS {   \
+C(_CORE),  \
+C(_DRIVER),
\
+C(_KMS),   \
+C(_PRIME), \
+C(_ATOMIC),
\
+C(_VBL),   \
+C(_STATE), \
+C(_LEASE), \
+C(_DP),\
+C(_DRMRES),
\
+  C(_DEFAULT)  \
+  }
+
+#undef C
+#define C(_cat) DRM_UT_##_cat  // wo _ after UT get 2x decl on local copy
+enum drm_dogs DRM_DEBUG_CATS;
+
+
+/**
+ * DEFINE_DYNAMIC_DEBUG_CLASSBITS() - bitmap control of classed pr_debugs
+ * @sysname: sysfs-node name
+ * @_var:C-identifier of ulong holding bit-vector (Bits 0-14 are usable)
+ * @_flgs:   string with dyndbg flags: 'p' and/or 'T', and maybe "fmlt" also.
+ * @desc:string summarizing the controls provided
+ * @classes: vector of callsite.class_id's (uint:4, 15 is reserved)
+ *
+ * This macro implements a DRM.debug API style bitmap, mapping bits
+ * 0-14 to classes of prdbg's, as initialized in their .class_id fields.
+ * @_flgs chooses the debug recipient; p - syslog, T - tracefs, and
+ * can include log decorations; m - module, f - function, l - line_num
+ */
+
+#define DEFINE_DYNAMIC_DEBUG_CLASSBITS(fsname, _var, _flgs, desc, ...) \
+   static struct dyndbg_classbits_param ddcats_##_var = {  \
+   .bits = &(_var),\
+   .flags = _flgs, \
+