Re: [PATCH v1 2/4] firmware loader: simplify holding module for request_firmware
Hi Ming, On Thu, Jun 06, 2013 at 08:01:48PM +0800, Ming Lei wrote: > module reference doesn't cover direct loading path, so this patch > simply holds the module in the whole life time of request_firmware() > to fix the problem. This does not make sense to me. If request_firmware() is executing that means some other module references it and module refcount already reflects that. We needed to pin module before Tejun's work ensuring that currently open sysfs entries won't keep related kobjects pinned after kernel marked them inactive. We can probably delete __module_get()/module_put() from firmware_class.c now. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Query]: trace-cmd crashing with '-e syscalls' on 3.13-rc1
On 26 December 2013 21:55, Viresh Kumar wrote: > On 26 December 2013 20:59, Frederic Weisbecker wrote: >> Please post your config, I'll try to at least narrow down the issue >> to the faulting instruction. > > Sure. Please find attached. Ping!! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LNG] Re: [Query] Ticks happen in pair for NO_HZ_FULL cores ?
On 23 December 2013 13:48, Viresh Kumar wrote: > Wrong time, probably many people on vacation now. But I am working, so > will continue reporting my problems, in case somebody is around :) Ping!! (Probably many people would be back from their vacations.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pwm: core: Use devm_kcalloc instead of kzalloc
Use devm_kcalloc instead of kzalloc to free automatically and make
the cleanup paths simpler and the code slightly shorter.
Signed-off-by: Xiubo Li
---
Changed in v2:
- Use devm_kcalloc instead of devm_kzalloc.
Changed in v1:
- Use devm_kzalloc instead of kzalloc.
drivers/pwm/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 2ca9504..75220e8 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -80,7 +80,6 @@ static void free_pwms(struct pwm_chip *chip)
bitmap_clear(allocated_pwms, chip->base, chip->npwm);
- kfree(chip->pwms);
chip->pwms = NULL;
}
@@ -245,7 +244,8 @@ int pwmchip_add(struct pwm_chip *chip)
if (ret < 0)
goto out;
- chip->pwms = kzalloc(chip->npwm * sizeof(*pwm), GFP_KERNEL);
+ chip->pwms = devm_kcalloc(chip->dev, chip->npwm,
+ sizeof(*pwm), GFP_KERNEL);
if (!chip->pwms) {
ret = -ENOMEM;
goto out;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm: core: Use devm_kzalloc instead of kzalloc
> > Use devm_kzalloc instead of kzalloc to free automatically and make > > the cleanup paths simpler and the code slightly shorter. > [] > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c > [] > > @@ -245,7 +244,9 @@ int pwmchip_add(struct pwm_chip *chip) > > if (ret < 0) > > goto out; > > > > - chip->pwms = kzalloc(chip->npwm * sizeof(*pwm), GFP_KERNEL); > > + chip->pwms = devm_kzalloc(chip->dev, > > + chip->npwm * sizeof(*pwm), > > + GFP_KERNEL); > > There is a devm_kcalloc and this should likely use it. > Yes, I will use it. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
[...]
Unfortunately not. This commit has a side effect that it in fact
disables the multiqueue macvtap transmission. Since all macvtap queues
will contend on a single qdisc lock.
They will only contend on a single qdisc lock if the lower device has
1 queue.
I think we are talking about 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
Yes.
The qdisc or txq lock were macvlan device itself since dev_queue_xmit()
was called for macvlan device itself. So even if lower device has
multiple txqs, if you just create a one queue macvlan device, you will
get lock contention on macvlan device. And even if you explicitly
specifying the txq numbers ( though I don't believe most management
software will do this) when creating the macvlan/macvtap device, you
must also configure the XPS for macvlan to make sure it has the
possibility of using multiple transmit queues.
OK I think I'm finally putting all the pieces together thanks.
Do you know why macvtap is setting dev->tx_queue_len by default? If you
zero this then the noqueue_qdisc is used and the q->enqueue check in
dev_queue_xmit will fail.
Also if XPS is not configured then skb_tx_hash is used so multiple
transmit queues will still be used.
Perhaps defaulting the L2 forwarding devices to 1queue was a
mistake. But the same issue arises when running macvtap over a
non-multiqueue nic. Or even if you have a multiqueue device and create
many more macvtap queues than the lower device has queues.
Shouldn't the macvtap configuration take into account the lowest level
devices queues?
See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
tx path"). It allows the management to create a device without worrying
the underlying device.
OK.
How does using the L2 forwarding device change the
contention issues? Without the L2 forwarding LLTX is enabled but the
qdisc lock, etc is still acquired on the device below the macvlan.
That's the point. We need make sure the txq selection and qdisc lock
were done for the lower device not for the macvlan device itself. Then
macvlan can automatically benefit from the multi-queue capable lower
devices. But L2 forwarding needs to contend on the txq lock on macvlan
device itself, which is unnecessary and can complex the management.
If I make the l2 forwarding defaults a bit better then using the L2
forwarding case should not be any more complex. And because the queues
are dedicated to the macvtap device any contention from qdisc lock, etc
comes from the upper device only. Also if I get the bandwidth controls
in we can set the max/min bandwidth per macvtap device this way. That
is future work though.
The ixgbe driver as it is currently written can be configured for up to
4 queues by setting numtxqueues when the device is created. I assume
when creating macvtap queues the user needs to account for the number
of queues supported by the lower device.
We'd better not complicate the task of management, lockless tx path work
very well so we can just keep it. Btw, there's no way for the user to
know the maximum number of queues that L2 forwarding supports.
Good point I'll add an attribute to query it.
For L2 forwarding offload itself, more issues need to be addressed for
multiqueue macvtap:
- ndo_dfwd_add_station() can only create queues per device at ndo_open,
but multiqueue macvtap allows user to create and destroy queues at their
will and at any time.
same argument as above, isn't this the same when running macvtap without
the l2 offloads over a real device? I expect you hit the same contention
points when running over a real device.
Not true and not only for contention.
Macvtap allows user to create or destroy a queue by simply open or close
to character device /dev/tapX. But currently, we do nothing when a new
queue was created or destroyed for L2 forwarding offload.
For contention, lockless tx path make the contention only happens for
the txq or qdisc for the lower device, but L2 forwarding offload make
contention also happen for the macvlan device itself.
Right, but there will be less contention there because those queues
are a dedicated resource for the upper device.
At this point I think I need to put together a real testbed and
benchmark some of this with netperf and perf running to get real
numbers. When I originally did the l2 forwarding I did not do any
testing with multiple macvtap queues and only very limited work with
macvtap.
- it looks that ixgbe has a upper limit of 4 queues per station, but
macvtap currently allows up to 16 queues per device.
The 4 limit was to simplify the code because the queue mapping in the
driver gets complicated if it is greater than 4. We can probably
increase this latter. But sorry reiterating how is this different than
a macvtap on a real device that supports a max of 4 queues?
Well, it maybe easy. I just point out possible issues we may meet currently.
Right.
So more works need to be done and unless those above 3 issues were
Re: status of block-integrity
On 01/07/2014 02:36 AM, Darrick J. Wong wrote: > On Fri, Jan 03, 2014 at 03:03:42PM -0500, Martin K. Petersen wrote: >>> "Hannes" == Hannes Reinecke writes: >> >> Hannes> Personally, I doubt it's a good idea to kill it off, but a >> Hannes> proper (userland) API for it has been a long time missing. >> >> Before we throw the baby out with the bath water, maybe Darrick can fill >> us in on the progress of the aio passthrough interface? > > I haven't made much progress on it -- I haven't seen any earnest demand for > it. > Of course not. Who should be demanding it? Application developer tend to code to existing interfaces. > Last year Chuck Lever said that some NFS working group was looking defining an > interface it... has there been any progress? It doesn't sound like there has > been. > Well, the point is that without any defined (userland) interface it's quite hard to pursuade any userland application developer to use it. Plus (as hch rightly pointed out) as there is no defined userland interface the question is why we bother with all the DIX stuff in the block layer. DIF support would be perfectly sufficient to cover any connectivity issues. And one feels _really_ silly trying to convince customers from the benefits of DIX they can't even use. I've tried that several times, and it doesn't get better over time... Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: core: Use devm_kzalloc instead of kzalloc
On Tue, 2014-01-07 at 14:05 +0800, Xiubo Li wrote: > Use devm_kzalloc instead of kzalloc to free automatically and make > the cleanup paths simpler and the code slightly shorter. [] > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c [] > @@ -245,7 +244,9 @@ int pwmchip_add(struct pwm_chip *chip) > if (ret < 0) > goto out; > > - chip->pwms = kzalloc(chip->npwm * sizeof(*pwm), GFP_KERNEL); > + chip->pwms = devm_kzalloc(chip->dev, > + chip->npwm * sizeof(*pwm), > + GFP_KERNEL); There is a devm_kcalloc and this should likely use it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
On Fri, Jan 03, 2014 at 09:41:33PM -0800, Dmitry Torokhov wrote: > On Fri, Jan 03, 2014 at 09:03:11PM -0800, Andrey Smirnov wrote: > > On Fri, Jan 3, 2014 at 8:44 PM, Dmitry Torokhov > > wrote: > > > On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote: > > >> On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov > > >> wrote: > > >> > Hi Andrey, > > >> > > > >> > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote: > > >> >> New version of the PCU firmware supports two new commands: > > >> >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the > > >> >> registers of one finger navigation(OFN) chip present on the device > > >> >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the > > >> >> registers of said chip. > > >> >> > > >> >> This commit adds two helper functions to use those commands and sysfs > > >> >> attributes to use them. It also exposes some OFN configuration > > >> >> parameters via sysfs. > > >> > > > >> > Thank you for making the changes. I do not still quite like the games > > >> > we > > >> > play with the OFN attributes, how about the patch below (on top of > > >> > yours)? > > >> > > > >> > > >> Yeah, I agree I like it the "two separate sysfs groups" group approach > > >> better. The only small nitpick about your patch is that I think we > > >> should use "get_unaligned_le16" instead of "le16_to_cpup"(In case > > >> anyone decides to run the driver on SuperH or C6x DSPs from TI :-)). > > >> Let me test it and if everything works as expected I'll apply you > > >> patch, convert it to "get_unaligned_le16", squash and send v3 of the > > >> patch. > > > > > > Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is > > > aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary. > > > > * The "pcu" structure is allocated with kmalloc which doesn't give any > > guarantees about address alignment. > > * I am not sure if the cmd_buf field in that structure is aligned, and > > even if it is, any future changes to that structure may shift its > > offset. > > * Also even if the data we are interested in is aligned on 2-byte > > border, I think all those architectures require 4-byte border > > alignment. > > As far as I know word access only requires word alignment. Please see > the other patch I just posted that adds alignment check in balcklight > handling code. Andrey, were you able to test the patch? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/6] [v4] phylib: Support attaching to generic 10g driver
> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, January 07, 2014 1:56 PM > To: shh@gmail.com > Cc: jg1@samsung.com; mugunthan...@ti.com; f.faine...@gmail.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Xie Shaohui-B21989; > aflem...@gmail.com > Subject: Re: [PATCH 5/6] [v4] phylib: Support attaching to generic 10g > driver > > From: > Date: Tue, 7 Jan 2014 10:14:25 +0800 > > > -static int phy_attach_direct(struct net_device *dev, struct > > phy_device *phydev, > > +int phy_attach_direct(struct net_device *dev, struct phy_device > > +*phydev, > > u32 flags, phy_interface_t interface) > > Since you are changing where the open parenthesis is, you must reindent > the arguments on the second line so that they start exactly at the first > column after that openning parenthesis. > [S.H] OK. Thank you! Will fix it in next version. Best Regards, Shaohui Xie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: core: Use devm_kzalloc instead of kzalloc
Use devm_kzalloc instead of kzalloc to free automatically and make
the cleanup paths simpler and the code slightly shorter.
Signed-off-by: Xiubo Li
---
drivers/pwm/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 2ca9504..74c9f9a 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -80,7 +80,6 @@ static void free_pwms(struct pwm_chip *chip)
bitmap_clear(allocated_pwms, chip->base, chip->npwm);
- kfree(chip->pwms);
chip->pwms = NULL;
}
@@ -245,7 +244,9 @@ int pwmchip_add(struct pwm_chip *chip)
if (ret < 0)
goto out;
- chip->pwms = kzalloc(chip->npwm * sizeof(*pwm), GFP_KERNEL);
+ chip->pwms = devm_kzalloc(chip->dev,
+ chip->npwm * sizeof(*pwm),
+ GFP_KERNEL);
if (!chip->pwms) {
ret = -ENOMEM;
goto out;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 0/7] cpufreq:boost: CPU Boost mode support
Hi Rafael, > This patch series introduces support for CPU overclocking technique > called Boost. > > It is a follow up of a LAB governor proposal. Boost is a LAB > component: > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > software oriented one (like the one done at Exynos). > For this reason cpufreq/freq_table code has been reorganized to > include common code. > > Important design decisions: > - Boost related code is compiled-in unconditionally to cpufreq core > and disabled by default. The cpufreq_driver is responsibile for > setting boost_supported flag and providing set_boost callback(if HW > support is needed). For software managed boost, special Kconfig flag - > CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only > when a target platform has thermal framework properly configured. > > - struct cpufreq_driver has been extended with boost related fields: > -- boost_supported - when driver supports boosting > -- boost_enabled - boost state > -- set_boost - callback to function, which is necessary to >enable/disable boost > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > visible _only_ when cpufreq driver supports Boost. > > - No special spin_lock for Boost was created. The one from cpufreq > core was reused. > > - The Boost code doesn't rely on any policy. When boost state is > changed, then the policy list is iterated and proper adjustements are > done. > > - To improve safety level, the thermal framework is also extended to > disable software boosting, when thermal trip point is reached. After > cooling down the boost can be enabled again. This emulates behaviour > similar to HW managed boost (like x86) > > Tested at HW: >Exynos 4412 3.13-rc4 Linux >Intel Core i7-3770 3.13-rc4 Linux > > Above patches were posted on top of kernel_pm/bleeding-edge > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > Lukasz Majewski (7): > cpufreq: Add boost frequency support in core > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common > boost solution > cpufreq:boost:Kconfig: Provide support for software managed BOOST > cpufreq:exynos:Extend Exynos cpufreq driver to support boost > framework > Documentation:cpufreq:boost: Update BOOST documentation > cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > thermal:exynos:boost: Automatic enable/disable of BOOST feature (at > Exynos4412) > > Documentation/cpu-freq/boost.txt | 26 +++ > drivers/cpufreq/Kconfig |4 + > drivers/cpufreq/Kconfig.arm | 15 > drivers/cpufreq/acpi-cpufreq.c| 86 > +++-- drivers/cpufreq/cpufreq.c | > 118 - > drivers/cpufreq/exynos-cpufreq.c |3 + > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > drivers/cpufreq/freq_table.c | 56 -- > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > include/linux/cpufreq.h | 24 ++ 10 files > changed, 261 insertions(+), 85 deletions(-) > A gentle ping about BOOST patches. Its been already acked by Viresh and Eduardo. It applies on kernel_pm/bleeding_edge SHA1: 4836deb72c5e2a9af0cb2129c1149783a26d99ab Thanks in advance. -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] GenWQE: Fix endian issues detected by sparse
Could you also fix this Smatch warning? drivers/misc/genwqe/card_dev.c:658 do_flash_update() warn: maybe return -EFAULT instead of the bytes remaining? Also we shouldn't be doing dev_err() on copy_to/from_user() problems. The user can trigger those and flood dmesg. It is a DoS (annoying). regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jan 7
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140106: Dropped tree: sh (complex merge conflicts against very old commits) The powerpc tree still had its build failure. The net-next tree lost its build failure. The bluetooth tree gained a conflict against the net and net-next trees. The mmc tree lost its build failure after I applied a supplied merge fix. The regulator tree lost its build failure. The security tree gained a conflict against the pm tree. The spi tree lost its build failure. The tip tree gained a conflict against the pm tree. The xen-tip tree gained a conflict against the arm-current tree. The akpm-current tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 6985 6796 files changed, 346068 insertions(+), 174150 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" as mentioned in the FAQ on the wiki (see below). 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 for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 29 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f0a679afefc0 Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (1e01c7eb7c43 ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h) Merging arm-current/fixes (0a5ccc86507f ARM: 7933/1: rename ioremap_cached to ioremap_cache) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (f991db1cf1bd Merge remote-tracking branch 'agust/merge' into merge) Merging sparc/master (d11739e6d83d Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (fe0d692bbc64 bridge: use spin_lock_bh() in br_multicast_set_hash_max) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (150116bcfbd9 ALSA: hiface: Fix typo in 352800 rate definition) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (e46316c86ee6 Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5) Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5) Merging char-misc.current/char-misc-linus (319e2e3f63c3 Linux 3.13-rc4) Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for Logitech F310 and F710) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile error) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: re
Re: [PATCH] usb:hub set hub->change_bits when over-current happens
On Tue, Jan 7, 2014 at 11:53 AM, Greg KH wrote: > On Tue, Jan 07, 2014 at 11:35:50AM +0800, 沈光 wrote: >> On Tue, Jan 7, 2014 at 10:40 AM, Greg KH wrote: >> > On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote: >> >> set hub->change_bits when we plug in a device which causes >> >> over-current condition, so that hub_events() will check it. >> > >> > Why? >> > >> > What does this solve? Is this a bug with existing devices that needs to >> > be backported to older kernels? >> > >> > thanks, >> > >> > greg k-h >> >> This is something that we found when we are doing compliance test with xHCI. >> If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes >> over-current condition to the root port, the hub->change_bits will not >> be set in current code in the function of hub_activate. > > Now that's something that should go in the changelog, don't you think? > > thanks, > > greg k-h Sure, I agree. I am sorry I didn't make it clear enough. And the reason why over-current can be detected if CONFIG_USB_SUSPEND is disabled, is that the interrupt pipe of the hub will report the change and set hub->event_bits, and then hub_events() will check what events happened. Thanks, Shen Guang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 2/5] misc: tda8026: Add NXP TDA8026 PHY driver
On 1/6/2014 9:00 PM, Mark Rutland wrote:
> On Mon, Jan 06, 2014 at 12:07:39PM +, Satish Patel wrote:
>> TDA8026 is a SmartCard PHY from NXP.
>>
>> The PHY interfaces with the main processor over the
>> I2C interface and acts as a slave device.
>>
>> The driver also exposes the phy interface
>> (defined@include/linux/sc_phy.h) for SmartCard controller.
>> Controller uses this interface to communicate with smart card
>> inserted to the phy's slot.
>>
>> Note: gpio irq is not validated as I do not have device with that.
>> I have validated interrupt with dedicated interrupt line on my device.
>>
>> Signed-off-by: Maulik Mankad
>> Signed-off-by: Satish Patel
>> ---
>> Documentation/devicetree/bindings/misc/tda8026.txt | 14 +
>> drivers/misc/Kconfig |7 +
>> drivers/misc/Makefile |1 +
>> drivers/misc/tda8026.c | 1271
>>
>> 4 files changed, 1293 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt
>> create mode 100644 drivers/misc/tda8026.c
>>
>> diff --git a/Documentation/devicetree/bindings/misc/tda8026.txt
>> b/Documentation/devicetree/bindings/misc/tda8026.txt
>> new file mode 100644
>> index 000..d3083bf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/tda8026.txt
>> @@ -0,0 +1,14 @@
>> +TDA8026 smart card slot interface
>> +
>> +Required properties:
>> +- compatible: nxp,tda8026
>
> Please quote strings:
>
> - compatible: should contain "nxp,tda8026"
ok
>
>> +- shutdown-gpio = GPIO pin mapping for SDWNN pin
>> +- reg = i2c interface address
>
> It's probably worth mentioning at the start that this is an i2c device.
>
> [...]
ok
>
>> +static int tda8026_parse_dt(struct device *dev, struct tda8026 *pdata)
>> +{
>> + struct device_node *np = dev->of_node;
>> + const struct of_device_id *match;
>> + int ret = 0;
>> +
>> + match = of_match_device(of_match_ptr(tda8026_id_table), dev);
>> + if (!match)
>> + return -EINVAL;
>
> Why do this? The of_device_id table contains one entry with no
> additional data. If you just want to see if this was probed via DT,
> dev->of_node not being NULL would tell you that.
>
agree..
> Is this going to be used without DT anywhere?
>
> [...]
>
>> + if (pdata->irq == 0) {
>> + /* look for the field irq-gpio in DT */
>> + irq_gpio = of_get_named_gpio(np, "irq-gpio", 0);
>> + if (!gpio_is_valid(irq_gpio)) {
>> + dev_err(dev, "Failed to get irq gpio,\n");
>> + return -EIO;
>> + }
>
> This is horrible. If the gpio controller can act as an irq controller
No it's not true. Let me clarify the signal flow,
Pins => GPIO => GPIO BANK => Interrupt controller => CPU/MPU
> then it should be annotated as such, with #interrupt-cells, and you
> should just describe the interrupt. The smart card controller cares
> about having an interrupt line, not a GPIO.
>
Let me quote MMC card-detect example here,
File: drivers/mmc/host/omap_hsmmc.c
Card detection is happening through GPIO (same as what this patch is
doing). Please refer to the probe sequence, you will find exactly same
thing there too.
AM437x device has a special feature for the USIM Phy, where the PHY
interrupt automatically gets hooked up to interrupt-controller and
the driver gets interrupt number from DT using #interrupt-cells, exactly
what you had mentioned.
But if same PHY gets interfaced to other SoC's over GPIO, then in order
to handle that scenario you __must__ go through gpio_to_irq().
Let me add another important point here,
You can not determine irq number for the given GPIO, as it gets
allocated dynamically based on GPIO banks supported on the device and on
the board.
> Additionally, this was not described in the binding.
>
> Thanks,
> Mark.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the akpm-current tree with the tip tree
On 01/07/2014 02:00 PM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
pg_data_t's memory from other node") from the akpm-current tree.
These appear to be two very similar solutions, I fixed it up (see below -
I (arbitrarily) chose to keep the actual allocation from the tip tree, but
the messages from the akpm-current tree) and can carry the fix as
necessary (no action is required).
memblock_alloc_nid() and __memblock_alloc_base() will call
memblock_alloc_base_nid() in the end. So I think it is OK to me.
I will do some tests when they are merged.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On 01/07/2014 01:15 PM, John Fastabend wrote:
> On 01/06/2014 07:10 PM, Jason Wang wrote:
>> On 01/06/2014 08:26 PM, Neil Horman wrote:
>>> On Mon, Jan 06, 2014 at 03:54:21PM +0800, Jason Wang wrote:
On 01/06/2014 03:35 PM, John Fastabend wrote:
> On 01/05/2014 07:21 PM, Jason Wang wrote:
>> L2 fowarding offload will bypass the rx handler of real device. This
>> will make
>> the packet could not be forwarded to macvtap device. Another problem
>> is the
>> dev_hard_start_xmit() called for macvtap does not have any
>> synchronization.
>>
>> Fix this by forbidding L2 forwarding for macvtap.
>>
>> Cc: John Fastabend
>> Cc: Neil Horman
>> Signed-off-by: Jason Wang
>> ---
>>drivers/net/macvlan.c |5 -
>>1 files changed, 4 insertions(+), 1 deletions(-)
>>
> I must be missing something.
>
> The lower layer device should set skb->dev to the correct macvtap
> device on receive so that in netif_receive_skb_core() the macvtap
> handler is hit. Skipping the macvlan receive handler should be OK
> because the switching was done by the hardware. If I read macvtap.c
> correctly macvlan_common_newlink() is called with 'dev' where 'dev'
> is the macvtap device. Any idea what I'm missing? I guess I'll need
> to setup a macvtap test case.
Unlike macvlan, macvtap depends on rx handler on the lower device to
work. In this case macvlan_handle_frame() will call macvtap_receive().
So doing netif_receive_skb_core() for macvtap device directly won't
work
since we need to forward the packet to userspace instead of kernel.
For net-next.git, it may work since commit
6acf54f1cf0a6747bac9fea26f34cfc5a9029523 let macvtap device
register an
rx handler for itself.
>>> I agree, this seems like it should already be fixed with the above
>>> commit. With
>>> this the macvlan rx handler should effectively be a no-op as far as the
>>> reception of frames is concerned. As long as the driver sets the
>>> dev correctly
>>> to the macvtap device (and it appears to), macvtap will get frames
>>> to user
>>> space, regardless of weather the software or hardware did the
>>> switching. If
>>> thats the case though, I think the solution is moving that fix to
>>> -stable
>>> (pending testing of course), rather than comming up with a new fix.
>>>
> And what synchronization are you worried about on
> dev_hard_start_xmit()?
> In the L2 forwarding offload case macvlan_open() clears the
> NETIF_F_LLTX
> flag so HARD_TX_LOCK protects the driver txq. We might hit this
> warning
> in dev_queue_xmit() though,
>
>net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
>
> Perhaps we can remove it.
The problem is macvtap does not call dev_queue_xmit() for macvlan
device. It calls macvlan_start_xmit() directly from
macvtap_get_user().
So HARD_TX_LOCK was not done for the txq.
>>> This seems to also be fixed by
>>> 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
>>> Macvtap does, as of that commit use dev_queue_xmit for the
>>> transmission of
>>> frames to the lowerdevice.
>>
>> Unfortunately not. This commit has a side effect that it in fact
>> disables the multiqueue macvtap transmission. Since all macvtap queues
>> will contend on a single qdisc lock.
>>
>
> They will only contend on a single qdisc lock if the lower device has
> 1 queue.
I think we are talking about 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
The qdisc or txq lock were macvlan device itself since dev_queue_xmit()
was called for macvlan device itself. So even if lower device has
multiple txqs, if you just create a one queue macvlan device, you will
get lock contention on macvlan device. And even if you explicitly
specifying the txq numbers ( though I don't believe most management
software will do this) when creating the macvlan/macvtap device, you
must also configure the XPS for macvlan to make sure it has the
possibility of using multiple transmit queues.
> Perhaps defaulting the L2 forwarding devices to 1queue was a
> mistake. But the same issue arises when running macvtap over a
> non-multiqueue nic. Or even if you have a multiqueue device and create
> many more macvtap queues than the lower device has queues.
>
> Shouldn't the macvtap configuration take into account the lowest level
> devices queues?
See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
tx path"). It allows the management to create a device without worrying
the underlying device.
> How does using the L2 forwarding device change the
> contention issues? Without the L2 forwarding LLTX is enabled but the
> qdisc lock, etc is still acquired on the device below the macvlan.
>
That's the point. We need make sure the txq selection and qdisc lock
were done for the lower device not for the macvlan device itself. Then
macvlan can automatically benefit from the
linux-next: manual merge of the akpm-current tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
pg_data_t's memory from other node") from the akpm-current tree.
These appear to be two very similar solutions, I fixed it up (see below -
I (arbitrarily) chose to keep the actual allocation from the tip tree, but
the messages from the akpm-current tree) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/mm/numa.c
index c85da7bb6b60,f26b16f0d3e0..
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@@ -211,11 -211,12 +211,12 @@@ static void __init setup_node_data(int
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
+ pr_warn("Cannot find %zu bytes in node %d, so try other nodes",
+ nd_size, nid);
- nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES,
- MAX_NUMNODES);
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+MEMBLOCK_ALLOC_ACCESSIBLE);
if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
+ pr_err("Cannot find %zu bytes in any node\n", nd_size);
return;
}
}
pgp6hC9X6HEBx.pgp
Description: PGP signature
Re: [PATCH v3] extcon: gpio: Add power resume support
Hi RongJun,
On 01/07/2014 01:56 PM, RongJun Ying wrote:
> From: Rongjun Ying
>
> When system on the suspend state, Some SoC can't get gpio interrupt.
> After system resume, need send extcon uevent to userspace.
>
> Signed-off-by: Rongjun Ying
> Reviewed-by: Barry Song
> ---
> -v3:
> 'check_on_resume' instead of 'load_sleep_irq' as Chanwoo Choi's proposal.
>
> drivers/extcon/extcon-gpio.c | 20
> include/linux/extcon/extcon-gpio.h |1 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 7e0dff5..fde52c1 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -40,6 +40,7 @@ struct gpio_extcon_data {
> int irq;
> struct delayed_work work;
> unsigned long debounce_jiffies;
> + bool check_on_resume;
> };
>
> static void gpio_extcon_work(struct work_struct *work)
> @@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> extcon_data->gpio_active_low = pdata->gpio_active_low;
> extcon_data->state_on = pdata->state_on;
> extcon_data->state_off = pdata->state_off;
> + extcon_data->check_on_resume = pdata->check_on_resume;
> if (pdata->state_on && pdata->state_off)
> extcon_data->edev.print_state = extcon_gpio_print_state;
> if (pdata->debounce) {
> @@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int gpio_extcon_resume(struct device *dev)
> +{
> + struct gpio_extcon_data *extcon_data;
> +
> + extcon_data = dev_get_drvdata(dev);
> + if (extcon_data->check_on_resume)
> + queue_delayed_work(system_power_efficient_wq,
> + _data->work, extcon_data->debounce_jiffies);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops gpio_extcon_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
If CONFIG_PM_SLEEP is undefined, gpio_extcon_pm_ops cannot find
gpio_extcon_resume function.
You should define dummy function for gpio_extcon_resume function.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] extcon: gpio: Add power resume support
This patch has conflict as following:
You have to implement extcon patch based mainline extcon-next branch.
Applying: extcon: gpio: Add power resume support
error: patch failed: drivers/extcon/extcon-gpio.c:103
error: drivers/extcon/extcon-gpio.c: patch does not apply
Patch failed at 0001 extcon: gpio: Add power resume support
The copy of the patch that failed is found in:
/home/cwchoi00/kernel/git.kernel/extcon/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
This time, I will manually apply this patch on extcon branch.
Thanks,
Chanwoo Choi
On 01/07/2014 01:56 PM, RongJun Ying wrote:
> From: Rongjun Ying
>
> When system on the suspend state, Some SoC can't get gpio interrupt.
> After system resume, need send extcon uevent to userspace.
>
> Signed-off-by: Rongjun Ying
> Reviewed-by: Barry Song
> ---
> -v3:
> 'check_on_resume' instead of 'load_sleep_irq' as Chanwoo Choi's proposal.
>
> drivers/extcon/extcon-gpio.c | 20
> include/linux/extcon/extcon-gpio.h |1 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 7e0dff5..fde52c1 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -40,6 +40,7 @@ struct gpio_extcon_data {
> int irq;
> struct delayed_work work;
> unsigned long debounce_jiffies;
> + bool check_on_resume;
> };
>
> static void gpio_extcon_work(struct work_struct *work)
> @@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> extcon_data->gpio_active_low = pdata->gpio_active_low;
> extcon_data->state_on = pdata->state_on;
> extcon_data->state_off = pdata->state_off;
> + extcon_data->check_on_resume = pdata->check_on_resume;
> if (pdata->state_on && pdata->state_off)
> extcon_data->edev.print_state = extcon_gpio_print_state;
> if (pdata->debounce) {
> @@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int gpio_extcon_resume(struct device *dev)
> +{
> + struct gpio_extcon_data *extcon_data;
> +
> + extcon_data = dev_get_drvdata(dev);
> + if (extcon_data->check_on_resume)
> + queue_delayed_work(system_power_efficient_wq,
> + _data->work, extcon_data->debounce_jiffies);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops gpio_extcon_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
> +};
> +
> static struct platform_driver gpio_extcon_driver = {
> .probe = gpio_extcon_probe,
> .remove = gpio_extcon_remove,
> .driver = {
> .name = "extcon-gpio",
> .owner = THIS_MODULE,
> + .pm = _extcon_pm_ops,
> },
> };
>
> diff --git a/include/linux/extcon/extcon-gpio.h
> b/include/linux/extcon/extcon-gpio.h
> index 4195810..c7f0c3e 100644
> --- a/include/linux/extcon/extcon-gpio.h
> +++ b/include/linux/extcon/extcon-gpio.h
> @@ -51,6 +51,7 @@ struct gpio_extcon_platform_data {
> /* if NULL, "0" or "1" will be printed */
> const char *state_on;
> const char *state_off;
> + bool check_on_resume;
> };
>
> #endif /* __EXTCON_GPIO_H__ */
> --
> 1.7.5.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: > [CCing build-system folks and others likely to know about potential > issues.] > > Does anyone have any objection to the use of "#pragma once" instead of > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > and the latest Sparse all support either method just fine. (I added > support to Sparse myself.) Both have equivalent performance. "#pragma > once" is simpler, and avoids the possibility of a typo in the defined > guard symbol. For kernel headers no concern. For UAPI headers we should be more carefull - as we do not know which compiler it ends up seeing - and what version. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
From: Jason Wang Date: Tue, 07 Jan 2014 11:17:06 +0800 > On 01/07/2014 04:47 AM, David Miller wrote: >> From: Jason Wang >> Date: Mon, 6 Jan 2014 11:21:06 +0800 >> >>> L2 fowarding offload will bypass the rx handler of real device. This will >>> make >>> the packet could not be forwarded to macvtap device. Another problem is the >>> dev_hard_start_xmit() called for macvtap does not have any synchronization. >>> >>> Fix this by forbidding L2 forwarding for macvtap. >>> >>> Cc: John Fastabend >>> Cc: Neil Horman >>> Signed-off-by: Jason Wang >> I think I agree with Neil that the rx_handler change might be the best >> way to fix this. That change seems to have a lot of nice unintended >> side effects, no? > > Not all sides effects are nice. > > One obvious issue is it disables the multiqueue macvtap transmission, > since all queues will contend on a single qdisc lock of macvlan. And > even more, multiqueue macvtap support creating and destroying a queue on > demand which is not supported by L2 forwarding offload. > > So L2 forwarding offload needs more fixes to let the multiqueue macvtap > works. Currently, we really need this patch to make sure macvtap works > as expected. Ok I moved these two patches back to "Under Review". These are pretty last minute and we'll need to make a decision on what to do before Friday if you want these changes to really make it into 3.13 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] [v4] phylib: Support attaching to generic 10g driver
From: Date: Tue, 7 Jan 2014 10:14:25 +0800 > -static int phy_attach_direct(struct net_device *dev, struct phy_device > *phydev, > +int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, >u32 flags, phy_interface_t interface) Since you are changing where the open parenthesis is, you must reindent the arguments on the second line so that they start exactly at the first column after that openning parenthesis. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748
On Mon, Jan 06, 2014 at 04:47:38PM -0800, Muthu Kumar wrote:
> OK, after a bit more staring I believe the correct fix is the following.
>
> Fengguang, Please try this one?
Yes, it runs fine now!
Tested-by: Fengguang Wu
Thanks,
Fengguang
>
> In btrfs_end_bio(), we increment bi_remaining if is_orig_bio. If not,
> we restore the orig_bio but failed to increment bi_remaining for
> orig_bio, which triggers a BUG_ON later when bio_endio is called. Fix
> is to increment bi_remaining when we restore the orig bio as well.
>
> Reported-by: fengguang...@intel.com
> CC: Kent Overstreet
> CC: Jens Axboe
> CC: Chris Mason Signed-off-by: Muthukumar Ratty
>
> fs/btrfs/volumes.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 37972d5..2011cc0 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -5297,9 +5297,9 @@ static void btrfs_end_bio(struct bio *bio, int err)
> if (!is_orig_bio) {
> bio_put(bio);
> bio = bbio->orig_bio;
> - } else {
> - atomic_inc(>bi_remaining);
> }
> + atomic_inc(>bi_remaining);
> +
> bio->bi_private = bbio->private;
> bio->bi_end_io = bbio->end_io;
> btrfs_io_bio(bio)->mirror_num = bbio->mirror_num;
>
> --
>
>
>
> On Mon, Jan 6, 2014 at 2:10 PM, Kent Overstreet wrote:
> > Chris, the patch below seems to be incorrect - with it we get hangs, so
> > bi_remaining (probably) isn't getting decremented when it should be. You
> > sent
> > Jens fixes for btrfs which I somehow lost when I rebased, do you remember
> > how
> > this is supposed to work? Looking at the code I'm not quite sure what's
> > going on
> > here.
> >
> > On Fri, Jan 03, 2014 at 11:51:31AM -0800, Muthu Kumar wrote:
> >> Looks like Kent missed the btrfs endio in the original commit. How
> >> about this patch:
> >>
> >> -
> >>
> >> In btrfs_end_bio, call bio_endio_nodec on the restored bio so the
> >> bi_remaining is accounted for correctly.
> >>
> >> Reported-by: fengguang...@intel.com
> >> Cc: Kent Overstreet
> >> CC: Jens Axboe
> >> Signed-off-by: Muthukumar Ratty
> >>
> >>
> >> fs/btrfs/volumes.c |6 +-
> >> 1 files changed, 5 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> >> index f2130de..edfed52 100644
> >> --- a/fs/btrfs/volumes.c
> >> +++ b/fs/btrfs/volumes.c
> >> @@ -5316,7 +5316,11 @@ static void btrfs_end_bio(struct bio *bio, int err)
> >> }
> >> kfree(bbio);
> >>
> >> - bio_endio(bio, err);
> >> +/*
> >> + * Call endio_nodec on the restored bio so the
> >> bi_remaining is
> >> + * accounted for correctly
> >> + */
> >> + bio_endio_nodec(bio, err);
> >> } else if (!is_orig_bio) {
> >> bio_put(bio);
> >> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] extcon: gpio: Add power resume support
> From: Rongjun Ying > > When system on the suspend state, Some SoC can't get gpio interrupt. > After system resume, need send extcon uevent to userspace. > > Signed-off-by: Rongjun Ying > Reviewed-by: Barry Song Acked-by: MyungJoo Ham Thanks! > --- > -v3: > 'check_on_resume' instead of 'load_sleep_irq' as Chanwoo Choi's proposal. > > drivers/extcon/extcon-gpio.c | 20 > include/linux/extcon/extcon-gpio.h |1 + > 2 files changed, 21 insertions(+), 0 deletions(-) > >
Re: [PATCH net] r8152: correct some messages
From: Hayes Wang Date: Tue, 7 Jan 2014 11:18:22 +0800 > - Replace pr_warn_ratelimited() with net_ratelimit() and netdev_warn(). > - Adjust the algnment of some messages. > - Remove the peroid. > - Fix some messages don't have terminating newline. > > Signed-off-by: Hayes Wang I only want major bug fixes in 'net' at this time so I've applied this to 'net-next'. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver
On 01/06/2014 12:58 AM, joeyli wrote:
> 於 二，2013-12-31 於 16:42 -0800，H. Peter Anvin 提到：
>> On 12/19/2013 09:41 PM, joeyli wrote:
What platform do you have that has TAD support? I am wondering how this
was tested.
>>>
>>> It's a testing platform that's only support get/set time functions of
>>> ACPI TAD.
>>>
>>
>> It would be really, really good to get this into Qemu (either SeaBIOS or
>> OVMF, or ideally both) so we can have anyone test.
>>
>> -hpa
>
> I will try to add to OVMF first.
>
For the record, I posted a patch to Qemu about a year ago to store the
timezone in the CMOS, which might be useful for this implementation. It
was rejected because of no firmware support, so if you implement it for
OVMF we can (update and) push this patch again.
-hpa
--- Begin Message ---
From: "H. Peter Anvin"
There is no standard method for storing timezone information
associated with the classic PC/AT RTC, however, there are standard
methods in ACPI (Time and Alarm Device) and EFI (GetTime/SetTime) for
getting this information.
Since these are abstract methods, it is qreally firmware-specific how
it is stored, however, since Qemu initializes the RTC in the virtual
environment that information needs to come from Qemu in the first
place.
Non-PC platforms that use the MC146181 RTC may have their own
firmware-specific methods as well.
The most logical place to stash this information is in the RTC CMOS;
not only is it logically co-located with the relevant information, but
it is also very easy to access from ACPI bytecode. Thus, save the
timezone information in two bytes in CMOS that have no known standard
definition, but are yet within the 64 bytes that even the most basic
RTC CMOS implementations including the original MC146181 support.
Note: all timezones currently in use in the world are on 15-minutes
boundaries, which would allow this information to be stored in a
single signed byte. However, both EFI and ACPI use a minute-granular
interface (specified as -1440 to +1440 with 2047 used to mean
"unknown", this requires a minimum of 12 bits to represent); this
follows that model.
Signed-off-by: H. Peter Anvin
Cc: "Kevin O'Connor"
Cc: David Woodhouse
---
hw/mc146818rtc.c | 6 ++
hw/mc146818rtc_regs.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2fb11f6..72541dd 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -681,6 +681,7 @@ static void rtc_set_date_from_host(ISADevice *dev)
{
RTCState *s = DO_UPCAST(RTCState, dev, dev);
struct tm tm;
+int minuteseast;
qemu_get_timedate(, 0);
@@ -690,6 +691,11 @@ static void rtc_set_date_from_host(ISADevice *dev)
/* set the CMOS date */
rtc_set_cmos(s, );
+
+/* Set the timezone information as a signed 16-bit number of minutes */
+minuteseast = ((int64_t)s->base_rtc - (int64_t)mktime()) / 60;
+s->cmos_data[RTC_TIMEZONE_L] = (uint8_t)(minuteseast);
+s->cmos_data[RTC_TIMEZONE_H] = (uint8_t)(minuteseast >> 8);
}
static int rtc_post_load(void *opaque, int version_id)
diff --git a/hw/mc146818rtc_regs.h b/hw/mc146818rtc_regs.h
index ccdee42..7dd5e0d 100644
--- a/hw/mc146818rtc_regs.h
+++ b/hw/mc146818rtc_regs.h
@@ -47,6 +47,8 @@
/* PC cmos mappings */
#define RTC_CENTURY 0x32
#define RTC_IBM_PS2_CENTURY_BYTE 0x37
+#define RTC_TIMEZONE_L 0x3e
+#define RTC_TIMEZONE_H 0x3f
#define REG_A_UIP 0x80
--
1.7.11.7
--- End Message ---
Re: could you clarify mm/mempolicy: fix !vma in new_vma_page()
On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko wrote:
> On Mon 06-01-14 20:45:54, Bob Liu wrote:
> [...]
>> 544 if (PageAnon(page)) {
>> 545 struct anon_vma *page__anon_vma = page_anon_vma(page);
>> 546 /*
>> 547 * Note: swapoff's unuse_vma() is more efficient with
>> this
>> 548 * check, and needs it to match anon_vma when KSM is
>> active.
>> 549 */
>> 550 if (!vma->anon_vma || !page__anon_vma ||
>> 551 vma->anon_vma->root != page__anon_vma->root)
>> 552 return -EFAULT;
>> 553 } else if (page->mapping && !(vma->vm_flags & VM_NONLINEAR)) {
>> 554 if (!vma->vm_file ||
>> 555 vma->vm_file->f_mapping != page->mapping)
>> 556 return -EFAULT;
>> 557 } else
>> 558 return -EFAULT;
>>
>> That's the "other conditions" and the reason why we can't use
>> BUG_ON(!vma) in new_vma_page().
>
> Sorry, I wasn't clear with my question. I was interested in which of
> these triggered and why only for hugetlb pages?
>
Sorry I didn't analyse the root cause. They are several checks in
page_address_in_vma() so I think it might be not difficult to hit one
of them. For example, if the page was mapped to vma by nonlinear
mapping?
Anyway, some debug code is needed to verify what really happened here.
alloc_page_vma() can handle the vma=NULL case while
alloc_huge_page_noerr() can't, so we return NULL instead of call down
to alloc_huge_page().
--
Regards,
--Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cleanups] x86: Delete non-required instances of include
Commit-ID: 663b55b9b39fa9c848cca273ca4e12bf29b32c71
Gitweb: http://git.kernel.org/tip/663b55b9b39fa9c848cca273ca4e12bf29b32c71
Author: Paul Gortmaker
AuthorDate: Mon, 6 Jan 2014 19:20:26 -0500
Committer: H. Peter Anvin
CommitDate: Mon, 6 Jan 2014 21:25:18 -0800
x86: Delete non-required instances of include
None of these files are actually using any __init type directives
and hence don't need to include . Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
[ hpa: undid incorrect removal from arch/x86/kernel/head_32.S ]
Signed-off-by: Paul Gortmaker
Link:
http://lkml.kernel.org/r/1389054026-12947-1-git-send-email-paul.gortma...@windriver.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/mce.h | 1 -
arch/x86/include/asm/mpspec.h| 1 -
arch/x86/include/asm/processor.h | 1 -
arch/x86/include/asm/ptrace.h| 1 -
arch/x86/include/asm/smp.h | 1 -
arch/x86/include/asm/timer.h | 1 -
arch/x86/kernel/apic/apic_flat_64.c | 1 -
arch/x86/kernel/apic/apic_noop.c | 1 -
arch/x86/kernel/apic/ipi.c | 1 -
arch/x86/kernel/apic/summit_32.c | 1 -
arch/x86/kernel/apic/x2apic_cluster.c| 1 -
arch/x86/kernel/apic/x2apic_phys.c | 1 -
arch/x86/kernel/cpu/amd.c| 1 -
arch/x86/kernel/cpu/centaur.c| 1 -
arch/x86/kernel/cpu/cyrix.c | 1 -
arch/x86/kernel/cpu/intel.c | 1 -
arch/x86/kernel/cpu/mcheck/mce_intel.c | 1 -
arch/x86/kernel/cpu/mcheck/p5.c | 1 -
arch/x86/kernel/cpu/mcheck/winchip.c | 1 -
arch/x86/kernel/cpu/transmeta.c | 1 -
arch/x86/kernel/cpu/umc.c| 1 -
arch/x86/kernel/crash.c | 1 -
arch/x86/kernel/doublefault.c| 1 -
arch/x86/kernel/hw_breakpoint.c | 1 -
arch/x86/kernel/kgdb.c | 1 -
arch/x86/kernel/machine_kexec_32.c | 1 -
arch/x86/kernel/pci-nommu.c | 1 -
arch/x86/kernel/process_32.c | 1 -
arch/x86/kernel/tsc_sync.c | 1 -
arch/x86/lib/delay.c | 1 -
arch/x86/mm/kmmio.c | 1 -
arch/x86/mm/pageattr-test.c | 1 -
arch/x86/pci/fixup.c | 1 -
arch/x86/platform/intel-mid/early_printk_intel_mid.c | 1 -
arch/x86/platform/iris/iris.c| 1 -
arch/x86/realmode/rm/reboot.S| 1 -
arch/x86/realmode/rm/trampoline_32.S | 1 -
arch/x86/realmode/rm/trampoline_64.S | 1 -
arch/x86/um/vdso/vdso.S | 1 -
arch/x86/vdso/vdso.S | 1 -
arch/x86/vdso/vdsox32.S | 1 -
41 files changed, 41 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index c696a86..6e4ce2d 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -118,7 +118,6 @@ extern void mce_register_decode_chain(struct notifier_block
*nb);
extern void mce_unregister_decode_chain(struct notifier_block *nb);
#include
-#include
#include
extern int mce_p5_enabled;
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 3142a94..3e6b492 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -1,7 +1,6 @@
#ifndef _ASM_X86_MPSPEC_H
#define _ASM_X86_MPSPEC_H
-#include
#include
#include
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 7b034a4..8ade617 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -27,7 +27,6 @@ struct mm_struct;
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 942a086..14fd6fd 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -60,7 +60,6 @@ struct pt_regs {
#endif /* !__i386__ */
-#include
#ifdef CONFIG_PARAVIRT
#include
#endif
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 4137890..8cd27e0 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -2,7 +2,6 @@
#define _ASM_X86_SMP_H
#ifndef __ASSEMBLY__
#include
-#include
#include
/*
diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index 34baa0e..a6f3e77 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -1,6 +1,5 @@
#ifndef
Re: kobject: provide kobject_put_wait to fix module unload race
This looks completely broken to me. You do a "kobject_put()" and then
after you've dropped that last use, you wait for the completion of
something that may already have been free'd.
Wtf? Am I missing something?
Linus
On Tue, Jan 7, 2014 at 12:01 PM, Mikulas Patocka wrote:
>
>
> On Mon, 6 Jan 2014, Mike Snitzer wrote:
>
>> On Mon, Jan 06 2014 at 1:55pm -0500,
>> Mikulas Patocka wrote:
>>
>> >
>> >
>> > On Sun, 5 Jan 2014, Greg Kroah-Hartman wrote:
>> >
>> > > On Sun, Jan 05, 2014 at 05:43:56PM +0100, Bart Van Assche wrote:
>> > > > On 01/04/14 19:06, Mikulas Patocka wrote:
>> > > > > - if (t && !t->release)
>> > > > > - pr_debug("kobject: '%s' (%p): does not have a
>> > > > > release() "
>> > > > > - "function, it is broken and must be fixed.\n",
>> > > > > - kobject_name(kobj), kobj);
>> > > > > -
>> > > >
>> > > > Has it been considered to issue a warning if no release function has
>> > > > been defined and free_completion == NULL instead of removing the above
>> > > > debug message entirely ? I think even with this patch applied it is
>> > > > still wrong to invoke kobject_put() on an object without defining a
>> > > > release function.
>> > >
>> > > This patch isn't going to be applied, and I've reverted the original
>> > > commit, so there shouldn't be any issues anymore with this code.
>> >
>> > Why? This patch does the same thing as
>> > eee031649707db3c9920d9498f8d03819b74fc23, but it's smaller. So why did you
>> > accept eee031649707db3c9920d9498f8d03819b74fc23 and not this?
>> >
>> > The code to wait for kobject destruction using completion already exists
>> > in cpufreq_sysfs_release, cpuidle_sysfs_release,
>> > cpuidle_state_sysfs_release, cpuidle_driver_sysfs_release,
>> > ext4_sb_release, ext4_feat_release, f2fs_sb_release (these are the only
>> > kobject users that are correct w.r.t. module unloading), so if you accept
>> > this patch, you can simplify them to use kobject_put_wait.
>>
>> Hi Mikulas,
>>
>> Please just submit a DM-only patch that follows the same racey pattern
>> of firing a completion from the kobj_type .release method in dm_mod.
>> I'll get it queued up for 3.14.
>>
>> If/when we gets reports of a crash due to dm_mod unload racing with
>> kobject_put we can revisit this.
>>
>> Thanks,
>> Mike
>
> Here I'm sending dm-only patch.
>
>
>
> dm: wait until kobject is destroyed
>
> There may be other parts of the kernel taking reference to the dm kobject.
> We must wait until they drop the references before deallocating the md
> structure.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/md/dm-sysfs.c | 10 +-
> drivers/md/dm.c | 11 +++
> drivers/md/dm.h |2 ++
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> Index: linux-3.13-rc7/drivers/md/dm-sysfs.c
> ===
> --- linux-3.13-rc7.orig/drivers/md/dm-sysfs.c 2014-01-07 02:06:08.0
> +0100
> +++ linux-3.13-rc7/drivers/md/dm-sysfs.c2014-01-07 02:07:09.0
> +0100
> @@ -79,6 +79,11 @@ static const struct sysfs_ops dm_sysfs_o
> .show = dm_attr_show,
> };
>
> +static void dm_kobject_release(struct kobject *kobj)
> +{
> + complete(dm_get_completion_from_kobject(kobj));
> +}
> +
> /*
> * dm kobject is embedded in mapped_device structure
> * no need to define release function here
> @@ -86,6 +91,7 @@ static const struct sysfs_ops dm_sysfs_o
> static struct kobj_type dm_ktype = {
> .sysfs_ops = _sysfs_ops,
> .default_attrs = dm_attrs,
> + .release= dm_kobject_release,
> };
>
> /*
> @@ -104,5 +110,7 @@ int dm_sysfs_init(struct mapped_device *
> */
> void dm_sysfs_exit(struct mapped_device *md)
> {
> - kobject_put(dm_kobject(md));
> + struct kobject *kobj = dm_kobject(md);
> + kobject_put(kobj);
> + wait_for_completion(dm_get_completion_from_kobject(kobj));
> }
> Index: linux-3.13-rc7/drivers/md/dm.c
> ===
> --- linux-3.13-rc7.orig/drivers/md/dm.c 2014-01-07 02:07:09.0 +0100
> +++ linux-3.13-rc7/drivers/md/dm.c 2014-01-07 04:58:37.0 +0100
> @@ -203,6 +203,9 @@ struct mapped_device {
> /* sysfs handle */
> struct kobject kobj;
>
> + /* wait until the kobject is released */
> + struct completion kobj_completion;
> +
> /* zero-length flush that will be cloned and submitted to targets */
> struct bio flush_bio;
>
> @@ -2049,6 +2052,7 @@ static struct mapped_device *alloc_dev(i
> init_waitqueue_head(>wait);
> INIT_WORK(>work, dm_wq_work);
> init_waitqueue_head(>eventq);
> + init_completion(>kobj_completion);
>
> md->disk->major = _major;
> md->disk->first_minor = minor;
> @@ -2931,6 +2935,13 @@ struct mapped_device *dm_get_from_kobjec
>
Re: [PATCH] x86: delete non-required instances of include
On 01/06/2014 04:20 PM, Paul Gortmaker wrote: > None of these files are actually using any __init type directives > and hence don't need to include . Most are just a > left over from __devinit and __cpuinit removal, or simply due to > code getting copied from one driver to the next. > > Signed-off-by: Paul Gortmaker > --- > > [build tested allyes/modconfig on x86/build from today's tip tree] > Did you remember to test both 32 and 64 bits? I'm assuming not, since head_32.S no longer builds: /home/hpa/kernel/tip.x86-cleanups/arch/x86/kernel/head_32.S: Assembler messages: /home/hpa/kernel/tip.x86-cleanups/arch/x86/kernel/head_32.S:86: Error: no such instruction: `__head' /home/hpa/kernel/tip.x86-cleanups/arch/x86/kernel/head_32.S:476: Error: no such instruction: `__init' /home/hpa/kernel/tip.x86-cleanups/arch/x86/kernel/head_32.S:635: Error: no such instruction: `__initdata' /home/hpa/kernel/tip.x86-cleanups/arch/x86/kernel/head_32.S:640: Error: no such instruction: `__refdata' /home/hpa/kernel/tip.x86-cleanups/arch/x86/kernel/head_32.S:698: Error: no such instruction: `__initrodata' make[4]: *** [arch/x86/kernel/head_32.o] Error 1 -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu/intel: SNP bit is not dependent on iommu domain coherency
On Tue, 2014-01-07 at 00:54 +, Zhang, Yang Z wrote: > Alex Williamson wrote on 2013-12-24: > > David, > > > > Any comments on this patch? Thanks, > > > > Hi Alex, > > There do have some IOMMUs will treat SNP bit in the PTE as reserved > (0) and will cause a reserved field violation fault if it is set but > hardware not support snoop-control(bit 7 in ECAP_REG is 0). So your > patch seems wrong to me. Thanks for the reply Yang. So effectively IOMMU_CACHE (SNP) is unusable on intel-iommu if we want a domain that can manage any device in the system, right? We have no way to atomically change the SNP bit across a domain so the only chance for enabling it is if all the DRHD units support snoop-control, but then a hot-added DRHD makes that impossible to predict. Is there any way we can make intel-iommu "do the right thing"? These are rather low-level implementation details of intel-iommu that I'd rather not know about as a user of the IOMMU API. Thanks, Alex > > On Tue, 2013-10-29 at 10:21 -0600, Alex Williamson wrote: > >> The setting of the SNP bit in the intel-iommu page tables should not > >> be dependent on the current capability of the iommu domain. The > >> current VT-d spec (2.2) indicates the SNP bit is "treated as > >> reserved[0] by hardware implementations not supporting Snoop Control". > >> Furthermore, section 3.7.3 indicates: > >> > >> If the Snoop Control (SC) field in extended capability Register is > >> reported as 0, snoop behavior for access to the page mapped through > >> second-level translation is determined by the no-snoop attribute in > >> the request. > >> This all seems to indicate that hardware incapable of Snoop Control > >> will handle the SNP bit as zero regardless of the value stored in > >> the PTE. > >> > >> The trouble with the current implementation is that mapping flags > >> depend on the state of the iommu domain at the time of the mapping, > >> yet no attempt is made to update existing mappings when the iommu > >> domain composition changes. This leaves the iommu domain in a state > >> where some mappings may enforce coherency, others do not, and the > >> user of the IOMMU API has no ability to later enable the desired > >> flags atomically with respect to DMA. > >> > >> If we always honor the IOMMU_CACHE flag then an IOMMU API user who > >> specifies IOMMU_CACHE for all mappings can assume that the coherency > >> of the mappings within a domain follow the coherency capability of > >> the domain itself. > >> > >> Signed-off-by: Alex Williamson > >> --- > >> drivers/iommu/intel-iommu.c |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> diff --git a/drivers/iommu/intel-iommu.c > >> b/drivers/iommu/intel-iommu.c index 15e9b57..c46c6a6 100644 > >> --- a/drivers/iommu/intel-iommu.c > >> +++ b/drivers/iommu/intel-iommu.c > >> @@ -4084,7 +4084,7 @@ static int intel_iommu_map(struct iommu_domain > > *domain, > >>prot |= DMA_PTE_READ; > >>if (iommu_prot & IOMMU_WRITE) > >>prot |= DMA_PTE_WRITE; > >> - if ((iommu_prot & IOMMU_CACHE) && dmar_domain->iommu_snooping) > >> + if (iommu_prot & IOMMU_CACHE) > >>prot |= DMA_PTE_SNP; > >> > >>max_addr = iova + size; > > > > > > > Best regards, > Yang > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On 01/06/2014 07:10 PM, Jason Wang wrote:
On 01/06/2014 08:26 PM, Neil Horman wrote:
On Mon, Jan 06, 2014 at 03:54:21PM +0800, Jason Wang wrote:
On 01/06/2014 03:35 PM, John Fastabend wrote:
On 01/05/2014 07:21 PM, Jason Wang wrote:
L2 fowarding offload will bypass the rx handler of real device. This
will make
the packet could not be forwarded to macvtap device. Another problem
is the
dev_hard_start_xmit() called for macvtap does not have any
synchronization.
Fix this by forbidding L2 forwarding for macvtap.
Cc: John Fastabend
Cc: Neil Horman
Signed-off-by: Jason Wang
---
drivers/net/macvlan.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
I must be missing something.
The lower layer device should set skb->dev to the correct macvtap
device on receive so that in netif_receive_skb_core() the macvtap
handler is hit. Skipping the macvlan receive handler should be OK
because the switching was done by the hardware. If I read macvtap.c
correctly macvlan_common_newlink() is called with 'dev' where 'dev'
is the macvtap device. Any idea what I'm missing? I guess I'll need
to setup a macvtap test case.
Unlike macvlan, macvtap depends on rx handler on the lower device to
work. In this case macvlan_handle_frame() will call macvtap_receive().
So doing netif_receive_skb_core() for macvtap device directly won't work
since we need to forward the packet to userspace instead of kernel.
For net-next.git, it may work since commit
6acf54f1cf0a6747bac9fea26f34cfc5a9029523 let macvtap device register an
rx handler for itself.
I agree, this seems like it should already be fixed with the above commit. With
this the macvlan rx handler should effectively be a no-op as far as the
reception of frames is concerned. As long as the driver sets the dev correctly
to the macvtap device (and it appears to), macvtap will get frames to user
space, regardless of weather the software or hardware did the switching. If
thats the case though, I think the solution is moving that fix to -stable
(pending testing of course), rather than comming up with a new fix.
And what synchronization are you worried about on dev_hard_start_xmit()?
In the L2 forwarding offload case macvlan_open() clears the NETIF_F_LLTX
flag so HARD_TX_LOCK protects the driver txq. We might hit this warning
in dev_queue_xmit() though,
net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
Perhaps we can remove it.
The problem is macvtap does not call dev_queue_xmit() for macvlan
device. It calls macvlan_start_xmit() directly from macvtap_get_user().
So HARD_TX_LOCK was not done for the txq.
This seems to also be fixed by 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
Macvtap does, as of that commit use dev_queue_xmit for the transmission of
frames to the lowerdevice.
Unfortunately not. This commit has a side effect that it in fact
disables the multiqueue macvtap transmission. Since all macvtap queues
will contend on a single qdisc lock.
They will only contend on a single qdisc lock if the lower device has
1 queue. Perhaps defaulting the L2 forwarding devices to 1queue was a
mistake. But the same issue arises when running macvtap over a
non-multiqueue nic. Or even if you have a multiqueue device and create
many more macvtap queues than the lower device has queues.
Shouldn't the macvtap configuration take into account the lowest level
devices queues? How does using the L2 forwarding device change the
contention issues? Without the L2 forwarding LLTX is enabled but the
qdisc lock, etc is still acquired on the device below the macvlan.
The ixgbe driver as it is currently written can be configured for up to
4 queues by setting numtxqueues when the device is created. I assume
when creating macvtap queues the user needs to account for the number
of queues supported by the lower device.
For L2 forwarding offload itself, more issues need to be addressed for
multiqueue macvtap:
- ndo_dfwd_add_station() can only create queues per device at ndo_open,
but multiqueue macvtap allows user to create and destroy queues at their
will and at any time.
same argument as above, isn't this the same when running macvtap without
the l2 offloads over a real device? I expect you hit the same contention
points when running over a real device.
- it looks that ixgbe has a upper limit of 4 queues per station, but
macvtap currently allows up to 16 queues per device.
The 4 limit was to simplify the code because the queue mapping in the
driver gets complicated if it is greater than 4. We can probably
increase this latter. But sorry reiterating how is this different than
a macvtap on a real device that supports a max of 4 queues?
So more works need to be done and unless those above 3 issues were
addressed, this patch is really needed to make sure macvtap works.
Agreed there is a lot more work here to improve things I'm just not
sure we need to disable this now. Also note its the l2 forwarding
should be disabled by default so a user would
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On 01/06/2014 07:10 PM, Jason Wang wrote:
On 01/06/2014 08:26 PM, Neil Horman wrote:
On Mon, Jan 06, 2014 at 03:54:21PM +0800, Jason Wang wrote:
On 01/06/2014 03:35 PM, John Fastabend wrote:
On 01/05/2014 07:21 PM, Jason Wang wrote:
L2 fowarding offload will bypass the rx handler of real device. This
will make
the packet could not be forwarded to macvtap device. Another problem
is the
dev_hard_start_xmit() called for macvtap does not have any
synchronization.
Fix this by forbidding L2 forwarding for macvtap.
Cc: John Fastabend
Cc: Neil Horman
Signed-off-by: Jason Wang
---
drivers/net/macvlan.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
I must be missing something.
The lower layer device should set skb->dev to the correct macvtap
device on receive so that in netif_receive_skb_core() the macvtap
handler is hit. Skipping the macvlan receive handler should be OK
because the switching was done by the hardware. If I read macvtap.c
correctly macvlan_common_newlink() is called with 'dev' where 'dev'
is the macvtap device. Any idea what I'm missing? I guess I'll need
to setup a macvtap test case.
Unlike macvlan, macvtap depends on rx handler on the lower device to
work. In this case macvlan_handle_frame() will call macvtap_receive().
So doing netif_receive_skb_core() for macvtap device directly won't work
since we need to forward the packet to userspace instead of kernel.
For net-next.git, it may work since commit
6acf54f1cf0a6747bac9fea26f34cfc5a9029523 let macvtap device register an
rx handler for itself.
I agree, this seems like it should already be fixed with the above commit. With
this the macvlan rx handler should effectively be a no-op as far as the
reception of frames is concerned. As long as the driver sets the dev correctly
to the macvtap device (and it appears to), macvtap will get frames to user
space, regardless of weather the software or hardware did the switching. If
thats the case though, I think the solution is moving that fix to -stable
(pending testing of course), rather than comming up with a new fix.
And what synchronization are you worried about on dev_hard_start_xmit()?
In the L2 forwarding offload case macvlan_open() clears the NETIF_F_LLTX
flag so HARD_TX_LOCK protects the driver txq. We might hit this warning
in dev_queue_xmit() though,
net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
Perhaps we can remove it.
The problem is macvtap does not call dev_queue_xmit() for macvlan
device. It calls macvlan_start_xmit() directly from macvtap_get_user().
So HARD_TX_LOCK was not done for the txq.
This seems to also be fixed by 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
Macvtap does, as of that commit use dev_queue_xmit for the transmission of
frames to the lowerdevice.
Unfortunately not. This commit has a side effect that it in fact
disables the multiqueue macvtap transmission. Since all macvtap queues
will contend on a single qdisc lock.
They will only contend on a single qdisc lock if the lower device has
1 queue. Perhaps defaulting the L2 forwarding devices to 1queue was a
mistake. But the same issue arises when running macvtap over a
non-multiqueue nic. Or even if you have a multiqueue device and create
many more macvtap queues than the lower device has queues.
Shouldn't the macvtap configuration take into account the lowest level
devices queues? How does using the L2 forwarding device change the
contention issues? Without the L2 forwarding LLTX is enabled but the
qdisc lock, etc is still acquired on the device below the macvlan.
The ixgbe driver as it is currently written can be configured for up to
4 queues by setting numtxqueues when the device is created. I assume
when creating macvtap queues the user needs to account for the number
of queues supported by the lower device.
For L2 forwarding offload itself, more issues need to be addressed for
multiqueue macvtap:
- ndo_dfwd_add_station() can only create queues per device at ndo_open,
but multiqueue macvtap allows user to create and destroy queues at their
will and at any time.
same argument as above, isn't this the same when running macvtap without
the l2 offloads over a real device? I expect you hit the same contention
points when running over a real device.
- it looks that ixgbe has a upper limit of 4 queues per station, but
macvtap currently allows up to 16 queues per device.
The 4 limit was to simplify the code because the queue mapping in the
driver gets complicated if it is greater than 4. We can probably
increase this latter. But sorry reiterating how is this different than
a macvtap on a real device that supports a max of 4 queues?
So more works need to be done and unless those above 3 issues were
addressed, this patch is really needed to make sure macvtap works.
Agreed there is a lot more work here to improve things I'm just not
sure we need to disable this now. Also note its the l2 forwarding
should be disabled by default so a user would
[tip:x86/cleanups] x86: Delete non-required instances of include
Commit-ID: 0262b6690132600c6e77534a639519be3f36f8f5
Gitweb: http://git.kernel.org/tip/0262b6690132600c6e77534a639519be3f36f8f5
Author: Paul Gortmaker
AuthorDate: Mon, 6 Jan 2014 19:20:26 -0500
Committer: H. Peter Anvin
CommitDate: Mon, 6 Jan 2014 21:14:15 -0800
x86: Delete non-required instances of include
None of these files are actually using any __init type directives
and hence don't need to include . Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: Paul Gortmaker
Link:
http://lkml.kernel.org/r/1389054026-12947-1-git-send-email-paul.gortma...@windriver.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/mce.h | 1 -
arch/x86/include/asm/mpspec.h| 1 -
arch/x86/include/asm/processor.h | 1 -
arch/x86/include/asm/ptrace.h| 1 -
arch/x86/include/asm/smp.h | 1 -
arch/x86/include/asm/timer.h | 1 -
arch/x86/kernel/apic/apic_flat_64.c | 1 -
arch/x86/kernel/apic/apic_noop.c | 1 -
arch/x86/kernel/apic/ipi.c | 1 -
arch/x86/kernel/apic/summit_32.c | 1 -
arch/x86/kernel/apic/x2apic_cluster.c| 1 -
arch/x86/kernel/apic/x2apic_phys.c | 1 -
arch/x86/kernel/cpu/amd.c| 1 -
arch/x86/kernel/cpu/centaur.c| 1 -
arch/x86/kernel/cpu/cyrix.c | 1 -
arch/x86/kernel/cpu/intel.c | 1 -
arch/x86/kernel/cpu/mcheck/mce_intel.c | 1 -
arch/x86/kernel/cpu/mcheck/p5.c | 1 -
arch/x86/kernel/cpu/mcheck/winchip.c | 1 -
arch/x86/kernel/cpu/transmeta.c | 1 -
arch/x86/kernel/cpu/umc.c| 1 -
arch/x86/kernel/crash.c | 1 -
arch/x86/kernel/doublefault.c| 1 -
arch/x86/kernel/head_32.S| 1 -
arch/x86/kernel/hw_breakpoint.c | 1 -
arch/x86/kernel/kgdb.c | 1 -
arch/x86/kernel/machine_kexec_32.c | 1 -
arch/x86/kernel/pci-nommu.c | 1 -
arch/x86/kernel/process_32.c | 1 -
arch/x86/kernel/tsc_sync.c | 1 -
arch/x86/lib/delay.c | 1 -
arch/x86/mm/kmmio.c | 1 -
arch/x86/mm/pageattr-test.c | 1 -
arch/x86/pci/fixup.c | 1 -
arch/x86/platform/intel-mid/early_printk_intel_mid.c | 1 -
arch/x86/platform/iris/iris.c| 1 -
arch/x86/realmode/rm/reboot.S| 1 -
arch/x86/realmode/rm/trampoline_32.S | 1 -
arch/x86/realmode/rm/trampoline_64.S | 1 -
arch/x86/um/vdso/vdso.S | 1 -
arch/x86/vdso/vdso.S | 1 -
arch/x86/vdso/vdsox32.S | 1 -
42 files changed, 42 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index c696a86..6e4ce2d 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -118,7 +118,6 @@ extern void mce_register_decode_chain(struct notifier_block
*nb);
extern void mce_unregister_decode_chain(struct notifier_block *nb);
#include
-#include
#include
extern int mce_p5_enabled;
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 3142a94..3e6b492 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -1,7 +1,6 @@
#ifndef _ASM_X86_MPSPEC_H
#define _ASM_X86_MPSPEC_H
-#include
#include
#include
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 7b034a4..8ade617 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -27,7 +27,6 @@ struct mm_struct;
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 942a086..14fd6fd 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -60,7 +60,6 @@ struct pt_regs {
#endif /* !__i386__ */
-#include
#ifdef CONFIG_PARAVIRT
#include
#endif
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 4137890..8cd27e0 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -2,7 +2,6 @@
#define _ASM_X86_SMP_H
#ifndef __ASSEMBLY__
#include
-#include
#include
/*
diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index 34baa0e..a6f3e77 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -1,6 +1,5 @@
#ifndef
Re: [PATCH 3.12 000/144] 3.12.7-stable review
On 01/06/2014 02:36 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.12.7 release. There are 144 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jan 8 22:37:25 UTC 2014. Anything received after that time might be too late. Build results: total: 111 pass: 107 skipped: 4 fail: 0 qemu tests all passed. Results are as expected. Details are available as usual at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 000/129] 3.10.26-stable review
On 01/06/2014 02:37 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.26 release. There are 129 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jan 8 22:38:42 UTC 2014. Anything received after that time might be too late. Build results: total: 111 pass: 109 skipped: 1 fail: 1 Build avr32:atngw100mkii_evklcd101_defconfig still fails. qemu tests all passed. Results are as expected. Details are available as usual at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/43] 3.4.76-stable review
On 01/06/2014 02:39 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.76 release. There are 43 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jan 8 22:39:27 UTC 2014. Anything received after that time might be too late. Build results: total: 104 pass: 89 skipped: 11 fail: 4 qemu tests all passed. Results are as expected. Details are available as usual at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] extcon: gpio: Add power resume support
From: Rongjun Ying
When system on the suspend state, Some SoC can't get gpio interrupt.
After system resume, need send extcon uevent to userspace.
Signed-off-by: Rongjun Ying
Reviewed-by: Barry Song
---
-v3:
'check_on_resume' instead of 'load_sleep_irq' as Chanwoo Choi's proposal.
drivers/extcon/extcon-gpio.c | 20
include/linux/extcon/extcon-gpio.h |1 +
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7e0dff5..fde52c1 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -40,6 +40,7 @@ struct gpio_extcon_data {
int irq;
struct delayed_work work;
unsigned long debounce_jiffies;
+ bool check_on_resume;
};
static void gpio_extcon_work(struct work_struct *work)
@@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
+ extcon_data->check_on_resume = pdata->check_on_resume;
if (pdata->state_on && pdata->state_off)
extcon_data->edev.print_state = extcon_gpio_print_state;
if (pdata->debounce) {
@@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int gpio_extcon_resume(struct device *dev)
+{
+ struct gpio_extcon_data *extcon_data;
+
+ extcon_data = dev_get_drvdata(dev);
+ if (extcon_data->check_on_resume)
+ queue_delayed_work(system_power_efficient_wq,
+ _data->work, extcon_data->debounce_jiffies);
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops gpio_extcon_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
+};
+
static struct platform_driver gpio_extcon_driver = {
.probe = gpio_extcon_probe,
.remove = gpio_extcon_remove,
.driver = {
.name = "extcon-gpio",
.owner = THIS_MODULE,
+ .pm = _extcon_pm_ops,
},
};
diff --git a/include/linux/extcon/extcon-gpio.h
b/include/linux/extcon/extcon-gpio.h
index 4195810..c7f0c3e 100644
--- a/include/linux/extcon/extcon-gpio.h
+++ b/include/linux/extcon/extcon-gpio.h
@@ -51,6 +51,7 @@ struct gpio_extcon_platform_data {
/* if NULL, "0" or "1" will be printed */
const char *state_on;
const char *state_off;
+ bool check_on_resume;
};
#endif /* __EXTCON_GPIO_H__ */
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi: Return -ENOENT in acpi_table_parse() and fix wrong comment.
On 01/06/2014 07:50 PM, Rafael J. Wysocki wrote:
On Monday, January 06, 2014 04:47:59 PM Tang Chen wrote:
The comment about return value of acpi_table_parse() is incorrect.
This patch fix it.
Since all callers only check if the function succeeded or not, this
patch simplifies the semantics by returning -errno for all failure
cases. This will also simply the comment.
As suggested by Toshi Kani, also change the stub
in linux/acpi.h to return -ENODEV.
Signed-off-by: Tang Chen
Queued up for 3.14 (but please use the e-mail address from MAINTAINERS next
time) with a modified subject. Thanks!
OK, will use the email address from MAINTAINERS next time.
Thanks.
---
drivers/acpi/tables.c | 7 ---
include/linux/acpi.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 5a5263b..10022ae 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -278,12 +278,13 @@ acpi_table_parse_madt(enum acpi_madt_type id,
/**
* acpi_table_parse - find table with @id, run @handler on it
- *
* @id: table id to find
* @handler: handler to run
*
* Scan the ACPI System Descriptor Table (STD) for a table matching @id,
- * run @handler on it. Return 0 if table found, return on if not.
+ * run @handler on it.
+ *
+ * Return 0 if table found, -errno if not.
*/
int __init acpi_table_parse(char *id, acpi_tbl_table_handler handler)
{
@@ -306,7 +307,7 @@ int __init acpi_table_parse(char *id,
acpi_tbl_table_handler handler)
early_acpi_os_unmap_memory(table, tbl_size);
return 0;
} else
- return 1;
+ return -ENODEV;
}
/*
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index d9099b1..fecfbcd 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -460,7 +460,7 @@ struct acpi_table_header;
static inline int acpi_table_parse(char *id,
int (*handler)(struct acpi_table_header *))
{
- return -1;
+ return -ENODEV;
}
static inline int acpi_nvs_register(__u64 start, __u64 size)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the xen-tip tree with the arm-current tree
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in
arch/arm/include/asm/xen/page.h between commit 0a5ccc86507f ("ARM:
7933/1: rename ioremap_cached to ioremap_cache") from the tree and
commit 02bcf053e9c5 ("asm/xen/page.h: remove redundant semicolon") from
the xen-tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/include/asm/xen/page.h
index 3759cacdd7f8,709c4b4d2f1d..
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@@ -117,6 -117,7 +117,7 @@@ static inline bool set_phys_to_machine(
return __set_phys_to_machine(pfn, mfn);
}
- #define xen_remap(cookie, size) ioremap_cache((cookie), (size));
-#define xen_remap(cookie, size) ioremap_cached((cookie), (size))
++#define xen_remap(cookie, size) ioremap_cache((cookie), (size))
+ #define xen_unmap(cookie) iounmap((cookie))
#endif /* _ASM_ARM_XEN_PAGE_H */
pgpfiGQf4d7_l.pgp
Description: PGP signature
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
On 01/06/2014 01:33 PM, Josh Boyer wrote: > On Thu, Jan 2, 2014 at 3:56 PM, H. Peter Anvin wrote: >> On 01/02/2014 12:39 PM, Vivek Goyal wrote: >>> >>> If secureboot is enabled, it enforces module signature verification. I >>> think similar will happen for kexec too. How would kernel know that on >>> a secureboot platform fd original verification will happen and it is >>> sufficient. >>> >>> I personally want to support bzImage as well (apart from ELF) because >>> distributions has been shipping bzImage for a long time and I don't >>> want to enforce a change there because of secureboot. It is not necessary. >>> Right now I am thinking more about storing detached bzImage signatures >>> and passing those signatures to kexec system call. >>> >> >> Since the secureboot scenario probably means people will be signing >> those kernels, and those kernels are going to be EFI images, that in >> order to have "one kernel, one signature" there will be a desire to >> support signed PE images. Yes, PE is ugly but it shouldn't be too bad. >> However, it is probably one of those things that can be dealt with one >> bit at a time. > > David Howells posted patches to support signed PE binaries early last > year. They were rejected rather quickly. > > https://lkml.org/lkml/2013/2/21/196 > > That was for loading keys via PE binaries, but the parser is needed > either way. Unless I'm misunderstanding what you're suggesting? > I know. I think the kexec is a better motivation, though. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the pm tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/processor_idle.c between commit 6cb85b2b9df9 ("ACPI /
cpuidle: fix max idle state handling with hotplug CPU support") from the
pm tree and commit 16824255394f ("x86, acpi, idle: Restructure the mwait
idle routines") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/acpi/processor_idle.c
index 1fc455b8ce17,f90c56c8379e..
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@@ -783,18 -780,6 +778,13 @@@ static int acpi_idle_enter_simple(struc
if (unlikely(!pr))
return -EINVAL;
+#ifdef CONFIG_HOTPLUG_CPU
+ if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
+ !pr->flags.has_cst &&
+ !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
+ return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START);
+#endif
+
- if (cx->entry_method == ACPI_CSTATE_FFH) {
- if (current_set_polling_and_test())
- return -EINVAL;
- }
-
/*
* Must be done before busmaster disable as we might need to
* access HPET !
pgpgyDHqKAKcA.pgp
Description: PGP signature
[PATCH v2] Staging: comedi: drivers:
Fixed a coding style issue in ke_counter.c Signed-off-by: Aruna Hewapathirane --- drivers/staging/comedi/drivers/ke_counter.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/ke_counter.c b/drivers/staging/comedi/drivers/ke_counter.c index 15589f6..cebf818 100644 --- a/drivers/staging/comedi/drivers/ke_counter.c +++ b/drivers/staging/comedi/drivers/ke_counter.c @@ -105,7 +105,7 @@ static int cnt_auto_attach(struct comedi_device *dev, dev->read_subdev = s; s->type = COMEDI_SUBD_COUNTER; - s->subdev_flags = SDF_READABLE /* | SDF_COMMON */ ; + s->subdev_flags = SDF_READABLE /* | SDF_COMMON */; s->n_chan = 3; s->maxdata = 0x00ff; s->insn_read = cnt_rinsn; @@ -120,7 +120,7 @@ static int cnt_auto_attach(struct comedi_device *dev, outb(0, dev->iobase + 0x40); dev_info(dev->class_dev, "%s: %s attached\n", - dev->driver->driver_name, dev->board_name); + dev->driver->driver_name, dev->board_name); return 0; } -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kobject: provide kobject_put_wait to fix module unload race
On Mon, 6 Jan 2014, Mike Snitzer wrote:
> On Mon, Jan 06 2014 at 1:55pm -0500,
> Mikulas Patocka wrote:
>
> >
> >
> > On Sun, 5 Jan 2014, Greg Kroah-Hartman wrote:
> >
> > > On Sun, Jan 05, 2014 at 05:43:56PM +0100, Bart Van Assche wrote:
> > > > On 01/04/14 19:06, Mikulas Patocka wrote:
> > > > > - if (t && !t->release)
> > > > > - pr_debug("kobject: '%s' (%p): does not have a release()
> > > > > "
> > > > > - "function, it is broken and must be fixed.\n",
> > > > > - kobject_name(kobj), kobj);
> > > > > -
> > > >
> > > > Has it been considered to issue a warning if no release function has
> > > > been defined and free_completion == NULL instead of removing the above
> > > > debug message entirely ? I think even with this patch applied it is
> > > > still wrong to invoke kobject_put() on an object without defining a
> > > > release function.
> > >
> > > This patch isn't going to be applied, and I've reverted the original
> > > commit, so there shouldn't be any issues anymore with this code.
> >
> > Why? This patch does the same thing as
> > eee031649707db3c9920d9498f8d03819b74fc23, but it's smaller. So why did you
> > accept eee031649707db3c9920d9498f8d03819b74fc23 and not this?
> >
> > The code to wait for kobject destruction using completion already exists
> > in cpufreq_sysfs_release, cpuidle_sysfs_release,
> > cpuidle_state_sysfs_release, cpuidle_driver_sysfs_release,
> > ext4_sb_release, ext4_feat_release, f2fs_sb_release (these are the only
> > kobject users that are correct w.r.t. module unloading), so if you accept
> > this patch, you can simplify them to use kobject_put_wait.
>
> Hi Mikulas,
>
> Please just submit a DM-only patch that follows the same racey pattern
> of firing a completion from the kobj_type .release method in dm_mod.
> I'll get it queued up for 3.14.
>
> If/when we gets reports of a crash due to dm_mod unload racing with
> kobject_put we can revisit this.
>
> Thanks,
> Mike
Here I'm sending dm-only patch.
dm: wait until kobject is destroyed
There may be other parts of the kernel taking reference to the dm kobject.
We must wait until they drop the references before deallocating the md
structure.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/md/dm-sysfs.c | 10 +-
drivers/md/dm.c | 11 +++
drivers/md/dm.h |2 ++
3 files changed, 22 insertions(+), 1 deletion(-)
Index: linux-3.13-rc7/drivers/md/dm-sysfs.c
===
--- linux-3.13-rc7.orig/drivers/md/dm-sysfs.c 2014-01-07 02:06:08.0
+0100
+++ linux-3.13-rc7/drivers/md/dm-sysfs.c2014-01-07 02:07:09.0
+0100
@@ -79,6 +79,11 @@ static const struct sysfs_ops dm_sysfs_o
.show = dm_attr_show,
};
+static void dm_kobject_release(struct kobject *kobj)
+{
+ complete(dm_get_completion_from_kobject(kobj));
+}
+
/*
* dm kobject is embedded in mapped_device structure
* no need to define release function here
@@ -86,6 +91,7 @@ static const struct sysfs_ops dm_sysfs_o
static struct kobj_type dm_ktype = {
.sysfs_ops = _sysfs_ops,
.default_attrs = dm_attrs,
+ .release= dm_kobject_release,
};
/*
@@ -104,5 +110,7 @@ int dm_sysfs_init(struct mapped_device *
*/
void dm_sysfs_exit(struct mapped_device *md)
{
- kobject_put(dm_kobject(md));
+ struct kobject *kobj = dm_kobject(md);
+ kobject_put(kobj);
+ wait_for_completion(dm_get_completion_from_kobject(kobj));
}
Index: linux-3.13-rc7/drivers/md/dm.c
===
--- linux-3.13-rc7.orig/drivers/md/dm.c 2014-01-07 02:07:09.0 +0100
+++ linux-3.13-rc7/drivers/md/dm.c 2014-01-07 04:58:37.0 +0100
@@ -203,6 +203,9 @@ struct mapped_device {
/* sysfs handle */
struct kobject kobj;
+ /* wait until the kobject is released */
+ struct completion kobj_completion;
+
/* zero-length flush that will be cloned and submitted to targets */
struct bio flush_bio;
@@ -2049,6 +2052,7 @@ static struct mapped_device *alloc_dev(i
init_waitqueue_head(>wait);
INIT_WORK(>work, dm_wq_work);
init_waitqueue_head(>eventq);
+ init_completion(>kobj_completion);
md->disk->major = _major;
md->disk->first_minor = minor;
@@ -2931,6 +2935,13 @@ struct mapped_device *dm_get_from_kobjec
return md;
}
+struct completion *dm_get_completion_from_kobject(struct kobject *kobj)
+{
+ struct mapped_device *md = container_of(kobj, struct mapped_device,
kobj);
+
+ return >kobj_completion;
+}
+
int dm_suspended_md(struct mapped_device *md)
{
return test_bit(DMF_SUSPENDED, >flags);
Index: linux-3.13-rc7/drivers/md/dm.h
===
--- linux-3.13-rc7.orig/drivers/md/dm.h
[PATCH] [RFC] timekeeping: Rework frequency adjustments to work better w/ nohz
Got a few cycles to take another look at this, and tried to address
Miroslav's latest comments. Please let me know if you have further
thoughts!
thanks
-john
The existing timekeeping_adjust logic has always been complicated
to understand. Further, since it was developed prior to NOHZ becoming
common, its not surprising it performs poorly when NOHZ is enabled.
Since Miroslav pointed out the problematic nature of the existing code
in the NOHZ case, I've tried to refactor the code to perform better.
The problem with the previous approach was that it tried to adjust
for the total cumulative error using a scaled dampening factor. This
resulted in large errors to be corrected slowly, while small errors
were corrected quickly. With NOHZ the timekeeping code doesn't know
how far out the next tick will be, so this results in bad
over-correction to small errors, and insufficient correction to large
errors.
Inspired by Miroslav's patch, I've refactored the code to try to
address the correction in two steps.
1) Check the future freq error for the next tick, and if the frequency
error is large, try to make sure we correct that error as best we can.
2) Then make a small single unit adjustment to correct any cumulative
error that we've collected.
This method performs fairly well in the simulator Miroslav created.
I also dropped the tk->ntp_error adjustments, as I've never quite
been able to recall how that was correct, and it doesn't seem to
have any affect in the simulator. Will have to proceed carefully
with testing here.
I still think this is probably 3.15 or later material, but I'd be
very interested in feedback, thoughts, and testing.
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Reported-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 163 +-
1 file changed, 61 insertions(+), 102 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 87b4f00..15354d4 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1048,54 +1048,50 @@ static int __init timekeeping_init_ops(void)
device_initcall(timekeeping_init_ops);
/*
- * If the error is already larger, we look ahead even further
- * to compensate for late or lost adjustments.
+ * Calculate the future error caused by incorrect freq value
+ * and adjust the timekeeper to correct that.
*/
-static __always_inline int timekeeping_bigadjust(struct timekeeper *tk,
-s64 error, s64 *interval,
-s64 *offset)
+static __always_inline void timekeeping_freqadjust(struct timekeeper *tk,
+s64 interval,
+s64 offset)
{
s64 tick_error, i;
- u32 look_ahead, adj;
- s32 error2, mult;
+ u32 adj;
+ s32 mult = 1;
- /*
-* Use the current error value to determine how much to look ahead.
-* The larger the error the slower we adjust for it to avoid problems
-* with losing too many ticks, otherwise we would overadjust and
-* produce an even larger error. The smaller the adjustment the
-* faster we try to adjust for it, as lost ticks can do less harm
-* here. This is tuned so that an error of about 1 msec is adjusted
-* within about 1 sec (or 2^20 nsec in 2^SHIFT_HZ ticks).
-*/
- error2 = tk->ntp_error >> (NTP_SCALE_SHIFT + 22 - 2 * SHIFT_HZ);
- error2 = abs(error2);
- for (look_ahead = 0; error2 > 0; look_ahead++)
- error2 >>= 2;
+ /* Calculate current error per tick */
+ tick_error = ntp_tick_length() >> tk->ntp_error_shift;
+ tick_error -= tk->xtime_interval;
- /*
-* Now calculate the error in (1 << look_ahead) ticks, but first
-* remove the single look ahead already included in the error.
-*/
- tick_error = ntp_tick_length() >> (tk->ntp_error_shift + 1);
- tick_error -= tk->xtime_interval >> 1;
- error = ((error - tick_error) >> look_ahead) + tick_error;
+ /* Don't worry about correcting it if its small */
+ if (likely(abs(tick_error) < 2*interval))
+ return;
- /* Finally calculate the adjustment shift value. */
- i = *interval;
- mult = 1;
- if (error < 0) {
- error = -error;
- *interval = -*interval;
- *offset = -*offset;
- mult = -1;
+ if (tick_error < 0) {
+ interval = -interval;
+ offset = -offset;
+ mult = -mult;
}
- for (adj = 0; error > i; adj++)
- error >>= 1;
- *interval <<= adj;
- *offset <<= adj;
- return mult << adj;
+ /* Sort out the magnitude of the correction */
+ tick_error = abs(tick_error);
+ i =
Re: [PATCH] usb:hub set hub->change_bits when over-current happens
On Tue, Jan 07, 2014 at 11:35:50AM +0800, 沈光 wrote: > On Tue, Jan 7, 2014 at 10:40 AM, Greg KH wrote: > > On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote: > >> set hub->change_bits when we plug in a device which causes > >> over-current condition, so that hub_events() will check it. > > > > Why? > > > > What does this solve? Is this a bug with existing devices that needs to > > be backported to older kernels? > > > > thanks, > > > > greg k-h > > This is something that we found when we are doing compliance test with xHCI. > If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes > over-current condition to the root port, the hub->change_bits will not > be set in current code in the function of hub_activate. Now that's something that should go in the changelog, don't you think? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the security tree with the pm tree
Hi James,
Today's linux-next merge of the security tree got a conflict in
drivers/char/tpm/tpm_ppi.c between commits df45c712d1f4 ("ACPI / TPM: fix
memory leak when walking ACPI namespace"), 84b1667dea23 ("ACPI / TPM:
replace open-coded _DSM code with helper functions") and 1569a4c4ceba
("ACPI / TPM: detect PPI features by checking availability of _DSM
functions") from the pm tree and commits 747d35bd9bb4 ("tpm/tpm_ppi: Do
not compare strcmp(a,b) == -1") and 238b1eaa59e6 ("tpm/tpm_ppi: Check
return value of acpi_get_name") from the security tree.
I fixed it up (all of the latter patches have been subsumed by changes in
the former ones) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpAtDb6PiElf.pgp
Description: PGP signature
[PATCH 3/6] [v4] phylib: turn genphy_driver to an array
From: Shaohui Xie
Then other generic phy driver such as generic 10g phy driver can join it.
Signed-off-by: Shaohui Xie
---
resend for v4.
drivers/net/phy/phy_device.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d6447b3..748bf07 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -53,7 +53,12 @@ static void phy_device_release(struct device *dev)
kfree(to_phy_device(dev));
}
-static struct phy_driver genphy_driver;
+enum genphy_driver {
+ GENPHY_DRV_1G,
+ GENPHY_DRV_MAX
+};
+
+static struct phy_driver genphy_driver[GENPHY_DRV_MAX];
extern int mdio_bus_init(void);
extern void mdio_bus_exit(void);
@@ -539,7 +544,7 @@ static int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
return -ENODEV;
}
- d->driver = _driver.driver;
+ d->driver = _driver[GENPHY_DRV_1G].driver;
err = d->driver->probe(d);
if (err >= 0)
@@ -613,6 +618,7 @@ EXPORT_SYMBOL(phy_attach);
*/
void phy_detach(struct phy_device *phydev)
{
+ int i;
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
@@ -620,8 +626,12 @@ void phy_detach(struct phy_device *phydev)
* was using the generic driver), we unbind the device
* from the generic driver so that there's a chance a
* real driver could be loaded */
- if (phydev->dev.driver == _driver.driver)
- device_release_driver(>dev);
+ for (i = 0; i < ARRAY_SIZE(genphy_driver); i++) {
+ if (phydev->dev.driver == _driver[i].driver) {
+ device_release_driver(>dev);
+ break;
+ }
+ }
}
EXPORT_SYMBOL(phy_detach);
@@ -1116,7 +1126,8 @@ void phy_drivers_unregister(struct phy_driver *drv, int n)
}
EXPORT_SYMBOL(phy_drivers_unregister);
-static struct phy_driver genphy_driver = {
+static struct phy_driver genphy_driver[] = {
+{
.phy_id = 0x,
.phy_id_mask= 0x,
.name = "Generic PHY",
@@ -1127,7 +1138,7 @@ static struct phy_driver genphy_driver = {
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = {.owner= THIS_MODULE, },
-};
+} };
static int __init phy_init(void)
{
@@ -1137,7 +1148,8 @@ static int __init phy_init(void)
if (rc)
return rc;
- rc = phy_driver_register(_driver);
+ rc = phy_drivers_register(genphy_driver,
+ ARRAY_SIZE(genphy_driver));
if (rc)
mdio_bus_exit();
@@ -1146,7 +1158,8 @@ static int __init phy_init(void)
static void __exit phy_exit(void)
{
- phy_driver_unregister(_driver);
+ phy_drivers_unregister(genphy_driver,
+ ARRAY_SIZE(genphy_driver));
mdio_bus_exit();
}
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 2/2] net: core: explicitly select a txq before doing l2 forwarding
On 01/06/2014 08:42 PM, Neil Horman wrote:
> On Mon, Jan 06, 2014 at 11:21:07AM +0800, Jason Wang wrote:
>> Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit().
>> The
>> will cause several issues:
>>
>> - NETIF_F_LLTX was forced for macvlan device in this case which lead extra
>> lock
>> contention.
>> - dev_hard_start_xmit() was called with NULL txq which bypasses the net
>> device
>> watchdog
>> - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
>> when tso is disabled for lower device.
>>
>> Fix this by explicitly introducing a select queue method just for l2
>> forwarding
>> offload (ndo_dfwd_select_queue), and introducing dfwd_direct_xmit() to do the
>> queue selecting and transmitting for l2 forwarding.
>>
>> With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no
>> need
>> to check txq against NULL in dev_hard_start_xmit().
>>
>> In the future, it was also required for macvtap l2 forwarding support since
>> it
>> provides a necessary synchronization method.
>>
>> Cc: John Fastabend
>> Cc: Neil Horman
>> Cc: e1000-de...@lists.sourceforge.net
>> Signed-off-by: Jason Wang
> Instead of creating another operation here to do special queue selection, why
> not just have ndo_dfwd_start_xmit include a pointer to a pointer in its
> argument
> list, so it can pass the txq it used back to the caller (dev_hard_start_xmit)?
> ndo_dfwd_start_xmit already knows which queue set to pick from (since their
> reserved for the device doing the transmitting). It seems more clear to me
> than
> creating a new netdevice operation.
See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
tx path"). The point is keep the tx path lockless to be efficient and
simplicity for management. And macvtap multiqueue was also implemented
with this assumption. The real contention should be done in the txq of
lower device instead of macvlan itself. This is also needed for
multiqueue macvtap.
>
> As for the crash issue, I'm not sure what you mean. Where in
> dev_hard_start_xmit would we need to check txq that we're not currently, and
> what crash results?
Well, see current dev_hard_start_xmit(), if lower device does not
support tso or tso is disabled, in gso path:
gso:
...
txq_trans_update(txq);
if (unlikely(netif_xmit_stopped(txq) && skb->next))
There's an obvious NULL pointer dereference.
>
> Also, can you elaborate on what you mean by additional lock contention?
If the lower device has NETIF_F_LLTX, then both macvlan txq lock and the
lock of device itself must be held before doing transmission. In the
case, the macvlan txq lock contention is obvious unnecessary.
> What
> contention do you see that goes above and beyond the normal locking required
> by
> txq access?
As I said above, the point is keeping the lockess tx path and make the
contention of txq for real device instead of macvlan itself.
> I suppose its extra locking above and beyond in the macvtap case,
> where you would otherwise never hit hardware, but that not the only use case,
> and I think the solution there is likely to add some code in the macvlan
> feature
> set handler so that NETIF_F_LLTX is cleared if you disable the hardware
> forwarding acceleration via ethtool.
>
> Regards
> Neil
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] [v4] phylib: Add of_phy_attach
From: Andy Fleming
10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Acked-by: Florian Fainelli
---
resend for v4.
drivers/of/of_mdio.c| 19 +++
include/linux/of_mdio.h | 9 +
2 files changed, 28 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..21076ac 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -247,3 +247,22 @@ struct phy_device *of_phy_connect_fixed_link(struct
net_device *dev,
return IS_ERR(phy) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ struct phy_device *phy = of_phy_find_device(phy_np);
+
+ if (!phy)
+ return NULL;
+
+ return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..108583a 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,9 @@ extern struct phy_device *of_phy_connect(struct net_device
*dev,
struct device_node *phy_np,
void (*hndlr)(struct net_device *),
u32 flags, phy_interface_t iface);
+struct phy_device *of_phy_attach(struct net_device *dev,
+struct device_node *phy_np, u32 flags,
+phy_interface_t iface);
extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface);
@@ -44,6 +47,12 @@ static inline struct phy_device *of_phy_connect(struct
net_device *dev,
return NULL;
}
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ return NULL;
+}
+
static inline struct phy_device *of_phy_connect_fixed_link(struct net_device
*dev,
void (*hndlr)(struct
net_device *),
phy_interface_t
iface)
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] [v4] phylib: Add generic 10G driver
From: Andy Fleming
Very incomplete, but will allow for binding an ethernet controller
to it.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
---
resend for v4.
drivers/net/phy/phy_device.c | 80
1 file changed, 80 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 748bf07..439b0d4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,6 +56,7 @@ static void phy_device_release(struct device *dev)
enum genphy_driver {
GENPHY_DRV_1G,
+ GENPHY_DRV_10G,
GENPHY_DRV_MAX
};
@@ -699,6 +701,12 @@ static int genphy_config_advert(struct phy_device *phydev)
return changed;
}
+int gen10g_config_advert(struct phy_device *dev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_config_advert);
+
/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
* @phydev: target phy_device struct
@@ -752,6 +760,11 @@ int genphy_restart_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_restart_aneg);
+int gen10g_restart_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_restart_aneg);
/**
* genphy_config_aneg - restart auto-negotiation or write BMCR
@@ -794,6 +807,12 @@ int genphy_config_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_config_aneg);
+int gen10g_config_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_config_aneg);
+
/**
* genphy_update_link - update link status in @phydev
* @phydev: target phy_device struct
@@ -923,6 +942,34 @@ int genphy_read_status(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_read_status);
+int gen10g_read_status(struct phy_device *phydev)
+{
+ int devad, reg;
+ u32 mmd_mask = phydev->c45_ids.devices_in_package;
+
+ phydev->link = 1;
+
+ /* For now just lie and say it's 10G all the time */
+ phydev->speed = SPEED_1;
+ phydev->duplex = DUPLEX_FULL;
+
+ for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
+ if (!(mmd_mask & 1))
+ continue;
+
+ /* Read twice because link state is latched and a
+* read moves the current state into the register
+*/
+ phy_read_mmd(phydev, devad, MDIO_STAT1);
+ reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
+ if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
+ phydev->link = 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_read_status);
+
static int genphy_config_init(struct phy_device *phydev)
{
int val;
@@ -969,6 +1016,16 @@ static int genphy_config_init(struct phy_device *phydev)
return 0;
}
+
+static int gen10g_config_init(struct phy_device *phydev)
+{
+ /* Temporarily just say we support everything */
+ phydev->supported = SUPPORTED_1baseT_Full;
+ phydev->advertising = SUPPORTED_1baseT_Full;
+
+ return 0;
+}
+
int genphy_suspend(struct phy_device *phydev)
{
int value;
@@ -984,6 +1041,12 @@ int genphy_suspend(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_suspend);
+int gen10g_suspend(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_suspend);
+
int genphy_resume(struct phy_device *phydev)
{
int value;
@@ -999,6 +1062,12 @@ int genphy_resume(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_resume);
+int gen10g_resume(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_resume);
+
/**
* phy_probe - probe and init a PHY device
* @dev: device to probe and init
@@ -1138,6 +1207,17 @@ static struct phy_driver genphy_driver[] = {
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = {.owner= THIS_MODULE, },
+}, {
+ .phy_id = 0x,
+ .phy_id_mask= 0x,
+ .name = "Generic 10G PHY",
+ .config_init= gen10g_config_init,
+ .features = 0,
+ .config_aneg= gen10g_config_aneg,
+ .read_status= gen10g_read_status,
+ .suspend= gen10g_suspend,
+ .resume = gen10g_resume,
+ .driver = {.owner = THIS_MODULE, },
} };
static int __init phy_init(void)
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] [v4] phylib: Support attaching to generic 10g driver
From: Andy Fleming
phy_attach_direct() may now attach to a generic 10G driver. It can
also be used exactly as phy_connect_direct(), which will be useful
when using of_mdio, as phy_connect (and therefore of_phy_connect)
start the PHY state machine, which is currently irrelevant for 10G
PHYs.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Acked-by: Florian Fainelli
---
resend for v4.
drivers/net/phy/phy_device.c | 20
include/linux/phy.h | 2 ++
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 439b0d4..6eab488 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -67,9 +67,6 @@ extern void mdio_bus_exit(void);
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface);
-
/*
* Creates a new phy_fixup and adds it to the list
* @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID)
@@ -527,12 +524,12 @@ int phy_init_hw(struct phy_device *phydev)
*
* Description: Called by drivers to attach to a particular PHY
* device. The phy_device is found, and properly hooked up
- * to the phy_driver. If no driver is attached, then the
- * genphy_driver is used. The phy_device is given a ptr to
+ * to the phy_driver. If no driver is attached, then a
+ * generic driver is used. The phy_device is given a ptr to
* the attaching device, and given a callback for link status
* change. The phy_device is returned to the attaching driver.
*/
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface)
{
struct device *d = >dev;
@@ -541,12 +538,10 @@ static int phy_attach_direct(struct net_device *dev,
struct phy_device *phydev,
/* Assume that if there is no driver, that it doesn't
* exist, and we should use the genphy driver. */
if (NULL == d->driver) {
- if (phydev->is_c45) {
- pr_err("No driver for phy %x\n", phydev->phy_id);
- return -ENODEV;
- }
-
- d->driver = _driver[GENPHY_DRV_1G].driver;
+ if (phydev->is_c45)
+ d->driver = _driver[GENPHY_DRV_10G].driver;
+ else
+ d->driver = _driver[GENPHY_DRV_1G].driver;
err = d->driver->probe(d);
if (err >= 0)
@@ -579,6 +574,7 @@ static int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
return err;
}
+EXPORT_SYMBOL(phy_attach_direct);
/**
* phy_attach - attach a network device to a particular PHY device
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 1d6d1b9..5ccbac1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -581,6 +581,8 @@ int phy_init_hw(struct phy_device *phydev);
struct phy_device * phy_attach(struct net_device *dev,
const char *bus_id, phy_interface_t interface);
struct phy_device *phy_find_first(struct mii_bus *bus);
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+u32 flags, phy_interface_t interface);
int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
void (*handler)(struct net_device *),
phy_interface_t interface);
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] [v4] phylib: introduce PHY_INTERFACE_MODE_XGMII for 10G PHY
From: Andy Fleming
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Acked-by: Florian Fainelli
---
resend for v4.
drivers/of/of_net.c | 1 +
include/linux/phy.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 8f9be2e..a208a45 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -30,6 +30,7 @@ static const char *phy_modes[] = {
[PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
[PHY_INTERFACE_MODE_RTBI] = "rtbi",
[PHY_INTERFACE_MODE_SMII] = "smii",
+ [PHY_INTERFACE_MODE_XGMII] = "xgmii",
};
/**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 0ff2476..1d6d1b9 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -66,6 +66,7 @@ typedef enum {
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
+ PHY_INTERFACE_MODE_XGMII,
} phy_interface_t;
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3.5 10/19] mac8011: slight optimization of addr compare
On 2014/1/6 23:11, Johannes Berg wrote: > On Thu, 2013-12-26 at 19:40 +0800, Ding Tianhong wrote: >> Use the possibly more efficient ether_addr_equal >> to instead of memcmp. > > This is a slow-path, I don't think that's really worth it. It kinda > makes sense, but relies on the struct mac_address allocation for > alignment and the fact that there are no other members in that struct, > so it seems to me that this ought to also add some alignment attributes? > > johannes > > Yes, I had to say that it is really a slight optimization.And I am sure the address in the struct is alignment, otherwise I have to use the ether_addr_equal_unaligned(). Regards Ding > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] [v4] phylib: Add Clause 45 read/write functions
From: Andy Fleming
Need an extra parameter to read or write Clause 45 PHYs, so
need a different API with the extra parameter.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
---
resend for v4.
include/linux/phy.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..0ff2476 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -498,6 +498,24 @@ static inline int phy_read(struct phy_device *phydev, u32
regnum)
}
/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32
regnum)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ return mdiobus_read(phydev->bus, phydev->addr,
+ MII_ADDR_C45 | (devad << 16) | (regnum & 0x));
+}
+
+/**
* phy_write - Convenience function for writing a given PHY register
* @phydev: the phy_device struct
* @regnum: register number to write
@@ -533,6 +551,27 @@ static inline bool phy_is_internal(struct phy_device
*phydev)
return phydev->is_internal;
}
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0x);
+
+ return mdiobus_write(phydev->bus, phydev->addr, regnum, val);
+}
+
struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
bool is_c45, struct phy_c45_device_ids *c45_ids);
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb:hub set hub->change_bits when over-current happens
On Tue, Jan 7, 2014 at 10:40 AM, Greg KH wrote:
> On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote:
>> set hub->change_bits when we plug in a device which causes
>> over-current condition, so that hub_events() will check it.
>
> Why?
>
> What does this solve? Is this a bug with existing devices that needs to
> be backported to older kernels?
>
> thanks,
>
> greg k-h
This is something that we found when we are doing compliance test with xHCI.
If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes
over-current condition to the root port, the hub->change_bits will not
be set in current code in the function of hub_activate.
Then hub_events() will ignore this change, below is a code fragment of
hub_events()
/* deal with port status changes */
for (i = 1; i <= hub->descriptor->bNbrPorts; i++) {
if (test_bit(i, hub->busy_bits))
continue;
connect_change = test_bit(i, hub->change_bits);
wakeup_change = test_and_clear_bit(i, hub->wakeup_bits);
if (!test_and_clear_bit(i, hub->event_bits) &&
!connect_change && !wakeup_change)
continue;
According to spec, software need to disable the port if there is an
over-current condition, while current code will not, since it will not
detect such condition.
but if we disable CONFIG_USB_SUSPEND, software can detect the
over-current condition. I am still checking the code to get the
reason.
--
Shen Guang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tuesday, January 07, 2014 11:45 AM, Tanmay Inamdar wrote: > On Sun, Jan 5, 2014 at 5:47 PM, Jingoo Han wrote: > > On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote: > >> > >> This patch adds the AppliedMicro X-gene SOC PCIe controller driver. > >> APM X-Gene PCIe controller supports maximum upto 8 lanes and > >> GEN3 speed. X-Gene has maximum 5 PCIe ports supported. > > > > (+cc Jason Gunthorpe, Arnd Bergmann) > > > > Hi Tanmay Inamdar, > > > > I added some minor comments. :-) > > > >> > >> Signed-off-by: Tanmay Inamdar > >> --- > >> drivers/pci/host/Kconfig |5 + > >> drivers/pci/host/Makefile |1 + > >> drivers/pci/host/pcie-xgene.c | 1017 > >> + > > > > Would you change the file name to 'pci-xgene.c'? > > Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'. > > I guess designware is an exception. There is > "drivers/pci/host/pcie-designware.c" (+cc Thierry Reding, Pratyush Anand, Mohit KUMAR) Now, the current naming rule is "PCI-" prefix as below. - Samsung Exynos: "pci"-exynos.c - Freescale i.MX6: "pci"-imx6.c - Marvell: pci-mvebu.c - Nvidia Tegra: pci-tegra.c - Renesas R-Car: pci-rcar-gen2.c According to the Thierry Reding's comment, "I think we should keep these sorted alphabetically. Also Tegra and Marvell are PCIe controllers but they still use the pci- prefix instead of pcie-. Perhaps it'd be good to keep consistency here? I initially chose pci- because from a software point of view it doesn't matter all that much whether it's PCI or PCIe and because the drivers are part of the PCI subsystem. However if Exynos now uses the pcie- prefix it makes it look like Tegra and Marvell are plain old PCI." (https://groups.google.com/forum/#!msg/linux.kernel/qtimJoNSc3w/_1aayHaG54YJ) However, "pcie-designware.c" is common layer driver for other SoC PCI host drivers that use Synopsys Designware PCI IP. Thus, currently it is shared by other SoC PCI host drivers such as pci-exynos.c, and pci-imx6.c. Also, ST PCI driver will use pcie-designware.c as common layer. Originally, "pci"-designware.c was used. However, Pratyush Anand suggested "pci"-designware.c can be renamed to "pcie"-designware.c, because Synopsys PCI IP and Synopsys PCI Express IP are different. So, currently "pcie"-designware.c is used. So, if there is no special reason, "pci-" prefix can be used. Thank you. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] tracing/triggers: A couple minor variable name changes
On Mon, 06 Jan 2014 20:51:09 -0600
Tom Zanussi wrote:
> I'll run the next version through my 'testsuite', which unfortunately is
> still manual (one of the many things on my todo list is automate it)..
I have some basic tests, attached is one. Which failed. Here's the
patch that fixes it:
-- Steve
tracing: Fix counter for traceon/off event triggers
The counters for the traceon and traceoff are only suppose to decrement
when the trigger enables or disables tracing. It is not suppose to decrement
every time the event is hit.
Only decrement the counter if the trigger actually did something.
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events_trigger.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index f6dd115..a53e0da 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -742,13 +742,16 @@ traceon_trigger(struct event_trigger_data *data)
static void
traceon_count_trigger(struct event_trigger_data *data)
{
+ if (tracing_is_on())
+ return;
+
if (!data->count)
return;
if (data->count != -1)
(data->count)--;
- traceon_trigger(data);
+ tracing_on();
}
static void
@@ -763,13 +766,16 @@ traceoff_trigger(struct event_trigger_data *data)
static void
traceoff_count_trigger(struct event_trigger_data *data)
{
+ if (!tracing_is_on())
+ return;
+
if (!data->count)
return;
if (data->count != -1)
(data->count)--;
- traceoff_trigger(data);
+ tracing_off();
}
static int
--
1.8.1.4
ftrace-test-event-traceon-off
Description: Binary data
Re: [PATCH v5 4/4] futex: Avoid taking hb lock if nothing to wakeup
On Mon, 2014-01-06 at 12:52 -0800, Darren Hart wrote: > On Thu, 2014-01-02 at 07:05 -0800, Davidlohr Bueso wrote: > > From: Davidlohr Bueso > > > > In futex_wake() there is clearly no point in taking the hb->lock if we know > > beforehand that there are no tasks to be woken. While the hash bucket's > > plist > > head is a cheap way of knowing this, we cannot rely 100% on it as there is a > > racy window between the futex_wait call and when the task is actually added > > to > > the plist. To this end, we couple it with the spinlock check as tasks > > trying to > > enter the critical region are most likely potential waiters that will be > > added > > to the plist, thus preventing tasks sleeping forever if wakers don't > > acknowledge > > all possible waiters. > > > > Furthermore, the futex ordering guarantees are preserved, ensuring that > > waiters > > either observe the changed user space value before blocking or is woken by a > > concurrent waker. For wakers, this is done by relying on the barriers in > > get_futex_key_refs() -- for archs that do have implicit mb in atomic_inc() > > we > > do NOT have implicit mb in atomic_inc() >^ oh, yes! > > Sorry to be a pedant, but this is gnarly stuff and we have to get the > documentation right. > Absolutely! > > explicitly add them through a new futex_get_mm function. For waiters we rely > > on the fact that spin_lock calls already update the head counter, so > > spinners > > are visible even if the lock hasn't been acquired yet. > > > > For more details please refer to the updated comments in the code and > > related > > discussion: https://lkml.org/lkml/2013/11/26/556 > > > > Special thanks to tglx for careful review and feedback. > > > > Cc: Ingo Molnar > > Cc: Darren Hart > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Paul E. McKenney > > Cc: Mike Galbraith > > Cc: Jeff Mahoney > > Suggested-by: Linus Torvalds > > Cc: Scott Norton > > Cc: Tom Vaden > > Cc: Aswin Chandramouleeswaran > > Cc: Waiman Long > > Cc: Jason Low > > Signed-off-by: Davidlohr Bueso > > --- > > kernel/futex.c | 113 > > + > > 1 file changed, 90 insertions(+), 23 deletions(-) > > > > diff --git a/kernel/futex.c b/kernel/futex.c > > index fcc6850..5b4d09e 100644 > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -75,17 +75,20 @@ > > * The waiter reads the futex value in user space and calls > > * futex_wait(). This function computes the hash bucket and acquires > > * the hash bucket lock. After that it reads the futex user space value > > - * again and verifies that the data has not changed. If it has not > > - * changed it enqueues itself into the hash bucket, releases the hash > > - * bucket lock and schedules. > > + * again and verifies that the data has not changed. If it has not changed > > + * it enqueues itself into the hash bucket, releases the hash bucket lock > > + * and schedules. > > * > > * The waker side modifies the user space value of the futex and calls > > - * futex_wake(). This functions computes the hash bucket and acquires > > - * the hash bucket lock. Then it looks for waiters on that futex in the > > - * hash bucket and wakes them. > > + * futex_wake(). This function computes the hash bucket and acquires the > > + * hash bucket lock. Then it looks for waiters on that futex in the hash > > + * bucket and wakes them. > > * > > - * Note that the spin_lock serializes waiters and wakers, so that the > > - * following scenario is avoided: > > + * In scenarios where wakeups are called and no tasks are blocked on a > > futex, > > > "wakeups are called" reads awkwardly to me. Perhaps: > > "In futex wake up scenarios where no tasks are blocked on the > futex, ..." > I have no particular preference, so I'll update it. > > > + * taking the hb spinlock can be avoided and simply return. In order for > > this > > + * optimization to work, ordering guarantees must exist so that the waiter > > + * being added to the list is acknowledged when the list is concurrently > > being > > + * checked by the waker, avoiding scenarios like the following: > > * > > * CPU 0 CPU 1 > > * val = *futex; > > @@ -106,24 +109,50 @@ > > * This would cause the waiter on CPU 0 to wait forever because it > > * missed the transition of the user space value from val to newval > > * and the waker did not find the waiter in the hash bucket queue. > > - * The spinlock serializes that: > > + * > > + * The correct serialization ensures that a waiter either observes > > + * the changed user space value before blocking or is woken by a > > + * concurrent waker: > > * > > * CPU 0 CPU 1 > > * val = *futex; > > * sys_futex(WAIT, futex, val); > > * futex_wait(futex, val); > > - * lock(hash_bucket(futex)); > > - * uval = *futex; > > - * *futex = newval; > > - *
Re: linux-next: build failure after merge of the mmc tree
Hi Shawn,
On Mon, 6 Jan 2014 14:44:08 +0800 Shawn Guo wrote:
>
> Okay, I missed your point. The resolution needs the additional changes
> as below.
Thanks, I applied the following as a merge fix patch today and will carry
it as necessary.
From: Stephen Rothwell
Date: Tue, 7 Jan 2014 14:20:53 +1100
Subject: [PATCH] mmc: merge fixup for imx6qdl-sabresd.dtsi
Signed-off-by: Stephen Rothwell
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 0eab66ea2009..0eb5704f2850 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -356,6 +356,10 @@
pinctrl_usdhc3: usdhc3grp {
fsl,pins = ;
};
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = ;
+ };
};
};
@@ -438,7 +438,7 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_usdhc4_1>;
+ pinctrl-0 = <_usdhc4>;
bus-width = <8>;
non-removable;
no-1-8-v;
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpCLHhP4vObh.pgp
Description: PGP signature
Re: [PATCH 0/2] tracing/triggers: A couple minor variable name changes
On Mon, 06 Jan 2014 20:51:09 -0600
Tom Zanussi wrote:
> > Hmm, OK, I think you may have convinced me. I'll swap the return values.
> >
>
> Sounds great, thanks!
New patch.
-- Steve
tracing: Consolidate event trigger code
The event trigger code that checks for callback triggers before and
after recording of an event has lots of flags checks. This code is
duplicated throughout the ftrace events, kprobes and system calls.
They all do the exact same checks against the event flags.
Added helper functions ftrace_trigger_soft_disabled(),
event_trigger_unlock_commit() and event_trigger_unlock_commit_regs()
that consolidated the code and these are used instead.
Signed-off-by: Steven Rostedt
---
include/linux/ftrace_event.h | 117 ++
include/trace/ftrace.h| 23 ++---
kernel/trace/trace_kprobe.c | 48 +++--
kernel/trace/trace_syscalls.c | 48 +++--
4 files changed, 137 insertions(+), 99 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 03d2db2..4e4cc28 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -370,6 +370,123 @@ extern enum event_trigger_type event_triggers_call(struct
ftrace_event_file *fil
extern void event_triggers_post_call(struct ftrace_event_file *file,
enum event_trigger_type tt);
+/**
+ * ftrace_trigger_soft_disabled - do triggers and test if soft disabled
+ * @file: The file pointer of the event to test
+ *
+ * If any triggers without filters are attached to this event, they
+ * will be called here. If the event is soft disabled and has no
+ * triggers that require testing the fields, it will return true,
+ * otherwise false.
+ */
+static inline bool
+ftrace_trigger_soft_disabled(struct ftrace_event_file *file)
+{
+ unsigned long eflags = file->flags;
+
+ if (!(eflags & FTRACE_EVENT_FL_TRIGGER_COND)) {
+ if (eflags & FTRACE_EVENT_FL_TRIGGER_MODE)
+ event_triggers_call(file, NULL);
+ if (eflags & FTRACE_EVENT_FL_SOFT_DISABLED)
+ return true;
+ }
+ return false;
+}
+
+/*
+ * Helper function for event_trigger_unlock_commit{_regs}().
+ * If there are event triggers attached to this event that requires
+ * filtering against its fields, then they wil be called as the
+ * entry already holds the field information of the current event.
+ *
+ * It also checks if the event should be discarded or not.
+ * It is to be discarded if the event is soft disabled and the
+ * event was only recorded to process triggers, or if the event
+ * filter is active and this event did not match the filters.
+ *
+ * Returns true if the event is discarded, false otherwise.
+ */
+static inline bool
+__event_trigger_test_discard(struct ftrace_event_file *file,
+struct ring_buffer *buffer,
+struct ring_buffer_event *event,
+void *entry,
+enum event_trigger_type *tt)
+{
+ unsigned long eflags = file->flags;
+
+ if (eflags & FTRACE_EVENT_FL_TRIGGER_COND)
+ *tt = event_triggers_call(file, entry);
+
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, >flags))
+ ring_buffer_discard_commit(buffer, event);
+ else if (!filter_check_discard(file, entry, buffer, event))
+ return false;
+
+ return true;
+}
+
+/**
+ * event_trigger_unlock_commit - handle triggers and finish event commit
+ * @file: The file pointer assoctiated to the event
+ * @buffer: The ring buffer that the event is being written to
+ * @event: The event meta data in the ring buffer
+ * @entry: The event itself
+ * @irq_flags: The state of the interrupts at the start of the event
+ * @pc: The state of the preempt count at the start of the event.
+ *
+ * This is a helper function to handle triggers that require data
+ * from the event itself. It also tests the event against filters and
+ * if the event is soft disabled and should be discarded.
+ */
+static inline void
+event_trigger_unlock_commit(struct ftrace_event_file *file,
+ struct ring_buffer *buffer,
+ struct ring_buffer_event *event,
+ void *entry, unsigned long irq_flags, int pc)
+{
+ enum event_trigger_type tt = ETT_NONE;
+
+ if (!__event_trigger_test_discard(file, buffer, event, entry, ))
+ trace_buffer_unlock_commit(buffer, event, irq_flags, pc);
+
+ if (tt)
+ event_triggers_post_call(file, tt);
+}
+
+/**
+ * event_trigger_unlock_commit_regs - handle triggers and finish event commit
+ * @file: The file pointer assoctiated to the event
+ * @buffer: The ring buffer that the event is being written to
+ * @event: The event meta data in the ring buffer
+ * @entry: The event itself
+ * @irq_flags: The state of the
Re: [PATCH 5/5] tools lib traceevent: Get rid of die() finally!!
On Tue, 7 Jan 2014 12:00:12 +0900 Namhyung Kim wrote: > Now all of its users were gone. :) > Die die! ;-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] r8152: correct some messages
- Replace pr_warn_ratelimited() with net_ratelimit() and netdev_warn().
- Adjust the algnment of some messages.
- Remove the peroid.
- Fix some messages don't have terminating newline.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5107372..49632ff 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -814,10 +814,12 @@ static void read_bulk_callback(struct urb *urb)
case -ENOENT:
return; /* the urb is in unlink state */
case -ETIME:
- pr_warn_ratelimited("may be reset is needed?..\n");
+ if (net_ratelimit())
+ netdev_warn(netdev, "maybe reset is needed?\n");
break;
default:
- pr_warn_ratelimited("Rx status %d\n", status);
+ if (net_ratelimit())
+ netdev_warn(netdev, "Rx status %d\n", status);
break;
}
@@ -850,7 +852,8 @@ static void write_bulk_callback(struct urb *urb)
stats = rtl8152_get_stats(tp->netdev);
if (status) {
- pr_warn_ratelimited("Tx status %d\n", status);
+ if (net_ratelimit())
+ netdev_warn(tp->netdev, "Tx status %d\n", status);
stats->tx_errors += agg->skb_num;
} else {
stats->tx_packets += agg->skb_num;
@@ -927,7 +930,7 @@ resubmit:
netif_device_detach(tp->netdev);
else if (res)
netif_err(tp, intr, tp->netdev,
- "can't resubmit intr, status %d\n", res);
+ "can't resubmit intr, status %d\n", res);
}
static inline void *rx_agg_align(void *data)
@@ -1336,7 +1339,7 @@ static void rtl8152_tx_timeout(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int i;
- netif_warn(tp, tx_err, netdev, "Tx timeout.\n");
+ netif_warn(tp, tx_err, netdev, "Tx timeout\n");
for (i = 0; i < RTL8152_MAX_TX; i++)
usb_unlink_urb(tp->tx_info[i].urb);
}
@@ -1806,8 +1809,8 @@ static int rtl8152_open(struct net_device *netdev)
if (res) {
if (res == -ENODEV)
netif_device_detach(tp->netdev);
- netif_warn(tp, ifup, netdev,
- "intr_urb submit failed: %d\n", res);
+ netif_warn(tp, ifup, netdev, "intr_urb submit failed: %d\n",
+ res);
return res;
}
@@ -2094,7 +2097,7 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev = alloc_etherdev(sizeof(struct r8152));
if (!netdev) {
- dev_err(>dev, "Out of memory");
+ dev_err(>dev, "Out of memory\n");
return -ENOMEM;
}
@@ -2135,11 +2138,11 @@ static int rtl8152_probe(struct usb_interface *intf,
ret = register_netdev(netdev);
if (ret != 0) {
- netif_err(tp, probe, netdev, "couldn't register the device");
+ netif_err(tp, probe, netdev, "couldn't register the device\n");
goto out1;
}
- netif_info(tp, probe, netdev, "%s", DRIVER_VERSION);
+ netif_info(tp, probe, netdev, "%s\n", DRIVER_VERSION);
return 0;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On 01/07/2014 04:47 AM, David Miller wrote: > From: Jason Wang > Date: Mon, 6 Jan 2014 11:21:06 +0800 > >> L2 fowarding offload will bypass the rx handler of real device. This will >> make >> the packet could not be forwarded to macvtap device. Another problem is the >> dev_hard_start_xmit() called for macvtap does not have any synchronization. >> >> Fix this by forbidding L2 forwarding for macvtap. >> >> Cc: John Fastabend >> Cc: Neil Horman >> Signed-off-by: Jason Wang > I think I agree with Neil that the rx_handler change might be the best > way to fix this. That change seems to have a lot of nice unintended > side effects, no? Not all sides effects are nice. One obvious issue is it disables the multiqueue macvtap transmission, since all queues will contend on a single qdisc lock of macvlan. And even more, multiqueue macvtap support creating and destroying a queue on demand which is not supported by L2 forwarding offload. So L2 forwarding offload needs more fixes to let the multiqueue macvtap works. Currently, we really need this patch to make sure macvtap works as expected. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On 01/06/2014 08:26 PM, Neil Horman wrote:
> On Mon, Jan 06, 2014 at 03:54:21PM +0800, Jason Wang wrote:
>> On 01/06/2014 03:35 PM, John Fastabend wrote:
>>> On 01/05/2014 07:21 PM, Jason Wang wrote:
L2 fowarding offload will bypass the rx handler of real device. This
will make
the packet could not be forwarded to macvtap device. Another problem
is the
dev_hard_start_xmit() called for macvtap does not have any
synchronization.
Fix this by forbidding L2 forwarding for macvtap.
Cc: John Fastabend
Cc: Neil Horman
Signed-off-by: Jason Wang
---
drivers/net/macvlan.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
>>> I must be missing something.
>>>
>>> The lower layer device should set skb->dev to the correct macvtap
>>> device on receive so that in netif_receive_skb_core() the macvtap
>>> handler is hit. Skipping the macvlan receive handler should be OK
>>> because the switching was done by the hardware. If I read macvtap.c
>>> correctly macvlan_common_newlink() is called with 'dev' where 'dev'
>>> is the macvtap device. Any idea what I'm missing? I guess I'll need
>>> to setup a macvtap test case.
>> Unlike macvlan, macvtap depends on rx handler on the lower device to
>> work. In this case macvlan_handle_frame() will call macvtap_receive().
>> So doing netif_receive_skb_core() for macvtap device directly won't work
>> since we need to forward the packet to userspace instead of kernel.
>>
>> For net-next.git, it may work since commit
>> 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 let macvtap device register an
>> rx handler for itself.
> I agree, this seems like it should already be fixed with the above commit.
> With
> this the macvlan rx handler should effectively be a no-op as far as the
> reception of frames is concerned. As long as the driver sets the dev
> correctly
> to the macvtap device (and it appears to), macvtap will get frames to user
> space, regardless of weather the software or hardware did the switching. If
> thats the case though, I think the solution is moving that fix to -stable
> (pending testing of course), rather than comming up with a new fix.
>
>>> And what synchronization are you worried about on dev_hard_start_xmit()?
>>> In the L2 forwarding offload case macvlan_open() clears the NETIF_F_LLTX
>>> flag so HARD_TX_LOCK protects the driver txq. We might hit this warning
>>> in dev_queue_xmit() though,
>>>
>>> net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
>>>
>>> Perhaps we can remove it.
>> The problem is macvtap does not call dev_queue_xmit() for macvlan
>> device. It calls macvlan_start_xmit() directly from macvtap_get_user().
>> So HARD_TX_LOCK was not done for the txq.
> This seems to also be fixed by 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
> Macvtap does, as of that commit use dev_queue_xmit for the transmission of
> frames to the lowerdevice.
Unfortunately not. This commit has a side effect that it in fact
disables the multiqueue macvtap transmission. Since all macvtap queues
will contend on a single qdisc lock.
For L2 forwarding offload itself, more issues need to be addressed for
multiqueue macvtap:
- ndo_dfwd_add_station() can only create queues per device at ndo_open,
but multiqueue macvtap allows user to create and destroy queues at their
will and at any time.
- it looks that ixgbe has a upper limit of 4 queues per station, but
macvtap currently allows up to 16 queues per device.
So more works need to be done and unless those above 3 issues were
addressed, this patch is really needed to make sure macvtap works.
>
> Regards
> Neil
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Input: add i2c/smbus driver for elan touchpad
This driver adds support for elan i2c/smbus touchpad found on some laptops PC Signed-off-by: Duson Lin --- drivers/input/mouse/Kconfig| 10 + drivers/input/mouse/Makefile |1 + drivers/input/mouse/elan_i2c.c | 890 3 files changed, 901 insertions(+) create mode 100644 drivers/input/mouse/elan_i2c.c diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig index effa9c5..095eccc 100644 --- a/drivers/input/mouse/Kconfig +++ b/drivers/input/mouse/Kconfig @@ -215,6 +215,16 @@ config MOUSE_CYAPA To compile this driver as a module, choose M here: the module will be called cyapa. +config MOUSE_ELAN_I2C + tristate "ELAN I2C Touchpad support" + depends on I2C + help + This driver adds support for Elan I2C Trackpads. + Say Y here if you have a ELAN I2C Touchpad. + + To compile this driver as a module, choose M here: the module will be + called elan_i2c. + config MOUSE_INPORT tristate "InPort/MS/ATIXL busmouse" depends on ISA diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile index c25efdb..24a12a6 100644 --- a/drivers/input/mouse/Makefile +++ b/drivers/input/mouse/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o obj-$(CONFIG_MOUSE_ATARI) += atarimouse.o obj-$(CONFIG_MOUSE_BCM5974)+= bcm5974.o obj-$(CONFIG_MOUSE_CYAPA) += cyapa.o +obj-$(CONFIG_MOUSE_ELAN_I2C) += elan_i2c.o obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o obj-$(CONFIG_MOUSE_INPORT) += inport.o obj-$(CONFIG_MOUSE_LOGIBM) += logibm.o diff --git a/drivers/input/mouse/elan_i2c.c b/drivers/input/mouse/elan_i2c.c new file mode 100644 index 000..f7bfa22 --- /dev/null +++ b/drivers/input/mouse/elan_i2c.c @@ -0,0 +1,890 @@ +/* + * Elan I2C/SMBus Touchpad driver + * + * Copyright (c) 2013 ELAN Microelectronics Corp. + * + * Author: 林政維 (Duson Lin) + * Version: 1.4.6 + * + * Based on cyapa driver: + * copyright (c) 2011-2012 Cypress Semiconductor, Inc. + * copyright (c) 2011-2012 Google, Inc. + * + * 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. + * + * Trademarks are the property of their respective owners. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"elan_i2c" +#define ELAN_DRIVER_VERSION"1.4.6" +#define ETP_PRESSURE_OFFSET25 +#define ETP_MAX_PRESSURE 255 +#define ETP_FWIDTH_REDUCE 90 +#define ETP_FINGER_WIDTH 15 + +#define ELAN_ADAPTER_FUNC_NONE 0 +#define ELAN_ADAPTER_FUNC_I2C1 +#define ELAN_ADAPTER_FUNC_SMBUS 2 +#define ELAN_ADAPTER_FUNC_BOTH 3 + +/* Length of Elan touchpad information */ +#define ETP_INF_LENGTH 2 +#define ETP_MAX_FINGERS5 +#define ETP_FINGER_DATA_LEN5 +#define ETP_REPORT_ID 0x5D +#define ETP_MAX_REPORT_LEN 34 +#define ETP_ENABLE_ABS 0x0001 +#define ETP_ENABLE_CALIBRATE 0x0002 +#define ETP_DISABLE_CALIBRATE 0x + +/* Elan smbus command */ +#define ETP_SMBUS_IAP_CMD 0x00 +#define ETP_SMBUS_ENABLE_TP0x20 +#define ETP_SMBUS_SLEEP_CMD0x21 +#define ETP_SMBUS_IAP_PASSWORD_WRITE 0x29 +#define ETP_SMBUS_IAP_PASSWORD_READ0x80 +#define ETP_SMBUS_WRITE_FW_BLOCK 0x2A +#define ETP_SMBUS_IAP_RESET_CMD0x2B +#define ETP_SMBUS_RANGE_CMD0xA0 +#define ETP_SMBUS_FW_VERSION_CMD 0xA1 +#define ETP_SMBUS_XY_TRACENUM_CMD 0xA2 +#define ETP_SMBUS_SM_VERSION_CMD 0xA3 +#define ETP_SMBUS_UNIQUEID_CMD 0xA3 +#define ETP_SMBUS_RESOLUTION_CMD 0xA4 +#define ETP_SMBUS_HELLOPACKET_CMD 0xA7 +#define ETP_SMBUS_PACKET_QUERY 0xA8 +#define ETP_SMBUS_IAP_VERSION_CMD 0xAC +#define ETP_SMBUS_IAP_CTRL_CMD 0xAD +#define ETP_SMBUS_IAP_CHECKSUM_CMD 0xAE +#define ETP_SMBUS_FW_CHECKSUM_CMD 0xAF +#define ETP_SMBUS_MAX_BASELINE_CMD 0xC3 +#define ETP_SMBUS_MIN_BASELINE_CMD 0xC4 +#define ETP_SMBUS_CALIBRATE_QUERY 0xC5 +#define ETP_SMBUS_REPORT_LEN 32 +#define ETP_SMBUS_FINGER_DATA_OFFSET 2 +#define ETP_SMBUS_HELLOPACKET_LEN 5 +#define ETP_SMBUS_IAP_PASSWORD 0x1234 +#define ETP_SMBUS_IAP_MODE_ON (1<<6) + +/* Elan i2c command */ +#define ETP_I2C_RESET 0x0100 +#define ETP_I2C_WAKE_UP0x0800 +#define ETP_I2C_SLEEP 0x0801 +#define ETP_I2C_DESC_CMD 0x0001 +#define ETP_I2C_REPORT_DESC_CMD0x0002 +#define ETP_I2C_STAND_CMD 0x0005 +#define ETP_I2C_UNIQUEID_CMD 0x0101 +#define ETP_I2C_FW_VERSION_CMD
Re: [RFC PATCH 3/3] dt-bindings: pci: xgene pcie device tree bindings
On Fri, Jan 3, 2014 at 1:49 AM, Arnd Bergmann wrote:
> On Monday 23 December 2013, Tanmay Inamdar wrote:
>> This patch adds the bindings for X-Gene PCIe driver. The driver resides
>> under 'drivers/pci/host/pcie-xgene.c' file.
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> .../devicetree/bindings/pci/xgene-pcie.txt | 43
>>
>> 1 file changed, 43 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/xgene-pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/xgene-pcie.txt
>> b/Documentation/devicetree/bindings/pci/xgene-pcie.txt
>> new file mode 100644
>> index 000..d92da4f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/xgene-pcie.txt
>> @@ -0,0 +1,43 @@
>> +* AppliedMicro X-Gene PCIe interface
>> +
>> +Required properties:
>> +- status: Either "ok" or "disabled".
>> +- device_type: set to "pci"
>> +- compatible: should contain "xgene,pcie" to identify the core.
>> +- reg: base addresses and lengths of the pcie controller configuration
>> + space register.
>> +- #address-cells: set to <3>
>> +- #size-cells: set to <2>
>> +- ranges: ranges for the PCI memory, I/O regions, config and MSI regions
>> +- #interrupt-cells: set to <1>
>> +- interrupt-map-mask and interrupt-map: standard PCI properties
>> + to define the mapping of the PCIe interface to interrupt
>> + numbers.
>> +- clocks: from common clock binding: handle to pci clock.
>> +- clock-names: from common clock binding. Should be "pcieclk".
>> +
>
> Better use an anonymous clock?
Sorry. Can you please elaborate?
>
> The driver also seems to use a phy that is not defined here.
>
>> +Example:
>> +
>> +SoC specific DT Entry:
>> + pcie0: pcie@1f2b {
>> + status = "disabled";
>> + device_type = "pci";
>> + compatible = "xgene,pcie";
>> + #interrupt-cells = <1>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + reg = < 0x00 0x1f2b 0x0 0x0001>;
>> + ranges = <0x0200 0x0 0x 0xe0 0x 0x0
>> 0x1000 /* mem*/
>
> This is an awfully small memory space for a 64 bit machine. Is that a
> hardware bug you
> are working around? If not, please make it as large as you can to allow for
> arbitrary
> extension cards with large BARs, at least 4GB.
HW does support a lot more than 256MB. I will change it.
>
> Also, do you support no prefetchable memory?
HW has either IO or Memory regions for mapping device's memory space.
There is no separate prefetchable memory space.
>
>> + 0x0100 0x0 0x8000 0xe0 0x8000 0x0
>> 0x0001 /* io */
>
> I/O space at 0x8000? That won't work with a lot of devices. Can you make
> it start
> at bus address 0?
Ok.
>
>> + 0x 0x0 0xd000 0xe0 0xd000 0x0
>> 0x0020 /* cfg */
>
> config space is not normally in the ranges property, and I think you will need
> it in the pcie node itself as a 'reg' property so the code can access it.
pcie-designware.c does it that way. I just followed their implementation.
>
>> + 0x 0x0 0x7900 0x00 0x7900 0x0
>> 0x0080>; /* msi */
>
> Same here. Also I suspect this is a separate irqchip that isn't actually part
> of the PCIe host. If they are separate devices, I'd strongly recommend
> modeling
> them as separate device-nodes in DT to make reuse easier.
You are right. However MSI irqchip needs PCIe core to map above
mentioned space. I will remove it for now and will send it along with
MSI patch.
>
>> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
>> + interrupt-map = <0x0 0x0 0x0 0x1 0x0 0xc2 0x1>;
>
> Only one IRQ for all devices?
The node represents a port. I believe that Linux framework uses only
one of the legacy IRQs per port. Rest all remain unused. Hence I
removed them. Please correct me if I am wrong.
>
>> + clocks = < 0>;
>> + clock-names = "pcieclk"
>> + };
>> +
>> +Board specific DT Entry:
>> + {
>> + status = "ok";
>> + };
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/4] futex: silence uninitialized warnings
On Tue, 2014-01-07 at 10:55 +0800, Linus Torvalds wrote:
> On Mon, Jan 6, 2014 at 9:38 AM, Davidlohr Bueso wrote:
> > {
> > int lock_taken, ret, force_take = 0;
> > - u32 uval, newval, curval, vpid = task_pid_vnr(task);
> > + u32 uval, newval, uninitialized_var(curval), vpid =
> > task_pid_vnr(task);
>
> Do you have some broken compiler?
I only notice this when testing this patchset on our servers with RHEL
6.4 (gcc 4.4.7 20120313 (Red Hat 4.4.7-3)).
> I really tend to hate this kind of
> workarounds, because as mentioned, they can actually hide valid
> warnings, and it seems to be due to just stupid compilers. Are we
> perhaps better off trying to get people off the broken compiler
> versions instead?
As Darren points out, this path is unlikely to change, but I have no
particular preference otherwise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] tools lib traceevent: Add WARN and WARN_ONCE macros
They're copied from the perf code and will be used to print error
message during trace_seq_printf() and friends.
Suggested-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-utils.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tools/lib/traceevent/event-utils.h
b/tools/lib/traceevent/event-utils.h
index e76c9acb92cd..5dc0aec5ab50 100644
--- a/tools/lib/traceevent/event-utils.h
+++ b/tools/lib/traceevent/event-utils.h
@@ -38,6 +38,28 @@ void __vdie(const char *fmt, ...);
void __vwarning(const char *fmt, ...);
void __vpr_stat(const char *fmt, ...);
+#define likely(x) __builtin_expect(!!(x), 1)
+#define unlikely(x)__builtin_expect(!!(x), 0)
+
+#define __WARN_printf(arg...) do { fprintf(stderr, arg); } while (0)
+
+#define WARN(condition, format...) ({ \
+ int __ret_warn_on = !!(condition); \
+ if (unlikely(__ret_warn_on))\
+ __WARN_printf(format); \
+ unlikely(__ret_warn_on);\
+})
+
+#define WARN_ONCE(condition, format...)({ \
+ static int __warned;\
+ int __ret_warn_once = !!(condition);\
+ \
+ if (unlikely(__ret_warn_once)) \
+ if (WARN(!__warned, format))\
+ __warned = 1; \
+ unlikely(__ret_warn_once); \
+})
+
#define min(x, y) ({ \
typeof(x) _min1 = (x); \
typeof(y) _min2 = (y); \
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] tools lib traceevent: Get rid of die() finally!!
Now all of its users were gone. :)
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-utils.h | 4
tools/lib/traceevent/parse-utils.c | 44 --
2 files changed, 48 deletions(-)
diff --git a/tools/lib/traceevent/event-utils.h
b/tools/lib/traceevent/event-utils.h
index 5dc0aec5ab50..496dba9fe984 100644
--- a/tools/lib/traceevent/event-utils.h
+++ b/tools/lib/traceevent/event-utils.h
@@ -23,18 +23,14 @@
#include
/* Can be overridden */
-void die(const char *fmt, ...);
-void *malloc_or_die(unsigned int size);
void warning(const char *fmt, ...);
void pr_stat(const char *fmt, ...);
void vpr_stat(const char *fmt, va_list ap);
/* Always available */
-void __die(const char *fmt, ...);
void __warning(const char *fmt, ...);
void __pr_stat(const char *fmt, ...);
-void __vdie(const char *fmt, ...);
void __vwarning(const char *fmt, ...);
void __vpr_stat(const char *fmt, ...);
diff --git a/tools/lib/traceevent/parse-utils.c
b/tools/lib/traceevent/parse-utils.c
index bba701cf10e6..eda07fa31dca 100644
--- a/tools/lib/traceevent/parse-utils.c
+++ b/tools/lib/traceevent/parse-utils.c
@@ -25,40 +25,6 @@
#define __weak __attribute__((weak))
-void __vdie(const char *fmt, va_list ap)
-{
- int ret = errno;
-
- if (errno)
- perror("trace-cmd");
- else
- ret = -1;
-
- fprintf(stderr, " ");
- vfprintf(stderr, fmt, ap);
-
- fprintf(stderr, "\n");
- exit(ret);
-}
-
-void __die(const char *fmt, ...)
-{
- va_list ap;
-
- va_start(ap, fmt);
- __vdie(fmt, ap);
- va_end(ap);
-}
-
-void __weak die(const char *fmt, ...)
-{
- va_list ap;
-
- va_start(ap, fmt);
- __vdie(fmt, ap);
- va_end(ap);
-}
-
void __vwarning(const char *fmt, va_list ap)
{
if (errno)
@@ -117,13 +83,3 @@ void __weak pr_stat(const char *fmt, ...)
__vpr_stat(fmt, ap);
va_end(ap);
}
-
-void __weak *malloc_or_die(unsigned int size)
-{
- void *data;
-
- data = malloc(size);
- if (!data)
- die("malloc");
- return data;
-}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 0/5] tools lib traceevent: Get rid of *die() calls finally!! (v2)
Hello, I've added WARN_ONCE in TRACE_SEQ_CHECK() as Jiri said. Other patches are same as the privous version. You can also get this on my 'libtraceevent/die-removal-v5' branch in my tree git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (5): tools lib traceevent: Add WARN and WARN_ONCE macros tools lib traceevent: Add state member to struct trace_seq tools lib traceevent: Check return value of realloc() tools lib traceevent: Get rid of malloc_or_die() in trace_seq_init() tools lib traceevent: Get rid of die() finally!! tools/lib/traceevent/event-parse.h | 7 + tools/lib/traceevent/event-utils.h | 26 ++--- tools/lib/traceevent/parse-utils.c | 44 - tools/lib/traceevent/trace-seq.c | 57 +- 4 files changed, 79 insertions(+), 55 deletions(-) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] tools lib traceevent: Get rid of malloc_or_die() in trace_seq_init()
Use plain malloc() and check its return value. Signed-off-by: Namhyung Kim --- tools/lib/traceevent/trace-seq.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/lib/traceevent/trace-seq.c b/tools/lib/traceevent/trace-seq.c index b139d55a6bf9..e858bfd3b104 100644 --- a/tools/lib/traceevent/trace-seq.c +++ b/tools/lib/traceevent/trace-seq.c @@ -46,8 +46,11 @@ void trace_seq_init(struct trace_seq *s) s->len = 0; s->readpos = 0; s->buffer_size = TRACE_SEQ_BUF_SIZE; - s->buffer = malloc_or_die(s->buffer_size); - s->state = TRACE_SEQ__GOOD; + s->buffer = malloc(s->buffer_size); + if (s->buffer != NULL) + s->state = TRACE_SEQ__GOOD; + else + s->state = TRACE_SEQ__MEM_ALLOC_FAILED; } /** -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] tools lib traceevent: Check return value of realloc()
If realloc() fails, it'll leak the buffer. Also increate buffer size
only if the allocation succeeded.
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/trace-seq.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/lib/traceevent/trace-seq.c b/tools/lib/traceevent/trace-seq.c
index 1747aa50ecb0..b139d55a6bf9 100644
--- a/tools/lib/traceevent/trace-seq.c
+++ b/tools/lib/traceevent/trace-seq.c
@@ -80,10 +80,16 @@ void trace_seq_destroy(struct trace_seq *s)
static void expand_buffer(struct trace_seq *s)
{
- s->buffer_size += TRACE_SEQ_BUF_SIZE;
- s->buffer = realloc(s->buffer, s->buffer_size);
- if (!s->buffer)
+ char *buf;
+
+ buf = realloc(s->buffer, s->buffer_size + TRACE_SEQ_BUF_SIZE);
+ if (!buf) {
s->state = TRACE_SEQ__MEM_ALLOC_FAILED;
+ return;
+ }
+
+ s->buffer = buf;
+ s->buffer_size += TRACE_SEQ_BUF_SIZE;
}
/**
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] tools lib traceevent: Add state member to struct trace_seq
The trace_seq->state is for tracking errors during the use of
trace_seq APIs and getting rid of die() in it.
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-parse.h | 7 +++
tools/lib/traceevent/trace-seq.c | 42 ++
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index cf5db9013f2c..3c890cb28db7 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -58,6 +58,12 @@ struct pevent_record {
#endif
};
+enum trace_seq_fail {
+ TRACE_SEQ__GOOD,
+ TRACE_SEQ__BUFFER_POISONED,
+ TRACE_SEQ__MEM_ALLOC_FAILED,
+};
+
/*
* Trace sequences are used to allow a function to call several other functions
* to create a string of data to use (up to a max of PAGE_SIZE).
@@ -68,6 +74,7 @@ struct trace_seq {
unsigned intbuffer_size;
unsigned intlen;
unsigned intreadpos;
+ enum trace_seq_fail state;
};
void trace_seq_init(struct trace_seq *s);
diff --git a/tools/lib/traceevent/trace-seq.c b/tools/lib/traceevent/trace-seq.c
index d7f2e68bc5b9..1747aa50ecb0 100644
--- a/tools/lib/traceevent/trace-seq.c
+++ b/tools/lib/traceevent/trace-seq.c
@@ -32,8 +32,9 @@
#define TRACE_SEQ_POISON ((void *)0xdeadbeef)
#define TRACE_SEQ_CHECK(s) \
do { \
- if ((s)->buffer == TRACE_SEQ_POISON)\
- die("Usage of trace_seq after it was destroyed"); \
+ if (WARN_ONCE((s)->buffer == TRACE_SEQ_POISON, \
+ "Usage of trace_seq after it was destroyed")) \
+ (s)->state = TRACE_SEQ__BUFFER_POISONED;\
} while (0)
/**
@@ -46,6 +47,7 @@ void trace_seq_init(struct trace_seq *s)
s->readpos = 0;
s->buffer_size = TRACE_SEQ_BUF_SIZE;
s->buffer = malloc_or_die(s->buffer_size);
+ s->state = TRACE_SEQ__GOOD;
}
/**
@@ -81,7 +83,7 @@ static void expand_buffer(struct trace_seq *s)
s->buffer_size += TRACE_SEQ_BUF_SIZE;
s->buffer = realloc(s->buffer, s->buffer_size);
if (!s->buffer)
- die("Can't allocate trace_seq buffer memory");
+ s->state = TRACE_SEQ__MEM_ALLOC_FAILED;
}
/**
@@ -108,6 +110,9 @@ trace_seq_printf(struct trace_seq *s, const char *fmt, ...)
TRACE_SEQ_CHECK(s);
try_again:
+ if (s->state != TRACE_SEQ__GOOD)
+ return 0;
+
len = (s->buffer_size - 1) - s->len;
va_start(ap, fmt);
@@ -144,6 +149,9 @@ trace_seq_vprintf(struct trace_seq *s, const char *fmt,
va_list args)
TRACE_SEQ_CHECK(s);
try_again:
+ if (s->state != TRACE_SEQ__GOOD)
+ return 0;
+
len = (s->buffer_size - 1) - s->len;
ret = vsnprintf(s->buffer + s->len, len, fmt, args);
@@ -174,11 +182,17 @@ int trace_seq_puts(struct trace_seq *s, const char *str)
TRACE_SEQ_CHECK(s);
+ if (s->state != TRACE_SEQ__GOOD)
+ return 0;
+
len = strlen(str);
while (len > ((s->buffer_size - 1) - s->len))
expand_buffer(s);
+ if (s->state != TRACE_SEQ__GOOD)
+ return 0;
+
memcpy(s->buffer + s->len, str, len);
s->len += len;
@@ -189,9 +203,15 @@ int trace_seq_putc(struct trace_seq *s, unsigned char c)
{
TRACE_SEQ_CHECK(s);
+ if (s->state != TRACE_SEQ__GOOD)
+ return 0;
+
while (s->len >= (s->buffer_size - 1))
expand_buffer(s);
+ if (s->state != TRACE_SEQ__GOOD)
+ return 0;
+
s->buffer[s->len++] = c;
return 1;
@@ -201,6 +221,9 @@ void trace_seq_terminate(struct trace_seq *s)
{
TRACE_SEQ_CHECK(s);
+ if (s->state != TRACE_SEQ__GOOD)
+ return;
+
/* There's always one character left on the buffer */
s->buffer[s->len] = 0;
}
@@ -208,5 +231,16 @@ void trace_seq_terminate(struct trace_seq *s)
int trace_seq_do_printf(struct trace_seq *s)
{
TRACE_SEQ_CHECK(s);
- return printf("%.*s", s->len, s->buffer);
+
+ switch (s->state) {
+ case TRACE_SEQ__GOOD:
+ return printf("%.*s", s->len, s->buffer);
+ case TRACE_SEQ__BUFFER_POISONED:
+ puts("Usage of trace_seq after it was destroyed");
+ break;
+ case TRACE_SEQ__MEM_ALLOC_FAILED:
+ puts("Can't allocate trace_seq buffer memory");
+ break;
+ }
+ return -1;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] fs: xattr-based FS_IOC_[GS]ETFLAGS interface
This is a proof of concept interface for replacing the contentious
FS_IOC_[GS]ETFLAGS interface with one that presents itself as the
xattr 'system.iflags'. Instead of using integer inode flags, this
interface uses a comma-separated string of words, such as
"extents,immutable" to describe the inode flags. This ought to enable
all filesystems to introduce arbitrary flags, with any sort of backend
they want, while also taking advantage of generic fs flags.
The initial conversion is for ext4, though given the similarities of
most filesystems' implementations, converting the rest shouldn't be
difficult. How we get everyone to agree on common flag names is
anyone's guess.
Includes some helper methods to handle the string<->int conversion,
and a tweak to the generic xattr code to allow setting iflags on an
immutable file.
Usage:
# setfattr -n system.iflags -v 'extents,append' /path/file
# getfattr -n system.iflags /path/file
system.iflags="secrm,unrm,sync,immutable,nodump,noatime,journal_data,extents"
Signed-off-by: Darrick J. Wong
---
fs/ext4/Makefile |2
fs/ext4/ext4.h |3 +
fs/ext4/ioctl.c| 198
fs/ext4/xattr.c|1
fs/ext4/xattr.h|1
fs/ext4/xattr_iflags.c | 90
fs/xattr.c |9 ++
include/linux/strflags.h | 27 ++
include/uapi/linux/xattr.h |2
lib/Makefile |2
lib/strflags.c | 117 ++
11 files changed, 358 insertions(+), 94 deletions(-)
create mode 100644 fs/ext4/xattr_iflags.c
create mode 100644 include/linux/strflags.h
create mode 100644 lib/strflags.c
diff --git a/fs/ext4/Makefile b/fs/ext4/Makefile
index 0310fec..7126958 100644
--- a/fs/ext4/Makefile
+++ b/fs/ext4/Makefile
@@ -8,7 +8,7 @@ ext4-y := balloc.o bitmap.o dir.o file.o fsync.o ialloc.o
inode.o page-io.o \
ioctl.o namei.o super.o symlink.o hash.o resize.o extents.o \
ext4_jbd2.o migrate.o mballoc.o block_validity.o move_extent.o \
mmp.o indirect.o extents_status.o xattr.o xattr_user.o \
- xattr_trusted.o inline.o
+ xattr_trusted.o inline.o xattr_iflags.o
ext4-$(CONFIG_EXT4_FS_POSIX_ACL) += acl.o
ext4-$(CONFIG_EXT4_FS_SECURITY)+= xattr_security.o
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index bf6c5cd..24837ab 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2660,6 +2660,9 @@ extern void ext4_inline_data_truncate(struct inode
*inode, int *has_inline);
extern int ext4_convert_inline_data(struct inode *inode);
+/* ioctl.c */
+extern int ext4_set_iflags(struct inode *inode, int flags);
+
/* namei.c */
extern const struct inode_operations ext4_dir_inode_operations;
extern const struct inode_operations ext4_special_inode_operations;
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 60589b6..c6f21c9 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -213,12 +213,115 @@ swap_boot_out:
return err;
}
+/*
+ * Set inode flags. Assume we already have mnt_want_write_file and i_mutex.
+ */
+int ext4_set_iflags(struct inode *inode, int flags)
+{
+ handle_t *handle = NULL;
+ int err, migrate = 0;
+ struct ext4_iloc iloc;
+ unsigned int oldflags, mask, i;
+ unsigned int jflag;
+ struct ext4_inode_info *ei = EXT4_I(inode);
+
+ if (!inode_owner_or_capable(inode))
+ return -EACCES;
+
+ flags = ext4_mask_flags(inode->i_mode, flags);
+
+ err = -EPERM;
+ /* Is it quota file? Do not allow user to mess with it */
+ if (IS_NOQUOTA(inode))
+ goto flags_out;
+
+ oldflags = ei->i_flags;
+
+ /* The JOURNAL_DATA flag is modifiable only by root */
+ jflag = flags & EXT4_JOURNAL_DATA_FL;
+
+ /*
+* The IMMUTABLE and APPEND_ONLY flags can only be changed by
+* the relevant capability.
+*
+* This test looks nicer. Thanks to Pauline Middelink
+*/
+ if ((flags ^ oldflags) & (EXT4_APPEND_FL | EXT4_IMMUTABLE_FL)) {
+ if (!capable(CAP_LINUX_IMMUTABLE))
+ goto flags_out;
+ }
+
+ /*
+* The JOURNAL_DATA flag can only be changed by
+* the relevant capability.
+*/
+ if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL)) {
+ if (!capable(CAP_SYS_RESOURCE))
+ goto flags_out;
+ }
+ if ((flags ^ oldflags) & EXT4_EXTENTS_FL)
+ migrate = 1;
+
+ if (flags & EXT4_EOFBLOCKS_FL) {
+ /* we don't support adding EOFBLOCKS flag */
+ if (!(oldflags & EXT4_EOFBLOCKS_FL)) {
+ err = -EOPNOTSUPP;
+ goto flags_out;
+ }
+ } else if (oldflags & EXT4_EOFBLOCKS_FL)
+ ext4_truncate(inode);
+
+ handle = ext4_journal_start(inode,
[PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
function in case of !CONFIG_PCI.
Signed-off-by: David Cohen
---
Change v1 -> v2:
- xhci_msix_sync_irqs() already uses __maybe_unused flag when CONFIG_PCI is
set. Proper solution is to add same flag when !CONFIG_PCI instead of define
function as inline.
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..ed6b717b8ee1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] arm64: dts: APM X-Gene PCIe device tree nodes
On Thu, Jan 2, 2014 at 4:52 PM, Jason Gunthorpe
wrote:
> On Thu, Jan 02, 2014 at 01:56:51PM -0800, Tanmay Inamdar wrote:
>> On Mon, Dec 23, 2013 at 9:46 AM, Jason Gunthorpe
>> wrote:
>> > On Mon, Dec 23, 2013 at 01:32:03PM +0530, Tanmay Inamdar wrote:
>> >> This patch adds the device tree nodes for APM X-Gene PCIe controller and
>> >> PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
>> >> nodes
>> >> are added.
>> >
>> > Can you include an lspci dump for PCI DT bindings please? It is
>> > impossible to review otherwise..
>> >
>>
>> On the X-Gene evaluation platform, there is only one PCIe port
>> enabled. Here is the 'lspci' dump
>
> This is a bit hard to read withouth more context, but:
>
>> # lspci -vvv
>> 00:00.0 Class 0604: Device 19aa:e008 (rev 04)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>
> This is an on-chip device? (19aa does not seem to be a VID I can find)
oops.. looks like vendor and device IDs are jumbled. You can look for
e008 vendor ID.
I will fix it in next version.
>
> Ideally this is the on-chip PCI-PCI bridge which represents the port.
>
> The problem I see is that your DT binding has a top level stanza per
> port.
>
> We *really* prefer to see a single stanza for all ports - but this
> requires the HW to be able to fit into the Linux resource assignment
> model - a single resource pool for all ports and standard PCI-PCI
> bridge config access to assign the resource to a port.
>
> If your HW can't do this (eg because the port aperture 0xe0 is
> hard wired) then the fall back is to place every port in a distinct
> domain, with a distinct DT node and have overlapping bus numbers
> and fixed windows. I don't see PCI domain support in your driver..
Thanks for the suggestion. I will think over this.
>
> There is some kind of an addressing problem because you've done this:
>
> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> +{
> + int i;
> +
> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> + dev->resource[i].start = dev->resource[i].end = 0;
> + dev->resource[i].flags = 0;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_BRIDGE_DEVICEID,
> +xgene_pcie_fixup_bridge);
>
> Which is usually a sign that something is wonky with how the HW is
> being fit into the PCI core.
We map the whole DDR range (eg 256 GB) into host's BAR. The Linux PCI
resource management tries to fit the host's memory into the ranges
provided (eg 0xe0).
Please let me know if there is any use case to do this mapping.
>
>> ParErr+ Stepping- SERR+ FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 64 bytes
>> Region 0: Memory at (64-bit, prefetchable)
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>> I/O behind bridge: f000-0fff
>> Memory behind bridge: 00c0-00cf
>
> [..]
>
>> 01:00.0 Class 0200: Device 15b3:1003
>> Region 0: Memory at e000c0 (64-bit, non-prefetchable) [size=1M]
>> Region 2: Memory at e0 (64-bit, prefetchable)
>> [size=8M]
>
> Something funky is going on here too, the 64 bit address e0
> should be reflected in the 'memory behind bridge' above, not
> truncated.
That's the Mellanox device that is plugged into the system. The
device's memory gets mapped at '0xe0'
>
> ranges = <0x0200 0x0 0x 0x90 0x 0x0 0x1000 /* mem*/
> + 0x0100 0x0 0x8000 0x90 0x8000
> 0x0 0x0001 /* io */
> + 0x 0x0 0xd000 0x90 0xd000
> 0x0 0x0020 /* cfg */
> + 0x 0x0 0x7900 0x00 0x7900
> 0x0 0x0080>; /* msi */
>
> Ranges has a defined meaning, MSI shouldn't be in ranges, and 'cfg' is
> only OK if the address encoding exactly matches the funky PCI-E extended
> configuration address format. You can move these to regs or other
> properties
ok
>
> (MSI is tricky, I'm not aware of DT binding work for MSI :()
>
It does not. This is the range required to be mapped by the controller
to support MSI. I know it is not a standard way of doing. I was just
trying to utilize 'of_pci_range_to_resource' api.
> Also, unrelated, can you please double check that your HW cannot
> generate 8 and 16 bit configuration write TLPs natively? The
> xgene_pcie_cfg_out8/16 hack is not desirable if it can be avoided.
>
Sadly HW cannot generate 8 and 16 bit configuration transactions.
> Regards,
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/4] futex: silence uninitialized warnings
On Mon, Jan 6, 2014 at 9:38 AM, Davidlohr Bueso wrote:
> {
> int lock_taken, ret, force_take = 0;
> - u32 uval, newval, curval, vpid = task_pid_vnr(task);
> + u32 uval, newval, uninitialized_var(curval), vpid =
> task_pid_vnr(task);
Do you have some broken compiler? I really tend to hate this kind of
workarounds, because as mentioned, they can actually hide valid
warnings, and it seems to be due to just stupid compilers. Are we
perhaps better off trying to get people off the broken compiler
versions instead?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] extcon: gpio: Add power resume support
On 12/27/2013 02:40 PM, rjying wrote:
> From: Rongjun Ying
>
> When system on the suspend state, Some SoC can't get gpio interrupt.
> After system resume, need send extcon uevent to userspace.
>
> Signed-off-by: Rongjun Ying
> ---
> -v2: Add lost_sleep_irq flags.
>
> drivers/extcon/extcon-gpio.c | 20
> include/linux/extcon/extcon-gpio.h |1 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 7e0dff5..fde52c1 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -40,6 +40,7 @@ struct gpio_extcon_data {
> int irq;
> struct delayed_work work;
> unsigned long debounce_jiffies;
> + bool lost_sleep_irq;
I prefer 'check_on_resume' instead of 'load_sleep_irq'.
> };
>
> static void gpio_extcon_work(struct work_struct *work)
> @@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> extcon_data->gpio_active_low = pdata->gpio_active_low;
> extcon_data->state_on = pdata->state_on;
> extcon_data->state_off = pdata->state_off;
> + extcon_data->lost_sleep_irq = pdata->lost_sleep_irq;
ditto.
> if (pdata->state_on && pdata->state_off)
> extcon_data->edev.print_state = extcon_gpio_print_state;
> if (pdata->debounce) {
> @@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int gpio_extcon_resume(struct device *dev)
> +{
> + struct gpio_extcon_data *extcon_data;
> +
> + extcon_data = dev_get_drvdata(dev);
> + if (extcon_data->lost_sleep_irq)
ditto.
> + queue_delayed_work(system_power_efficient_wq,
> + _data->work, extcon_data->debounce_jiffies);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops gpio_extcon_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
> +};
> +
> static struct platform_driver gpio_extcon_driver = {
> .probe = gpio_extcon_probe,
> .remove = gpio_extcon_remove,
> .driver = {
> .name = "extcon-gpio",
> .owner = THIS_MODULE,
> + .pm = _extcon_pm_ops,
> },
> };
>
> diff --git a/include/linux/extcon/extcon-gpio.h
> b/include/linux/extcon/extcon-gpio.h
> index 4195810..c7f0c3e 100644
> --- a/include/linux/extcon/extcon-gpio.h
> +++ b/include/linux/extcon/extcon-gpio.h
> @@ -51,6 +51,7 @@ struct gpio_extcon_platform_data {
> /* if NULL, "0" or "1" will be printed */
> const char *state_on;
> const char *state_off;
> + bool lost_sleep_irq;
ditto.
> };
>
> #endif /* __EXTCON_GPIO_H__ */
>
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748
On Mon, Jan 06, 2014 at 04:47:38PM -0800, Muthu Kumar wrote:
> OK, after a bit more staring I believe the correct fix is the following.
This code still confuses me but I think you're correct, the fix certainly
matches the evidence we have.
> Fengguang, Please try this one?
>
> Regards,
> Muthu
>
>
> In btrfs_end_bio(), we increment bi_remaining if is_orig_bio. If not,
> we restore the orig_bio but failed to increment bi_remaining for
> orig_bio, which triggers a BUG_ON later when bio_endio is called. Fix
> is to increment bi_remaining when we restore the orig bio as well.
>
> Reported-by: fengguang...@intel.com
> CC: Kent Overstreet
> CC: Jens Axboe
> CC: Chris Mason Signed-off-by: Muthukumar Ratty
>
> fs/btrfs/volumes.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 37972d5..2011cc0 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -5297,9 +5297,9 @@ static void btrfs_end_bio(struct bio *bio, int err)
> if (!is_orig_bio) {
> bio_put(bio);
> bio = bbio->orig_bio;
> - } else {
> - atomic_inc(>bi_remaining);
> }
> + atomic_inc(>bi_remaining);
> +
> bio->bi_private = bbio->private;
> bio->bi_end_io = bbio->end_io;
> btrfs_io_bio(bio)->mirror_num = bbio->mirror_num;
>
> --
>
>
>
> On Mon, Jan 6, 2014 at 2:10 PM, Kent Overstreet wrote:
> > Chris, the patch below seems to be incorrect - with it we get hangs, so
> > bi_remaining (probably) isn't getting decremented when it should be. You
> > sent
> > Jens fixes for btrfs which I somehow lost when I rebased, do you remember
> > how
> > this is supposed to work? Looking at the code I'm not quite sure what's
> > going on
> > here.
> >
> > On Fri, Jan 03, 2014 at 11:51:31AM -0800, Muthu Kumar wrote:
> >> Looks like Kent missed the btrfs endio in the original commit. How
> >> about this patch:
> >>
> >> -
> >>
> >> In btrfs_end_bio, call bio_endio_nodec on the restored bio so the
> >> bi_remaining is accounted for correctly.
> >>
> >> Reported-by: fengguang...@intel.com
> >> Cc: Kent Overstreet
> >> CC: Jens Axboe
> >> Signed-off-by: Muthukumar Ratty
> >>
> >>
> >> fs/btrfs/volumes.c |6 +-
> >> 1 files changed, 5 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> >> index f2130de..edfed52 100644
> >> --- a/fs/btrfs/volumes.c
> >> +++ b/fs/btrfs/volumes.c
> >> @@ -5316,7 +5316,11 @@ static void btrfs_end_bio(struct bio *bio, int err)
> >> }
> >> kfree(bbio);
> >>
> >> - bio_endio(bio, err);
> >> +/*
> >> + * Call endio_nodec on the restored bio so the
> >> bi_remaining is
> >> + * accounted for correctly
> >> + */
> >> + bio_endio_nodec(bio, err);
> >> } else if (!is_orig_bio) {
> >> bio_put(bio);
> >> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] tracing/triggers: A couple minor variable name changes
> > > > + enum event_trigger_type tt = ETT_NONE; > > > + > > > + if (__event_trigger_test_discard(file, buffer, event, entry, )) > > > + trace_buffer_unlock_commit(buffer, event, irq_flags, pc); > > > > The logic is correct overall, but the way it reads is the opposite of > > what it used to i.e. it should read 'if you don't discard the event, > > then do the trace_buffer_unlock_commit' - it works as written because it > > returns 1 if it didn't discard, which is confusing. > > Hmm, OK, I think you may have convinced me. I'll swap the return values. > Sounds great, thanks! > I need to write up some trigger tests to make sure they work the same > before and after this patch. > I'll run the next version through my 'testsuite', which unfortunately is still manual (one of the many things on my todo list is automate it).. Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] tools lib traceevent: Add state member to struct trace_seq
Hi Steve and Jiri, 2014-01-06 PM 11:45, Steven Rostedt wrote: On Mon, 6 Jan 2014 15:38:28 +0100 Jiri Olsa wrote: I just thought that it's not so important to print message so keeps the error internally until it gets printed. But I can be wrong as usual... I think that if she manages to get one of those errors the perf would fail soon anyway.. so it feels better to print it out immediately. Yeah, using a trace_seq after it has been destroyed is a critical failure, and a major bug. A print to the user console should not be a problem here. And actually, crashing is not that bad either, as glibc does the same with using free() of a freed pointer. But as this error is major, an unwanted print is minor. OK, I'll add the WARN_ONCE in the TRACE_SEQ_CHECK then. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: slub: fix ALLOC_SLOWPATH stat
On Mon, 6 Jan 2014, Dave Hansen wrote: > This patch moves stat(s, ALLOC_SLOWPATH) to be called from the > same place that __slab_alloc() is. This makes it much less > likely that ALLOC_SLOWPATH will get botched again in the > spaghetti-code inside __slab_alloc(). Acked-by: Christoph Lameter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv9 02/20] thermal: introduce device tree parser
Hi, Eduardo
Will you consider my comments :)
Thanks.
Wei.
On 12/31/2013 06:17 PM, Wei Ni wrote:
> On 11/13/2013 03:46 AM, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> ...
>> +
>> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
>> +enum thermal_trend *trend)
>> +{
>> +struct __thermal_zone *data = tz->devdata;
>> +long dev_trend;
>> +int r;
>> +
>> +if (!data->get_trend)
>> +return -EINVAL;
>> +
>> +r = data->get_trend(data->sensor_data, _trend);
> I think the ->get_trend should be defined as:
> .get_trend(*dev, int, *long)
> so that the "trip" can be passed into it, otherwise the "trip" can't be
> used.
> And the dev_trend should be returned as THERMAL_TREND_XXX directly.
> because the THERM_TREND_xx is more than three states.
>
> The code may be something like:
> r = data->get_trend(data->sensor_data, trip, _trend);
> if (r)
> return r;
> *trend = dev_trend;
> return 0;
>> +if (r)
>> +return r;
>> +
>> +/* TODO: These intervals might have some thresholds, but in core code */
>> +if (dev_trend > 0)
>> +*trend = THERMAL_TREND_RAISING;
>> +else if (dev_trend < 0)
>> +*trend = THERMAL_TREND_DROPPING;
>> +else
>> +*trend = THERMAL_TREND_STABLE;
>> +
>> +return 0;
>> +}
>> +
>> .
>> +
>> +/*** sensor API ***/
>> +
>> +static struct thermal_zone_device *
>> +thermal_zone_of_add_sensor(struct device_node *zone,
>> + struct device_node *sensor, void *data,
>> + int (*get_temp)(void *, long *),
>> + int (*get_trend)(void *, long *))
>> +{
>> +struct thermal_zone_device *tzd;
>> +struct __thermal_zone *tz;
>> +
>> +tzd = thermal_zone_get_zone_by_name(zone->name);
> I think we could get the thermal zone by node,
> something like:
> thermal_zone_get_zone_by_node(zone);
> so that it can get unique zone.
>
> I think we can add a member "struct device_node *np" in the
> thermal_zone_device,
> and set it after you call thermal_zone_device_register successfully.
> Then add following codes:
> thermal_zone_get_zone_by_node(struct device_node *node)
> {
> struct thermal_zone_device *pos = NULL, *ref = ERR_PTR(-ENODEV);
> bool found = false;
>
> if (!node)
> return ERR_PTR(-EINVAL);
>
> mutex_lock(_list_lock);
> list_for_each_entry(pos, _tz_list, node)
> if (node == pos->np) {
> ref = pos;
> found = true;
> break;
> }
> mutex_unlock(_list_lock);
>
> return ref;
> }
>
> Thanks.
> Wei.
>> +if (IS_ERR(tzd))
>> +return ERR_PTR(-EPROBE_DEFER);
>> +
>> +tz = tzd->devdata;
>> +
>> +mutex_lock(>lock);
>> +tz->get_temp = get_temp;
>> +tz->get_trend = get_trend;
>> +tz->sensor_data = data;
>> +
>> +tzd->ops->get_temp = of_thermal_get_temp;
>> +tzd->ops->get_trend = of_thermal_get_trend;
>> +mutex_unlock(>lock);
>> +
>> +return tzd;
>> +}
>> +
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Sun, Jan 5, 2014 at 5:47 PM, Jingoo Han wrote:
> On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote:
>>
>> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
>> APM X-Gene PCIe controller supports maximum upto 8 lanes and
>> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
>
> (+cc Jason Gunthorpe, Arnd Bergmann)
>
> Hi Tanmay Inamdar,
>
> I added some minor comments. :-)
>
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig |5 +
>> drivers/pci/host/Makefile |1 +
>> drivers/pci/host/pcie-xgene.c | 1017
>> +
>
> Would you change the file name to 'pci-xgene.c'?
> Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'.
I guess designware is an exception. There is
"drivers/pci/host/pcie-designware.c"
>
> [.]
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Would you re-order these headers alphabetically?
> It enhances the readability.
ok.
>
> [.]
>
>> +static int xgene_pcie_parse_map_ranges(struct xgene_pcie_port *port)
>> +{
>> + struct device_node *np = port->node;
>> + struct of_pci_range range;
>> + struct of_pci_range_parser parser;
>> + struct device *dev = port->dev;
>> + u32 cfg_map_done = 0;
>> + int ret;
>> +
>> + if (of_pci_range_parser_init(, np)) {
>> + dev_err(dev, "missing ranges property\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* Get the I/O, memory, config ranges from DT */
>> + for_each_of_pci_range(, ) {
>> + struct resource *res = NULL;
>> + u64 restype = range.flags & IORESOURCE_TYPE_BITS;
>> + u64 end = range.cpu_addr + range.size - 1;
>> + dev_dbg(port->dev, "0x%08x 0x%016llx..0x%016llx ->
>> 0x%016llx\n",
>> + range.flags, range.cpu_addr, end, range.pci_addr);
>> +
>> + switch (restype) {
>> + case IORESOURCE_IO:
>> + res = >res[XGENE_IO];
>> + of_pci_range_to_resource(, np, res);
>> + xgene_pcie_setup_ob_reg(port->csr_base, OMR1BARL,
>> + XGENE_IO, res);
>> + break;
>> + case IORESOURCE_MEM:
>> + res = >res[XGENE_MEM];
>> + of_pci_range_to_resource(, np, res);
>> + xgene_pcie_setup_ob_reg(port->csr_base, OMR2BARL,
>> + XGENE_MEM, res);
>> + break;
>> + case 0:
>> + if (!cfg_map_done) {
>> + /* config region */
>> + if (port->type == PTYPE_ROOT_PORT) {
>> + ret = xgene_pcie_map_cfg(port, );
>> + if (ret)
>> + return ret;
>> + }
>> + cfg_map_done = 1;
>> + } else {
>> + /* msi region */
>> + res = >res[XGENE_MSI];
>> + of_pci_range_to_resource(, np, res);
>
> As Jason Gunthorpe said, the DT 'range' property should not
> handle MSI. Please refer to other PCI host drivers such as
> pci-mvebu.c, pci-tegra.c and pcie-designware.c.
Right. I will remove MSI from ranges.
>
> Currently, 'struct msi_chip', ' struct irq_domain' are used
> for implementing MSI feature.
>
> Best regards,
> Jingoo Han
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv9 02/20] thermal: introduce device tree parser
On 01/06/2014 10:54 PM, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On 06-01-2014 09:51, Mark Rutland wrote: >> On Thu, Jan 02, 2014 at 05:50:06PM +, Matthew Longnecker wrote: >>> I think the platform driver may set governor for the thermal zone, so how about to add a property named as "governor", and parse it to tzp->governor_name, something like: ret = of_property_read_string(child, "governor", ); if (ret == 0) if (strlen(str) < THERMAL_NAME_LENGTH) strcpy(tzp->governor_name, str); Thanks. Wei. >>> >>> DT is supposed to describe the hardware, right? The governor isn't >>> hardware -- it's a software control policy. On the other hand, that >>> control policy must be tuned according to the behaviors of the platform >>> hardware otherwise the system will be unstable. >>> >>> Is it appropriate to be naming the governor in DT? If so, is it equally >>> appropriate to describe any governor-specific parameters in DT (even >>> though they are pure software constructs)? >> >> The dt should be relatively static -- if the hardware doesn't change the >> dt shouldn't have to. >> >> The governers are not static. We can introduce new ones and throw away >> old ones at any time. Tuning parameters can also change at any time. >> >> I'd prefer to not have governer details described in the dt, and the >> choice of governer and configuration of its tuning parameters should be >> made at runtime somehow. > > Agreed. Yes, I think so, but the of-thermal driver handle the thermal_zone_device_register, and pass the "tzp" without governor_name, so the created thermal_zone's governor will be NULL, then it can't run into the governor->throttle() if needed. And currently there have no interface to support updating governor and configuration at runtime. I think it's better to initialize the governor_name when register the thermal zone device in the of-thermal driver. Thanks. > >> >> Thanks, >> Mark. >> >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
Thanks for your comments. Please see some inline replies.
On Fri, Jan 3, 2014 at 4:07 AM, Arnd Bergmann wrote:
> On Monday 23 December 2013, Tanmay Inamdar wrote:
>> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
>> APM X-Gene PCIe controller supports maximum upto 8 lanes and
>> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig |5 +
>> drivers/pci/host/Makefile |1 +
>> drivers/pci/host/pcie-xgene.c | 1017
>> +
>> 3 files changed, 1023 insertions(+)
>> create mode 100644 drivers/pci/host/pcie-xgene.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 47d46c6..6d8fcbc 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
>> There are 3 internal PCI controllers available with a single
>> built-in EHCI/OHCI host controller present on each one.
>>
>> +config PCI_XGENE
>> + bool "X-Gene PCIe controller"
>> + depends on ARCH_XGENE
>> + depends on OF
>
> Please add a help text here.
ok
>
>> +#ifdef CONFIG_ARM64
>> +#include
>> +#else
>> +#include
>> +#endif
>
> What is !ARM64 case? Is this for PowerPC or ARM? Since you depend on
> ARCH_XGENE in Kconfig I guess neither case can actually happen,
> so you can remove the #ifdef.
ok
>
>> +#define CFG_CONSTANTS_31_00 0x2000
>> +#define CFG_CONSTANTS_63_32 0x2004
>> +#define CFG_CONSTANTS_159_1280x2010
>> +#define CFG_CONSTANTS_415_384 0x2030
>
> These macros do not seem helpful. If you don't have meaningful register
> names, just don't provide any and address the registers by index.
ok
>
>> +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) & ~0x0200) | \
>> + (((u32)(src) << 0x19) & \
>> + 0x0200))
>
> Makes this an inline function, or open-code it in the caller if there
> is only one.
>
ok
>> +#ifdef CONFIG_64BIT
>> +#define pci_io_offset(s) (s & 0xff)
>> +#else
>> +#define pci_io_offset(s) (s & 0x)
>> +#endif /* CONFIG_64BIT */
>
> Why is this needed? The I/O space can never be over 0x,
> or in practice 0x. My best guess is that you have a bug in the
> function parsing your ranges property, or in the property value.
I will recheck the logic.
>
>> +static inline struct xgene_pcie_port *
>> +xgene_pcie_sys_to_port(struct pci_sys_data *sys)
>> +{
>> + return (struct xgene_pcie_port *)sys->private_data;
>> +}
>
> You shouldn't need the cast, or the accessor function, since private_data
> is already a void pointer.
got it.
>
>> +/* IO ports are memory mapped */
>> +void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
>> +unsigned int nr)
>> +{
>> + return devm_ioremap_nocache(>dev, port, nr);
>> +}
>
> This can't be in the host driver, since you can have only one instance
> of the function in the system, but you probably want multiple host
> drivers in a multiplatform kernel on ARM64.
You are right. It will fail multiplatform kernel.
>
> Also, the implementation is wrong since the I/O port range already needs
> to be ioremapped in order for inb/outb to work. There is already a
> generic implementation of this in include/asm-generic/iomap.h, which
> correctly calls ioport_map. Make sure that arm64 uses this implementation
> and provides an ioport_map() function like
>
> static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> {
> return PCI_IOBASE + port;
> }
For X-Gene, IO regions are memory mapped IO regions. So I am not sure
if 'ioport_map'
would work.
>
>> +/* PCIE Out/In to CSR */
>> +static inline void xgene_pcie_out32(void *addr, u32 val)
>> +{
>> + pr_debug("pcie csr wr: 0x%llx 0x%08x\n", (phys_addr_t)addr, val);
>> + writel(val, addr);
>> +}
>> +
>> +static inline void xgene_pcie_in32(void *addr, u32 *val)
>> +{
>> + *val = readl(addr);
>> + pr_debug("pcie csr rd: 0x%llx 0x%08x\n", (phys_addr_t)addr, *val);
>> +}
>
> These add no value, just remove them. If your code is so buggy that
> you need to print every register access to the debug log, we don't
> want it ;-)
Yep. I will remove it.
>
>> +static inline void xgene_pcie_cfg_out16(void *addr, u16 val)
>> +{
>> + phys_addr_t temp_addr = (phys_addr_t) addr & ~0x3;
>> + u32 val32 = readl((void *)temp_addr);
>> +
>> + switch ((phys_addr_t) addr & 0x3) {
>> + case 2:
>> + val32 &= ~0x;
>> + val32 |= (u32) val << 16;
>> + break;
>> + case 0:
>> + default:
>> + val32 &= ~0x;
>> + val32 |= val;
>> + break;
>> + }
>> + writel(val32, (void *)temp_addr);
>> +}
>
> Isn't there a generic version of this? If not, should
Re: [PATCH v3 03/14] mm, hugetlb: protect region tracking via newly introduced resv_map lock
On Wed, 2013-12-18 at 15:53 +0900, Joonsoo Kim wrote: > There is a race condition if we map a same file on different processes. > Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex. > When we do mmap, we don't grab a hugetlb_instantiation_mutex, but, > grab a mmap_sem. This doesn't prevent other process to modify region > structure, so it can be modified by two processes concurrently. > > To solve this, I introduce a lock to resv_map and make region manipulation > function grab a lock before they do actual work. This makes region > tracking safe. > > Signed-off-by: Joonsoo Kim Reviewed-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb:hub set hub->change_bits when over-current happens
On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote: > set hub->change_bits when we plug in a device which causes > over-current condition, so that hub_events() will check it. Why? What does this solve? Is this a bug with existing devices that needs to be backported to older kernels? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/14] mm, hugetlb: region manipulation functions take resv_map rather list_head
On Wed, 2013-12-18 at 15:53 +0900, Joonsoo Kim wrote: > To change a protection method for region tracking to find grained one, > we pass the resv_map, instead of list_head, to region manipulation > functions. This doesn't introduce any functional change, and it is just > for preparing a next step. > > Reviewed-by: Aneesh Kumar K.V > Signed-off-by: Joonsoo Kim Reviewed-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/14] mm, hugetlb: unify region structure handling
On Wed, 2013-12-18 at 15:53 +0900, Joonsoo Kim wrote: > Currently, to track a reserved and allocated region, we use two different > ways for MAP_SHARED and MAP_PRIVATE. For MAP_SHARED, we use > address_mapping's private_list and, for MAP_PRIVATE, we use a resv_map. > Now, we are preparing to change a coarse grained lock which protect > a region structure to fine grained lock, and this difference hinder it. > So, before changing it, unify region structure handling. > > Reviewed-by: Aneesh Kumar K.V > Signed-off-by: Joonsoo Kim Reviewed-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user
On Tue, 2014-01-07 at 10:57 +0900, Joonsoo Kim wrote: > On Mon, Jan 06, 2014 at 04:19:05AM -0800, Davidlohr Bueso wrote: > > On Mon, 2014-01-06 at 09:19 +0900, Joonsoo Kim wrote: > > > On Fri, Jan 03, 2014 at 11:55:45AM -0800, Davidlohr Bueso wrote: > > > > Hi Joonsoo, > > > > > > > > Sorry about the delay... > > > > > > > > On Mon, 2013-12-23 at 11:11 +0900, Joonsoo Kim wrote: > > > > > On Mon, Dec 23, 2013 at 09:44:38AM +0900, Joonsoo Kim wrote: > > > > > > On Fri, Dec 20, 2013 at 10:48:17PM -0800, Davidlohr Bueso wrote: > > > > > > > On Fri, 2013-12-20 at 14:01 +, Mel Gorman wrote: > > > > > > > > On Thu, Dec 19, 2013 at 05:02:02PM -0800, Andrew Morton wrote: > > > > > > > > > On Wed, 18 Dec 2013 15:53:59 +0900 Joonsoo Kim > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > If parallel fault occur, we can fail to allocate a hugepage, > > > > > > > > > > because many threads dequeue a hugepage to handle a fault > > > > > > > > > > of same address. > > > > > > > > > > This makes reserved pool shortage just for a little while > > > > > > > > > > and this cause > > > > > > > > > > faulting thread who can get hugepages to get a SIGBUS > > > > > > > > > > signal. > > > > > > > > > > > > > > > > > > > > To solve this problem, we already have a nice solution, > > > > > > > > > > that is, > > > > > > > > > > a hugetlb_instantiation_mutex. This blocks other threads to > > > > > > > > > > dive into > > > > > > > > > > a fault handler. This solve the problem clearly, but it > > > > > > > > > > introduce > > > > > > > > > > performance degradation, because it serialize all fault > > > > > > > > > > handling. > > > > > > > > > > > > > > > > > > > > Now, I try to remove a hugetlb_instantiation_mutex to get > > > > > > > > > > rid of > > > > > > > > > > performance degradation. > > > > > > > > > > > > > > > > > > So the whole point of the patch is to improve performance, > > > > > > > > > but the > > > > > > > > > changelog doesn't include any performance measurements! > > > > > > > > > > > > > > > > > > > > > > > > > I don't really deal with hugetlbfs any more and I have not > > > > > > > > examined this > > > > > > > > series but I remember why I never really cared about this > > > > > > > > mutex. It wrecks > > > > > > > > fault scalability but AFAIK fault scalability almost never > > > > > > > > mattered for > > > > > > > > workloads using hugetlbfs. The most common user of hugetlbfs > > > > > > > > by far is > > > > > > > > sysv shared memory. The memory is faulted early in the lifetime > > > > > > > > of the > > > > > > > > workload and after that it does not matter. At worst, it hurts > > > > > > > > application > > > > > > > > startup time but that is still poor motivation for putting a > > > > > > > > lot of work > > > > > > > > into removing the mutex. > > > > > > > > > > > > > > Yep, important hugepage workloads initially pound heavily on this > > > > > > > lock, > > > > > > > then it naturally decreases. > > > > > > > > > > > > > > > Microbenchmarks will be able to trigger problems in this area > > > > > > > > but it'd > > > > > > > > be important to check if any workload that matters is actually > > > > > > > > hitting > > > > > > > > that problem. > > > > > > > > > > > > > > I was thinking of writing one to actually get some numbers for > > > > > > > this > > > > > > > patchset -- I don't know of any benchmark that might stress this > > > > > > > lock. > > > > > > > > > > > > > > However I first measured the amount of cycles it costs to start an > > > > > > > Oracle DB and things went south with these changes. A simple > > > > > > > 'startup > > > > > > > immediate' calls hugetlb_fault() ~5000 times. For a vanilla > > > > > > > kernel, this > > > > > > > costs ~7.5 billion cycles and with this patchset it goes up to > > > > > > > ~27.1 > > > > > > > billion. While there is naturally a fair amount of variation, > > > > > > > these > > > > > > > changes do seem to do more harm than good, at least in real world > > > > > > > scenarios. > > > > > > > > > > > > Hello, > > > > > > > > > > > > I think that number of cycles is not proper to measure this > > > > > > patchset, > > > > > > because cycles would be wasted by fault handling failure. Instead, > > > > > > it > > > > > > targeted improved elapsed time. > > > > > > > > Fair enough, however the fact of the matter is this approach does en up > > > > hurting performance. Regarding total startup time, I didn't see hardly > > > > any differences, with both vanilla and this patchset it takes close to > > > > 33.5 seconds. > > > > > > > > > Could you tell me how long it > > > > > > takes to fault all of it's hugepages? > > > > > > > > > > > > Anyway, this order of magnitude still seems a problem. :/ > > > > > > > > > > > > I guess that cycles are wasted by zeroing hugepage in fault-path > > > > > > like as > > > > > > Andrew pointed out. > > > > > > > > > > > > I will send another patches to fix
[PATCH v2 3/5] arm: add early_ioremap support
This patch uses the generic early_ioremap code to implement
early_ioremap for ARM. The ARM-specific bits come mostly from
an earlier patch from Leif Lindholm
here:
https://lkml.org/lkml/2013/10/3/279
Signed-off-by: Mark Salter
Tested-by: Leif Lindholm
CC: linux-arm-ker...@lists.infradead.org
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Arnd Bergmann
---
arch/arm/Kconfig | 11 +
arch/arm/include/asm/Kbuild | 1 +
arch/arm/include/asm/fixmap.h | 18 +
arch/arm/include/asm/io.h | 1 +
arch/arm/kernel/setup.c | 3 ++
arch/arm/mm/Makefile | 1 +
arch/arm/mm/early_ioremap.c | 93 +++
arch/arm/mm/mmu.c | 2 +
8 files changed, 130 insertions(+)
create mode 100644 arch/arm/mm/early_ioremap.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..78a79a6a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1842,6 +1842,17 @@ config UACCESS_WITH_MEMCPY
However, if the CPU data cache is using a write-allocate mode,
this option is unlikely to provide any performance gain.
+config EARLY_IOREMAP
+ depends on MMU
+ bool "Provide early_ioremap() support for kernel initialization."
+ select GENERIC_EARLY_IOREMAP
+ help
+ Provide a mechanism for kernel initialisation code to temporarily
+ map, in a highmem-agnostic way, memory pages in before ioremap()
+ and friends are available (before paging_init() has run). It uses
+ the same virtual memory range as kmap so all early mappings must
+ be unapped before paging_init() is called.
+
config SECCOMP
bool
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index c38b58c..49ec506 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -4,6 +4,7 @@ generic-y += auxvec.h
generic-y += bitsperlong.h
generic-y += cputime.h
generic-y += current.h
+generic-y += early_ioremap.h
generic-y += emergency-restart.h
generic-y += errno.h
generic-y += exec.h
diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 68ea615..e92b7a4 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -21,8 +21,26 @@ enum fixed_addresses {
FIX_KMAP_BEGIN,
FIX_KMAP_END = (FIXADDR_TOP - FIXADDR_START) >> PAGE_SHIFT,
__end_of_fixed_addresses
+/*
+ * 224 temporary boot-time mappings, used by early_ioremap(),
+ * before ioremap() is functional.
+ *
+ * (P)re-using the FIXADDR region, which is used for highmem
+ * later on, and statically aligned to 1MB.
+ */
+#define NR_FIX_BTMAPS 32
+#define FIX_BTMAPS_SLOTS 7
+#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN(FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1)
};
+#define FIXMAP_PAGE_NORMAL (L_PTE_MT_WRITEBACK | L_PTE_YOUNG | L_PTE_PRESENT)
+#define FIXMAP_PAGE_IO (L_PTE_MT_DEV_NONSHARED | L_PTE_YOUNG | L_PTE_PRESENT)
+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
#include
#endif
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3c597c2..131e0ba 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
/*
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 987a7f5..038fb75 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -887,6 +888,8 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
+ early_ioremap_init();
+
sort(, meminfo.nr_banks, sizeof(meminfo.bank[0]),
meminfo_cmp, NULL);
early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index ecfe6e5..fea855e 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -15,6 +15,7 @@ endif
obj-$(CONFIG_MODULES) += proc-syms.o
obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
+obj-$(CONFIG_EARLY_IOREMAP)+= early_ioremap.o
obj-$(CONFIG_HIGHMEM) += highmem.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
diff --git a/arch/arm/mm/early_ioremap.c b/arch/arm/mm/early_ioremap.c
new file mode 100644
index 000..c3e2bf2
--- /dev/null
+++ b/arch/arm/mm/early_ioremap.c
@@ -0,0 +1,93 @@
+/*
+ * early_ioremap() support for ARM
+ *
+ * Based on existing support in arch/x86/mm/ioremap.c
+ *
+ * Restrictions: currently only functional before paging_init()
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+static pte_t bm_pte[PTRS_PER_PTE] __aligned(PTE_HWTABLE_SIZE) __initdata;
+
+static
[PATCH v2 1/5] mm: create generic early_ioremap() support
This patch creates a generic implementation of early_ioremap() support
based on the existing x86 implementation. early_ioremp() is useful for
early boot code which needs to temporarily map I/O or memory regions
before normal mapping functions such as ioremap() are available.
There is one difference from the existing x86 implementation which
should be noted. The generic early_memremap() function does not return
an __iomem pointer and a new early_memunmap() function has been added
to act as a wrapper for early_iounmap() but with a non __iomem pointer
passed in. This is in line with the first patch of this series:
https://lkml.org/lkml/2013/12/22/69
Signed-off-by: Mark Salter
CC: x...@kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: Andrew Morton
CC: Arnd Bergmann
CC: Ingo Molnar
CC: Thomas Gleixner
CC: "H. Peter Anvin"
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
---
include/asm-generic/early_ioremap.h | 41 ++
mm/Kconfig | 3 +
mm/Makefile | 1 +
mm/early_ioremap.c | 249
4 files changed, 294 insertions(+)
create mode 100644 include/asm-generic/early_ioremap.h
create mode 100644 mm/early_ioremap.c
diff --git a/include/asm-generic/early_ioremap.h
b/include/asm-generic/early_ioremap.h
new file mode 100644
index 000..d43e187
--- /dev/null
+++ b/include/asm-generic/early_ioremap.h
@@ -0,0 +1,41 @@
+#ifndef _ASM_EARLY_IOREMAP_H_
+#define _ASM_EARLY_IOREMAP_H_
+
+#include
+
+#ifdef CONFIG_GENERIC_EARLY_IOREMAP
+/*
+ * early_ioremap() and early_iounmap() are for temporary early boot-time
+ * mappings, before the real ioremap() is functional.
+ */
+extern void __iomem *early_ioremap(resource_size_t phys_addr,
+ unsigned long size);
+extern void *early_memremap(resource_size_t phys_addr,
+ unsigned long size);
+extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
+
+/* Arch-specific initialization */
+extern void early_ioremap_init(void);
+
+/* Generic initialization called by architecture code */
+extern void early_ioremap_setup(void);
+
+/*
+ * Called as last step in paging_init() so library can act
+ * accordingly for subsequent map/unmap requests.
+ */
+extern void early_ioremap_reset(void);
+
+/*
+ * Weak function called by early_ioremap_reset(). It does nothing, but
+ * architectures may provide their own version to do any needed cleanups.
+ */
+extern void early_ioremap_shutdown(void);
+#else
+static inline void early_ioremap_init(void) { }
+static inline void early_ioremap_setup(void) { }
+static inline void early_ioremap_reset(void) { }
+#endif
+
+#endif /* _ASM_EARLY_IOREMAP_H_ */
diff --git a/mm/Kconfig b/mm/Kconfig
index 723bbe0..0dcebf2a 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -552,3 +552,6 @@ config MEM_SOFT_DIRTY
it can be cleared by hands.
See Documentation/vm/soft-dirty.txt for more details.
+
+config GENERIC_EARLY_IOREMAP
+ bool
diff --git a/mm/Makefile b/mm/Makefile
index 305d10a..4e102e9 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
obj-$(CONFIG_CLEANCACHE) += cleancache.o
obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
obj-$(CONFIG_ZBUD) += zbud.o
+obj-$(CONFIG_GENERIC_EARLY_IOREMAP) += early_ioremap.o
diff --git a/mm/early_ioremap.c b/mm/early_ioremap.c
new file mode 100644
index 000..8c1ac48
--- /dev/null
+++ b/mm/early_ioremap.c
@@ -0,0 +1,249 @@
+/*
+ * Provide common bits of early_ioremap() support for architectures needing
+ * temporary mappings during boot before ioremap() is available.
+ *
+ * This is mostly a direct copy of the x86 early_ioremap implementation.
+ *
+ * (C) Copyright 1995 1996 Linus Torvalds
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int early_ioremap_debug __initdata;
+
+static int __init early_ioremap_debug_setup(char *str)
+{
+ early_ioremap_debug = 1;
+
+ return 0;
+}
+early_param("early_ioremap_debug", early_ioremap_debug_setup);
+
+static int after_paging_init __initdata;
+
+void __init __attribute__((weak)) early_ioremap_shutdown(void)
+{
+}
+
+void __init early_ioremap_reset(void)
+{
+ early_ioremap_shutdown();
+ after_paging_init = 1;
+}
+
+/*
+ * Generally, ioremap() is available after paging_init() has been called.
+ * Architectures wanting to allow early_ioremap after paging_init() can
+ * define __late_set_fixmap and __late_clear_fixmap to do the right thing.
+ */
+#ifndef __late_set_fixmap
+static inline void __init __late_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t prot)
+{
+ BUG();
+}
+#endif
+
+#ifndef __late_clear_fixmap
+static inline void __init __late_clear_fixmap(enum fixed_addresses idx)
+{
+ BUG();
+}
[PATCH v2 5/5] arm64: add early_ioremap support
Add support for early IO or memory mappings which are needed
before the normal ioremap() is usable. This also adds fixmap
support for permanent fixed mappings such as that used by the
earlyprintk device register region.
Signed-off-by: Mark Salter
CC: linux-arm-ker...@lists.infradead.org
CC: Catalin Marinas
CC: Will Deacon
---
Documentation/arm64/memory.txt | 4 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/include/asm/fixmap.h | 68
arch/arm64/include/asm/io.h | 1 +
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/kernel/early_printk.c | 8 +++-
arch/arm64/kernel/head.S | 9 ++---
arch/arm64/kernel/setup.c| 2 +
arch/arm64/mm/ioremap.c | 85
arch/arm64/mm/mmu.c | 41 ---
11 files changed, 170 insertions(+), 52 deletions(-)
create mode 100644 arch/arm64/include/asm/fixmap.h
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 5e054bf..953c81e 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -35,7 +35,7 @@ ffbc ffbd 8GB
vmemmap
ffbe ffbffbbf ~8GB [guard, future
vmmemap]
-ffbffbc0 ffbffbdf 2MB earlyprintk
device
+ffbffbc0 ffbffbdf 2MB fixed mappings
ffbffbe0 ffbffbe0 64KB PCI I/O space
@@ -60,7 +60,7 @@ fdfc fdfd 8GB
vmemmap
fdfe fdfffbbf ~8GB [guard, future
vmmemap]
-fdfffbc0 fdfffbdf 2MB earlyprintk
device
+fdfffbc0 fdfffbdf 2MB fixed mappings
fdfffbe0 fdfffbe0 64KB PCI I/O space
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d4dd22..e66a317 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -12,6 +12,7 @@ config ARM64
select CLONE_BACKWARDS
select COMMON_CLK
select GENERIC_CLOCKEVENTS
+ select GENERIC_EARLY_IOREMAP
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 519f89f..b7f99a3 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -10,6 +10,7 @@ generic-y += delay.h
generic-y += div64.h
generic-y += dma.h
generic-y += emergency-restart.h
+generic-y += early_ioremap.h
generic-y += errno.h
generic-y += ftrace.h
generic-y += hw_irq.h
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
new file mode 100644
index 000..7ad4f29
--- /dev/null
+++ b/arch/arm64/include/asm/fixmap.h
@@ -0,0 +1,68 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ * Copyright (C) 2013 Mark Salter
+ *
+ * Adapted from arch/x86_64 version.
+ *
+ */
+
+#ifndef _ASM_ARM64_FIXMAP_H
+#define _ASM_ARM64_FIXMAP_H
+
+#ifndef __ASSEMBLY__
+#include
+#include
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process.
+ *
+ * These 'compile-time allocated' memory buffers are
+ * page-sized. Use set_fixmap(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ */
+enum fixed_addresses {
+ FIX_EARLYCON,
+ __end_of_permanent_fixed_addresses,
+
+ /*
+* Temporary boot-time mappings, used by early_ioremap(),
+* before ioremap() is functional.
+*/
+#ifdef CONFIG_ARM64_64K_PAGES
+#define NR_FIX_BTMAPS 4
+#else
+#define NR_FIX_BTMAPS 64
+#endif
+#define FIX_BTMAPS_SLOTS 7
+#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+
+ FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
+ FIX_BTMAP_BEGIN = FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1,
+ __end_of_fixed_addresses
+};
+
+#define FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
+
+#define FIXMAP_PAGE_NORMAL PAGE_KERNEL_EXEC
+#define FIXMAP_PAGE_IO __pgprot(PROT_DEVICE_nGnRE)
+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define __set_fixmap __early_set_fixmap
+
+#include
+
+#endif /* !__ASSEMBLY__ */
+#endif /* _ASM_ARM64_FIXMAP_H */
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index
[PATCH v2 0/5] generic early_ioremap support
This patch series takes the common bits from the x86 early ioremap implementation and creates a generic implementation which may be used by other architectures. The early ioremap interfaces are intended for situations where boot code needs to make temporary virtual mappings before the normal ioremap interfaces are available. Typically, this means before paging_init() has run. These patches are layered on top of generic fixmap patches which were discussed here (and are in the akpm tree): http://lkml.org/lkml/2013/11/25/474 This is version 2 of the patch series. These patches (and underlying fixmap patches) may be found at: git://github.com/mosalter/linux.git (early-ioremap-v2 branch) Changes from version 1: * Moved the generic code into linux/mm instead of linux/lib * Have early_memremap() return normal pointer instead of __iomem This is in response to sparse warning cleanups being made in an unrelated patch series: https://lkml.org/lkml/2013/12/22/69 * Added arm64 patch to call init_mem_pgprot() earlier so that the pgprot macros are valid in time for early_ioremap use * Added validity checking for early_ioremap pgd, pud, and pmd in arm64 Mark Salter (5): mm: create generic early_ioremap() support x86: use generic early_ioremap arm: add early_ioremap support arm64: initialize pgprot info earlier in boot arm64: add early_ioremap support Documentation/arm64/memory.txt | 4 +- arch/arm/Kconfig| 11 ++ arch/arm/include/asm/Kbuild | 1 + arch/arm/include/asm/fixmap.h | 18 +++ arch/arm/include/asm/io.h | 1 + arch/arm/kernel/setup.c | 3 + arch/arm/mm/Makefile| 1 + arch/arm/mm/early_ioremap.c | 93 ++ arch/arm/mm/mmu.c | 2 + arch/arm64/Kconfig | 1 + arch/arm64/include/asm/Kbuild | 1 + arch/arm64/include/asm/fixmap.h | 68 ++ arch/arm64/include/asm/io.h | 1 + arch/arm64/include/asm/memory.h | 2 +- arch/arm64/include/asm/mmu.h| 1 + arch/arm64/kernel/early_printk.c| 8 +- arch/arm64/kernel/head.S| 9 +- arch/arm64/kernel/setup.c | 4 + arch/arm64/mm/ioremap.c | 85 arch/arm64/mm/mmu.c | 44 +-- arch/x86/Kconfig| 1 + arch/x86/include/asm/Kbuild | 1 + arch/x86/include/asm/fixmap.h | 6 + arch/x86/include/asm/io.h | 14 +- arch/x86/mm/ioremap.c | 224 +--- arch/x86/mm/pgtable_32.c| 2 +- include/asm-generic/early_ioremap.h | 41 ++ mm/Kconfig | 3 + mm/Makefile | 1 + mm/early_ioremap.c | 249 30 files changed, 611 insertions(+), 289 deletions(-) create mode 100644 arch/arm/mm/early_ioremap.c create mode 100644 arch/arm64/include/asm/fixmap.h create mode 100644 include/asm-generic/early_ioremap.h create mode 100644 mm/early_ioremap.c -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] arm64: initialize pgprot info earlier in boot
Presently, paging_init() calls init_mem_pgprot() to initialize pgprot
values used by macros such as PAGE_KERNEL, PAGE_KERNEL_EXEC, etc. The
new fixmap and early_ioremap support also needs to use these macros
before paging_init() is called. This patch moves the init_mem_pgprot()
call out of paging_init() and into setup_arch() so that pgprot_default
gets initialized in time for fixmap and early_ioremap.
Signed-off-by: Mark Salter
CC: linux-arm-ker...@lists.infradead.org
CC: Catalin Marinas
CC: Will Deacon
---
arch/arm64/include/asm/mmu.h | 1 +
arch/arm64/kernel/setup.c| 2 ++
arch/arm64/mm/mmu.c | 3 +--
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 2494fc0..f600d40 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -27,5 +27,6 @@ typedef struct {
extern void paging_init(void);
extern void setup_mm_for_reboot(void);
extern void __iomem *early_io_map(phys_addr_t phys, unsigned long virt);
+extern void init_mem_pgprot(void);
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bd9bbd0..029ecfe 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -221,6 +221,8 @@ void __init setup_arch(char **cmdline_p)
*cmdline_p = boot_command_line;
+ init_mem_pgprot();
+
parse_early_param();
arm64_memblock_init();
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f557ebb..541c782 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -125,7 +125,7 @@ early_param("cachepolicy", early_cachepolicy);
/*
* Adjust the PMD section entries according to the CPU in use.
*/
-static void __init init_mem_pgprot(void)
+void __init init_mem_pgprot(void)
{
pteval_t default_pgprot;
int i;
@@ -349,7 +349,6 @@ void __init paging_init(void)
{
void *zero_page;
- init_mem_pgprot();
map_mem();
/*
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] x86: use generic early_ioremap
Move x86 over to the generic early ioremap implementation. The
generic implementation is functionally the same except that the
early_memremap() function returns a normal pointer instead of an
__iomem pointer. This is in line with sparse warning cleanups in
this patch series:
https://lkml.org/lkml/2013/12/22/69
Signed-off-by: Mark Salter
CC: x...@kernel.org
CC: Andrew Morton
CC: Arnd Bergmann
CC: Ingo Molnar
CC: Thomas Gleixner
CC: "H. Peter Anvin"
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/Kbuild | 1 +
arch/x86/include/asm/fixmap.h | 6 ++
arch/x86/include/asm/io.h | 14 +--
arch/x86/mm/ioremap.c | 224 +-
arch/x86/mm/pgtable_32.c | 2 +-
6 files changed, 13 insertions(+), 235 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0952ecd..50e1eab 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -125,6 +125,7 @@ config X86
select RTC_LIB
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
+ select GENERIC_EARLY_IOREMAP
config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index 7f66985..203f5f9 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -5,3 +5,4 @@ genhdr-y += unistd_64.h
genhdr-y += unistd_x32.h
generic-y += clkdev.h
+generic-y += early_ioremap.h
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 7252cd3..e5f236d 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -177,5 +177,11 @@ static inline void __set_fixmap(enum fixed_addresses idx,
#include
+#define __late_set_fixmap(idx, phys, flags) __set_fixmap(idx, phys, flags)
+#define __late_clear_fixmap(idx) __set_fixmap(idx, 0, __pgprot(0))
+
+void __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_X86_FIXMAP_H */
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..aae7010 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
@@ -316,19 +317,6 @@ extern int ioremap_change_attr(unsigned long vaddr,
unsigned long size,
unsigned long prot_val);
extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
-/*
- * early_ioremap() and early_iounmap() are for temporary early boot-time
- * mappings, before the real ioremap() is functional.
- * A boot-time mapping is currently limited to at most 16 pages.
- */
-extern void early_ioremap_init(void);
-extern void early_ioremap_reset(void);
-extern void __iomem *early_ioremap(resource_size_t phys_addr,
- unsigned long size);
-extern void __iomem *early_memremap(resource_size_t phys_addr,
- unsigned long size);
-extern void early_iounmap(void __iomem *addr, unsigned long size);
-extern void fixup_early_ioremap(void);
extern bool is_early_ioremap_ptep(pte_t *ptep);
#ifdef CONFIG_XEN
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 799580c..597ac15 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -328,17 +328,6 @@ void unxlate_dev_mem_ptr(unsigned long phys, void *addr)
return;
}
-static int __initdata early_ioremap_debug;
-
-static int __init early_ioremap_debug_setup(char *str)
-{
- early_ioremap_debug = 1;
-
- return 0;
-}
-early_param("early_ioremap_debug", early_ioremap_debug_setup);
-
-static __initdata int after_paging_init;
static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __page_aligned_bss;
static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
@@ -362,18 +351,11 @@ bool __init is_early_ioremap_ptep(pte_t *ptep)
return ptep >= _pte[0] && ptep < _pte[PAGE_SIZE/sizeof(pte_t)];
}
-static unsigned long slot_virt[FIX_BTMAPS_SLOTS] __initdata;
-
void __init early_ioremap_init(void)
{
pmd_t *pmd;
- int i;
- if (early_ioremap_debug)
- printk(KERN_INFO "early_ioremap_init()\n");
-
- for (i = 0; i < FIX_BTMAPS_SLOTS; i++)
- slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN - NR_FIX_BTMAPS*i);
+ early_ioremap_setup();
pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
memset(bm_pte, 0, sizeof(bm_pte));
@@ -402,13 +384,8 @@ void __init early_ioremap_init(void)
}
}
-void __init early_ioremap_reset(void)
-{
- after_paging_init = 1;
-}
-
-static void __init __early_set_fixmap(enum fixed_addresses idx,
- phys_addr_t phys, pgprot_t flags)
+void __init __early_set_fixmap(enum fixed_addresses idx,
+
