Re: [PATCH v4 6/6] Add Propeller configuration for kernel build.

[Arnd Bergmann]

On Wed, Oct 23, 2024, at 07:06, Masahiro Yamada wrote:
> On Tue, Oct 22, 2024 at 9:00 AM Rong Xu  wrote:
>
>> > > +===
>> > > +
>> > > +Configure the kernel with::
>> > > +
>> > > +   CONFIG_AUTOFDO_CLANG=y
>> >
>> >
>> > This is automatically met due to "depends on AUTOFDO_CLANG".
>>
>> Agreed. But we will remove the dependency from PROPELlER_CLANG to 
>> AUTOFDO_CLANG.
>> So we will keep the part.
>
>
> You can replace "depends on AUTOFDO_CLANG" with
> "imply AUTOFDO_CLANG" if it is sensible.
>
> Up to you.

I don't think we should ever encourage the use of 'imply'
because it is almost always used incorrectly.

   Arnd

Re: [PATCH v4 24/26] arch_numa: switch over to numa_memblks

[Arnd Bergmann]

On Wed, Aug 7, 2024, at 20:18, Mike Rapoport wrote:
> On Wed, Aug 07, 2024 at 08:58:37AM +0200, Arnd Bergmann wrote:
>> On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
>> > 
>> >  void __init arch_numa_init(void);
>> >  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
>> > -void __init numa_set_distance(int from, int to, int distance);
>> > -void __init numa_free_distance(void);
>> >  void __init early_map_cpu_to_node(unsigned int cpu, int nid);
>> >  int __init early_cpu_to_node(int cpu);
>> >  void numa_store_cpu_info(unsigned int cpu);
>> 
>> but is still declared as __init in the header, so it is
>> still put in that section and discarded after boot.
>
> I believe this should fix it

Yes, sorry I should have posted the patch as well, this is
what I tested with locally.

 Arnd

Re: [PATCH v4 24/26] arch_numa: switch over to numa_memblks

[Arnd Bergmann]

On Wed, Aug 7, 2024, at 08:41, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" 
>
> Until now arch_numa was directly translating firmware NUMA information
> to memblock.

I get a link time warning from this:

WARNING: modpost: vmlinux: section mismatch in reference: 
numa_set_cpumask+0x24 (section: .text.unlikely) -> early_cpu_to_node (section: 
.init.text)

> @@ -142,7 +144,7 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
> nid)
>  unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
>  EXPORT_SYMBOL(__per_cpu_offset);
> 
> -int __init early_cpu_to_node(int cpu)
> +int early_cpu_to_node(int cpu)
>  {
>   return cpu_to_node_map[cpu];
>  }

early_cpu_to_node() can no longer be __init here

> +#endif /* CONFIG_NUMA_EMU */
> diff --git a/include/asm-generic/numa.h b/include/asm-generic/numa.h
> index c32e0cf23c90..c2b046d1fd82 100644
> --- a/include/asm-generic/numa.h
> +++ b/include/asm-generic/numa.h
> @@ -32,8 +32,6 @@ static inline const struct cpumask *cpumask_of_node(int 
> node)
> 
>  void __init arch_numa_init(void);
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> -void __init numa_set_distance(int from, int to, int distance);
> -void __init numa_free_distance(void);
>  void __init early_map_cpu_to_node(unsigned int cpu, int nid);
>  int __init early_cpu_to_node(int cpu);
>  void numa_store_cpu_info(unsigned int cpu);

but is still declared as __init in the header, so it is
still put in that section and discarded after boot.

I was confused by this at first, since the 'early' name
seems to imply that you shouldn't call it once the system
is up, but now you do.

 Arnd

Re: [PATCH v2 28/39] timekeeping: Fix a circular include dependency

[Arnd Bergmann]

On Fri, Oct 27, 2023, at 01:54, Kent Overstreet wrote:
> On Fri, Oct 27, 2023 at 01:05:48AM +0200, Thomas Gleixner wrote:
>> On Thu, Oct 26 2023 at 18:33, Suren Baghdasaryan wrote:
>> > On Wed, Oct 25, 2023 at 5:33 PM Thomas Gleixner  wrote:
>> >> > This avoids a circular header dependency in an upcoming patch by only
>> >> > making hrtimer.h depend on percpu-defs.h
>> >>
>> >> What's the actual dependency problem?
>> >
>> > Sorry for the delay.
>> > When we instrument per-cpu allocations in [1] we need to include
>> > sched.h in percpu.h to be able to use alloc_tag_save(). sched.h
>> 
>> Including sched.h in percpu.h is fundamentally wrong as sched.h is the
>> initial place of all header recursions.
>> 
>> There is a reason why a lot of funtionalitiy has been split out of
>> sched.h into seperate headers over time in order to avoid that.
>
> Yeah, it's definitely unfortunate. The issue here is that
> alloc_tag_save() needs task_struct - we have to pull that in for
> alloc_tag_save() to be inline, which we really want.
>
> What if we moved task_struct to its own dedicated header? That might be
> good to do anyways...

Yes, I agree that is the best way to handle it. I've prototyped
a more thorough header cleanup with good results (much improved
build speed) in the past, and most of the work to get there is
to seperate out structures like task_struct, mm_struct, net_device,
etc into headers that only depend on the embedded structure
definitions without needing all the inline functions associated
with them.

  Arnd

Re: [PATCH v2 01/10] appletalk: make localtalk and ppp support conditional

[Arnd Bergmann]

On Wed, Oct 11, 2023, at 17:04, Jiri Pirko wrote:
> Could you provide a cover letter for the set please?

Subject: [PATCH v2 00/10] remove final .ndo_do_ioctl references

The .ndo_do_ioctl() netdev operation used to be how one communicates
with a network driver from userspace, but since my previous cleanup [1],
it is purely internal to the kernel.

Removing the cops appletalk/localtalk driver made me revisit the
missing pieces from that older series, removing all the unused
implementations in wireless drivers as well as the two kernel-internal
callers in the ieee802154 and appletalk stacks.

One ethernet driver was already merged in the meantime that should
have used .ndo_eth_ioctl instead of .ndo_do_ioctl, so fix that as well.
With the complete removal, any future drivers making this mistake
cause build failures that are easier to spot.

[1] https://lore.kernel.org/netdev/20201106221743.3271965-1-a...@kernel.org/


Hope that helps, I had commented on the cops removal about sending
this but of course not everyone here saw that. Let me know if I should
resend the patches together with the cover letter.

Arnd

[PATCH v2 10/10] net: remove ndo_do_ioctl handler

[Arnd Bergmann]

From: Arnd Bergmann 

All of the references to the callback pointer are gone, so remove the
pointer itself before we grow new references to it.

Signed-off-by: Arnd Bergmann 
---
 Documentation/networking/netdevices.rst | 8 
 include/linux/netdevice.h   | 7 ---
 2 files changed, 15 deletions(-)

diff --git a/Documentation/networking/netdevices.rst 
b/Documentation/networking/netdevices.rst
index 9e4cccb90b870..6f9b71c5d37b8 100644
--- a/Documentation/networking/netdevices.rst
+++ b/Documentation/networking/netdevices.rst
@@ -218,14 +218,6 @@ ndo_stop:
Context: process
Note: netif_running() is guaranteed false
 
-ndo_do_ioctl:
-   Synchronization: rtnl_lock() semaphore.
-   Context: process
-
-This is only called by network subsystems internally,
-not by user space calling ioctl as it was in before
-linux-5.14.
-
 ndo_siocbond:
 Synchronization: rtnl_lock() semaphore.
 Context: process
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e070a4540fbaf..8d1cc8f195cb6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1121,11 +1121,6 @@ struct netdev_net_notifier {
  * int (*ndo_validate_addr)(struct net_device *dev);
  * Test if Media Access Control address is valid for the device.
  *
- * int (*ndo_do_ioctl)(struct net_device *dev, struct ifreq *ifr, int cmd);
- * Old-style ioctl entry point. This is used internally by the
- * appletalk and ieee802154 subsystems but is no longer called by
- * the device ioctl handler.
- *
  * int (*ndo_siocbond)(struct net_device *dev, struct ifreq *ifr, int cmd);
  * Used by the bonding driver for its device specific ioctls:
  * SIOCBONDENSLAVE, SIOCBONDRELEASE, SIOCBONDSETHWADDR, 
SIOCBONDCHANGEACTIVE,
@@ -1429,8 +1424,6 @@ struct net_device_ops {
int (*ndo_set_mac_address)(struct net_device *dev,
   void *addr);
int (*ndo_validate_addr)(struct net_device *dev);
-   int (*ndo_do_ioctl)(struct net_device *dev,
-   struct ifreq *ifr, int cmd);
int (*ndo_eth_ioctl)(struct net_device *dev,
 struct ifreq *ifr, int cmd);
int (*ndo_siocbond)(struct net_device *dev,
-- 
2.39.2

[PATCH v2 09/10] wifi: hostap: remove unused ioctl function

[Arnd Bergmann]

From: Arnd Bergmann 

The ioctl handler has no actual callers in the kernel and is useless.
All the functionality should be reachable through the regualar interfaces.

Acked-by: Kalle Valo 
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/wireless/hostap/hostap.h  |   1 -
 .../staging/wireless/hostap/hostap_ioctl.c| 228 --
 drivers/staging/wireless/hostap/hostap_main.c |   3 -
 3 files changed, 232 deletions(-)

diff --git a/drivers/staging/wireless/hostap/hostap.h 
b/drivers/staging/wireless/hostap/hostap.h
index c17ab6dbbb538..552ae33d78751 100644
--- a/drivers/staging/wireless/hostap/hostap.h
+++ b/drivers/staging/wireless/hostap/hostap.h
@@ -92,7 +92,6 @@ void hostap_info_process(local_info_t *local, struct sk_buff 
*skb);
 extern const struct iw_handler_def hostap_iw_handler_def;
 extern const struct ethtool_ops prism2_ethtool_ops;
 
-int hostap_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
 int hostap_siocdevprivate(struct net_device *dev, struct ifreq *ifr,
  void __user *data, int cmd);
 
diff --git a/drivers/staging/wireless/hostap/hostap_ioctl.c 
b/drivers/staging/wireless/hostap/hostap_ioctl.c
index b4adfc190ae87..26162f92e3c3d 100644
--- a/drivers/staging/wireless/hostap/hostap_ioctl.c
+++ b/drivers/staging/wireless/hostap/hostap_ioctl.c
@@ -2316,21 +2316,6 @@ static const struct iw_priv_args prism2_priv[] = {
 };
 
 
-static int prism2_ioctl_priv_inquire(struct net_device *dev, int *i)
-{
-   struct hostap_interface *iface;
-   local_info_t *local;
-
-   iface = netdev_priv(dev);
-   local = iface->local;
-
-   if (local->func->cmd(dev, HFA384X_CMDCODE_INQUIRE, *i, NULL, NULL))
-   return -EOPNOTSUPP;
-
-   return 0;
-}
-
-
 static int prism2_ioctl_priv_prism2_param(struct net_device *dev,
  struct iw_request_info *info,
  union iwreq_data *uwrq, char *extra)
@@ -2910,146 +2895,6 @@ static int prism2_ioctl_priv_writemif(struct net_device 
*dev,
 }
 
 
-static int prism2_ioctl_priv_monitor(struct net_device *dev, int *i)
-{
-   struct hostap_interface *iface;
-   local_info_t *local;
-   int ret = 0;
-   union iwreq_data wrqu;
-
-   iface = netdev_priv(dev);
-   local = iface->local;
-
-   printk(KERN_DEBUG "%s: process %d (%s) used deprecated iwpriv monitor "
-  "- update software to use iwconfig mode monitor\n",
-  dev->name, task_pid_nr(current), current->comm);
-
-   /* Backward compatibility code - this can be removed at some point */
-
-   if (*i == 0) {
-   /* Disable monitor mode - old mode was not saved, so go to
-* Master mode */
-   wrqu.mode = IW_MODE_MASTER;
-   ret = prism2_ioctl_siwmode(dev, NULL, &wrqu, NULL);
-   } else if (*i == 1) {
-   /* netlink socket mode is not supported anymore since it did
-* not separate different devices from each other and was not
-* best method for delivering large amount of packets to
-* user space */
-   ret = -EOPNOTSUPP;
-   } else if (*i == 2 || *i == 3) {
-   switch (*i) {
-   case 2:
-   local->monitor_type = PRISM2_MONITOR_80211;
-   break;
-   case 3:
-   local->monitor_type = PRISM2_MONITOR_PRISM;
-   break;
-   }
-   wrqu.mode = IW_MODE_MONITOR;
-   ret = prism2_ioctl_siwmode(dev, NULL, &wrqu, NULL);
-   hostap_monitor_mode_enable(local);
-   } else
-   ret = -EINVAL;
-
-   return ret;
-}
-
-
-static int prism2_ioctl_priv_reset(struct net_device *dev, int *i)
-{
-   struct hostap_interface *iface;
-   local_info_t *local;
-
-   iface = netdev_priv(dev);
-   local = iface->local;
-
-   printk(KERN_DEBUG "%s: manual reset request(%d)\n", dev->name, *i);
-   switch (*i) {
-   case 0:
-   /* Disable and enable card */
-   local->func->hw_shutdown(dev, 1);
-   local->func->hw_config(dev, 0);
-   break;
-
-   case 1:
-   /* COR sreset */
-   local->func->hw_reset(dev);
-   break;
-
-   case 2:
-   /* Disable and enable port 0 */
-   local->func->reset_port(dev);
-   break;
-
-   case 3:
-   prism2_sta_deauth(local, WLAN_REASON_DEAUTH_LEAVING);
-   if (local->func->cmd(dev, HFA384X_CMDCODE_DISABLE, 0, NULL,
-NULL))
-   return -EINVAL;
-   break;
-
-   case 4:
-   if (local->func->cmd(dev, HFA384X_CMDCODE_ENABLE, 0, NULL,
-

[PATCH v2 08/10] wifi: atmel: remove unused ioctl function

[Arnd Bergmann]

From: Arnd Bergmann 

This function has no callers, and for the past 20 years, the request_firmware
interface has been in place instead of the custom firmware loader.

Acked-by: Kalle Valo 
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/wireless/atmel/atmel.c | 72 --
 1 file changed, 72 deletions(-)

diff --git a/drivers/staging/wireless/atmel/atmel.c 
b/drivers/staging/wireless/atmel/atmel.c
index 7c2d1c588156d..461dce21de2b0 100644
--- a/drivers/staging/wireless/atmel/atmel.c
+++ b/drivers/staging/wireless/atmel/atmel.c
@@ -571,7 +571,6 @@ static const struct {
  { REG_DOMAIN_ISRAEL, 3, 9, "Israel"} };
 
 static void build_wpa_mib(struct atmel_private *priv);
-static int atmel_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
 static void atmel_copy_to_card(struct net_device *dev, u16 dest,
   const unsigned char *src, u16 len);
 static void atmel_copy_to_host(struct net_device *dev, unsigned char *dest,
@@ -1487,7 +1486,6 @@ static const struct net_device_ops atmel_netdev_ops = {
.ndo_stop   = atmel_close,
.ndo_set_mac_address= atmel_set_mac_address,
.ndo_start_xmit = start_tx,
-   .ndo_do_ioctl   = atmel_ioctl,
.ndo_validate_addr  = eth_validate_addr,
 };
 
@@ -2616,76 +2614,6 @@ static const struct iw_handler_def atmel_handler_def = {
.get_wireless_stats = atmel_get_wireless_stats
 };
 
-static int atmel_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
-{
-   int i, rc = 0;
-   struct atmel_private *priv = netdev_priv(dev);
-   struct atmel_priv_ioctl com;
-   struct iwreq *wrq = (struct iwreq *) rq;
-   unsigned char *new_firmware;
-   char domain[REGDOMAINSZ + 1];
-
-   switch (cmd) {
-   case ATMELIDIFC:
-   wrq->u.param.value = ATMELMAGIC;
-   break;
-
-   case ATMELFWL:
-   if (copy_from_user(&com, rq->ifr_data, sizeof(com))) {
-   rc = -EFAULT;
-   break;
-   }
-
-   if (!capable(CAP_NET_ADMIN)) {
-   rc = -EPERM;
-   break;
-   }
-
-   new_firmware = memdup_user(com.data, com.len);
-   if (IS_ERR(new_firmware)) {
-   rc = PTR_ERR(new_firmware);
-   break;
-   }
-
-   kfree(priv->firmware);
-
-   priv->firmware = new_firmware;
-   priv->firmware_length = com.len;
-   strncpy(priv->firmware_id, com.id, 31);
-   priv->firmware_id[31] = '\0';
-   break;
-
-   case ATMELRD:
-   if (copy_from_user(domain, rq->ifr_data, REGDOMAINSZ)) {
-   rc = -EFAULT;
-   break;
-   }
-
-   if (!capable(CAP_NET_ADMIN)) {
-   rc = -EPERM;
-   break;
-   }
-
-   domain[REGDOMAINSZ] = 0;
-   rc = -EINVAL;
-   for (i = 0; i < ARRAY_SIZE(channel_table); i++) {
-   if (!strcasecmp(channel_table[i].name, domain)) {
-   priv->config_reg_domain = 
channel_table[i].reg_domain;
-   rc = 0;
-   }
-   }
-
-   if (rc == 0 &&  priv->station_state != STATION_STATE_DOWN)
-   rc = atmel_open(dev);
-   break;
-
-   default:
-   rc = -EOPNOTSUPP;
-   }
-
-   return rc;
-}
-
 struct auth_body {
__le16 alg;
__le16 trans_seq;
-- 
2.39.2

[PATCH v2 07/10] staging: rtl8723bs: remove dead code

[Arnd Bergmann]

From: Arnd Bergmann 

The .ndo_do_ioctl functions are never called, so the three implementation here
is useless but only works as a way to identify the device in the notifiers,
which can really be removed as well.

Looking through the exported functions, I found a bunch more that have
no callers, so just drop all of those.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/rtl8723bs/Makefile|1 -
 .../staging/rtl8723bs/include/osdep_intf.h|   32 -
 drivers/staging/rtl8723bs/include/rtw_io.h|1 -
 .../staging/rtl8723bs/os_dep/ioctl_linux.c| 1300 -
 drivers/staging/rtl8723bs/os_dep/os_intfs.c   |   29 -
 drivers/staging/rtl8723bs/os_dep/sdio_intf.c  |   23 +-
 6 files changed, 1 insertion(+), 1385 deletions(-)
 delete mode 100644 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c

diff --git a/drivers/staging/rtl8723bs/Makefile 
b/drivers/staging/rtl8723bs/Makefile
index 590bde02058c7..0f3f6dea4955e 100644
--- a/drivers/staging/rtl8723bs/Makefile
+++ b/drivers/staging/rtl8723bs/Makefile
@@ -50,7 +50,6 @@ r8723bs-y = \
hal/HalHWImg8723B_RF.o \
hal/HalPhyRf_8723B.o \
os_dep/ioctl_cfg80211.o \
-   os_dep/ioctl_linux.o \
os_dep/mlme_linux.o \
os_dep/osdep_service.o \
os_dep/os_intfs.o \
diff --git a/drivers/staging/rtl8723bs/include/osdep_intf.h 
b/drivers/staging/rtl8723bs/include/osdep_intf.h
index 111e0179712ac..83a25598e9627 100644
--- a/drivers/staging/rtl8723bs/include/osdep_intf.h
+++ b/drivers/staging/rtl8723bs/include/osdep_intf.h
@@ -8,33 +8,6 @@
 #ifndef __OSDEP_INTF_H_
 #define __OSDEP_INTF_H_
 
-
-struct intf_priv {
-
-   u8 *intf_dev;
-   u32 max_iosz;   /* USB2.0: 128, USB1.1: 64, SDIO:64 */
-   u32 max_xmitsz; /* USB2.0: unlimited, SDIO:512 */
-   u32 max_recvsz; /* USB2.0: unlimited, SDIO:512 */
-
-   volatile u8 *io_rwmem;
-   volatile u8 *allocated_io_rwmem;
-   u32 io_wsz; /* unit: 4bytes */
-   u32 io_rsz;/* unit: 4bytes */
-   u8 intf_status;
-
-   void (*_bus_io)(u8 *priv);
-
-/*
-Under Sync. IRP (SDIO/USB)
-A protection mechanism is necessary for the io_rwmem(read/write protocol)
-
-Under Async. IRP (SDIO/USB)
-The protection mechanism is through the pending queue.
-*/
-
-   struct mutex ioctl_mutex;
-};
-
 struct dvobj_priv *devobj_init(void);
 void devobj_deinit(struct dvobj_priv *pdvobj);
 
@@ -47,17 +20,12 @@ u32 rtw_start_drv_threads(struct adapter *padapter);
 void rtw_stop_drv_threads(struct adapter *padapter);
 void rtw_cancel_all_timer(struct adapter *padapter);
 
-int rtw_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
-
 int rtw_init_netdev_name(struct net_device *pnetdev, const char *ifname);
 struct net_device *rtw_init_netdev(struct adapter *padapter);
 void rtw_unregister_netdevs(struct dvobj_priv *dvobj);
 
 u16 rtw_recv_select_queue(struct sk_buff *skb);
 
-int rtw_ndev_notifier_register(void);
-void rtw_ndev_notifier_unregister(void);
-
 void rtw_ips_dev_unload(struct adapter *padapter);
 
 int rtw_ips_pwr_up(struct adapter *padapter);
diff --git a/drivers/staging/rtl8723bs/include/rtw_io.h 
b/drivers/staging/rtl8723bs/include/rtw_io.h
index e98083a07a660..f92093e73fe67 100644
--- a/drivers/staging/rtl8723bs/include/rtw_io.h
+++ b/drivers/staging/rtl8723bs/include/rtw_io.h
@@ -72,7 +72,6 @@
 
 #define _INTF_ASYNC_   BIT(0)  /* support async io */
 
-struct intf_priv;
 struct intf_hdl;
 struct io_queue;
 
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
deleted file mode 100644
index c81b30f1f1b05..0
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ /dev/null
@@ -1,1300 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/**
- *
- * Copyright(c) 2007 - 2012 Realtek Corporation. All rights reserved.
- *
- 
**/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define RTL_IOCTL_WPA_SUPPLICANT   (SIOCIWFIRSTPRIV + 30)
-
-static int wpa_set_auth_algs(struct net_device *dev, u32 value)
-{
-   struct adapter *padapter = rtw_netdev_priv(dev);
-   int ret = 0;
-
-   if ((value & IW_AUTH_ALG_SHARED_KEY) && (value & 
IW_AUTH_ALG_OPEN_SYSTEM)) {
-   padapter->securitypriv.ndisencryptstatus = 
Ndis802_11Encryption1Enabled;
-   padapter->securitypriv.ndisauthtype = 
Ndis802_11AuthModeAutoSwitch;
-   padapter->securitypriv.dot11AuthAlgrthm = dot11AuthAlgrthm_Auto;
-   } else if (value & IW_AUTH_ALG_SHARED_KEY)  {
-   padapter->securitypriv.ndisencryptstatus = 
Ndis802_11Encryption1Enabled;
-
-   padapter->securitypriv.ndisauthtype = Ndis802_11AuthModeShared;
-   pada

[PATCH v2 06/10] staging: rtl8712: remove unused legacy ioctl handlers

[Arnd Bergmann]

From: Arnd Bergmann 

The .ndo_do_ioctl functions are never called, and can just be removed,
especially since this is a staging driver.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/rtl8712/os_intfs.c|   1 -
 drivers/staging/rtl8712/osdep_intf.h  |   2 -
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 124 --
 3 files changed, 127 deletions(-)

diff --git a/drivers/staging/rtl8712/os_intfs.c 
b/drivers/staging/rtl8712/os_intfs.c
index b18e6d9c832b8..121edffbd2507 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -191,7 +191,6 @@ static const struct net_device_ops rtl8712_netdev_ops = {
.ndo_start_xmit = r8712_xmit_entry,
.ndo_set_mac_address = r871x_net_set_mac_address,
.ndo_get_stats = r871x_net_get_stats,
-   .ndo_do_ioctl = r871x_ioctl,
 };
 
 struct net_device *r8712_init_netdev(void)
diff --git a/drivers/staging/rtl8712/osdep_intf.h 
b/drivers/staging/rtl8712/osdep_intf.h
index 9e75116c987ec..ce823030bfec2 100644
--- a/drivers/staging/rtl8712/osdep_intf.h
+++ b/drivers/staging/rtl8712/osdep_intf.h
@@ -27,6 +27,4 @@ struct intf_priv {
struct completion io_retevt_comp;
 };
 
-int r871x_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
-
 #endif /*_OSDEP_INTF_H_*/
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 36f6904d25abc..a4a34c9f00b84 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -36,8 +36,6 @@
 #include 
 #include 
 
-#define RTL_IOCTL_WPA_SUPPLICANT   (SIOCIWFIRSTPRIV + 0x1E)
-
 #define SCAN_ITEM_SIZE 768
 #define MAX_CUSTOM_LEN 64
 #define RATE_COUNT 4
@@ -2066,128 +2064,6 @@ static int r871x_wps_start(struct net_device *dev,
return 0;
 }
 
-static int wpa_set_param(struct net_device *dev, u8 name, u32 value)
-{
-   struct _adapter *padapter = netdev_priv(dev);
-
-   switch (name) {
-   case IEEE_PARAM_WPA_ENABLED:
-   padapter->securitypriv.AuthAlgrthm = 2; /* 802.1x */
-   switch ((value) & 0xff) {
-   case 1: /* WPA */
-   padapter->securitypriv.ndisauthtype =
-   Ndis802_11AuthModeWPAPSK; /* WPA_PSK */
-   padapter->securitypriv.ndisencryptstatus =
-   Ndis802_11Encryption2Enabled;
-   break;
-   case 2: /* WPA2 */
-   padapter->securitypriv.ndisauthtype =
-   Ndis802_11AuthModeWPA2PSK; /* WPA2_PSK */
-   padapter->securitypriv.ndisencryptstatus =
-   Ndis802_11Encryption3Enabled;
-   break;
-   }
-   break;
-   case IEEE_PARAM_TKIP_COUNTERMEASURES:
-   break;
-   case IEEE_PARAM_DROP_UNENCRYPTED:
-   /* HACK:
-*
-* wpa_supplicant calls set_wpa_enabled when the driver
-* is loaded and unloaded, regardless of if WPA is being
-* used.  No other calls are made which can be used to
-* determine if encryption will be used or not prior to
-* association being expected.  If encryption is not being
-* used, drop_unencrypted is set to false, else true -- we
-* can use this to determine if the CAP_PRIVACY_ON bit should
-* be set.
-*/
-   break;
-   case IEEE_PARAM_PRIVACY_INVOKED:
-   break;
-   case IEEE_PARAM_AUTH_ALGS:
-   return wpa_set_auth_algs(dev, value);
-   case IEEE_PARAM_IEEE_802_1X:
-   break;
-   case IEEE_PARAM_WPAX_SELECT:
-   /* added for WPA2 mixed mode */
-   break;
-   default:
-   return -EOPNOTSUPP;
-   }
-   return 0;
-}
-
-static int wpa_mlme(struct net_device *dev, u32 command, u32 reason)
-{
-   struct _adapter *padapter = netdev_priv(dev);
-
-   switch (command) {
-   case IEEE_MLME_STA_DEAUTH:
-   if (!r8712_set_802_11_disassociate(padapter))
-   return -1;
-   break;
-   case IEEE_MLME_STA_DISASSOC:
-   if (!r8712_set_802_11_disassociate(padapter))
-   return -1;
-   break;
-   default:
-   return -EOPNOTSUPP;
-   }
-   return 0;
-}
-
-static int wpa_supplicant_ioctl(struct net_device *dev, struct iw_point *p)
-{
-   struct ieee_param *param;
-   int ret = 0;
-   struct _adapter *padapter = netdev_priv(dev);
-
-   if (p->length < sizeof(struct ieee_param) || !p->pointer)
-   return -EINVAL;
-   param = memdup_user(p->pointer, p->length);
-   if (IS_ERR(param))
- 

[PATCH v2 04/10] staging: ks7010: remove unused ioctl handler

[Arnd Bergmann]

From: Arnd Bergmann 

The ndo_do_ioctl function has no actual callers, and doesn't do much here,
so just remove it entirely as preparation for removing the callback pointer
from net_device_ops.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/ks7010/ks_wlan_net.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 0fb97a79ad0b3..ab7463bb25169 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -51,8 +51,6 @@ static int ks_wlan_close(struct net_device *dev);
 static void ks_wlan_set_rx_mode(struct net_device *dev);
 static struct net_device_stats *ks_wlan_get_stats(struct net_device *dev);
 static int ks_wlan_set_mac_address(struct net_device *dev, void *addr);
-static int ks_wlan_netdev_ioctl(struct net_device *dev, struct ifreq *rq,
-   int cmd);
 
 static atomic_t update_phyinfo;
 static struct timer_list update_phyinfo_timer;
@@ -2458,24 +2456,6 @@ static const struct iw_handler_def ks_wlan_handler_def = 
{
.get_wireless_stats = ks_get_wireless_stats,
 };
 
-static int ks_wlan_netdev_ioctl(struct net_device *dev, struct ifreq *rq,
-   int cmd)
-{
-   int ret;
-   struct iwreq *wrq = (struct iwreq *)rq;
-
-   switch (cmd) {
-   case SIOCIWFIRSTPRIV + 20:  /* KS_WLAN_SET_STOP_REQ */
-   ret = ks_wlan_set_stop_request(dev, NULL, &wrq->u, NULL);
-   break;
-   // All other calls are currently unsupported
-   default:
-   ret = -EOPNOTSUPP;
-   }
-
-   return ret;
-}
-
 static
 struct net_device_stats *ks_wlan_get_stats(struct net_device *dev)
 {
@@ -2608,7 +2588,6 @@ static const struct net_device_ops ks_wlan_netdev_ops = {
.ndo_start_xmit = ks_wlan_start_xmit,
.ndo_open = ks_wlan_open,
.ndo_stop = ks_wlan_close,
-   .ndo_do_ioctl = ks_wlan_netdev_ioctl,
.ndo_set_mac_address = ks_wlan_set_mac_address,
.ndo_get_stats = ks_wlan_get_stats,
.ndo_tx_timeout = ks_wlan_tx_timeout,
-- 
2.39.2

[PATCH v2 05/10] staging: rtl8192: remove unused legacy ioctl handlers

[Arnd Bergmann]

From: Arnd Bergmann 

The .ndo_do_ioctl functions are never called, and can just be removed,
especially since this is a staging driver.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/rtl8192u/ieee80211/dot11d.c   |  41 --
 drivers/staging/rtl8192u/ieee80211/dot11d.h   |   2 -
 .../staging/rtl8192u/ieee80211/ieee80211.h|  12 -
 .../rtl8192u/ieee80211/ieee80211_softmac.c| 563 --
 drivers/staging/rtl8192u/r8192U.h |   2 -
 drivers/staging/rtl8192u/r8192U_core.c| 109 
 6 files changed, 729 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c 
b/drivers/staging/rtl8192u/ieee80211/dot11d.c
index ddaf66fa0f936..8a72c1e9eb1e1 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.c
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.c
@@ -97,22 +97,6 @@ void dot11d_update_country_ie(struct ieee80211_device *dev, 
u8 *pTaddr,
 }
 EXPORT_SYMBOL(dot11d_update_country_ie);
 
-u8 dot11d_get_max_tx_pwr_in_dbm(struct ieee80211_device *dev, u8 Channel)
-{
-   struct rt_dot11d_info *dot11d_info = GET_DOT11D_INFO(dev);
-   u8 MaxTxPwrInDbm = 255;
-
-   if (Channel > MAX_CHANNEL_NUMBER) {
-   netdev_err(dev->dev, "%s: Invalid Channel\n", __func__);
-   return MaxTxPwrInDbm;
-   }
-   if (dot11d_info->channel_map[Channel])
-   MaxTxPwrInDbm = dot11d_info->max_tx_pwr_dbm_list[Channel];
-
-   return MaxTxPwrInDbm;
-}
-EXPORT_SYMBOL(dot11d_get_max_tx_pwr_in_dbm);
-
 void dot11d_scan_complete(struct ieee80211_device *dev)
 {
struct rt_dot11d_info *dot11d_info = GET_DOT11D_INFO(dev);
@@ -147,28 +131,3 @@ int is_legal_channel(struct ieee80211_device *dev, u8 
channel)
return 0;
 }
 EXPORT_SYMBOL(is_legal_channel);
-
-int to_legal_channel(struct ieee80211_device *dev, u8 channel)
-{
-   struct rt_dot11d_info *dot11d_info = GET_DOT11D_INFO(dev);
-   u8 default_chn = 0;
-   u32 i = 0;
-
-   for (i = 1; i <= MAX_CHANNEL_NUMBER; i++) {
-   if (dot11d_info->channel_map[i] > 0) {
-   default_chn = i;
-   break;
-   }
-   }
-
-   if (channel > MAX_CHANNEL_NUMBER) {
-   netdev_err(dev->dev, "%s: Invalid Channel\n", __func__);
-   return default_chn;
-   }
-
-   if (dot11d_info->channel_map[channel] > 0)
-   return channel;
-
-   return default_chn;
-}
-EXPORT_SYMBOL(to_legal_channel);
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.h 
b/drivers/staging/rtl8192u/ieee80211/dot11d.h
index 8b485fa180898..fd774265211a5 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.h
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.h
@@ -49,9 +49,7 @@ void dot11d_update_country_ie(struct ieee80211_device *dev,
  u8 *addr,
  u16 coutry_ie_len,
  u8 *coutry_ie);
-u8 dot11d_get_max_tx_pwr_in_dbm(struct ieee80211_device *dev, u8 channel);
 void dot11d_scan_complete(struct ieee80211_device *dev);
 int is_legal_channel(struct ieee80211_device *dev, u8 channel);
-int to_legal_channel(struct ieee80211_device *dev, u8 channel);
 
 #endif /* #ifndef __INC_DOT11D_H */
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 694d1b18f81c7..fc4201757c408 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -223,11 +223,7 @@ struct cb_desc {
 #define MAX_IE_LEN  0xff
 
 // added for kernel conflict
-#define ieee80211_wake_queue   ieee80211_wake_queue_rsl
-#define ieee80211_stop_queue   ieee80211_stop_queue_rsl
 #define notify_wx_assoc_event  notify_wx_assoc_event_rsl
-#define SendDisassociation SendDisassociation_rsl
-
 
 struct ieee_param {
u32 cmd;
@@ -2152,7 +2148,6 @@ int ieee80211_wx_set_gen_ie(struct ieee80211_device 
*ieee, u8 *ie, size_t len);
 
 /* ieee80211_softmac.c */
 short ieee80211_is_54g(const struct ieee80211_network *net);
-short ieee80211_is_shortslot(const struct ieee80211_network *net);
 int ieee80211_rx_frame_softmac(struct ieee80211_device *ieee,
   struct sk_buff *skb,
   struct ieee80211_rx_stats *rx_stats,
@@ -2160,7 +2155,6 @@ int ieee80211_rx_frame_softmac(struct ieee80211_device 
*ieee,
 void ieee80211_softmac_new_net(struct ieee80211_device *ieee,
   struct ieee80211_network *net);
 
-void SendDisassociation(struct ieee80211_device *ieee, u8 *asSta, u8 asRsn);
 void ieee80211_softmac_xmit(struct ieee80211_txb *txb,
struct ieee80211_device *ieee);
 
@@ -2182,13 +2176,7 @@ void ieee80211_stop_protocol(struct ieee80211_device 
*ieee);
 void ieee80211_softmac_start_protocol(struct ieee80211_device *ieee);
 void ieee8021

[PATCH v2 03/10] ethernet: sp7021: fix ioctl callback pointer

[Arnd Bergmann]

From: Arnd Bergmann 

The old .ndo_do_ioctl() callback is never called any more, instead the
driver should set .ndo_eth_ioctl() for the phy operations.

Fixes: fd3040b9394c5 ("net: ethernet: Add driver for Sunplus SP7021")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/sunplus/spl2sw_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sunplus/spl2sw_driver.c 
b/drivers/net/ethernet/sunplus/spl2sw_driver.c
index 391a1bc7f4463..bb4514f4e8157 100644
--- a/drivers/net/ethernet/sunplus/spl2sw_driver.c
+++ b/drivers/net/ethernet/sunplus/spl2sw_driver.c
@@ -199,7 +199,7 @@ static const struct net_device_ops netdev_ops = {
.ndo_start_xmit = spl2sw_ethernet_start_xmit,
.ndo_set_rx_mode = spl2sw_ethernet_set_rx_mode,
.ndo_set_mac_address = spl2sw_ethernet_set_mac_address,
-   .ndo_do_ioctl = phy_do_ioctl,
+   .ndo_eth_ioctl = phy_do_ioctl,
.ndo_tx_timeout = spl2sw_ethernet_tx_timeout,
 };
 
-- 
2.39.2

[PATCH v2 02/10] ieee802154: avoid deprecated .ndo_do_ioctl callback

[Arnd Bergmann]

From: Arnd Bergmann 

The ieee802154 socket implementation is the last remaining caller of the
netdevice ioctl callback. In order to completely remove this, add a custom
pointer to the existing wpan_dev specific operations structure. Since that
structure is currently only used to wrap the 'create' header operation,
adjust the naming slightly to make this more generic.

It would be a good idea to adjust the calling conventions and split the
get/set operations into separate functions, but that can be a follow-up
cleanup. For the moment, I kept the actual changes to a minimum to
avoid regressions.

Signed-off-by: Arnd Bergmann 
---
 include/net/cfg802154.h | 9 +
 net/ieee802154/socket.c | 5 +++--
 net/mac802154/iface.c   | 8 
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index f79ce133e51a7..e604df98e2ee9 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -433,15 +433,16 @@ struct ieee802154_llsec_device_key {
u32 frame_counter;
 };
 
-struct wpan_dev_header_ops {
+struct wpan_dev_ops {
/* TODO create callback currently assumes ieee802154_mac_cb inside
 * skb->cb. This should be changed to give these information as
 * parameter.
 */
-   int (*create)(struct sk_buff *skb, struct net_device *dev,
+   int (*header_create)(struct sk_buff *skb, struct net_device *dev,
  const struct ieee802154_addr *daddr,
  const struct ieee802154_addr *saddr,
  unsigned int len);
+   int (*ioctl)(struct net_device *dev, struct ifreq *ifr, int cmd);
 };
 
 struct wpan_dev {
@@ -452,7 +453,7 @@ struct wpan_dev {
struct list_head list;
struct net_device *netdev;
 
-   const struct wpan_dev_header_ops *header_ops;
+   const struct wpan_dev_ops *ops;
 
/* lowpan interface, set when the wpan_dev belongs to one lowpan_dev */
struct net_device *lowpan_dev;
@@ -491,7 +492,7 @@ wpan_dev_hard_header(struct sk_buff *skb, struct net_device 
*dev,
 {
struct wpan_dev *wpan_dev = dev->ieee802154_ptr;
 
-   return wpan_dev->header_ops->create(skb, dev, daddr, saddr, len);
+   return wpan_dev->ops->header_create(skb, dev, daddr, saddr, len);
 }
 #endif
 
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index 00302e8b9615b..27e58237091ca 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -139,8 +139,9 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct 
ifreq __user *arg,
if (!dev)
return -ENODEV;
 
-   if (dev->type == ARPHRD_IEEE802154 && dev->netdev_ops->ndo_do_ioctl)
-   ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
+   if (dev->type == ARPHRD_IEEE802154 && dev->ieee802154_ptr &&
+   dev->ieee802154_ptr->ops)
+   ret = dev->ieee802154_ptr->ops->ioctl(dev, &ifr, cmd);
 
if (!ret && put_user_ifreq(&ifr, arg))
ret = -EFAULT;
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index c0e2da5072bea..4937f8c2fb4cc 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -406,8 +406,9 @@ static int ieee802154_header_create(struct sk_buff *skb,
return hlen;
 }
 
-static const struct wpan_dev_header_ops ieee802154_header_ops = {
-   .create = ieee802154_header_create,
+static const struct wpan_dev_ops ieee802154_ops = {
+   .header_create  = ieee802154_header_create,
+   .ioctl  = mac802154_wpan_ioctl,
 };
 
 /* This header create functionality assumes a 8 byte array for
@@ -495,7 +496,6 @@ static const struct net_device_ops mac802154_wpan_ops = {
.ndo_open   = mac802154_wpan_open,
.ndo_stop   = mac802154_slave_close,
.ndo_start_xmit = ieee802154_subif_start_xmit,
-   .ndo_do_ioctl   = mac802154_wpan_ioctl,
.ndo_set_mac_address= mac802154_wpan_mac_addr,
 };
 
@@ -581,7 +581,7 @@ ieee802154_setup_sdata(struct ieee802154_sub_if_data *sdata,
sdata->dev->netdev_ops = &mac802154_wpan_ops;
sdata->dev->ml_priv = &mac802154_mlme_wpan;
sdata->iface_default_filtering = 
IEEE802154_FILTERING_4_FRAME_FIELDS;
-   wpan_dev->header_ops = &ieee802154_header_ops;
+   wpan_dev->ops = &ieee802154_ops;
 
mutex_init(&sdata->sec_mtx);
 
-- 
2.39.2

[PATCH v2 01/10] appletalk: make localtalk and ppp support conditional

[Arnd Bergmann]

From: Arnd Bergmann 

The last localtalk driver is gone now, and ppp support was never fully
merged, but the code to support them for phase1 networking still calls
the deprecated .ndo_do_ioctl() helper.

In order to better isolate the localtalk and ppp portions of appletalk,
guard all of the corresponding code with CONFIG_DEV_APPLETALK checks,
including a preprocessor conditional that guards the internal ioctl calls.

This is currently all dead code and will now be left out of the
module since this Kconfig symbol is always undefined, but there are
plans to add a new driver for localtalk again in the future. When
that happens, the logic can be cleaned up to work properly without
the need for the ioctl.

Link: 
https://lore.kernel.org/lkml/790ba488-b6f6-41ed-96ef-2089ef1c0...@xhero.org/
Signed-off-by: Arnd Bergmann 
---
v2: only add compile-time consitionals rather than removing localtalk
support entirely
---
 include/linux/atalk.h  |  1 -
 net/appletalk/Makefile |  3 ++-
 net/appletalk/aarp.c   | 24 +++-
 net/appletalk/ddp.c| 24 +---
 4 files changed, 30 insertions(+), 22 deletions(-)

diff --git a/include/linux/atalk.h b/include/linux/atalk.h
index a55bfc6567d01..2896f2ac9568e 100644
--- a/include/linux/atalk.h
+++ b/include/linux/atalk.h
@@ -121,7 +121,6 @@ static inline struct atalk_iface *atalk_find_dev(struct 
net_device *dev)
 #endif
 
 extern struct atalk_addr *atalk_find_dev_addr(struct net_device *dev);
-extern struct net_device *atrtr_get_dev(struct atalk_addr *sa);
 extern int  aarp_send_ddp(struct net_device *dev,
   struct sk_buff *skb,
   struct atalk_addr *sa, void *hwaddr);
diff --git a/net/appletalk/Makefile b/net/appletalk/Makefile
index 33164d972d379..410d52f9113e2 100644
--- a/net/appletalk/Makefile
+++ b/net/appletalk/Makefile
@@ -5,6 +5,7 @@
 
 obj-$(CONFIG_ATALK) += appletalk.o
 
-appletalk-y:= aarp.o ddp.o dev.o
+appletalk-y:= aarp.o ddp.o
 appletalk-$(CONFIG_PROC_FS)+= atalk_proc.o
 appletalk-$(CONFIG_SYSCTL) += sysctl_net_atalk.o
+appletalk-$(CONFIG_DEV_APPLETALK) += dev.o
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 9fa0b246902be..b15f67293ac4c 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -438,14 +438,17 @@ static struct atalk_addr *__aarp_proxy_find(struct 
net_device *dev,
  */
 static void aarp_send_probe_phase1(struct atalk_iface *iface)
 {
+#if IS_ENABLED(CONFIG_DEV_APPLETALK)
struct ifreq atreq;
struct sockaddr_at *sa = (struct sockaddr_at *)&atreq.ifr_addr;
const struct net_device_ops *ops = iface->dev->netdev_ops;
 
sa->sat_addr.s_node = iface->address.s_node;
sa->sat_addr.s_net = ntohs(iface->address.s_net);
-
-   /* We pass the Net:Node to the drivers/cards by a Device ioctl. */
+   /*
+* We used to pass the address via device ioctl, this has to
+*  be rewritten if we bring back localtalk.
+*/
if (!(ops->ndo_do_ioctl(iface->dev, &atreq, SIOCSIFADDR))) {
ops->ndo_do_ioctl(iface->dev, &atreq, SIOCGIFADDR);
if (iface->address.s_net != htons(sa->sat_addr.s_net) ||
@@ -455,13 +458,15 @@ static void aarp_send_probe_phase1(struct atalk_iface 
*iface)
iface->address.s_net  = htons(sa->sat_addr.s_net);
iface->address.s_node = sa->sat_addr.s_node;
}
+#endif
 }
 
 
 void aarp_probe_network(struct atalk_iface *atif)
 {
-   if (atif->dev->type == ARPHRD_LOCALTLK ||
-   atif->dev->type == ARPHRD_PPP)
+   if (IS_ENABLED(CONFIG_DEV_APPLETALK) &&
+   (atif->dev->type == ARPHRD_LOCALTLK ||
+atif->dev->type == ARPHRD_PPP))
aarp_send_probe_phase1(atif);
else {
unsigned int count;
@@ -488,8 +493,9 @@ int aarp_proxy_probe_network(struct atalk_iface *atif, 
struct atalk_addr *sa)
 * we don't currently support LocalTalk or PPP for proxy AARP;
 * if someone wants to try and add it, have fun
 */
-   if (atif->dev->type == ARPHRD_LOCALTLK ||
-   atif->dev->type == ARPHRD_PPP)
+   if (IS_ENABLED(CONFIG_DEV_APPLETALK) &&
+   (atif->dev->type == ARPHRD_LOCALTLK ||
+atif->dev->type == ARPHRD_PPP))
goto out;
 
/*
@@ -550,7 +556,8 @@ int aarp_send_ddp(struct net_device *dev, struct sk_buff 
*skb,
skb_reset_network_header(skb);
 
/* Check for LocalTalk first */
-   if (dev->type == ARPHRD_LOCALTLK) {
+   if (IS_ENABLED(CONFIG_DEV_APPLETALK) &&
+   dev->type == ARPHRD_LOCALTLK) {
struct atalk_addr *at = atalk_find_dev_addr(dev);
struct ddpehdr *ddp = (struct ddpehdr *)skb->data;
  

Re: [PATCH v3 0/8] drivers: add new variants of devm_platform_ioremap_resource()

[Arnd Bergmann]

On Mon, Oct 21, 2019 at 6:29 PM Bartosz Golaszewski  wrote:
> pon., 21 paź 2019 o 17:53 Arnd Bergmann  napisał(a):
> > On Mon, Oct 21, 2019 at 5:04 PM Bartosz Golaszewski  wrote:
> > > gentle ping for this. I noticed that some maintainers are complaining
> > > about being spammed with patches converting old drivers to using
> > > devm_platform_ioremap_resource() and there's even a patch removing the
> > > relevant coccinelle script on the list, but I think for new drivers
> > > these are still useful. Do you want to pick them up for v5.5 (or at
> > > all)?
> >
> > I think this series is useful and we should merge it. Are there any
> > remaining dependencies or conflicts with Christoph Hellwig's recent
> > __ioremap rework? If there are, I would prioritize his work and maybe
> > delay this one by another merge window, otherwise please add
> > my Reviewed-by to all patches and resend them for Greg to pick
> > up (provided he has no objections).
>
> Is Christoph's work in next? The series doesn't apply cleanly on next,
> I needed to fix a couple conflicts. What branch should I rebase it on
> before resending?

Not sure, maybe Christoph can comment.

Your patches would best go through the char-misc tree and be based
on top of that, for Christoph's I think the idea is to have some go
through the architecture maintainer trees, and have whatever is
left go through my asm-generic tree.

  Arnd

Re: [PATCH v3 0/8] drivers: add new variants of devm_platform_ioremap_resource()

[Arnd Bergmann]

On Mon, Oct 21, 2019 at 5:04 PM Bartosz Golaszewski  wrote:
> niedz., 6 paź 2019 o 07:39 Bartosz Golaszewski  napisał(a):
> > From: Bartosz Golaszewski 
> > Bartosz Golaszewski (8):
> >   Documentation: devres: add missing entry for
> > devm_platform_ioremap_resource()
> >   lib: devres: prepare devm_ioremap_resource() for more variants
> >   lib: devres: provide devm_ioremap_resource_wc()
> >   drivers: platform: provide devm_platform_ioremap_resource_wc()
> >   misc: sram: use devm_platform_ioremap_resource_wc()
> >   drivers: provide devm_platform_ioremap_resource_byname()
> >   gpio: mvebu: use devm_platform_ioremap_resource_byname()
> >   gpio: tegra186: use devm_platform_ioremap_resource_byname()
> >
> >  .../driver-api/driver-model/devres.rst|  4 ++
> >  drivers/base/platform.c   | 39 +++-
> >  drivers/gpio/gpio-mvebu.c | 19 +++---
> >  drivers/gpio/gpio-tegra186.c  |  4 +-
> >  drivers/misc/sram.c   | 28 +++--
> >  include/linux/device.h|  2 +
> >  include/linux/platform_device.h   |  6 ++
> >  lib/devres.c  | 62 +--
> >  8 files changed, 108 insertions(+), 56 deletions(-)
>
> Greg, Arnd,
>
> gentle ping for this. I noticed that some maintainers are complaining
> about being spammed with patches converting old drivers to using
> devm_platform_ioremap_resource() and there's even a patch removing the
> relevant coccinelle script on the list, but I think for new drivers
> these are still useful. Do you want to pick them up for v5.5 (or at
> all)?

I think this series is useful and we should merge it. Are there any
remaining dependencies or conflicts with Christoph Hellwig's recent
__ioremap rework? If there are, I would prioritize his work and maybe
delay this one by another merge window, otherwise please add
my Reviewed-by to all patches and resend them for Greg to pick
up (provided he has no objections).

Arnd

Re: [PATCH 3/9] lib: devres: provide new variants for devm_ioremap_resource()

[Arnd Bergmann]

On Thu, Aug 29, 2019 at 4:38 PM Bartosz Golaszewski  wrote:

> @@ -710,6 +710,10 @@ extern void devm_free_pages(struct device *dev, unsigned 
> long addr);
>
>  void __iomem *devm_ioremap_resource(struct device *dev,
> const struct resource *res);
> +void __iomem *devm_ioremap_resource_nocache(struct device *dev,
> +   const struct resource *res);
> +void __iomem *devm_ioremap_resource_wc(struct device *dev,
> +  const struct resource *res);
>
>  void __iomem *devm_of_iomap(struct device *dev,
> struct device_node *node, int index,
> diff --git a/lib/devres.c b/lib/devres.c

I think adding devm_ioremap_resource_wc() and
devm_platform_ioremap_resource_wc() makes sense, but I think we're
better off without devm_ioremap_resource_nocache() and
devm_ioremap_resource_cache().

The only architecture that actually has a difference between
ioremap() and ioremap_nocache() seems to be ia64. I would
generally assume that any driver using ioremap_nocache()
that is not ia64 specific should just use ioremap().

The ia64 version of ioremap() tries to guess whether it needs
a cached or uncached mapping, everyone else always
gets uncached these days.

   Arnd

[PATCH v5 14/18] compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t

[Arnd Bergmann]

The ppp_idle structure is defined in terms of __kernel_time_t, which is
defined as 'long' on all architectures, and this usage is not affected
by the y2038 problem since it transports a time interval rather than an
absolute time.

However, the ppp user space defines the same structure as time_t, which
may be 64-bit wide on new libc versions even on 32-bit architectures.

It's easy enough to just handle both possible structure layouts on
all architectures, to deal with the possibility that a user space ppp
implementation comes with its own ppp_idle structure definition, as well
as to document the fact that the driver is y2038-safe.

Doing this also avoids the need for a special compat mode translation,
since 32-bit and 64-bit kernels now support the same interfaces.  The old
32-bit structure is also available on native 64-bit architectures now,
but this is harmless.

Signed-off-by: Arnd Bergmann 
---
 Documentation/networking/ppp_generic.txt |  2 ++
 drivers/net/ppp/ppp_generic.c| 19 ++
 fs/compat_ioctl.c| 32 ++--
 include/uapi/linux/ppp-ioctl.h   |  2 ++
 include/uapi/linux/ppp_defs.h| 14 +++
 5 files changed, 34 insertions(+), 35 deletions(-)

diff --git a/Documentation/networking/ppp_generic.txt 
b/Documentation/networking/ppp_generic.txt
index 61daf4b39600..fd563aff5fc9 100644
--- a/Documentation/networking/ppp_generic.txt
+++ b/Documentation/networking/ppp_generic.txt
@@ -378,6 +378,8 @@ an interface unit are:
   CONFIG_PPP_FILTER option is enabled, the set of packets which reset
   the transmit and receive idle timers is restricted to those which
   pass the `active' packet filter.
+  Two versions of this command exist, to deal with user space
+  expecting times as either 32-bit or 64-bit time_t seconds.
 
 * PPPIOCSMAXCID sets the maximum connection-ID parameter (and thus the
   number of connection slots) for the TCP header compressor and
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 2ab67bad6224..6b4e227cb002 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -612,7 +612,8 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
struct ppp_file *pf;
struct ppp *ppp;
int err = -EFAULT, val, val2, i;
-   struct ppp_idle idle;
+   struct ppp_idle32 idle32;
+   struct ppp_idle64 idle64;
struct npioctl npi;
int unit, cflags;
struct slcompress *vj;
@@ -735,10 +736,18 @@ static long ppp_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
err = 0;
break;
 
-   case PPPIOCGIDLE:
-   idle.xmit_idle = (jiffies - ppp->last_xmit) / HZ;
-   idle.recv_idle = (jiffies - ppp->last_recv) / HZ;
-   if (copy_to_user(argp, &idle, sizeof(idle)))
+   case PPPIOCGIDLE32:
+idle32.xmit_idle = (jiffies - ppp->last_xmit) / HZ;
+idle32.recv_idle = (jiffies - ppp->last_recv) / HZ;
+if (copy_to_user(argp, &idle32, sizeof(idle32)))
+   break;
+   err = 0;
+   break;
+
+   case PPPIOCGIDLE64:
+   idle64.xmit_idle = (jiffies - ppp->last_xmit) / HZ;
+   idle64.recv_idle = (jiffies - ppp->last_recv) / HZ;
+   if (copy_to_user(argp, &idle64, sizeof(idle64)))
break;
err = 0;
break;
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 0b5a732d7afd..f97cf698cfdd 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -99,33 +99,6 @@ static int sg_grt_trans(struct file *file,
 }
 #endif /* CONFIG_BLOCK */
 
-struct ppp_idle32 {
-   compat_time_t xmit_idle;
-   compat_time_t recv_idle;
-};
-#define PPPIOCGIDLE32  _IOR('t', 63, struct ppp_idle32)
-
-static int ppp_gidle(struct file *file, unsigned int cmd,
-   struct ppp_idle32 __user *idle32)
-{
-   struct ppp_idle __user *idle;
-   __kernel_time_t xmit, recv;
-   int err;
-
-   idle = compat_alloc_user_space(sizeof(*idle));
-
-   err = do_ioctl(file, PPPIOCGIDLE, (unsigned long) idle);
-
-   if (!err) {
-   if (get_user(xmit, &idle->xmit_idle) ||
-   get_user(recv, &idle->recv_idle) ||
-   put_user(xmit, &idle32->xmit_idle) ||
-   put_user(recv, &idle32->recv_idle))
-   err = -EFAULT;
-   }
-   return err;
-}
-
 /*
  * simple reversible transform to make our table more evenly
  * distributed after sorting.
@@ -192,7 +165,8 @@ COMPATIBLE_IOCTL(PPPIOCGDEBUG)
 COMPATIBLE_IOCTL(PPPIOCSDEBUG)
 /* PPPIOCSPASS is translated */
 /* PPPIOCSACTIVE is translated */
-/* PPPIOCGIDLE is translated */
+COMPATIBLE_IOCTL(PPPIOCGIDLE32)
+COMPATIBLE_IOCTL(PPPIOCGID

Re: [PATCH 04/16] watchdog: remove ks8695 driver

[Arnd Bergmann]

On Fri, Aug 9, 2019 at 10:42 PM Guenter Roeck  wrote:
>
> On Fri, Aug 09, 2019 at 10:27:32PM +0200, Arnd Bergmann wrote:
> > The platform is getting removed, so there are no remaining
> > users of this driver.
> >
> > Signed-off-by: Arnd Bergmann 
>
> Acked-by: Guenter Roeck 
>
> Please let me know if this should be applied through the watchdog tree.
> For now I'll assume it will be applied together with the rest of the
> series.

For this series, my preference is that you apply the patches through
the subsystem tree as there are no dependencies.

Thanks,

 Arnd

[PATCH 04/16] watchdog: remove ks8695 driver

[Arnd Bergmann]

The platform is getting removed, so there are no remaining
users of this driver.

Signed-off-by: Arnd Bergmann 
---
 .../watchdog/watchdog-parameters.rst  |   9 -
 drivers/watchdog/Kconfig  |   7 -
 drivers/watchdog/Makefile |   1 -
 drivers/watchdog/ks8695_wdt.c | 319 --
 4 files changed, 336 deletions(-)
 delete mode 100644 drivers/watchdog/ks8695_wdt.c

diff --git a/Documentation/watchdog/watchdog-parameters.rst 
b/Documentation/watchdog/watchdog-parameters.rst
index a3985cc5aeda..226aba56f704 100644
--- a/Documentation/watchdog/watchdog-parameters.rst
+++ b/Documentation/watchdog/watchdog-parameters.rst
@@ -301,15 +301,6 @@ ixp4xx_wdt:
 
 -
 
-ks8695_wdt:
-wdt_time:
-   Watchdog time in seconds. (default=5)
-nowayout:
-   Watchdog cannot be stopped once started
-   (default=kernel config parameter)
-
--
-
 machzwd:
 nowayout:
Watchdog cannot be stopped once started
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8188963a405b..e631f1ae303a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -477,13 +477,6 @@ config IXP4XX_WATCHDOG
 
  Say N if you are unsure.
 
-config KS8695_WATCHDOG
-   tristate "KS8695 watchdog"
-   depends on ARCH_KS8695
-   help
- Watchdog timer embedded into KS8695 processor. This will reboot your
- system when the timeout is reached.
-
 config HAVE_S3C2410_WATCHDOG
bool
help
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7caa920e7e60..85f55ec76f8d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -49,7 +49,6 @@ obj-$(CONFIG_21285_WATCHDOG) += wdt285.o
 obj-$(CONFIG_977_WATCHDOG) += wdt977.o
 obj-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o
 obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
-obj-$(CONFIG_KS8695_WATCHDOG) += ks8695_wdt.o
 obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o
 obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o
 obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o
diff --git a/drivers/watchdog/ks8695_wdt.c b/drivers/watchdog/ks8695_wdt.c
deleted file mode 100644
index 1550ce3c5702..
--- a/drivers/watchdog/ks8695_wdt.c
+++ /dev/null
@@ -1,319 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Watchdog driver for Kendin/Micrel KS8695.
- *
- * (C) 2007 Andrew Victor
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define KS8695_TMR_OFFSET  (0xF + 0xE400)
-#define KS8695_TMR_VA  (KS8695_IO_VA + KS8695_TMR_OFFSET)
-
-/*
- * Timer registers
- */
-#define KS8695_TMCON   (0x00)  /* Timer Control Register */
-#define KS8695_T0TC(0x08)  /* Timer 0 Timeout Count 
Register */
-#define TMCON_T0EN (1 << 0)/* Timer 0 Enable */
-
-/* Timer0 Timeout Counter Register */
-#define T0TC_WATCHDOG  (0xff)  /* Enable watchdog mode */
-
-#define WDT_DEFAULT_TIME   5   /* seconds */
-#define WDT_MAX_TIME   171 /* seconds */
-
-static int wdt_time = WDT_DEFAULT_TIME;
-static bool nowayout = WATCHDOG_NOWAYOUT;
-
-module_param(wdt_time, int, 0);
-MODULE_PARM_DESC(wdt_time, "Watchdog time in seconds. (default="
-   __MODULE_STRING(WDT_DEFAULT_TIME) ")");
-
-#ifdef CONFIG_WATCHDOG_NOWAYOUT
-module_param(nowayout, bool, 0);
-MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
-   __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
-#endif
-
-
-static unsigned long ks8695wdt_busy;
-static DEFINE_SPINLOCK(ks8695_lock);
-
-/* . */
-
-/*
- * Disable the watchdog.
- */
-static inline void ks8695_wdt_stop(void)
-{
-   unsigned long tmcon;
-
-   spin_lock(&ks8695_lock);
-   /* disable timer0 */
-   tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
-   __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
-   spin_unlock(&ks8695_lock);
-}
-
-/*
- * Enable and reset the watchdog.
- */
-static inline void ks8695_wdt_start(void)
-{
-   unsigned long tmcon;
-   unsigned long tval = wdt_time * KS8695_CLOCK_RATE;
-
-   spin_lock(&ks8695_lock);
-   /* disable timer0 */
-   tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
-   __raw_writel(tmcon & ~TMCON_T0EN, KS8695_TMR_VA + KS8695_TMCON);
-
-   /* program timer0 */
-   __raw_writel(tval | T0TC_WATCHDOG, KS8695_TMR_VA + KS8695_T0TC);
-
-   /* re-enable timer0 */
-   tmcon = __raw_readl(KS8695_TMR_VA + KS8695_TMCON);
-

[PATCH 06/16] watchdog: remove w90x900 driver

[Arnd Bergmann]

The ARM w90x900 platform is getting removed, so this driver is obsolete

Signed-off-by: Arnd Bergmann 
---
 .../watchdog/watchdog-parameters.rst  |  10 -
 drivers/watchdog/Kconfig  |   9 -
 drivers/watchdog/Makefile |   1 -
 drivers/watchdog/nuc900_wdt.c | 302 --
 4 files changed, 322 deletions(-)
 delete mode 100644 drivers/watchdog/nuc900_wdt.c

diff --git a/Documentation/watchdog/watchdog-parameters.rst 
b/Documentation/watchdog/watchdog-parameters.rst
index 226aba56f704..223c99361a30 100644
--- a/Documentation/watchdog/watchdog-parameters.rst
+++ b/Documentation/watchdog/watchdog-parameters.rst
@@ -366,16 +366,6 @@ nic7018_wdt:
 
 -
 
-nuc900_wdt:
-heartbeat:
-   Watchdog heartbeats in seconds.
-   (default = 15)
-nowayout:
-   Watchdog cannot be stopped once started
-   (default=kernel config parameter)
-
--
-
 omap_wdt:
 timer_margin:
initial watchdog timeout (in seconds)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e631f1ae303a..0e64f501ef30 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -655,15 +655,6 @@ config STMP3XXX_RTC_WATCHDOG
  To compile this driver as a module, choose M here: the
  module will be called stmp3xxx_rtc_wdt.
 
-config NUC900_WATCHDOG
-   tristate "Nuvoton NUC900 watchdog"
-   depends on ARCH_W90X900 || COMPILE_TEST
-   help
- Say Y here if to include support for the watchdog timer
- for the Nuvoton NUC900 series SoCs.
- To compile this driver as a module, choose M here: the
- module will be called nuc900_wdt.
-
 config TS4800_WATCHDOG
tristate "TS-4800 Watchdog"
depends on HAS_IOMEM && OF
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 85f55ec76f8d..b5a0aed537af 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -63,7 +63,6 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_NPCM7XX_WATCHDOG) += npcm_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
-obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
 obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
 obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
 obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
diff --git a/drivers/watchdog/nuc900_wdt.c b/drivers/watchdog/nuc900_wdt.c
deleted file mode 100644
index db124cebe838..
--- a/drivers/watchdog/nuc900_wdt.c
+++ /dev/null
@@ -1,302 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2009 Nuvoton technology corporation.
- *
- * Wan ZongShun 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define REG_WTCR   0x1c
-#define WTCLK  (0x01 << 10)
-#define WTE(0x01 << 7) /*wdt enable*/
-#define WTIS   (0x03 << 4)
-#define WTIF   (0x01 << 3)
-#define WTRF   (0x01 << 2)
-#define WTRE   (0x01 << 1)
-#define WTR(0x01 << 0)
-/*
- * The watchdog time interval can be calculated via following formula:
- * WTISreal time interval (formula)
- * 0x00((2^ 14 ) * ((external crystal freq) / 256))seconds
- * 0x01((2^ 16 ) * ((external crystal freq) / 256))seconds
- * 0x02((2^ 18 ) * ((external crystal freq) / 256))seconds
- * 0x03((2^ 20 ) * ((external crystal freq) / 256))seconds
- *
- * The external crystal freq is 15Mhz in the nuc900 evaluation board.
- * So 0x00 = +-0.28 seconds, 0x01 = +-1.12 seconds, 0x02 = +-4.48 seconds,
- * 0x03 = +- 16.92 seconds..
- */
-#define WDT_HW_TIMEOUT 0x02
-#define WDT_TIMEOUT(HZ/2)
-#define WDT_HEARTBEAT  15
-
-static int heartbeat = WDT_HEARTBEAT;
-module_param(heartbeat, int, 0);
-MODULE_PARM_DESC(heartbeat, "Watchdog heartbeats in seconds. "
-   "(default = " __MODULE_STRING(WDT_HEARTBEAT) ")");
-
-static bool nowayout = WATCHDOG_NOWAYOUT;
-module_param(nowayout, bool, 0);
-MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
-   "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
-
-struct nuc900_wdt {
-   struct clk   *wdt_clock;
-   struct platform_device *pdev;
-   void __iomem *wdt_base;
-   char expect_close;
-   struct timer_list timer;
-   spinlock_t   wdt_lock;
-   unsigned long next_heartbeat;
-};
-
-static unsigned long nuc900wdt_busy;
-static struct nuc900_wdt *nuc900_wdt;
-
-static inline void nuc900_wdt_keepali

Re: [EXTERNAL][PATCH v15 04/13] mfd/syscon: Add device_node_to_regmap()

[Arnd Bergmann]

On Mon, Jul 29, 2019 at 6:55 PM Paul Burton  wrote:
>
> Lee, Arnd,
>
> On Wed, Jul 24, 2019 at 01:16:06PM -0400, Paul Cercueil wrote:
> > device_node_to_regmap() is exactly like syscon_node_to_regmap(), but it
> > does not check that the node is compatible with "syscon", and won't
> > attach the first clock it finds to the regmap.
> >
> > The rationale behind this, is that one device node with a standard
> > compatible string "foo,bar" can be covered by multiple drivers sharing a
> > regmap, or by a single driver doing all the job without a regmap, but
> > these are implementation details which shouldn't reflect on the
> > devicetree.
>
> Does this looks like a good path forwards to you? Its use in this case
> is described by Documentation/devicetree/bindings/timer/ingenic,tcu.txt
> in patch 3 of the series.
>
> If you're OK with it an ack would be appreciated so I can take the
> series through mips-next, otherwise I guess we'd need to go back to the
> v14 approach.

Yes, I guess this is ok, sorry for missing the submission earlier.

Acked-by: Arnd Bergmann 

[PATCH] Documentation: change linux-4.x references to 5.x

[Arnd Bergmann]

As linux-5.0.x is coming up soon, the documentation should match,
in particular the README.rst file, so change all 4.x references
accordingly. There was a mix of lowercase and uppercase X here,
which I changed to using lowercase consistently.

Signed-off-by: Arnd Bergmann 
---
 Documentation/admin-guide/README.rst  |  32 ++---
 Documentation/process/applying-patches.rst| 117 +-
 .../translations/it_IT/admin-guide/README.rst |   2 +-
 3 files changed, 78 insertions(+), 73 deletions(-)

diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index 0797eec76be1..47e577264198 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -1,9 +1,9 @@
 .. _readme:
 
-Linux kernel release 4.x <http://kernel.org/>
+Linux kernel release 5.x <http://kernel.org/>
 =
 
-These are the release notes for Linux version 4.  Read them carefully,
+These are the release notes for Linux version 5.  Read them carefully,
 as they tell you what this is all about, explain how to install the
 kernel, and what to do if something goes wrong.
 
@@ -63,7 +63,7 @@ Installing the kernel source
directory where you have permissions (e.g. your home directory) and
unpack it::
 
- xz -cd linux-4.X.tar.xz | tar xvf -
+ xz -cd linux-5.x.tar.xz | tar xvf -
 
Replace "X" with the version number of the latest kernel.
 
@@ -72,26 +72,26 @@ Installing the kernel source
files.  They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
 
- - You can also upgrade between 4.x releases by patching.  Patches are
+ - You can also upgrade between 5.x releases by patching.  Patches are
distributed in the xz format.  To install by patching, get all the
newer patch files, enter the top level directory of the kernel source
-   (linux-4.X) and execute::
+   (linux-5.x) and execute::
 
- xz -cd ../patch-4.x.xz | patch -p1
+ xz -cd ../patch-5.x.xz | patch -p1
 
-   Replace "x" for all versions bigger than the version "X" of your current
+   Replace "x" for all versions bigger than the version "x" of your current
source tree, **in_order**, and you should be ok.  You may want to remove
the backup files (some-file-name~ or some-file-name.orig), and make sure
that there are no failed patches (some-file-name# or some-file-name.rej).
If there are, either you or I have made a mistake.
 
-   Unlike patches for the 4.x kernels, patches for the 4.x.y kernels
+   Unlike patches for the 5.x kernels, patches for the 5.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
-   directly to the base 4.x kernel.  For example, if your base kernel is 4.0
-   and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
-   and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
-   want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
-   patch -R) **before** applying the 4.0.3 patch. You can read more on this in
+   directly to the base 5.x kernel.  For example, if your base kernel is 5.0
+   and you want to apply the 5.0.3 patch, you must not first apply the 5.0.1
+   and 5.0.2 patches. Similarly, if you are running kernel version 5.0.2 and
+   want to jump to 5.0.3, you must first reverse the 5.0.2 patch (that is,
+   patch -R) **before** applying the 5.0.3 patch. You can read more on this in
:ref:`Documentation/process/applying-patches.rst `.
 
Alternatively, the script patch-kernel can be used to automate this
@@ -114,7 +114,7 @@ Installing the kernel source
 Software requirements
 -
 
-   Compiling and running the 4.x kernels requires up-to-date
+   Compiling and running the 5.x kernels requires up-to-date
versions of various software packages.  Consult
:ref:`Documentation/process/changes.rst ` for the minimum version 
numbers
required and how to get updates for these packages.  Beware that using
@@ -132,12 +132,12 @@ Build directory for the kernel
place for the output files (including .config).
Example::
 
- kernel source code: /usr/src/linux-4.X
+ kernel source code: /usr/src/linux-5.x
  build directory:/home/name/build/kernel
 
To configure and build the kernel, use::
 
- cd /usr/src/linux-4.X
+ cd /usr/src/linux-5.x
  make O=/home/name/build/kernel menuconfig
  make O=/home/name/build/kernel
  sudo make O=/home/name/build/kernel modules_install install
diff --git a/Documentation/process/applying-patches.rst 
b/Documentation/process/applying-patches.rst
index dc2ddc345044..fbb9297e6360 100644
--- a/Documentation/process/applying-patches.rst
+++ b/Documentation/process/applying-patches.rst
@@ -216,14 +216,14 @@ You can use the ``interdiff`` program 
(http://cyberelk.net/tim/patchutils/) to
 generate a p

Re: [PATCH RFC LKMM 5/7] docs/memory-barriers.txt: Enforce heavy ordering for port I/O accesses

[Arnd Bergmann]

On Mon, Feb 11, 2019 at 4:30 PM Will Deacon  wrote:

> Given the lack of Intel response here, I went away to do some digging.
> As evidenced by the commit message, there is certainly an understanding
> amongst some developers that inX/outX() are strongly ordered on x86 and
> this was re-enforced by Linus in March last year:
>
> https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg131212.html
>
> It was this information on which I based my patch. The Intel SDM is not
> quite as assertive in its claims.
>
> However, it has also occurred to me that this patch is actually missing
> the point. memory-barriers.txt should be documenting the *Linux* memory
> model, not the x86 one, and so the port accessors should be defined to
> have the same ordering semantics as the MMIO accessors. If this wasn't
> the case, then macros such as ioreadX() and iowriteX() would be unusable
> in portable driver code.

My interpretation of the ioreadX() and iowriteX() semantics is that they
only guarantee readl()/writel() barrier semantics, even though they
may in fact provide stronger barriers for PIO on architectures that use
CONFIG_GENERIC_IOMAP (which falls back to inX()/outX()).

> The inX/outX implementation in asm-generic would
> also be bogus, despite being widely used.

They likely are. The asm-generic files tend to provide a generic
abstraction as much as that is possible, but without having access
to the architecture specific semantics, they raditionally don't know
what should be done here. We now have __io_pbw()/__io_paw()/
__io_pbr()/__io_par() to let architectures get it right, but that is
a fairly recent addition, so nothing other than riscv defines them
today.
To make things worse, a lot of machines are unable to provide
__io_paw(), e.g. when all bus writes are posted.

  Arnd

Re: [PATCH] Raise the minimum required gcc version to 4.6

[Arnd Bergmann]

On Sat, Dec 29, 2018 at 3:25 PM Geert Uytterhoeven  wrote:

> On Fri, Aug 24, 2018 at 12:00 AM Joe Perches  wrote:
> > On Thu, 2018-08-23 at 23:52 +0200, Geert Uytterhoeven wrote:
> --- 
> build.log.linux-4.20.0-atari-07795-g835f16c9b68966ff-gcc-4.1.2-20061115-prerelease-Ubuntu-4.1.1-21
> +++ 
> build.log.linux-4.20.0-atari-07767-gc085b9fd60f52a62-gcc-7.3.0-27ubuntu1~18.04
>
> 20 warning regressions:
>   + arch/m68k/atari/config.c: warning: ISO C90 forbids variable length
> array ‘switches’ [-Wvla]:  => 151:2

Ah, so we still have some of these. The warning was only recently added.

>   + arch/m68k/include/asm/cmpxchg.h: warning: value computed is not
> used [-Wunused-value]:  => 79:22, 122:3, 137:3

IIRC this can be avoided using a ({ ... }) type expression.

>   + arch/m68k/include/asm/raw_io.h: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]:  => 20:19, 33:35,
> 26:31, 30:32

The I/O accessors are defined in an unusual way that defeats a lot
of the type checking we normally have. Generally speaking the
memory space operations (readl/ioread32/__raw_readl, ...) should
be inline functions taking a 'const volatile void __iomem *' argument
(non-const for writel), while the I/O space operations should take
an integer port number (16 or 32 bit, depending on how your ISA
or PCI buses work).

Doing that should avoid all the warnings you quote here, but may
introduce warnings about nonportable driver code.

>   + arch/m68k/include/asm/string.h: warning: argument 2 null where
> non-null expected [-Wnonnull]:  => 72:25

This might be a kernel bug.

>   + arch/m68k/kernel/setup_mm.c: warning: #warning Are you building an
> allnoconfig kernel? [-Wcpp]:  => 51:2
>   + arch/m68k/kernel/setup_mm.c: warning: #warning No CPU/platform
> type selected, your kernel will not work! [-Wcpp]:  => 50:2
>   + arch/m68k/mvme147/config.c: warning: #warning check me! [-Wcpp]:  => 150:2
>   + arch/m68k/mvme16x/config.c: warning: #warning check me! [-Wcpp]:  => 397:2

I've removed that kind of warning from other architectures.

>   + arch/m68k/kernel/signal.c: warning: ISO C90 forbids variable
> length array ‘buf’ [-Wvla]:  => 654:3

You can probably pick the maximum here.

>   + drivers/i2c/i2c-core-base.c: warning: ‘ret’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]:  => 235:5

This might come from the new CONFIG_NO_AUTO_INLINE.

>   + drivers/input/joystick/analog.c: warning: #warning Precise timer
> not defined for this architecture. [-Wcpp]:  => 172:2

Maybe add a Kconfig dependency on !M68K?

>   + include/linux/dynamic_debug.h: warning: statement will never be
> executed [-Wswitch-unreachable]:  => 115:19

No idea.

>   + warning: unmet direct dependencies detected for NEED_MULTIPLE_NODES:  => 
> N/A
>   + warning: unmet direct dependencies detected for SND_SOC_QDSP6:  => N/A

Not gcc warnings.

  Arnd

Re: [PATCH v10 0/9] Add the I3C subsystem

[Arnd Bergmann]

On Thu, Nov 15, 2018 at 7:01 AM Wolfram Sang  wrote:
> > What we could do though, is expose I3C devices that do not have a
> > driver in kernel space, like spidev does.
>
> ...
>
> > Mark, Wolfram, Arnd, Greg, any opinion?
>
> Is there a benefit for having drivers in userspace? My gut feeling is to
> encourage people to write kernel drivers. If this is, for some reason,
> not possible for some driver, then we have a use case at hand to test
> the then-to-be-developed userspace interface against. Until then, I
> personally wouldn't waste effort on designing it without a user in
> sight.
>
> Dunno if you have that, but a debug interface (exchanging data with
> clients) on the other hand would be super useful most probably. Maybe
> you can start having that in debugfs and already learn from it if you
> ever want to move some interface outside of debugfs?

I think it may depend a little bit on the complexity we require
for a user interface. If it's basically just pread/pwrite, then the
debugfs would not look any different from a stable interface,
and there is little risk of getting it wrong. The more complex
the interface turns out to be, the more cautious we may want
to be about declaring it stable.

Other than that, I agree we should encourage users to write kernel
drivers, but given the precedent of uio, libusb, spidev, i2c-dev,
and vfio, it does seem extremely likely that users will have
requirements for it, and I think it's a good idea to start the design
discussion before users start building their own interfaces to do the
same thing badly.

Arnd

Re: [PATCH v10 0/9] Add the I3C subsystem

[Arnd Bergmann]

On Thu, Nov 15, 2018 at 4:58 AM Boris Brezillon
 wrote:
> +Mark Brown for the question about /dev/spidev
> On Thu, 15 Nov 2018 12:14:37 +
> vitor  wrote:
> > My initial thoughts are to do the same think as for i2c, expose the
> > buses or the i3c_devices and use ioctl for private transfers.
>
> Exposing the bus is dangerous IMO, because an I3C bus is not like an
> I2C bus:
>
>* I3C device needs to be discovered through DAA
>* I2C devices need to be declared ahead of time, and LVR is used to
>  determine the limitations on the bus at runtime
>
> So you'd anyway be able to interact only with devices that have
> previously been discovered.
>
> Note that the virtual I2C bus is already exposed, but any command
> targeting an address that is not attached to a registered I2C dev will
> get a -ENOENT error.
>
> What we could do though, is expose I3C devices that do not have a
> driver in kernel space, like spidev does.
>
> > Some
> > direct CCC commands can be sent through the /sys as you plan for SETNEWDA .
>
> Yes, CCC commands that need to be exposed to userspace should be
> exposed through sysfs, or, if we decide to create a /dev/i3cX device
> per bus, through ioctls.
>
> >
> > What do you think about this?
>
> I think this request is perfectly valid, we just need to decide how it
> should be done, and before we take this decision, I'd like to get
> inputs from other maintainers.
>
> Mark, Wolfram, Arnd, Greg, any opinion?

I think for a new user space interface, it makes sense to explore a number of
different options before making the final decision.

I agree about better not exposing the bus as a /dev/i3c* node, and that we
probably do need to expose individual devices in some form to allow
writing complete user space drivers that can do everything a kernel driver
can do.

Can you describe what a low-level interface to the device looks like
in the kernel? Can this be abstracted as simply pread()/pwrite() plus
an interrupt mechanism, or do we need a set of ioctl() operations as
well?

If it can be purely based on a regmap abstraction, a sysfs inteface
might be sufficient, though that has some downsides with permission
management compared to a /dev/* node.

Another option might be the use of a socket interface, which also
has some issues in terms of permission management, but might
be a good fit if we could abstract bus transactions as packets that
can be queued.

   Arnd

Re: [PATCH v9 6/9] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On Fri, Oct 26, 2018 at 2:46 PM Boris Brezillon
 wrote:
> On Fri, 26 Oct 2018 12:01:52 +0200
> Arnd Bergmann  wrote:
> > On Fri, Oct 26, 2018 at 9:57 AM Boris Brezillon
> >  wrote:
> > > On Fri, 26 Oct 2018 09:43:25 +0200
> > > Arnd Bergmann  wrote:
> > >
> > > > On Thu, Oct 25, 2018 at 6:30 PM Boris Brezillon
> > > >  wrote:
> > > > > On Thu, 25 Oct 2018 18:13:51 +0200 Arnd Bergmann  
> > > > > wrote:
> > > > > On Thu, Oct 25, 2018 at 6:07 PM Boris Brezillon 
> > > > >  wrote:
> > > > > > > On Thu, 25 Oct 2018 17:30:26 +0200
> >
> > This is apparently not allowed on ARC when 'buffer' is
> > unaligned. I think what we need here is to use
> > put_unaligned() instead of the pointer dereference.
> > For architectures that can do unaligned accesses,
> > the result is the same, but for ARC it will fix the problem.
>
> Okay, so writesl()/readsl() should deal with unaligned pointers, and
> default implementations should be fixed. I guess you'll send a patch to
> use put/get_unaligned().

That's one way of doing it, though thinking about it some more,
this can also introduce overhead on machines that don't support
unaligned buffers and only work on drivers that are guaranteed
to see fully aligned data.

We could also override these specifically for ARC, and risk
running into the same problem elsewhere, rather than be sure
to fix everyone while risking to introduce noticeable performance
regressions in existing drivers.

> > > > One way to address this might be to always bounce any
> > > > messages that are less than a cache line through a
> > > > (pre-)kmallocated buffer, and require any longer messages
> > > > to be cache capable. This could also solve the issue with
> > > > readsl(), but it would be a rather confusing user interface.
> > > >
> > > > Another option might be to have separate interfaces for
> > > > "short" and "long" messages at the API level and have
> > > > distinct rules for those: short would always be bounced
> > > > by the i3c code, and long puts restrictions on the buffer
> > > > location.
> > >
> > > Hm, let's keep the API simple. I'll just mandate that all payload bufs
> > > passed to i3c_master_send_ccc_cmd_locked() be dynamically allocated.
> >
> > Ok. What about i2c commands sent to the same i3c controller
> > then?
>
> Still not taken care of.
>
> > Do we need to copy those to satisfy the requirements
> > of the i3c layer?
>
> I guess we should. The question is, should we do that unconditionally
> or should we try to optimize thins with something like:
>
> if (!virt_addr_valid(xfer->buf) ||
> object_is_on_stack(xfer->buf))
> /* Alloc bounce buf. */
> else
> /* Use provided buf. */

There may be too many cases that we need to handle here that
are not DMA capable. To be on the safe side, I'd probably always
copy all data that is not a multiple of fully aligned cache lines,
as well as pointers that fails to meet some other requirements
(stack, vmalloc, kmap, ...)

Arnd

Re: [PATCH v9 6/9] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On Fri, Oct 26, 2018 at 9:57 AM Boris Brezillon
 wrote:
> On Fri, 26 Oct 2018 09:43:25 +0200
> Arnd Bergmann  wrote:
>
> > On Thu, Oct 25, 2018 at 6:30 PM Boris Brezillon
> >  wrote:
> > > On Thu, 25 Oct 2018 18:13:51 +0200 Arnd Bergmann  wrote:
> > > On Thu, Oct 25, 2018 at 6:07 PM Boris Brezillon 
> > >  wrote:
> > > > > On Thu, 25 Oct 2018 17:30:26 +0200
> > Ok. Is i3c_master_send_ccc_cmd_locked() what implements the public
> > interfaces then, or is this something else?
>
> i3c_master_send_ccc_cmd_locked() calls master->ops->send_ccc_cmd(), so
> it's part of the master controller interface.
>
> >
> > If you place a buffer on the stack, it is not DMA capable, but
> > it is guaranteed to be at least 32-bit word aligned, and should
> > not cause an exception in readsl(), unless it starts with a couple of
> > (not multiple of four)  extra bytes that are not sent to the devices.
> > Is that what happens here?
>
> Here is the report I received from Vitor:
>
> "
> Hi Boris,
>
>
> I'm trying this new patch-set version but I get some issues when use
> readsl() function.
>
> Basically the system complain about memory alignment.
>

> > +static int i3c_master_getpid_locked(struct i3c_master_controller 
> *master,
> > + struct i3c_device_info *info)
> > +{
> > + struct i3c_ccc_getpid getpid;
>
> at this point the getpid struct it is already unaligned with
>
> i3c_master_getpid_locked:1129 getpid_add=0x9a249c7a
>
> > + struct i3c_ccc_cmd_dest dest = {
> > + .addr = info->dyn_addr,
> > + .payload.len = sizeof(struct i3c_ccc_getpid),
> > + .payload.data = &getpid,
> > + };

> > +}
> > +
>
> and them when
>
> static void dw_i3c_master_read_rx_fifo(struct dw_i3c_master *master,
> u8 *bytes, int nbytes)
> {
>  readsl(master->regs + RX_TX_DATA_PORT, bytes, nbytes / 4);
> ...
> }

Ok, I spent an hour chasing the ARM implementation and finding
no way this could go wrong here. I see that 'struct i3c_ccc_getpid'
may be misaligned on the stack (it normally won't be), and that
the ARM readsl() has a lot of extra code to handle unaligned
output. However, the dump that Vitor reports

> [ECR   ]: 0x00230400 => Misaligned r/w from 0x9a249c7a
> [EFA   ]: 0x9a249c7a
>[BLINK ]: dw_i3c_master_irq_handler+0x200/0x2fc [dw_i3c_master]

Is from an arch/arc kernel that uses asm-generic/io.h, and
that stores the output using a u32 pointer:

static inline void readsl(const volatile void __iomem *addr, void *buffer,
  unsigned int count)
{
if (count) {
u32 *buf = buffer;

do {
u32 x = __raw_readl(addr);
*buf++ = x;
} while (--count);
}
}

This is apparently not allowed on ARC when 'buffer' is
unaligned. I think what we need here is to use
put_unaligned() instead of the pointer dereference.
For architectures that can do unaligned accesses,
the result is the same, but for ARC it will fix the problem.

> > One way to address this might be to always bounce any
> > messages that are less than a cache line through a
> > (pre-)kmallocated buffer, and require any longer messages
> > to be cache capable. This could also solve the issue with
> > readsl(), but it would be a rather confusing user interface.
> >
> > Another option might be to have separate interfaces for
> > "short" and "long" messages at the API level and have
> > distinct rules for those: short would always be bounced
> > by the i3c code, and long puts restrictions on the buffer
> > location.
>
> Hm, let's keep the API simple. I'll just mandate that all payload bufs
> passed to i3c_master_send_ccc_cmd_locked() be dynamically allocated.

Ok. What about i2c commands sent to the same i3c controller
then? Do we need to copy those to satisfy the requirements
of the i3c layer?

  Arnd

Re: [PATCH v9 6/9] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On Thu, Oct 25, 2018 at 6:30 PM Boris Brezillon
 wrote:
> On Thu, 25 Oct 2018 18:13:51 +0200 Arnd Bergmann  wrote:
> On Thu, Oct 25, 2018 at 6:07 PM Boris Brezillon  
> wrote:
> > > On Thu, 25 Oct 2018 17:30:26 +0200
> > > Arnd Bergmann  wrote:
> > > > On 10/24/18, Boris Brezillon  wrote:
> > > > > On Mon, 22 Oct 2018 15:34:01 +0200
> > > I guess I could dynamically allocate the payload, but that requires
> > > going over all users of i3c_send_ccc_cmd() to patch them.
> >
> > This reminds me that Wolfram mentioned in his ELC talk that the
> > buffers on i3c should all be DMA capable to make life easier for
> > i3c master drivers that want to implement DMA transfers.
>
> And this is the case for all buffers passed to
> i3c_device_do_priv_xfers() (and soon i3c_device_send_hdr_cmd()),
> but I did not enforce that for the internal
> i3c_master_send_ccc_cmd_locked() helper, maybe I should...
> It was just convenient to place the object to be transmitted/received on
> the stack.

Ok. Is i3c_master_send_ccc_cmd_locked() what implements the public
interfaces then, or is this something else?

If you place a buffer on the stack, it is not DMA capable, but
it is guaranteed to be at least 32-bit word aligned, and should
not cause an exception in readsl(), unless it starts with a couple of
(not multiple of four)  extra bytes that are not sent to the devices.
Is that what happens here?

> > If we have buffers here that are not aligned to cache lines
> > (or even just 32 bit words), doesn't that also mean that the
> > same buffers are not DMA capable either?
>
> Yep, if it's not cache-line-aligned (and on the stack), it's not
> DMA-able.

This sounds like a more fundamental problem to solve first
then. Obviously it is incredibly /useful/ to be able to put short
i2c or i3c messages on the stack, but allowing that in general
also prevents the use of DMA without bounce buffers.

One way to address this might be to always bounce any
messages that are less than a cache line through a
(pre-)kmallocated buffer, and require any longer messages
to be cache capable. This could also solve the issue with
readsl(), but it would be a rather confusing user interface.

Another option might be to have separate interfaces for
"short" and "long" messages at the API level and have
distinct rules for those: short would always be bounced
by the i3c code, and long puts restrictions on the buffer
location.

   Arnd

Re: [PATCH v9 6/9] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On Thu, Oct 25, 2018 at 6:07 PM Boris Brezillon
 wrote:
>
> On Thu, 25 Oct 2018 17:30:26 +0200
> Arnd Bergmann  wrote:
>
> > On 10/24/18, Boris Brezillon  wrote:
> > > Hi Arnd,
> > >
> > > On Mon, 22 Oct 2018 15:34:01 +0200
> > > Boris Brezillon  wrote:
> > >
> > >
> > >> +
> > >> +static void cdns_i3c_master_rd_from_rx_fifo(struct cdns_i3c_master
> > >> *master,
> > >> +  u8 *bytes, int nbytes)
> > >> +{
> > >> +  readsl(master->regs + RX_FIFO, bytes, nbytes / 4);
> > >
> > > Vitor reported a problem with readsl(): this function expects the 2nd
> > > argument to be aligned on 32-bit, which is not guaranteed here. Unless
> > > you see a better solution, I'll switch back to a loop doing:
> > >
> > > for (i = 0; i < nbytes; i += 4) {
> > > u32 tmp = __raw_readl(...);
> > > memcpy(bytes + i, &tmp,
> > >nbytes - i  > 4 ? 4 : nbytes - i);
> > > }
> >
> > Could we maybe mandate that the buffer itself must be aligned here?
> > What would be a reason why we see an unaligned target buffer?
>
> Well, the buffers we pass to i3c_send_ccc_cmd() are not necessarily
> aligned because they're not dynamically allocated (allocated on the
> stack) and are not naturally aligned on 32-bits (either because they
> are smaller than 32bits or because the struct is declared __packed).
>
> I guess I could dynamically allocate the payload, but that requires
> going over all users of i3c_send_ccc_cmd() to patch them.

This reminds me that Wolfram mentioned in his ELC talk that the
buffers on i3c should all be DMA capable to make life easier for
i3c master drivers that want to implement DMA transfers.

If we have buffers here that are not aligned to cache lines
(or even just 32 bit words), doesn't that also mean that the
same buffers are not DMA capable either?

Arnd

Re: [PATCH v9 6/9] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On 10/24/18, Boris Brezillon  wrote:
> Hi Arnd,
>
> On Mon, 22 Oct 2018 15:34:01 +0200
> Boris Brezillon  wrote:
>
>
>> +
>> +static void cdns_i3c_master_rd_from_rx_fifo(struct cdns_i3c_master
>> *master,
>> +u8 *bytes, int nbytes)
>> +{
>> +readsl(master->regs + RX_FIFO, bytes, nbytes / 4);
>
> Vitor reported a problem with readsl(): this function expects the 2nd
> argument to be aligned on 32-bit, which is not guaranteed here. Unless
> you see a better solution, I'll switch back to a loop doing:
>
>   for (i = 0; i < nbytes; i += 4) {
>   u32 tmp = __raw_readl(...);
>   memcpy(bytes + i, &tmp,
>  nbytes - i  > 4 ? 4 : nbytes - i);
>   }

Could we maybe mandate that the buffer itself must be aligned here?
What would be a reason why we see an unaligned target buffer?

The open-coded loop should generally work (maybe a little slower),
but it does seem error-prone to use __raw_readl() in general.

  Arnd

Re: [PATCH v9 00/24] ILP32 for ARM64

[Arnd Bergmann]

On Sat, Oct 13, 2018 at 4:07 AM Eugene Syromiatnikov  wrote:
>
> On Wed, Oct 10, 2018 at 03:39:07PM +0100, Szabolcs Nagy wrote:
> > On 10/10/18 15:10, Eugene Syromiatnikov wrote:
> > >  * What's the reasoning behind capping syscall arguments to 32 bit? x32
> > >and MIPS N32 do not have such a restriction (and do not need special
> > >wrappers for syscalls that pass 64-bit values as a result, except
> > >when they do,  as it is the case for preadv2 on x32); moreover, that
> > >would lead to insurmountable difficulties for AArch64 ILP32 tracers
> > >that try to trace LP64 tracees, as it would be impossible to pass
> > >64-bit addresses to process_vm_{read,write} or ptrace PEEK/POKE.
> >
> > but that's necessarily the case for all ilp32 abis:
> > the userspace syscall function receives 32bit
> > arguments so even if the kernel abi takes 64bit
> > args you cannot use that from c code. (the libc
> > does not even know which args should be sign or
> > zero extended.)
>
> glibc's syscall() prototype has kernel_ulong_t as its arguments (more
> specifically, to __syscall_ulong_t, which is 64-bit wide on x32; it
> should also have kernel_long_t as its return type instead of long,
> but that's another story), so it works perfectly fine in case of x32.
>
> > process_vm_readv/writev is limited by the ilp32
> > iovec struct, not by the syscall arguments.
>
> Right, on x32/N32 this issue is worked around by the usage of the respective
> x86_64/N64 call, and it looks like another thing that is impossible
> with AArch64 ilp32.
>
> > ptrace is specified to take void* addr argument,
> > and void* is 32bit on all ilp32 targets.
> > so again on the c language level there is no
> > way around the 32bit limitation.
>
> Which is an issue.

I have no idea why you think this is a problem specific to aarch64-ilp32:
If we want to be able to debug 64-bit tasks from a 32-bit task on any
architecture that has compat mode, we should solve it once and
extend the ptrace interface to allow it on *all* of them. We certainly
don't need /more/ special cases for the x32 hack, there should really
be fewer of them.

  Arnd

Re: [PATCH v9 00/24] ILP32 for ARM64

[Arnd Bergmann]

On Sat, Oct 13, 2018 at 9:36 PM Andy Lutomirski  wrote:
>
> On Wed, May 16, 2018 at 1:19 AM Yury Norov  wrote:
> >
> > This series enables AARCH64 with ILP32 mode.
> >
> > As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> > option that is enabled for existing 32-bit architectures but disabled
> > for new arches (so 64-bit off_t userspace type is used by new userspace).
> > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> Second, ILP32 user code is highly unlikely
> to end up with the same struct layout as ILP64 code.  The latter seems
> like it should be solved entirely in userspace by adding a way to
> annotate a structure as being a kernel ABI structure and getting the
> toolchain to lay it out as if it were ILP64 even though the target is
> ILP32.

The syscall ABI could be almost completely abstracted in glibc, the
main issue is ioctl and a couple of related interfaces that pass data
structures (read() on /dev/input/*, mmap on /dev/snd/*
or raw sockets, fcntl).

The question whether a data type is laid out like a 64-bit architecture
would cannot be a property of the type in most of those cases,
because the same types are used elsewhere. Many ioctls just
take a pointer to a 'long' or similar, and then you have structures
like 'timespec' that are used both in syscall/ioctl ABI and in normal
user space code, but are required to be laid out differently there.
(timespec is a bad example because y2038 of course, but it
illustrates the point).

> 2. I think you should make a conscious decision as to whether the
> ILP32-ness of a syscall is a property of the task or of the syscall.
> On x86, x32-ness is a property of the syscall, but historically it
> also got rather entangled with the state of the task, and the result
> was a mess.  It looks like you're making it be a property of the task,
> which is fine, but you're making it impossible for very clever ILP32
> libraries to include little ILP64 stubs that do fancy things with full
> 64-bit syscalls.
>
> 3. Make very certain that you aren't exploitable by malicious
> processes that set the high bits in ILP32 syscall args.  x86 compat
> has issues like that in the past.

This point was actually the most important one for keeping the
aarch64 ilp32 interface as restricted as it is: it doesn't allow
anything that the normal aarch32/armv7 emulation doesn't
already provide.

Arnd

Re: [PATCH v9 00/24] ILP32 for ARM64

[Arnd Bergmann]

On 10/10/18, Eugene Syromiatnikov  wrote:
> On Tue, Jul 24, 2018 at 08:39:57PM +0300, Yury Norov wrote:
>> Hi all,
>>
>> + Pavel Machek, Palmer Dabbelt, Wookey.
>>
>> On Wed, May 16, 2018 at 11:18:45AM +0300, Yury Norov wrote:
>> > This series enables AARCH64 with ILP32 mode.
>> >
>> > As supporting work, it introduces ARCH_32BIT_OFF_T configuration
>> > option that is enabled for existing 32-bit architectures but disabled
>> > for new arches (so 64-bit off_t userspace type is used by new
>> > userspace).
>> > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>> >
>> > Based on kernel v4.16. Tested with LTP, glibc testsuite, trinity,
>> > lmbench,
>> > CPUSpec.
>
>> This is the update of the series based on 4.17 kernel
>> https://github.com/norov/linux/tree/ilp32-4.17
>
> Hello.
>
> I have some questions regarding AArch64 ILP32 implementation for which I
> failed to find an answer myself:
>  * How ptrace() tracer is supposed to distinguish between ILP32 and LP64
>tracees? For MIPS N32 and x32 this is possible based on syscall
>number, but for AArch64 ILP32 I do not see such a sign. There's also
>ARM_ip is employed for signalling entering/exiting, I wonder whether
>it's possible to employ it also for signalling tracee's personality.

Don't know.

>  * What's the reasoning behind capping syscall arguments to 32 bit? x32
>and MIPS N32 do not have such a restriction (and do not need special
>wrappers for syscalls that pass 64-bit values as a result, except
>when they do,  as it is the case for preadv2 on x32); moreover, that
>would lead to insurmountable difficulties for AArch64 ILP32 tracers
>that try to trace LP64 tracees, as it would be impossible to pass
>64-bit addresses to process_vm_{read,write} or ptrace PEEK/POKE.

The idea is to keep the syscall entry points as similar as possible
between arm (aarch32) emulation and aarch64-ilp32 mode when
you have a kernel that supports both.

  Arnd

Re: [PATCH v8 00/10] Add the I3C subsystem

[Arnd Bergmann]

On Wed, Oct 3, 2018 at 3:22 PM Boris Brezillon
 wrote:
>
> Sorry for the huge delay between v7 and v8 despite the small amount of
> things I was asked to fix/rework.
>
> This patch series is adding a new subsystem to support I3C devices.
>
> This is just adding support for basic features. Extra features will
> be added afterwards.
>
> There are a few design choices that are worth mentioning because they
> impact the way I3C device drivers can interact with their devices:
>
> - all functions used to send I3C/I2C frames must be called in
>   non-atomic context. Mainly done this way to ease implementation, but
>   this is still open to discussion. Please let me know if you think it's
>   worth considering an asynchronous model here
> - the I3C bus and I3C master controller are now tightly coupled even
>   though they're still allocated separately. There's now a 1:1
>   relationship between these objects, and the I3C master is no longer
>   represented under the I3C bus object.
>   Arnd, let me know if you had something different in mind, and I'll
>   rework the implementation accordingly.

I looked at the entire series again and I'm rather happy with how
it turned out. I've commented on a tiny issue about the readsl()
that should be easy to resolve one way or another, with that
you can add my

Reviewed-by: Arnd Bergmann 

There is one additional issue that we've talked about previously
and that I'd like to hear about from GregKH or maybe other
subsystem maintainers: In the current version, you have a single
'bus_type' object, and this is used to represent both a 'host' and
a 'device'. I think we concluded that this is done in other
subsystems as well, and that this is fitting here because a
host (master device) can hand over being a master to another
device (slave), which then becomes the host and sees this
one as a slave. Also a lot of the sysfs attributes are the same
because of this relationship.

It also means that you get a mix of things in sysfs:

/sys/devices/i3c/
/sys/devices/i3c/
/sys/devices/i3c//

which is a bit like what we have on USB where we can have hub
devices that are again parents of other USB devices, but I don't
think we can have i3c hubs or multiplexers in the same way, so
it's only a single level.

I'm ok with this model after our previous discussion and couldn't
come up with a better one. If anyone else still sees it as
problematic and has a better idea, please let us know now.

 Arnd

Re: [PATCH v8 07/10] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On Mon, Oct 8, 2018 at 12:21 PM Boris Brezillon
 wrote:
>
> On Mon, 8 Oct 2018 12:06:30 +0200
> Arnd Bergmann  wrote:
>
> > On Wed, Oct 3, 2018 at 3:22 PM Boris Brezillon
> >  wrote:
> > >
> > > Add a driver for Cadence I3C master IP.
> > >
> > > Signed-off-by: Boris Brezillon 
> > > ---
> >
> > > Changes in v7:
> > > - Fix readsl/writesl() usage
> > > - Add a depends on ARM || ARM64 || XTENSA to forbid selection of this
> > >   driver on platforms that are not implementing readsl/writesl
> >
> > Most architectures include asm-generic/io.h, which contains a generic
> > implementation of readsl(). Maybe that #ifdef could be extended here?
> > I remember discussing this with you not so long ago, which led to
> > commit 0bbf47eab469 ("ia64: use asm-generic/io.h"). Do we have
> > a list of architectures that don't include asm-generic/io.h? Maybe
> > the 'depends on' could be for the set of architectures that fail here.
>
> Well, we started patching 2 archs (ia64 and sparc) based on kbuild
> robots failure report, and then I received other reports (still from
> kbuild robots) long after the initial ones. I can't tell for sure which
> archs are not implementing those functions, hence the conservative
> approach taken here.

I think it's a fairly safe assumption that architectures which include
asm-generic/io.h will be fine here. If one of them is broken, that
can be fixed individually. Looking at the ones that don't include this
file:

grep -L asm-generic/io.h arch/*/include/asm/io*.h
arch/alpha/include/asm/io.h# missing readsl
arch/hexagon/include/asm/io.h   # has its own readsl
arch/mips/include/asm/io.h # missing readsl (but used from ide.h?)
arch/parisc/include/asm/io.h   # missing readsl
arch/powerpc/include/asm/io.h   # has its own readsl
arch/sh/include/asm/io.h # has its own readsl
arch/sparc/include/asm/io.h# has its own readsl

Based on this, I would try what happens on mips, and make it depend
on !(ALPHA || PARISC)

Another option is to just use ioread32_rep(), which should be
available everywhere and has almost the same behavior as
readsl(). The only difference is that on architectures like x86
it takes a few extra cycles to look at the address.

Arnd

Re: [PATCH v8 07/10] i3c: master: Add driver for Cadence IP

[Arnd Bergmann]

On Wed, Oct 3, 2018 at 3:22 PM Boris Brezillon
 wrote:
>
> Add a driver for Cadence I3C master IP.
>
> Signed-off-by: Boris Brezillon 
> ---

> Changes in v7:
> - Fix readsl/writesl() usage
> - Add a depends on ARM || ARM64 || XTENSA to forbid selection of this
>   driver on platforms that are not implementing readsl/writesl

Most architectures include asm-generic/io.h, which contains a generic
implementation of readsl(). Maybe that #ifdef could be extended here?
I remember discussing this with you not so long ago, which led to
commit 0bbf47eab469 ("ia64: use asm-generic/io.h"). Do we have
a list of architectures that don't include asm-generic/io.h? Maybe
the 'depends on' could be for the set of architectures that fail here.

> +static void cdns_i3c_master_rd_from_rx_fifo(struct cdns_i3c_master *master,
> +   u8 *bytes, int nbytes)
> +{
> +   readsl(master->regs + RX_FIFO, bytes, nbytes / 4);
> +   if (nbytes & 3) {
> +   u32 tmp = __raw_readl(master->regs + RX_FIFO);
> +
> +   memcpy(bytes + (nbytes & ~3), &tmp, nbytes & 3);
> +   }
> +}

The __raw_readl() is probably correct here (I can't think of any
architecture on which it is not), but it still makes me feel uneasy
about possible endianess or other issues.

Maybe make this:?

readsl(master->regs + RX_FIFO, &tmp, 1);


 Arnd

Re: [PATCH v2 00/29] at24: remove at24_platform_data

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 4:36 PM Sowmini Varadhan
 wrote:
>
> Just catching up on this thread, so please excuse any unintentional
> misquotes here.
>
> > > > > David: I couldn't find a place in sparc code where any ethernet device
> > > > > would be registered, so is there a chance that nobody is using it?
> > > >
> > > > SPARC uses a true Open Firmware implementation, so it would register
> > > > drivers through the CONFIG_OF infrastructure.
>
> correct
>
> > The calls are not even that old, and clearly added intentionally for sparc,
> > see commit ba94272d08a7 ("i40e: use eth_platform_get_mac_address()")
> > which added the first one.
>
> Yes, correct again. Wouldn't PPC also end up doing the same thing?
>
> See also commit c762dff24c06 (for ixgbe) - without this fix sparc systems
> will come up with a bogus mac address and then you end up having to
> manually fix this in ugly ways.

The of_get_mac_address() portion is not controversial at all I think,
the question was whether we need the fallback to
arch_get_platform_mac_address() in any of the drivers that
call eth_platform_get_mac_address().

  Arnd

Re: [PATCH v2 00/29] at24: remove at24_platform_data

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 1:06 PM Bartosz Golaszewski  wrote:
> śr., 3 paź 2018 o 23:04 Florian Fainelli  napisał(a):
> > On 10/3/2018 1:15 PM, Bartosz Golaszewski wrote:
> > > pt., 31 sie 2018 o 21:46 Brian Norris  
> > > napisał(a):
> > >>
> > >> Hi,
> > >>
> > >> On Fri, Aug 10, 2018 at 10:04:57AM +0200, Bartosz Golaszewski wrote:
> > >>> Most boards use the EEPROM to store the MAC address. This series adds
> > >>> support for cell lookups to the nvmem framework, registers relevant
> > >>> cells for all users, adds nvmem support to 
> > >>> eth_platform_get_mac_address(),
> > >>> converts davinci_emac driver to using it and replaces at24_platform_data
> > >>> with device properties.
> > >>
> > >> We already have:
> > >>
> > >> of_get_nvmem_mac_address() (which does exactly what you're adding,
> > >> except it's DT specific)
> > >> of_get_mac_address()
> > >> fwnode_get_mac_address()
> > >> device_get_mac_address()
> > >>
> > >> and now you've taught me that this exists too:
> > >>
> > >> eth_platform_get_mac_address()
> > >>
> > >> These mostly don't share code, and with your series, they'll start to
> > >> diverge even more as to what they support. Can you please help rectify
> > >> that, instead of widening the gap?
> > >>
> > >> For instance, you can delete most of eth_platform_get_mac_address() and
> > >> replace it with device_get_mac_address() [1]. And you could add your new
> > >> stuff to fwnode_get_mac_address().
> > >>
> > >> And important part to note here is that you code isn't just useful for
> > >> ethernet -- it could be useful for Wifi devices too. So IMO, sticking it
> > >> only in an "eth" function is the wrong move.
> > >>
> > >> Brian
> > >>
> > >> [1] arch_get_platform_mac_address() is the only part I wouldn't want to
> > >> replicate into a truly generic helper. The following should be a no-op
> > >> refactor, AIUI:
> > >>
> > >
> > > The only user of arch_get_platform_mac_address() is sparc. It returns
> > > an address that seems to be read from some kind of EEPROM. I'm not
> > > familiar with this arch though. I'm wondering if we could somehow
> > > seamlessly remove this call and then convert all users of
> > > eth_platform_get_mac_address() to using device_get_mac_address()?
> > >
> > > David: I couldn't find a place in sparc code where any ethernet device
> > > would be registered, so is there a chance that nobody is using it?
> >
> > SPARC uses a true Open Firmware implementation, so it would register
> > drivers through the CONFIG_OF infrastructure.
> > --
>
> I'm seeing that there are only six callers of
> eth_platform_get_mac_address() (the only function which calls
> arch_get_platform_mac_address()).
>
> Of these six callers four are intel ethernet drivers and two are usb
> ethernet adapter drivers.
>
> Is it even possible that sparc wants to get the mac address for a usb
> adapter from some memory chip? Maybe we *can* safely remove that
> function completely? That would allow us to simplify a lot of code.

The calls are not even that old, and clearly added intentionally for sparc,
see commit ba94272d08a7 ("i40e: use eth_platform_get_mac_address()")
which added the first one.

Before that commit, the driver did the same as a couple of sun
specific ones that access the idprom directly:

drivers/net/ethernet/aeroflex/greth.c:
macaddr[i] = (unsigned int) idprom->id_ethaddr[i];
drivers/net/ethernet/amd/sun3lance.c:dev->dev_addr[i] =
idprom->id_ethaddr[i];
drivers/net/ethernet/amd/sunlance.c:dev->dev_addr[i] =
idprom->id_ethaddr[i];
drivers/net/ethernet/broadcom/tg3.c:memcpy(dev->dev_addr,
idprom->id_ethaddr, ETH_ALEN);
drivers/net/ethernet/i825xx/sun3_82586.c:dev->dev_addr[i]
= idprom->id_ethaddr[i];
drivers/net/ethernet/sun/sunbmac.c: dev->dev_addr[i] =
idprom->id_ethaddr[i];
drivers/net/ethernet/sun/sungem.c:  addr = idprom->id_ethaddr;
drivers/net/ethernet/sun/sunhme.c:
memcpy(dev->dev_addr, idprom->id_ethaddr, ETH_ALEN);
drivers/net/ethernet/sun/sunhme.c:
memcpy(dev->dev_addr, idprom->id_ethaddr, ETH_ALEN);
drivers/net/ethernet/sun/sunqe.c:   memcpy(dev->dev_addr,
idprom->id_ethaddr, ETH_ALEN);

  Arnd

Re: [PATCH 4/4] sh: remove board_time_init() callback

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 5:48 PM, Arnd Bergmann  wrote:

> @@ -41,8 +39,7 @@ static void __init sh_late_time_init(void)
>
>  void __init time_init(void)
>  {
> -   if (board_time_init)
> -   board_time_init();
> +   timer_init();

Testing revealed this to be broken, the fix is:

diff --git a/arch/sh/kernel/time.c b/arch/sh/kernel/time.c
index a29eb989d81b..8a1c6c8ab4ec 100644
--- a/arch/sh/kernel/time.c
+++ b/arch/sh/kernel/time.c
@@ -39,7 +39,7 @@ static void __init sh_late_time_init(void)

 void __init time_init(void)
 {
- timer_init();
+ timer_probe();

  clk_init();

Let me know if you'd like me to resend the series with that typo fixed.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] sh: remove board_time_init() callback

[Arnd Bergmann]

The only remaining user of board_time_init() is the of-generic
machine, and that just calls the global timer_init() function.
Calling that one has no effect on non-DT platforms, so we can
simply call it unconditionally in place of board_time_init().

Signed-off-by: Arnd Bergmann 
---
 Documentation/sh/new-machine.txt | 8 
 arch/sh/boards/of-generic.c  | 8 
 arch/sh/include/asm/rtc.h| 1 -
 arch/sh/kernel/time.c| 5 +
 4 files changed, 1 insertion(+), 21 deletions(-)

diff --git a/Documentation/sh/new-machine.txt b/Documentation/sh/new-machine.txt
index f0354164cb0e..e0961a66130b 100644
--- a/Documentation/sh/new-machine.txt
+++ b/Documentation/sh/new-machine.txt
@@ -116,7 +116,6 @@ might look something like:
  * arch/sh/boards/vapor/setup.c - Setup code for imaginary board
  */
 #include 
-#include  /* for board_time_init() */
 
 const char *get_system_type(void)
 {
@@ -132,13 +131,6 @@ int __init platform_setup(void)
 * this board.
 */
 
-   /* 
-* Presume all FooTech boards have the same broken timer,
-* and also presume that we've defined foo_timer_init to
-* do something useful.
-*/
-   board_time_init = foo_timer_init;
-
/* Start-up imaginary PCI ... */
 
/* And whatever else ... */
diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
index 46b2481eec90..ee74ff1e7721 100644
--- a/arch/sh/boards/of-generic.c
+++ b/arch/sh/boards/of-generic.c
@@ -116,18 +116,10 @@ static void __init sh_of_mem_reserve(void)
early_init_fdt_scan_reserved_mem();
 }
 
-static void __init sh_of_time_init(void)
-{
-   pr_info("SH generic board support: scanning for clocksource devices\n");
-   timer_probe();
-}
-
 static void __init sh_of_setup(char **cmdline_p)
 {
struct device_node *root;
 
-   board_time_init = sh_of_time_init;
-
sh_mv.mv_name = "Unknown SH model";
root = of_find_node_by_path("/");
if (root) {
diff --git a/arch/sh/include/asm/rtc.h b/arch/sh/include/asm/rtc.h
index fe55fbb181aa..69dbae2949b0 100644
--- a/arch/sh/include/asm/rtc.h
+++ b/arch/sh/include/asm/rtc.h
@@ -3,7 +3,6 @@
 #define _ASM_RTC_H
 
 void time_init(void);
-extern void (*board_time_init)(void);
 
 #define RTC_CAP_4_DIGIT_YEAR   (1 << 0)
 
diff --git a/arch/sh/kernel/time.c b/arch/sh/kernel/time.c
index eb0a91270499..a29eb989d81b 100644
--- a/arch/sh/kernel/time.c
+++ b/arch/sh/kernel/time.c
@@ -22,8 +22,6 @@
 #include 
 #include 
 
-void (*board_time_init)(void);
-
 static void __init sh_late_time_init(void)
 {
/*
@@ -41,8 +39,7 @@ static void __init sh_late_time_init(void)
 
 void __init time_init(void)
 {
-   if (board_time_init)
-   board_time_init();
+   timer_init();
 
clk_init();
 
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke  wrote:
> On 03/15/2018 10:42 AM, David Howells wrote:
>> Do we have anything left that still implements NOMMU?
>>
> RISC-V ?
> (evil grin :-)

Is anyone producing a chip that includes enough of the Privileged ISA spec
to have things like system calls, but not the MMU parts?

I thought at least initially the kernel only supports hardware that has a rather
complete feature set.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> Do we have anything left that still implements NOMMU?

Yes, plenty. I was wondering the same thing, but it seems that the architectures
we remove are almost completely representative of what we support overall,
except that they are all not licensed to 3rd parties, unlike many of the ones we
keep.

I've made an overview of the remaining architectures for my own reference[1].
The remaining NOMMU architectures are:

- arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
gaining traction
- arch/sh has an open-source J2 core that was added not that long ago,
it seems to
  be the only SH compatible core that anyone is working on.
- arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
- arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
  classic processors
- c6x has no MMU

   Arnd

[1] 
https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 31/47] watchdog: remove bfin_wdt driver

[Arnd Bergmann]

The blackfin architecture is getting removed, so this driver has
become obsolete.

Signed-off-by: Arnd Bergmann 
---
 Documentation/watchdog/watchdog-parameters.txt |   5 -
 drivers/watchdog/Kconfig   |  17 -
 drivers/watchdog/Makefile  |   7 -
 drivers/watchdog/bfin_wdt.c| 476 -
 4 files changed, 505 deletions(-)
 delete mode 100644 drivers/watchdog/bfin_wdt.c

diff --git a/Documentation/watchdog/watchdog-parameters.txt 
b/Documentation/watchdog/watchdog-parameters.txt
index beea975980f6..6d6200ea27b8 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -55,11 +55,6 @@ wdt_time: Watchdog time in seconds. (default=30)
 nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
 -
-bfin_wdt:
-timeout: Watchdog timeout in seconds. (1<=timeout<=((2^32)/SCLK), default=20)
-nowayout: Watchdog cannot be stopped once started
-   (default=kernel config parameter)
--
 coh901327_wdt:
 margin: Watchdog margin in seconds (default 60s)
 -
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 098e5ed4ee3d..f89f8869ca2a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -815,23 +815,6 @@ config SPRD_WATCHDOG
  Say Y here to include watchdog timer supported
  by Spreadtrum system.
 
-# BLACKFIN Architecture
-
-config BFIN_WDT
-   tristate "Blackfin On-Chip Watchdog Timer"
-   depends on BLACKFIN
-   ---help---
- If you say yes here you will get support for the Blackfin On-Chip
- Watchdog Timer. If you have one of these processors and wish to
- have watchdog support enabled, say Y, otherwise say N.
-
- To compile this driver as a module, choose M here: the
- module will be called bfin_wdt.
-
-# CRIS Architecture
-
-# FRV Architecture
-
 # X86 (i386 + ia64 + x86_64) Architecture
 
 config ACQUIRE_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0474d38aa854..e209824541b8 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -91,13 +91,6 @@ obj-$(CONFIG_UNIPHIER_WATCHDOG) += uniphier_wdt.o
 obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
 obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
 
-# BLACKFIN Architecture
-obj-$(CONFIG_BFIN_WDT) += bfin_wdt.o
-
-# CRIS Architecture
-
-# FRV Architecture
-
 # X86 (i386 + ia64 + x86_64) Architecture
 obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
 obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o
diff --git a/drivers/watchdog/bfin_wdt.c b/drivers/watchdog/bfin_wdt.c
deleted file mode 100644
index aa4d2e8a8ef9..
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/47] arch-removal: device drivers

[Arnd Bergmann]

Hi driver maintainers,

I just posted one series with the removal of eight architectures,
see https://lkml.org/lkml/2018/3/14/505 for details, or
https://lwn.net/Articles/748074/ for more background.

These are the device drivers that go along with them. I have already
picked up the drivers for arch/metag/ into my tree, they were reviewed
earlier.

Please let me know if you have any concerns with the patch, or if you
prefer to pick up the patches in your respective trees.  I created
the patches with 'git format-patch -D', so they will not apply without
manually removing those files.

For anything else, I'd keep the removal patches in my asm-generic tree
and will send a pull request for 4.17 along with the actual arch removal.

   Arnd

Arnd Bergmann
  edac: remove tile driver
  net: tile: remove ethernet drivers
  net: adi: remove blackfin ethernet drivers
  net: 8390: remove m32r specific bits
  net: remove cris etrax ethernet driver
  net: smsc: remove m32r specific smc91x configuration
  raid: remove tile specific raid6 implementation
  rtc: remove tile driver
  rtc: remove bfin driver
  char: remove obsolete ds1302 rtc driver
  char: remove tile-srom.c
  char: remove blackfin OTP driver
  pcmcia: remove m32r drivers
  pcmcia: remove blackfin driver
  ASoC: remove blackfin drivers
  video/logo: remove obsolete logo files
  fbdev: remove blackfin drivers
  fbdev: s1d13xxxfb: remove m32r specific hacks
  crypto: remove blackfin CRC driver
  media: platform: remove blackfin capture driver
  media: platform: remove m32r specific arv driver
  cpufreq: remove blackfin driver
  cpufreq: remove cris specific drivers
  gpio: remove etraxfs driver
  pinctrl: remove adi2/blackfin drivers
  ata: remove bf54x driver
  input: keyboard: remove bf54x driver
  input: misc: remove blackfin rotary driver
  mmc: remove bfin_sdh driver
  can: remove bfin_can driver
  watchdog: remove bfin_wdt driver
  mtd: maps: remove bfin-async-flash driver
  mtd: nand: remove bf5xx_nand driver
  spi: remove blackfin related host drivers
  i2c: remove bfin-twi driver
  pwm: remobe pwm-bfin driver
  usb: host: remove tilegx platform glue
  usb: musb: remove blackfin port
  usb: isp1362: remove blackfin arch glue
  serial: remove cris/etrax uart drivers
  serial: remove blackfin drivers
  serial: remove m32r_sio driver
  serial: remove tile uart driver
  tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
  tty: hvc: remove tile driver
  staging: irda: remove bfin_sir driver
  staging: iio: remove iio-trig-bfin-timer driver

 .../devicetree/bindings/gpio/gpio-etraxfs.txt  |   22 -
 .../bindings/serial/axis,etraxfs-uart.txt  |   22 -
 Documentation/watchdog/watchdog-parameters.txt |5 -
 MAINTAINERS|8 -
 drivers/ata/Kconfig|9 -
 drivers/ata/Makefile   |1 -
 drivers/ata/pata_bf54x.c   | 1703 
 drivers/char/Kconfig   |   48 -
 drivers/char/Makefile  |3 -
 drivers/char/bfin-otp.c|  237 --
 drivers/char/ds1302.c  |  357 --
 drivers/char/tile-srom.c   |  475 ---
 drivers/cpufreq/Makefile   |3 -
 drivers/cpufreq/blackfin-cpufreq.c |  217 -
 drivers/cpufreq/cris-artpec3-cpufreq.c |   93 -
 drivers/cpufreq/cris-etraxfs-cpufreq.c |   92 -
 drivers/crypto/Kconfig |7 -
 drivers/crypto/Makefile|1 -
 drivers/crypto/bfin_crc.c  |  753 
 drivers/crypto/bfin_crc.h  |  124 -
 drivers/edac/Kconfig   |8 -
 drivers/edac/Makefile  |2 -
 drivers/edac/tile_edac.c   |  265 --
 drivers/gpio/Kconfig   |9 -
 drivers/gpio/Makefile  |1 -
 drivers/gpio/gpio-etraxfs.c|  475 ---
 drivers/i2c/busses/Kconfig |   18 -
 drivers/i2c/busses/Makefile|1 -
 drivers/i2c/busses/i2c-bfin-twi.c  |  737 
 drivers/input/keyboard/Kconfig |9 -
 drivers/input/keyboard/Makefile|1 -
 drivers/input/keyboard/bf54x-keys.c|  396 --
 drivers/input/misc/Kconfig |9 -
 drivers/input/misc/Makefile|1 -
 drivers/input/misc/bfin_rotary.c   |  294 --
 drivers/media/platform/Kconfig |   22 -
 drivers/media/platform/Makefile|4 -
 drivers/media/platform/arv.c   |  884 
 drivers/media/platform/blackfin/Kconfig|   16 -
 drivers/media/platform/bl

[PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

Here is the collection of patches I have applied to my 'asm-generic' tree
on top of the 'metag' removal. This does not include any of the device
drivers, I'll send those separately to a someone different list of people.

The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/

Following up from the state described there, I ended up removing the
mn10300, tile, blackfin and cris architectures directly, rather than
waiting, after consulting with the respective maintainers.

However, the unicore32 architecture is no longer part of the removal,
after its maintainer Xuetao Guan said that the port is still actively
being used and that he intends to keep working on it, and that he will
try to provide updated toolchain sources.

In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company in
charge of an SoC line, a CPU microarchitecture and a software ecosystem,
which was more costly than licensing newer off-the-shelf CPU cores from
a third party (typically ARM, MIPS, or RISC-V). It seems that all the
SoC product lines are still around, but have not used the custom CPU
architectures for several years at this point.

  Arnd

Arnd Bergmann (14):
  arch: remove frv port
  arch: remove m32r port
  arch: remove score port
  arch: remove blackfin port
  arch: remove tile port
  procfs: remove CONFIG_HARDWALL dependency
  mm: remove blackfin MPU support
  mm: remove obsolete alloc_remap()
  treewide: simplify Kconfig dependencies for removed archs
  asm-generic: siginfo: remove obsolete #ifdefs
  Documentation: arch-support: remove obsolete architectures
  asm-generic: clean up asm/unistd.h
  recordmcount.pl: drop blackin and tile support
  ktest: remove obsolete architectures

David Howells (1):
  mn10300: Remove the architecture

Jesper Nilsson (1):
  CRIS: Drop support for the CRIS port

Dirstat only (full diffstat is over 100KB):

   6.3% arch/blackfin/mach-bf548/include/mach/
   4.5% arch/blackfin/mach-bf609/include/mach/
  26.3% arch/blackfin/
   4.1% arch/cris/arch-v32/
   5.6% arch/cris/include/arch-v32/arch/hwregs/iop/
   4.1% arch/cris/include/arch-v32/mach-a3/mach/hwregs/
   4.7% arch/cris/include/arch-v32/
   7.8% arch/cris/
   5.6% arch/frv/
   5.5% arch/m32r/
   7.0% arch/mn10300/
   7.6% arch/tile/include/
   6.4% arch/tile/kernel/
   0.0% Documentation/admin-guide/
   0.0% Documentation/blackfin/
   0.0% Documentation/cris/
   0.0% Documentation/devicetree/bindings/cris/
   0.0% Documentation/devicetree/bindings/interrupt-controller/
   2.8% Documentation/features/
   0.5% Documentation/frv/
   0.0% Documentation/ioctl/
   0.0% Documentation/mn10300/
   0.0% Documentation/
   0.0% block/
   0.0% crypto/
   0.0% drivers/ide/
   0.0% drivers/input/joystick/
   0.0% drivers/isdn/hisax/
   0.0% drivers/net/ethernet/davicom/
   0.0% drivers/net/ethernet/smsc/
   0.0% drivers/net/wireless/cisco/
   0.0% drivers/pci/
   0.0% drivers/pwm/
   0.0% drivers/rtc/
   0.0% drivers/spi/
   0.0% drivers/staging/speakup/
   0.0% drivers/usb/musb/
   0.0% drivers/video/console/
   0.0% drivers/watchdog/
   0.0% fs/minix/
   0.0% fs/proc/
   0.0% fs/
   0.0% include/asm-generic/
   0.0% include/linux/
   0.0% include/uapi/asm-generic/
   0.0% init/
   0.0% kernel/
   0.0% lib/
   0.0% mm/
   0.0% samples/blackfin/
   0.0% samples/kprobes/
   0.0% samples/
   0.0% scripts/mod/
   0.0% scripts/
   0.0% tools/arch/frv/include/uapi/asm/
   0.0% tools/arch/m32r/include/uapi/asm/
   0.0% tools/arch/mn10300/include/uapi/asm/
   0.0% tools/arch/score/include/uapi/asm/
   0.0% tools/arch/tile/include/asm/
   0.0% tools/arch/tile/include/uapi/asm/
   0.0% tools/include/asm-generic/
   0.0% tools/scripts/
   0.0% tools/testing/ktest/examples/
   0.0% tools/testing/ktest/

Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-watch...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
> These patches remove the metag architecture and tightly dependent
> drivers from the kernel. With the 4.16 kernel the ancient gcc 4.2.4
> based metag toolchain we have been using is hitting compiler bugs, so
> now seems a good time to drop it altogether.
>
> Quoting from patch 1:
>
> The earliest Meta architecture port of Linux I have a record of was an
> import of a Meta port of Linux v2.4.1 in February 2004, which was worked
> on significantly over the next few years by Graham Whaley, Will Newton,
> Matt Fleming, myself and others.
>
> Eventually the port was merged into mainline in v3.9 in March 2013, not
> long after Imagination Technologies bought MIPS Technologies and shifted
> its CPU focus over to the MIPS architecture.
>
> As a result, though the port was maintained for a while, kept on life
> support for a while longer, and useful for testing a few specific
> drivers for which I don't have ready access to the equivalent MIPS
> hardware, it is now essentially dead with no users.
>
> It is also stuck using an out-of-tree toolchain based on GCC 4.2.4 which
> is no longer maintained, now struggles to build modern kernels due to
> toolchain bugs, and doesn't itself build with a modern GCC. The latest
> buildroot port is still using an old uClibc snapshot which is no longer
> served, and the latest uClibc doesn't build with GCC 4.2.4.
>
> So lets call it a day and drop the Meta architecture port from the
> kernel. RIP Meta.

I've pulled it into my asm-generic tree now, which is also part of linux-next,
and followed up with patches removing frv, m32r, score, unicore32
and blackfin. I have not removed the device drivers yet, but I'm working
on that.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

[Arnd Bergmann]

On Tue, Mar 6, 2018 at 2:05 PM, Pavel Machek  wrote:
> On Tue 2018-03-06 13:54:16, Andrew Lunn wrote:
>> On Tue, Mar 06, 2018 at 01:40:02PM +0100, Pavel Machek wrote:
>> > Hi!
>> >
>> > > Signed-off-by: Jae Hyun Yoo 
>> > > ---
>> > >  .../devicetree/bindings/peci/peci-aspeed.txt   | 73 
>> > > ++
>> > >  1 file changed, 73 insertions(+)
>> > >  create mode 100644 
>> > > Documentation/devicetree/bindings/peci/peci-aspeed.txt
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.txt 
>> > > b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
>> > > new file mode 100644
>> > > index ..8a86f346d550
>> > > --- /dev/null
>> > > +++ b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
>> > > @@ -0,0 +1,73 @@
>> > > +Device tree configuration for PECI buses on the AST24XX and AST25XX 
>> > > SoCs.
>> >
>> > Are these SoCs x86-based?
>>
>> ARM, as far as i can tell. If i get the architecture correct, these
>> are BMC, Board Management Controllers, looking after the main x86 CPU,
>> stopping it overheating, controlling the power supplies, remote
>> management, etc.
>
> Ok, so with x86 machine, I get arm-based one for free. I get it. Is
> user able to run his own kernel on the arm system, or is it locked
> down, TiVo style?

In the past, they were all locked down, the team submitting those
patches in working on changing that. Have a look for OpenBMC.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Fri, Feb 23, 2018 at 12:02 PM, James Hogan  wrote:
> On Fri, Feb 23, 2018 at 11:26:58AM +0100, Arnd Bergmann wrote:
>> On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
>> > So lets call it a day and drop the Meta architecture port from the
>> > kernel. RIP Meta.
>>
>> Since I brought up the architecture removal independently, I could
>> pick this up into a git tree that also has the removal of some of the
>> other architectures.
>>
>> I see your tree is part of linux-next, so you could also just put it
>> in there and send a pull request at the merge window if you prefer.
>>
>> The only real reason I see for a shared git tree would be to avoid
>> conflicts when we touch the same Kconfig files or #ifdefs in driver,
>> but Meta only appears in
>>
>> config FRAME_POINTER
>> bool "Compile the kernel with frame pointers"
>> depends on DEBUG_KERNEL && \
>> (CRIS || M68K || FRV || UML || \
>>  SUPERH || BLACKFIN || MN10300 || METAG) || \
>> ARCH_WANT_FRAME_POINTERS
>>
>> and
>>
>> include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
>> defined(CONFIG_METAG) || defined(CONFIG_IA64)
>>
>> so there is little risk.
>
> I'm happy to put v2 in linux-next now (only patch 4 has changed, I just
> sent an updated version), and send you a pull request early next week so
> you can take it from there. The patches can't be directly applied with
> git-am anyway thanks to the -D option to make them more concise.
>
> Sound okay?

Yes, sounds good, thanks!

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] Remove metag architecture

[Arnd Bergmann]

On Thu, Feb 22, 2018 at 12:38 AM, James Hogan  wrote:
> These patches remove the metag architecture and tightly dependent
> drivers from the kernel. With the 4.16 kernel the ancient gcc 4.2.4
> based metag toolchain we have been using is hitting compiler bugs, so
> now seems a good time to drop it altogether.
>
> Quoting from patch 1:
>
> The earliest Meta architecture port of Linux I have a record of was an
> import of a Meta port of Linux v2.4.1 in February 2004, which was worked
> on significantly over the next few years by Graham Whaley, Will Newton,
> Matt Fleming, myself and others.
>
> Eventually the port was merged into mainline in v3.9 in March 2013, not
> long after Imagination Technologies bought MIPS Technologies and shifted
> its CPU focus over to the MIPS architecture.
>
> As a result, though the port was maintained for a while, kept on life
> support for a while longer, and useful for testing a few specific
> drivers for which I don't have ready access to the equivalent MIPS
> hardware, it is now essentially dead with no users.
>
> It is also stuck using an out-of-tree toolchain based on GCC 4.2.4 which
> is no longer maintained, now struggles to build modern kernels due to
> toolchain bugs, and doesn't itself build with a modern GCC. The latest
> buildroot port is still using an old uClibc snapshot which is no longer
> served, and the latest uClibc doesn't build with GCC 4.2.4.
>
> So lets call it a day and drop the Meta architecture port from the
> kernel. RIP Meta.

Since I brought up the architecture removal independently, I could
pick this up into a git tree that also has the removal of some of the
other architectures.

I see your tree is part of linux-next, so you could also just put it
in there and send a pull request at the merge window if you prefer.

The only real reason I see for a shared git tree would be to avoid
conflicts when we touch the same Kconfig files or #ifdefs in driver,
but Meta only appears in

config FRAME_POINTER
bool "Compile the kernel with frame pointers"
depends on DEBUG_KERNEL && \
(CRIS || M68K || FRV || UML || \
 SUPERH || BLACKFIN || MN10300 || METAG) || \
ARCH_WANT_FRAME_POINTERS

and

include/trace/events/mmflags.h:#elif defined(CONFIG_PARISC) ||
defined(CONFIG_METAG) || defined(CONFIG_IA64)

so there is little risk.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

[Arnd Bergmann]

On Wed, Feb 21, 2018 at 1:57 PM, Masahiro Yamada
 wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann :
>> On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
>>  wrote:
>>> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann :
>>>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
>>>>  wrote:
>>>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson :
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>

One case that comes to mind would be architecture level selection on 32-bit
ARM, which is roughly this (I probably have some details wrong, but you
get the idea):

- older compilers don't support the latest architecture setting (-march=armv8
  or -march=armv7ve)
- newer compilers no longer support really old architectures (-march=armv4)
- setting -mthumb requires setting one of  -march=armv7-a, armv7ve, armv7-m or
  armv8 if the compiler doesn't default to those
- on a compiler that defaults to -marm, setting -march=armv7-m requires
  setting -mthumb (IIRC)
- really old compilers only support OABI, but not EABI
- newer compilers no longer support OABI
- mthumb requires EABI
- armv6 and higher are subtly broken with OABI, but only when using
  certain inline assembly with 64-bit arguments in register pairs.

I think we just shouldn't try to capture all of the above correctly in Kconfig
conditionals.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

[Arnd Bergmann]

On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
 wrote:
> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann :
>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
>>  wrote:
>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson :
>
> Let me clarify my concern.
>
> When we test the compiler flag, is there a case
> where a particular flag depends on -m{32,64} ?
>
> For example, is there a compiler that supports -fstack-protector
> for 64bit mode, but unsupports it for 32bit mode?
>
>   $(cc-option -m32) ->  y
>   $(cc-option -m64) ->  y
>   $(cc-option -fstack-protector)->  y
>   $(cc-option -m32 -fstack-protector)   ->  n
>   $(cc-option -m64 -fstack-protector)   ->  y
>
> I guess this is unlikely to happen,
> but I am not whether it is zero possibility.
>
> If this could happen,
> $(cc-option ) must be evaluated together with
> correct bi-arch option (either -m32 or -m64).
>
>
> Currently, -m32/-m64 is specified in Makefile,
> but we are moving compiler tests to Kconfig
> and, CONFIG_64BIT can be dynamically toggled in Kconfig.

I don't think it can happen for this particular combination (stack protector
and word size), but I'm sure we'll eventually run into options that
need to be tested in combination. For the current CFLAGS_KERNEL
setting, we definitely have the case of needing the variables to be
evaluated in a specific order.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

[Arnd Bergmann]

On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
 wrote:
> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson :
>
>>>
>>> I'm not happy that we in one context can reference CONFIG variables
>>> directly, but inside the $(call ...) and $(shell ...) needs the $ prefix.
>>> But I could not come up with something un-ambigious where this could be 
>>> avoided.
>>
>> I think we should be careful about allowing references to config
>> symbols. It mixes up the parsing and evaluation phases, since $() is
>> expanded during parsing (which I consider a feature and think is
>> needed to retain sanity).
>>
>> Patch 06/23 removes the last existing instance of symbol references in
>> strings by getting rid of 'option env'. That's an improvement to me.
>> We shouldn't add it back.
>
>
> This is really important design decision,
> so I'd like to hear a little more from experts.
>
>
> For example, x86 allows users to choose sub-arch, either 'i386' or 'x86_64'.
>
> https://github.com/torvalds/linux/blob/v4.16-rc2/arch/x86/Kconfig#L4
>
>
>
> If the user toggles CONFIG_64BIT,
> the bi-arch compiler will work in a slightly different mode
> (at least, back-end parts)
>
> So, my question is, is there a case,
>
> $(cc-option, -m32 -foo) is y, but
> $(cc-option, -m64 -foo) is n  ?
> (or vice versa)
>
>
> If the answer is yes, $(cc-option -foo) would have to be re-calculated
> every time CONFIG_64BIT is toggled.
>
> This is what I'd like to avoid, though.

The -m32/-m64 trick (and -mbig-endian/-mlittle-endian on other architectures
as well as a couple of other flags) only works if the compiler is configured to
support it. In other cases (e.g. big-endian xtensa), the kernel always
detects what the compiler does and silently configures itself to match
using Makefile logic.

On x86, compilers are usually built as bi-arch, but you can build one that
only allows one of them.

I can see two reasonable ways out:

- we don't use  $(cc-option -foo) in a case like this, and instead require the
  user to have a matching toolchain.
- we could make the 32/64 selection on x86 a 'choice' statement where
  each option depends on both the ARCH= variable and the
  $(cc-option, -m32)/ $(cc-option, -m64) output.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

[Arnd Bergmann]

On Fri, Jan 26, 2018 at 3:39 AM, Rob Landley  wrote:

> The problem with 1 second timestamps was you honestly could confuse
> "make" about which file was newer once an exec() could complete in the
> same second having done real work. That was the motivating issue causing
> the change, going to nanoseconds was just the big hammer of "this is
> large enough it won't matter again in our lifetimes". But nanosecond
> time stamps are recording more jitter than useful information, and that
> seems unlikely to change this century?

Sure, the only thing we really need the nanosecond timestamp for is
to keep them identical. E.g. if you use cpio to make an exact copy
of a file system, using microseconds timestamps will round all mtime
values. If you then use 'rsync' to compare/update the two copies
without passing a --modify-window= or --size-only, it will have
to read all files in rather then skipping those with identical size and
mtime.

Side note: the default behavior for file systems is actually to only use
the coarse timestamps of the last timer tick, so you actually do get
identical timestamps in practice, plus six digits of nonsense:

(on tmpfs)
 $ for i in {000..999} ; do > $i ; done; stat --format="%y" *  | uniq -c
 86 2018-01-26 10:01:48.811135084 +0100
469 2018-01-26 10:01:48.815135143 +0100
445 2018-01-26 10:01:48.819135201 +0100

 Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

[Arnd Bergmann]

On Thu, Jan 25, 2018 at 9:26 PM, Taras Kondratiuk  wrote:
> Quoting Arnd Bergmann (2018-01-25 01:29:12)
>> On Thu, Jan 25, 2018 at 4:27 AM, Taras Kondratiuk  wrote:
>
> We can match statx(2) by having 64 bits for seconds plus 32 bits for
> nanoseconds.

Ok.

> For initramfs nanoseconds field can be ignored during
> unpacking.

That sounds like a pointless microoptimization. Most likely we won't ever
need the nanoseconds in the initramfs, but it's trivial to just copy them
into the right field, and not adding that one source line would probably
involve adding a one-line source comment to explain the omission ;-)

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

[Arnd Bergmann]

On Thu, Jan 25, 2018 at 4:27 AM, Taras Kondratiuk  wrote:
> Many of the Linux security/integrity features are dependent on file
> metadata, stored as extended attributes (xattrs), for making decisions.
> These features need to be initialized during initcall and enabled as
> early as possible for complete security coverage.
>
> Initramfs (tmpfs) supports xattrs, but newc CPIO archive format does not
> support including them into the archive.
>
> This patch describes "extended" newc format (newcx) that is based on
> newc and has following changes:
> - extended attributes support
> - increased size of filesize to support files >4GB.
> - increased mtime field size to have usec precision and more than
>   32-bit of seconds.
> - removed unused checksum field.
>
> Signed-off-by: Taras Kondratiuk 
> Signed-off-by: Mimi Zohar 
> Signed-off-by: Victor Kamensky 

Ah nice, I like the extension of the time handling, that certainly
addresses one of the issues with y2038 that we have previously
hacked around in an ugly way (interpreting the 32-bit
number as unsigned).

However, if this is to become a generally supported format
for cpio files, could we make it use nanosecond resolution
instead? The issue that I see with microseconds is that
storing a file in an archive and extracting it again would
otherwise keep the mtime stamp /almost/ identical on file
systems that have nanosecond resolution, but most of
the time a comparison would indicate that the files are
not the same.

Unfortunately, the range of a 64-bit nanoseconds counter
is still a bit limited (584 years, or half of that if we make it
signed). While this is clearly enough for the uses in
initramfs, it still has a similar problem: someone creating
a fake timestamp a long time in the past or future on
a file system would lose information after going though
cpio.

 Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux dev-4.10 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon

[Arnd Bergmann]

On Thu, Jan 11, 2018 at 12:45 AM, Jae Hyun Yoo
 wrote:
> On 1/10/2018 4:29 AM, Arnd Bergmann wrote:
>>
>> On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
>>  wrote:
>>>
>>> This commit adds driver implementation for a generic PECI hwmon.
>>>
>>> Signed-off-by: Jae Hyun Yoo 
>>
>>
>>> +static int xfer_peci_msg(int cmd, void *pmsg)
>>> +{
>>> +   int rc;
>>> +
>>> +   mutex_lock(&peci_hwmon_lock);
>>> +   rc = peci_ioctl(NULL, cmd, (unsigned long)pmsg);
>>> +   mutex_unlock(&peci_hwmon_lock);
>>> +
>>> +   return rc;
>>> +}
>>
>>
>> I said earlier that peci_ioctl() looked unused, that was obviously
>> wrong, but what you have here
>> is not a proper way to abstract a bus.
>>
>> Maybe this can be done more like an i2c bus: make the peci controller
>> a bus device
>> and register all known target/index pairs as devices with the peci bus
>> type, and have
>> them probed from DT. The driver can then bind to each of those
>> individually.
>> Not sure if that is getting to granular at that point, I'd have to
>> understand better
>> how it is expected to get used, and what the variances are between
>> implementations.
>>
>
> Thanks for sharing your opinion. In fact, this was also suggested by openbmc
> community so I should consider of redesigning it. I'm currently thinking
> about adding a new PECI device class as an abstract layer and any BMC
> chipset specific driver could be attached to the PECI class driver. Then,
> each CPU client could be registered as an individual device as you
> suggested. Will consider your suggestion.

Another idea might be to pretend that PECI was I2C. We already have a few
drivers for hardware that is not I2C but whose software interface looks
similar enough that it just works. No idea if that is the case for PECI, but
xfer_peci_msg might be close enough to i2c_xfer to make it work. If you
are able to do that, then the PECI controller would just register itself
as an i2c controller and it can be accessed using /dev/i2c from user space
or a high-level i2c_driver.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

[Arnd Bergmann]

On Thu, Jan 11, 2018 at 9:41 AM, Greg KH  wrote:
> On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote:
>> On Wed, Jan 10, 2018 at 11:30 PM, Greg KH  wrote:
>> > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote:
>> >> Thanks for your pointing it out and I totally agree with you. Actually, we
>> >> are preparing 4.13 update for now and an another update will be followed 
>> >> up.
>> >> As I answered above, I'll rebase this patch set onto the latest kernel.org
>> >> mainline. Sorry for my misunderstanding of upstream process.
>> >
>> > 4.13?  Why that kernel?  It too is obsolete and insecure and
>> > unsupported.
>>
>> It contains support for our hardware that I have integrated from work
>> in progress patches and upstream commits.
>>
>> The OpenBMC project, with myself as the kernel maintainer, have
>> intentions to regularly move to upstream releases. This takes time and
>> effort. This time and effort is balanced with submitting our drivers
>> upstream.
>
> Of course, but please do not have your "users" use a kernel that is
> known to have bugs and can not be supported.  That would not be good at
> all, don't you think?

I've been pretty happy with the progress in merging drivers upstream
for OpenBMC. Of course things always take longer than planned,
but they are getting there. Most servers today are probably running
the aspeed vendor kernel based on linux-2.6.28.10, at least that's
what my workstation runs (and no, I did not connect the BMC to my
home network).

The particular choices of mainline versions (4.10 and 4.13) may be
unfortunate as they are both one off from a longterm release, but
not being stuck on 2.6 is the important first step in order to upstream
stuff.

>> Another silicon vendor has recently joined the project and that brings
>> an entire SoC that is not upstream. We have patches on the ARM that
>> are under review for this SoC, with more drivers undergoing cleanup in
>> order to submit them to the relevant maintainers.
>
> Why are you merging all SoC trees together into one place?  That seems
> like a nightmare to manage, especially with git.

Why would anyone want to have multiple kernel trees just to run
things on different SoCs? ;-)

It's just a collection of device drivers in different stages of getting
upstreamed.

>> > And if you do have out-of-tree code, why not use a process that makes it
>> > trivial to update the base kernel version so that you can keep up to
>> > date very easily?  (hint, just using 'git' is not a good way to do
>> > this...)
>>
>> We have a process that we've been developing under for the past few
>> years. I find git to be a great tool for managing Linux kernel trees.
>>
>> What would you recommend for managing kernel trees?
>
> quilt is best for a tree that you can not rebase (i.e. a public git
> tree).  Otherwise you end up getting patches all mushed together and
> hard to extract in any simple way.

I'm ususally happy with having git with topic branches to make the
rebasing easier. In many cases, you can just leave a topic branch
for a particular subsystem unchanged between versions and just
merge the latest version of those branches until the branch goes
away after upstreaming.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux dev-4.10 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon

[Arnd Bergmann]

On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
 wrote:
> This commit adds driver implementation for a generic PECI hwmon.
>
> Signed-off-by: Jae Hyun Yoo 

> +static int xfer_peci_msg(int cmd, void *pmsg)
> +{
> +   int rc;
> +
> +   mutex_lock(&peci_hwmon_lock);
> +   rc = peci_ioctl(NULL, cmd, (unsigned long)pmsg);
> +   mutex_unlock(&peci_hwmon_lock);
> +
> +   return rc;
> +}

I said earlier that peci_ioctl() looked unused, that was obviously
wrong, but what you have here
is not a proper way to abstract a bus.

Maybe this can be done more like an i2c bus: make the peci controller
a bus device
and register all known target/index pairs as devices with the peci bus
type, and have
them probed from DT. The driver can then bind to each of those individually.
Not sure if that is getting to granular at that point, I'd have to
understand better
how it is expected to get used, and what the variances are between
implementations.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux dev-4.10 4/6] Documentation: dt-bindings: Add a generic PECI hwmon

[Arnd Bergmann]

On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
 wrote:
> This commit add a dt-bindings document for a generic PECI hwmon
> driver.
>
> Signed-off-by: Jae Hyun Yoo 
> ---
>  .../devicetree/bindings/hwmon/peci-hwmon.txt   | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt 
> b/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
> new file mode 100644
> index 000..20b86f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
> @@ -0,0 +1,33 @@
> +* Generic PECI (Platform Environment Control Interface) hwmon driver.
> +
> +Dependency:
> +- This driver uses a PECI misc driver as a controller interface so one of 
> PECI
> +  misc drivers which provides compatible ioctls has to be enabled.

The binding should only explain how we describe the hardware in an
operating-system
independent way, but not talk about how an OS is supposed to implement those
drivers.

Having multiple drivers each provide an exported function is not possible
in Linux: it immediately breaks building an 'allyesconfig' kernel, and prevents
you from running the same kernel across multiple implementations, so that
has to be redesigned anyway.

> +Required properties:
> +- compatible: "peci-hwmon"
> +- cpu-id: Should contain CPU socket ID
> +   - 0 ~ 7
> +
> +Optional properties:
> +- show-core: If this protperty is defined, core tmeperature attrubites will 
> be

s/protperty/property/
s/tmeperature/temperature/
s/attrubites/attributes/

> +enumerated.
> +- dimm-nums: Should contain the number of DIMM slots that attached to each 
> CPU
> +which is indicated by cpu-id.
> +   0 ~ 16 (default: 16)
> +In case of 0, DIMM temperature attrubites will not be enumerated.

Is this only an initial list that you expect to be extended in the
future, or is this
a complete list of sensors that can ever be connected to PECI?

Should this be PECI version specific?

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers

[Arnd Bergmann]

On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
 wrote:
> This commit adds driver implementation for Aspeed PECI. Also adds
> generic peci.h and peci_ioctl.h files to provide compatibility
> to peci drivers that can be implemented later e.g. Nuvoton's BMC
> SoC family.
>
> Signed-off-by: Jae Hyun Yoo 

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

semaphore.h is not used here and can be dropped.

> +static struct aspeed_peci *aspeed_peci_priv;

Try to avoid instance variables like this one. You should always be able to find
that pointer from whatever structure you were called with.


> +   timeout = wait_for_completion_interruptible_timeout(
> +   &priv->xfer_complete,
> +   
> msecs_to_jiffies(priv->cmd_timeout_ms));
> +
> +   dev_dbg(priv->dev, "INT_STS : 0x%08x\n", priv->sts);
> +   if (!regmap_read(priv->regmap, AST_PECI_CMD, &peci_state))
> +   dev_dbg(priv->dev, "PECI_STATE : 0x%lx\n",
> +   PECI_CMD_STS_GET(peci_state));
> +   else
> +   dev_dbg(priv->dev, "PECI_STATE : read error\n");
> +
> +   if (timeout <= 0 || !(priv->sts & PECI_INT_CMD_DONE)) {
> +   if (timeout <= 0) {
> +   dev_dbg(priv->dev, "Timeout waiting for a 
> response!\n");
> +   rc = -ETIME;
> +   } else {
> +   dev_dbg(priv->dev, "No valid response!\n");
> +   rc = -EFAULT;
> +   }
> +   return rc;
> +   }

You don't seem to handle -ERESTARTSYS correct here. Either do it
right, or drop the _interruptible part above.

> +typedef int (*ioctl_fn)(struct aspeed_peci *, void *);
> +
> +static ioctl_fn peci_ioctl_fn[PECI_CMD_MAX] = {
> +   ioctl_xfer_msg,
> +   ioctl_ping,
> +   ioctl_get_dib,
> +   ioctl_get_temp,
> +   ioctl_rd_pkg_cfg,
> +   ioctl_wr_pkg_cfg,
> +   ioctl_rd_ia_msr,
> +   NULL, /* Reserved */
> +   ioctl_rd_pci_cfg,
> +   NULL, /* Reserved */
> +   ioctl_rd_pci_cfg_local,
> +   ioctl_wr_pci_cfg_local,
> +};
> +
> +
> +long peci_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> +{
> +   struct aspeed_peci *priv;
> +   long ret = 0;
> +   void __user *argp = (void __user *)arg;
> +   int timeout = PECI_IDLE_CHECK_TIMEOUT;
> +   u8 msg[sizeof(struct peci_xfer_msg)];
> +   unsigned int peci_cmd, msg_size;
> +   u32 cmd_sts;
> +
> +   /*
> +* Treat it as an inter module call when filp is null but only in case
> +* the private data is initialized.
> +*/
> +   if (filp)
> +   priv = container_of(filp->private_data,
> +   struct aspeed_peci, miscdev);
> +   else
> +   priv = aspeed_peci_priv;

Drop this.

> +   if (!priv)
> +   return -ENXIO;
> +
> +   switch (cmd) {
> +   case PECI_IOC_XFER:
> +   case PECI_IOC_PING:
> +   case PECI_IOC_GET_DIB:
> +   case PECI_IOC_GET_TEMP:
> +   case PECI_IOC_RD_PKG_CFG:
> +   case PECI_IOC_WR_PKG_CFG:
> +   case PECI_IOC_RD_IA_MSR:
> +   case PECI_IOC_RD_PCI_CFG:
> +   case PECI_IOC_RD_PCI_CFG_LOCAL:
> +   case PECI_IOC_WR_PCI_CFG_LOCAL:
> +   peci_cmd = _IOC_TYPE(cmd) - PECI_IOC_BASE;
> +   msg_size = _IOC_SIZE(cmd);
> +   break;

Having to keep the switch() statement and the array above seems a
little fragile. Can you just do one or the other?

Regarding the command set, you have both a low-level PECI_IOC_XFER
interface and a high-level interface. Can you explain why? I'd think that
generally speaking it's better to have only one of the two.

> +   /* Check command sts and bus idle state */
> +   while (!regmap_read(priv->regmap, AST_PECI_CMD, &cmd_sts)
> +  && (cmd_sts & (PECI_CMD_STS_MASK | PECI_CMD_PIN_MON))) {
> +   if (timeout-- < 0) {
> +   dev_dbg(priv->dev, "Timeout waiting for idle 
> state!\n");
> +   ret = -ETIME;
> +   goto out;
> +   }
> +   usleep_range(1, 11000);
> +   };

To implement timeout, it's better to replace the counter with a
jiffies/time_before or ktime_get()/ktime_before() check, since usleep_range()
is might sleep considerably longer than expected.

> +EXPORT_SYMBOL_GPL(peci_ioctl);

No user of this, so drop it.

> +static int aspeed_peci_open(struct inode *inode, struct file *filp)
> +{
> +   struct aspeed_peci *priv =
> +   container_of(filp->private_data, struct aspeed_peci, miscdev);
> +
> +   atomic_inc(&priv->ref_count);
> +
> +   dev_dbg(priv->dev, "ref_count : %d\n", atomic_read(&priv->ref_count));
> +
> +   

Re: [PATCH v10 11/13] slimbus: qcom: Add Qualcomm Slimbus controller driver

[Arnd Bergmann]

> +
> +   ctrl->tx.base = dmam_alloc_coherent(&pdev->dev,
> +  (ctrl->tx.sl_sz * ctrl->tx.n),
> +  &ctrl->tx.phy, GFP_KERNEL);
> +   if (!ctrl->tx.base) {
> +   ret = -ENOMEM;
> +   goto err;
> +   }
> +
> +   ctrl->rx.base = dmam_alloc_coherent(&pdev->dev,
> +  (ctrl->rx.sl_sz * ctrl->rx.n),
> +  &ctrl->rx.phy, GFP_KERNEL);

I got another one of

/git/arm-soc/drivers/slimbus/qcom-ctrl.c: In function 'qcom_slim_probe':
/git/arm-soc/drivers/slimbus/qcom-ctrl.c:584:9: error: passing
argument 3 of 'dmam_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
 &ctrl->tx.phy, GFP_KERNEL);
 ^
In file included from /git/arm-soc/drivers/slimbus/qcom-ctrl.c:16:0:
/git/arm-soc/include/linux/dma-mapping.h:760:14: note: expected
'dma_addr_t * {aka unsigned int *}' but argument is of type
'phys_addr_t * {aka long long unsigned int *}'
 extern void *dmam_alloc_coherent(struct device *dev, size_t size,
  ^~~
/git/arm-soc/drivers/slimbus/qcom-ctrl.c:592:9: error: passing
argument 3 of 'dmam_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
 &ctrl->rx.phy, GFP_KERNEL);
 ^
In file included from /git/arm-soc/drivers/slimbus/qcom-ctrl.c:16:0:
/git/arm-soc/include/linux/dma-mapping.h:760:14: note: expected
'dma_addr_t * {aka unsigned int *}' but argument is of type
'phys_addr_t * {aka long long unsigned int *}'
 extern void *dmam_alloc_coherent(struct device *dev, size_t size,


I don't have time to analyze this further, but I guess this is the
same confusion
that happened in a few other qualcomm drivers, which all used dma_alloc_*
to get a buffer that gets passed into firmware.This is always wrong.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Arnd Bergmann]

On Tue, Aug 1, 2017 at 5:14 PM, Boris Brezillon
 wrote:
> On Tue, 1 Aug 2017 16:22:21 +0200 Arnd Bergmann  wrote:
>> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
>>  wrote:
>> > On Tue, 1 Aug 2017 15:34:14 +0200
>> > Boris Brezillon  wrote:
>> >> On Tue, 1 Aug 2017 15:11:44 +0200
>> >> Arnd Bergmann  wrote:
>> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> >> >  wrote:
>> > I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
>> > entry. Indeed, I'm unconditionally calling functions provided by the
>> > I2C framework which have no dummy wrapper when I2C support is disabled.
>> > I could of course conditionally compile some portion of the I3C
>> > framework so that it still builds when I2C is disabled but I'm not sure
>> > it's worth the trouble.
>> >
>> > This "depends on I2C" should also solve the I2C+I3C driver issue, since
>> > I2C is necessarily enabled when I3C is.
>> >
>> > Am I missing something?
>>
>> That should solve another part of the problem, as a combined driver then
>> just needs 'depends on I3C'.
>>
>> On top of that, the i3c_driver structure could also contain callback
>> pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
>> When the i2c_probe() callback exists, the i3c layer could construct
>> a 'struct i2c_driver' with those callbacks and register that under the
>> cover. This would mean that combined drivers no longer need to
>> register two driver objects.
>
> That should work. Actually, i2c_driver contains a few more hooks, like
> ->alert(), ->command() and ->detect(). Of course we could assume that
> I3C/I2C drivers do not need them,

I was thinking we can add them as they are needed.

> but I'm wondering if it's not easier
> to just add an i2c_driver pointer inside the i3c_driver struct and let
> the driver populate it if it needs to supports both protocols.
>
> Something like:
>
> struct i3c_driver {
> ...
> struct i2c_driver *i2c_compat;
> ...
> };
>
>
> and then in I3C/I2C drivers:
>
> static struct i2c_driver my_i2c_driver = {
> ...
> };
>
> static struct i3c_driver my_i3c_driver = {
> ...
> .i2c_compat = &my_i2c_driver,
> ...
> };
> module_i3c_driver(my_i3c_driver);
>
>
>
> Of course, you'll have a few fields of ->i2c_compat that would be
> filled by the core (like the driver name which can be extracted from
> my_i3c_driver->driver.name).

Right, that would work too, but it's almost the same as the version
you proposed earlier that would use

module_i2c_i3c_driver(my_i2c_driver, my_i3c_driver);

It's probably a little cleaner this way in the subsystem implementation
compared to my suggestion of adding the i2c callback pointers in
struct i3c_driver, while that would make the drivers look a little nicer
(and save a few lines per driver).

 Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Arnd Bergmann]

On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
 wrote:
> On Tue, 1 Aug 2017 15:34:14 +0200
> Boris Brezillon  wrote:
>> On Tue, 1 Aug 2017 15:11:44 +0200
>> Arnd Bergmann  wrote:
>> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> >  wrote:
> I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
> entry. Indeed, I'm unconditionally calling functions provided by the
> I2C framework which have no dummy wrapper when I2C support is disabled.
> I could of course conditionally compile some portion of the I3C
> framework so that it still builds when I2C is disabled but I'm not sure
> it's worth the trouble.
>
> This "depends on I2C" should also solve the I2C+I3C driver issue, since
> I2C is necessarily enabled when I3C is.
>
> Am I missing something?

That should solve another part of the problem, as a combined driver then
just needs 'depends on I3C'.

On top of that, the i3c_driver structure could also contain callback
pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
When the i2c_probe() callback exists, the i3c layer could construct
a 'struct i2c_driver' with those callbacks and register that under the
cover. This would mean that combined drivers no longer need to
register two driver objects.

 Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Arnd Bergmann]

On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
 wrote:
> On Tue, 1 Aug 2017 14:00:05 +0200
> Arnd Bergmann  wrote:

>> Another argument for a combined bus would be devices that
>> can be attached to either i2c and i3c, depending on the host
>> capabilities.
>
> Hm, that's already the case, isn't it? And you'll anyway need to
> develop specific code for both cases in the I2C/I3C device driver
> because I2C and I3C transfers are different. So I don't see how it
> would help to have a single bus here.
>
>> We have discussed whether i2c and spi should be
>> merged into a single bus_type in the past, as a lot of devices
>> can be attached to either of them.
>
> Oh, really? What's the rational behind that? I mean, I2C and SPI are
> quite different, and even if some devices provide both interfaces, I
> don't see why we should merge them. But you probably had good reasons
> to do so.

Well, we never changed it, so at least the work required to merge
the two was considered too much to justify any advantages.

The main problem with having one driver that can operate on
different bus types (i2c plus either spi or i3c) is the handling for
the various combinations in configurations (e.g. I2C=m, SPI=y).

The easy case is having a module_init function that registers two
device drivers, but that requires having a Kconfig dependency
on both subsystems, and you can't use the module_i2c_driver()
helper.

The second way is to have a number of #ifdef and complex
Kconfig dependencies for the driver to only register the
device_driver objects for the buses that are enabled. This
is also doable, but everyone gets the logic wrong the first time.

What we end up doing to work around this for other drivers is
to have the base driver in one library module, and separate
modules for the bus-specific portions, which can then
use module_i2c_driver again. There are many instances
for combined i2c/spi drivers in the kernel, and it works fine,
but it adds a fair bit of overhead compared to having one
driver that would e.g. use regmap to abstract the differences
in the probe() function and otherwise keeps everything in
one place.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Arnd Bergmann]

On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
 wrote:
> Hi Arnd,
>
> Le Mon, 31 Jul 2017 22:16:42 +0200,
> Arnd Bergmann  a écrit :
>
>> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
>>  wrote:
>> > Add core infrastructure to support I3C in Linux and document it.
>>
>> > - I2C backward compatibility has been designed to be transparent to I2C
>> >   drivers and the I2C subsystem. The I3C master just registers an I2C
>> >   adapter which creates a new I2C bus. I'd say that, from a
>> >   representation PoV it's not ideal because what should appear as a
>> >   single I3C bus exposing I3C and I2C devices here appears as 2
>> >   different busses connected to each other through the parenting (the
>> >   I3C master is the parent of the I2C and I3C busses).
>> >   On the other hand, I don't see a better solution if we want something
>> >   that is not invasive.
>>
>> Can you describe the reasons for making i3c a separate subsystem then,
>> rather than extending the i2c subsystem to handle both i2c devices as
>> before and also i3c devices and hosts?
>
> Actually, that's the first option I considered, but I3C and I2C are
> really different. I'm not talking about the physical layer here, but
> the way the bus has to be handled by the software layer. Actually, I
> thing the I3C bus is philosophically closer to auto-discoverable busses
> like USB than I2C or SPI.
>
> Indeed, all I3C devices can be discovered and do not need to be
> described at the board level (using DT, board files, ACPI or whatever).
> Also, some I3C devices are hotpluggable, and most importantly, all I3C
> devices describe themselves during the discovery procedure (called DAA
> in the I3C world).

Side note: please make sure you define a way to describe them
in DT anyway. We ended up needing additional DT properties
as well as power sequencing for most discoverable buses (pci,
usb, mmc, ...), I'm sure this one won't be an exception even though
the standard says you don't need it and most devices will work
without it.

> There is some kind of "device class" concept. In the I3C world it's
> called DCR (Device Characteristic Register), but it plays the same role:
> it's a set of generic interfaces devices have to comply with when they
> declare themselves as being compatible with a DCR ID (like
> accelerometer, gyroscope, or whatever). See this table of normalized
> DCR for more information [1].
>
> Devices also expose a 48-bit Provisional ID which is made of
> sub-fields. Two of them are particularly interesting: the manufacturer
> ID and the part ID, which are comparable to the vendor and product ID in
> the USB world.
>
> These three information (DCR, ManufacturerID and PartID) can be used to
> match drivers instead of the compatible string or driver-name used for
> I2C devices

The matching would be fairly easy to accomodate: the i2c bus already
handles two distinct ways: of_device_id tables and matching by
name, so we could easily add another method here.

> So, as you can imagine, dealing with an I3C bus is really different
> from dealing with an I2C bus, and I found the "expose an i2c_adapter
> object for each i3c_master" way simpler (and less invasive) than
> extending the I2C framework to support I3C devices.
>
> Of course, I can move all the code in drivers/i2c/, but that won't
> change the fact that I3C and I2C busses are completely different
> with little to share between them.
>
> To me, the I2C backward compatibility is just a nice feature that was
> added to help people smoothly transition from mixed I3C busses with
> both I2C and I3C devices connected to it (I2C devices being here
> when no (affordable) equivalent exist in the I3C world) to pure I3C
> busses with only I3C devices connected to it.
>
> This being said, I'd be happy if you prove me wrong and propose a
> solution that allows us to extend the I2C framework to support I3C
> without to much pain ;-).

I think the question is not whether it can be done or not, but whether
it is a good idea. Obviously we can create some frankenstein bus
design that combines arbitrary different device types by just containing
the superset of the required information, and sprinking the code
with if()/else() to call one or the other function.

If there is very little shared code between the i2c and i3c
implementations, then the added complexity of having a combined
subsystem is clearly a strong argument against it.

On the other hand, there is value in representing the physical
bus hierarchy in the software model, and if i2c and i3c devices can
be attached to the same host bus, a good abstraction should
show them under the same paren

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Arnd Bergmann]

On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
 wrote:
> Add core infrastructure to support I3C in Linux and document it.

> - I2C backward compatibility has been designed to be transparent to I2C
>   drivers and the I2C subsystem. The I3C master just registers an I2C
>   adapter which creates a new I2C bus. I'd say that, from a
>   representation PoV it's not ideal because what should appear as a
>   single I3C bus exposing I3C and I2C devices here appears as 2
>   different busses connected to each other through the parenting (the
>   I3C master is the parent of the I2C and I3C busses).
>   On the other hand, I don't see a better solution if we want something
>   that is not invasive.

Can you describe the reasons for making i3c a separate subsystem then,
rather than extending the i2c subsystem to handle both i2c devices as
before and also i3c devices and hosts?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Arnd Bergmann]

On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst  wrote:
> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky  wrote:
>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
>>
>> I originally had a check for SME here in a previous version of the
>> patch.  Thomas Gleixner recommended removing the check so that the code
>> path was always exercised regardless of the state of SME in order to
>> better detect issues:
>>
>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>
> Looking a bit closer, this shortcut doesn't set the caching
> attributes.  So it's probably best to get rid of it anyways.  Also
> note, there is a corresponding check in iounmap().

Could that cause regressions if a driver relies on (write-through)
cacheable access to the VGA frame buffer RAM or an read-only
cached access to an option ROM but now gets uncached access?

I also tried to find out whether we can stop mapping the ISA MMIO
area into the linear mapping, but at least the VGA code uses
VGA_MAP_MEM() to get access to the same pointers. I'm pretty
sure this got copied incorrectly into most other architectures, but
it is definitely still used on x86 with vga16fb/vgacon/mdacon.

On the plus side, I see that removing this code path will end up
restoring MMIOTRACE support for the ISA MMIO range that was
apparently removed by accident in commit d61fc44853f4
("x86: mmiotrace, preview 2") in linux-2.6.27.

  Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/20] arm64: ilp32: share aarch32 syscall handlers

[Arnd Bergmann]

On Thu, Jun 8, 2017 at 4:10 PM, Catalin Marinas  wrote:
> On Sun, Jun 04, 2017 at 03:00:02PM +0300, Yury Norov wrote:
>> off_t is  passed in register pair just like in aarch32.
>> In this patch corresponding aarch32 handlers are shared to
>> ilp32 code.
>
> Is the comment here relevant? IOW, do we have any AArch64/ILP32 syscall
> where off_t is used as an argument? AFAICT, the *64 syscalls use loff_t
> or loff_t *.

I think it should just be reworded, the 'off_t' above seems to refer to the
user space type that corresponds to the kernel's loff_t.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/7] nios2: put setup.h in uapi

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:55 AM CET Nicolas Dichtel wrote:

> diff --git a/arch/nios2/include/uapi/asm/setup.h 
> b/arch/nios2/include/uapi/asm/setup.h
> new file mode 100644
> index ..8d8285997ba8
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/setup.h
> @@ -0,0 +1,6 @@
> +#ifndef _UAPI_ASM_NIOS2_SETUP_H
> +#define _UAPI_ASM_NIOS2_SETUP_H
> +
> +#include 
> +
> +#endif /* _UAPI_ASM_NIOS2_SETUP_H */
> 

This one is only a redirect to an asm-generic header, so it can be
removed completely and replaced with a line in the 
arch/nios2/include/uapi/asm/ file:

generic-y += setup.h

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] uapi: export all headers under uapi directories

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> Here is the v2 of this series. The first 5 patches are just cleanup: some
> exported headers were still under a non-uapi directory.

Since this is meant as a cleanup, I commented on this to point out a cleaner
way to do the same.

> The patch 6 was spotted by code review: there is no in-tree user of this
> functionality.
> The last patch remove the use of header-y. Now all files under an uapi
> directory are exported.

Very nice!

> asm is a bit special, most of architectures export asm//include/uapi/asm
> only, but there is two exceptions:
>  - cris which exports arch/cris/include/uapi/arch-v[10|32];

This is interesting, though not your problem. Maybe someone who understands
cris better can comment on this: How is the decision made about which of
the arch/user.h headers gets used? I couldn't find that in the sources,
but it appears to be based on kernel compile-time settings, which is
wrong for user space header files that should be independent of the kernel
config.

>  - tile which exports arch/tile/include/uapi/arch.
> Because I don't know if the output of 'make headers_install_all' can be 
> changed,
> I introduce subdir-y in Kbuild file. The headers_install_all target copies all
> asm//include/uapi/asm to usr/include/asm- but
> arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> prefixed (they are put asis in usr/include/). If it's acceptable to modify the
> output of 'make headers_install_all' to export asm headers in
> usr/include/asm-/asm, then I could remove this new subdir-y and exports
> everything under arch//include/uapi/.

I don't know if anyone still uses "make headers_install_all", I suspect
distros these days all use "make headers_install", so it probably
doesn't matter much.

In case of cris, it should be easy enough to move all the contents of the
uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
only seem to be referenced from there.

For tile, I suspect that would not work as the arch/*.h headers are
apparently defined as interfaces for both user space and kernel.

> Note also that exported files for asm are a mix of files listed by:
>  - include/uapi/asm-generic/Kbuild.asm;
>  - arch/x86/include/uapi/asm/Kbuild;
>  - arch/x86/include/asm/Kbuild.
> This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> used by scripts/Makefile.asm-generic).
> 
> This series has been tested with a 'make headers_install' on x86 and a
> 'make headers_install_all'. I've checked the result of both commands.
> 
> This patch is built against linus tree. I don't know if it should be
> made against antoher tree.

The series should probably get merged through the kbuild tree, but testing
it on mainline is fine here.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/7] arm: put types.h in uapi

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> 
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> index a53cdb8f068c..c48fee3d7b3b 100644
> --- a/arch/arm/include/asm/types.h
> +++ b/arch/arm/include/asm/types.h
> @@ -1,40 +1,6 @@
>  #ifndef _ASM_TYPES_H
>  #define _ASM_TYPES_H
>  
> -#include 
...
> -#define __UINTPTR_TYPE__   unsigned long
> -#endif
> +#include 
>  
>  #endif /* _ASM_TYPES_H */
> 

Moving the file is correct as far as I can tell, but the extra
#include is not necessary here, as the kernel will automatically
search both arch/arm/include/ and arch/arm/include/uapi/.

The same applies to patches 2 and 4.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Arnd Bergmann]

On Tuesday, January 3, 2017 11:57:36 PM CET Paul Bolle wrote:
> On Tue, 2017-01-03 at 23:25 +0100, Arnd Bergmann wrote:
> > As far as I'm concerned, we are totally fine as long as there exists a
> > longterm supported kernel that has i4l in drivers/staging.
> 
> Or in drivers/isdn, right?

Right, I was assuming that we would first move it to staging and then
delete it, both at future points in time that we can debate. With the
existing longterm kernels that have i4l in drivers/isdn, the few remaining
users still have access to a supported kernel release until at least
2020.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Arnd Bergmann]

On Tuesday, January 3, 2017 10:54:19 PM CET Paul Bolle wrote:
> On Tue, 2017-01-03 at 22:19 +0100, Arnd Bergmann wrote:
> > isdn: move isdnhdlc out of i4l
> > isdn: i4l: move hisax driver to staging
> > isdn: move i4l to staging
> > 
> > I can post those as well, at least I think the first two are helpful
> > for untangling i4l from the rest of ISDN.  I also still think that
> > moving hisax and i4l to staging is reasonable given the state of
> > that code, even if there are a couple of users today.
> 
> There are? And even if there are: is there any reason to expect that moving
> the rest of i4l to staging will result in anything other than a stream of
> checkpatch cleanups?

To clarify: Karsten's concern was about the loss of features that are
present in i4l but not in mISDN. There were active users of those features
last year, so I assumed that there are still a few this year. However,
whether any of those users would ever need to move to a 4.11 kernel or
newer is an entirely different question.

As far as I'm concerned, we are totally fine as long as there exists a
longterm supported kernel that has i4l in drivers/staging. If we move
i4l to staging for v4.11 with the intention of removing it after the
2018 longterm release (i.e. after Deutsche Telekom turns off their
ISDN network), that gives us at least until 2020. I assume there will
be at least one older kernel with a longer end-of-support date.

> How often did a bunch of drivers re-enter the tree after being sent to
> staging?

Greg can probably answer that. I'm sure it's either never or very rare.
The only case of removed code coming back later is arch/h8300, which
was removed in 2013 and replaced with a much nicer implementation
in 2015.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Arnd Bergmann]

On Tuesday, January 3, 2017 4:24:36 PM CET Greg Kroah-Hartman wrote:
> On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote:
> > The icn, act2000 and pcbit drivers are all for very old hardware,
> > and it is highly unlikely that anyone is actually still using them
> > on modern kernels, if at all.
> > 
> > All three drivers apparently are for hardware that predates PCI
> > being the common connector, as they are ISA-only and active
> > PCI ISDN cards were widely available in the 1990s.
> > 
> > Looking through the git logs, it I cannot find any indication of a
> > patch to any of these drivers that has been tested on real hardware,
> > only cleanups or global API changes.
> > 
> > Signed-off-by: Arnd Bergmann 
> > Acked-by: Karsten Keil 
> 
> This patch got added in the 4.6 kernel release.  As I am now taking
> patches for 4.11-rc1, I figure it is time to just delete the
> drivers/staging/i4l/ directory now, given that no one has really done
> anything with it.  If people show up that wish to maintain it, I'll be
> glad to revert it, or if someone really screams in the next week.
> Otherwise it's time to just move on 

Sounds good to me. My original series contained four more patches that
I did not post again after there was some concern[1] that we did not
come to a conclusion on:

isdn: gigaset: remove i4l code
isdn: move isdnhdlc out of i4l
isdn: i4l: move hisax driver to staging
isdn: move i4l to staging

I can post those as well, at least I think the first two are helpful
for untangling i4l from the rest of ISDN.  I also still think that
moving hisax and i4l to staging is reasonable given the state of
that code, even if there are a couple of users today.

Arnd

[1] https://lkml.org/lkml/2016/3/4/762
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

[Arnd Bergmann]

On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > On Mon, Dec 05, 2016 at 04:34:23PM +, Catalin Marinas wrote:
> > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > detection of the task type.
> > > 
> > > What's wrong with the run-time detection? If it's just to avoid a
> > > negligible overhead, I would rather keep the code simpler by avoiding
> > > duplicating the generic compat_sys_ptrace().
> > 
> > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
> 
> Hmm, I completely forgot about this ;). There is still an advantage to
> doing run-time checking if we avoid touching core code (less acks to
> gather and less code duplication).
> 
> Let's see what Arnd says but the initial patch looked simpler.

I don't currently have either version of the patch in my inbox
(the archive is on a different machine), but in general I'd still
think it's best to avoid the runtime check for aarch64-ilp32
altogether. I'd have to look at the overall kernel source to
see if it's worth avoiding one or two instances though, or
if there are an overwhelming number of other checks that we
can't avoid at all.

Regarding ptrace, I notice that arch/tile doesn't even use
the compat entry point for its ilp32 user space on 64-bit
kernels, it just calls the regular 64-bit one. Would that
help here?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Ksummit-discuss] Including images on Sphinx documents

[Arnd Bergmann]

On Wednesday, November 16, 2016 6:26:33 PM CET Mauro Carvalho Chehab wrote:
> Em Wed, 16 Nov 2016 17:03:47 +0100
> Arnd Bergmann  escreveu:
> 
> > On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> > > It basically calls ImageMagick "convert" tool for all png and
> > > pdf files currently at the documentation (they're all at media,
> > > ATM).  
> > 
> > It looks like we still need to find a way to address the .gif files
> > though, as they have the same problem as the .pdf files.
> 
> Actually, my last patch series removed all *.pdf images and converted
> all .gif files under Documentation/media to PNG[1]. I also replaced some
> images by .svg, but the remaining ones are more complex. I'm even not
> sure if it makes sense to convert a few of them to vectorial graphics,
> like on this case:
>   https://mchehab.fedorapeople.org/kernel_docs/media/_images/selection.png
> 
> >
> > During the kernel summit, I looked around for any binary files in
> > the kernel source tree, and except for the penguin logo, they are
> > all in Documentation/media/uapi/v4l/, but they are not all pdf
> > files, but also .png and .pdf.
> 
> From what I understood from Linus, his problem is to carry on a
> non-editable file at the Kernel tree. With that sense, a PNG file
> is OK, as it is editable.

[adding Linus for clarification]

I understood the concern as being about binary files that you cannot
modify with classic 'patch', which is a separate issue.

> I had, in the past, problems with binary contents on either Mercurial
> or git (before migrating to git, we used Mercurial for a while).
> So, before Kernel 4.8, those .pdf, .png (and .gif) images were uuencoded,
> in order to avoid troubles handling patches with them.
> 
> Nowadays, I don't see any issue handling binary images via e-mail or via git.



> Btw, with that regards, SVG images are a lot worse to handle, as a single
> line can easily have more than 998 characters, with makes some email
> servers to reject patches with them. So, at the version 3 of my patch 
> series, I had to use inkscape to ungroup some images, and to rewrite their
> files, as otherwise, two patches were silently rejected by the VGER 
> server.

Ok, good to know.

> [1] The reason to convert to PNG is that it means one less format to be
> concerned with. Also, it doesn't make much sense to use two different
> formats for bitmap images at the documentation.

I just tried converting all the .gif and .png files to .pnm. This would
make the files patchable but also add around 25MB to the uncompressed
kernel source tree (118kb compressed, compared to 113kb for the .gif and
.png files). This is certainly worse than the uuencoded files you
had before

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Ksummit-discuss] Including images on Sphinx documents

[Arnd Bergmann]

On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> > [...]
> > > And it may even require "--shell-escape" to be passed at the xelatex
> > > call if inkscape is not in the path, with seems to be a strong
> > > indication that SVG support is not native to texlive, but, instead,
> > > just a way to make LaTeX to call inkscape to do the image conversion.  
> > 
> > Please don't require --shell-escape as part of the TeX workflow.  If
> > LaTeX can't handle the desired image format natively, it needs
> > conversion in advance.
> 
> Agreed. I sent a patch series to linux-doc, doing the conversion in
> advance:
> https://marc.info/?l=linux-doc&m=147859902804144&w=2
> 
> Not sure why, but the archives don't have all patches yet.
> Anyway, the relevant one is this:
> 
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=pdf-fixes&id=5d41c452c787f6a6c755a3855312435bc439acb8
> 
> It basically calls ImageMagick "convert" tool for all png and
> pdf files currently at the documentation (they're all at media,
> ATM).

It looks like we still need to find a way to address the .gif files
though, as they have the same problem as the .pdf files.

During the kernel summit, I looked around for any binary files in
the kernel source tree, and except for the penguin logo, they are
all in Documentation/media/uapi/v4l/, but they are not all pdf
files, but also .png and .pdf.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/18] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

[Arnd Bergmann]

On Monday, October 24, 2016 12:30:47 PM CEST Chris Metcalf wrote:
> On 10/21/2016 4:33 PM, Yury Norov wrote:
> > All new 32-bit architectures should have 64-bit off_t type, but existing
> > architectures has 32-bit ones.
> >
> > [...]
> > For syscalls sys_openat() and sys_open_by_handle_at() force_o_largefile()
> > is called, to set O_LARGEFILE flag, and this is the only difference
> > comparing to compat versions. All compat ABIs are already turned to use
> > 64-bit off_t, except tile. So, compat versions for this syscalls are not
> > needed anymore. Tile is handled explicitly.
> >
> > [...]
> > --- a/arch/tile/kernel/compat.c
> > +++ b/arch/tile/kernel/compat.c
> > @@ -103,6 +103,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, 
> > unsigned int, offset_high,
> >   #define compat_sys_readahead sys32_readahead
> >   #define sys_llseek compat_sys_llseek
> >   
> > +#define sys_openat compat_sys_openat
> > +#define sys_open_by_handle_at  compat_sys_open_by_handle_at
> > +
> >   /* Call the assembly trampolines where necessary. */
> >   #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> >   #define sys_clone _sys_clone
> 
> This patch accomplishes two goals that could be completely separated.
> It's confusing to have them mixed in the same patch without any
> discussion of why they are in the same patch.
> 
> First, you want to modify the default  behavior for
> compat syscalls so that the default is sys_openat (etc) rather than
> the existing compat_sys_openat, and then use that new behavior for
> arm64 ILP32.  This lets you force O_LARGEFILE for arm64 ILP32 to
> support having a 64-bit off_t at all times.  To do that, you fix the
> asm-generic header, and then make tile have a special override.
> This seems reasonable enough.
> 
> Second, you introduce ARCH_32BIT_OFF_T basically as a synonym for
> "BITS_PER_WORD == 32", so that new 32-bit architectures can choose not
> to enable it.  This is fine in the abstract, but I'm a bit troubled by
> the fact that you are not actually introducing a new 32-bit
> architecture here (just a new 32-bit mode for the arm 64-bit kernel).
> Shouldn't this part of the change wait until someone actually has a
> new 32-bit kernel to drive this forward?

I asked for this specifically because we identified the problem
during the review of the aarch64 ilp32 code, and it might not
be noticed in the next architecture submission.

The most important aspect from my perspective is that the new
ilp32 ABI on aarch64 behaves the same way that any native 32-bit
architecture does, and when we change the default, it should
be done for both compat mode and native mode at the same time.

> If you want to push forward the ARCH_32BIT_OFF_T change in the absence
> of an architecture that supports it, I would think it would be a lot
> less confusing to have these two in separate patches, and make it
> clear that the ARCH_32BIT_OFF_T change is just laying groundwork
> for some hypothetical future architecture.
> 
> The existing commit language itself is also confusing. You write "All
> compat ABIs are already turned to use 64-bit off_t, except tile."
> First, I'm not sure what you mean by "turned" here.  And, tile is just
> one of many compat ABIs that allow O_LARGEFILE not to be part of the
> open call: see arm64's AArch32 ABI, MIPS o32, s390 31-bit emulation,
> sparc64's 32-bit mode, and of course x86's 32-bit compat mode.
> Presumably your point here is that tile is the only pre-existing
> architecture that #includes  to create its compat
> syscall table, and so I think "all except tile" here is particularly
> confusing, since there are no architectures except tile that use the
> __SYSCALL_COMPAT functionality in the current tree.

Agreed, this could be made clearer, and splitting the patch up
in two also seems reasonable, though I didn't see it as important.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent

[Arnd Bergmann]

On Friday, October 21, 2016 3:09:16 PM CEST Jonathan Corbet wrote:
> On Mon, 17 Oct 2016 16:26:23 +0100
> Punit Agrawal  wrote:
> 
> > The dma mapping api howto gives the impression that using the
> > dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
> > to check all the components in the path from the device to memory for
> > addressing restrictions. In systems with address translations between
> > the device and memory (e.g., when using IOMMU), this implies that a
> > successful call to set set dma mask has checked the addressing
> > constraints of the intermediaries as well.
> > 
> > For the IOMMU drivers in the tree, the check is actually performed while
> > allocating the DMA buffer rather than when the DMA mask is
> > configured. For MMUs that do not support the full device addressing
> > capability, the allocations are made from a reduced address space.
> > 
> > Update the documentation to clarify that even though the call to
> > dma_set_mask_and_coherent succeeds, it may not be possible to use the
> > full addressing capability of the device.
> 
> OK, so I guess I can buy this.  But...
> 
> > Signed-off-by: Punit Agrawal 
> > Cc: Jonathan Corbet 
> > ---
> >  Documentation/DMA-API-HOWTO.txt | 39 
> > +++
> >  1 file changed, 23 insertions(+), 16 deletions(-)
> > 
> > diff --git a/Documentation/DMA-API-HOWTO.txt 
> > b/Documentation/DMA-API-HOWTO.txt
> > index 979228b..240d1ee 100644
> > --- a/Documentation/DMA-API-HOWTO.txt
> > +++ b/Documentation/DMA-API-HOWTO.txt
> > @@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions. 
> >  And at least
> >  one platform (SGI SN2) requires 64-bit consistent allocations to
> >  operate correctly when the IO bus is in PCI-X mode.
> >  
> > -For correct operation, you must interrogate the kernel in your device
> > -probe routine to see if the DMA controller on the machine can properly
> > -support the DMA addressing limitation your device has.  It is good
> > +For correct operation, you must inform the kernel in your device probe
> > +routine to see if the DMA controller on the machine can properly
> > +support the DMA addressing capabilities your device has.  It is good
> 
> Here it's still saying "to see if the DMA controller on the machine can
> properly support the DMA addressing capabilities your device has".  So
> you've not really changed the sense of this sentence here.
> 
> If I understand things correctly, the calls in question are storing the
> device's limitations; they will only fail if the kernel is entirely
> unable to work within the indicated range, right?  I don't think there's
> ever been any guarantee that the system as a whole could use the entire
> range that is addressable by the device.  I have no objection to making
> that more clear, but let's actually make it more clear by saying what the
> functions are actually doing.
> 
> Make sense, or am I missing something here?

The call is a two-way interface, and the existing text tries to convey
that already: The device tells the kernel whether it is limited (< 32
bit mask) or if it can support extended addresses (> 32 bit mask),
or just handles the default 32bit mask, and the kernel should come
back saying whether that mask allows a correct operation of the device
on the given platform, as well as set it up correctly that way.

What exactly happens in dma_set_mask() and the related interfaces
is highly platform specific, including:

- if the mask is smaller than the smallest memory zone and the
  swiotlb bounce buffers (if any) don't fit inside it, it has to
  fail

- if the device claims to support larger mask, but the bus it
  connects to does not (e.g. a 32-bit PCI host), it may
  also fail (or succeed if there is no RAM outside of the
  intersection of the two masks)

- if the mask is large enough to cover all RAM, we can bypass
  the IOMMU and use a direct mapping

- if swiotlb is enabled or an IOMMU is present, any mask that
  includes the bounce buffer area (or the virtual address space
  of the IOMMU) should succeed.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 00/11] pci: support for configurable PCI endpoint

[Arnd Bergmann]

On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
> > On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I 
> > wrote:
> > I've added the drivers/ntb maintainers to Cc, given that there is
> > a certain degree of overlap between your work and the existing
> > code, I think they should be part of the discussion.
> >  
> >> Known Limitation:
> >>*) Does not support multi-function devices
> > 
> > If I understand it right, this was a problem for USB and adding
> > it later made it somewhat inconsistent. Maybe we can at least
> > try to come up with an idea of how multi-function devices
> > could be handled even if we don't implement it until someone
> > actually needs it.
> 
> Actually IMO multi-function device in PCI should be much simpler than it is 
> for
> USB. In the case of USB, all the functions in a multi-function device will
> share the same *usb configuration* . (USB device can have multiple
> configuration but only one can be enabled at a time). A multi-function USB
> device will still have a single vendor-id/product-id/class... So I think a
> separate library (composite.c) in USB makes sense.

Ok, makes sense.

> But in the case of PCI, every function can be treated independently since all
> the functions have it's own 4KB configuration space. Each function can be
> configured independently. Each can have it's own vendor-id/product-id/class..
> I'm not sure if we'll need a separate library for PCI like we have for USB.

I think it depends on whether we want to add the software multi-function
support you mention.

> Now the restriction for not allowing multi-function device is because of the
> following structure definition.
> 
> struct pci_epc {
>   ..
> struct pci_epf *epf;
>   ..
> };
> 
> EPC has a single reference to EPF and it is used *only* to notify the function
> driver when the link is up. (If this can be changed to use notification
> mechanism, multi-function devices can be supported here)
> 
> One more place where this restriction arises is in designware driver
> 
> struct dw_pcie_ep {
>   ..
> u8 bar_to_atu[6];
>   ..
> };
> 
> We use single ATU window to configure a BAR (in BAR). If there are multiple
> functions, then this should also be modified since each function has 6 BARs.
> 
> This can be fixed without much effort unless some other issue props up.

Ok.

> > 
> > Is your hardware able to make the PCIe endpoint look like
> > a device with multiple PCI functions, or would one have to
> > do this in software inside of a single PCI function if we
> > ever need it?
> 
> The hardware I have doesn't support multiple PCI functions (like having a
> separate configuration space for each function). It has a dedicated space for
> configuration space supporting only one function. [Section 24.9.7.3.2
> PCIe_SS_EP_CFG_DBICS Register Description in  [1]].
> 
> yeah, it has to be done in software (but that won't be multi-function device 
> in
> PCI terms).
> 
> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf

Ok, so in theory there can be other hardware (and quite likely is)
that supports multiple functions, and we can extend the framework
to support them without major obstacles, but your hardware doesn't,
so you kept it simple with one hardcoded function, right?

Seems completely reasonable to me.

> >> TODO:
> >>*) access buffers in RC
> >>*) raise MSI interrupts
> >>*) Enable user space control for the RC side PCI driver
> > 
> > The user space control would end up just being one of several
> > gadget drivers, right? E.g. gadget drivers for standard hardware
> > (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
> > drivers while a user space driver can be used for things that
> > are more unusual and that don't need to interface to another
> > part of the kernel?
> 
> Actually I didn't mean that. It was more with respect to the host side PCI 
> test
> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
> itself. I wanted to change this so that the user controls which tests to run.
> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
> to perform various PCI tests.

Ok, I see. So what I described above would be yet another function
driver that can be implemented, but so far, you have not planned
to do that because there was not need, right?

> > 
> >>   

Re: [RFC PATCH 00/11] pci: support for configurable PCI endpoint

[Arnd Bergmann]

On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I wrote:
> This patch series
>   *) adds PCI endpoint core layer
>   *) modifies designware/dra7xx driver to be configured in EP mode
>   *) adds a PCI endpoint *test* function driver

Hi Kishon,

I think this is a great start, thanks for posting early with a clear
list of limitations and TODO items.

I've added the drivers/ntb maintainers to Cc, given that there is
a certain degree of overlap between your work and the existing
code, I think they should be part of the discussion.
 
> Known Limitation:
>   *) Does not support multi-function devices

If I understand it right, this was a problem for USB and adding
it later made it somewhat inconsistent. Maybe we can at least
try to come up with an idea of how multi-function devices
could be handled even if we don't implement it until someone
actually needs it.

Is your hardware able to make the PCIe endpoint look like
a device with multiple PCI functions, or would one have to
do this in software inside of a single PCI function if we
ever need it?

> TODO:
>   *) access buffers in RC
>   *) raise MSI interrupts
>   *) Enable user space control for the RC side PCI driver

The user space control would end up just being one of several
gadget drivers, right? E.g. gadget drivers for standard hardware
(8250 uart, ATA, NVMe, some ethernet) could be done as kernel
drivers while a user space driver can be used for things that
are more unusual and that don't need to interface to another
part of the kernel?

>   *) Adapt all other users of designware to use the new design (only
>  dra7xx has been adapted)

I don't fully understand this part. Does every designware based
driver need modifications, or are the changes to the
generic parts of the designware driver enough to make it
work for the simpler platforms?

> HOW TO:
> 
> ON THE EP SIDE:
> ***
> 
> /* EP function is configured using configfs */
> # mount -t configfs none /sys/kernel/config
> 
> /* PCI EP core layer creates "pci_ep" entry in configfs */
> # cd /sys/kernel/config/pci_ep/
> 
> /*
>  * This is the 1st step in creating an endpoint function. This
>  * creates the endpoint function device *instance*. The string
>  * before the . suffix will identify the driver this
>  * EP function will bind to.
>  * Just pci_epf_test is also valid. The . suffix is used
>  * if there are multiple PCI controllers and all of them wants
>  * to use the same function.
>  */
> # mkdir pci_epf_test.0

I haven't used USB gadgets, but I assume this is modeled around
the same interface. If there are notable differences, please mention
what they are. Otherwise the general concept seems rather nice to me.

>  drivers/pci/{host => controller}/Kconfig   |  109 +-
>  drivers/pci/{host => controller}/Makefile  |2 +
>  drivers/pci/{host => controller}/pci-aardvark.c|0
>  drivers/pci/{host => controller}/pci-dra7xx.c  |  340 +
>  drivers/pci/{host => controller}/pci-exynos.c  |0
>  drivers/pci/{host => controller}/pci-host-common.c |0
>  .../pci/{host => controller}/pci-host-generic.c|0
>  drivers/pci/{host => controller}/pci-hyperv.c  |0
>  drivers/pci/{host => controller}/pci-imx6.c|0
>  drivers/pci/{host => controller}/pci-keystone-dw.c |0
>  drivers/pci/{host => controller}/pci-keystone.c|0
>  drivers/pci/{host => controller}/pci-keystone.h|0

Maybe it's better to wait before moving it around, this will make
it harder for you to rebase the patch series while you are working on
it and other people are working on the existing code.

I'd suggest dropping the rename patches for the moment and just work
in drivers/pci/host.

Let's talk (high-level) about the DT binding. I see that the way
you have done it here, one will need to have a different .dtb file
for a machine depending on whether the PCIe is used in host or
endpoint mode. The advantage of this way is that it's a much
cleaner binding (PCIe host bindings are a mess, and adding more
options to it will only make it worse), the downside is that
you can't decide at runtime what you want to use it for. E.g.
connecting two identical machines over PCIe requires deciding
in the bootloader which one is the endpoint, or using DT
overlays, which may be awkward for some users. Is this a realistic
use case, or do you expect that all machines will only ever be
used in one of the two ways?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

On Friday, September 9, 2016 1:43:17 PM CEST Hoan Tran wrote:
> 
> > * Are you sure you don't need any smp_rmb()/smp_wmb() barriers
> > between the accesses?
> 
> No, we don't need a strict read/write during access PCC subspace. Just
> make sure all access is committed before PCC send message to the
> platform which done by PCC mailbox driver.
> 

Ok, got it. The PCC mailbox driver presumably uses writel() to
send the message, and that implies the necessary barrier
(unlike writel_relaxed), right?

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

The newly added hwmon driver fails to build in an allmodconfig
kernel:

  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!

According to comments in the code, the mailbox is a shared memory region,
not a set of MMIO registers, so we should use memremap() for mapping it
instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
of readl/writel.

The driver already uses plain kernel pointers, so it's a bit unusual
to work with functions that operate on __iomem pointers, and this
fixes that part too.

I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
regarding the ordering of the accesses from the CPU, but note that
there are no barriers (also unchanged from before).

I'm also keeping the endianess behavior, though I'm unsure whether
the message data was supposed to be in LE32 format in the first
place, it's possible this was meant to be interpreted as a byte
stream instead.

Signed-off-by: Arnd Bergmann 
---
v2: use write-back mapping instead of write-thru,
minor coding style changes

diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
index bc78a5d10182..e5470bd49067 100644
--- a/drivers/hwmon/xgene-hwmon.c
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+
 #include 
 
 /* SLIMpro message defines */
@@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 {
u16 ret, val;
 
-   val = readw_relaxed(addr);
+   val = le16_to_cpu(READ_ONCE(*addr));
ret = val & mask;
val &= ~mask;
-   writew_relaxed(val, addr);
+   WRITE_ONCE(*addr, cpu_to_le16(val));
 
return ret;
 }
@@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
 {
struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
-   void *ptr = generic_comm_base + 1;
+   u32 *ptr = (void *)(generic_comm_base + 1);
int rc, i;
u16 val;
 
@@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
*ctx, u32 *msg)
ctx->resp_pending = true;
 
/* Write signature for subspace */
-   writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
-  &generic_comm_base->signature);
+   WRITE_ONCE(generic_comm_base->signature,
+  cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
 
/* Write to the shared command region */
-   writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
-  &generic_comm_base->command);
+   WRITE_ONCE(generic_comm_base->command,
+  cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
 
/* Flip CMD COMPLETE bit */
-   val = readw_relaxed(&generic_comm_base->status);
+   val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
val &= ~PCCS_CMD_COMPLETE;
-   writew_relaxed(val, &generic_comm_base->status);
+   WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
 
/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
-   writel_relaxed(msg[i], ptr + i * 4);
+   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
 
/* Ring the doorbell */
rc = mbox_send_message(ctx->mbox_chan, msg);
@@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
 */
ctx->comm_base_addr = cppc_ss->base_address;
if (ctx->comm_base_addr) {
-   ctx->pcc_comm_addr =
-   acpi_os_ioremap(ctx->comm_base_addr,
-   cppc_ss->length);
+   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
+   cppc_ss->length,
+   MEMREMAP_WB);
} else {
dev_err(&pdev->dev, "Failed to get PCC comm region\n");
rc = -ENODEV;

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

On Friday, September 9, 2016 12:24:32 PM CEST Hoan Tran wrote:
> On Fri, Sep 9, 2016 at 8:38 AM, Arnd Bergmann  wrote:
> > The newly added hwmon driver fails to build in an allmodconfig
> > index bc78a5d10182..e834dfb3acca 100644
> > --- a/drivers/hwmon/xgene-hwmon.c
> > +++ b/drivers/hwmon/xgene-hwmon.c
> > @@ -34,7 +34,8 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> 
> Alphabetical order.
> 
> > struct acpi_pcct_shared_memory *generic_comm_base = 
> > ctx->pcc_comm_addr;
> > -   void *ptr = generic_comm_base + 1;
> > +   u32 *ptr = (void*)(generic_comm_base + 1);
> 
> Space before "*".

Ok.

> > @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device 
> > *pdev)
> >  */
> > ctx->comm_base_addr = cppc_ss->base_address;
> > if (ctx->comm_base_addr) {
> > -   ctx->pcc_comm_addr =
> > -   acpi_os_ioremap(ctx->comm_base_addr,
> > -   cppc_ss->length);
> > +   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
> > +   cppc_ss->length,
> > +   MEMREMAP_WT);
> 
> It should be MEMREMAP_WB. As mailbox shared memory is on RAM and our
> co-processor is also in the coherency domain.

Right, I was wondering about this, since I could not figure out what
the other side is (hardware, service processor or firmware).
So MEMREMAP_WB makes sense here.

Two more questions:

* Any comment on the byte ordering of the data in this line:

/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
-   writel_relaxed(msg[i], ptr + i * 4);
+   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));

This assumes that the old code was correct even when running on
big-endian kernels and the message data consists of 32-bit data words.
If the message has some other format instead, we would need to treat
this as a byte stream and not do swapping here but instead do it
(if any) in the code that reads or writes the actual data here.

* Are you sure you don't need any smp_rmb()/smp_wmb() barriers
between the accesses?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> > On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > > +   ctx->comm_base_addr = cppc_ss->base_address;
> > > +   if (ctx->comm_base_addr) {
> > > +   ctx->pcc_comm_addr =
> > > +   
> > > acpi_os_ioremap(ctx->comm_base_addr,
> > > +   cppc_ss->length);
> > > 
> > 
> > This causes the arm64 allmodconfig build to fail now, according to
> > kernelci:
> > 
> >   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> > undefined!
> > 
> > Should this perhaps call ioremap() or memremap() instead?
> > 
> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 ("arm64:
> mark reserved memblock regions explicitly in iomem") starts using a function
> in acpi_os_ioremap() which is not exported. On top of that, 
> memblock_is_memory()
> is declared as __init_memblock, which makes me really uncomfortable.
> If acpi_os_ioremap() must not be used by modules, and possibly only during
> early (?) initialization, maybe its declaration should state those 
> limitations ?

I think there is more wrong with it, the driver also accesses a shared
memory area with kernel pointers using readl_relaxed/writel_relaxed,
which are only valid on MMIO registers.

I've prepared a patch, please have a look at the follow-up email.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

The newly added hwmon driver fails to build in an allmodconfig
kernel:

  1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!

According to comments in the code, the mailbox is a shared memory region,
not a set of MMIO registers, so we should use memremap() for mapping it
instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
of readl/writel.

The driver already uses plain kernel pointers, so it's a bit unusual
to work with functions that operate on __iomem pointers, and this
fixes that part too.

I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
regarding the ordering of the accesses from the CPU, but note that
there are no barriers (also unchanged from before).

I'm also keeping the endianess behavior, though I'm unsure whether
the message data was supposed to be in LE32 format in the first
place, it's possible this was meant to be interpreted as a byte
stream instead.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
index bc78a5d10182..e834dfb3acca 100644
--- a/drivers/hwmon/xgene-hwmon.c
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -34,7 +34,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+
 #include 
 
 /* SLIMpro message defines */
@@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 {
u16 ret, val;
 
-   val = readw_relaxed(addr);
+   val = le16_to_cpu(READ_ONCE(*addr));
ret = val & mask;
val &= ~mask;
-   writew_relaxed(val, addr);
+   WRITE_ONCE(*addr, cpu_to_le16(val));
 
return ret;
 }
@@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
 {
struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
-   void *ptr = generic_comm_base + 1;
+   u32 *ptr = (void*)(generic_comm_base + 1);
int rc, i;
u16 val;
 
@@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
*ctx, u32 *msg)
ctx->resp_pending = true;
 
/* Write signature for subspace */
-   writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
-  &generic_comm_base->signature);
+   WRITE_ONCE(generic_comm_base->signature,
+  cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
 
/* Write to the shared command region */
-   writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
-  &generic_comm_base->command);
+   WRITE_ONCE(generic_comm_base->command,
+  cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
 
/* Flip CMD COMPLETE bit */
-   val = readw_relaxed(&generic_comm_base->status);
+   val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
val &= ~PCCS_CMD_COMPLETE;
-   writew_relaxed(val, &generic_comm_base->status);
+   WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
 
/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
-   writel_relaxed(msg[i], ptr + i * 4);
+   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
 
/* Ring the doorbell */
rc = mbox_send_message(ctx->mbox_chan, msg);
@@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
 */
ctx->comm_base_addr = cppc_ss->base_address;
if (ctx->comm_base_addr) {
-   ctx->pcc_comm_addr =
-   acpi_os_ioremap(ctx->comm_base_addr,
-   cppc_ss->length);
+   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
+   cppc_ss->length,
+   MEMREMAP_WT);
} else {
dev_err(&pdev->dev, "Failed to get PCC comm region\n");
rc = -ENODEV;

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Thursday, September 8, 2016 7:55:44 AM CEST Guenter Roeck wrote:
> Maybe, but now I get
> 
> Building arm:allmodconfig ... failed
> --
> Error log:
> crypto/crypto_engine.c: In function 'crypto_transfer_hash_request':
> crypto/crypto_engine.c:234:3: error: implicit declaration of function 
> 'queue_kthread_work'
> 
> Building arm64:allmodconfig ... failed
> --
> Error log:
> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c: In function 
> ‘kvm_timer_hyp_init’:
> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:457:1: warning: label 
> ‘out_free’ defined but not used

Right, I sent fixes for both. I think we had a clean build yesterday,
probably tomorrow those will both be fixed.

The time between -rc5 and -rc7 seems to be the worst for build testing ;-)

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Wednesday, September 7, 2016 3:27:54 PM CEST Guenter Roeck wrote:
> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> > On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > > +   ctx->comm_base_addr = cppc_ss->base_address;
> > > +   if (ctx->comm_base_addr) {
> > > +   ctx->pcc_comm_addr =
> > > +   
> > > acpi_os_ioremap(ctx->comm_base_addr,
> > > +   cppc_ss->length);
> > > 
> > 
> > This causes the arm64 allmodconfig build to fail now, according to
> > kernelci:
> > 
> >   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> > undefined!
> > 
> How do you even get there ? arm64:allmodconfig fails for me in -next with
> 
> drivers/pwm/pwm-berlin.c: In function ‘berlin_pwm_suspend’:
> drivers/pwm/pwm-berlin.c:245:35: error: ‘struct berlin_pwm_chip’ has no 
> member named ‘chips’

That was fixed in yesterday's linux-next.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> > On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > > +   ctx->comm_base_addr = cppc_ss->base_address;
> > > +   if (ctx->comm_base_addr) {
> > > +   ctx->pcc_comm_addr =
> > > +   
> > > acpi_os_ioremap(ctx->comm_base_addr,
> > > +   cppc_ss->length);
> > > 
> > 
> > This causes the arm64 allmodconfig build to fail now, according to
> > kernelci:
> > 
> >   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> > undefined!
> > 
> > Should this perhaps call ioremap() or memremap() instead?
> > 
> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 ("arm64:
> mark reserved memblock regions explicitly in iomem") starts using a function
> in acpi_os_ioremap() which is not exported. On top of that, 
> memblock_is_memory()
> is declared as __init_memblock, which makes me really uncomfortable.
> If acpi_os_ioremap() must not be used by modules, and possibly only during
> early (?) initialization, maybe its declaration should state those 
> limitations ?

Ah, I didn't notice that. I guess both patches were correct individually and
got added to linux-next around the same time but caused allmodconfig to blow up
when used together.

Adding everyone who was involved in the memblock patch to Cc here, maybe one
of them has an idea what the correct fix is. There are only two other drivers
using acpi_os_ioremap() and one of them is x86-specific, so it's still likely
that drivers are not actually supposed to use this symbol. Making
acpi_os_ioremap() an exported function in arm64 would also work.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> +   ctx->comm_base_addr = cppc_ss->base_address;
> +   if (ctx->comm_base_addr) {
> +   ctx->pcc_comm_addr =
> +   acpi_os_ioremap(ctx->comm_base_addr,
> +   cppc_ss->length);
> 

This causes the arm64 allmodconfig build to fail now, according to
kernelci:

  1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!

Should this perhaps call ioremap() or memremap() instead?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: ioctl: Add some clarifications to botching-up-ioctls

[Arnd Bergmann]

On Friday, September 2, 2016 3:42:24 PM CEST Laura Abbott wrote:
> - The guide currently says to pad the structure to a multiple of
>   64-bits. This is not necessary in cases where the structure contains
>   no 64-bit types. Clarify this concept to avoid unnecessary padding.
> - When using __u64 to hold user pointers, blindly trying to do a cast to
>   a void __user * may generate a warning on 32-bit systems about a cast
>   from an integer to a pointer of different size. There is a macro to
>   deal with this which hides an ugly double cast. Add a reference to
>   this macro.
> 
> Signed-off-by: Laura Abbott 
> 

Looks good to me,

Acked-by: Arnd Bergmann 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/18] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Arnd Bergmann]

On Friday, September 2, 2016 6:46:19 PM CEST Bamvor Jian Zhang wrote:
> diff --git a/arch/arm64/include/uapi/asm/unistd.h 
> b/arch/arm64/include/uapi/asm/unistd.h
> index 043d17a..78bea1d 100644
> --- a/arch/arm64/include/uapi/asm/unistd.h
> +++ b/arch/arm64/include/uapi/asm/unistd.h
> @@ -16,4 +16,9 @@
> 
>  #define __ARCH_WANT_RENAMEAT
> 
> +/* We need to make sure it works for both userspace and kernel(sys_ilp32.c) 
> */
> +#if defined(__ILP32__) || defined(__SYSCALL_COMPAT)
> +#define __ARCH_WANT_SYNC_FILE_RANGE2
> +#endif
> +
>  #include 
> diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
> index 10fc0ca..13c9c9d 100644
> --- a/arch/arm64/kernel/sys_ilp32.c
> +++ b/arch/arm64/kernel/sys_ilp32.c
> @@ -42,7 +42,7 @@
>  #define compat_sys_pwrite64compat_sys_pwrite64_wrapper
>  #define compat_sys_readahead   compat_sys_readahead_wrapper
>  #define compat_sys_shmat   sys_shmat
> -#define compat_sys_sync_file_range compat_sys_sync_file_range2_wrapper
> +#define compat_sys_sync_file_range2compat_sys_sync_file_range2_wrapper
>  #define compat_sys_truncate64  compat_sys_truncate64_wrapper
>  #define sys_mmap2  compat_sys_mmap2_wrapper
>  #define sys_ptrace compat_sys_ptrace
> 

Looks good to me.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/19] compat ABI: use non-compat openat and open_by_handle_at variants

[Arnd Bergmann]

On Monday, August 15, 2016 5:30:28 PM CEST Yury Norov wrote:
> On Mon, Jun 27, 2016 at 09:47:38AM +0200, Andreas Schwab wrote:
> > Yury Norov  writes:
> > 
> > > The only difference is that non-compat version forces O_LARGEFILE,
> > > and it should be the default behaviour for all architectures, as
> > > we don't support 32-bit off_t. The only exception is tile32, that
> > > continues with compat version of syscalls.
> > >
> > > Signed-off-by: Yury Norov 
> > > Acked-by: Arnd Bergmann 
> > > Acked-by: Chris Metcalf  [for tile]
> > > ---
> > >  arch/tile/kernel/compat.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
> > > index 4912084..489ae19 100644
> > > --- a/arch/tile/kernel/compat.c
> > > +++ b/arch/tile/kernel/compat.c
> > > @@ -94,6 +94,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, 
> > > unsigned int, offset_high,
> > >  #define compat_sys_readahead sys32_readahead
> > >  #define sys_llseek compat_sys_llseek
> > >  
> > > +#define sys_openat   compat_sys_openat
> > > +#define sys_open_by_handle_atcompat_sys_open_by_handle_at
> > > +
> > >  /* Call the assembly trampolines where necessary. */
> > >  #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> > >  #define sys_clone _sys_clone
> > 
> > This is a no-op.  Did you mean to add this?  Without that the testsuite
> > of tar fails on ILP32.
> 
> The change you suggest below is what I originally sent at the end of
> December, but that chunk was lost after one of numerous rebases probably.
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1512.3/00510.html
> 
> IIRC, the only difference between this couple of syscalls and their
> compat versions is that non-compat syscalls set O_LARGEFILE depending
> on (BITS_PER_LONG != 32). Next patch of this series introduces
> ARCH_32BIT_OFF_T config option to force O_LARGEFILE for 64-bit arches,
> and all new 32-bit arches, as ARCH_32BIT_OFF_T is enabled for existing
> 32-bit arches explicitly.
> 
> O_LARGEFILE is controlled like this:
> -#define force_o_largefile() (BITS_PER_LONG != 32)
> +#define force_o_largefile() (!IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))
> 
> So if I restore original patch, everything will work. But my question
> is: if ARCH_32BIT_OFF_T disables O_LARGEFILE for tile32 anyway, what
> for we redirect native syscall handlers to compat ones? They are
> looking identical...

I've lost context here, but let me try to recall what we had
discussed in the past:

- native 32-bit architectures are handled using CONFIG_ARCH_32BIT_OFF_T
- native 64-bit architectures keep setting the flag.
- compat 32-bit architectures need special cases, but the only one
  that exists is tile, which has to keep not setting O_LARGEFILE
  while new compat architectures (ilp32) should set it.
 
> If my understanding is correct, we can drop the change in
> arch/tile/kernel/compat.c and join this patch with next one in this
> series.
> 
> Chris, Arnd?

The change in arch/tile/kernel/compat.c can either come before the
below change, or in the same patch, but not later.

Arnd

> > diff --git a/include/uapi/asm-generic/unistd.h 
> > b/include/uapi/asm-generic/unistd.h
> > index a26415b..4dcc38d 100644
> > --- a/include/uapi/asm-generic/unistd.h
> > +++ b/include/uapi/asm-generic/unistd.h
> > @@ -178,7 +178,7 @@ __SYSCALL(__NR_fchownat, sys_fchownat)
> >  #define __NR_fchown 55
> >  __SYSCALL(__NR_fchown, sys_fchown)
> >  #define __NR_openat 56
> > -__SC_COMP(__NR_openat, sys_openat, compat_sys_openat)
> > +__SYSCALL(__NR_openat, sys_openat)
> >  #define __NR_close 57
> >  __SYSCALL(__NR_close, sys_close)
> >  #define __NR_vhangup 58
> > @@ -676,8 +676,7 @@ __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
> >  #define __NR_name_to_handle_at 264
> >  __SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at)
> >  #define __NR_open_by_handle_at 265
> > -__SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \
> > - compat_sys_open_by_handle_at)
> > +__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
> >  #define __NR_clock_adjtime 266
> >  __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime)
> >  #define __NR_syncfs 267
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

[Arnd Bergmann]

On Thursday, August 11, 2016 5:30:03 PM CEST Catalin Marinas wrote:

> > > > and you can have ARM binaries with
> > > > PER_LINUX (using the arm64 uname) just like you can have
> > > > arm64 binaries running with PER_LINUX32.
> > > 
> > > I was actually looking to enforce the 32-bit binaries to only see
> > > PER_LINUX32, though with a risk of breaking the ABI. OTOH, people are
> > > abusing this and write 32-bit apps relying on the 64-bit /proc/cpuinfo:
> > > 
> > > http://lkml.kernel.org/g/1464706504-25224-3-git-send-email-catalin.mari...@arm.com
> > > 
> > > (you were summoned on that discussion couple of times ;))
> > 
> > Hmm, I thought I saw the thread and didn't have any good idea for
> > the uname information, but didn't notice it was for /proc/cpuinfo.
> > 
> > What's wrong with always showing both the 32-bit and the 64-bit
> > hwcap strings here (minus the duplicates, which hopefully have
> > the same meaning here)?
> 
> As I said above, some of them have the same name (which may be a good
> thing at a first look) but we don't have an architecture guarantee that
> the feature is present in both AArch32 and AArch64 modes (e.g. AES may
> only be available in AArch64).

Is this the case on actual implementations that exist today? If they
are actually always both present, we might be able to get away with it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

[Arnd Bergmann]

On Thursday, August 11, 2016 3:50:00 PM CEST Catalin Marinas wrote:
> On Thu, Aug 11, 2016 at 10:53:01AM +0200, Arnd Bergmann wrote:
> > On Thursday, August 11, 2016 3:35:01 PM CEST Zhangjian (Bamvor) wrote:
> > > On 2016/6/18 7:54, Yury Norov wrote:
> > > > From: Andrew Pinski 
> > > >
> > > > In this patchset  ILP32 ABI support is added. Additionally to AARCH32,
> > > > which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible.
> > > >
> > > >  From now, AARCH32_EL0 (former COMPAT) config option means the support 
> > > > of
> > > > AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see next 
> > > > patches),
> > > > and COMPAT indicates that one of them, or both, is enabled.
> > > >
> > > > Where needed, CONFIG_COMPAT is changed over to use CONFIG_AARCH32_EL0 
> > > > instead
> > > >
> > > > Reviewed-by: David Daney 
> > > > Signed-off-by: Andrew Pinski 
> > > > Signed-off-by: Philipp Tomsich 
> > > > Signed-off-by: Christoph Muellner 
> > > > 
> > > > Signed-off-by: Bamvor Jian Zhang 
> > > > Signed-off-by: Yury Norov 
> > > ...
> > > > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > > > index c173d32..af200a8 100644
> > > > --- a/arch/arm64/kernel/cpuinfo.c
> > > > +++ b/arch/arm64/kernel/cpuinfo.c
> > > > @@ -134,15 +134,17 @@ static int c_show(struct seq_file *m, void *v)
> > > >  */
> > > > seq_puts(m, "Features\t:");
> > > > if (compat) {
> > > > -#ifdef CONFIG_COMPAT
> > > > -   for (j = 0; compat_hwcap_str[j]; j++)
> > > > -   if (compat_elf_hwcap & (1 << j))
> > > > -   seq_printf(m, " %s", 
> > > > compat_hwcap_str[j]);
> > > > -
> > > > -   for (j = 0; compat_hwcap2_str[j]; j++)
> > > > -   if (compat_elf_hwcap2 & (1 << j))
> > > > -   seq_printf(m, " %s", 
> > > > compat_hwcap2_str[j]);
> > > > -#endif /* CONFIG_COMPAT */
> > > > +#ifdef CONFIG_AARCH32_EL0
> > > I saw that compat_hwcap_str and compat_hwcap2_str is defined when
> > > "CONFIG_COMPAT" is true. Why we only change it to CONFIG_AARCH32_EL0
> > > in c show()?
> > > > +   if (personality(current->personality) == 
> > > > PER_LINUX32) {
> > > And "compat" is "personality(current->personality) == PER_LINUX32;",
> > > it seems that there is no need to add this twice.
> > 
> > I think it would be best to remove the #ifdef here completely,
> > the PER_LINUX32 concept is not strictly tied to the emulation
> > of ARM binaries, it literally just changes the output of
> > /proc/cpuinfo and 'uname',
> 
> It's not strictly related to ARM binaries, however it is related to
> AArch32 CPU features being supported and detected by the kernel.
> Currently, with CONFIG_COMPAT disabled, we won't have access to a
> (meaningful) compat_elf_hwcap.

Ah, makes sense. In that case, using CONFIG_AARCH32_EL0 sounds like
the right thing to do here, though I guess we can just drop the
"if (compat)" check, as we specifically want to print the supported
features of the CPU, and they are still present even if a
process with PER_LINUX reads them.

> > and you can have ARM binaries with
> > PER_LINUX (using the arm64 uname) just like you can have
> > arm64 binaries running with PER_LINUX32.
> 
> I was actually looking to enforce the 32-bit binaries to only see
> PER_LINUX32, though with a risk of breaking the ABI. OTOH, people are
> abusing this and write 32-bit apps relying on the 64-bit /proc/cpuinfo:
> 
> http://lkml.kernel.org/g/1464706504-25224-3-git-send-email-catalin.mari...@arm.com
> 
> (you were summoned on that discussion couple of times ;))

Hmm, I thought I saw the thread and didn't have any good idea for
the uname information, but didn't notice it was for /proc/cpuinfo.

What's wrong with always showing both the 32-bit and the 64-bit
hwcap strings here (minus the duplicates, which hopefully have
the same meaning here)?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

[Arnd Bergmann]

On Thursday, August 11, 2016 3:35:01 PM CEST Zhangjian (Bamvor) wrote:
> On 2016/6/18 7:54, Yury Norov wrote:
> > From: Andrew Pinski 
> >
> > In this patchset  ILP32 ABI support is added. Additionally to AARCH32,
> > which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible.
> >
> >  From now, AARCH32_EL0 (former COMPAT) config option means the support of
> > AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see next patches),
> > and COMPAT indicates that one of them, or both, is enabled.
> >
> > Where needed, CONFIG_COMPAT is changed over to use CONFIG_AARCH32_EL0 
> > instead
> >
> > Reviewed-by: David Daney 
> > Signed-off-by: Andrew Pinski 
> > Signed-off-by: Philipp Tomsich 
> > Signed-off-by: Christoph Muellner 
> > Signed-off-by: Bamvor Jian Zhang 
> > Signed-off-by: Yury Norov 
> ...
> > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > index c173d32..af200a8 100644
> > --- a/arch/arm64/kernel/cpuinfo.c
> > +++ b/arch/arm64/kernel/cpuinfo.c
> > @@ -134,15 +134,17 @@ static int c_show(struct seq_file *m, void *v)
> >  */
> > seq_puts(m, "Features\t:");
> > if (compat) {
> > -#ifdef CONFIG_COMPAT
> > -   for (j = 0; compat_hwcap_str[j]; j++)
> > -   if (compat_elf_hwcap & (1 << j))
> > -   seq_printf(m, " %s", 
> > compat_hwcap_str[j]);
> > -
> > -   for (j = 0; compat_hwcap2_str[j]; j++)
> > -   if (compat_elf_hwcap2 & (1 << j))
> > -   seq_printf(m, " %s", 
> > compat_hwcap2_str[j]);
> > -#endif /* CONFIG_COMPAT */
> > +#ifdef CONFIG_AARCH32_EL0
> I saw that compat_hwcap_str and compat_hwcap2_str is defined when
> "CONFIG_COMPAT" is true. Why we only change it to CONFIG_AARCH32_EL0
> in c show()?
> > +   if (personality(current->personality) == PER_LINUX32) {
> And "compat" is "personality(current->personality) == PER_LINUX32;",
> it seems that there is no need to add this twice.

I think it would be best to remove the #ifdef here completely,
the PER_LINUX32 concept is not strictly tied to the emulation
of ARM binaries, it literally just changes the output of
/proc/cpuinfo and 'uname', and you can have ARM binaries with
PER_LINUX (using the arm64 uname) just like you can have
arm64 binaries running with PER_LINUX32.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Documentation/watchdog: check return value for magic close

[Arnd Bergmann]

A recent commit added a write to the watchdog test code for doing the "magic
close", but that caused a compile-time warning:

Documentation/watchdog/src/watchdog-test.c: In function ‘main’:
Documentation/watchdog/src/watchdog-test.c:94:5: warning: ignoring return value 
of ‘write’, declared with attribute warn_unused_result [-Wunused-result]

This changes the code to print a runtime warning if the write fails.

Fixes: 5a2d3de19602 ("Documentation/watchdog: add support for magic close to 
watchdog-test")
Signed-off-by: Arnd Bergmann 
---
v2: fix typo as pointed out by both Guenter Roeck and Randy Dunlap
---
 Documentation/watchdog/src/watchdog-test.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/watchdog/src/watchdog-test.c 
b/Documentation/watchdog/src/watchdog-test.c
index c69153913722..6983d05097e2 100644
--- a/Documentation/watchdog/src/watchdog-test.c
+++ b/Documentation/watchdog/src/watchdog-test.c
@@ -2,6 +2,7 @@
  * Watchdog Driver Test Program
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -35,9 +36,13 @@ static void keep_alive(void)
 
 static void term(int sig)
 {
-write(fd, &v, 1);
+int ret = write(fd, &v, 1);
+
 close(fd);
-printf("\nStopping watchdog ticks...\n");
+if (ret < 0)
+   printf("\nStopping watchdog ticks failed (%d)...\n", errno);
+else
+   printf("\nStopping watchdog ticks...\n");
 exit(0);
 }
 
@@ -45,6 +50,7 @@ int main(int argc, char *argv[])
 {
 int flags;
 unsigned int ping_rate = 1;
+int ret;
 
 setbuf(stdout, NULL);
 
@@ -91,7 +97,9 @@ int main(int argc, char *argv[])
sleep(ping_rate);
 }
 end:
-write(fd, &v, 1);
+ret = write(fd, &v, 1);
+if (ret < 0)
+   printf("Stopping watchdog ticks failed (%d)...\n", errno);
 close(fd);
 return 0;
 }
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html