Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

[Naoya Horiguchi]

On Tue, Apr 03, 2018 at 09:59:28AM +0200, Michal Hocko wrote:
> On Tue 03-04-18 13:46:28, Naoya Horiguchi wrote:
> > My testing for the latest kernel supporting thp migration found out an
> > infinite loop in offlining the memory block that is filled with shmem
> > thps.  We can get out of the loop with a signal, but kernel should
> > return with failure in this case.
> >
> > What happens in the loop is that scan_movable_pages() repeats returning
> > the same pfn without any progress. That's because page migration always
> > fails for shmem thps.
>
> Why does it fail? Shmem pages should be movable without any issues.

.. because try_to_unmap_one() explicitly skips unmapping for migration.

  #ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
  /* PMD-mapped THP migration entry */
  if (!pvmw.pte && (flags & TTU_MIGRATION)) {
  VM_BUG_ON_PAGE(PageHuge(page) || 
!PageTransCompound(page), page);
  
  if (!PageAnon(page))
  continue;
  
  set_pmd_migration_entry(&pvmw, page);
  continue;
  }
  #endif

When I implemented this code, I felt hard to work on both of anon thp
and shmem thp at one time, so I separated the proposal into smaller steps.
Shmem uses pagecache so we need some non-trivial effort (including testing)
to extend thp migration for shmem. But I think it's a reasonable next step.

Thanks,
Naoya Horiguchi

[PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Hello!

Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.

This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via 
Xen guest domain configuration options [5].

***
* Driver limitations
***
 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend
allocated buffers) below are not supported at the same time.

 2. Only primary plane without additional properties is supported.

 3. Only one video mode supported which resolution is configured via XenStore.

 4. All CRTCs operate at fixed frequency of 60Hz.

***
* Driver modes of operation in terms of display buffers used
***
 Depending on the requirements for the para-virtualized environment, namely
 requirements dictated by the accompanying DRM/(v)GPU drivers running in both
 host and guest environments, number of operating modes of para-virtualized
 display driver are supported:
  - display buffers can be allocated by either frontend driver or backend
  - display buffers can be allocated to be contiguous in memory or not

 Note! Frontend driver itself has no dependency on contiguous memory for
   its operation.

***
* 1. Buffers allocated by the frontend driver.
***

 The below modes of operation are configured at compile-time via
 frontend driver's kernel configuration.

 1.1. Front driver configured to use GEM CMA helpers
  This use-case is useful when used with accompanying DRM/vGPU driver in
  guest domain which was designed to only work with contiguous buffers,
  e.g. DRM driver based on GEM CMA helpers: such drivers can only import
  contiguous PRIME buffers, thus requiring frontend driver to provide
  such. In order to implement this mode of operation para-virtualized
  frontend driver can be configured to use GEM CMA helpers.

 1.2. Front driver doesn't use GEM CMA
  If accompanying drivers can cope with non-contiguous memory then, to
  lower pressure on CMA subsystem of the kernel, driver can allocate
  buffers from system memory.

 Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
   may require IOMMU support on the platform, so accompanying DRM/vGPU
   hardware can still reach display buffer memory while importing PRIME
   buffers from the frontend driver.

***
* 2. Buffers allocated by the backend
***

 This mode of operation is run-time configured via guest domain configuration
 through XenStore entries.

 For systems which do not provide IOMMU support, but having specific
 requirements for display buffers it is possible to allocate such buffers
 at backend side and share those with the frontend.
 For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
 physically contiguous memory, this allows implementing zero-copying
 use-cases.


I would like to thank at least, but not at last the following
people/communities who helped this driver to happen ;)

1. My team at EPAM for continuous support
2. Xen community for answering tons of questions on different
modes of operation of the driver with respect to virtualized
environment.
3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6]
4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7]
5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8]

Changes since v5:
***
- fixed most of scripts/checkpatch.pl warnings

Changes since v4:
***
- updated the driver after "drm/simple-kms-helper: Plumb plane state
  to the enable hook" [14]
- made display_mode_valid static
- fixed page leak on event channel error path
- changed title of the documentation to match the rest of the drivers
- removed from the series the patch from Noralf Trønnes [12] as it was sent out
  as a standalone one

Changes since v3:
***
- no changes to Xen related code (shared buffer h

[PATCH v6 1/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].

Driver limitations:
 1. Only primary plane without additional properties is supported.
 2. Only one video mode supported which resolution is configured
via XenStore.
 3. All CRTCs operate at fixed frequency of 60Hz.

1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.

2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
  - read connector(s) configuration
  - read buffer allocation mode (backend/frontend)

3. Handle Xen event channels:
  - create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
  - implement event channels interrupt handlers
  - create and destroy event channels with respect to Xen bus state

4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
  - handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
  page directory
  - allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
  - grant references to the required set of pages for the
shared buffer itself
  - implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)

5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
  simple pipepline helper which is possible due to the fact
  that the para-virtualized driver only supports a single
  (primary) plane:
  - initialize connectors according to XenStore configuration
  - handle frame done events from the backend
  - create and destroy frame buffers and propagate those
to the backend
  - propagate set/reset mode configuration to the backend on display
enable/disable callbacks
  - send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
  - support only pixel formats suitable for single plane modes
  - make sure the connector is always connected
  - support a single video mode as per para-virtualized driver
configuration

6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment,
namely requirements dictated by the accompanying DRM/(v)GPU drivers
running in both host and guest environments, number of operating
modes of para-virtualized display driver are supported:
 - display buffers can be allocated by either
   frontend driver or backend
 - display buffers can be allocated to be contiguous
   in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

6.1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

6.1.1. Front driver configured to use GEM CMA helpers
 This use-case is useful when used with accompanying DRM/vGPU driver
 in guest domain which was designed to only work with contiguous
 buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
 only import contiguous PRIME buffers, thus requiring frontend driver
 to provide such. In order to implement this mode of operation
 para-virtualized frontend driver can be configured to use
 GEM CMA helpers.

6.1.2. Front driver doesn't use GEM CMA
 If accompanying drivers can cope with non-contiguous memory then, to
 lower pressure on CMA subsystem of the kernel, driver can allocate
 buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

6.2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain
configuration through XenStore entries.

For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting physically contiguous memory, this allows implementing
zero-copying use-cases.

Note, while using this scenario the following should be considered:
  a) If gu

[PATCH v30 2/4] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

[Wei Wang]

Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature indicates the
support of reporting hints of guest free pages to host via virtio-balloon.

Host requests the guest to report free page hints by sending a new cmd
id to the guest via the free_page_report_cmd_id configuration register.

When the guest starts to report, the first element added to the free page
vq is the cmd id given by host. When the guest finishes the reporting
of all the free pages, VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID is added
to the vq to tell host that the reporting is done. Host polls the free
page vq after sending the starting cmd id, so the guest doesn't need to
kick after filling an element to the vq.

Host may also requests the guest to stop the reporting in advance by
sending the stop cmd id to the guest via the configuration register.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
Cc: Michael S. Tsirkin 
Cc: Michal Hocko 
---
 drivers/virtio/virtio_balloon.c | 257 +++-
 include/uapi/linux/virtio_balloon.h |   4 +
 2 files changed, 225 insertions(+), 36 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index dfe5684..18d24a4 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -51,9 +51,22 @@
 static struct vfsmount *balloon_mnt;
 #endif
 
+enum virtio_balloon_vq {
+   VIRTIO_BALLOON_VQ_INFLATE,
+   VIRTIO_BALLOON_VQ_DEFLATE,
+   VIRTIO_BALLOON_VQ_STATS,
+   VIRTIO_BALLOON_VQ_FREE_PAGE,
+   VIRTIO_BALLOON_VQ_MAX
+};
+
 struct virtio_balloon {
struct virtio_device *vdev;
-   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
+
+   /* Balloon's own wq for cpu-intensive work items */
+   struct workqueue_struct *balloon_wq;
+   /* The free page reporting work item submitted to the balloon wq */
+   struct work_struct report_free_page_work;
 
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
@@ -63,6 +76,13 @@ struct virtio_balloon {
spinlock_t stop_update_lock;
bool stop_update;
 
+   /* The new cmd id received from host */
+   uint32_t cmd_id_received;
+   /* The cmd id that is in use */
+   __virtio32 cmd_id_use;
+   /* Buffer to store the stop sign */
+   __virtio32 stop_cmd_id;
+
/* Waiting for host to ack the pages we released. */
wait_queue_head_t acked;
 
@@ -320,17 +340,6 @@ static void stats_handle_request(struct virtio_balloon *vb)
virtqueue_kick(vq);
 }
 
-static void virtballoon_changed(struct virtio_device *vdev)
-{
-   struct virtio_balloon *vb = vdev->priv;
-   unsigned long flags;
-
-   spin_lock_irqsave(&vb->stop_update_lock, flags);
-   if (!vb->stop_update)
-   queue_work(system_freezable_wq, &vb->update_balloon_size_work);
-   spin_unlock_irqrestore(&vb->stop_update_lock, flags);
-}
-
 static inline s64 towards_target(struct virtio_balloon *vb)
 {
s64 target;
@@ -347,6 +356,34 @@ static inline s64 towards_target(struct virtio_balloon *vb)
return target - vb->num_pages;
 }
 
+static void virtballoon_changed(struct virtio_device *vdev)
+{
+   struct virtio_balloon *vb = vdev->priv;
+   unsigned long flags;
+   s64 diff = towards_target(vb);
+
+   if (diff) {
+   spin_lock_irqsave(&vb->stop_update_lock, flags);
+   if (!vb->stop_update)
+   queue_work(system_freezable_wq,
+  &vb->update_balloon_size_work);
+   spin_unlock_irqrestore(&vb->stop_update_lock, flags);
+   }
+
+   if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+   virtio_cread(vdev, struct virtio_balloon_config,
+free_page_report_cmd_id, &vb->cmd_id_received);
+   if (vb->cmd_id_received !=
+   VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID) {
+   spin_lock_irqsave(&vb->stop_update_lock, flags);
+   if (!vb->stop_update)
+   queue_work(vb->balloon_wq,
+  &vb->report_free_page_work);
+   spin_unlock_irqrestore(&vb->stop_update_lock, flags);
+   }
+   }
+}
+
 static void update_balloon_size(struct virtio_balloon *vb)
 {
u32 actual = vb->num_pages;
@@ -421,42 +458,163 @@ static void update_balloon_size_func(struct work_struct 
*work)
 
 static int init_vqs(struct virtio_balloon *vb)
 {
-   struct virtqueue *vqs[3];
-   vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
};
-   static const char * const names[] = { "inflate", "deflate", "stats" };
-   int err, nvqs;
+   struct virtqueue *vqs[VIRTIO_BALLOON_VQ_MAX];
+   vq_callback_t *callbacks[V

[PATCH v30 4/4] virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON

[Wei Wang]

The VIRTIO_BALLOON_F_PAGE_POISON feature bit is used to indicate if the
guest is using page poisoning. Guest writes to the poison_val config
field to tell host about the page poisoning value in use.

Signed-off-by: Wei Wang 
Suggested-by: Michael S. Tsirkin 
Cc: Michael S. Tsirkin 
Cc: Michal Hocko 
Cc: Andrew Morton 
---
 drivers/virtio/virtio_balloon.c | 10 ++
 include/uapi/linux/virtio_balloon.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 18d24a4..6de9339 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -699,6 +699,7 @@ static struct dentry *balloon_mount(struct file_system_type 
*fs_type,
 static int virtballoon_probe(struct virtio_device *vdev)
 {
struct virtio_balloon *vb;
+   __u32 poison_val;
int err;
 
if (!vdev->config->get) {
@@ -744,6 +745,11 @@ static int virtballoon_probe(struct virtio_device *vdev)
vb->stop_cmd_id = cpu_to_virtio32(vb->vdev,
VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID);
INIT_WORK(&vb->report_free_page_work, report_free_page_func);
+   if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+   memset(&poison_val, PAGE_POISON, sizeof(poison_val));
+   virtio_cwrite(vb->vdev, struct virtio_balloon_config,
+ poison_val, &poison_val);
+   }
}
 
vb->nb.notifier_call = virtballoon_oom_notify;
@@ -862,6 +868,9 @@ static int virtballoon_restore(struct virtio_device *vdev)
 
 static int virtballoon_validate(struct virtio_device *vdev)
 {
+   if (!page_poisoning_enabled())
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
+
__virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
return 0;
 }
@@ -871,6 +880,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
VIRTIO_BALLOON_F_STATS_VQ,
VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
VIRTIO_BALLOON_F_FREE_PAGE_HINT,
+   VIRTIO_BALLOON_F_PAGE_POISON,
 };
 
 static struct virtio_driver virtio_balloon_driver = {
diff --git a/include/uapi/linux/virtio_balloon.h 
b/include/uapi/linux/virtio_balloon.h
index b2d86c2..8b93581 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -35,6 +35,7 @@
 #define VIRTIO_BALLOON_F_STATS_VQ  1 /* Memory Stats virtqueue */
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_FREE_PAGE_HINT3 /* VQ to report free pages */
+#define VIRTIO_BALLOON_F_PAGE_POISON   4 /* Guest is using page poisoning */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
@@ -47,6 +48,8 @@ struct virtio_balloon_config {
__u32 actual;
/* Free page report command id, readonly by guest */
__u32 free_page_report_cmd_id;
+   /* Stores PAGE_POISON if page poisoning is in use */
+   __u32 poison_val;
 };
 
 #define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
-- 
1.8.3.1

[PATCH v30 3/4] mm/page_poison: expose page_poisoning_enabled to kernel modules

[Wei Wang]

In some usages, e.g. virtio-balloon, a kernel module needs to know if
page poisoning is in use. This patch exposes the page_poisoning_enabled
function to kernel modules.

Signed-off-by: Wei Wang 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Michael S. Tsirkin 
Acked-by: Andrew Morton 
---
 mm/page_poison.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mm/page_poison.c b/mm/page_poison.c
index e83fd44..762b472 100644
--- a/mm/page_poison.c
+++ b/mm/page_poison.c
@@ -17,6 +17,11 @@ static int early_page_poison_param(char *buf)
 }
 early_param("page_poison", early_page_poison_param);
 
+/**
+ * page_poisoning_enabled - check if page poisoning is enabled
+ *
+ * Return true if page poisoning is enabled, or false if not.
+ */
 bool page_poisoning_enabled(void)
 {
/*
@@ -29,6 +34,7 @@ bool page_poisoning_enabled(void)
(!IS_ENABLED(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC) &&
debug_pagealloc_enabled()));
 }
+EXPORT_SYMBOL_GPL(page_poisoning_enabled);
 
 static void poison_page(struct page *page)
 {
-- 
1.8.3.1

[PATCH v30 0/4] Virtio-balloon: support free page reporting

[Wei Wang]

This patch series is separated from the previous "Virtio-balloon
Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT,  
implemented by this series enables the virtio-balloon driver to report
hints of guest free pages to the host. It can be used to accelerate live
migration of VMs. Here is an introduction of this usage:

Live migration needs to transfer the VM's memory from the source machine
to the destination round by round. For the 1st round, all the VM's memory
is transferred. From the 2nd round, only the pieces of memory that were
written by the guest (after the 1st round) are transferred. One method
that is popularly used by the hypervisor to track which part of memory is
written is to write-protect all the guest memory.

This feature enables the optimization by skipping the transfer of guest
free pages during VM live migration. It is not concerned that the memory
pages are used after they are given to the hypervisor as a hint of the
free pages, because they will be tracked by the hypervisor and transferred
in the subsequent round if they are used and written.

* Tests
- Test Environment
Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
Guest: 8G RAM, 4 vCPU
Migration setup: migrate_set_speed 100G, migrate_set_downtime 2 second

- Test Results
- Idle Guest Live Migration Time (results are averaged over 10 runs):
- Optimization v.s. Legacy = 271ms vs 1769ms --> ~86% reduction
- Guest with Linux Compilation Workload (make bzImage -j4):
- Live Migration Time (average)
  Optimization v.s. Legacy = 1265ms v.s. 2634ms --> ~51% reduction
- Linux Compilation Time
  Optimization v.s. Legacy = 4min56s v.s. 5min3s
  --> no obvious difference

ChangeLog:
v29->v30:
- mm/walk_free_mem_block: add cond_sched() for each order
v28->v29:
- mm/page_poison: only expose page_poison_enabled(), rather than more
  changes did in v28, as we are not 100% confident about that for now.
- virtio-balloon: use a separate buffer for the stop cmd, instead of
  having the start and stop cmd use the same buffer. This avoids the
  corner case that the start cmd is overridden by the stop cmd when
  the host has a delay in reading the start cmd.
v27->v28:
- mm/page_poison: Move PAGE_POISON to page_poison.c and add a function
  to expose page poison val to kernel modules.
v26->v27:
- add a new patch to expose page_poisoning_enabled to kernel modules
- virtio-balloon: set poison_val to 0x, instead of 0xaa
v25->v26: virtio-balloon changes only
- remove kicking free page vq since the host now polls the vq after
  initiating the reporting
- report_free_page_func: detach all the used buffers after sending
  the stop cmd id. This avoids leaving the detaching burden (i.e.
  overhead) to the next cmd id. Detaching here isn't considered
  overhead since the stop cmd id has been sent, and host has already
  moved formard.
v24->v25:
- mm: change walk_free_mem_block to return 0 (instead of true) on
  completing the report, and return a non-zero value from the
  callabck, which stops the reporting.
- virtio-balloon:
- use enum instead of define for VIRTIO_BALLOON_VQ_INFLATE etc.
- avoid __virtio_clear_bit when bailing out;
- a new method to avoid reporting the some cmd id to host twice
- destroy_workqueue can cancel free page work when the feature is
  negotiated;
- fail probe when the free page vq size is less than 2.
v23->v24:
- change feature name VIRTIO_BALLOON_F_FREE_PAGE_VQ to
  VIRTIO_BALLOON_F_FREE_PAGE_HINT
- kick when vq->num_free < half full, instead of "= half full"
- replace BUG_ON with bailing out
- check vb->balloon_wq in probe(), if null, bail out
- add a new feature bit for page poisoning
- solve the corner case that one cmd id being sent to host twice
v22->v23:
- change to kick the device when the vq is half-way full;
- open-code batch_free_page_sg into add_one_sg;
- change cmd_id from "uint32_t" to "__virtio32";
- reserver one entry in the vq for the driver to send cmd_id, instead
  of busywaiting for an available entry;
- add "stop_update" check before queue_work for prudence purpose for
  now, will have a separate patch to discuss this flag check later;
- init_vqs: change to put some variables on stack to have simpler
  implementation;
- add destroy_workqueue(vb->balloon_wq);
v21->v22:
- add_one_sg: some code and comment re-arrangement
- send_cmd_id: handle a cornercase

For previous ChangeLog, please reference
https://lwn.net/Articles/743660/

Wei Wang (4):
  mm: support reporting free page blocks
  virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
  mm/page_poison: expose page_poisoning_enabled to kernel modules
  virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON

 drivers/virtio/virtio_balloon.c | 267 +

re: [PATCH] mm: avoid the unnecessary waiting when force empty a cgroup

[Li,Rongqing]

> -邮件原件-
> 发件人: Michal Hocko [mailto:mho...@kernel.org]
> 发送时间: 2018年4月3日 16:05
> 收件人: Li,Rongqing 
> 抄送: han...@cmpxchg.org; vdavydov@gmail.com;
> cgro...@vger.kernel.org; linux...@kvack.org;
> linux-kernel@vger.kernel.org
> 主题: Re: [PATCH] mm: avoid the unnecessary waiting when force empty a
> cgroup
> 
> On Tue 03-04-18 15:12:09, Li RongQing wrote:
> > The number of writeback and dirty page can be read out from memcg, the
> > unnecessary waiting can be avoided by these counts
> 
> This changelog doesn't explain the problem and how the patch fixes it.

If a process in a memory cgroup takes some RSS, when force empty this memory 
cgroup, congestion_wait will be called unconditionally, there is 0.5 seconds 
delay

If use this patch, nearly no delay.


> Why do wee another throttling when we do already throttle in the reclaim
> path?

Do you mean we should remove congestion_wait(BLK_RW_ASYNC, HZ/10) from 
mem_cgroup_force_empty, since try_to_free_mem_cgroup_pages 
[shrink_inactive_list] has called congestion_wait


-RongQing

> 
> > Signed-off-by: Li RongQing 
> > ---
> >  mm/memcontrol.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c index
> > 9ec024b862ac..5258651bd4ec 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -2613,9 +2613,13 @@ static int mem_cgroup_force_empty(struct
> mem_cgroup *memcg)
> > progress = try_to_free_mem_cgroup_pages(memcg, 1,
> > GFP_KERNEL, true);
> > if (!progress) {
> > +   unsigned long num;
> > +
> > +   num = memcg_page_state(memcg, NR_WRITEBACK) +
> > +   memcg_page_state(memcg, NR_FILE_DIRTY);
> > nr_retries--;
> > -   /* maybe some writeback is necessary */
> > -   congestion_wait(BLK_RW_ASYNC, HZ/10);
> > +   if (num)
> > +   congestion_wait(BLK_RW_ASYNC, HZ/10);
> > }
> >
> > }
> > --
> > 2.11.0
> 
> --
> Michal Hocko
> SUSE Labs

[PATCH v30 1/4] mm: support reporting free page blocks

[Wei Wang]

This patch adds support to walk through the free page blocks in the
system and report them via a callback function. Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages.

One use example of this patch is to accelerate live migration by skipping
the transfer of free pages reported from the guest. A popular method used
by the hypervisor to track which part of memory is written during live
migration is to write-protect all the guest memory. So, those pages that
are reported as free pages but are written after the report function
returns will be captured by the hypervisor, and they will be added to the
next round of memory transfer.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
Cc: Michal Hocko 
Cc: Andrew Morton 
Cc: Michael S. Tsirkin 
Acked-by: Michal Hocko 
---
 include/linux/mm.h |  6 
 mm/page_alloc.c| 97 ++
 2 files changed, 103 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ccac106..8141e99 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1942,6 +1942,12 @@ extern void free_area_init_node(int nid, unsigned long * 
zones_size,
unsigned long zone_start_pfn, unsigned long *zholes_size);
 extern void free_initmem(void);
 
+extern int walk_free_mem_block(void *opaque,
+  int min_order,
+  int (*report_pfn_range)(void *opaque,
+  unsigned long pfn,
+  unsigned long num));
+
 /*
  * Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK)
  * into the buddy system. The freed pages will be poisoned with pattern
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4ea0182..83e50fd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4912,6 +4912,103 @@ void show_free_areas(unsigned int filter, nodemask_t 
*nodemask)
show_swap_cache_info();
 }
 
+/*
+ * Walk through a free page list and report the found pfn range via the
+ * callback.
+ *
+ * Return 0 if it completes the reporting. Otherwise, return the non-zero
+ * value returned from the callback.
+ */
+static int walk_free_page_list(void *opaque,
+  struct zone *zone,
+  int order,
+  enum migratetype mt,
+  int (*report_pfn_range)(void *,
+  unsigned long,
+  unsigned long))
+{
+   struct page *page;
+   struct list_head *list;
+   unsigned long pfn, flags;
+   int ret = 0;
+
+   spin_lock_irqsave(&zone->lock, flags);
+   list = &zone->free_area[order].free_list[mt];
+   list_for_each_entry(page, list, lru) {
+   pfn = page_to_pfn(page);
+   ret = report_pfn_range(opaque, pfn, 1 << order);
+   if (ret)
+   break;
+   }
+   spin_unlock_irqrestore(&zone->lock, flags);
+
+   return ret;
+}
+
+/**
+ * walk_free_mem_block - Walk through the free page blocks in the system
+ * @opaque: the context passed from the caller
+ * @min_order: the minimum order of free lists to check
+ * @report_pfn_range: the callback to report the pfn range of the free pages
+ *
+ * If the callback returns a non-zero value, stop iterating the list of free
+ * page blocks. Otherwise, continue to report.
+ *
+ * Please note that there are no locking guarantees for the callback and
+ * that the reported pfn range might be freed or disappear after the
+ * callback returns so the caller has to be very careful how it is used.
+ *
+ * The callback itself must not sleep or perform any operations which would
+ * require any memory allocations directly (not even GFP_NOWAIT/GFP_ATOMIC)
+ * or via any lock dependency. It is generally advisable to implement
+ * the callback as simple as possible and defer any heavy lifting to a
+ * different context.
+ *
+ * There is no guarantee that each free range will be reported only once
+ * during one walk_free_mem_block invocation.
+ *
+ * pfn_to_page on the given range is strongly discouraged and if there is
+ * an absolute need for that make sure to contact MM people to discuss
+ * potential problems.
+ *
+ * The function itself might sleep so it cannot be called from atomic
+ * contexts.
+ *
+ * In general low orders tend to be very volatile and so it makes more
+ * sense to query larger ones first for various optimizations which like
+ * ballooning etc... This will reduce the overhead as well.
+ *
+ * Return 0 if it completes the reporting. Otherwise, return the non-zero
+ * value returned from the callback.
+ */
+int walk_free_mem_block(void *opaque,
+   int min_order,
+   int (*report_pfn_range)(void *opaque

Re: [PATCH] usb: dwc3: of-simple: use managed and shared reset control

[Masahiro Yamada]

2018-04-03 17:00 GMT+09:00 Philipp Zabel :
> On Thu, 2018-03-29 at 15:07 +0900, Masahiro Yamada wrote:
>> This driver handles the reset control in a common manner; deassert
>> resets before use, assert them after use.  There is no good reason
>> why it should be exclusive.
>
> Is this preemptive cleanup, or do you have hardware on the horizon that
> shares these reset lines with other peripherals?


This patch is necessary for Socionext SoCs.

The same reset lines are shared between
this dwc3-of_simple and other glue circuits.



>> Also, use devm_ for clean-up.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> CCing Philipp Zabel.
>> I see his sob in commit 06c47e6286d5.
>
> At the time I was concerned with the reset_control_array addition and
> didn't look closely at the exclusive vs shared issue.
>>  drivers/usb/dwc3/dwc3-of-simple.c | 7 ++-
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
>> b/drivers/usb/dwc3/dwc3-of-simple.c
>> index e54c362..bd6ab65 100644
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -91,7 +91,7 @@ static int dwc3_of_simple_probe(struct platform_device 
>> *pdev)
>>   platform_set_drvdata(pdev, simple);
>>   simple->dev = dev;
>>
>> - simple->resets = of_reset_control_array_get_optional_exclusive(np);
>> + simple->resets = devm_reset_control_array_get_optional_shared(dev);
>
> From the usage in the driver, it does indeed look like _shared reset
> usage is appropriate. I assume that the hardware has no need for the
> reset to be asserted right before probe or after remove, it just
> requires that the reset line is kept deasserted while the driver is
> probed.
>
>>   if (IS_ERR(simple->resets)) {
>>   ret = PTR_ERR(simple->resets);
>>   dev_err(dev, "failed to get device resets, err=%d\n", ret);
>> @@ -100,7 +100,7 @@ static int dwc3_of_simple_probe(struct platform_device 
>> *pdev)
>>
>>   ret = reset_control_deassert(simple->resets);
>>   if (ret)
>> - goto err_resetc_put;
>> + return ret;
>>
>>   ret = dwc3_of_simple_clk_init(simple, of_count_phandle_with_args(np,
>>   "clocks", "#clock-cells"));
>> @@ -126,8 +126,6 @@ static int dwc3_of_simple_probe(struct platform_device 
>> *pdev)
>>  err_resetc_assert:
>>   reset_control_assert(simple->resets);
>>
>> -err_resetc_put:
>> - reset_control_put(simple->resets);
>>   return ret;
>>  }
>>
>> @@ -146,7 +144,6 @@ static int dwc3_of_simple_remove(struct platform_device 
>> *pdev)
>>   simple->num_clocks = 0;
>>
>>   reset_control_assert(simple->resets);
>> - reset_control_put(simple->resets);
>>
>>   pm_runtime_put_sync(dev);
>>   pm_runtime_disable(dev);
>
> Changing to devm_ changes the order here. Whether or not it could be a
> problem to assert the reset only after pm_runtime_put (or potentially
> never), I can't say. I assume this is a non-issue, but somebody who
> knows the hardware better would have to decide.



I do not understand what you mean.
Can you describe your concern in more details?

I am not touching reset_control_assert() here.

I am delaying the call for reset_control_put().


If I understand reset_control_put() correctly,
the effects of this change are:
  - The ref_count and module ownership for the reset controller
driver will be held a little longer
  - The call for kfree() will be a little bit delayed.

Why do you need knowledge about this hardware?



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma

[Boris Brezillon]

On Tue, 3 Apr 2018 10:14:31 +0200
Peter Rosin  wrote:

> On 2018-04-03 09:15, Boris Brezillon wrote:
> > On Tue, 3 Apr 2018 08:51:10 +0200
> > Peter Rosin  wrote:
> >   
> >> On 2018-04-02 22:20, Boris Brezillon wrote:  
> >>> On Mon, 2 Apr 2018 21:28:43 +0200
> >>> Boris Brezillon  wrote:
> >>> 
>  On Mon, 2 Apr 2018 19:59:39 +0200
>  Peter Rosin  wrote:
> 
> > On 2018-04-02 14:22, Boris Brezillon wrote:  
> >> On Thu, 29 Mar 2018 16:27:12 +0200
> >> Peter Rosin  wrote:
> >> 
> >>> On 2018-03-29 15:44, Boris Brezillon wrote:
>  On Thu, 29 Mar 2018 15:37:43 +0200
>  Peter Rosin  wrote:
>    
> > On 2018-03-29 15:33, Boris Brezillon wrote:  
> >> On Thu, 29 Mar 2018 15:10:54 +0200
> >> Peter Rosin  wrote:
> >> 
> >>> On a sama5d31 with a Full-HD dual LVDS panel (132MHz pixel clock) 
> >>> NAND
> >>> flash accesses have a tendency to cause display disturbances. Add 
> >>> a
> >>> module param to disable DMA from the NAND controller, since that 
> >>> fixes
> >>> the display problem for me.
> >>>
> >>> Signed-off-by: Peter Rosin 
> >>> ---
> >>>  drivers/mtd/nand/raw/atmel/nand-controller.c | 7 ++-
> >>>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c 
> >>> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> index b2f00b398490..2ff7a77c7b8e 100644
> >>> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> >>> @@ -129,6 +129,11 @@
> >>>  #define DEFAULT_TIMEOUT_MS   1000
> >>>  #define MIN_DMA_LEN  128
> >>>  
> >>> +static bool atmel_nand_avoid_dma __read_mostly;
> >>> +
> >>> +MODULE_PARM_DESC(avoiddma, "Avoid using DMA");
> >>> +module_param_named(avoiddma, atmel_nand_avoid_dma, bool, 0400);  
> >>>   
> >>
> >> I'm not a big fan of those driver specific cmdline parameters. 
> >> Can't we
> >> instead give an higher priority to HLCDC master using the bus 
> >> matrix?
> >
> > I don't know if it will be enough, but we sure can try. However, I 
> > have
> > no idea how to do that. I will happily test stuff though... 
> >  
> 
>  There's no interface to configure that from Linux, but you can try to
>  tweak it with devmem and if that does the trick, maybe we can expose 
>  a
>  way to configure that from Linux. For more details, see the "Bus 
>  Matrix
>  (MATRIX)" section in Atmel datasheets.  
> >>>
> >>> I don't seem to succeed in changing the registers I think I need to 
> >>> change.
> >>> I can poke the "Write Protection Mode Register" by writing MAT0 and 
> >>> MAT1 to
> >>> it.
> >>
> >> You mean 0x4D415400, right? ("MAT0" != 0x4D415400).
> >
> > Bits 1 through 7 do not matter, so even though not equal they are (or
> > should be) equivalent. But I did use 0x4d415400. I simply used the
> > shorter syntax since that was easier to type and conveyed the relevant
> > info.  
> 
>  Ok.
> 
> >   
> >>> But when I try to write to "Priority Registers B For Slaves" it 
> >>> doesn't
> >>> take, regardless of write protect mode.
> >>
> >> Did you check MATRIX_WPSR after writing to MATRIX_PRXSY?
> >
> > No, but did it again and checked, see transcript below.  
> 
>  I don't use devmem2. Is 'readback' information accurate or is it
>  always what's been written? Because when you write 0x33 to 0xECBC,
>  0x33 is read back, but just after that, when you read it again it's 0.
> 
> > BTW, how do I
> > know which master is in use for the LCD controller? 8 or 9? Both?  
> 
>  It's configurable on a per-layer basis through the SIF bit in
>  LCDC_CFG0. The driver tries to dispatch the load on those 2 AHB
>  masters [1].
> 
> > And
> > which DDR slave is the target? 7, 8, 9 or 10? More than one?  
> 
>  This, I don't know. I guess all of them can be used.
> >>>
> >>> Looks like I was wrong. According to "Table 15-3. SAMA5D3 Master to
> >>> Slave Access", LCDC port 0 can only access DDR port 2 and LCDC port 1
> >>> can only access DDR port 3.
> >>>
> >>> Can you try to write 0x3 to 0xECCC and 0x30 to 0xECD4?
> >>
> >> Given the matrix dump in the other mail, it is not surprising that I
> >> can't. But if I change the matrix from the default
> >>
> >>  0 33--3--3----
> >>  1 33--3--3-

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

[Hans de Goede]

Hi Luis,

Thank you for the review.

On 03-04-18 01:23, Luis R. Rodriguez wrote:

On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote:

Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometimes may contain data which is useful/necessary for peripheral drivers
to have access to.

Specifically the EFI code may contain an embedded copy of firmware which
needs to be (re)loaded into the peripheral. Normally such firmware would be
part of linux-firmware, but in some cases this is not feasible, for 2
reasons:

1) The firmware is customized for a specific use-case of the chipset / use
with a specific hardware model, so we cannot have a single firmware file
for the chipset. E.g. touchscreen controller firmwares are compiled
specifically for the hardware model they are used with, as they are
calibrated for a specific model digitizer.


Some devices have OTP and use this sort of calibration data,


Right, I'm not sure it really is OTP and not flash, but many touchscreen
controllers do come with their firmware embedded into the controller, but
not all unfortunately.


I was unaware of
the use of EFI to stash firmware. Good to know, but can you also provide
references to what part of what standard should be followed for it in
documentation?


This is not part of the standard. There has been a long(ish) standing issue
with us not being able to get re-distribute permission for the firmware for
some touchscreen controllers found on cheap x86 devices. Which means that
we cannot put it in Linux firmware.

Dave Olsthoorn (in the Cc) noticed that the touchscreen did work in the
refind bootload UI, so the EFI code must have a copy of the firmware.

I asked Peter Jones for suggestions how to extract this during boot and
he suggested seeing if there was a copy of the firmware in the
EFI_BOOT_SERVICES_CODE memory segment, which it turns out there is.

My patch to add support for this contains a table of device-model (dmi
strings), firmware header (first 64 bits), length and crc32 and then if
we boot on a device-model which is in the table the code scans the
EFI_BOOT_SERVICES_CODE for the prefix, if found checks the crc and
caches the firmware for later use by request-firmware.

So I just do a brute-force search for the firmware, this really is hack,
nothing standard about it I'm afraid. But it works on 4 different x86
tablets I have and makes the touchscreen work OOTB on them, so I believe
it is a worthwhile hack to have.


2) Despite repeated attempts we have failed to get permission to
redistribute the firmware. This is especially a problem with customized
firmwares, these get created by the chip vendor for a specific ODM and the
copyright may partially belong with the ODM, so the chip vendor cannot
give a blanket permission to distribute these.

This commit adds support for finding peripheral firmware embedded in the
EFI code and making this available to peripheral drivers through the
standard firmware loading mechanism.


Neat.


Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware pretty
late in the init sequence,


This also creates a technical limitation on use for the API that users
should be aware of. Its important to document such limitation.


I don't think this is a problem for any normal drivers, when I say pretty
late I mean late in init/main.c: start_kernel(), so still before any normal
drivers load.

The first idea was to scan for the firmware at the same time we check for
things as the ACPI BGRT logo stuff, but as mentioned that requires using
early_mmap() which does not work for the amount of memory we want to map.


Also if we can address the limitation that would be even better.

For instance, on what part of the driver is the call to request firmware
being made? Note that we support async probe now, so if the call was done
on probe, it may be wise to use async probe, however, can we be *certain*
that the EFI firmware would have been parsed and ready by then? Please
check. It just may be the case.

Or, if we use late_initcall() would that suffice on the driver, if they
used a request firmware call on init or probe?


As said I think we still do it early enough for any driver use, when
I wrote "late in the init sequence" I should have probably written something
else, like "near the end of start_kernel() instead of from setup_arch()"




this is on purpose because the typical
EFI_BOOT_SERVICES_CODE memory-segment is too large for early_memremap().


To be clear you neede to use memremap()


Yes.


What mechanism would have in place to ensure that a driver which expects
firmware to be on EFI data to be already available prior to its driver's
call to initialize?


See above, this still runs before start_kernel() calls rest_init() which is
where any normal init calls (and driver probing) happens so still early
enough for any users I can think of. I think my poorly worded commit
message is causing a b

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

[Michal Hocko]

On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote:
> On Tue, Apr 03, 2018 at 09:59:28AM +0200, Michal Hocko wrote:
> > On Tue 03-04-18 13:46:28, Naoya Horiguchi wrote:
> > > My testing for the latest kernel supporting thp migration found out an
> > > infinite loop in offlining the memory block that is filled with shmem
> > > thps.  We can get out of the loop with a signal, but kernel should
> > > return with failure in this case.
> > >
> > > What happens in the loop is that scan_movable_pages() repeats returning
> > > the same pfn without any progress. That's because page migration always
> > > fails for shmem thps.
> >
> > Why does it fail? Shmem pages should be movable without any issues.
> 
> .. because try_to_unmap_one() explicitly skips unmapping for migration.
> 
>   #ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
>   /* PMD-mapped THP migration entry */
>   if (!pvmw.pte && (flags & TTU_MIGRATION)) {
>   VM_BUG_ON_PAGE(PageHuge(page) || 
> !PageTransCompound(page), page);
>   
>   if (!PageAnon(page))
>   continue;
>   
>   set_pmd_migration_entry(&pvmw, page);
>   continue;
>   }
>   #endif
> 
> When I implemented this code, I felt hard to work on both of anon thp
> and shmem thp at one time, so I separated the proposal into smaller steps.
> Shmem uses pagecache so we need some non-trivial effort (including testing)
> to extend thp migration for shmem. But I think it's a reasonable next step.

OK, I see. I have forgot about this part. Please be explicit about that
in the changelog. Also the proper fix is to not use movable zone for
shmem page THP rather than hack around it in the hotplug specific code
IMHO.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] reset: uniphier: add SATA reset control support and change SATA-PHY ID

[Masahiro Yamada]

2018-04-03 17:18 GMT+09:00 Philipp Zabel :
> On Fri, 2018-03-30 at 18:44 +0900, Kunihiko Hayashi wrote:
>> Add reset lines for SATA controller on UniPhier SoCs.
>> This adds support for Pro4 and PXs3 in addition to PXs2.
>>
>> And this changes the ID of the reset line for SATA-PHY on PXs2.
>> Since some SoCs have two controller instances with a common PHY, this moves
>> the ID of SATA-PHY for consistency.
>>
>> Signed-off-by: Kunihiko Hayashi 
>> ---
>>  drivers/reset/reset-uniphier.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
>> index 55ae0f1..90e6caf 100644
>> --- a/drivers/reset/reset-uniphier.c
>> +++ b/drivers/reset/reset-uniphier.c
>> @@ -63,6 +63,9 @@ static const struct uniphier_reset_data 
>> uniphier_pro4_sys_reset_data[] = {
>>   UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (Ether, SATA, USB3) */
>>   UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
>>   UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
>> + UNIPHIER_RESETX(28, 0x2000, 18),/* SATA0 */
>> + UNIPHIER_RESETX(29, 0x2004, 18),/* SATA1 */
>> + UNIPHIER_RESETX(30, 0x2000, 19),/* SATA-PHY */
>>   UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
>>   UNIPHIER_RESET_END,
>>  };
>> @@ -90,7 +93,7 @@ static const struct uniphier_reset_data 
>> uniphier_pxs2_sys_reset_data[] = {
>>   UNIPHIER_RESETX(20, 0x2014, 5), /* USB31-PHY0 */
>>   UNIPHIER_RESETX(21, 0x2014, 1), /* USB31-PHY1 */
>>   UNIPHIER_RESETX(28, 0x2014, 12),/* SATA */
>> - UNIPHIER_RESET(29, 0x2014, 8),  /* SATA-PHY (active high) */
>> + UNIPHIER_RESET(30, 0x2014, 8),  /* SATA-PHY (active high) */
>
> This is a backwards incompatible change.
> There is no DT in use that relies on this being 29 ?


Right.  No user for this reset line ever.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma

[Peter Rosin]

On 2018-04-03 09:18, Alexandre Belloni wrote:
> On 02/04/2018 at 22:23:17 +0200, Peter Rosin wrote:
 No, but did it again and checked, see transcript below.
>>>
>>> I don't use devmem2. Is 'readback' information accurate or is it
>>> always what's been written? Because when you write 0x33 to 0xECBC,
>>> 0x33 is read back, but just after that, when you read it again it's 0.
>>
>> Looking at the devmem2 source, it seems very likely that the compiler
>> optimizes out the read and thus outputs what has been written.
>>
> 
> At least on x86, it is not optimized out.

Looking at the disassembly, they are gone here (not that I'm fluent).
I then tried to compile devmem2 with -O0 (instead of -Os) and the read
is then fine. So, I guess the devmem2 devs could claim that it's a
buildroot issue, but a volatile would certainly have helped...

Cheers,
Peter

Re: [PATCH] mm: avoid the unnecessary waiting when force empty a cgroup

[Michal Hocko]

On Tue 03-04-18 08:29:39, Li,Rongqing wrote:
> 
> 
> > -邮件原件-
> > 发件人: Michal Hocko [mailto:mho...@kernel.org]
> > 发送时间: 2018年4月3日 16:05
> > 收件人: Li,Rongqing 
> > 抄送: han...@cmpxchg.org; vdavydov@gmail.com;
> > cgro...@vger.kernel.org; linux...@kvack.org;
> > linux-kernel@vger.kernel.org
> > 主题: Re: [PATCH] mm: avoid the unnecessary waiting when force empty a
> > cgroup
> > 
> > On Tue 03-04-18 15:12:09, Li RongQing wrote:
> > > The number of writeback and dirty page can be read out from memcg, the
> > > unnecessary waiting can be avoided by these counts
> > 
> > This changelog doesn't explain the problem and how the patch fixes it.
> 
> If a process in a memory cgroup takes some RSS, when force empty this
> memory cgroup, congestion_wait will be called unconditionally, there
> is 0.5 seconds delay

OK, so the problem is that force_empty hits congestion_wait too much?
Why do we have no progress from try_to_free_mem_cgroup_pages?
 
> If use this patch, nearly no delay.
> 
> 
> > Why do wee another throttling when we do already throttle in the reclaim
> > path?
> 
> Do you mean we should remove congestion_wait(BLK_RW_ASYNC, HZ/10)
> from mem_cgroup_force_empty, since try_to_free_mem_cgroup_pages
> [shrink_inactive_list] has called congestion_wait

If it turns unnecessary, which is quite possible then yes. As I've said
we already throttle when seeing pages under writeback. If that is not
sufficient then we should investigate why.

Please also note that force_empty is considered deprecated. Do you have
any usecase which led you to fixing it?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 07:52:25AM +0200, Martin Schwidefsky wrote:
> On Thu, 29 Mar 2018 20:08:36 +0200
> Peter Zijlstra  wrote:
> 
> > On Thu, Mar 29, 2018 at 04:53:43PM +0200, Martin Schwidefsky wrote:
> > > The lowcore optimization for softirq_pending field is not really needed,
> > > just nice to have. But if there is a strong reason to make a common
> > > definition for it we can certainly do that.  
> > 
> > A slightly related question; would it make sense to move all kernel
> > static per-cpu stuff into lowcore, or is that asking for too much
> > trickery?
>  
> The space in lowcore is quite limited, for zArch the structure is 8K with
> many pre-defined fields. I fear that putting all of the static per-cpu
> stuff in there is too much. 
> 
> So far I used the lowcore as optimization for selected per-cpu fields
> which are performance relevant.

Fair enough; and yes 8k isn't much. Thanks for the info.

Re: [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA

[Jian-Hong Pan]

2018-04-02 19:29 GMT+08:00 Takashi Iwai :
>
> On Mon, 02 Apr 2018 09:33:13 +0200,
> Jian-Hong Pan wrote:
> >
> > This ASUS D640SA desktop whose mother board is D640MB has
> > - two jacks which are a headphone and a mic on the front panel,
> > - three jacks which are a mic, a line out and a line in on the rear panel
> > - one internal speaker.
> >
> > If I plug a headphone to the front headphone jack, there will be sound
> > through the headphone jack, and no sound through the internal speaker.
> > If I unplug the headphone from the the headphone jack, there will be
> > sound through the internal speaker.  And always no sound through rear
> > line out, when I plug a headphone or an externel speaker to the rear
> > line out jack.
> >
> > Besides, I had checked and toggled the Auto-Mute Mode in alsamixer, but
> > the rear line out still was not working.  Then I checked the sound
> > settings in GUI, and found there was no "Line Out" could be chosen, only
> > the "Headphones" and "HDMI/DisplayPort".
> > However, system does know that there is an "Intel PCH Line Out".
> >
> > [   10.089082] snd_hda_codec_realtek hdaudioC0D0: autoconfig for
> > ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
> > [   10.089083] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1
> > (0x1a/0x0/0x0/0x0/0x0)
> > [   10.089084] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1
> > (0x1b/0x0/0x0/0x0/0x0)
> > [   10.089085] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
> > [   10.089086] snd_hda_codec_realtek hdaudioC0D0:inputs:
> > [   10.089087] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
> > [   10.089088] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
> > [   10.089089] snd_hda_codec_realtek hdaudioC0D0:  Line=0x15
> > [   10.104387] input: HDA Intel PCH Rear Mic as
> > /devices/pci:00/:00:1f.3/sound/card0/input9
> > [   10.104416] input: HDA Intel PCH Front Mic as
> > /devices/pci:00/:00:1f.3/sound/card0/input10
> > [   10.104441] input: HDA Intel PCH Line as
> > /devices/pci:00/:00:1f.3/sound/card0/input11
> > [   10.104467] input: HDA Intel PCH Line Out as
> > /devices/pci:00/:00:1f.3/sound/card0/input12
> > [   10.104494] input: HDA Intel PCH Front Headphone as
> > /devices/pci:00/:00:1f.3/sound/card0/input13
> >
> > Consequently, I checked the pin widgets' default configuration values:
> > - Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
> > Pin Default 0x01014010: [Jack] Line Out at Ext Rear
> >
> > - Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
> > Pin Default 0x02214030: [Jack] HP Out at Ext Front
> >
> > Because the headphone jack (Node ID:0x1b) locates on the desktop's front
> > panel, not rear panel, I change the headphone jack's configuration from
> > primary chassis to separate chassis.  So, the configuration value of
> > Node ID:0x1b should be 0x22214030.
>
> This is OK, but...
>
> > Additionally, I toggle the Auto-Mute Mode of Realtek codecs to “Speaker
> > Only” which makes signal outputs through line out jack when the "Line
> > Out" is chosen in the sound settings.
>
> ... this is a matter of taste, and I don't think it good to set a
> different default from others.  You can change it once and save it via
> alsactl.

The default state of Auto-Mute Mode of Realtek codec on this machine is
"Line Out + Speaker".
This disallows to output audio signal through the line out jack, even I already
choose the "Line Out" as the audio output device in the sound settings.
It means there is no way to use the line out jack in "Line Out + Speaker" state
of Auto-Mute Mode on this machine.

To enhance the user experience, especially the new one who first uses Linux,
changing this machine's Auto-Mute Mode to "Speaker Only" state, which allows
to output the audio signal through the line out jack, will be the better choice.

By the way, if the "Headphones" is chosen as the audio output device in the
sound settings, the audio signal will not output through the line out jack
automatically.

Therefore, I think this part of the quirk is still needed on this machine.

> And, the code to change this doesn't look good, either.  If any, it'd
> be easier to just set spec->gen.automute_speaker and
> spec->gen.automute_lo in the fixup with HDA_FIXUP_ACT_PROBE (that is
> performed after the parser call).

Oh!  This advice looks great and more directly!  I will try this.
Thanks for the suggestion.

Jian-Hong

> So, for now, I prefer having a change only touching the pinconfig.
> Care to resend the reduced one?
>
>
> thanks,
>
> Takashi
>
> >
> > Signed-off-by: Jian-Hong Pan 
> > ---
> >  sound/pci/hda/patch_realtek.c | 34 ++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index aef1f52db7d9..a066d84c6478 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -1810,6 +1810,8 @@ enum {
> >  

Re: [PATCH v8 0/4] Fix issues with huge mapping in ioremap for ARM64

[Marc Zyngier]

Hi Chintan,

On 03/04/18 09:00, Chintan Pandya wrote:
> This series of patches are follow up work (and depends on)
> Toshi Kani 's patches "fix memory leak/
> panic in ioremap huge pages".
> 
> This series of patches are tested on 4.9 kernel with Cortex-A75
> based SoC.

Given that this is targeting mainline, can you please test with 4.16?
Basing your patches on something that is over 15 months old is not
exactly reassuring.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] usb: dwc3: of-simple: use managed and shared reset control

[Philipp Zabel]

On Tue, 2018-04-03 at 17:30 +0900, Masahiro Yamada wrote:
> 2018-04-03 17:00 GMT+09:00 Philipp Zabel :
> > On Thu, 2018-03-29 at 15:07 +0900, Masahiro Yamada wrote:
> > > This driver handles the reset control in a common manner; deassert
> > > resets before use, assert them after use.  There is no good reason
> > > why it should be exclusive.
> > 
> > Is this preemptive cleanup, or do you have hardware on the horizon that
> > shares these reset lines with other peripherals?
> 
> This patch is necessary for Socionext SoCs.
> 
> The same reset lines are shared between
> this dwc3-of_simple and other glue circuits.

Thanks, this is helpful information.

> > > Also, use devm_ for clean-up.
> > > 
> > > Signed-off-by: Masahiro Yamada 
> > > ---
> > > 
> > > CCing Philipp Zabel.
> > > I see his sob in commit 06c47e6286d5.
> > 
> > At the time I was concerned with the reset_control_array addition and
> > didn't look closely at the exclusive vs shared issue.
> > >  drivers/usb/dwc3/dwc3-of-simple.c | 7 ++-
> > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
> > > b/drivers/usb/dwc3/dwc3-of-simple.c
> > > index e54c362..bd6ab65 100644
> > > --- a/drivers/usb/dwc3/dwc3-of-simple.c
> > > +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> > > @@ -91,7 +91,7 @@ static int dwc3_of_simple_probe(struct platform_device 
> > > *pdev)
> > >   platform_set_drvdata(pdev, simple);
> > >   simple->dev = dev;
> > > 
> > > - simple->resets = of_reset_control_array_get_optional_exclusive(np);
> > > + simple->resets = devm_reset_control_array_get_optional_shared(dev);
> > 
> > From the usage in the driver, it does indeed look like _shared reset
> > usage is appropriate. I assume that the hardware has no need for the
> > reset to be asserted right before probe or after remove, it just
> > requires that the reset line is kept deasserted while the driver is
> > probed.
> > 
> > >   if (IS_ERR(simple->resets)) {
> > >   ret = PTR_ERR(simple->resets);
> > >   dev_err(dev, "failed to get device resets, err=%d\n", ret);
> > > @@ -100,7 +100,7 @@ static int dwc3_of_simple_probe(struct 
> > > platform_device *pdev)
> > > 
> > >   ret = reset_control_deassert(simple->resets);
> > >   if (ret)
> > > - goto err_resetc_put;
> > > + return ret;
> > > 
> > >   ret = dwc3_of_simple_clk_init(simple, of_count_phandle_with_args(np,
> > >   "clocks", "#clock-cells"));
> > > @@ -126,8 +126,6 @@ static int dwc3_of_simple_probe(struct 
> > > platform_device *pdev)
> > >  err_resetc_assert:
> > >   reset_control_assert(simple->resets);
> > > 
> > > -err_resetc_put:
> > > - reset_control_put(simple->resets);
> > >   return ret;
> > >  }
> > > 
> > > @@ -146,7 +144,6 @@ static int dwc3_of_simple_remove(struct 
> > > platform_device *pdev)
> > >   simple->num_clocks = 0;
> > > 
> > >   reset_control_assert(simple->resets);
> > > - reset_control_put(simple->resets);
> > > 
> > >   pm_runtime_put_sync(dev);
> > >   pm_runtime_disable(dev);
> > 
> > Changing to devm_ changes the order here. Whether or not it could be a
> > problem to assert the reset only after pm_runtime_put (or potentially
> > never), I can't say. I assume this is a non-issue, but somebody who
> > knows the hardware better would have to decide.
> 
> 
> 
> I do not understand what you mean.

Sorry for the confusion, I have mixed up things here.

> Can you describe your concern in more details?
> 
> I am not touching reset_control_assert() here.

With the change to shared reset control, reset_control_assert
potentially does nothing, so it could be possible that
pm_runtime_put_sync cuts the power before the reset es asserted again.

> I am delaying the call for reset_control_put().

Yes, please disregard my comment about the devm_ change, that should
have no effect whatsoever and looks fine to me.

> If I understand reset_control_put() correctly,
> the effects of this change are:
>   - The ref_count and module ownership for the reset controller
> driver will be held a little longer
>   - The call for kfree() will be a little bit delayed.

Correct.

> Why do you need knowledge about this hardware?

Is it ok to keep the reset deasserted while the power is cut? Or do you
have to guarantee that drivers sharing the same reset also keep the same
power domains active?

regards
Philipp

Re: [PATCH v5 11/13] ARM: sun9i: smp: Add is_sun9i field

[Maxime Ripard]

On Tue, Apr 03, 2018 at 08:18:34AM +0200, Mylène Josserand wrote:
> To prepare the support of sun8i-a83t, add a field in the smp_data
> structure to enable the case of sun9i.
> 
> Start to handle the differences between sun9i-a80 and sun8i-a83t
> by using this variable.
>
> Add an index to retrieve which structures we are using.

This should have been in a separate commit, but maybe we can store a
pointer to the array cell we're using instead of always using the
index?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 2/2] reset: uniphier: add SATA reset control support and change SATA-PHY ID

[Philipp Zabel]

On Tue, 2018-04-03 at 17:35 +0900, Masahiro Yamada wrote:
> 2018-04-03 17:18 GMT+09:00 Philipp Zabel :
> > On Fri, 2018-03-30 at 18:44 +0900, Kunihiko Hayashi wrote:
> > > Add reset lines for SATA controller on UniPhier SoCs.
> > > This adds support for Pro4 and PXs3 in addition to PXs2.
> > > 
> > > And this changes the ID of the reset line for SATA-PHY on PXs2.
> > > Since some SoCs have two controller instances with a common PHY, this 
> > > moves
> > > the ID of SATA-PHY for consistency.
> > > 
> > > Signed-off-by: Kunihiko Hayashi 
> > > ---
> > >  drivers/reset/reset-uniphier.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/reset/reset-uniphier.c 
> > > b/drivers/reset/reset-uniphier.c
> > > index 55ae0f1..90e6caf 100644
> > > --- a/drivers/reset/reset-uniphier.c
> > > +++ b/drivers/reset/reset-uniphier.c
> > > @@ -63,6 +63,9 @@ static const struct uniphier_reset_data 
> > > uniphier_pro4_sys_reset_data[] = {
> > >   UNIPHIER_RESETX(12, 0x2000, 6), /* GIO (Ether, SATA, USB3) 
> > > */
> > >   UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
> > >   UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
> > > + UNIPHIER_RESETX(28, 0x2000, 18),/* SATA0 */
> > > + UNIPHIER_RESETX(29, 0x2004, 18),/* SATA1 */
> > > + UNIPHIER_RESETX(30, 0x2000, 19),/* SATA-PHY */
> > >   UNIPHIER_RESETX(40, 0x2000, 13),/* AIO */
> > >   UNIPHIER_RESET_END,
> > >  };
> > > @@ -90,7 +93,7 @@ static const struct uniphier_reset_data 
> > > uniphier_pxs2_sys_reset_data[] = {
> > >   UNIPHIER_RESETX(20, 0x2014, 5), /* USB31-PHY0 */
> > >   UNIPHIER_RESETX(21, 0x2014, 1), /* USB31-PHY1 */
> > >   UNIPHIER_RESETX(28, 0x2014, 12),/* SATA */
> > > - UNIPHIER_RESET(29, 0x2014, 8),  /* SATA-PHY (active high) */
> > > + UNIPHIER_RESET(30, 0x2014, 8),  /* SATA-PHY (active high) */
> > 
> > This is a backwards incompatible change.
> > There is no DT in use that relies on this being 29 ?
> 
> 
> Right.  No user for this reset line ever.

Thank you, I have applied both patches to reset/next.

regards
Philipp

Re: [PATCH v5 10/13] ARM: sun9i: smp: Move structures

[Maxime Ripard]

On Tue, Apr 03, 2018 at 08:18:33AM +0200, Mylène Josserand wrote:
> To prepare the support for sun8i-a83t, move some structures
> at the beginning of the file.
> 
> Signed-off-by: Mylène Josserand 

I'm not quite sure what would be the benefit from that, if it's was
working before, then it would probably work in your case as welle, right?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v5 12/13] ARM: sun8i: smp: Add support for A83T

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 2:18 PM, Mylène Josserand
 wrote:
> Add the support for A83T.
>
> A83T SoC has an additional register than A80 to handle CPU configurations:
> R_CPUS_CFG. Information about the register comes from Allwinner's BSP
> driver.
> An important difference is the Power Off Gating register for clusters
> which is BIT(4) in case of SUN9I-A80 and BIT(0) in case of SUN8I-A83T.
> There is also a bit swap between sun8i-a83t and sun9i-a80 that must be
> handled.
>
> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/mach-sunxi/mc_smp.c | 120 
> +--
>  1 file changed, 117 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> index 468a6c46bfc9..72e497dc43ac 100644
> --- a/arch/arm/mach-sunxi/mc_smp.c
> +++ b/arch/arm/mach-sunxi/mc_smp.c
> @@ -55,22 +55,31 @@
>  #define CPUCFG_CX_RST_CTRL_L2_RST  BIT(8)
>  #define CPUCFG_CX_RST_CTRL_CX_RST(n)   BIT(4 + (n))
>  #define CPUCFG_CX_RST_CTRL_CORE_RST(n) BIT(n)
> +#define CPUCFG_CX_RST_CTRL_CORE_RST_ALL(0xf << 0)
>
>  #define PRCM_CPU_PO_RST_CTRL(c)(0x4 + 0x4 * (c))
>  #define PRCM_CPU_PO_RST_CTRL_CORE(n)   BIT(n)
>  #define PRCM_CPU_PO_RST_CTRL_CORE_ALL  0xf
>  #define PRCM_PWROFF_GATING_REG(c)  (0x100 + 0x4 * (c))
> +/* The power off register for clusters are different from a80 and a83t */
> +#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN8I   BIT(0)
>  #define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
>  #define PRCM_PWROFF_GATING_REG_CORE(n) BIT(n)
>  #define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
>  #define PRCM_CPU_SOFT_ENTRY_REG0x164
>
> +/* R_CPUCFG registers, specific to SUN8I */

You should mention it as A83T specific, since sun8i covers the
entire Cortex-A7-based SoC family.

> +#define R_CPUCFG_CLUSTER_PO_RST_CTRL(c)(0x30 + (c) * 0x4)
> +#define R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(n)   BIT(n)
> +#define R_CPUCFG_CPU_SOFT_ENTRY_REG0x01a4
> +
>  #define CPU0_SUPPORT_HOTPLUG_MAGIC00xFA50392F
>  #define CPU0_SUPPORT_HOTPLUG_MAGIC10x790DCA3A
>
>  static void __iomem *cpucfg_base;
>  static void __iomem *prcm_base;
>  static void __iomem *sram_b_smp_base;
> +static void __iomem *r_cpucfg_base;
>  static int index;
>
>  /*
> @@ -81,6 +90,7 @@ struct sunxi_mc_smp_nodes {
> struct device_node *prcm_node;
> struct device_node *cpucfg_node;
> struct device_node *sram_node;
> +   struct device_node *r_cpucfg_node;
>  };
>
>  /* This structure holds SoC-specific bits tied to an enable-method string. */
> @@ -94,6 +104,7 @@ extern void sunxi_mc_smp_secondary_startup(void);
>  extern void sunxi_mc_smp_resume(void);
>
>  static int __init sun9i_a80_get_smp_nodes(struct sunxi_mc_smp_nodes *nodes);
> +static int __init sun8i_a83t_get_smp_nodes(struct sunxi_mc_smp_nodes *nodes);
>
>  static const struct sunxi_mc_smp_data sunxi_mc_smp_data[] __initconst = {
> {
> @@ -101,6 +112,11 @@ static const struct sunxi_mc_smp_data 
> sunxi_mc_smp_data[] __initconst = {
> .get_smp_nodes  = sun9i_a80_get_smp_nodes,
> .is_sun9i   = true,
> },
> +   {
> +   .enable_method  = "allwinner,sun8i-a83t-smp",
> +   .get_smp_nodes  = sun8i_a83t_get_smp_nodes,
> +   .is_sun9i   = false,
> +   },
>  };
>
>  static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
> @@ -188,6 +204,16 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
> int cluster)
> reg &= ~PRCM_CPU_PO_RST_CTRL_CORE(cpu);
> writel(reg, prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
>
> +   if (r_cpucfg_base) {

Please check against is_sun9i, since this is A83T specific. My point
is we should be able to see clearly what parts of the code are shared,
and what parts are SoC specific.

> +   /* assert cpu power-on reset */
> +   reg  = readl(r_cpucfg_base +
> +R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
> +   reg &= ~(R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(cpu));
> +   writel(reg, r_cpucfg_base +
> +  R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
> +   udelay(10);
> +   }
> +
> /* Cortex-A7: hold L1 reset disable signal low */
> if (!sunxi_core_is_cortex_a15(cpu, cluster)) {
> reg = readl(cpucfg_base + CPUCFG_CX_CTRL_REG0(cluster));
> @@ -211,17 +237,38 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
> int cluster)
> /* open power switch */
> sunxi_cpu_power_switch_set(cpu, cluster, true);
>
> +   /* Handle A83T bit swap */
> +   if (!sunxi_mc_smp_data[index].is_sun9i) {
> +   if (cpu == 0)
> +   cpu = 4;
> +   }
> +
> /* clear processor power gate */
> reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> reg &= ~PRCM_PWROFF_GATING_RE

Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

[Pavel Machek]

Hi!

> > On Tue, 20 Mar 2018, Ingo Molnar wrote:
> > > * Thomas Gleixner  wrote:
> > > 
> > > > > So I do think we could do more in this area to improve driver 
> > > > > performance, if the 
> > > > > code is correct and if there's actual benchmarks that are showing 
> > > > > real benefits.
> > > > 
> > > > If it's about hotpath performance I'm all for it, but the use case here 
> > > > is
> > > > a debug facility...
> > > > 
> > > > And if we go down that road then we want a AVX based memcpy()
> > > > implementation which is runtime conditional on the feature bit(s) and
> > > > length dependent. Just slapping a readqq() at it and use it in a loop 
> > > > does
> > > > not make any sense.
> > > 
> > > Yeah, so generic memcpy() replacement is only feasible I think if the 
> > > most 
> > > optimistic implementation is actually correct:
> > > 
> > >  - if no preempt disable()/enable() is required
> > > 
> > >  - if direct access to the AVX[2] registers does not disturb legacy FPU 
> > > state in 
> > >any fashion
> > > 
> > >  - if direct access to the AVX[2] registers cannot raise weird exceptions 
> > > or have
> > >weird behavior if the FPU control word is modified to non-standard 
> > > values by 
> > >untrusted user-space
> > > 
> > > If we have to touch the FPU tag or control words then it's probably only 
> > > good for 
> > > a specialized API.
> > 
> > I did not mean to have a general memcpy replacement. Rather something like
> > magic_memcpy() which falls back to memcpy when AVX is not usable or the
> > length does not justify the AVX stuff at all.
> 
> OK, fair enough.
> 
> Note that a generic version might still be worth trying out, if and only if 
> it's 
> safe to access those vector registers directly: modern x86 CPUs will do their 
> non-constant memcpy()s via the common memcpy_erms() function - which could in 
> theory be an easy common point to be (cpufeatures-) patched to an AVX2 
> variant, if 
> size (and alignment, perhaps) is a multiple of 32 bytes or so.

How is AVX2 supposed to help the memcpy speed?

If the copy is small, constant overhead will dominate, and I don't
think AVX2 is going to be win there.

If the copy is big, well, the copy loop will likely run out of L1 and
maybe even out of L2, and at that point speed of the loop does not
matter because memory is slow...?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v5 11/13] ARM: sun9i: smp: Add is_sun9i field

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 4:46 PM, Maxime Ripard  wrote:
> On Tue, Apr 03, 2018 at 08:18:34AM +0200, Mylène Josserand wrote:
>> To prepare the support of sun8i-a83t, add a field in the smp_data
>> structure to enable the case of sun9i.
>>
>> Start to handle the differences between sun9i-a80 and sun8i-a83t
>> by using this variable.
>>
>> Add an index to retrieve which structures we are using.
>
> This should have been in a separate commit, but maybe we can store a
> pointer to the array cell we're using instead of always using the
> index?

Using a pointer would also avoid some of the code movement from the
previous patch.

ChenYu

Re: general protection fault in try_to_wake_up

[Petr Mladek]

On Thu 2018-03-29 09:01:02, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> bcfc1f4554662d8f2429ac8bd96064a59c149754 (Sat Mar 24 16:50:12 2018 +)
> Merge tag 'pinctrl-v4.16-3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=d1fe9b7b917f2715c7d4
> 
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=4649457446551552
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=4909621332410368
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d1fe9b7b917f2715c...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> IPVS: ftp: loaded support on port[0] = 21
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN

This is already 2nd level fault. I wonder if KASAN or lockdep should
have already been disabled at this point. Adding some more people
into CC.


> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4170 Comm: syz-executor0 Not tainted 4.16.0-rc6+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__lock_acquire+0x209/0x3e00 kernel/locking/lockdep.c:3320
> RSP: 0018:8801db206f60 EFLAGS: 00010002
> RAX: 078e0401078e0401 RBX:  RCX: 
> RDX: 1100389fe583 RSI:  RDI: 8801c4ff2c18
> RBP: 8801db2072f0 R08: 814d839c R09: 0001
> R10:  R11: 8801c4ff2c10 R12: 
> R13: 0001 R14:  R15: 8801b793c440
> FS:  014fa940() GS:8801db20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 004cb4e0 CR3: 0001b7980002 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>  _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>  try_to_wake_up+0xbc/0x15f0 kernel/sched/core.c:1989
>  default_wake_function+0x30/0x50 kernel/sched/core.c:3693
>  autoremove_wake_function+0x78/0x350 kernel/sched/wait.c:377
>  __wake_up_common+0x18e/0x780 kernel/sched/wait.c:97
>  __wake_up_common_lock+0x1b4/0x310 kernel/sched/wait.c:125
>  __wake_up+0xe/0x10 kernel/sched/wait.c:149
>  wake_up_klogd_work_func+0x4a/0x70 kernel/printk/printk.c:2869
>  irq_work_run_list+0x184/0x240 kernel/irq_work.c:155
>  irq_work_tick+0x136/0x1a0 kernel/irq_work.c:181
>  update_process_times+0x48/0x60 kernel/time/timer.c:1639
>  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>  __run_hrtimer kernel/time/hrtimer.c:1349 [inline]
>  __hrtimer_run_queues+0x39c/0xec0 kernel/time/hrtimer.c:1411
>  hrtimer_interrupt+0x2a5/0x6f0 kernel/time/hrtimer.c:1469
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:857
>  
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:778
> [inline]
> RIP: 0010:console_unlock+0xb18/0xfb0 kernel/printk/printk.c:2403
> RSP: 0018:8801b79068d8 EFLAGS: 0293 ORIG_RAX: ff12
> RAX: 8801b793c440 RBX: 0200 RCX: 815a8d6f
> RDX:  RSI: 110036f279af RDI: 0293
> RBP: 8801b7906a40 R08: 110036f20ce9 R09: 
> R10:  R11:  R12: 
> R13:  R14: 83ba15e0 R15: dc00
>  vprintk_emit+0x5c3/0xb90 kernel/printk/printk.c:1907

raw_spin_lock() succeeded here. Therefore lockdep was still working
at this stage.

>  vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
>  vprintk_func+0x57/0xc0 kernel/printk/printk_safe.c:379
>  printk+0xaa/0xca kernel/printk/printk.c:1980
>  kasan_die_handler+0x3d/0x3f arch/x86/mm/kasan_init_64.c:248
>  notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
>  __atomic_notifier_call_chain kernel/notifier.c:183 [inline]
>  atomic_notifier_call_chain+0x77/0x140 kernel/notifier.c:193
>  notify_die+0x18c/0x280 kernel/notifier.c:549

It must have been general protection fault as well.

Best Regards,
Petr

>  do_general_protection+0x3

Re: [PATCHv6 1/2] dt-bindings: mfd: motorola-cpcap: document audio-codec

[Pavel Machek]

On Fri 2018-03-30 14:58:23, Sebastian Reichel wrote:
> This adds the DT binding for the audio-codec sub-module found
> inside the Motorola CPCAP PMIC.
> 
> Acked-by: Mark Brown 
> Acked-by: Tony Lindgren 
> Reviewed-by: Rob Herring 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Nicolas Ferre]

On 31/03/2018 at 10:54, Alexandre Belloni wrote:

On 30/03/2018 at 16:44:20 +0100, Colin King wrote:

From: Colin Ian King 

Trivial fix to spelling mistake in pr_debug message text


Acked-by: Alexandre Belloni 


Acked-by: Nicolas Ferre 

Signed-off-by: Colin Ian King 
---
  sound/soc/atmel/atmel_ssc_dai.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index a1e2c5682dcd..1c7af0ca98ec 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -820,7 +820,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
if (ret < 0) {
printk(KERN_WARNING
"atmel_ssc_dai: request_irq failure\n");
-   pr_debug("Atmel_ssc_dai: Stoping clock\n");
+   pr_debug("Atmel_ssc_dai: Stopping clock\n");
clk_disable(ssc_p->ssc->clk);
return ret;
}
--
2.15.1






--
Nicolas Ferre

Re: [PATCH 3/4] mm: Add free()

[Pavel Machek]

Hi!

> > And sure, your free() implementation obviously also has that property,
> > but I'm worried that they might one day decide to warn about the
> > prototype mismatch (actually, I'm surprised it doesn't warn now, given
> > that it obviously pretends to know what free() function I'm calling...),
> > or make some crazy optimization that will break stuff in very subtle ways.
> > 
> > Also, we probably don't want people starting to use free() (or whatever
> > name is chosen) if they do know the kind of memory they're freeing?
> > Maybe it should not be advertised that widely (i.e., in kernel.h).
> 
> All that you've said I see as an advantage, not a disadvantage.
> Maybe I should change the prototype to match the userspace
> free(), although gcc is deliberately lax about the constness of
> function arguments when determining compatibility with builtins.
> See match_builtin_function_types() if you're really curious.
> 
> gcc already does some nice optimisations around free().  For example, it
> can eliminate dead stores:

Are we comfortable with that optimalization for kernel?

us: "Hey, let's remove those encryption keys before freeing memory."
gcc: :-).

us: "Hey, we want to erase lock magic values not to cause confusion
later."
gcc: "I like confusion!"

Yes, these probably can be fixed by strategic "volatile" and/or
barriers, but...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

linux-next on x60: hangs when I request suspend was Re: linux-next on x60: network manager often complains "network is disabled" after resume

[Pavel Machek]

Hi!

I wanted to re-test next (4.16.0-rc7-next-20180329), but that one does
not suspend at all.

I normally suspend by pressing power button in MATE, but that action
currently results in machine hanging.

Pavel


On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > > 
> > > > Broken state.
> > > > 
> > > > pavel@amd:~$ nmcli dev
> > > > DEVICE  TYPE  STATECONNECTION
> > > > eth1ethernet  unavailable  --
> > > > lo  loopback  unmanaged--
> > > > wlan0   wifi  unmanaged--
> > > 
> > > If the state is "unmanaged" on resume, that would indicate a
> > > problem
> > > with sleep/wake and likely not a kernel network device issue.
> > > 
> > > We should probably move this discussion to the NM lists to debug
> > > further.  Before you suspend, run "nmcli gen log level trace" to
> > > turn
> > > on full debug logging, then reproduce the issue, and send a pointer
> > > to
> > > those logs (scrubbed for anything you consider sensitive) to the NM
> > > mailing list.
> > 
> > Hmm :-)
> > 
> > root@amd:/data/pavel# nmcli gen log level trace
> > Error: Unknown log level 'trace'
> 
> What NM version?  'trace' is pretty old (since 1.0 from December 2014)
> so unless you're using a really, really old version of Debian I'd
> expect you'd have it.  Anyway, debug would do.
> 
> > root@amd:/data/pavel# nmcli gen log level help
> > Error: Unknown log level 'help'
> 
> nmcli gen help
> 
> > root@amd:/data/pavel# nmcli gen log level
> > Error: value for 'level' argument is required.
> > root@amd:/data/pavel# nmcli gen log level debug
> 
> This should be OK.
> 
> > root@amd:/data/pavel# cat /var/log/sys/log
> 
> It routes it to whatever the syslog 'daemon' facility logs to (however
> that's configured on your system).  Usually /var/log/messages or
> /var/log/daemon.log or sometimes your distro configures it to
> /var/log/NetworkManager.log.
> 
> Or if you're using a systemd-based distro, it would probably be in the
> systemd journal so "journalctl -b -u NetworkManager"
> 
> > Where do I get the logs? I don't see much in the syslog...
> 
> > And.. It seems that it is "every other suspend". One resume results
> > in
> > broken network, one in working one, one in broken one...
> 
> Does your distro use pm-utils, upower, or systemd for suspend/resume
> handling?
> 
> Dan

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v5 10/13] ARM: sun9i: smp: Move structures

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 4:47 PM, Maxime Ripard  wrote:
> On Tue, Apr 03, 2018 at 08:18:33AM +0200, Mylène Josserand wrote:
>> To prepare the support for sun8i-a83t, move some structures
>> at the beginning of the file.
>>
>> Signed-off-by: Mylène Josserand 
>
> I'm not quite sure what would be the benefit from that, if it's was
> working before, then it would probably work in your case as welle, right?

You should only need to move struct sunxi_mc_smp_data, since you are reading
the is_sun9i field. I suppose you could also get away with adding a global
variable just for that, and not have to store an index or pointer. Then none
of this code movement would be necessary. It would be slightly harder to
understand, but it's still contained within this file, and it has a clear
purpose, so I would call that acceptable.

ChenYu

Re: Regression caused by commit bc976233a872, ethernet r8169 stops working after system S3

[Thomas Gleixner]

On Sat, 31 Mar 2018, Kai-Heng Feng wrote:
> Thomas Gleixner  wrote:
> 
> > On Sat, 31 Mar 2018, Kai-Heng Feng wrote:
> > > A user reported [1] that the Realtek ethernet r8169 stops working after S3
> > > since v4.15-rc6. The issue still exists in Linus' tree:
> > > 
> > > [ 150.877998] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
> > > [ 150.944101] do_IRQ: 3.37 No irq handler for vector
> > > [ 150.944105] r8169 :01:00.0 enp1s0: link down
> > > [ 150.944180] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
> > > 
> > > My desktop also has this device, which is also affected by this
> > > regression. So
> > > I did a bisect, and this is the bad commit:
> > > bc976233a872 genirq/msi x86/vector: Prevent reservation mode for non
> > > maskable
> > > MSI
> > > 
> > > After this commit gets reverted, the issue is gone.
> > 
> > Sigh. Can you please apply the debug patch below and provide the output of
> > 
> > # cat /proc/interrupts
> > 
> > and full dmesg after resume.
> 
> Weird. I don't see this issue with this debug patch.

Bah. The patch is broken. New version written with brain awake below.

Thanks,

tglx

8<-
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -134,6 +134,10 @@ static bool migrate_one_irq(struct irq_d
brokeaff = false;
}
 
+   pr_info("IRQ%u: New affinity: %*pbl effective: %*pbl\n",
+   d->irq, cpumask_pr_args(affinity),
+   cpumask_pr_args(irq_data_get_effective_affinity_mask(d)));
+
if (maskchip && chip->irq_unmask)
chip->irq_unmask(d);
 

Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Pavel Machek]

Hi!

> > I think I should have the required options enabled... 
> > 
> > CONFIG_SND_OMAP_SOC=y
> > CONFIG_SND_OMAP_SOC_DMIC=y
> > CONFIG_SND_OMAP_SOC_MCBSP=y
> > CONFIG_SND_OMAP_SOC_MCPDM=y
> > CONFIG_SND_OMAP_SOC_HDMI_AUDIO=y
> 
> That's the SoC (OMAP) side.
> 
> > # CONFIG_SND_OMAP_SOC_RX51 is not set
> > # CONFIG_SND_OMAP_SOC_N9 is not set
> > CONFIG_SND_OMAP_SOC_OMAP_TWL4030=y
> > CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=y
> 
> That's not needed (but does not hurt). The Droid 4
> has no TWL companion chip and uses CPCAP instead.

Umm. AFAICT CONFIG_SND_OMAP_SOC_MCBSP=y can not be selected without
selecting one of the other options... right?

Seems like bug in Kconfig.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 2/4] clk: qcom: Configure the RCGs to a safe source as needed

[Amit Nischal]

On 2018-03-20 06:00, Stephen Boyd wrote:

Quoting Amit Nischal (2018-03-07 23:18:13)
For some root clock generators, there could be child branches which 
are
controlled by an entity other than application processor subsystem. 
For
such RCGs, as per application processor subsystem clock driver, all of 
its
downstream clocks are disabled and RCG is in disabled state but in 
actual

downstream clocks can be left enabled before.


s/actual/reality?

Thanks for the review. I will address this in next patch series.





So in this scenario, when RCG is disabled as per clock driver's point 
of
view and when rate scaling request comes before downstream clock 
enable
request, then RCG fails to update its configuration because in actual 
RCG


s/actual/reality?


I will address this in next patch series.


is on and it expects its new source to alredy in enable state  but in


s/alredy/already be/

I will address this in next patch series.



reality new source is in off state. In order to avoid letting the RCG 
to


s/is in off state/is off/
s/letting/having/

I will address this in next patch series.



go into an invalid state, add support to just cache the rate of RCG 
during


s/just//

I will address this in next patch series.




set_rate(), defer actual RCG configuration update to be done during
clk_enable() as at this point of time, both its new parent and safe 
source

will be already enabled and RCG can safely switch to new parent.

During clk_disable() request, configure it to safe source as both
its parents, safe source and current parent will be enabled and RCG 
can

safely execute a switch. Also add support to have safe configuration
frequency table structure for each shared RCG.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 2a7489a..205fa34 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -146,6 +146,9 @@ struct clk_dyn_rcg {
  * @hid_width: number of bits in half integer divider
  * @parent_map: map from software's parent index to hardware's 
src_sel field

  * @freq_tbl: frequency table
+ * @current_freq: last cached frequency when using branches with 
shared RCGs
+ * @safe_src_freq_tbl : frequency table of safe source when using 
branches

+ * with shared RCGs
  * @clkr: regmap clock handle
  *
  */
@@ -155,6 +158,8 @@ struct clk_rcg2 {
u8  hid_width;
const struct parent_map *parent_map;
const struct freq_tbl   *freq_tbl;
+   unsigned long   current_freq;
+   const struct freq_tbl   *safe_src_freq_tbl;


Can we store safe_src index instead? And then construct the frequency
table entry on the fly at the call site? I think it would greatly
clarify that we don't really care about the rate of the clk at all.
Instead, all we care about is making sure the mux is set to whatever
source selection can provide an always on signal.


We will address the above in the V3 series of the patch set. We will be
generating the safe frequency table on the fly taking the safe source
frequency index input from the RCG clock.


struct clk_regmap   clkr;
 };

@@ -167,5 +172,6 @@ struct clk_rcg2 {
 extern const struct clk_ops clk_byte2_ops;
 extern const struct clk_ops clk_pixel_ops;
 extern const struct clk_ops clk_gfx3d_ops;
+extern const struct clk_ops clk_rcg2_shared_ops;

 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index e63db10..a52de54 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -790,3 +790,158 @@ static int clk_gfx3d_set_rate(struct clk_hw *hw, 
unsigned long rate,

.determine_rate = clk_gfx3d_determine_rate,
 };
+
+static unsigned long
+clk_rcg2_shared_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)

+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+
+   if (!__clk_is_enabled(hw->clk)) {
+   if (!rcg->current_freq) {
+   if (!clk_rcg2_get_parent(hw))


This is checking for 0 source selection of parent? So basically if
source is XO selected then return what we know is the XO speed? We
should be able to do that by returning parent_rate though?


+   rcg->current_freq =
+   rcg->safe_src_freq_tbl->freq;
+   else
+   rcg->current_freq =
+   clk_rcg2_recalc_rate(hw, 
parent_rate);

+   }
+
+   return rcg->current_freq;
+   }
+
+   return rcg->current_freq = clk_rcg2_recalc_rate(hw, 
parent_rate);


I don't get this function.

To simplify just return cached rate if it's set and clk is off,
otherwise read the hardware?

if (!__clk_is_enabled(hw->clk) && rcg->current_freq)
return rcg->current_freq;

return clk_rcg2_recalc_rate(hw, parent_rate);

I would also rename current_freq to so

Re: [PATCH v4 3/3] MIPS: use generic GCC library routines from lib/

[James Hogan]

On Thu, Mar 29, 2018 at 11:41:23AM +0100, Matt Redfearn wrote:
> This commit removes several generic GCC library routines from
> arch/mips/lib/ in favour of similar routines from lib/.

> diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
> index e84e12655fa8..6537e022ef62 100644
> --- a/arch/mips/lib/Makefile
> +++ b/arch/mips/lib/Makefile
> @@ -16,5 +16,4 @@ obj-$(CONFIG_CPU_R3000) += r3k_dump_tlb.o
>  obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o
>  
>  # libgcc-style stuff needed in the kernel
> -obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o 
> \
> -  ucmpdi2.o
> +obj-y += bswapsi.o bswapdi.o multi3.o

Have you missed deleting the files?

Cheers
James


signature.asc
Description: Digital signature

Re: general protection fault in try_to_wake_up

[Petr Mladek]

On Tue 2018-04-03 10:50:02, Petr Mladek wrote:
> On Thu 2018-03-29 09:01:02, syzbot wrote:
> > Hello,
> > 
> > syzbot hit the following crash on upstream commit
> > bcfc1f4554662d8f2429ac8bd96064a59c149754 (Sat Mar 24 16:50:12 2018 +)
> > Merge tag 'pinctrl-v4.16-3' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=d1fe9b7b917f2715c7d4
> > 
> > syzkaller reproducer:
> > https://syzkaller.appspot.com/x/repro.syz?id=4649457446551552
> > Raw console output:
> > https://syzkaller.appspot.com/x/log.txt?id=4909621332410368
> > Kernel config:
> > https://syzkaller.appspot.com/x/.config?id=-5034017172441945317
> > compiler: gcc (GCC) 7.1.1 20170620
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+d1fe9b7b917f2715c...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > IPVS: ftp: loaded support on port[0] = 21
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault:  [#1] SMP KASAN
> 
> This is already 2nd level fault. I wonder if KASAN or lockdep should
> have already been disabled at this point. Adding some more people
> into CC.

Ah, there seem to be more related reports, see
https://lkml.kernel.org/r/CACT4Y+ZJ2QD7MPy4hB-M=mz2LuVu3bRbLg1QdY=z=+su1qw...@mail.gmail.com

I am sorry for the noise. My mail client did not put the other replies
in a single thread from some reasons.

Best Regards,
Petr

> 
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > Modules linked in:
> > CPU: 0 PID: 4170 Comm: syz-executor0 Not tainted 4.16.0-rc6+ #1
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:__lock_acquire+0x209/0x3e00 kernel/locking/lockdep.c:3320
> > RSP: 0018:8801db206f60 EFLAGS: 00010002
> > RAX: 078e0401078e0401 RBX:  RCX: 
> > RDX: 1100389fe583 RSI:  RDI: 8801c4ff2c18
> > RBP: 8801db2072f0 R08: 814d839c R09: 0001
> > R10:  R11: 8801c4ff2c10 R12: 
> > R13: 0001 R14:  R15: 8801b793c440
> > FS:  014fa940() GS:8801db20() knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2: 004cb4e0 CR3: 0001b7980002 CR4: 001606f0
> > DR0:  DR1:  DR2: 
> > DR3:  DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >  
> >  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
> >  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> >  _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
> >  try_to_wake_up+0xbc/0x15f0 kernel/sched/core.c:1989
> >  default_wake_function+0x30/0x50 kernel/sched/core.c:3693
> >  autoremove_wake_function+0x78/0x350 kernel/sched/wait.c:377
> >  __wake_up_common+0x18e/0x780 kernel/sched/wait.c:97
> >  __wake_up_common_lock+0x1b4/0x310 kernel/sched/wait.c:125
> >  __wake_up+0xe/0x10 kernel/sched/wait.c:149
> >  wake_up_klogd_work_func+0x4a/0x70 kernel/printk/printk.c:2869
> >  irq_work_run_list+0x184/0x240 kernel/irq_work.c:155
> >  irq_work_tick+0x136/0x1a0 kernel/irq_work.c:181
> >  update_process_times+0x48/0x60 kernel/time/timer.c:1639
> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
> >  __run_hrtimer kernel/time/hrtimer.c:1349 [inline]
> >  __hrtimer_run_queues+0x39c/0xec0 kernel/time/hrtimer.c:1411
> >  hrtimer_interrupt+0x2a5/0x6f0 kernel/time/hrtimer.c:1469
> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
> >  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:857
> >  
> > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:778
> > [inline]
> > RIP: 0010:console_unlock+0xb18/0xfb0 kernel/printk/printk.c:2403
> > RSP: 0018:8801b79068d8 EFLAGS: 0293 ORIG_RAX: ff12
> > RAX: 8801b793c440 RBX: 0200 RCX: 815a8d6f
> > RDX:  RSI: 110036f279af RDI: 0293
> > RBP: 8801b7906a40 R08: 110036f20ce9 R09: 
> > R10:  R11:  R12: 
> > R13:  R14: 83ba15e0 R15: dc00
> >  vprintk_emit+0x5c3/0xb90 kernel/printk/printk.c:1907
> 
> raw_spin_lock() succeeded here. Therefore lockdep was still working
> at this stage.
> 
> >  vprintk_default+0x28/0x30 kernel/printk/printk.c:1947

Re: [GIT PULL] x86/build changes for v4.17

[Peter Zijlstra]

On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote:
> On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar  wrote:
> >
> > The biggest change is the forcing of asm-goto support on x86, which 
> > effectively
> > increases the GCC minimum supported version to gcc-4.5 (on x86).
> 
> So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves
> to be forced, or can stay with old kernels).
> 
> No, my biggest worry is clang. What's the status there?
> 
> I've pulled this, and honestly, the disaster with
> -fmerge-all-constants makes me think that clang isn't that good a
> compiler choice anyway, but it's sad if this undoes a lot of clang
> work just because of the worries about Spectre and mis-speculated
> branches.

It's not just spectre, I believe you yourself wanted to use asm-goto
somewhere in the x86 code:

  
http://lkml.kernel.org/r/CA+55aFyCp-9Qqjcn9wp=vdp2ko7tfyuumjxvkc75xxu0web...@mail.gmail.com

There was some KVM talk of relying on it here:

  http://lkml.kernel.org/r/6a5f2453-cf51-d491-db54-5f239caa2...@redhat.com

And there's the comment here:

  https://elixir.bootlin.com/linux/v4.16-rc7/source/arch/x86/kvm/emulate.c#L457

As to the suitablility of using clang, there's also this unresolved
issue:

  http://lkml.kernel.org/r/20180321211931.ga111...@google.com

The fact that even without asm-goto they cannot correctly compile a
kernel and have sat on their hands regarding asm-goto for the past 7 odd
years makes me care very little.

And since they need to spin a new version of the compiler with all the
various bugs fixed, they might as well include asm-goto in that and be
done with it.

[PATCH] fs: ufs: Convert ufs_set_de_type to use lookup table

[Phillip Potter]

Modify ufs_set_de_type function in fs/ufs/util.h to use a lookup
table rather than a switch statement, as per the TODO comment.

Signed-off-by: Phillip Potter 
---
 fs/ufs/util.h | 50 ++
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 1907be6d5808..1edf4c6454e3 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -155,37 +155,31 @@ ufs_set_de_namlen(struct super_block *sb, struct 
ufs_dir_entry *de, u16 value)
 static inline void
 ufs_set_de_type(struct super_block *sb, struct ufs_dir_entry *de, int mode)
 {
+   /* type lookup table, DT_UNKNOWN is default type if no case holds */
+   const int mode_table[] = {
+   DT_UNKNOWN,
+   DT_FIFO,/* mode & S_IFMT == S_IFIFO case */
+   DT_CHR, /* mode & S_IFMT == S_IFCHR case */
+   DT_UNKNOWN,
+   DT_DIR, /* mode & S_IFMT == S_IFDIR case */
+   DT_UNKNOWN,
+   DT_BLK, /* mode & S_IFMT == S_IFBLK case */
+   DT_UNKNOWN,
+   DT_REG, /* mode & S_IFMT == S_IFREG case */
+   DT_UNKNOWN,
+   DT_LNK, /* mode & S_IFMT == S_IFLNK case */
+   DT_UNKNOWN,
+   DT_SOCK,/* mode & S_IFMT == S_IFSOCK case */
+   DT_UNKNOWN,
+   DT_UNKNOWN,
+   DT_UNKNOWN
+   };
+
if ((UFS_SB(sb)->s_flags & UFS_DE_MASK) != UFS_DE_44BSD)
return;
 
-   /*
-* TODO turn this into a table lookup
-*/
-   switch (mode & S_IFMT) {
-   case S_IFSOCK:
-   de->d_u.d_44.d_type = DT_SOCK;
-   break;
-   case S_IFLNK:
-   de->d_u.d_44.d_type = DT_LNK;
-   break;
-   case S_IFREG:
-   de->d_u.d_44.d_type = DT_REG;
-   break;
-   case S_IFBLK:
-   de->d_u.d_44.d_type = DT_BLK;
-   break;
-   case S_IFDIR:
-   de->d_u.d_44.d_type = DT_DIR;
-   break;
-   case S_IFCHR:
-   de->d_u.d_44.d_type = DT_CHR;
-   break;
-   case S_IFIFO:
-   de->d_u.d_44.d_type = DT_FIFO;
-   break;
-   default:
-   de->d_u.d_44.d_type = DT_UNKNOWN;
-   }
+   /* shift (mode & S_IFMT) right 12 bits to index into table */
+   de->d_u.d_44.d_type = mode_table[(mode & S_IFMT) >> 12];
 }
 
 static inline u32
-- 
2.14.3

Re: [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA

[Takashi Iwai]

On Tue, 03 Apr 2018 10:43:02 +0200,
Jian-Hong Pan wrote:
> 
> 2018-04-02 19:29 GMT+08:00 Takashi Iwai :
> >
> > On Mon, 02 Apr 2018 09:33:13 +0200,
> > Jian-Hong Pan wrote:
> > >
> > > This ASUS D640SA desktop whose mother board is D640MB has
> > > - two jacks which are a headphone and a mic on the front panel,
> > > - three jacks which are a mic, a line out and a line in on the rear panel
> > > - one internal speaker.
> > >
> > > If I plug a headphone to the front headphone jack, there will be sound
> > > through the headphone jack, and no sound through the internal speaker.
> > > If I unplug the headphone from the the headphone jack, there will be
> > > sound through the internal speaker.  And always no sound through rear
> > > line out, when I plug a headphone or an externel speaker to the rear
> > > line out jack.
> > >
> > > Besides, I had checked and toggled the Auto-Mute Mode in alsamixer, but
> > > the rear line out still was not working.  Then I checked the sound
> > > settings in GUI, and found there was no "Line Out" could be chosen, only
> > > the "Headphones" and "HDMI/DisplayPort".
> > > However, system does know that there is an "Intel PCH Line Out".
> > >
> > > [   10.089082] snd_hda_codec_realtek hdaudioC0D0: autoconfig for
> > > ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
> > > [   10.089083] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1
> > > (0x1a/0x0/0x0/0x0/0x0)
> > > [   10.089084] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1
> > > (0x1b/0x0/0x0/0x0/0x0)
> > > [   10.089085] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
> > > [   10.089086] snd_hda_codec_realtek hdaudioC0D0:inputs:
> > > [   10.089087] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
> > > [   10.089088] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
> > > [   10.089089] snd_hda_codec_realtek hdaudioC0D0:  Line=0x15
> > > [   10.104387] input: HDA Intel PCH Rear Mic as
> > > /devices/pci:00/:00:1f.3/sound/card0/input9
> > > [   10.104416] input: HDA Intel PCH Front Mic as
> > > /devices/pci:00/:00:1f.3/sound/card0/input10
> > > [   10.104441] input: HDA Intel PCH Line as
> > > /devices/pci:00/:00:1f.3/sound/card0/input11
> > > [   10.104467] input: HDA Intel PCH Line Out as
> > > /devices/pci:00/:00:1f.3/sound/card0/input12
> > > [   10.104494] input: HDA Intel PCH Front Headphone as
> > > /devices/pci:00/:00:1f.3/sound/card0/input13
> > >
> > > Consequently, I checked the pin widgets' default configuration values:
> > > - Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
> > > Pin Default 0x01014010: [Jack] Line Out at Ext Rear
> > >
> > > - Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
> > > Pin Default 0x02214030: [Jack] HP Out at Ext Front
> > >
> > > Because the headphone jack (Node ID:0x1b) locates on the desktop's front
> > > panel, not rear panel, I change the headphone jack's configuration from
> > > primary chassis to separate chassis.  So, the configuration value of
> > > Node ID:0x1b should be 0x22214030.
> >
> > This is OK, but...
> >
> > > Additionally, I toggle the Auto-Mute Mode of Realtek codecs to “Speaker
> > > Only” which makes signal outputs through line out jack when the "Line
> > > Out" is chosen in the sound settings.
> >
> > ... this is a matter of taste, and I don't think it good to set a
> > different default from others.  You can change it once and save it via
> > alsactl.
> 
> The default state of Auto-Mute Mode of Realtek codec on this machine is
> "Line Out + Speaker".
> This disallows to output audio signal through the line out jack, even I 
> already
> choose the "Line Out" as the audio output device in the sound settings.
> It means there is no way to use the line out jack in "Line Out + Speaker" 
> state
> of Auto-Mute Mode on this machine.

It's a setup issue by PA, and it's not specific to this device at
all.  If PA wants the independent output, it can change to auto-mute
off by itself.

> To enhance the user experience, especially the new one who first uses Linux,
> changing this machine's Auto-Mute Mode to "Speaker Only" state, which allows
> to output the audio signal through the line out jack, will be the better 
> choice.
> 
> By the way, if the "Headphones" is chosen as the audio output device in the
> sound settings, the audio signal will not output through the line out jack
> automatically.
> 
> Therefore, I think this part of the quirk is still needed on this machine.

Again, this isn't about the machine configuration, but a generic PA
problem.  Fixing it in a device-specific fixup is no right way.


thanks,

Takashi

linux-next: Tree for Apr 3

[Stephen Rothwell]

Hi all,

Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.

Changes since 20180329:

The kbuild tree lost its build failure.

The asm-generic tree gained a conflict against Linus' tree.

The vfs tree still had its build failure for which I reverted a commit.

The pci tree gained conflicts against Linus', the asm-generic and
arm-soc trees.

The net-next tree gained a conflict against the pci tree.

The selinux tree gained a conflict against the security tree.

Non-merge commits (relative to Linus' tree): 9213
 11817 files changed, 430998 insertions(+), 772860 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 261 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (46e0d28bdb8e Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (7928b2cbe55b Linux 4.16-rc1)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (1b8837b61714 ARM: 8750/1: deflate_xip_data.sh: minor 
fixes)
Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax 
ARM_SMCCC_ARCH_WORKAROUND_1 discovery)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (52396500f97c powerpc/64s: Fix i-side SLB miss bad 
address handler saving nonvolatile GPRs)
Merging sparc/master (9c548bb5823d sparc64: Oracle DAX driver depends on 
SPARC64)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging bpf/master (e8a4796ee295 nfp: bpf: fix check of program max insn count)
Merging ipsec/master (9a3fb9fb84cc xfrm: Fix transport mode skb control buffer 
usage.)
Merging netfilter/master (b9fc828debc8 qede: Fix barrier usage after tx 
doorbell write.)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (9b9322db5c5a brcmfmac: Fix check for ISO3166 
code)
Merging mac80211/master (1dfe82ebd7d8 net: fix possible out-of-bound read in 
skb_network_protocol())
Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer 
rdma_addr_size() variants)
Merging sound-current/for-linus (903d271a3f83 Merge tag 'asoc-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (fc110ebdd014 PCI: dwc: Fix enumeration end when 
reaching root subordinate)
Merging driver-core.current/driver-core-linus (0c8efd610b58 Linux 4.16-rc5)
Merging tty.current/tty-linus (c698ca527893 Linux 4.16-rc6)
Merging usb.current/usb-linus (c698ca527893 Linux 4.16-rc6)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add 
support for Harman FirmwareHubEmulator)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Mer

Re: [PATCH v5 09/13] ARM: sun9i: smp: Rename clusters's power-off

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 2:18 PM, Mylène Josserand
 wrote:
> To prepare the support for sun8i-a83t, rename the variable name
> that handles the power-off of clusters because it is different from
> sun9i-a80 to sun8i-a83t.
>
> The power off register for clusters are different from a80 and a83t.
>
> Signed-off-by: Mylène Josserand 
> Acked-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 

[GIT PULL] MMC for v.4.17

[Ulf Hansson]

Hi Linus,

Here's the PR with MMC updates for v.4.17. Details about the highlights are as
usual found in the signed tag.

Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:

  Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.17

for you to fetch changes up to 4472f0fc248e3f0573301f725eff9dc9cde5cb62:

  mmc: renesas_sdhi: replace EXT_ACC with HOST_MODE (2018-03-22 10:53:12 +0100)


MMC core:
 - Export host capabilities through debugfs
 - Export card RCA register via sysfs
 - Improve card initializing sequence while enabling 4-bit bus
 - Export a function to enable/disable wakeup for card detect IRQ

MMC host:
 - dw_mmc: Add support for new hi3798cv200 variant
 - dw_mmc: Remove support for some deprecated DT properties
 - mediatek: Add support for new variant used on MT7622 SoC
 - sdhci: Improve wakeup support for SDIO IRQs
 - sdhci: Improve wakeup support for card detect IRQs
 - sdhci-omap: Add tuning support
 - sdhci_omap: Add UHS-I mode support
 - sunxi: Prepare for runtime PM support via a few re-factorings
 - tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property
 - tmio/renesas_sdhi: Consolidate code supporting write protect
 - tmio: Improve DMA vs PIO handling
 - tmio: Add support for IP-builtin card detection logic


Abbas Raza (1):
  mmc: Export host capabilities to debugfs.

Adrian Hunter (7):
  mmc: sdhci-pci: Get rid of glk_cqe_enable()
  mmc: sdhci: Do not unnecessarily enable wakeup for card detect interrupt
  mmc: sdhci: Do not unnecessarily enable wakeup for SDIO card interrupt
  mmc: slot-gpio: Add a function to enable/disable card detect IRQ wakeup
  mmc: sdhci-pci: Respect PM flags when enabling card detect GPIO IRQ wakeup
  mmc: core: Fix tracepoint print of blk_addr and blksz
  mmc: sdhci-acpi: Fix IRQ 0

Alexey Roslyakov (1):
  mmc: dw_mmc: update kernel-doc comments for dw_mci

Andy Shevchenko (1):
  mmc: core: Re-use DEFINE_SHOW_ATTRIBUTE() macro

Bastian Stender (2):
  mmc: block: fix updating ext_csd caches on ioctl call
  mmc: block: fix updating ext_csd caches on ioctl call

Dirk Behme (2):
  mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards
  mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards

Evgeniy Didin (2):
  mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit 
systems
  mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

Harish Jenny K N (1):
  mmc: core: Export card RCA register via sysfs

Jaehoon Chung (7):
  mmc: dw_mmc: remove the deprecated "clock-freq-min-max" property
  mmc: dw_mmc: remove the deprecated "num-slots"
  ARM: dts: socfpga: remove 'num-slots' property for dwmmc
  arm64: dts: stratix10: remove 'num-slots' property for dwmmc
  ARM: dts: lpc18xx: remove 'num-slots' property for dwmmc
  arm64: dts: hi3660: remove 'num-slots' property for dwmmc
  mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433

Joel Cunningham (1):
  mmc: update sdio_claim_irq documentation

John Keeping (1):
  mmc: dw_mmc-rockchip: correct property names in debug

Kishon Vijay Abraham I (7):
  mmc: sdhci-omap: Update 'power_mode' outside sdhci_omap_init_74_clocks
  mmc: sdhci-omap: Add card_busy host ops
  mmc: sdhci-omap: Add custom set_uhs_signaling sdhci_host ops
  mmc: sdhci-omap: Add tuning support
  mmc: sdhci-omap: Workaround for Errata i802
  mmc: sdhci_omap: Add support to set IODELAY values
  mmc: sdhci_omap: Fix sdhci-omap quirks

Markus Elfring (1):
  mmc: core: Use memdup_user() rather than duplicating its implementation

Masaharu Hayakawa (1):
  mmc: renesas_sdhi: replace EXT_ACC with HOST_MODE

Masahiro Yamada (10):
  mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE
  mmc: tmio: deprecate "toshiba, mmc-wrprotect-disable" DT property
  mmc: tmio: support IP-builtin card detection logic
  mmc: tmio: fix never-detected card insertion bug
  mmc: tmio: move TMIO_MASK_{READOP, WRITEOP} handling to correct place
  mmc: tmio: clear force_pio flag before starting data transfer
  mmc: tmio: remove useless TMIO_MASK_CMD handling in tmio_mmc_host_probe()

Maxime Ripard (3):
  mmc: sunxi: Move resources management to separate functions
  mmc: sunxi: Move the reset deassertion before enabling the clocks
  mmc: sunxi: Set our device drvdata earlier

Sean Wang (2):
  mmc: dt-bindings: add support for MT

Re: [PATCH v5 05/13] ARM: dts: sun8i: Add R_CPUCFG device node for the A83T dtsi

[Chen-Yu Tsai]

On Tue, Apr 3, 2018 at 2:18 PM, Mylène Josserand
 wrote:
> The R_CPUCFG is a collection of registers needed for SMP bringup
> on clusters and cluster's reset.
> For the moment, documentation about this register is found in
> Allwinner's code only.
>
> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 32992afa0b12..85f14f4ebeed 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -933,6 +933,11 @@
> #reset-cells = <1>;
> };
>
> +   r_cpucfg@1f01c00 {
> +   compatible = "allwinner,sun8i-a83t-r-cpucfg";
> +   reg = <0x1f01c00 0x100>;

The memory map says that its size is 0x400.

ChenYu

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote:
> Am 29.03.2018 um 08:57 schrieb Daniel Vetter:
> > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:
> > > Add a peer2peer flag noting that the importer can deal with device
> > > resources which are not backed by pages.
> > > 
> > > Signed-off-by: Christian König 
> > Um strictly speaking they all should, but ttm never bothered to use the
> > real interfaces but just hacked around the provided sg list, grabbing the
> > underlying struct pages, then rebuilding&remapping the sg list again.
> 
> Actually that isn't correct. TTM converts them to a dma address array
> because drivers need it like this (at least nouveau, radeon and amdgpu).
> 
> I've fixed radeon and amdgpu to be able to deal without it and mailed with
> Ben about nouveau, but the outcome is they don't really know.
> 
> TTM itself doesn't have any need for the pages on imported BOs (you can't
> mmap them anyway), the real underlying problem is that sg tables doesn't
> provide what drivers need.
> 
> I think we could rather easily fix sg tables, but that is a totally separate
> task.

Looking at patch 8, the sg table seems perfectly sufficient to convey the
right dma addresses to the importer. Ofcourse the exporter has to set up
the right kind of iommu mappings to make this work.

> > The entire point of using sg lists was exactly to allow this use case of
> > peer2peer dma (or well in general have special exporters which managed
> > memory/IO ranges not backed by struct page). So essentially you're having
> > a "I'm totally not broken flag" here.
> 
> No, independent of needed struct page pointers we need to note if the
> exporter can handle peer2peer stuff from the hardware side in general.
> 
> So what I've did is just to set peer2peer allowed on the importer because of
> the driver needs and clear it in the exporter if the hardware can't handle
> that.

The only thing the importer seems to do is call the
pci_peer_traffic_supported, which the exporter could call too. What am I
missing (since the sturct_page stuff sounds like it's fixed already by
you)?
-Daniel

> > I think a better approach would be if we add a requires_struct_page or so,
> > and annotate the current importers accordingly. Or we just fix them up (it
> > is all in shared ttm code after all, I think everyone else got this
> > right).
> 
> I would rather not bed on that.
> 
> Christian.
> 
> > -Daniel
> > 
> > > ---
> > >   drivers/dma-buf/dma-buf.c | 1 +
> > >   include/linux/dma-buf.h   | 4 
> > >   2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index ffaa2f9a9c2c..f420225f93c6 100644
> > > --- a/drivers/dma-buf/dma-buf.c
> > > +++ b/drivers/dma-buf/dma-buf.c
> > > @@ -565,6 +565,7 @@ struct dma_buf_attachment *dma_buf_attach(const 
> > > struct dma_buf_attach_info *info
> > >   attach->dev = info->dev;
> > >   attach->dmabuf = dmabuf;
> > > + attach->peer2peer = info->peer2peer;
> > >   attach->priv = info->priv;
> > >   attach->invalidate = info->invalidate;
> > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > index 15dd8598bff1..1ef50bd9bc5b 100644
> > > --- a/include/linux/dma-buf.h
> > > +++ b/include/linux/dma-buf.h
> > > @@ -313,6 +313,7 @@ struct dma_buf {
> > >* @dmabuf: buffer for this attachment.
> > >* @dev: device attached to the buffer.
> > >* @node: list of dma_buf_attachment.
> > > + * @peer2peer: true if the importer can handle peer resources without 
> > > pages.
> > >* @priv: exporter specific attachment data.
> > >*
> > >* This structure holds the attachment information between the dma_buf 
> > > buffer
> > > @@ -328,6 +329,7 @@ struct dma_buf_attachment {
> > >   struct dma_buf *dmabuf;
> > >   struct device *dev;
> > >   struct list_head node;
> > > + bool peer2peer;
> > >   void *priv;
> > >   /**
> > > @@ -392,6 +394,7 @@ struct dma_buf_export_info {
> > >* @dmabuf: the exported dma_buf
> > >* @dev:the device which wants to import the attachment
> > >* @priv:   private data of importer to this attachment
> > > + * @peer2peer:   true if the importer can handle peer resources without 
> > > pages
> > >* @invalidate: callback to use for invalidating mappings
> > >*
> > >* This structure holds the information required to attach to a buffer. 
> > > Used
> > > @@ -401,6 +404,7 @@ struct dma_buf_attach_info {
> > >   struct dma_buf *dmabuf;
> > >   struct device *dev;
> > >   void *priv;
> > > + bool peer2peer;
> > >   void (*invalidate)(struct dma_buf_attachment *attach);
> > >   };
> > > -- 
> > > 2.14.1
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> _

Re: [PATCH v2 1/2] spi: spi-ti-qspi: Fix parameters order in regmap_update_bits calls

[Mark Brown]

On Fri, Mar 30, 2018 at 11:41:23AM +0200, Arkadiusz Kwiatkowski wrote:
> This commit fixes the order of parameters passed to regmap_update_bits
> function inside spi-ti-qspi driver. Accidentally the code worked
> correctly when cs=0, but it is not the case for other values.

This doesn't apply against current code, please check and resend.


signature.asc
Description: PGP signature

Re: [PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth

[Daniel Vetter]

On Wed, Mar 28, 2018 at 12:03:39PM +0200, Peter Rosin wrote:
> On 2018-03-28 09:34, Boris Brezillon wrote:
> > Hi Peter,
> > 
> > On Mon, 26 Mar 2018 09:35:02 +0200
> > Peter Rosin  wrote:
> > 
> >> I have an sama5d31-based system with 64MB of memory and a 1920x1080
> >> LVDS display wired for 16-bpp. When I enable legacy fbdev support,
> >> the contiguous memory allocator invariably fails with the order-11
> >> allocation for a 1920x1080@24-bpp buffer (~6MB). But this HW can never
> >> make any good use of RGB888, so that is a wasted attempt anyway that
> >> would also waste precious memory should it succeed.
> >>
> >> Sure, I could rewrite user-space to go directly to KMS etc, and that
> >> makes the (attempted) order-11 allocation go away, replacing it with
> >> one order-10 allocation per application restart for a 1920x1080@16-bpp
> >> buffer (<4MB). But after a few restarts, order-10 allocations start to
> >> fail as well, which is only to be expected AFAIU.
> >>
> >> So, I'd rather not change user-space (which was originally written
> >> to target a smaller display) so that I at the same time get the
> >> benefit of an early pre-allocated fbdev frame-buffer that can be
> >> reused over and over. But to do that I need to tell the driver that
> >> 16-bpp is the preferred depth. Add a module parameter to do just that.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +-
> >>  1 file changed, 17 insertions(+), 1 deletion(-)
> >>
> >> I found some inspiration regarding naming and implementation here:
> >> https://patchwork.kernel.org/patch/9848631/
> >>
> >> I have found no feedback on that patch though, which makes me wonder if
> >> I'm perhaps barking up the wronig tree?
> > 
> > Hm, isn't that something you can already overload with the video=
> > parameter?
> > 
> > video=:[-]
> 
> Heh, you are right...
> 
> > AFAIR,  encodes the color depth, so what is the benefit of adding
> > this new property to overload the default depth?
> 
> ...but hhhmmm, I think I will have to have to encode the display size
> in the bootargs so I will have to use distinct barebox environments
> depending on the panel, but that's no biggie.
> 
> Splendid, please throw away the patch!

I think we could fix the parsing to allow -bpp without the resolution ...
Not sure how to best do that though. Maybe state that 0x0-bpp means to not
change the resolution from the default?
-Daniel

> 
> Cheers,
> Peter
> 
> > Maybe I'm wrong and the default depth param is actually useful, but in
> > this case we should probably make it generic since other drivers seems
> > to need it too, and we might want to attach it to a specific display
> > engine instance.
> > 
> > Thanks,
> > 
> > Boris
> > 
> >>
> >> Cheers,
> >> Peter
> >>
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> index c1ea5c36b006..f0148627c221 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> @@ -29,6 +29,11 @@
> >>  
> >>  #define ATMEL_HLCDC_LAYER_IRQS_OFFSET 8
> >>  
> >> +static int atmel_hlcdc_preferred_depth __read_mostly;
> >> +
> >> +MODULE_PARM_DESC(preferreddepth, "Set preferred bpp");
> >> +module_param_named(preferreddepth, atmel_hlcdc_preferred_depth, int, 
> >> 0400);
> >> +
> >>  static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9n12_layers[] = {
> >>{
> >>.name = "base",
> >> @@ -590,6 +595,7 @@ static int atmel_hlcdc_dc_modeset_init(struct 
> >> drm_device *dev)
> >>dev->mode_config.min_height = dc->desc->min_height;
> >>dev->mode_config.max_width = dc->desc->max_width;
> >>dev->mode_config.max_height = dc->desc->max_height;
> >> +  dev->mode_config.preferred_depth = 24;
> >>dev->mode_config.funcs = &mode_config_funcs;
> >>  
> >>return 0;
> >> @@ -658,7 +664,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
> >>  
> >>platform_set_drvdata(pdev, dev);
> >>  
> >> -  drm_fb_cma_fbdev_init(dev, 24, 0);
> >> +  drm_fb_cma_fbdev_init(dev, atmel_hlcdc_preferred_depth, 0);
> >>  
> >>drm_kms_helper_poll_init(dev);
> >>  
> >> @@ -756,6 +762,16 @@ static int atmel_hlcdc_dc_drm_probe(struct 
> >> platform_device *pdev)
> >>struct drm_device *ddev;
> >>int ret;
> >>  
> >> +  switch (atmel_hlcdc_preferred_depth) {
> >> +  case 0: /* driver default */
> >> +  case 8:
> >> +  case 16:
> >> +  case 24:
> >> +  break;
> >> +  default:
> >> +  return -EINVAL;
> >> +  }
> >> +
> >>ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
> >>if (IS_ERR(ddev))
> >>return PTR_ERR(ddev);
> > 
> > 
> > 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.f

Re: [PATCH v5 08/13] ARM: sunxi: Add initialization of CNTVOFF

[Maxime Ripard]

On Tue, Apr 03, 2018 at 08:18:31AM +0200, Mylène Josserand wrote:
> Add the initialization of CNTVOFF for sun8i-a83t.
> 
> For boot CPU, Create a new machine that handles this
> function's call in an "init_early" callback.
> For secondary CPUs, add this function into secondary_startup
> assembly entry.
> 
> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/mach-sunxi/headsmp.S |  1 +
>  arch/arm/mach-sunxi/sunxi.c   | 18 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> index 79890fbe5613..b586b7cf803a 100644
> --- a/arch/arm/mach-sunxi/headsmp.S
> +++ b/arch/arm/mach-sunxi/headsmp.S
> @@ -71,6 +71,7 @@ ENDPROC(sunxi_mc_smp_cluster_cache_enable)
>  
>  ENTRY(sunxi_mc_smp_secondary_startup)
>   bl  sunxi_mc_smp_cluster_cache_enable
> + bl  smp_init_cntvoff
>   b   secondary_startup
>  ENDPROC(sunxi_mc_smp_secondary_startup)
>  
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 5e9602ce1573..090784108c0a 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  static const char * const sunxi_board_dt_compat[] = {
>   "allwinner,sun4i-a10",
> @@ -62,7 +63,6 @@ MACHINE_END
>  static const char * const sun8i_board_dt_compat[] = {
>   "allwinner,sun8i-a23",
>   "allwinner,sun8i-a33",
> - "allwinner,sun8i-a83t",
>   "allwinner,sun8i-h2-plus",
>   "allwinner,sun8i-h3",
>   "allwinner,sun8i-r40",
> @@ -75,6 +75,22 @@ DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i Family")
>   .dt_compat  = sun8i_board_dt_compat,
>  MACHINE_END
>  
> +void __init sun8i_cntvoff_init(void)
> +{
> + smp_init_cntvoff();

Can't this be moved to the SMP setup code?

> +}
> +
> +static const char * const sun8i_cntvoff_board_dt_compat[] = {
> + "allwinner,sun8i-a83t",
> + NULL,
> +};
> +
> +DT_MACHINE_START(SUN8I_CNTVOFF_DT, "Allwinner sun8i boards needing cntvoff")

All of the SoCs need CNTVOFF, so that doesn't really make sense. Why
not just calling it for what it is: an A83t?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v3] scsi: Introduce sdev_printk_ratelimited to throttle frequent printk

[Jason Yan]

On 2018/4/3 14:04, Wen Yang wrote:

There would be so many same lines printed by frequent printk if one
disk went wrong, like,
[  546.185242] sd 0:1:0:0: rejecting I/O to offline device
[  546.185258] sd 0:1:0:0: rejecting I/O to offline device
[  546.185280] sd 0:1:0:0: rejecting I/O to offline device
[  546.185307] sd 0:1:0:0: rejecting I/O to offline device
[  546.185334] sd 0:1:0:0: rejecting I/O to offline device
[  546.185364] sd 0:1:0:0: rejecting I/O to offline device
[  546.185390] sd 0:1:0:0: rejecting I/O to offline device
[  546.185410] sd 0:1:0:0: rejecting I/O to offline device
For slow serial console, the frequent printk may be blocked for a
long time, and if any spin_lock has been acquired before the printk
like in scsi_request_fn, watchdog could be triggered.

Related disscussion can be found here,
https://bugzilla.kernel.org/show_bug.cgi?id=199003
And Petr brought the idea to throttle the frequent printk, it's
useless to print the same lines frequently after all.

v2: fix some typos
v3: limit the print only for the same device

Suggested-by: Petr Mladek
Suggested-by: Sergey Senozhatsky
Signed-off-by: Wen Yang
Signed-off-by: Jiang Biao
Signed-off-by: Tan Hu
Reviewed-by: Bart Van Assche
CC: BartVanAssche
CC: Petr Mladek
CC: Sergey Senozhatsky
CC: Martin K. Petersen
CC: "James E.J. Bottomley"
CC: Tejun Heo
CC: JasonYan


In my machine it works fine.

Tested-by: Jason Yan 

RE: [PATCH 2/3] rpmsg: Only invoke announce_create for rpdev with endpoints

[Loic PALLARDY]

Hi Bjorn,

> -Original Message-
> From: linux-remoteproc-ow...@vger.kernel.org [mailto:linux-remoteproc-
> ow...@vger.kernel.org] On Behalf Of Bjorn Andersson
> Sent: Tuesday, March 27, 2018 11:07 PM
> To: Ohad Ben-Cohen ; Bjorn Andersson
> 
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> arm-...@vger.kernel.org
> Subject: [PATCH 2/3] rpmsg: Only invoke announce_create for rpdev with
> endpoints
> 
> For special rpmsg devices without a primary endpoint there is nothing to
> announce so don't call the backend announce create function if we didn't
> create an endpoint.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/rpmsg/rpmsg_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index dffa3aab7178..e85d2691d2cf 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -442,7 +442,7 @@ static int rpmsg_dev_probe(struct device *dev)
>   goto out;
>   }
> 
> - if (rpdev->ops->announce_create)
> + if (ept && rpdev->ops->announce_create)

This check is already part of virtio_rpmsg.c (see line 341)
/* need to tell remote processor's name service about this channel ? */
if (rpdev->announce && rpdev->ept &&
virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {

should it be part of qcom_smd driver too? (but each implementation will 
duplicate checks)
Or may have a generic check in the core including rpdev->announce as well (and 
doing virtio_rpmsg.c clean-up)

Change will become:
if (rpdev->announce && ept && rpdev->ops->announce_create)

Regards,
Loic
>   err = rpdev->ops->announce_create(rpdev);
>  out:
>   return err;
> --
> 2.16.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] s390 patches for the 4.17 merge window #1

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

 * Improvements for the spectre defense:
   - The spectre related code is consolidated to a single file nospec-branch.c
   - Automatic enable/disable for the spectre v2 defenses (expoline vs. nobp)
   - Syslog messages for specve v2 are added
   - Enable CONFIG_GENERIC_CPU_VULNERABILITIES and define the attribute
 functions for spectre v1 and v2

 * Add helper macros for assembler alternatives and use them to shorten
   the code in entry.S.

 * Add support for persistent configuration data via the SCLP Store Data
   interface. The H/W interface requires a page table that uses 4K pages
   only, the code to setup such an address space is added as well.

 * Enable virtio GPU emulation in QEMU. To do this the depends statements
   for a few common Kconfig options are modified.

 * Add support for format-3 channel path descriptors and add a binary
   sysfs interface to export the associated utility strings.

 * Add a sysfs attribute to control the IFCC handling in case of constant
   channel errors.

 * The vfio-ccw changes from Cornelia.

 * Bug fixes and cleanups.

There is a trivial merge conflict in drivers/video/console/Kconfig.

Christian Borntraeger (2):
  s390/sclp_tty: enable line mode tty even if there is an ascii console
  s390/defkeymap: fix global init to zero

Claudio Imbrenda (4):
  s390/sclp: clean up, use sccb_mask_t where appropriate
  s390/sclp: generic event mask accessors
  s390/sclp: 32 bit event mask compatibility mode
  s390/sclp: 64 bit event mask

Cornelia Huck (3):
  s390: fix comment for scsw_cmd_is_valid_sctl
  vfio-ccw: update documentation
  vfio-ccw: fence off transport mode

Farhan Ali (3):
  Kconfig : Remove HAS_IOMEM dependency for Graphics support
  s390/char : Rename EBCDIC keymap variables
  s390/setup : enable display support for KVM guest

Harald Freudenberger (1):
  s390/crypto: Fix kernel crash on aes_s390 module remove.

Heiko Carstens (1):
  s390/mm: provide base_asce_alloc() / base_asce_free() helper functions

Julian Wiedmann (6):
  s390: fix typo in irb description
  s390/qdio: simplify math in get_*_buffer_frontier()
  s390/qdio: don't merge ERROR output buffers
  s390/qdio: restrict buffer merging to eligible devices
  s390/qdio: don't retry EQBS after CCQ 96
  s390/qdio: split up CCQ handling for EQBS / SQBS

Martin Schwidefsky (8):
  s390: move nobp parameter functions to nospec-branch.c
  s390: add automatic detection of the spectre defense
  s390: report spectre mitigation via syslog
  s390: add sysfs attributes for spectre
  s390: add assembler macros for CPU alternatives
  s390/entry.S: use assembler alternatives
  s390/lpp: use assembler alternatives for the LPP instruction
  s390/kvm: improve stack frame constants in entry.S

Peter Oberparleiter (1):
  s390/sclp: Add support for Store Data SCLP interface

Sebastian Ott (4):
  s390/cio: fix unbind of io_subchannel_driver
  s390/cio: rename struct channel_path_desc
  s390/chsc: query utility strings via fmt3 channel path descriptor
  s390/cio: add util_string sysfs attribute

Stefan Haberland (3):
  s390/dasd: configurable IFCC handling
  s390/dasd: remove unneeded sanity check
  s390/dasd: set timestamps unconditionally

Vasily Gorbik (4):
  s390/decompressor: discard __ex_table section
  s390: unify linker symbols usage
  s390: set bzImage as default image for packaging
  s390/decompressor: trim uncompressed image head during the build

 Documentation/s390/vfio-ccw.txt |  79 +++--
 arch/s390/Kconfig   |   3 +-
 arch/s390/Makefile  |   8 +-
 arch/s390/boot/compressed/Makefile  |  16 +-
 arch/s390/boot/compressed/head.S|   6 +-
 arch/s390/boot/compressed/misc.c|  10 +-
 arch/s390/boot/compressed/vmlinux.lds.S |   1 +
 arch/s390/crypto/aes_s390.c |   5 +-
 arch/s390/include/asm/alternative-asm.h | 108 ++
 arch/s390/include/asm/ccwdev.h  |   2 +-
 arch/s390/include/asm/chpid.h   |   2 +-
 arch/s390/include/asm/cio.h |   2 +-
 arch/s390/include/asm/cpu_mf.h  |   4 +-
 arch/s390/include/asm/css_chars.h   |   6 +-
 arch/s390/include/asm/nospec-branch.h   |   6 +-
 arch/s390/include/asm/pgalloc.h |   3 +
 arch/s390/include/asm/scsw.h|   4 +-
 arch/s390/include/asm/setup.h   |   2 -
 arch/s390/include/uapi/asm/dasd.h   |  38 ++-
 arch/s390/kernel/Makefile   |   4 +-
 arch/s390/kernel/alternative.c  |  24 +-
 arch/s390/kernel/asm-offsets.c  |   1 +
 arch/s390/kernel/early.c|   4 +-
 arch/s390/kernel/entry.S|  96 ++
 arch/s390/kernel/module.c   |  11 +-
 arch/s

Re: general protection fault in try_to_wake_up

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 10:50:03AM +0200, Petr Mladek wrote:
> raw_spin_lock() succeeded here. Therefore lockdep was still working
> at this stage.

What does the success of raw_spin_lock() have to do with lockdep ?

Re: [PATCH 1/2] lib: vsprintf: Implement %pCOW

[Petr Mladek]

On Mon 2018-04-02 17:18:12, Andy Shevchenko wrote:
> On Sun, 2018-04-01 at 10:56 +0200, Richard Weinberger wrote:
> > Add a new format string to print in cowsay format.
> > 
> 
> Apparently NAK b/c missed test cases!

This is really sad. I'll miss the cows.

Moo,
Petr

Re: [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device

[Aaron Ma]

Hi Jiri:

This patch is pending for long time.

Could you merge this single patch to upstream?

Regards,
Aaron

Re: [GIT PULL] arch: remove obsolete architecture ports

[Geert Uytterhoeven]

On Mon, Apr 2, 2018 at 9:54 PM, Arnd Bergmann  wrote:
> On Mon, Apr 2, 2018 at 8:57 PM, Linus Torvalds
>  wrote:
> Regarding a possible revert, that would indeed involve reverting
> multiple patches for most architectures, plus parts of at least these
> three:
>
>   Documentation: arch-support: remove obsolete architectures
>   treewide: simplify Kconfig dependencies for removed archs
>   ktest: remove obsolete architectures
>
> For those, I went the other way, and removed all architectures at
> once to simplify my work and to avoid touching the same files up
> to eight times with interdependent patches (which couldn't
> be reverted without conflicts either).
>
> There are a couple of driver removal patches that got picked up
> into subsystem trees instead of this tree, so a full revert would also
> involve finding other drivers, but if you prefer to have the patches
> completely split up by arch, I could rework the series that way.

In reality, a resurrection may not be implemented as a pure revert, but as
the addition of a new architecture, implemented using modern features (DT,
CCF, ...).

Cfr. the resurrected arch/h8300, which doesn't have much in common with
the removed one:

$ git diff --stat v3.12..v4.2 -- arch/h8300
[...]
 197 files changed, 3155 insertions(+), 7849 deletions(-)

(for a total of ca. 6200 lines)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RESEND PATCH v6 1/5] pwm-backlight: enable/disable the PWM before/after LCD enable toggle.

[Lee Jones]

On Wed, 28 Mar 2018, Enric Balletbo i Serra wrote:

> Before this patch the enable signal was set before the PWM signal and
> vice-versa on power off. This sequence is wrong, at least, it is on
> the different panels datasheets that I checked, so I inverted the sequence
> to follow the specs.
> 
> For reference the following panels have the mentioned sequence:
>   - N133HSE-EA1 (Innolux)
>   - N116BGE (Innolux)
>   - N156BGE-L21 (Innolux)
>   - B101EAN0 (Auo)
>   - B101AW03 (Auo)
>   - LTN101NT05 (Samsung)
>   - CLAA101WA01A (Chunghwa)
> 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Daniel Thompson 
> Acked-by: Jingoo Han 
> Acked-by: Thierry Reding 
> ---
> Changes since v5:
>  - Add Acked-by: Thierry Reding 
> Changes since v4:
>  - Rebase on top of mainline.
>  - Add the acks from Daniel Thompson and Jingoo Han.
> Changes since v3:
>  - List the part numbers for the panel checked (Daniel Thompson)
> Changes since v2:
>  - Add this as a separate patch (Thierry Reding)
> Changes since v1:
>  - None
> ---
>  drivers/video/backlight/pwm_bl.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND PATCH v6 3/5] pwm-backlight: add support for PWM delays proprieties.

[Lee Jones]

On Wed, 28 Mar 2018, Enric Balletbo i Serra wrote:

> Some panels (i.e. N116BGE-L41), in their power sequence specifications,
> request a delay between set the PWM signal and enable the backlight and
> between clear the PWM signal and disable the backlight. Add support for
> the new post-pwm-on-delay-ms and pwm-off-delay-ms proprieties to meet
> the timings.
> 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Pavel Machek 
> Acked-by: Daniel Thompson 
> Acked-by: Jingoo Han 
> Acked-by: Thierry Reding 
> ---
> Changes since v5:
>  - Add Acked-by: Thierry Reding 
> Changes since v4:
>  - Rebased on top of mainline.
>  - Added the acks from Pavel Machek, Daniel thompson and Jingoo Han
> Changes since v3:
>  - Use two named members instead of pwm_delay[] (Daniel and Pavel)
>  - Use msleep instead of usleep_range. (Pavel)
> Changes since v2:
>  - Move the pwm/enable sequence to another patch (Thierry Reding)
> Changes since v1:
>  - As suggested by Daniel Thompson
>- Do not assume power-on delay and power-off delay will be the same
>  - Move the check of dt property to the parse dt function.
> ---
>  drivers/video/backlight/pwm_bl.c | 19 +++
>  include/linux/pwm_backlight.h|  2 ++
>  2 files changed, 21 insertions(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND PATCH v6 2/5] dt-bindings: pwm-backlight: add PWM delay proprieties.

[Lee Jones]

On Wed, 28 Mar 2018, Enric Balletbo i Serra wrote:

> Hardware needs a delay between setting an initial (non-zero) PWM and
> enabling the backlight using GPIO. The post-pwm-on-delay-ms specifies
> this delay in milli seconds. Hardware also needs a delay between disabing
> the backlight using GPIO and setting PWM value to 0. The pwm-off-delay-ms
> is this delay in milli seconds.
> 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Pavel Machek 
> Acked-by: Thierry Reding 
> Acked-by: Daniel Thompson 
> Reviewed-by: Rob Herring 
> ---
> Based on the original Huang Lin  work.
> Changes since v5:
>  - Add Acked-by: Thierry Reding 
>  - CC DT mainling list (for some reason dropped at some point, my
>fault)
> Changes since v4:
>  - Rebase on top of mainline.
> Changes since v3:
>  - Replace us for ms.
>  - Add Acked-by: Pavel Machek 
> Changes since v2:
>  - Use separate properties (Rob Herring)
> Changes since v1:
>  - As suggested by Daniel Thompson
>- Do not assume power-on delay and power-off delay will be the same
> ---
>  Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt | 6 ++
>  1 file changed, 6 insertions(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/5] kokr/doc: READ_ONCE() now implies smp_barrier_depends()

[SeongJae Park]

This commit applies an upstream change, commit 40555946447a ("doc:
READ_ONCE() now implies smp_barrier_depends()") to the Korean version
document.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index 0a0930ab4156..edef154d77b2 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -255,17 +255,20 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니
  (*) 어떤 CPU 든, 의존성이 존재하는 메모리 액세스들은 해당 CPU 자신에게
  있어서는 순서대로 메모리 시스템에 수행 요청됩니다. 즉, 다음에 대해서:
 
-   Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
+   Q = READ_ONCE(P); D = READ_ONCE(*Q);
 
  CPU 는 다음과 같은 메모리 오퍼레이션 시퀀스를 수행 요청합니다:
 
Q = LOAD P, D = LOAD *Q
 
- 그리고 그 시퀀스 내에서의 순서는 항상 지켜집니다.  대부분의 시스템에서
- smp_read_barrier_depends() 는 아무일도 안하지만 DEC Alpha 에서는
- 명시적으로 사용되어야 합니다.  보통의 경우에는 smp_read_barrier_depends()
- 를 직접 사용하는 대신 rcu_dereference() 같은 것들을 사용해야 함을
- 알아두세요.
+ 그리고 그 시퀀스 내에서의 순서는 항상 지켜집니다.  하지만, DEC Alpha 에서
+ READ_ONCE() 는 메모리 배리어 명령도 내게 되어 있어서, DEC Alpha CPU 는
+ 다음과 같은 메모리 오퍼레이션들을 내놓게 됩니다:
+
+   Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER
+
+ DEC Alpha 에서 수행되든 아니든, READ_ONCE() 는 컴파일러로부터의 악영향
+ 또한 제거합니다.
 
  (*) 특정 CPU 내에서 겹치는 영역의 메모리에 행해지는 로드와 스토어 들은 해당
  CPU 안에서는 순서가 바뀌지 않은 것으로 보여집니다.  즉, 다음에 대해서:
-- 
2.13.0

[PATCH 4/5] kokr/memory-barriers: Fix description of data dependency barriers

[SeongJae Park]

This commit applies an upstream change, commit 51de78892b12
("memory-barriers: Fix description of data dependency barriers") to the
Korean version document.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index 2c0ab128cd04..99ef4ca1c1bf 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -427,8 +427,8 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니
  데이터 의존성 배리어는 읽기 배리어의 보다 완화된 형태입니다.  두개의 로드
  오퍼레이션이 있고 두번째 것이 첫번째 것의 결과에 의존하고 있을 때(예:
  두번째 로드가 참조할 주소를 첫번째 로드가 읽는 경우), 두번째 로드가 읽어올
- 데이터는 첫번째 로드에 의해 그 주소가 얻어지기 전에 업데이트 되어 있음을
- 보장하기 위해서 데이터 의존성 배리어가 필요할 수 있습니다.
+ 데이터는 첫번째 로드에 의해 그 주소가 얻어진 뒤에 업데이트 됨을 보장하기
+ 위해서 데이터 의존성 배리어가 필요할 수 있습니다.
 
  데이터 의존성 배리어는 상호 의존적인 로드 오퍼레이션들 사이의 부분적 순서
  세우기입니다; 스토어 오퍼레이션들이나 독립적인 로드들, 또는 중복되는
-- 
2.13.0

[PATCH 0/5] memory-barriers.txt: Applies upstream changes to the Korean version

[SeongJae Park]

This patchset applies upstream changes for memory-barriers.txt to the Korean
version of it.

SeongJae Park (5):
  kokr/doc: READ_ONCE() now implies smp_barrier_depends()
  kokr/doc: De-emphasize smp_read_barrier_depends
  kokr/Documentation/memory-barriers.txt: Cross-reference
"tools/memory-model/"
  kokr/memory-barriers: Fix description of data dependency barriers
  kokr/locking/memory-barriers: De-emphasize smp_read_barrier_depends()
some more

 .../translations/ko_KR/memory-barriers.txt | 50 +++---
 1 file changed, 34 insertions(+), 16 deletions(-)

-- 
2.13.0

[PATCH 3/5] kokr/Documentation/memory-barriers.txt: Cross-reference "tools/memory-model/"

[SeongJae Park]

This commit applies an upstream change, commit 621df431b0ac
("Documentation/memory-barriers.txt: Cross-reference
"tools/memory-model/"") to the Korean version document.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index 44e47c2d33cf..2c0ab128cd04 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -36,6 +36,9 @@ Documentation/memory-barriers.txt
 부분도 있고, 의도하진 않았지만 사람에 의해 쓰였다보니 불완전한 부분도 있습니다.
 이 문서는 리눅스에서 제공하는 다양한 메모리 배리어들을 사용하기 위한
 안내서입니다만, 뭔가 이상하다 싶으면 (그런게 많을 겁니다) 질문을 부탁드립니다.
+일부 이상한 점들은 공식적인 메모리 일관성 모델과 tools/memory-model/ 에 있는
+관련 문서를 참고해서 해결될 수 있을 겁니다.  그러나, 이 메모리 모델조차도 그
+관리자들의 의견의 집합으로 봐야지, 절대 옳은 예언자로 신봉해선 안될 겁니다.
 
 다시 말하지만, 이 문서는 리눅스가 하드웨어에 기대하는 사항에 대한 명세서가
 아닙니다.
-- 
2.13.0

[PATCH 5/5] kokr/locking/memory-barriers: De-emphasize smp_read_barrier_depends() some more

[SeongJae Park]

This commit applies an upstream change, commit f28f0868feb1
("locking/memory-barriers: De-emphasize smp_read_barrier_depends() some
more") to the Korean version documentation.

Signed-off-by: SeongJae Park 
---
 .../translations/ko_KR/memory-barriers.txt | 27 ++
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index 99ef4ca1c1bf..21e78af7ee93 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -80,7 +80,7 @@ Documentation/memory-barriers.txt
 
  - 메모리 배리어의 종류.
  - 메모리 배리어에 대해 가정해선 안될 것.
- - 데이터 의존성 배리어.
+ - 데이터 의존성 배리어 (역사적).
  - 컨트롤 의존성.
  - SMP 배리어 짝맞추기.
  - 메모리 배리어 시퀀스의 예.
@@ -576,8 +576,14 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 
Documentation/DMA-API.txt
 
 
-데이터 의존성 배리어
-
+데이터 의존성 배리어 (역사적)
+-
+
+리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
+추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
+전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
+그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
+배리어에 대한 이야기를 적습니다.
 
 데이터 의존성 배리어의 사용에 있어 지켜야 하는 사항들은 약간 미묘하고, 데이터
 의존성 배리어가 사용되어야 하는 상황도 항상 명백하지는 않습니다.  설명을 위해
@@ -2802,8 +2808,9 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 
 
 
 여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
-사이에 넣어야 합니다.  이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성
-큐를 처리하도록 강제하게 됩니다.
+사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
+그렇게 됩니다).  이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
+처리하도록 강제하게 됩니다.
 
CPU 1   CPU 2   COMMENT
=== === ===
@@ -2833,9 +2840,9 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 
 액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다.  Alpha 는 가장
 약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
 사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
-더 높은 CPU 클락 속도를 가질 수 있게 했습니다.  하지만, Alpha 아키텍쳐 전용
-코드와 READ_ONCE() 매크로 내부에서를 제외하고는 smp_read_barrier_depends() 가
-사용되지 않아야 함을 알아두시기 바랍니다.
+더 높은 CPU 클락 속도를 가질 수 있게 했습니다.  하지만, (다시 말하건대, v4.15
+이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
+smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
 
 
 캐시 일관성 VS DMA
@@ -2997,7 +3004,9 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
 메모리 일관성 시스템과 함께 두개의 캐시를 동기화 시켜서, 포인터 변경과 새로운
 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
 
-리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다.
+리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
+부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
+Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
 
 위의 "캐시 일관성" 서브섹션을 참고하세요.
 
-- 
2.13.0

[PATCH 2/5] kokr/doc: De-emphasize smp_read_barrier_depends

[SeongJae Park]

This commit applies an upstream change, commit 9ad3c143d7d6 ("doc:
De-emphasize smp_read_barrier_depends") to the Korean version document.

Signed-off-by: SeongJae Park 
---
 Documentation/translations/ko_KR/memory-barriers.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index edef154d77b2..44e47c2d33cf 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -1790,7 +1790,7 @@ CPU 메모리 배리어
범용  mb()smp_mb()
쓰기  wmb()   smp_wmb()
읽기  rmb()   smp_rmb()
-   데이터 의존성 read_barrier_depends()  smp_read_barrier_depends()
+   데이터 의존성 READ_ONCE()
 
 
 데이터 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를
@@ -2829,7 +2829,10 @@ CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 
 다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
 액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다.  Alpha 는 가장
 약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
-사용되지 않았을 때에는 그런 조정이 필요하지 않게 했습니다.
+사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
+더 높은 CPU 클락 속도를 가질 수 있게 했습니다.  하지만, Alpha 아키텍쳐 전용
+코드와 READ_ONCE() 매크로 내부에서를 제외하고는 smp_read_barrier_depends() 가
+사용되지 않아야 함을 알아두시기 바랍니다.
 
 
 캐시 일관성 VS DMA
-- 
2.13.0

Re: NO_HZ_FULL and tick running within a reasonable amount of time

[Peter Zijlstra]

On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote:

> The WARN_ON_ONCE() triggering is this guy:
> 
>   delta = rq_clock_task(rq) - curr->se.exec_start;
>   WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3);
> 
> But given that ->se.exec_start is zeroed from time to time, for example,
> in migrate_task_rq_fair(), I am a bit suspicious of this check.
> 
> What am I missing here?

We clear it on migration, but set it when we schedule a task back in.
The above checks that the 'current' task of that CPU had a tick at least
3 seconds ago (to ensure tasks don't go too long without ticks).

The 'current' task is obviously scheduled in and thus must have !0
exec_start time.

Re: [PATCH v4 3/3] MIPS: use generic GCC library routines from lib/

[Matt Redfearn]

On 03/04/18 09:53, James Hogan wrote:

On Thu, Mar 29, 2018 at 11:41:23AM +0100, Matt Redfearn wrote:

This commit removes several generic GCC library routines from
arch/mips/lib/ in favour of similar routines from lib/.



diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index e84e12655fa8..6537e022ef62 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -16,5 +16,4 @@ obj-$(CONFIG_CPU_R3000)   += r3k_dump_tlb.o
  obj-$(CONFIG_CPU_TX39XX)  += r3k_dump_tlb.o
  
  # libgcc-style stuff needed in the kernel

-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
-ucmpdi2.o
+obj-y += bswapsi.o bswapdi.o multi3.o


Have you missed deleting the files?


Oops, got lost during the rebase :-/

Thanks,
Matt



Cheers
James

[PATCH v5 1/3] Add notrace to lib/ucmpdi2.c

[Matt Redfearn]

From: Palmer Dabbelt 

As part of the MIPS conversion to use the generic GCC library routines,
Matt Redfearn discovered that I'd missed a notrace on __ucmpdi2().  This
patch rectifies the problem.

CC: Matt Redfearn 
CC: Antony Pavlov 
Signed-off-by: Palmer Dabbelt 
Reviewed-by: Matt Redfearn 
Signed-off-by: Matt Redfearn 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
  add notrace to lib/ucmpdi2.c

 lib/ucmpdi2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/ucmpdi2.c b/lib/ucmpdi2.c
index 25ca2d4c1e19..597998169a96 100644
--- a/lib/ucmpdi2.c
+++ b/lib/ucmpdi2.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b)
 {
const DWunion au = {.ll = a};
const DWunion bu = {.ll = b};
-- 
2.7.4

[PATCH v5 2/3] lib: Rename compiler intrinsic selects to GENERIC_LIB_*

[Matt Redfearn]

When these are included into arch Kconfig files, maintaining
alphabetical ordering of the selects means these get split up. To allow
for keeping things tidier and alphabetical, rename the selects to
GENERIC_LIB_*

Signed-off-by: Matt Redfearn 
Reviewed-by: Palmer Dabbelt 

---

Changes in v5: None
Changes in v4:
Rename Kconfig symbols GENERIC_* -> GENERIC_LIB_*

Changes in v3: None
Changes in v2: None

 arch/riscv/Kconfig |  6 +++---
 lib/Kconfig| 12 ++--
 lib/Makefile   | 12 ++--
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 04807c7f64cc..20185aaaf933 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -104,9 +104,9 @@ config ARCH_RV32I
bool "RV32I"
select CPU_SUPPORTS_32BIT_KERNEL
select 32BIT
-   select GENERIC_ASHLDI3
-   select GENERIC_ASHRDI3
-   select GENERIC_LSHRDI3
+   select GENERIC_LIB_ASHLDI3
+   select GENERIC_LIB_ASHRDI3
+   select GENERIC_LIB_LSHRDI3
 
 config ARCH_RV64I
bool "RV64I"
diff --git a/lib/Kconfig b/lib/Kconfig
index e96089499371..e54ebe00937e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -588,20 +588,20 @@ config STRING_SELFTEST
 
 endmenu
 
-config GENERIC_ASHLDI3
+config GENERIC_LIB_ASHLDI3
bool
 
-config GENERIC_ASHRDI3
+config GENERIC_LIB_ASHRDI3
bool
 
-config GENERIC_LSHRDI3
+config GENERIC_LIB_LSHRDI3
bool
 
-config GENERIC_MULDI3
+config GENERIC_LIB_MULDI3
bool
 
-config GENERIC_CMPDI2
+config GENERIC_LIB_CMPDI2
bool
 
-config GENERIC_UCMPDI2
+config GENERIC_LIB_UCMPDI2
bool
diff --git a/lib/Makefile b/lib/Makefile
index a90d4fcd748f..7425e177f08c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -253,9 +253,9 @@ obj-$(CONFIG_SBITMAP) += sbitmap.o
 obj-$(CONFIG_PARMAN) += parman.o
 
 # GCC library routines
-obj-$(CONFIG_GENERIC_ASHLDI3) += ashldi3.o
-obj-$(CONFIG_GENERIC_ASHRDI3) += ashrdi3.o
-obj-$(CONFIG_GENERIC_LSHRDI3) += lshrdi3.o
-obj-$(CONFIG_GENERIC_MULDI3) += muldi3.o
-obj-$(CONFIG_GENERIC_CMPDI2) += cmpdi2.o
-obj-$(CONFIG_GENERIC_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_ASHLDI3) += ashldi3.o
+obj-$(CONFIG_GENERIC_LIB_ASHRDI3) += ashrdi3.o
+obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o
+obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
+obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
-- 
2.7.4

[PATCH v5 3/3] MIPS: use generic GCC library routines from lib/

[Matt Redfearn]

From: Antony Pavlov 

The commit b35cd9884fa5 ("lib: Add shared copies of some GCC library
routines") makes it possible to share generic GCC library routines by
several architectures.

This commit removes several generic GCC library routines from
arch/mips/lib/ in favour of similar routines from lib/.

Signed-off-by: Antony Pavlov 
[Matt Redfearn] Use GENERIC_LIB_* named Kconfig entries
Signed-off-by: Matt Redfearn 
Cc: Palmer Dabbelt 
Cc: Matt Redfearn 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org

---

Changes in v5:
  Actually delete the MIPS lib routines

Changes in v4:
  Rework to use the new GENERIC_LIB_ Kconfig entries

Changes in v3:
  Maintain alphabetical order of MIPS Kconfig

Changes in v2: None

 arch/mips/Kconfig   |  5 +
 arch/mips/lib/Makefile  |  3 +--
 arch/mips/lib/ashldi3.c | 30 --
 arch/mips/lib/ashrdi3.c | 32 
 arch/mips/lib/cmpdi2.c  | 28 
 arch/mips/lib/lshrdi3.c | 30 --
 arch/mips/lib/ucmpdi2.c | 22 --
 7 files changed, 6 insertions(+), 144 deletions(-)
 delete mode 100644 arch/mips/lib/ashldi3.c
 delete mode 100644 arch/mips/lib/ashrdi3.c
 delete mode 100644 arch/mips/lib/cmpdi2.c
 delete mode 100644 arch/mips/lib/lshrdi3.c
 delete mode 100644 arch/mips/lib/ucmpdi2.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 8128c3b68d6b..98955a76c656 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -22,6 +22,11 @@ config MIPS
select GENERIC_CPU_AUTOPROBE
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
+   select GENERIC_LIB_ASHLDI3
+   select GENERIC_LIB_ASHRDI3
+   select GENERIC_LIB_CMPDI2
+   select GENERIC_LIB_LSHRDI3
+   select GENERIC_LIB_UCMPDI2
select GENERIC_PCI_IOMAP
select GENERIC_SCHED_CLOCK if !CAVIUM_OCTEON_SOC
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index e84e12655fa8..6537e022ef62 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -16,5 +16,4 @@ obj-$(CONFIG_CPU_R3000)   += r3k_dump_tlb.o
 obj-$(CONFIG_CPU_TX39XX)   += r3k_dump_tlb.o
 
 # libgcc-style stuff needed in the kernel
-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
-ucmpdi2.o
+obj-y += bswapsi.o bswapdi.o multi3.o
diff --git a/arch/mips/lib/ashldi3.c b/arch/mips/lib/ashldi3.c
deleted file mode 100644
index 24cd6903e797..
--- a/arch/mips/lib/ashldi3.c
+++ /dev/null
@@ -1,30 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include 
-
-#include "libgcc.h"
-
-long long notrace __ashldi3(long long u, word_type b)
-{
-   DWunion uu, w;
-   word_type bm;
-
-   if (b == 0)
-   return u;
-
-   uu.ll = u;
-   bm = 32 - b;
-
-   if (bm <= 0) {
-   w.s.low = 0;
-   w.s.high = (unsigned int) uu.s.low << -bm;
-   } else {
-   const unsigned int carries = (unsigned int) uu.s.low >> bm;
-
-   w.s.low = (unsigned int) uu.s.low << b;
-   w.s.high = ((unsigned int) uu.s.high << b) | carries;
-   }
-
-   return w.ll;
-}
-
-EXPORT_SYMBOL(__ashldi3);
diff --git a/arch/mips/lib/ashrdi3.c b/arch/mips/lib/ashrdi3.c
deleted file mode 100644
index 23f5295af51e..
--- a/arch/mips/lib/ashrdi3.c
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include 
-
-#include "libgcc.h"
-
-long long notrace __ashrdi3(long long u, word_type b)
-{
-   DWunion uu, w;
-   word_type bm;
-
-   if (b == 0)
-   return u;
-
-   uu.ll = u;
-   bm = 32 - b;
-
-   if (bm <= 0) {
-   /* w.s.high = 1..1 or 0..0 */
-   w.s.high =
-   uu.s.high >> 31;
-   w.s.low = uu.s.high >> -bm;
-   } else {
-   const unsigned int carries = (unsigned int) uu.s.high << bm;
-
-   w.s.high = uu.s.high >> b;
-   w.s.low = ((unsigned int) uu.s.low >> b) | carries;
-   }
-
-   return w.ll;
-}
-
-EXPORT_SYMBOL(__ashrdi3);
diff --git a/arch/mips/lib/cmpdi2.c b/arch/mips/lib/cmpdi2.c
deleted file mode 100644
index 93cfc785927d..
--- a/arch/mips/lib/cmpdi2.c
+++ /dev/null
@@ -1,28 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include 
-
-#include "libgcc.h"
-
-word_type notrace __cmpdi2(long long a, long long b)
-{
-   const DWunion au = {
-   .ll = a
-   };
-   const DWunion bu = {
-   .ll = b
-   };
-
-   if (au.s.high < bu.s.high)
-   return 0;
-   else if (au.s.high > bu.s.high)
-   return 2;
-
-   if ((unsigned int) au.s.low < (unsigned int) bu.s.low)
-   return 0;
-   else if ((unsigned int) au.s.low > (unsigned int) bu.s.low)
-   return 2;
-
-   return 1;
-}
-
-EXPORT_SYMBOL(__cmpdi2);

Re: general protection fault in try_to_wake_up

[Petr Mladek]

On Tue 2018-04-03 11:13:33, Peter Zijlstra wrote:
> On Tue, Apr 03, 2018 at 10:50:03AM +0200, Petr Mladek wrote:
> > raw_spin_lock() succeeded here. Therefore lockdep was still working
> > at this stage.
> 
> What does the success of raw_spin_lock() have to do with lockdep ?

It means that also lockdep succeeded there. Therefore the general
protection fault in __lock_acquire() was specific to the spinlock
taken by try_to_wake_up(). I though that it might had been an useful
information.

Anyway, the other replay from Dmitry suggested that it was a known
bug, see
https://lkml.kernel.org/r/CACT4Y+ZJ2QD7MPy4hB-M=mz2LuVu3bRbLg1QdY=z=+su1qw...@mail.gmail.com

Best Regards,
Petr

Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role

[Maxime Ripard]

Hi,

On Thu, Mar 29, 2018 at 01:57:24PM +0200, Paul Kocialkowski wrote:
> On Thu, 2018-03-29 at 11:23 +0200, Maxime Ripard wrote:
> > On Wed, Mar 28, 2018 at 11:52:13PM +0200, Paul Kocialkowski wrote:
> > > This allows dual-role ports to be reported as having gadget mode by
> > > the
> > > musb_has_gadget helper. This is required to enable MUSB at all with
> > > MUSB
> > > glue layers that set the port mode to MUSB_PORT_MODE_DUAL_ROLE at
> > > init.
> > > 
> > > Most notably, this allows calling musb_start when needed in the
> > > virtual
> > > MUSB root HUB, regardless of whether the current mode should be
> > > gadget
> > > or host.
> > > 
> > > This fixes USB OTG on Allwinner devices that I could test it with,
> > > mainly A20 devices.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > 
> > Surely there's more to it than that. The gadget mode of A20 boards
> > have been working in the past, including when compiling with mUSB
> > setup as dual role.
> >
> > Is this a regression since a particular commit? Or is there another,
> > deeper issue overlooked in the commit log?
> 
> The root of the issue here is that musb_start is not called at any point
> without this patch. My understanding of the flow is the following: when
> the PHY detects that there was a VBUS/ID change, it will notify its
> listeners (mainly the musb sunxi glue layer). This will then schedule
> the driver's work (sunxi_musb_work), which does nothing since the
> SUNXI_MUSB_FL_ENABLED bit was never set. This bit is only set after
> calling sunxi_musb_enable, which is called from musb_platform_enable,
> that originates from musb_start.
> 
> Currently I see two places where musb_start is called:
> * musb_virthub
> * musb_gadget
> 
> In the latter case, it is in turn called from udc_start, which should
> probably (correct me if I'm wrong) happen later in the call chain than
> ID/VBUS change notification time.
> 
> In the former case, musb_start is called in the root controller hub
> control, when setting the USB_PORT_FEAT_POWER feature. This looks
> perfectly legit and IMO this is where it should be initially calling
> musb_start in the dual role case. The kernel is indeed setting the
> feature, only that it fails to enable musb without this patch.
> 
> First, I'd like to make sure that this understanding of the flow is
> correct as I may have missed something here. Does it make sense?
> 
> Then, it seems that the offending commit is: be9d39881fc4f
> ("usb: musb: host: rely on port_mode to call musb_start()")
> 
> That itself fixed: ae44df2e21b5
> ("usb: musb: call musb_start() only once in OTG mode")
> 
> Still, this commit was authored in June 2015, so almost 3 years ago.
> In the meantime, the sunxi driver has received feature improvements, so
> it seems hard to believe that it was broken all this time...

I'm not that knowlegdeable about the musb driver, so I can't really
comment on whether what you're saying actually makes sense, but from
what you seem to say, the issue is just happening upon VBUS / ID
notification.

Have you tested without the role switching? For example, trying to
boot while acting as a gadget?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Tue, Apr 03, 2018 at 03:41:22PM +1000, Stephen Rothwell wrote:

> Caused by commit
> 
>   9b8cce52c4b5 ("sched/wait: Remove the wait_on_atomic_t() API")
> 
> interacting with commits
> 
>   d3be4d244330 ("xrpc: Fix potential call vs socket/net destruction race")
>   31f5f9a1691e ("rxrpc: Fix apparent leak of rxrpc_local objects")
> 
> from the net-next tree.
> 
> Haven't we figured out how to remove/change APIs yet? :-(

I figured that since there were only a handful of users it wasn't a
popular API, also David very much knew of those patches changing it so
could easily have pulled in the special tip/sched/wait branch :/

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Jani Nikula]

On Fri, 30 Mar 2018, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in DRM_ERROR error message text

Thanks for the patch.

Please do consider limiting the distribution in the future,
though. There's no need to include lkml or even dri-devel for trivial
patches like this.

Thanks,
Jani.

>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e42a28e3adc5..1df1c91b6ae5 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
> amdgpu_device *adev)
>   break;
>  #endif
>   default:
> - DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> + DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
>   goto fail;
>   }
>  
> @@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle)
>   break;
>  #endif
>   default:
> - DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> + DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
>   return -EINVAL;
>   }

-- 
Jani Nikula, Intel Open Source Technology Center

Re: general protection fault in __mem_cgroup_free

[Michal Hocko]

[CC Andrey]

On Sat 31-03-18 13:47:05, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=8a5de3cce7cdc70e9ebe
> 
> So far this crash happened 14 times on upstream.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5578311367393280
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5708657048158208
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=6693821748346880
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> RBP: 006dcc20 R08: 0002 R09: 3335
> R10:  R11: 0246 R12: 0030656c69662f2e
> R13: 7f1747954d80 R14:  R15: 0006
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 4422 Comm: syzkaller101598 Not tainted 4.16.0-rc7+ #372
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:free_mem_cgroup_per_node_info mm/memcontrol.c:4111 [inline]
> RIP: 0010:__mem_cgroup_free+0x71/0x110 mm/memcontrol.c:4120

Is this a real bug or a KASAN false positive? The RIP points at
free_percpu(pn->lruvec_stat_cpu);

Which can be NULL if we are failing to allocate per-node data in
mem_cgroup_alloc. You stack unwinder seems to point to
mem_cgroup_css_alloc->mem_cgroup_free though and that one cannot see
NULL memcg->nodeinfo[node] AFAICS.

Even if this is really mem_cgroup_alloc path then calling free_percpu
with NULL pointer should be OK. Or am I missing something?

> RSP: 0018:8801accf75a8 EFLAGS: 00010206
> RAX: 0011 RBX:  RCX: 8310cdfd
> RDX:  RSI: 0040 RDI: 0088
> RBP: 8801accf75c8 R08:  R09: 8801accf73a0
> R10:  R11:  R12: 
> R13: 8801ad210d40 R14: dc00 R15: 8801ad210d40
> FS:  7f1747955700() GS:8801db00() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0046 CR3: 0001cb367004 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  mem_cgroup_free mm/memcontrol.c:4128 [inline]
>  mem_cgroup_css_alloc+0x403/0x19c0 mm/memcontrol.c:4239
>  css_create kernel/cgroup/cgroup.c:4729 [inline]
>  cgroup_apply_control_enable+0x44d/0xbc0 kernel/cgroup/cgroup.c:2916
>  cgroup_mkdir+0x56f/0xfc0 kernel/cgroup/cgroup.c:4938
>  kernfs_iop_mkdir+0x153/0x1e0 fs/kernfs/dir.c:1099
>  vfs_mkdir+0x390/0x600 fs/namei.c:3800
>  SYSC_mkdirat fs/namei.c:3823 [inline]
>  SyS_mkdirat+0x22b/0x2b0 fs/namei.c:3807
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x44a0c9
> RSP: 002b:7f1747954d78 EFLAGS: 0246 ORIG_RAX: 0102
> RAX: ffda RBX: 006dcc24 RCX: 0044a0c9
> RDX: 0020 RSI: 2280 RDI: 0005
> RBP: 006dcc20 R08: 0002 R09: 3335
> R10:  R11: 0246 R12: 0030656c69662f2e
> R13: 7f1747954d80 R14:  R15: 0006
> Code: 00 00 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 85 99 00 00 00 4f 8b a4
> e5 f0 09 00 00 49 8d bc 24 88 00 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 30 00
> 0f 85 88 00 00 00 49 8b bc 24 88 00 00 00 e8 77
> RIP: free_mem_cgroup_per_node_info mm/memcontrol.c:4111 [inline] RSP:
> 8801accf75a8
> RIP: __mem_cgroup_free+0x71/0x110 mm/memcontrol.c:4120 RSP: 8801accf75a8
> ---[ end trace 57ac07c30502ef78 ]---
> Kernel panic - not syncing: Fatal exception
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Julia Lawall]

On Tue, 3 Apr 2018, Jani Nikula wrote:

> On Fri, 30 Mar 2018, Colin King  wrote:
> > From: Colin Ian King 
> >
> > Trivial fix to spelling mistake in DRM_ERROR error message text
>
> Thanks for the patch.
>
> Please do consider limiting the distribution in the future,
> though. There's no need to include lkml or even dri-devel for trivial
> patches like this.

It's complex to have to remember the preferences for every subsystem.
Preferences should be expressed in the MAINTAINERS file in some way.
Also, since no one reads lkml, does it hurt to have even trivial patches?

julia

>
> Thanks,
> Jani.
>
> >
> > Signed-off-by: Colin Ian King 
> > ---
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index e42a28e3adc5..1df1c91b6ae5 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
> > amdgpu_device *adev)
> > break;
> >  #endif
> > default:
> > -   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> > +   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
> > goto fail;
> > }
> >
> > @@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle)
> > break;
> >  #endif
> > default:
> > -   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
> > +   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
> > return -EINVAL;
> > }
>
> --
> Jani Nikula, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: general protection fault in __mem_cgroup_free

[Michal Hocko]

On Tue 03-04-18 11:37:33, Michal Hocko wrote:
> [CC Andrey]
> 
> On Sat 31-03-18 13:47:05, syzbot wrote:
> > Hello,
> > 
> > syzbot hit the following crash on upstream commit
> > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> > Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=8a5de3cce7cdc70e9ebe
> > 
> > So far this crash happened 14 times on upstream.
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5578311367393280
> > syzkaller reproducer:
> > https://syzkaller.appspot.com/x/repro.syz?id=5708657048158208
> > Raw console output:
> > https://syzkaller.appspot.com/x/log.txt?id=6693821748346880
> > Kernel config:
> > https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
> > compiler: gcc (GCC) 7.1.1 20170620
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > RBP: 006dcc20 R08: 0002 R09: 3335
> > R10:  R11: 0246 R12: 0030656c69662f2e
> > R13: 7f1747954d80 R14:  R15: 0006
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault:  [#1] SMP KASAN
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > Modules linked in:
> > CPU: 0 PID: 4422 Comm: syzkaller101598 Not tainted 4.16.0-rc7+ #372
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:free_mem_cgroup_per_node_info mm/memcontrol.c:4111 [inline]
> > RIP: 0010:__mem_cgroup_free+0x71/0x110 mm/memcontrol.c:4120
> 
> Is this a real bug or a KASAN false positive? The RIP points at
> free_percpu(pn->lruvec_stat_cpu);
> 
> Which can be NULL if we are failing to allocate per-node data in
> mem_cgroup_alloc. You stack unwinder seems to point to
> mem_cgroup_css_alloc->mem_cgroup_free though and that one cannot see
> NULL memcg->nodeinfo[node] AFAICS.
> 
> Even if this is really mem_cgroup_alloc path then calling free_percpu
> with NULL pointer should be OK. Or am I missing something?

Scratch that. The bug is real. We can have memcg->nodeinfo[node] =
NULL from mem_cgroup_alloc. It uses the same failure path as the pcp
allocation failure.

This should fix it. I will send the full patch with proper changelog
shortly
---
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e3d5a0a7917f..0a9c4d5194f3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4340,6 +4340,9 @@ static void free_mem_cgroup_per_node_info(struct 
mem_cgroup *memcg, int node)
 {
struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
 
+   if (!pn)
+   return;
+
free_percpu(pn->lruvec_stat_cpu);
kfree(pn);
 }
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA software controller

[Thomas Gleixner]

On Thu, 29 Mar 2018, Vikas Shivappa wrote:
> +Memory bandwidth(b/w) in MegaBytes
> +--
> +
> +Memory bandwidth is a core specific mechanism which means that when the
> +Memory b/w percentage is specified in the schemata per package it
> +actually is applied on a per core basis via IA32_MBA_THRTL_MSR
> +interface. This may lead to confusion in scenarios below:
> +
> +1. User may not see increase in actual b/w when percentage values are
> +   increased:
> +
> +This can occur when aggregate L2 external b/w is more than L3 external
> +b/w. Consider an SKL SKU with 24 cores on a package and where L2
> +external b/w is 10GBps (hence aggregate L2 external b/w is 240GBps) and
> +L3 external b/w is 100GBps. Now a workload with '20 threads, having 50%
> +b/w, each consuming 5GBps' consumes the max L3 b/w of 100GBps although
> +the percentage value specified is only 50% << 100%. Hence increasing
> +the b/w percentage will not yeild any more b/w. This is because
> +although the L2 external b/w still has capacity, the L3 external b/w
> +is fully used. Also note that this would be dependent on number of
> +cores the benchmark is run on.
> +
> +2. Same b/w percentage may mean different actual b/w depending on # of
> +   threads:
> +
> +For the same SKU in #1, a 'single thread, with 10% b/w' and '4 thread,
> +with 10% b/w' can consume upto 10GBps and 40GBps although they have same
> +percentage b/w of 10%. This is simply because as threads start using
> +more cores in an rdtgroup, the actual b/w may increase or vary although
> +user specified b/w percentage is same.
> +
> +In order to mitigate this and make the interface more user friendly, we
> +can let the user specify the max bandwidth per rdtgroup in bytes(or mega
> +bytes). The kernel underneath would use a software feedback mechanism or
> +a "Software Controller" which reads the actual b/w using MBM counters
> +and adjust the memowy bandwidth percentages to ensure the "actual b/w
> +< user b/w".
> +
> +The legacy behaviour is default and user can switch to the "MBA software
> +controller" mode using a mount option 'mba_MB'.

You said above:

> This may lead to confusion in scenarios below:

Reading the blurb after that creates even more confusion than being
helpful.

First of all this information should not be under the section 'Memory
bandwidth in MB/s'.

Also please write bandwidth. The weird acronym b/w (band per width???) is
really not increasing legibility. 

What you really want is a general section about memory bandwidth allocation
where you explain the technical background in purely technical terms w/o
fairy tale mode. Technical descriptions have to be factual and not
'could/may/would'. 

If I decode the above correctly then the current percentage based
implementation was buggy from the very beginning in several ways.

Now the obvious question which is in no way answered by the cover letter is
why the current percentage based implementation cannot be fixed and we need
some feedback driven magic to achieve that. I assume you spent some brain
cycles on that question, so it would be really helpful if you shared that.

If I understand it correctly then the problem is that the throttling
mechanism is per core and affects the L2 external bandwidth.

  Is this really per core? What about hyper threads. Both threads have that
  MSR. How is that working?

The L2 external bandwidth is higher than the L3 external bandwidth.

  Is there any information available from CPUID or whatever source which
  allows us to retrieve the bandwidth ratio or the absolute maximum
  bandwidth per level?

What's also missing from your explanation is how that feedback loop behaves
under different workloads.

  Is this assuming that the involved threads/cpus actually try to utilize
  the bandwidth completely?

  What happens if the threads/cpus are only using a small set because they
  are idle or their computations are mostly cache local and do not need
  external bandwidth? Looking at the implementation I don't see how that is
  taken into account.

Thanks,

tglx

Re: [PATCH 1/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Daniel Vetter]

On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> +static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj)
> +{
> + grant_ref_t priv_gref_head;
> + int ret, j, cur_ref, num_pages;
> + struct sg_page_iter sg_iter;
> +
> + ret = gnttab_alloc_grant_references(xen_obj->num_pages,
> + &priv_gref_head);
> + if (ret < 0) {
> + DRM_ERROR("Cannot allocate grant references\n");
> + return ret;
> + }
> +
> + j = 0;
> + num_pages = xen_obj->num_pages;
> + for_each_sg_page(xen_obj->sgt->sgl, &sg_iter, xen_obj->sgt->nents, 0) {
> + struct page *page;
> +
> + page = sg_page_iter_page(&sg_iter);

Quick drive-by: You can't assume that an sgt is struct page backed.

And you probably want to check this at import/attach time.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [GIT PULL] x86/build changes for v4.17

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote:
> > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar  wrote:
> > >
> > > The biggest change is the forcing of asm-goto support on x86, which 
> > > effectively
> > > increases the GCC minimum supported version to gcc-4.5 (on x86).
> > 
> > So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves
> > to be forced, or can stay with old kernels).
> > 
> > No, my biggest worry is clang. What's the status there?
> > 
> > I've pulled this, and honestly, the disaster with
> > -fmerge-all-constants makes me think that clang isn't that good a
> > compiler choice anyway, but it's sad if this undoes a lot of clang
> > work just because of the worries about Spectre and mis-speculated
> > branches.
> 
> It's not just spectre, I believe you yourself wanted to use asm-goto
> somewhere in the x86 code:
> 
>   
> http://lkml.kernel.org/r/CA+55aFyCp-9Qqjcn9wp=vdp2ko7tfyuumjxvkc75xxu0web...@mail.gmail.com
> 
> There was some KVM talk of relying on it here:
> 
>   http://lkml.kernel.org/r/6a5f2453-cf51-d491-db54-5f239caa2...@redhat.com
> 
> And there's the comment here:
> 
>   
> https://elixir.bootlin.com/linux/v4.16-rc7/source/arch/x86/kvm/emulate.c#L457
> 
> As to the suitablility of using clang, there's also this unresolved
> issue:
> 
>   http://lkml.kernel.org/r/20180321211931.ga111...@google.com
> 
> The fact that even without asm-goto they cannot correctly compile a
> kernel and have sat on their hands regarding asm-goto for the past 7 odd
> years makes me care very little.
> 
> And since they need to spin a new version of the compiler with all the
> various bugs fixed, they might as well include asm-goto in that and be
> done with it.

So there's really two questions here:

 - This asm-goto change only impacts x86, is there any production x86 kernel 
being
   built with Clang? I think the Pixel kernel is built with Clang, but that's 
ARM.

 - Is there anyone on the Clang side _actually_ bending metal and working on 
   asm-goto support, with something like very early alpha test patches 
available, 
   etc.? Last I saw the communicated Clang POV was still that they wanted to do 
   something "better" (and incompatible to ...) asm-goto. Has this changed?

If it's being relied on, or if there's actually something firmly planned,
which we could track, then I'd have no problem with reverting this change
and waiting one more kernel cycle or so.

Thanks,

Ingo

Re: possible deadlock in skb_queue_tail

[Kirill Tkhai]

On 02.04.2018 12:20, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on net-next commit
> 06b19fe9a6df7aaa423cd8404ebe5ac9ec4b2960 (Sun Apr 1 03:37:33 2018 +)
> Merge branch 'chelsio-inline-tls'
> syzbot dashboard link: 
> https://syzkaller.appspot.com/bug?extid=6b495100f17ca8554ab9
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output: 
> https://syzkaller.appspot.com/x/log.txt?id=6218830443446272
> Kernel config: https://syzkaller.appspot.com/x/.config?id=3327544840960562528
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6b495100f17ca8554...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
> 
> 
> ==
> WARNING: possible circular locking dependency detected
> 4.16.0-rc6+ #290 Not tainted
> --
> syz-executor7/20971 is trying to acquire lock:
>  (&af_unix_sk_receive_queue_lock_key){+.+.}, at: [<271ef0d8>] 
> skb_queue_tail+0x26/0x150 net/core/skbuff.c:2899
> 
> but task is already holding lock:
>  (&(&u->lock)->rlock/1){+.+.}, at: [<4e725e14>] 
> unix_state_double_lock+0x7b/0xb0 net/unix/af_unix.c:1088
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (&(&u->lock)->rlock/1){+.+.}:
>    _raw_spin_lock_nested+0x28/0x40 kernel/locking/spinlock.c:354
>    sk_diag_dump_icons net/unix/diag.c:82 [inline]
>    sk_diag_fill.isra.4+0xa52/0xfe0 net/unix/diag.c:144
>    sk_diag_dump net/unix/diag.c:178 [inline]
>    unix_diag_dump+0x400/0x4f0 net/unix/diag.c:206
>    netlink_dump+0x492/0xcf0 net/netlink/af_netlink.c:2221
>    __netlink_dump_start+0x4ec/0x710 net/netlink/af_netlink.c:2318
>    netlink_dump_start include/linux/netlink.h:214 [inline]
>    unix_diag_handler_dump+0x3e7/0x750 net/unix/diag.c:307
>    __sock_diag_cmd net/core/sock_diag.c:230 [inline]
>    sock_diag_rcv_msg+0x204/0x360 net/core/sock_diag.c:261
>    netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2443
>    sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:272
>    netlink_unicast_kernel net/netlink/af_netlink.c:1307 [inline]
>    netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1333
>    netlink_sendmsg+0xa4a/0xe80 net/netlink/af_netlink.c:1896
>    sock_sendmsg_nosec net/socket.c:629 [inline]
>    sock_sendmsg+0xca/0x110 net/socket.c:639
>    sock_write_iter+0x31a/0x5d0 net/socket.c:908
>    call_write_iter include/linux/fs.h:1782 [inline]
>    new_sync_write fs/read_write.c:469 [inline]
>    __vfs_write+0x684/0x970 fs/read_write.c:482
>    vfs_write+0x189/0x510 fs/read_write.c:544
>    SYSC_write fs/read_write.c:589 [inline]
>    SyS_write+0xef/0x220 fs/read_write.c:581
>    do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>    entry_SYSCALL_64_after_hwframe+0x42/0xb7
> 
> -> #0 (&af_unix_sk_receive_queue_lock_key){+.+.}:
>    lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
>    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>    _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
>    skb_queue_tail+0x26/0x150 net/core/skbuff.c:2899
>    unix_dgram_sendmsg+0xa30/0x1610 net/unix/af_unix.c:1807
>    sock_sendmsg_nosec net/socket.c:629 [inline]
>    sock_sendmsg+0xca/0x110 net/socket.c:639
>    ___sys_sendmsg+0x320/0x8b0 net/socket.c:2047
>    __sys_sendmmsg+0x1ee/0x620 net/socket.c:2137
>    SYSC_sendmmsg net/socket.c:2168 [inline]
>    SyS_sendmmsg+0x35/0x60 net/socket.c:2163
>    do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>    entry_SYSCALL_64_after_hwframe+0x42/0xb7

sk_diag_dump_icons() dumps only sockets in TCP_LISTEN state.
TCP_LISTEN state may be assigned in only place in net/unix/af_unix.c:
it's unix_listen(). The function is applied to stream and seqpacket
socket types.

It can't be stream because of the second stack, and seqpacket also can't,
as I don't think it's possible for gcc to inline unix_seqpacket_sendmsg()
in the way, we don't see it in the stack.

So, this is looks like false positive result for me.

Kirill

> 
> other info that might help us debug this:
> 
>  Possible unsafe locking scenario:
> 
>    CPU0    CPU1
>        
>   lock(&(&u->lock)->rlock/1);
>    lock(&af_unix_sk_receive_queue_lock_key);
>    lock(&(&u->lock)->rlock/1);
>   lock(&af_unix_sk_receive_queue_lock_key);
> 
>  *** DEADLOCK ***
> 
> 1 lock held by syz-executor7/20971:
>  #0:  (&(&u->lock)->rlock/1){+.+.}, at: [<4e725e14>] 
> unix_state_double_lock+0x7b/0xb0 net/unix/af_unix.c

Re: [PATCH 3/6] x86/intel_rdt/mba_sc: Add initialization support

[Thomas Gleixner]

On Thu, 29 Mar 2018, Vikas Shivappa wrote:
> +void setup_ctrlval(struct rdt_resource *r, u32 *dc, u32 *dm)
> +{
> + int i;
> +
> + /*
> +  * Initialize the Control MSRs to having no control.
> +  * For Cache Allocation: Set all bits in cbm
> +  * For Memory Allocation: Set b/w requested to 100%
> +  * and the b/w in MB to U32_MAX
> +  */
> + for (i = 0; i < r->num_closid; i++, dc++, dm++) {
> + *dc = r->membw.bw_byte ? MBA_BW_MAX_MB : r->default_ctrl;
> + *dm = r->default_ctrl;

No! Please stop duct taping your stuff into the existing code. So far the
ctrl value was the same as the value which was actually written into the
MSR. With your new mode you have to split that up into the user supplied
value and the value which gets written into the MSR.

So the right thing to do is to separate the user value and the MSR value
first and independent of the mode. Then the new mode falls into place
naturally because r->default_ctrl and r->default_msrval are set up at mount
time with the values which correspond to the mount mode. 

Thanks,

tglx

Re: [v2,2/2] mailbox: add STMicroelectronics STM32 IPCC driver

[Fabien DESSENNE]

Just a gentle ping ... or have I missed out on a reply?


On 12/03/18 11:58, Fabien DESSENNE wrote:
> The STMicroelectronics STM32 Inter-Processor Communication Controller
> (IPCC) is used for communicating data between two processors.
> It provides a non blocking signaling mechanism to post and retrieve
> communication data in an atomic way.
>
> Signed-off-by: Fabien Dessenne 
> Signed-off-by: Ludovic Barre 
> ---
>   drivers/mailbox/Kconfig  |   8 +
>   drivers/mailbox/Makefile |   2 +
>   drivers/mailbox/stm32-ipcc.c | 403 
> +++
>   3 files changed, 413 insertions(+)
>   create mode 100644 drivers/mailbox/stm32-ipcc.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index ba2f152..d7581f0 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -171,4 +171,12 @@ config BCM_FLEXRM_MBOX
> Mailbox implementation of the Broadcom FlexRM ring manager,
> which provides access to various offload engines on Broadcom
> SoCs. Say Y here if you want to use the Broadcom FlexRM.
> +
> +config STM32_IPCC
> + tristate "STM32 IPCC Mailbox"
> + depends on MACH_STM32MP157
> + help
> +   Mailbox implementation for STMicroelectonics STM32 family chips
> +   with hardware for Inter-Processor Communication Controller (IPCC)
> +   between processors. Say Y here if you want to have this support.
>   endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index 4896f8d..7ea9654 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -36,3 +36,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX)   += bcm-flexrm-mailbox.o
>   obj-$(CONFIG_QCOM_APCS_IPC) += qcom-apcs-ipc-mailbox.o
>   
>   obj-$(CONFIG_TEGRA_HSP_MBOX)+= tegra-hsp.o
> +
> +obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
> diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
> new file mode 100644
> index 000..fa3cc59
> --- /dev/null
> +++ b/drivers/mailbox/stm32-ipcc.c
> @@ -0,0 +1,403 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
> + * Authors: Ludovic Barre  for STMicroelectronics.
> + *  Fabien Dessenne  for STMicroelectronics.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IPCC_XCR 0x000
> +#define XCR_RXOIEBIT(0)
> +#define XCR_TXOIEBIT(16)
> +
> +#define IPCC_XMR 0x004
> +#define IPCC_XSCR0x008
> +#define IPCC_XTOYSR  0x00c
> +
> +#define IPCC_PROC_OFFST  0x010
> +
> +#define IPCC_HWCFGR  0x3f0
> +#define IPCFGR_CHAN_MASK GENMASK(7, 0)
> +
> +#define IPCC_VER 0x3f4
> +#define VER_MINREV_MASK  GENMASK(3, 0)
> +#define VER_MAJREV_MASK  GENMASK(7, 4)
> +
> +#define RX_BIT_MASK  GENMASK(15, 0)
> +#define RX_BIT_CHAN(chan)BIT(chan)
> +#define TX_BIT_SHIFT 16
> +#define TX_BIT_MASK  GENMASK(31, 16)
> +#define TX_BIT_CHAN(chan)BIT(TX_BIT_SHIFT + (chan))
> +
> +#define STM32_MAX_PROCS  2
> +
> +enum {
> + IPCC_IRQ_RX,
> + IPCC_IRQ_TX,
> + IPCC_IRQ_NUM,
> +};
> +
> +struct stm32_ipcc {
> + struct mbox_controller controller;
> + void __iomem *reg_base;
> + void __iomem *reg_proc;
> + struct clk *clk;
> + int irqs[IPCC_IRQ_NUM];
> + int wkp;
> + u32 proc_id;
> + u32 n_chans;
> + u32 xcr;
> + u32 xmr;
> +};
> +
> +static inline void stm32_ipcc_set_bits(void __iomem *reg, u32 mask)
> +{
> + writel_relaxed(readl_relaxed(reg) | mask, reg);
> +}
> +
> +static inline void stm32_ipcc_clr_bits(void __iomem *reg, u32 mask)
> +{
> + writel_relaxed(readl_relaxed(reg) & ~mask, reg);
> +}
> +
> +static irqreturn_t stm32_ipcc_rx_irq(int irq, void *data)
> +{
> + struct stm32_ipcc *ipcc = data;
> + struct device *dev = ipcc->controller.dev;
> + u32 status, mr, tosr, chan;
> + irqreturn_t ret = IRQ_NONE;
> + int proc_offset;
> +
> + /* read 'channel occupied' status from other proc */
> + proc_offset = ipcc->proc_id ? -IPCC_PROC_OFFST : IPCC_PROC_OFFST;
> + tosr = readl_relaxed(ipcc->reg_proc + proc_offset + IPCC_XTOYSR);
> + mr = readl_relaxed(ipcc->reg_proc + IPCC_XMR);
> +
> + /* search for unmasked 'channel occupied' */
> + status = tosr & FIELD_GET(RX_BIT_MASK, ~mr);
> +
> + for (chan = 0; chan < ipcc->n_chans; chan++) {
> + if (!(status & (1 << chan)))
> + continue;
> +
> + dev_dbg(dev, "%s: chan:%d rx\n", __func__, chan);
> +
> + mbox_chan_received_data(&ipcc->controller.chans[chan], NULL);
> +
> + stm32_ipcc_set_bits(ipcc->reg_proc + IPCC_XSCR,
> + RX_BIT_CHAN(chan));
> +
> + ret = IRQ_HANDLED;
> + }
> +
> + return ret;
> +}
> +
> +static irq

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

[Cornelia Huck]

On Tue, 27 Mar 2018 16:45:02 +0200
Pierre Morel  wrote:

> On 27/03/2018 13:17, Cornelia Huck wrote:
> > On Thu, 15 Mar 2018 13:25:25 -0400
> > Tony Krowiak  wrote:
> >  
> >> On 03/15/2018 09:25 AM, Pierre Morel wrote:  
> >>> On 14/03/2018 19:25, Tony Krowiak wrote:  
>  +config VFIO_AP
>  +def_tristate m  
> >>> not sure it must be module by default.
> >>> I would not set it by default.  
> >> Connie also asked about this in the last review, so I will go ahead
> >> and change it.  
> >>> 
>  +prompt "VFIO support for AP devices"
>  +depends on ZCRYPT && VFIO_MDEV_DEVICE  
> >>> VFIO_MDEV_DEVICE is a general feature *needed* by VFIO_AP
> >>> and has no use case by its own. If it is set it is obviously because some
> >>> mediated device drivers needs it.
> >>> while ZCRYPT is a Z feature which may be set without VFIO_AP.
> >>>
> >>> So you need:
> >>>
> >>> config VFIO_AP
> >>>  def_tristate n
> >>>  prompt "VFIO support for AP devices"
> >>>  depends on ZCRYPT
> >>>  select VFIO_MDEV
> >>>  select VFIO_MDEV_DEVICE
> >>> ...  
> >> I was thinking the same just yesterday and I agree, this makes sense.  
> > OTOH, nobody else seems to do a select on these symbols so far.
> >
> > If you decide to go that route, you'll also need to depend on VFIO  
> 
> I think a select is better (again).
> 
> > (otherwise you could end up selecting symbols with unmet dependencies).
> > All in all, I prefer the 'depends' approach.
> >  
> Why do you prefer this approach?

Hm, I thought I had already written a mail, but apparently I didn't
 
> I can tell you why I prefer a mixed approach:
> 
> We have two tools, depends and select.
> 
> It seems to me that depends should be used for things we can not choose 
> to be there or not, but things that just are there, like hardware 
> dependencies. For example MMU, CPU type, CRYPTO hardware...
> 
> Select on the other hand is useful to choose things that we need like 
> libraries, VFIO, VIRTIO, crypto libraries etc.
> 
> Using this policy is clear and makes easy to choose functionalities and 
> get the utilities automatically.
> 
> On the other hand, only using depends makes things to hide the 
> functionalities behind the utilities.

My view is the following:
- select is useful for library functionality or for enabling
  architecture-specific optimizations (the HAVE_xxx symbols),
  especially things you don't want the user to deal with. If you select
  something, you need to take care of any dependencies yourself.
- depends is useful for more complex dependencies, and especially
  things you don't want automagically enabled. [In modern menuconfig,
  it is easy to figure out any missing dependencies for a config option
  anyway.]

The mdev infrastructure is too complex to be considered a simple
library IMO (cf. the missing VFIO dependency).

[PATCH] drm/virtio: fix vq wait_event condition

[Gerd Hoffmann]

Wait until we have enough space in the virt queue to actually queue up
our request.  Avoids the guest spinning in case we have a non-zero
amount of free entries but not enough for the request.

Cc: sta...@vger.kernel.org
Reported-by: Alain Magloire 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 48e4f1df6e..020070d483 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -293,7 +293,7 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct 
virtio_gpu_device *vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
if (ret == -ENOSPC) {
spin_unlock(&vgdev->ctrlq.qlock);
-   wait_event(vgdev->ctrlq.ack_queue, vq->num_free);
+   wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= outcnt + 
incnt);
spin_lock(&vgdev->ctrlq.qlock);
goto retry;
} else {
@@ -368,7 +368,7 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device 
*vgdev,
ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
if (ret == -ENOSPC) {
spin_unlock(&vgdev->cursorq.qlock);
-   wait_event(vgdev->cursorq.ack_queue, vq->num_free);
+   wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(&vgdev->cursorq.qlock);
goto retry;
} else {
-- 
2.9.3

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Daniel Lezcano]

On 31/03/2018 19:46, Paul Cercueil wrote:
> Le 2018-03-31 10:10, Daniel Lezcano a écrit :
>> On 29/03/2018 16:52, Paul Cercueil wrote:
>>>
>>>
>>> Le mer. 28 mars 2018 à 18:25, Daniel Lezcano 
>>> a écrit :
 On 28/03/2018 17:15, Paul Cercueil wrote:
>  Le 2018-03-24 07:26, Daniel Lezcano a écrit :
>>  On 18/03/2018 00:29, Paul Cercueil wrote:
>>>  This driver will use the TCU (Timer Counter Unit) present on the
>>> Ingenic
>>>  JZ47xx SoCs to provide the kernel with a clocksource and timers.
>>
>>  Please provide a more detailed description about the timer.
>
>  There's a doc file for that :)

 Usually, when there is a new driver I ask for a description in the
 changelog for reference.

>>  Where is the clocksource ?
>
>  Right, there is no clocksource, just timers.
>
>>  I don't see the point of using channel idx and pwm checking here.
>>
>>  There is one clockevent, why create multiple channels ? Can't you
>> stick
>>  to the usual init routine for a timer.
>
>  So the idea is that we use all the TCU channels that won't be used
> for PWM
>  as timers. Hence the PWM checking. Why is this bad?

 It is not bad but arguable. By checking the channels used by the pwm in
 the code, you introduce an adherence between two subsystems even if it
 is just related to the DT parsing part.

 As it is not needed to have more than one timer in the time framework
 (at least with the same characteristics), the pwm channels check is
 pointless. We can assume the author of the DT file is smart enough to
 prevent conflicts and define a pwm and a timer properly instead of
 adding more code complexity.

 In addition, simplifying the code will allow you to use the timer-of
 code and reduce very significantly the init function.
>>>
>>> That's what I had in my V1 and V2, my DT node for the timer-ingenic
>>> driver
>>> had a "timers" property (e.g. "timers = <4 5>;") to select the channels
>>> that
>>> should be used as timers. Then Rob told me I shouldn't do that, and
>>> instead
>>> detect the channels that will be used for PWM.
>>>
>>
>> [ ... ]
>>
>> How do you specify the channels used for PWM ?
> 
> To detect the channels that will be used as PWM I parse the whole
> devicetree
> searching for "pwms" properties; check that the PWM handle is for our
> TCU PWM
> driver; then read the PWM number from there.
> 
> Of course it's hackish, and it only works for devicetree. I preferred the
> method with the "timers" property.

Do you have a DT portion describing that? Eg somewhere in the kernel's
git tree ?

>From what I understood, we can specify the channel for a pwm but not for
a timer, there is certainly something I'm missing.

>>>
>>>  +config INGENIC_TIMER
>>>  +    bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
>>>  +    depends on MACH_INGENIC || COMPILE_TEST
>>
>>  bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if
>> COMPILE_TEST
>>
>>  Remove the depends MACH_INGENIC.
>
>  This driver is not useful on anything else than Ingenic SoCs, why
> should I
>  remove MACH_INGENIC then?

 For COMPILE_TEST on x86.
>>>
>>> Well that's a logical OR right here, so it will work...
>>
>> Right, I missed the second part of the condition. For consistency
>> reason, we don't add a dependency on the platform. The platform will
>> select it. Look the other timer options and you will see there is no
>> MACH deps. I'm trying consolidating all these options to have same
>> format and hopefully factor them out.
> 
> I'm all for factorisation, but what I dislike with not depending on
> MACH_INGENIC, is that the driver now appears in the menuconfig for
> every arch, even if it only applies to one MIPS SoC.

Can you do the following change?

bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if COMPILE_TEST

so it will appear only when the COMPILE_TEST option is set whatever the
platform which is the purpose of this option to increase compile test
coverage.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 0/5] KVM: x86: hyperv: PV TLB flush for Windows guests

[Roman Kagan]

On Mon, Apr 02, 2018 at 06:10:54PM +0200, Vitaly Kuznetsov wrote:
> This is both a new feature and a bugfix.
> 
> Bugfix description: 
> 
> It was found that Windows 2016 guests on KVM crash when they have > 64
> vCPUs, non-flat topology (>1 core/thread per socket; in case it has >64
> sockets Windows just ignores vCPUs above 64) and Hyper-V enlightenments
> (any) are enabled. The most common error reported is "PAGE FAULT IN
> NONPAGED AREA" but I saw different messages. Apparently, Windows doesn't
> expect to run on a Hyper-V server without PV TLB flush support as there's
> no such Hyper-V servers out there (it's only WS2016 supporting > 64 vCPUs
> AFAIR).
> 
> Adding PV TLB flush support to KVM helps, Windows 2016 guests now boot 
> normally (I tried '-smp 128,sockets=64,cores=1,threads=2' and 
> '-smp 128,sockets=8,cores=16,threads=1' but other topologies should work
> too).
> 
> Feature description:
> 
> PV TLB flush helps a lot when running overcommited. KVM gained support for
> it recently but it is only available for Linux guests. Windows guests use
> emulated Hyper-V interface and PV TLB flush needs to be added there.
> 
> I tested WS2016 guest with 128 vCPUs running on a 12 pCPU server. The test
> was running 64 threads doing 100 mmap()/munmap() for 16384 pages with a
> tiny random nanosleep in between (I used Cygwin. It would be great if
> someone could point me to a good Windows-native TLB trashing test).
> 
> The results are:
> Before:
> real0m44.362s
> user0m1.796s
> sys 6m43.218s
> 
> After:
> real0m24.425s
> user0m1.811s
> sys 0m40.625s
> 
> When running without overcommit (single 12 vCPU guest on 12 pCPU server) the
> results of the same test are very close:
> Before:
> real0m21.237s
> user0m1.531s
> sys 0m19.984s
> 
> After:
> real0m21.082s
> user0m1.546s
> sys 0m20.030s

I vaguely remember Denis Plotnikov (cc-d) did a similar attempt a couple
of years ago.  IIRC the outcome was that win2012r2 (back then) guests
started to also use this mechanism for local tlb flushes via self-IPI,
which led to noticable degradation on certain workloads.

Denis do you have any details to share?

Thanks,
Roman.

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Dan Carpenter]

On Tue, Apr 03, 2018 at 11:41:05AM +0200, Julia Lawall wrote:
> 
> 
> On Tue, 3 Apr 2018, Jani Nikula wrote:
> 
> > On Fri, 30 Mar 2018, Colin King  wrote:
> > > From: Colin Ian King 
> > >
> > > Trivial fix to spelling mistake in DRM_ERROR error message text
> >
> > Thanks for the patch.
> >
> > Please do consider limiting the distribution in the future,
> > though. There's no need to include lkml or even dri-devel for trivial
> > patches like this.
> 
> It's complex to have to remember the preferences for every subsystem.
> Preferences should be expressed in the MAINTAINERS file in some way.
> Also, since no one reads lkml, does it hurt to have even trivial patches?

I always tell people not to CC lkml when there is a smaller subsystem
list which can handle it but Linus said my advice was bad.

regards,
dan carpenter

Re: [PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

[Jani Nikula]

On Tue, 03 Apr 2018, Julia Lawall  wrote:
> On Tue, 3 Apr 2018, Jani Nikula wrote:
>> Please do consider limiting the distribution in the future,
>> though. There's no need to include lkml or even dri-devel for trivial
>> patches like this.
>
> It's complex to have to remember the preferences for every subsystem.
> Preferences should be expressed in the MAINTAINERS file in some way.

They are; it's just that get_maintainer.pl has silly defaults. There's
no reason it should include the full chain from the leaf driver to the
subsystem to the LKML by default, with a bunch of authors and commit
signers on top. Especially so for supported drivers. I'm surprised it
doesn't include Linus by default.

> Also, since no one reads lkml, does it hurt to have even trivial patches?

Heh. Let's just say I care more about dri-devel.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] selftests/ftrace: fix spelling mistake: "tiggers" -> "triggers"

[Dan Carpenter]

On Fri, Mar 30, 2018 at 09:51:21AM -0600, Shuah Khan wrote:
> On 03/29/2018 12:04 PM, Steven Rostedt wrote:
> > On Thu, 29 Mar 2018 11:54:28 -0600
> > Shuah Khan  wrote:
> > 
> >> I will pick this up with your Ack Steve, unless you want include
> >> it in your pull request.
> > 
> > You or Janitors can take it.
> > 
> 
> Okay we can leave it to the Janitors then.
>

There isn't a Janitor tree...

regards,
dan carpenter

 

[PATCH 2/3] mmc: meson-axg: add support for the Meson-AXG platform

[Yixun Lan]

From: Nan Li 

Introduce the compatible data to cover the register offset & mask
change of the eMMC controller in Amlogic's Meson-AXG SoC.

Signed-off-by: Nan Li 
Signed-off-by: Yixun Lan 
---
 drivers/mmc/host/meson-gx-mmc.c | 61 ++---
 1 file changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 4f972b879fe6..56c90542ac29 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -47,15 +47,29 @@
 #define   CLK_CORE_PHASE_MASK GENMASK(9, 8)
 #define   CLK_TX_PHASE_MASK GENMASK(11, 10)
 #define   CLK_RX_PHASE_MASK GENMASK(13, 12)
-#define   CLK_TX_DELAY_MASK GENMASK(19, 16)
-#define   CLK_RX_DELAY_MASK GENMASK(23, 20)
+#define   CLK_V2_TX_DELAY_MASK GENMASK(19, 16)
+#define   CLK_V2_RX_DELAY_MASK GENMASK(23, 20)
+#define   CLK_V2_ALWAYS_ON BIT(24)
+
+#define   CLK_V3_TX_DELAY_MASK GENMASK(21, 16)
+#define   CLK_V3_RX_DELAY_MASK GENMASK(27, 22)
+#define   CLK_V3_ALWAYS_ON BIT(28)
+
 #define   CLK_DELAY_STEP_PS 200
 #define   CLK_PHASE_STEP 30
 #define   CLK_PHASE_POINT_NUM (360 / CLK_PHASE_STEP)
-#define   CLK_ALWAYS_ON BIT(24)
+
+#define   CLK_TX_DELAY_MASK(h) (h->data->tx_delay_mask)
+#define   CLK_RX_DELAY_MASK(h) (h->data->rx_delay_mask)
+#define   CLK_ALWAYS_ON(h) (h->data->always_on)
 
 #define SD_EMMC_DELAY 0x4
 #define SD_EMMC_ADJUST 0x8
+
+#define SD_EMMC_DELAY1 0x4
+#define SD_EMMC_DELAY2 0x8
+#define SD_EMMC_V3_ADJUST 0xc
+
 #define SD_EMMC_CALOUT 0x10
 #define SD_EMMC_START 0x40
 #define   START_DESC_INIT BIT(0)
@@ -122,6 +136,12 @@
 
 #define MUX_CLK_NUM_PARENTS 2
 
+struct meson_mmc_data {
+   unsigned int tx_delay_mask;
+   unsigned int rx_delay_mask;
+   unsigned int always_on;
+};
+
 struct sd_emmc_desc {
u32 cmd_cfg;
u32 cmd_arg;
@@ -131,6 +151,7 @@ struct sd_emmc_desc {
 
 struct meson_host {
struct  device  *dev;
+   struct  meson_mmc_data *data;
struct  mmc_host*mmc;
struct  mmc_command *cmd;
 
@@ -474,7 +495,7 @@ static int meson_mmc_clk_init(struct meson_host *host)
 
/* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
clk_reg = 0;
-   clk_reg |= CLK_ALWAYS_ON;
+   clk_reg |= CLK_ALWAYS_ON(host);
clk_reg |= CLK_DIV_MASK;
writel(clk_reg, host->regs + SD_EMMC_CLOCK);
 
@@ -574,7 +595,7 @@ static int meson_mmc_clk_init(struct meson_host *host)
 
tx->reg = host->regs + SD_EMMC_CLOCK;
tx->phase_mask = CLK_TX_PHASE_MASK;
-   tx->delay_mask = CLK_TX_DELAY_MASK;
+   tx->delay_mask = CLK_TX_DELAY_MASK(host);
tx->delay_step_ps = CLK_DELAY_STEP_PS;
tx->hw.init = &init;
 
@@ -597,7 +618,7 @@ static int meson_mmc_clk_init(struct meson_host *host)
 
rx->reg = host->regs + SD_EMMC_CLOCK;
rx->phase_mask = CLK_RX_PHASE_MASK;
-   rx->delay_mask = CLK_RX_DELAY_MASK;
+   rx->delay_mask = CLK_RX_DELAY_MASK(host);
rx->delay_step_ps = CLK_DELAY_STEP_PS;
rx->hw.init = &init;
 
@@ -1184,6 +1205,13 @@ static int meson_mmc_probe(struct platform_device *pdev)
goto free_host;
}
 
+   host->data = (struct meson_mmc_data *)
+   of_device_get_match_data(&pdev->dev);
+   if (!host->data) {
+   ret = -EINVAL;
+   goto free_host;
+   }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
host->regs = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(host->regs)) {
@@ -1315,11 +1343,24 @@ static int meson_mmc_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct meson_mmc_data meson_gx_data = {
+   .tx_delay_mask  = CLK_V2_TX_DELAY_MASK,
+   .rx_delay_mask  = CLK_V2_RX_DELAY_MASK,
+   .always_on  = CLK_V2_ALWAYS_ON,
+};
+
+static const struct meson_mmc_data meson_axg_data = {
+   .tx_delay_mask  = CLK_V3_TX_DELAY_MASK,
+   .rx_delay_mask  = CLK_V3_RX_DELAY_MASK,
+   .always_on  = CLK_V3_ALWAYS_ON,
+};
+
 static const struct of_device_id meson_mmc_of_match[] = {
-   { .compatible = "amlogic,meson-gx-mmc", },
-   { .compatible = "amlogic,meson-gxbb-mmc", },
-   { .compatible = "amlogic,meson-gxl-mmc", },
-   { .compatible = "amlogic,meson-gxm-mmc", },
+   { .compatible = "amlogic,meson-gx-mmc", .data = &meson_gx_data 
},
+   { .compatible = "amlogic,meson-gxbb-mmc",   .data = &meson_gx_data 
},
+   { .compatible = "amlogic,meson-gxl-mmc",.data = &meson_gx_data 
},
+   { .compatible = "amlogic,meson-gxm-mmc",.data = &meson_gx_data 
},
+   { .compatible = "amlogic,meson-axg-mmc",.data = &meson_axg_data 
},
{}
 };
 MODULE_DEVICE_TABLE(of, meson_mmc_of_match);
-- 
2.16.2

[PATCH 3/3] mmc: meson: update doc to support Meson-AXG platform

[Yixun Lan]

From: Nan Li 

Explicitly update the docomentation to support the Meson-AXG platform.

Signed-off-by: Nan Li 
Signed-off-by: Yixun Lan 
---
 drivers/mmc/host/Kconfig| 4 ++--
 drivers/mmc/host/meson-gx-mmc.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 620c2d90a646..751090d1d94c 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -345,11 +345,11 @@ config MMC_SDHCI_IPROC
  If unsure, say N.
 
 config MMC_MESON_GX
-   tristate "Amlogic S905/GX* SD/MMC Host Controller support"
+   tristate "Amlogic S905/GX*/AXG SD/MMC Host Controller support"
depends on ARCH_MESON && MMC
help
  This selects support for the Amlogic SD/MMC Host Controller
- found on the S905/GX* family of SoCs.  This controller is
+ found on the S905/GX*/AXG family of SoCs.  This controller is
  MMC 5.1 compliant and supports SD, eMMC and SDIO interfaces.
 
  If you have a controller with this interface, say Y here.
diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 56c90542ac29..55bbd67177df 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -1376,6 +1376,6 @@ static struct platform_driver meson_mmc_driver = {
 
 module_platform_driver(meson_mmc_driver);
 
-MODULE_DESCRIPTION("Amlogic S905*/GX* SD/eMMC driver");
+MODULE_DESCRIPTION("Amlogic S905*/GX*/AXG SD/eMMC driver");
 MODULE_AUTHOR("Kevin Hilman ");
 MODULE_LICENSE("GPL v2");
-- 
2.16.2

[PATCH 0/3] mmc: meson-axg: initial support for AXG SoC platform

[Yixun Lan]

   The patches series try to enable basic eMMC support in the Meson-AXG 
platfrom.

   Currently HS200 mode is tested with clock running at 166MHz, since
not all boards are stable to running 200MHz (due to tuning phase error),
we will further improve the tuning phase driver in the future,
but in my opiton, this patch series itself is pretty good to go.

Nan Li (3):
  mmc: dt-bindings: update bindings doc to support Meson-AXG SoC
  mmc: meson-axg: add support for the Meson-AXG platform
  mmc: meson: update doc to support Meson-AXG platform

 .../devicetree/bindings/mmc/amlogic,meson-gx.txt   |  1 +
 drivers/mmc/host/Kconfig   |  4 +-
 drivers/mmc/host/meson-gx-mmc.c| 63 ++
 3 files changed, 55 insertions(+), 13 deletions(-)

-- 
2.16.2

[PATCH 1/3] mmc: dt-bindings: update bindings doc to support Meson-AXG SoC

[Yixun Lan]

From: Nan Li 

Update the documentation to list support for Meson-AXG SoC explicitly.
The new binding string is necessary since this SoC introduce a few
IP difference comparing to previous old generation.

Signed-off-by: Nan Li 
Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt 
b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
index 50bf611a4d2c..5add8d7d855f 100644
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
@@ -12,6 +12,7 @@ Required properties:
   - "amlogic,meson-gxbb-mmc"
   - "amlogic,meson-gxl-mmc"
   - "amlogic,meson-gxm-mmc"
+  - "amlogic,meson-axg-mmc"
 - clocks : A list of phandle + clock-specifier pairs for the clocks listed 
in clock-names.
 - clock-names: Should contain the following:
"core" - Main peripheral bus clock
-- 
2.16.2

Re: [PATCH 4/8] misc: pci_endpoint_test: Add designware EP entry

[Gustavo Pimentel]

Hi Kishon,

On 02/04/2018 06:36, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote:
>> Adds the designware EP device ID entry to pci_endpoint_test driver table
>> to allow this device to be recognize and handle by the pci_endpoint_test
>> driver.
>>
>> Signed-off-by: Gustavo Pimentel 
>> ---
>>  drivers/misc/pci_endpoint_test.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/misc/pci_endpoint_test.c 
>> b/drivers/misc/pci_endpoint_test.c
>> index 320276f..e80c533 100644
>> --- a/drivers/misc/pci_endpoint_test.c
>> +++ b/drivers/misc/pci_endpoint_test.c
>> @@ -632,6 +632,7 @@ static void pci_endpoint_test_remove(struct pci_dev 
>> *pdev)
>>  static const struct pci_device_id pci_endpoint_test_tbl[] = {
>>  { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
>>  { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
>> +{ PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, 0xedda) },
> 
> Add device ids to include/linux/pci_ids.h and use the macro here.

Add device id request sent, as soon as I get a positive confirmation from them
I'll change for the macro. It works for you?

> 
> Thanks
> Kishon
> 

Regards,
Gustavo

[PATCH] display: panel: Add AUO g070vvn01 display support (800x480)

[Lukasz Majewski]

This commit adds support for AUO's 7.0" display.

Signed-off-by: Lukasz Majewski 
---
 .../bindings/display/panel/auo,g070vvn01   | 30 +
 drivers/gpu/drm/panel/panel-simple.c   | 31 ++
 2 files changed, 61 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,g070vvn01

diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01 
b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
new file mode 100644
index ..bd4017362094
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
@@ -0,0 +1,30 @@
+AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,g070vvn01"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX6Q based board
+
+   lcd_panel: lcd-panel {
+   compatible = "auo,g070vvn01";
+   backlight = <&backlight_lcd>;
+   bus-format-override = "rgb565";
+   power-supply = <®_display>;
+
+   port {
+   lcd_panel_in: endpoint {
+   remote-endpoint = <&lcd_display_out>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..62314085b635 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -581,6 +581,34 @@ static const struct panel_desc auo_b133htn01 = {
},
 };
 
+static const struct display_timing auo_g070vvn01_timings = {
+   .pixelclock = { 3330, 34209000, 4500 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 20, 40, 200 },
+   .hback_porch = { 87, 40, 1 },
+   .hsync_len = { 1, 48, 87 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 5, 13, 200 },
+   .vback_porch = { 31, 31, 29 },
+   .vsync_len = { 1, 1, 3 },
+};
+
+static const struct panel_desc auo_g070vvn01 = {
+   .timings = &auo_g070vvn01_timings,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .delay = {
+   .prepare = 200,
+   .enable = 50,
+   .disable = 50,
+   .unprepare = 1000,
+   },
+};
+
 static const struct display_timing auo_g133han01_timings = {
.pixelclock = { 13400, 14120, 14900 },
.hactive = { 1920, 1920, 1920 },
@@ -2049,6 +2077,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
}, {
+   .compatible = "auo,g070vvn01",
+   .data = &auo_g070vvn01,
+   }, {
.compatible = "auo,g133han01",
.data = &auo_g133han01,
}, {
-- 
2.11.0

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

[Herbert Xu]

On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote:
>
> However, as it uses the exact same mechanism of the regular xts-aes-ccree
> but takes the key from another source, I've marked it with a test of
> alg_test_null() on the premise that if the xts-aes-ccree works, so must this.

Well it appears to be stubbed out as cc_is_hw_key always returns
false.

> > Are there other crypto drivers doing this?
> 
> I thought the exact same thing until I ran into a presentation about the s390
> secure keys implementation. I basically imitated their use (or abuse?)
> of the Crypto API
> assuming it is the way to go.
> 
> Take a look at arch/s390/crypto/paes_s390.c

It's always nice to discover code that was never reviewed.

The general approach seems sane though.

> Anyway, if this is not the way to go I'd be more than happy to do whatever
> work is needed to create the right interface.
> 
> PS. I'd be out of the office and away from email access to the coming week, so
> kindly excuse any delay in response.

I think it's fine.  However, I don't really like the idea of everyone
coming up with their own "paes", i.e., your patch's use of "haes".
It should be OK to just use paes for everyone, no?

As to your patch specifically, there is one issue where you're
directly dereferencing the key as a struct.  This is a no-no because
the key may have come from user-space.  You must treat it as a
binary blob.  The s390 code seems to do this correctly.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] usb: dwc3: of-simple: use managed and shared reset control

[Masahiro Yamada]

2018-04-03 17:46 GMT+09:00 Philipp Zabel :
> On Tue, 2018-04-03 at 17:30 +0900, Masahiro Yamada wrote:
>> 2018-04-03 17:00 GMT+09:00 Philipp Zabel :
>> > On Thu, 2018-03-29 at 15:07 +0900, Masahiro Yamada wrote:
>> > > This driver handles the reset control in a common manner; deassert
>> > > resets before use, assert them after use.  There is no good reason
>> > > why it should be exclusive.
>> >
>> > Is this preemptive cleanup, or do you have hardware on the horizon that
>> > shares these reset lines with other peripherals?
>>
>> This patch is necessary for Socionext SoCs.
>>
>> The same reset lines are shared between
>> this dwc3-of_simple and other glue circuits.
>
> Thanks, this is helpful information.
>
>> > > Also, use devm_ for clean-up.
>> > >
>> > > Signed-off-by: Masahiro Yamada 
>> > > ---
>> > >
>> > > CCing Philipp Zabel.
>> > > I see his sob in commit 06c47e6286d5.
>> >
>> > At the time I was concerned with the reset_control_array addition and
>> > didn't look closely at the exclusive vs shared issue.
>> > >  drivers/usb/dwc3/dwc3-of-simple.c | 7 ++-
>> > >  1 file changed, 2 insertions(+), 5 deletions(-)
>> > >
>> > > diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
>> > > b/drivers/usb/dwc3/dwc3-of-simple.c
>> > > index e54c362..bd6ab65 100644
>> > > --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> > > +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> > > @@ -91,7 +91,7 @@ static int dwc3_of_simple_probe(struct platform_device 
>> > > *pdev)
>> > >   platform_set_drvdata(pdev, simple);
>> > >   simple->dev = dev;
>> > >
>> > > - simple->resets = of_reset_control_array_get_optional_exclusive(np);
>> > > + simple->resets = devm_reset_control_array_get_optional_shared(dev);
>> >
>> > From the usage in the driver, it does indeed look like _shared reset
>> > usage is appropriate. I assume that the hardware has no need for the
>> > reset to be asserted right before probe or after remove, it just
>> > requires that the reset line is kept deasserted while the driver is
>> > probed.
>> >
>> > >   if (IS_ERR(simple->resets)) {
>> > >   ret = PTR_ERR(simple->resets);
>> > >   dev_err(dev, "failed to get device resets, err=%d\n", ret);
>> > > @@ -100,7 +100,7 @@ static int dwc3_of_simple_probe(struct 
>> > > platform_device *pdev)
>> > >
>> > >   ret = reset_control_deassert(simple->resets);
>> > >   if (ret)
>> > > - goto err_resetc_put;
>> > > + return ret;
>> > >
>> > >   ret = dwc3_of_simple_clk_init(simple, 
>> > > of_count_phandle_with_args(np,
>> > >   "clocks", "#clock-cells"));
>> > > @@ -126,8 +126,6 @@ static int dwc3_of_simple_probe(struct 
>> > > platform_device *pdev)
>> > >  err_resetc_assert:
>> > >   reset_control_assert(simple->resets);
>> > >
>> > > -err_resetc_put:
>> > > - reset_control_put(simple->resets);
>> > >   return ret;
>> > >  }
>> > >
>> > > @@ -146,7 +144,6 @@ static int dwc3_of_simple_remove(struct 
>> > > platform_device *pdev)
>> > >   simple->num_clocks = 0;
>> > >
>> > >   reset_control_assert(simple->resets);
>> > > - reset_control_put(simple->resets);
>> > >
>> > >   pm_runtime_put_sync(dev);
>> > >   pm_runtime_disable(dev);
>> >
>> > Changing to devm_ changes the order here. Whether or not it could be a
>> > problem to assert the reset only after pm_runtime_put (or potentially
>> > never), I can't say. I assume this is a non-issue, but somebody who
>> > knows the hardware better would have to decide.
>>
>>
>>
>> I do not understand what you mean.
>
> Sorry for the confusion, I have mixed up things here.
>
>> Can you describe your concern in more details?
>>
>> I am not touching reset_control_assert() here.
>
> With the change to shared reset control, reset_control_assert
> potentially does nothing, so it could be possible that
> pm_runtime_put_sync cuts the power before the reset es asserted again.
>
>> I am delaying the call for reset_control_put().
>
> Yes, please disregard my comment about the devm_ change, that should
> have no effect whatsoever and looks fine to me.
>
>> If I understand reset_control_put() correctly,
>> the effects of this change are:
>>   - The ref_count and module ownership for the reset controller
>> driver will be held a little longer
>>   - The call for kfree() will be a little bit delayed.
>
> Correct.
>
>> Why do you need knowledge about this hardware?
>
> Is it ok to keep the reset deasserted while the power is cut?
> Or do you
> have to guarantee that drivers sharing the same reset also keep the same
> power domains active?
>

If this were really a problem, the driver would have to check
the error code from reset_control_assert().


 ret = reset_control_assert(simple->resets);
 if (ret)
   return ret; /* if we cannot assert reset, do not allow
driver detach */

 pm_runtime_put_sync(dev);
 pm_runtime_disable(dev);
 return 0;



What I can tell is, the current situation is
block

Re: [PATCH] genirq: only scan the present CPUs

[Thomas Gleixner]

On Mon, 2 Apr 2018, Li RongQing wrote:

> lots of application will read /proc/stat, like ps and vmstat, but we
> find the reading time are spreading on Purley platform which has lots
> of possible CPUs and interrupt.
> 
> To reduce the reading time, only scan the present CPUs, not all possible
> CPUs, which speeds the reading of /proc/stat 20 times on Purley platform
> which has 56 present CPUs, and 224 possible CPUs

Why is BIOS/ACPI telling the kernel that there are 224 possible CPUs unless
it supports physical CPU hotplug.

Thanks,

tglx

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

[Sergey Suloev]

On 04/03/2018 11:10 AM, Maxime Ripard wrote:

On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote:

There is no need to handle 3/4 empty/full interrupts as the maximum
supported transfer length in PIO mode is 64 bytes for sun4i-family
SoCs.

That assumes that you'll be able to treat the FIFO full interrupt and
drain the FIFO before we have the next byte coming in. This would
require a real time system, and we're not in one of them.

Maxime



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


so you think we should still handle 3/4 FIFO full ?

Re: [PATCH 4.4 076/134] kprobes/x86: Set kprobes pages read-only

[Greg Kroah-Hartman]

On Mon, Apr 02, 2018 at 03:45:57PM +0900, Masami Hiramatsu wrote:
> On Sun, 01 Apr 2018 17:20:30 +0100
> Ben Hutchings  wrote:
> 
> > On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Masami Hiramatsu 
> > > 
> > > 
> > > [ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
> > 
> > This caused a regression in mainline, fixed by:
> > 
> > commit c93f5cf571e7795f97d49ef51b766cf25e328545
> > Author: Masami Hiramatsu 
> > Date:   Thu May 25 19:38:17 2017 +0900
> > 
> > kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
> 
> Thanks Ben,
> Greg, could you please pick above patch too?

Now picked up, thanks.

greg k-h