[PATCH v2] dell-rbtn: constify rfkill_ops structures

2017-06-08 Thread Bhumika Goyal
Add const to rfkill_ops structures that are only passed as an argument
to the functions rfkill_alloc or samsung_new_rfkill. These arguments are
of type const, so such structures can be annotated with const.

Signed-off-by: Bhumika Goyal 
---
Changes since v1:
* Split the changes to one patch per vendor.

 drivers/platform/x86/dell-rbtn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index dcd9f40..6b5bbaf 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -110,7 +110,7 @@ static int rbtn_rfkill_set_block(void *data, bool blocked)
return -EINVAL;
 }
 
-static struct rfkill_ops rbtn_ops = {
+static const struct rfkill_ops rbtn_ops = {
.query = rbtn_rfkill_query,
.set_block = rbtn_rfkill_set_block,
 };
-- 
2.7.4



[PATCH v2] dell-rbtn: constify rfkill_ops structures

2017-06-08 Thread Bhumika Goyal
Add const to rfkill_ops structures that are only passed as an argument
to the functions rfkill_alloc or samsung_new_rfkill. These arguments are
of type const, so such structures can be annotated with const.

Signed-off-by: Bhumika Goyal 
---
Changes since v1:
* Split the changes to one patch per vendor.

 drivers/platform/x86/dell-rbtn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index dcd9f40..6b5bbaf 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -110,7 +110,7 @@ static int rbtn_rfkill_set_block(void *data, bool blocked)
return -EINVAL;
 }
 
-static struct rfkill_ops rbtn_ops = {
+static const struct rfkill_ops rbtn_ops = {
.query = rbtn_rfkill_query,
.set_block = rbtn_rfkill_set_block,
 };
-- 
2.7.4



Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK

2017-06-08 Thread Nicholas A. Bellinger
On Mon, 2017-06-05 at 15:57 +, Bart Van Assche wrote:
> On Sat, 2017-06-03 at 22:10 +, Nicholas A. Bellinger wrote:
> > +static bool target_lookup_lun_from_tag(struct se_session *se_sess, u64 tag,
> > +  u64 *unpacked_lun)
> > +{
> > +   struct se_cmd *se_cmd;
> > +   unsigned long flags;
> > +   bool ret = false;
> > +
> > +   spin_lock_irqsave(_sess->sess_cmd_lock, flags);
> > +   list_for_each_entry(se_cmd, _sess->sess_cmd_list, se_cmd_list) {
> > +   if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB)
> > +   continue;
> > +
> > +   if (se_cmd->tag == tag) {
> > +   *unpacked_lun = se_cmd->orig_fe_lun;
> > +   ret = true;
> > +   break;
> > +   }
> > +   }
> > +   spin_unlock_irqrestore(_sess->sess_cmd_lock, flags);
> > +
> > +   return ret;
> > +}
> > +
> >  /**
> >   * target_submit_tmr - lookup unpacked lun and submit uninitialized se_cmd
> >   * for TMR CDBs
> > @@ -1639,19 +1662,31 @@ int target_submit_tmr(struct se_cmd *se_cmd, struct 
> > se_session *se_sess,
> > core_tmr_release_req(se_cmd->se_tmr_req);
> > return ret;
> > }
> > +   /*
> > +* If this is ABORT_TASK with no explicit fabric provided LUN,
> > +* go ahead and search active session tags for a match to figure
> > +* out unpacked_lun for the original se_cmd.
> > +*/
> > +   if (tm_type == TMR_ABORT_TASK && (flags & 
> > TARGET_SCF_LOOKUP_LUN_FROM_TAG)) {
> > +   if (!target_lookup_lun_from_tag(se_sess, tag, _lun))
> > +   goto failure;
> > +   }
> >  
> > ret = transport_lookup_tmr_lun(se_cmd, unpacked_lun);
> > -   if (ret) {
> > -   /*
> > -* For callback during failure handling, push this work off
> > -* to process context with TMR_LUN_DOES_NOT_EXIST status.
> > -*/
> > -   INIT_WORK(_cmd->work, target_complete_tmr_failure);
> > -   schedule_work(_cmd->work);
> > -   return 0;
> > -   }
> > +   if (ret)
> > +   goto failure;
> > +
> > transport_generic_handle_tmr(se_cmd);
> > return 0;
> 
> Hello Nic,
> 
> So after LUN lookup has finished sess_cmd_lock lock is dropped, a context
> switch occurs due to the queue_work() call in transport_generic_handle_tmr()
> and next core_tmr_abort_task() reacquires that lock? Sorry but I'm afraid
> that if after that lock is dropped and before it is reacquired a command
> finishes and the initiator reuses the same tag for another command for the
> same LUN that this may result in the wrong command being aborted.

This is only getting a unpacked_lun to determine where the incoming
ABORT_TASK should perform a se_lun lookup and percpu ref upon.

The scenario you are talking about would require a tag be reused on the
same session for the same device between when the ABORT_TASK is
dispatched here, and actually processed.

Because qla2xxx doesn't reuse tags, it's not a problem since it's the
only consumer of TARGET_SCF_LOOKUP_LUN_FROM_TAG.

Since Himanshu and Quinn are OK it with, I'm OK with it.

If you have another driver that needs to use this logic where an
ABORT_TASK doesn't know the unpacked_lun to reference, and does reuse
tags then I'd consider a patch for that.



Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK

2017-06-08 Thread Nicholas A. Bellinger
On Mon, 2017-06-05 at 15:57 +, Bart Van Assche wrote:
> On Sat, 2017-06-03 at 22:10 +, Nicholas A. Bellinger wrote:
> > +static bool target_lookup_lun_from_tag(struct se_session *se_sess, u64 tag,
> > +  u64 *unpacked_lun)
> > +{
> > +   struct se_cmd *se_cmd;
> > +   unsigned long flags;
> > +   bool ret = false;
> > +
> > +   spin_lock_irqsave(_sess->sess_cmd_lock, flags);
> > +   list_for_each_entry(se_cmd, _sess->sess_cmd_list, se_cmd_list) {
> > +   if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB)
> > +   continue;
> > +
> > +   if (se_cmd->tag == tag) {
> > +   *unpacked_lun = se_cmd->orig_fe_lun;
> > +   ret = true;
> > +   break;
> > +   }
> > +   }
> > +   spin_unlock_irqrestore(_sess->sess_cmd_lock, flags);
> > +
> > +   return ret;
> > +}
> > +
> >  /**
> >   * target_submit_tmr - lookup unpacked lun and submit uninitialized se_cmd
> >   * for TMR CDBs
> > @@ -1639,19 +1662,31 @@ int target_submit_tmr(struct se_cmd *se_cmd, struct 
> > se_session *se_sess,
> > core_tmr_release_req(se_cmd->se_tmr_req);
> > return ret;
> > }
> > +   /*
> > +* If this is ABORT_TASK with no explicit fabric provided LUN,
> > +* go ahead and search active session tags for a match to figure
> > +* out unpacked_lun for the original se_cmd.
> > +*/
> > +   if (tm_type == TMR_ABORT_TASK && (flags & 
> > TARGET_SCF_LOOKUP_LUN_FROM_TAG)) {
> > +   if (!target_lookup_lun_from_tag(se_sess, tag, _lun))
> > +   goto failure;
> > +   }
> >  
> > ret = transport_lookup_tmr_lun(se_cmd, unpacked_lun);
> > -   if (ret) {
> > -   /*
> > -* For callback during failure handling, push this work off
> > -* to process context with TMR_LUN_DOES_NOT_EXIST status.
> > -*/
> > -   INIT_WORK(_cmd->work, target_complete_tmr_failure);
> > -   schedule_work(_cmd->work);
> > -   return 0;
> > -   }
> > +   if (ret)
> > +   goto failure;
> > +
> > transport_generic_handle_tmr(se_cmd);
> > return 0;
> 
> Hello Nic,
> 
> So after LUN lookup has finished sess_cmd_lock lock is dropped, a context
> switch occurs due to the queue_work() call in transport_generic_handle_tmr()
> and next core_tmr_abort_task() reacquires that lock? Sorry but I'm afraid
> that if after that lock is dropped and before it is reacquired a command
> finishes and the initiator reuses the same tag for another command for the
> same LUN that this may result in the wrong command being aborted.

This is only getting a unpacked_lun to determine where the incoming
ABORT_TASK should perform a se_lun lookup and percpu ref upon.

The scenario you are talking about would require a tag be reused on the
same session for the same device between when the ABORT_TASK is
dispatched here, and actually processed.

Because qla2xxx doesn't reuse tags, it's not a problem since it's the
only consumer of TARGET_SCF_LOOKUP_LUN_FROM_TAG.

Since Himanshu and Quinn are OK it with, I'm OK with it.

If you have another driver that needs to use this logic where an
ABORT_TASK doesn't know the unpacked_lun to reference, and does reuse
tags then I'd consider a patch for that.



[git pull] drm fixes for 4.12-rc5

2017-06-08 Thread Dave Airlie
Hi Linus,

Bit more spread out fixes this time, fixes for 7 drivers + a couple of
core fixes.

i915 and vmwgfx are the main ones. The vmwgfx ones fix a bunch of
regressions in their atomic
rework, and a few fixes destined for stable. i915 has some 4.12
regressions and older things that need to be fixed in stable as well.

nouveau also has some runtime pm fixes and a timer list handling fix,
otherwise a couple of core and small driver regression fixes.

Thanks,
Dave,


The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f:

  Linux 4.12-rc4 (2017-06-04 16:47:43 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc5

for you to fetch changes up to 6e88007e224ce51969ccf9afeec645146c638816:

  Merge branch 'vmwgfx-fixes-4.12' of
git://people.freedesktop.org/~thomash/linux into drm-fixes (2017-06-09
13:12:02 +1000)


intel, nouveau, rockchip, vmwgfx, imx, meson, mediatek and core fixes


Ben Skeggs (3):
  drm/nouveau: replace multiple open-coded runpm support checks
with function
  drm/nouveau: enable autosuspend only when it'll actually be used
  drm/nouveau/tmr: fully separate alarm execution/pending lists

Chris Wilson (4):
  drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle
  drm/i915: Hold a wakeref for probing the ring registers
  drm/i915: Guard against i915_ggtt_disable_guc() being invoked
unconditionally
  drm/i915: Fix logical inversion for gen4 quirking

Colin Ian King (1):
  drm/vmwgfx: fix spelling mistake "exeeds" -> "exceeds"

Dan Carpenter (2):
  drm/mediatek: fix a timeout loop
  drm/vmwgfx: Handle vmalloc() failure in vmw_local_fifo_reserve()

Daniel Vetter (1):
  drm: Fix locking in drm_atomic_helper_resume

Dave Airlie (7):
  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-02' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'imx-drm-fixes-2017-06-08' of
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge branch 'mediatek-drm-fixes-4.12-rc1' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-07' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-06-08' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'vmwgfx-fixes-4.12' of
git://people.freedesktop.org/~thomash/linux into drm-fixes

Gustavo A. R. Silva (1):
  drm/nouveau/kms/nv50: add null check before pointer dereference

Hans de Goede (1):
  drm: Fix oops + Xserver hang when unplugging USB drm devices

Imre Deak (1):
  drm/i915: Prevent the system suspend complete optimization

Jani Nikula (1):
  drm/i915: fix warning for unused variable

John Stultz (1):
  drm: kirin: Fix drm_of_find_panel_or_bridge conversion

Jon Bloomfield (1):
  drm/i915: Serialize GTT/Aperture accesses on BXT

Kai Chen (1):
  drm/i915: Disable decoupled MMIO

Leonard Crestez (1):
  drm/imx: imx-ldb: Accept drm_of_find_panel_or_bridge failure

Lucas Stach (1):
  gpu: ipu-v3: pre: only use internal clock gating

Maarten Lankhorst (1):
  drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

Marek Vasut (1):
  gpu: ipu-v3: Fix CSI selection for VDIC

Mark yao (1):
  drm/rockchip: Correct vop out_mode configure

Michal Wajdeczko (1):
  drm/i915/guc: Remove stale comment for q_fail

Nagaraju, Vathsala (1):
  drm/i915/psr: disable psr2 for resolution greater than 32X20

Neil Armstrong (1):
  drm/meson: Fix driver bind when only CVBS is available

Sinclair Yeh (5):
  drm/vmwgfx: Don't create proxy surface for cursor
  drm/vmwgfx: Make sure backup_handle is always valid
  drm/vmwgfx: Make sure to update STDU when FB is updated
  drm/vmwgfx: Fix large topology crash
  drm/vmwgfx: Remove unused legacy cursor functions

Thomas Hellstrom (1):
  drm/vmwgfx: Bump driver minor and date

Ville Syrjälä (3):
  drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail
  drm/i915: Restore has_fbc=1 for ILK-M
  drm/i915: Fix 90/270 rotated coordinates for FBC

Vladis Dronov (1):
  drm/vmwgfx: limit the number of mip levels in
vmw_gb_surface_define_ioctl()

YYS (1):
  drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake

 drivers/gpu/drm/drm_atomic_helper.c|  11 ++
 drivers/gpu/drm/drm_drv.c  |   7 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c   |   2 +-
 drivers/gpu/drm/i915/i915_drv.c|   9 ++
 drivers/gpu/drm/i915/i915_drv.h|  10 ++
 drivers/gpu/drm/i915/i915_gem.c|   4 +
 drivers/gpu/drm/i915/i915_gem_gtt.c| 

[git pull] drm fixes for 4.12-rc5

2017-06-08 Thread Dave Airlie
Hi Linus,

Bit more spread out fixes this time, fixes for 7 drivers + a couple of
core fixes.

i915 and vmwgfx are the main ones. The vmwgfx ones fix a bunch of
regressions in their atomic
rework, and a few fixes destined for stable. i915 has some 4.12
regressions and older things that need to be fixed in stable as well.

nouveau also has some runtime pm fixes and a timer list handling fix,
otherwise a couple of core and small driver regression fixes.

Thanks,
Dave,


The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f:

  Linux 4.12-rc4 (2017-06-04 16:47:43 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc5

for you to fetch changes up to 6e88007e224ce51969ccf9afeec645146c638816:

  Merge branch 'vmwgfx-fixes-4.12' of
git://people.freedesktop.org/~thomash/linux into drm-fixes (2017-06-09
13:12:02 +1000)


intel, nouveau, rockchip, vmwgfx, imx, meson, mediatek and core fixes


Ben Skeggs (3):
  drm/nouveau: replace multiple open-coded runpm support checks
with function
  drm/nouveau: enable autosuspend only when it'll actually be used
  drm/nouveau/tmr: fully separate alarm execution/pending lists

Chris Wilson (4):
  drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle
  drm/i915: Hold a wakeref for probing the ring registers
  drm/i915: Guard against i915_ggtt_disable_guc() being invoked
unconditionally
  drm/i915: Fix logical inversion for gen4 quirking

Colin Ian King (1):
  drm/vmwgfx: fix spelling mistake "exeeds" -> "exceeds"

Dan Carpenter (2):
  drm/mediatek: fix a timeout loop
  drm/vmwgfx: Handle vmalloc() failure in vmw_local_fifo_reserve()

Daniel Vetter (1):
  drm: Fix locking in drm_atomic_helper_resume

Dave Airlie (7):
  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-02' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'imx-drm-fixes-2017-06-08' of
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge branch 'mediatek-drm-fixes-4.12-rc1' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-07' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-06-08' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'vmwgfx-fixes-4.12' of
git://people.freedesktop.org/~thomash/linux into drm-fixes

Gustavo A. R. Silva (1):
  drm/nouveau/kms/nv50: add null check before pointer dereference

Hans de Goede (1):
  drm: Fix oops + Xserver hang when unplugging USB drm devices

Imre Deak (1):
  drm/i915: Prevent the system suspend complete optimization

Jani Nikula (1):
  drm/i915: fix warning for unused variable

John Stultz (1):
  drm: kirin: Fix drm_of_find_panel_or_bridge conversion

Jon Bloomfield (1):
  drm/i915: Serialize GTT/Aperture accesses on BXT

Kai Chen (1):
  drm/i915: Disable decoupled MMIO

Leonard Crestez (1):
  drm/imx: imx-ldb: Accept drm_of_find_panel_or_bridge failure

Lucas Stach (1):
  gpu: ipu-v3: pre: only use internal clock gating

Maarten Lankhorst (1):
  drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

Marek Vasut (1):
  gpu: ipu-v3: Fix CSI selection for VDIC

Mark yao (1):
  drm/rockchip: Correct vop out_mode configure

Michal Wajdeczko (1):
  drm/i915/guc: Remove stale comment for q_fail

Nagaraju, Vathsala (1):
  drm/i915/psr: disable psr2 for resolution greater than 32X20

Neil Armstrong (1):
  drm/meson: Fix driver bind when only CVBS is available

Sinclair Yeh (5):
  drm/vmwgfx: Don't create proxy surface for cursor
  drm/vmwgfx: Make sure backup_handle is always valid
  drm/vmwgfx: Make sure to update STDU when FB is updated
  drm/vmwgfx: Fix large topology crash
  drm/vmwgfx: Remove unused legacy cursor functions

Thomas Hellstrom (1):
  drm/vmwgfx: Bump driver minor and date

Ville Syrjälä (3):
  drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail
  drm/i915: Restore has_fbc=1 for ILK-M
  drm/i915: Fix 90/270 rotated coordinates for FBC

Vladis Dronov (1):
  drm/vmwgfx: limit the number of mip levels in
vmw_gb_surface_define_ioctl()

YYS (1):
  drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake

 drivers/gpu/drm/drm_atomic_helper.c|  11 ++
 drivers/gpu/drm/drm_drv.c  |   7 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c   |   2 +-
 drivers/gpu/drm/i915/i915_drv.c|   9 ++
 drivers/gpu/drm/i915/i915_drv.h|  10 ++
 drivers/gpu/drm/i915/i915_gem.c|   4 +
 drivers/gpu/drm/i915/i915_gem_gtt.c| 

Re: [PATCHv3] Bluetooth: hci_ll: Add compatible values for more WL chips

2017-06-08 Thread Marcel Holtmann
Hi Sebastian,

> Add compatible values for WiLink chips from 128x and 180x series.
> Also the DT binding already contained compatible values for the 127x
> series, but the driver did not. This brings the list on par with
> the list from wlcore (the wifi driver).
> 
> Signed-off-by: Sebastian Reichel 
> ---
> Hi,
> 
> This patch originally was part of the "Motorola Droid 4: Add WL1285C support"
> series. It can be queued standalone via the bluetooth tree, though.
> 
> Changes since PATCHv2:
> * none
> Changes since PATCHv1:
> * patch did not exist
> 
> -- Sebastian
> ---
> Documentation/devicetree/bindings/net/ti,wilink-st.txt | 6 ++
> drivers/bluetooth/hci_ll.c | 8 
> 2 files changed, 14 insertions(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel



Re: [PATCHv3] Bluetooth: hci_ll: Add compatible values for more WL chips

2017-06-08 Thread Marcel Holtmann
Hi Sebastian,

> Add compatible values for WiLink chips from 128x and 180x series.
> Also the DT binding already contained compatible values for the 127x
> series, but the driver did not. This brings the list on par with
> the list from wlcore (the wifi driver).
> 
> Signed-off-by: Sebastian Reichel 
> ---
> Hi,
> 
> This patch originally was part of the "Motorola Droid 4: Add WL1285C support"
> series. It can be queued standalone via the bluetooth tree, though.
> 
> Changes since PATCHv2:
> * none
> Changes since PATCHv1:
> * patch did not exist
> 
> -- Sebastian
> ---
> Documentation/devicetree/bindings/net/ti,wilink-st.txt | 6 ++
> drivers/bluetooth/hci_ll.c | 8 
> 2 files changed, 14 insertions(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel



Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

2017-06-08 Thread Sascha Hauer
On Thu, Jun 08, 2017 at 10:09:07PM -0700, Jiada Wang wrote:
> On 06/01/2017 10:38 PM, Sascha Hauer wrote:
> > On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote:
> > > Hi Sascha
> > > 
> > > On 05/29/2017 02:50 AM, Sascha Hauer wrote:
> > > > Hi,
> > > > 
> > > > On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote:
> > > > > From: Jiada Wang
> > > > > 
> > > > > previously burst length (BURST_LENGTH) is always set to equal
> > > > > to bits_per_word, causes a 10us gap between each word in
> > > > > transfer, which significantly affects performance.
> > > > > 
> > > > > This patch uses 32 bits transfer to simulate lower bits transfer,
> > > > > and adjusts burst length runtimely to use biggeest burst length
> > > > > as possible to reduce the gaps in transfer for PIO mode.
> > > > > 
> > > > First let me say that I'm not really looking forward to have this patch
> > > > in the driver. It adds quite some code to already hairy code pathes in
> > > > the imx-spi driver and I saw you have the same patch for DMA mode
> > > > aswell.
> > > > 
> > > > The driver has different function hooks for the different controllers.
> > > > This patch breaks that. In some places it assumes that dynamic burst
> > > > is only possible on i.MX51 type controllers and also that in case
> > > > dynamic burst is enabled it must be an i.MX51 type controller.
> > > > 
> > > > We should really see how this patch can be better integrated into the
> > > > driver, or, how the driver can be changed to better support the dynamic
> > > > burst usecase.
> > >   Yes, I can understand your concern, as this patch brings in a bunch of
> > > change,
> > > and changes the behaviour of data transfer.
> > > how about introduce a new DTS property like "fsl,spi-dynamic-burst",
> > > and only enables dynamic burst when this property is added.
> > This will only reduce the testing coverage of the feature, not a good
> > option.
> As an improvement, I am thinking about the following
> 1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before
> 2. remove all change in specific functions hooks, for example
> "mx51_ecspi_config"
> 3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle actual
> swapped data transfer,
> and burst length adjustment.

Whether or not the spi driver uses dynamic bursts is an implementation
detail of the driver and should be decided by the driver, not by the
device tree.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

2017-06-08 Thread Sascha Hauer
On Thu, Jun 08, 2017 at 10:09:07PM -0700, Jiada Wang wrote:
> On 06/01/2017 10:38 PM, Sascha Hauer wrote:
> > On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote:
> > > Hi Sascha
> > > 
> > > On 05/29/2017 02:50 AM, Sascha Hauer wrote:
> > > > Hi,
> > > > 
> > > > On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote:
> > > > > From: Jiada Wang
> > > > > 
> > > > > previously burst length (BURST_LENGTH) is always set to equal
> > > > > to bits_per_word, causes a 10us gap between each word in
> > > > > transfer, which significantly affects performance.
> > > > > 
> > > > > This patch uses 32 bits transfer to simulate lower bits transfer,
> > > > > and adjusts burst length runtimely to use biggeest burst length
> > > > > as possible to reduce the gaps in transfer for PIO mode.
> > > > > 
> > > > First let me say that I'm not really looking forward to have this patch
> > > > in the driver. It adds quite some code to already hairy code pathes in
> > > > the imx-spi driver and I saw you have the same patch for DMA mode
> > > > aswell.
> > > > 
> > > > The driver has different function hooks for the different controllers.
> > > > This patch breaks that. In some places it assumes that dynamic burst
> > > > is only possible on i.MX51 type controllers and also that in case
> > > > dynamic burst is enabled it must be an i.MX51 type controller.
> > > > 
> > > > We should really see how this patch can be better integrated into the
> > > > driver, or, how the driver can be changed to better support the dynamic
> > > > burst usecase.
> > >   Yes, I can understand your concern, as this patch brings in a bunch of
> > > change,
> > > and changes the behaviour of data transfer.
> > > how about introduce a new DTS property like "fsl,spi-dynamic-burst",
> > > and only enables dynamic burst when this property is added.
> > This will only reduce the testing coverage of the feature, not a good
> > option.
> As an improvement, I am thinking about the following
> 1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before
> 2. remove all change in specific functions hooks, for example
> "mx51_ecspi_config"
> 3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle actual
> swapped data transfer,
> and burst length adjustment.

Whether or not the spi driver uses dynamic bursts is an implementation
detail of the driver and should be decided by the driver, not by the
device tree.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [PATCH 11/16] powerpc: vio_cmo: use dev_groups and not dev_attrs for bus_type

2017-06-08 Thread Greg Kroah-Hartman
On Fri, Jun 09, 2017 at 08:53:22AM +1000, Michael Ellerman wrote:
> Greg Kroah-Hartman  writes:
> 
> > On Thu, Jun 08, 2017 at 11:12:10PM +1000, Michael Ellerman wrote:
> >> Greg Kroah-Hartman  writes:
> >> 
> >> > The dev_attrs field has long been "depreciated" and is finally being
> >> > removed, so move the driver to use the "correct" dev_groups field
> >> > instead for struct bus_type.
> >> >
> >> > Cc: Benjamin Herrenschmidt 
> >> > Cc: Paul Mackerras 
> >> > Cc: Michael Ellerman 
> >> > Cc: Vineet Gupta 
> >> > Cc: Bart Van Assche 
> >> > Cc: Robin Murphy 
> >> > Cc: Joerg Roedel 
> >> > Cc: Johan Hovold 
> >> > Cc: Alexey Kardashevskiy 
> >> > Cc: Krzysztof Kozlowski 
> >> > Cc: 
> >> > Signed-off-by: Greg Kroah-Hartman 
> >> > ---
> >> >  arch/powerpc/platforms/pseries/vio.c | 37 
> >> > +---
> >> >  1 file changed, 22 insertions(+), 15 deletions(-)
> >> 
> >> This one needed a bit more work to get building, the incremental diff is
> >> below. We need a forward declaration of name, devspec and modalias,
> >> which is a bit weird, but that's how the code is currently structured.
> >> And there's dev and bus attributes with the same name, so that needed an
> >> added "bus".
> >> 
> >> I booted v2 of patch 10 and this one and everything looks identical to
> >> upstream.
> >
> > Ah, many thanks, this was on my todo list to fix up today.
> >
> > But you renamed the sysfs files when you added "bus" to the function
> > names, are you sure you want to do that?  I don't mind, but if you
> > happen to have userspace tools that look at those files, they just broke
> > :(
> 
> Ugh crap, no that won't work.
> 
> I didn't see it when I tested because my machine doesn't have the CMO
> feature enabled.
> 
> I guess we have to open code some of the BUS_ATTR_RO() etc. so we can
> avoid the name clash.

Or split it into multiple files, I've solved this that way in the past.
You shouldn't have to "open code" BUS_ATTR_RO().

thanks,

greg k-h


Re: [PATCH 11/16] powerpc: vio_cmo: use dev_groups and not dev_attrs for bus_type

2017-06-08 Thread Greg Kroah-Hartman
On Fri, Jun 09, 2017 at 08:53:22AM +1000, Michael Ellerman wrote:
> Greg Kroah-Hartman  writes:
> 
> > On Thu, Jun 08, 2017 at 11:12:10PM +1000, Michael Ellerman wrote:
> >> Greg Kroah-Hartman  writes:
> >> 
> >> > The dev_attrs field has long been "depreciated" and is finally being
> >> > removed, so move the driver to use the "correct" dev_groups field
> >> > instead for struct bus_type.
> >> >
> >> > Cc: Benjamin Herrenschmidt 
> >> > Cc: Paul Mackerras 
> >> > Cc: Michael Ellerman 
> >> > Cc: Vineet Gupta 
> >> > Cc: Bart Van Assche 
> >> > Cc: Robin Murphy 
> >> > Cc: Joerg Roedel 
> >> > Cc: Johan Hovold 
> >> > Cc: Alexey Kardashevskiy 
> >> > Cc: Krzysztof Kozlowski 
> >> > Cc: 
> >> > Signed-off-by: Greg Kroah-Hartman 
> >> > ---
> >> >  arch/powerpc/platforms/pseries/vio.c | 37 
> >> > +---
> >> >  1 file changed, 22 insertions(+), 15 deletions(-)
> >> 
> >> This one needed a bit more work to get building, the incremental diff is
> >> below. We need a forward declaration of name, devspec and modalias,
> >> which is a bit weird, but that's how the code is currently structured.
> >> And there's dev and bus attributes with the same name, so that needed an
> >> added "bus".
> >> 
> >> I booted v2 of patch 10 and this one and everything looks identical to
> >> upstream.
> >
> > Ah, many thanks, this was on my todo list to fix up today.
> >
> > But you renamed the sysfs files when you added "bus" to the function
> > names, are you sure you want to do that?  I don't mind, but if you
> > happen to have userspace tools that look at those files, they just broke
> > :(
> 
> Ugh crap, no that won't work.
> 
> I didn't see it when I tested because my machine doesn't have the CMO
> feature enabled.
> 
> I guess we have to open code some of the BUS_ATTR_RO() etc. so we can
> avoid the name clash.

Or split it into multiple files, I've solved this that way in the past.
You shouldn't have to "open code" BUS_ATTR_RO().

thanks,

greg k-h


linux-next: build failure after merge of the uuid tree

2017-06-08 Thread Stephen Rothwell
Hi Christoph,

After merging the uuid tree, today's linux-next build (x86_64
allmodconfig) failed like this:

/home/sfr/next/next/drivers/thermal/int340x_thermal/int3400_thermal.c: In 
function 'int3400_thermal_get_uuids':
/home/sfr/next/next/drivers/thermal/int340x_thermal/int3400_thermal.c:146:4: 
error: implicit declaration of function 'acpi_str_to_uuid' 
[-Werror=implicit-function-declaration]
acpi_str_to_uuid(int3400_thermal_uuids[j], uuid);
^

Caused by commit

  94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")

I have used the uuid tree from next-20170607 again today.

-- 
Cheers,
Stephen Rothwell


linux-next: build failure after merge of the uuid tree

2017-06-08 Thread Stephen Rothwell
Hi Christoph,

After merging the uuid tree, today's linux-next build (x86_64
allmodconfig) failed like this:

/home/sfr/next/next/drivers/thermal/int340x_thermal/int3400_thermal.c: In 
function 'int3400_thermal_get_uuids':
/home/sfr/next/next/drivers/thermal/int340x_thermal/int3400_thermal.c:146:4: 
error: implicit declaration of function 'acpi_str_to_uuid' 
[-Werror=implicit-function-declaration]
acpi_str_to_uuid(int3400_thermal_uuids[j], uuid);
^

Caused by commit

  94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")

I have used the uuid tree from next-20170607 again today.

-- 
Cheers,
Stephen Rothwell


Re: [PATCH] staging: wlan-ng: cfg80211.c: fixed a line over 80 characters long

2017-06-08 Thread Greg KH
On Thu, Jun 08, 2017 at 06:38:30PM -0700, Elias Carter wrote:
> From: edcarter 
> 
> Fixed a coding style issue where a line was longer than 80 characters.
> 
> Signed-off-by: Elias Carter 

Your from and signed-off-by names have to match :(


Re: [PATCH] staging: wlan-ng: cfg80211.c: fixed a line over 80 characters long

2017-06-08 Thread Greg KH
On Thu, Jun 08, 2017 at 06:38:30PM -0700, Elias Carter wrote:
> From: edcarter 
> 
> Fixed a coding style issue where a line was longer than 80 characters.
> 
> Signed-off-by: Elias Carter 

Your from and signed-off-by names have to match :(


Re: [PATCH 0/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support

2017-06-08 Thread Nicholas A. Bellinger
Hi Himanshu & Quinn,

On Wed, 2017-06-07 at 05:02 +, Madhani, Himanshu wrote:
> > On Jun 3, 2017, at 3:10 PM, Nicholas A. Bellinger  
> > wrote:
> > 
> > From: Nicholas Bellinger 
> > 
> > Hi Himanshu + Quinn,
> > 
> > Here is a small series to introduce proper percpu se_lun->lun_ref
> > counting for TMR, and add common code in target_submit_tmr() to
> > do tag lookup for unpacked_lun in order to drop the original
> > driver specific lookup within __qlt_24xx_handle_abts().
> > 
> > It's rather straight-forward, so review and test as a v4.13 item.
> > 
> > Thanks!
> > 
> > Nicholas Bellinger (3):
> >  target: Add support for TMR percpu reference counting
> >  target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK
> >  qla2xxx: Convert QLA_TGT_ABTS to TARGET_SCF_LOOKUP_LUN_FROM_TAG
> > 
> > drivers/scsi/qla2xxx/qla_target.c  | 39 ++-
> > drivers/scsi/qla2xxx/tcm_qla2xxx.c |  4 ++-
> > drivers/target/target_core_device.c| 14 ++---
> > drivers/target/target_core_transport.c | 56 
> > --
> > include/target/target_core_base.h  |  3 +-
> > 5 files changed, 71 insertions(+), 45 deletions(-)
> > 
> > -- 
> > 1.9.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe target-devel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Series looks good. 
> 
> Acked-by: Himanshu Madhani 
> 

Thanks for the review! 



Re: [PATCH 0/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support

2017-06-08 Thread Nicholas A. Bellinger
Hi Himanshu & Quinn,

On Wed, 2017-06-07 at 05:02 +, Madhani, Himanshu wrote:
> > On Jun 3, 2017, at 3:10 PM, Nicholas A. Bellinger  
> > wrote:
> > 
> > From: Nicholas Bellinger 
> > 
> > Hi Himanshu + Quinn,
> > 
> > Here is a small series to introduce proper percpu se_lun->lun_ref
> > counting for TMR, and add common code in target_submit_tmr() to
> > do tag lookup for unpacked_lun in order to drop the original
> > driver specific lookup within __qlt_24xx_handle_abts().
> > 
> > It's rather straight-forward, so review and test as a v4.13 item.
> > 
> > Thanks!
> > 
> > Nicholas Bellinger (3):
> >  target: Add support for TMR percpu reference counting
> >  target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK
> >  qla2xxx: Convert QLA_TGT_ABTS to TARGET_SCF_LOOKUP_LUN_FROM_TAG
> > 
> > drivers/scsi/qla2xxx/qla_target.c  | 39 ++-
> > drivers/scsi/qla2xxx/tcm_qla2xxx.c |  4 ++-
> > drivers/target/target_core_device.c| 14 ++---
> > drivers/target/target_core_transport.c | 56 
> > --
> > include/target/target_core_base.h  |  3 +-
> > 5 files changed, 71 insertions(+), 45 deletions(-)
> > 
> > -- 
> > 1.9.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe target-devel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Series looks good. 
> 
> Acked-by: Himanshu Madhani 
> 

Thanks for the review! 



Re: [PATCH 4/7] zram: use class_groups instead of class_attrs

2017-06-08 Thread Sergey Senozhatsky
On (06/08/17 10:12), Greg Kroah-Hartman wrote:
> The class_attrs pointer is long depreciated, and is about to be finally
> removed, so move to use the class_groups pointer instead.
> 
> Cc: Minchan Kim 
> Cc: Nitin Gupta 
> Cc: Sergey Senozhatsky 
> Signed-off-by: Greg Kroah-Hartman 

FWIW, looks good to me.

Reviewed-by: Sergey Senozhatsky 

-ss


Re: [PATCH 4/7] zram: use class_groups instead of class_attrs

2017-06-08 Thread Sergey Senozhatsky
On (06/08/17 10:12), Greg Kroah-Hartman wrote:
> The class_attrs pointer is long depreciated, and is about to be finally
> removed, so move to use the class_groups pointer instead.
> 
> Cc: Minchan Kim 
> Cc: Nitin Gupta 
> Cc: Sergey Senozhatsky 
> Signed-off-by: Greg Kroah-Hartman 

FWIW, looks good to me.

Reviewed-by: Sergey Senozhatsky 

-ss


[lkp-robot] [x86/mm] d52d163f42: WARNING:at_arch/x86/mm/tlb.c:#switch_mm_irqs_off

2017-06-08 Thread kernel test robot

FYI, we noticed the following commit:

commit: d52d163f428136feb592f7546cb2333cfad775bf ("x86/mm: Rework lazy TLB mode 
and TLB freshness tracking")
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git x86/pcid

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 195a7a2576 | d52d163f42 |
+--+++
| boot_successes   | 8  | 3  |
| boot_failures| 0  | 7  |
| WARNING:at_arch/x86/mm/tlb.c:#switch_mm_irqs_off | 0  | 7  |
| EIP:switch_mm_irqs_off   | 0  | 7  |
+--+++



[7.985468] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:83 
switch_mm_irqs_off+0x23/0x393
[7.986572] Modules linked in:
[7.986920] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.12.0-rc4-00017-gd52d163 #1
[7.987754] task: 79fb4a40 task.stack: 79faa000
[7.988257] EIP: switch_mm_irqs_off+0x23/0x393
[7.988761] EFLAGS: 00010203 CPU: 0
[7.989157] EAX: 0202 EBX: 79fe5260 ECX:  EDX: 79e4aa05
[7.989854] ESI: 8b0959c0 EDI: 79fe5498 EBP: 79fabf18 ESP: 79fabf08
[7.990552]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[7.991159] CR0: 80050033 CR2: 6f6f79c0 CR3: 0c453000 CR4: 0690
[7.991858] Call Trace:
[7.992145]  idle_task_exit+0x45/0x55
[7.992565]  play_dead_common+0x8/0x1a
[7.992988]  native_play_dead+0xa/0xd2
[7.993407]  arch_cpu_idle_dead+0x9/0xb
[7.993847]  do_idle+0x42/0x166
[7.994206]  cpu_startup_entry+0x56/0x58
[7.994654]  rest_init+0x108/0x10d
[7.995039]  start_kernel+0x3fe/0x406
[7.995463]  i386_start_kernel+0x9a/0x9e
[7.995902]  startup_32_smp+0x166/0x168
[7.996333] Code: e5 e8 02 fd ff ff 5d c3 55 89 e5 57 56 53 51 89 d3 e8 fc 
e7 36 00 64 8b 35 00 04 17 7a 89 c1 9c 58 8d 74 26 00 0f ba e0 09 73 02 <0f> ff 
39 de a1 5c 02 0c 7a 0f 85 3c 01 00 00 39 c1 8b 93 bc 01
[7.998498] ---[ end trace 67c561e2f6b242ff ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y

[lkp-robot] [x86/mm] d52d163f42: WARNING:at_arch/x86/mm/tlb.c:#switch_mm_irqs_off

2017-06-08 Thread kernel test robot

FYI, we noticed the following commit:

commit: d52d163f428136feb592f7546cb2333cfad775bf ("x86/mm: Rework lazy TLB mode 
and TLB freshness tracking")
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git x86/pcid

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 195a7a2576 | d52d163f42 |
+--+++
| boot_successes   | 8  | 3  |
| boot_failures| 0  | 7  |
| WARNING:at_arch/x86/mm/tlb.c:#switch_mm_irqs_off | 0  | 7  |
| EIP:switch_mm_irqs_off   | 0  | 7  |
+--+++



[7.985468] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:83 
switch_mm_irqs_off+0x23/0x393
[7.986572] Modules linked in:
[7.986920] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.12.0-rc4-00017-gd52d163 #1
[7.987754] task: 79fb4a40 task.stack: 79faa000
[7.988257] EIP: switch_mm_irqs_off+0x23/0x393
[7.988761] EFLAGS: 00010203 CPU: 0
[7.989157] EAX: 0202 EBX: 79fe5260 ECX:  EDX: 79e4aa05
[7.989854] ESI: 8b0959c0 EDI: 79fe5498 EBP: 79fabf18 ESP: 79fabf08
[7.990552]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[7.991159] CR0: 80050033 CR2: 6f6f79c0 CR3: 0c453000 CR4: 0690
[7.991858] Call Trace:
[7.992145]  idle_task_exit+0x45/0x55
[7.992565]  play_dead_common+0x8/0x1a
[7.992988]  native_play_dead+0xa/0xd2
[7.993407]  arch_cpu_idle_dead+0x9/0xb
[7.993847]  do_idle+0x42/0x166
[7.994206]  cpu_startup_entry+0x56/0x58
[7.994654]  rest_init+0x108/0x10d
[7.995039]  start_kernel+0x3fe/0x406
[7.995463]  i386_start_kernel+0x9a/0x9e
[7.995902]  startup_32_smp+0x166/0x168
[7.996333] Code: e5 e8 02 fd ff ff 5d c3 55 89 e5 57 56 53 51 89 d3 e8 fc 
e7 36 00 64 8b 35 00 04 17 7a 89 c1 9c 58 8d 74 26 00 0f ba e0 09 73 02 <0f> ff 
39 de a1 5c 02 0c 7a 0f 85 3c 01 00 00 39 c1 8b 93 bc 01
[7.998498] ---[ end trace 67c561e2f6b242ff ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y

[lkp-robot] [drm] e1f8a89c4f: pft.faults_per_sec_per_cpu -77.9% regression

2017-06-08 Thread kernel test robot

Greeting,

FYI, we noticed a -77.9% regression of pft.faults_per_sec_per_cpu due to commit:


commit: e1f8a89c4f33f5b32cfb047f07fdf6d38cda854a ("drm: introduce sync objects 
(v4)")
git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem

in testcase: pft
on test machine: qemu-system-x86_64 -enable-kvm -cpu Penryn -smp 4 -m 2G
with following parameters:

iterations: 20x

test-description: Pft is the page fault test micro benchmark.
test-url: https://github.com/gormanm/pft



Details are as below:
-->


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email

testcase/path_params/tbox_group/run: pft/20x/vm-vp-2G

   v4.12-rc2  e1f8a89c4f33f5b32cfb047f07
  --
 %stddev %change %stddev


 \  |\  


878620 ± 
15% -77.9% 194209 ± 12%  pft.faults_per_sec_per_cpu
  7.16 ± 23%+257.2%  25.58 ± 12%  pft.time.elapsed_time
  7.16 ± 23%+257.2%  25.58 ± 12%  pft.time.elapsed_time.max
  1223 ± 10%+199.9%   3667 ± 15%  
pft.time.involuntary_context_switches
 61828 ±  2%  +10106.0%6310202 ±  0%  pft.time.minor_page_faults
145.40 ±  3% +20.6% 175.33 ±  5%  
pft.time.percent_of_cpu_this_job_got
  9.37 ± 22%+345.2%  41.72 ± 15%  pft.time.system_time
  5.04 ± 11% -45.6%   2.74 ±  9%  mpstat.cpu.usr%
131734 ± 12% +20.3% 158487 ±  5%  softirqs.TIMER


  1335 ± 11%+105.1%   2738 ± 
19%  vmstat.system.cs
  5390 ±  4% -27.6%   3904 ± 38%  slabinfo.kmalloc-96.active_objs
  5420 ±  3% -21.5%   4252 ± 27%  slabinfo.kmalloc-96.num_objs
 68.30 ±209%  +13218.2%   9096 ± 84%  
latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
588552 ± 32% -74.2% 151873 ± 37%  
latency_stats.sum.ep_poll.SyS_epoll_wait.do_syscall_64.return_from_SYSCALL_64
 74.20 ±203%  +12326.8%   9220 ± 82%  
latency_stats.sum.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
160550 ± 14%-100.0%   0.00 ± -1%  meminfo.AnonHugePages
204792 ±  0%-100.0%   0.00 ± -1%  meminfo.CmaFree
204800 ±  0%-100.0%   0.00 ± -1%  meminfo.CmaTotal
  3041 ±  0% +13.4%   3449 ±  0%  meminfo.KernelStack
 51198 ±  0%-100.0%   0.00 ± -1%  proc-vmstat.nr_free_cma
  3033 ±  1% +13.6%   3446 ±  0%  proc-vmstat.nr_kernel_stack
 73394 ±  9%   +8258.9%6134982 ±  2%  proc-vmstat.numa_hit
 73394 ±  9%   +8258.9%6134982 ±  2%  proc-vmstat.numa_local
 67006 ±  9%   +9043.7%6126912 ±  2%  proc-vmstat.pgfault
 11161 ±  7%-100.0%   0.00 ± -1%  
proc-vmstat.thp_deferred_split_page
 11217 ±  7%-100.0%   0.00 ± -1%  proc-vmstat.thp_fault_alloc
  7.16 ± 23%+257.2%  25.58 ± 12%  time.elapsed_time
  7.16 ± 23%+257.2%  25.58 ± 12%  time.elapsed_time.max
  1223 ± 10%+199.9%   3667 ± 15%  time.involuntary_context_switches
 61828 ±  2%  +10106.0%6310202 ±  0%  time.minor_page_faults




 pft.faults_per_sec_per_cpu

   1e+06 ++--*--+
  90 ++*..  ..  |
 |   *:   ..|
  80 ++ : :   : ...*|
  70 ++  ...*   : :  :  *...|
 *...: :   : :  |
  60 ++  : :   ::   |
  50 ++   :   : :   :   |
  40 ++   :   :  : :|
 | : :   : :|
  30 ++ :   : :   : |
  20 O+ O   : O :O: O :  O OO
   

[lkp-robot] [drm] e1f8a89c4f: pft.faults_per_sec_per_cpu -77.9% regression

2017-06-08 Thread kernel test robot

Greeting,

FYI, we noticed a -77.9% regression of pft.faults_per_sec_per_cpu due to commit:


commit: e1f8a89c4f33f5b32cfb047f07fdf6d38cda854a ("drm: introduce sync objects 
(v4)")
git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem

in testcase: pft
on test machine: qemu-system-x86_64 -enable-kvm -cpu Penryn -smp 4 -m 2G
with following parameters:

iterations: 20x

test-description: Pft is the page fault test micro benchmark.
test-url: https://github.com/gormanm/pft



Details are as below:
-->


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email

testcase/path_params/tbox_group/run: pft/20x/vm-vp-2G

   v4.12-rc2  e1f8a89c4f33f5b32cfb047f07
  --
 %stddev %change %stddev


 \  |\  


878620 ± 
15% -77.9% 194209 ± 12%  pft.faults_per_sec_per_cpu
  7.16 ± 23%+257.2%  25.58 ± 12%  pft.time.elapsed_time
  7.16 ± 23%+257.2%  25.58 ± 12%  pft.time.elapsed_time.max
  1223 ± 10%+199.9%   3667 ± 15%  
pft.time.involuntary_context_switches
 61828 ±  2%  +10106.0%6310202 ±  0%  pft.time.minor_page_faults
145.40 ±  3% +20.6% 175.33 ±  5%  
pft.time.percent_of_cpu_this_job_got
  9.37 ± 22%+345.2%  41.72 ± 15%  pft.time.system_time
  5.04 ± 11% -45.6%   2.74 ±  9%  mpstat.cpu.usr%
131734 ± 12% +20.3% 158487 ±  5%  softirqs.TIMER


  1335 ± 11%+105.1%   2738 ± 
19%  vmstat.system.cs
  5390 ±  4% -27.6%   3904 ± 38%  slabinfo.kmalloc-96.active_objs
  5420 ±  3% -21.5%   4252 ± 27%  slabinfo.kmalloc-96.num_objs
 68.30 ±209%  +13218.2%   9096 ± 84%  
latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
588552 ± 32% -74.2% 151873 ± 37%  
latency_stats.sum.ep_poll.SyS_epoll_wait.do_syscall_64.return_from_SYSCALL_64
 74.20 ±203%  +12326.8%   9220 ± 82%  
latency_stats.sum.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
160550 ± 14%-100.0%   0.00 ± -1%  meminfo.AnonHugePages
204792 ±  0%-100.0%   0.00 ± -1%  meminfo.CmaFree
204800 ±  0%-100.0%   0.00 ± -1%  meminfo.CmaTotal
  3041 ±  0% +13.4%   3449 ±  0%  meminfo.KernelStack
 51198 ±  0%-100.0%   0.00 ± -1%  proc-vmstat.nr_free_cma
  3033 ±  1% +13.6%   3446 ±  0%  proc-vmstat.nr_kernel_stack
 73394 ±  9%   +8258.9%6134982 ±  2%  proc-vmstat.numa_hit
 73394 ±  9%   +8258.9%6134982 ±  2%  proc-vmstat.numa_local
 67006 ±  9%   +9043.7%6126912 ±  2%  proc-vmstat.pgfault
 11161 ±  7%-100.0%   0.00 ± -1%  
proc-vmstat.thp_deferred_split_page
 11217 ±  7%-100.0%   0.00 ± -1%  proc-vmstat.thp_fault_alloc
  7.16 ± 23%+257.2%  25.58 ± 12%  time.elapsed_time
  7.16 ± 23%+257.2%  25.58 ± 12%  time.elapsed_time.max
  1223 ± 10%+199.9%   3667 ± 15%  time.involuntary_context_switches
 61828 ±  2%  +10106.0%6310202 ±  0%  time.minor_page_faults




 pft.faults_per_sec_per_cpu

   1e+06 ++--*--+
  90 ++*..  ..  |
 |   *:   ..|
  80 ++ : :   : ...*|
  70 ++  ...*   : :  :  *...|
 *...: :   : :  |
  60 ++  : :   ::   |
  50 ++   :   : :   :   |
  40 ++   :   :  : :|
 | : :   : :|
  30 ++ :   : :   : |
  20 O+ O   : O :O: O :  O OO
   

Re: [PATCH RFC] KVM: async_pf: fix async_pf exception injection

2017-06-08 Thread Wanpeng Li
2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>
> 3) add an async_page_fault member to vcpu->arch.exception

Do you think we should also add an async_page_fault field to
x86_exception, then pass down to kvm_inject_page_fault() through
x86_exception? Maybe we should modify
kvm_queue_exception_e/kvm_multiple_exception etc to add an function
parameter for async_page_fault.

Regards,
Wanpeng Li


Re: [PATCH RFC] KVM: async_pf: fix async_pf exception injection

2017-06-08 Thread Wanpeng Li
2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>
> 3) add an async_page_fault member to vcpu->arch.exception

Do you think we should also add an async_page_fault field to
x86_exception, then pass down to kvm_inject_page_fault() through
x86_exception? Maybe we should modify
kvm_queue_exception_e/kvm_multiple_exception etc to add an function
parameter for async_page_fault.

Regards,
Wanpeng Li


Re: [PATCH] iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP

2017-06-08 Thread Nicholas A. Bellinger
Reviews pretty please..?

On Sat, 2017-06-03 at 21:32 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger 
> 
> This patch fixes a BUG() in iscsit_close_session() that could be
> triggered when iscsit_logout_post_handler() execution from within
> tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
> (15 seconds), and the TCP connection didn't already close before
> then forcing tx thread context to automatically exit.
> 
> This would manifest itself during explicit logout as:
> 
> [33206.974254] 1 connection(s) still exist for iSCSI session to 
> iqn.1993-08.org.debian:01:3f5523242179
> [33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 
> 2100.772 msecs
> [33209.078643] [ cut here ]
> [33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
> 
> Normally when explicit logout attempt fails, the tx thread context
> exits and iscsit_close_connection() from rx thread context does the
> extra cleanup once it detects conn->conn_logout_remove has not been
> cleared by the logout type specific post handlers.
> 
> To address this special case, if the logout post handler in tx thread
> context detects conn->tx_thread_active has already been cleared, simply
> return and exit in order for existing iscsit_close_connection()
> logic from rx thread context do failed logout cleanup.
> 
> Reported-by: Bart Van Assche 
> Cc: Mike Christie 
> Cc: Hannes Reinecke 
> Cc: Sagi Grimberg 
> Cc: sta...@vger.kernel.org # 3.14+
> Signed-off-by: Nicholas Bellinger 
> ---
>  drivers/target/iscsi/iscsi_target.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/target/iscsi/iscsi_target.c 
> b/drivers/target/iscsi/iscsi_target.c
> index 0d8f815..c025451 100644
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -4423,8 +4423,11 @@ static void iscsit_logout_post_handler_closesession(
>* always sleep waiting for RX/TX thread shutdown to complete
>* within iscsit_close_connection().
>*/
> - if (!conn->conn_transport->rdma_shutdown)
> + if (!conn->conn_transport->rdma_shutdown) {
>   sleep = cmpxchg(>tx_thread_active, true, false);
> + if (!sleep)
> + return;
> + }
>  
>   atomic_set(>conn_logout_remove, 0);
>   complete(>conn_logout_comp);
> @@ -4440,8 +4443,11 @@ static void iscsit_logout_post_handler_samecid(
>  {
>   int sleep = 1;
>  
> - if (!conn->conn_transport->rdma_shutdown)
> + if (!conn->conn_transport->rdma_shutdown) {
>   sleep = cmpxchg(>tx_thread_active, true, false);
> + if (!sleep)
> + return;
> + }
>  
>   atomic_set(>conn_logout_remove, 0);
>   complete(>conn_logout_comp);




Re: [PATCH] iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP

2017-06-08 Thread Nicholas A. Bellinger
Reviews pretty please..?

On Sat, 2017-06-03 at 21:32 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger 
> 
> This patch fixes a BUG() in iscsit_close_session() that could be
> triggered when iscsit_logout_post_handler() execution from within
> tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
> (15 seconds), and the TCP connection didn't already close before
> then forcing tx thread context to automatically exit.
> 
> This would manifest itself during explicit logout as:
> 
> [33206.974254] 1 connection(s) still exist for iSCSI session to 
> iqn.1993-08.org.debian:01:3f5523242179
> [33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 
> 2100.772 msecs
> [33209.078643] [ cut here ]
> [33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
> 
> Normally when explicit logout attempt fails, the tx thread context
> exits and iscsit_close_connection() from rx thread context does the
> extra cleanup once it detects conn->conn_logout_remove has not been
> cleared by the logout type specific post handlers.
> 
> To address this special case, if the logout post handler in tx thread
> context detects conn->tx_thread_active has already been cleared, simply
> return and exit in order for existing iscsit_close_connection()
> logic from rx thread context do failed logout cleanup.
> 
> Reported-by: Bart Van Assche 
> Cc: Mike Christie 
> Cc: Hannes Reinecke 
> Cc: Sagi Grimberg 
> Cc: sta...@vger.kernel.org # 3.14+
> Signed-off-by: Nicholas Bellinger 
> ---
>  drivers/target/iscsi/iscsi_target.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/target/iscsi/iscsi_target.c 
> b/drivers/target/iscsi/iscsi_target.c
> index 0d8f815..c025451 100644
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -4423,8 +4423,11 @@ static void iscsit_logout_post_handler_closesession(
>* always sleep waiting for RX/TX thread shutdown to complete
>* within iscsit_close_connection().
>*/
> - if (!conn->conn_transport->rdma_shutdown)
> + if (!conn->conn_transport->rdma_shutdown) {
>   sleep = cmpxchg(>tx_thread_active, true, false);
> + if (!sleep)
> + return;
> + }
>  
>   atomic_set(>conn_logout_remove, 0);
>   complete(>conn_logout_comp);
> @@ -4440,8 +4443,11 @@ static void iscsit_logout_post_handler_samecid(
>  {
>   int sleep = 1;
>  
> - if (!conn->conn_transport->rdma_shutdown)
> + if (!conn->conn_transport->rdma_shutdown) {
>   sleep = cmpxchg(>tx_thread_active, true, false);
> + if (!sleep)
> + return;
> + }
>  
>   atomic_set(>conn_logout_remove, 0);
>   complete(>conn_logout_comp);




Re: [PATCH] target: Fix kref->refcount underflow in transport_cmd_finish_abort

2017-06-08 Thread Nicholas A. Bellinger
(Adding Quinn CC')

Reviews please..?

On Sat, 2017-06-03 at 21:09 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger 
> 
> This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
> when a fabric driver drops it's second reference from below the
> target_core_tmr.c based callers of transport_cmd_finish_abort().
> 
> Recently with the conversion of kref to refcount_t, this bug was
> manifesting itself as:
> 
> [705519.601034] refcount_t: underflow; use-after-free.
> [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 
> 20116.512 msecs
> [705539.719111] [ cut here ]
> [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 
> refcount_sub_and_test+0x33/0x51
> 
> Since the original kref atomic_t based kref_put() didn't check for
> underflow and only invoked the final callback when zero was reached,
> this bug did not manifest in practice since all se_cmd memory is
> using preallocated tags.
> 
> To address this, go ahead and propigate the existing return from
> transport_put_cmd() up via transport_cmd_finish_abort(), and
> change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
> callers to only do their local target_put_sess_cmd() if necessary.
> 
> Reported-by: Bart Van Assche 
> Cc: Mike Christie 
> Cc: Hannes Reinecke 
> Cc: Christoph Hellwig 
> Cc: Himanshu Madhani 
> Cc: Sagi Grimberg 
> Cc: sta...@vger.kernel.org # 3.14+
> Signed-off-by: Nicholas Bellinger 
> ---
>  drivers/target/target_core_internal.h  |  2 +-
>  drivers/target/target_core_tmr.c   | 16 
>  drivers/target/target_core_transport.c |  9 ++---
>  3 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/target/target_core_internal.h 
> b/drivers/target/target_core_internal.h
> index 9ab7090..0912de7 100644
> --- a/drivers/target/target_core_internal.h
> +++ b/drivers/target/target_core_internal.h
> @@ -136,7 +136,7 @@ struct se_node_acl 
> *core_tpg_add_initiator_node_acl(struct se_portal_group *tpg,
>  void release_se_kmem_caches(void);
>  u32  scsi_get_new_index(scsi_index_t);
>  void transport_subsystem_check_init(void);
> -void transport_cmd_finish_abort(struct se_cmd *, int);
> +int  transport_cmd_finish_abort(struct se_cmd *, int);
>  unsigned char *transport_dump_cmd_direction(struct se_cmd *);
>  void transport_dump_dev_state(struct se_device *, char *, int *);
>  void transport_dump_dev_info(struct se_device *, struct se_lun *,
> diff --git a/drivers/target/target_core_tmr.c 
> b/drivers/target/target_core_tmr.c
> index dce1e1b..13f47bf 100644
> --- a/drivers/target/target_core_tmr.c
> +++ b/drivers/target/target_core_tmr.c
> @@ -75,7 +75,7 @@ void core_tmr_release_req(struct se_tmr_req *tmr)
>   kfree(tmr);
>  }
>  
> -static void core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
> +static int core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
>  {
>   unsigned long flags;
>   bool remove = true, send_tas;
> @@ -91,7 +91,7 @@ static void core_tmr_handle_tas_abort(struct se_cmd *cmd, 
> int tas)
>   transport_send_task_abort(cmd);
>   }
>  
> - transport_cmd_finish_abort(cmd, remove);
> + return transport_cmd_finish_abort(cmd, remove);
>  }
>  
>  static int target_check_cdb_and_preempt(struct list_head *list,
> @@ -184,8 +184,8 @@ void core_tmr_abort_task(
>   cancel_work_sync(_cmd->work);
>   transport_wait_for_tasks(se_cmd);
>  
> - transport_cmd_finish_abort(se_cmd, true);
> - target_put_sess_cmd(se_cmd);
> + if (!transport_cmd_finish_abort(se_cmd, true))
> + target_put_sess_cmd(se_cmd);
>  
>   printk("ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for"
>   " ref_tag: %llu\n", ref_tag);
> @@ -281,8 +281,8 @@ static void core_tmr_drain_tmr_list(
>   cancel_work_sync(>work);
>   transport_wait_for_tasks(cmd);
>  
> - transport_cmd_finish_abort(cmd, 1);
> - target_put_sess_cmd(cmd);
> + if (!transport_cmd_finish_abort(cmd, 1))
> + target_put_sess_cmd(cmd);
>   }
>  }
>  
> @@ -380,8 +380,8 @@ static void core_tmr_drain_state_list(
>   cancel_work_sync(>work);
>   transport_wait_for_tasks(cmd);
>  
> - core_tmr_handle_tas_abort(cmd, tas);
> - target_put_sess_cmd(cmd);
> + if (!core_tmr_handle_tas_abort(cmd, tas))
> + target_put_sess_cmd(cmd);
>   }
>  }
>  
> diff --git a/drivers/target/target_core_transport.c 
> b/drivers/target/target_core_transport.c
> index 6025935..f1b3a46 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -651,9 +651,10 @@ static 

Re: [PATCH] target: Fix kref->refcount underflow in transport_cmd_finish_abort

2017-06-08 Thread Nicholas A. Bellinger
(Adding Quinn CC')

Reviews please..?

On Sat, 2017-06-03 at 21:09 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger 
> 
> This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
> when a fabric driver drops it's second reference from below the
> target_core_tmr.c based callers of transport_cmd_finish_abort().
> 
> Recently with the conversion of kref to refcount_t, this bug was
> manifesting itself as:
> 
> [705519.601034] refcount_t: underflow; use-after-free.
> [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 
> 20116.512 msecs
> [705539.719111] [ cut here ]
> [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 
> refcount_sub_and_test+0x33/0x51
> 
> Since the original kref atomic_t based kref_put() didn't check for
> underflow and only invoked the final callback when zero was reached,
> this bug did not manifest in practice since all se_cmd memory is
> using preallocated tags.
> 
> To address this, go ahead and propigate the existing return from
> transport_put_cmd() up via transport_cmd_finish_abort(), and
> change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
> callers to only do their local target_put_sess_cmd() if necessary.
> 
> Reported-by: Bart Van Assche 
> Cc: Mike Christie 
> Cc: Hannes Reinecke 
> Cc: Christoph Hellwig 
> Cc: Himanshu Madhani 
> Cc: Sagi Grimberg 
> Cc: sta...@vger.kernel.org # 3.14+
> Signed-off-by: Nicholas Bellinger 
> ---
>  drivers/target/target_core_internal.h  |  2 +-
>  drivers/target/target_core_tmr.c   | 16 
>  drivers/target/target_core_transport.c |  9 ++---
>  3 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/target/target_core_internal.h 
> b/drivers/target/target_core_internal.h
> index 9ab7090..0912de7 100644
> --- a/drivers/target/target_core_internal.h
> +++ b/drivers/target/target_core_internal.h
> @@ -136,7 +136,7 @@ struct se_node_acl 
> *core_tpg_add_initiator_node_acl(struct se_portal_group *tpg,
>  void release_se_kmem_caches(void);
>  u32  scsi_get_new_index(scsi_index_t);
>  void transport_subsystem_check_init(void);
> -void transport_cmd_finish_abort(struct se_cmd *, int);
> +int  transport_cmd_finish_abort(struct se_cmd *, int);
>  unsigned char *transport_dump_cmd_direction(struct se_cmd *);
>  void transport_dump_dev_state(struct se_device *, char *, int *);
>  void transport_dump_dev_info(struct se_device *, struct se_lun *,
> diff --git a/drivers/target/target_core_tmr.c 
> b/drivers/target/target_core_tmr.c
> index dce1e1b..13f47bf 100644
> --- a/drivers/target/target_core_tmr.c
> +++ b/drivers/target/target_core_tmr.c
> @@ -75,7 +75,7 @@ void core_tmr_release_req(struct se_tmr_req *tmr)
>   kfree(tmr);
>  }
>  
> -static void core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
> +static int core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
>  {
>   unsigned long flags;
>   bool remove = true, send_tas;
> @@ -91,7 +91,7 @@ static void core_tmr_handle_tas_abort(struct se_cmd *cmd, 
> int tas)
>   transport_send_task_abort(cmd);
>   }
>  
> - transport_cmd_finish_abort(cmd, remove);
> + return transport_cmd_finish_abort(cmd, remove);
>  }
>  
>  static int target_check_cdb_and_preempt(struct list_head *list,
> @@ -184,8 +184,8 @@ void core_tmr_abort_task(
>   cancel_work_sync(_cmd->work);
>   transport_wait_for_tasks(se_cmd);
>  
> - transport_cmd_finish_abort(se_cmd, true);
> - target_put_sess_cmd(se_cmd);
> + if (!transport_cmd_finish_abort(se_cmd, true))
> + target_put_sess_cmd(se_cmd);
>  
>   printk("ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for"
>   " ref_tag: %llu\n", ref_tag);
> @@ -281,8 +281,8 @@ static void core_tmr_drain_tmr_list(
>   cancel_work_sync(>work);
>   transport_wait_for_tasks(cmd);
>  
> - transport_cmd_finish_abort(cmd, 1);
> - target_put_sess_cmd(cmd);
> + if (!transport_cmd_finish_abort(cmd, 1))
> + target_put_sess_cmd(cmd);
>   }
>  }
>  
> @@ -380,8 +380,8 @@ static void core_tmr_drain_state_list(
>   cancel_work_sync(>work);
>   transport_wait_for_tasks(cmd);
>  
> - core_tmr_handle_tas_abort(cmd, tas);
> - target_put_sess_cmd(cmd);
> + if (!core_tmr_handle_tas_abort(cmd, tas))
> + target_put_sess_cmd(cmd);
>   }
>  }
>  
> diff --git a/drivers/target/target_core_transport.c 
> b/drivers/target/target_core_transport.c
> index 6025935..f1b3a46 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -651,9 +651,10 @@ static void transport_lun_remove_cmd(struct se_cmd *cmd)
>   percpu_ref_put(>lun_ref);
>  }
>  
> -void transport_cmd_finish_abort(struct se_cmd *cmd, int remove)
> 

Re: [PATCH 3/3] libnvdimm: New ACPI 6.2 DSM functions

2017-06-08 Thread Dan Williams
On Thu, Jun 8, 2017 at 1:02 AM, Johannes Thumshirn  wrote:
> On 06/07/2017 07:04 PM, Jerry Hoemann wrote:
>> @@ -179,6 +217,10 @@ static inline const char *nvdimm_bus_cmd_name(unsigned 
>> cmd)
>>   [ND_CMD_ARS_START] = "ars_start",
>>   [ND_CMD_ARS_STATUS] = "ars_status",
>>   [ND_CMD_CLEAR_ERROR] = "clear_error",
>> + [5] = "trans_spa",
>> + [7] = "ars_err_inj",
>> + [8] = "ars_err_inj_clr",
>> + [9] = "ars_err_inj_stat",
>>   [ND_CMD_CALL] = "cmd_call",
>>   };
>
> Can you please add the new values to the enum in uapi/ndctl.h? I don't
> really like the magic numbers here.

I think the reason Jerry didn't add them is due to symmetry. All the
current ND_CMD_ definitions have corresponding ND_IOCTL_ definitions.
These new commands we're only adding function number support and using
ND_CMD_CALL for the ioctl transport. We can still add definitions for
them, but perhaps with an ACPI_NFIT_DSM_ prefix? The only consumer in
the kernel of this is debug output code. I think perhaps we should
just delete them here and either print raw numbers or enable
acpi_nfit_ctl() to the decode and not rely on nvdimm_bus_cmd_name()
which is meant to represent NVDIMM bus type generic command numbers.


Re: [PATCH 3/3] libnvdimm: New ACPI 6.2 DSM functions

2017-06-08 Thread Dan Williams
On Thu, Jun 8, 2017 at 1:02 AM, Johannes Thumshirn  wrote:
> On 06/07/2017 07:04 PM, Jerry Hoemann wrote:
>> @@ -179,6 +217,10 @@ static inline const char *nvdimm_bus_cmd_name(unsigned 
>> cmd)
>>   [ND_CMD_ARS_START] = "ars_start",
>>   [ND_CMD_ARS_STATUS] = "ars_status",
>>   [ND_CMD_CLEAR_ERROR] = "clear_error",
>> + [5] = "trans_spa",
>> + [7] = "ars_err_inj",
>> + [8] = "ars_err_inj_clr",
>> + [9] = "ars_err_inj_stat",
>>   [ND_CMD_CALL] = "cmd_call",
>>   };
>
> Can you please add the new values to the enum in uapi/ndctl.h? I don't
> really like the magic numbers here.

I think the reason Jerry didn't add them is due to symmetry. All the
current ND_CMD_ definitions have corresponding ND_IOCTL_ definitions.
These new commands we're only adding function number support and using
ND_CMD_CALL for the ioctl transport. We can still add definitions for
them, but perhaps with an ACPI_NFIT_DSM_ prefix? The only consumer in
the kernel of this is debug output code. I think perhaps we should
just delete them here and either print raw numbers or enable
acpi_nfit_ctl() to the decode and not rely on nvdimm_bus_cmd_name()
which is meant to represent NVDIMM bus type generic command numbers.


[PATCH] Drivers: unisys: visorhba - style fix

2017-06-08 Thread Derek Robson
Fixed style of permissions to octal.
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 2fd31c9762c6..a6e7a6bbc428 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -1090,7 +1090,7 @@ static int visorhba_probe(struct visor_device *dev)
goto err_scsi_remove_host;
}
devdata->debugfs_info =
-   debugfs_create_file("info", S_IRUSR | S_IRGRP,
+   debugfs_create_file("info", 0440,
devdata->debugfs_dir, devdata,
_debugfs_fops);
if (!devdata->debugfs_info) {
-- 
2.13.0



[PATCH] Drivers: unisys: visorhba - style fix

2017-06-08 Thread Derek Robson
Fixed style of permissions to octal.
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 2fd31c9762c6..a6e7a6bbc428 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -1090,7 +1090,7 @@ static int visorhba_probe(struct visor_device *dev)
goto err_scsi_remove_host;
}
devdata->debugfs_info =
-   debugfs_create_file("info", S_IRUSR | S_IRGRP,
+   debugfs_create_file("info", 0440,
devdata->debugfs_dir, devdata,
_debugfs_fops);
if (!devdata->debugfs_info) {
-- 
2.13.0



[PATCH 2/9] libnvdimm, label: add v1.2 interleave-set-cookie algorithm

2017-06-08 Thread Dan Williams
The interleave-set-cookie algorithm is extended to incorporate all the
same components that are used to generate an nvdimm unique-id. For
backwards compatibility we still maintain the old v1.1 definition.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|   53 ++-
 drivers/nvdimm/label.c  |3 +-
 drivers/nvdimm/namespace_devs.c |9 +--
 drivers/nvdimm/nd.h |3 +-
 drivers/nvdimm/region_devs.c|   43 
 include/linux/libnvdimm.h   |5 +++-
 6 files changed, 104 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 097eff0b963d..db21f5b62562 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1663,12 +1663,29 @@ struct nfit_set_info {
} mapping[0];
 };
 
+struct nfit_set_info2 {
+   struct nfit_set_info_map2 {
+   u64 region_offset;
+   u32 serial_number;
+   u16 vendor_id;
+   u16 manufacturing_date;
+   u8  manufacturing_location;
+   u8  reserved[31];
+   } mapping[0];
+};
+
 static size_t sizeof_nfit_set_info(int num_mappings)
 {
return sizeof(struct nfit_set_info)
+ num_mappings * sizeof(struct nfit_set_info_map);
 }
 
+static size_t sizeof_nfit_set_info2(int num_mappings)
+{
+   return sizeof(struct nfit_set_info2)
+   + num_mappings * sizeof(struct nfit_set_info_map2);
+}
+
 static int cmp_map_compat(const void *m0, const void *m1)
 {
const struct nfit_set_info_map *map0 = m0;
@@ -1690,6 +1707,18 @@ static int cmp_map(const void *m0, const void *m1)
return 0;
 }
 
+static int cmp_map2(const void *m0, const void *m1)
+{
+   const struct nfit_set_info_map2 *map0 = m0;
+   const struct nfit_set_info_map2 *map1 = m1;
+
+   if (map0->region_offset < map1->region_offset)
+   return -1;
+   else if (map0->region_offset > map1->region_offset)
+   return 1;
+   return 0;
+}
+
 /* Retrieve the nth entry referencing this spa */
 static struct acpi_nfit_memory_map *memdev_from_spa(
struct acpi_nfit_desc *acpi_desc, u16 range_index, int n)
@@ -1711,6 +1740,7 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
u16 nr = ndr_desc->num_mappings;
+   struct nfit_set_info2 *info2;
struct nfit_set_info *info;
 
if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
@@ -1725,9 +1755,15 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
+
+   info2 = devm_kzalloc(dev, sizeof_nfit_set_info2(nr), GFP_KERNEL);
+   if (!info2)
+   return -ENOMEM;
+
for (i = 0; i < nr; i++) {
struct nd_mapping_desc *mapping = _desc->mapping[i];
struct nfit_set_info_map *map = >mapping[i];
+   struct nfit_set_info_map2 *map2 = >mapping[i];
struct nvdimm *nvdimm = mapping->nvdimm;
struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
struct acpi_nfit_memory_map *memdev = memdev_from_spa(acpi_desc,
@@ -1740,19 +1776,32 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
 
map->region_offset = memdev->region_offset;
map->serial_number = nfit_mem->dcr->serial_number;
+
+   map2->region_offset = memdev->region_offset;
+   map2->serial_number = nfit_mem->dcr->serial_number;
+   map2->vendor_id = nfit_mem->dcr->vendor_id;
+   map2->manufacturing_date = nfit_mem->dcr->manufacturing_date;
+   map2->manufacturing_location = 
nfit_mem->dcr->manufacturing_location;
}
 
+   /* v1.1 namespaces */
sort(>mapping[0], nr, sizeof(struct nfit_set_info_map),
cmp_map, NULL);
-   nd_set->cookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
+   nd_set->cookie1 = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
+
+   /* v1.2 namespaces */
+   sort(>mapping[0], nr, sizeof(struct nfit_set_info_map2),
+   cmp_map2, NULL);
+   nd_set->cookie2 = nd_fletcher64(info, sizeof_nfit_set_info2(nr), 0);
 
-   /* support namespaces created with the wrong sort order */
+   /* support v1.1 namespaces created with the wrong sort order */
sort(>mapping[0], nr, sizeof(struct nfit_set_info_map),
cmp_map_compat, NULL);
nd_set->altcookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
 
ndr_desc->nd_set = nd_set;
devm_kfree(dev, info);
+   devm_kfree(dev, info2);
 

[PATCH 2/9] libnvdimm, label: add v1.2 interleave-set-cookie algorithm

2017-06-08 Thread Dan Williams
The interleave-set-cookie algorithm is extended to incorporate all the
same components that are used to generate an nvdimm unique-id. For
backwards compatibility we still maintain the old v1.1 definition.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|   53 ++-
 drivers/nvdimm/label.c  |3 +-
 drivers/nvdimm/namespace_devs.c |9 +--
 drivers/nvdimm/nd.h |3 +-
 drivers/nvdimm/region_devs.c|   43 
 include/linux/libnvdimm.h   |5 +++-
 6 files changed, 104 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 097eff0b963d..db21f5b62562 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1663,12 +1663,29 @@ struct nfit_set_info {
} mapping[0];
 };
 
+struct nfit_set_info2 {
+   struct nfit_set_info_map2 {
+   u64 region_offset;
+   u32 serial_number;
+   u16 vendor_id;
+   u16 manufacturing_date;
+   u8  manufacturing_location;
+   u8  reserved[31];
+   } mapping[0];
+};
+
 static size_t sizeof_nfit_set_info(int num_mappings)
 {
return sizeof(struct nfit_set_info)
+ num_mappings * sizeof(struct nfit_set_info_map);
 }
 
+static size_t sizeof_nfit_set_info2(int num_mappings)
+{
+   return sizeof(struct nfit_set_info2)
+   + num_mappings * sizeof(struct nfit_set_info_map2);
+}
+
 static int cmp_map_compat(const void *m0, const void *m1)
 {
const struct nfit_set_info_map *map0 = m0;
@@ -1690,6 +1707,18 @@ static int cmp_map(const void *m0, const void *m1)
return 0;
 }
 
+static int cmp_map2(const void *m0, const void *m1)
+{
+   const struct nfit_set_info_map2 *map0 = m0;
+   const struct nfit_set_info_map2 *map1 = m1;
+
+   if (map0->region_offset < map1->region_offset)
+   return -1;
+   else if (map0->region_offset > map1->region_offset)
+   return 1;
+   return 0;
+}
+
 /* Retrieve the nth entry referencing this spa */
 static struct acpi_nfit_memory_map *memdev_from_spa(
struct acpi_nfit_desc *acpi_desc, u16 range_index, int n)
@@ -1711,6 +1740,7 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
u16 nr = ndr_desc->num_mappings;
+   struct nfit_set_info2 *info2;
struct nfit_set_info *info;
 
if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
@@ -1725,9 +1755,15 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
+
+   info2 = devm_kzalloc(dev, sizeof_nfit_set_info2(nr), GFP_KERNEL);
+   if (!info2)
+   return -ENOMEM;
+
for (i = 0; i < nr; i++) {
struct nd_mapping_desc *mapping = _desc->mapping[i];
struct nfit_set_info_map *map = >mapping[i];
+   struct nfit_set_info_map2 *map2 = >mapping[i];
struct nvdimm *nvdimm = mapping->nvdimm;
struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
struct acpi_nfit_memory_map *memdev = memdev_from_spa(acpi_desc,
@@ -1740,19 +1776,32 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
 
map->region_offset = memdev->region_offset;
map->serial_number = nfit_mem->dcr->serial_number;
+
+   map2->region_offset = memdev->region_offset;
+   map2->serial_number = nfit_mem->dcr->serial_number;
+   map2->vendor_id = nfit_mem->dcr->vendor_id;
+   map2->manufacturing_date = nfit_mem->dcr->manufacturing_date;
+   map2->manufacturing_location = 
nfit_mem->dcr->manufacturing_location;
}
 
+   /* v1.1 namespaces */
sort(>mapping[0], nr, sizeof(struct nfit_set_info_map),
cmp_map, NULL);
-   nd_set->cookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
+   nd_set->cookie1 = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
+
+   /* v1.2 namespaces */
+   sort(>mapping[0], nr, sizeof(struct nfit_set_info_map2),
+   cmp_map2, NULL);
+   nd_set->cookie2 = nd_fletcher64(info, sizeof_nfit_set_info2(nr), 0);
 
-   /* support namespaces created with the wrong sort order */
+   /* support v1.1 namespaces created with the wrong sort order */
sort(>mapping[0], nr, sizeof(struct nfit_set_info_map),
cmp_map_compat, NULL);
nd_set->altcookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
 
ndr_desc->nd_set = nd_set;
devm_kfree(dev, info);
+   devm_kfree(dev, info2);
 
return 0;
 }
diff --git 

[PATCH 4/9] libnvdimm, label: populate the type_guid property for v1.2 namespaces

2017-06-08 Thread Dan Williams
The type_guid refers to the "Address Range Type GUID" for the region
backing a namespace as defined the ACPI NFIT (NVDIMM Firmware Interface
Table). This 'type' identifier specifies an access mechanism for the
given namespace. This capability replaces the confusing usage of the
'NSLABEL_FLAG_LOCAL' flag to indicate a block-aperture-mode namespace.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|   15 +++---
 drivers/nvdimm/label.c  |6 
 drivers/nvdimm/namespace_devs.c |   57 ++-
 include/linux/libnvdimm.h   |3 ++
 4 files changed, 57 insertions(+), 24 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index db21f5b62562..83ee3c829411 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1743,15 +1743,17 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
struct nfit_set_info2 *info2;
struct nfit_set_info *info;
 
+   nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
+   if (!nd_set)
+   return -ENOMEM;
+   ndr_desc->nd_set = nd_set;
+   guid_copy(_set->type_guid, (guid_t *) spa->range_guid);
+
if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
/* pass */;
else
return 0;
 
-   nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
-   if (!nd_set)
-   return -ENOMEM;
-
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -2228,7 +2230,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
struct acpi_nfit_system_address *spa = nfit_spa->spa;
struct nd_blk_region_desc *ndbr_desc;
struct nfit_mem *nfit_mem;
-   int blk_valid = 0;
+   int blk_valid = 0, rc;
 
if (!nvdimm) {
dev_err(acpi_desc->dev, "spa%d dimm: %#x not found\n",
@@ -2260,6 +2262,9 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
ndbr_desc = to_blk_region_desc(ndr_desc);
ndbr_desc->enable = acpi_nfit_blk_region_enable;
ndbr_desc->do_io = acpi_desc->blk_do_io;
+   rc = acpi_nfit_init_interleave_set(acpi_desc, ndr_desc, spa);
+   if (rc)
+   return rc;
nfit_spa->nd_region = 
nvdimm_blk_region_create(acpi_desc->nvdimm_bus,
ndr_desc);
if (!nfit_spa->nd_region)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 1aacd4866c76..d8b87d3a0ebe 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -553,6 +553,7 @@ static int __pmem_label_update(struct nd_region *nd_region,
struct nd_mapping *nd_mapping, struct nd_namespace_pmem *nspm,
int pos)
 {
+   struct nd_interleave_set *nd_set = nd_region->nd_set;
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct nd_label_ent *label_ent, *victim = NULL;
struct nd_namespace_label *nd_label;
@@ -597,6 +598,8 @@ static int __pmem_label_update(struct nd_region *nd_region,
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->slot = __cpu_to_le32(slot);
+   if (namespace_label_has(ndd, type_guid))
+   guid_copy(_label->type_guid, _set->type_guid);
nd_dbg_dpa(nd_region, ndd, res, "%s\n", __func__);
 
/* update label */
@@ -684,6 +687,7 @@ static int __blk_label_update(struct nd_region *nd_region,
int num_labels)
 {
int i, alloc, victims, nfree, old_num_resources, nlabel, rc = -ENXIO;
+   struct nd_interleave_set *nd_set = nd_region->nd_set;
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct nd_namespace_label *nd_label;
struct nd_label_ent *label_ent, *e;
@@ -788,6 +792,8 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->lbasize = __cpu_to_le64(nsblk->lbasize);
nd_label->slot = __cpu_to_le32(slot);
+   if (namespace_label_has(ndd, type_guid))
+   guid_copy(_label->type_guid, _set->type_guid);
 
/* update label */
offset = nd_label_offset(ndd, nd_label);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index e034b003a5e2..e101aec186c7 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1639,6 +1639,8 @@ static bool has_uuid_at_pos(struct nd_region *nd_region, 
u8 *uuid,
 
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = _region->mapping[i];
+   struct nd_interleave_set *nd_set = nd_region->nd_set;
+   struct 

[PATCH 4/9] libnvdimm, label: populate the type_guid property for v1.2 namespaces

2017-06-08 Thread Dan Williams
The type_guid refers to the "Address Range Type GUID" for the region
backing a namespace as defined the ACPI NFIT (NVDIMM Firmware Interface
Table). This 'type' identifier specifies an access mechanism for the
given namespace. This capability replaces the confusing usage of the
'NSLABEL_FLAG_LOCAL' flag to indicate a block-aperture-mode namespace.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|   15 +++---
 drivers/nvdimm/label.c  |6 
 drivers/nvdimm/namespace_devs.c |   57 ++-
 include/linux/libnvdimm.h   |3 ++
 4 files changed, 57 insertions(+), 24 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index db21f5b62562..83ee3c829411 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1743,15 +1743,17 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
struct nfit_set_info2 *info2;
struct nfit_set_info *info;
 
+   nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
+   if (!nd_set)
+   return -ENOMEM;
+   ndr_desc->nd_set = nd_set;
+   guid_copy(_set->type_guid, (guid_t *) spa->range_guid);
+
if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
/* pass */;
else
return 0;
 
-   nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
-   if (!nd_set)
-   return -ENOMEM;
-
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -2228,7 +2230,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
struct acpi_nfit_system_address *spa = nfit_spa->spa;
struct nd_blk_region_desc *ndbr_desc;
struct nfit_mem *nfit_mem;
-   int blk_valid = 0;
+   int blk_valid = 0, rc;
 
if (!nvdimm) {
dev_err(acpi_desc->dev, "spa%d dimm: %#x not found\n",
@@ -2260,6 +2262,9 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
ndbr_desc = to_blk_region_desc(ndr_desc);
ndbr_desc->enable = acpi_nfit_blk_region_enable;
ndbr_desc->do_io = acpi_desc->blk_do_io;
+   rc = acpi_nfit_init_interleave_set(acpi_desc, ndr_desc, spa);
+   if (rc)
+   return rc;
nfit_spa->nd_region = 
nvdimm_blk_region_create(acpi_desc->nvdimm_bus,
ndr_desc);
if (!nfit_spa->nd_region)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 1aacd4866c76..d8b87d3a0ebe 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -553,6 +553,7 @@ static int __pmem_label_update(struct nd_region *nd_region,
struct nd_mapping *nd_mapping, struct nd_namespace_pmem *nspm,
int pos)
 {
+   struct nd_interleave_set *nd_set = nd_region->nd_set;
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct nd_label_ent *label_ent, *victim = NULL;
struct nd_namespace_label *nd_label;
@@ -597,6 +598,8 @@ static int __pmem_label_update(struct nd_region *nd_region,
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->slot = __cpu_to_le32(slot);
+   if (namespace_label_has(ndd, type_guid))
+   guid_copy(_label->type_guid, _set->type_guid);
nd_dbg_dpa(nd_region, ndd, res, "%s\n", __func__);
 
/* update label */
@@ -684,6 +687,7 @@ static int __blk_label_update(struct nd_region *nd_region,
int num_labels)
 {
int i, alloc, victims, nfree, old_num_resources, nlabel, rc = -ENXIO;
+   struct nd_interleave_set *nd_set = nd_region->nd_set;
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct nd_namespace_label *nd_label;
struct nd_label_ent *label_ent, *e;
@@ -788,6 +792,8 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->lbasize = __cpu_to_le64(nsblk->lbasize);
nd_label->slot = __cpu_to_le32(slot);
+   if (namespace_label_has(ndd, type_guid))
+   guid_copy(_label->type_guid, _set->type_guid);
 
/* update label */
offset = nd_label_offset(ndd, nd_label);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index e034b003a5e2..e101aec186c7 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1639,6 +1639,8 @@ static bool has_uuid_at_pos(struct nd_region *nd_region, 
u8 *uuid,
 
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = _region->mapping[i];
+   struct nd_interleave_set *nd_set = nd_region->nd_set;
+   struct nvdimm_drvdata *ndd = 

[PATCH 7/9] libnvdimm, label: add v1.2 label checksum support

2017-06-08 Thread Dan Williams
The v1.2 namespace label specification adds a fletcher checksum to each
label instance. Add generation and validation support for the new field.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   39 +++
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index d7f9916c6ed5..c503362a03c7 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -326,7 +326,8 @@ static bool preamble_next(struct nvdimm_drvdata *ndd,
free, nslot);
 }
 
-static bool slot_valid(struct nd_namespace_label *nd_label, u32 slot)
+static bool slot_valid(struct nvdimm_drvdata *ndd,
+   struct nd_namespace_label *nd_label, u32 slot)
 {
/* check that we are written where we expect to be written */
if (slot != __le32_to_cpu(nd_label->slot))
@@ -337,6 +338,21 @@ static bool slot_valid(struct nd_namespace_label 
*nd_label, u32 slot)
| __le64_to_cpu(nd_label->rawsize)) % SZ_4K)
return false;
 
+   /* check checksum */
+   if (namespace_label_has(ndd, checksum)) {
+   u64 sum, sum_save;
+
+   sum_save = __le64_to_cpu(nd_label->checksum);
+   nd_label->checksum = __cpu_to_le64(0);
+   sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
+   nd_label->checksum = __cpu_to_le64(sum_save);
+   if (sum != sum_save) {
+   dev_dbg(ndd->dev, "%s fail checksum. slot: %d expect: 
%#llx\n",
+   __func__, slot, sum);
+   return false;
+   }
+   }
+
return true;
 }
 
@@ -359,7 +375,7 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd)
 
nd_label = to_label(ndd, slot);
 
-   if (!slot_valid(nd_label, slot))
+   if (!slot_valid(ndd, nd_label, slot))
continue;
 
memcpy(label_uuid, nd_label->uuid, NSLABEL_UUID_LEN);
@@ -391,7 +407,7 @@ int nd_label_active_count(struct nvdimm_drvdata *ndd)
 
nd_label = to_label(ndd, slot);
 
-   if (!slot_valid(nd_label, slot)) {
+   if (!slot_valid(ndd, nd_label, slot)) {
u32 label_slot = __le32_to_cpu(nd_label->slot);
u64 size = __le64_to_cpu(nd_label->rawsize);
u64 dpa = __le64_to_cpu(nd_label->dpa);
@@ -419,7 +435,7 @@ struct nd_namespace_label *nd_label_active(struct 
nvdimm_drvdata *ndd, int n)
struct nd_namespace_label *nd_label;
 
nd_label = to_label(ndd, slot);
-   if (!slot_valid(nd_label, slot))
+   if (!slot_valid(ndd, nd_label, slot))
continue;
 
if (n-- == 0)
@@ -600,6 +616,13 @@ static int __pmem_label_update(struct nd_region *nd_region,
nd_label->slot = __cpu_to_le32(slot);
if (namespace_label_has(ndd, type_guid))
guid_copy(_label->type_guid, _set->type_guid);
+   if (namespace_label_has(ndd, checksum)) {
+   u64 sum;
+
+   nd_label->checksum = __cpu_to_le64(0);
+   sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
+   nd_label->checksum = __cpu_to_le64(sum);
+   }
nd_dbg_dpa(nd_region, ndd, res, "%s\n", __func__);
 
/* update label */
@@ -825,6 +848,14 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->slot = __cpu_to_le32(slot);
if (namespace_label_has(ndd, type_guid))
guid_copy(_label->type_guid, _set->type_guid);
+   if (namespace_label_has(ndd, checksum)) {
+   u64 sum;
+
+   nd_label->checksum = __cpu_to_le64(0);
+   sum = nd_fletcher64(nd_label,
+   sizeof_namespace_label(ndd), 1);
+   nd_label->checksum = __cpu_to_le64(sum);
+   }
 
/* update label */
offset = nd_label_offset(ndd, nd_label);



[PATCH 7/9] libnvdimm, label: add v1.2 label checksum support

2017-06-08 Thread Dan Williams
The v1.2 namespace label specification adds a fletcher checksum to each
label instance. Add generation and validation support for the new field.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   39 +++
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index d7f9916c6ed5..c503362a03c7 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -326,7 +326,8 @@ static bool preamble_next(struct nvdimm_drvdata *ndd,
free, nslot);
 }
 
-static bool slot_valid(struct nd_namespace_label *nd_label, u32 slot)
+static bool slot_valid(struct nvdimm_drvdata *ndd,
+   struct nd_namespace_label *nd_label, u32 slot)
 {
/* check that we are written where we expect to be written */
if (slot != __le32_to_cpu(nd_label->slot))
@@ -337,6 +338,21 @@ static bool slot_valid(struct nd_namespace_label 
*nd_label, u32 slot)
| __le64_to_cpu(nd_label->rawsize)) % SZ_4K)
return false;
 
+   /* check checksum */
+   if (namespace_label_has(ndd, checksum)) {
+   u64 sum, sum_save;
+
+   sum_save = __le64_to_cpu(nd_label->checksum);
+   nd_label->checksum = __cpu_to_le64(0);
+   sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
+   nd_label->checksum = __cpu_to_le64(sum_save);
+   if (sum != sum_save) {
+   dev_dbg(ndd->dev, "%s fail checksum. slot: %d expect: 
%#llx\n",
+   __func__, slot, sum);
+   return false;
+   }
+   }
+
return true;
 }
 
@@ -359,7 +375,7 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd)
 
nd_label = to_label(ndd, slot);
 
-   if (!slot_valid(nd_label, slot))
+   if (!slot_valid(ndd, nd_label, slot))
continue;
 
memcpy(label_uuid, nd_label->uuid, NSLABEL_UUID_LEN);
@@ -391,7 +407,7 @@ int nd_label_active_count(struct nvdimm_drvdata *ndd)
 
nd_label = to_label(ndd, slot);
 
-   if (!slot_valid(nd_label, slot)) {
+   if (!slot_valid(ndd, nd_label, slot)) {
u32 label_slot = __le32_to_cpu(nd_label->slot);
u64 size = __le64_to_cpu(nd_label->rawsize);
u64 dpa = __le64_to_cpu(nd_label->dpa);
@@ -419,7 +435,7 @@ struct nd_namespace_label *nd_label_active(struct 
nvdimm_drvdata *ndd, int n)
struct nd_namespace_label *nd_label;
 
nd_label = to_label(ndd, slot);
-   if (!slot_valid(nd_label, slot))
+   if (!slot_valid(ndd, nd_label, slot))
continue;
 
if (n-- == 0)
@@ -600,6 +616,13 @@ static int __pmem_label_update(struct nd_region *nd_region,
nd_label->slot = __cpu_to_le32(slot);
if (namespace_label_has(ndd, type_guid))
guid_copy(_label->type_guid, _set->type_guid);
+   if (namespace_label_has(ndd, checksum)) {
+   u64 sum;
+
+   nd_label->checksum = __cpu_to_le64(0);
+   sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
+   nd_label->checksum = __cpu_to_le64(sum);
+   }
nd_dbg_dpa(nd_region, ndd, res, "%s\n", __func__);
 
/* update label */
@@ -825,6 +848,14 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->slot = __cpu_to_le32(slot);
if (namespace_label_has(ndd, type_guid))
guid_copy(_label->type_guid, _set->type_guid);
+   if (namespace_label_has(ndd, checksum)) {
+   u64 sum;
+
+   nd_label->checksum = __cpu_to_le64(0);
+   sum = nd_fletcher64(nd_label,
+   sizeof_namespace_label(ndd), 1);
+   nd_label->checksum = __cpu_to_le64(sum);
+   }
 
/* update label */
offset = nd_label_offset(ndd, nd_label);



[PATCH 9/9] libnvdimm, label: switch to using v1.2 labels by default

2017-06-08 Thread Dan Williams
The rules for which version of the label specification are in effect at
any given point in time are as follows:

1/ If a DIMM has an existing / valid index block then the version
   specified is used regardless if it is a previous version.

2/ By default when the kernel is initializing new index blocks the
   latest specification version (v1.2 at time of writing) is used.

3/ An environment that wants to force create v1.1 label-sets must
   arrange for userspace to disable all active regions / namespaces /
   dimms and write a valid set of v1.1 index blocks to the dimms.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 837bf21c8555..235f2089fab2 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -222,9 +222,10 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
 * need to know the size of the labels, and we can't trust the
 * size of the labels until we validate the index blocks.
 * Resolve this dependency loop by probing for known label
-* sizes.
+* sizes, but default to v1.2 256-byte namespace labels if
+* discovery fails.
 */
-   int label_size[] = { 256, 128 };
+   int label_size[] = { 128, 256 };
int i, rc;
 
for (i = 0; i < ARRAY_SIZE(label_size); i++) {
@@ -532,7 +533,10 @@ static int nd_label_write_index(struct nvdimm_drvdata 
*ndd, int index, u32 seq,
nsindex->labeloff = __cpu_to_le64(offset);
nsindex->nslot = __cpu_to_le32(nslot);
nsindex->major = __cpu_to_le16(1);
-   nsindex->minor = __cpu_to_le16(1);
+   if (sizeof_namespace_label(ndd) < 256)
+   nsindex->minor = __cpu_to_le16(1);
+   else
+   nsindex->minor = __cpu_to_le16(2);
nsindex->checksum = __cpu_to_le64(0);
if (flags & ND_NSINDEX_INIT) {
unsigned long *free = (unsigned long *) nsindex->free;



[PATCH 8/9] libnvdimm, label: add address abstraction identifiers

2017-06-08 Thread Dan Williams
Starting with v1.2 labels, 'address abstractions' can be hinted via an
address abstraction id that implies an info-block format. The standard
address abstraction in the specification is the v2 format of the
Block-Translation-Table (BTT). Support for that is saved for a later
patch, for now we add support for the Linux supported address
abstractions BTT (v1), PFN, and DAX.

The new 'holder_class' attribute for namespace devices is added for
tooling to specify the 'abstraction_guid' to store in the namespace label.
For v1.1 labels this field is undefined and any setting of
'holder_class' away from the default 'none' value will only have effect
until the driver is unloaded. Setting 'holder_class' requires that
whatever device tries to claim the namespace must be of the specified
class.

Cc: Vishal Verma 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt_devs.c   |8 
 drivers/nvdimm/claim.c  |   28 +++
 drivers/nvdimm/core.c   |3 ++
 drivers/nvdimm/dax_devs.c   |8 
 drivers/nvdimm/label.c  |   58 +++
 drivers/nvdimm/label.h  |5 +++
 drivers/nvdimm/namespace_devs.c |   74 +++
 drivers/nvdimm/nd.h |1 +
 drivers/nvdimm/pfn_devs.c   |8 
 include/linux/nd.h  |   10 +
 10 files changed, 203 insertions(+)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 4c989bb9a8a0..31d875a91569 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -295,6 +295,14 @@ int nd_btt_probe(struct device *dev, struct 
nd_namespace_common *ndns)
if (ndns->force_raw)
return -ENODEV;
 
+   switch (ndns->claim_class) {
+   case NVDIMM_CCLASS_NONE:
+   case NVDIMM_CCLASS_BTT:
+   break;
+   default:
+   return -ENODEV;
+   }
+
nvdimm_bus_lock(>dev);
btt_dev = __nd_btt_create(nd_region, 0, NULL, ndns);
nvdimm_bus_unlock(>dev);
diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
index 7ceb5fa4f2a1..de9b1cce242e 100644
--- a/drivers/nvdimm/claim.c
+++ b/drivers/nvdimm/claim.c
@@ -184,6 +184,34 @@ ssize_t nd_namespace_store(struct device *dev,
}
 
ndns = to_ndns(found);
+
+   switch (ndns->claim_class) {
+   case NVDIMM_CCLASS_NONE:
+   break;
+   case NVDIMM_CCLASS_BTT:
+   if (!is_nd_btt(dev)) {
+   len = -EBUSY;
+   goto out_attach;
+   }
+   break;
+   case NVDIMM_CCLASS_PFN:
+   if (!is_nd_pfn(dev)) {
+   len = -EBUSY;
+   goto out_attach;
+   }
+   break;
+   case NVDIMM_CCLASS_DAX:
+   if (!is_nd_dax(dev)) {
+   len = -EBUSY;
+   goto out_attach;
+   }
+   break;
+   default:
+   len = -EBUSY;
+   goto out_attach;
+   break;
+   }
+
if (__nvdimm_namespace_capacity(ndns) < SZ_16M) {
dev_dbg(dev, "%s too small to host\n", name);
len = -ENXIO;
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 2dee908e4bae..ed0bf174d128 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -699,6 +699,9 @@ static __init int libnvdimm_init(void)
rc = nd_region_init();
if (rc)
goto err_region;
+
+   nd_label_init();
+
return 0;
  err_region:
nvdimm_exit();
diff --git a/drivers/nvdimm/dax_devs.c b/drivers/nvdimm/dax_devs.c
index c1b6556aea6e..59f676381ae5 100644
--- a/drivers/nvdimm/dax_devs.c
+++ b/drivers/nvdimm/dax_devs.c
@@ -111,6 +111,14 @@ int nd_dax_probe(struct device *dev, struct 
nd_namespace_common *ndns)
if (ndns->force_raw)
return -ENODEV;
 
+   switch (ndns->claim_class) {
+   case NVDIMM_CCLASS_NONE:
+   case NVDIMM_CCLASS_DAX:
+   break;
+   default:
+   return -ENODEV;
+   }
+
nvdimm_bus_lock(>dev);
nd_dax = nd_dax_alloc(nd_region);
nd_pfn = _dax->nd_pfn;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index c503362a03c7..837bf21c8555 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -12,6 +12,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,10 @@
 #include "label.h"
 #include "nd.h"
 
+static guid_t nvdimm_btt_guid;
+static guid_t nvdimm_pfn_guid;
+static guid_t nvdimm_dax_guid;
+
 static u32 best_seq(u32 a, u32 b)
 {
a &= NSINDEX_SEQ_MASK;
@@ -565,10 +570,44 @@ static unsigned long nd_label_offset(struct 
nvdimm_drvdata *ndd,
- (unsigned long) to_namespace_index(ndd, 0);
 }
 
+enum nvdimm_claim_class to_nvdimm_cclass(guid_t *guid)
+{
+   if 

[PATCH 9/9] libnvdimm, label: switch to using v1.2 labels by default

2017-06-08 Thread Dan Williams
The rules for which version of the label specification are in effect at
any given point in time are as follows:

1/ If a DIMM has an existing / valid index block then the version
   specified is used regardless if it is a previous version.

2/ By default when the kernel is initializing new index blocks the
   latest specification version (v1.2 at time of writing) is used.

3/ An environment that wants to force create v1.1 label-sets must
   arrange for userspace to disable all active regions / namespaces /
   dimms and write a valid set of v1.1 index blocks to the dimms.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 837bf21c8555..235f2089fab2 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -222,9 +222,10 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
 * need to know the size of the labels, and we can't trust the
 * size of the labels until we validate the index blocks.
 * Resolve this dependency loop by probing for known label
-* sizes.
+* sizes, but default to v1.2 256-byte namespace labels if
+* discovery fails.
 */
-   int label_size[] = { 256, 128 };
+   int label_size[] = { 128, 256 };
int i, rc;
 
for (i = 0; i < ARRAY_SIZE(label_size); i++) {
@@ -532,7 +533,10 @@ static int nd_label_write_index(struct nvdimm_drvdata 
*ndd, int index, u32 seq,
nsindex->labeloff = __cpu_to_le64(offset);
nsindex->nslot = __cpu_to_le32(nslot);
nsindex->major = __cpu_to_le16(1);
-   nsindex->minor = __cpu_to_le16(1);
+   if (sizeof_namespace_label(ndd) < 256)
+   nsindex->minor = __cpu_to_le16(1);
+   else
+   nsindex->minor = __cpu_to_le16(2);
nsindex->checksum = __cpu_to_le64(0);
if (flags & ND_NSINDEX_INIT) {
unsigned long *free = (unsigned long *) nsindex->free;



[PATCH 8/9] libnvdimm, label: add address abstraction identifiers

2017-06-08 Thread Dan Williams
Starting with v1.2 labels, 'address abstractions' can be hinted via an
address abstraction id that implies an info-block format. The standard
address abstraction in the specification is the v2 format of the
Block-Translation-Table (BTT). Support for that is saved for a later
patch, for now we add support for the Linux supported address
abstractions BTT (v1), PFN, and DAX.

The new 'holder_class' attribute for namespace devices is added for
tooling to specify the 'abstraction_guid' to store in the namespace label.
For v1.1 labels this field is undefined and any setting of
'holder_class' away from the default 'none' value will only have effect
until the driver is unloaded. Setting 'holder_class' requires that
whatever device tries to claim the namespace must be of the specified
class.

Cc: Vishal Verma 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt_devs.c   |8 
 drivers/nvdimm/claim.c  |   28 +++
 drivers/nvdimm/core.c   |3 ++
 drivers/nvdimm/dax_devs.c   |8 
 drivers/nvdimm/label.c  |   58 +++
 drivers/nvdimm/label.h  |5 +++
 drivers/nvdimm/namespace_devs.c |   74 +++
 drivers/nvdimm/nd.h |1 +
 drivers/nvdimm/pfn_devs.c   |8 
 include/linux/nd.h  |   10 +
 10 files changed, 203 insertions(+)

diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 4c989bb9a8a0..31d875a91569 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -295,6 +295,14 @@ int nd_btt_probe(struct device *dev, struct 
nd_namespace_common *ndns)
if (ndns->force_raw)
return -ENODEV;
 
+   switch (ndns->claim_class) {
+   case NVDIMM_CCLASS_NONE:
+   case NVDIMM_CCLASS_BTT:
+   break;
+   default:
+   return -ENODEV;
+   }
+
nvdimm_bus_lock(>dev);
btt_dev = __nd_btt_create(nd_region, 0, NULL, ndns);
nvdimm_bus_unlock(>dev);
diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
index 7ceb5fa4f2a1..de9b1cce242e 100644
--- a/drivers/nvdimm/claim.c
+++ b/drivers/nvdimm/claim.c
@@ -184,6 +184,34 @@ ssize_t nd_namespace_store(struct device *dev,
}
 
ndns = to_ndns(found);
+
+   switch (ndns->claim_class) {
+   case NVDIMM_CCLASS_NONE:
+   break;
+   case NVDIMM_CCLASS_BTT:
+   if (!is_nd_btt(dev)) {
+   len = -EBUSY;
+   goto out_attach;
+   }
+   break;
+   case NVDIMM_CCLASS_PFN:
+   if (!is_nd_pfn(dev)) {
+   len = -EBUSY;
+   goto out_attach;
+   }
+   break;
+   case NVDIMM_CCLASS_DAX:
+   if (!is_nd_dax(dev)) {
+   len = -EBUSY;
+   goto out_attach;
+   }
+   break;
+   default:
+   len = -EBUSY;
+   goto out_attach;
+   break;
+   }
+
if (__nvdimm_namespace_capacity(ndns) < SZ_16M) {
dev_dbg(dev, "%s too small to host\n", name);
len = -ENXIO;
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 2dee908e4bae..ed0bf174d128 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -699,6 +699,9 @@ static __init int libnvdimm_init(void)
rc = nd_region_init();
if (rc)
goto err_region;
+
+   nd_label_init();
+
return 0;
  err_region:
nvdimm_exit();
diff --git a/drivers/nvdimm/dax_devs.c b/drivers/nvdimm/dax_devs.c
index c1b6556aea6e..59f676381ae5 100644
--- a/drivers/nvdimm/dax_devs.c
+++ b/drivers/nvdimm/dax_devs.c
@@ -111,6 +111,14 @@ int nd_dax_probe(struct device *dev, struct 
nd_namespace_common *ndns)
if (ndns->force_raw)
return -ENODEV;
 
+   switch (ndns->claim_class) {
+   case NVDIMM_CCLASS_NONE:
+   case NVDIMM_CCLASS_DAX:
+   break;
+   default:
+   return -ENODEV;
+   }
+
nvdimm_bus_lock(>dev);
nd_dax = nd_dax_alloc(nd_region);
nd_pfn = _dax->nd_pfn;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index c503362a03c7..837bf21c8555 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -12,6 +12,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,10 @@
 #include "label.h"
 #include "nd.h"
 
+static guid_t nvdimm_btt_guid;
+static guid_t nvdimm_pfn_guid;
+static guid_t nvdimm_dax_guid;
+
 static u32 best_seq(u32 a, u32 b)
 {
a &= NSINDEX_SEQ_MASK;
@@ -565,10 +570,44 @@ static unsigned long nd_label_offset(struct 
nvdimm_drvdata *ndd,
- (unsigned long) to_namespace_index(ndd, 0);
 }
 
+enum nvdimm_claim_class to_nvdimm_cclass(guid_t *guid)
+{
+   if (guid_equal(guid, _btt_guid))
+   return 

[PATCH 0/9] libnvdimm, label: namespace specification v1.2 support

2017-06-08 Thread Dan Williams
The recently released UEFI 2.7 Specification [1], includes an updated
version (v1.2) of the NVDIMM Namespace Label Specification that was previously
published on pmem.io [2] (v1.1).

In the process of moving to a UEFI standard definition the v1.2 updates
adds several features for improved cross-OS and pre-OS (EFI driver)
compatibility and safety. The major highlights include:

1/ Support for an "address abstraction guid" so that implementations can
   uniquely identify personalities layered on top of a namespace. A
   standard address abstraction definition example is the BTT (Block
   Translation Table for sector atomicity) layout. A private / local
   abstraction definition example is the Linux device-DAX personality.

2/ Checksums for individual label slots

3/ Additional safety and self-consistency properties like an updated
   interleave-set-cookie algorithm and recording the NFIT address-type-guid
   in the namespace.

UEFI mandates that these labels be accessed through new ACPI methods
_LSI, _LSR, and _LSW (Label Storage {Info,Read,Write}), however support
for those is saved for a later patch series once the ACPICA enabling for
ACPI 6.2 lands in an immutable form in the acpi tree.

These updates pass a run through the nvdimm unit tests and an updated
version of the tests targeting the address-abstraction guid. This set is
based on the 'uuid-types' branch of git.infradead.org/users/hch/uuid.git
which includes Christoph's and Andy's revamp of the kernel's uuid + guid
helper routines.

[1]: http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf
[2]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf

---

Dan Williams (9):
  libnvdimm, label: add v1.2 nvdimm label definitions
  libnvdimm, label: add v1.2 interleave-set-cookie algorithm
  libnvdimm, label: honor the lba size specified in v1.2 labels
  libnvdimm, label: populate the type_guid property for v1.2 namespaces
  libnvdimm, label: populate 'isetcookie' for blk-aperture namespaces
  libnvdimm, label: update 'nlabel' and 'position' handling for local 
namespaces
  libnvdimm, label: add v1.2 label checksum support
  libnvdimm, label: add address abstraction identifiers
  libnvdimm, label: switch to using v1.2 labels by default


 drivers/acpi/nfit/core.c|   67 +--
 drivers/nvdimm/btt_devs.c   |8 +
 drivers/nvdimm/claim.c  |   28 
 drivers/nvdimm/core.c   |3 
 drivers/nvdimm/dax_devs.c   |8 +
 drivers/nvdimm/label.c  |  244 +++
 drivers/nvdimm/label.h  |   20 +++
 drivers/nvdimm/namespace_devs.c |  211 +-
 drivers/nvdimm/nd.h |   13 ++
 drivers/nvdimm/pfn_devs.c   |8 +
 drivers/nvdimm/pmem.c   |1 
 drivers/nvdimm/region_devs.c|   43 ++-
 include/linux/libnvdimm.h   |8 +
 include/linux/nd.h  |   12 ++
 14 files changed, 596 insertions(+), 78 deletions(-)


[PATCH 1/9] libnvdimm, label: add v1.2 nvdimm label definitions

2017-06-08 Thread Dan Williams
In support of improved interoperability between operating systems and pre-boot
environments the Intel proposed NVDIMM Namespace Specification [1], has been
adopted and modified to the the UEFI 2.7 NVDIMM Label Protocol [2].

Update the definitions of the namespace label data structures so that the new
format can be supported alongside the existing label format.

The new specification changes the default label size to 256 bytes, so
everywhere that relied on sizeof(struct nd_namespace_label) must now use the
sizeof_namespace_label() helper.

There should be no functional differences from these changes as the
default is still the v1.1 128-byte format. Future patches will move the
default to the v1.2 definition.

[1]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
[2]: http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   95 +++-
 drivers/nvdimm/label.h |   15 +++-
 drivers/nvdimm/nd.h|8 
 3 files changed, 97 insertions(+), 21 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index dd615345699f..d6233d220bfd 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -34,6 +34,11 @@ static u32 best_seq(u32 a, u32 b)
return a;
 }
 
+unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd)
+{
+   return ndd->nslabel_size;
+}
+
 size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 {
u32 index_span;
@@ -49,7 +54,7 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 * starts to waste space at larger config_sizes, but it's
 * unlikely we'll ever see anything but 128K.
 */
-   index_span = ndd->nsarea.config_size / 129;
+   index_span = ndd->nsarea.config_size / (sizeof_namespace_label(ndd) + 
1);
index_span /= NSINDEX_ALIGN * 2;
ndd->nsindex_size = index_span * NSINDEX_ALIGN;
 
@@ -58,10 +63,10 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 
 int nvdimm_num_label_slots(struct nvdimm_drvdata *ndd)
 {
-   return ndd->nsarea.config_size / 129;
+   return ndd->nsarea.config_size / (sizeof_namespace_label(ndd) + 1);
 }
 
-int nd_label_validate(struct nvdimm_drvdata *ndd)
+static int __nd_label_validate(struct nvdimm_drvdata *ndd)
 {
/*
 * On media label format consists of two index blocks followed
@@ -104,6 +109,7 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
u32 nslot;
u8 sig[NSINDEX_SIG_LEN];
u64 sum_save, sum, size;
+   unsigned int version, labelsize;
 
memcpy(sig, nsindex[i]->sig, NSINDEX_SIG_LEN);
if (memcmp(sig, NSINDEX_SIGNATURE, NSINDEX_SIG_LEN) != 0) {
@@ -111,6 +117,21 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
__func__, i);
continue;
}
+
+   /* label sizes larger than 128 arrived with v1.2 */
+   version = __le16_to_cpu(nsindex[i]->major) * 100
+   + __le16_to_cpu(nsindex[i]->minor);
+   if (version >= 102)
+   labelsize = 1 << (7 + nsindex[i]->labelsize);
+   else
+   labelsize = 128;
+
+   if (labelsize != sizeof_namespace_label(ndd)) {
+   dev_dbg(dev, "%s: nsindex%d labelsize %d invalid\n",
+   __func__, i, nsindex[i]->labelsize);
+   continue;
+   }
+
sum_save = __le64_to_cpu(nsindex[i]->checksum);
nsindex[i]->checksum = __cpu_to_le64(0);
sum = nd_fletcher64(nsindex[i], sizeof_namespace_index(ndd), 1);
@@ -153,7 +174,7 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
}
 
nslot = __le32_to_cpu(nsindex[i]->nslot);
-   if (nslot * sizeof(struct nd_namespace_label)
+   if (nslot * sizeof_namespace_label(ndd)
+ 2 * sizeof_namespace_index(ndd)
> ndd->nsarea.config_size) {
dev_dbg(dev, "%s: nsindex%d nslot: %u invalid, 
config_size: %#x\n",
@@ -189,6 +210,28 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
return -1;
 }
 
+int nd_label_validate(struct nvdimm_drvdata *ndd)
+{
+   /*
+* In order to probe for and validate namespace index blocks we
+* need to know the size of the labels, and we can't trust the
+* size of the labels until we validate the index blocks.
+* Resolve this dependency loop by probing for known label
+* sizes.
+*/
+   int label_size[] = { 256, 128 };
+   int i, rc;
+
+   for (i = 0; i < ARRAY_SIZE(label_size); i++) {
+   ndd->nslabel_size = label_size[i];
+   rc = 

[PATCH 6/9] libnvdimm, label: update 'nlabel' and 'position' handling for local namespaces

2017-06-08 Thread Dan Williams
The v1.2 namespace label specification requires 'nlabel' and 'position'
to be valid for the first ("lowest dpa") label in the set. It also
requires all non-first labels to set those fields to 0xff.

Linux does not much care if these values are correct, because we can
just trust the count of labels with the matching uuid like the v1.1
case. However, we set them correctly in case other environments care.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index ba0582fb0e21..d7f9916c6ed5 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -696,6 +696,7 @@ static int __blk_label_update(struct nd_region *nd_region,
struct resource *res, **old_res_list;
struct nd_label_id label_id;
u8 uuid[NSLABEL_UUID_LEN];
+   int min_dpa_idx = 0;
LIST_HEAD(list);
u32 nslot, slot;
 
@@ -767,6 +768,18 @@ static int __blk_label_update(struct nd_region *nd_region,
}
}
 
+   /*
+* Find the resource associated with the first label in the set
+* per the v1.2 namespace specification.
+*/
+   for (i = 0; i < nsblk->num_resources; i++) {
+   struct resource *min = nsblk->res[min_dpa_idx];
+
+   res = nsblk->res[i];
+   if (res->start < min->start)
+   min_dpa_idx = i;
+   }
+
for (i = 0; i < nsblk->num_resources; i++) {
size_t offset;
 
@@ -785,18 +798,26 @@ static int __blk_label_update(struct nd_region *nd_region,
memcpy(nd_label->name, nsblk->alt_name,
NSLABEL_NAME_LEN);
nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_LOCAL);
-   nd_label->nlabel = __cpu_to_le16(0); /* N/A */
-   nd_label->position = __cpu_to_le16(0); /* N/A */
 
/*
 * Use the presence of the type_guid as a flag to
-* determine isetcookie usage for blk-aperture
-* namespaces.
+* determine isetcookie usage and nlabel + position
+* policy for blk-aperture namespaces.
 */
-   if (namespace_label_has(ndd, type_guid))
+   if (namespace_label_has(ndd, type_guid)) {
+   if (i == min_dpa_idx) {
+   nd_label->nlabel = 
__cpu_to_le16(nsblk->num_resources);
+   nd_label->position = __cpu_to_le16(0);
+   } else {
+   nd_label->nlabel = __cpu_to_le16(0x);
+   nd_label->position = __cpu_to_le16(0x);
+   }
nd_label->isetcookie = __cpu_to_le64(nd_set->cookie2);
-   else
+   } else {
+   nd_label->nlabel = __cpu_to_le16(0); /* N/A */
+   nd_label->position = __cpu_to_le16(0); /* N/A */
nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+   }
 
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->rawsize = __cpu_to_le64(resource_size(res));



[PATCH 0/9] libnvdimm, label: namespace specification v1.2 support

2017-06-08 Thread Dan Williams
The recently released UEFI 2.7 Specification [1], includes an updated
version (v1.2) of the NVDIMM Namespace Label Specification that was previously
published on pmem.io [2] (v1.1).

In the process of moving to a UEFI standard definition the v1.2 updates
adds several features for improved cross-OS and pre-OS (EFI driver)
compatibility and safety. The major highlights include:

1/ Support for an "address abstraction guid" so that implementations can
   uniquely identify personalities layered on top of a namespace. A
   standard address abstraction definition example is the BTT (Block
   Translation Table for sector atomicity) layout. A private / local
   abstraction definition example is the Linux device-DAX personality.

2/ Checksums for individual label slots

3/ Additional safety and self-consistency properties like an updated
   interleave-set-cookie algorithm and recording the NFIT address-type-guid
   in the namespace.

UEFI mandates that these labels be accessed through new ACPI methods
_LSI, _LSR, and _LSW (Label Storage {Info,Read,Write}), however support
for those is saved for a later patch series once the ACPICA enabling for
ACPI 6.2 lands in an immutable form in the acpi tree.

These updates pass a run through the nvdimm unit tests and an updated
version of the tests targeting the address-abstraction guid. This set is
based on the 'uuid-types' branch of git.infradead.org/users/hch/uuid.git
which includes Christoph's and Andy's revamp of the kernel's uuid + guid
helper routines.

[1]: http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf
[2]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf

---

Dan Williams (9):
  libnvdimm, label: add v1.2 nvdimm label definitions
  libnvdimm, label: add v1.2 interleave-set-cookie algorithm
  libnvdimm, label: honor the lba size specified in v1.2 labels
  libnvdimm, label: populate the type_guid property for v1.2 namespaces
  libnvdimm, label: populate 'isetcookie' for blk-aperture namespaces
  libnvdimm, label: update 'nlabel' and 'position' handling for local 
namespaces
  libnvdimm, label: add v1.2 label checksum support
  libnvdimm, label: add address abstraction identifiers
  libnvdimm, label: switch to using v1.2 labels by default


 drivers/acpi/nfit/core.c|   67 +--
 drivers/nvdimm/btt_devs.c   |8 +
 drivers/nvdimm/claim.c  |   28 
 drivers/nvdimm/core.c   |3 
 drivers/nvdimm/dax_devs.c   |8 +
 drivers/nvdimm/label.c  |  244 +++
 drivers/nvdimm/label.h  |   20 +++
 drivers/nvdimm/namespace_devs.c |  211 +-
 drivers/nvdimm/nd.h |   13 ++
 drivers/nvdimm/pfn_devs.c   |8 +
 drivers/nvdimm/pmem.c   |1 
 drivers/nvdimm/region_devs.c|   43 ++-
 include/linux/libnvdimm.h   |8 +
 include/linux/nd.h  |   12 ++
 14 files changed, 596 insertions(+), 78 deletions(-)


[PATCH 1/9] libnvdimm, label: add v1.2 nvdimm label definitions

2017-06-08 Thread Dan Williams
In support of improved interoperability between operating systems and pre-boot
environments the Intel proposed NVDIMM Namespace Specification [1], has been
adopted and modified to the the UEFI 2.7 NVDIMM Label Protocol [2].

Update the definitions of the namespace label data structures so that the new
format can be supported alongside the existing label format.

The new specification changes the default label size to 256 bytes, so
everywhere that relied on sizeof(struct nd_namespace_label) must now use the
sizeof_namespace_label() helper.

There should be no functional differences from these changes as the
default is still the v1.1 128-byte format. Future patches will move the
default to the v1.2 definition.

[1]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
[2]: http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   95 +++-
 drivers/nvdimm/label.h |   15 +++-
 drivers/nvdimm/nd.h|8 
 3 files changed, 97 insertions(+), 21 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index dd615345699f..d6233d220bfd 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -34,6 +34,11 @@ static u32 best_seq(u32 a, u32 b)
return a;
 }
 
+unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd)
+{
+   return ndd->nslabel_size;
+}
+
 size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 {
u32 index_span;
@@ -49,7 +54,7 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 * starts to waste space at larger config_sizes, but it's
 * unlikely we'll ever see anything but 128K.
 */
-   index_span = ndd->nsarea.config_size / 129;
+   index_span = ndd->nsarea.config_size / (sizeof_namespace_label(ndd) + 
1);
index_span /= NSINDEX_ALIGN * 2;
ndd->nsindex_size = index_span * NSINDEX_ALIGN;
 
@@ -58,10 +63,10 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 
 int nvdimm_num_label_slots(struct nvdimm_drvdata *ndd)
 {
-   return ndd->nsarea.config_size / 129;
+   return ndd->nsarea.config_size / (sizeof_namespace_label(ndd) + 1);
 }
 
-int nd_label_validate(struct nvdimm_drvdata *ndd)
+static int __nd_label_validate(struct nvdimm_drvdata *ndd)
 {
/*
 * On media label format consists of two index blocks followed
@@ -104,6 +109,7 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
u32 nslot;
u8 sig[NSINDEX_SIG_LEN];
u64 sum_save, sum, size;
+   unsigned int version, labelsize;
 
memcpy(sig, nsindex[i]->sig, NSINDEX_SIG_LEN);
if (memcmp(sig, NSINDEX_SIGNATURE, NSINDEX_SIG_LEN) != 0) {
@@ -111,6 +117,21 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
__func__, i);
continue;
}
+
+   /* label sizes larger than 128 arrived with v1.2 */
+   version = __le16_to_cpu(nsindex[i]->major) * 100
+   + __le16_to_cpu(nsindex[i]->minor);
+   if (version >= 102)
+   labelsize = 1 << (7 + nsindex[i]->labelsize);
+   else
+   labelsize = 128;
+
+   if (labelsize != sizeof_namespace_label(ndd)) {
+   dev_dbg(dev, "%s: nsindex%d labelsize %d invalid\n",
+   __func__, i, nsindex[i]->labelsize);
+   continue;
+   }
+
sum_save = __le64_to_cpu(nsindex[i]->checksum);
nsindex[i]->checksum = __cpu_to_le64(0);
sum = nd_fletcher64(nsindex[i], sizeof_namespace_index(ndd), 1);
@@ -153,7 +174,7 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
}
 
nslot = __le32_to_cpu(nsindex[i]->nslot);
-   if (nslot * sizeof(struct nd_namespace_label)
+   if (nslot * sizeof_namespace_label(ndd)
+ 2 * sizeof_namespace_index(ndd)
> ndd->nsarea.config_size) {
dev_dbg(dev, "%s: nsindex%d nslot: %u invalid, 
config_size: %#x\n",
@@ -189,6 +210,28 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
return -1;
 }
 
+int nd_label_validate(struct nvdimm_drvdata *ndd)
+{
+   /*
+* In order to probe for and validate namespace index blocks we
+* need to know the size of the labels, and we can't trust the
+* size of the labels until we validate the index blocks.
+* Resolve this dependency loop by probing for known label
+* sizes.
+*/
+   int label_size[] = { 256, 128 };
+   int i, rc;
+
+   for (i = 0; i < ARRAY_SIZE(label_size); i++) {
+   ndd->nslabel_size = label_size[i];
+   rc = __nd_label_validate(ndd);
+   if 

[PATCH 6/9] libnvdimm, label: update 'nlabel' and 'position' handling for local namespaces

2017-06-08 Thread Dan Williams
The v1.2 namespace label specification requires 'nlabel' and 'position'
to be valid for the first ("lowest dpa") label in the set. It also
requires all non-first labels to set those fields to 0xff.

Linux does not much care if these values are correct, because we can
just trust the count of labels with the matching uuid like the v1.1
case. However, we set them correctly in case other environments care.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/label.c |   33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index ba0582fb0e21..d7f9916c6ed5 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -696,6 +696,7 @@ static int __blk_label_update(struct nd_region *nd_region,
struct resource *res, **old_res_list;
struct nd_label_id label_id;
u8 uuid[NSLABEL_UUID_LEN];
+   int min_dpa_idx = 0;
LIST_HEAD(list);
u32 nslot, slot;
 
@@ -767,6 +768,18 @@ static int __blk_label_update(struct nd_region *nd_region,
}
}
 
+   /*
+* Find the resource associated with the first label in the set
+* per the v1.2 namespace specification.
+*/
+   for (i = 0; i < nsblk->num_resources; i++) {
+   struct resource *min = nsblk->res[min_dpa_idx];
+
+   res = nsblk->res[i];
+   if (res->start < min->start)
+   min_dpa_idx = i;
+   }
+
for (i = 0; i < nsblk->num_resources; i++) {
size_t offset;
 
@@ -785,18 +798,26 @@ static int __blk_label_update(struct nd_region *nd_region,
memcpy(nd_label->name, nsblk->alt_name,
NSLABEL_NAME_LEN);
nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_LOCAL);
-   nd_label->nlabel = __cpu_to_le16(0); /* N/A */
-   nd_label->position = __cpu_to_le16(0); /* N/A */
 
/*
 * Use the presence of the type_guid as a flag to
-* determine isetcookie usage for blk-aperture
-* namespaces.
+* determine isetcookie usage and nlabel + position
+* policy for blk-aperture namespaces.
 */
-   if (namespace_label_has(ndd, type_guid))
+   if (namespace_label_has(ndd, type_guid)) {
+   if (i == min_dpa_idx) {
+   nd_label->nlabel = 
__cpu_to_le16(nsblk->num_resources);
+   nd_label->position = __cpu_to_le16(0);
+   } else {
+   nd_label->nlabel = __cpu_to_le16(0x);
+   nd_label->position = __cpu_to_le16(0x);
+   }
nd_label->isetcookie = __cpu_to_le64(nd_set->cookie2);
-   else
+   } else {
+   nd_label->nlabel = __cpu_to_le16(0); /* N/A */
+   nd_label->position = __cpu_to_le16(0); /* N/A */
nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+   }
 
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->rawsize = __cpu_to_le64(resource_size(res));



[PATCH 3/9] libnvdimm, label: honor the lba size specified in v1.2 labels

2017-06-08 Thread Dan Williams
Previously we only honored the lba size for blk-aperture mode
namespaces. For pmem namespaces the lba size was just assumed to be 512.
With the new v1.2 label definition and compatibility with other
operating environments, the ->lbasize property is now respected for pmem
namespaces.

Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/namespace_devs.c |   65 ---
 drivers/nvdimm/nd.h |1 +
 drivers/nvdimm/pmem.c   |1 +
 include/linux/nd.h  |2 +
 4 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 51f304fe8a52..e034b003a5e2 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -163,6 +163,29 @@ bool pmem_should_map_pages(struct device *dev)
 }
 EXPORT_SYMBOL(pmem_should_map_pages);
 
+unsigned int pmem_sector_size(struct nd_namespace_common *ndns)
+{
+   if (is_namespace_pmem(>dev)) {
+   struct nd_namespace_pmem *nspm;
+
+   nspm = to_nd_namespace_pmem(>dev);
+   if (nspm->lbasize == 0 || nspm->lbasize == 512)
+   /* default */;
+   else if (nspm->lbasize == 4096)
+   return 4096;
+   else
+   dev_WARN(>dev, "unsupported sector size: %ld\n",
+   nspm->lbasize);
+   }
+
+   /*
+* There is no namespace label (is_namespace_io()), or the label
+* indicates the default sector size.
+*/
+   return 512;
+}
+EXPORT_SYMBOL(pmem_sector_size);
+
 const char *nvdimm_namespace_disk_name(struct nd_namespace_common *ndns,
char *name)
 {
@@ -1283,28 +1306,49 @@ static ssize_t resource_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(resource);
 
-static const unsigned long ns_lbasize_supported[] = { 512, 520, 528,
+static const unsigned long blk_lbasize_supported[] = { 512, 520, 528,
4096, 4104, 4160, 4224, 0 };
 
+static const unsigned long pmem_lbasize_supported[] = { 512, 4096, 0 };
+
 static ssize_t sector_size_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
+   if (is_namespace_blk(dev)) {
+   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
-   if (!is_namespace_blk(dev))
-   return -ENXIO;
+   return nd_sector_size_show(nsblk->lbasize,
+   blk_lbasize_supported, buf);
+   }
 
-   return nd_sector_size_show(nsblk->lbasize, ns_lbasize_supported, buf);
+   if (is_namespace_pmem(dev)) {
+   struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
+
+   return nd_sector_size_show(nspm->lbasize,
+   pmem_lbasize_supported, buf);
+   }
+   return -ENXIO;
 }
 
 static ssize_t sector_size_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
-   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
struct nd_region *nd_region = to_nd_region(dev->parent);
+   const unsigned long *supported;
+   unsigned long *lbasize;
ssize_t rc = 0;
 
-   if (!is_namespace_blk(dev))
+   if (is_namespace_blk(dev)) {
+   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
+
+   lbasize = >lbasize;
+   supported = blk_lbasize_supported;
+   } else if (is_namespace_pmem(dev)) {
+   struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
+
+   lbasize = >lbasize;
+   supported = pmem_lbasize_supported;
+   } else
return -ENXIO;
 
device_lock(dev);
@@ -1312,8 +1356,7 @@ static ssize_t sector_size_store(struct device *dev,
if (to_ndns(dev)->claim)
rc = -EBUSY;
if (rc >= 0)
-   rc = nd_sector_size_store(dev, buf, >lbasize,
-   ns_lbasize_supported);
+   rc = nd_sector_size_store(dev, buf, lbasize, supported);
if (rc >= 0)
rc = nd_namespace_label_update(nd_region, dev);
dev_dbg(dev, "%s: result: %zd %s: %s%s", __func__,
@@ -1458,9 +1501,6 @@ static umode_t namespace_visible(struct kobject *kobj,
if (a == _attr_size.attr)
return 0644;
 
-   if (is_namespace_pmem(dev) && a == _attr_sector_size.attr)
-   return 0;
-
return a->mode;
}
 
@@ -1795,6 +1835,7 @@ struct device *create_namespace_pmem(struct nd_region 
*nd_region,
NSLABEL_NAME_LEN, GFP_KERNEL);
nspm->uuid = kmemdup((void __force *) label0->uuid,
NSLABEL_UUID_LEN, 

[PATCH 5/9] libnvdimm, label: populate 'isetcookie' for blk-aperture namespaces

2017-06-08 Thread Dan Williams
Starting with the v1.2 definition of namespace labels, the isetcookie
field is populated and validated for blk-aperture namespaces. This adds
some safety against inadvertent copying of namespace labels from one
DIMM-device to another.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|7 +--
 drivers/nvdimm/label.c  |   12 +++-
 drivers/nvdimm/namespace_devs.c |   20 ++--
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 83ee3c829411..47d2dbb45695 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1736,12 +1736,12 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
struct nd_region_desc *ndr_desc,
struct acpi_nfit_system_address *spa)
 {
-   int i, spa_type = nfit_spa_type(spa);
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
u16 nr = ndr_desc->num_mappings;
struct nfit_set_info2 *info2;
struct nfit_set_info *info;
+   int i;
 
nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
if (!nd_set)
@@ -1749,11 +1749,6 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
ndr_desc->nd_set = nd_set;
guid_copy(_set->type_guid, (guid_t *) spa->range_guid);
 
-   if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
-   /* pass */;
-   else
-   return 0;
-
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index d8b87d3a0ebe..ba0582fb0e21 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -787,7 +787,17 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_LOCAL);
nd_label->nlabel = __cpu_to_le16(0); /* N/A */
nd_label->position = __cpu_to_le16(0); /* N/A */
-   nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+
+   /*
+* Use the presence of the type_guid as a flag to
+* determine isetcookie usage for blk-aperture
+* namespaces.
+*/
+   if (namespace_label_has(ndd, type_guid))
+   nd_label->isetcookie = __cpu_to_le64(nd_set->cookie2);
+   else
+   nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->lbasize = __cpu_to_le64(nsblk->lbasize);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index e101aec186c7..7aba9a569c8e 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -2065,12 +2065,20 @@ struct device *create_namespace_blk(struct nd_region 
*nd_region,
struct device *dev = NULL;
struct resource *res;
 
-   if (namespace_label_has(ndd, type_guid)
-   && !guid_equal(_set->type_guid,
-   _label->type_guid)) {
-   dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
-   nd_set->type_guid.b, nd_label->type_guid.b);
-   return ERR_PTR(-EAGAIN);
+   if (namespace_label_has(ndd, type_guid)) {
+   if (!guid_equal(_set->type_guid, _label->type_guid)) {
+   dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
+   nd_set->type_guid.b,
+   nd_label->type_guid.b);
+   return ERR_PTR(-EAGAIN);
+   }
+
+   if (nd_label->isetcookie != __cpu_to_le64(nd_set->cookie2)) {
+   dev_dbg(ndd->dev, "expect cookie %#llx got %#llx\n",
+   nd_set->cookie2,
+   __le64_to_cpu(nd_label->isetcookie));
+   return ERR_PTR(-EAGAIN);
+   }
}
 
nsblk = kzalloc(sizeof(*nsblk), GFP_KERNEL);



[PATCH 3/9] libnvdimm, label: honor the lba size specified in v1.2 labels

2017-06-08 Thread Dan Williams
Previously we only honored the lba size for blk-aperture mode
namespaces. For pmem namespaces the lba size was just assumed to be 512.
With the new v1.2 label definition and compatibility with other
operating environments, the ->lbasize property is now respected for pmem
namespaces.

Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/namespace_devs.c |   65 ---
 drivers/nvdimm/nd.h |1 +
 drivers/nvdimm/pmem.c   |1 +
 include/linux/nd.h  |2 +
 4 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 51f304fe8a52..e034b003a5e2 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -163,6 +163,29 @@ bool pmem_should_map_pages(struct device *dev)
 }
 EXPORT_SYMBOL(pmem_should_map_pages);
 
+unsigned int pmem_sector_size(struct nd_namespace_common *ndns)
+{
+   if (is_namespace_pmem(>dev)) {
+   struct nd_namespace_pmem *nspm;
+
+   nspm = to_nd_namespace_pmem(>dev);
+   if (nspm->lbasize == 0 || nspm->lbasize == 512)
+   /* default */;
+   else if (nspm->lbasize == 4096)
+   return 4096;
+   else
+   dev_WARN(>dev, "unsupported sector size: %ld\n",
+   nspm->lbasize);
+   }
+
+   /*
+* There is no namespace label (is_namespace_io()), or the label
+* indicates the default sector size.
+*/
+   return 512;
+}
+EXPORT_SYMBOL(pmem_sector_size);
+
 const char *nvdimm_namespace_disk_name(struct nd_namespace_common *ndns,
char *name)
 {
@@ -1283,28 +1306,49 @@ static ssize_t resource_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(resource);
 
-static const unsigned long ns_lbasize_supported[] = { 512, 520, 528,
+static const unsigned long blk_lbasize_supported[] = { 512, 520, 528,
4096, 4104, 4160, 4224, 0 };
 
+static const unsigned long pmem_lbasize_supported[] = { 512, 4096, 0 };
+
 static ssize_t sector_size_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
+   if (is_namespace_blk(dev)) {
+   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
-   if (!is_namespace_blk(dev))
-   return -ENXIO;
+   return nd_sector_size_show(nsblk->lbasize,
+   blk_lbasize_supported, buf);
+   }
 
-   return nd_sector_size_show(nsblk->lbasize, ns_lbasize_supported, buf);
+   if (is_namespace_pmem(dev)) {
+   struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
+
+   return nd_sector_size_show(nspm->lbasize,
+   pmem_lbasize_supported, buf);
+   }
+   return -ENXIO;
 }
 
 static ssize_t sector_size_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
-   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
struct nd_region *nd_region = to_nd_region(dev->parent);
+   const unsigned long *supported;
+   unsigned long *lbasize;
ssize_t rc = 0;
 
-   if (!is_namespace_blk(dev))
+   if (is_namespace_blk(dev)) {
+   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
+
+   lbasize = >lbasize;
+   supported = blk_lbasize_supported;
+   } else if (is_namespace_pmem(dev)) {
+   struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
+
+   lbasize = >lbasize;
+   supported = pmem_lbasize_supported;
+   } else
return -ENXIO;
 
device_lock(dev);
@@ -1312,8 +1356,7 @@ static ssize_t sector_size_store(struct device *dev,
if (to_ndns(dev)->claim)
rc = -EBUSY;
if (rc >= 0)
-   rc = nd_sector_size_store(dev, buf, >lbasize,
-   ns_lbasize_supported);
+   rc = nd_sector_size_store(dev, buf, lbasize, supported);
if (rc >= 0)
rc = nd_namespace_label_update(nd_region, dev);
dev_dbg(dev, "%s: result: %zd %s: %s%s", __func__,
@@ -1458,9 +1501,6 @@ static umode_t namespace_visible(struct kobject *kobj,
if (a == _attr_size.attr)
return 0644;
 
-   if (is_namespace_pmem(dev) && a == _attr_sector_size.attr)
-   return 0;
-
return a->mode;
}
 
@@ -1795,6 +1835,7 @@ struct device *create_namespace_pmem(struct nd_region 
*nd_region,
NSLABEL_NAME_LEN, GFP_KERNEL);
nspm->uuid = kmemdup((void __force *) label0->uuid,
NSLABEL_UUID_LEN, GFP_KERNEL);
+   nspm->lbasize = 

[PATCH 5/9] libnvdimm, label: populate 'isetcookie' for blk-aperture namespaces

2017-06-08 Thread Dan Williams
Starting with the v1.2 definition of namespace labels, the isetcookie
field is populated and validated for blk-aperture namespaces. This adds
some safety against inadvertent copying of namespace labels from one
DIMM-device to another.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c|7 +--
 drivers/nvdimm/label.c  |   12 +++-
 drivers/nvdimm/namespace_devs.c |   20 ++--
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 83ee3c829411..47d2dbb45695 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1736,12 +1736,12 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
struct nd_region_desc *ndr_desc,
struct acpi_nfit_system_address *spa)
 {
-   int i, spa_type = nfit_spa_type(spa);
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
u16 nr = ndr_desc->num_mappings;
struct nfit_set_info2 *info2;
struct nfit_set_info *info;
+   int i;
 
nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
if (!nd_set)
@@ -1749,11 +1749,6 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
ndr_desc->nd_set = nd_set;
guid_copy(_set->type_guid, (guid_t *) spa->range_guid);
 
-   if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
-   /* pass */;
-   else
-   return 0;
-
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index d8b87d3a0ebe..ba0582fb0e21 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -787,7 +787,17 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_LOCAL);
nd_label->nlabel = __cpu_to_le16(0); /* N/A */
nd_label->position = __cpu_to_le16(0); /* N/A */
-   nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+
+   /*
+* Use the presence of the type_guid as a flag to
+* determine isetcookie usage for blk-aperture
+* namespaces.
+*/
+   if (namespace_label_has(ndd, type_guid))
+   nd_label->isetcookie = __cpu_to_le64(nd_set->cookie2);
+   else
+   nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->lbasize = __cpu_to_le64(nsblk->lbasize);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index e101aec186c7..7aba9a569c8e 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -2065,12 +2065,20 @@ struct device *create_namespace_blk(struct nd_region 
*nd_region,
struct device *dev = NULL;
struct resource *res;
 
-   if (namespace_label_has(ndd, type_guid)
-   && !guid_equal(_set->type_guid,
-   _label->type_guid)) {
-   dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
-   nd_set->type_guid.b, nd_label->type_guid.b);
-   return ERR_PTR(-EAGAIN);
+   if (namespace_label_has(ndd, type_guid)) {
+   if (!guid_equal(_set->type_guid, _label->type_guid)) {
+   dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
+   nd_set->type_guid.b,
+   nd_label->type_guid.b);
+   return ERR_PTR(-EAGAIN);
+   }
+
+   if (nd_label->isetcookie != __cpu_to_le64(nd_set->cookie2)) {
+   dev_dbg(ndd->dev, "expect cookie %#llx got %#llx\n",
+   nd_set->cookie2,
+   __le64_to_cpu(nd_label->isetcookie));
+   return ERR_PTR(-EAGAIN);
+   }
}
 
nsblk = kzalloc(sizeof(*nsblk), GFP_KERNEL);



Re: [PATCH v10 1/6] i2c: designware: Cleaning and comment style fixes.

2017-06-08 Thread Peter Rosin
On 2017-06-08 19:36, Luis Oliveira wrote:
> complicated to review. The work here won't bring any additional work to
> backported fixes because is just style and reordering.

I challenge that. If there is an old bug that existed before this patch
that is fixed in the future after this patch has been applied, it might
very well be hard_er_ to backport that fix to a point before this patch
has been applied. So, what do you mean?

> @@ -984,12 +984,12 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
>   }
>  
>   i2c_dw_disable_int(dev);
> - r = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags,
> + ret = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags,
>dev_name(dev->dev), dev);

Two extra spaces needed to align with the opening bracket.

Cheers,
peda


Re: [PATCH v10 1/6] i2c: designware: Cleaning and comment style fixes.

2017-06-08 Thread Peter Rosin
On 2017-06-08 19:36, Luis Oliveira wrote:
> complicated to review. The work here won't bring any additional work to
> backported fixes because is just style and reordering.

I challenge that. If there is an old bug that existed before this patch
that is fixed in the future after this patch has been applied, it might
very well be hard_er_ to backport that fix to a point before this patch
has been applied. So, what do you mean?

> @@ -984,12 +984,12 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
>   }
>  
>   i2c_dw_disable_int(dev);
> - r = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags,
> + ret = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags,
>dev_name(dev->dev), dev);

Two extra spaces needed to align with the opening bracket.

Cheers,
peda


Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

2017-06-08 Thread Jiada Wang

On 06/01/2017 10:38 PM, Sascha Hauer wrote:

On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote:

Hi Sascha

On 05/29/2017 02:50 AM, Sascha Hauer wrote:

Hi,

On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.


First let me say that I'm not really looking forward to have this patch
in the driver. It adds quite some code to already hairy code pathes in
the imx-spi driver and I saw you have the same patch for DMA mode
aswell.

The driver has different function hooks for the different controllers.
This patch breaks that. In some places it assumes that dynamic burst
is only possible on i.MX51 type controllers and also that in case
dynamic burst is enabled it must be an i.MX51 type controller.

We should really see how this patch can be better integrated into the
driver, or, how the driver can be changed to better support the dynamic
burst usecase.

  Yes, I can understand your concern, as this patch brings in a bunch of
change,
and changes the behaviour of data transfer.
how about introduce a new DTS property like "fsl,spi-dynamic-burst",
and only enables dynamic burst when this property is added.

This will only reduce the testing coverage of the feature, not a good
option.

As an improvement, I am thinking about the following
1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before
2. remove all change in specific functions hooks, for example 
"mx51_ecspi_config"
3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle 
actual swapped data transfer,

and burst length adjustment.


What do you think ?

Sascha





Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

2017-06-08 Thread Jiada Wang

On 06/01/2017 10:38 PM, Sascha Hauer wrote:

On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote:

Hi Sascha

On 05/29/2017 02:50 AM, Sascha Hauer wrote:

Hi,

On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.


First let me say that I'm not really looking forward to have this patch
in the driver. It adds quite some code to already hairy code pathes in
the imx-spi driver and I saw you have the same patch for DMA mode
aswell.

The driver has different function hooks for the different controllers.
This patch breaks that. In some places it assumes that dynamic burst
is only possible on i.MX51 type controllers and also that in case
dynamic burst is enabled it must be an i.MX51 type controller.

We should really see how this patch can be better integrated into the
driver, or, how the driver can be changed to better support the dynamic
burst usecase.

  Yes, I can understand your concern, as this patch brings in a bunch of
change,
and changes the behaviour of data transfer.
how about introduce a new DTS property like "fsl,spi-dynamic-burst",
and only enables dynamic burst when this property is added.

This will only reduce the testing coverage of the feature, not a good
option.

As an improvement, I am thinking about the following
1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before
2. remove all change in specific functions hooks, for example 
"mx51_ecspi_config"
3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle 
actual swapped data transfer,

and burst length adjustment.


What do you think ?

Sascha





Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]

2017-06-08 Thread Joe Perches
On Thu, 2017-06-08 at 18:02 +0300, Andy Shevchenko wrote:
> On Thu, Jun 8, 2017 at 5:52 PM, Joe Perches  wrote:
> > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > > Recently I have noticed too many users of struct rtc_time that printing
> > > its content field by field.
> > > 
> > > In this series I introduce %pt[dt][rv] specifier to make life a bit
> > > easier.
[]
> > > Most of the users currently are RTC drivers, thus the patch series is
> > > assumed to go via RTC tree.
> > 
> > What I wonder about this series is how much
> > larger it makes a typical kernel and how
> > often multiple rtc clocks are built for a
> > single kernel?
> 
> We may hide it under CONFIG_RTC_??? if we want to reduce kernel for
> non RTC cases.

Depends whether it is for rtc_time only

> > What is the size impact on an embedded kernel
> > that uses a single rtc driver?
> 
> I would

You would what?



Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]

2017-06-08 Thread Joe Perches
On Thu, 2017-06-08 at 18:02 +0300, Andy Shevchenko wrote:
> On Thu, Jun 8, 2017 at 5:52 PM, Joe Perches  wrote:
> > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > > Recently I have noticed too many users of struct rtc_time that printing
> > > its content field by field.
> > > 
> > > In this series I introduce %pt[dt][rv] specifier to make life a bit
> > > easier.
[]
> > > Most of the users currently are RTC drivers, thus the patch series is
> > > assumed to go via RTC tree.
> > 
> > What I wonder about this series is how much
> > larger it makes a typical kernel and how
> > often multiple rtc clocks are built for a
> > single kernel?
> 
> We may hide it under CONFIG_RTC_??? if we want to reduce kernel for
> non RTC cases.

Depends whether it is for rtc_time only

> > What is the size impact on an embedded kernel
> > that uses a single rtc driver?
> 
> I would

You would what?



[PATCH] staging: ks7010: use little-endian types

2017-06-08 Thread Perry Hooker
This patch fixes a number of sparse warnings of the form:
drivers/staging/ks7010/ks_hostif.c:2187:29:
warning: incorrect type in assignment (different base types)
generated when storing little-endian data in variables
that do not have a specified endianness.

Signed-off-by: Perry Hooker 
---
 drivers/staging/ks7010/ks_hostif.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 697347b..db01a48 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1821,7 +1821,7 @@ void hostif_receive(struct ks_wlan_private *priv, 
unsigned char *p,
 static
 void hostif_sme_set_wep(struct ks_wlan_private *priv, int type)
 {
-   u32 val;
+   __le32 val;
 
switch (type) {
case SME_WEP_INDEX_REQUEST:
@@ -1870,13 +1870,13 @@ void hostif_sme_set_wep(struct ks_wlan_private *priv, 
int type)
 }
 
 struct wpa_suite_t {
-   unsigned short size;
+   __le16 size;
unsigned char suite[4][CIPHER_ID_LEN];
 } __packed;
 
 struct rsn_mode_t {
-   u32 rsn_mode;
-   u16 rsn_capability;
+   __le32 rsn_mode;
+   __le16 rsn_capability;
 } __packed;
 
 static
@@ -1884,7 +1884,7 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 {
struct wpa_suite_t wpa_suite;
struct rsn_mode_t rsn_mode;
-   u32 val;
+   __le32 val;
 
memset(_suite, 0, sizeof(wpa_suite));
 
@@ -1936,7 +1936,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_UNICAST_CIPHER,
   sizeof(wpa_suite.size) +
-  CIPHER_ID_LEN * wpa_suite.size,
+  CIPHER_ID_LEN *
+  le16_to_cpu(wpa_suite.size),
   MIB_VALUE_TYPE_OSTRING, _suite);
break;
case SME_RSN_MCAST_REQUEST:
@@ -2028,7 +2029,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_AUTH_SUITE,
   sizeof(wpa_suite.size) +
-  KEY_MGMT_ID_LEN * wpa_suite.size,
+  KEY_MGMT_ID_LEN *
+  le16_to_cpu(wpa_suite.size),
   MIB_VALUE_TYPE_OSTRING, _suite);
break;
case SME_RSN_ENABLED_REQUEST:
@@ -2165,7 +2167,7 @@ void hostif_sme_multicast_set(struct ks_wlan_private 
*priv)
int mc_count;
struct netdev_hw_addr *ha;
char set_address[NIC_MAX_MCAST_LIST * ETH_ALEN];
-   unsigned long filter_type;
+   __le32 filter_type;
int i = 0;
 
DPRINTK(3, "\n");
@@ -2276,7 +2278,7 @@ void hostif_sme_sleep_set(struct ks_wlan_private *priv)
 static
 void hostif_sme_set_key(struct ks_wlan_private *priv, int type)
 {
-   u32 val;
+   __le32 val;
 
switch (type) {
case SME_SET_FLAG:
@@ -2335,7 +2337,7 @@ static
 void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
 {
struct pmk_cache_t {
-   u16 size;
+   __le16 size;
struct {
u8 bssid[ETH_ALEN];
u8 pmkid[IW_PMKID_LEN];
@@ -2366,7 +2368,7 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
 static
 void hostif_sme_execute(struct ks_wlan_private *priv, int event)
 {
-   u32 val;
+   __le32 val;
 
DPRINTK(3, "event=%d\n", event);
switch (event) {
-- 
2.4.11



[PATCH] staging: ks7010: use little-endian types

2017-06-08 Thread Perry Hooker
This patch fixes a number of sparse warnings of the form:
drivers/staging/ks7010/ks_hostif.c:2187:29:
warning: incorrect type in assignment (different base types)
generated when storing little-endian data in variables
that do not have a specified endianness.

Signed-off-by: Perry Hooker 
---
 drivers/staging/ks7010/ks_hostif.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 697347b..db01a48 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1821,7 +1821,7 @@ void hostif_receive(struct ks_wlan_private *priv, 
unsigned char *p,
 static
 void hostif_sme_set_wep(struct ks_wlan_private *priv, int type)
 {
-   u32 val;
+   __le32 val;
 
switch (type) {
case SME_WEP_INDEX_REQUEST:
@@ -1870,13 +1870,13 @@ void hostif_sme_set_wep(struct ks_wlan_private *priv, 
int type)
 }
 
 struct wpa_suite_t {
-   unsigned short size;
+   __le16 size;
unsigned char suite[4][CIPHER_ID_LEN];
 } __packed;
 
 struct rsn_mode_t {
-   u32 rsn_mode;
-   u16 rsn_capability;
+   __le32 rsn_mode;
+   __le16 rsn_capability;
 } __packed;
 
 static
@@ -1884,7 +1884,7 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 {
struct wpa_suite_t wpa_suite;
struct rsn_mode_t rsn_mode;
-   u32 val;
+   __le32 val;
 
memset(_suite, 0, sizeof(wpa_suite));
 
@@ -1936,7 +1936,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_UNICAST_CIPHER,
   sizeof(wpa_suite.size) +
-  CIPHER_ID_LEN * wpa_suite.size,
+  CIPHER_ID_LEN *
+  le16_to_cpu(wpa_suite.size),
   MIB_VALUE_TYPE_OSTRING, _suite);
break;
case SME_RSN_MCAST_REQUEST:
@@ -2028,7 +2029,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int 
type)
 
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_AUTH_SUITE,
   sizeof(wpa_suite.size) +
-  KEY_MGMT_ID_LEN * wpa_suite.size,
+  KEY_MGMT_ID_LEN *
+  le16_to_cpu(wpa_suite.size),
   MIB_VALUE_TYPE_OSTRING, _suite);
break;
case SME_RSN_ENABLED_REQUEST:
@@ -2165,7 +2167,7 @@ void hostif_sme_multicast_set(struct ks_wlan_private 
*priv)
int mc_count;
struct netdev_hw_addr *ha;
char set_address[NIC_MAX_MCAST_LIST * ETH_ALEN];
-   unsigned long filter_type;
+   __le32 filter_type;
int i = 0;
 
DPRINTK(3, "\n");
@@ -2276,7 +2278,7 @@ void hostif_sme_sleep_set(struct ks_wlan_private *priv)
 static
 void hostif_sme_set_key(struct ks_wlan_private *priv, int type)
 {
-   u32 val;
+   __le32 val;
 
switch (type) {
case SME_SET_FLAG:
@@ -2335,7 +2337,7 @@ static
 void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
 {
struct pmk_cache_t {
-   u16 size;
+   __le16 size;
struct {
u8 bssid[ETH_ALEN];
u8 pmkid[IW_PMKID_LEN];
@@ -2366,7 +2368,7 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
 static
 void hostif_sme_execute(struct ks_wlan_private *priv, int event)
 {
-   u32 val;
+   __le32 val;
 
DPRINTK(3, "event=%d\n", event);
switch (event) {
-- 
2.4.11



[PATCH 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-06-08 Thread Hoegeun Kwon
Hi all,

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

The first and second patches are Add the binding document and panel
driver. The third patch is remove the unnecessary properties in the
rinato dts.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 491 +
 5 files changed, 523 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1



[PATCH 0/3] Add support for the s6e63j0x03 panel on Rinato board

2017-06-08 Thread Hoegeun Kwon
Hi all,

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

The first and second patches are Add the binding document and panel
driver. The third patch is remove the unnecessary properties in the
rinato dts.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 491 +
 5 files changed, 523 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1



[PATCH 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-06-08 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 82e676a..3d19b7c 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1



[PATCH 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

2017-06-08 Thread Hoegeun Kwon
The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 82e676a..3d19b7c 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1



[PATCH 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-06-08 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..34b6e2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1



[PATCH 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-06-08 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 491 +++
 3 files changed, 499 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..e47e56d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..bf70a20
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,491 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, 
+ * Hoegeun Kwon, 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+   0x28, 0x27, 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0x31, 0x31,
+   0x30, 0x00, 0xf9, 0x01, 0x05, 0x01, 0x1b
+   },
+   {   /* gamma 150 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x31, 0x51, 0x53, 0x66, 0x66, 0x67, 0x28,
+   0x29, 0x27, 0x28, 0x27, 0x27, 0x2e, 

[PATCH 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

2017-06-08 Thread Hoegeun Kwon
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..34b6e2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active high)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1



[PATCH 2/3] drm/panel: Add support for s6e63j0x03 panel driver

2017-06-08 Thread Hoegeun Kwon
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 491 +++
 3 files changed, 499 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..e47e56d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..bf70a20
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,491 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, 
+ * Hoegeun Kwon, 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+   0x28, 0x27, 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0x31, 0x31,
+   0x30, 0x00, 0xf9, 0x01, 0x05, 0x01, 0x1b
+   },
+   {   /* gamma 150 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x31, 0x51, 0x53, 0x66, 0x66, 0x67, 0x28,
+   0x29, 0x27, 0x28, 0x27, 0x27, 0x2e, 0x2d, 0x2e, 0x31, 0x31,
+   0x30, 0x01, 0x04, 0x01, 0x11, 0x01, 0x29
+   },
+   {   /* gamma 200 */

[PATCH] netfilter: ctnetlink: move CTA_TIMEOUT case to outside

2017-06-08 Thread Haishuang Yan
When cda[CTA_TIMEOUT] is zero, ctnetlink_new_conntrack will
free allocated ct and return, so move it to outside to optimize
this situation.

Signed-off-by: Haishuang Yan 
---
 net/netfilter/nf_conntrack_netlink.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_netlink.c 
b/net/netfilter/nf_conntrack_netlink.c
index a8be9b7..d1e6b1c 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1768,9 +1768,6 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
if (IS_ERR(ct))
return ERR_PTR(-ENOMEM);
 
-   if (!cda[CTA_TIMEOUT])
-   goto err1;
-
ct->timeout = nfct_time_stamp + ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * 
HZ;
 
rcu_read_lock();
@@ -1944,7 +1941,7 @@ static int ctnetlink_new_conntrack(struct net *net, 
struct sock *ctnl,
if (nlh->nlmsg_flags & NLM_F_CREATE) {
enum ip_conntrack_events events;
 
-   if (!cda[CTA_TUPLE_ORIG] || !cda[CTA_TUPLE_REPLY])
+   if (!cda[CTA_TUPLE_ORIG] || !cda[CTA_TUPLE_REPLY] || 
!cda[CTA_TIMEOUT])
return -EINVAL;
if (otuple.dst.protonum != rtuple.dst.protonum)
return -EINVAL;
-- 
1.8.3.1





[PATCH] netfilter: ctnetlink: move CTA_TIMEOUT case to outside

2017-06-08 Thread Haishuang Yan
When cda[CTA_TIMEOUT] is zero, ctnetlink_new_conntrack will
free allocated ct and return, so move it to outside to optimize
this situation.

Signed-off-by: Haishuang Yan 
---
 net/netfilter/nf_conntrack_netlink.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_netlink.c 
b/net/netfilter/nf_conntrack_netlink.c
index a8be9b7..d1e6b1c 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1768,9 +1768,6 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
if (IS_ERR(ct))
return ERR_PTR(-ENOMEM);
 
-   if (!cda[CTA_TIMEOUT])
-   goto err1;
-
ct->timeout = nfct_time_stamp + ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * 
HZ;
 
rcu_read_lock();
@@ -1944,7 +1941,7 @@ static int ctnetlink_new_conntrack(struct net *net, 
struct sock *ctnl,
if (nlh->nlmsg_flags & NLM_F_CREATE) {
enum ip_conntrack_events events;
 
-   if (!cda[CTA_TUPLE_ORIG] || !cda[CTA_TUPLE_REPLY])
+   if (!cda[CTA_TUPLE_ORIG] || !cda[CTA_TUPLE_REPLY] || 
!cda[CTA_TIMEOUT])
return -EINVAL;
if (otuple.dst.protonum != rtuple.dst.protonum)
return -EINVAL;
-- 
1.8.3.1





Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

2017-06-08 Thread Binoy Jayan
On 8 June 2017 at 20:40, Arnd Bergmann  wrote:
> On Thu, Jun 8, 2017 at 12:04 PM, Binoy Jayan  wrote:
>> The semaphore 'cmd_mutex' is used as a simple mutex, so
>> it should be written as one. Semaphores are going away in the future.
>>
>> Signed-off-by: Binoy Jayan 
>> ---
>
>> @@ -1283,7 +1283,7 @@ static int ngene_load_firm(struct ngene *dev)
>>
>>  static void ngene_stop(struct ngene *dev)
>>  {
>> -   down(>cmd_mutex);
>> +   mutex_lock(>cmd_mutex);
>> i2c_del_adapter(&(dev->channel[0].i2c_adapter));
>> i2c_del_adapter(&(dev->channel[1].i2c_adapter));
>> ngwritel(0, NGENE_INT_ENABLE);
>
> Are you sure about this one? There is only one mutex_lock() and
> then the structure gets freed without a corresponding mutex_unlock().
>
> I suspect this violates some rules of mutexes, either when compile
> testing with "make C=1", or when running with lockdep enabled.
>
> Can we actually have a concurrently held mutex at the time we
> get here? If not, using mutex_destroy() in place of the down()
> may be the right answer.

I noticed the missing 'up' here, but may be semaphores do not have
to adhere to that rule? Thank you for pointing out that. I'll check the
concurrency part. By the way why do we need mutex_destoy?
To debug an aberrate condition?

Thanks,
Binoy


Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

2017-06-08 Thread Binoy Jayan
On 8 June 2017 at 20:40, Arnd Bergmann  wrote:
> On Thu, Jun 8, 2017 at 12:04 PM, Binoy Jayan  wrote:
>> The semaphore 'cmd_mutex' is used as a simple mutex, so
>> it should be written as one. Semaphores are going away in the future.
>>
>> Signed-off-by: Binoy Jayan 
>> ---
>
>> @@ -1283,7 +1283,7 @@ static int ngene_load_firm(struct ngene *dev)
>>
>>  static void ngene_stop(struct ngene *dev)
>>  {
>> -   down(>cmd_mutex);
>> +   mutex_lock(>cmd_mutex);
>> i2c_del_adapter(&(dev->channel[0].i2c_adapter));
>> i2c_del_adapter(&(dev->channel[1].i2c_adapter));
>> ngwritel(0, NGENE_INT_ENABLE);
>
> Are you sure about this one? There is only one mutex_lock() and
> then the structure gets freed without a corresponding mutex_unlock().
>
> I suspect this violates some rules of mutexes, either when compile
> testing with "make C=1", or when running with lockdep enabled.
>
> Can we actually have a concurrently held mutex at the time we
> get here? If not, using mutex_destroy() in place of the down()
> may be the right answer.

I noticed the missing 'up' here, but may be semaphores do not have
to adhere to that rule? Thank you for pointing out that. I'll check the
concurrency part. By the way why do we need mutex_destoy?
To debug an aberrate condition?

Thanks,
Binoy


Re: [PATCH v2 2/2] ARM: sun8i: a83t: add dwmac-sun8i ethernet driver

2017-06-08 Thread Chen-Yu Tsai
On Thu, Jun 8, 2017 at 8:48 PM, Maxime Ripard
 wrote:
> On Thu, Jun 08, 2017 at 10:42:22AM +0200, Corentin Labbe wrote:
>> On Thu, Jun 08, 2017 at 10:34:28AM +0200, Maxime Ripard wrote:
>> > On Wed, Jun 07, 2017 at 07:33:45PM +0200, Corentin Labbe wrote:
>> > > The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000 
>> > > speed.
>> > > This patch enable the dwmac-sun8i on the Allwinner a83t SoC Device-tree.
>> > >
>> > > Signed-off-by: Corentin Labbe 
>> > > Reviewed-by: Chen-Yu Tsai 
>> > > ---
>> > >  arch/arm/boot/dts/sun8i-a83t.dtsi | 28 
>> > >  1 file changed, 28 insertions(+)
>> > >
>> > > diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
>> > > b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > index 01a83406f9ae..7d719b4aeaa9 100644
>> > > --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > @@ -200,6 +200,14 @@
>> > >   #interrupt-cells = <3>;
>> > >   #gpio-cells = <3>;
>> > >
>> > > + emac_rgmii_pins: emac-rgmii-pins {
>> > > + pins = "PD2", "PD3", "PD4", "PD5", "PD6", 
>> > > "PD7",
>> > > +"PD11", "PD12", "PD13", "PD14", "PD18",
>> > > +"PD19", "PD21", "PD22", "PD23";
>> > > + function = "gmac";
>> > > + drive-strength = <40>;
>> > > + };
>> > > +
>> >
>> > This is not used anywhere.
>> >
>> But will be used by bpim3 board
>
> Then will add it when we'll add support for that board, until then,
> it's dead code.

I'll include this in my A83T work branch and resend it when I get around to it.

Thanks
ChenYu


Re: [PATCH v2 2/2] ARM: sun8i: a83t: add dwmac-sun8i ethernet driver

2017-06-08 Thread Chen-Yu Tsai
On Thu, Jun 8, 2017 at 8:48 PM, Maxime Ripard
 wrote:
> On Thu, Jun 08, 2017 at 10:42:22AM +0200, Corentin Labbe wrote:
>> On Thu, Jun 08, 2017 at 10:34:28AM +0200, Maxime Ripard wrote:
>> > On Wed, Jun 07, 2017 at 07:33:45PM +0200, Corentin Labbe wrote:
>> > > The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000 
>> > > speed.
>> > > This patch enable the dwmac-sun8i on the Allwinner a83t SoC Device-tree.
>> > >
>> > > Signed-off-by: Corentin Labbe 
>> > > Reviewed-by: Chen-Yu Tsai 
>> > > ---
>> > >  arch/arm/boot/dts/sun8i-a83t.dtsi | 28 
>> > >  1 file changed, 28 insertions(+)
>> > >
>> > > diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
>> > > b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > index 01a83406f9ae..7d719b4aeaa9 100644
>> > > --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > @@ -200,6 +200,14 @@
>> > >   #interrupt-cells = <3>;
>> > >   #gpio-cells = <3>;
>> > >
>> > > + emac_rgmii_pins: emac-rgmii-pins {
>> > > + pins = "PD2", "PD3", "PD4", "PD5", "PD6", 
>> > > "PD7",
>> > > +"PD11", "PD12", "PD13", "PD14", "PD18",
>> > > +"PD19", "PD21", "PD22", "PD23";
>> > > + function = "gmac";
>> > > + drive-strength = <40>;
>> > > + };
>> > > +
>> >
>> > This is not used anywhere.
>> >
>> But will be used by bpim3 board
>
> Then will add it when we'll add support for that board, until then,
> it's dead code.

I'll include this in my A83T work branch and resend it when I get around to it.

Thanks
ChenYu


[PATCH v2] acpi: handle the acpi hotplug schedule error

2017-06-08 Thread Lee, Chun-Yi
Kernel should decrements the reference count of acpi device
when the scheduling of acpi hotplug work is failed, and
evaluates _OST to notify BIOS the failure.

v2:
To simplify the code. (Andy Shevchenko)

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Andy Shevchenko 
Signed-off-by: "Lee, Chun-Yi" 
---
 drivers/acpi/bus.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..91adb71 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -427,12 +427,17 @@ static void acpi_bus_notify(acpi_handle handle, u32 type, 
void *data)
(driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
driver->ops.notify(adev, type);
 
-   if (hotplug_event && ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
-   return;
+   if (hotplug_event) {
+   if (ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
+   return;
+   goto err_put_device;
+   }
 
acpi_bus_put_acpi_device(adev);
return;
 
+ err_put_device:
+   acpi_bus_put_acpi_device(adev);
  err:
acpi_evaluate_ost(handle, type, ost_code, NULL);
 }
-- 
2.10.2



[PATCH v2] acpi: handle the acpi hotplug schedule error

2017-06-08 Thread Lee, Chun-Yi
Kernel should decrements the reference count of acpi device
when the scheduling of acpi hotplug work is failed, and
evaluates _OST to notify BIOS the failure.

v2:
To simplify the code. (Andy Shevchenko)

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Andy Shevchenko 
Signed-off-by: "Lee, Chun-Yi" 
---
 drivers/acpi/bus.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..91adb71 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -427,12 +427,17 @@ static void acpi_bus_notify(acpi_handle handle, u32 type, 
void *data)
(driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
driver->ops.notify(adev, type);
 
-   if (hotplug_event && ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
-   return;
+   if (hotplug_event) {
+   if (ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
+   return;
+   goto err_put_device;
+   }
 
acpi_bus_put_acpi_device(adev);
return;
 
+ err_put_device:
+   acpi_bus_put_acpi_device(adev);
  err:
acpi_evaluate_ost(handle, type, ost_code, NULL);
 }
-- 
2.10.2



Re: [PATCH 0/2] perf stat: fix segfault when closing events

2017-06-08 Thread Ganapatrao Kulkarni
ping?

On Tue, May 23, 2017 at 8:44 PM, Ganapatrao Kulkarni
 wrote:
> On Tue, May 23, 2017 at 3:34 PM, Mark Rutland  wrote:
>> Hi,
>>
>> Does anyone have any comments on these?
>>
>> I'm happy to rebase/resend if necessary.
>>
>> I'd very much like to see this fixed.
>
> arm64 platforms have dependency on this patch set to use latest perf tool.
> Earliest merge/review is much appreciated!!
>
>>
>> Thanks,
>> Mark.
>>
>> On Fri, Apr 28, 2017 at 12:47:08PM +0100, Mark Rutland wrote:
>>> Hi,
>>>
>>> These patches fix a segfault seen in some cases when perf stat is exiting.
>>>
>>> We don't balance opening/closing of events in all cases, and go 
>>> out-of-bounds
>>> when we close events. Full details in the patch 2 commit message.
>>>
>>> Thanks,
>>> Mark.
>>>
>>> Mark Rutland (2):
>>>   perf evsel: add per{cpu,thread} close helpers
>>>   perf stat: balance opening/closing of events
>>>
>>>  tools/perf/builtin-stat.c | 24 +++-
>>>  tools/perf/util/evsel.c   | 26 --
>>>  tools/perf/util/evsel.h   |  4 
>>>  3 files changed, 47 insertions(+), 7 deletions(-)
>>>
>>> --
>>> 1.9.1
>>>
>
> thanks
> Ganapat


Re: [PATCH 0/2] perf stat: fix segfault when closing events

2017-06-08 Thread Ganapatrao Kulkarni
ping?

On Tue, May 23, 2017 at 8:44 PM, Ganapatrao Kulkarni
 wrote:
> On Tue, May 23, 2017 at 3:34 PM, Mark Rutland  wrote:
>> Hi,
>>
>> Does anyone have any comments on these?
>>
>> I'm happy to rebase/resend if necessary.
>>
>> I'd very much like to see this fixed.
>
> arm64 platforms have dependency on this patch set to use latest perf tool.
> Earliest merge/review is much appreciated!!
>
>>
>> Thanks,
>> Mark.
>>
>> On Fri, Apr 28, 2017 at 12:47:08PM +0100, Mark Rutland wrote:
>>> Hi,
>>>
>>> These patches fix a segfault seen in some cases when perf stat is exiting.
>>>
>>> We don't balance opening/closing of events in all cases, and go 
>>> out-of-bounds
>>> when we close events. Full details in the patch 2 commit message.
>>>
>>> Thanks,
>>> Mark.
>>>
>>> Mark Rutland (2):
>>>   perf evsel: add per{cpu,thread} close helpers
>>>   perf stat: balance opening/closing of events
>>>
>>>  tools/perf/builtin-stat.c | 24 +++-
>>>  tools/perf/util/evsel.c   | 26 --
>>>  tools/perf/util/evsel.h   |  4 
>>>  3 files changed, 47 insertions(+), 7 deletions(-)
>>>
>>> --
>>> 1.9.1
>>>
>
> thanks
> Ganapat


linux-next: manual merge of the kvms390 tree with the kvm-arm tree

2017-06-08 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the kvms390 tree got a conflict in:

  arch/s390/include/asm/kvm_host.h

between commit:

  2387149eade2 ("KVM: improve arch vcpu request defining")

from the kvm-arm tree and commit:

  8611a6a64661 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode")

from the kvms390 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/include/asm/kvm_host.h
index 9c3bd94204ac,a8cafed79eb4..
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@@ -42,9 -42,11 +42,11 @@@
  #define KVM_HALT_POLL_NS_DEFAULT 8
  
  /* s390-specific vcpu->requests bit members */
 -#define KVM_REQ_ENABLE_IBS 8
 -#define KVM_REQ_DISABLE_IBS9
 -#define KVM_REQ_ICPT_OPEREXC   10
 -#define KVM_REQ_START_MIGRATION   11
 -#define KVM_REQ_STOP_MIGRATION12
 +#define KVM_REQ_ENABLE_IBSKVM_ARCH_REQ(0)
 +#define KVM_REQ_DISABLE_IBS   KVM_ARCH_REQ(1)
 +#define KVM_REQ_ICPT_OPEREXC  KVM_ARCH_REQ(2)
++#define KVM_REQ_START_MIGRATION   KVM_ARCH_REQ(3)
++#define KVM_REQ_STOP_MIGRATIONKVM_ARCH_REQ(4)
  
  #define SIGP_CTRL_C   0x80
  #define SIGP_CTRL_SCN_MASK0x3f


linux-next: manual merge of the kvms390 tree with the kvm-arm tree

2017-06-08 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the kvms390 tree got a conflict in:

  arch/s390/include/asm/kvm_host.h

between commit:

  2387149eade2 ("KVM: improve arch vcpu request defining")

from the kvm-arm tree and commit:

  8611a6a64661 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode")

from the kvms390 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/include/asm/kvm_host.h
index 9c3bd94204ac,a8cafed79eb4..
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@@ -42,9 -42,11 +42,11 @@@
  #define KVM_HALT_POLL_NS_DEFAULT 8
  
  /* s390-specific vcpu->requests bit members */
 -#define KVM_REQ_ENABLE_IBS 8
 -#define KVM_REQ_DISABLE_IBS9
 -#define KVM_REQ_ICPT_OPEREXC   10
 -#define KVM_REQ_START_MIGRATION   11
 -#define KVM_REQ_STOP_MIGRATION12
 +#define KVM_REQ_ENABLE_IBSKVM_ARCH_REQ(0)
 +#define KVM_REQ_DISABLE_IBS   KVM_ARCH_REQ(1)
 +#define KVM_REQ_ICPT_OPEREXC  KVM_ARCH_REQ(2)
++#define KVM_REQ_START_MIGRATION   KVM_ARCH_REQ(3)
++#define KVM_REQ_STOP_MIGRATIONKVM_ARCH_REQ(4)
  
  #define SIGP_CTRL_C   0x80
  #define SIGP_CTRL_SCN_MASK0x3f


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

2017-06-08 Thread Damien Le Moal
Stephen,

On 6/9/17 12:12, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the device-mapper tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/md/dm-zoned-target.c:947:2: error: unknown field 'suspend' specified 
> in initializer
>   .suspend  = dmz_suspend,
>   ^
> drivers/md/dm-zoned-target.c:947:14: error: initialization from incompatible 
> pointer type [-Werror=incompatible-pointer-types]
>   .suspend  = dmz_suspend,
>   ^
> 
> Caused by commit
> 
>   02da2e15e81f ("dm zoned: drive-managed zoned block device target")
> 
> I have used the device-mapper tree from next-20170608 for today.

My apologies for that. My mistake.
I just posted a patch to dm-devel to fix this.
Everything should come in order after Mike's review.

Best regards.

-- 
Damien Le Moal, Ph.D.
Sr Manager, System Software Group,
Western Digital Research
damien.lem...@wdc.com
Tel: (+81) 0466-98-3593 (Ext. 51-3593)
1 kirihara-cho, Fujisawa, Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com


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

2017-06-08 Thread Damien Le Moal
Stephen,

On 6/9/17 12:12, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the device-mapper tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/md/dm-zoned-target.c:947:2: error: unknown field 'suspend' specified 
> in initializer
>   .suspend  = dmz_suspend,
>   ^
> drivers/md/dm-zoned-target.c:947:14: error: initialization from incompatible 
> pointer type [-Werror=incompatible-pointer-types]
>   .suspend  = dmz_suspend,
>   ^
> 
> Caused by commit
> 
>   02da2e15e81f ("dm zoned: drive-managed zoned block device target")
> 
> I have used the device-mapper tree from next-20170608 for today.

My apologies for that. My mistake.
I just posted a patch to dm-devel to fix this.
Everything should come in order after Mike's review.

Best regards.

-- 
Damien Le Moal, Ph.D.
Sr Manager, System Software Group,
Western Digital Research
damien.lem...@wdc.com
Tel: (+81) 0466-98-3593 (Ext. 51-3593)
1 kirihara-cho, Fujisawa, Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com


Re: [PATCH v2] refcount: Create unchecked atomic_t implementation

2017-06-08 Thread Manfred Spraul

Hi Davidlohr,

On 06/08/2017 10:09 PM, Davidlohr Bueso wrote:


Yes, this would be a prerequisite for ipc; which I initially thought 
didn't

take a performance hit.


Did you see a regression for ipc?

The fast paths don't use the refcount, it is only used for rare situations:
- GETALL, SETALL for large arrays
- alloc undo

--
Manfred


Re: [PATCH v2] refcount: Create unchecked atomic_t implementation

2017-06-08 Thread Manfred Spraul

Hi Davidlohr,

On 06/08/2017 10:09 PM, Davidlohr Bueso wrote:


Yes, this would be a prerequisite for ipc; which I initially thought 
didn't

take a performance hit.


Did you see a regression for ipc?

The fast paths don't use the refcount, it is only used for rare situations:
- GETALL, SETALL for large arrays
- alloc undo

--
Manfred


Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

2017-06-08 Thread Hari Bathini



On Friday 09 June 2017 07:47 AM, Xunlei Pang wrote:

S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
is now defined as follows:
 typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
It was changed by the CONFIG_CRASH_CORE feature.

This patch gets rid of all the old KEXEC_NOTE_BYTES stuff, and
renames KEXEC_NOTE_BYTES to CRASH_CORE_NOTE_BYTES for S390.

Fixes: 692f66f26a4c ("crash: move crashkernel parsing and vmcore related code under 
CONFIG_CRASH_CORE")
Cc: Dave Young 
Cc: Dave Anderson 
Cc: Hari Bathini 
Cc: Gustavo Luiz Duarte 
Signed-off-by: Xunlei Pang 
---
  arch/s390/include/asm/kexec.h |  2 +-
  include/linux/crash_core.h|  7 +++
  include/linux/kexec.h | 11 +--
  3 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
index 2f924bc..352deb8 100644
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -47,7 +47,7 @@
   * Seven notes plus zero note at the end: prstatus, fpregset, timer,
   * tod_cmp, tod_reg, control regs, and prefix
   */
-#define KEXEC_NOTE_BYTES \
+#define CRASH_CORE_NOTE_BYTES \
(ALIGN(sizeof(struct elf_note), 4) * 8 + \
 ALIGN(sizeof("CORE"), 4) * 7 + \
 ALIGN(sizeof(struct elf_prstatus), 4) + \
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index e9de6b4..dbc6e5c 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -10,9 +10,16 @@
  #define CRASH_CORE_NOTE_NAME_BYTES ALIGN(sizeof(CRASH_CORE_NOTE_NAME), 4)
  #define CRASH_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)

+/*
+ * The per-cpu notes area is a list of notes terminated by a "NULL"
+ * note header.  For kdump, the code in vmcore.c runs in the context
+ * of the second kernel to combine them into one note.
+ */
+#ifndef CRASH_CORE_NOTE_BYTES
  #define CRASH_CORE_NOTE_BYTES((CRASH_CORE_NOTE_HEAD_BYTES * 2) +  \
 CRASH_CORE_NOTE_NAME_BYTES +   \
 CRASH_CORE_NOTE_DESC_BYTES)
+#endif

  #define VMCOREINFO_BYTES PAGE_SIZE
  #define VMCOREINFO_NOTE_NAME "VMCOREINFO"
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 3ea8275..133df03 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -14,7 +14,6 @@

  #if !defined(__ASSEMBLY__)

-#include 
  #include 

  #include 
@@ -25,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 

  /* Verify architecture specific macros are defined */

@@ -63,15 +63,6 @@
  #define KEXEC_CORE_NOTE_NAME  CRASH_CORE_NOTE_NAME

  /*
- * The per-cpu notes area is a list of notes terminated by a "NULL"
- * note header.  For kdump, the code in vmcore.c runs in the context
- * of the second kernel to combine them into one note.
- */
-#ifndef KEXEC_NOTE_BYTES
-#define KEXEC_NOTE_BYTES   CRASH_CORE_NOTE_BYTES
-#endif
-
-/*
   * This structure is used to hold the arguments that are used when loading
   * kernel binaries.
   */


Looks good to me. Thanks for the fix..

- Hari



Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

2017-06-08 Thread Hari Bathini



On Friday 09 June 2017 07:47 AM, Xunlei Pang wrote:

S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
is now defined as follows:
 typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
It was changed by the CONFIG_CRASH_CORE feature.

This patch gets rid of all the old KEXEC_NOTE_BYTES stuff, and
renames KEXEC_NOTE_BYTES to CRASH_CORE_NOTE_BYTES for S390.

Fixes: 692f66f26a4c ("crash: move crashkernel parsing and vmcore related code under 
CONFIG_CRASH_CORE")
Cc: Dave Young 
Cc: Dave Anderson 
Cc: Hari Bathini 
Cc: Gustavo Luiz Duarte 
Signed-off-by: Xunlei Pang 
---
  arch/s390/include/asm/kexec.h |  2 +-
  include/linux/crash_core.h|  7 +++
  include/linux/kexec.h | 11 +--
  3 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
index 2f924bc..352deb8 100644
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -47,7 +47,7 @@
   * Seven notes plus zero note at the end: prstatus, fpregset, timer,
   * tod_cmp, tod_reg, control regs, and prefix
   */
-#define KEXEC_NOTE_BYTES \
+#define CRASH_CORE_NOTE_BYTES \
(ALIGN(sizeof(struct elf_note), 4) * 8 + \
 ALIGN(sizeof("CORE"), 4) * 7 + \
 ALIGN(sizeof(struct elf_prstatus), 4) + \
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index e9de6b4..dbc6e5c 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -10,9 +10,16 @@
  #define CRASH_CORE_NOTE_NAME_BYTES ALIGN(sizeof(CRASH_CORE_NOTE_NAME), 4)
  #define CRASH_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)

+/*
+ * The per-cpu notes area is a list of notes terminated by a "NULL"
+ * note header.  For kdump, the code in vmcore.c runs in the context
+ * of the second kernel to combine them into one note.
+ */
+#ifndef CRASH_CORE_NOTE_BYTES
  #define CRASH_CORE_NOTE_BYTES((CRASH_CORE_NOTE_HEAD_BYTES * 2) +  \
 CRASH_CORE_NOTE_NAME_BYTES +   \
 CRASH_CORE_NOTE_DESC_BYTES)
+#endif

  #define VMCOREINFO_BYTES PAGE_SIZE
  #define VMCOREINFO_NOTE_NAME "VMCOREINFO"
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 3ea8275..133df03 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -14,7 +14,6 @@

  #if !defined(__ASSEMBLY__)

-#include 
  #include 

  #include 
@@ -25,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 

  /* Verify architecture specific macros are defined */

@@ -63,15 +63,6 @@
  #define KEXEC_CORE_NOTE_NAME  CRASH_CORE_NOTE_NAME

  /*
- * The per-cpu notes area is a list of notes terminated by a "NULL"
- * note header.  For kdump, the code in vmcore.c runs in the context
- * of the second kernel to combine them into one note.
- */
-#ifndef KEXEC_NOTE_BYTES
-#define KEXEC_NOTE_BYTES   CRASH_CORE_NOTE_BYTES
-#endif
-
-/*
   * This structure is used to hold the arguments that are used when loading
   * kernel binaries.
   */


Looks good to me. Thanks for the fix..

- Hari



Re: [PATCH 1/4] drm: bridge: dw-hdmi: Export hdmi_phy_configure_dwc_hdmi_3d_tx

2017-06-08 Thread Mark yao
Ignore this patch, Jose has a better patch to solve rk3399 hdmi phy 
configure.


Hi Jose

Sorry for missing your patch about hdmi 2.0 vendor phy fixup: 
https://patchwork.kernel.org/patch/9702229

It works fine on rk3399/rk3288, can you resend a standard patch to upstream?

Thanks

On 2017年06月09日 10:45, Mark Yao wrote:

So dw-hdmi vendor driver can reuse hdmi_phy_configure_dwc_hdmi_3d_tx
to configure their hardware.

Signed-off-by: Mark Yao 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
  include/drm/bridge/dw_hdmi.h  | 3 +++
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 4e1f54a..c1ceec7 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1097,7 +1097,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
   * information the DWC MHL PHY has the same register layout and is thus also
   * supported by this function.
   */
-static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
const struct dw_hdmi_plat_data *pdata,
unsigned long mpixelclock)
  {
@@ -1146,6 +1146,7 @@ static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct 
dw_hdmi *hdmi,
  
  	return 0;

  }
+EXPORT_SYMBOL_GPL(hdmi_phy_configure_dwc_hdmi_3d_tx);
  
  static int hdmi_phy_configure(struct dw_hdmi *hdmi)

  {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ed599be..7eb67e6 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -150,6 +150,9 @@ int dw_hdmi_probe(struct platform_device *pdev,
  int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
 const struct dw_hdmi_plat_data *plat_data);
  
+int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,

+   const struct dw_hdmi_plat_data *pdata,
+   unsigned long mpixelclock);
  void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
  
  void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);



--
Mark Yao




Re: [PATCH 1/4] drm: bridge: dw-hdmi: Export hdmi_phy_configure_dwc_hdmi_3d_tx

2017-06-08 Thread Mark yao
Ignore this patch, Jose has a better patch to solve rk3399 hdmi phy 
configure.


Hi Jose

Sorry for missing your patch about hdmi 2.0 vendor phy fixup: 
https://patchwork.kernel.org/patch/9702229

It works fine on rk3399/rk3288, can you resend a standard patch to upstream?

Thanks

On 2017年06月09日 10:45, Mark Yao wrote:

So dw-hdmi vendor driver can reuse hdmi_phy_configure_dwc_hdmi_3d_tx
to configure their hardware.

Signed-off-by: Mark Yao 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
  include/drm/bridge/dw_hdmi.h  | 3 +++
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 4e1f54a..c1ceec7 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1097,7 +1097,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
   * information the DWC MHL PHY has the same register layout and is thus also
   * supported by this function.
   */
-static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
const struct dw_hdmi_plat_data *pdata,
unsigned long mpixelclock)
  {
@@ -1146,6 +1146,7 @@ static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct 
dw_hdmi *hdmi,
  
  	return 0;

  }
+EXPORT_SYMBOL_GPL(hdmi_phy_configure_dwc_hdmi_3d_tx);
  
  static int hdmi_phy_configure(struct dw_hdmi *hdmi)

  {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ed599be..7eb67e6 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -150,6 +150,9 @@ int dw_hdmi_probe(struct platform_device *pdev,
  int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
 const struct dw_hdmi_plat_data *plat_data);
  
+int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,

+   const struct dw_hdmi_plat_data *pdata,
+   unsigned long mpixelclock);
  void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
  
  void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);



--
Mark Yao




[PATCH v6] mtd: handle partitioning on devices with 0 erasesize

2017-06-08 Thread Chris Packham
erasesize is meaningful for flash devices but for SRAM there is no
concept of an erase block so erasesize is set to 0. When partitioning
these devices instead of ensuring partitions fall on erasesize
boundaries we ensure they fall on writesize boundaries.

Helped-by: Boris Brezillon 
Signed-off-by: Chris Packham 
---
Changes in v3:
- new
Changes in v4:
- None
Changes in v5:
- None (yet). There is some active discussion on this so it may change.
  patch 4/5 is somewhat dependent on this but only if partitions are
  specified on the dt node.
  Changes in v6:
- Use MTD_NO_ERASE flag to decide whether to use writesize or erasesize
  for alignment purposes

 drivers/mtd/mtdpart.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index ea5e5307f667..2e152e53ace0 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -393,8 +393,12 @@ static struct mtd_part *allocate_partition(struct mtd_info 
*master,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
 {
+   int wr_alignment = (master->flags & MTD_NO_ERASE) ? master->writesize:
+   master->erasesize;
struct mtd_part *slave;
+   u32 remainder;
char *name;
+   u64 tmp;
 
/* allocate the partition structure */
slave = kzalloc(sizeof(*slave), GFP_KERNEL);
@@ -499,10 +503,11 @@ static struct mtd_part *allocate_partition(struct 
mtd_info *master,
if (slave->offset == MTDPART_OFS_APPEND)
slave->offset = cur_offset;
if (slave->offset == MTDPART_OFS_NXTBLK) {
+   tmp = cur_offset;
slave->offset = cur_offset;
-   if (mtd_mod_by_eb(cur_offset, master) != 0) {
-   /* Round up to next erasesize */
-   slave->offset = (mtd_div_by_eb(cur_offset, master) + 1) 
* master->erasesize;
+   remainder = do_div(tmp, wr_alignment);
+   if (remainder) {
+   slave->offset += wr_alignment - remainder;
printk(KERN_NOTICE "Moving partition %d: "
   "0x%012llx -> 0x%012llx\n", partno,
   (unsigned long long)cur_offset, (unsigned long 
long)slave->offset);
@@ -567,19 +572,22 @@ static struct mtd_part *allocate_partition(struct 
mtd_info *master,
slave->mtd.erasesize = master->erasesize;
}
 
-   if ((slave->mtd.flags & MTD_WRITEABLE) &&
-   mtd_mod_by_eb(slave->offset, >mtd)) {
+   tmp = slave->offset;
+   remainder = do_div(tmp, wr_alignment);
+   if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
/* Doesn't start on a boundary of major erase size */
/* FIXME: Let it be writable if it is on a boundary of
 * _minor_ erase size though */
slave->mtd.flags &= ~MTD_WRITEABLE;
-   printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an 
erase block boundary -- force read-only\n",
+   printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an 
erase/write block boundary -- force read-only\n",
part->name);
}
-   if ((slave->mtd.flags & MTD_WRITEABLE) &&
-   mtd_mod_by_eb(slave->mtd.size, >mtd)) {
+
+   tmp = slave->mtd.size;
+   remainder = do_div(tmp, wr_alignment);
+   if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
slave->mtd.flags &= ~MTD_WRITEABLE;
-   printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an 
erase block -- force read-only\n",
+   printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an 
erase/write block -- force read-only\n",
part->name);
}
 
-- 
2.13.0



[PATCH v6] mtd: handle partitioning on devices with 0 erasesize

2017-06-08 Thread Chris Packham
erasesize is meaningful for flash devices but for SRAM there is no
concept of an erase block so erasesize is set to 0. When partitioning
these devices instead of ensuring partitions fall on erasesize
boundaries we ensure they fall on writesize boundaries.

Helped-by: Boris Brezillon 
Signed-off-by: Chris Packham 
---
Changes in v3:
- new
Changes in v4:
- None
Changes in v5:
- None (yet). There is some active discussion on this so it may change.
  patch 4/5 is somewhat dependent on this but only if partitions are
  specified on the dt node.
  Changes in v6:
- Use MTD_NO_ERASE flag to decide whether to use writesize or erasesize
  for alignment purposes

 drivers/mtd/mtdpart.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index ea5e5307f667..2e152e53ace0 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -393,8 +393,12 @@ static struct mtd_part *allocate_partition(struct mtd_info 
*master,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
 {
+   int wr_alignment = (master->flags & MTD_NO_ERASE) ? master->writesize:
+   master->erasesize;
struct mtd_part *slave;
+   u32 remainder;
char *name;
+   u64 tmp;
 
/* allocate the partition structure */
slave = kzalloc(sizeof(*slave), GFP_KERNEL);
@@ -499,10 +503,11 @@ static struct mtd_part *allocate_partition(struct 
mtd_info *master,
if (slave->offset == MTDPART_OFS_APPEND)
slave->offset = cur_offset;
if (slave->offset == MTDPART_OFS_NXTBLK) {
+   tmp = cur_offset;
slave->offset = cur_offset;
-   if (mtd_mod_by_eb(cur_offset, master) != 0) {
-   /* Round up to next erasesize */
-   slave->offset = (mtd_div_by_eb(cur_offset, master) + 1) 
* master->erasesize;
+   remainder = do_div(tmp, wr_alignment);
+   if (remainder) {
+   slave->offset += wr_alignment - remainder;
printk(KERN_NOTICE "Moving partition %d: "
   "0x%012llx -> 0x%012llx\n", partno,
   (unsigned long long)cur_offset, (unsigned long 
long)slave->offset);
@@ -567,19 +572,22 @@ static struct mtd_part *allocate_partition(struct 
mtd_info *master,
slave->mtd.erasesize = master->erasesize;
}
 
-   if ((slave->mtd.flags & MTD_WRITEABLE) &&
-   mtd_mod_by_eb(slave->offset, >mtd)) {
+   tmp = slave->offset;
+   remainder = do_div(tmp, wr_alignment);
+   if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
/* Doesn't start on a boundary of major erase size */
/* FIXME: Let it be writable if it is on a boundary of
 * _minor_ erase size though */
slave->mtd.flags &= ~MTD_WRITEABLE;
-   printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an 
erase block boundary -- force read-only\n",
+   printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an 
erase/write block boundary -- force read-only\n",
part->name);
}
-   if ((slave->mtd.flags & MTD_WRITEABLE) &&
-   mtd_mod_by_eb(slave->mtd.size, >mtd)) {
+
+   tmp = slave->mtd.size;
+   remainder = do_div(tmp, wr_alignment);
+   if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
slave->mtd.flags &= ~MTD_WRITEABLE;
-   printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an 
erase block -- force read-only\n",
+   printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an 
erase/write block -- force read-only\n",
part->name);
}
 
-- 
2.13.0



Re: [kernel-hardening] [PATCH 0/6] LSM: Security module blob management

2017-06-08 Thread James Morris
On Thu, 8 Jun 2017, Matt Brown wrote:

> On 6/8/17 4:43 PM, Casey Schaufler wrote:
> > Subject: [PATCH 0/6] LSM: Security module blob management
> > 
> > This patch set moves management of security blobs out of
> > the Linux security modules and into the security module
> > infrastructure. This allows "major" security modules that
> > use blobs to be stacked, just as "minor" modules that
> > do not use blobs can be stacked today. It stops short of
> > providing a safe interface for the Netlabel and SO_PEERSEC.
> > As a result, any of the existing security modules may be
> > used in combination except for SELinux and Smack.
> 
> Very excited about this! I can definitely see use cases for special
> purpose LSMs that require data blobs but do not replace things like
> SELinux, SMACK or AppArmor. I have had a few ideas recently that would
> not be possible under the current setup of one shared blob.

Please post details of these ideas once you have say a prototype working 
with Casey's patches.


-- 
James Morris




Re: [kernel-hardening] [PATCH 0/6] LSM: Security module blob management

2017-06-08 Thread James Morris
On Thu, 8 Jun 2017, Matt Brown wrote:

> On 6/8/17 4:43 PM, Casey Schaufler wrote:
> > Subject: [PATCH 0/6] LSM: Security module blob management
> > 
> > This patch set moves management of security blobs out of
> > the Linux security modules and into the security module
> > infrastructure. This allows "major" security modules that
> > use blobs to be stacked, just as "minor" modules that
> > do not use blobs can be stacked today. It stops short of
> > providing a safe interface for the Netlabel and SO_PEERSEC.
> > As a result, any of the existing security modules may be
> > used in combination except for SELinux and Smack.
> 
> Very excited about this! I can definitely see use cases for special
> purpose LSMs that require data blobs but do not replace things like
> SELinux, SMACK or AppArmor. I have had a few ideas recently that would
> not be possible under the current setup of one shared blob.

Please post details of these ideas once you have say a prototype working 
with Casey's patches.


-- 
James Morris




Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

2017-06-08 Thread John Hubbard

On 05/24/2017 10:20 AM, Jérôme Glisse wrote:
[...8<...]

+#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
+int device_private_entry_fault(struct vm_area_struct *vma,
+  unsigned long addr,
+  swp_entry_t entry,
+  unsigned int flags,
+  pmd_t *pmdp)
+{
+   struct page *page = device_private_entry_to_page(entry);
+
+   /*
+* The page_fault() callback must migrate page back to system memory
+* so that CPU can access it. This might fail for various reasons
+* (device issue, device was unsafely unplugged, ...). When such
+* error conditions happen, the callback must return VM_FAULT_SIGBUS.
+*
+* Note that because memory cgroup charges are accounted to the device
+* memory, this should never fail because of memory restrictions (but
+* allocation of regular system page might still fail because we are
+* out of memory).
+*
+* There is a more in-depth description of what that callback can and
+* cannot do, in include/linux/memremap.h
+*/
+   return page->pgmap->page_fault(vma, addr, page, flags, pmdp);
+}
+EXPORT_SYMBOL(device_private_entry_fault);
+#endif /* CONFIG_DEVICE_PRIVATE */
+
  static void pgmap_radix_release(struct resource *res)
  {
resource_size_t key, align_start, align_size, align_end;
@@ -321,6 +351,10 @@ void *devm_memremap_pages(struct device *dev, struct 
resource *res,
}
pgmap->ref = ref;
pgmap->res = _map->res;
+   pgmap->type = MEMORY_DEVICE_PUBLIC;
+   pgmap->page_fault = NULL;
+   pgmap->page_free = NULL;
+   pgmap->data = NULL;
  
  	mutex_lock(_lock);

error = 0;
diff --git a/mm/Kconfig b/mm/Kconfig
index d744cff..f5357ff 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -736,6 +736,19 @@ config ZONE_DEVICE
  
  	  If FS_DAX is enabled, then say Y.
  
+config DEVICE_PRIVATE

+   bool "Unaddressable device memory (GPU memory, ...)"
+   depends on X86_64
+   depends on ZONE_DEVICE
+   depends on MEMORY_HOTPLUG
+   depends on MEMORY_HOTREMOVE
+   depends on SPARSEMEM_VMEMMAP
+
+   help
+ Allows creation of struct pages to represent unaddressable device
+ memory; i.e., memory that is only accessible from the device (or
+ group of devices).
+


Hi Jerome,

CONFIG_DEVICE_PRIVATE has caused me some problems, because it's not coupled to 
HMM_DEVMEM.

To fix this, my first choice would be to just s/DEVICE_PRIVATE/HMM_DEVMEM/g , because I don't see 
any value to DEVICE_PRIVATE as an independent Kconfig choice. It's complicating the Kconfig choices, 
and adding problems. However, if DEVICE_PRIVATE must be kept, then something like this also fixes my 
HMM tests:


From: John Hubbard 
Date: Thu, 8 Jun 2017 20:13:13 -0700
Subject: [PATCH] hmm: select CONFIG_DEVICE_PRIVATE with HMM_DEVMEM

The HMM_DEVMEM feature is useless without the various
features that are guarded with CONFIG_DEVICE_PRIVATE.
Therefore, auto-select DEVICE_PRIVATE when selecting
HMM_DEVMEM.

Otherwise, you can easily end up with a partially
working HMM installation: if you select HMM_DEVMEM,
but do not select DEVICE_PRIVATE, then faulting and
migrating to a device (such as a GPU) works, but CPU
page faults are ignored, so the page never migrates
back to the CPU.

Signed-off-by: John Hubbard 
---
 mm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 46296d5d7570..23d2f5ec865e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -318,6 +318,8 @@ config HMM_DEVMEM
bool "HMM device memory helpers (to leverage ZONE_DEVICE)"
depends on ARCH_HAS_HMM
select HMM
+   select DEVICE_PRIVATE
+
help
  HMM devmem is a set of helper routines to leverage the ZONE_DEVICE
  feature. This is just to avoid having device drivers to replicating a 
lot
--
2.13.1

This is a minor thing, and I don't think this needs to hold up merging HMM v23 into -mm, IMHO. But I 
would like it fixed at some point.


thanks,
--
John Hubbard
NVIDIA


Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

2017-06-08 Thread John Hubbard

On 05/24/2017 10:20 AM, Jérôme Glisse wrote:
[...8<...]

+#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
+int device_private_entry_fault(struct vm_area_struct *vma,
+  unsigned long addr,
+  swp_entry_t entry,
+  unsigned int flags,
+  pmd_t *pmdp)
+{
+   struct page *page = device_private_entry_to_page(entry);
+
+   /*
+* The page_fault() callback must migrate page back to system memory
+* so that CPU can access it. This might fail for various reasons
+* (device issue, device was unsafely unplugged, ...). When such
+* error conditions happen, the callback must return VM_FAULT_SIGBUS.
+*
+* Note that because memory cgroup charges are accounted to the device
+* memory, this should never fail because of memory restrictions (but
+* allocation of regular system page might still fail because we are
+* out of memory).
+*
+* There is a more in-depth description of what that callback can and
+* cannot do, in include/linux/memremap.h
+*/
+   return page->pgmap->page_fault(vma, addr, page, flags, pmdp);
+}
+EXPORT_SYMBOL(device_private_entry_fault);
+#endif /* CONFIG_DEVICE_PRIVATE */
+
  static void pgmap_radix_release(struct resource *res)
  {
resource_size_t key, align_start, align_size, align_end;
@@ -321,6 +351,10 @@ void *devm_memremap_pages(struct device *dev, struct 
resource *res,
}
pgmap->ref = ref;
pgmap->res = _map->res;
+   pgmap->type = MEMORY_DEVICE_PUBLIC;
+   pgmap->page_fault = NULL;
+   pgmap->page_free = NULL;
+   pgmap->data = NULL;
  
  	mutex_lock(_lock);

error = 0;
diff --git a/mm/Kconfig b/mm/Kconfig
index d744cff..f5357ff 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -736,6 +736,19 @@ config ZONE_DEVICE
  
  	  If FS_DAX is enabled, then say Y.
  
+config DEVICE_PRIVATE

+   bool "Unaddressable device memory (GPU memory, ...)"
+   depends on X86_64
+   depends on ZONE_DEVICE
+   depends on MEMORY_HOTPLUG
+   depends on MEMORY_HOTREMOVE
+   depends on SPARSEMEM_VMEMMAP
+
+   help
+ Allows creation of struct pages to represent unaddressable device
+ memory; i.e., memory that is only accessible from the device (or
+ group of devices).
+


Hi Jerome,

CONFIG_DEVICE_PRIVATE has caused me some problems, because it's not coupled to 
HMM_DEVMEM.

To fix this, my first choice would be to just s/DEVICE_PRIVATE/HMM_DEVMEM/g , because I don't see 
any value to DEVICE_PRIVATE as an independent Kconfig choice. It's complicating the Kconfig choices, 
and adding problems. However, if DEVICE_PRIVATE must be kept, then something like this also fixes my 
HMM tests:


From: John Hubbard 
Date: Thu, 8 Jun 2017 20:13:13 -0700
Subject: [PATCH] hmm: select CONFIG_DEVICE_PRIVATE with HMM_DEVMEM

The HMM_DEVMEM feature is useless without the various
features that are guarded with CONFIG_DEVICE_PRIVATE.
Therefore, auto-select DEVICE_PRIVATE when selecting
HMM_DEVMEM.

Otherwise, you can easily end up with a partially
working HMM installation: if you select HMM_DEVMEM,
but do not select DEVICE_PRIVATE, then faulting and
migrating to a device (such as a GPU) works, but CPU
page faults are ignored, so the page never migrates
back to the CPU.

Signed-off-by: John Hubbard 
---
 mm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 46296d5d7570..23d2f5ec865e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -318,6 +318,8 @@ config HMM_DEVMEM
bool "HMM device memory helpers (to leverage ZONE_DEVICE)"
depends on ARCH_HAS_HMM
select HMM
+   select DEVICE_PRIVATE
+
help
  HMM devmem is a set of helper routines to leverage the ZONE_DEVICE
  feature. This is just to avoid having device drivers to replicating a 
lot
--
2.13.1

This is a minor thing, and I don't think this needs to hold up merging HMM v23 into -mm, IMHO. But I 
would like it fixed at some point.


thanks,
--
John Hubbard
NVIDIA


linux-next: manual merge of the devicetree tree with the renesas tree

2017-06-08 Thread Stephen Rothwell
Hi Rob,

Today's linux-next merge of the devicetree tree got a conflict in:

  Documentation/devicetree/bindings/vendor-prefixes.txt

between commit:

  d795f15618b8 ("of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd")

from the renesas tree and commit:

  97a0268e764c ("devicetree: add Itead vendor prefix")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index b946fc4b172a,b81092afe76d..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -158,7 -159,7 +159,8 @@@ iomIomega Corporatio
  isee  ISEE 2007 S.L.
  isil  Intersil
  issi  Integrated Silicon Solutions Inc.
+ itead ITEAD Intelligent Systems Co.Ltd
 +iwave iWave Systems Technologies Pvt. Ltd.
  jdi   Japan Display Inc.
  jedec JEDEC Solid State Technology Association
  karo  Ka-Ro electronics GmbH


linux-next: manual merge of the devicetree tree with the renesas tree

2017-06-08 Thread Stephen Rothwell
Hi Rob,

Today's linux-next merge of the devicetree tree got a conflict in:

  Documentation/devicetree/bindings/vendor-prefixes.txt

between commit:

  d795f15618b8 ("of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd")

from the renesas tree and commit:

  97a0268e764c ("devicetree: add Itead vendor prefix")

from the devicetree tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index b946fc4b172a,b81092afe76d..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -158,7 -159,7 +159,8 @@@ iomIomega Corporatio
  isee  ISEE 2007 S.L.
  isil  Intersil
  issi  Integrated Silicon Solutions Inc.
+ itead ITEAD Intelligent Systems Co.Ltd
 +iwave iWave Systems Technologies Pvt. Ltd.
  jdi   Japan Display Inc.
  jedec JEDEC Solid State Technology Association
  karo  Ka-Ro electronics GmbH


Re: [PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board

2017-06-08 Thread Hoegeun Kwon

Dear Thierry,

Could you check these patches.

Regards,
Hoegeun

On 05/19/2017 03:56 PM, Hoegeun Kwon wrote:

Dear Thierry,

Could you check these patches?
I think this patches have accumulated enough dust.
If you have a another opinion, please tell me.

Best regards,
Hoegeun

On 04/18/2017 05:40 PM, Hoegeun Kwon wrote:

Hi all,

The purpose of this patch is add support for s6e3hf2 AMOLED panel on
the TM2e board. The panel has 1600x2560 resolution in 5.65" physical
panel in the TM2e device.

The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"),
but resolution and some command message are different. So it can be
distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Changes for V3:
- Remove te-gpios property in dts.
- Added Reviewed-by: Andrzej Hajda  on all patches.
- Added Reviewed-by: Inki Dae  on patch (2/3).

Changes for V2:
- Add new compatible string to "samsung,s6e3ha2.txt binding with 
comments.

- Fix the panel name from s6e3ha2-e to s6e3hf2

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e3hf2 panel
   drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
   arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e 
board


  .../bindings/display/panel/samsung,s6e3ha2.txt |  5 +-
  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 
  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 64 
+++---

  3 files changed, 72 insertions(+), 8 deletions(-)









Re: [PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board

2017-06-08 Thread Hoegeun Kwon

Dear Thierry,

Could you check these patches.

Regards,
Hoegeun

On 05/19/2017 03:56 PM, Hoegeun Kwon wrote:

Dear Thierry,

Could you check these patches?
I think this patches have accumulated enough dust.
If you have a another opinion, please tell me.

Best regards,
Hoegeun

On 04/18/2017 05:40 PM, Hoegeun Kwon wrote:

Hi all,

The purpose of this patch is add support for s6e3hf2 AMOLED panel on
the TM2e board. The panel has 1600x2560 resolution in 5.65" physical
panel in the TM2e device.

The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"),
but resolution and some command message are different. So it can be
distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Changes for V3:
- Remove te-gpios property in dts.
- Added Reviewed-by: Andrzej Hajda  on all patches.
- Added Reviewed-by: Inki Dae  on patch (2/3).

Changes for V2:
- Add new compatible string to "samsung,s6e3ha2.txt binding with 
comments.

- Fix the panel name from s6e3ha2-e to s6e3hf2

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e3hf2 panel
   drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
   arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e 
board


  .../bindings/display/panel/samsung,s6e3ha2.txt |  5 +-
  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 
  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 64 
+++---

  3 files changed, 72 insertions(+), 8 deletions(-)









  1   2   3   4   5   6   7   8   9   10   >