[PATCH] drm/i915: Fix an error hanfling path in 'i915_gem_do_execbuffer'

[Christophe JAILLET]

if 'eb_create()' fails, we must release some resources as done in all other
error handling paths of this function.

Signed-off-by: Christophe JAILLET 
---
This patch is just a guess based on surrounding gotos and function names.
(i.e. 'get_unused_fd_flags()' and 'put_unused_fd()')
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9337446f1068..0746b352f820 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2180,8 +2180,9 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
}
 
-   if (eb_create())
-   return -ENOMEM;
+   err = eb_create();
+   if (err)
+   goto err_put_unused_fd;
 
/*
 * Take a local wakeref for preparing to dispatch the execbuf as
@@ -2340,6 +2341,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
 err_rpm:
intel_runtime_pm_put(eb.i915);
eb_destroy();
+err_put_unused_fd:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
 err_in_fence:
-- 
2.11.0

[PATCH] drm/i915: Fix an error hanfling path in 'i915_gem_do_execbuffer'

[Christophe JAILLET]

if 'eb_create()' fails, we must release some resources as done in all other
error handling paths of this function.

Signed-off-by: Christophe JAILLET 
---
This patch is just a guess based on surrounding gotos and function names.
(i.e. 'get_unused_fd_flags()' and 'put_unused_fd()')
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9337446f1068..0746b352f820 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2180,8 +2180,9 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
}
 
-   if (eb_create())
-   return -ENOMEM;
+   err = eb_create();
+   if (err)
+   goto err_put_unused_fd;
 
/*
 * Take a local wakeref for preparing to dispatch the execbuf as
@@ -2340,6 +2341,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
 err_rpm:
intel_runtime_pm_put(eb.i915);
eb_destroy();
+err_put_unused_fd:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
 err_in_fence:
-- 
2.11.0

[PATCH] mux: remove the Kconfig question for the subsystem

[Peter Rosin]

The MULTIPLEXER question in the Kconfig might be confusing and is
of dubious value. Remove it. This makes consumers responsible for
selecting MULTIPLEXER, which they already do.

Signed-off-by: Peter Rosin 
---
 drivers/mux/Kconfig | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

Hi Linus!

My thinking was that I wanted it to be possible to select
mux drivers before any mux consumer was selected. I also
wanted to avoid one question for each of the mux drivers
when the whole thing is not needed most of the time...

But ok, is something like this what you wanted?

Cheers,
peda

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 7c754a0..96d364e 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -2,18 +2,7 @@
 # Multiplexer devices
 #
 
-menuconfig MULTIPLEXER
-   tristate "Multiplexer subsystem"
-   help
- Multiplexer controller subsystem. Multiplexers are used in a
- variety of settings, and this subsystem abstracts their use
- so that the rest of the kernel sees a common interface. When
- multiple parallel multiplexers are controlled by one single
- multiplexer controller, this subsystem also coordinates the
- multiplexer accesses.
-
- To compile the subsystem as a module, choose M here: the module will
- be called mux-core.
+menu "Multiplexer support"
 
 if MULTIPLEXER
 
@@ -57,3 +46,5 @@ config MUX_MMIO
  be called mux-mmio.
 
 endif
+
+endmenu
-- 
2.1.4

[PATCH] mux: remove the Kconfig question for the subsystem

[Peter Rosin]

The MULTIPLEXER question in the Kconfig might be confusing and is
of dubious value. Remove it. This makes consumers responsible for
selecting MULTIPLEXER, which they already do.

Signed-off-by: Peter Rosin 
---
 drivers/mux/Kconfig | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

Hi Linus!

My thinking was that I wanted it to be possible to select
mux drivers before any mux consumer was selected. I also
wanted to avoid one question for each of the mux drivers
when the whole thing is not needed most of the time...

But ok, is something like this what you wanted?

Cheers,
peda

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 7c754a0..96d364e 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -2,18 +2,7 @@
 # Multiplexer devices
 #
 
-menuconfig MULTIPLEXER
-   tristate "Multiplexer subsystem"
-   help
- Multiplexer controller subsystem. Multiplexers are used in a
- variety of settings, and this subsystem abstracts their use
- so that the rest of the kernel sees a common interface. When
- multiple parallel multiplexers are controlled by one single
- multiplexer controller, this subsystem also coordinates the
- multiplexer accesses.
-
- To compile the subsystem as a module, choose M here: the module will
- be called mux-core.
+menu "Multiplexer support"
 
 if MULTIPLEXER
 
@@ -57,3 +46,5 @@ config MUX_MMIO
  be called mux-mmio.
 
 endif
+
+endmenu
-- 
2.1.4

Re: [PATCH v2] ext4: have ext4_xattr_set_handle() allocate journal credits

[Theodore Ts'o]

On Fri, Jun 30, 2017 at 12:36:51PM -0700, Tahsin Erdogan wrote:
> > One problem with this approach is that restarting the transaction handle 
> > will
> > make the xattr update non-atomic, which could be a real problem for some
> > workloads.  For example, ACLs or SELinux or fscrypt xattrs being added in
> > a separate transaction from file creation, or being modified (delete in a
> > separate transaction from add) and then lost completely if the system 
> > crashes
> > before the second transaction is committed.
> 
> Agreed.

I really don't like this patch for this reason.

In fact, it doesn't work because in your example code path:

> An example code path is this:
> 
> ext4_mkdir()
>   ext4_new_inode_start_handle()
> __ext4_new_inode()   <<== transaction handle is started here
>   ext4_init_acl()
> __ext4_set_acl()
>   ext4_xattr_set_handle()
> 
> In this case, __ext4_new_inode() needs to figure out all journal
> credits needed including the ones for ext4_xattr_set_handle(). This is
> a few levels deep so reaching out to ext4_xattr_set_credits() with the
> right parameters is where the complexity lies.

If we need to restart a transaction in ext4_init_acl(), we will end up
breaking up a transaction into two pieces.  Which means if we crash,
we could very easily end up with a corrupt file system because the
inode might be allocated, but not yet linked into the directory
hierarchy.

Worse, it doesn't really solve the problem because
ext4_xattr_ensure_credits() merely makes sure there are enough credits
for the xattr operation.  If setting the xattr ACL chews up credits
needed to insert the name of the newly created file into the
directory, you're still going to end up running into problems.

The way we've historically handled this is to simplify things by
making worse-case estimates when the transaction handled started.  So
for example, we assume the worst case that we'll split an directory
hash tree, even though we might not know whether or not this will be
necessary.  That's because if we over-estimate the number of credits
needed for a handle, it's really not a disaster.  Most handles are
active for a very short time, and when we close the handle, we can
give back any unused credits.

I understand that for ext4_new_inode it can be quite tricky, since in
theory we might need to add an SE Linux label, plus an ACL, plus an
encryption context.

The one good news is that is that with the xattr inode deduplication
feature, ext4_init_acl as called from ext4_new_inode should always
require just bumping a refcount, since the ACL will be inherited from
the directory's default ACL.

The bad news is that in general, we don't know what
security_inode_init_security() will do.  In theory, it could try to
set an arbitrarily large lael, although in practice we know the SE
Linux label tends not to be too terribly large.

Are you aware of other cases where we're likely to run into problems
besides ext4_new_inode()?

- Ted

Re: [PATCH v2] ext4: have ext4_xattr_set_handle() allocate journal credits

[Theodore Ts'o]

On Fri, Jun 30, 2017 at 12:36:51PM -0700, Tahsin Erdogan wrote:
> > One problem with this approach is that restarting the transaction handle 
> > will
> > make the xattr update non-atomic, which could be a real problem for some
> > workloads.  For example, ACLs or SELinux or fscrypt xattrs being added in
> > a separate transaction from file creation, or being modified (delete in a
> > separate transaction from add) and then lost completely if the system 
> > crashes
> > before the second transaction is committed.
> 
> Agreed.

I really don't like this patch for this reason.

In fact, it doesn't work because in your example code path:

> An example code path is this:
> 
> ext4_mkdir()
>   ext4_new_inode_start_handle()
> __ext4_new_inode()   <<== transaction handle is started here
>   ext4_init_acl()
> __ext4_set_acl()
>   ext4_xattr_set_handle()
> 
> In this case, __ext4_new_inode() needs to figure out all journal
> credits needed including the ones for ext4_xattr_set_handle(). This is
> a few levels deep so reaching out to ext4_xattr_set_credits() with the
> right parameters is where the complexity lies.

If we need to restart a transaction in ext4_init_acl(), we will end up
breaking up a transaction into two pieces.  Which means if we crash,
we could very easily end up with a corrupt file system because the
inode might be allocated, but not yet linked into the directory
hierarchy.

Worse, it doesn't really solve the problem because
ext4_xattr_ensure_credits() merely makes sure there are enough credits
for the xattr operation.  If setting the xattr ACL chews up credits
needed to insert the name of the newly created file into the
directory, you're still going to end up running into problems.

The way we've historically handled this is to simplify things by
making worse-case estimates when the transaction handled started.  So
for example, we assume the worst case that we'll split an directory
hash tree, even though we might not know whether or not this will be
necessary.  That's because if we over-estimate the number of credits
needed for a handle, it's really not a disaster.  Most handles are
active for a very short time, and when we close the handle, we can
give back any unused credits.

I understand that for ext4_new_inode it can be quite tricky, since in
theory we might need to add an SE Linux label, plus an ACL, plus an
encryption context.

The one good news is that is that with the xattr inode deduplication
feature, ext4_init_acl as called from ext4_new_inode should always
require just bumping a refcount, since the ACL will be inherited from
the directory's default ACL.

The bad news is that in general, we don't know what
security_inode_init_security() will do.  In theory, it could try to
set an arbitrarily large lael, although in practice we know the SE
Linux label tends not to be too terribly large.

Are you aware of other cases where we're likely to run into problems
besides ext4_new_inode()?

- Ted

linux-next: Tree for Jul 4

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to you linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170703:

The sound-asoc tree lost its build failure.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 10374
 9398 files changed, 767022 insertions(+), 194071 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c6b1e36c8fa0 Merge branch 'for-4.13/block' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (c0bc126f97fb Linux 4.12-rc7)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (ea23b42739a2 Merge tag 'mlx5-fixes-2017-06-28' of 
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (91af6ba7ff16 netfilter: ebt_nflog: fix unexpected 
truncated packet)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (4b153ca989a9 Merge tag 'mac80211-for-davem-2017-06-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (a178232ddab5 ALSA: hda/realtek - Remove 
GPIO_MASK)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (3c2993b8c614 Linux 4.12-rc4)
Merging usb.current/usb-linus (dec08194ffec xhci: Limit USB2 port wake support 
for AMD Promontory hosts)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (41f1830f5a7a Linux 4.12-rc6)
Merging char-misc.current/char-misc-linus (32c1431eea48 Linux 4.12-rc5)
Merging input-current/for-linus (9768935264c4 Input: synaptics-rmi4 - only read 
the F54 query registers which are used)
Merging crypto-current/master (019d62db5401 crypto: caam - fix gfp allocation 
flags (part II))
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Mergi

linux-next: Tree for Jul 4

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to you linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170703:

The sound-asoc tree lost its build failure.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 10374
 9398 files changed, 767022 insertions(+), 194071 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c6b1e36c8fa0 Merge branch 'for-4.13/block' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (c0bc126f97fb Linux 4.12-rc7)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (ea23b42739a2 Merge tag 'mlx5-fixes-2017-06-28' of 
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (91af6ba7ff16 netfilter: ebt_nflog: fix unexpected 
truncated packet)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (4b153ca989a9 Merge tag 'mac80211-for-davem-2017-06-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (a178232ddab5 ALSA: hda/realtek - Remove 
GPIO_MASK)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (3c2993b8c614 Linux 4.12-rc4)
Merging usb.current/usb-linus (dec08194ffec xhci: Limit USB2 port wake support 
for AMD Promontory hosts)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (41f1830f5a7a Linux 4.12-rc6)
Merging char-misc.current/char-misc-linus (32c1431eea48 Linux 4.12-rc5)
Merging input-current/for-linus (9768935264c4 Input: synaptics-rmi4 - only read 
the F54 query registers which are used)
Merging crypto-current/master (019d62db5401 crypto: caam - fix gfp allocation 
flags (part II))
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Mergi

Re: [PATCH v2 09/19] media: camms: Add core files

[Sakari Ailus]

Hi Todor,

On Mon, Jul 03, 2017 at 05:03:40PM +0300, Todor Tomov wrote:
> >> +  unsigned int i;
> >> +
> >> +  v4l2_of_parse_endpoint(node, );
> >> +
> >> +  csd->interface.csiphy_id = vep.base.port;
> >> +
> >> +  mipi_csi2 = _csi2;
> >> +  lncfg->clk.pos = mipi_csi2->clock_lane;
> >> +  lncfg->clk.pol = mipi_csi2->lane_polarities[0];
> >> +  lncfg->num_data = mipi_csi2->num_data_lanes;
> >> +
> >> +  lncfg->data = devm_kzalloc(dev, lncfg->num_data * sizeof(*lncfg->data),
> >> + GFP_KERNEL);
> >> +  if (!lncfg->data)
> >> +  return -ENOMEM;
> >> +
> >> +  for (i = 0; i < lncfg->num_data; i++) {
> >> +  lncfg->data[i].pos = mipi_csi2->data_lanes[i];
> >> +  lncfg->data[i].pol = mipi_csi2->lane_polarities[i + 1];
> >> +  }
> >> +
> >> +  of_property_read_u32(node, "qcom,settle-cnt", settle_cnt);
> > 
> > Isn't this something that depends on the CSI-2 bus speed, for instance?
> > Could you calculate it instead of putting it to DT?
> 
> Actually, after some digging into this, yes, I can calculate it. I can
> calculate the CSI-2 bus speed based on the sensor's output pixel clock
> and then calculate the settle time and this settle count value.
> So I already have the code to get the sensor's pixel clock using the
> standard v4l2 control V4L2_CID_PIXEL_RATE.

What we have currently in documentation on this is here:



I.e. both should be implemented. The link frequency is rather more relevant
for CSI-2 albeit you can derive one from the other in case of CSI-2. The
pixel rate documentation should probably be rather elsewhere.

> Now the question is what to do if the sensor driver doesn't support this
> control? Just return an error and refuse to work with this "limited"
> sensor driver?

If the sensor driver does not provide enough information to work with a
receiver, it's only fair not to proceed with streaming. That said, it might
be possible to manage with some sensible defaults in some cases but then again
you could have only some units working with this configuration. It'd be
much safer to require the information: not doing so hides the error and
makes it (more) difficult to debug.

...

> >> +struct camss {
> >> +  struct v4l2_device v4l2_dev;
> >> +  struct v4l2_async_notifier notifier;
> >> +  struct media_device media_dev;
> >> +  struct device *dev;
> >> +  struct csiphy_device csiphy[CAMSS_CSIPHY_NUM];
> >> +  struct csid_device csid[CAMSS_CSID_NUM];
> >> +  struct ispif_device ispif;
> >> +  struct vfe_device vfe;
> >> +  atomic_t ref_count;

If this is refcount, then you should use refcount_t instead.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 09/19] media: camms: Add core files

[Sakari Ailus]

Hi Todor,

On Mon, Jul 03, 2017 at 05:03:40PM +0300, Todor Tomov wrote:
> >> +  unsigned int i;
> >> +
> >> +  v4l2_of_parse_endpoint(node, );
> >> +
> >> +  csd->interface.csiphy_id = vep.base.port;
> >> +
> >> +  mipi_csi2 = _csi2;
> >> +  lncfg->clk.pos = mipi_csi2->clock_lane;
> >> +  lncfg->clk.pol = mipi_csi2->lane_polarities[0];
> >> +  lncfg->num_data = mipi_csi2->num_data_lanes;
> >> +
> >> +  lncfg->data = devm_kzalloc(dev, lncfg->num_data * sizeof(*lncfg->data),
> >> + GFP_KERNEL);
> >> +  if (!lncfg->data)
> >> +  return -ENOMEM;
> >> +
> >> +  for (i = 0; i < lncfg->num_data; i++) {
> >> +  lncfg->data[i].pos = mipi_csi2->data_lanes[i];
> >> +  lncfg->data[i].pol = mipi_csi2->lane_polarities[i + 1];
> >> +  }
> >> +
> >> +  of_property_read_u32(node, "qcom,settle-cnt", settle_cnt);
> > 
> > Isn't this something that depends on the CSI-2 bus speed, for instance?
> > Could you calculate it instead of putting it to DT?
> 
> Actually, after some digging into this, yes, I can calculate it. I can
> calculate the CSI-2 bus speed based on the sensor's output pixel clock
> and then calculate the settle time and this settle count value.
> So I already have the code to get the sensor's pixel clock using the
> standard v4l2 control V4L2_CID_PIXEL_RATE.

What we have currently in documentation on this is here:

https://www.linuxtv.org/downloads/v4l-dvb-apis/kapi/csi2.html>

I.e. both should be implemented. The link frequency is rather more relevant
for CSI-2 albeit you can derive one from the other in case of CSI-2. The
pixel rate documentation should probably be rather elsewhere.

> Now the question is what to do if the sensor driver doesn't support this
> control? Just return an error and refuse to work with this "limited"
> sensor driver?

If the sensor driver does not provide enough information to work with a
receiver, it's only fair not to proceed with streaming. That said, it might
be possible to manage with some sensible defaults in some cases but then again
you could have only some units working with this configuration. It'd be
much safer to require the information: not doing so hides the error and
makes it (more) difficult to debug.

...

> >> +struct camss {
> >> +  struct v4l2_device v4l2_dev;
> >> +  struct v4l2_async_notifier notifier;
> >> +  struct media_device media_dev;
> >> +  struct device *dev;
> >> +  struct csiphy_device csiphy[CAMSS_CSIPHY_NUM];
> >> +  struct csid_device csid[CAMSS_CSID_NUM];
> >> +  struct ispif_device ispif;
> >> +  struct vfe_device vfe;
> >> +  atomic_t ref_count;

If this is refcount, then you should use refcount_t instead.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

[Juergen Gross]

On 03/07/17 20:44, Igor Druzhinin wrote:
> On 03/07/17 16:40, Juergen Gross wrote:
>> When setting up the Xenstore watch for the memory target size the new
>> watch will fire at once. Don't try to reach the configured target size
>> by onlining new memory in this case, as the current memory size will
>> be smaller in almost all cases due to e.g. BIOS reserved pages.
>>
>> Onlining new memory will lead to more problems e.g. undesired conflicts
>> with NVMe devices meant to be operated as block devices.
>>
>> Instead remember the difference between target size and current size
>> when the watch fires for the first time and apply it to any further
>> size changes, too.
>>
>> In order to avoid races between balloon.c and xen-balloon.c init calls
>> do the xen-balloon.c initialization from balloon.c.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/xen/balloon.c |  3 +++
>>  drivers/xen/xen-balloon.c | 20 
>>  include/xen/balloon.h |  8 
>>  3 files changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>> index 50dcb68d8070..ab609255a0f3 100644
>> --- a/drivers/xen/balloon.c
>> +++ b/drivers/xen/balloon.c
>> @@ -780,6 +780,9 @@ static int __init balloon_init(void)
>>  }
>>  #endif
>>  
>> +/* Init the xen-balloon driver. */
>> +xen_balloon_init();
>> +
>>  return 0;
>>  }
>>  subsys_initcall(balloon_init);
>> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
>> index e7715cb62eef..66ec519c825c 100644
>> --- a/drivers/xen/xen-balloon.c
>> +++ b/drivers/xen/xen-balloon.c
>> @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch,
>>  {
>>  unsigned long long new_target;
>>  int err;
>> +static bool watch_fired;
>> +static unsigned long target_diff;
>>  
>>  err = xenbus_scanf(XBT_NIL, "memory", "target", "%llu", _target);
>>  if (err != 1) {
>> @@ -69,7 +71,14 @@ static void watch_target(struct xenbus_watch *watch,
>>  /* The given memory/target value is in KiB, so it needs converting to
>>   * pages. PAGE_SHIFT converts bytes to pages, hence PAGE_SHIFT - 10.
>>   */
>> -balloon_set_new_target(new_target >> (PAGE_SHIFT - 10));
>> +new_target >>= PAGE_SHIFT - 10;
>> +if (watch_fired) {
>> +balloon_set_new_target(new_target - target_diff);
>> +return;
>> +}
>> +
>> +watch_fired = true;
>> +target_diff = new_target - balloon_stats.target_pages;
>>  }
>>  static struct xenbus_watch target_watch = {
>>  .node = "memory/target",
>> @@ -94,13 +103,8 @@ static struct notifier_block xenstore_notifier = {
>>  .notifier_call = balloon_init_watcher,
>>  };
>>  
>> -static int __init balloon_init(void)
>> +void __init xen_balloon_init(void)
>>  {
>> -if (!xen_domain())
>> -return -ENODEV;
>> -
>> -pr_info("Initialising balloon driver\n");
>> -
>>  register_balloon(_dev);
>>  
>>  register_xen_selfballooning(_dev);
>> @@ -109,7 +113,7 @@ static int __init balloon_init(void)
>>  
>>  return 0;
>>  }
>> -subsys_initcall(balloon_init);
>> +EXPORT_SYMBOL_GPL(xen_balloon_init);
>>  
>>  #define BALLOON_SHOW(name, format, args...) \
>>  static ssize_t show_##name(struct device *dev,  \
>> diff --git a/include/xen/balloon.h b/include/xen/balloon.h
>> index d1767dfb0d95..8906361bb50c 100644
>> --- a/include/xen/balloon.h
>> +++ b/include/xen/balloon.h
>> @@ -35,3 +35,11 @@ static inline int register_xen_selfballooning(struct 
>> device *dev)
>>  return -ENOSYS;
>>  }
>>  #endif
>> +
>> +#ifdef CONFIG_XEN_BALLOON
>> +void xen_balloon_init(void);
>> +#else
>> +static inline void xen_balloon_init(void)
>> +{
>> +}
>> +#endif
>>
> 
> We came across the same issue just recently. The problem was that for
> some kernel versions DMA buffers for emulated devices are allocated in
> this recently hotplugged area. This area is not properly described for
> QEMU so when a DMA request comes in QEMU treats it as "unassigned" and
> skips by default. This eventually leads to cryptic failures of system
> loading.
> 
> Internally we developed a workaround for QEMU with which we try to
> satisfy all the "unassigned" requests. But it doesn't solves the problem
> in a proper way IMHO.
> 
> I haven't not completely understood your use-case but we might try come
> up with a general solution for both of the problems because they are
> obviously related.
> 
>> Onlining new memory will lead to more problems e.g. undesired conflicts
>> with NVMe devices meant to be operated as block devices.
> 
> Could you explain this in more detail?

Please see

https://lists.xen.org/archives/html/xen-devel/2017-03/msg03020.html

for a more detailed discussion.


Juergen

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

[Juergen Gross]

On 03/07/17 20:44, Igor Druzhinin wrote:
> On 03/07/17 16:40, Juergen Gross wrote:
>> When setting up the Xenstore watch for the memory target size the new
>> watch will fire at once. Don't try to reach the configured target size
>> by onlining new memory in this case, as the current memory size will
>> be smaller in almost all cases due to e.g. BIOS reserved pages.
>>
>> Onlining new memory will lead to more problems e.g. undesired conflicts
>> with NVMe devices meant to be operated as block devices.
>>
>> Instead remember the difference between target size and current size
>> when the watch fires for the first time and apply it to any further
>> size changes, too.
>>
>> In order to avoid races between balloon.c and xen-balloon.c init calls
>> do the xen-balloon.c initialization from balloon.c.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/xen/balloon.c |  3 +++
>>  drivers/xen/xen-balloon.c | 20 
>>  include/xen/balloon.h |  8 
>>  3 files changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>> index 50dcb68d8070..ab609255a0f3 100644
>> --- a/drivers/xen/balloon.c
>> +++ b/drivers/xen/balloon.c
>> @@ -780,6 +780,9 @@ static int __init balloon_init(void)
>>  }
>>  #endif
>>  
>> +/* Init the xen-balloon driver. */
>> +xen_balloon_init();
>> +
>>  return 0;
>>  }
>>  subsys_initcall(balloon_init);
>> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
>> index e7715cb62eef..66ec519c825c 100644
>> --- a/drivers/xen/xen-balloon.c
>> +++ b/drivers/xen/xen-balloon.c
>> @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch,
>>  {
>>  unsigned long long new_target;
>>  int err;
>> +static bool watch_fired;
>> +static unsigned long target_diff;
>>  
>>  err = xenbus_scanf(XBT_NIL, "memory", "target", "%llu", _target);
>>  if (err != 1) {
>> @@ -69,7 +71,14 @@ static void watch_target(struct xenbus_watch *watch,
>>  /* The given memory/target value is in KiB, so it needs converting to
>>   * pages. PAGE_SHIFT converts bytes to pages, hence PAGE_SHIFT - 10.
>>   */
>> -balloon_set_new_target(new_target >> (PAGE_SHIFT - 10));
>> +new_target >>= PAGE_SHIFT - 10;
>> +if (watch_fired) {
>> +balloon_set_new_target(new_target - target_diff);
>> +return;
>> +}
>> +
>> +watch_fired = true;
>> +target_diff = new_target - balloon_stats.target_pages;
>>  }
>>  static struct xenbus_watch target_watch = {
>>  .node = "memory/target",
>> @@ -94,13 +103,8 @@ static struct notifier_block xenstore_notifier = {
>>  .notifier_call = balloon_init_watcher,
>>  };
>>  
>> -static int __init balloon_init(void)
>> +void __init xen_balloon_init(void)
>>  {
>> -if (!xen_domain())
>> -return -ENODEV;
>> -
>> -pr_info("Initialising balloon driver\n");
>> -
>>  register_balloon(_dev);
>>  
>>  register_xen_selfballooning(_dev);
>> @@ -109,7 +113,7 @@ static int __init balloon_init(void)
>>  
>>  return 0;
>>  }
>> -subsys_initcall(balloon_init);
>> +EXPORT_SYMBOL_GPL(xen_balloon_init);
>>  
>>  #define BALLOON_SHOW(name, format, args...) \
>>  static ssize_t show_##name(struct device *dev,  \
>> diff --git a/include/xen/balloon.h b/include/xen/balloon.h
>> index d1767dfb0d95..8906361bb50c 100644
>> --- a/include/xen/balloon.h
>> +++ b/include/xen/balloon.h
>> @@ -35,3 +35,11 @@ static inline int register_xen_selfballooning(struct 
>> device *dev)
>>  return -ENOSYS;
>>  }
>>  #endif
>> +
>> +#ifdef CONFIG_XEN_BALLOON
>> +void xen_balloon_init(void);
>> +#else
>> +static inline void xen_balloon_init(void)
>> +{
>> +}
>> +#endif
>>
> 
> We came across the same issue just recently. The problem was that for
> some kernel versions DMA buffers for emulated devices are allocated in
> this recently hotplugged area. This area is not properly described for
> QEMU so when a DMA request comes in QEMU treats it as "unassigned" and
> skips by default. This eventually leads to cryptic failures of system
> loading.
> 
> Internally we developed a workaround for QEMU with which we try to
> satisfy all the "unassigned" requests. But it doesn't solves the problem
> in a proper way IMHO.
> 
> I haven't not completely understood your use-case but we might try come
> up with a general solution for both of the problems because they are
> obviously related.
> 
>> Onlining new memory will lead to more problems e.g. undesired conflicts
>> with NVMe devices meant to be operated as block devices.
> 
> Could you explain this in more detail?

Please see

https://lists.xen.org/archives/html/xen-devel/2017-03/msg03020.html

for a more detailed discussion.


Juergen

Re: 'skb' buffer address information leakage

[Jakub Kicinski]

On Tue, 4 Jul 2017 13:12:18 +0800, Dison River wrote:
> drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
>  seq_printf(file, " frag=%p", skb);

FWIW that's actually not a skb pointer.  The structure is defined like
this:

struct nfp_net_tx_buf {
union { 
struct sk_buff *skb;
void *frag;
};
dma_addr_t dma_addr;
short int fidx;
u16 pkt_cnt;
u32 real_len;
};

So the line in question is actually reading the frag pointer, I just
reused the skb variable, because this has to be read via READ_ONCE()
and NULL-checked so I thought that doing it separately for skb and
frag is a waste of LOC especially in debug code.  I will queue up a
clean up for after the merge window.

Thanks!

Re: 'skb' buffer address information leakage

[Jakub Kicinski]

On Tue, 4 Jul 2017 13:12:18 +0800, Dison River wrote:
> drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
>  seq_printf(file, " frag=%p", skb);

FWIW that's actually not a skb pointer.  The structure is defined like
this:

struct nfp_net_tx_buf {
union { 
struct sk_buff *skb;
void *frag;
};
dma_addr_t dma_addr;
short int fidx;
u16 pkt_cnt;
u32 real_len;
};

So the line in question is actually reading the frag pointer, I just
reused the skb variable, because this has to be read via READ_ONCE()
and NULL-checked so I thought that doing it separately for skb and
frag is a waste of LOC especially in debug code.  I will queue up a
clean up for after the merge window.

Thanks!

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

[Sergey Senozhatsky]

On (07/03/17 15:34), Steven Rostedt wrote:
> > +#define PRINTK_FLOOD_DEFAULT_DELAY 10
> > +
> >  int printk_delay_msec __read_mostly;
> >  
> > +static inline void __printk_delay(int m)
> > +{
> > +   while (m--) {
> > +   mdelay(1);
> > +   touch_nmi_watchdog();
> > +   }
> > +}
> > +
> >  static inline void printk_delay(void)
> >  {
> > -   if (unlikely(printk_delay_msec)) {
> > -   int m = printk_delay_msec;
> > +   unsigned long flags;
> > +   u64 console_seen = 0, console_to_see;
> >  
> > -   while (m--) {
> > -   mdelay(1);
> > -   touch_nmi_watchdog();
> > -   }
> > +   if (printk_delay_msec) {
> > +   __printk_delay(printk_delay_msec);
> > +   return;
> > +   }
> > +
> 
> This had better be an option, and not default.

yes.

> And what happens if the printk caller happens to preempt the one
> doing the writes to consoles?

in short - we just burn CPU cycles. that case is broken.

that's mostly the reason behind PRINTK_FLOOD_DEFAULT_DELAY being quite
small.

one can simply do

console_lock();
printk();
printk();

printk();
console_unlock();

and trigger a useless throttling. a needed one in general case,
but useless in the given circumstances.

not sure if we can properly throttle printk in all of the cases.
we know that console_sem is locked, but we don't know what for.
is CPU that owns the console_sem is now in console_unlock() or
somewhere in fbcon, or anywhere else. we probably need not to
throttle printk() if we know that console_sem is already locked
by this_cpu and we simply call printk either from IRQ that
preempted console_unlock() on this_cpu or recursive printk from
console_unlock()... and so on.

-ss

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

[Sergey Senozhatsky]

On (07/03/17 15:34), Steven Rostedt wrote:
> > +#define PRINTK_FLOOD_DEFAULT_DELAY 10
> > +
> >  int printk_delay_msec __read_mostly;
> >  
> > +static inline void __printk_delay(int m)
> > +{
> > +   while (m--) {
> > +   mdelay(1);
> > +   touch_nmi_watchdog();
> > +   }
> > +}
> > +
> >  static inline void printk_delay(void)
> >  {
> > -   if (unlikely(printk_delay_msec)) {
> > -   int m = printk_delay_msec;
> > +   unsigned long flags;
> > +   u64 console_seen = 0, console_to_see;
> >  
> > -   while (m--) {
> > -   mdelay(1);
> > -   touch_nmi_watchdog();
> > -   }
> > +   if (printk_delay_msec) {
> > +   __printk_delay(printk_delay_msec);
> > +   return;
> > +   }
> > +
> 
> This had better be an option, and not default.

yes.

> And what happens if the printk caller happens to preempt the one
> doing the writes to consoles?

in short - we just burn CPU cycles. that case is broken.

that's mostly the reason behind PRINTK_FLOOD_DEFAULT_DELAY being quite
small.

one can simply do

console_lock();
printk();
printk();

printk();
console_unlock();

and trigger a useless throttling. a needed one in general case,
but useless in the given circumstances.

not sure if we can properly throttle printk in all of the cases.
we know that console_sem is locked, but we don't know what for.
is CPU that owns the console_sem is now in console_unlock() or
somewhere in fbcon, or anywhere else. we probably need not to
throttle printk() if we know that console_sem is already locked
by this_cpu and we simply call printk either from IRQ that
preempted console_unlock() on this_cpu or recursive printk from
console_unlock()... and so on.

-ss

Re: [PATCH] media: vb2 dma-sg: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 14:18, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
5238112   4535414ea 
drivers/media/v4l2-core/videobuf2-dma-sg.o

File size After adding 'const':
text   data bss dec hex filename
5358  0   4536214f2 
drivers/media/v4l2-core/videobuf2-dma-sg.o

Signed-off-by: Arvind Yadav 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 8e8798a..f8b4643 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -500,7 +500,7 @@ static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_dma_sg_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {

+static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
.attach = vb2_dma_sg_dmabuf_ops_attach,
.detach = vb2_dma_sg_dmabuf_ops_detach,
.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] media: vb2 dma-sg: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 14:18, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
5238112   4535414ea 
drivers/media/v4l2-core/videobuf2-dma-sg.o

File size After adding 'const':
text   data bss dec hex filename
5358  0   4536214f2 
drivers/media/v4l2-core/videobuf2-dma-sg.o

Signed-off-by: Arvind Yadav 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 8e8798a..f8b4643 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -500,7 +500,7 @@ static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_dma_sg_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {

+static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
.attach = vb2_dma_sg_dmabuf_ops_attach,
.detach = vb2_dma_sg_dmabuf_ops_detach,
.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Joonsoo Kim]

On Mon, Jul 03, 2017 at 04:18:01PM +0200, Vlastimil Babka wrote:
> On 07/03/2017 01:48 PM, Vlastimil Babka wrote:
> > On 06/30/2017 04:18 PM, Michal Hocko wrote:
> >> fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") seem
> >> to silently depend on CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID resp.
> >> CONFIG_HAVE_MEMBLOCK_NODE_MAP. early_pfn_to_nid is returning zero with
> >> !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID) && 
> >> !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> >> I am not sure how widely is this used but such a code is tricky. I see
> >> how catching early allocations during defered initialization might be
> >> useful but a subtly broken code sounds like a problem to me.  So is
> >> fe53ca54270a worth this or we should revert it?
> > 
> > There might be more issues with fe53ca54270a, I think. This I've
> > observed on our 4.4-based kernel, which has deferred page struct init,
> > but doesn't have b8f1a75d61d8 ("mm: call page_ext_init() after all
> > struct pages are initialized") nor aforementioned fe53ca54270a:
> > 
> > [0.00] allocated 421003264 bytes of page_ext
> > [0.00] Node 0, zone  DMA: page owner found early allocated 0 
> > pages
> > [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> > pages
> > [0.00] Node 0, zone   Normal: page owner found early allocated 
> > 2842622 pages
> > [0.00] BUG: unable to handle kernel NULL pointer dereference at 
> >   (null)
> > [0.00] IP: [] init_page_owner+0x12a/0x240
> > [0.00] PGD 0 
> > [0.00] Oops:  [#1] SMP 
> > [0.00] Modules linked in:
> > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.74+ #7
> > [0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > 1.0.0-prebuilt.qemu-project.org 04/01/2014
> > [0.00] task: 81e104c0 ti: 81e0 task.ti: 
> > 81e0
> > [0.00] RIP: 0010:[]  [] 
> > init_page_owner+0x12a/0x240
> > [0.00] RSP: :81e03ed0  EFLAGS: 00010046
> > [0.00] RAX:  RBX: 88083ffe0210 RCX: 
> > ea001300
> > [0.00] RDX: 0300 RSI: 81f57437 RDI: 
> > 004c
> > [0.00] RBP: 81e03f20 R08: 81e03e90 R09: 
> > 
> > [0.00] R10: 004c0200 R11:  R12: 
> > ea00
> > [0.00] R13: 004c0200 R14: 004c R15: 
> > 0084
> > [0.00] FS:  () GS:88042fc0() 
> > knlGS:
> > [0.00] CS:  0010 DS:  ES:  CR0: 80050033
> > [0.00] CR2:  CR3: 01e0b000 CR4: 
> > 000406b0
> > [0.00] Stack:
> > [0.00]  0206 88083ffe0f90 88083ffdf000 
> > 3181
> > [0.00]  ea001300 0040 ea00 
> > 0084
> > [0.00]  0084 8e10 81e03f50 
> > 81f84145
> > [0.00] Call Trace:
> > [0.00]  [] page_ext_init+0x15e/0x167
> > [0.00]  [] start_kernel+0x351/0x418
> > [0.00]  [] ? early_idt_handler_array+0x120/0x120
> > [0.00]  [] x86_64_start_reservations+0x2a/0x2c
> > [0.00]  [] x86_64_start_kernel+0x12c/0x13b
> > [0.00] Code: 81 e2 00 fe ff ff 4d 39 fa 4d 0f 47 d7 4d 39 f2 4d 89 
> > d5 77 34 eb 5e 48 8b 01 f6 c4 04 75 21 48 89 cf 48 89 4d d0 e8 b6 35 00 00 
> > <48> 8b 00 a8 04 75 0e 48 8b 4d d0 e9 c2 00 00 00 48 83 45 c8 01 
> > [0.00] RIP  [] init_page_owner+0x12a/0x240
> > [0.00]  RSP 
> > [0.00] CR2: 
> > [0.00] ---[ end trace 19e05592f03a690f ]---
> > 
> > Note that this is different backtrace than in b8f1a75d61d8 log.
> > 
> > Still, backporting b8f1a75d61d8 fixes this:
> > 
> > [1.538379] allocated 738197504 bytes of page_ext
> > [1.539340] Node 0, zone  DMA: page owner found early allocated 0 
> > pages
> > [1.540179] Node 0, zoneDMA32: page owner found early allocated 33 
> > pages
> > [1.611173] Node 0, zone   Normal: page owner found early allocated 
> > 96755 pages
> > [1.683167] Node 1, zone   Normal: page owner found early allocated 
> > 96575 pages
> > 
> > No panic, notice how it allocated more for page_ext, and found smaller 
> > number of
> > early allocated pages.
> > 
> > Now backporting fe53ca54270a on top:
> > 
> > [0.00] allocated 738197504 bytes of page_ext
> > [0.00] Node 0, zone  DMA: page owner found early allocated 0 
> > pages
> > [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> > pages
> > [0.00] Node 0, zone   Normal: page owner found early allocated 
> > 2842622 pages
> > [0.00] Node 1, zone   Normal: page owner found early allocated 
> > 3694362 pages
> > 
> > Again no panic, and same amount of page_ext usage. But the "early 
> 

Re: [PATCH] media: vb2 vmalloc: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 13:37, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
3171192   03363 d23 
drivers/media/v4l2-core/videobuf2-vmalloc.o

File size After adding 'const':
text   data bss dec hex filename
3291 80   03371 d2b 
drivers/media/v4l2-core/videobuf2-vmalloc.o

Signed-off-by: Arvind Yadav 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-vmalloc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index b337d78..6bc130f 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -338,7 +338,7 @@ static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_vmalloc_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {

+static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
.attach = vb2_vmalloc_dmabuf_ops_attach,
.detach = vb2_vmalloc_dmabuf_ops_detach,
.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Joonsoo Kim]

On Mon, Jul 03, 2017 at 04:18:01PM +0200, Vlastimil Babka wrote:
> On 07/03/2017 01:48 PM, Vlastimil Babka wrote:
> > On 06/30/2017 04:18 PM, Michal Hocko wrote:
> >> fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") seem
> >> to silently depend on CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID resp.
> >> CONFIG_HAVE_MEMBLOCK_NODE_MAP. early_pfn_to_nid is returning zero with
> >> !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID) && 
> >> !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> >> I am not sure how widely is this used but such a code is tricky. I see
> >> how catching early allocations during defered initialization might be
> >> useful but a subtly broken code sounds like a problem to me.  So is
> >> fe53ca54270a worth this or we should revert it?
> > 
> > There might be more issues with fe53ca54270a, I think. This I've
> > observed on our 4.4-based kernel, which has deferred page struct init,
> > but doesn't have b8f1a75d61d8 ("mm: call page_ext_init() after all
> > struct pages are initialized") nor aforementioned fe53ca54270a:
> > 
> > [0.00] allocated 421003264 bytes of page_ext
> > [0.00] Node 0, zone  DMA: page owner found early allocated 0 
> > pages
> > [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> > pages
> > [0.00] Node 0, zone   Normal: page owner found early allocated 
> > 2842622 pages
> > [0.00] BUG: unable to handle kernel NULL pointer dereference at 
> >   (null)
> > [0.00] IP: [] init_page_owner+0x12a/0x240
> > [0.00] PGD 0 
> > [0.00] Oops:  [#1] SMP 
> > [0.00] Modules linked in:
> > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.74+ #7
> > [0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > 1.0.0-prebuilt.qemu-project.org 04/01/2014
> > [0.00] task: 81e104c0 ti: 81e0 task.ti: 
> > 81e0
> > [0.00] RIP: 0010:[]  [] 
> > init_page_owner+0x12a/0x240
> > [0.00] RSP: :81e03ed0  EFLAGS: 00010046
> > [0.00] RAX:  RBX: 88083ffe0210 RCX: 
> > ea001300
> > [0.00] RDX: 0300 RSI: 81f57437 RDI: 
> > 004c
> > [0.00] RBP: 81e03f20 R08: 81e03e90 R09: 
> > 
> > [0.00] R10: 004c0200 R11:  R12: 
> > ea00
> > [0.00] R13: 004c0200 R14: 004c R15: 
> > 0084
> > [0.00] FS:  () GS:88042fc0() 
> > knlGS:
> > [0.00] CS:  0010 DS:  ES:  CR0: 80050033
> > [0.00] CR2:  CR3: 01e0b000 CR4: 
> > 000406b0
> > [0.00] Stack:
> > [0.00]  0206 88083ffe0f90 88083ffdf000 
> > 3181
> > [0.00]  ea001300 0040 ea00 
> > 0084
> > [0.00]  0084 8e10 81e03f50 
> > 81f84145
> > [0.00] Call Trace:
> > [0.00]  [] page_ext_init+0x15e/0x167
> > [0.00]  [] start_kernel+0x351/0x418
> > [0.00]  [] ? early_idt_handler_array+0x120/0x120
> > [0.00]  [] x86_64_start_reservations+0x2a/0x2c
> > [0.00]  [] x86_64_start_kernel+0x12c/0x13b
> > [0.00] Code: 81 e2 00 fe ff ff 4d 39 fa 4d 0f 47 d7 4d 39 f2 4d 89 
> > d5 77 34 eb 5e 48 8b 01 f6 c4 04 75 21 48 89 cf 48 89 4d d0 e8 b6 35 00 00 
> > <48> 8b 00 a8 04 75 0e 48 8b 4d d0 e9 c2 00 00 00 48 83 45 c8 01 
> > [0.00] RIP  [] init_page_owner+0x12a/0x240
> > [0.00]  RSP 
> > [0.00] CR2: 
> > [0.00] ---[ end trace 19e05592f03a690f ]---
> > 
> > Note that this is different backtrace than in b8f1a75d61d8 log.
> > 
> > Still, backporting b8f1a75d61d8 fixes this:
> > 
> > [1.538379] allocated 738197504 bytes of page_ext
> > [1.539340] Node 0, zone  DMA: page owner found early allocated 0 
> > pages
> > [1.540179] Node 0, zoneDMA32: page owner found early allocated 33 
> > pages
> > [1.611173] Node 0, zone   Normal: page owner found early allocated 
> > 96755 pages
> > [1.683167] Node 1, zone   Normal: page owner found early allocated 
> > 96575 pages
> > 
> > No panic, notice how it allocated more for page_ext, and found smaller 
> > number of
> > early allocated pages.
> > 
> > Now backporting fe53ca54270a on top:
> > 
> > [0.00] allocated 738197504 bytes of page_ext
> > [0.00] Node 0, zone  DMA: page owner found early allocated 0 
> > pages
> > [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> > pages
> > [0.00] Node 0, zone   Normal: page owner found early allocated 
> > 2842622 pages
> > [0.00] Node 1, zone   Normal: page owner found early allocated 
> > 3694362 pages
> > 
> > Again no panic, and same amount of page_ext usage. But the "early 
> 

Re: [PATCH] media: vb2 vmalloc: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 13:37, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
3171192   03363 d23 
drivers/media/v4l2-core/videobuf2-vmalloc.o

File size After adding 'const':
text   data bss dec hex filename
3291 80   03371 d2b 
drivers/media/v4l2-core/videobuf2-vmalloc.o

Signed-off-by: Arvind Yadav 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-vmalloc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index b337d78..6bc130f 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -338,7 +338,7 @@ static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_vmalloc_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {

+static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
.attach = vb2_vmalloc_dmabuf_ops_attach,
.detach = vb2_vmalloc_dmabuf_ops_detach,
.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] media: vb2 dma-contig: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 13:27, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
6035272   0630718a3 
drivers/media/v4l2-core/videobuf2-dma-contig.o

File size After adding 'const':
text   data bss dec hex filename
6155160   0631518ab 
drivers/media/v4l2-core/videobuf2-dma-contig.o

Signed-off-by: Arvind Yadav 


Thanks!
Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 4f246d1..5b90a66 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -352,7 +352,7 @@ static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_dc_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_dc_dmabuf_ops = {

+static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
.attach = vb2_dc_dmabuf_ops_attach,
.detach = vb2_dc_dmabuf_ops_detach,
.map_dma_buf = vb2_dc_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] media: vb2 dma-contig: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 13:27, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
6035272   0630718a3 
drivers/media/v4l2-core/videobuf2-dma-contig.o

File size After adding 'const':
text   data bss dec hex filename
6155160   0631518ab 
drivers/media/v4l2-core/videobuf2-dma-contig.o

Signed-off-by: Arvind Yadav 


Thanks!
Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 4f246d1..5b90a66 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -352,7 +352,7 @@ static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_dc_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_dc_dmabuf_ops = {

+static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
.attach = vb2_dc_dmabuf_ops_attach,
.detach = vb2_dc_dmabuf_ops_detach,
.map_dma_buf = vb2_dc_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Joonsoo Kim]

On Mon, Jul 03, 2017 at 01:48:05PM +0200, Vlastimil Babka wrote:
> On 06/30/2017 04:18 PM, Michal Hocko wrote:
> > fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") seem
> > to silently depend on CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID resp.
> > CONFIG_HAVE_MEMBLOCK_NODE_MAP. early_pfn_to_nid is returning zero with
> > !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID) && 
> > !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> > I am not sure how widely is this used but such a code is tricky. I see
> > how catching early allocations during defered initialization might be
> > useful but a subtly broken code sounds like a problem to me.  So is
> > fe53ca54270a worth this or we should revert it?
> 
> There might be more issues with fe53ca54270a, I think. This I've
> observed on our 4.4-based kernel, which has deferred page struct init,
> but doesn't have b8f1a75d61d8 ("mm: call page_ext_init() after all
> struct pages are initialized") nor aforementioned fe53ca54270a:
> 
> [0.00] allocated 421003264 bytes of page_ext
> [0.00] Node 0, zone  DMA: page owner found early allocated 0 pages
> [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> pages
> [0.00] Node 0, zone   Normal: page owner found early allocated 
> 2842622 pages
> [0.00] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [0.00] IP: [] init_page_owner+0x12a/0x240
> [0.00] PGD 0 
> [0.00] Oops:  [#1] SMP 
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.74+ #7
> [0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.0.0-prebuilt.qemu-project.org 04/01/2014
> [0.00] task: 81e104c0 ti: 81e0 task.ti: 
> 81e0
> [0.00] RIP: 0010:[]  [] 
> init_page_owner+0x12a/0x240
> [0.00] RSP: :81e03ed0  EFLAGS: 00010046
> [0.00] RAX:  RBX: 88083ffe0210 RCX: 
> ea001300
> [0.00] RDX: 0300 RSI: 81f57437 RDI: 
> 004c
> [0.00] RBP: 81e03f20 R08: 81e03e90 R09: 
> 
> [0.00] R10: 004c0200 R11:  R12: 
> ea00
> [0.00] R13: 004c0200 R14: 004c R15: 
> 0084
> [0.00] FS:  () GS:88042fc0() 
> knlGS:
> [0.00] CS:  0010 DS:  ES:  CR0: 80050033
> [0.00] CR2:  CR3: 01e0b000 CR4: 
> 000406b0
> [0.00] Stack:
> [0.00]  0206 88083ffe0f90 88083ffdf000 
> 3181
> [0.00]  ea001300 0040 ea00 
> 0084
> [0.00]  0084 8e10 81e03f50 
> 81f84145
> [0.00] Call Trace:
> [0.00]  [] page_ext_init+0x15e/0x167
> [0.00]  [] start_kernel+0x351/0x418
> [0.00]  [] ? early_idt_handler_array+0x120/0x120
> [0.00]  [] x86_64_start_reservations+0x2a/0x2c
> [0.00]  [] x86_64_start_kernel+0x12c/0x13b
> [0.00] Code: 81 e2 00 fe ff ff 4d 39 fa 4d 0f 47 d7 4d 39 f2 4d 89 d5 
> 77 34 eb 5e 48 8b 01 f6 c4 04 75 21 48 89 cf 48 89 4d d0 e8 b6 35 00 00 <48> 
> 8b 00 a8 04 75 0e 48 8b 4d d0 e9 c2 00 00 00 48 83 45 c8 01 
> [0.00] RIP  [] init_page_owner+0x12a/0x240
> [0.00]  RSP 
> [0.00] CR2: 
> [0.00] ---[ end trace 19e05592f03a690f ]---
> 
> Note that this is different backtrace than in b8f1a75d61d8 log.
> 
> Still, backporting b8f1a75d61d8 fixes this:
> 
> [1.538379] allocated 738197504 bytes of page_ext
> [1.539340] Node 0, zone  DMA: page owner found early allocated 0 pages
> [1.540179] Node 0, zoneDMA32: page owner found early allocated 33 
> pages
> [1.611173] Node 0, zone   Normal: page owner found early allocated 96755 
> pages
> [1.683167] Node 1, zone   Normal: page owner found early allocated 96575 
> pages
> 
> No panic, notice how it allocated more for page_ext, and found smaller number 
> of
> early allocated pages.
> 
> Now backporting fe53ca54270a on top:
> 
> [0.00] allocated 738197504 bytes of page_ext
> [0.00] Node 0, zone  DMA: page owner found early allocated 0 pages
> [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> pages
> [0.00] Node 0, zone   Normal: page owner found early allocated 
> 2842622 pages
> [0.00] Node 1, zone   Normal: page owner found early allocated 
> 3694362 pages
> 
> Again no panic, and same amount of page_ext usage. But the "early allocated" 
> numbers
> seem bogus to me. I think it's because init_pages_in_zone() is running and 
> inspecting
> struct pages that have not been yet initialized. It doesn't end up crashing, 
> but
> still doesn't seem correct?

Numbers looks sane to me. 

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Joonsoo Kim]

On Mon, Jul 03, 2017 at 01:48:05PM +0200, Vlastimil Babka wrote:
> On 06/30/2017 04:18 PM, Michal Hocko wrote:
> > fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") seem
> > to silently depend on CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID resp.
> > CONFIG_HAVE_MEMBLOCK_NODE_MAP. early_pfn_to_nid is returning zero with
> > !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID) && 
> > !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> > I am not sure how widely is this used but such a code is tricky. I see
> > how catching early allocations during defered initialization might be
> > useful but a subtly broken code sounds like a problem to me.  So is
> > fe53ca54270a worth this or we should revert it?
> 
> There might be more issues with fe53ca54270a, I think. This I've
> observed on our 4.4-based kernel, which has deferred page struct init,
> but doesn't have b8f1a75d61d8 ("mm: call page_ext_init() after all
> struct pages are initialized") nor aforementioned fe53ca54270a:
> 
> [0.00] allocated 421003264 bytes of page_ext
> [0.00] Node 0, zone  DMA: page owner found early allocated 0 pages
> [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> pages
> [0.00] Node 0, zone   Normal: page owner found early allocated 
> 2842622 pages
> [0.00] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [0.00] IP: [] init_page_owner+0x12a/0x240
> [0.00] PGD 0 
> [0.00] Oops:  [#1] SMP 
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.74+ #7
> [0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.0.0-prebuilt.qemu-project.org 04/01/2014
> [0.00] task: 81e104c0 ti: 81e0 task.ti: 
> 81e0
> [0.00] RIP: 0010:[]  [] 
> init_page_owner+0x12a/0x240
> [0.00] RSP: :81e03ed0  EFLAGS: 00010046
> [0.00] RAX:  RBX: 88083ffe0210 RCX: 
> ea001300
> [0.00] RDX: 0300 RSI: 81f57437 RDI: 
> 004c
> [0.00] RBP: 81e03f20 R08: 81e03e90 R09: 
> 
> [0.00] R10: 004c0200 R11:  R12: 
> ea00
> [0.00] R13: 004c0200 R14: 004c R15: 
> 0084
> [0.00] FS:  () GS:88042fc0() 
> knlGS:
> [0.00] CS:  0010 DS:  ES:  CR0: 80050033
> [0.00] CR2:  CR3: 01e0b000 CR4: 
> 000406b0
> [0.00] Stack:
> [0.00]  0206 88083ffe0f90 88083ffdf000 
> 3181
> [0.00]  ea001300 0040 ea00 
> 0084
> [0.00]  0084 8e10 81e03f50 
> 81f84145
> [0.00] Call Trace:
> [0.00]  [] page_ext_init+0x15e/0x167
> [0.00]  [] start_kernel+0x351/0x418
> [0.00]  [] ? early_idt_handler_array+0x120/0x120
> [0.00]  [] x86_64_start_reservations+0x2a/0x2c
> [0.00]  [] x86_64_start_kernel+0x12c/0x13b
> [0.00] Code: 81 e2 00 fe ff ff 4d 39 fa 4d 0f 47 d7 4d 39 f2 4d 89 d5 
> 77 34 eb 5e 48 8b 01 f6 c4 04 75 21 48 89 cf 48 89 4d d0 e8 b6 35 00 00 <48> 
> 8b 00 a8 04 75 0e 48 8b 4d d0 e9 c2 00 00 00 48 83 45 c8 01 
> [0.00] RIP  [] init_page_owner+0x12a/0x240
> [0.00]  RSP 
> [0.00] CR2: 
> [0.00] ---[ end trace 19e05592f03a690f ]---
> 
> Note that this is different backtrace than in b8f1a75d61d8 log.
> 
> Still, backporting b8f1a75d61d8 fixes this:
> 
> [1.538379] allocated 738197504 bytes of page_ext
> [1.539340] Node 0, zone  DMA: page owner found early allocated 0 pages
> [1.540179] Node 0, zoneDMA32: page owner found early allocated 33 
> pages
> [1.611173] Node 0, zone   Normal: page owner found early allocated 96755 
> pages
> [1.683167] Node 1, zone   Normal: page owner found early allocated 96575 
> pages
> 
> No panic, notice how it allocated more for page_ext, and found smaller number 
> of
> early allocated pages.
> 
> Now backporting fe53ca54270a on top:
> 
> [0.00] allocated 738197504 bytes of page_ext
> [0.00] Node 0, zone  DMA: page owner found early allocated 0 pages
> [0.00] Node 0, zoneDMA32: page owner found early allocated 33 
> pages
> [0.00] Node 0, zone   Normal: page owner found early allocated 
> 2842622 pages
> [0.00] Node 1, zone   Normal: page owner found early allocated 
> 3694362 pages
> 
> Again no panic, and same amount of page_ext usage. But the "early allocated" 
> numbers
> seem bogus to me. I think it's because init_pages_in_zone() is running and 
> inspecting
> struct pages that have not been yet initialized. It doesn't end up crashing, 
> but
> still doesn't seem correct?

Numbers looks sane to me. 

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Joonsoo Kim]

On Fri, Jun 30, 2017 at 05:44:16PM +0200, Michal Hocko wrote:
> On Fri 30-06-17 17:42:24, Michal Hocko wrote:
> [...]
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 16532fa0bb64..894697c1e6f5 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -1055,6 +1055,7 @@ static inline struct zoneref 
> > *first_zones_zonelist(struct zonelist *zonelist,
> > !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> >  static inline unsigned long early_pfn_to_nid(unsigned long pfn)
> >  {
> > +   BUILD_BUG_ON(!IS_ENABLED(CONFIG_NUMA));
> 
> Err, this should read BUILD_BUG_ON(IS_ENABLED(CONFIG_NUMA)) of course

Agreed.

However, AFAIK, ARM can set CONFIG_NUMA but it doesn't have
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID and CONFIG_HAVE_MEMBLOCK_NODE_MAP.

If page_ext uses early_pfn_to_nid(), it will cause build error in ARM.

Therefore, I suggest following change.
CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on proper early_pfn_to_nid().
So, following code will always work as long as
CONFIG_DEFERRED_STRUCT_PAGE_INIT works.

Thanks.

--->8---
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 88ccc044..e3db259 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -384,6 +384,7 @@ void __init page_ext_init(void)
 
for_each_node_state(nid, N_MEMORY) {
unsigned long start_pfn, end_pfn;
+   int page_nid;
 
start_pfn = node_start_pfn(nid);
end_pfn = node_end_pfn(nid);
@@ -405,8 +406,15 @@ void __init page_ext_init(void)
 *
 * Take into account DEFERRED_STRUCT_PAGE_INIT.
 */
-   if (early_pfn_to_nid(pfn) != nid)
+#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
+   page_nid = early_pfn_to_nid(pfn);
+#else
+   page_nid = pfn_to_nid(pfn);
+#endif
+
+   if (page_nid != nid)
continue;
+
if (init_section_page_ext(pfn, nid))
goto oom;
}

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Joonsoo Kim]

On Fri, Jun 30, 2017 at 05:44:16PM +0200, Michal Hocko wrote:
> On Fri 30-06-17 17:42:24, Michal Hocko wrote:
> [...]
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 16532fa0bb64..894697c1e6f5 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -1055,6 +1055,7 @@ static inline struct zoneref 
> > *first_zones_zonelist(struct zonelist *zonelist,
> > !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> >  static inline unsigned long early_pfn_to_nid(unsigned long pfn)
> >  {
> > +   BUILD_BUG_ON(!IS_ENABLED(CONFIG_NUMA));
> 
> Err, this should read BUILD_BUG_ON(IS_ENABLED(CONFIG_NUMA)) of course

Agreed.

However, AFAIK, ARM can set CONFIG_NUMA but it doesn't have
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID and CONFIG_HAVE_MEMBLOCK_NODE_MAP.

If page_ext uses early_pfn_to_nid(), it will cause build error in ARM.

Therefore, I suggest following change.
CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on proper early_pfn_to_nid().
So, following code will always work as long as
CONFIG_DEFERRED_STRUCT_PAGE_INIT works.

Thanks.

--->8---
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 88ccc044..e3db259 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -384,6 +384,7 @@ void __init page_ext_init(void)
 
for_each_node_state(nid, N_MEMORY) {
unsigned long start_pfn, end_pfn;
+   int page_nid;
 
start_pfn = node_start_pfn(nid);
end_pfn = node_end_pfn(nid);
@@ -405,8 +406,15 @@ void __init page_ext_init(void)
 *
 * Take into account DEFERRED_STRUCT_PAGE_INIT.
 */
-   if (early_pfn_to_nid(pfn) != nid)
+#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
+   page_nid = early_pfn_to_nid(pfn);
+#else
+   page_nid = pfn_to_nid(pfn);
+#endif
+
+   if (page_nid != nid)
continue;
+
if (init_section_page_ext(pfn, nid))
goto oom;
}

'skb' buffer address information leakage

[Dison River]

Hi all:
I'd found several address leaks of "skb" buffer.When i have a
arbitrary address write vulnerability in kernel(enabled kASLR),I can
use skb's address find sk_destruct's address and overwrite it. And
then,invoke close(sock_fd) function can trigger the
shellcode(sk_destruct func).

In kernel 4.12-rc7
drivers/net/irda/vlsi_ir.c:326   seq_printf(seq, "skb=%p
data=%p hw=%p\n", rd->skb, rd->buf, rd->hw);
drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
 seq_printf(file, " frag=%p", skb);
drivers/net/wireless/ath/wil6210/debugfs.c:926   seq_printf(s,
"  SKB = 0x%p\n", skb);

Thanks.

'skb' buffer address information leakage

[Dison River]

Hi all:
I'd found several address leaks of "skb" buffer.When i have a
arbitrary address write vulnerability in kernel(enabled kASLR),I can
use skb's address find sk_destruct's address and overwrite it. And
then,invoke close(sock_fd) function can trigger the
shellcode(sk_destruct func).

In kernel 4.12-rc7
drivers/net/irda/vlsi_ir.c:326   seq_printf(seq, "skb=%p
data=%p hw=%p\n", rd->skb, rd->buf, rd->hw);
drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c:167
 seq_printf(file, " frag=%p", skb);
drivers/net/wireless/ath/wil6210/debugfs.c:926   seq_printf(s,
"  SKB = 0x%p\n", skb);

Thanks.

Re: [GIT PULL] Char/Misc driver patches for 4.13-rc1

[Linus Torvalds]

On Mon, Jul 3, 2017 at 8:00 AM, Greg KH  wrote:
>
> Peter Rosin (11):
>   mux: minimal mux subsystem

Hmm. The MULTIPLEXER question in the Kconfig strikes me as confusing
and of dubious value.

Can we please get rid of questions that people have basically an
impossible time answering, and instead have the drivers that want to
use CONFIG_MULTIPLEXER just add a "select" statement.

In fact it looks like we actually *have* the select statements, but
then we still ask the user about something they can't answer?

Most people will not have any kind of idea that whatever other driver
they are using wants to use the mux-core functionality..

  Linus

Re: [GIT PULL] Char/Misc driver patches for 4.13-rc1

[Linus Torvalds]

On Mon, Jul 3, 2017 at 8:00 AM, Greg KH  wrote:
>
> Peter Rosin (11):
>   mux: minimal mux subsystem

Hmm. The MULTIPLEXER question in the Kconfig strikes me as confusing
and of dubious value.

Can we please get rid of questions that people have basically an
impossible time answering, and instead have the drivers that want to
use CONFIG_MULTIPLEXER just add a "select" statement.

In fact it looks like we actually *have* the select statements, but
then we still ask the user about something they can't answer?

Most people will not have any kind of idea that whatever other driver
they are using wants to use the mux-core functionality..

  Linus

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

[gengdongjiu]

Hi Christoffer,
  thanks for the review.


On 2017/7/3 16:39, Christoffer Dall wrote:
> Hi Dongjiu,
> 
> On Mon, Jun 26, 2017 at 08:46:39PM +0800, Dongjiu Geng wrote:
>> when SError happen, kvm notifies user space to record the CPER,
>> user space specifies and passes the contents of ESR_EL1 on taking
>> a virtual SError interrupt to KVM, KVM enables virtual system
>> error or asynchronous abort with this specifies syndrome. This
>> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
>> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
>> HCR_EL2.VSE injects an SError. This register is added by the
>> RAS Extensions.
> 
> This commit message is confusing and doesn't help me understand the
> patch.
(1) what is the rationale for the guest OS SError interrupt(SEI) handling in 
the RAS solution?
  you can refer to document: "RAS_Extension_PRD03-PRDC-010953-32-0, 6.5.3 
Example software sequences"
  a). In the firmware-first RAS solution, when guest OS happen a SError 
interrupt (SEI), it will firstly trap to EL3(SCR_EL3.EA = 1);
  b). The firmware logs, triages, and delegates the error exception to the 
hypervisor. As the error came from guest OS  EL1, firmware
  does by faking an SError interrupt exception entry to EL2.
  c). Control transfers to the hypervisor's delegated error recovery 
agent.Because HCR_EL2.AMO is set to 1, the hypervisor can use a
  Virtual SError interrupt to delegate an asynchronous abort to EL1, by 
setting HCR_EL2.VSE to 1 and using VESR_EL2 to pass syndrome.

(2) what is this patch mainly do?
  As mentioned above, the hypervisor needs to enable virtual SError and pass 
the virtual syndrome to the guest OS.

  a). when Control transfers to the hypervisor from firmware by faking an 
SError interrupt, the hypervisor delivered the syndrome_info(esr_el2) and
  host VA address( Qemu translate this VA address to the virtual machine 
physical address(IPA)) using below new added "serror_intr" struct.
/* KVM_EXIT_SERROR_INTR */
struct {
__u32 syndrome_info;
__u64 address;
} serror_intr;

  b). Qemu gets the address(host VA) delivered by KVM, translate this host VA 
address to virtual machine physical address(IPA), and runtime record this 
virtual
 machine physical address(IPA) to the guest OS's APEI table.

  c). Qemu gets the syndrome_info delivered by KVM, it refers to this syndrome 
value(but can be different from it) to specify the virtual SError interrupt's 
syndrome through setting VESR_EL2.

the vsesr_el2 is armv8.2 register, its explanation can be found in 
"RAS_Extension_PRD03-PRDC-010953-33-0, 5.6.18 VSESR_EL2, Virtual SError 
Exception Syndrome Register"

>>The VSESR_EL2 characteristics are:
>>Purpose:
>>Provides the syndrome value reported to software on taking a virtual 
SError interrupt exception:
>>  — If the virtual SError interrupt is taken to EL1 using AArch64 
then VSESR_EL2 provides the
>>syndrome value reported in ESR_EL1.
>>  — If the virtual SError interrupt is taken to EL1 using AArch32 
then VSESR_EL2 provides the
>>syndrome values reported in DFSR.{AET, ExT} and the remainder 
of the DFSR is set as
>>   defined by VMSAv8-32.

 so in the KVM, I added a new IOCTL(#define KVM_ARM_SEI  _IO(KVMIO,  0xb8)) 
to pass the virtual SError syndrome value specified by Qemu and enable a 
virtual System Error.


 d). when world switch to guest OS, guest OS will happen virtual SError(this 
virtual SError can not be route to EL3 firmware), guest OS uses the specified 
syndrome value to do the recovery and
 parses the guest OS CPER which is dynamically recorded by the Qemu in the 
APEI table .



> 
> I think this patch is trying to do too many things.  I suggest you split
> the patch into (at least) one patch that captures exception information
> from the world-switch path, one patch that deals with the new exit
> reason, and finally a patch with the new ioctl.  That way you can write
> a commit message for each patch describing first what the patch does,
> and then why this is a good idea.
  Ok, thanks for the good suggestion.

> 
> Neverthess, I added some random comments below.
> 
>>
>> Changes since v3:
>> (1) Move restore VSESR_EL2 value logic to a helper method
>> (2) In the world-switch, not save VSESR_EL2, because no one cares the
>> old VSESR_EL2 value
>> (3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
>> a virtual system error
>>
>> Signed-off-by: Dongjiu Geng 
>> Signed-off-by: Quanming Wu 
>> ---
>>  Documentation/virtual/kvm/api.txt| 10 ++
>>  arch/arm/include/asm/kvm_host.h  |  1 +
>>  arch/arm/kvm/arm.c   |  7 +++
>>  arch/arm/kvm/guest.c |  5 +
>>  arch/arm64/include/asm/esr.h |  2 ++
>>  

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

[gengdongjiu]

Hi Christoffer,
  thanks for the review.


On 2017/7/3 16:39, Christoffer Dall wrote:
> Hi Dongjiu,
> 
> On Mon, Jun 26, 2017 at 08:46:39PM +0800, Dongjiu Geng wrote:
>> when SError happen, kvm notifies user space to record the CPER,
>> user space specifies and passes the contents of ESR_EL1 on taking
>> a virtual SError interrupt to KVM, KVM enables virtual system
>> error or asynchronous abort with this specifies syndrome. This
>> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
>> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
>> HCR_EL2.VSE injects an SError. This register is added by the
>> RAS Extensions.
> 
> This commit message is confusing and doesn't help me understand the
> patch.
(1) what is the rationale for the guest OS SError interrupt(SEI) handling in 
the RAS solution?
  you can refer to document: "RAS_Extension_PRD03-PRDC-010953-32-0, 6.5.3 
Example software sequences"
  a). In the firmware-first RAS solution, when guest OS happen a SError 
interrupt (SEI), it will firstly trap to EL3(SCR_EL3.EA = 1);
  b). The firmware logs, triages, and delegates the error exception to the 
hypervisor. As the error came from guest OS  EL1, firmware
  does by faking an SError interrupt exception entry to EL2.
  c). Control transfers to the hypervisor's delegated error recovery 
agent.Because HCR_EL2.AMO is set to 1, the hypervisor can use a
  Virtual SError interrupt to delegate an asynchronous abort to EL1, by 
setting HCR_EL2.VSE to 1 and using VESR_EL2 to pass syndrome.

(2) what is this patch mainly do?
  As mentioned above, the hypervisor needs to enable virtual SError and pass 
the virtual syndrome to the guest OS.

  a). when Control transfers to the hypervisor from firmware by faking an 
SError interrupt, the hypervisor delivered the syndrome_info(esr_el2) and
  host VA address( Qemu translate this VA address to the virtual machine 
physical address(IPA)) using below new added "serror_intr" struct.
/* KVM_EXIT_SERROR_INTR */
struct {
__u32 syndrome_info;
__u64 address;
} serror_intr;

  b). Qemu gets the address(host VA) delivered by KVM, translate this host VA 
address to virtual machine physical address(IPA), and runtime record this 
virtual
 machine physical address(IPA) to the guest OS's APEI table.

  c). Qemu gets the syndrome_info delivered by KVM, it refers to this syndrome 
value(but can be different from it) to specify the virtual SError interrupt's 
syndrome through setting VESR_EL2.

the vsesr_el2 is armv8.2 register, its explanation can be found in 
"RAS_Extension_PRD03-PRDC-010953-33-0, 5.6.18 VSESR_EL2, Virtual SError 
Exception Syndrome Register"

>>The VSESR_EL2 characteristics are:
>>Purpose:
>>Provides the syndrome value reported to software on taking a virtual 
SError interrupt exception:
>>  — If the virtual SError interrupt is taken to EL1 using AArch64 
then VSESR_EL2 provides the
>>syndrome value reported in ESR_EL1.
>>  — If the virtual SError interrupt is taken to EL1 using AArch32 
then VSESR_EL2 provides the
>>syndrome values reported in DFSR.{AET, ExT} and the remainder 
of the DFSR is set as
>>   defined by VMSAv8-32.

 so in the KVM, I added a new IOCTL(#define KVM_ARM_SEI  _IO(KVMIO,  0xb8)) 
to pass the virtual SError syndrome value specified by Qemu and enable a 
virtual System Error.


 d). when world switch to guest OS, guest OS will happen virtual SError(this 
virtual SError can not be route to EL3 firmware), guest OS uses the specified 
syndrome value to do the recovery and
 parses the guest OS CPER which is dynamically recorded by the Qemu in the 
APEI table .



> 
> I think this patch is trying to do too many things.  I suggest you split
> the patch into (at least) one patch that captures exception information
> from the world-switch path, one patch that deals with the new exit
> reason, and finally a patch with the new ioctl.  That way you can write
> a commit message for each patch describing first what the patch does,
> and then why this is a good idea.
  Ok, thanks for the good suggestion.

> 
> Neverthess, I added some random comments below.
> 
>>
>> Changes since v3:
>> (1) Move restore VSESR_EL2 value logic to a helper method
>> (2) In the world-switch, not save VSESR_EL2, because no one cares the
>> old VSESR_EL2 value
>> (3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
>> a virtual system error
>>
>> Signed-off-by: Dongjiu Geng 
>> Signed-off-by: Quanming Wu 
>> ---
>>  Documentation/virtual/kvm/api.txt| 10 ++
>>  arch/arm/include/asm/kvm_host.h  |  1 +
>>  arch/arm/kvm/arm.c   |  7 +++
>>  arch/arm/kvm/guest.c |  5 +
>>  arch/arm64/include/asm/esr.h |  2 ++
>>  arch/arm64/include/asm/kvm_emulate.h | 10 ++

Re: [PULL] Docs for 4.13

[Linus Torvalds]

On Mon, Jul 3, 2017 at 6:20 AM, Jonathan Corbet  wrote:
>You'll also encounter more than the usual number of conflicts, which
>is saying something.

Hmm. I fixed the ones that were actual data conflicts, but I think
there ends up being several things that are just stale or didn't get
updated by other pulls.

Eg things like

  Error: Cannot open file ./kernel/rcu/srcu.c
  Error: Cannot open file ./kernel/rcu/srcu.c

happen simply because that file no longer exists, and the docs never
got updated.

So my merge didn't even try to fix those kinds of things at all.  I
literally just looked at the conflicts and moved those over to the rst
files, and that was it. There's a lot of other changes that never
cause conflicts for the simple reason that those changes never caused
documentation changes to begin with.

Now, this is obviously not new, but it does strike me that if checking
for these kinds of things was easier and part of "make allmodconfig",
then we might have less of it happen.

At the same time, lots of people run a lot of builds, and while I'd
love to see warnings about docs failures, I am *not* willing to slow
down my usual build enormously. I run "male allmodconfig" builds
between every single pull during the merge window, and while it's
often parallel with me looking at the problems, I don't really want to
slow the build down too much. And the doc building is still *slow*.

Is there some fast "just basic sanity checks" that would be more reasonable?

Because one thing that the switch to sphinx has done is that the doc
build environment seems saner (tool-wise). So now that kind of thing
would at least be _possible_ to do in ways I don't think was
reasonable with docbook.

And now docbook is finally gone. But sphinx isn't exactly a speed demon either.

 Linus

Re: [PULL] Docs for 4.13

[Linus Torvalds]

On Mon, Jul 3, 2017 at 6:20 AM, Jonathan Corbet  wrote:
>You'll also encounter more than the usual number of conflicts, which
>is saying something.

Hmm. I fixed the ones that were actual data conflicts, but I think
there ends up being several things that are just stale or didn't get
updated by other pulls.

Eg things like

  Error: Cannot open file ./kernel/rcu/srcu.c
  Error: Cannot open file ./kernel/rcu/srcu.c

happen simply because that file no longer exists, and the docs never
got updated.

So my merge didn't even try to fix those kinds of things at all.  I
literally just looked at the conflicts and moved those over to the rst
files, and that was it. There's a lot of other changes that never
cause conflicts for the simple reason that those changes never caused
documentation changes to begin with.

Now, this is obviously not new, but it does strike me that if checking
for these kinds of things was easier and part of "make allmodconfig",
then we might have less of it happen.

At the same time, lots of people run a lot of builds, and while I'd
love to see warnings about docs failures, I am *not* willing to slow
down my usual build enormously. I run "male allmodconfig" builds
between every single pull during the merge window, and while it's
often parallel with me looking at the problems, I don't really want to
slow the build down too much. And the doc building is still *slow*.

Is there some fast "just basic sanity checks" that would be more reasonable?

Because one thing that the switch to sphinx has done is that the doc
build environment seems saner (tool-wise). So now that kind of thing
would at least be _possible_ to do in ways I don't think was
reasonable with docbook.

And now docbook is finally gone. But sphinx isn't exactly a speed demon either.

 Linus

Commit edf064e7c (btrfs: nowait aio support) breaks shells

[Markus Trippelsdorf]

commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
Author: Goldwyn Rodrigues 
Date:   Tue Jun 20 07:05:49 2017 -0500

btrfs: nowait aio support

apparently breaks several shell related features on my system.
In zsh history stopped working, because no new entries are added
anymore.
I fist noticed the issue when I tried to build mplayer. It uses a shell
script to generate a help_mp.h file:

  % help/help_create.sh help/help_mp-en.h UTF-8

This file gets corrupted:

--- help_mp_good.h  2017-07-04 05:38:33.161640826 +0200
+++ help_mp_bad.h   2017-07-04 05:51:00.650730726 +0200
@@ -1,14 +1,8 @@
-/* WARNING! This is a generated file, do NOT edit.
- * See the help/ subdirectory for the editable files. */
 
 -#ifndef MPLAYER_HELP_MP_H
 -#define MPLAYER_HELP_MP_H
 -
 -#include 
 -#include "config.h"
 +#endif /* MPLAYER_HELP_MP_H */
 +he English master file */
  
  -// $Revision: 37846 $
  -// MASTER FILE. Use this file as base for translations.
  + for translations.
...
(I have attached the testcase.)

/dev/sdc3 on / type btrfs 
(rw,noatime,lazytime,compress=lzo,ssd,noacl,space_cache=v2,subvolid=5,subvol=/) 
 # cat /sys/block/sdc/queue/scheduler
[none] mq-deadline 

-- 
Markus


test.tar.bz2
Description: Binary data

Commit edf064e7c (btrfs: nowait aio support) breaks shells

[Markus Trippelsdorf]

commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
Author: Goldwyn Rodrigues 
Date:   Tue Jun 20 07:05:49 2017 -0500

btrfs: nowait aio support

apparently breaks several shell related features on my system.
In zsh history stopped working, because no new entries are added
anymore.
I fist noticed the issue when I tried to build mplayer. It uses a shell
script to generate a help_mp.h file:

  % help/help_create.sh help/help_mp-en.h UTF-8

This file gets corrupted:

--- help_mp_good.h  2017-07-04 05:38:33.161640826 +0200
+++ help_mp_bad.h   2017-07-04 05:51:00.650730726 +0200
@@ -1,14 +1,8 @@
-/* WARNING! This is a generated file, do NOT edit.
- * See the help/ subdirectory for the editable files. */
 
 -#ifndef MPLAYER_HELP_MP_H
 -#define MPLAYER_HELP_MP_H
 -
 -#include 
 -#include "config.h"
 +#endif /* MPLAYER_HELP_MP_H */
 +he English master file */
  
  -// $Revision: 37846 $
  -// MASTER FILE. Use this file as base for translations.
  + for translations.
...
(I have attached the testcase.)

/dev/sdc3 on / type btrfs 
(rw,noatime,lazytime,compress=lzo,ssd,noacl,space_cache=v2,subvolid=5,subvol=/) 
 # cat /sys/block/sdc/queue/scheduler
[none] mq-deadline 

-- 
Markus


test.tar.bz2
Description: Binary data

Re: [PATCH] ext4: fix __ext4_xattr_set_credits()

[Theodore Ts'o]

On Wed, Jun 28, 2017 at 02:47:50PM -0700, Tahsin Erdogan wrote:
> __ext4_xattr_set_credits() calculates journal credits needed for a
> set xattr operation. Currently, credits needed for quota updates are
> added only if ea_inode feature is enabled which is wrong. Fix this by
> moving quota related additions to above ea_inode feature check.
> 
> Fixes: 74c5bfa651af ("ext4: xattr inode deduplication")
> 
> Signed-off-by: Tahsin Erdogan 

Thanks, I've folded this into the xattr_inode_deduplication patch.

  - Ted

Re: [PATCH] ext4: fix __ext4_xattr_set_credits()

[Theodore Ts'o]

On Wed, Jun 28, 2017 at 02:47:50PM -0700, Tahsin Erdogan wrote:
> __ext4_xattr_set_credits() calculates journal credits needed for a
> set xattr operation. Currently, credits needed for quota updates are
> added only if ea_inode feature is enabled which is wrong. Fix this by
> moving quota related additions to above ea_inode feature check.
> 
> Fixes: 74c5bfa651af ("ext4: xattr inode deduplication")
> 
> Signed-off-by: Tahsin Erdogan 

Thanks, I've folded this into the xattr_inode_deduplication patch.

  - Ted

[PATCH] char: ipmi: eliminate misleading print info when being probed via ACPI

[Hanjun Guo]

From: Hanjun Guo 

When ipmi is probed via ACPI, the boot log shows

[   17.945139] ipmi_si IPI0001:00: probing via device tree
[   17.950369] ipmi_si IPI0001:00: ipmi_si: probing via ACPI
[   17.955795] ipmi_si IPI0001:00: [io  0x00e4-0x3fff] regsize 1 spacing 1 irq 0
[   17.962932] ipmi_si: Adding ACPI-specified bt state machine

which "ipmi_si IPI0001:00: probing via device tree" is misleading
with a ACPI HID "IPI0001" but probing via DT.

Eliminate this misleading print info by checking of_node is valid
or not before calling of_ipmi_probe().

Signed-off-by: Hanjun Guo 
---
 drivers/char/ipmi/ipmi_si_intf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 59ee93e..159950d 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2810,7 +2810,7 @@ static int acpi_ipmi_probe(struct platform_device *dev)
 
 static int ipmi_probe(struct platform_device *dev)
 {
-   if (of_ipmi_probe(dev) == 0)
+   if (dev->dev.of_node && of_ipmi_probe(dev) == 0)
return 0;
 
return acpi_ipmi_probe(dev);
-- 
1.7.12.4

[PATCH] char: ipmi: eliminate misleading print info when being probed via ACPI

[Hanjun Guo]

From: Hanjun Guo 

When ipmi is probed via ACPI, the boot log shows

[   17.945139] ipmi_si IPI0001:00: probing via device tree
[   17.950369] ipmi_si IPI0001:00: ipmi_si: probing via ACPI
[   17.955795] ipmi_si IPI0001:00: [io  0x00e4-0x3fff] regsize 1 spacing 1 irq 0
[   17.962932] ipmi_si: Adding ACPI-specified bt state machine

which "ipmi_si IPI0001:00: probing via device tree" is misleading
with a ACPI HID "IPI0001" but probing via DT.

Eliminate this misleading print info by checking of_node is valid
or not before calling of_ipmi_probe().

Signed-off-by: Hanjun Guo 
---
 drivers/char/ipmi/ipmi_si_intf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 59ee93e..159950d 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2810,7 +2810,7 @@ static int acpi_ipmi_probe(struct platform_device *dev)
 
 static int ipmi_probe(struct platform_device *dev)
 {
-   if (of_ipmi_probe(dev) == 0)
+   if (dev->dev.of_node && of_ipmi_probe(dev) == 0)
return 0;
 
return acpi_ipmi_probe(dev);
-- 
1.7.12.4

Re: [PATCH] ext4: fast symlink test should not rely on i_blocks

[Theodore Ts'o]

On Wed, Jun 28, 2017 at 10:53:31AM -0600, Andreas Dilger wrote:
> 
> > On Jun 27, 2017, at 6:34 PM, Tahsin Erdogan  wrote:
> > 
> > ext4_inode_info->i_data is the storage area for 4 types of data:
> > 
> >  a) Extents data
> >  b) Inline data
> >  c) Block map
> >  d) Fast symlink data (symlink length < 60)
> > 
> > Extents data case is positively identified by EXT4_INODE_EXTENTS flag.
> > Inline data case is also obvious because of EXT4_INODE_INLINE_DATA
> > flag.
> > 
> > Distinguishing c) and d) however requires additional logic. This
> > currently relies on i_blocks count. After subtracting external xattr
> > block from i_blocks, if it is greater than 0 then we know that some
> > data blocks exist, so there must be a block map.
> > 
> > This logic got broken after ea_inode feature was added. That feature
> > charges the data blocks of external xattr inodes to the referencing
> > inode and so adds them to the i_blocks. To fix this, we could subtract
> > ea_inode blocks by iterating through all xattr entries and then check
> > whether remaining i_blocks count is zero. Besides being complicated,
> > this won't change the fact that the current way of distinguishing
> > between c) and d) is fragile.
> > 
> > The alternative solution is to test whether i_size is less than 60 to
> > determine fast symlink case. ext4_symlink() uses the same test to decide
> > whether to store the symlink in i_data. There is one caveat to address
> > before this can work though.
> > 
> > If an inode's i_nlink is zero during eviction, its i_size is set to
> > zero and its data is truncated. If system crashes before inode is removed
> > from the orphan list, next boot orphan cleanup may find the inode with
> > zero i_size. So, a symlink that had its data stored in a block may now
> > appear to be a fast symlink. The solution used in this patch is to treat
> > i_size = 0 as a non-fast symlink case. A zero sized symlink is not legal
> > so the only time this can happen is the mentioned scenario. This is also
> > logically correct because a i_size = 0 symlink has no data stored in
> > i_data.
> > 
> > Fixes: 74c5bfa651af ("ext4: xattr inode deduplication")
> > 
> > Suggested-by: Andreas Dilger 
> > Signed-off-by: Tahsin Erdogan 
> 
> The unfortunate bit is that this makes the inode impossible to undelete, but
> I don't think that is a huge concern for symlinks.
> 
> Reviewed-by: Andreas Dilger 

Thanks, applied.

- Ted

Re: [PATCH] ext4: fast symlink test should not rely on i_blocks

[Theodore Ts'o]

On Wed, Jun 28, 2017 at 10:53:31AM -0600, Andreas Dilger wrote:
> 
> > On Jun 27, 2017, at 6:34 PM, Tahsin Erdogan  wrote:
> > 
> > ext4_inode_info->i_data is the storage area for 4 types of data:
> > 
> >  a) Extents data
> >  b) Inline data
> >  c) Block map
> >  d) Fast symlink data (symlink length < 60)
> > 
> > Extents data case is positively identified by EXT4_INODE_EXTENTS flag.
> > Inline data case is also obvious because of EXT4_INODE_INLINE_DATA
> > flag.
> > 
> > Distinguishing c) and d) however requires additional logic. This
> > currently relies on i_blocks count. After subtracting external xattr
> > block from i_blocks, if it is greater than 0 then we know that some
> > data blocks exist, so there must be a block map.
> > 
> > This logic got broken after ea_inode feature was added. That feature
> > charges the data blocks of external xattr inodes to the referencing
> > inode and so adds them to the i_blocks. To fix this, we could subtract
> > ea_inode blocks by iterating through all xattr entries and then check
> > whether remaining i_blocks count is zero. Besides being complicated,
> > this won't change the fact that the current way of distinguishing
> > between c) and d) is fragile.
> > 
> > The alternative solution is to test whether i_size is less than 60 to
> > determine fast symlink case. ext4_symlink() uses the same test to decide
> > whether to store the symlink in i_data. There is one caveat to address
> > before this can work though.
> > 
> > If an inode's i_nlink is zero during eviction, its i_size is set to
> > zero and its data is truncated. If system crashes before inode is removed
> > from the orphan list, next boot orphan cleanup may find the inode with
> > zero i_size. So, a symlink that had its data stored in a block may now
> > appear to be a fast symlink. The solution used in this patch is to treat
> > i_size = 0 as a non-fast symlink case. A zero sized symlink is not legal
> > so the only time this can happen is the mentioned scenario. This is also
> > logically correct because a i_size = 0 symlink has no data stored in
> > i_data.
> > 
> > Fixes: 74c5bfa651af ("ext4: xattr inode deduplication")
> > 
> > Suggested-by: Andreas Dilger 
> > Signed-off-by: Tahsin Erdogan 
> 
> The unfortunate bit is that this makes the inode impossible to undelete, but
> I don't think that is a huge concern for symlinks.
> 
> Reviewed-by: Andreas Dilger 

Thanks, applied.

- Ted

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

[Darrick J. Wong]

On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > Was there ever a version of NFS (or more generally callers of the
> > > exportfs code) that couldn't deal with i_generation in the file handle,
> > > and therefore we invented this generation hack to work around the loss
> > > of the generation information?
> > > 
> > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
> > > with subtree_check (which seems to require one ino/gen pair for the file
> > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
> > > provide enough space for all the file handle information, but that's the
> > > furthest I got with lazy-mining the git history. :)
> > 
> > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
> > 
> > * Currently we don't know the generation for parent directory, so
> > * a generation of 0 means "accept any"
> > 
> > But I don't see that used.
> > 
> > It was used once upon a time; I see it actually used in old 2.5 code in
> > nfsd_get_dentry.  Hm.
> 
> Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
> 
>   switch (fh_type) {
>   case FILEID_INO32_GEN_PARENT:
>   inode = get_inode(sb, fid->i32.parent_ino,
> (fh_len > 3 ? fid->i32.parent_gen : 0));
>   break;
>   }
> 
> I'm not sure under what conditions that filehandle encoding is used.

The best guess I can come up with is the old nfs_fhbase_old style handles,
which (afaict) do not carry parent i_generation?

--D

> 
> --b.

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

[Darrick J. Wong]

On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > Was there ever a version of NFS (or more generally callers of the
> > > exportfs code) that couldn't deal with i_generation in the file handle,
> > > and therefore we invented this generation hack to work around the loss
> > > of the generation information?
> > > 
> > > There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes
> > > with subtree_check (which seems to require one ino/gen pair for the file
> > > and a second pair for the file's parent) on NFSv2 because v2 doesn't
> > > provide enough space for all the file handle information, but that's the
> > > furthest I got with lazy-mining the git history. :)
> > 
> > There's a comment in fs/ext4/super.c:ext4_nfs_get_inode
> > 
> > * Currently we don't know the generation for parent directory, so
> > * a generation of 0 means "accept any"
> > 
> > But I don't see that used.
> > 
> > It was used once upon a time; I see it actually used in old 2.5 code in
> > nfsd_get_dentry.  Hm.
> 
> Oh, maybe it's here in fs/libfs.c:generic_fh_to_parent:
> 
>   switch (fh_type) {
>   case FILEID_INO32_GEN_PARENT:
>   inode = get_inode(sb, fid->i32.parent_ino,
> (fh_len > 3 ? fid->i32.parent_gen : 0));
>   break;
>   }
> 
> I'm not sure under what conditions that filehandle encoding is used.

The best guess I can come up with is the old nfs_fhbase_old style handles,
which (afaict) do not carry parent i_generation?

--D

> 
> --b.

[PATCH] gpio: drop unnecessary includes from include/linux/gpio/driver.h

[Masahiro Yamada]

Some of include directives in include/linux/gpio/driver.h are
unneeded because the header does not need to know the content of
struct device, irq_chip, etc.  Just declare they are structures.

On the other hand,  and 
turned out to be necessary for irq_flow_handler_t and spinlock_t,
respectively.

Each driver should include what it needs without relying on what is
implicitly included from .  This will cut down
unnecessary header parsing.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/gpio-104-dio-48e.c  |  1 +
 drivers/gpio/gpio-104-idi-48.c   |  1 +
 drivers/gpio/gpio-104-idio-16.c  |  1 +
 drivers/gpio/gpio-altera-a10sr.c |  2 ++
 drivers/gpio/gpio-altera.c   |  3 +++
 drivers/gpio/gpio-aspeed.c   |  5 +
 drivers/gpio/gpio-ath79.c|  2 ++
 drivers/gpio/gpio-bcm-kona.c |  1 +
 drivers/gpio/gpio-clps711x.c |  1 +
 drivers/gpio/gpio-crystalcove.c  |  2 ++
 drivers/gpio/gpio-dln2.c |  1 +
 drivers/gpio/gpio-dwapb.c|  1 +
 drivers/gpio/gpio-etraxfs.c  |  1 +
 drivers/gpio/gpio-f7188x.c   |  1 +
 drivers/gpio/gpio-ftgpio010.c|  3 +++
 drivers/gpio/gpio-ingenic.c  |  1 +
 drivers/gpio/gpio-intel-mid.c|  2 ++
 drivers/gpio/gpio-lp873x.c   |  1 +
 drivers/gpio/gpio-lynxpoint.c|  2 ++
 drivers/gpio/gpio-max732x.c  |  1 +
 drivers/gpio/gpio-max77620.c |  1 +
 drivers/gpio/gpio-menz127.c  |  1 +
 drivers/gpio/gpio-merrifield.c   |  4 
 drivers/gpio/gpio-omap.c |  3 +++
 drivers/gpio/gpio-pca953x.c  |  1 +
 drivers/gpio/gpio-pci-idio-16.c  |  2 ++
 drivers/gpio/gpio-pisosr.c   |  1 +
 drivers/gpio/gpio-pl061.c|  1 +
 drivers/gpio/gpio-rcar.c |  1 +
 drivers/gpio/gpio-stmpe.c|  2 ++
 drivers/gpio/gpio-tc3589x.c  |  3 +++
 drivers/gpio/gpio-tegra.c|  1 +
 drivers/gpio/gpio-tps65218.c |  1 +
 drivers/gpio/gpio-vf610.c|  3 +++
 drivers/gpio/gpio-vx855.c|  1 +
 drivers/gpio/gpio-wcove.c|  2 ++
 drivers/gpio/gpio-wm831x.c   |  1 +
 drivers/gpio/gpio-wm8994.c   |  1 +
 drivers/gpio/gpio-ws16c48.c  |  1 +
 drivers/gpio/gpio-xgene-sb.c |  2 ++
 drivers/gpio/gpio-xlp.c  |  1 +
 drivers/gpio/gpio-zx.c   |  1 +
 drivers/gpio/gpio-zynq.c |  3 +++
 drivers/gpio/gpiolib-acpi.c  |  1 +
 drivers/gpio/gpiolib.c   |  2 ++
 include/linux/gpio/driver.h  | 11 ++-
 46 files changed, 80 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index 598e209efa2d..bdc52be7902a 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index 51f046e29ff7..7bbb0e8573d1 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
index ec2ce34ff473..7e3fc0bf3398 100644
--- a/drivers/gpio/gpio-104-idio-16.c
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-altera-a10sr.c b/drivers/gpio/gpio-altera-a10sr.c
index 16a8951b2bed..4cdca9332043 100644
--- a/drivers/gpio/gpio-altera-a10sr.c
+++ b/drivers/gpio/gpio-altera-a10sr.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /**
  * struct altr_a10sr_gpio - Altera Max5 GPIO device private data structure
diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
index 17485dc20384..40b26274acaf 100644
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -17,6 +17,9 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 4ca436e66bdb..a9d575e215da 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -15,9 +15,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
index f33d4a5fe671..1249ab0f8f4f 100644
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define AR71XX_GPIO_REG_OE 0x00
 #define AR71XX_GPIO_REG_IN 0x04
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index dfcf56ee3c61..937d646d184b 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define BCM_GPIO_PASSWD0x00a5a501
 #define 

[PATCH] gpio: drop unnecessary includes from include/linux/gpio/driver.h

[Masahiro Yamada]

Some of include directives in include/linux/gpio/driver.h are
unneeded because the header does not need to know the content of
struct device, irq_chip, etc.  Just declare they are structures.

On the other hand,  and 
turned out to be necessary for irq_flow_handler_t and spinlock_t,
respectively.

Each driver should include what it needs without relying on what is
implicitly included from .  This will cut down
unnecessary header parsing.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/gpio-104-dio-48e.c  |  1 +
 drivers/gpio/gpio-104-idi-48.c   |  1 +
 drivers/gpio/gpio-104-idio-16.c  |  1 +
 drivers/gpio/gpio-altera-a10sr.c |  2 ++
 drivers/gpio/gpio-altera.c   |  3 +++
 drivers/gpio/gpio-aspeed.c   |  5 +
 drivers/gpio/gpio-ath79.c|  2 ++
 drivers/gpio/gpio-bcm-kona.c |  1 +
 drivers/gpio/gpio-clps711x.c |  1 +
 drivers/gpio/gpio-crystalcove.c  |  2 ++
 drivers/gpio/gpio-dln2.c |  1 +
 drivers/gpio/gpio-dwapb.c|  1 +
 drivers/gpio/gpio-etraxfs.c  |  1 +
 drivers/gpio/gpio-f7188x.c   |  1 +
 drivers/gpio/gpio-ftgpio010.c|  3 +++
 drivers/gpio/gpio-ingenic.c  |  1 +
 drivers/gpio/gpio-intel-mid.c|  2 ++
 drivers/gpio/gpio-lp873x.c   |  1 +
 drivers/gpio/gpio-lynxpoint.c|  2 ++
 drivers/gpio/gpio-max732x.c  |  1 +
 drivers/gpio/gpio-max77620.c |  1 +
 drivers/gpio/gpio-menz127.c  |  1 +
 drivers/gpio/gpio-merrifield.c   |  4 
 drivers/gpio/gpio-omap.c |  3 +++
 drivers/gpio/gpio-pca953x.c  |  1 +
 drivers/gpio/gpio-pci-idio-16.c  |  2 ++
 drivers/gpio/gpio-pisosr.c   |  1 +
 drivers/gpio/gpio-pl061.c|  1 +
 drivers/gpio/gpio-rcar.c |  1 +
 drivers/gpio/gpio-stmpe.c|  2 ++
 drivers/gpio/gpio-tc3589x.c  |  3 +++
 drivers/gpio/gpio-tegra.c|  1 +
 drivers/gpio/gpio-tps65218.c |  1 +
 drivers/gpio/gpio-vf610.c|  3 +++
 drivers/gpio/gpio-vx855.c|  1 +
 drivers/gpio/gpio-wcove.c|  2 ++
 drivers/gpio/gpio-wm831x.c   |  1 +
 drivers/gpio/gpio-wm8994.c   |  1 +
 drivers/gpio/gpio-ws16c48.c  |  1 +
 drivers/gpio/gpio-xgene-sb.c |  2 ++
 drivers/gpio/gpio-xlp.c  |  1 +
 drivers/gpio/gpio-zx.c   |  1 +
 drivers/gpio/gpio-zynq.c |  3 +++
 drivers/gpio/gpiolib-acpi.c  |  1 +
 drivers/gpio/gpiolib.c   |  2 ++
 include/linux/gpio/driver.h  | 11 ++-
 46 files changed, 80 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index 598e209efa2d..bdc52be7902a 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index 51f046e29ff7..7bbb0e8573d1 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
index ec2ce34ff473..7e3fc0bf3398 100644
--- a/drivers/gpio/gpio-104-idio-16.c
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-altera-a10sr.c b/drivers/gpio/gpio-altera-a10sr.c
index 16a8951b2bed..4cdca9332043 100644
--- a/drivers/gpio/gpio-altera-a10sr.c
+++ b/drivers/gpio/gpio-altera-a10sr.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /**
  * struct altr_a10sr_gpio - Altera Max5 GPIO device private data structure
diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
index 17485dc20384..40b26274acaf 100644
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -17,6 +17,9 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 4ca436e66bdb..a9d575e215da 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -15,9 +15,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
index f33d4a5fe671..1249ab0f8f4f 100644
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define AR71XX_GPIO_REG_OE 0x00
 #define AR71XX_GPIO_REG_IN 0x04
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index dfcf56ee3c61..937d646d184b 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define BCM_GPIO_PASSWD0x00a5a501
 #define GPIO_PER_BANK   

[PATCH] gpio: add COMPILE_TEST to several drivers

[Masahiro Yamada]

These drivers are actually platform-agnostic.  Add COMPILE_TEST for
the compilation test coverage.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/Kconfig | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index f235eae04c16..da82cee24980 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -153,7 +153,7 @@ config GPIO_CLPS711X
 config GPIO_DAVINCI
bool "TI Davinci/Keystone GPIO support"
default y if ARCH_DAVINCI
-   depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE)
+   depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE || COMPILE_TEST)
help
  Say yes here to enable GPIO support for TI Davinci/Keystone SoCs.
 
@@ -279,7 +279,7 @@ config GPIO_LPC18XX
 
 config GPIO_LYNXPOINT
tristate "Intel Lynxpoint GPIO support"
-   depends on ACPI && X86
+   depends on ACPI && (X86 || COMPILE_TEST)
select GPIOLIB_IRQCHIP
help
  driver for GPIO functionality on Intel Lynxpoint PCH chipset
@@ -337,20 +337,20 @@ config GPIO_MPC8XXX
 
 config GPIO_MVEBU
def_bool y
-   depends on PLAT_ORION || ARCH_MVEBU
+   depends on PLAT_ORION || ARCH_MVEBU || COMPILE_TEST
depends on OF_GPIO
select GENERIC_IRQ_CHIP
select REGMAP_MMIO
 
 config GPIO_MXC
def_bool y
-   depends on ARCH_MXC
+   depends on ARCH_MXC || COMPILE_TEST
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
 
 config GPIO_MXS
def_bool y
-   depends on ARCH_MXS
+   depends on ARCH_MXS || COMPILE_TEST
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
 
@@ -381,7 +381,7 @@ config GPIO_PL061
 
 config GPIO_PXA
bool "PXA GPIO support"
-   depends on ARCH_PXA || ARCH_MMP
+   depends on ARCH_PXA || ARCH_MMP || COMPILE_TEST
help
  Say yes here to support the PXA GPIO device
 
@@ -467,7 +467,7 @@ config GPIO_TZ1090_PDC
 
 config GPIO_VF610
def_bool y
-   depends on ARCH_MXC && SOC_VF610
+   depends on (ARCH_MXC && SOC_VF610) || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say yes here to support Vybrid vf610 GPIOs.
@@ -492,7 +492,7 @@ config GPIO_VX855
 
 config GPIO_XGENE
bool "APM X-Gene GPIO controller support"
-   depends on ARM64 && OF_GPIO
+   depends on (ARM64 || COMPILE_TEST) && OF_GPIO
help
  This driver is to support the GPIO block within the APM X-Gene SoC
  platform's generic flash controller. The GPIO pins are muxed with
@@ -543,7 +543,7 @@ config GPIO_ZEVIO
 
 config GPIO_ZYNQ
tristate "Xilinx Zynq GPIO support"
-   depends on ARCH_ZYNQ || ARCH_ZYNQMP
+   depends on ARCH_ZYNQ || ARCH_ZYNQMP || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say yes here to support Xilinx Zynq GPIO controller.
@@ -1154,14 +1154,14 @@ config GPIO_BT8XX
 
 config GPIO_INTEL_MID
bool "Intel MID GPIO support"
-   depends on X86_INTEL_MID
+   depends on X86_INTEL_MID || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say Y here to support Intel MID GPIO.
 
 config GPIO_MERRIFIELD
tristate "Intel Merrifield GPIO support"
-   depends on X86_INTEL_MID
+   depends on X86_INTEL_MID || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say Y here to support Intel Merrifield GPIO.
-- 
2.7.4

[PATCH] gpio: add COMPILE_TEST to several drivers

[Masahiro Yamada]

These drivers are actually platform-agnostic.  Add COMPILE_TEST for
the compilation test coverage.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/Kconfig | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index f235eae04c16..da82cee24980 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -153,7 +153,7 @@ config GPIO_CLPS711X
 config GPIO_DAVINCI
bool "TI Davinci/Keystone GPIO support"
default y if ARCH_DAVINCI
-   depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE)
+   depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE || COMPILE_TEST)
help
  Say yes here to enable GPIO support for TI Davinci/Keystone SoCs.
 
@@ -279,7 +279,7 @@ config GPIO_LPC18XX
 
 config GPIO_LYNXPOINT
tristate "Intel Lynxpoint GPIO support"
-   depends on ACPI && X86
+   depends on ACPI && (X86 || COMPILE_TEST)
select GPIOLIB_IRQCHIP
help
  driver for GPIO functionality on Intel Lynxpoint PCH chipset
@@ -337,20 +337,20 @@ config GPIO_MPC8XXX
 
 config GPIO_MVEBU
def_bool y
-   depends on PLAT_ORION || ARCH_MVEBU
+   depends on PLAT_ORION || ARCH_MVEBU || COMPILE_TEST
depends on OF_GPIO
select GENERIC_IRQ_CHIP
select REGMAP_MMIO
 
 config GPIO_MXC
def_bool y
-   depends on ARCH_MXC
+   depends on ARCH_MXC || COMPILE_TEST
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
 
 config GPIO_MXS
def_bool y
-   depends on ARCH_MXS
+   depends on ARCH_MXS || COMPILE_TEST
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
 
@@ -381,7 +381,7 @@ config GPIO_PL061
 
 config GPIO_PXA
bool "PXA GPIO support"
-   depends on ARCH_PXA || ARCH_MMP
+   depends on ARCH_PXA || ARCH_MMP || COMPILE_TEST
help
  Say yes here to support the PXA GPIO device
 
@@ -467,7 +467,7 @@ config GPIO_TZ1090_PDC
 
 config GPIO_VF610
def_bool y
-   depends on ARCH_MXC && SOC_VF610
+   depends on (ARCH_MXC && SOC_VF610) || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say yes here to support Vybrid vf610 GPIOs.
@@ -492,7 +492,7 @@ config GPIO_VX855
 
 config GPIO_XGENE
bool "APM X-Gene GPIO controller support"
-   depends on ARM64 && OF_GPIO
+   depends on (ARM64 || COMPILE_TEST) && OF_GPIO
help
  This driver is to support the GPIO block within the APM X-Gene SoC
  platform's generic flash controller. The GPIO pins are muxed with
@@ -543,7 +543,7 @@ config GPIO_ZEVIO
 
 config GPIO_ZYNQ
tristate "Xilinx Zynq GPIO support"
-   depends on ARCH_ZYNQ || ARCH_ZYNQMP
+   depends on ARCH_ZYNQ || ARCH_ZYNQMP || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say yes here to support Xilinx Zynq GPIO controller.
@@ -1154,14 +1154,14 @@ config GPIO_BT8XX
 
 config GPIO_INTEL_MID
bool "Intel MID GPIO support"
-   depends on X86_INTEL_MID
+   depends on X86_INTEL_MID || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say Y here to support Intel MID GPIO.
 
 config GPIO_MERRIFIELD
tristate "Intel Merrifield GPIO support"
-   depends on X86_INTEL_MID
+   depends on X86_INTEL_MID || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say Y here to support Intel Merrifield GPIO.
-- 
2.7.4

Re: [PATCH] x86/platform/uv/BAU: minor cleanup, make some local functions static

[Dou Liyang]

Hi Colin,

At 07/03/2017 10:22 PM, Colin King wrote:

From: Colin Ian King 

Functions normal_busy, handle_uv2_busy, uv_flush_send_and_wait and
find_another_by_swack are local to the source, so make them static

Fixes various smatch warnings, such as:
"symbol 'find_another_by_swack' was not declared. Should it be static?"
"symbol 'handle_uv2_busy' was not declared. Should it be static?"

Signed-off-by: Colin Ian King 
---
 arch/x86/platform/uv/tlb_uv.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 2983faab5b18..730b47dce402 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -595,7 +595,7 @@ static unsigned long uv2_3_read_status(unsigned long 
offset, int rshft, int desc
  * The bit provided by the activation_status_2 register is irrelevant to
  * the status if it is only being tested for busy or not busy.
  */
-int normal_busy(struct bau_control *bcp)
+static int normal_busy(struct bau_control *bcp)


In my opinion, there is no need to mark *normal_busy* static, remove it
directly.

the commit c5d35d399e68(x86/UV2: Work around BAU bug) add it to
handle_uv2_busy(), but the handle_uv2_busy() is rewritten now. the
normal_busy is unused, can be remove.

By the way, there are also an other function named
uv_bau_message_interrupt() can be remove.


Thanks,

dou.


 {
int cpu = bcp->uvhub_cpu;
int mmr_offset;
@@ -612,7 +612,7 @@ int normal_busy(struct bau_control *bcp)
  * of a hardware bug.
  * Workaround the bug.
  */
-int handle_uv2_busy(struct bau_control *bcp)
+static int handle_uv2_busy(struct bau_control *bcp)
 {
struct ptc_stats *stat = bcp->statp;

@@ -917,7 +917,8 @@ static void handle_cmplt(int completion_status, struct 
bau_desc *bau_desc,
  * Returns 1 if it gives up entirely and the original cpu mask is to be
  * returned to the kernel.
  */
-int uv_flush_send_and_wait(struct cpumask *flush_mask, struct bau_control *bcp,
+static int uv_flush_send_and_wait(struct cpumask *flush_mask,
+   struct bau_control *bcp,
struct bau_desc *bau_desc)
 {
int seq_number = 0;
@@ -1212,8 +1213,8 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
  * Search the message queue for any 'other' unprocessed message with the
  * same software acknowledge resource bit vector as the 'msg' message.
  */
-struct bau_pq_entry *find_another_by_swack(struct bau_pq_entry *msg,
-  struct bau_control *bcp)
+static struct bau_pq_entry *find_another_by_swack(struct bau_pq_entry *msg,
+ struct bau_control *bcp)
 {
struct bau_pq_entry *msg_next = msg + 1;
unsigned char swack_vec = msg->swack_vec;

Re: [PATCH] x86/platform/uv/BAU: minor cleanup, make some local functions static

[Dou Liyang]

Hi Colin,

At 07/03/2017 10:22 PM, Colin King wrote:

From: Colin Ian King 

Functions normal_busy, handle_uv2_busy, uv_flush_send_and_wait and
find_another_by_swack are local to the source, so make them static

Fixes various smatch warnings, such as:
"symbol 'find_another_by_swack' was not declared. Should it be static?"
"symbol 'handle_uv2_busy' was not declared. Should it be static?"

Signed-off-by: Colin Ian King 
---
 arch/x86/platform/uv/tlb_uv.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 2983faab5b18..730b47dce402 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -595,7 +595,7 @@ static unsigned long uv2_3_read_status(unsigned long 
offset, int rshft, int desc
  * The bit provided by the activation_status_2 register is irrelevant to
  * the status if it is only being tested for busy or not busy.
  */
-int normal_busy(struct bau_control *bcp)
+static int normal_busy(struct bau_control *bcp)


In my opinion, there is no need to mark *normal_busy* static, remove it
directly.

the commit c5d35d399e68(x86/UV2: Work around BAU bug) add it to
handle_uv2_busy(), but the handle_uv2_busy() is rewritten now. the
normal_busy is unused, can be remove.

By the way, there are also an other function named
uv_bau_message_interrupt() can be remove.


Thanks,

dou.


 {
int cpu = bcp->uvhub_cpu;
int mmr_offset;
@@ -612,7 +612,7 @@ int normal_busy(struct bau_control *bcp)
  * of a hardware bug.
  * Workaround the bug.
  */
-int handle_uv2_busy(struct bau_control *bcp)
+static int handle_uv2_busy(struct bau_control *bcp)
 {
struct ptc_stats *stat = bcp->statp;

@@ -917,7 +917,8 @@ static void handle_cmplt(int completion_status, struct 
bau_desc *bau_desc,
  * Returns 1 if it gives up entirely and the original cpu mask is to be
  * returned to the kernel.
  */
-int uv_flush_send_and_wait(struct cpumask *flush_mask, struct bau_control *bcp,
+static int uv_flush_send_and_wait(struct cpumask *flush_mask,
+   struct bau_control *bcp,
struct bau_desc *bau_desc)
 {
int seq_number = 0;
@@ -1212,8 +1213,8 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
  * Search the message queue for any 'other' unprocessed message with the
  * same software acknowledge resource bit vector as the 'msg' message.
  */
-struct bau_pq_entry *find_another_by_swack(struct bau_pq_entry *msg,
-  struct bau_control *bcp)
+static struct bau_pq_entry *find_another_by_swack(struct bau_pq_entry *msg,
+ struct bau_control *bcp)
 {
struct bau_pq_entry *msg_next = msg + 1;
unsigned char swack_vec = msg->swack_vec;

Re: [PATCH v1 1/1] usb:xhci: update condition to select bus->sysdev from parent device

[Thang Q. Nguyen]

On Tue, Jun 6, 2017 at 2:11 PM, Thang Q. Nguyen  wrote:
> For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
> configuration"), sysdev points to devices known to the system firmware
> or hardware for DMA parameters.
> However, the parent of the system firmware/hardware device checking
> logic does not work in ACPI boot mode. This patch updates the formulation
> to check this case in both DT and ACPI.
>
> Signed-off-by: Tung Nguyen 
> Signed-off-by: Thang Q. Nguyen 
> ---
>  drivers/usb/host/xhci-plat.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index c04144b..e3e342a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -187,7 +187,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
>  */
> sysdev = >dev;
> -   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
> +   if (sysdev->parent && (sysdev->fwnode->type == FWNODE_PDATA) &&
> +   (is_of_node(sysdev->parent->fwnode) ||
> +   is_acpi_device_node(sysdev->parent->fwnode)))
> sysdev = sysdev->parent;
>  #ifdef CONFIG_PCI
> else if (sysdev->parent && sysdev->parent->parent &&
> --
> 1.7.1
>
Hi,
Do you have any comment on this patch?

Regards,
Thang Q. Nguyen

Re: [PATCH v1 1/1] usb:xhci: update condition to select bus->sysdev from parent device

[Thang Q. Nguyen]

On Tue, Jun 6, 2017 at 2:11 PM, Thang Q. Nguyen  wrote:
> For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
> configuration"), sysdev points to devices known to the system firmware
> or hardware for DMA parameters.
> However, the parent of the system firmware/hardware device checking
> logic does not work in ACPI boot mode. This patch updates the formulation
> to check this case in both DT and ACPI.
>
> Signed-off-by: Tung Nguyen 
> Signed-off-by: Thang Q. Nguyen 
> ---
>  drivers/usb/host/xhci-plat.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index c04144b..e3e342a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -187,7 +187,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
>  */
> sysdev = >dev;
> -   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
> +   if (sysdev->parent && (sysdev->fwnode->type == FWNODE_PDATA) &&
> +   (is_of_node(sysdev->parent->fwnode) ||
> +   is_acpi_device_node(sysdev->parent->fwnode)))
> sysdev = sysdev->parent;
>  #ifdef CONFIG_PCI
> else if (sysdev->parent && sysdev->parent->parent &&
> --
> 1.7.1
>
Hi,
Do you have any comment on this patch?

Regards,
Thang Q. Nguyen

Re: [PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize

[Chris Packham]

Hi,

On 02/06/17 15:21, Chris Packham wrote:
> 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 

I had someone mention to me in passing that mtdinfo was failing for them 
(crashing with some floating point error). I'm wondering if we've 
created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. 
I don't have any other info and right now I don't have access to the 
system I had with the mchp23lcv1024 sram.

Andrew, do you still have access to your device?

Re: [PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize

[Chris Packham]

Hi,

On 02/06/17 15:21, Chris Packham wrote:
> 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 

I had someone mention to me in passing that mtdinfo was failing for them 
(crashing with some floating point error). I'm wondering if we've 
created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. 
I don't have any other info and right now I don't have access to the 
system I had with the mchp23lcv1024 sram.

Andrew, do you still have access to your device?

Re: [PATCH v2 0/7] KVM: MMU: fast write protect

[Xiao Guangrong]

On 07/03/2017 11:47 PM, Paolo Bonzini wrote:



On 03/07/2017 16:39, Xiao Guangrong wrote:



On 06/20/2017 05:15 PM, guangrong.x...@gmail.com wrote:

From: Xiao Guangrong 

Changelog in v2:
thanks to Paolo's review, this version disables write-protect-all if
PML is supported


Hi Paolo,

Do you have time to have a look at this new version? ;)
Or I should wait until the patchset of dirty ring-buffer is merged?


I will look at it soon, but I still plan to merge dirty ring buffer first.

Thanks for your understanding,


Sure, i fully understand, thank you for bearing my push. :)

Re: [PATCH v2 0/7] KVM: MMU: fast write protect

[Xiao Guangrong]

On 07/03/2017 11:47 PM, Paolo Bonzini wrote:



On 03/07/2017 16:39, Xiao Guangrong wrote:



On 06/20/2017 05:15 PM, guangrong.x...@gmail.com wrote:

From: Xiao Guangrong 

Changelog in v2:
thanks to Paolo's review, this version disables write-protect-all if
PML is supported


Hi Paolo,

Do you have time to have a look at this new version? ;)
Or I should wait until the patchset of dirty ring-buffer is merged?


I will look at it soon, but I still plan to merge dirty ring buffer first.

Thanks for your understanding,


Sure, i fully understand, thank you for bearing my push. :)

[PATCH] net: ethernet: mediatek: fixed deadlock captured by lockdep

[sean.wang]

From: Sean Wang 

Lockdep found an inconsistent lock state when mtk_get_stats64 is called
in user context while NAPI updates MAC statistics in softirq.

Use spin_trylock_bh/spin_unlock_bh fix following lockdep warning.

[   81.321030] WARNING: inconsistent lock state
[   81.325266] 4.12.0-rc1-00035-gd9dda65 #32 Not tainted
[   81.330273] 
[   81.334505] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   81.340464] ksoftirqd/0/7 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   81.345731]  (>seq#2){+.?...}, at: [] 
mtk_handle_status_irq.part.6+0x70/0x84
[   81.354219] {SOFTIRQ-ON-W} state was registered at:
[   81.359062]   lock_acquire+0xfc/0x2b0
[   81.362696]   mtk_stats_update_mac+0x60/0x2c0
[   81.367017]   mtk_get_stats64+0x17c/0x18c
[   81.370995]   dev_get_stats+0x48/0xbc
[   81.374628]   rtnl_fill_stats+0x48/0x128
[   81.378520]   rtnl_fill_ifinfo+0x4ac/0xd1c
[   81.382584]   rtmsg_ifinfo_build_skb+0x7c/0xe0
[   81.386991]   rtmsg_ifinfo.part.5+0x24/0x54
[   81.391139]   rtmsg_ifinfo+0x24/0x28
[   81.394685]   __dev_notify_flags+0xa4/0xac
[   81.398749]   dev_change_flags+0x50/0x58
[   81.402640]   devinet_ioctl+0x768/0x85c
[   81.406444]   inet_ioctl+0x1a4/0x1d0
[   81.409990]   sock_ioctl+0x16c/0x33c
[   81.413538]   do_vfs_ioctl+0xb4/0xa34
[   81.417169]   SyS_ioctl+0x44/0x6c
[   81.420458]   ret_fast_syscall+0x0/0x1c
[   81.424260] irq event stamp: 3354692
[   81.427806] hardirqs last  enabled at (3354692): [] 
net_rx_action+0xc0/0x504
[   81.435660] hardirqs last disabled at (3354691): [] 
net_rx_action+0x8c/0x504
[   81.443515] softirqs last  enabled at (3354106): [] 
__do_softirq+0x4b4/0x614
[   81.451370] softirqs last disabled at (3354109): [] 
run_ksoftirqd+0x44/0x80
[   81.459134]
[   81.459134] other info that might help us debug this:
[   81.465608]  Possible unsafe locking scenario:
[   81.465608]
[   81.471478]CPU0
[   81.473900]
[   81.476321]   lock(>seq#2);
[   81.479701]   
[   81.482294] lock(>seq#2);
[   81.485847]
[   81.485847]  *** DEADLOCK ***
[   81.485847]
[   81.491720] 1 lock held by ksoftirqd/0/7:
[   81.495693]  #0:  (&(>hw_stats->stats_lock)->rlock){+.+...}, at: 
[] mtk_handle_status_irq.part.6+0x48/0x84
[   81.506579]
[   81.506579] stack backtrace:
[   81.510904] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 
4.12.0-rc1-00035-gd9dda65 #32
[   81.518668] Hardware name: Mediatek Cortex-A7 (Device Tree)
[   81.524208] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   81.531899] [] (show_stack) from [] 
(dump_stack+0xb4/0xe0)
[   81.539072] [] (dump_stack) from [] 
(print_usage_bug+0x234/0x2e0)
[   81.546846] [] (print_usage_bug) from [] 
(mark_lock+0x63c/0x7bc)
[   81.554532] [] (mark_lock) from [] 
(__lock_acquire+0x654/0x1bfc)
[   81.562217] [] (__lock_acquire) from [] 
(lock_acquire+0xfc/0x2b0)
[   81.569990] [] (lock_acquire) from [] 
(mtk_stats_update_mac+0x60/0x2c0)
[   81.578283] [] (mtk_stats_update_mac) from [] 
(mtk_handle_status_irq.part.6+0x70/0x84)
[   81.587865] [] (mtk_handle_status_irq.part.6) from [] 
(mtk_napi_tx+0x358/0x37c)
[   81.596845] [] (mtk_napi_tx) from [] 
(net_rx_action+0x244/0x504)
[   81.604533] [] (net_rx_action) from [] 
(__do_softirq+0x134/0x614)
[   81.612306] [] (__do_softirq) from [] 
(run_ksoftirqd+0x44/0x80)
[   81.619907] [] (run_ksoftirqd) from [] 
(smpboot_thread_fn+0x14c/0x25c)
[   81.628110] [] (smpboot_thread_fn) from [] 
(kthread+0x150/0x180)
[   81.635798] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 16f9755..8a2acb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -470,9 +470,9 @@ static void mtk_get_stats64(struct net_device *dev,
unsigned int start;
 
if (netif_running(dev) && netif_device_present(dev)) {
-   if (spin_trylock(_stats->stats_lock)) {
+   if (spin_trylock_bh(_stats->stats_lock)) {
mtk_stats_update_mac(mac);
-   spin_unlock(_stats->stats_lock);
+   spin_unlock_bh(_stats->stats_lock);
}
}
 
@@ -2156,9 +2156,9 @@ static void mtk_get_ethtool_stats(struct net_device *dev,
return;
 
if (netif_running(dev) && netif_device_present(dev)) {
-   if (spin_trylock(>stats_lock)) {
+   if (spin_trylock_bh(>stats_lock)) {
mtk_stats_update_mac(mac);
-   spin_unlock(>stats_lock);
+   spin_unlock_bh(>stats_lock);
}
}
 
-- 
2.7.4

[PATCH] net: ethernet: mediatek: fixed deadlock captured by lockdep

[sean.wang]

From: Sean Wang 

Lockdep found an inconsistent lock state when mtk_get_stats64 is called
in user context while NAPI updates MAC statistics in softirq.

Use spin_trylock_bh/spin_unlock_bh fix following lockdep warning.

[   81.321030] WARNING: inconsistent lock state
[   81.325266] 4.12.0-rc1-00035-gd9dda65 #32 Not tainted
[   81.330273] 
[   81.334505] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   81.340464] ksoftirqd/0/7 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   81.345731]  (>seq#2){+.?...}, at: [] 
mtk_handle_status_irq.part.6+0x70/0x84
[   81.354219] {SOFTIRQ-ON-W} state was registered at:
[   81.359062]   lock_acquire+0xfc/0x2b0
[   81.362696]   mtk_stats_update_mac+0x60/0x2c0
[   81.367017]   mtk_get_stats64+0x17c/0x18c
[   81.370995]   dev_get_stats+0x48/0xbc
[   81.374628]   rtnl_fill_stats+0x48/0x128
[   81.378520]   rtnl_fill_ifinfo+0x4ac/0xd1c
[   81.382584]   rtmsg_ifinfo_build_skb+0x7c/0xe0
[   81.386991]   rtmsg_ifinfo.part.5+0x24/0x54
[   81.391139]   rtmsg_ifinfo+0x24/0x28
[   81.394685]   __dev_notify_flags+0xa4/0xac
[   81.398749]   dev_change_flags+0x50/0x58
[   81.402640]   devinet_ioctl+0x768/0x85c
[   81.406444]   inet_ioctl+0x1a4/0x1d0
[   81.409990]   sock_ioctl+0x16c/0x33c
[   81.413538]   do_vfs_ioctl+0xb4/0xa34
[   81.417169]   SyS_ioctl+0x44/0x6c
[   81.420458]   ret_fast_syscall+0x0/0x1c
[   81.424260] irq event stamp: 3354692
[   81.427806] hardirqs last  enabled at (3354692): [] 
net_rx_action+0xc0/0x504
[   81.435660] hardirqs last disabled at (3354691): [] 
net_rx_action+0x8c/0x504
[   81.443515] softirqs last  enabled at (3354106): [] 
__do_softirq+0x4b4/0x614
[   81.451370] softirqs last disabled at (3354109): [] 
run_ksoftirqd+0x44/0x80
[   81.459134]
[   81.459134] other info that might help us debug this:
[   81.465608]  Possible unsafe locking scenario:
[   81.465608]
[   81.471478]CPU0
[   81.473900]
[   81.476321]   lock(>seq#2);
[   81.479701]   
[   81.482294] lock(>seq#2);
[   81.485847]
[   81.485847]  *** DEADLOCK ***
[   81.485847]
[   81.491720] 1 lock held by ksoftirqd/0/7:
[   81.495693]  #0:  (&(>hw_stats->stats_lock)->rlock){+.+...}, at: 
[] mtk_handle_status_irq.part.6+0x48/0x84
[   81.506579]
[   81.506579] stack backtrace:
[   81.510904] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 
4.12.0-rc1-00035-gd9dda65 #32
[   81.518668] Hardware name: Mediatek Cortex-A7 (Device Tree)
[   81.524208] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   81.531899] [] (show_stack) from [] 
(dump_stack+0xb4/0xe0)
[   81.539072] [] (dump_stack) from [] 
(print_usage_bug+0x234/0x2e0)
[   81.546846] [] (print_usage_bug) from [] 
(mark_lock+0x63c/0x7bc)
[   81.554532] [] (mark_lock) from [] 
(__lock_acquire+0x654/0x1bfc)
[   81.562217] [] (__lock_acquire) from [] 
(lock_acquire+0xfc/0x2b0)
[   81.569990] [] (lock_acquire) from [] 
(mtk_stats_update_mac+0x60/0x2c0)
[   81.578283] [] (mtk_stats_update_mac) from [] 
(mtk_handle_status_irq.part.6+0x70/0x84)
[   81.587865] [] (mtk_handle_status_irq.part.6) from [] 
(mtk_napi_tx+0x358/0x37c)
[   81.596845] [] (mtk_napi_tx) from [] 
(net_rx_action+0x244/0x504)
[   81.604533] [] (net_rx_action) from [] 
(__do_softirq+0x134/0x614)
[   81.612306] [] (__do_softirq) from [] 
(run_ksoftirqd+0x44/0x80)
[   81.619907] [] (run_ksoftirqd) from [] 
(smpboot_thread_fn+0x14c/0x25c)
[   81.628110] [] (smpboot_thread_fn) from [] 
(kthread+0x150/0x180)
[   81.635798] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 16f9755..8a2acb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -470,9 +470,9 @@ static void mtk_get_stats64(struct net_device *dev,
unsigned int start;
 
if (netif_running(dev) && netif_device_present(dev)) {
-   if (spin_trylock(_stats->stats_lock)) {
+   if (spin_trylock_bh(_stats->stats_lock)) {
mtk_stats_update_mac(mac);
-   spin_unlock(_stats->stats_lock);
+   spin_unlock_bh(_stats->stats_lock);
}
}
 
@@ -2156,9 +2156,9 @@ static void mtk_get_ethtool_stats(struct net_device *dev,
return;
 
if (netif_running(dev) && netif_device_present(dev)) {
-   if (spin_trylock(>stats_lock)) {
+   if (spin_trylock_bh(>stats_lock)) {
mtk_stats_update_mac(mac);
-   spin_unlock(>stats_lock);
+   spin_unlock_bh(>stats_lock);
}
}
 
-- 
2.7.4

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

[Michael Ellerman]

"Rafael J. Wysocki"  writes:

> On Fri, Jun 30, 2017 at 5:45 AM, Michael Ellerman  wrote:
>> "Rafael J. Wysocki"  writes:
>>
>>> On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman
>>>  wrote:
 On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote:
> local_irq_enable can cause interrupts to be taken which could
> take significant amount of processing time. The idle process
> should set its polling flag before this, so another process that
> wakes it during this time will not have to send an IPI.
>
> Expand the TIF_POLLING_NRFLAG coverage to as large as possible.
>
> Reviewed-by: Gautham R. Shenoy 
> Signed-off-by: Nicholas Piggin 

 Series applied to powerpc next, thanks.

 https://git.kernel.org/powerpc/c/3fc5ee927ff4ffed6aa2fcd44d2fbf
>>>
>>> OK
>>>
>>> I've applied it too, so I guess I should drop it?
>>
>> Erk sorry. I hadn't heard anything so I picked it up.
>>
>> If you can drop it that would be good, but if not git will probably work
>> it out mostly :)
>
> I've dropped it, no problem.

Thanks.

cheers

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

[Michael Ellerman]

"Rafael J. Wysocki"  writes:

> On Fri, Jun 30, 2017 at 5:45 AM, Michael Ellerman  wrote:
>> "Rafael J. Wysocki"  writes:
>>
>>> On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman
>>>  wrote:
 On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote:
> local_irq_enable can cause interrupts to be taken which could
> take significant amount of processing time. The idle process
> should set its polling flag before this, so another process that
> wakes it during this time will not have to send an IPI.
>
> Expand the TIF_POLLING_NRFLAG coverage to as large as possible.
>
> Reviewed-by: Gautham R. Shenoy 
> Signed-off-by: Nicholas Piggin 

 Series applied to powerpc next, thanks.

 https://git.kernel.org/powerpc/c/3fc5ee927ff4ffed6aa2fcd44d2fbf
>>>
>>> OK
>>>
>>> I've applied it too, so I guess I should drop it?
>>
>> Erk sorry. I hadn't heard anything so I picked it up.
>>
>> If you can drop it that would be good, but if not git will probably work
>> it out mostly :)
>
> I've dropped it, no problem.

Thanks.

cheers

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

[Yang Zhang]

On 2017/7/3 18:06, Thomas Gleixner wrote:

On Mon, 3 Jul 2017, Yang Zhang wrote:

The background is that we(Alibaba Cloud) do get more and more complaints from
our customers in both KVM and Xen compare to bare-mental.After investigations,
the root cause is known to us: big cost in message passing workload(David show
it in KVM forum 2015)

A typical message workload like below:
vcpu 0 vcpu 1
1. send ipi 2.  doing hlt
3. go into idle 4.  receive ipi and wake up from hlt
5. write APIC time twice6.  write APIC time twice to
   to stop sched timer  reprogram sched timer
7. doing hlt8.  handle task and send ipi to
vcpu 0
9. same to 4.   10. same to 3

One transaction will introduce about 12 vmexits(2 hlt and 10 msr write). The
cost of such vmexits will degrades performance severely. Linux kernel already
provide idle=poll to mitigate the trend. But it only eliminates the IPI and
hlt vmexit. It has nothing to do with start/stop sched timer. A compromise
would be to turn off NOHZ kernel, but it is not the default config for new
distributions.


You still can turn if off on the kernel command line via nohz=off


You are right. Senior users will turn off it manually. But it only solve 
the sched timer. They still have the IPI/hlt problem. Another point is 
we release the distribution image to customer without any extra 
configuration to avoid mismatch between VM and bare-metal. To change 
such configuration needs reboot, but some customer's business cannot be 
interrupted after they start the service(like online gaming). It would 
be better if we can provide the sysctl interface to allow run-time 
modification. By the way, idle=poll seems too heavy to use.






Thanks,

tglx




--
Yang
Alibaba Cloud Computing

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

[Yang Zhang]

On 2017/7/3 18:06, Thomas Gleixner wrote:

On Mon, 3 Jul 2017, Yang Zhang wrote:

The background is that we(Alibaba Cloud) do get more and more complaints from
our customers in both KVM and Xen compare to bare-mental.After investigations,
the root cause is known to us: big cost in message passing workload(David show
it in KVM forum 2015)

A typical message workload like below:
vcpu 0 vcpu 1
1. send ipi 2.  doing hlt
3. go into idle 4.  receive ipi and wake up from hlt
5. write APIC time twice6.  write APIC time twice to
   to stop sched timer  reprogram sched timer
7. doing hlt8.  handle task and send ipi to
vcpu 0
9. same to 4.   10. same to 3

One transaction will introduce about 12 vmexits(2 hlt and 10 msr write). The
cost of such vmexits will degrades performance severely. Linux kernel already
provide idle=poll to mitigate the trend. But it only eliminates the IPI and
hlt vmexit. It has nothing to do with start/stop sched timer. A compromise
would be to turn off NOHZ kernel, but it is not the default config for new
distributions.


You still can turn if off on the kernel command line via nohz=off


You are right. Senior users will turn off it manually. But it only solve 
the sched timer. They still have the IPI/hlt problem. Another point is 
we release the distribution image to customer without any extra 
configuration to avoid mismatch between VM and bare-metal. To change 
such configuration needs reboot, but some customer's business cannot be 
interrupted after they start the service(like online gaming). It would 
be better if we can provide the sysctl interface to allow run-time 
modification. By the way, idle=poll seems too heavy to use.






Thanks,

tglx




--
Yang
Alibaba Cloud Computing

[PATCH] MAINTAINERS:add maintainer for kirin pcie

[Xiaowei Song]

Kirin PCIe Driver does not have a maintainer at present,

Add maintainers for kirin pcie driver and Doc, the two fellowing files.
Documentation/devicetree/bindings/pci/pcie-kirin.txt
drivers/pci/dwc/pcie-kirin.c

Signed-off-by: Xiaowei Song 
Cc: Guodong Xu 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ee3125f8341..c64ff79587c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9851,6 +9851,14 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/dwc/pcie-hisi.c
 
+PCIE DRIVER FOR Kirin
+M: Xiaowei Song 
+M: Binghui Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
+F: drivers/pci/dwc/pcie-kirin.c
+
 PCIE DRIVER FOR ROCKCHIP
 M: Shawn Lin 
 M: Wenrui Li 
-- 
2.11.GIT

[PATCH] MAINTAINERS:add maintainer for kirin pcie

[Xiaowei Song]

Kirin PCIe Driver does not have a maintainer at present,

Add maintainers for kirin pcie driver and Doc, the two fellowing files.
Documentation/devicetree/bindings/pci/pcie-kirin.txt
drivers/pci/dwc/pcie-kirin.c

Signed-off-by: Xiaowei Song 
Cc: Guodong Xu 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ee3125f8341..c64ff79587c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9851,6 +9851,14 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/dwc/pcie-hisi.c
 
+PCIE DRIVER FOR Kirin
+M: Xiaowei Song 
+M: Binghui Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
+F: drivers/pci/dwc/pcie-kirin.c
+
 PCIE DRIVER FOR ROCKCHIP
 M: Shawn Lin 
 M: Wenrui Li 
-- 
2.11.GIT

[PATCH] MAINTAINERS:add maintainer for kirin pcie

[Xiaowei Song]

Kirin PCIe Driver does not have a maintainer at present,

Add maintainers for kirin pcie driver and Doc, the two fellowing files.
Documentation/devicetree/bindings/pci/pcie-kirin.txt
drivers/pci/dwc/pcie-kirin.c

Signed-off-by: Xiaowei Song 
Cc: Guodong Xu 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ee3125f8341..c64ff79587c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9851,6 +9851,14 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/dwc/pcie-hisi.c
 
+PCIE DRIVER FOR Kirin
+M: Xiaowei Song 
+M: Binghui Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
+F: drivers/pci/dwc/pcie-kirin.c
+
 PCIE DRIVER FOR ROCKCHIP
 M: Shawn Lin 
 M: Wenrui Li 
-- 
2.11.GIT

[PATCH] MAINTAINERS:add maintainer for kirin pcie

[Xiaowei Song]

Kirin PCIe Driver does not have a maintainer at present,

Add maintainers for kirin pcie driver and Doc, the two fellowing files.
Documentation/devicetree/bindings/pci/pcie-kirin.txt
drivers/pci/dwc/pcie-kirin.c

Signed-off-by: Xiaowei Song 
Cc: Guodong Xu 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ee3125f8341..c64ff79587c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9851,6 +9851,14 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/dwc/pcie-hisi.c
 
+PCIE DRIVER FOR Kirin
+M: Xiaowei Song 
+M: Binghui Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
+F: drivers/pci/dwc/pcie-kirin.c
+
 PCIE DRIVER FOR ROCKCHIP
 M: Shawn Lin 
 M: Wenrui Li 
-- 
2.11.GIT

Re: [PATCH v11 0/3]add PCIe driver for Kirin PCIe

[Guodong Xu]

On Mon, Jul 3, 2017 at 9:32 PM, Wei Xu  wrote:
> Hi Guodong,
>
> On 2017/7/3 14:04, Guodong Xu wrote:
>> Hi, Xu Wei
>>
>>
>>
>> On Mon, Jul 3, 2017 at 6:47 PM, Will Deacon  wrote:
>>> On Sun, Jul 02, 2017 at 06:36:57PM -0500, Bjorn Helgaas wrote:
 [+cc Catalin, Will, linux-arm-kernel]

 Applied patches 2 & 3 to pci/host-kirin for v4.13.

 I would like a MAINTAINERS update, too.  If you send me that, I'll
 squash it into the driver patch.

 Catalin, Will, how do you want to handle the
 arch/arm64/configs/defconfig change (patch 3)?  It's currently on my
 branch, but I'm happy to drop it if another route is better.
>>>
>>> defconfig updates usually go through arm-soc, via the relevant platform
>>> maintainer, so it would be best to follow that route here too otherwise
>>> you'll probably see conflicts in -next.
>>>
>>
>> Is it ok for you to pick up the arch/arm64/configs/defconfig change (patch 
>> 3)?
>
> Since it is already 4.12-rc7, I will pick up it and queue for the v4.14.
> Are you fine about that?
> Thanks!

Sure.

>
> Best Regards,
> Wei
>
>>
>> -Guodong
>>
>>> Will
>>
>> .
>>
>

Re: [PATCH v11 0/3]add PCIe driver for Kirin PCIe

[Guodong Xu]

On Mon, Jul 3, 2017 at 9:32 PM, Wei Xu  wrote:
> Hi Guodong,
>
> On 2017/7/3 14:04, Guodong Xu wrote:
>> Hi, Xu Wei
>>
>>
>>
>> On Mon, Jul 3, 2017 at 6:47 PM, Will Deacon  wrote:
>>> On Sun, Jul 02, 2017 at 06:36:57PM -0500, Bjorn Helgaas wrote:
 [+cc Catalin, Will, linux-arm-kernel]

 Applied patches 2 & 3 to pci/host-kirin for v4.13.

 I would like a MAINTAINERS update, too.  If you send me that, I'll
 squash it into the driver patch.

 Catalin, Will, how do you want to handle the
 arch/arm64/configs/defconfig change (patch 3)?  It's currently on my
 branch, but I'm happy to drop it if another route is better.
>>>
>>> defconfig updates usually go through arm-soc, via the relevant platform
>>> maintainer, so it would be best to follow that route here too otherwise
>>> you'll probably see conflicts in -next.
>>>
>>
>> Is it ok for you to pick up the arch/arm64/configs/defconfig change (patch 
>> 3)?
>
> Since it is already 4.12-rc7, I will pick up it and queue for the v4.14.
> Are you fine about that?
> Thanks!

Sure.

>
> Best Regards,
> Wei
>
>>
>> -Guodong
>>
>>> Will
>>
>> .
>>
>

Re: [PATCH v4] PCI: Workaround wrong flags completions for IDT switch

[Ethan Zhao]

James,

On Tue, Jul 4, 2017 at 2:17 AM, james puthukattukaran
 wrote:
>
> Ethan -
>
>
> On 7/2/2017 9:55 PM, Ethan Zhao wrote:
>>
>> James,
>>
>> On Wed, Jun 28, 2017 at 5:42 AM, James Puthukattukaran
>>  wrote:
>>>
>>> From: James Puthukattukaran 
>>>
>>> The IDT switch incorrectly flags an ACS source violation on a read config
>>> request to an end point device on the completion (IDT 89H32H8G3-YC,
>>> errata #36) even though the PCI Express spec states that completions are
>>> never affected by ACS source violation (PCI Spec 3.1, Section 6.12.1.1).
>>>
>>> The suggested workaround by IDT is to issue a configuration write to the
>>> downstream device before issuing the first config read. This allows the
>>> downstream device to capture its bus number, thus avoiding the ACS
>>> violation on the completion.
>>>
>>> The patch does the following -
>>>
>>> 1. Disable ACS source violation if enabled
>>> 2. Wait for config space access to become available by reading vendor id
>>> 3. Do a config write to the end point (errata workaround)
>>> 4. Enable ACS source validation (if it was enabled to begin with)
>>>
>>> -v2: move workaround to pci_bus_read_dev_vendor_id() from
>>> pci_bus_check_dev()
>>>   and move enable_acs_sv to drivers/pci/pci.c -- by Yinghai
>>> -v3: add bus->self check for root bus and virtual bus for sriov vfs.
>>> -v4: only do workaround for IDT switches
>>>
>>> Signed-off-by: James Puthukattukaran 
>>> Signed-off-by: Yinghai Lu 
>>>
>>> --
>>>
>>>   drivers/pci/pci.c   | 33 +
>>>   drivers/pci/pci.h   |  1 +
>>>   drivers/pci/probe.c | 38 --
>>>   3 files changed, 70 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 563901c..a7a2e2b 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -2835,6 +2835,39 @@ static bool pci_acs_flags_enabled(struct pci_dev
>>> *pdev, u16 acs_flags)
>>>   }
>>>
>>>   /**
>>> + *  pci_std_enable_acs_sv - enable/disable ACS source validation if
>>> supported by the switch
>>> + *  @dev - pcie switch/RP
>>> + *  @enable - enable (1) or disable (0) source validation
>>> + *
>>> + *  Returns : < 0 on failure
>>
>> You didn't define the meaning of 0 and >0, but you check it later against
>> >0,
>> Then what does it mean 0 and >0 ?
>
> see below..
>>
>>
>>> + *   previous acs_sv state
>
>
> It returns the previous acs_sv state (0 or 1).

You didn't clarify the meaning of previous acs_sv state, or possible value,
you check it later with >0 also confused the possibility.


>>>
>>> + */
>>> +int pci_std_enable_acs_sv(struct pci_dev *dev, bool enable)
>>> +{
>>> +   int pos;
>>> +   u16 cap;
>>> +   u16 ctrl;
>>> +   int retval;
>>> +
>>> +   pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS);
>>> +   if (!pos)
>>> +   return -ENODEV;
>>> +
>>> +   pci_read_config_word(dev, pos + PCI_ACS_CAP, );
>>> +   pci_read_config_word(dev, pos + PCI_ACS_CTRL, );
>>> +
>>> +   retval = !!(ctrl & cap & PCI_ACS_SV);
>>
>> If the device's ACS SV( ACS Source Validation) capability wasn't
>> implemented, the return value of this function will still tell us the
>> operation of enabling is successful ? though it might be rare case.
>
> If the ACS capability is implemented, then all bits are expected to have
> meaning and are valid. If SV is not implemented by the switch, the control
> bit for it should return zero (no source validation done). This is the PCI
> specification.  The onus is on the switch designer to keep it so.

PCI spec doesn't say SV must be implemented in every device even it
has ACS Cap, see also:

"6.12.1.2. ACS Functions in Multi-Function Devices This section
applies to multi-Function device ACS Functions, with the exception of
Downstream Port Functions, which are covered in the preceding section.
 ACS Source Validation: must not be implemented. 20  ACS Translation
Blocking: must not be implemented.  ACS P2P Request Redirect: must be
implemented by Functions that support peer-to-peer traffic with other
Functions.
"
Here pci_std_enable_acs_sv() is common function, once implemented,
possible be used by other code to enable acs beside this workaround.

Then how about it is called with a MF device ?

Thanks,
Ethan

>
> thanks,
> James
>
>
>>> +   if (enable)
>>> +   ctrl |= (cap & PCI_ACS_SV);
>>> +   else
>>> +   ctrl &= ~(cap & PCI_ACS_SV);
>>> +
>>> +   pci_write_config_word(dev, pos + PCI_ACS_CTRL, ctrl);
>>> +
>>> +   return retval;
>>> +}
>>> +
>>> +/**
>>>* pci_acs_enabled - test ACS against required flags for a given device
>>>* @pdev: device to test
>>>* @acs_flags: required PCI ACS flags
>>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>>> index 

Re: [PATCH v4] PCI: Workaround wrong flags completions for IDT switch

[Ethan Zhao]

James,

On Tue, Jul 4, 2017 at 2:17 AM, james puthukattukaran
 wrote:
>
> Ethan -
>
>
> On 7/2/2017 9:55 PM, Ethan Zhao wrote:
>>
>> James,
>>
>> On Wed, Jun 28, 2017 at 5:42 AM, James Puthukattukaran
>>  wrote:
>>>
>>> From: James Puthukattukaran 
>>>
>>> The IDT switch incorrectly flags an ACS source violation on a read config
>>> request to an end point device on the completion (IDT 89H32H8G3-YC,
>>> errata #36) even though the PCI Express spec states that completions are
>>> never affected by ACS source violation (PCI Spec 3.1, Section 6.12.1.1).
>>>
>>> The suggested workaround by IDT is to issue a configuration write to the
>>> downstream device before issuing the first config read. This allows the
>>> downstream device to capture its bus number, thus avoiding the ACS
>>> violation on the completion.
>>>
>>> The patch does the following -
>>>
>>> 1. Disable ACS source violation if enabled
>>> 2. Wait for config space access to become available by reading vendor id
>>> 3. Do a config write to the end point (errata workaround)
>>> 4. Enable ACS source validation (if it was enabled to begin with)
>>>
>>> -v2: move workaround to pci_bus_read_dev_vendor_id() from
>>> pci_bus_check_dev()
>>>   and move enable_acs_sv to drivers/pci/pci.c -- by Yinghai
>>> -v3: add bus->self check for root bus and virtual bus for sriov vfs.
>>> -v4: only do workaround for IDT switches
>>>
>>> Signed-off-by: James Puthukattukaran 
>>> Signed-off-by: Yinghai Lu 
>>>
>>> --
>>>
>>>   drivers/pci/pci.c   | 33 +
>>>   drivers/pci/pci.h   |  1 +
>>>   drivers/pci/probe.c | 38 --
>>>   3 files changed, 70 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 563901c..a7a2e2b 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -2835,6 +2835,39 @@ static bool pci_acs_flags_enabled(struct pci_dev
>>> *pdev, u16 acs_flags)
>>>   }
>>>
>>>   /**
>>> + *  pci_std_enable_acs_sv - enable/disable ACS source validation if
>>> supported by the switch
>>> + *  @dev - pcie switch/RP
>>> + *  @enable - enable (1) or disable (0) source validation
>>> + *
>>> + *  Returns : < 0 on failure
>>
>> You didn't define the meaning of 0 and >0, but you check it later against
>> >0,
>> Then what does it mean 0 and >0 ?
>
> see below..
>>
>>
>>> + *   previous acs_sv state
>
>
> It returns the previous acs_sv state (0 or 1).

You didn't clarify the meaning of previous acs_sv state, or possible value,
you check it later with >0 also confused the possibility.


>>>
>>> + */
>>> +int pci_std_enable_acs_sv(struct pci_dev *dev, bool enable)
>>> +{
>>> +   int pos;
>>> +   u16 cap;
>>> +   u16 ctrl;
>>> +   int retval;
>>> +
>>> +   pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS);
>>> +   if (!pos)
>>> +   return -ENODEV;
>>> +
>>> +   pci_read_config_word(dev, pos + PCI_ACS_CAP, );
>>> +   pci_read_config_word(dev, pos + PCI_ACS_CTRL, );
>>> +
>>> +   retval = !!(ctrl & cap & PCI_ACS_SV);
>>
>> If the device's ACS SV( ACS Source Validation) capability wasn't
>> implemented, the return value of this function will still tell us the
>> operation of enabling is successful ? though it might be rare case.
>
> If the ACS capability is implemented, then all bits are expected to have
> meaning and are valid. If SV is not implemented by the switch, the control
> bit for it should return zero (no source validation done). This is the PCI
> specification.  The onus is on the switch designer to keep it so.

PCI spec doesn't say SV must be implemented in every device even it
has ACS Cap, see also:

"6.12.1.2. ACS Functions in Multi-Function Devices This section
applies to multi-Function device ACS Functions, with the exception of
Downstream Port Functions, which are covered in the preceding section.
 ACS Source Validation: must not be implemented. 20  ACS Translation
Blocking: must not be implemented.  ACS P2P Request Redirect: must be
implemented by Functions that support peer-to-peer traffic with other
Functions.
"
Here pci_std_enable_acs_sv() is common function, once implemented,
possible be used by other code to enable acs beside this workaround.

Then how about it is called with a MF device ?

Thanks,
Ethan

>
> thanks,
> James
>
>
>>> +   if (enable)
>>> +   ctrl |= (cap & PCI_ACS_SV);
>>> +   else
>>> +   ctrl &= ~(cap & PCI_ACS_SV);
>>> +
>>> +   pci_write_config_word(dev, pos + PCI_ACS_CTRL, ctrl);
>>> +
>>> +   return retval;
>>> +}
>>> +
>>> +/**
>>>* pci_acs_enabled - test ACS against required flags for a given device
>>>* @pdev: device to test
>>>* @acs_flags: required PCI ACS flags
>>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>>> index f8113e5..3960c2a 100644
>>> --- a/drivers/pci/pci.h
>>> +++ b/drivers/pci/pci.h
>>> @@ -343,6 +343,7 @@ static inline resource_size_t
>>> pci_resource_alignment(struct 

Re: [PATCH v3 1/2] acpi: thermal: initialize tz_enabled to 1

[Zhang Rui]

On Mon, 2017-07-03 at 23:08 +0200, Rafael J. Wysocki wrote:
> On Mon, Jul 3, 2017 at 10:00 AM, Enric Balletbo i Serra
>  wrote:
> > 
> > From: Sameer Nanda 
> > 
> > In the acpi_thermal_add path, acpi_thermal_get_info gets called
> > before
> > acpi_thermal_register_thermal_zone.  Since tz_enabled was getting
> > set to
> > 1 only in acpi_thermal_register_thermal_zone, acpi_thermal_get_info
> > ended up disabling thermal polling.
> > 
> > Moved setting of tz_enabled to 1 into acpi_thermal_add itself.
> > 
> > Signed-off-by: Sameer Nanda 
> > Signed-off-by: Enric Balletbo i Serra  > >
> > ---
> > Changes since v2:
> >  - Zhang Rui:
> >    - Make sure tz->tz_enabled is set properly before registering
> > the zone.
> > 
> > Changes since v1:
> >  - This patch is new from v1 [1]
> > 
> >  [1] https://patchwork.kernel.org/patch/9804229/
> > 
> >  drivers/acpi/thermal.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> > index 1d0417b..cd0fe92 100644
> > --- a/drivers/acpi/thermal.c
> > +++ b/drivers/acpi/thermal.c
> > @@ -930,8 +930,6 @@ static int
> > acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
> > if (ACPI_FAILURE(status))
> > return -ENODEV;
> > 
> > -   tz->tz_enabled = 1;
> > -
> > dev_info(>device->dev, "registered as
> > thermal_zone%d\n",
> >  tz->thermal_zone->id);
> > return 0;
> > @@ -1088,6 +1086,7 @@ static int acpi_thermal_add(struct
> > acpi_device *device)
> > return -ENOMEM;
> > 
> > tz->device = device;
> > +   tz->tz_enabled = 1;
> > strcpy(tz->name, device->pnp.bus_id);
> > strcpy(acpi_device_name(device), ACPI_THERMAL_DEVICE_NAME);
> > strcpy(acpi_device_class(device), ACPI_THERMAL_CLASS);
> > --
> Rui,
> 
> Can I just apply this, or do I need to work for a thermal core
> update?
>  In the latter case, can you take care of this one too, please?
> 
Yes, I will take both of the patches.

thanks,
rui

> Thanks,
> Rafael

Re: [PATCH v3 1/2] acpi: thermal: initialize tz_enabled to 1

[Zhang Rui]

On Mon, 2017-07-03 at 23:08 +0200, Rafael J. Wysocki wrote:
> On Mon, Jul 3, 2017 at 10:00 AM, Enric Balletbo i Serra
>  wrote:
> > 
> > From: Sameer Nanda 
> > 
> > In the acpi_thermal_add path, acpi_thermal_get_info gets called
> > before
> > acpi_thermal_register_thermal_zone.  Since tz_enabled was getting
> > set to
> > 1 only in acpi_thermal_register_thermal_zone, acpi_thermal_get_info
> > ended up disabling thermal polling.
> > 
> > Moved setting of tz_enabled to 1 into acpi_thermal_add itself.
> > 
> > Signed-off-by: Sameer Nanda 
> > Signed-off-by: Enric Balletbo i Serra  > >
> > ---
> > Changes since v2:
> >  - Zhang Rui:
> >    - Make sure tz->tz_enabled is set properly before registering
> > the zone.
> > 
> > Changes since v1:
> >  - This patch is new from v1 [1]
> > 
> >  [1] https://patchwork.kernel.org/patch/9804229/
> > 
> >  drivers/acpi/thermal.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> > index 1d0417b..cd0fe92 100644
> > --- a/drivers/acpi/thermal.c
> > +++ b/drivers/acpi/thermal.c
> > @@ -930,8 +930,6 @@ static int
> > acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
> > if (ACPI_FAILURE(status))
> > return -ENODEV;
> > 
> > -   tz->tz_enabled = 1;
> > -
> > dev_info(>device->dev, "registered as
> > thermal_zone%d\n",
> >  tz->thermal_zone->id);
> > return 0;
> > @@ -1088,6 +1086,7 @@ static int acpi_thermal_add(struct
> > acpi_device *device)
> > return -ENOMEM;
> > 
> > tz->device = device;
> > +   tz->tz_enabled = 1;
> > strcpy(tz->name, device->pnp.bus_id);
> > strcpy(acpi_device_name(device), ACPI_THERMAL_DEVICE_NAME);
> > strcpy(acpi_device_class(device), ACPI_THERMAL_CLASS);
> > --
> Rui,
> 
> Can I just apply this, or do I need to work for a thermal core
> update?
>  In the latter case, can you take care of this one too, please?
> 
Yes, I will take both of the patches.

thanks,
rui

> Thanks,
> Rafael

Re: [GIT PULL] Char/Misc driver patches for 4.13-rc1

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 17:00:30 +0200 Greg KH  wrote:
>
> All of these have been in linux-next for a while with the only reported
> issue being a merge problem with this tree and the jc-docs tree in the
> w1 documentation area.  The fix should be obvious for what to do when it
> happens, if not, we can send a follow-up patch for it afterward.

I have been using this (after deleting Documentation/DocBook/w1.tmpl):

From: Stephen Rothwell 
Date: Wed, 14 Jun 2017 14:01:14 +1000
Subject: [PATCH] docs-rst: merge fix for "DocBook: w1: Update W1 file
 locations and names in DocBook"

Signed-off-by: Stephen Rothwell 
---
 Documentation/driver-api/w1.rst | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/driver-api/w1.rst b/Documentation/driver-api/w1.rst
index c1da8f0cb476..64826ceba2de 100644
--- a/Documentation/driver-api/w1.rst
+++ b/Documentation/driver-api/w1.rst
@@ -10,12 +10,12 @@ W1 API internal to the kernel
 W1 API internal to the kernel
 -
 
-drivers/w1/w1.h
-~~~
+include/linux/w1.h
+~~
 
-W1 core functions.
+W1 kernel API functions.
 
-.. kernel-doc:: drivers/w1/w1.h
+.. kernel-doc:: include/linux/w1.h
:internal:
 
 drivers/w1/w1.c
@@ -26,20 +26,20 @@ W1 core functions.
 .. kernel-doc:: drivers/w1/w1.c
:internal:
 
-drivers/w1/w1_family.h
+drivers/w1/w1_family.c
 ~~~
 
 Allows registering device family operations.
 
-.. kernel-doc:: drivers/w1/w1_family.h
-   :internal:
+.. kernel-doc:: drivers/w1/w1_family.c
+   :export:
 
-drivers/w1/w1_family.c
-~~~
+drivers/w1/w1_internal.h
+
 
-Allows registering device family operations.
+W1 internal initialization for master devices.
 
-.. kernel-doc:: drivers/w1/w1_family.c
+.. kernel-doc:: drivers/w1/w1_internal.h
:export:
 
 drivers/w1/w1_int.c
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [GIT PULL] Char/Misc driver patches for 4.13-rc1

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 17:00:30 +0200 Greg KH  wrote:
>
> All of these have been in linux-next for a while with the only reported
> issue being a merge problem with this tree and the jc-docs tree in the
> w1 documentation area.  The fix should be obvious for what to do when it
> happens, if not, we can send a follow-up patch for it afterward.

I have been using this (after deleting Documentation/DocBook/w1.tmpl):

From: Stephen Rothwell 
Date: Wed, 14 Jun 2017 14:01:14 +1000
Subject: [PATCH] docs-rst: merge fix for "DocBook: w1: Update W1 file
 locations and names in DocBook"

Signed-off-by: Stephen Rothwell 
---
 Documentation/driver-api/w1.rst | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/driver-api/w1.rst b/Documentation/driver-api/w1.rst
index c1da8f0cb476..64826ceba2de 100644
--- a/Documentation/driver-api/w1.rst
+++ b/Documentation/driver-api/w1.rst
@@ -10,12 +10,12 @@ W1 API internal to the kernel
 W1 API internal to the kernel
 -
 
-drivers/w1/w1.h
-~~~
+include/linux/w1.h
+~~
 
-W1 core functions.
+W1 kernel API functions.
 
-.. kernel-doc:: drivers/w1/w1.h
+.. kernel-doc:: include/linux/w1.h
:internal:
 
 drivers/w1/w1.c
@@ -26,20 +26,20 @@ W1 core functions.
 .. kernel-doc:: drivers/w1/w1.c
:internal:
 
-drivers/w1/w1_family.h
+drivers/w1/w1_family.c
 ~~~
 
 Allows registering device family operations.
 
-.. kernel-doc:: drivers/w1/w1_family.h
-   :internal:
+.. kernel-doc:: drivers/w1/w1_family.c
+   :export:
 
-drivers/w1/w1_family.c
-~~~
+drivers/w1/w1_internal.h
+
 
-Allows registering device family operations.
+W1 internal initialization for master devices.
 
-.. kernel-doc:: drivers/w1/w1_family.c
+.. kernel-doc:: drivers/w1/w1_internal.h
:export:
 
 drivers/w1/w1_int.c
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [GIT PULL] USB/PHY patches for 4.13-rc1

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 16:58:47 +0200 Greg KH  wrote:
>
> All of these have been in linux-next for a while with no reported
> issues.

I have been carrying the following merge fix patch for the merge
against the uuid tree (now in Linus' tree):

From: Stephen Rothwell 
Date: Thu, 29 Jun 2017 14:36:10 +1000
Subject: [PATCH] usb: typec: fix for "ACPI: Switch to use generic guid_t in
 acpi_evaluate_dsm()"

Signed-off-by: Stephen Rothwell 
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c 
b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 3fb2e48e1c91..7b7c9373a9b6 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -23,14 +23,14 @@ struct ucsi_acpi {
struct device *dev;
struct ucsi *ucsi;
struct ucsi_ppm ppm;
-   uuid_le uuid;
+   guid_t uuid;
 };
 
 static int ucsi_acpi_dsm(struct ucsi_acpi *ua, int func)
 {
union acpi_object *obj;
 
-   obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), ua->uuid.b, 1, func,
+   obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), >uuid, 1, func,
NULL);
if (!obj) {
dev_err(ua->dev, "%s: failed to evaluate _DSM %d\n",
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [GIT PULL] USB/PHY patches for 4.13-rc1

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 16:58:47 +0200 Greg KH  wrote:
>
> All of these have been in linux-next for a while with no reported
> issues.

I have been carrying the following merge fix patch for the merge
against the uuid tree (now in Linus' tree):

From: Stephen Rothwell 
Date: Thu, 29 Jun 2017 14:36:10 +1000
Subject: [PATCH] usb: typec: fix for "ACPI: Switch to use generic guid_t in
 acpi_evaluate_dsm()"

Signed-off-by: Stephen Rothwell 
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c 
b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 3fb2e48e1c91..7b7c9373a9b6 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -23,14 +23,14 @@ struct ucsi_acpi {
struct device *dev;
struct ucsi *ucsi;
struct ucsi_ppm ppm;
-   uuid_le uuid;
+   guid_t uuid;
 };
 
 static int ucsi_acpi_dsm(struct ucsi_acpi *ua, int func)
 {
union acpi_object *obj;
 
-   obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), ua->uuid.b, 1, func,
+   obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), >uuid, 1, func,
NULL);
if (!obj) {
dev_err(ua->dev, "%s: failed to evaluate _DSM %d\n",
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

RE: [PATCH v1] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

> -Original Message-
> From: Zhang, Tina
> Sent: Tuesday, July 4, 2017 9:04 AM
> To: alex.william...@redhat.com; kra...@redhat.com; ch...@chris-wilson.co.uk;
> zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A
> ; Tian, Kevin ; dan...@ffwll.ch;
> kwankh...@nvidia.com
> Cc: Zhang, Tina ; intel-...@lists.freedesktop.org; 
> intel-
> gvt-...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: [PATCH v1] vfio: ABI for mdev display dma-buf operation
> 
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query
> and get the plan and its related information.
> 
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be a new fd or an
> old fd of a re-exported dma-buf. Host User mode can check the value of fd and
> to see if it need to creat new resource according to the new fd or just use 
> the
> existed resource related to the old fd.
> 
> Signed-off-by: Tina Zhang 
> 
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index
> ae46105..c92bc69 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,6 +502,36 @@ struct vfio_pci_hot_reset {
> 
>  #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE + 13)
> 
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + *   struct vfio_device_query_gfx_plane)
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +struct vfio_device_gfx_plane_info {
> + __u64 start;
> + __u64 drm_format_mod;
> + __u32 drm_format;
> + __u32 width;
> + __u32 height;
> + __u32 stride;
> + __u32 size;
> + __u32 x_pos;
> + __u32 y_pos;
> +};
In this version, we don't rely on user mode to compare and find out whether a 
new dmabuf needs to be created. So, some of fields can be removed if user mode 
thinks they are not interesting any more. 

> +
> +struct vfio_device_query_gfx_plane {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_device_gfx_plane_info plane_info;
> + __u32 plane_type;
> + __s32 fd; /* dma-buf fd */
> + __u32 plane_id;
> +};
Still cannot figure out what the plane_id stands for in dmabuf case. As it 
might be needed by region usage, just add it here.

> +
> +#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
> +
> +
>  /*  API for Type1 VFIO IOMMU  */
> 
>  /**
> --
> 2.7.4

RE: [PATCH v1] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

> -Original Message-
> From: Zhang, Tina
> Sent: Tuesday, July 4, 2017 9:04 AM
> To: alex.william...@redhat.com; kra...@redhat.com; ch...@chris-wilson.co.uk;
> zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A
> ; Tian, Kevin ; dan...@ffwll.ch;
> kwankh...@nvidia.com
> Cc: Zhang, Tina ; intel-...@lists.freedesktop.org; 
> intel-
> gvt-...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: [PATCH v1] vfio: ABI for mdev display dma-buf operation
> 
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query
> and get the plan and its related information.
> 
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be a new fd or an
> old fd of a re-exported dma-buf. Host User mode can check the value of fd and
> to see if it need to creat new resource according to the new fd or just use 
> the
> existed resource related to the old fd.
> 
> Signed-off-by: Tina Zhang 
> 
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index
> ae46105..c92bc69 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,6 +502,36 @@ struct vfio_pci_hot_reset {
> 
>  #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE + 13)
> 
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + *   struct vfio_device_query_gfx_plane)
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +struct vfio_device_gfx_plane_info {
> + __u64 start;
> + __u64 drm_format_mod;
> + __u32 drm_format;
> + __u32 width;
> + __u32 height;
> + __u32 stride;
> + __u32 size;
> + __u32 x_pos;
> + __u32 y_pos;
> +};
In this version, we don't rely on user mode to compare and find out whether a 
new dmabuf needs to be created. So, some of fields can be removed if user mode 
thinks they are not interesting any more. 

> +
> +struct vfio_device_query_gfx_plane {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_device_gfx_plane_info plane_info;
> + __u32 plane_type;
> + __s32 fd; /* dma-buf fd */
> + __u32 plane_id;
> +};
Still cannot figure out what the plane_id stands for in dmabuf case. As it 
might be needed by region usage, just add it here.

> +
> +#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
> +
> +
>  /*  API for Type1 VFIO IOMMU  */
> 
>  /**
> --
> 2.7.4

Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment

[zhouxianrong]

the test was done as follows:

1. the environment is android 7.0 and kernel is 4.1 and managed memory is 3.5GB
2. every 4s startup one apk, total 100 more apks need to startup
3. after finishing step 2, sample buddyinfo once and get the result

On 2017/7/3 23:33, Michal Hocko wrote:

On Mon 03-07-17 20:02:16, zhouxianrong wrote:
[...]

from above i think after applying the patch the result is better.


You haven't described your testing methodology, nor the workload that was
tested. As such this data is completely meaningless.

Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment

[zhouxianrong]

the test was done as follows:

1. the environment is android 7.0 and kernel is 4.1 and managed memory is 3.5GB
2. every 4s startup one apk, total 100 more apks need to startup
3. after finishing step 2, sample buddyinfo once and get the result

On 2017/7/3 23:33, Michal Hocko wrote:

On Mon 03-07-17 20:02:16, zhouxianrong wrote:
[...]

from above i think after applying the patch the result is better.


You haven't described your testing methodology, nor the workload that was
tested. As such this data is completely meaningless.

[PATCH v1] vfio: ABI for mdev display dma-buf operation

[Tina Zhang]

Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
get the plan and its related information.

The dma-buf's life cycle is handled by user mode and tracked by kernel.
The returned fd in struct vfio_device_query_gfx_plane can be a new
fd or an old fd of a re-exported dma-buf. Host User mode can check the
value of fd and to see if it need to creat new resource according to the
new fd or just use the existed resource related to the old fd.

Signed-off-by: Tina Zhang 

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index ae46105..c92bc69 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -502,6 +502,36 @@ struct vfio_pci_hot_reset {
 
 #define VFIO_DEVICE_PCI_HOT_RESET  _IO(VFIO_TYPE, VFIO_BASE + 13)
 
+/**
+ * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
+ *   struct vfio_device_query_gfx_plane)
+ * Return: 0 on success, -errno on failure.
+ */
+
+struct vfio_device_gfx_plane_info {
+   __u64 start;
+   __u64 drm_format_mod;
+   __u32 drm_format;
+   __u32 width;
+   __u32 height;
+   __u32 stride;
+   __u32 size;
+   __u32 x_pos;
+   __u32 y_pos;
+};
+
+struct vfio_device_query_gfx_plane {
+   __u32 argsz;
+   __u32 flags;
+   struct vfio_device_gfx_plane_info plane_info;
+   __u32 plane_type;
+   __s32 fd; /* dma-buf fd */
+   __u32 plane_id;
+};
+
+#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
+
+
 /*  API for Type1 VFIO IOMMU  */
 
 /**
-- 
2.7.4

[PATCH v1] vfio: ABI for mdev display dma-buf operation

[Tina Zhang]

Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
get the plan and its related information.

The dma-buf's life cycle is handled by user mode and tracked by kernel.
The returned fd in struct vfio_device_query_gfx_plane can be a new
fd or an old fd of a re-exported dma-buf. Host User mode can check the
value of fd and to see if it need to creat new resource according to the
new fd or just use the existed resource related to the old fd.

Signed-off-by: Tina Zhang 

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index ae46105..c92bc69 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -502,6 +502,36 @@ struct vfio_pci_hot_reset {
 
 #define VFIO_DEVICE_PCI_HOT_RESET  _IO(VFIO_TYPE, VFIO_BASE + 13)
 
+/**
+ * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
+ *   struct vfio_device_query_gfx_plane)
+ * Return: 0 on success, -errno on failure.
+ */
+
+struct vfio_device_gfx_plane_info {
+   __u64 start;
+   __u64 drm_format_mod;
+   __u32 drm_format;
+   __u32 width;
+   __u32 height;
+   __u32 stride;
+   __u32 size;
+   __u32 x_pos;
+   __u32 y_pos;
+};
+
+struct vfio_device_query_gfx_plane {
+   __u32 argsz;
+   __u32 flags;
+   struct vfio_device_gfx_plane_info plane_info;
+   __u32 plane_type;
+   __s32 fd; /* dma-buf fd */
+   __u32 plane_id;
+};
+
+#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
+
+
 /*  API for Type1 VFIO IOMMU  */
 
 /**
-- 
2.7.4

Re: [GIT pull] x86/timers updates for 4.13

[Linus Torvalds]

On Mon, Jul 3, 2017 at 1:20 AM, Thomas Gleixner  wrote:
>
> This update contains:
>
>- The final solution for the TSC deadline timer borkage, which is caused
>  by a hardware problem in the TSC_ADJUST/TSC_DEADLINE_TIMER logic.
>
>  The problem is documented now fixed with a microcode update, so we can
>  remove the workaround and check for the microcode version. If the
>  microcode is not up to date, then the TSC deadline timer is
>  enabled. If the borkage is fixed by the proper micro code version,
>  then the deadline timer can be used. In both cases the restrictions to
>  the range of the TSC_ADJUST value, which were added as workarounds,
>  are removed.
>
>   - A few simple fixes and updates to the timer related x86 code.

That deadline timer explanation made no sense.

I edited it to what I think you wanted to say in the commit message.

   Linus

Re: [GIT pull] x86/timers updates for 4.13

[Linus Torvalds]

On Mon, Jul 3, 2017 at 1:20 AM, Thomas Gleixner  wrote:
>
> This update contains:
>
>- The final solution for the TSC deadline timer borkage, which is caused
>  by a hardware problem in the TSC_ADJUST/TSC_DEADLINE_TIMER logic.
>
>  The problem is documented now fixed with a microcode update, so we can
>  remove the workaround and check for the microcode version. If the
>  microcode is not up to date, then the TSC deadline timer is
>  enabled. If the borkage is fixed by the proper micro code version,
>  then the deadline timer can be used. In both cases the restrictions to
>  the range of the TSC_ADJUST value, which were added as workarounds,
>  are removed.
>
>   - A few simple fixes and updates to the timer related x86 code.

That deadline timer explanation made no sense.

I edited it to what I think you wanted to say in the commit message.

   Linus

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

[Paul E. McKenney]

On Mon, Jul 03, 2017 at 05:39:36PM -0700, Paul E. McKenney wrote:
> On Mon, Jul 03, 2017 at 03:49:42PM -0700, Linus Torvalds wrote:
> > On Mon, Jul 3, 2017 at 3:30 PM, Paul E. McKenney
> >  wrote:
> > >
> > > That certainly is one interesting function, isn't it?  I wonder what
> > > happens if you replace the raw_spin_is_locked() calls with an
> > > unlock under a trylock check?  ;-)
> > 
> > Deadlock due to interrupts again?
> 
> Unless I am missing something subtle, the kgdb_cpu_enter() function in
> question has a local_irq_save() over the "interesting" portion of its
> workings, so interrupt-handler self-deadlock should not happen.
> 
> > Didn't your spin_unlock_wait() patches teach you anything? Checking
> > state is fundamentally different from taking the lock. Even a trylock.
> 
> That was an embarrassing bug, no two ways about it.  :-/
> 
> > I guess you could try with the irqsave versions. But no, we're not doing 
> > that.
> 
> Again, no need in this case.
> 
> But I agree with Will's assessment of this function...
> 
> The raw_spin_is_locked() looks to be asking if -any- CPU holds the
> dbg_slave_lock, and the answer could of course change immediately
> on return from raw_spin_is_locked().  Perhaps the theory is that
> if other CPU holds the lock, this CPU is supposed to be subjected to
> kgdb_roundup_cpus().  Except that the CPU that held dbg_slave_lock might
> be just about to release that lock.  Odd.
> 
> Seems like there should be a get_online_cpus() somewhere, but maybe
> that constraint is to be manually enforced.

Except that invoking get_online_cpus() from an exception handler would
be of course be a spectacularly bad idea.  I would feel better if the
num_online_cpus() was under the local_irq_save(), but perhaps this code
is relying on the stop_machine().  Except that it appears we could
deadlock with offline waiting for stop_machine() to complete and kdbg
waiting for all CPUs to report, including those in stop_machine().

Looks like the current situation is "Don't use kdbg if there is any
possibility of CPU-hotplug operations."  Not necessarily an unreasonable
restriction.

But I need to let me eyes heal a bit before looking at this more.

Thanx, Paul

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

[Paul E. McKenney]

On Mon, Jul 03, 2017 at 05:39:36PM -0700, Paul E. McKenney wrote:
> On Mon, Jul 03, 2017 at 03:49:42PM -0700, Linus Torvalds wrote:
> > On Mon, Jul 3, 2017 at 3:30 PM, Paul E. McKenney
> >  wrote:
> > >
> > > That certainly is one interesting function, isn't it?  I wonder what
> > > happens if you replace the raw_spin_is_locked() calls with an
> > > unlock under a trylock check?  ;-)
> > 
> > Deadlock due to interrupts again?
> 
> Unless I am missing something subtle, the kgdb_cpu_enter() function in
> question has a local_irq_save() over the "interesting" portion of its
> workings, so interrupt-handler self-deadlock should not happen.
> 
> > Didn't your spin_unlock_wait() patches teach you anything? Checking
> > state is fundamentally different from taking the lock. Even a trylock.
> 
> That was an embarrassing bug, no two ways about it.  :-/
> 
> > I guess you could try with the irqsave versions. But no, we're not doing 
> > that.
> 
> Again, no need in this case.
> 
> But I agree with Will's assessment of this function...
> 
> The raw_spin_is_locked() looks to be asking if -any- CPU holds the
> dbg_slave_lock, and the answer could of course change immediately
> on return from raw_spin_is_locked().  Perhaps the theory is that
> if other CPU holds the lock, this CPU is supposed to be subjected to
> kgdb_roundup_cpus().  Except that the CPU that held dbg_slave_lock might
> be just about to release that lock.  Odd.
> 
> Seems like there should be a get_online_cpus() somewhere, but maybe
> that constraint is to be manually enforced.

Except that invoking get_online_cpus() from an exception handler would
be of course be a spectacularly bad idea.  I would feel better if the
num_online_cpus() was under the local_irq_save(), but perhaps this code
is relying on the stop_machine().  Except that it appears we could
deadlock with offline waiting for stop_machine() to complete and kdbg
waiting for all CPUs to report, including those in stop_machine().

Looks like the current situation is "Don't use kdbg if there is any
possibility of CPU-hotplug operations."  Not necessarily an unreasonable
restriction.

But I need to let me eyes heal a bit before looking at this more.

Thanx, Paul

Re: [PATCH v2 2/2] thermal: uniphier: add UniPhier thermal driver

[Kunihiko Hayashi]

Hi Eduardo,
Thank you for your comment.

On Fri, 30 Jun 2017 20:16:33 -0700  wrote:

> Hey,
> 
> On Wed, Jun 28, 2017 at 07:11:59PM +0900, Kunihiko Hayashi wrote:
> > Add a thermal driver for on-chip PVT (Process, Voltage and Temperature)
> > monitoring unit implemented on UniPhier SoCs. This driver supports
> > temperature monitoring and alert function.
> > 
> > Signed-off-by: Kunihiko Hayashi 
> > ---
> >  drivers/thermal/Kconfig|   8 +
> >  drivers/thermal/Makefile   |   1 +
> >  drivers/thermal/uniphier_thermal.c | 391 
> > +
> >  3 files changed, 400 insertions(+)
> >  create mode 100644 drivers/thermal/uniphier_thermal.c

(snip)

> > +static void uniphier_tm_enable_sensor(struct uniphier_tm_dev *tdev)
> > +{
> > +   struct regmap *map = tdev->regmap;
> > +   int i;
> > +   u32 bits = 0;
> > +
> > +   for (i = 0; i < ALERT_CH_NUM; i++)
> > +   if (tdev->alert_en[i])
> > +   bits |= PMALERTINTCTL_EN(i);
> > +
> > +   /* enable alert interrupt */
> > +   regmap_write_bits(map, tdev->data->map_base + PMALERTINTCTL,
> > + PMALERTINTCTL_MASK, bits);
> > +
> > +   /* start PVT */
> > +   regmap_write_bits(map, tdev->data->block_base + PVTCTLEN,
> > + PVTCTLEN_EN, PVTCTLEN_EN);
> 
> Do we need to wait some time after starting PVT and before reading the
> first temperature?

Thanks for your pointing out.

According to the spec sheet, we can read first temperature
with waiting 700us after starting PVT. And after disabling PVT,
we must wait 1ms until next access.

I'll add "nsleep" after accessing PVTCTLEN in
uniphier_tm_{enable,disable}_sensor().

> > +}
> > +
> > +static void uniphier_tm_disable_sensor(struct uniphier_tm_dev *tdev)
> > +{
> > +   struct regmap *map = tdev->regmap;
> > +
> > +   /* disable alert interrupt */
> > +   regmap_write_bits(map, tdev->data->map_base + PMALERTINTCTL,
> > + PMALERTINTCTL_MASK, 0);
> > +
> > +   /* stop PVT */
> > +   regmap_write_bits(map, tdev->data->block_base + PVTCTLEN,
> > + PVTCTLEN_EN, 0);
> > +}
> > +
> > +static int uniphier_tm_get_temp(void *data, int *out_temp)
> > +{
> > +   struct uniphier_tm_dev *tdev = data;
> > +   struct regmap *map = tdev->regmap;
> > +   int ret;
> > +   u32 temp;
> > +
> > +   ret = regmap_read(map, tdev->data->map_base + TMOD, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   /*
> > +* Since MSB of TMOD_MASK in TMOD represents signed bit,
> > +* if the register value is bigger than or equal to
> > +* ((TMOD_MASK + 1) / 2), it represents a negative value
> > +* of temperature.
> > +*/
> > +   temp &= TMOD_MASK;
> > +   if (temp >= ((TMOD_MASK + 1) / 2))
> > +   *out_temp = (temp - (TMOD_MASK + 1)) * 1000;
> 
> But, why do you mask negative values? Are you considering them invalid?
> should this be reported? Why simply silently transforming into positive?

My explanation comment is insufficient.
The whole TMOD register doesn't represent temperature value.

TMOD[31:9] has always 0 as reserved bits.
TMOD[8:0] has 2's complement value of temperature (Celsius)
represented by 9bits.
For example, when we read 0x1ff from the TMOD, it means -1.

Then according to linux/bitops.h,
it can be replaced with "*out_temp = sign_extend32(temp, 9)" simply.

Best Regards,
Kunihiko Hayashi

Re: [PATCH v2 2/2] thermal: uniphier: add UniPhier thermal driver

[Kunihiko Hayashi]

Hi Eduardo,
Thank you for your comment.

On Fri, 30 Jun 2017 20:16:33 -0700  wrote:

> Hey,
> 
> On Wed, Jun 28, 2017 at 07:11:59PM +0900, Kunihiko Hayashi wrote:
> > Add a thermal driver for on-chip PVT (Process, Voltage and Temperature)
> > monitoring unit implemented on UniPhier SoCs. This driver supports
> > temperature monitoring and alert function.
> > 
> > Signed-off-by: Kunihiko Hayashi 
> > ---
> >  drivers/thermal/Kconfig|   8 +
> >  drivers/thermal/Makefile   |   1 +
> >  drivers/thermal/uniphier_thermal.c | 391 
> > +
> >  3 files changed, 400 insertions(+)
> >  create mode 100644 drivers/thermal/uniphier_thermal.c

(snip)

> > +static void uniphier_tm_enable_sensor(struct uniphier_tm_dev *tdev)
> > +{
> > +   struct regmap *map = tdev->regmap;
> > +   int i;
> > +   u32 bits = 0;
> > +
> > +   for (i = 0; i < ALERT_CH_NUM; i++)
> > +   if (tdev->alert_en[i])
> > +   bits |= PMALERTINTCTL_EN(i);
> > +
> > +   /* enable alert interrupt */
> > +   regmap_write_bits(map, tdev->data->map_base + PMALERTINTCTL,
> > + PMALERTINTCTL_MASK, bits);
> > +
> > +   /* start PVT */
> > +   regmap_write_bits(map, tdev->data->block_base + PVTCTLEN,
> > + PVTCTLEN_EN, PVTCTLEN_EN);
> 
> Do we need to wait some time after starting PVT and before reading the
> first temperature?

Thanks for your pointing out.

According to the spec sheet, we can read first temperature
with waiting 700us after starting PVT. And after disabling PVT,
we must wait 1ms until next access.

I'll add "nsleep" after accessing PVTCTLEN in
uniphier_tm_{enable,disable}_sensor().

> > +}
> > +
> > +static void uniphier_tm_disable_sensor(struct uniphier_tm_dev *tdev)
> > +{
> > +   struct regmap *map = tdev->regmap;
> > +
> > +   /* disable alert interrupt */
> > +   regmap_write_bits(map, tdev->data->map_base + PMALERTINTCTL,
> > + PMALERTINTCTL_MASK, 0);
> > +
> > +   /* stop PVT */
> > +   regmap_write_bits(map, tdev->data->block_base + PVTCTLEN,
> > + PVTCTLEN_EN, 0);
> > +}
> > +
> > +static int uniphier_tm_get_temp(void *data, int *out_temp)
> > +{
> > +   struct uniphier_tm_dev *tdev = data;
> > +   struct regmap *map = tdev->regmap;
> > +   int ret;
> > +   u32 temp;
> > +
> > +   ret = regmap_read(map, tdev->data->map_base + TMOD, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   /*
> > +* Since MSB of TMOD_MASK in TMOD represents signed bit,
> > +* if the register value is bigger than or equal to
> > +* ((TMOD_MASK + 1) / 2), it represents a negative value
> > +* of temperature.
> > +*/
> > +   temp &= TMOD_MASK;
> > +   if (temp >= ((TMOD_MASK + 1) / 2))
> > +   *out_temp = (temp - (TMOD_MASK + 1)) * 1000;
> 
> But, why do you mask negative values? Are you considering them invalid?
> should this be reported? Why simply silently transforming into positive?

My explanation comment is insufficient.
The whole TMOD register doesn't represent temperature value.

TMOD[31:9] has always 0 as reserved bits.
TMOD[8:0] has 2's complement value of temperature (Celsius)
represented by 9bits.
For example, when we read 0x1ff from the TMOD, it means -1.

Then according to linux/bitops.h,
it can be replaced with "*out_temp = sign_extend32(temp, 9)" simply.

Best Regards,
Kunihiko Hayashi

RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Daniel Vetter
> Sent: Thursday, June 29, 2017 4:39 PM
> To: Gerd Hoffmann 
> Cc: Wang, Zhenyu Z ; intel-
> g...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Chen, Xiaoguang
> ; Zhang, Tina ; Alex
> Williamson ; Lv, Zhiyuan
> ; Kirti Wankhede ; intel-gvt-
> d...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
> 
> On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> >
> > > > Does gvt track the live cycle of all dma-bufs it has handed out?
> > >
> > > The V9 implementation does track the dma-bufs' live cycle. The
> > > original idea was that leaving the dma-bufs' live cycle management
> > > to user mode.
> >
> > That is still the case, user space decides which dma-bufs it'll go
> > keep cached.  But kernel space can see what user space is doing, so
> > there is no need to explicitly tell the kernel whenever a cached
> > dma-buf exists or not.
> 
> We do the same trick in drm_prime.c, keeping a cache of exported dma-buf
> around for re-exporting. Since for prime sharing the use-case is almost always
> re-importing as a drm gem buffer again we can then on re-import also tell
> userspace whether it already has that buffer in it's userspace buffer manager,
> but that's an additional optimization. With plain dma-buf we could achieve the
> same by wiring up a real stat() implementation with unique inode numbers (atm
> they all share the anon_inode singleton). But thus far no one asked for that.

Thanks. I'm going to submit the v10 version of ABI interface.

> 
> btw I'm lost a bit in the discussion (was on vacation), but I think all the 
> concerns
> I've noticed with the initial rfc have been raised already, so things look 
> good. I'll
> check the next rfc once that shows up.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Daniel Vetter
> Sent: Thursday, June 29, 2017 4:39 PM
> To: Gerd Hoffmann 
> Cc: Wang, Zhenyu Z ; intel-
> g...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Chen, Xiaoguang
> ; Zhang, Tina ; Alex
> Williamson ; Lv, Zhiyuan
> ; Kirti Wankhede ; intel-gvt-
> d...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
> 
> On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> >
> > > > Does gvt track the live cycle of all dma-bufs it has handed out?
> > >
> > > The V9 implementation does track the dma-bufs' live cycle. The
> > > original idea was that leaving the dma-bufs' live cycle management
> > > to user mode.
> >
> > That is still the case, user space decides which dma-bufs it'll go
> > keep cached.  But kernel space can see what user space is doing, so
> > there is no need to explicitly tell the kernel whenever a cached
> > dma-buf exists or not.
> 
> We do the same trick in drm_prime.c, keeping a cache of exported dma-buf
> around for re-exporting. Since for prime sharing the use-case is almost always
> re-importing as a drm gem buffer again we can then on re-import also tell
> userspace whether it already has that buffer in it's userspace buffer manager,
> but that's an additional optimization. With plain dma-buf we could achieve the
> same by wiring up a real stat() implementation with unique inode numbers (atm
> they all share the anon_inode singleton). But thus far no one asked for that.

Thanks. I'm going to submit the v10 version of ABI interface.

> 
> btw I'm lost a bit in the discussion (was on vacation), but I think all the 
> concerns
> I've noticed with the initial rfc have been raised already, so things look 
> good. I'll
> check the next rfc once that shows up.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

Re: [PATCH 2/3] mtd: spi-nor: core code for the Altera Quadspi Flash Controller v2

[Cyrille Pitchen]

Hi Matthew,


Le 26/06/2017 à 18:13, matthew.gerl...@linux.intel.com a écrit :
> From: Matthew Gerlach 
> 
> Signed-off-by: Matthew Gerlach 
> ---
>  MAINTAINERS  |   7 +
>  drivers/mtd/spi-nor/Kconfig  |   5 +
>  drivers/mtd/spi-nor/Makefile |   4 +-
>  drivers/mtd/spi-nor/altera-quadspi.c | 676 
> +++
>  include/linux/mtd/altera-quadspi.h   |  28 ++
>  5 files changed, 719 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/spi-nor/altera-quadspi.c
>  create mode 100644 include/linux/mtd/altera-quadspi.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6b4395c..ae33fa6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -648,6 +648,13 @@ L:   linux-g...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/gpio/gpio-altera.c
>  
> +ALTERA QUADSPI FLASH DRIVER
> +M:   Matthew Gerlach 
> +L:   linux-...@lists.infradead.org
> +S:   Maintained
> +F:   drivers/mtd/spi-nor/altera-quadspi.c
> +F:   inclulde/linux/mtd/altera-quadspi.h
> +
>  ALTERA SYSTEM RESOURCE DRIVER FOR ARRIA10 DEVKIT
>  M:   Thor Thayer 
>  S:   Maintained
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 293c8a4..89fe425 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -113,4 +113,9 @@ config SPI_STM32_QUADSPI
> This enables support for the STM32 Quad SPI controller.
> We only connect the NOR to this controller.
>  
> +config SPI_ALTERA_QUADSPI
> +tristate "Altera Quad SPI Flash Controller II"
> +help
> +  Enable support for version 2 of Altera Quad SPI Flash Controller.
> +
>  endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 285aab8..024c6ac 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -8,4 +8,6 @@ obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
>  obj-$(CONFIG_SPI_INTEL_SPI)  += intel-spi.o
>  obj-$(CONFIG_SPI_INTEL_SPI_PLATFORM) += intel-spi-platform.o
> -obj-$(CONFIG_SPI_STM32_QUADSPI)  += stm32-quadspi.o
> \ No newline at end of file
> +obj-$(CONFIG_SPI_STM32_QUADSPI)  += stm32-quadspi.o
> +obj-$(CONFIG_SPI_ALTERA_QUADSPI) += altera-quadspi.o
> +
> diff --git a/drivers/mtd/spi-nor/altera-quadspi.c 
> b/drivers/mtd/spi-nor/altera-quadspi.c
> new file mode 100644
> index 000..de65453
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/altera-quadspi.c
> @@ -0,0 +1,676 @@
> +/*
> + * Copyright (C) 2014 Altera Corporation. All rights reserved.
> + * Copyright (C) 2017 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ALTERA_QUADSPI_RESOURCE_NAME "altera_quadspi"
> +
> +#define EPCS_OPCODE_ID   1
> +#define NON_EPCS_OPCODE_ID   2
> +
> +#define WRITE_CHECK  1
> +#define ERASE_CHECK  0
> +
> +#define QUADSPI_SR_REG   0x0
> +#define QUADSPI_SR_MASK  0x000F
> +
> +/* defines for device id register */
> +#define QUADSPI_SID_REG  0x4
> +#define QUADSPI_RDID_REG 0x8
> +#define QUADSPI_ID_MASK  0x00FF
> +
> +/*
> + * QUADSPI_MEM_OP register offset
> + *
> + * The QUADSPI_MEM_OP register is used to do memory protect and erase 
> operations
> + *
> + */
> +#define QUADSPI_MEM_OP_REG   0xC
> +
> +#define QUADSPI_MEM_OP_CMD_MASK  0x0003
> +#define QUADSPI_MEM_OP_BULK_ERASE_CMD0x0001
> +#define QUADSPI_MEM_OP_SECTOR_ERASE_CMD  0x0002
> +#define QUADSPI_MEM_OP_SECTOR_PROTECT_CMD0x0003
> +#define QUADSPI_MEM_OP_SECTOR_WRITE_ENABLE_CMD   0x0004
> +#define QUADSPI_MEM_OP_SECTOR_VALUE_MASK 0x0003FF00
> +
> +#define QUADSPI_MEM_OP_SECTOR_PROTECT_SHIFT  8
> +#define QUADSPI_MEM_OP_SECTOR_PROTECT_VALUE_MASK 0x1F00

Re: [PATCH 2/3] mtd: spi-nor: core code for the Altera Quadspi Flash Controller v2

[Cyrille Pitchen]

Hi Matthew,


Le 26/06/2017 à 18:13, matthew.gerl...@linux.intel.com a écrit :
> From: Matthew Gerlach 
> 
> Signed-off-by: Matthew Gerlach 
> ---
>  MAINTAINERS  |   7 +
>  drivers/mtd/spi-nor/Kconfig  |   5 +
>  drivers/mtd/spi-nor/Makefile |   4 +-
>  drivers/mtd/spi-nor/altera-quadspi.c | 676 
> +++
>  include/linux/mtd/altera-quadspi.h   |  28 ++
>  5 files changed, 719 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/spi-nor/altera-quadspi.c
>  create mode 100644 include/linux/mtd/altera-quadspi.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6b4395c..ae33fa6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -648,6 +648,13 @@ L:   linux-g...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/gpio/gpio-altera.c
>  
> +ALTERA QUADSPI FLASH DRIVER
> +M:   Matthew Gerlach 
> +L:   linux-...@lists.infradead.org
> +S:   Maintained
> +F:   drivers/mtd/spi-nor/altera-quadspi.c
> +F:   inclulde/linux/mtd/altera-quadspi.h
> +
>  ALTERA SYSTEM RESOURCE DRIVER FOR ARRIA10 DEVKIT
>  M:   Thor Thayer 
>  S:   Maintained
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 293c8a4..89fe425 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -113,4 +113,9 @@ config SPI_STM32_QUADSPI
> This enables support for the STM32 Quad SPI controller.
> We only connect the NOR to this controller.
>  
> +config SPI_ALTERA_QUADSPI
> +tristate "Altera Quad SPI Flash Controller II"
> +help
> +  Enable support for version 2 of Altera Quad SPI Flash Controller.
> +
>  endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 285aab8..024c6ac 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -8,4 +8,6 @@ obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
>  obj-$(CONFIG_SPI_INTEL_SPI)  += intel-spi.o
>  obj-$(CONFIG_SPI_INTEL_SPI_PLATFORM) += intel-spi-platform.o
> -obj-$(CONFIG_SPI_STM32_QUADSPI)  += stm32-quadspi.o
> \ No newline at end of file
> +obj-$(CONFIG_SPI_STM32_QUADSPI)  += stm32-quadspi.o
> +obj-$(CONFIG_SPI_ALTERA_QUADSPI) += altera-quadspi.o
> +
> diff --git a/drivers/mtd/spi-nor/altera-quadspi.c 
> b/drivers/mtd/spi-nor/altera-quadspi.c
> new file mode 100644
> index 000..de65453
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/altera-quadspi.c
> @@ -0,0 +1,676 @@
> +/*
> + * Copyright (C) 2014 Altera Corporation. All rights reserved.
> + * Copyright (C) 2017 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ALTERA_QUADSPI_RESOURCE_NAME "altera_quadspi"
> +
> +#define EPCS_OPCODE_ID   1
> +#define NON_EPCS_OPCODE_ID   2
> +
> +#define WRITE_CHECK  1
> +#define ERASE_CHECK  0
> +
> +#define QUADSPI_SR_REG   0x0
> +#define QUADSPI_SR_MASK  0x000F
> +
> +/* defines for device id register */
> +#define QUADSPI_SID_REG  0x4
> +#define QUADSPI_RDID_REG 0x8
> +#define QUADSPI_ID_MASK  0x00FF
> +
> +/*
> + * QUADSPI_MEM_OP register offset
> + *
> + * The QUADSPI_MEM_OP register is used to do memory protect and erase 
> operations
> + *
> + */
> +#define QUADSPI_MEM_OP_REG   0xC
> +
> +#define QUADSPI_MEM_OP_CMD_MASK  0x0003
> +#define QUADSPI_MEM_OP_BULK_ERASE_CMD0x0001
> +#define QUADSPI_MEM_OP_SECTOR_ERASE_CMD  0x0002
> +#define QUADSPI_MEM_OP_SECTOR_PROTECT_CMD0x0003
> +#define QUADSPI_MEM_OP_SECTOR_WRITE_ENABLE_CMD   0x0004
> +#define QUADSPI_MEM_OP_SECTOR_VALUE_MASK 0x0003FF00
> +
> +#define QUADSPI_MEM_OP_SECTOR_PROTECT_SHIFT  8
> +#define QUADSPI_MEM_OP_SECTOR_PROTECT_VALUE_MASK 0x1F00
> +/*
> + * QUADSPI_ISR register offset
> + *
> + * The QUADSPI_ISR register is used to determine whether an invalid write or
> 

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

[Paul E. McKenney]

On Mon, Jul 03, 2017 at 03:49:42PM -0700, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 3:30 PM, Paul E. McKenney
>  wrote:
> >
> > That certainly is one interesting function, isn't it?  I wonder what
> > happens if you replace the raw_spin_is_locked() calls with an
> > unlock under a trylock check?  ;-)
> 
> Deadlock due to interrupts again?

Unless I am missing something subtle, the kgdb_cpu_enter() function in
question has a local_irq_save() over the "interesting" portion of its
workings, so interrupt-handler self-deadlock should not happen.

> Didn't your spin_unlock_wait() patches teach you anything? Checking
> state is fundamentally different from taking the lock. Even a trylock.

That was an embarrassing bug, no two ways about it.  :-/

> I guess you could try with the irqsave versions. But no, we're not doing that.

Again, no need in this case.

But I agree with Will's assessment of this function...

The raw_spin_is_locked() looks to be asking if -any- CPU holds the
dbg_slave_lock, and the answer could of course change immediately
on return from raw_spin_is_locked().  Perhaps the theory is that
if other CPU holds the lock, this CPU is supposed to be subjected to
kgdb_roundup_cpus().  Except that the CPU that held dbg_slave_lock might
be just about to release that lock.  Odd.

Seems like there should be a get_online_cpus() somewhere, but maybe
that constraint is to be manually enforced.

Thanx, Paul

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

[Paul E. McKenney]

On Mon, Jul 03, 2017 at 03:49:42PM -0700, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 3:30 PM, Paul E. McKenney
>  wrote:
> >
> > That certainly is one interesting function, isn't it?  I wonder what
> > happens if you replace the raw_spin_is_locked() calls with an
> > unlock under a trylock check?  ;-)
> 
> Deadlock due to interrupts again?

Unless I am missing something subtle, the kgdb_cpu_enter() function in
question has a local_irq_save() over the "interesting" portion of its
workings, so interrupt-handler self-deadlock should not happen.

> Didn't your spin_unlock_wait() patches teach you anything? Checking
> state is fundamentally different from taking the lock. Even a trylock.

That was an embarrassing bug, no two ways about it.  :-/

> I guess you could try with the irqsave versions. But no, we're not doing that.

Again, no need in this case.

But I agree with Will's assessment of this function...

The raw_spin_is_locked() looks to be asking if -any- CPU holds the
dbg_slave_lock, and the answer could of course change immediately
on return from raw_spin_is_locked().  Perhaps the theory is that
if other CPU holds the lock, this CPU is supposed to be subjected to
kgdb_roundup_cpus().  Except that the CPU that held dbg_slave_lock might
be just about to release that lock.  Odd.

Seems like there should be a get_online_cpus() somewhere, but maybe
that constraint is to be manually enforced.

Thanx, Paul

Re: [PATCH 1/2] selftests: ftrace: Do not failure if there is unsupported tests

[Masami Hiramatsu]

On Mon, 3 Jul 2017 11:59:06 -0400
Steven Rostedt  wrote:

> On Tue, 4 Jul 2017 00:52:32 +0900
> Masami Hiramatsu  wrote:
> > 
> > > 
> > > Can we add an option in kselftest, or to ftracetest that decides if
> > > unsupported is a failure or not? Otherwise I can not ack this patch.  
> > 
> > I would rather like to add an option to ftracetest instead of
> > kselftest, because whether the tested feature should be supported
> > or not is hard to decide from testing framework. It should be
> > checked by manual.
> 
> Can we do both? That is, add an option to have ftracetest not fail on
> "unsupported" but have it fail by default. We can have kselftest just
> pass in a parameter to ftracetest that has unsupported not fail?

I rather like to treat unsupported as success (or XFAIL) by default
and add "--fail-unsupported" option.

Thank you,

> But if that is too difficult, then I can live with modifying my test
> case to add the option.
> 
> -- Steve


-- 
Masami Hiramatsu 

Re: [PATCH 1/2] selftests: ftrace: Do not failure if there is unsupported tests

[Masami Hiramatsu]

On Mon, 3 Jul 2017 11:59:06 -0400
Steven Rostedt  wrote:

> On Tue, 4 Jul 2017 00:52:32 +0900
> Masami Hiramatsu  wrote:
> > 
> > > 
> > > Can we add an option in kselftest, or to ftracetest that decides if
> > > unsupported is a failure or not? Otherwise I can not ack this patch.  
> > 
> > I would rather like to add an option to ftracetest instead of
> > kselftest, because whether the tested feature should be supported
> > or not is hard to decide from testing framework. It should be
> > checked by manual.
> 
> Can we do both? That is, add an option to have ftracetest not fail on
> "unsupported" but have it fail by default. We can have kselftest just
> pass in a parameter to ftracetest that has unsupported not fail?

I rather like to treat unsupported as success (or XFAIL) by default
and add "--fail-unsupported" option.

Thank you,

> But if that is too difficult, then I can live with modifying my test
> case to add the option.
> 
> -- Steve


-- 
Masami Hiramatsu 

Re: [PATCH] aic7xxx: fix firmware build with O=path

[Jakub Kicinski]

On Wed, 28 Jun 2017 21:17:16 -0700, Jakub Kicinski wrote:
> Building firmware with O=path was apparently broken in aic7 for ever.
> Message of the previous commit to the Makefile (from 2008) mentions
> this unfortunate state of affairs already.  Fix this, mostly to make
> randconfig builds more reliable.
> 
> Signed-off-by: Jakub Kicinski 

Did anyone have a chance to look at this one?  It would be nice if it
could make its way into 4.13 :)

Re: [PATCH] aic7xxx: fix firmware build with O=path

[Jakub Kicinski]

On Wed, 28 Jun 2017 21:17:16 -0700, Jakub Kicinski wrote:
> Building firmware with O=path was apparently broken in aic7 for ever.
> Message of the previous commit to the Makefile (from 2008) mentions
> this unfortunate state of affairs already.  Fix this, mostly to make
> randconfig builds more reliable.
> 
> Signed-off-by: Jakub Kicinski 

Did anyone have a chance to look at this one?  It would be nice if it
could make its way into 4.13 :)