Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver
Hi John, On Thursday 19 May 2016 06:50:56, John Crispin wrote: > On 18/05/2016 18:24, Florian Fainelli wrote: > > CC'ing Andrew, John, > > also CC'ing Matthias and Hauke. we have had a driver in OpenWrt/LEDE for > several years that seems a little more complete than this one. > > https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/lantiq/patc > hes-4.4/0023-NET-PHY-adds-driver-for-lantiq-PHY11G.patch;h=93bb4275ec1d261f3 > 98afb8fdc879c1dd973f997;hb=HEAD Thanks for the link, I wasn't aware of that patch. I like it in general, but there are some things I'd like to get addressed first: * vr9_gphy_of_reg_init() writes uncoditionally to led3h and led3l even on PEf7071 which does not have this register at all * Why is PHY_HAS_INTERRUPT commented out everywhere? * ltq_phy_init and ltq_phy_exit can be simplified using phy_drivers_register and phy_drivers_unregister * A mdio_device_id table is missing Best regards, Alexander
[PATCH 2/2] ARM: dts: am335x-icev2: Add DT node for TI PCA9536
AM335x ICE board has a TI PCA9536 chip connected to I2C0 at address
0x41. Add DT entry for the same.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/am335x-icev2.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-icev2.dts
b/arch/arm/boot/dts/am335x-icev2.dts
index e271013e78a6..7d8b8fefdf08 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -206,6 +206,13 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ pca9536: gpio@41 {
+ compatible = "ti,pca9536";
+ reg = <0x41>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
#include "tps65910.dtsi"
--
2.8.2
[PATCH 0/2] AM335x ICE: Add support for PCA9536 GPIO expander
This patch series adds support for TI PCA9536 GPIO expander present on AM335x ICE board. Vignesh R (2): gpio: pca953x: Add support for TI PCA9536 ARM: dts: am335x-icev2: Add DT node for TI PCA9536 Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 + arch/arm/boot/dts/am335x-icev2.dts | 7 +++ drivers/gpio/gpio-pca953x.c | 1 + 3 files changed, 9 insertions(+) -- 2.8.2
[PATCH 1/2] gpio: pca953x: Add support for TI PCA9536
TI PCA9536 is 4-Bit I2C GPIO expander without interrupt support[1].
Add support for the same.
[1] TRM: http://www.ti.com/lit/ds/symlink/pca9536.pdf
Signed-off-by: Vignesh R
---
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 +
drivers/gpio/gpio-pca953x.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
index 6b4a98f74be3..08dd15f89ba9 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
@@ -21,6 +21,7 @@ Required properties:
maxim,max7313
maxim,max7315
ti,pca6107
+ ti,pca9536
ti,tca6408
ti,tca6416
ti,tca6424
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 5e3be32ebb8d..763028562d22 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -861,6 +861,7 @@ static const struct of_device_id pca953x_dt_ids[] = {
{ .compatible = "maxim,max7315", .data = OF_953X( 8, PCA_INT), },
{ .compatible = "ti,pca6107", .data = OF_953X( 8, PCA_INT), },
+ { .compatible = "ti,pca9536", .data = OF_953X( 4, 0), },
{ .compatible = "ti,tca6408", .data = OF_953X( 8, PCA_INT), },
{ .compatible = "ti,tca6416", .data = OF_953X(16, PCA_INT), },
{ .compatible = "ti,tca6424", .data = OF_953X(24, PCA_INT), },
--
2.8.2
[PATCH] printk: add tgid and comm in dump_stack_print_info
Some threads'name of android is the same in different process.
So we need to get the tgid and the comm of thread's group_leader.
Signed-off-by: Liu Hailong
---
kernel/printk/printk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index bfbf284..84246b3 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3166,6 +3166,9 @@ void dump_stack_print_info(const char *log_lvl)
(int)strcspn(init_utsname()->version, " "),
init_utsname()->version);
+ printk("TGID: %d Comm: %.20s\n",
+ current->tgid, current->group_leader->comm);
+
if (dump_stack_arch_desc_str[0] != '\0')
printk("%sHardware name: %s\n",
log_lvl, dump_stack_arch_desc_str);
--
1.8.3.2
linux-next: Tree for May 19
Hi all,
Please do not add any v4.8 destined material to your linux-next included
branches until after v4.7-rc1 has been released.
Changes since 20160518:
The nfs tree gained a conflict against Linus' tree and a build failure
for which I applied a merge fix patch.
The vfs tree gained a conflict against Linus' tree.
The rdma tree gained conflicts against Linus' and the nfs trees.
The security tree gained a build failure for which I applied a merge
fix patch.
Non-merge commits (relative to Linus' tree): 6082
5050 files changed, 271582 insertions(+), 113615 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
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.
Below is a summary of the state of the merge.
I am currently merging 236 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).
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 (4a5219edcdae Merge tag 'armsoc-drivers' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move
{set,get}_domain under config guard)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (0b7962a6c4a3 Merge branch 'for-4.7' of
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag
'iwlwifi-for-kalle-2016-05-04' of
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if
dev_alloc_name() fails)
Merging sound-current/for-linus (17e1717c11a3 ALSA: firewire-lib: change a
member of event structure to suppress sparse wanings to bool type)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg:
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (23ea5967d6bd Merge branch 'next' into
for-linus)
Merging crypto-current/master (4a6b27b79da5 crypto: sha1-mb - make
s
Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure
On 19/05/16 16:22, Michael Ellerman wrote: Did you test the plugins with all gcc versions (4.5-6)? What's the concern about gcc versions? Just not breaking the build on old compilers? I'm pretty sure powerpc big endian still builds with gcc 4.4. gcc's plugin support only landed in 4.5, so we don't care about <=4.4. However if Andrew's only tested on little endian, then that select should be guarded with an "if CPU_LITTLE_ENDIAN". And to build LE you need gcc >= 4.9. I'm going to give BE a test too just to be sure. -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnel...@au1.ibm.com IBM Australia Limited
[PATCH 2/2] lightnvm: hold nvm_lock until finish the target creation
From: Wenwei Tao
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target creation.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 160c1a6..a622081 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -791,6 +791,7 @@ static int nvm_create_target(struct nvm_dev *dev,
struct nvm_tgt_type *tt;
struct nvm_target *t;
void *targetdata;
+ int ret = -ENOMEM;
if (!dev->mt) {
pr_info("nvm: device has no media manager registered.\n");
@@ -801,21 +802,20 @@ static int nvm_create_target(struct nvm_dev *dev,
tt = nvm_find_target_type(create->tgttype);
if (!tt) {
pr_err("nvm: target type %s not found\n", create->tgttype);
- up_write(&nvm_lock);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_unlock;
}
t = nvm_find_target(create->tgtname);
if (t) {
pr_err("nvm: target name already exists.\n");
- up_write(&nvm_lock);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_unlock;
}
- up_write(&nvm_lock);
t = kmalloc(sizeof(struct nvm_target), GFP_KERNEL);
if (!t)
- return -ENOMEM;
+ goto err_unlock;
tqueue = blk_alloc_queue_node(GFP_KERNEL, dev->q->node);
if (!tqueue)
@@ -848,8 +848,6 @@ static int nvm_create_target(struct nvm_dev *dev,
t->type = tt;
t->disk = tdisk;
t->dev = dev;
-
- down_write(&nvm_lock);
list_add_tail(&t->list, &nvm_targets);
up_write(&nvm_lock);
@@ -860,7 +858,9 @@ err_queue:
blk_cleanup_queue(tqueue);
err_t:
kfree(t);
- return -ENOMEM;
+err_unlock:
+ up_write(&nvm_lock);
+ return ret;
}
static int __nvm_configure_create(struct nvm_ioctl_create *create)
--
1.8.3.1
[PATCH 1/2] lightnvm: break the loop when rqd is not null
From: Wenwei Tao
Break the loop when rqd is not null to reduce
unnecessary schedule.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 2103e97..2915e39 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -98,6 +98,9 @@ static void rrpc_discard(struct rrpc *rrpc, struct bio *bio)
do {
rqd = rrpc_inflight_laddr_acquire(rrpc, slba, len);
+ if (rqd)
+ break;
+
schedule();
} while (!rqd);
--
1.8.3.1
Re: [PATCH v4 18/18] make nbd device wait for its users in case of timeout
Hi,
On Thu, May 12, 2016 at 08:49:00PM +0530, Pranay Srivastava wrote:
> On Thu, May 12, 2016 at 2:49 PM, Markus Pargmann wrote:
> > Hi,
> >
> > On Wednesday 11 May 2016 11:18:46 Pranay Kr. Srivastava wrote:
> >> When a timeout occurs or a recv fails, then
> >> instead of abruplty killing nbd block device
> >> wait for it's users to finish.
> >>
> >> This is more required when filesystem(s) like
> >> ext2 or ext3 don't expect their buffer heads to
> >> disappear while the filesystem is mounted.
> >>
> >> The change is described below:
> >> a) Add a users count to nbd_device structure.
> >> b) Add a bit flag to nbd_device structure of unsigned long.
> >>
> >> If the current user count is not 1 then make nbd-client wait
> >> for the in_use bit to be cleared.
> >
> > Thanks, I like this approach much more.
> >
> >>
> >> Signed-off-by: Pranay Kr. Srivastava
> >> ---
> >> drivers/block/nbd.c | 40
> >> include/uapi/linux/nbd.h | 1 +
> >> 2 files changed, 41 insertions(+)
> >>
> >> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> >> index 482a3c0..9b024d8 100644
> >> --- a/drivers/block/nbd.c
> >> +++ b/drivers/block/nbd.c
> >> @@ -59,6 +59,7 @@ struct nbd_device {
> >> int xmit_timeout;
> >> atomic_t timedout;
> >> bool disconnect; /* a disconnect has been requested by user */
> >> + u32 users;
> >
> > Perhaps it is better to use kref for this?
>
> Yup will do.
>
> >
> >>
> >> struct timer_list timeout_timer;
> >> /* protects initialization and shutdown of the socket */
> >> @@ -69,6 +70,7 @@ struct nbd_device {
> >> #if IS_ENABLED(CONFIG_DEBUG_FS)
> >> struct dentry *dbg_dir;
> >> #endif
> >> + unsigned long bflags; /* word size bit flags for use. */
> >
> > Maybe it is better to use a completion instead of a bitfield.
>
> Ok.
>
> >
> >> };
> >>
> >> #if IS_ENABLED(CONFIG_DEBUG_FS)
> >> @@ -822,6 +824,15 @@ static int __nbd_ioctl(struct block_device *bdev,
> >> struct nbd_device *nbd,
> >> sock_shutdown(nbd);
> >> mutex_lock(&nbd->tx_lock);
> >> nbd_clear_que(nbd);
> >> + /*
> >> + * Wait for any users currently using
> >> + * this block device.
> >> + */
> >> + mutex_unlock(&nbd->tx_lock);
> >> + pr_info("Waiting for users to release device %s ...\n",
> >> + bdev->bd_disk->disk_name);
> >> + wait_on_bit(&nbd->bflags, NBD_BFLAG_INUSE_BIT,
> >> TASK_INTERRUPTIBLE);
> >> + mutex_lock(&nbd->tx_lock);
> >> kill_bdev(bdev);
> >> nbd_bdev_reset(bdev);
> >>
> >> @@ -870,10 +881,39 @@ static int nbd_ioctl(struct block_device *bdev,
> >> fmode_t mode,
> >> return error;
> >> }
> >>
> >> +static int nbd_open(struct block_device *bdev, fmode_t mode)
> >> +{
> >> + struct nbd_device *nbd_dev = bdev->bd_disk->private_data;
> >
> > Here is a new line missing otherwise checkpatch will probably warn about
> > this?
> >
> > Should we check here if we are connected here? And check whether the
> > connection is about to be closed?
>
> I don't think it should matter if we are connected or not. We already
> handle that case
> correctly. Requests would fail and those failures will be reported to
> userland. The idea
> here is not to enforce "harsh measures" on the user on failure but to
> report them instead.
I see. Yes that's fine.
Thanks,
Markus
>
> >
> > Best Regards,
> >
> > Markus
>
> I'll send in a new patch after making changes as per your review.
>
> Thanks alot!.
>
> >
> >> + nbd_dev->users++;
> >> + pr_debug("Opening nbd_dev %s. Active users = %u\n",
> >> + bdev->bd_disk->disk_name, nbd_dev->users);
> >> + if (nbd_dev->users > 1)
> >> + {
> >> + set_bit(NBD_BFLAG_INUSE_BIT, &nbd_dev->bflags);
> >> + }
> >> + return 0;
> >> +}
> >> +
> >> +static void nbd_release(struct gendisk *disk, fmode_t mode)
> >> +{
> >> + struct nbd_device *nbd_dev = disk->private_data;
> >> + nbd_dev->users--;
> >> + pr_debug("Closing nbd_dev %s. Active users = %u\n",
> >> + disk->disk_name, nbd_dev->users);
> >> + if (nbd_dev->users == 1)
> >> + {
> >> + clear_bit(NBD_BFLAG_INUSE_BIT, &nbd_dev->bflags);
> >> + smp_mb();
> >> + wake_up_bit(&nbd_dev->bflags, NBD_BFLAG_INUSE_BIT);
> >> + }
> >> +}
> >> +
> >> static const struct block_device_operations nbd_fops = {
> >> .owner =THIS_MODULE,
> >> .ioctl =nbd_ioctl,
> >> .compat_ioctl = nbd_ioctl,
> >> + .open = nbd_open,
> >> + .release = nbd_release
> >> };
> >>
> >> #if IS_ENABLED(CONFIG_DEBUG_FS)
> >> diff --git a/include/uapi/linux/nbd.h b/include/uapi/linux/nbd.h
> >> index e08e413..8f3d3f0 100644
> >> --- a/include/uapi/linux/nbd.h
> >> +++ b/include/uapi/linux
Re: [Nbd] [PATCH] NBD: replace kill_bdev() with __invalidate_device()
Hi Wouter,
On Sun, May 15, 2016 at 02:55:39PM +0200, Wouter Verhelst wrote:
> Hi Markus,
>
> On Thu, May 12, 2016 at 11:53:01AM +0200, Markus Pargmann wrote:
> > On Thursday 28 April 2016 18:27:34 Wouter Verhelst wrote:
> > > However, at some point I agreed with Paul (your predecessor) that when
> > > this happens due to an error condition (as opposed to it being due to an
> > > explicit disconnect), the kernel would block all reads from or writes to
> > > the device, and the client may try to reconnect *from the same
> > > PID* (i.e., it may not fork()). If that succeeds, the next NBD_DO_IT is
> > > assumed to be connected to the same server; if instead the process
> > > exits, then the block device is assumed to be dead, will be reset, and
> > > all pending reads or writes would error.
> > >
> > > In principle, this allows for a proper reconnect from userspace if it
> > > can be done. However, I'm not sure whether this ever worked well or
> > > whether it was documented, so it's probably fine if you think it should
> > > be replaced with something else.
> >
> > At least I was not aware of this possibility. As far as I know the
> > previous code even had issues with the signals used to kill on timeouts
> > which also killed the userspace program sometimes.
> >
> > Currently I can't see a code path that supports reconnects. But I may
> > have removed that accidently in the past.
>
> Right. Like I said, I'm not sure if it ever worked well. The user space
> client has a -persist option that tries to implement it, but I've been
> getting some bug reports from people who've tried it (although that may
> have been my fault rather than the kernel's).
>
> > > (obviously, userspace reconnecting the device to a different device is
> > > wrong and should not be done, but that's a case of "if you break it, you
> > > get to keep both pieces)
> > >
> > > At any rate, I think it makes sense for userspace to be given a chance
> > > to *attempt* to reconnect a device when the connection drops
> > > unexpectedly.
> >
> > Perhaps it would be better to setup the kernel driver explicitly for
> > that. Perhaps some flag to let the kernel driver know that the client
> > would like to keep the block device open? In that case the client could
> > excplicitly use NBD_CLEAR_SOCK to cleanup everything.
>
> I'm not sure what you mean by this. Can you clarify?
I meant that it might be better to have a separate way for NBD_DO_IT.
Something where the client software can directly instruct the kernel to
keep everything opened in case of an error so that the client may
reconnect afterwards.
This could be a new ioctl that sets it up, for example 'NBD_PERSISTENT'.
The NBD_DO_IT afterwards would keep everything up and running in case of
a connection error so that the client could set a new socket using
NBD_SET_SOCK and reenter using NBD_DO_IT.
For all clients that are not capable of this mechanism or don't use it,
NBD_DO_IT would clean up everything properly on any error.
>
> > Or perhaps a completely new ioctl that can transmit back some more
> > information about what failures were seen and whether the blockdevice
> > was closed or not?
>
> The intent was that ioctl(NBD_DO_IT) would return an error when the
> disconnect was not requested, and would return 0 when the connection
> dropped due to userspace doing ioctl(NBD_DISCONNECT), since dropping the
> connection when userspace explicitly asks for it is not an error.
>
> drivers/block/nbd.c contains the following:
>
> static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
>unsigned int cmd, unsigned long arg)
> {
> [...]
> case NBD_DO_IT: {
> [...]
> if (nbd->disconnect) /* user requested, ignore socket errors
> */
> return 0;
> return error;
> }
> [...]
>
> so the signalling part of it is at least still there. Whether it works,
> I haven't tested.
I just looked up the kernel code from 4.0. This code was there as
well. But the socket and blockdevice were both destroyed before leaving
the NBD_DO_IT ioctl. So it seems to have never been really persistent.
Filesystems would have still been killed.
So for a persistent nbd device there is some more code necessary to do
it.
Best Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()
On Wed, May 18, 2016 at 09:41:20AM +0100, Matt Fleming wrote:
> On Wed, 18 May, at 03:01:27AM, Yuyang Du wrote:
> > On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote:
> > > So, if the code looks like the following, either now or in the future,
> > >
> > > static void __schedule(bool preempt)
> > > {
> > > ...
> > > /* Clear RQCF_ACT_SKIP */
> > > rq->clock_update_flags = 0;
> > > ...
> > > delta = rq_clock();
> > > }
> >
> > Sigh, you even said "Clear RQCF_ACT_SKIP", but you not only clear it,
> > you clear everything.
>
> That was sloppy on my part but intentional because that's what the
> code looks like in tip/sched/core today.
Sure, rq->clock_update_flags = 0 is itself all right, just say what you do.
> It was purely meant to demonstrate that setting RQCF_UPDATE just
> because RQCF_ACT_SKIP is set does not make sense. You can replace the
> clearing line with the correct bit masking operation.
I don't understand how you demonstrated that does not make sense. Anways,
you sort it out.
> But I get it, the pseudo-code was confusing. I'll send out a v2.
>
> > And if you clear the RQCF_UPDATE also (maybe you shouldn't, but
> > actually it does not matter), of course you will get a warning...
>
> Right, I wouldn't actually clear RQCF_UPDATE in v2 of this patch.
>
> > In addition, it looks like multiple skips are possible, so:
>
> I'm not sure what you mean, could you elaborate?
>
> > update_rq_clock() {
> > rq->clock_update_flags |= RQCF_UPDATE;
> >
> > ...
> > }
> >
> > instead of clearing the skip flag there.
>
> Huh? RQCF_*_SKIP are not cleared in update_rq_clock().
Yeah, I previously cleared the SKIP bit, which is not right, so I corrected.
RE: new driver for drivers/virt/?
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, May 18, 2016 6:25 PM > To: Thomas Gleixner > Cc: Sell, Timothy C; mi...@kernel.org; dave.han...@linux.intel.com; > ti...@freescale.com; ga...@kernel.crashing.org; Kershner, David A; > cor...@lwn.net; mi...@redhat.com; h...@zytor.com; Arfvidson, Erik; > hof...@osadl.org; dzic...@redhat.com; Curtin, Alexander Paul; > janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com; > pra...@redhat.com; Binder, David Anthony; nhor...@redhat.com; > dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; linux- > d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par- > Maintainer; Jes Sorensen > Subject: Re: new driver for drivers/virt/? > > On Thu, May 19, 2016 at 12:11:46AM +0200, Thomas Gleixner wrote: > > On Wed, 18 May 2016, Sell, Timothy C wrote: > > > We have a bus driver currently in drivers/staging/unisys/visorbus/ that > > > we are trying to get out of staging and into the kernel proper. Since > > > "visorbus" is a driver to host a virtual bus presented to a Linux guest > > > in a hypervisor environment (refer to > > > drivers/staging/unisys/Documentation/overview.txt for more details), > > > Greg KH and Jes Sorensen have suggested the possibility that > drivers/virt/ > > > might be a good place for visorbus. But right now, we see that the only > > > driver under drivers/virt/ is the Freescale hypervisor environment, > which > > > made us wonder whether this was really the correct place. > > > > > > Would you have any guidance for us? > > > Our intent is to push our visorbus out of staging immediately following > > > the current merge window. > > > > What's the problem with Gregs and Jes suggestion? I don't see any. > > Neither do I, odd that they wanted a third opinion :( Sorry; I didn't intend to belittle your opinions. Since we want to push code to drivers/virt/, I figured it would be prudent to get permission from those folks reported by: ./scripts/get_maintainer.pl -f drivers/virt/ first. That was the intent of my original email, and why I chose the distribution list I did. I've never done this before, so I spend quite a lot of time groping around blindly... ;-( Tim Sell > > > There is bigger fish to fry than the final place of this driver. I had just > > a > > peek at the staging code and there is enough stuff which wants to be > cleaned > > up before moving anywhere. I don't have time to do a proper review now, > but > > here are a few hints upfront: > > > > I don't think anyone has given a good review of the code yet, I know > it's been a long time for me. It's on my todo list, but that's not > going to happen until way after 4.7-rc1 is out. Thanks for this initial > list. > > greg k-h
[GIT PULL] ARC updates for 4.7-rc1
Hi Linus,
We have a relatively big changeset for ARC for 4.7.
The highlight is support for EZChip (now Mellanox) NPS-400 network processor, a
400-Gb throughput C-programmable packet processor based on ARC700 cores from
Synopsys (http://www.mellanox.com/related-docs/prod_npu/PB_NPS-400.pdf)
Also present are irqchip and clocksource drivers for NPS as agreed with
respective
maintainers to go via ARC tree due to an soc header dependency.
I have the needed ACKs from Jason, Marc, Daniel. You might run into a trivial
merge conflict in drivers/irqchip/*
This EZChip platform support required some deep changes in ARC architecture code
and also opportunity to cleanup past sins (legacy irq domains, missing irq
domain
lookup, hard coded timer irqs...)
Please pull.
Thx,
-Vineet
->
The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99:
Linux 4.6-rc7 (2016-05-08 14:38:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-4.7-rc1
for you to fetch changes up to 776d7f1694a7d678291354a05f0243965708306a:
arc: axs103_smp: Fix CPU frequency to 100MHz for dual-core (2016-05-18
10:50:18
+0530)
ARC updates for 4.7-rc1
- Support for EZChip (now Mellanox) NPS-400 Network processor based on ARC700
http://www.mellanox.com/related-docs/prod_npu/PB_NPS-400.pdf
- NPS interrupt controller and clocksource drivers
- ARC timers probed off DT
- ARC iqrchips switching to linear domain (upgrade from legacy domains)
Alexey Brodkin (4):
ARC: use fixed frequencies in arc_set_early_base_baud()
ARC: Don't try to use value of top level clock-frequency in DT
ARC: RIP arc_{get|set}_core_freq() clk API
arc: axs103_smp: Fix CPU frequency to 100MHz for dual-core
Jose Abreu (1):
arc: axs10x: Add DT bindings for I2S PLL Clock
Noam Camus (18):
ARC: clockevent: switch to cpu notifier for clockevent setup
ARC: clockevent: Prepare for DT based probe
Documentation: Add EZchip vendor to binding list
soc: Support for EZchip SoC
clocksource: Add NPS400 timers driver
irqchip: add nps Internal and external irqchips
ARC: clean out UAPI byteorder.h clean off Kconfig symbol
ARC: Make vmalloc size configurable
ARC: rwlock: disable interrupts in !LLSC variant
ARC: Mark secondary cpu online only after all HW setup is done
ARC: [plat-eznps] Add eznps board defconfig and dts
ARC: [plat-eznps] Add eznps platform
ARC: [plat-eznps] Use dedicated user stack top
ARC: [plat-eznps] Use dedicated atomic/bitops/cmpxchg
ARC: [plat-eznps] Use dedicated SMP barriers
ARC: [plat-eznps] Use dedicated identity auxiliary register.
ARC: [plat-eznps] Use dedicated COMMAND_LINE_SIZE
ARC: Add eznps platform to Kconfig and Makefile
Tal Zilcer (1):
ARC: [plat-eznps] Use dedicated cpu_relax()
Re: Linux-next parallel cp workload hang
On Thu, May 19, 2016 at 09:02:31AM +1000, Dave Chinner wrote: > On Thu, May 19, 2016 at 12:17:26AM +1000, Dave Chinner wrote: > > Patch below should fix the deadlock. > > The test has been running for several hours without failure using > this patch, so I'd say this fixes the problem... Yes, the same for me. Thanks. Xiong > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com
Re: [kernel-hardening] [PATCH v8 2/4] GCC plugin infrastructure
On Wed, 2016-05-18 at 12:33 +0200, Emese Revfy wrote: > > I've done some basic sanity testing on powerpc with the cyclomatic > > complexity plugin (with LE native + cross-compilers) and it seems to > > work with the patch below. > > > > Signed-off-by: Andrew Donnellan > > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > > index a18a0dc..0cfed5b 100644 > > --- a/arch/powerpc/Kconfig > > +++ b/arch/powerpc/Kconfig > > @@ -97,6 +97,7 @@ config PPC > > select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL > > select HAVE_FUNCTION_TRACER > > select HAVE_FUNCTION_GRAPH_TRACER > > + select HAVE_GCC_PLUGINS > > select SYSCTL_EXCEPTION_TRACE > > select ARCH_WANT_OPTIONAL_GPIOLIB > > select VIRT_TO_BUS if !PPC64 > > Hi, > > Did you test the plugins with all gcc versions (4.5-6)? What's the concern about gcc versions? Just not breaking the build on old compilers? I'm pretty sure powerpc big endian still builds with gcc 4.4. However if Andrew's only tested on little endian, then that select should be guarded with an "if CPU_LITTLE_ENDIAN". And to build LE you need gcc >= 4.9. cheers
Re: [PATCH v4 01/18] nbd: Fix might_sleep warning on xmit timeout
Hi,
On Wed, May 11, 2016 at 11:18:29AM +0300, Pranay Kr. Srivastava wrote:
> This patch fixes the warning generated when a timeout occurs
> on the request and socket is closed from a non-sleep context
> by
>
> 1. Moving the socket closing on a timeout to nbd_thread_send
What happens if a send blocks?
>
> 2. Make sock lock to be a mutex instead of a spin lock, since
>nbd_xmit_timeout doesn't need to hold it anymore.
I can't see why we need a mutex instead of a spinlock?
>
> Signed-off-by: Pranay Kr. Srivastava
> ---
> drivers/block/nbd.c | 65
> -
> 1 file changed, 39 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 31e73a7..c79bcd7 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -57,12 +57,12 @@ struct nbd_device {
> int blksize;
> loff_t bytesize;
> int xmit_timeout;
> - bool timedout;
> + atomic_t timedout;
> bool disconnect; /* a disconnect has been requested by user */
>
> struct timer_list timeout_timer;
> /* protects initialization and shutdown of the socket */
> - spinlock_t sock_lock;
> + struct mutex sock_lock;
> struct task_struct *task_recv;
> struct task_struct *task_send;
>
> @@ -172,10 +172,9 @@ static void nbd_end_request(struct nbd_device *nbd,
> struct request *req)
> */
> static void sock_shutdown(struct nbd_device *nbd)
> {
> - spin_lock_irq(&nbd->sock_lock);
> -
> + mutex_lock(&nbd->sock_lock);
> if (!nbd->sock) {
> - spin_unlock_irq(&nbd->sock_lock);
> + mutex_unlock(&nbd->sock_lock);
> return;
> }
>
> @@ -183,27 +182,19 @@ static void sock_shutdown(struct nbd_device *nbd)
> kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> sockfd_put(nbd->sock);
> nbd->sock = NULL;
> - spin_unlock_irq(&nbd->sock_lock);
> -
> + mutex_unlock(&nbd->sock_lock);
> del_timer(&nbd->timeout_timer);
> }
>
> static void nbd_xmit_timeout(unsigned long arg)
> {
> struct nbd_device *nbd = (struct nbd_device *)arg;
> - unsigned long flags;
>
> if (list_empty(&nbd->queue_head))
> return;
>
> - spin_lock_irqsave(&nbd->sock_lock, flags);
> -
> - nbd->timedout = true;
> -
> - if (nbd->sock)
> - kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> -
> - spin_unlock_irqrestore(&nbd->sock_lock, flags);
> + atomic_inc(&nbd->timedout);
> + wake_up(&nbd->waiting_wq);
>
> dev_err(nbd_to_dev(nbd), "Connection timed out, shutting down
> connection\n");
> }
> @@ -579,7 +570,27 @@ static int nbd_thread_send(void *data)
> /* wait for something to do */
> wait_event_interruptible(nbd->waiting_wq,
>kthread_should_stop() ||
> - !list_empty(&nbd->waiting_queue));
> + !list_empty(&nbd->waiting_queue) ||
> + atomic_read(&nbd->timedout));
> +
> + if (atomic_read(&nbd->timedout)) {
> + mutex_lock(&nbd->sock_lock);
> + if (nbd->sock) {
> + struct request sreq;
> +
> + blk_rq_init(NULL, &sreq);
> + sreq.cmd_type = REQ_TYPE_DRV_PRIV;
> + mutex_lock(&nbd->tx_lock);
> + nbd->disconnect = true;
> + nbd_send_req(nbd, &sreq);
> + mutex_unlock(&nbd->tx_lock);
> + dev_err(disk_to_dev(nbd->disk),
> + "Device Timeout occured.Shutting down"
> + " socket.");
> + }
> + mutex_unlock(&nbd->sock_lock);
> + sock_shutdown(nbd);
Why are you trying to send something on a connection that timed out
(nbd_send_req())? And afterwards you execute a socket shutdown so in most
timeout cases this won't reach the server and we risk a blocking send on
a timedout connection.
Regards,
Markus
> + }
>
> /* extract request */
> if (list_empty(&nbd->waiting_queue))
> @@ -592,7 +603,11 @@ static int nbd_thread_send(void *data)
> spin_unlock_irq(&nbd->queue_lock);
>
> /* handle request */
> - nbd_handle_req(nbd, req);
> + if (atomic_read(&nbd->timedout)) {
> + req->errors++;
> + nbd_end_request(nbd, req);
> + } else
> + nbd_handle_req(nbd, req);
> }
>
> nbd->task_send = NULL;
> @@ -647,7 +662,7 @@ static int nbd_set_socket(struct nbd_device *nbd, struct
> socket *sock)
> {
> int ret = 0;
>
> - spin_lock_irq(&nbd->sock_lock);
> + mutex
RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, May 19, 2016 12:13 > To: Dexuan Cui > Cc: KY Srinivasan ; o...@aepfle.de; > gre...@linuxfoundation.org; jasow...@redhat.com; linux- > ker...@vger.kernel.org; j...@perches.com; net...@vger.kernel.org; > a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang > > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) > > > I'm travelling and very busy with the merge window. So sorry I won't be able > to think about this for some time. David, Sure, I understand. Please let me recap my last mail: 1) I'll replace my statically-allocated per-connection "send/recv bufs" with dynamically ones, so no buf is used when there is no traffic. 2) Another kind of bufs i.e., the multi-page "VMBus send/recv ringbuffer", is a must IMO due to the host side's design of the feature: every connection needs its own ringbuffer, which takes several pages (2~3 pages at least. And, 5 pages should suffice for good performance). The ringbuffer can be accessed by the host at any time, so IMO the pages can't be swappable. I understand net-next is closed now. I'm going to post the next version after 4.7-rc1 is out in several weeks. If you could give me some suggestions, I would be definitely happy to take. Thanks! -- Dexuan
Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2
Hi Tony, On Thursday 19 May 2016 01:00 AM, Tony Lindgren wrote: > * Peter Ujfalusi [160518 03:26]: >> On 05/18/16 11:45, Kishon Vijay Abraham I wrote: >>> omap hsmmc host controller has ADMA2 feature. Enable it here >>> for better read and write throughput. Add a new dt binding >>> "ti,use_adma" to enable ADMA2. >>> >>> Signed-off-by: Kishon Vijay Abraham I >>> --- >>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 + >>> drivers/mmc/host/omap_hsmmc.c | 320 >>> >>> include/linux/platform_data/hsmmc-omap.h |1 + >>> 3 files changed, 256 insertions(+), 66 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >>> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >>> index 74166a0..eb5ceec2 100644 >>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >>> @@ -28,6 +28,7 @@ specifier is required. >>> dma-names: List of DMA request names. These strings correspond >>> 1:1 with the DMA specifiers listed in dmas. The string naming is >>> to be "rx" and "tx" for RX and TX DMA requests, respectively. >>> +ti,use_adma: enable adma2 feature >> >> Do we have use case when you want to fall back to generic DMA instead of >> aDMA2? > > Yes my guess is that PM runtime breaks with these currently.. pm_runtime_get is invoked during omap_hsmmc_request and pm_runtime_put is invoked during omap_hsmmc_request_done. Both these calls are outside DMA API's. So it shouldn't break anything w.r.t PM runtime no? > >> IMHO if the driver supports aDMA2, it is going to use it instead of the >> generic s/eDMA. >> What I mean is: >> the driver implements the aDMA2 support. >> if the IP has support for aDMA2, then it is going to use it, otherwise it >> will >> use the generic DMA. > > Ideally the adma support would be a separate loadable module, > similar how the cppi41dma is a child of the OTG controller. > > That way the systems wanting to use adma can just specify it > in the binding, and adma PM runtime support can be added later > on. > > Of course this won't work if the adma registers are sprinkled > within the MMC controller registers.. right, adma registers are within the MMC controller register space. Thanks Kishon
Re: [PATCH v1] PM / sleep: make pm notifier called symmetrically
On Wed, May 18, 2016 at 1:34 PM, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 8:07 AM, Lianwei Wang wrote: >> This makes pm notifier PREPARE/POST symmetrical: if PREPARE >> fails, we will only undo what ever happened on PREPARE. >> >> It fixes the unbalanced cpu hotplug enable in cpu pm notifier. > > Can you please describe the problem you're trying to address in a bit > more detail? It is described in another patch, and it is a common issue. I fixed the similar issue several times, all because that the CPU_POST_SUSPEND notifier callback is called without call CPU_SUSPEND_PREPARE notifier callback before. Something is DO in PM_XXX_PREPARE and UNDO in POST_XXX. If we don't DO it in XXX_PREPARE then we don't need to UNDO it in PM_POST_XXX. Here is the link for the unbalanced cpu hotplug enable case: https://lkml.org/lkml/2016/5/6/61 . Thanks, Lianwei
Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2
Hi Peter, On Wednesday 18 May 2016 03:54 PM, Peter Ujfalusi wrote: > On 05/18/16 11:45, Kishon Vijay Abraham I wrote: >> omap hsmmc host controller has ADMA2 feature. Enable it here >> for better read and write throughput. Add a new dt binding >> "ti,use_adma" to enable ADMA2. >> >> Signed-off-by: Kishon Vijay Abraham I >> --- >> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 + >> drivers/mmc/host/omap_hsmmc.c | 320 >> >> include/linux/platform_data/hsmmc-omap.h |1 + >> 3 files changed, 256 insertions(+), 66 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> index 74166a0..eb5ceec2 100644 >> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> @@ -28,6 +28,7 @@ specifier is required. >> dma-names: List of DMA request names. These strings correspond >> 1:1 with the DMA specifiers listed in dmas. The string naming is >> to be "rx" and "tx" for RX and TX DMA requests, respectively. >> +ti,use_adma: enable adma2 feature > > Do we have use case when you want to fall back to generic DMA instead of > aDMA2? > IMHO if the driver supports aDMA2, it is going to use it instead of the > generic s/eDMA. > What I mean is: > the driver implements the aDMA2 support. > if the IP has support for aDMA2, then it is going to use it, otherwise it will > use the generic DMA. hmm.. how will the driver know if the IP has support for aDMA2. Using dt binding is one way. Using MMCHS_HL_HWINFO is another way but then the register offsets in omap_hsmmc driver has to be modified for omap4+. Thanks Kishon
[GIT PULL] dmaengine updates for 4.7-rc1
Hello Linus, Please PULL to receive the dmaengine updates for 4.7-rc1: The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.7-rc1 for you to fetch changes up to f9114a54c1d828abbe87ac446a2da49d9720203f: Merge branch 'topic/xilinx' into for-linus (2016-05-17 10:15:34 +0530) dmaengine updates for 4.7 This time round the update brings in following changes: - New tegra driver for ADMA device - Support for Xilinx AXI Direct Memory Access Engine and Xilinx AXI Central Direct Memory Access Engine and few updates to this driver. - New cyclic capability to sun6i and few updates. - Slave-sg support in bcm2835. - Updates to many drivers like designware, hsu, mv_xor, pxa, edma, qcom_hidma & bam. Andy Shevchenko (16): dmaengine: hsu: allow more than 3 descriptors dmaengine: hsu: don't check direction of timeouted channel dmaengine: hsu: set maximum allowed segment size for DMA dmaengine: dw: fix master selection dmaengine: dw: rename masters to reflect actual topology dmaengine: dw: substitute dma_read_byaddr by dma_readl_native dmaengine: dw: define counter variables as unsigned int dmaengine: dw: move dwc->paused to dwc->flags dmaengine: dw: move dwc->initialized to dwc->flags dmaengine: dw: move residue to a descriptor dmaengine: dw: set cdesc to NULL when free cyclic transfers dmaengine: dw: platform: check nr_masters to be non-zero dmaengine: dw: revisit data_width property dmaengine: dw: keep entire platform data in struct dw_dma dmaengine: dw: pass platform data via struct dw_dma_chip dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC Christian Lamparter (1): dmaengine: dw: lazy allocation of dma descriptors Dave Jiang (1): dmaengine: ioatdma: disable relaxed ordering for ioatdma Eric Engestrom (1): dmaengine: pxa_dma: remove duplicate const qualifier Gregory CLEMENT (3): dmaengine: mv_xor: make the code 64 bits compliant dmaengine: mv_xor: use SoC type instead of directly the operation mode dmaengine: mv_xor: Allow selecting mv_xor for mvebu only compatible SoC Jarkko Nikula (2): dmaengine: core: Use dev_ functions for debug and error prints dmaengine: core: Revert back to pr_debug in __dma_request_channel() Javier Martinez Canillas (1): dmaengine: core: Use IS_ENABLED() instead of checking for built-in or module Jean-Francois Moine (6): dmaengine: sun6i: Fix the access of the IRQ register dmaengine: sun6i: Fix impossible settings of burst and bus width dmaengine: sun6i: Simplify lli setting dmaengine: sun6i: Set default maxburst size and bus width dmaengine: sun6i: Remove useless check dmaengine: sun6i: Add cyclic capability Jon Hunter (3): Documentation: DT: Add binding documentation for NVIDIA ADMA dmaengine: tegra-adma: Add support for Tegra210 ADMA MAINTAINERS: Update Tegra DMA maintainers Julia Lawall (4): dmaengine: mmp_pdma: Use dma_pool_zalloc dmaengine: ioatdma: Use dma_pool_zalloc dmaengine: fsldma: Use dma_pool_zalloc dmaengine: vdma: Use dma_pool_zalloc Kedareswara rao Appana (11): dmaengine: vdma: Add 64 bit addressing support to the driver dmaengine: vdma: Fix race condition in Non-SG mode dmaengine: vdma: Fix checkpatch.pl warnings dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma Documentation: DT: vdma: update binding doc for AXI DMA dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine Documentation: DT: vdma: update binding doc for AXI CDMA dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine dmaengine: vdma: Add config structure to differentiate dmas Documentation: DT: vdma: Add clock support for dmas dmaengine: vdma: Add clock support Linus Walleij (1): dmaengine: pl08x: allocate OF slave channel data at probe time Mans Rullgard (4): dmaengine: dw: set src and dst master select according to xfer direction dmaengine: dw: fix byte order of hw descriptor fields dmaengine: dw: set LMS field in descriptors dmaengine: dw: clear LLP_[SD]_EN bits in last descriptor of a chain Marcin Wojtas (1): dmaengine: mv_xor: add support for Armada 3700 SoC Mario Six (3): dmaengine: mpc512x: Fix hanging DMA device transfer for MPC8308 dmaengine: mpc512x: Implement additional chunk sizes for DMA transfers dmaengine: mpc512x: Fix code style Martin Sperl (12): dmaengine: bcm2835: set residue_granularity field dmaengine: bcm2835: remove unnecessary masking
Re: [PATCH 1/1] net: pegasus: simplify logical constraint
On 16-05-18 20:40:51, Heinrich Schuchardt wrote: > If !count is true, count < 4 is also true. Yep, you're right. However, gcc optimizes away the first condition. What you really got me to think about is whether 4 is the right number. I guess i shall refer to the HW documentation. Petko > Signed-off-by: Heinrich Schuchardt > --- > drivers/net/usb/pegasus.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c > index 36cd7f0..9bbe0161 100644 > --- a/drivers/net/usb/pegasus.c > +++ b/drivers/net/usb/pegasus.c > @@ -473,7 +473,7 @@ static void read_bulk_callback(struct urb *urb) > goto goon; > } > > - if (!count || count < 4) > + if (count < 4) > goto goon; > > rx_status = buf[count - 2]; > -- > 2.1.4 > >
[PATCH v5] iio: max5487: Add support for Maxim digital potentiometers
Add implementation for Maxim MAX5487, MAX5488, MAX5489
digital potentiometers.
Datasheet:
http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf
Signed-off-by: Cristina Moraru
CC: Daniel Baluta
---
Changes since v4:
Add year for copyright
Changes since v3:
Fix size issue in max5487_write_cmd
Fix typo
Changes since v2:
Change switch statement in max5487_write_raw
to if statement for consistency
Add blank line before return statement
Eliminate regmap support and use spi_write
Use iio_device_register instead of devm_ version
Changes since v1:
Fix spacing
Eliminate max5487_cfg struct
Add kohms as driver data
drivers/iio/potentiometer/Kconfig | 11 +++
drivers/iio/potentiometer/Makefile | 1 +
drivers/iio/potentiometer/max5487.c | 161
3 files changed, 173 insertions(+)
create mode 100644 drivers/iio/potentiometer/max5487.c
diff --git a/drivers/iio/potentiometer/Kconfig
b/drivers/iio/potentiometer/Kconfig
index 6acb238..0941c8d4 100644
--- a/drivers/iio/potentiometer/Kconfig
+++ b/drivers/iio/potentiometer/Kconfig
@@ -15,6 +15,17 @@ config DS1803
To compile this driver as a module, choose M here: the
module will be called ds1803.
+config MAX5487
+tristate "Maxim MAX5487/MAX5488/MAX5489 Digital Potentiometer driver"
+depends on SPI
+help
+ Say yes here to build support for the Maxim
+ MAX5487, MAX5488, MAX5489 digital potentiometer
+ chips.
+
+ To compile this driver as a module, choose M here: the
+ module will be called max5487.
+
config MCP4131
tristate "Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital
Potentiometer driver"
depends on SPI
diff --git a/drivers/iio/potentiometer/Makefile
b/drivers/iio/potentiometer/Makefile
index 6007faa..8adb58f 100644
--- a/drivers/iio/potentiometer/Makefile
+++ b/drivers/iio/potentiometer/Makefile
@@ -4,6 +4,7 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_DS1803) += ds1803.o
+obj-$(CONFIG_MAX5487) += max5487.o
obj-$(CONFIG_MCP4131) += mcp4131.o
obj-$(CONFIG_MCP4531) += mcp4531.o
obj-$(CONFIG_TPL0102) += tpl0102.o
diff --git a/drivers/iio/potentiometer/max5487.c
b/drivers/iio/potentiometer/max5487.c
new file mode 100644
index 000..6c50939
--- /dev/null
+++ b/drivers/iio/potentiometer/max5487.c
@@ -0,0 +1,161 @@
+/*
+ * max5487.c - Support for MAX5487, MAX5488, MAX5489 digital potentiometers
+ *
+ * Copyright (C) 2016 Cristina-Gabriela Moraru
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+
+#include
+#include
+
+#define MAX5487_WRITE_WIPER_A (0x01 << 8)
+#define MAX5487_WRITE_WIPER_B (0x02 << 8)
+
+/* copy both wiper regs to NV regs */
+#define MAX5487_COPY_AB_TO_NV (0x23 << 8)
+/* copy both NV regs to wiper regs */
+#define MAX5487_COPY_NV_TO_AB (0x33 << 8)
+
+#define MAX5487_MAX_POS255
+
+struct max5487_data {
+ struct spi_device *spi;
+ int kohms;
+};
+
+#define MAX5487_CHANNEL(ch, addr) {\
+ .type = IIO_RESISTANCE, \
+ .indexed = 1, \
+ .output = 1,\
+ .channel = ch, \
+ .address = addr,\
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec max5487_channels[] = {
+ MAX5487_CHANNEL(0, MAX5487_WRITE_WIPER_A),
+ MAX5487_CHANNEL(1, MAX5487_WRITE_WIPER_B),
+};
+
+static int max5487_write_cmd(struct spi_device *spi, u16 cmd)
+{
+ return spi_write(spi, (const void *) &cmd, sizeof(u16));
+}
+
+static int max5487_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct max5487_data *data = iio_priv(indio_dev);
+
+ if (mask != IIO_CHAN_INFO_SCALE)
+ return -EINVAL;
+
+ *val = 1000 * data->kohms;
+ *val2 = MAX5487_MAX_POS;
+
+ return IIO_VAL_FRACTIONAL;
+}
+
+static int max5487_write_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int val, int val2, long mask)
+{
+ struct max5487_data *data = iio_priv(indio_dev);
+
+ if (mask != IIO_CHAN_INFO_RAW)
+ return -EINVAL;
+
+ if (val < 0 || val > MAX5487_MAX_POS)
+ return -EINVAL;
+
+ return max5487_write_cmd(data->spi, chan->address | val);
+}
+
[PATCH v2] xen: add steal_clock support on x86
The pv_time_ops structure contains a function pointer for the
"steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
uses its own mechanism to account for the "stolen" time a thread wasn't
able to run due to hypervisor scheduling.
Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen and remove the x86 Xen
hack.
Signed-off-by: Juergen Gross
---
V2: remove the x86 do_stolen_accounting() hack
---
arch/arm/xen/enlighten.c| 17 ++---
arch/x86/xen/time.c | 44 ++--
drivers/xen/time.c | 19 +++
include/linux/kernel_stat.h | 1 -
include/xen/xen-ops.h | 1 +
kernel/sched/cputime.c | 10 --
6 files changed, 24 insertions(+), 68 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..9163b94 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
-static unsigned long long xen_stolen_accounting(int cpu)
-{
- struct vcpu_runstate_info state;
-
- BUG_ON(cpu != smp_processor_id());
-
- xen_get_runstate_snapshot(&state);
-
- WARN_ON(state.state != RUNSTATE_running);
-
- return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
static void xen_read_wallclock(struct timespec64 *ts)
{
u32 version;
@@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
register_cpu_notifier(&xen_cpu_notifier);
- pv_time_ops.steal_clock = xen_stolen_accounting;
- static_key_slow_inc(¶virt_steal_enabled);
+ xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -31,44 +29,6 @@
/* Xen may fire a timer up to this many ns early */
#define TIMER_SLOP 10
-#define NS_PER_TICK(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void do_stolen_accounting(void)
-{
- struct vcpu_runstate_info state;
- struct vcpu_runstate_info *snap;
- s64 runnable, offline, stolen;
- cputime_t ticks;
-
- xen_get_runstate_snapshot(&state);
-
- WARN_ON(state.state != RUNSTATE_running);
-
- snap = this_cpu_ptr(&xen_runstate_snapshot);
-
- /* work out how much time the VCPU has not been runn*ing* */
- runnable = state.time[RUNSTATE_runnable] -
snap->time[RUNSTATE_runnable];
- offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
-
- *snap = state;
-
- /* Add the appropriate number of ticks of stolen time,
- including any left-overs from last time. */
- stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
-
- if (stolen < 0)
- stolen = 0;
-
- ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
- __this_cpu_write(xen_residual_stolen, stolen);
- account_steal_ticks(ticks);
-}
/* Get the TSC speed from Xen */
static unsigned long xen_tsc_khz(void)
@@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void
*dev_id)
ret = IRQ_HANDLED;
}
- do_stolen_accounting();
-
return ret;
}
@@ -431,6 +389,8 @@ static void __init xen_time_init(void)
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
+ xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
}
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 7107842..6648a78 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -75,6 +75,15 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
}
+static u64 xen_steal_clock(int cpu)
+{
+ struct vcpu_runstate_info state;
+
+ BUG_ON(cpu != smp_processor_id());
+ xen_get_runstate_snapshot(&state);
+ return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
+}
+
void xen_setup_runstate_info(int cpu)
{
struct vcpu_register_runstate_memory_area area;
@@ -86,3 +95,13 @@ void xen_setup_runstate_info(int cpu)
BUG();
}
+void __init xen_time_setup_guest(void)
+{
+ pv_time_ops.steal_clock = xen_steal_clock;
+
+ static_key_slow_inc(¶virt_steal_enabled);
+ /*
+* We can't set paravirt_steal_rq_enabled as this would require the
+* capability to read another
[PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.
In ftrace.c inside the function alloc_retstack_tasklist()(which will be
invoked when function_graph tracing is on) the tasklist_lock is being
held as reader while iterating through list of threads. Here the lock
being held as reader with irqs disabled. The tasklist_lock is never
write_locked in interrupt context so it is safe to not disable interrupts
for the duration of read_lock in this block which, can be significant,
given the block of code iterates through all threads. Hence changing the
code to call read_lock() and read_unlock() instead of read_lock_irqsave()
and read_unlock_irqrestore(). Seen the same change is made in
"kernel/tracepoint.c" and "kernel/sched/core.c"files with commit ids
'commit 8063e41d2ffc ("tracing: Change syscall_*regfunc() to check
PF_KTHREAD and use for_each_process_thread()")'
'commit 3472eaa1f12e ("sched: normalize_rt_tasks(): Don't use _irqsave
for tasklist_lock, use task_rq_lock()")'
Done basic testing by enabling function graph tracing in x86_64.
Signed-off-by: Soumya PN
---
kernel/trace/ftrace.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b1870fb..45bc72f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5713,7 +5713,6 @@ static int alloc_retstack_tasklist(struct
ftrace_ret_stack **ret_stack_list)
{
int i;
int ret = 0;
- unsigned long flags;
int start = 0, end = FTRACE_RETSTACK_ALLOC_SIZE;
struct task_struct *g, *t;
@@ -5728,8 +5727,7 @@ static int alloc_retstack_tasklist(struct
ftrace_ret_stack **ret_stack_list)
goto free;
}
}
-
- read_lock_irqsave(&tasklist_lock, flags);
+ read_lock(&tasklist_lock);
do_each_thread(g, t) {
if (start == end) {
ret = -EAGAIN;
@@ -5747,7 +5745,7 @@ static int alloc_retstack_tasklist(struct
ftrace_ret_stack **ret_stack_list)
} while_each_thread(g, t);
unlock:
- read_unlock_irqrestore(&tasklist_lock, flags);
+ read_unlock(&tasklist_lock);
free:
for (i = start; i < end; i++)
kfree(ret_stack_list[i]);
--
1.8.3.1
[PATCH net V2] tuntap: correctly wake up process during uninit
We used to check dev->reg_state against NETREG_REGISTERED after each
time we are woke up. But after commit 9e641bdcfa4e ("net-tun:
restructure tun_do_read for better sleep/wakeup efficiency"), it uses
skb_recv_datagram() which does not check dev->reg_state. This will
result if we delete a tun/tap device after a process is blocked in the
reading. The device will wait for the reference count which was held
by that process for ever.
Fixes this by using RCV_SHUTDOWN which will be checked during
sk_recv_datagram() before trying to wake up the process during uninit.
Fixes: 9e641bdcfa4e ("net-tun: restructure tun_do_read for better
sleep/wakeup efficiency")
Cc: Eric Dumazet
Cc: Xi Wang
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
- The patch is needed for -stable.
- Changes from v1: remove unnecessary NETREG_REGISTERED check in tun_do_read()
---
drivers/net/tun.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 425e983..e16487c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -580,11 +580,13 @@ static void tun_detach_all(struct net_device *dev)
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
BUG_ON(!tfile);
+ tfile->socket.sk->sk_shutdown = RCV_SHUTDOWN;
tfile->socket.sk->sk_data_ready(tfile->socket.sk);
RCU_INIT_POINTER(tfile->tun, NULL);
--tun->numqueues;
}
list_for_each_entry(tfile, &tun->disabled, next) {
+ tfile->socket.sk->sk_shutdown = RCV_SHUTDOWN;
tfile->socket.sk->sk_data_ready(tfile->socket.sk);
RCU_INIT_POINTER(tfile->tun, NULL);
}
@@ -641,6 +643,7 @@ static int tun_attach(struct tun_struct *tun, struct file
*file, bool skip_filte
goto out;
}
tfile->queue_index = tun->numqueues;
+ tfile->socket.sk->sk_shutdown &= ~RCV_SHUTDOWN;
rcu_assign_pointer(tfile->tun, tun);
rcu_assign_pointer(tun->tfiles[tun->numqueues], tfile);
tun->numqueues++;
@@ -1491,9 +1494,6 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct
tun_file *tfile,
if (!iov_iter_count(to))
return 0;
- if (tun->dev->reg_state != NETREG_REGISTERED)
- return -EIO;
-
/* Read frames from queue */
skb = __skb_recv_datagram(tfile->socket.sk, noblock ? MSG_DONTWAIT : 0,
&peeked, &off, &err);
--
2.7.4
Re: [PATCH net] tuntap: correctly wake up process during uninit
On 2016年05月18日 21:01, Eric Dumazet wrote:
On Wed, 2016-05-18 at 18:58 +0800, Jason Wang wrote:
We used to check dev->reg_state against NETREG_REGISTERED after each
time we are woke up. But after commit 9e641bdcfa4e ("net-tun:
restructure tun_do_read for better sleep/wakeup efficiency"), it uses
skb_recv_datagram() which does not check dev->reg_state. This will
result if we delete a tun/tap device after a process is blocked in the
reading. The device will wait for the reference count which was held
by that process for ever.
Fixes this by using RCV_SHUTDOWN which will be checked during
sk_recv_datagram() before trying to wake up the process during uninit.
Fixes: 9e641bdcfa4e ("net-tun: restructure tun_do_read for better
sleep/wakeup efficiency")
Ok.
Cc: Eric Dumazet
Cc: Xi Wang
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
The patch is needed for -stable.
---
drivers/net/tun.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 425e983..752d849 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -580,11 +580,13 @@ static void tun_detach_all(struct net_device *dev)
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
BUG_ON(!tfile);
+ tfile->socket.sk->sk_shutdown = RCV_SHUTDOWN;
tfile->socket.sk->sk_data_ready(tfile->socket.sk);
RCU_INIT_POINTER(tfile->tun, NULL);
--tun->numqueues;
}
list_for_each_entry(tfile, &tun->disabled, next) {
+ tfile->socket.sk->sk_shutdown = RCV_SHUTDOWN;
tfile->socket.sk->sk_data_ready(tfile->socket.sk);
RCU_INIT_POINTER(tfile->tun, NULL);
}
@@ -641,6 +643,7 @@ static int tun_attach(struct tun_struct *tun, struct file
*file, bool skip_filte
goto out;
}
tfile->queue_index = tun->numqueues;
+ tfile->socket.sk->sk_shutdown &= ~RCV_SHUTDOWN;
rcu_assign_pointer(tfile->tun, tun);
rcu_assign_pointer(tun->tfiles[tun->numqueues], tfile);
tun->numqueues++;
Is the "if (tun->dev->reg_state != NETREG_REGISTERED) return -EIO;"
check still needed then ?
Thanks.
No need since we've check tun before, will remove this in V2.
Thanks
Re: [PATCH] xen: add steal_clock support on x86
On 18/05/16 18:13, Boris Ostrovsky wrote:
> On 05/18/2016 12:00 PM, Juergen Gross wrote:
>> On 18/05/16 17:53, Boris Ostrovsky wrote:
>>> On 05/18/2016 11:45 AM, David Vrabel wrote:
On 18/05/16 16:42, Juergen Gross wrote:
> On 18/05/16 17:25, Boris Ostrovsky wrote:
>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>>> On 18/05/16 16:46, Boris Ostrovsky wrote:
On 05/18/2016 08:15 AM, Juergen Gross wrote:
> }
>
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> + * We can't set paravirt_steal_rq_enabled as this would require
> the
> + * capability to read another cpu's runstate info.
> + */
> +}
Won't we be accounting for stolen cycles twice now --- once from
steal_account_process_tick()->steal_clock() and second time from
do_stolen_accounting()?
>>> Uuh, yes.
>>>
>>> I guess I should rip do_stolen_accounting() out, too?
>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
> This is easy to accomplish. :-)
>>>
>>> I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
>>> neither) and in their case that's presumably because stealing accounting
>>> is a CPUID bit, i.e. it might not be supported. In Xen case we always
>>> have this interface.
>> So they added it later and the default is to keep the old behavior.
>>
>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>> maybe check for paravirt_steal_enabled.
> Is this really a sensible thing to do? There is a mechanism used by KVM
> to do the stolen accounting. I think we should use it instead of having
> a second implementation doing the same thing in case the generic one
> isn't enabled.
I agree.
Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
don't think it's essential (or is it?).
>>> Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
>>> support yet.
>> I think the patch is still useful. It is reducing code size and
>> it is removing arch-specific Xen-hack(s). With the patch Xen's
>> solution for arm and x86 is common and the same as for KVM. Adding
>> paravirt_steal_rq_enabled later will be much easier as only one
>> function needs substantial modification.
>
> I am not arguing against having a patch that will remove
> do_stolen_accounting(). I was responding to David's statement about
> whether we need to select CONFIG_PARAVIRT_TIME_ACCOUNTING, and I am not
> sure this is necessary since steal_account_process_tick() (that will
> take case of things that do_stolen_accounting() currently does) doesn't
> need it.
Aah, okay. That's a good reason to not add the Kconfig stuff.
> (And if it is indeed needed --- can we have Xen's Kconfig select it
> instead of "default y if XEN" ?)
I've verified that CONFIG_PARAVIRT_TIME_ACCOUNTING is _not_ needed.
I've removed it from .config and used my patch with
do_stolen_accounting() removed. In an overcommitted guest (4 vcpus on 2
physical cpus) running a parallel make top showed near 50% stolen time.
Juergen
Re: [PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given
On Thu, 19 May 2016 06:15:38 +0530
Hemant Kumar wrote:
> Hi Masami,
>
> On 05/15/2016 08:50 AM, Masami Hiramatsu wrote:
> > From: Masami Hiramatsu
> >
> > perf-probe --del removes caches when --cache is given.
> > Note that the delete pattern is not same as normal events.
> >
> > If you cached probes with event name, --del "eventname"
> > works as expected. However, if you skipped it, the cached
> > probes doesn't have actual event name. In that case
> > --del "probe-desc" is required (wildcard is acceptable).
> > For example a cache entry has the probe-desc "vfs_read $params",
> > you can remove it with --del 'vfs_read*'.
> >
> >-
> ># perf probe --cache --list
> >/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
> >vfs_read $params
> >/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
> >getaddrinfo $params
> >
> ># perf probe --cache --del vfs_read\*
> >Removed event: probe:vfs_read
>
> Not sure where the o/p message for perf probe --cache --del
> is coming from here. So, if we are removing an event from the cache,
> is it intended to remove that from the {u,k}probe_events file as well?
No, it only deletes entries from the cache. No actual probes are
removed.
> The patch removes only from the cache (which I think is the intended
> behavior). With this patch, when I delete an event from the cache, it
> silently deletes it. So, do we add some kind of a message there?
Ah, good point!
> # ./perf probe --cache --list
> [kernel.kallsyms] (818a8e96766649cb2b62fc0bc3e66c27be0cd870):
> vfs_read
> /usr/lib64/libc-2.18.so (e8587f5d2edba244cc43368b5ebfce1782195b6f):
> getaddrinfo $params
>
> # ./perf probe --cache --del vfs_read\*
> #
>
> If we are silently removing the events from the cache, the commit message
> needs to be ammended.
Hmm, it must be dropped while updating series...
OK, I'll fix it!
Thanks!
>
> ># perf probe --cache --list
> >/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
> >/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
> >getaddrinfo $params
> >-
> >
> > Signed-off-by: Masami Hiramatsu
> > Signed-off-by: Masami Hiramatsu
> > ---
> > Changes in v4:
> >- move del_perf_probe_caches() into builtin-probe.c since
> > command-line related delete procedure is there now.
> > ---
> > tools/perf/Documentation/perf-probe.txt |1 +
> > tools/perf/builtin-probe.c | 27 ++
> > tools/perf/util/probe-file.c| 32
> > ---
> > tools/perf/util/probe-file.h|2 ++
> > 4 files changed, 55 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/perf/Documentation/perf-probe.txt
> > b/tools/perf/Documentation/perf-probe.txt
> > index 5a70d45..8d09173 100644
> > --- a/tools/perf/Documentation/perf-probe.txt
> > +++ b/tools/perf/Documentation/perf-probe.txt
> > @@ -116,6 +116,7 @@ OPTIONS
> > (With --add) Cache the probes. Any events which successfully added
> > are also stored in the cache file.
> > (With --list) Show cached probes.
> > + (With --del) Remove cached probes.
> >
> > --max-probes=NUM::
> > Set the maximum number of probe points for an event. Default is 128.
> > diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
> > index 53e380c0e..8f61525 100644
> > --- a/tools/perf/builtin-probe.c
> > +++ b/tools/perf/builtin-probe.c
> > @@ -363,6 +363,30 @@ out_cleanup:
> > return ret;
> > }
> >
> > +static int del_perf_probe_caches(struct strfilter *filter)
> > +{
> > + struct probe_cache *cache;
> > + struct strlist *bidlist;
> > + struct str_node *nd;
> > + int ret;
> > +
> > + ret = build_id_cache__list_all(&bidlist);
> > + if (ret < 0) {
> > + pr_debug("Failed to get buildids: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + strlist__for_each(nd, bidlist) {
> > + cache = probe_cache__new(nd->s);
> > + if (!cache)
> > + continue;
> > + probe_cache__remove_entries(cache, filter);
> > + probe_cache__commit(cache);
> > + probe_cache__delete(cache);
> > + }
> > + return 0;
> > +}
> > +
> > static int perf_del_probe_events(struct strfilter *filter)
> > {
> > int ret, ret2, ufd = -1, kfd = -1;
> > @@ -375,6 +399,9 @@ static int perf_del_probe_events(struct strfilter
> > *filter)
> >
> > pr_debug("Delete filter: \'%s\'\n", str);
> >
> > + if (probe_conf.cache)
> > + return del_perf_probe_caches(filter);
> > +
> > /* Get current event names */
> > ret = probe_file__open_both(&kfd, &ufd, PF_FL_RW);
> > if (ret < 0)
> > diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> > index a6d4a67..cc0f183 100644
> > --- a/tools/perf/util/probe-file.c
> > +++ b/tools/perf/util/probe-file.c
> > @@ -660,19 +660,37 @@ out:
> > return ret;
> > }
> >
> > +static bo
Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver
Hi,
On 18/05/2016 18:24, Florian Fainelli wrote:
> CC'ing Andrew, John,
>
also CC'ing Matthias and Hauke. we have had a driver in OpenWrt/LEDE for
several years that seems a little more complete than this one.
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/lantiq/patches-4.4/0023-NET-PHY-adds-driver-for-lantiq-PHY11G.patch;h=93bb4275ec1d261f398afb8fdc879c1dd973f997;hb=HEAD
John
> On 05/18/2016 09:03 AM, Alexander Stein wrote:
>> This currently only supports PEF7071 and allows to specify max-speed and
>> is able to read the LED configuration from device-tree.
>>
>> Signed-off-by: Alexander Stein
>> ---
>> The main purpose for now is to set a LED configuration from device tree and
>> to limit the maximum speed. The latter one in my case hardware limited.
>> As MAC and it's link partner support 1000MBit/s they would try to use that
>> but will eventually fail due to magnetics only supporting 100MBit/s. So
>> limit the maximum link speed supported directly from the start.
>
> The 'max-speed' parsing that you do in the driver should not be needed,
> PHYLIB takes care of that already see
> drivers/net/phy/phy_device.c::of_set_phy_supported
>
> For LEDs, we had a patch series floating around adding LED triggers [1],
> and it seems to me like the LEDs class subsystem would be a good fit for
> controlling PHY LEDs, possibly with the help of PHYLIB when it comes to
> doing the low-level work of registering LEDs and their names with the
> LEDS subsystem.
>
> [1]: http://lists.openwall.net/netdev/2016/03/23/61
>
>>
>> As this is a RFC I skipped the device tree binding doc.
>
> Too bad, that's probably what needs to be discussed here, because the
> driver looks pretty reasonable otherwise.
>
>>
>> drivers/net/phy/Kconfig | 5 ++
>> drivers/net/phy/Makefile | 1 +
>> drivers/net/phy/lantiq.c | 167
>> +++
>> 3 files changed, 173 insertions(+)
>> create mode 100644 drivers/net/phy/lantiq.c
>>
>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>> index 3e28f7a..c004885 100644
>> --- a/drivers/net/phy/Kconfig
>> +++ b/drivers/net/phy/Kconfig
>> @@ -119,6 +119,11 @@ config STE10XP
>> ---help---
>>This is the driver for the STe100p and STe101p PHYs.
>>
>> +config LANTIQ_PHY
>> +tristate "Driver for Lantiq PHYs"
>> +---help---
>> + Supports the PEF7071 PHYs.
>> +
>> config LSI_ET1011C_PHY
>> tristate "Driver for LSI ET1011C PHY"
>> ---help---
>> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
>> index 8ad4ac6..e886549 100644
>> --- a/drivers/net/phy/Makefile
>> +++ b/drivers/net/phy/Makefile
>> @@ -38,3 +38,4 @@ obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
>> obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
>> obj-$(CONFIG_AMD_XGBE_PHY) += amd-xgbe-phy.o
>> obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
>> +obj-$(CONFIG_LANTIQ_PHY)+= lantiq.o
>> diff --git a/drivers/net/phy/lantiq.c b/drivers/net/phy/lantiq.c
>> new file mode 100644
>> index 000..876a7d1
>> --- /dev/null
>> +++ b/drivers/net/phy/lantiq.c
>> @@ -0,0 +1,167 @@
>> +/*
>> + * Driver for Lantiq PHYs
>> + *
>> + * Author: Alexander Stein
>> + *
>> + * Copyright (c) 2015-2016 SYS TEC electronic GmbH
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define PHY_ID_PEF7071 0xd565a401
>> +
>> +#define MII_LANTIQ_MMD_CTRL_REG 0x0d
>> +#define MII_LANTIQ_MMD_REGDATA_REG 0x0e
>> +#define OP_DATA 1
>> +
>> +struct lantiqphy_led_ctrl {
>> +const char *property;
>> +u32 regnum;
>> +};
>> +
>> +static int lantiq_extended_write(struct phy_device *phydev,
>> + u8 mode, u32 dev_addr, u32 regnum, u16 val)
>> +{
>> +phy_write(phydev, MII_LANTIQ_MMD_CTRL_REG, dev_addr);
>> +phy_write(phydev, MII_LANTIQ_MMD_REGDATA_REG, regnum);
>> +phy_write(phydev, MII_LANTIQ_MMD_CTRL_REG, (mode << 14) | dev_addr);
>> +return phy_write(phydev, MII_LANTIQ_MMD_REGDATA_REG, val);
>> +}
>> +
>> +static int lantiq_of_load_led_config(struct phy_device *phydev,
>> + struct device_node *of_node,
>> + const struct lantiqphy_led_ctrl *leds,
>> + u8 entries)
>> +{
>> +u16 val;
>> +int i;
>> +int ret = 0;
>> +
>> +for (i = 0; i < entries; i++) {
>> +if (!of_property_read_u16(of_node, leds[i].property, &val)) {
>> +ret = lantiq_extended_write(phydev, OP_DATA, 0x1f,
>> +leds[i].regnum, val);
>> +if (ret) {
>> +
Re: [PATCH 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
On 18-05-16, 18:30, Dave Gerlach wrote:
> Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
> have different OPPs available for the MPU depending on which specific
> variant of the SoC is in use. This can be determined through use of the
> revision and an eFuse register present in the silicon. Introduce a
> ti-cpufreq driver that can read the aformentioned values and provide
> them as version matching data to the opp framework. Through this the
> opp-supported-hw dt binding that is part of the operating-points-v2
> table can be used to indicate availability of OPPs for each device.
>
> This driver also creates the "cpufreq-dt" platform_device after passing
> the version matching data to the OPP framework so that the cpufreq-dt
> handles the actual cpufreq implementation. Even without the necessary
> data to pass the version matching data the driver will still create this
> device to maintain backwards compatibility with operating-points v1
> tables.
>
> Signed-off-by: Dave Gerlach
> ---
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/ti-cpufreq.c | 254
> +++
> 3 files changed, 266 insertions(+)
> create mode 100644 drivers/cpufreq/ti-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index d89b8afe23b6..0dea6849ac3e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -234,6 +234,17 @@ config ARM_TEGRA124_CPUFREQ
> help
> This adds the CPUFreq driver support for Tegra124 SOCs.
>
> +config ARM_TI_CPUFREQ
> + tristate "Texas Instruments CPUFreq support"
You sure you want to get it compiled as a module? And don't provide
module_exit() at all?
> + depends on ARCH_OMAP2PLUS
> + help
> + This driver enables valid OPPs on the running platform based on
> + values contained within the SoC in use. Enable this in order to
> + use the cpufreq-dt driver on all Texas Instruments platforms that
> + provide dt based operating-points-v2 tables with opp-supported-hw
> + data provided. Required for cpufreq support on AM335x, AM437x,
> + DRA7x, and AM57x platforms.
> +
> config ARM_PXA2xx_CPUFREQ
> tristate "Intel PXA2xx CPUfreq driver"
> depends on PXA27x || PXA25x
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 0a9b6a093646..5b1b6ec0a9f0 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -77,6 +77,7 @@ obj-$(CONFIG_ARM_SPEAR_CPUFREQ) +=
> spear-cpufreq.o
> obj-$(CONFIG_ARM_STI_CPUFREQ)+= sti-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)+= tegra20-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
> +obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
> obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
> obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
> obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> new file mode 100644
> index ..e47b452aadd0
> --- /dev/null
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -0,0 +1,254 @@
> +/*
> + * TI CPUFreq/OPP hw-supported driver
> + *
> + * Copyright (C) 2016 Texas Instruments, Inc.
> + *Dave Gerlach
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define REVISION_MASK(0xF << 28)
Use below shift-mask here ?
> +#define REVISION_SHIFT 28
> +
> +#define DRA7_EFUSE_HAS_OD_MPU_OPP11
> +#define DRA7_EFUSE_HAS_HIGH_MPU_OPP 15
> +#define DRA7_EFUSE_HAS_ALL_MPU_OPP 23
> +
> +#define DRA7_EFUSE_NOM_MPU_OPP BIT(0)
> +#define DRA7_EFUSE_OD_MPU_OPPBIT(1)
> +#define DRA7_EFUSE_HIGH_MPU_OPP BIT(2)
> +
> +#define VERSION_COUNT2
> +
> +static struct ti_cpufreq_data {
> + struct device *cpu;
> + struct regmap *opp_efuse;
> + struct regmap *revision;
> +} opp_data;
> +
> +static struct ti_cpufreq_soc_data {
> + unsigned long (*efuse_xlate)(unsigned long efuse);
> +} *soc_data;
> +
> +static unsigned long amx3_efuse_xlate(unsigned long efuse)
> +{
> + /* AM335x and AM437x use "OPP disable" bits, so invert */
> + return ~efuse;
> +}
> +
> +static unsigned long dra7_efuse
[PATCH V1 4/4] MIPS: Loongson1C: Add defconfig
Add defconfig file for Loongson1C Signed-off-by: Yang Ling --- arch/mips/configs/loongson1c_defconfig | 126 + 1 file changed, 126 insertions(+) create mode 100644 arch/mips/configs/loongson1c_defconfig diff --git a/arch/mips/configs/loongson1c_defconfig b/arch/mips/configs/loongson1c_defconfig new file mode 100644 index 000..2304d41 --- /dev/null +++ b/arch/mips/configs/loongson1c_defconfig @@ -0,0 +1,126 @@ +CONFIG_MACH_LOONGSON32=y +CONFIG_LOONGSON1_LS1C=y +CONFIG_PREEMPT=y +# CONFIG_SECCOMP is not set +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_KERNEL_XZ=y +CONFIG_SYSVIPC=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=16 +CONFIG_NAMESPACES=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_EXPERT=y +CONFIG_PERF_EVENTS=y +# CONFIG_COMPAT_BRK is not set +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_LBDAF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +# CONFIG_SUSPEND is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_SYN_COOKIES=y +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_DIAG is not set +# CONFIG_IPV6 is not set +# CONFIG_WIRELESS is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_STANDALONE is not set +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_LOONGSON1=y +CONFIG_MTD_UBI=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_SCSI=m +# CONFIG_SCSI_PROC_FS is not set +CONFIG_BLK_DEV_SD=m +# CONFIG_SCSI_LOWLEVEL is not set +CONFIG_NETDEVICES=y +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +CONFIG_STMMAC_ETH=y +# CONFIG_NET_VENDOR_WIZNET is not set +# CONFIG_WLAN is not set +CONFIG_INPUT_EVDEV=y +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +CONFIG_VT_HW_CONSOLE_BINDING=y +CONFIG_LEGACY_PTY_COUNT=8 +# CONFIG_DEVKMEM is not set +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +# CONFIG_HW_RANDOM is not set +CONFIG_GPIOLIB=y +CONFIG_GPIO_LOONGSON1=y +# CONFIG_HWMON is not set +# CONFIG_VGA_CONSOLE is not set +CONFIG_HID_GENERIC=m +CONFIG_USB_HID=m +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_EHCI_TT_NEWSCHED is not set +CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_STORAGE=m +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_PL2303=m +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_LOONGSON1=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT2_FS=y +CONFIG_EXT2_FS_XATTR=y +CONFIG_EXT2_FS_POSIX_ACL=y +CONFIG_EXT2_FS_SECURITY=y +CONFIG_EXT3_FS=y +CONFIG_EXT3_FS_POSIX_ACL=y +CONFIG_EXT3_FS_SECURITY=y +# CONFIG_DNOTIFY is not set +CONFIG_VFAT_FS=y +CONFIG_PROC_KCORE=y +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_UBIFS_FS=y +CONFIG_UBIFS_FS_ADVANCED_COMPR=y +CONFIG_UBIFS_ATIME_SUPPORT=y +CONFIG_NFS_FS=y +CONFIG_ROOT_NFS=y +CONFIG_NLS_CODEPAGE_437=m +CONFIG_NLS_ISO8859_1=m +CONFIG_DYNAMIC_DEBUG=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_DEBUG_FS=y +CONFIG_MAGIC_SYSRQ=y +# CONFIG_SCHED_DEBUG is not set +# CONFIG_DEBUG_PREEMPT is not set +# CONFIG_FTRACE is not set +# CONFIG_EARLY_PRINTK is not set +# CONFIG_CRYPTO_ECHAINIV is not set +# CONFIG_CRYPTO_HW is not set -- 1.9.1
[PATCH V1 3/4] MIPS: Loongson1C: Add board support
Adds basic platform devices for Loongson1C, including serial port and ethernet. Signed-off-by: Yang Ling --- arch/mips/Kconfig | 13 + arch/mips/include/asm/mach-loongson32/irq.h | 41 ++- arch/mips/include/asm/mach-loongson32/loongson1.h | 5 ++ arch/mips/include/asm/mach-loongson32/regs-clk.h | 34 + arch/mips/include/asm/mach-loongson32/regs-mux.h | 61 +++ arch/mips/loongson32/Kconfig | 15 ++ arch/mips/loongson32/Makefile | 6 +++ arch/mips/loongson32/Platform | 1 + arch/mips/loongson32/common/irq.c | 55 ++-- arch/mips/loongson32/common/platform.c| 19 +++ arch/mips/loongson32/common/setup.c | 4 ++ arch/mips/loongson32/ls1c/Makefile| 5 ++ arch/mips/loongson32/ls1c/board.c | 28 +++ 13 files changed, 283 insertions(+), 4 deletions(-) create mode 100644 arch/mips/loongson32/ls1c/Makefile create mode 100644 arch/mips/loongson32/ls1c/board.c diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index e237868..4093cfa 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1384,6 +1384,16 @@ config CPU_LOONGSON1B The Loongson 1B is a 32-bit SoC, which implements the MIPS32 release 2 instruction set. +config CPU_LOONGSON1C + bool "Loongson 1C" + depends on SYS_HAS_CPU_LOONGSON1C + select CPU_LOONGSON1 + select ARCH_WANT_OPTIONAL_GPIOLIB + select LEDS_GPIO_REGISTER + help + The Loongson 1C is a 32-bit SoC, which implements the MIPS32 + release 2 instruction set. + config CPU_MIPS32_R1 bool "MIPS32 Release 1" depends on SYS_HAS_CPU_MIPS32_R1 @@ -1827,6 +1837,9 @@ config SYS_HAS_CPU_LOONGSON2F config SYS_HAS_CPU_LOONGSON1B bool +config SYS_HAS_CPU_LOONGSON1C + bool + config SYS_HAS_CPU_MIPS32_R1 bool diff --git a/arch/mips/include/asm/mach-loongson32/irq.h b/arch/mips/include/asm/mach-loongson32/irq.h index c1c7441..8c01b30 100644 --- a/arch/mips/include/asm/mach-loongson32/irq.h +++ b/arch/mips/include/asm/mach-loongson32/irq.h @@ -36,9 +36,14 @@ #define LS1X_IRQ(n, x) (LS1X_IRQ_BASE + (n << 5) + (x)) #define LS1X_UART0_IRQ LS1X_IRQ(0, 2) +#if defined(CONFIG_LOONGSON1_LS1B) #define LS1X_UART1_IRQ LS1X_IRQ(0, 3) #define LS1X_UART2_IRQ LS1X_IRQ(0, 4) #define LS1X_UART3_IRQ LS1X_IRQ(0, 5) +#elif defined(CONFIG_LOONGSON1_LS1C) +#define LS1X_UART1_IRQ LS1X_IRQ(0, 4) +#define LS1X_UART2_IRQ LS1X_IRQ(0, 5) +#endif #define LS1X_CAN0_IRQ LS1X_IRQ(0, 6) #define LS1X_CAN1_IRQ LS1X_IRQ(0, 7) #define LS1X_SPI0_IRQ LS1X_IRQ(0, 8) @@ -47,6 +52,9 @@ #define LS1X_DMA0_IRQ LS1X_IRQ(0, 13) #define LS1X_DMA1_IRQ LS1X_IRQ(0, 14) #define LS1X_DMA2_IRQ LS1X_IRQ(0, 15) +#if defined(CONFIG_LOONGSON1_LS1C) +#define LS1X_NAND_IRQ LS1X_IRQ(0, 16) +#endif #define LS1X_PWM0_IRQ LS1X_IRQ(0, 17) #define LS1X_PWM1_IRQ LS1X_IRQ(0, 18) #define LS1X_PWM2_IRQ LS1X_IRQ(0, 19) @@ -54,18 +62,49 @@ #define LS1X_RTC_INT0_IRQ LS1X_IRQ(0, 21) #define LS1X_RTC_INT1_IRQ LS1X_IRQ(0, 22) #define LS1X_RTC_INT2_IRQ LS1X_IRQ(0, 23) +#if defined(CONFIG_LOONGSON1_LS1B) #define LS1X_TOY_INT0_IRQ LS1X_IRQ(0, 24) #define LS1X_TOY_INT1_IRQ LS1X_IRQ(0, 25) #define LS1X_TOY_INT2_IRQ LS1X_IRQ(0, 26) #define LS1X_RTC_TICK_IRQ LS1X_IRQ(0, 27) #define LS1X_TOY_TICK_IRQ LS1X_IRQ(0, 28) +#define LS1X_UART4_IRQ LS1X_IRQ(0, 29) +#define LS1X_UART5_IRQ LS1X_IRQ(0, 30) +#elif defined(CONFIG_LOONGSON1_LS1C) +#define LS1X_UART3_IRQ LS1X_IRQ(0, 29) +#define LS1X_ADC_IRQ LS1X_IRQ(0, 30) +#define LS1X_SDIO_IRQ LS1X_IRQ(0, 31) +#endif #define LS1X_EHCI_IRQ LS1X_IRQ(1, 0) #define LS1X_OHCI_IRQ LS1X_IRQ(1, 1) +#if defined(CONFIG_LOONGSON1_LS1B) #define LS1X_GMAC0_IRQ LS1X_IRQ(1, 2) #define LS1X_GMAC1_IRQ LS1X_IRQ(1, 3) +#elif defined(CONFIG_LOONGSON1_LS1C) +#define LS1X_OTG_IRQ LS1X_IRQ(1, 2) +#define LS1X_GMAC0_IRQ LS1X_IRQ(1, 3) +#define LS1X_CAM_IRQ LS1X_IRQ(1, 4) +#define LS1X_UART4_IRQ LS1X_IRQ(1, 5) +#define LS1X_UART5_IRQ LS1X_IRQ(1, 6) +#define LS1X_UART6_IRQ LS1X_IRQ(1, 7) +#define LS1X_UART7_IRQ LS1X_IRQ(1, 8) +#define LS1X_UART8_IRQ LS1X_IRQ(1, 9) +#define LS1X_UART9_IRQ LS1X_IRQ(1, 13) +#def
Re: [PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC
On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote: > I spend some time to make tools/testing/selftest/rcutorture run on PPC, > here are some documention and fixes made while I was trying. > > The scripts are able to run and get results on PPC, however please > note there are some stalls even build errors that could be found > by the tests currently. > > As I'm certainly not an expert of qemu or bash programming, there > may be something I am missing in those patches. So tests and comments > are welcome ;-) > > Regards, > Boqun > > Boqun Feng (4): > rcutorture/doc: Add a new way to create initrd using dracut > rcutorture: Use vmlinux as the fallback kernel image > rcutorture: Make -soundhw a x86 specific option > rcutorture: Don't specify the cpu type of QEMU on PPC All four of these seem reasonable to me: Reviewed-by: Josh Triplett I responded to the -soundhw patch, trying to track down why that option was needed in the first place, and seeking a solution that doesn't require adding to the set of target-specific options. But I don't think that investigation should block your fix.
Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote: > The option "-soundhw pcspk" gives me a error on PPC as follow: > > qemu-system-ppc64: ISA bus not available for pcspk > > , which means this option doesn't work on ppc by default. So simply make > this an x86-specific option via identify_qemu_args(). > > Signed-off-by: Boqun Feng The emulated system for RCU testing does not need sound hardware at all. Paul added this option in commit 16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound hardware, saying that '"-soundhw pcspk" makes the script a bit less dependent on odd audio libraries being installed'. Unfortunately, it looks like there isn't a "-soundhw none". As far as I can tell, currently the only way to completely eliminate sound hardware is to pass "-nodefaults" and then explicitly specify each desired device; while that would solve the issue, it would likely introduce *more* hardware-specific command-line options... I've filed two feature requests on upstream qemu to make this simpler: https://bugs.launchpad.net/qemu/+bug/1583420 and https://bugs.launchpad.net/qemu/+bug/1583421 . Paul, what did you mean by "dependent on odd audio libraries"? Did you mean in the guest or the host? And either way, is this something that could potentially be solved another way? - Josh Triplett
[PATCH V1 2/4] MIPS: Add CPU support for Loongson1C
Loongson1C is a 32-bit SoC designed by Loongson Technology Co., Ltd, with many features similar to Loongson1B. Signed-off-by: Yang Ling --- arch/mips/include/asm/cpu-type.h | 3 ++- arch/mips/include/asm/cpu.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/mips/include/asm/cpu-type.h b/arch/mips/include/asm/cpu-type.h index fbe1881..bdd6dc1 100644 --- a/arch/mips/include/asm/cpu-type.h +++ b/arch/mips/include/asm/cpu-type.h @@ -24,7 +24,8 @@ static inline int __pure __get_cpu_type(const int cpu_type) case CPU_LOONGSON3: #endif -#ifdef CONFIG_SYS_HAS_CPU_LOONGSON1B +#if defined(CONFIG_SYS_HAS_CPU_LOONGSON1B) || \ +defined(CONFIG_SYS_HAS_CPU_LOONGSON1C) case CPU_LOONGSON1: #endif diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h index a7a9185..f70517d 100644 --- a/arch/mips/include/asm/cpu.h +++ b/arch/mips/include/asm/cpu.h @@ -239,6 +239,7 @@ #define PRID_REV_VR41300x0080 #define PRID_REV_34K_V1_0_20x0022 #define PRID_REV_LOONGSON1B0x0020 +#define PRID_REV_LOONGSON1C0x0020 /* Same as Loongson-1B */ #define PRID_REV_LOONGSON2E0x0002 #define PRID_REV_LOONGSON2F0x0003 #define PRID_REV_LOONGSON3A0x0005 -- 1.9.1
[PATCH] fbcon: use default if cursor blink interval is not valid
Two current [1] and three previous [2] systems locked during boot
because the cursor flash timer was set using an ops->cur_blink_jiffies
value of 0. Previous patches attempted to solve the problem by moving
variable initialization earlier in the setup sequence [2].
Use the normal cursor blink default interval of 200 ms if
ops->cur_blink_jiffies is not in the range specified in commit
bd63364caa8d. Since invalid values are not used, specific system
initialization timings should not cause lockups.
[1] https://bugs.launchpad.net/bugs/1574814
[2] see commits: 2a17d7e80f1d, f235f664a8af, a1e533ec07d5
Signed-off-by: Scot Doyle
Cc: [v4.2]
---
drivers/video/console/fbcon.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 6e92917..da61d87 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -396,13 +396,23 @@ static void fb_flashcursor(struct work_struct *work)
console_unlock();
}
+static int cursor_blink_jiffies(int candidate)
+{
+ if (candidate >= msecs_to_jiffies(50) &&
+ candidate <= msecs_to_jiffies(USHRT_MAX))
+ return candidate;
+ else
+ return HZ / 5;
+}
+
static void cursor_timer_handler(unsigned long dev_addr)
{
struct fb_info *info = (struct fb_info *) dev_addr;
struct fbcon_ops *ops = info->fbcon_par;
queue_work(system_power_efficient_wq, &info->queue);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
+ mod_timer(&ops->cursor_timer, jiffies +
+ cursor_blink_jiffies(ops->cur_blink_jiffies));
}
static void fbcon_add_cursor_timer(struct fb_info *info)
@@ -417,7 +427,8 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
init_timer(&ops->cursor_timer);
ops->cursor_timer.function = cursor_timer_handler;
- ops->cursor_timer.expires = jiffies + ops->cur_blink_jiffies;
+ ops->cursor_timer.expires = jiffies +
+ cursor_blink_jiffies(ops->cur_blink_jiffies);
ops->cursor_timer.data = (unsigned long ) info;
add_timer(&ops->cursor_timer);
ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
@@ -709,7 +720,6 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
struct fb_info *info,
}
if (!err) {
- ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
if (vc)
@@ -957,7 +967,6 @@ static const char *fbcon_startup(void)
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
- ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
p->con_rotate = initial_rotation;
set_blitting_type(vc, info);
--
2.1.4
investici
Jsem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi ucast. Odpoved na e-mailu nize v pripade zajmu. E-mail: pbrt...@gmail.com
[added to the 4.1 stable tree] workqueue: fix ghost PENDING flag while doing MQ IO
From: Roman Pen
This patch has been added to the 4.1 stable tree. If you have any
objections, please let us know.
===
[ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ]
The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
with the following backtrace:
[ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
[ 601.347574] Tainted: G O4.4.5-1-storage+ #6
[ 601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 601.348142] kworker/u129:5 D 880803077988 0 1636 2 0x
[ 601.348519] Workqueue: ibnbd_server_fileio_wq
ibnbd_dev_file_submit_io_worker [ibnbd_server]
[ 601.348999] 880803077988 88080466b900 8808033f9c80
880803078000
[ 601.349662] 880807c95000 7fff 815b0920
880803077ad0
[ 601.350333] 8808030779a0 815b01d5
880803077a38
[ 601.350965] Call Trace:
[ 601.351203] [] ? bit_wait+0x60/0x60
[ 601.351444] [] schedule+0x35/0x80
[ 601.351709] [] schedule_timeout+0x192/0x230
[ 601.351958] [] ? blk_flush_plug_list+0xc7/0x220
[ 601.352208] [] ? ktime_get+0x37/0xa0
[ 601.352446] [] ? bit_wait+0x60/0x60
[ 601.352688] [] io_schedule_timeout+0xa4/0x110
[ 601.352951] [] ? _raw_spin_unlock_irqrestore+0xe/0x10
[ 601.353196] [] bit_wait_io+0x1b/0x70
[ 601.353440] [] __wait_on_bit+0x5d/0x90
[ 601.353689] [] wait_on_page_bit+0xc0/0xd0
[ 601.353958] [] ? autoremove_wake_function+0x40/0x40
[ 601.354200] [] __filemap_fdatawait_range+0xe4/0x140
[ 601.354441] [] filemap_fdatawait_range+0x14/0x30
[ 601.354688] [] filemap_write_and_wait_range+0x3f/0x70
[ 601.354932] [] blkdev_fsync+0x1b/0x50
[ 601.355193] [] vfs_fsync_range+0x49/0xa0
[ 601.355432] [] blkdev_write_iter+0xca/0x100
[ 601.355679] [] __vfs_write+0xaa/0xe0
[ 601.355925] [] vfs_write+0xa9/0x1a0
[ 601.356164] [] kernel_write+0x38/0x50
The underlying device is a null_blk, with default parameters:
queue_mode= MQ
submit_queues = 1
Verification that nullb0 has something inflight:
root@pserver8:~# cat /sys/block/nullb0/inflight
01
root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec
cat {} \;
...
/sys/block/nullb0/mq/0/cpu2/rq_list
CTX pending:
8838038e2400
...
During debug it became clear that stalled request is always inserted in
the rq_list from the following path:
save_stack_trace_tsk + 34
blk_mq_insert_requests + 231
blk_mq_flush_plug_list + 281
blk_flush_plug_list + 199
wait_on_page_bit + 192
__filemap_fdatawait_range + 228
filemap_fdatawait_range + 20
filemap_write_and_wait_range + 63
blkdev_fsync + 27
vfs_fsync_range + 73
blkdev_write_iter + 202
__vfs_write + 170
vfs_write + 169
kernel_write + 56
So blk_flush_plug_list() was called with from_schedule == true.
If from_schedule is true, that means that finally blk_mq_insert_requests()
offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
i.e. it calls kblockd_schedule_delayed_work_on().
That means, that we race with another CPU, which is about to execute
__blk_mq_run_hw_queue() work.
Further debugging shows the following traces from different CPUs:
CPU#0 CPU#1
-- ---
reqeust A inserted
STORE hctx->ctx_map[0] bit marked
kblockd_schedule...() returns 1
request B inserted
STORE hctx->ctx_map[1] bit marked
kblockd_schedule...() returns 0
*** WORK PENDING bit is cleared ***
flush_busy_ctxs() is executed, but
bit 1, set by CPU#1, is not observed
As a result request B pended forever.
This behaviour can be explained by speculative LOAD of hctx->ctx_map on
CPU#0, which is reordered with clear of PENDING bit and executed _before_
actual STORE of bit 1 on CPU#1.
The proper fix is an explicit full barrier , which guarantees
that clear of PENDING bit is to be executed before all possible
speculative LOADS or STORES inside actual work function.
Signed-off-by: Roman Pen
Cc: Gioh Kim
Cc: Michael Wang
Cc: Tejun Heo
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 6d63116..32152a4 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -654,6 +654,35 @@ static void set_work_pool_and_clear_pending(struct
work_struct *work,
*/
smp_wmb();
set_work_data(work, (unsigned long)pool_id << WORK_OFFQ_POOL_SHIFT, 0);
+ /*
+* The following mb guarantees that previous clear of a PENDING bit
+* wi
[added to the 3.18 stable tree] workqueue: fix ghost PENDING flag while doing MQ IO
From: Roman Pen
This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.
===
[ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ]
The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
with the following backtrace:
[ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
[ 601.347574] Tainted: G O4.4.5-1-storage+ #6
[ 601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 601.348142] kworker/u129:5 D 880803077988 0 1636 2 0x
[ 601.348519] Workqueue: ibnbd_server_fileio_wq
ibnbd_dev_file_submit_io_worker [ibnbd_server]
[ 601.348999] 880803077988 88080466b900 8808033f9c80
880803078000
[ 601.349662] 880807c95000 7fff 815b0920
880803077ad0
[ 601.350333] 8808030779a0 815b01d5
880803077a38
[ 601.350965] Call Trace:
[ 601.351203] [] ? bit_wait+0x60/0x60
[ 601.351444] [] schedule+0x35/0x80
[ 601.351709] [] schedule_timeout+0x192/0x230
[ 601.351958] [] ? blk_flush_plug_list+0xc7/0x220
[ 601.352208] [] ? ktime_get+0x37/0xa0
[ 601.352446] [] ? bit_wait+0x60/0x60
[ 601.352688] [] io_schedule_timeout+0xa4/0x110
[ 601.352951] [] ? _raw_spin_unlock_irqrestore+0xe/0x10
[ 601.353196] [] bit_wait_io+0x1b/0x70
[ 601.353440] [] __wait_on_bit+0x5d/0x90
[ 601.353689] [] wait_on_page_bit+0xc0/0xd0
[ 601.353958] [] ? autoremove_wake_function+0x40/0x40
[ 601.354200] [] __filemap_fdatawait_range+0xe4/0x140
[ 601.354441] [] filemap_fdatawait_range+0x14/0x30
[ 601.354688] [] filemap_write_and_wait_range+0x3f/0x70
[ 601.354932] [] blkdev_fsync+0x1b/0x50
[ 601.355193] [] vfs_fsync_range+0x49/0xa0
[ 601.355432] [] blkdev_write_iter+0xca/0x100
[ 601.355679] [] __vfs_write+0xaa/0xe0
[ 601.355925] [] vfs_write+0xa9/0x1a0
[ 601.356164] [] kernel_write+0x38/0x50
The underlying device is a null_blk, with default parameters:
queue_mode= MQ
submit_queues = 1
Verification that nullb0 has something inflight:
root@pserver8:~# cat /sys/block/nullb0/inflight
01
root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec
cat {} \;
...
/sys/block/nullb0/mq/0/cpu2/rq_list
CTX pending:
8838038e2400
...
During debug it became clear that stalled request is always inserted in
the rq_list from the following path:
save_stack_trace_tsk + 34
blk_mq_insert_requests + 231
blk_mq_flush_plug_list + 281
blk_flush_plug_list + 199
wait_on_page_bit + 192
__filemap_fdatawait_range + 228
filemap_fdatawait_range + 20
filemap_write_and_wait_range + 63
blkdev_fsync + 27
vfs_fsync_range + 73
blkdev_write_iter + 202
__vfs_write + 170
vfs_write + 169
kernel_write + 56
So blk_flush_plug_list() was called with from_schedule == true.
If from_schedule is true, that means that finally blk_mq_insert_requests()
offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
i.e. it calls kblockd_schedule_delayed_work_on().
That means, that we race with another CPU, which is about to execute
__blk_mq_run_hw_queue() work.
Further debugging shows the following traces from different CPUs:
CPU#0 CPU#1
-- ---
reqeust A inserted
STORE hctx->ctx_map[0] bit marked
kblockd_schedule...() returns 1
request B inserted
STORE hctx->ctx_map[1] bit marked
kblockd_schedule...() returns 0
*** WORK PENDING bit is cleared ***
flush_busy_ctxs() is executed, but
bit 1, set by CPU#1, is not observed
As a result request B pended forever.
This behaviour can be explained by speculative LOAD of hctx->ctx_map on
CPU#0, which is reordered with clear of PENDING bit and executed _before_
actual STORE of bit 1 on CPU#1.
The proper fix is an explicit full barrier , which guarantees
that clear of PENDING bit is to be executed before all possible
speculative LOADS or STORES inside actual work function.
Signed-off-by: Roman Pen
Cc: Gioh Kim
Cc: Michael Wang
Cc: Tejun Heo
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 2273f53..fabb96d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -623,6 +623,35 @@ static void set_work_pool_and_clear_pending(struct
work_struct *work,
*/
smp_wmb();
set_work_data(work, (unsigned long)pool_id << WORK_OFFQ_POOL_SHIFT, 0);
+ /*
+* The following mb guarantees that previous clear of a PENDING bit
+* w
Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
I'm travelling and very busy with the merge window. So sorry I won't be able to think about this for some time.
Re: [GIT] Networking
From: Linus Torvalds Date: Wed, 18 May 2016 11:45:06 -0700 > David, do you happen to recall that merge conflict? I think you must > have removed that "skb_info" variable declaration and initialization > manually (due to the "unused variable" warning, which in turn was due > to the incorrect merge of the actual conflict), because I think git > would have merged that line into the result. Yes, I know I buggered this merge conflict and Kalle said he'd have a fix coming my way ASAP. Sorry, I was travelling today, so I'll catch up with this tomorrow.
[GIT PULL] security subsystem updates for 4.7
Please pull these updates for the 4.7 kernel. Highlights: 1. A new LSM, "LoadPin", from Kees Cook is added, which allows forcing of modules and firmware to be loaded from a specific device (this is from ChromeOS, where the device as a whole is verified cryptographically via dm-verity). This is disabled by default but can be configured to be enabled by default (don't do this if you don't know what you're doing). 2. Keys: allow authentication data to be stored in an asymmetric key. Lots of general fixes and updates. 3. SELinux: add restrictions for loading of kernel modules via finit_module(). Distinguish non-init user namespace capability checks. Apply execstack check on thread stacks. The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next for you to fetch changes up to b937190c40de0f6f07f592042e3097b16c6b0130: LSM: LoadPin: provide enablement CONFIG (2016-05-17 20:10:30 +1000) Andreas Ziegler (1): security: integrity: Remove select to deleted option PUBLIC_KEY_ALGO_RSA David Howells (23): X.509: Whitespace cleanup KEYS: Allow authentication data to be stored in an asymmetric key KEYS: Add identifier pointers to public_key_signature struct X.509: Retain the key verification data PKCS#7: Make the signature a pointer rather than embedding it X.509: Extract signature digest and make self-signed cert checks earlier X.509: Fix self-signed determination KEYS: Generalise system_verify_data() to provide access to internal content PKCS#7: Make trust determination dependent on contents of trust keyring KEYS: Add a facility to restrict new links into a keyring KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c KEYS: Generalise x509_request_asymmetric_key() X.509: Use verify_signature() if we have a struct key * to use X.509: Move the trust validation code out to its own file KEYS: Make the system trusted keyring depend on the asymmetric key type KEYS: Move the point of trust determination to __key_link() KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED certs: Add a secondary system keyring that can be added to dynamically IMA: Use the the system trusted keyrings instead of .ima_mok KEYS: user_update should use copy of payload made during preparsing Merge branch 'keys-misc' into keys-next Merge branch 'keys-sig' into keys-next Merge branch 'keys-trust' into keys-next Dmitry Kasatkin (1): vfs: forbid write access when reading a file into memory James Morris (2): Merge tag 'keys-next-20160505' of git://git.kernel.org/.../dhowells/linux-fs into next Merge branch 'stable-4.7' of git://git.infradead.org/users/pcmoore/selinux into next Janak Desai (1): netlabel: fix a problem with netlbl_secattr_catmap_setrng() Jeff Vander Stoep (1): selinux: restrict kernel module loading Kees Cook (7): string_helpers: add kstrdup_quotable string_helpers: add kstrdup_quotable_cmdline string_helpers: add kstrdup_quotable_file Yama: consolidate error reporting LSM: LoadPin for kernel file loading restrictions fs: fix over-zealous use of "const" LSM: LoadPin: provide enablement CONFIG Kirill Marinushkin (1): Security: Keys: Big keys stored encrypted Mat Martineau (1): KEYS: Add KEYCTL_DH_COMPUTE command Mickaël Salaün (1): seccomp: Fix comment typo Mimi Zohar (3): fs: define a string representation of the kernel_read_file_id enumeration ima: fix ima_inode_post_setattr ima: add support for creating files using the mknodat syscall Paolo Abeni (1): security: drop the unused hook skb_owned_by Paul Moore (6): selinux: don't revalidate inodes in selinux_socket_getpeersec_dgram() selinux: simply inode label states to INVALID and INITIALIZED selinux: consolidate the ptrace parent lookup code selinux: don't revalidate an inode's label when explicitly setting it selinux: delay inode label lookup as long as possible selinux: check ss_initialized before revalidating an inode label Prarit Bhargava (1): selinux: Change bool variable name to index. Sasha Levin (1): Yama: use atomic allocations when reporting Stephen Smalley (2): selinux: distinguish non-init user namespace capability checks selinux: apply execstack check on thread stacks Documentation/security/LoadPin.txt| 17 ++ Documentation/security/keys.txt | 52 ++ MAINTAINERS | 6 + arch/x86/kernel/kexec-bzimage64.c | 18 +- certs/Kconfig | 9 + certs/system_keyring.c
Re: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects
Hi Calvin, Here is the log w.r.t target drive 2:0:0:0 with your changes, mpt3sas version 12.100.00.00 unloading kobject: '2:0:0:0' (8800d50f1010): kobject_uevent_env kobject: '2:0:0:0' (8800d50f1010): fill_kobj_path: path = '/devices/pci:00/:00:07.0/host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/bsg/2:0:0:0' kobject: 'bsg' (88011a011780): kobject_cleanup, parent 8800d58611a8 kobject: 'bsg' (88011a011780): auto cleanup kobject_del kobject: 'bsg' (88011a011780): calling ktype release kobject: 'bsg': free name kobject: '2:0:0:0' (8800d50f1010): kobject_cleanup, parent (null) kobject: '2:0:0:0' (8800d50f1010): calling ktype release kobject: '2:0:0:0': free name kobject: 'sg0' (8800d50f1810): kobject_uevent_env kobject: 'sg0' (8800d50f1810): fill_kobj_path: path = '/devices/pci:00/:00:07.0/host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/scsi_generic/sg0' kobject: 'scsi_generic' (88011a011e80): kobject_cleanup, parent 8800d58611a8 kobject: 'scsi_generic' (88011a011e80): auto cleanup kobject_del kobject: 'scsi_generic' (88011a011e80): calling ktype release kobject: 'scsi_generic': free name kobject: 'sg0' (8800d50f1810): kobject_cleanup, parent (null) kobject: 'sg0' (8800d50f1810): calling ktype release kobject: 'sg0': free name kobject: '(null)' (88011a5af800): kobject_cleanup, parent (null) kobject: '(null)' (88011a5af800): calling ktype release kobject: '(null)' (8800da2a2880): kobject_cleanup, parent (null) kobject: '(null)' (8800da2a2880): calling ktype release kobject: '2:0:0:0' (8800d5861478): kobject_uevent_env kobject: '2:0:0:0' (8800d5861478): fill_kobj_path: path = '/devices/pci:00/:00:07.0/host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/scsi_device/2:0:0:0' kobject: 'scsi_device' (88011a011b00): kobject_cleanup, parent 8800d58611a8 kobject: 'scsi_device' (88011a011b00): auto cleanup kobject_del kobject: 'scsi_device' (88011a011b00): calling ktype release kobject: 'scsi_device': free name kobject: '2:0:0:0' (8800d5861478): kobject_cleanup, parent (null) kobject: '2:0:0:0' (8800d5861478): calling ktype release kobject: '2:0:0:0': free name kobject: '2:0:0:0' (8800da3de420): kobject_uevent_env kobject: '2:0:0:0' (8800da3de420): fill_kobj_path: path = '/devices/pci:00/:00:07.0/host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0' kobject: 'scsi_disk' (8800daa11180): kobject_cleanup, parent 8800d58611a8 kobject: 'scsi_disk' (8800daa11180): auto cleanup kobject_del kobject: 'scsi_disk' (8800daa11180): calling ktype release kobject: 'scsi_disk': free name kobject: 'integrity' (8800d98d2c00): kobject_uevent_env kobject: 'integrity' (8800d98d2c00): kobject_uevent_env: filter function caused the event to drop! kobject: 'integrity' (8800d98d2c00): kobject_cleanup, parent (null) kobject: 'integrity' (8800d98d2c00): does not have a release() function, it is broken and must be fixed. kobject: 'integrity': free name kobject: 'iosched' (8800d488b410): kobject_uevent_env kobject: 'iosched' (8800d488b410): kobject_uevent_env: filter function caused the event to drop! kobject: 'queue' (8800d9691120): kobject_uevent_env kobject: 'queue' (8800d9691120): kobject_uevent_env: filter function caused the event to drop! kobject: 'holders' (8800dae04000): kobject_cleanup, parent 8800d98d2880 kobject: 'holders' (8800dae04000): auto cleanup kobject_del kobject: 'holders' (8800dae04000): calling ktype release kobject: (8800dae04000): dynamic_kobj_release kobject: 'holders': free name kobject: 'slaves' (8800d9851740): kobject_cleanup, parent 8800d98d2880 kobject: 'slaves' (8800d9851740): auto cleanup kobject_del kobject: 'slaves' (8800d9851740): calling ktype release kobject: (8800d9851740): dynamic_kobj_release kobject: 'slaves': free name kobject: 'sda' (8800d98d2880): kobject_uevent_env kobject: 'sda' (8800d98d2880): fill_kobj_path: path = '/devices/pci:00/:00:07.0/host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/block/sda' kobject: 'block' (8800d9fe4c80): kobject_cleanup, parent 8800d58611a8 kobject: 'block' (8800d9fe4c80): auto cleanup kobject_del kobject: 'block' (8800d9fe4c80): calling ktype release kobject: 'block': free name sd 2:0:0:0: [sda] Synchronizing SCSI cache sd 2:0:0:0: tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 sd 2:0:0:0: tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 sd 2:0:0:0: tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 sd 2:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK kobject: '2:0:0:0' (8800da3de420): kobject_cleanup, parent (null) kobject: '2:0:0:0' (8800da3de420): calling ktype release kobject: 'sda' (8800d98d2880): kobject_cleanup, par
linux-next: build failure after merge of the security tree
Hi James,
After merging the security tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego':
fs/cifs/cifs_spnego.c:206:12: error: too few arguments to function
'keyring_alloc'
keyring = keyring_alloc(".cifs_spnego",
^
In file included from include/linux/cred.h:17:0,
from include/linux/sched.h:56,
from include/linux/kasan.h:4,
from include/linux/slab.h:118,
from fs/cifs/cifs_spnego.c:23:
include/linux/key.h:302:20: note: declared here
extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t
gid,
^
Caused by commit
5b82c5cbcfe4 ("cifs: Create dedicated keyring for spnego operations")
from the cifs tree interacting with commit
5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring")
from the security tree.
I added the following merge fix patch (and someone will have to let
Linus know):
From: Stephen Rothwell
Date: Thu, 19 May 2016 13:45:10 +1000
Subject: [PATCH] cifs: fix for keyringalloc() API change
Signed-off-by: Stephen Rothwell
---
fs/cifs/cifs_spnego.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/cifs_spnego.c b/fs/cifs/cifs_spnego.c
index 248ab431930c..9ef0dfcb2f95 100644
--- a/fs/cifs/cifs_spnego.c
+++ b/fs/cifs/cifs_spnego.c
@@ -207,7 +207,7 @@ init_cifs_spnego(void)
GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, cred,
(KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ,
- KEY_ALLOC_NOT_IN_QUOTA, NULL);
+ KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
if (IS_ERR(keyring)) {
ret = PTR_ERR(keyring);
goto failed_put_cred;
--
2.7.0
--
Cheers,
Stephen Rothwell
Re: Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'
On Wed, May 18, 2016 at 08:11:12PM -0700, Guenter Roeck wrote: > Hi, > > some of my ppc qemu tests crash with the following log message. > > VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available > partitions: > 01004096 ram0 (driver?) > 01014096 ram1 (driver?) > 01024096 ram2 (driver?) > 01034096 ram3 (driver?) > 01044096 ram4 (driver?) > 01054096 ram5 (driver?) > 01064096 ram6 (driver?) > 01074096 ram7 (driver?) > 01084096 ram8 (driver?) > 01094096 ram9 (driver?) > 010a4096 ram10 (driver?) > 010b4096 ram11 (driver?) > 010c4096 ram12 (driver?) > 010d4096 ram13 (driver?) > 010e4096 ram14 (driver?) > 010f4096 ram15 (driver?) > 16008383 hdc driver: ide-gd > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > A complete boot log is available at > http://kerneltests.org/builders/qemu-ppc-next/builds/408/steps/qemubuildcommand/logs/stdio > > Bisect points to commit 'drivers/of: Fix depth when unflattening devicetree'. > Reverting this commit fixes the problem. Bisect log is attached. > > The scripts and root file system used for the test are available at > https://github.com/groeck/linux-build-test/tree/master/rootfs/ppc > > Failing tests are > > powerpc:mac99:nosmp:ppc_book3s_defconfig > powerpc:g3beige:nosmp:ppc_book3s_defconfig > powerpc:mac99:smp:ppc_book3s_defconfig > Turns out this list of failed tests is incomplete. Also failing due to the same commit, and passing after the commit was reverted: arm:versatilepb-scsi:versatile_defconfig:versatile-pb arm:versatilepb:versatile_defconfig:versatile-pb arm:overo:multi_v7_defconfig:omap3-overo-tobi arm:overo:omap2plus_defconfig:omap3-overo-tobi arm:integratorcp:integrator_defconfig:integratorcp Log with failures is at http://kerneltests.org/builders/qemu-arm-next/builds/444/steps/qemubuildcommand/logs/stdio Guenter > Guenter > > --- > # bad: [1af872fb6cfb3c701d8819466a4672f85c3f17a3] dcssblk: fix the > direct_access prototype to add 'size' > # good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6 > git bisect start 'HEAD' 'v4.6' > # good: [586cf328ff7e7c0c32f89d6f2063c81143802c01] Merge remote-tracking > branch 'net-next/master' > git bisect good 586cf328ff7e7c0c32f89d6f2063c81143802c01 > # bad: [69bf2b19c358d937a3f40c07a08bc73476d43c02] Merge remote-tracking > branch 'tty/tty-next' > git bisect bad 69bf2b19c358d937a3f40c07a08bc73476d43c02 > # good: [c81e18989b12bdb70a056b05b94620eefd2aed7b] Merge remote-tracking > branch 'drm/drm-next' > git bisect good c81e18989b12bdb70a056b05b94620eefd2aed7b > # good: [4668e9adc5722b6fdf887d0bc70e9f5998507689] Merge remote-tracking > branch 'vfio/next' > git bisect good 4668e9adc5722b6fdf887d0bc70e9f5998507689 > # bad: [8ab5e17d29971673f08ce9cabfa6170e2f56fe07] Merge remote-tracking > branch 'ftrace/for-next' > git bisect bad 8ab5e17d29971673f08ce9cabfa6170e2f56fe07 > # bad: [a792d9ada26755882a5ea1e958bc582fe6f2d7bc] Merge remote-tracking > branch 'dt-rh/for-next' > git bisect bad a792d9ada26755882a5ea1e958bc582fe6f2d7bc > # good: [03da37387a3aa07e45d077043f48e7dc29206b62] Merge remote-tracking > branch 'trivial/for-next' > git bisect good 03da37387a3aa07e45d077043f48e7dc29206b62 > # good: [8f97c2814b5448d91a3c67081f7d978c097feabe] Documentation: dt: > interrupt-controller: fix spelling mistakes > git bisect good 8f97c2814b5448d91a3c67081f7d978c097feabe > # good: [947c82cbf01c9c6012cb96e385b5f6d6d1e1decb] drivers/of: Rename > unflatten_dt_node() > git bisect good 947c82cbf01c9c6012cb96e385b5f6d6d1e1decb > # bad: [047eb65024c00807ff8f0407580f088b23cf908e] of/unittest: Remove > unnecessary module.h header inclusion > git bisect bad 047eb65024c00807ff8f0407580f088b23cf908e > # good: [bb91f923d176578257aed682047653cc33148413] drivers/of: Export > of_detach_node() > git bisect good bb91f923d176578257aed682047653cc33148413 > # bad: [ac78f9bdcf3836cafcd114a76a9473380a3faef5] drivers/of: Fix depth when > unflattening devicetree > git bisect bad ac78f9bdcf3836cafcd114a76a9473380a3faef5 > # good: [b9c43856f21d97ffdfdd642acf2eb0b52d3b1555] of: dynamic: changeset > prop-update revert fix > git bisect good b9c43856f21d97ffdfdd642acf2eb0b52d3b1555 > # first bad commit: [ac78f9bdcf3836cafcd114a76a9473380a3faef5] drivers/of: > Fix depth when unflattening devicetree
Re: [PATCH 3.14 00/17] 3.14.70-stable review
On Wed, May 18, 2016 at 08:48:16PM -0700, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-queue boot: 234 boots: 15 failed, 215 passed with 1 offline, 3 > > untried/unknown (v3.14.69-17-g9f0aa90f9624) > > Interpretation: all good. > > The OMAP failures were due to a bug in my lab. > The at91 boards are newly added to mainline, so expected to be broken in > v3.14, so will be blacklisted. Thanks, your Interpretation is appreciated :)
[PATCH] mwifiex: fix racing condition when downloading firmware
The action 'check for winner' and 'download firmware' should be an
atomic action. This is true for btmrvl driver but not mwmfiex, which
cause firmware download to fail when the following senerio happens:
1) mwifiex check winner status: true
2) btmrvl check winner status: true, and start downloading firmware
3) mwfieix tries to download firmware, but failed because btmrvl is
already downloading.
This won't happen if 1) and 3) is an atomic action. This patch adds
sdio_claim/release_host call around those two actions to make sure it's
atomic.
Signed-off-by: Wei-Ning Huang
---
drivers/net/wireless/marvell/mwifiex/main.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c
b/drivers/net/wireless/marvell/mwifiex/main.c
index 8b67a55..2b65334 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -21,6 +21,7 @@
#include "wmm.h"
#include "cfg80211.h"
#include "11n.h"
+#include "sdio.h"
#define VERSION"1.0"
@@ -514,6 +515,7 @@ static void mwifiex_fw_dpc(const struct firmware *firmware,
void *context)
struct semaphore *sem = adapter->card_sem;
bool init_failed = false;
struct wireless_dev *wdev;
+ struct sdio_mmc_card *card = adapter->card;
if (!firmware) {
mwifiex_dbg(adapter, ERROR,
@@ -526,10 +528,16 @@ static void mwifiex_fw_dpc(const struct firmware
*firmware, void *context)
fw.fw_buf = (u8 *) adapter->firmware->data;
fw.fw_len = adapter->firmware->size;
- if (adapter->if_ops.dnld_fw)
+ if (adapter->if_ops.dnld_fw) {
ret = adapter->if_ops.dnld_fw(adapter, &fw);
- else
+ } else {
+ if (adapter->iface_type == MWIFIEX_SDIO)
+ sdio_claim_host(card->func);
ret = mwifiex_dnld_fw(adapter, &fw);
+ if (adapter->iface_type == MWIFIEX_SDIO)
+ sdio_release_host(card->func);
+ }
+
if (ret == -1)
goto err_dnld_fw;
--
2.1.2
[PATCH V1 1/4] clk: add Loongson1C clock support
This adds clock support to Loongson1C SoC.
Signed-off-by: Yang Ling
---
drivers/clk/clk-loongson1.c | 52 +++--
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/clk-loongson1.c b/drivers/clk/clk-loongson1.c
index ce2135c..cc9793a 100644
--- a/drivers/clk/clk-loongson1.c
+++ b/drivers/clk/clk-loongson1.c
@@ -15,8 +15,16 @@
#include
+#if defined(CONFIG_LOONGSON1_LS1B)
#define OSC(33 * 100)
#define DIV_APB2
+#define OSC_CLK"osc_33m_clk"
+#elif defined(CONFIG_LOONGSON1_LS1C)
+#define OSC(24 * 100)
+#define DIV_APB1
+#define OSC_CLK"osc_24m_clk"
+#endif
+
static DEFINE_SPINLOCK(_lock);
@@ -35,9 +43,15 @@ static unsigned long ls1x_pll_recalc_rate(struct clk_hw *hw,
u32 pll, rate;
pll = __raw_readl(LS1X_CLK_PLL_FREQ);
+#if defined(CONFIG_LOONGSON1_LS1B)
rate = 12 + (pll & 0x3f) + (((pll >> 8) & 0x3ff) >> 10);
rate *= OSC;
rate >>= 1;
+#elif defined(CONFIG_LOONGSON1_LS1C)
+ rate = ((pll >> 8) & 0xff) + ((pll >> 16) & 0xff);
+ rate *= OSC;
+ rate >>= 2;
+#endif
return rate;
}
@@ -78,20 +92,27 @@ static struct clk *__init clk_register_pll(struct device
*dev,
return clk;
}
-static const char *const cpu_parents[] = { "cpu_clk_div", "osc_33m_clk", };
-static const char *const ahb_parents[] = { "ahb_clk_div", "osc_33m_clk", };
-static const char *const dc_parents[] = { "dc_clk_div", "osc_33m_clk", };
+static const char *const cpu_parents[] = { "cpu_clk_div", OSC_CLK, };
+static const char *const ahb_parents[] = { "ahb_clk_div", OSC_CLK, };
+static const char *const dc_parents[] = { "dc_clk_div", OSC_CLK, };
+
+static const struct clk_div_table ahb_div_table[] = {
+ [0] = { .val = 0, .div = 2 },
+ [1] = { .val = 1, .div = 4 },
+ [2] = { .val = 2, .div = 3 },
+ [3] = { .val = 3, .div = 3 },
+};
void __init ls1x_clk_init(void)
{
struct clk *clk;
- clk = clk_register_fixed_rate(NULL, "osc_33m_clk", NULL, CLK_IS_ROOT,
+ clk = clk_register_fixed_rate(NULL, OSC_CLK, NULL, CLK_IS_ROOT,
OSC);
- clk_register_clkdev(clk, "osc_33m_clk", NULL);
+ clk_register_clkdev(clk, OSC_CLK, NULL);
- /* clock derived from 33 MHz OSC clk */
- clk = clk_register_pll(NULL, "pll_clk", "osc_33m_clk", 0);
+ /* clock derived from OSC clk */
+ clk = clk_register_pll(NULL, "pll_clk", OSC_CLK, 0);
clk_register_clkdev(clk, "pll_clk", NULL);
/* clock derived from PLL clk */
@@ -107,10 +128,14 @@ void __init ls1x_clk_init(void)
CLK_DIVIDER_ONE_BASED |
CLK_DIVIDER_ROUND_CLOSEST, &_lock);
clk_register_clkdev(clk, "cpu_clk_div", NULL);
+#if defined(CONFIG_LOONGSON1_LS1B)
clk = clk_register_mux(NULL, "cpu_clk", cpu_parents,
ARRAY_SIZE(cpu_parents),
CLK_SET_RATE_NO_REPARENT, LS1X_CLK_PLL_DIV,
BYPASS_CPU_SHIFT, BYPASS_CPU_WIDTH, 0, &_lock);
+#elif defined(CONFIG_LOONGSON1_LS1C)
+ clk = clk_register_fixed_factor(NULL, "cpu_clk", "cpu_clk_div", 0, 1,
1);
+#endif
clk_register_clkdev(clk, "cpu_clk", NULL);
/* _
@@ -123,10 +148,14 @@ void __init ls1x_clk_init(void)
0, LS1X_CLK_PLL_DIV, DIV_DC_SHIFT,
DIV_DC_WIDTH, CLK_DIVIDER_ONE_BASED, &_lock);
clk_register_clkdev(clk, "dc_clk_div", NULL);
+#if defined(CONFIG_LOONGSON1_LS1B)
clk = clk_register_mux(NULL, "dc_clk", dc_parents,
ARRAY_SIZE(dc_parents),
CLK_SET_RATE_NO_REPARENT, LS1X_CLK_PLL_DIV,
BYPASS_DC_SHIFT, BYPASS_DC_WIDTH, 0, &_lock);
+#elif defined(CONFIG_LOONGSON1_LS1C)
+ clk = clk_register_fixed_factor(NULL, "dc_clk", "dc_clk_div", 0, 1, 1);
+#endif
clk_register_clkdev(clk, "dc_clk", NULL);
/* _
@@ -135,6 +164,7 @@ void __init ls1x_clk_init(void)
*\___ PLL ___ DDR DIV ___| |
*|_|
*/
+#if defined(CONFIG_LOONGSON1_LS1B)
clk = clk_register_divider(NULL, "ahb_clk_div", "pll_clk",
0, LS1X_CLK_PLL_DIV, DIV_DDR_SHIFT,
DIV_DDR_WIDTH, CLK_DIVIDER_ONE_BASED,
@@ -144,6 +174,14 @@ void __init ls1x_clk_init(void)
ARRAY_SIZE(ahb_parents),
CLK_SET_RATE_NO_REPARENT, LS1X_CLK_PLL_DIV,
BYPASS_DDR_SHIFT, BYPASS_DDR_WIDTH, 0, &_lock);
+#elif defined(CONFIG_LOONGSON1_LS1C)
+ clk = clk_register_divider_table(NULL, "ahb_c
[PATCH 3/4] rcutorture: Make -soundhw a x86 specific option
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng
---
tools/testing/selftests/rcutorture/bin/functions.sh | 1 +
tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh
b/tools/testing/selftests/rcutorture/bin/functions.sh
index 616180153208..77fdb46cc65a 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -171,6 +171,7 @@ identify_qemu_append () {
identify_qemu_args () {
case "$1" in
qemu-system-x86_64|qemu-system-i386)
+ echo -soundhw pcspk
;;
qemu-system-ppc64)
echo -enable-kvm -M pseries -cpu POWER7 -nodefaults
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
index 46cb6bc098bd..d7a3de26dd11 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
@@ -8,9 +8,9 @@
#
# Usage: kvm-test-1-run.sh config builddir resdir seconds qemu-args boot_args
#
-# qemu-args defaults to "-enable-kvm -soundhw pcspk -nographic", along with
-# arguments specifying the number of CPUs and other
-# options generated from the underlying CPU architecture.
+# qemu-args defaults to "-enable-kvm -nographic", along with arguments
+# specifying the number of CPUs and other options
+# generated from the underlying CPU architecture.
# boot_args defaults to value returned by the per_version_boot_params
# shell function.
#
@@ -148,7 +148,7 @@ then
fi
# Generate -smp qemu argument.
-qemu_args="-enable-kvm -soundhw pcspk -nographic $qemu_args"
+qemu_args="-enable-kvm -nographic $qemu_args"
cpu_count=`configNR_CPUS.sh $config_template`
cpu_count=`configfrag_boot_cpus "$boot_args" "$config_template" "$cpu_count"`
vcpus=`identify_qemu_vcpus`
--
2.8.0
[PATCH 4/4] rcutorture: Don't specify the cpu type of QEMU on PPC
Do not restrict the cpu type to POWER7 for QEMU as we have POWER8 now.
Signed-off-by: Boqun Feng
---
tools/testing/selftests/rcutorture/bin/functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh
b/tools/testing/selftests/rcutorture/bin/functions.sh
index 77fdb46cc65a..56ac202859eb 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -174,7 +174,7 @@ identify_qemu_args () {
echo -soundhw pcspk
;;
qemu-system-ppc64)
- echo -enable-kvm -M pseries -cpu POWER7 -nodefaults
+ echo -enable-kvm -M pseries -nodefaults
echo -device spapr-vscsi
if test -n "$TORTURE_QEMU_INTERACTIVE" -a -n "$TORTURE_QEMU_MAC"
then
--
2.8.0
[PATCH 2/4] rcutorture: Use vmlinux as the fallback kernel image
vmlinux is available for all the architectures, and suitable for running
a KVM guest by QEMU, besides, we used to copy the vmlinux to $resdir
anyway. Therefore it makes sense to use it as the fallback kernel image
for rcutorture KVM tests.
This patch makes identify_boot_image() return vmlinux if
${TORTURE_BOOT_IMAGE} is not set on non-x86 architectures, also fixes
several places that hard-code "bzImage" as $KERNEL.
This also fixes a problem that PPC doesn't have a bzImage file as build
results.
Signed-off-by: Boqun Feng
---
tools/testing/selftests/rcutorture/bin/functions.sh | 10 --
tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 5 +++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh
b/tools/testing/selftests/rcutorture/bin/functions.sh
index b325470c01b3..616180153208 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -99,8 +99,9 @@ configfrag_hotplug_cpu () {
# identify_boot_image qemu-cmd
#
# Returns the relative path to the kernel build image. This will be
-# arch//boot/bzImage unless overridden with the TORTURE_BOOT_IMAGE
-# environment variable.
+# arch//boot/bzImage or vmlinux if bzImage is not a target for the
+# architecture, unless overridden with the TORTURE_BOOT_IMAGE environment
+# variable.
identify_boot_image () {
if test -n "$TORTURE_BOOT_IMAGE"
then
@@ -110,11 +111,8 @@ identify_boot_image () {
qemu-system-x86_64|qemu-system-i386)
echo arch/x86/boot/bzImage
;;
- qemu-system-ppc64)
- echo arch/powerpc/boot/bzImage
- ;;
*)
- echo ""
+ echo vmlinux
;;
esac
fi
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
index 4109f306d855..46cb6bc098bd 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
@@ -96,7 +96,8 @@ if test "$base_resdir" != "$resdir" -a -f
$base_resdir/bzImage -a -f $base_resdi
then
# Rerunning previous test, so use that test's kernel.
QEMU="`identify_qemu $base_resdir/vmlinux`"
- KERNEL=$base_resdir/bzImage
+ BOOT_IMAGE="`identify_boot_image $QEMU`"
+ KERNEL=$base_resdir/${BOOT_IMAGE##*/} # use the last component of
${BOOT_IMAGE}
ln -s $base_resdir/Make*.out $resdir # for kvm-recheck.sh
ln -s $base_resdir/.config $resdir # for kvm-recheck.sh
elif kvm-build.sh $config_template $builddir $T
@@ -110,7 +111,7 @@ then
if test -n "$BOOT_IMAGE"
then
cp $builddir/$BOOT_IMAGE $resdir
- KERNEL=$resdir/bzImage
+ KERNEL=$resdir/${BOOT_IMAGE##*/}
else
echo No identifiable boot image, not running KVM, see $resdir.
echo Do the torture scripts know about your architecture?
--
2.8.0
[PATCH 1/4] rcutorture/doc: Add a new way to create initrd using dracut
Using dracut is another way to get an initramfs for kvm based rcu torture tests, which is more flexible than using the host's initramfs image, because modules and binaries may be added or removed via dracut command options. So add an example in the document, in case that there are some situations where host's initramfs couldn't be used. Signed-off-by: Boqun Feng --- tools/testing/selftests/rcutorture/doc/initrd.txt | 22 ++ 1 file changed, 22 insertions(+) diff --git a/tools/testing/selftests/rcutorture/doc/initrd.txt b/tools/testing/selftests/rcutorture/doc/initrd.txt index 4170e714f044..833f826d6ec2 100644 --- a/tools/testing/selftests/rcutorture/doc/initrd.txt +++ b/tools/testing/selftests/rcutorture/doc/initrd.txt @@ -13,6 +13,22 @@ cd initrd cpio -id < /tmp/initrd.img.zcat +Another way to create an initramfs image is using "dracut"[1], which is +available on many distros, however the initramfs dracut generates is a cpio +archive with another cpio archive in it, so an extra step is needed to create +the initrd directory hierarchy. + +Here are the commands to create a initrd directory for rcutorture using +dracut: + + +dracut --no-hostonly --no-hostonly-cmdline --module "base bash shutdown" /tmp/initramfs.img +cd tools/testing/selftests/rcutorture +mkdir initrd +cd initrd +/usr/lib/dracut/skipcpio /tmp/initramfs.img | zcat | cpio -id < /tmp/initramfs.img + + Interestingly enough, if you are running rcutorture, you don't really need userspace in many cases. Running without userspace has the advantage of allowing you to test your kernel independently of the @@ -89,3 +105,9 @@ while : do sleep 10 done + + +References: +[1]: https://dracut.wiki.kernel.org/index.php/Main_Page +[2]: http://blog.elastocloud.org/2015/06/rapid-linux-kernel-devtest-with-qemu.html +[3]: https://www.centos.org/forums/viewtopic.php?t=51621 -- 2.8.0
[PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC
I spend some time to make tools/testing/selftest/rcutorture run on PPC, here are some documention and fixes made while I was trying. The scripts are able to run and get results on PPC, however please note there are some stalls even build errors that could be found by the tests currently. As I'm certainly not an expert of qemu or bash programming, there may be something I am missing in those patches. So tests and comments are welcome ;-) Regards, Boqun Boqun Feng (4): rcutorture/doc: Add a new way to create initrd using dracut rcutorture: Use vmlinux as the fallback kernel image rcutorture: Make -soundhw a x86 specific option rcutorture: Don't specify the cpu type of QEMU on PPC .../testing/selftests/rcutorture/bin/functions.sh | 13 ++--- .../selftests/rcutorture/bin/kvm-test-1-run.sh | 13 +++-- tools/testing/selftests/rcutorture/doc/initrd.txt | 22 ++ 3 files changed, 35 insertions(+), 13 deletions(-) -- 2.8.0
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On Wed, 2016-05-18 at 12:03 -0600, Tony S wrote: > On Wed, May 18, 2016 at 11:59 AM, Tony S > wrote: > > On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky > > wrote: > > > Tony narrowed the problem down to update_curr() where vruntime is > > > calculated, based on runqueue's clock_task value. That value is > > > computed > > > in update_rq_clock_task(), which needs paravirt_steal_rq_enabled. > > > > > Hi Boris, > > > > You are right. > > > > The real problem is steal_clock in pv_time_ops is implemented in > > KVM > > but not in Xen. > > > > [...] > > > > Therefore, even though update_rq_clock_task() calculates the value > > and > > paravirt_steal_rq_enabled option is enabled, the steal value just > > returns 0. This will cause the problem which I mentioned. > > > > update_rq_clock_task > > --> paravirt_steal_clock > > --> pv_time_ops.steal_clock > > --> native_steal_clock (if in Xen) > > --> 0 > > Ok, thanks again for confirming this. > Also, I tried the latest long term version of Linux 4.4, this issue > still exists there. Hoping the next version can add this patch. > Yes, as Juergen said here: http://lists.xen.org/archives/html/xen-devel/2016-05/msg01712.html he has in his plans to implement the full mechanism. It will just take a bit longer, due to the amount of work necessary for this second part. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq
On 18-05-16, 18:30, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
> to provide an opp-supported-hw property for each OPP to define when
> it is available. This driver is responsible for reading and parsing
> registers to determine which OPPs can be selectively enabled based
> on the specific SoC in use by matching against the opp-supported-hw
> data.
Here and ...
> Signed-off-by: Dave Gerlach
> ---
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 89
> ++
> 1 file changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> new file mode 100644
> index ..f719b2df2a1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> @@ -0,0 +1,89 @@
> +Bindings for TI's CPUFreq driver
> +
> +
> +The ti-cpufreq driver works with the operating-points-v2 binding described
> +at [../opp/opp.txt] to make sure the proper OPPs for a platform get enabled
> +and then creates a "cpufreq-dt" platform device to leverage the cpufreq-dt
> +driver described in [cpufreq-dt.txt].
> +
> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
> +families support different OPPs depending on the silicon variant in use.
> +The ti-cpufreq driver uses the revision and an efuse value from the SoC to
> +provide the OPP framework with supported hardware information. This is used
> +to determine which OPPs from the operating-points-v2 table get enabled. In
> +order to maintain backwards compatilibity if this information is not present
> +the "cpufreq-dt" platform device is still created to attempt to find an
> +operating-points (v1) table, otherwise no OPPs will be available because
> +safe OPPs cannot be determined.
... here..
We shouldn't be talking about the drivers are going to use it, etc.
This is a binding document, which should be independent of Linux
kernel. It can be used by other Operating systems as well and so the
implementation details should be just dropped.
> +
> +Required properties:
> +
> +In 'cpus' nodes:
> +- operating-points-v2: Phandle to the operating-points-v2 table to use
> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
> +mask, and efuse register shift to get the relevant bits
> +that describe OPP availability
> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC
These are proper sentences and so maybe a full-stop (.) at the end of
each line ?
> +
> +In 'operating-points-v2' table:
> +- opp-supported-hw: Two bitfields indicating:
> + 1. Which revision of the SoC the OPP is supported by
> + 2. Which eFuse bits indicate this OPP is available
> +
> + A bitwise and is performed against these values and if any bit
AND or &
> + matches, the OPP gets enabled.
> +
> +NOTE: Without the above, platform-device for "cpufreq-dt" is still created
> + but no determination of which OPPs should be available is done, but
> this
> + allows for use of a v1 operating-points table.
Again, these are implementation details.. should be dropped.
> +
> +Example:
> +
> +
> +/* From arch/arm/boot/dts/am4372.dtsi */
> +cpus {
> + cpu: cpu@0 {
> + ...
> +
> + operating-points-v2 = <&cpu0_opp_table>;
> +
> + ti,syscon-efuse = <&scm_conf 0x610 0x3f 0>;
> + ti,syscon-rev = <&scm_conf 0x600>;
@Rob: Can we add properties to the CPU node just like that ?
> +
> + ...
> + };
> +};
> +
> +cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
Otherwise, you could have added above properties right here and added
your own compatible string..
> + opp50@3 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <95>;
> + opp-supported-hw = <0xFF 0x01>;
> + opp-suspend;
> + };
> +
> + opp100@6 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <110>;
> + opp-supported-hw = <0xFF 0x04>;
> + };
> +
> + opp120@72000 {
> + opp-hz = /bits/ 64 <72000>;
> + opp-microvolt = <120>;
> + opp-supported-hw = <0xFF 0x08>;
> + };
> +
> + oppturbo@8 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <126>;
> + opp-supported-hw = <0xFF 0x10>;
> + };
> +
> + oppnitro@10 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = <1325000>;
> + opp-supported-hw = <0xFF 0x20>;
so the first one is always FF ? Why have it then ?
> +
Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'
Hi, some of my ppc qemu tests crash with the following log message. VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: 01004096 ram0 (driver?) 01014096 ram1 (driver?) 01024096 ram2 (driver?) 01034096 ram3 (driver?) 01044096 ram4 (driver?) 01054096 ram5 (driver?) 01064096 ram6 (driver?) 01074096 ram7 (driver?) 01084096 ram8 (driver?) 01094096 ram9 (driver?) 010a4096 ram10 (driver?) 010b4096 ram11 (driver?) 010c4096 ram12 (driver?) 010d4096 ram13 (driver?) 010e4096 ram14 (driver?) 010f4096 ram15 (driver?) 16008383 hdc driver: ide-gd Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) A complete boot log is available at http://kerneltests.org/builders/qemu-ppc-next/builds/408/steps/qemubuildcommand/logs/stdio Bisect points to commit 'drivers/of: Fix depth when unflattening devicetree'. Reverting this commit fixes the problem. Bisect log is attached. The scripts and root file system used for the test are available at https://github.com/groeck/linux-build-test/tree/master/rootfs/ppc Failing tests are powerpc:mac99:nosmp:ppc_book3s_defconfig powerpc:g3beige:nosmp:ppc_book3s_defconfig powerpc:mac99:smp:ppc_book3s_defconfig Guenter --- # bad: [1af872fb6cfb3c701d8819466a4672f85c3f17a3] dcssblk: fix the direct_access prototype to add 'size' # good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6 git bisect start 'HEAD' 'v4.6' # good: [586cf328ff7e7c0c32f89d6f2063c81143802c01] Merge remote-tracking branch 'net-next/master' git bisect good 586cf328ff7e7c0c32f89d6f2063c81143802c01 # bad: [69bf2b19c358d937a3f40c07a08bc73476d43c02] Merge remote-tracking branch 'tty/tty-next' git bisect bad 69bf2b19c358d937a3f40c07a08bc73476d43c02 # good: [c81e18989b12bdb70a056b05b94620eefd2aed7b] Merge remote-tracking branch 'drm/drm-next' git bisect good c81e18989b12bdb70a056b05b94620eefd2aed7b # good: [4668e9adc5722b6fdf887d0bc70e9f5998507689] Merge remote-tracking branch 'vfio/next' git bisect good 4668e9adc5722b6fdf887d0bc70e9f5998507689 # bad: [8ab5e17d29971673f08ce9cabfa6170e2f56fe07] Merge remote-tracking branch 'ftrace/for-next' git bisect bad 8ab5e17d29971673f08ce9cabfa6170e2f56fe07 # bad: [a792d9ada26755882a5ea1e958bc582fe6f2d7bc] Merge remote-tracking branch 'dt-rh/for-next' git bisect bad a792d9ada26755882a5ea1e958bc582fe6f2d7bc # good: [03da37387a3aa07e45d077043f48e7dc29206b62] Merge remote-tracking branch 'trivial/for-next' git bisect good 03da37387a3aa07e45d077043f48e7dc29206b62 # good: [8f97c2814b5448d91a3c67081f7d978c097feabe] Documentation: dt: interrupt-controller: fix spelling mistakes git bisect good 8f97c2814b5448d91a3c67081f7d978c097feabe # good: [947c82cbf01c9c6012cb96e385b5f6d6d1e1decb] drivers/of: Rename unflatten_dt_node() git bisect good 947c82cbf01c9c6012cb96e385b5f6d6d1e1decb # bad: [047eb65024c00807ff8f0407580f088b23cf908e] of/unittest: Remove unnecessary module.h header inclusion git bisect bad 047eb65024c00807ff8f0407580f088b23cf908e # good: [bb91f923d176578257aed682047653cc33148413] drivers/of: Export of_detach_node() git bisect good bb91f923d176578257aed682047653cc33148413 # bad: [ac78f9bdcf3836cafcd114a76a9473380a3faef5] drivers/of: Fix depth when unflattening devicetree git bisect bad ac78f9bdcf3836cafcd114a76a9473380a3faef5 # good: [b9c43856f21d97ffdfdd642acf2eb0b52d3b1555] of: dynamic: changeset prop-update revert fix git bisect good b9c43856f21d97ffdfdd642acf2eb0b52d3b1555 # first bad commit: [ac78f9bdcf3836cafcd114a76a9473380a3faef5] drivers/of: Fix depth when unflattening devicetree
[PATCH v2] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
Add ion cached pool in system heap. This patch add a cached pool
in system heap. It has a great improvement of alloc for cached
buffer.
With memory pressue alloc test 800MB in userspace used iontest.
The result avg is 577ms. Without patch it's avg is about 883ms.
v1: Makes the cached buffer zeroed before going to pool
v2: Add cached param in pool to distinguish wheather need to flush
cache at a fresh alloc.
Rework the shrink function.
Signed-off-by: Chen Feng
Signed-off-by: Xia Qing
Reviewed-by: Fu Jun
---
drivers/staging/android/ion/ion_page_pool.c | 10 +-
drivers/staging/android/ion/ion_priv.h| 5 +-
drivers/staging/android/ion/ion_system_heap.c | 183 +-
3 files changed, 133 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/android/ion/ion_page_pool.c
b/drivers/staging/android/ion/ion_page_pool.c
index 1fe8016..2c5e5c5 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -30,8 +30,9 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool
*pool)
if (!page)
return NULL;
- ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
- DMA_BIDIRECTIONAL);
+ if (!pool->cached)
+ ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
+ DMA_BIDIRECTIONAL);
return page;
}
@@ -147,7 +148,8 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t
gfp_mask,
return freed;
}
-struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order)
+struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order,
+ bool cached)
{
struct ion_page_pool *pool = kmalloc(sizeof(*pool), GFP_KERNEL);
@@ -161,6 +163,8 @@ struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask,
unsigned int order)
pool->order = order;
mutex_init(&pool->mutex);
plist_node_init(&pool->list, order);
+ if (cached)
+ pool->cached = true;
return pool;
}
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/ion_priv.h
index 0239883..f3cb8b4 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -360,6 +360,7 @@ void ion_carveout_free(struct ion_heap *heap,
ion_phys_addr_t addr,
* @gfp_mask: gfp_mask to use from alloc
* @order: order of pages in the pool
* @list: plist node for list of pools
+ * @cached:it's cached pool or not
*
* Allows you to keep a pool of pre allocated pages to use from your heap.
* Keeping a pool of pages that is ready for dma, ie any cached mapping have
@@ -369,6 +370,7 @@ void ion_carveout_free(struct ion_heap *heap,
ion_phys_addr_t addr,
struct ion_page_pool {
int high_count;
int low_count;
+ bool cached;
struct list_head high_items;
struct list_head low_items;
struct mutex mutex;
@@ -377,7 +379,8 @@ struct ion_page_pool {
struct plist_node list;
};
-struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order);
+struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order,
+ bool cached);
void ion_page_pool_destroy(struct ion_page_pool *);
struct page *ion_page_pool_alloc(struct ion_page_pool *);
void ion_page_pool_free(struct ion_page_pool *, struct page *);
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index b69dfc7..32a0ebf 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -26,16 +26,18 @@
#include "ion.h"
#include "ion_priv.h"
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
__GFP_NORETRY) & ~__GFP_RECLAIM;
static gfp_t low_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
static const unsigned int orders[] = {8, 4, 0};
-static const int num_orders = ARRAY_SIZE(orders);
+
static int order_to_index(unsigned int order)
{
int i;
- for (i = 0; i < num_orders; i++)
+ for (i = 0; i < NUM_ORDERS; i++)
if (order == orders[i])
return i;
BUG();
@@ -49,47 +51,55 @@ static inline unsigned int order_to_size(int order)
struct ion_system_heap {
struct ion_heap heap;
- struct ion_page_pool *pools[0];
+ struct ion_page_pool *uncached_pools[NUM_ORDERS];
+ struct ion_page_pool *cached_pools[NUM_ORDERS];
};
+/**
+ * The page from page-pool are all zeroed before. We need do cache
+ * clean for cached buffer. The uncached buffer are always non-cached
+ * since it's allocated. So no need for non-
RE: [PATCH] usb: gadget: f_fs: report error if excess data received
> On Wed, May 18 2016, Felipe Balbi wrote: > > we've been through this before. This needs to be done at the gadget > > layer. Gadget driver can over-allocate ahead of time if > > gadget->quirk_ep_out_aligned_size is true, then we avoid memcpy() at > > the UDC driver level. > > Right, all right, so let’s look at it from a regular USB function point > of view. If a USB function allocates a request which is not aligned, > UDC will align the buffer and *drop* excess data. Seeing how ugly > Do you mean UDC driver align the buffer? I searched the code, currently only DWC3 needs buffer size to be aligned to MaxPacketSize on ep out. And the align is done in f_fs driver. > f_fs’s code is becoming, I’m now leaning to letting to f_fs do the same > thing: if user space makes an unaligned read, f_fs aligns the buffer and > then drops excess data. > > Any arguments for f_fs to not drop the data apply to UDC, so they should > behave identically. > I'd prefer fail the request at all, and it is better done in HW. Because per the USB Spec that device can return NAK if a function was unable to accept data From the host. the DWC3 has not been design as this, if software fail the transfer, it is a little weird for host. So, now we have 3 choices: 1) buffer the excess data 2) fail the transfer 3) drop the excess data, then print an warning message Which one do you prefer? > -- > Best regards > ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ > «If at first you don’t succeed, give up skydiving» Best Regards, Du, Changbin
[PATCH] i2c_hid: enable i2c-hid devices to suspend/resume asynchronously
i2c-hid devices' suspend/resume are usually time-consuming process. For example, the touch controller(i2c-ATML1000:00) on ASUS T100 tablet takes about 160ms for suspending and 120ms for resuming. This patch enables i2c-hid devices to suspend/resume asynchronously. This will take advantage of multicore and speed up system suspend/resume process. Signed-off-by: Zhonghui Fu --- drivers/hid/i2c-hid/i2c-hid.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c index 2e021ba..cc41e1e 100644 --- a/drivers/hid/i2c-hid/i2c-hid.c +++ b/drivers/hid/i2c-hid/i2c-hid.c @@ -1020,6 +1020,7 @@ static int i2c_hid_probe(struct i2c_client *client, pm_runtime_get_noresume(&client->dev); pm_runtime_set_active(&client->dev); pm_runtime_enable(&client->dev); + device_enable_async_suspend(&client->dev); ret = i2c_hid_fetch_hid_descriptor(ihid); if (ret < 0) -- 1.7.1
[PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility
we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's cpuinfo don't has this now, so we need add this. Signed-off-by: Qing Xia --- arch/arm64/kernel/cpuinfo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index 3808470..c3527ad 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -114,6 +114,9 @@ static int c_show(struct seq_file *m, void *v) * online processors, looking for lines beginning with * "processor". Give glibc what it expects. */ + seq_printf(m, "Processor\t: AArch64 Processor rev %d (%s)\n", + read_cpuid_id() & 15, ELF_PLATFORM); + seq_printf(m, "processor\t: %d\n", i); seq_printf(m, "BogoMIPS\t: %lu.%02lu\n", -- 1.8.3.2
RE: [PATCH] usb: gadget: f_fs: report error if excess data received
> >> thanks Alan Stern and Michal. > >> Here just have a comment - the buffered data need be dropped when > the > >> epfile is closed, because it means the session is terminated. > > > > I blame that on sleep deprivation. Another issue is what to do when > > endpoint is disabled. Should the buffer be cleared as soon as the > > endpoint is disabled? Or maybe when the endpoint is enabled again? Or > > maybe it should never be cleared? > > > > If the buffer is cleared when endpoint is disabled, we again silently > > drop data. On the other hand, if we don’t do that, read() on the > > endpoint will may succeed even if the configuration is disabled which > > may be surprising for users. > > tough decision... but seems like clearing the buffer as soon as ep is > disabled is the way to go. > > -- > Balbi I agree with Balbi, seems it is not easy to maintain the excess buffer... I was to implement it at the beginning but I am not confident everything is done correctly.
Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
Hey James, yeah that's a lot better. I do still get some syslog messages, but i was trivially able to bind a shiftfs into a container and use it the way I'd want. [ 209.452274] [ cut here ] [ 209.452296] WARNING: CPU: 0 PID: 3072 at fs/ext4/inode.c:3977 ext4_truncate+0x3f5/0x5b0 [ 209.452299] Modules linked in: binfmt_misc veth ip6t_MASQUERADE nf_nat_masquerade_ipv6 ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6_tables xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ppdev kvm_intel kvm irqbypass nls_utf8 isofs joydev input_leds serio_raw i2c_piix4 pvpanic parport_pc 8250_fintek mac_hid parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops [ 209.452388] psmouse drm pata_acpi floppy [ 209.452401] CPU: 0 PID: 3072 Comm: bash Not tainted 4.6.0-rc5+ #11 [ 209.452404] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 209.452407] 0286 ccc8425d 88007a1cfa98 8145dae3 [ 209.452412] 88007a1cfad8 8108c25b [ 209.452416] 0f897a1cfaf8 880052efe340 88007a1cfbb8 880052efe560 [ 209.452421] Call Trace: [ 209.452431] [] dump_stack+0x85/0xc2 [ 209.452437] [] __warn+0xcb/0xf0 [ 209.452440] [] warn_slowpath_null+0x1d/0x20 [ 209.452444] [] ext4_truncate+0x3f5/0x5b0 [ 209.452447] [] ext4_setattr+0x627/0xa40 [ 209.452457] [] ? security_prepare_creds+0x43/0x60 [ 209.452468] [] ? creds_are_invalid.part.1+0x12/0x40 [ 209.452478] [] shiftfs_setattr+0x181/0x202 [ 209.452492] [] notify_change+0x235/0x360 [ 209.452500] [] do_truncate+0x77/0xc0 [ 209.452505] [] path_openat+0x269/0x1350 [ 209.452509] [] do_filp_open+0x91/0x100 [ 209.452517] [] ? _raw_spin_unlock+0x27/0x40 [ 209.452522] [] ? __alloc_fd+0xf9/0x210 [ 209.452526] [] do_sys_open+0x124/0x210 [ 209.452529] [] SyS_open+0x1e/0x20 [ 209.452534] [] do_syscall_64+0x69/0x160 [ 209.452537] [] entry_SYSCALL64_slow_path+0x25/0x25 [ 209.452541] ---[ end trace b995e24e590f8b85 ]--- [ 209.452790] [ cut here ] [ 209.452800] WARNING: CPU: 0 PID: 3072 at fs/ext4/namei.c:2778 ext4_orphan_add+0x11a/0x290 [ 209.452803] Modules linked in: binfmt_misc veth ip6t_MASQUERADE nf_nat_masquerade_ipv6 ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6_tables xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ppdev kvm_intel kvm irqbypass nls_utf8 isofs joydev input_leds serio_raw i2c_piix4 pvpanic parport_pc 8250_fintek mac_hid parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops [ 209.452896] psmouse drm pata_acpi floppy [ 209.452903] CPU: 0 PID: 3072 Comm: bash Tainted: GW 4.6.0-rc5+ #11 [ 209.452905] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 209.452907] 0286 ccc8425d 88007a1cfa30 8145dae3 [ 209.452912] 88007a1cfa70 8108c25b [ 209.452917] 0ada0008 880052efe340 88007c3ba0c0 880036806000 [ 209.452921] Call Trace: [ 209.452925] [] dump_stack+0x85/0xc2 [ 209.452929] [] __warn+0xcb/0xf0 [ 209.452933] [] warn_slowpath_null+0x1d/0x20 [ 209.452936] [] ext4_orphan_add+0x11a/0x290 [ 209.452940] [] ? ext4_truncate+0x14e/0x5b0 [ 209.452948] [] ? __ext4_journal_start_sb+0x88/0x1f0 [ 209.452953] [] ext4_truncate+0x181/0x5b0 [ 209.452956] [] ext4_setattr+0x627/0xa40 [ 209.452960] [] ? security_prepare_creds+0x43/0x60 [ 209.452964] [] ? creds_are_invalid.part.1+0x12/0x40 [ 209.452967] [] shiftfs_setattr+0x181/0x202 [ 209.452971] [] notify_change+0x235/0x360 [ 209.452975] [] do_truncate+0x77/0xc0 [ 209.452978] [] path_openat+0x269/0x1350 [ 209.452982] [] do_filp_open+0x91/0x100 [ 209.452986] [] ? _raw_spin_unlock+0x27/0x40 [ 209.452989] [] ? __alloc_fd+0xf9/0x210 [ 209.452993] [] do_sys_open+0x124/0x210 [ 209.452997] [] SyS_open+0x1e/0x20 [ 209.453001] [] do_syscall_64+0x69/0x160 [ 209.453004] [] entry_SYSCALL64_slow_path+0x25/0x25 [ 209.453007] ---[ end trace b995e24e590f8b86 ]--- [
Re: [PATCH v3] iio: max5487: Add support for Maxim digital potentiometers
Slight nitpick below.
On Tue, May 17, 2016 at 6:11 AM, Cristina Moraru
wrote:
> Add implementation for Maxim MAX5487, MAX5488, MAX5489
> digital potentiometers.
>
> Datasheet:
> http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf
>
> Signed-off-by: Cristina Moraru
> CC: Daniel Baluta
> ---
> Changes since v2:
> Change switch statement in max5487_write_raw
> to if statement for consistency
> Add blank line before return statement
> Eliminate regmap support and use spi_write
> Use iio_device_register instead of devm_ version
> Changes since v1:
> Fix spacing
> Eliminate max5487_cfg struct
> Add kohms as driver data
>
> drivers/iio/potentiometer/Kconfig | 11 +++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/max5487.c | 162
>
> 3 files changed, 174 insertions(+)
> create mode 100644 drivers/iio/potentiometer/max5487.c
>
> diff --git a/drivers/iio/potentiometer/Kconfig
> b/drivers/iio/potentiometer/Kconfig
> index 6acb238..bb77b50 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -15,6 +15,17 @@ config DS1803
> To compile this driver as a module, choose M here: the
> module will be called ds1803.
>
> +config MAX5487
> +tristate "Maxim MAX5487/MAX5488/MAX5489 Digital Potentiometer driver"
> +depends on SPI
> +help
> + Say yes here to build support for the Maxim
> + MAX5487, MAX5488, MAX5489 digital potentiomenter
> + chips.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called max5487.
> +
> config MCP4131
> tristate "Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X
> Digital Potentiometer driver"
> depends on SPI
> diff --git a/drivers/iio/potentiometer/Makefile
> b/drivers/iio/potentiometer/Makefile
> index 6007faa..8adb58f 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -4,6 +4,7 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_DS1803) += ds1803.o
> +obj-$(CONFIG_MAX5487) += max5487.o
> obj-$(CONFIG_MCP4131) += mcp4131.o
> obj-$(CONFIG_MCP4531) += mcp4531.o
> obj-$(CONFIG_TPL0102) += tpl0102.o
> diff --git a/drivers/iio/potentiometer/max5487.c
> b/drivers/iio/potentiometer/max5487.c
> new file mode 100644
> index 000..d5c9089
> --- /dev/null
> +++ b/drivers/iio/potentiometer/max5487.c
> @@ -0,0 +1,162 @@
> +/*
> + * max5487.c - Support for MAX5487, MAX5488, MAX5489 digital potentiometers
> + *
> + * Copyright (C) Cristina-Gabriela Moraru
You'll want to put a year for the copyright.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define MAX5487_WRITE_WIPER_A (0x01 << 8)
> +#define MAX5487_WRITE_WIPER_B (0x02 << 8)
> +
> +/* copy both wiper regs to NV regs */
> +#define MAX5487_COPY_AB_TO_NV (0x23 << 8)
> +/* copy both NV regs to wiper regs */
> +#define MAX5487_COPY_NV_TO_AB (0x33 << 8)
> +
> +#define MAX5487_MAX_POS255
> +#define MAX5487_REG_SIZE 16
> +
> +struct max5487_data {
> + struct spi_device *spi;
> + int kohms;
> +};
> +
> +#define MAX5487_CHANNEL(ch, addr) {\
> + .type = IIO_RESISTANCE, \
> + .indexed = 1, \
> + .output = 1,\
> + .channel = ch, \
> + .address = addr,\
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +}
> +
> +static const struct iio_chan_spec max5487_channels[] = {
> + MAX5487_CHANNEL(0, MAX5487_WRITE_WIPER_A),
> + MAX5487_CHANNEL(1, MAX5487_WRITE_WIPER_B),
> +};
> +
> +static int max5487_write_cmd(struct spi_device *spi, int cmd)
> +{
> + return spi_write(spi, (const void *) &cmd, MAX5487_REG_SIZE);
> +}
> +
> +static int max5487_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct max5487_data *data = iio_priv(indio_dev);
> +
> + if (mask != IIO_CHAN_INFO_SCALE)
> + return -EINVAL;
> +
> + *val = 1000 * data->kohms;
> + *val2 = MAX5487_MAX_POS;
> +
> + return IIO_VAL_FRACTIONAL;
> +}
> +
> +static int max5487_write_raw(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int
Re: Linux 3.14.70
diff --git a/Makefile b/Makefile
index c6762fdfc967..bc3311a0893b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 14
-SUBLEVEL = 69
+SUBLEVEL = 70
EXTRAVERSION =
NAME = Remembering Coco
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d1dedc8195ed..eafd120b53f1 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM. Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb )
- THUMB(.align )
- THUMB(bx pc )
- THUMB(nop )
- .arm
-
b omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
sdrc_power:
.word SDRC_POWER_V
cm_idlest1_core:
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 865ef923eda6..7cddee979ddd 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -64,8 +64,9 @@ static int hash_walk_new_entry(struct crypto_hash_walk *walk)
struct scatterlist *sg;
sg = walk->sg;
- walk->pg = sg_page(sg);
walk->offset = sg->offset;
+ walk->pg = sg_page(walk->sg) + (walk->offset >> PAGE_SHIFT);
+ walk->offset = offset_in_page(walk->offset);
walk->entrylen = sg->length;
if (walk->entrylen > walk->total)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 834847527982..b60cb76aae51 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -259,8 +259,14 @@ static bool intel_crt_compute_config(struct intel_encoder
*encoder,
pipe_config->has_pch_encoder = true;
/* LPT FDI RX only supports 8bpc. */
- if (HAS_PCH_LPT(dev))
+ if (HAS_PCH_LPT(dev)) {
+ if (pipe_config->bw_constrained && pipe_config->pipe_bpp < 24) {
+ DRM_DEBUG_KMS("LPT only supports 24bpp\n");
+ return false;
+ }
+
pipe_config->pipe_bpp = 24;
+ }
return true;
}
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 0db3e208f02a..b205f76400ad 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1600,6 +1600,7 @@ static u32 radeon_get_pll_use_mask(struct drm_crtc *crtc)
static int radeon_get_shared_dp_ppll(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct drm_crtc *test_crtc;
struct radeon_crtc *test_radeon_crtc;
@@ -1609,6 +1610,10 @@ static int radeon_get_shared_dp_ppll(struct drm_crtc
*crtc)
test_radeon_crtc = to_radeon_crtc(test_crtc);
if (test_radeon_crtc->encoder &&
ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
+ /* PPLL2 is exclusive to UNIPHYA on DCE61 */
+ if (ASIC_IS_DCE61(rdev) && !ASIC_IS_DCE8(rdev) &&
+ test_radeon_crtc->pll_id == ATOM_PPLL2)
+ continue;
/* for DP use the same PLL for all */
if (test_radeon_crtc->pll_id != ATOM_PPLL_INVALID)
return test_radeon_crtc->pll_id;
@@ -1630,6 +1635,7 @@ static int radeon_get_shared_nondp_ppll(struct drm_crtc
*crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct drm_crtc *test_crtc;
struct radeon_crtc *test_radeon_crtc;
u32 adjusted_clock, test_adjusted_clock;
@@ -1645,6 +1651,10 @@ static int radeon_get_shared_nondp_ppll(struct drm_crtc
*crtc)
test_radeon_crtc = to_radeon_crtc(test_crtc);
if (test_radeon_crtc->encoder &&
!ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
+ /* PPLL2 is exclusive to UNIPHYA on DCE61 */
+ if (ASIC_IS_DCE61(rdev) && !ASIC_IS_DCE8(rdev) &&
+ test_radeon_crtc->pll_id == ATOM_PPLL2)
+ continue;
/* check if we are already driving this connector
Re: Linux 4.4.11
diff --git a/Makefile b/Makefile
index 5b5f462f834c..aad86274b61b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 10
+SUBLEVEL = 11
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index 0827d594b1f0..cd0cd5fd09a3 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -106,7 +106,7 @@
pmc: pmc@fc00 {
compatible = "atmel,at91sam9x5-pmc", "syscon";
- reg = <0xfc00 0x100>;
+ reg = <0xfc00 0x200>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
interrupt-controller;
#address-cells = <1>;
diff --git a/arch/s390/include/asm/mmu.h b/arch/s390/include/asm/mmu.h
index d29ad9545b41..081b2ad99d73 100644
--- a/arch/s390/include/asm/mmu.h
+++ b/arch/s390/include/asm/mmu.h
@@ -11,7 +11,7 @@ typedef struct {
spinlock_t list_lock;
struct list_head pgtable_list;
struct list_head gmap_list;
- unsigned long asce_bits;
+ unsigned long asce;
unsigned long asce_limit;
unsigned long vdso_base;
/* The mmu context allocates 4K page tables. */
diff --git a/arch/s390/include/asm/mmu_context.h
b/arch/s390/include/asm/mmu_context.h
index e485817f7b1a..22877c9440ea 100644
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@ -26,12 +26,28 @@ static inline int init_new_context(struct task_struct *tsk,
mm->context.has_pgste = 0;
mm->context.use_skey = 0;
#endif
- if (mm->context.asce_limit == 0) {
+ switch (mm->context.asce_limit) {
+ case 1UL << 42:
+ /*
+* forked 3-level task, fall through to set new asce with new
+* mm->pgd
+*/
+ case 0:
/* context created by exec, set asce limit to 4TB */
- mm->context.asce_bits = _ASCE_TABLE_LENGTH |
- _ASCE_USER_BITS | _ASCE_TYPE_REGION3;
mm->context.asce_limit = STACK_TOP_MAX;
- } else if (mm->context.asce_limit == (1UL << 31)) {
+ mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
+ _ASCE_USER_BITS | _ASCE_TYPE_REGION3;
+ break;
+ case 1UL << 53:
+ /* forked 4-level task, set new asce with new mm->pgd */
+ mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
+ _ASCE_USER_BITS | _ASCE_TYPE_REGION2;
+ break;
+ case 1UL << 31:
+ /* forked 2-level compat task, set new asce with new mm->pgd */
+ mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
+ _ASCE_USER_BITS | _ASCE_TYPE_SEGMENT;
+ /* pgd_alloc() did not increase mm->nr_pmds */
mm_inc_nr_pmds(mm);
}
crst_table_init((unsigned long *) mm->pgd, pgd_entry_type(mm));
@@ -42,7 +58,7 @@ static inline int init_new_context(struct task_struct *tsk,
static inline void set_user_asce(struct mm_struct *mm)
{
- S390_lowcore.user_asce = mm->context.asce_bits | __pa(mm->pgd);
+ S390_lowcore.user_asce = mm->context.asce;
if (current->thread.mm_segment.ar4)
__ctl_load(S390_lowcore.user_asce, 7, 7);
set_cpu_flag(CIF_ASCE);
@@ -71,7 +87,7 @@ static inline void switch_mm(struct mm_struct *prev, struct
mm_struct *next,
{
int cpu = smp_processor_id();
- S390_lowcore.user_asce = next->context.asce_bits | __pa(next->pgd);
+ S390_lowcore.user_asce = next->context.asce;
if (prev == next)
return;
if (MACHINE_HAS_TLB_LC)
diff --git a/arch/s390/include/asm/pgalloc.h b/arch/s390/include/asm/pgalloc.h
index d7cc79fb6191..5991cdcb5b40 100644
--- a/arch/s390/include/asm/pgalloc.h
+++ b/arch/s390/include/asm/pgalloc.h
@@ -56,8 +56,8 @@ static inline unsigned long pgd_entry_type(struct mm_struct
*mm)
return _REGION2_ENTRY_EMPTY;
}
-int crst_table_upgrade(struct mm_struct *, unsigned long limit);
-void crst_table_downgrade(struct mm_struct *, unsigned long limit);
+int crst_table_upgrade(struct mm_struct *);
+void crst_table_downgrade(struct mm_struct *);
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long address)
{
diff --git a/arch/s390/include/asm/processor.h
b/arch/s390/include/asm/processor.h
index b16c3d0a1b9f..c1ea67db8404 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -163,7 +163,7 @@ extern __vector128 init_task_fpu_regs[__NUM_VXRS];
regs->psw.mask = PSW_USER_BITS | PSW_MASK_BA; \
regs->psw.addr = new_psw | PSW_ADDR_AMODE; \
regs->gpr
Linux 3.14.70
I'm announcing the release of the 3.14.70 kernel. All users of the 3.14 kernel series must upgrade. The updated 3.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- arch/arm/mach-omap2/sleep34xx.S | 22 ++ crypto/ahash.c |3 ++- drivers/gpu/drm/i915/intel_crt.c |8 +++- drivers/gpu/drm/radeon/atombios_crtc.c | 10 ++ drivers/input/misc/max8997_haptic.c |6 -- drivers/net/ethernet/atheros/atlx/atl2.c |2 +- drivers/pnp/pnpbios/bioscalls.c |9 + fs/isofs/rock.c | 13 ++--- net/bridge/br_ioctl.c|5 +++-- net/core/rtnetlink.c | 18 ++ net/decnet/dn_route.c|9 - net/ipv4/route.c | 12 net/llc/af_llc.c |1 + net/packet/af_packet.c |1 + net/vmw_vsock/af_vsock.c | 21 + net/x25/x25_facilities.c |1 + 17 files changed, 79 insertions(+), 64 deletions(-) Al Viro (1): get_rock_ridge_filename(): handle malformed NM entries Andi Kleen (1): asmlinkage, pnp: Make variables used from assembler code visible Ben Hutchings (1): atl2: Disable unimplemented scatter/gather feature Chris Friesen (1): route: do not cache fib route info on local routes with oif Daniel Vetter (1): drm/i915: Bail out of pipe config compute loop on LPT David S. Miller (1): decnet: Do not build routes to devices without decnet private data. Greg Kroah-Hartman (1): Linux 3.14.70 Herbert Xu (1): crypto: hash - Fix page length clamping in hash walk Ian Campbell (1): VSOCK: do not disconnect socket when peer has shutdown SEND only Kangjie Lu (3): net: fix infoleak in llc net: fix infoleak in rtnetlink net: fix a kernel infoleak in x25 module Lucas Stach (1): drm/radeon: fix PLL sharing on DCE6.1 (v2) Marek Szyprowski (1): Input: max8997-haptic - fix NULL pointer dereference Mathias Krause (1): packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface Nikolay Aleksandrov (1): net: bridge: fix old ioctl unlocked net device walk Tony Lindgren (1): ARM: OMAP3: Fix booting with thumb2 kernel signature.asc Description: PGP signature
Linux 4.4.11
I'm announcing the release of the 4.4.11 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/boot/dts/at91sam9x5.dtsi |2 arch/s390/include/asm/mmu.h|2 arch/s390/include/asm/mmu_context.h| 28 +- arch/s390/include/asm/pgalloc.h|4 arch/s390/include/asm/processor.h |2 arch/s390/include/asm/tlbflush.h |9 -- arch/s390/mm/init.c|3 arch/s390/mm/mmap.c|6 - arch/s390/mm/pgtable.c | 85 ++-- crypto/ahash.c |3 crypto/testmgr.c | 27 +- drivers/base/regmap/regmap-spmi.c |2 drivers/crypto/qat/qat_common/adf_common_drv.h |2 drivers/crypto/qat/qat_common/adf_ctl_drv.c|6 + drivers/crypto/qat/qat_common/adf_sriov.c | 26 +++--- drivers/gpu/drm/i915/intel_crt.c |8 + drivers/gpu/drm/i915/intel_pm.c|6 + drivers/gpu/drm/radeon/atombios_crtc.c | 10 ++ drivers/gpu/drm/radeon/radeon_dp_auxch.c |2 drivers/infiniband/hw/mlx5/main.c |4 drivers/input/misc/max8997_haptic.c|6 - drivers/media/v4l2-core/videobuf2-v4l2.c |6 - drivers/net/ethernet/atheros/atlx/atl2.c |2 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |4 drivers/net/ethernet/freescale/fec_main.c | 10 +- drivers/net/ethernet/mellanox/mlx4/en_rx.c |2 drivers/net/ethernet/mellanox/mlx4/en_tx.c |6 - drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 15 ++- drivers/net/ethernet/mellanox/mlx5/core/port.c | 10 +- drivers/net/usb/cdc_mbim.c |9 +- drivers/pinctrl/pinctrl-at91-pio4.c|2 drivers/regulator/axp20x-regulator.c |4 drivers/regulator/s2mps11.c| 28 +- drivers/scsi/qla1280.c |2 drivers/spi/spi-pxa2xx.c |2 drivers/spi/spi-ti-qspi.c | 45 ++ fs/isofs/rock.c| 13 ++- fs/namei.c | 26 ++ fs/ocfs2/acl.c | 87 + fs/ocfs2/acl.h |5 + fs/ocfs2/file.c|4 fs/ocfs2/namei.c | 23 - fs/ocfs2/refcounttree.c| 17 fs/ocfs2/xattr.c | 14 +-- fs/ocfs2/xattr.h |4 fs/open.c | 12 -- include/linux/bpf.h|3 include/linux/dcache.h | 12 ++ include/linux/mfd/samsung/s2mps11.h|2 include/linux/mlx5/driver.h|6 - include/linux/net.h| 10 ++ include/net/codel.h|4 include/net/sch_generic.h | 20 include/uapi/linux/if.h| 28 ++ include/uapi/linux/libc-compat.h | 44 ++ kernel/bpf/inode.c |7 - kernel/bpf/syscall.c | 24 - kernel/bpf/verifier.c | 66 +-- kernel/events/ring_buffer.c| 10 ++ kernel/workqueue.c | 11 ++ mm/zsmalloc.c |7 + net/bridge/br_ioctl.c |5 - net/bridge/br_multicast.c | 12 +- net/core/rtnetlink.c | 18 ++-- net/core/skbuff.c | 11 +- net/decnet/dn_route.c |9 +- net/ipv4/fib_frontend.c|6 + net/ipv4/fib_semantics.c |2 net/ipv4/ip_gre.c | 11 +- net/ipv4/route.c | 12 ++ net/ipv4/tcp_output.c |6 - net/ipv6/reassembly.c |6 - net/ipv6/route.
Linux 4.5.5
I'm announcing the release of the 4.5.5 kernel. All users of the 4.5 kernel series must upgrade. The updated 4.5.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.5.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/boot/dts/at91sam9x5.dtsi |2 crypto/ahash.c |3 crypto/testmgr.c | 27 - drivers/base/regmap/regmap-spmi.c |2 drivers/crypto/qat/qat_common/adf_common_drv.h | 11 ++ drivers/crypto/qat/qat_common/adf_ctl_drv.c|6 + drivers/crypto/qat/qat_common/adf_sriov.c | 26 +++-- drivers/gpu/drm/amd/amdgpu/atombios_dp.c |4 drivers/gpu/drm/i915/i915_debugfs.c| 16 --- drivers/gpu/drm/i915/i915_reg.h|2 drivers/gpu/drm/i915/intel_audio.c |9 - drivers/gpu/drm/i915/intel_crt.c |8 + drivers/gpu/drm/i915/intel_ddi.c | 24 + drivers/gpu/drm/i915/intel_display.c |2 drivers/gpu/drm/i915/intel_dp_mst.c| 22 drivers/gpu/drm/i915/intel_drv.h |2 drivers/gpu/drm/i915/intel_pm.c|6 + drivers/gpu/drm/radeon/atombios_crtc.c | 10 ++ drivers/gpu/drm/radeon/atombios_dp.c |4 drivers/gpu/drm/radeon/radeon_dp_auxch.c |2 drivers/infiniband/hw/mlx5/main.c |4 drivers/input/misc/max8997_haptic.c|6 - drivers/media/v4l2-core/videobuf2-v4l2.c |6 - drivers/net/ethernet/atheros/atlx/atl2.c |2 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |4 drivers/net/ethernet/freescale/fec_main.c | 10 +- drivers/net/ethernet/mellanox/mlx4/en_rx.c |2 drivers/net/ethernet/mellanox/mlx4/en_tx.c |6 - drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 57 +--- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 46 +++-- drivers/net/ethernet/mellanox/mlx5/core/port.c | 10 +- drivers/net/ethernet/mellanox/mlx5/core/vport.c| 40 drivers/net/usb/cdc_mbim.c |9 + drivers/pinctrl/pinctrl-at91-pio4.c|2 drivers/regulator/axp20x-regulator.c |4 drivers/regulator/s2mps11.c| 28 - drivers/scsi/qla1280.c |2 drivers/spi/spi-pxa2xx.c |2 drivers/spi/spi-ti-qspi.c | 45 + drivers/staging/wilc1000/wilc_spi.c|2 fs/btrfs/ctree.c | 12 +- fs/btrfs/ctree.h |2 fs/btrfs/dev-replace.c |2 fs/btrfs/disk-io.c | 28 +++-- fs/btrfs/file.c|9 + fs/btrfs/inode.c | 36 +++ fs/btrfs/ioctl.c | 10 +- fs/btrfs/qgroup.c | 54 ++- fs/btrfs/reada.c |4 fs/btrfs/relocation.c |1 fs/btrfs/tree-log.c| 99 ++--- fs/btrfs/tree-log.h|2 fs/isofs/rock.c| 13 ++ fs/namei.c | 26 + fs/ocfs2/acl.c | 87 ++ fs/ocfs2/acl.h |5 + fs/ocfs2/file.c|4 fs/ocfs2/namei.c | 23 fs/ocfs2/refcounttree.c| 17 --- fs/ocfs2/xattr.c | 14 +- fs/ocfs2/xattr.h |4 fs/open.c | 12 -- include/linux/bpf.h|3 include/linux/dcache.h | 12 ++ include/linux/mfd/samsung/s2mps11.h|2 include/linux/mlx5/driver.h|6 - include/linux/mlx5/vport.h |2 include/linux/mm.h |9 + include/linux/net.h| 10 +- include/linux/rculist_nulls.h | 39 include/linux/swap.h |6 - include/net/codel.h|4 include/net/sch_generi
Re: [PATCH 4/6] cpufreq: conservative: Remove declaration of cs_dbs_gov
On 18-05-16, 23:03, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar wrote: > > The code doesn't use 'cs_dbs_gov' anymore before it is defined and the > > extra line for declaring it can be removed. > > This sort of conflicts with a patch I've just posted > (https://patchwork.kernel.org/patch/9122121/) and I'd prefer to go > with that one if that's not a big deal. Yeah, drop it. -- viresh
Re: [PATCH 5/6] cpufreq: Reuse gov_attr_* macros in schedutil governor
On 18-05-16, 23:01, Rafael J. Wysocki wrote: > On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar wrote: > > These macros can be used by governors which don't use the common > > governor code present in cpufreq_governor.c and should be moved to the > > relevant header. > > > > Now that they are getting moved to the right header file, reuse them in > > schedutil governor as well (that required rename of show/store > > routines). > > I'm not sure what the benefit is to be honest. > > It adds one level of indirection to the definition of rate_limit_us, > but why is that better? I agree. I did it because I am required to use these macros for the interactive-governor and have to move them to cpufreq.h anyway. Now that we have to move them out, I thought that we should perhaps use them for schedutil as well. This would look more relevant to schedutil once it has more tunables instead of just one. -- viresh
Re: [PATCH] cpufreq: Drop the 'initialized' field from struct cpufreq_governor
On 18-05-16, 22:59, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The 'initialized' field in struct cpufreq_governor is only used by > the conservative governor (as a usage counter) and the way that > happens is far from straightforward and arguably incorrect. > > Namely, the value of 'initialized' is checked by > cpufreq_dbs_governor_init() and cpufreq_dbs_governor_exit() and > the results of those checks are passed (as the second argument) to > the ->init() and ->exit() callbacks in struct dbs_governor. Those > callbacks are only implemented by the ondemand and conservative > governors and ondemand doesn't use their second argument at all. > In turn, the conservative governor uses it to decide whether or not > to either register or unregister a transition notifier. > > That whole mechanism is not only unnecessarily convoluted, but also > racy, because the 'initialized' field of struct cpufreq_governor is > updated in cpufreq_init_governor() and cpufreq_exit_governor() under > policy->rwsem which doesn't help if one of these functions is run > twice in parallel for different policies (which isn't impossible in > principle), for example. > > Instead of it, add a proper usage counter to the conservative > governor and update it from cs_init() and cs_exit() which is > guaranteed to be non-racy, as those functions are only called > under gov_dbs_data_mutex which is global. > > With that in place, drop the 'initialized' field from struct > cpufreq_governor as it is not used any more. > > Signed-off-by: Rafael J. Wysocki > --- > > This is on top of https://patchwork.kernel.org/patch/9094021/ > > --- > drivers/cpufreq/cpufreq.c |3 -- > drivers/cpufreq/cpufreq_conservative.c | 44 > + > drivers/cpufreq/cpufreq_governor.c |6 ++-- > drivers/cpufreq/cpufreq_governor.h |4 +-- > drivers/cpufreq/cpufreq_ondemand.c |4 +-- > include/linux/cpufreq.h|1 > 6 files changed, 36 insertions(+), 26 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [RFC v1 2/2] mm: SLUB Freelist randomization
On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote: > I thought the mix of slab_test & kernbench would show a diverse > picture on perf data. Is there another test that you think would be > useful? Single thread testing on slab_test would be meaningful because it also touch the slowpath. Problem is just unstable result of slab_test. You can get more stable result of slab_test if you repeat same test sometimes and get average result. Please use following slab_test. It will do each operations 10 times and repeat it 50 times. https://github.com/JoonsooKim/linux/blob/slab_test_robust-next-20160509/mm/slab_test.c I did a quick test for this patchset and get following result. - Before (With patch and randomization is disabled by config) Single thread testing = 1. Kmalloc: Repeatedly allocate then free test 10 times kmalloc(8) -> 42 cycles kfree -> 67 cycles 10 times kmalloc(16) -> 43 cycles kfree -> 68 cycles 10 times kmalloc(32) -> 47 cycles kfree -> 72 cycles 10 times kmalloc(64) -> 54 cycles kfree -> 78 cycles 10 times kmalloc(128) -> 75 cycles kfree -> 87 cycles 10 times kmalloc(256) -> 84 cycles kfree -> 111 cycles 10 times kmalloc(512) -> 82 cycles kfree -> 112 cycles 10 times kmalloc(1024) -> 86 cycles kfree -> 113 cycles 10 times kmalloc(2048) -> 113 cycles kfree -> 127 cycles 10 times kmalloc(4096) -> 151 cycles kfree -> 154 cycles - After (With patch and randomization is enabled by config) Single thread testing = 1. Kmalloc: Repeatedly allocate then free test 10 times kmalloc(8) -> 51 cycles kfree -> 68 cycles 10 times kmalloc(16) -> 57 cycles kfree -> 70 cycles 10 times kmalloc(32) -> 70 cycles kfree -> 75 cycles 10 times kmalloc(64) -> 95 cycles kfree -> 84 cycles 10 times kmalloc(128) -> 142 cycles kfree -> 97 cycles 10 times kmalloc(256) -> 150 cycles kfree -> 107 cycles 10 times kmalloc(512) -> 151 cycles kfree -> 107 cycles 10 times kmalloc(1024) -> 154 cycles kfree -> 110 cycles 10 times kmalloc(2048) -> 230 cycles kfree -> 124 cycles 10 times kmalloc(4096) -> 423 cycles kfree -> 165 cycles It seems that performance decreases a lot but I don't care about it because it is a security feature and I don't have a better idea. Thanks.
Re: linux-next: manual merge of the vfs tree with Linus' tree
As noted below, it is easier to remove the obsolete comments and I
just pushed the following trivial patch to cifs-2.6.git for-next to do
that.
https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=fea17ae8ac1c8c44b2fd1c02ae2e15b847d327d1
On Wed, May 18, 2016 at 8:17 PM, Stephen Rothwell wrote:
> Hi Al,
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/cifs/cifsfs.c
>
> between commit:
>
> a9ae008f407b ("cifs: Switch to generic xattr handlers")
>
> from Linus' tree and commit:
>
> 51085a1f913a ("cifs: use C99 syntax for inode_operations initializer")
>
> from the vfs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> Al: the c99 fixup is not really necessary as the line is commented out
> and you didn't fix the one in the line above ... a better fix might be
> to delete both those lines?
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/cifs/cifsfs.c
> index 67f622df0858,586d4eadd49e..
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@@ -917,11 -919,13 +917,11 @@@ const struct inode_operations cifs_syml
> .permission = cifs_permission,
> /* BB add the following two eventually */
> /* revalidate: cifs_revalidate,
> - setattr:cifs_notify_change, *//* BB do we need notify change */
> + .setattr = cifs_notify_change, *//* BB do we need notify change */
> -#ifdef CONFIG_CIFS_XATTR
> - .setxattr = cifs_setxattr,
> - .getxattr = cifs_getxattr,
> + .setxattr = generic_setxattr,
> + .getxattr = generic_getxattr,
> .listxattr = cifs_listxattr,
> - .removexattr = cifs_removexattr,
> -#endif
> + .removexattr = generic_removexattr,
> };
>
> static int cifs_clone_file_range(struct file *src_file, loff_t off,
--
Thanks,
Steve
Re: perf probe -L on ubuntu 16.04
On Mon, 16 May 2016 22:56:36 -0300 Arnaldo Carvalho de Melo wrote: > Hi Masami, > > Have you ever tried using 'perf probe' on ubuntu? > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r) > linux-image-4.4.0-21-generic - Linux kernel image for version 4.4.0 on > 64 bit x86 SMP > linux-image-4.4.0-21-generic-dbgsym - Linux kernel debug image for > version 4.4.0 on 64 bit x86 SMP > acme@ubuntu:~/git/linux$ > acme@ubuntu:~/git/linux$ > > So those are installed, but then I try: > > > root@ubuntu:~# perf probe -vvv -L getname_flags > Looking at the vmlinux_path (8 entries long) > Using /usr/lib/debug/boot/vmlinux-4.4.0-21-generic for symbols > Open Debuginfo file: /usr/lib/debug/boot/vmlinux-4.4.0-21-generic > fname: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c, lineno:125 > New line range: 125 to 2147483647 > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > Get 3665 lines from this CU > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c > Failed to find source file path. > Error: Failed to show lines. Reason: No such file or directory (Code: -2) > root@ubuntu:~# > > Couldn't find the source code files, which is the case: > > acme@ubuntu:~/git/linux$ dpkg -L linux-image-$(uname -r)-dbgsym | grep > '\.c' > acme@ubuntu:~/git/linux$ dpkg -L linux-image-$(uname -r)-dbgsym | grep > '\.ko' | tail -2 > /usr/lib/debug/lib/modules/4.4.0-21-generic/kernel/crypto/pcbc.ko > /usr/lib/debug/lib/modules/4.4.0-21-generic/kernel/crypto/crc32.ko > acme@ubuntu:~/git/linux$ > > Have to dig deeper to see where the source code is, ideas? It shows the "path" is ; > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c So, would you have the source code under this temporary directory? (yeah, I guess No) Anyway, ubuntu has "linux-source" package, or apt source linux-image-`uname -r` will give you the source tree in current dir. After you get a proper kernel source code, you can use -s to show source code. -s, --source path to kernel source I ensured it is working correctly by below command. $ perf probe -s ./linux-4.4.0 -L getname_flags Enjoy! :) -- Masami Hiramatsu
RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume
Hi, > From: Bastien Nocera [mailto:had...@hadess.net] > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote: > > (This patch hasn't been tested, it's sent for comments) > > > > Linux userspace (systemd-logind) keeps on rechecking lid state when the > > lid state is closed. If it failed to update the lid state to open after > > boot/resume, it could suspend the system. But as: > > 1. Traditional ACPI platform may not generate the lid open event after > > resuming as the open event is actually handled by the BIOS and the system > > is then resumed from a FACS vector. > > 2. The _LID control method's initial returning value is not reliable. The > > _LID control method is described to return the "current" lid state, > > however the word of "current" has ambiguity, many BIOSen return lid > > state upon last lid notification while the developers may think the > > BIOSen should always return the lid state upon last _LID evaluation. > > There won't be difference when we evaluate _LID during the runtime, the > > problem is the initial returning value of this function. When the BIOSen > > implement this control method with cached value, the initial returning > > value is likely not reliable. > > Thus there is no mean for the ACPI lid driver to provide such an event > > conveying correct current lid state. When there is no such an event or the > > event conveys wrong result, false suspending can be examined. > > > > The root cause of the issue is systemd itself, it could handle the ACPI > > control method lid device by implementing a special option like > > LidSwitchLevelTriggered=False when it detected the ACPI lid device. However > > there is no explicit documentation clarified the ambiguity, we need to > > work it around in the kernel before systemd changing its mind. > > > > Link 1: https://lkml.org/2016/3/7/460 > > Link 2: https://github.com/systemd/systemd/issues/2087 > > Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211 > > https://bugzilla.kernel.org/show_bug.cgi?id=106151 > > https://bugzilla.kernel.org/show_bug.cgi?id=106941 > > Signed-off-by: Lv Zheng > > Cc: Bastien Nocera: > > As mentioned previously, I'd be much happier if either: > - a new system was put in place that matched the ACPI specs and the way > they are used by Windows [Lv Zheng] Then what about the old systems? Surface Pro 1 and Surface 3 are MS platforms that should have already adapted to the Windows. They are currently suffering from the same issue by running Linux. > - an additional tag/property was added to show that the API offered by > the LID switch is different from the one that existing since ACPI > support was added to Linux. > > And I'd really appreciate it if you stopped saying that it's systemd's > fault. [Lv Zheng] OK. Instead of saying this is a fault, I'll say systemd may need an additional option to handle ACPI lid device. > > The kernel has offered an API to user-space that included the state of > the LID switch. And the state of the LID switch has been correct for > the majority of systems and devices for the past decade or so. The fact > that this device means that the LID state isn't reliable anymore means > that the kernel needs to communicate that to user-space. > > I'm volunteering to modify systemd and UPower to respect the fact that > the LID switch state isn't available on those devices. If you want to > find something to blame, blame the kernel for implementing an API that > doesn't reflect what the hardware makes available. Though you can only > say that with the benefit of hindsight. > > So, NAK from me. [Lv Zheng] I'm out of the context here. This patch is generated to respect the current systemd behavior. If not, we'd rather just delete the 2 wrong lines. I know that you need a documentation clarification, we are putting effort on this. Thanks and best regards -Lv
linux-next: manual merge of the rdma tree with the nfs tree
Hi Doug,
Today's linux-next merge of the rdma tree got a conflict in:
net/sunrpc/xprtrdma/frwr_ops.c
between commit:
55fdfce101a0 ("xprtrdma: Rename rpcrdma_frwr::sg and sg_nents")
from the nfs tree and commits:
ff2ba9936591 ("IB/core: Add passing an offset into the SG to ib_map_mr_sg")
9aa8b3217ed3 ("IB/core: Enhance ib_map_mr_sg()")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/sunrpc/xprtrdma/frwr_ops.c
index a192b91ad67e,94c3fa910b85..
--- a/net/sunrpc/xprtrdma/frwr_ops.c
+++ b/net/sunrpc/xprtrdma/frwr_ops.c
@@@ -450,10 -421,10 +450,10 @@@ frwr_op_map(struct rpcrdma_xprt *r_xprt
return -ENOMEM;
}
- n = ib_map_mr_sg(mr, frmr->fr_sg, frmr->fr_nents, PAGE_SIZE);
- n = ib_map_mr_sg(mr, frmr->sg, frmr->sg_nents, NULL, PAGE_SIZE);
- if (unlikely(n != frmr->sg_nents)) {
++ n = ib_map_mr_sg(mr, frmr->fr_sg, frmr->fr_nents, NULL, PAGE_SIZE);
+ if (unlikely(n != frmr->fr_nents)) {
pr_err("RPC: %s: failed to map mr %p (%u/%u)\n",
- __func__, frmr->fr_mr, n, frmr->sg_nents);
+ __func__, frmr->fr_mr, n, frmr->fr_nents);
rc = n < 0 ? n : -EINVAL;
goto out_senderr;
}
Re: [PATCH v12 07/10] arm64: kprobes instruction simulation support
On Wed, Apr 27, 2016 at 02:53:02PM -0400, David Long wrote:
> From: Sandeepa Prabhu
>
> Kprobes needs simulation of instructions that cannot be stepped
> from a different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented using a copy of pt_regs.
>
> The following instruction categories are simulated:
> - All branching instructions(conditional, register, and immediate)
> - Literal access instructions(load-literal, adr/adrp)
>
> Conditional execution is limited to branching instructions in
> ARM v8. If conditions at PSTATE do not match the condition fields
> of opcode, the instruction is effectively NOP.
>
> Thanks to Will Cohen for assorted suggested changes.
>
> Signed-off-by: Sandeepa Prabhu
> Signed-off-by: William Cohen
> Signed-off-by: David A. Long
> ---
> arch/arm64/include/asm/insn.h| 1 +
> arch/arm64/include/asm/probes.h | 5 +-
> arch/arm64/kernel/Makefile | 3 +-
> arch/arm64/kernel/insn.c | 1 +
> arch/arm64/kernel/kprobes-arm64.c| 29
> arch/arm64/kernel/kprobes.c | 32 -
> arch/arm64/kernel/probes-simulate-insn.c | 218
> +++
> arch/arm64/kernel/probes-simulate-insn.h | 28
> 8 files changed, 311 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
> create mode 100644 arch/arm64/kernel/probes-simulate-insn.h
>
> diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
> index b9567a1..26cee10 100644
> --- a/arch/arm64/include/asm/insn.h
> +++ b/arch/arm64/include/asm/insn.h
> @@ -410,6 +410,7 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn);
>
> typedef bool (pstate_check_t)(unsigned long);
> extern pstate_check_t * const opcode_condition_checks[16];
> +
> #endif /* __ASSEMBLY__ */
>
> #endif /* __ASM_INSN_H */
> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
> index c5fcbe6..d524f7d 100644
> --- a/arch/arm64/include/asm/probes.h
> +++ b/arch/arm64/include/asm/probes.h
> @@ -15,11 +15,12 @@
> #ifndef _ARM_PROBES_H
> #define _ARM_PROBES_H
>
> +#include
> +
> struct kprobe;
> struct arch_specific_insn;
>
> typedef u32 kprobe_opcode_t;
> -typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
> typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
>
> enum pc_restore_type {
> @@ -35,7 +36,7 @@ struct kprobe_pc_restore {
> /* architecture specific copy of original instruction */
> struct arch_specific_insn {
> kprobe_opcode_t *insn;
> - kprobes_pstate_check_t *pstate_cc;
> + pstate_check_t *pstate_cc;
> kprobes_handler_t *handler;
> /* restore address after step xol */
> struct kprobe_pc_restore restore;
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 8816de2..43bf6cc 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -37,7 +37,8 @@ arm64-obj-$(CONFIG_CPU_PM) += sleep.o suspend.o
> arm64-obj-$(CONFIG_CPU_IDLE) += cpuidle.o
> arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
> arm64-obj-$(CONFIG_KGDB) += kgdb.o
> -arm64-obj-$(CONFIG_KPROBES) += kprobes.o kprobes-arm64.o
> +arm64-obj-$(CONFIG_KPROBES) += kprobes.o kprobes-arm64.o
> \
> +probes-simulate-insn.o
> arm64-obj-$(CONFIG_EFI) += efi.o efi-entry.stub.o
> arm64-obj-$(CONFIG_PCI) += pci.o
> arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index f79e72e..bb2738c 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define AARCH64_INSN_SF_BIT BIT(31)
> diff --git a/arch/arm64/kernel/kprobes-arm64.c
> b/arch/arm64/kernel/kprobes-arm64.c
> index e07727a..487238a 100644
> --- a/arch/arm64/kernel/kprobes-arm64.c
> +++ b/arch/arm64/kernel/kprobes-arm64.c
> @@ -21,6 +21,7 @@
> #include
>
> #include "kprobes-arm64.h"
> +#include "probes-simulate-insn.h"
>
> static bool __kprobes aarch64_insn_is_steppable(u32 insn)
> {
> @@ -62,8 +63,36 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct
> arch_specific_insn *asi)
>*/
> if (aarch64_insn_is_steppable(insn))
> return INSN_GOOD;
> +
> + if (aarch64_insn_is_bcond(insn)) {
> + asi->handler = simulate_b_cond;
> + } else if (aarch64_insn_is_cbz(insn) ||
> + aarch64_insn_is_cbnz(insn)) {
> + asi->handler = simulate_cbz_cbnz;
> + } else if (aarch64_insn_is_tbz(insn) ||
> + aarch64_insn_is_tbnz(insn)) {
> + asi->handler = simulate_tbz_tbnz;
> + } else if (aarch64_insn_is_adr_adrp(insn))
> +
Re: drivers/of: crash on boot
On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote:
> On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote:
>> On 5/18/2016 3:58 PM, Rhyland Klein wrote:
>>> On 5/18/2016 3:36 PM, Rob Herring wrote:
On Wed, May 18, 2016 at 10:34 AM, Sasha Levin
wrote:
> Hi Rhyland,
>
> I'm seeing a crash on boot that seems to have been caused by
> "drivers/of: Fix depth when unflattening devicetree":
>
> [ 61.145229]
> ==
>
> [ 61.147588] BUG: KASAN: stack-out-of-bounds in
> unflatten_dt_nodes+0x11d2/0x1290 at addr 88005b30777c
[...]
>> This patch seems to work for me. I found a bug in my original patch.
>> Sasha/Rob, can you see if this works for you too:
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 0b5850027bb5..e7a8caac5b27 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -407,9 +407,9 @@ static int unflatten_dt_nodes(const void *blob,
>>
>> root = dad;
>> fpsizes[depth] = dad ? strlen(of_node_full_name(dad)) : 0;
>> - nps[depth+1] = dad;
>> + nps[depth] = dad;
>> for (offset = 0;
>> -offset >= 0;
>> +offset >= 0 && depth >= 0;
>> offset = fdt_next_node(blob, offset, &depth)) {
>> if (WARN_ON_ONCE(depth >= FDT_MAX_DEPTH))
>> continue;
>
> This is not work for me. I'm booting x86 with the DT unit test and
> KASAN enabled. I suspect our differences are due to different data
> after the end of the dtb. Also, I think there may be a bug in
> fdt_next_node FDT_END handling. The "!depth" seems suspicious to me
> and I think it should be "!(*depth)".
>
> The DT overlay unit tests are also failing. Not sure if that's related.
Seems with the above patch and the fix to fdt_next_node, the problem
is fixed both for KASAN and the DT overlay tests. Trying it out now
with some other configurations.
Rob
RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume
Hi, > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > boot/resume > > On Wed, May 18, 2016 at 3:25 AM, Zheng, Lv wrote: > > Hi, Rafael > > > > Thanks for the review. > > > >> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > >> Rafael J. Wysocki > >> Sent: Wednesday, May 18, 2016 7:37 AM > >> To: Zheng, Lv > >> Cc: Wysocki, Rafael J ; Rafael J. Wysocki > >> ; Brown, Len ; Lv Zheng > >> ; Linux Kernel Mailing List >> ker...@vger.kernel.org>; ACPI Devel Maling List a...@vger.kernel.org>; > >> Bastien Nocera: > >> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after > >> boot/resume > >> > >> On Tue, May 17, 2016 at 10:27 AM, Lv Zheng wrote: > >> > (This patch hasn't been tested, it's sent for comments) > >> > >> I have a couple of concerns (see below). > >> > >> > Linux userspace (systemd-logind) keeps on rechecking lid state when the > >> > lid state is closed. If it failed to update the lid state to open after > >> > boot/resume, it could suspend the system. But as: > >> > 1. Traditional ACPI platform may not generate the lid open event after > >> >resuming as the open event is actually handled by the BIOS and the > system > >> >is then resumed from a FACS vector. > >> > 2. The _LID control method's initial returning value is not reliable. The > >> >_LID control method is described to return the "current" lid state, > >> >however the word of "current" has ambiguity, many BIOSen return lid > >> >state upon last lid notification while the developers may think the > >> >BIOSen should always return the lid state upon last _LID evaluation. > >> >There won't be difference when we evaluate _LID during the runtime, > the > >> >problem is the initial returning value of this function. When the > >> > BIOSen > >> >implement this control method with cached value, the initial returning > >> >value is likely not reliable. > >> > Thus there is no mean for the ACPI lid driver to provide such an event > >> > conveying correct current lid state. When there is no such an event or > >> > the > >> > event conveys wrong result, false suspending can be examined. > >> > > >> > The root cause of the issue is systemd itself, it could handle the ACPI > >> > control method lid device by implementing a special option like > >> > LidSwitchLevelTriggered=False when it detected the ACPI lid device. > However > >> > there is no explicit documentation clarified the ambiguity, we need to > >> > work it around in the kernel before systemd changing its mind. > >> > >> The above doesn't explain how the issue is addressed here. > > [Lv Zheng] > > The story is a bit long. > > We can see several issues that some platform suspends right after > boot/resume. > > We noticed that on that platforms, _LID is always implemented with cached > lid state returned. > > And it's initial returning value may be "closed" after boot/resume. > > > > It appears the acpi_lid_send_state() sent after boot/resume is the culprit > > to > report the wrong lid state to the userspace. > > But to our surprise, after delete the 2 lines, reporters still can see > > suspends > after boot/resume. > > That's because of systemd implementation. > > It contains code logic that: > > When the lid state is closed, a re-checking mechanism is installed. > > So if we do not send any notification after boot/resume and the old lid > > state > is "closed". > > systemd determines to suspend in the re-checking mechanism. > > If that really is the case, it is plain silly and I don't think we can > do anything in the kernel to help here. [Lv Zheng] The problem is: If we just removed the 2 lines sending wrong lid state after boot/resume. Problem couldn't be solved. It could only be solved by changing both the systemd and the kernel (deleting the 2 lines). > > >> > >> > Link 1: https://lkml.org/2016/3/7/460 > >> > Link 2: https://github.com/systemd/systemd/issues/2087 > >> > Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211 > >> > https://bugzilla.kernel.org/show_bug.cgi?id=106151 > >> > https://bugzilla.kernel.org/show_bug.cgi?id=106941 > >> > Signed-off-by: Lv Zheng > >> > Cc: Bastien Nocera: > >> > --- > >> > drivers/acpi/button.c | 63 > >> + > >> > 1 file changed, 59 insertions(+), 4 deletions(-) > >> > > >> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c > >> > index 5c3b091..bb14ca5 100644 > >> > --- a/drivers/acpi/button.c > >> > +++ b/drivers/acpi/button.c > >> > @@ -53,6 +53,10 @@ > >> > #define ACPI_BUTTON_DEVICE_NAME_LID"Lid Switch" > >> > #define ACPI_BUTTON_TYPE_LID 0x05 > >> > > >> > +#define ACPI_BUTTON_LID_INIT_IGNORE0x00 > >> > +#define ACPI_BUTTON_LID_INIT_OPEN 0x01 > >> > +#define ACPI_BUTTON_LID_INIT_METHOD0x02 > >> > + > >> > #define _COMPONENT
[PATCH RESEND v4 6/9] irqchip/ls1x-cpu: Move the CPU IRQ driver from arch/mips/loongson32/common/
Signed-off-by: Chunbo Cui
Signed-off-by: Binbin Zhou
Signed-off-by: Huacai Chen
---
arch/mips/include/asm/irq_cpu.h | 1 +
arch/mips/loongson32/common/irq.c | 128 +---
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ls1x-cpu.c| 242 ++
4 files changed, 245 insertions(+), 127 deletions(-)
create mode 100644 drivers/irqchip/irq-ls1x-cpu.c
diff --git a/arch/mips/include/asm/irq_cpu.h b/arch/mips/include/asm/irq_cpu.h
index 39a160b..a6ccd6f 100644
--- a/arch/mips/include/asm/irq_cpu.h
+++ b/arch/mips/include/asm/irq_cpu.h
@@ -16,6 +16,7 @@
extern void mips_cpu_irq_init(void);
extern void rm7k_cpu_irq_init(void);
extern void rm9k_cpu_irq_init(void);
+extern void ls1x_cpu_irq_init(void);
#ifdef CONFIG_IRQ_DOMAIN
struct device_node;
diff --git a/arch/mips/loongson32/common/irq.c
b/arch/mips/loongson32/common/irq.c
index f2520f2..8e67a8c 100644
--- a/arch/mips/loongson32/common/irq.c
+++ b/arch/mips/loongson32/common/irq.c
@@ -14,134 +14,8 @@
#include
#include
-#define LS1X_INTC_REG(n, x) \
- ((void __iomem *)KSEG1ADDR(LS1X_INT_REG_BASE + (n * 0x18) +
(x)))
-
-#define LS1X_INTC_INTISR(n)LS1X_INTC_REG(n, 0x0)
-#define LS1X_INTC_INTIEN(n)LS1X_INTC_REG(n, 0x4)
-#define LS1X_INTC_INTSET(n)LS1X_INTC_REG(n, 0x8)
-#define LS1X_INTC_INTCLR(n)LS1X_INTC_REG(n, 0xc)
-#define LS1X_INTC_INTPOL(n)LS1X_INTC_REG(n, 0x10)
-#define LS1X_INTC_INTEDGE(n) LS1X_INTC_REG(n, 0x14)
-
-static void ls1x_irq_ack(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTCLR(n))
- | (1 << bit), LS1X_INTC_INTCLR(n));
-}
-
-static void ls1x_irq_mask(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTIEN(n))
- & ~(1 << bit), LS1X_INTC_INTIEN(n));
-}
-
-static void ls1x_irq_mask_ack(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTIEN(n))
- & ~(1 << bit), LS1X_INTC_INTIEN(n));
- __raw_writel(__raw_readl(LS1X_INTC_INTCLR(n))
- | (1 << bit), LS1X_INTC_INTCLR(n));
-}
-
-static void ls1x_irq_unmask(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTIEN(n))
- | (1 << bit), LS1X_INTC_INTIEN(n));
-}
-
-static struct irq_chip ls1x_irq_chip = {
- .name = "LS1X-INTC",
- .irq_ack= ls1x_irq_ack,
- .irq_mask = ls1x_irq_mask,
- .irq_mask_ack = ls1x_irq_mask_ack,
- .irq_unmask = ls1x_irq_unmask,
-};
-
-static void ls1x_irq_dispatch(int n)
-{
- u32 int_status, irq;
-
- /* Get pending sources, masked by current enables */
- int_status = __raw_readl(LS1X_INTC_INTISR(n)) &
- __raw_readl(LS1X_INTC_INTIEN(n));
-
- if (int_status) {
- irq = LS1X_IRQ(n, __ffs(int_status));
- do_IRQ(irq);
- }
-}
-
-asmlinkage void plat_irq_dispatch(void)
-{
- unsigned int pending;
-
- pending = read_c0_cause() & read_c0_status() & ST0_IM;
-
- if (pending & CAUSEF_IP7)
- do_IRQ(TIMER_IRQ);
- else if (pending & CAUSEF_IP2)
- ls1x_irq_dispatch(0); /* INT0 */
- else if (pending & CAUSEF_IP3)
- ls1x_irq_dispatch(1); /* INT1 */
- else if (pending & CAUSEF_IP4)
- ls1x_irq_dispatch(2); /* INT2 */
- else if (pending & CAUSEF_IP5)
- ls1x_irq_dispatch(3); /* INT3 */
- else if (pending & CAUSEF_IP6)
- ls1x_irq_dispatch(4); /* INT4 */
- else
- spurious_interrupt();
-
-}
-
-struct irqaction cascade_irqaction = {
- .handler = no_action,
- .name = "cascade",
- .flags = IRQF_NO_THREAD,
-};
-
-static void __init ls1x_irq_init(int base)
-{
- int n;
-
- /* Disable interrupts and clear pending,
-* setup all IRQs as high level triggered
-*/
- for (n = 0; n < 4; n++) {
- __raw_writel(0x0, LS1X_INTC_INTIEN(n));
- __raw_writel(0x, LS1X_INTC_INTCLR(n));
- __raw_writel(0x, LS1X_INTC_INTPOL(n));
- /* set DMA0, DMA1 and DMA2 to edge trigger */
- __raw_writel(n ? 0x0 : 0xe000, LS1X_INTC_INTEDGE(n));
- }
-
-
- for (n = base; n < LS1X_IRQS; n++) {
- irq_set_chip_and_handler(n, &ls1x_irq_chip,
-handle_level_irq);
linux-next: manual merge of the rdma tree with Linus' tree
Hi Doug,
Today's linux-next merge of the rdma tree got a conflict in:
include/linux/mlx5/driver.h
between commit:
43a335e055bb ("net/mlx5_core: Flow counters infrastructure")
from Linus' tree and commit:
94c6825e0ff7 ("net/mlx5_core: Use tasklet for user-space CQ completion
events")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/mlx5/driver.h
index 07b504f7eb84,5a41f9003941..
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@@ -41,7 -41,7 +41,8 @@@
#include
#include
#include
+#include
+ #include
#include
#include
Re: [PATCH] serial: 8250_early: Add earlycon support for Synopsys DesignWare ABP UART
+Cc Jon and arm-kernel mailist Any comments, thanks. Kefeng On 2016/5/11 14:06, Kefeng Wang wrote: > Some board like Hisilicon D02 uses Synopsys DesignWare ABP UART, declare an > OF early console for it, so early console device can be enabled with comand > line "earlycon"(without option) via the "stdout-path" property in device-tree. > > Signed-off-by: Kefeng Wang > --- > drivers/tty/serial/8250/8250_early.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/tty/serial/8250/8250_early.c > b/drivers/tty/serial/8250/8250_early.c > index 8d08ff5..85a12f0 100644 > --- a/drivers/tty/serial/8250/8250_early.c > +++ b/drivers/tty/serial/8250/8250_early.c > @@ -150,6 +150,7 @@ EARLYCON_DECLARE(uart, early_serial8250_setup); > OF_EARLYCON_DECLARE(ns16550, "ns16550", early_serial8250_setup); > OF_EARLYCON_DECLARE(ns16550a, "ns16550a", early_serial8250_setup); > OF_EARLYCON_DECLARE(uart, "nvidia,tegra20-uart", early_serial8250_setup); > +OF_EARLYCON_DECLARE(uart, "snps,dw-apb-uart", early_serial8250_setup); > > #ifdef CONFIG_SERIAL_8250_OMAP > >
[PATCH v2] kprobes: add a new module parameter
This patch adds a new module parameter which can be used as the
symbol name. Without this patch, we can only test the "_do_fork" function
with this kernel module. With this patch, the module becomes more flexable,
we can test any functions with this module with:
#insmod kprobe_example.ko symbol="xxx"
Signed-off-by: Huang Shijie
---
v1 -- > v2:
Add more comment for this patch.
---
samples/kprobes/kprobe_example.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 727eb21..2bb190d 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -14,9 +14,13 @@
#include
#include
+#define MAX_SYMBOL_LEN 64
+static char symbol[MAX_SYMBOL_LEN] = "_do_fork";
+module_param_string(symbol, symbol, sizeof(symbol), 0644);
+
/* For each probe you need to allocate a kprobe structure */
static struct kprobe kp = {
- .symbol_name= "_do_fork",
+ .symbol_name= symbol,
};
/* kprobe pre_handler: called just before the probed instruction is executed */
--
2.5.5
Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field
On Fri, May 06, 2016 at 08:20:24PM -0400, Waiman Long wrote: > Currently, it is not possible to determine for sure if a reader > owns a rwsem by looking at the content of the rwsem data structure. > This patch adds a new state RWSEM_READER_OWNED to the owner field > to indicate that readers currently own the lock. Oh, yes please. This will enable us to get rid of the remaining mrlock rwsem abstraction we've carried since the days of Irix in XFS. The only reason the abstraction still exists is that we track write locks for the purposes of checking for correct inode locking contexts via ASSERT(xfs_isilocked()) calls Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH v2] kprobes: add a new module parameter
This patch adds a new module parameter which can be used as the
symbol name. Without this patch, we can only test the "_do_fork" function
with this kernel module. With this patch, the module becomes more flexable,
we can test any functions with this module with:
#insmod kprobe_example.ko symbol="xxx"
Signed-off-by: Huang Shijie
---
v1 -- > v2:
Add more comment for this patch.
---
samples/kprobes/kprobe_example.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 727eb21..2bb190d 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -14,9 +14,13 @@
#include
#include
+#define MAX_SYMBOL_LEN 64
+static char symbol[MAX_SYMBOL_LEN] = "_do_fork";
+module_param_string(symbol, symbol, sizeof(symbol), 0644);
+
/* For each probe you need to allocate a kprobe structure */
static struct kprobe kp = {
- .symbol_name= "_do_fork",
+ .symbol_name= symbol,
};
/* kprobe pre_handler: called just before the probed instruction is executed */
--
2.5.5
Re: linux-next: manual merge of the nfs tree with Linus' tree
> On May 18, 2016, at 8:40 PM, Stephen Rothwell wrote:
>
> Hi Trond,
>
> Today's linux-next merge of the nfs tree got a conflict in:
>
> fs/nfs/direct.c
>
> between commit:
>
> c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO")
>
> from Linus' tree and commit:
>
> ed3743a6d4f3 ("nfs: add debug to directio "good_bytes" counting")
>
> from the nfs tree.
The merge of the nfs tree’s commit looks good to me.
-dros
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/nfs/direct.c
> index 741a92c470bb,7f03163b5364..
> --- a/fs/nfs/direct.c
> +++ b/fs/nfs/direct.c
> @@@ -591,8 -596,8 +594,8 @@@ ssize_t nfs_file_direct_read(struct kio
> goto out_unlock;
>
> dreq->inode = inode;
> - dreq->bytes_left = count;
> + dreq->bytes_left = dreq->max_count = count;
> - dreq->io_start = pos;
> + dreq->io_start = iocb->ki_pos;
> dreq->ctx = get_nfs_open_context(nfs_file_open_context(iocb->ki_filp));
> l_ctx = nfs_get_lock_context(dreq->ctx);
> if (IS_ERR(l_ctx)) {
>
Re: linux-next: manual merge of the vfs tree with the ext4 tree
Hi Arnd,
On Wed, 18 May 2016 16:25:39 +0200 Arnd Bergmann wrote:
>
> I'm getting a warning here because the 'offset' variable is no longer
> used, I've fixed it up on my test box like this:
Thanks. I have applied that to linux-next today and fixed up the merge
fix patch from tomorrow.
> commit 21fffc41b151a6146981487a3fee974e33c7005e
> Author: Arnd Bergmann
> Date: Tue May 17 13:23:39 2016 +0200
>
> ext4: fix linux-next mismerge
>
> fs/ext4/inode.c: In function 'ext4_direct_IO_read':
> fs/ext4/inode.c:3502:9: error: unused variable 'offset'
> [-Werror=unused-variable]
> loff_t offset = iocb->ki_pos;
>
> Signed-off-by: Arnd Bergmann
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index cd72f208c405..f7140ca66e3b 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3499,7 +3499,6 @@ static ssize_t ext4_direct_IO_read(struct kiocb *iocb,
> struct iov_iter *iter)
> {
> int unlocked = 0;
> struct inode *inode = iocb->ki_filp->f_mapping->host;
> - loff_t offset = iocb->ki_pos;
> ssize_t ret;
>
> if (ext4_should_dioread_nolock(inode)) {
--
Cheers,
Stephen Rothwell
Re: [PATCH v5 00/11] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark
On Thu, 2016-05-12 at 18:06 +0300, Andy Shevchenko wrote:
> On Fri, 2016-05-06 at 18:17 +0300, Andy Shevchenko wrote:
> > This is combined series of two things:
> > - split out the Intel LPSS specific driver from 8250_pci into
> > 8250_lpss
> > - enable DMA support on Intel Quark UART
> >
> > The patch has been tested on few Intel SoCs / platforms. In any
> > case I
> > would
> > like to ask Bryan to do independent test.
Andy.
It looks as though there's a performance drop when enabling the DMA
here (v) stock PIO mode with the 8250 driver.
Test setup Galileo Gen1 transmitter - Galileo Gen2 receiver. TX/RX
cross-wired between the Arduino UART headers respectively (pins 0 & 1
on the "Digital PWM" header), GND pin14 similarly cross-wired.
User-space:
Receiver: Stock on-flash yocto-tiny kernel 3.8.7
Transmitter: Galileo Debian image :
https://sourceforge.net/projects/galileodebian/
3.8.7 kernel: On SPI-flash BSP kernel
andy-v4: From your tree
d13ffcf ('serial: 8250: attempt to keep Kconfig and
Makefile in order')
tip-of-tree : 97f0090 ('Merge tag 'rproc-v4.7' of
git://github.com/andersson/remoteproc')
Results:
### Test0 ###
galileo dma andy-v4 9600 8n1
root@galileo:~# time echo "abcdefghijklmnopqrstuvwxyz0123456789" >
/dev/ttyS0
real0m0.060s
user0m0.000s
sys 0m0.000s
galileo non-dma Linux 3.8.7 9600 8n1:
9600 8n1
root@galileo:~# time echo "abcdefghijklmnopqrstuvwxyz0123456789" >
/dev/ttyS0
real0m0.051s
user0m0.000s
sys 0m0.000s
galileo non-dma tip-of-tree 9600 8n1:
root@galileo:~# time echo "abcdefghijklmnopqrstuvwxyz0123456789" >
/dev/ttyS0
real0m0.048s
user0m0.000s
sys 0m0.000s
### Test1 ###
galileo dma andy-v4 9600 8n1:
root@galileo:~# time echo
"abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz01234567
89abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456
789abcdefghijklmnopqrstuvwxyz0123456789" > /dev/ttyS0
real0m0.209s
user0m0.000s
sys 0m0.000s
galileo non-dma Linux 3.8.7 9600 8n1:
root@galileo:~# time echo
"abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz01234567
89abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456
789abcdefghijklmnopqrstuvwxyz0123456789" > /dev/ttyS0
real0m0.206s
user0m0.000s
sys 0m0.000s
galileo non-dma tip-of-tree 9600 8n1:
root@galileo:~# time echo
"abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz01234567
89abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456
789abcdefghijklmnopqrstuvwxyz0123456789" > /dev/ttyS0
real0m0.199s
user0m0.010s
sys 0m0.000s
---
bod
[lkp] [writeback] 074e46e1ad: fio.write_bw_MBps -10.5% regression
FYI, we noticed fio.write_bw_MBps -10.5% regression due to commit:
commit 074e46e1aded0ac0474a5db4d50d514d9dc42e78 ("writeback: throttle buffered
writeback")
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
wb-buf-throttle
in testcase: fio-basic
on test machine: lkp-bdw-ep2: threads Broadwell-EP with 128G memory
with following conditions:
bs=4k/cpufreq_governor=performance/disk=1SSD/fs=xfs/ioengine=sync/nr_task=8/runtime=300/rw=write/test_size=512g
Details are as below:
-->
=
bs/compiler/cpufreq_governor/disk/fs/ioengine/kconfig/nr_task/rootfs/runtime/rw/tbox_group/test_size/testcase:
4k/gcc-4.9/performance/1SSD/xfs/sync/x86_64-rhel/8/debian-x86_64-2015-02-07.cgz/300/write/lkp-bdw-ep2/512g/fio-basic
commit:
565d33b77b63e5f70357ebf97c4141044854f621
074e46e1aded0ac0474a5db4d50d514d9dc42e78
565d33b77b63e5f7 074e46e1aded0ac0474a5db4d5
--
fail:runs %reproductionfail:runs
| | |
1:4 -25%:5
kmsg.ENERGY_PERF_BIAS:Set_to'normal',was'performance'
1:4 -25%:5
kmsg.ENERGY_PERF_BIAS:View_and_update_with_x86_energy_perf_policy(#)
%stddev %change %stddev
\ |\
289.61 ± 0% +3.7% 300.36 ± 0% fio.time.elapsed_time
289.61 ± 0% +3.7% 300.36 ± 0% fio.time.elapsed_time.max
1.074e+09 ± 0% -7.1% 9.971e+08 ± 0% fio.time.file_system_outputs
3446 ± 9% -64.2% 1234 ± 27%
fio.time.involuntary_context_switches
105.50 ± 0% -12.8% 92.00 ± 0%
fio.time.percent_of_cpu_this_job_got
268.34 ± 0% -10.4% 240.47 ± 1% fio.time.system_time
98347 ± 0% +4.6% 102892 ± 0%
fio.time.voluntary_context_switches
1812 ± 0% -10.5% 1622 ± 0% fio.write_bw_MBps
463987 ± 0% -10.5% 415407 ± 0% fio.write_iops
239.56 ± 0% -1.9% 235.12 ± 0% pmeter.Average_Active_Power
1944 ± 0% -8.8% 1773 ± 0% pmeter.performance_per_watt
3446 ± 9% -64.2% 1234 ± 27% time.involuntary_context_switches
105.50 ± 0% -12.8% 92.00 ± 0% time.percent_of_cpu_this_job_got
268.34 ± 0% -10.4% 240.47 ± 1% time.system_time
1774732 ± 0% -10.9%1581981 ± 0% vmstat.io.bo
8570 ± 1% -48.5% 4417 ± 1% vmstat.system.cs
17991 ± 0% -11.1% 15999 ± 0% vmstat.system.in
31090 ± 2% -8.5% 28447 ± 1% meminfo.Active(anon)
7169 ± 12% -32.5% 4839 ± 0% meminfo.AnonHugePages
28207 ± 3% -8.3% 25865 ± 1% meminfo.AnonPages
969710 ± 0% -12.9% 844795 ± 0% meminfo.Writeback
4437 ± 22% -32.7% 2986 ± 24% numa-vmstat.node0.nr_active_anon
3915 ± 19% -27.6% 2835 ± 18% numa-vmstat.node0.nr_anon_pages
125910 ± 6% -14.5% 107612 ± 7% numa-vmstat.node0.nr_writeback
17293 ± 5% -6.5% 16170 ± 5%
numa-vmstat.node1.nr_slab_unreclaimable
120890 ± 5% -14.7% 103101 ± 8% numa-vmstat.node1.nr_writeback
1.837e+08 ± 5% +12.8% 2.072e+08 ± 5% cpuidle.C1-BDW.time
2471919 ± 1% +15.3%2849758 ± 3% cpuidle.C1-BDW.usage
1.565e+08 ± 11% -13.7% 1.35e+08 ± 10% cpuidle.C1E-BDW.time
2.784e+08 ± 16% -80.3% 54791144 ± 18% cpuidle.C3-BDW.time
380002 ± 5% -24.9% 285251 ± 10% cpuidle.C3-BDW.usage
1340681 ± 2% -32.0% 911539 ± 7% cpuidle.C6-BDW.usage
71772 ± 6% -9.0% 65308 ± 4% numa-meminfo.node0.Active
17749 ± 22% -32.7% 11947 ± 24% numa-meminfo.node0.Active(anon)
5249 ± 49% -66.0% 1786 ±123% numa-meminfo.node0.AnonHugePages
15662 ± 19% -27.6% 11342 ± 18% numa-meminfo.node0.AnonPages
503521 ± 6% -14.1% 432594 ± 7% numa-meminfo.node0.Writeback
69173 ± 5% -6.5% 64685 ± 5% numa-meminfo.node1.SUnreclaim
483701 ± 5% -14.7% 412545 ± 8% numa-meminfo.node1.Writeback
1.77 ± 1% -14.4% 1.52 ± 1% turbostat.%Busy
59.50 ± 1% -13.6% 51.40 ± 0% turbostat.Avg_MHz
6.52 ± 2% -17.7% 5.36 ± 2% turbostat.CPU%c1
1.47 ± 20% -82.3% 0.26 ± 23% turbostat.CPU%c3
0.24 ± 48% +52.4% 0.36 ± 5% turbostat.Pkg%pc6
93.44 ± 0% -2.6% 90.99 ± 0% turbostat.PkgWatt
58.25 ± 0% -1.8% 57.22 ± 1% turbostat.RAMWatt
675.50 ± 6% -46.5% 361.60 ± 7%
proc-vmstat.kswapd_low_wmark_hit_quickly
7768 ± 2% -8.5% 7108 ± 1% proc-vmstat.nr_active_anon
7047 ± 3% -8.3% 6463 ± 1% proc-vmstat.nr_anon_pages
2
linux-next: manual merge of the vfs tree with Linus' tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/cifs/cifsfs.c
between commit:
a9ae008f407b ("cifs: Switch to generic xattr handlers")
from Linus' tree and commit:
51085a1f913a ("cifs: use C99 syntax for inode_operations initializer")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
Al: the c99 fixup is not really necessary as the line is commented out
and you didn't fix the one in the line above ... a better fix might be
to delete both those lines?
--
Cheers,
Stephen Rothwell
diff --cc fs/cifs/cifsfs.c
index 67f622df0858,586d4eadd49e..
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@@ -917,11 -919,13 +917,11 @@@ const struct inode_operations cifs_syml
.permission = cifs_permission,
/* BB add the following two eventually */
/* revalidate: cifs_revalidate,
- setattr:cifs_notify_change, *//* BB do we need notify change */
+ .setattr = cifs_notify_change, *//* BB do we need notify change */
-#ifdef CONFIG_CIFS_XATTR
- .setxattr = cifs_setxattr,
- .getxattr = cifs_getxattr,
+ .setxattr = generic_setxattr,
+ .getxattr = generic_getxattr,
.listxattr = cifs_listxattr,
- .removexattr = cifs_removexattr,
-#endif
+ .removexattr = generic_removexattr,
};
static int cifs_clone_file_range(struct file *src_file, loff_t off,
Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote: > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > > Behalf > > Of Dexuan Cui > > Sent: Tuesday, May 17, 2016 10:46 > > To: David Miller > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > > linux-kernel@vger.kernel.org; j...@perches.com; net...@vger.kernel.org; > > a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang > > > > Subject: RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) > > > > > From: David Miller [mailto:da...@davemloft.net] > > > Sent: Monday, May 16, 2016 1:16 > > > To: Dexuan Cui > > > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > > a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY > > > Srinivasan ; Haiyang Zhang ; > > > j...@perches.com; vkuzn...@redhat.com > > > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM > > > Sockets(hv_sock) > > > > > > From: Dexuan Cui > > > Date: Sun, 15 May 2016 09:52:42 -0700 > > > > > > > Changes since v10 > > > > > > > > 1) add module params: send_ring_page, recv_ring_page. They can be used > > to > > > > enlarge the ringbuffer size to get better performance, e.g., > > > > # modprobe hv_sock recv_ring_page=16 send_ring_page=16 > > > > By default, recv_ring_page is 3 and send_ring_page is 2. > > > > > > > > 2) add module param max_socket_number (the default is 1024). > > > > A user can enlarge the number to create more than 1024 hv_sock sockets. > > > > By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes. > > > > (Here 1+1 means 1 page for send/recv buffers per connection, > > > > respectively.) > > > > > > This is papering around my objections, and create module parameters which > > > I am fundamentally against. > > > > > > You're making the facility unusable by default, just to work around my > > > memory consumption concerns. > > > > > > What will end up happening is that everyone will simply increase the > > > values. > > > > > > You're not really addressing the core issue, and I will be ignoring you > > > future submissions of this change until you do. > > > > David, > > I am sorry I came across as ignoring your feedback; that was not my > > intention. > > The current host side design for this feature is such that each socket > > connection > > needs its own channel, which consists of > > > > 1.A ring buffer for host to guest communication > > 2.A ring buffer for guest to host communication > > > > The memory for the ring buffers has to be pinned down as this will be > > accessed > > both from interrupt level in Linux guest and from the host OS at any time. > > > > To address your concerns, I am planning to re-implement both the receive > > path > > and the send path so that no additional pinned memory will be needed. > > > > Receive Path: > > When the application does a read on the socket, we will dynamically allocate > > the buffer and perform the read operation on the incoming ring buffer. Since > > we will be in the process context, we can sleep here and will set the > > "GFP_KERNEL | __GFP_NOFAIL" flags. This buffer will be freed once the > > application consumes all the data. > > > > Send Path: > > On the send side, we will construct the payload to be sent directly on the > > outgoing ringbuffer. > > > > So, with these changes, the only memory that will be pinned down will be the > > memory for the ring buffers on a per-connection basis and this memory will > > be > > pinned down until the connection is torn down. > > > > Please let me know if this addresses your concerns. > > > > -- Dexuan > > Hi David, > Ping. Really appreciate your comment. Don't wait for people to respond to random design questions, go work on the code and figure out if it is workable or not yourself. Then post patches. We aren't responsible for your work, you are. greg k-h
RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Dexuan Cui > Sent: Tuesday, May 17, 2016 10:46 > To: David Miller > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > linux-kernel@vger.kernel.org; j...@perches.com; net...@vger.kernel.org; > a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang > > Subject: RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) > > > From: David Miller [mailto:da...@davemloft.net] > > Sent: Monday, May 16, 2016 1:16 > > To: Dexuan Cui > > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY > > Srinivasan ; Haiyang Zhang ; > > j...@perches.com; vkuzn...@redhat.com > > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) > > > > From: Dexuan Cui > > Date: Sun, 15 May 2016 09:52:42 -0700 > > > > > Changes since v10 > > > > > > 1) add module params: send_ring_page, recv_ring_page. They can be used > to > > > enlarge the ringbuffer size to get better performance, e.g., > > > # modprobe hv_sock recv_ring_page=16 send_ring_page=16 > > > By default, recv_ring_page is 3 and send_ring_page is 2. > > > > > > 2) add module param max_socket_number (the default is 1024). > > > A user can enlarge the number to create more than 1024 hv_sock sockets. > > > By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes. > > > (Here 1+1 means 1 page for send/recv buffers per connection, > > > respectively.) > > > > This is papering around my objections, and create module parameters which > > I am fundamentally against. > > > > You're making the facility unusable by default, just to work around my > > memory consumption concerns. > > > > What will end up happening is that everyone will simply increase the > > values. > > > > You're not really addressing the core issue, and I will be ignoring you > > future submissions of this change until you do. > > David, > I am sorry I came across as ignoring your feedback; that was not my intention. > The current host side design for this feature is such that each socket > connection > needs its own channel, which consists of > > 1.A ring buffer for host to guest communication > 2.A ring buffer for guest to host communication > > The memory for the ring buffers has to be pinned down as this will be accessed > both from interrupt level in Linux guest and from the host OS at any time. > > To address your concerns, I am planning to re-implement both the receive path > and the send path so that no additional pinned memory will be needed. > > Receive Path: > When the application does a read on the socket, we will dynamically allocate > the buffer and perform the read operation on the incoming ring buffer. Since > we will be in the process context, we can sleep here and will set the > "GFP_KERNEL | __GFP_NOFAIL" flags. This buffer will be freed once the > application consumes all the data. > > Send Path: > On the send side, we will construct the payload to be sent directly on the > outgoing ringbuffer. > > So, with these changes, the only memory that will be pinned down will be the > memory for the ring buffers on a per-connection basis and this memory will be > pinned down until the connection is torn down. > > Please let me know if this addresses your concerns. > > -- Dexuan Hi David, Ping. Really appreciate your comment. Thanks, -- Dexuan
linux-next: build failure after merge of the nfs tree
Hi Trond,
After merging the nfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from include/linux/fs.h:19:0,
from fs/nfs/nfs42proc.c:4:
fs/nfs/nfs42proc.c: In function 'nfs42_proc_copy':
fs/nfs/nfs42proc.c:212:30: error: 'struct inode' has no member named 'i_mutex'
mutex_lock(&file_inode(dst)->i_mutex);
^
include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
#define mutex_lock(lock) mutex_lock_nested(lock, 0)
^
fs/nfs/nfs42proc.c:215:32: error: 'struct inode' has no member named 'i_mutex'
mutex_unlock(&file_inode(dst)->i_mutex);
^
Caused by commit
2e72448b07dc ("NFS: Add COPY nfs operation")
interacting with commit
9902af79c01a ("parallel lookups: actual switch to rwsem")
from Linus' tree.
I applied the following merge fix patch - you will need to send this to
Linus when you ask him to merge your tree.
From: Stephen Rothwell
Date: Thu, 19 May 2016 10:50:26 +1000
Subject: [PATCH] nfs: fix for i_mutex to i_rwsem change
Signed-off-by: Stephen Rothwell
---
fs/nfs/nfs42proc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c
index 20c44d1209dc..aa03ed09ba06 100644
--- a/fs/nfs/nfs42proc.c
+++ b/fs/nfs/nfs42proc.c
@@ -209,10 +209,10 @@ ssize_t nfs42_proc_copy(struct file *src, loff_t pos_src,
dst_exception.state = dst_lock->open_context->state;
do {
- mutex_lock(&file_inode(dst)->i_mutex);
+ inode_lock(file_inode(dst));
err = _nfs42_proc_copy(src, pos_src, src_lock,
dst, pos_dst, dst_lock, count);
- mutex_unlock(&file_inode(dst)->i_mutex);
+ inode_unlock(file_inode(dst));
if (err == -ENOTSUPP) {
err = -EOPNOTSUPP;
--
2.7.0
--
Cheers,
Stephen Rothwell
Re: + zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch added to -mm tree
On (05/18/16 14:54), a...@linux-foundation.org wrote:
> The patch titled
> Subject: zram-introduce-per-device-debug_stat-sysfs-node-update-2
> has been added to the -mm tree. Its filename is
> zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch
>
> This patch should soon appear at
>
> http://ozlabs.org/~akpm/mmots/broken-out/zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch
> and later at
>
> http://ozlabs.org/~akpm/mmotm/broken-out/zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch
Hello Andrew,
please drop this one. sorry for inconvenience, it was confusing,
but the final patch here is
message-id: 20160513230834.GB26763@bbox
lkml.kernel.org/r/20160513230834.GB26763@bbox
(link http://marc.info/?l=linux-kernel&m=146318088829399)
-ss
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> --
> From: Sergey Senozhatsky
> Subject: zram-introduce-per-device-debug_stat-sysfs-node-update-2
>
> Link:
> http://lkml.kernel.org/r/20160513130358.631-1-sergey.senozhat...@gmail.com
> Signed-off-by: Sergey Senozhatsky
> Acked-by: Minchan Kim
> Signed-off-by: Andrew Morton
> ---
>
> drivers/block/zram/zram_drv.c |8
> drivers/block/zram/zram_drv.h |2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff -puN
> drivers/block/zram/zram_drv.c~zram-introduce-per-device-debug_stat-sysfs-node-update-2
> drivers/block/zram/zram_drv.c
> ---
> a/drivers/block/zram/zram_drv.c~zram-introduce-per-device-debug_stat-sysfs-node-update-2
> +++ a/drivers/block/zram/zram_drv.c
> @@ -446,7 +446,7 @@ static ssize_t debug_stat_show(struct de
> ret = scnprintf(buf, PAGE_SIZE,
> "version: %d\n%8llu\n",
> version,
> - (u64)atomic64_read(&zram->stats.writestall));
> + (u64)atomic64_read(&zram->stats.num_recompress));
> up_read(&zram->init_lock);
>
> return ret;
> @@ -737,12 +737,12 @@ compress_again:
> zcomp_strm_release(zram->comp, zstrm);
> zstrm = NULL;
>
> - atomic64_inc(&zram->stats.writestall);
> -
> handle = zs_malloc(meta->mem_pool, clen,
> GFP_NOIO | __GFP_HIGHMEM);
> - if (handle)
> + if (handle) {
> + atomic64_inc(&zram->stats.num_recompress);
> goto compress_again;
> + }
>
> pr_err("Error allocating memory for compressed page: %u,
> size=%zu\n",
> index, clen);
> diff -puN
> drivers/block/zram/zram_drv.h~zram-introduce-per-device-debug_stat-sysfs-node-update-2
> drivers/block/zram/zram_drv.h
> ---
> a/drivers/block/zram/zram_drv.h~zram-introduce-per-device-debug_stat-sysfs-node-update-2
> +++ a/drivers/block/zram/zram_drv.h
> @@ -85,7 +85,7 @@ struct zram_stats {
> atomic64_t zero_pages; /* no. of zero filled pages */
> atomic64_t pages_stored;/* no. of pages currently stored */
> atomic_long_t max_used_pages; /* no. of maximum pages stored */
> - atomic64_t writestall; /* no. of write slow paths */
> + atomic64_t num_recompress; /* no. of compression slow paths */
> };
>
> struct zram_meta {
> _
>
> Patches currently in -mm which might be from sergey.senozhat...@gmail.com are
>
> zsmalloc-require-gfp-in-zs_malloc.patch
> zsmalloc-require-gfp-in-zs_malloc-v2.patch
> zram-user-per-cpu-compression-streams.patch
> zram-user-per-cpu-compression-streams-fix.patch
> zram-remove-max_comp_streams-internals.patch
> zram-introduce-per-device-debug_stat-sysfs-node.patch
> zram-introduce-per-device-debug_stat-sysfs-node-update-2.patch
>
> --
> To unsubscribe from this list: send the line "unsubscribe mm-commits" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: malloc() size in CMA region seems to be aligned to CMA_ALIGNMENT
On Wed, May 18, 2016 at 09:15:13PM +0800, lunar12 lunartwix wrote:
> 2016-05-18 16:48 GMT+08:00 Michal Hocko :
> > [CC linux-mm and some usual suspects]
Michal, Thanks.
> >
> > On Tue 17-05-16 23:37:55, lunar12 lunartwix wrote:
> >> A 4MB dma_alloc_coherent in kernel after malloc(2*1024) 40 times in
> >> CMA region by user space will cause an error on our ARM 3.18 kernel
> >> platform with a 32MB CMA.
> >>
> >> It seems that the malloc in CMA region will be aligned to
> >> CMA_ALIGNMENT everytime even if the requested malloc size is very
> >> small so the CMA region is not available after the malloc operations.
> >>
> >> Is there any configuraiton that can change this behavior??
> >>
> >> Thanks
> >>
> >> Cheers
> >> Ken
> >
> > --
> > Michal Hocko
> > SUSE Labs
>
> Update more information and any comment would be very appreciated
>
> CMA region (from boot message):
> Reserved memory: created CMA memory pool at 0x22e0, size 80 MiB
>
> User space test program:
>
> do
> {
>
> addr = malloc(2*1024);
> memset((void *)addr,2*1024,0x5A);
> vaddr=(unsigned int)addr;
>
> //get_user_page & page_to_phys in kernel
> ioctl(devfd, IOCTL_MSYS_USER_TO_PHYSICAL, &addr)
>
> count++;
> paddr=(unsigned int)addr;
>
> if(paddr>0x22E0)
> {
> printf("USR:0x%08X 0x%08X %d\n",vaddr,paddr,count);
> }
> } while(addr!=NULL);
>
>
> System print out:
>
> USR:0x0164B248 0x27C0 11337
> USR:0x0164BA50 0x27C0 11338
> USR:0x0164C258 0x2780 11339
> USR:0x0164CA60 0x2780 11340
> USR:0x0164D268 0x2760 11341
> USR:0x0164DA70 0x2760 11342
> USR:0x0164E278 0x2740 11343
> USR:0x0164EA80 0x2740 11344
> USR:0x0164F288 0x2720 11345
> USR:0x0164FA90 0x2720 11346
>
> It seems that an 2MB CMA would be occpuied every 2 malloc()
I'm not familiar with device part of CMA but try to analyze.
Above output means that your device maps 2 MB CMA mem to 1 page. I guess
that your device requires such alignment. Could you check
CONFIG_CMA_ALIGNMENT? And, insert to log to below snippet
in drivers/base/dma-contiguous.c to check your device align requirement?
struct page *dma_alloc_from_contiguous(struct device *dev, size_t count,
unsigned int align)
{
if (align > CONFIG_CMA_ALIGNMENT)
align = CONFIG_CMA_ALIGNMENT;
return cma_alloc(dev_get_cma_area(dev), count, align);
}
I guess changing CONFIG_CMA_ALIGNMENT works for you, but, since it
ignore your device align requirement, I'm not sure that it is right solution.
Thanks.
Re: [PATCH perf/core v8 07/16] perf probe: Remove caches when --cache is given
Hi Masami,
On 05/15/2016 08:50 AM, Masami Hiramatsu wrote:
From: Masami Hiramatsu
perf-probe --del removes caches when --cache is given.
Note that the delete pattern is not same as normal events.
If you cached probes with event name, --del "eventname"
works as expected. However, if you skipped it, the cached
probes doesn't have actual event name. In that case
--del "probe-desc" is required (wildcard is acceptable).
For example a cache entry has the probe-desc "vfs_read $params",
you can remove it with --del 'vfs_read*'.
-
# perf probe --cache --list
/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
vfs_read $params
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
# perf probe --cache --del vfs_read\*
Removed event: probe:vfs_read
Not sure where the o/p message for perf probe --cache --del
is coming from here. So, if we are removing an event from the cache,
is it intended to remove that from the {u,k}probe_events file as well?
The patch removes only from the cache (which I think is the intended
behavior). With this patch, when I delete an event from the cache, it
silently deletes it. So, do we add some kind of a message there?
# ./perf probe --cache --list
[kernel.kallsyms] (818a8e96766649cb2b62fc0bc3e66c27be0cd870):
vfs_read
/usr/lib64/libc-2.18.so (e8587f5d2edba244cc43368b5ebfce1782195b6f):
getaddrinfo $params
# ./perf probe --cache --del vfs_read\*
#
If we are silently removing the events from the cache, the commit message
needs to be ammended.
# perf probe --cache --list
/[kernel.kallsyms] (1466a0a250b5d0070c6d0f03c5fed30b237970a1):
/usr/lib64/libc-2.17.so (c31ffe7942bfd77b2fca8f9bd5709d387a86d3bc):
getaddrinfo $params
-
Signed-off-by: Masami Hiramatsu
Signed-off-by: Masami Hiramatsu
---
Changes in v4:
- move del_perf_probe_caches() into builtin-probe.c since
command-line related delete procedure is there now.
---
tools/perf/Documentation/perf-probe.txt |1 +
tools/perf/builtin-probe.c | 27 ++
tools/perf/util/probe-file.c| 32 ---
tools/perf/util/probe-file.h|2 ++
4 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index 5a70d45..8d09173 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -116,6 +116,7 @@ OPTIONS
(With --add) Cache the probes. Any events which successfully added
are also stored in the cache file.
(With --list) Show cached probes.
+ (With --del) Remove cached probes.
--max-probes=NUM::
Set the maximum number of probe points for an event. Default is 128.
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 53e380c0e..8f61525 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -363,6 +363,30 @@ out_cleanup:
return ret;
}
+static int del_perf_probe_caches(struct strfilter *filter)
+{
+ struct probe_cache *cache;
+ struct strlist *bidlist;
+ struct str_node *nd;
+ int ret;
+
+ ret = build_id_cache__list_all(&bidlist);
+ if (ret < 0) {
+ pr_debug("Failed to get buildids: %d\n", ret);
+ return ret;
+ }
+
+ strlist__for_each(nd, bidlist) {
+ cache = probe_cache__new(nd->s);
+ if (!cache)
+ continue;
+ probe_cache__remove_entries(cache, filter);
+ probe_cache__commit(cache);
+ probe_cache__delete(cache);
+ }
+ return 0;
+}
+
static int perf_del_probe_events(struct strfilter *filter)
{
int ret, ret2, ufd = -1, kfd = -1;
@@ -375,6 +399,9 @@ static int perf_del_probe_events(struct strfilter *filter)
pr_debug("Delete filter: \'%s\'\n", str);
+ if (probe_conf.cache)
+ return del_perf_probe_caches(filter);
+
/* Get current event names */
ret = probe_file__open_both(&kfd, &ufd, PF_FL_RW);
if (ret < 0)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index a6d4a67..cc0f183 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -660,19 +660,37 @@ out:
return ret;
}
+static bool probe_cache_entry__compare(struct probe_cache_entry *entry,
+ struct strfilter *filter)
+{
+ char buf[128], *ptr = entry->spev;
+
+ if (entry->pev.event) {
+ snprintf(buf, 128, "%s:%s", entry->pev.group, entry->pev.event);
+ ptr = buf;
+ }
+ return strfilter__compare(filter, ptr);
+}
+
+int probe_cache__remove_entries(struct probe_cache *pcache,
+ struct strfilter *filter)
+{
+ struct probe_cache_entry *entry, *tmp;
+
+ list_for
linux-next: manual merge of the nfs tree with Linus' tree
Hi Trond,
Today's linux-next merge of the nfs tree got a conflict in:
fs/nfs/direct.c
between commit:
c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO")
from Linus' tree and commit:
ed3743a6d4f3 ("nfs: add debug to directio "good_bytes" counting")
from the nfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/nfs/direct.c
index 741a92c470bb,7f03163b5364..
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@@ -591,8 -596,8 +594,8 @@@ ssize_t nfs_file_direct_read(struct kio
goto out_unlock;
dreq->inode = inode;
- dreq->bytes_left = count;
+ dreq->bytes_left = dreq->max_count = count;
- dreq->io_start = pos;
+ dreq->io_start = iocb->ki_pos;
dreq->ctx = get_nfs_open_context(nfs_file_open_context(iocb->ki_filp));
l_ctx = nfs_get_lock_context(dreq->ctx);
if (IS_ERR(l_ctx)) {
Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4
On 5/18/2016 12:15 PM, Christian Lamparter wrote: > On Tuesday, May 17, 2016 04:50:48 PM John Youn wrote: >> On 5/14/2016 6:11 AM, Christian Lamparter wrote: >>> On Thursday, May 12, 2016 11:40:28 AM John Youn wrote: On 5/12/2016 6:30 AM, Christian Lamparter wrote: > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote: >> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote: >> Detecting the endianess of the >> device is probably the best future-proof solution, but it's also >> considerably more work to do in the driver, and comes with a >> tiny runtime overhead. > > The runtime overhead is probably non-measurable compared with the cost > of the actual MMIOs. Right. The code size increase is probably measurable (but still small), the runtime overhead is not. >>> >>> Ok, so no rebuts or complains have been posted. >>> >>> I've tested the patch you made in: https://lkml.org/lkml/2016/5/9/354 >>> and it works: >>> >>> Tested-by: Christian Lamparter >>> >>> So, how do we go from here? There is are two small issues with the >>> original patch (#ifdef DWC2_LOG_WRITES got converted to lower case: >>> #ifdef dwc2_log_writes) and I guess a proper subject would be nice. >>> >>> Arnd, can you please respin and post it (cc'd stable as well)? >>> So this is can be picked up? Or what's your plan? >> >> (I just realized my reply was stuck in my outbox, so the patch >> went out first) >> >> If I recall correctly, the rough consensus was to go with your longer >> patch in the future (fixed up for the comments that BenH and >> I sent), and I'd suggest basing it on top of a fixed version of >> my patch. > Well, but it comes with the "overhead"! So this was just as I said: > "Let's look at it and see if it's any good"... And I think it isn't > since the usb/host/ehci people also opted for #ifdef CONFIG_BIG_ENDIAN > archs etc... I slightly prefer the more general patch for future kernel versions. The overhead will probably be negligible, but we can perform some testing to make sure. Can you resubmit with all gathered feedback? >>> >>> Yes, here are the changes. >>> >>> I've tested it on my MyBook Live Duo. The usbotg comes right up: >>> [12610.540004] dwc2 4bff8.usbotg: USB bus 1 deregistered >>> [12612.513934] dwc2 4bff8.usbotg: Specified GNPTXFDEP=1024 > 256 >>> [12612.518756] dwc2 4bff8.usbotg: EPs: 3, shared fifos, 2042 entries in >>> SPRAM >>> [12612.530112] dwc2 4bff8.usbotg: DWC OTG Controller >>> [12612.533948] dwc2 4bff8.usbotg: new USB bus registered, assigned bus >>> number 1 >>> [12612.540083] dwc2 4bff8.usbotg: irq 33, io mem 0x >>> >>> John: Can you run some perf test with it? >>> >>> I've based this on: >>> >>> commit 6ea2fffc9057a67df1994d85a7c085d899eaa25a >>> Author: Arnd Bergmann >>> Date: Fri May 13 15:52:27 2016 +0200 >>> >>> usb: dwc2: fix regression on big-endian PowerPC/ARM systems >>> >>> so naturally, it needs to be applied first. >>> Most of the conversion work was done by the attached >>> coccinelle semantic patches. >>> >>> I had to edit the __bic32 and __orr32 helpers by hand. >>> As well as some debugfs code and stuff in gadget.c. >>> >> >> Thanks Christian. >> >> I'll keep this in our internal tree and send it to Felipe later. This >> causes a bunch of conflicts that I have to fix up and I should do a >> bit of testing as well. >> >> And since there is a patch that fixes the regression this is can wait. >> >> Regards, >> John > --- > Hey, that's really nice of you to do that :-D. Please keep me in the > loop (Cc) for those then. Sure no problem. > > Yes, this needs definitely testing on all the affected ARCHs. > I've attached a diff to a updated version of the patch. It > drops the special MIPS case (as requested by Arnd). > > BTW, I looked into the ioread32_rep and iowrite32_rep again. I'm > not entirely convinced that the hardware FIFOs are actually endian > neutral. But I can't verify it since my Western Digital My Book Live > only supports the host configuration (forces host mode), so I don't > know what a device in dual-mode or peripheral do here. > > The reason why I think it was broken is because there's a PIO copy > to and from the HCFIFO(x) in dwc2_hc_write_packet and > dwc2_hc_read_packet access in the hcd.c file as well... And there, > the code was using the dwc2_readl and dwc2_writel to access the data. > I added special accessors for the FIFOS now: > dwc2_readl_rep and dwc2_writel_rep. > Hmmm, you could be right in that case. I'll have to check with the IP engineers and maybe try to run some tests on our platforms. So native access to the host FIFO will fail then? This platform is a BE CPU with the IP connected as LE, right? > I went all the way and implemented the helpers to do unal
