[GIT PULL] regulator updates for v3.20
The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e: Linux 3.19-rc7 (2015-02-01 20:07:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-v3.20 for you to fetch changes up to dd7c2e720a16958da1279a8d69de6fb14b6f4ee4: Merge remote-tracking branches 'regulator/topic/rk808', 'regulator/topic/rpm', 'regulator/topic/rt5033' and 'regulator/topic/tps65023' into regulator-next (2015-02-08 11:16:30 +0800) regulator: Updates for v3.20 This has not been a busy release for the regulator framework, though we do have the first parts of some ongoing work from Bjorn Andersson to allow us to support more complex modern systems with dynamic configuration of regulators in suspend and idle states. - Support for device-specific properties on regulator nodes when using simplified DT parsing in the core from Krzysztof Kozlowski. - Restructuring of the load tracking code, intended to support future improvements in this area for more complex system designs. - New drivers for Maxim MAX77843 and Mediatek MT6397. - Lots of smaller fixes and improvements. Aniroop Mathur (2): regulator: core: Avoid negative regulator no & initialize it to -1 regulator: core: Fix format specifier warning Arnaud Ebalard (1): regulator: isl9305: deprecate use of isl in compatible string for isil Axel Lin (2): regulator: lp872x: Remove **regulators from struct lp872x regulator: qcom_rpm: Don't update vreg->uV/mV if rpm_reg_write fails Beomho Seo (2): regulator: max14577: Use regulator_nodes/of_match in the descriptor regulator: rt5033-regulator: Use regulator_nodes/of_match in the descriptor Bjorn Andersson (2): regulator: core: Consolidate drms update handling regulator: qcom-rpm: Make it possible to specify supply Chen-Yu Tsai (2): regulator: axp20x: Fill regulators_node and of_match descriptor fields regulator: axp20x: Migrate to regulator core's simplified DT parsing code Dan Carpenter (1): regulator: qcom-rpm: signedness bug in probe() Flora Fu (2): regulator: mt6397: Add support for MT6397 regulator regulator: Add document for MT6397 regulator Jaewon Kim (1): regulator: max77843: Add max77843 regulator driver James Ban (2): regulator: da9211: fix unmatched of_node regulator: da9211: Add gpio control for enable/disable of buck Krzysztof Kozlowski (9): regulator: fan53555: Constify struct regmap_config and slew_rates array regulator: max8649: Constify struct regmap_config and regulator_ops regulator: tps65023: Constify struct regmap_config and regulator_ops regulator: Copy config passed during registration regulator: max77686: Add GPIO control regulator: Allow parsing custom properties when using simplified DT parsing regulator: max77686: Document gpio properties regulator: Update documentation after renaming function argument regulator: Fix build breakage on !REGULATOR Mark Brown (9): Merge branch 'topic/core' of git://git.kernel.org/.../broonie/regulator into regulator-dt-cb Merge tag 'regulator-v3.19-rc7' into regulator-linus Merge remote-tracking branch 'regulator/fix/qcom-rpm' into regulator-linus Merge remote-tracking branch 'regulator/topic/core' into regulator-next Merge remote-tracking branch 'regulator/topic/dt-cb' into regulator-next Merge remote-tracking branches 'regulator/topic/axp20x', 'regulator/topic/da9211' and 'regulator/topic/fan53555' into regulator-next Merge remote-tracking branches 'regulator/topic/isl9305', 'regulator/topic/lp872x', 'regulator/topic/max14577', 'regulator/topic/max7686' and 'regulator/topic/max77843' into regulator-next Merge remote-tracking branches 'regulator/topic/max8649', 'regulator/topic/mode', 'regulator/topic/mt6397', 'regulator/topic/pfuze100' and 'regulator/topic/qcom-rpm' into regulator-next Merge remote-tracking branches 'regulator/topic/rk808', 'regulator/topic/rpm', 'regulator/topic/rt5033' and 'regulator/topic/tps65023' into regulator-next Robin Gong (1): regulator: pfuze100-regulator: add pfuze3000 support Takashi Iwai (1): regulator: Build sysfs entries with static attribute groups Wei Yongjun (1): regulator: rk808: Fix sparse non static symbol warnings Documentation/devicetree/bindings/mfd/max77686.txt | 14 + .../devicetree/bindings/regulator/da9211.txt | 7 +- .../devicetree/bindings/regulator/isl9305.txt | 4 +- .../bindings/regulator/mt6397-regulator.txt| 217 .../devicetree/bindings/regulator/pfuze100.txt | 94 +- drivers/regulator/Kconfig | 17 + drivers/regulator/Makefile | 2 +
Re: [RFT PATCH 2/4] compal-laptop: Check return value of power_supply_register
On pią, 2015-02-06 at 18:42 -0800, Darren Hart wrote:
> On Tue, Jan 27, 2015 at 12:30:19PM +0100, Krzysztof Kozlowski wrote:
> > The return value of power_supply_register() call was not checked and
> > even on error probe() function returned 0. If registering failed then
> > during unbind the driver tried to unregister power supply which was not
> > actually registered.
> >
> > This could lead to memory corruption because power_supply_unregister()
> > unconditionally cleans up given power supply.
> >
> > Fix this by checking return status of power_supply_register() call. In
> > case of failure, unregister the hwmon device and fail the probe. Add a
> > fixme note about missing hwmon_device_unregister() in driver removal.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > Fixes: 9be0fcb5ed46 ("compal-laptop: add JHL90, battery & hwmon interface")
> > Cc:
> > ---
> > drivers/platform/x86/compal-laptop.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/compal-laptop.c
> > b/drivers/platform/x86/compal-laptop.c
> > index 15c0fab2bfa1..cf55a9246f12 100644
> > --- a/drivers/platform/x86/compal-laptop.c
> > +++ b/drivers/platform/x86/compal-laptop.c
> > @@ -1036,12 +1036,16 @@ static int compal_probe(struct platform_device
> > *pdev)
> >
> > /* Power supply */
> > initialize_power_supply_data(data);
> > - power_supply_register(_device->dev, >psy);
> > + err = power_supply_register(_device->dev, >psy);
> > + if (err < 0)
> > + goto psy_err;
> >
> > platform_set_drvdata(pdev, data);
> >
> > return 0;
> >
> > +psy_err:
> > + hwmon_device_unregister(hwmon_dev);
> > remove:
> > sysfs_remove_group(>dev.kobj, _platform_attr_group);
> > return err;
> > @@ -1072,6 +1076,7 @@ static int compal_remove(struct platform_device *pdev)
> >
> > data = platform_get_drvdata(pdev);
> > power_supply_unregister(>psy);
> > + /* FIXME: missing hwmon_device_unregister() */
>
> Is this FIXME a leftover? Is there a reason we can't fix this now instead of
> adding a FIXME?
This is not a leftover. I think this should be fixed but:
1. I cannot test this driver,
2. I am not such familiar with hwmon API,
so my fix could be wrong and introduce more errors than fixes.
If you also think hwmon_device_unregister() is needed then I could send
new version of patch. Also I would be happy if someone else fixed this.
Best regards,
Krzysztof
--
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: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
> > Subject: Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to > > enable MC promiscuous mode > > > > On Fri, 2015-01-30 at 11:37 +, Hiroshi Shimamoto wrote: > > > From: Hiroshi Shimamoto > > > > > > The limitation of the number of multicast address for VF is not enough > > > for the large scale server with SR-IOV feature. > > > IPv6 requires the multicast MAC address for each IP address to handle > > > the Neighbor Solicitation message. > > > We couldn't assign over 30 IPv6 addresses to a single VF interface. > > > > > > The easy way to solve this is enabling multicast promiscuous mode. > > > It is good to have a functionality to enable multicast promiscuous > > > mode > > > for each VF from VF driver. > > > > > > This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to > > > enable/disable multicast promiscuous mode in VF. If multicast > > > promiscuous > > > mode is enabled the VF can receive all multicast packets. > > > > > > With this patch, the ixgbevf driver automatically enable multicast > > > promiscuous mode when the number of multicast addresses is over than > > > 30 > > > if possible. > > > > > > This also bump the API version up to 1.2 to check whether the API, > > > IXGBE_VF_SET_MC_PROMISC is available. > > > > > > Signed-off-by: Hiroshi Shimamoto > > > Reviewed-by: Hayato Momma > > > CC: Choi, Sy Jong > > > --- > > > drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 + > > > drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 4 + > > > drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 89 > > > ++- > > > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++- > > > drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 + > > > drivers/net/ethernet/intel/ixgbevf/vf.c | 29 +++- > > > drivers/net/ethernet/intel/ixgbevf/vf.h | 1 + > > > 7 files changed, 137 insertions(+), 4 deletions(-) > > > > Hiroshi, I tried to apply your patches to my queue but they do not apply > > cleanly and they are in a DOS file format, not UNIX. I also noted > > several checkpatch.pl issues with your patches, so please fix those up > > as well. > > I'm sorry to bother you. > Will fix. > > > > > Can you please fix up your patches based on my tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git > > Yes. I haven't noticed your tree. > Will resend patches against it. > I encountered an issue with your tree, the commit id is below. $ git log | head commit e6f1649780f8f5a87299bf6af04453f93d1e3d5e Author: Rasmus Villemoes Date: Fri Jan 23 20:43:14 2015 -0800 ethernet: fm10k: Actually drop 4 bits The comment explains the intention, but vid has type u16. Before the inner shift, it is promoted to int, which has plenty of space for all vid's bits, so nothing is dropped. Use a simple mask instead. I use the kernel from your tree in both host and guest. Assign an IPv6 for VF in guest. # ip -6 addr add 2001:db8::18:1/64 dev ens0 Send ping packet from other server to the VM. # ping6 2001:db8::18:1 -I eth0 The following message was shown. ixgbevf :00:08.0: partial checksum but l4 proto=3a! If I did the same operation in the host, I saw the same error message in host too. ixgbe :2d:00.0: partial checksum but l4 proto=3a! Do you have any idea about that? thanks, Hiroshi
Re: [GIT PULL rcu/next] RCU commits for 3.20
* Paul E. McKenney wrote: > On Fri, Feb 06, 2015 at 07:28:23PM +0100, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > On Tue, Feb 03, 2015 at 03:34:45PM +0100, David Hildenbrand wrote: > > > > > > > > > > * Paul E. McKenney wrote: > > > > > > > > > > > Hello, Ingo, > > > > > > > > > > > > The changes in this series include: > > > > > > > > > > > > 1. Documentation updates. These were posted to LKML at > > > > > > https://lkml.org/lkml/2015/1/7/496. > > > > > > > > > > > > 2. Miscellaneous fixes. These were posted to LKML at > > > > > > https://lkml.org/lkml/2015/1/7/507. > > > > > > > > > > > > 3. Preemptible-RCU fixes, including fixing an old bug in the > > > > > > interaction of RCU priority boosting and CPU hotplug. These > > > > > > were > > > > > > posted to LKML at https://lkml.org/lkml/2015/1/7/535. > > > > > > > > > > > > 4. SRCU updates. These were posted to LKML at > > > > > > https://lkml.org/lkml/2015/1/7/555. > > > > > > > > > > > > 5. RCU CPU stall-warning updates. These were posted to LKML at > > > > > > https://lkml.org/lkml/2015/1/7/565. > > > > > > > > > > > > 6. RCU torture-test updates. These were posted to LKML at > > > > > > https://lkml.org/lkml/2015/1/7/591. > > > > > > > > > > > > These changes are available in the git repository at: > > > > > > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > > > > > for-mingo > > > > > > > > > > > > for you to fetch changes up to > > > > > > 78e691f4ae2d5edea0199ca802bb505b9cdced88: > > > > > > > > > > > > Merge branches 'doc.2015.01.07a', 'fixes.2015.01.15a', > > > > > > 'preempt.2015.01.06a', 'srcu.2015.01.06a', 'stall.2015.01.16a' and > > > > > > 'torture.2015.01.11a' into HEAD (2015-01-15 23:34:34 -0800) > > > > > > > > > > > > > > > > > > > > > > > > Alexander Gordeev (1): > > > > > > rcu: Remove redundant rcu_is_cpu_rrupt_from_idle() from tiny > > > > > > RCU > > > > > > > > > > > > Calvin Owens (1): > > > > > > ksoftirqd: Enable IRQs and call cond_resched() before poking > > > > > > RCU > > > > > > > > > > > > David Hildenbrand (1): > > > > > > hotplugcpu: Avoid deadlocks by waking active_writer > > > > > > > > > > > > > > Hi Ingo, Paul, > > > > > > > > Heiko/Christian seem to have hit the bug (hotplugcpu: Avoid deadlocks > > > > by waking > > > > active_writer addresses) in 3.18-rc3. > > > > > > > > And as commit b2c4623dcd07 was in linux starting with 3.18-rc3, we > > > > should > > > > probably (have done a) cc-stable. > > > > > > Good point, though appropriate RCU changes seem to make their > > > way to -stable without explicit CCs. Maybe I should be doing > > > them, but doing so in the past has normally gotten me > > > complaints from the -stable maintainers. > > > > > > Ingo, how would you like me to be handling this in the future? > > > > So if you put a Cc: stable tag into the commit then usually they > > get picked up automatically. > > > > Just make sure you don't Cc: the stable team on patch > > submissions (which might or might not make it into > > Linus's tree), that's what will get complaints. > > > > Does that work for you? > > I will give it a spin. I thought that adding the "Cc: > stable" tag to the commit log got me complaints when I > later did git-format-patch and git-send-email, but > perhaps I was confused or this has since changed. Yeah, I believe that will get you complaints, so you have to avoid sending those emails to -stable - but there's no restriction on what can be in the Cc: entries of the commit log itself. Thanks, Ingo -- 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 0/3] powerpc: Enable seccomp filter support
Add the missing pieces in order to enable SECCOMP_FILTER on PowerPC architectures, and enable this support. Testing has been pursued using libseccomp with the latest ppc support patches [1], on Freescale platforms for both ppc and ppc64. ppc64le support is untested. [1] https://groups.google.com/forum/#!topic/libseccomp/ktR-bQr1tGw Bogdan Purcareata (3): powerpc: Don't force ENOSYS as error on syscall fail powerpc: Relax secure computing on syscall entry trace powerpc: Enable HAVE_ARCH_SECCOMP_FILTER arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/entry_32.S | 3 ++- arch/powerpc/kernel/entry_64.S | 2 +- arch/powerpc/kernel/ptrace.c | 4 +++- 4 files changed, 7 insertions(+), 3 deletions(-) -- 2.1.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: [GIT PULL] RAS update for 3.20 (one more thing)
* Luck, Tony wrote: > The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce: > > Linux 3.19-rc6 (2015-01-25 20:04:41 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git > tags/please-pull-fixmcelog > > for you to fetch changes up to 728b6f14abaa7f36a8c6d41c6d6fe0320d32d5e9: > > x86, mce: Kernel does full decoding for AMD, others still need /dev/mcelog > reports (2015-01-30 11:25:46 -0800) > > > Long standing regression - functions registered on the mce decoder > chain can declare that they have completely dealt with an event. > True for AMD (says Boris), since the kernel fully decodes the > machine check bank information. Not true for Intel processors. Full > decode is done in user space, so we need to make the log visible > via /dev/mcelog > > > Tony Luck (1): > x86, mce: Kernel does full decoding for AMD, others still need > /dev/mcelog reports > > arch/x86/kernel/cpu/mcheck/mce.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Pulled into tip:x86/ras, thanks Tony! Ingo -- 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:Re: [Question] should we export set_suspend_voltage()?
At 2015-02-07 06:10:58, "Mark Brown" wrote:
>On Fri, Feb 06, 2015 at 10:57:49AM +0800, Yi Zhang wrote:
>
>Please fix your mailer to word wrap within paragraphs, your mail is very
>difficult to read and reply to.
>
Thanks Mark for pointing this out;
>> do you think it's good to export the set_suspend_voltage()? to make it
>> controllable by the regulator itself? another method in my opinion is
>> add a set of virtual-regulator for this usage?
>
>> could you please share your advice?
>
>There's been some discussion of this in the context of some Qualcomm
>systems recently, search the archives for discussions especially with
>Bjorn Andersson recently. The basic idea was to mirror the existing
>APIs but with an additional mode argument (and permisions) to allow
>consumers to manipulate states other than the default state.
Thanks, I searched http://article.gmane.org/gmane.linux.ports.arm.msm/10606
if possible, could you please add me in that loop? thanks very much;
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[GIT PULL] spi v3.20
The following changes since commit d426a842b0c203c182ec2658efc4282ef1eb80be: Merge remote-tracking branches 'spi/fix/fsl-dspi' and 'spi/fix/imx' into spi-linus (2015-02-04 20:57:31 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v3.20 for you to fetch changes up to 66886337bf2a523aef76cff84c846335db5f85f9: Merge remote-tracking branch 'spi/topic/xilinx' into spi-next (2015-02-08 11:17:01 +0800) spi: Updates for v3.20 The major highlight this release is a refactoring of the core to allow us to run synchronous transfers in the context of the caller when there is no contention for the bus. This improves performance in the very common case by eliminating context switches and reducing the number of hardware setup and teardown operations we need to perform. Other changes: - New drivers for DLN-2 USB-SPI adapter and ST SPI controllers. - A big round of cleanups, performance and feature improvements for the xilinx driver from Ricardo Ribalda Delgado. - A wide range of smaller cleanups, fixes and feature improvements throughout the subsystem. Andrew Bresticker (1): spi: img-spfi: Select FIFO based on transfer length Andy Shevchenko (3): spi: dw: print debug message with FIFO size spi: dw-pci: describe Intel MID controllers better spi: dw-mid: get a proper clock frequency for SPI2 Arnd Bergmann (2): spi/rockchip: avoid uninitialized-use warning spi: pl08x: do not select S3C64XX_PL080 Axel Lin (1): spi: st-ssc4: Remove duplicate code to test unsupported mode bits Barry Song (2): spi: sirf: drop redundant sirf,marco-spi compatible string spi: sirf: add missed devicetree binding document Bhuvanchandra DV (1): spi: fsl-dspi: Remove possible memory leak of 'chip' Chao Fu (1): spi: spi-fsl-dspi: Remove spi-bitbang Esben Haabendal (1): spi: fsl-(e)spi: Support compile as module Fabio Estevam (1): spi: spi-imx: Do not store the irq number in the private structure Geert Uytterhoeven (1): spi: sh-msiof: Use async pm_runtime_put() in sh_msiof_spi_setup() Ian Abbott (1): spi: spidev: Convert buf pointers for 32-bit compat SPI_IOC_MESSAGE(n) Ivan T. Ivanov (1): spi: qup: Add SPI_CPOL configuration support Jarkko Nikula (7): spi: Remove FSF mailing addresses spi: pxa2xx: Remove unused define spi: pxa2xx: Move is_lpss_ssp() tests to caller spi: pxa2xx: Add definition for Intel Quark DDS_RATE register spi: pxa2xx: Pass driver data instead of ioaddr to wait_ssp_rx_stall() spi: pxa2xx: Cleanup register access macros spi: pxa2xx: Fix unconditional call of lpss_ssp_setup in pxa2xx_spi_resume Ken Wilson (2): spi: orion: Change spi-orion to use transfer_one() semantics for SPI transfers spi: orion: Add multiple chip select support to spi-orion Krzysztof Kozlowski (1): spi: meson: Constify struct regmap_config Laurentiu Palcu (2): spi: add support for DLN-2 USB-SPI adapter spi/dln2: simplify return flow for dln2_spi_transfer_setup and dln2_spi_enable Lee Jones (2): spi: Add new driver for STMicroelectronics' SPI Controller spi: st: Provide Device Tree binding documentation Mark Brown (18): spi: Move queue data structure initialisation to main master init spi: Check to see if the device is processing a message before we idle spi: Pump transfers inside calling context for spi_sync() spi: Only idle the message pump in the worker kthread spi/falcon: Remove hardware prepare and unprepare functions spi/dln2: Fix for PM_RUNTIME removal Merge remote-tracking branch 'spi/fix/msiof' into spi-sh-msiof Merge tag 'v3.19-rc3' into spi-sh-msiof spi: Revert "spi/xilinx: Remove iowrite/ioread wrappers" Merge tag 'spi-v3.19-rc7' into spi-linus Merge remote-tracking branch 'spi/topic/core' into spi-next Merge remote-tracking branch 'spi/topic/sh-msiof' into spi-next Merge remote-tracking branches 'spi/topic/atmel', 'spi/topic/config', 'spi/topic/dln2' and 'spi/topic/dw' into spi-next Merge remote-tracking branches 'spi/topic/falcon', 'spi/topic/fsf', 'spi/topic/fsl', 'spi/topic/fsl-dspi' and 'spi/topic/gpio' into spi-next Merge remote-tracking branches 'spi/topic/img-spfi', 'spi/topic/imx', 'spi/topic/inline', 'spi/topic/meson' and 'spi/topic/mxs' into spi-next Merge remote-tracking branches 'spi/topic/orion', 'spi/topic/pxa2xx', 'spi/topic/qup', 'spi/topic/rockchip' and 'spi/topic/samsung' into spi-next Merge remote-tracking branches 'spi/topic/sirf', 'spi/topic/spidev', 'spi/topic/st-ssc' and 'spi/topic/ti-qspi' into spi-next Merge remote-tracking branch 'spi/topic/xilinx' into spi-next Michal Simek (1): spi: Kconfig:
RE: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates
Bo Shen wrote: > Hi Peter, Hi! > On 02/07/2015 06:51 PM, Peter Rosin wrote: > > Mark Brown wrote: > >> On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote: > >> > >>> One thing remains a bit unclear, and that is the 500ppm deduction. > >>> Is that really warranted? The number was just pulled out of my hat... > >> > >> I don't really get what this is supposed to be protecting against. > >> > >>> + case SND_SOC_DAIFMT_CBM_CFS: > >>> + case SND_SOC_DAIFMT_CBM_CFM: > >>> + t.min = 8000; > >>> + t.max = ssc_p->mck_rate / mck_div / frame_size; > >>> + /* Take away 500ppm, just to be on the safe side. */ > >>> + t.max -= t.max / 2000; > >>> + t.openmin = t.openmax = 0; > >>> + t.integer = 0; > >>> + ret = snd_interval_refine(i, ); > >> > >> As I understand it this is a straight divider rather than something > >> that's doing dithering or anything else more fancy. Given that it > >> seems as well just to trust the clock rate we've got - we don't do > >> any error tracking with the clock API (perhaps we should) and for > >> many applications some degree of divergence from the nominal rate is > >> not > >> *too* bad for audio systems (for application specific values of "some" > >> and "too" of course). If it is just dividers I'm not sure the > >> situation is really improved materially by knocking off the top frequency. > >> > >> If we are doing something more fancy than divididing my analysis is > >> off base of course. > > > > I'm thinking that the SSC samples the selected BCK pin using the > > (possibly > > divided) peripheral clock. Getting too near the theoretical rate limit > > would be bad, if these two independent clocks drift the wrong way. At > > least that is my take on it, but I don't know the internal workings of the > > SSC, so... > > > > I was hoping that someone from Atmel could chime in? Maybe I'm totally > > Sorry for late response. No problem! > > off base, and the SSC is doing this completely differently? > > What you mean here? I am not sure I fully understand. The SSC spec list a maximum rate (which varies with the direction of various signals, ignoring that for the sake of this explanation). Lets assume that this maximum rate is 11MHz, derived from the peripheral clock which might be 66MHz. If you then try to input an 11MHz signal derived from some unrelated xtal you might think it should work. My theory was that the rate limit would be broken if the peripheral clock wasn't really 66MHz, but instead a few ppm lower than nominal, and the unrelated xtal was a few ppm higher than nominal. If this matters or not depends on how the SSC is implemented. There might be other reasons for not caring all that much about this fringe case, and just trust the nominal rates and limits. > > In our application, we're not near the limit. Therefore, it really > > doesn't matter much to us. > > > > Should I resend w/o the 500ppm deduction? > > > > Cheers, > > Peter > > > > Best Regards, > Bo Shen -- 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] idle/intel_powerclamp: Redesign idle injection to use bandwidth control mechanism
On Sun, Feb 8, 2015 at 8:49 PM, Preeti U Murthy wrote: > The powerclamp driver injects idle periods to stay within the thermal > constraints. > The driver does a fake idle by spawning per-cpu threads that call the mwait > instruction. This behavior of fake idle can confuse the other kernel > subsystems. > For instance it calls into the nohz tick handlers, which are meant to be > called > only by the idle thread. It sets the state of the tick in each cpu to idle and > stops the tick, when there are tasks on the runqueue. As a result the callers > of > idle_cpu()/ tick_nohz_tick_stopped() see different states of the cpu; while > the > former thinks that the cpu is busy, the latter thinks that it is idle. The > outcome > may be inconsistency in the scheduler/nohz states which can lead to serious > consequences. One of them was reported on this thread: > https://lkml.org/lkml/2014/12/11/365. > > Thomas posted out a patch to disable the powerclamp driver from calling into > the > tick nohz code which has taken care of the above regression for the moment. > However > powerclamp driver as a result, will not be able to inject idle periods due to > the > presence of periodic ticks. With the current design of fake idle, we cannot > move > towards a better solution. > https://lkml.org/lkml/2014/12/18/169 > > This patch aims at removing the concept of fake idle and instead makes the > cpus > truly idle by throttling the runqueues during the idle injection periods. The > situation > is in fact very similar to throttling of cfs_rqs when they exceed their > bandwidths. > The idle injection metrics can be mapped to the bandwidth control metrics > 'quota' and > 'period' to achieve the same result. When the powerclamping is begun or when > the > clamping controls have been modified, the bandwidth for the root task group > is set. > The 'quota' will be the amount of time that the system needs to be busy and > 'period' > will be the sum of this busy duration and the idle duration as calculated by > the driver. > This gets rid of per-cpu kthreads, control cpu, hotplug notifiers and > clamping mask since > the thread starting powerclamping will set the bandwidth and throttling of > all cpus will > automatically fall in place. None of the other cpus need be bothered about > this. This > simplifies the design of the driver. > > Of course this is only if the idle injection metrics can be conveniently > transformed > into bandwidth control metrics. There are a couple of other primary concerns > around if > doing the below two in this patch is valid. > a. This patch exports the functions to set the quota and period of task > groups. > b. This patch removes the constraint of not being able to set the root task > grp's bandwidth. > > Signed-off-by: Preeti U Murthy This doesn't compile. Missing forward declaration: drivers/thermal/intel_powerclamp.c: In function ‘window_size_set’: drivers/thermal/intel_powerclamp.c:160:2: error: implicit declaration of function ‘clamp_cpus’ [-Werror=implicit-function-declaration] clamp_cpus(); ^ drivers/thermal/intel_powerclamp.c: At top level: drivers/thermal/intel_powerclamp.c:355:12: error: static declaration of ‘clamp_cpus’ follows non-static declaration static int clamp_cpus(void) ^ drivers/thermal/intel_powerclamp.c:160:2: note: previous implicit declaration of ‘clamp_cpus’ was here clamp_cpus(); ^ Missing RUNTIME_INF definition (only appears in kernel/sched/sched.h from what I can see?): drivers/thermal/intel_powerclamp.c: In function ‘clamp_cpus’: drivers/thermal/intel_powerclamp.c:358:14: error: ‘RUNTIME_INF’ undeclared (first use in this function) u64 quota = RUNTIME_INF, period; ^ drivers/thermal/intel_powerclamp.c:358:14: note: each undeclared identifier is reported only once for each function it appears in Weird label placement that doesn't make sense: drivers/thermal/intel_powerclamp.c:364:2: error: a label can only be part of a statement and a declaration is not a statement int sleeptime; ^ drivers/thermal/intel_powerclamp.c:365:2: error: expected expression before ‘unsigned’ unsigned long target_jiffies; ^ drivers/thermal/intel_powerclamp.c:366:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] unsigned int guard; ^ drivers/thermal/intel_powerclamp.c:390:2: error: ‘target_jiffies’ undeclared (first use in this function) target_jiffies = roundup(jiffies, interval); ^ Missing debug variable: drivers/thermal/intel_powerclamp.c: In function ‘powerclamp_debug_show’: drivers/thermal/intel_powerclamp.c:598:41: error: ‘control_cpu’ undeclared (first use in this function) seq_printf(m, "controlling cpu: %d\n", control_cpu); ^ Missing label: drivers/thermal/intel_powerclamp.c: In function ‘powerclamp_init’: drivers/thermal/intel_powerclamp.c:649:3: error: label ‘exit_free’ used but not defined goto exit_free; ^
Re: [PATCH v2] staging: lustre: fix coding style errors in drivers/staging/lustre/lustre/libcfs/linux/linux-proc.c
On Sun, Feb 08, 2015 at 07:57:01PM +0200, Tal Shorer wrote: > Signed-off-by: Tal Shorer > --- > Decided not to #define the constants away because their addresses are > used later in the file. I don't understand what this means. > 1) The subject is crap (which coding style issues are you fixing). 2) The subject is too long. 3) Don't put the whole path in the subject. 4) There is no patch description. 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/
[PATCH v2 2/2] mmc: dw_mmc: Don't start command while data busy
We should wait for data busy here in non-volt-switch state. This may happend when sdio sends CMD53. Signed-off-by: Addy Ke --- drivers/mmc/host/dw_mmc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index b0b57e3..b40080d 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1007,6 +1007,13 @@ static void __dw_mci_start_request(struct dw_mci *host, mci_writel(host, BLKSIZ, data->blksz); } + /* +* We should wait for data busy here in non-volt-switch state. +* This may happend when sdio sends CMD53. +*/ + if (host->state != STATE_WAITING_CMD11_DONE) + dw_mci_wait_busy(slot); + cmdflags = dw_mci_prepare_command(slot->mmc, cmd); /* this is the first command, send the initialization clock */ -- 1.8.3.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/
[PATCH v2 0/2] about data busy
Addy Ke (2): mmc: dw_mmc: fix bug that cause 'Timeout sending command' mmc: dw_mmc: Don't start command while data busy drivers/mmc/host/dw_mmc.c | 35 +++ 1 file changed, 35 insertions(+) -- Changes in v2: - add new patch to handle data busy when start command - add cpu_relaxed, suggested by Daniel Kurtz 1.8.3.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/
[PATCH v2 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..b0b57e3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+static int dw_mci_card_busy(struct mmc_host *mmc);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
cmd, u32 arg)
cmd, arg, cmd_status);
}
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+ struct dw_mci *host = slot->host;
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
+ do {
+ if (!dw_mci_card_busy(slot->mmc))
+ return;
+ cpu_relax();
+ } while (time_before(jiffies, timeout));
+
+ dev_err(host->dev, "Data busy (status %#x)\n",
+ mci_readl(slot->host, STATUS));
+
+ /*
+* Data busy, this should not happend when mmc controller send command
+* to update card clocks in non-volt-switch state. If it happends, we
+* should reset controller to avoid getting "Timeout sending command".
+*/
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
+
+ /* Fail to reset controller or still data busy, WARN_ON! */
+ WARN_ON(dw_mci_card_busy(slot->mmc));
+}
+
static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
{
struct dw_mci *host = slot->host;
@@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
force_clkinit)
/* We must continue to set bit 28 in CMD until the change is complete */
if (host->state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
+ else
+ dw_mci_wait_busy(slot);
if (!clock) {
mci_writel(host, CLKENA, 0);
--
1.8.3.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/
[GIT PULL] regmap updates for v3.20
The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e: Linux 3.19-rc7 (2015-02-01 20:07:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-v3.20 for you to fetch changes up to 1aff0310ebdd42fa0045440cee19c5a8cfecf70c: Merge remote-tracking branches 'regmap/topic/ac97', 'regmap/topic/doc' and 'regmap/topic/smbus' into regmap-next (2015-02-08 11:16:11 +0800) regmap: Updates for v3.20 A very quiet release for regmap this time around: - Fix an endianness issue for I2C devices connected via SMBus where we were getting two layers both trying to do endianness handling. - Use a union to reduce the size of the regmap struct. - A couple of smaller fixes. Bintian Wang (1): regmap: correct the description of structure element in reg_field Guenter Roeck (2): regmap: Export regmap_get_val_endian regmap: Fix i2c word access when using SMBus access functions Mark Brown (3): regmap: ac97: Clean up indentation Merge remote-tracking branch 'regmap/topic/core' into regmap-next Merge remote-tracking branches 'regmap/topic/ac97', 'regmap/topic/doc' and 'regmap/topic/smbus' into regmap-next Wang, Yalin (1): regmap: Move spinlock_flags into the union drivers/base/regmap/internal.h| 10 +++-- drivers/base/regmap/regmap-ac97.c | 4 ++-- drivers/base/regmap/regmap-i2c.c | 46 ++- drivers/base/regmap/regmap.c | 7 +++--- include/linux/regmap.h| 2 +- 5 files changed, 60 insertions(+), 9 deletions(-) signature.asc Description: Digital signature
Re: [PATCH] net:ethernet:intel:Remove outdated fix me comment in the function,gb_acquire_swfw_sync_i210
Hi, Can you please leave full patch with git diff when you're replying to Nicks e-mails? Nick is banned in *@vger.kernel.org so we cannot see his patches and rest of the world is seeing only replyies to his e-mail. And it's really hard to test anything when we don't see changes. On 02/08/2015 08:21 PM, Jeff Kirsher wrote: > On Sun, 2015-02-08 at 00:21 -0500, Nicholas Krause wrote: >> Removes the outdated fix me comment in the >> function,gb_acquire_swfw_sync_i210 >> for setting the variables, i and timeout to the intended correct >> values for >> the function,gb_acquire_swfw_sync_i210 to function correctly. This >> comment is >> no longer due to these values having been no changed in the last few >> years and >> no known issues have been found for these variables being set to their >> current >> values. Due to this the comment can now be removed as the values set >> for these >> variables are known to be correct after years of no known issues or >> bugs related >> to their current values. >> >> Signed-off-by: Nicholas Krause >> --- >> drivers/net/ethernet/intel/igb/e1000_i210.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Thank Nick, I will add your patch to my queue. > -- Kind regards, b. -- 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 v17 1/7] mm: support madvise(MADV_FREE)
On Fri, Feb 06, 2015 at 10:29:18AM -0800, Shaohua Li wrote: > On Fri, Feb 06, 2015 at 02:51:03PM +0900, Minchan Kim wrote: > > Hi Shaohua, > > > > On Thu, Feb 05, 2015 at 04:33:11PM -0800, Shaohua Li wrote: > > > > > > Hi Minchan, > > > > > > Sorry to jump in this thread so later, and if some issues are discussed > > > before. > > > I'm interesting in this patch, so tried it here. I use a simple test with > > > > No problem at all. Interest is always win over ignorance. > > > > > jemalloc. Obviously this can improve performance when there is no memory > > > pressure. Did you try setup with memory pressure? > > > > Sure but it was not a huge memory system like yours. > > Yes, I'd like to check the symptom in memory pressure, so choose such test. > > > > In my test, jemalloc will map 61G vma, and use about 32G memory without > > > MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory > > > because > > > madvise doesn't reclaim the unused memory. If I disable swap (tweak your > > > patch > > > > Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely. > > right. > > > slightly to make it work without swap), I got oom. If swap is enabled, my > > > > You mean you modified anon aging logic so it works although there is no > > swap? > > If so, I have no idea why OOM happens. I guess it should free all of > > freeable > > pages during the aging so although system stall happens more, I don't expect > > OOM. Anyway, with MADV_FREE with no swap, we should consider more things > > about anonymous aging. > > In the patch, MADV_FREE will be disabled and fallback to DONTNEED if no swap > is > enabled. Our production environment doesn't enable swap, so I tried to delete > the 'no swap' check and make MADV_FREE always enabled regardless if swap is > enabled. I didn't change anything else. With such change, I saw oom > immediately. So definitely we have aging issue, the pages aren't reclaimed > fast. In current VM implementation, it doesn't age anonymous LRU list if we have no swap. That's the reason to drop freeing pages instantly. I think it could be enhanced later. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311591.html > > > > system is totally stalled because of swap activity. Without the MADV_FREE, > > > everything is ok. Considering we definitely don't want to waste too much > > > memory, a system with memory pressure is normal, so sounds MADV_FREE will > > > introduce big trouble here. > > > > > > Did you think about move the MADV_FREE pages to the head of inactive LRU, > > > so > > > they can be reclaimed easily? > > > > I think it's desirable if the page lived in active LRU. > > The reason I didn't that was caused by volatile ranges system call which > > was motivaion for MADV_FREE in my mind. > > In last LSF/MM, there was concern about data's hotness. > > Some of users want to keep that as it is in LRU position, others want to > > handle that as cold(tail of inactive list)/warm(head of inactive list)/ > > hot(head of active list), for example. > > The vrange syscall was just about volatiltiy, not depends on page hotness > > so the decision on my head was not to change LRU order and let's make new > > hotness advise if we need it later. > > > > However, MADV_FREE's main customer is allocators and afaik, they want > > to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, > > but we couldn't make sure so head of inactive is good compromise. > > Another concern about tail of inactive list is that there could be > > plenty of pages in there, which was asynchromos write-backed in > > previous reclaim path, not-yet reclaimed because of not being able > > to free the in softirq context of writeback. It means we ends up > > freeing more potential pages to become workingset in advance > > than pages VM already decided to evict. > > Yes, they are definitely cold pages. I thought We should make sure the > MADV_FREE pages are reclaimed first before other pages, at least in the anon > LRU list, though there might be difficult to determine if we should reclaim > writeback pages first or MADV_FREE pages first. Frankly speaking, the issue with writeback page is just hurdle of implementation, not design so if we could fix it, we might move cold pages into tail of the inactive LRU. I tried it but don't have time slot to continue these days. Hope to get a time to look soon. https://lkml.org/lkml/2014/7/1/628 Even, it wouldn't be critical problem although we couldn't fix the problem of writeback pages because they are already all cold pages so it might be not important to keep order in LRU so we could save working set and effort of VM to reclaim them at the cost of moving all of hinting pages into tail of the LRU whenever the syscall is called. However, significant problem from my mind is we couldn't make sure they are really cold pages. It would be true for allocators but it's cache-friendly pages so it might be better to discard tail
BUG: stuck on mmap_sem in 3.18.6
Python was running under ptrace-based sandbox "sydbox" used exherbo chroot. Kernel: 3.18.6 + my patch "mm: prevent endless growth of anon_vma hierarchy" (patch seems stable). [ 4674.087780] INFO: task python:25873 blocked for more than 120 seconds. [ 4674.087793] Tainted: G U 3.18.6-zurg+ #158 [ 4674.087797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4674.087801] python D 88041e2d2000 14176 25873 25630 0x0102 [ 4674.087817] 880286247b68 0086 8803d5fe6b40 00012000 [ 4674.087824] 880286247fd8 00012000 88040c16eb40 8803d5fe6b40 [ 4674.087830] 00030003 8803d5fe6b40 880362888e78 880362888e60 [ 4674.087836] Call Trace: [ 4674.087854] [] schedule+0x29/0x70 [ 4674.087865] [] rwsem_down_write_failed+0x1d5/0x2f0 [ 4674.087873] [] call_rwsem_down_write_failed+0x13/0x20 [ 4674.087881] [] ? down_write+0x31/0x50 [ 4674.087891] [] do_coredump+0x144/0xee0 [ 4674.087900] [] ? pick_next_task_fair+0x397/0x450 [ 4674.087909] [] ? __switch_to+0x1d6/0x5f0 [ 4674.087915] [] ? __schedule+0x3a6/0x880 [ 4674.087924] [] ? klist_remove+0x40/0xd0 [ 4674.087932] [] get_signal+0x298/0x6b0 [ 4674.087940] [] do_signal+0x28/0xbb0 [ 4674.087946] [] ? do_send_sig_info+0x5d/0x80 [ 4674.087955] [] do_notify_resume+0x69/0xb0 [ 4674.087963] [] int_signal+0x12/0x17 Maybe this guy did something wrong? [ 5153.460186] INFO: task khugepaged:262 blocked for more than 120 seconds. [ 5153.460198] Tainted: G U 3.18.6-zurg+ #158 [ 5153.460201] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 5153.460206] khugepaged D 88041e292000 14496 262 2 0x [ 5153.460220] 88040b99bcb0 0046 88040b994a40 00012000 [ 5153.460227] 88040b99bfd8 00012000 88040c16e300 88040b994a40 [ 5153.460233] 810d5c1b 88040b994a40 880362888e60 [ 5153.460240] Call Trace: [ 5153.460255] [] ? lock_timer_base.isra.41+0x2b/0x50 [ 5153.460264] [] schedule+0x29/0x70 [ 5153.460272] [] rwsem_down_read_failed+0xd5/0x120 [ 5153.460280] [] call_rwsem_down_read_failed+0x14/0x30 [ 5153.460287] [] ? down_read+0x24/0x30 [ 5153.460297] [] khugepaged+0x381/0x13f0 [ 5153.460309] [] ? abort_exclusive_wait+0xb0/0xb0 [ 5153.460316] [] ? maybe_pmd_mkwrite+0x30/0x30 [ 5153.460325] [] kthread+0xdb/0x100 [ 5153.460332] [] ? kthread_create_on_node+0x170/0x170 [ 5153.460340] [] ret_from_fork+0x7c/0xb0 [ 5153.460347] [] ? kthread_create_on_node+0x170/0x170 and a lot of ps stuck in /proc/*/cmdline (this thing should be killable) [ 5153.460713] INFO: task ps:26686 blocked for more than 120 seconds. [ 5153.460716] Tainted: G U 3.18.6-zurg+ #158 [ 5153.460718] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 5153.460721] ps D 88041e2d2000 14272 26686 26676 0x [ 5153.460730] 8802a991bc10 0086 88040bb3 00012000 [ 5153.460736] 8802a991bfd8 00012000 88040c16eb40 88040bb3 [ 5153.460741] 880385d29100 88040bb3 880362888e60 [ 5153.460747] Call Trace: [ 5153.460753] [] schedule+0x29/0x70 [ 5153.460760] [] rwsem_down_read_failed+0xd5/0x120 [ 5153.460765] [] ? single_open+0x61/0xb0 [ 5153.460770] [] call_rwsem_down_read_failed+0x14/0x30 [ 5153.460777] [] ? down_read+0x24/0x30 [ 5153.460784] [] __access_remote_vm+0x42/0x2e0 [ 5153.460791] [] ? dput+0x2a/0x1b0 [ 5153.460799] [] access_process_vm+0x50/0x70 [ 5153.460806] [] get_cmdline+0x5c/0x100 [ 5153.460812] [] proc_pid_cmdline+0x2b/0x50 [ 5153.460817] [] proc_single_show+0x54/0xa0 [ 5153.460822] [] seq_read+0xcd/0x3b0 [ 5153.460828] [] vfs_read+0x98/0x160 [ 5153.460833] [] SyS_read+0x46/0xb0 [ 5153.460841] [] system_call_fastpath+0x16/0x1b [ 5187.935448] SysRq : Show Blocked State [ 5187.935462] taskPC stack pid father [ 5187.935474] khugepaged D 88041e292000 14496 262 2 0x [ 5187.935489] 88040b99bcb0 0046 88040b994a40 00012000 [ 5187.935496] 88040b99bfd8 00012000 88040c16e300 88040b994a40 [ 5187.935502] 810d5c1b 88040b994a40 880362888e60 [ 5187.935508] Call Trace: [ 5187.935524] [] ? lock_timer_base.isra.41+0x2b/0x50 [ 5187.935533] [] schedule+0x29/0x70 [ 5187.935541] [] rwsem_down_read_failed+0xd5/0x120 [ 5187.935549] [] call_rwsem_down_read_failed+0x14/0x30 [ 5187.935556] [] ? down_read+0x24/0x30 [ 5187.935566] [] khugepaged+0x381/0x13f0 [ 5187.935578] [] ? abort_exclusive_wait+0xb0/0xb0 [ 5187.935585] [] ? maybe_pmd_mkwrite+0x30/0x30 [ 5187.935593] [] kthread+0xdb/0x100 [ 5187.935601] [] ? kthread_create_on_node+0x170/0x170 [ 5187.935609] [] ret_from_fork+0x7c/0xb0 [ 5187.935615] [] ? kthread_create_on_node+0x170/0x170 [ 5187.935688]
[PATCH v2 4/7] staging: ft1000: ft1000-usb: remove unnecessary parentheses
Remove checkpatch.pl warning
WARNING: Unnecessary parentheses - maybe == should be = ?
+ if ((dev->app_info[i].fileobject == NULL))
Signed-off-by: Pushpendra Singh
---
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index c8d2782..25166db 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -317,7 +317,7 @@ static int ft1000_open(struct inode *inode, struct file
*file)
/* Search for available application info block */
for (i = 0; i < MAX_NUM_APP; i++) {
- if ((dev->app_info[i].fileobject == NULL)) {
+ if (dev->app_info[i].fileobject == NULL) {
break;
}
}
--
1.9.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 3/7] staging: ft1000: ft1000-pcmcia: remove unnecessary parentheses
Remove checkpatch.pl warning
WARNING: Unnecessary parentheses
+ if ((tempword != *ppseudohdr)) {
Signed-off-by: Pushpendra Singh
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 9d0fd6c..26659d0 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -911,7 +911,7 @@ static bool ft1000_receive_cmd(struct net_device *dev, u16
*pbuffer,
tempword = *ppseudohdr++;
for (i = 1; i < 7; i++)
tempword ^= *ppseudohdr++;
- if ((tempword != *ppseudohdr)) {
+ if (tempword != *ppseudohdr) {
pr_debug("Pseudo header checksum mismatch\n");
/* Drop this message */
return false;
--
1.9.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 6/7] staging: ft1000: ft1000-usb: remove conditional statement
their is no statements for if condition, but else have so instead
of using else condition ,use a single condition statement if(!qtype)
Signed-off-by: Puhspendra Singh
---
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index bd0d25c..a6dfe65 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -588,8 +588,7 @@ static long ft1000_ioctl(struct file *file, unsigned int
command,
/* Check message qtype type which is the lower
byte within qos_class */
qtype = ntohs(dpram_data->pseudohdr.qos_class)
& 0xff;
/* pr_debug("qtype = %d\n", qtype); */
- if (qtype) {
- } else {
+ if (!qtype) {
/* Put message into Slow Queue */
/* Only put a message into the DPRAM if
msg doorbell is available */
status =
ft1000_read_register(ft1000dev, , FT1000_REG_DOORBELL);
--
1.9.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 7/7] staging: ft1000: ft1000-usb: remove unnecessary out of memory warning
Remove checkpatch.pl warning
WARNING: Possible unnecessary 'out of memory' message
+ if (skb == NULL) {
+ pr_debug("No Network buffers available\n");
Signed-off-by: Pushpendra Singh
---
drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
index f0ac438..690032b 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_hw.c
@@ -843,7 +843,6 @@ static int ft1000_copy_up_pkt(struct urb *urb)
skb = dev_alloc_skb(len + 12 + 2);
if (skb == NULL) {
- pr_debug("No Network buffers available\n");
info->stats.rx_errors++;
ft1000_submit_rx_urb(info);
return -1;
--
1.9.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 5/7] staging: ft1000: ft1000-usb: removed unnecessary braces
Removed Checkpatch.pl warning
WARNING: braces {} are not necessary for single statement blocks
+ if (dev->app_info[i].fileobject == NULL) {
+ break;
+ }
Signed-off-by: Pushpendra Singh
---
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index 25166db..bd0d25c 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -317,9 +317,8 @@ static int ft1000_open(struct inode *inode, struct file
*file)
/* Search for available application info block */
for (i = 0; i < MAX_NUM_APP; i++) {
- if (dev->app_info[i].fileobject == NULL) {
+ if (dev->app_info[i].fileobject == NULL)
break;
- }
}
/* Fail due to lack of application info block */
@@ -575,9 +574,8 @@ static long ft1000_ioctl(struct file *file, unsigned int
command,
} else {
/* Check if this message came from a registered
application */
for (i = 0; i < MAX_NUM_APP; i++) {
- if (ft1000dev->app_info[i].fileobject
== >f_owner) {
+ if (ft1000dev->app_info[i].fileobject
== >f_owner)
break;
- }
}
if (i == MAX_NUM_APP) {
pr_debug("No matching application
fileobject\n");
@@ -629,9 +627,8 @@ static long ft1000_ioctl(struct file *file, unsigned int
command,
pmsg = (u16
*)_data->pseudohdr;
ppseudo_hdr = (struct
pseudo_hdr *)pmsg;
total_len = msgsz+2;
- if (total_len & 0x1) {
+ if (total_len & 0x1)
total_len++;
- }
/* Insert slow queue sequence
number */
ppseudo_hdr->seq_num =
info->squeseqnum++;
--
1.9.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 1/7] staging: ft1000: ft1000-pcmcia: removed unnecessary braces
Remove checkpatch.pl warning
WARNING: braces {} are not necessary for any arm of this statement
+ if (tempword & 0x1f) {
[...]
+ } else {
[...]
Signed-off-by: Pushpendra Singh
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index e7072bc..374db6d 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -1947,11 +1947,10 @@ static irqreturn_t ft1000_interrupt(int irq, void
*dev_id)
ft1000_read_reg(dev,
FT1000_REG_MAG_DFSR);
}
- if (tempword & 0x1f) {
+ if (tempword & 0x1f)
ft1000_copy_up_pkt(dev);
- } else {
+ else
break;
- }
cnt++;
} while (cnt < MAX_RCV_LOOP);
--
1.9.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/7] staging: ft1000: ft1000-pcmcia: add blank line after declarations
Removed Checkpatch.pl warning
WARNING: Missing a blank line after declarations
+ struct ft1000_info *ft_info;
+ ft_info = netdev_priv(dev);
Signed-off-by: Pushpendra Singh
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 374db6d..9d0fd6c 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -2006,8 +2006,8 @@ static void ft1000_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
struct ft1000_info *ft_info;
- ft_info = netdev_priv(dev);
+ ft_info = netdev_priv(dev);
strlcpy(info->driver, "ft1000", sizeof(info->driver));
snprintf(info->bus_info, sizeof(info->bus_info), "PCMCIA 0x%lx",
dev->base_addr);
--
1.9.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 v8 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Mon, Feb 09, 2015 at 06:53:31AM +, Hanjun Guo wrote:
> On 2015年02月09日 14:34, Will Deacon wrote:
> > On Mon, Feb 02, 2015 at 12:45:43PM +, Hanjun Guo wrote:
> >> Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
> >> used, and then register device's gsi with the core IRQ subsystem.
> >>
> >> acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
> >> since gsi is unique in the system, so use hwirq number directly
> >> for the mapping.
> >>
> >> We are going to implement stacked domains when GICv2m, GICv3, ITS
> >> support are added.
> >>
> >> CC: Marc Zyngier
> >> Originally-by: Amit Daniel Kachhap
> >> Tested-by: Suravee Suthikulpanit
> >> Tested-by: Yijing Wang
> >> Tested-by: Mark Langsdorf
> >> Tested-by: Jon Masters
> >> Tested-by: Timur Tabi
> >> Signed-off-by: Hanjun Guo
> >> ---
> >> arch/arm64/kernel/acpi.c | 73
> >>
> >> drivers/acpi/bus.c | 3 ++
> >> include/linux/acpi.h | 1 +
> >> 3 files changed, 77 insertions(+)
> >>
> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >> index f80caef..f86a982 100644
> >> --- a/arch/arm64/kernel/acpi.c
> >> +++ b/arch/arm64/kernel/acpi.c
> >> @@ -38,6 +38,12 @@ EXPORT_SYMBOL(acpi_pci_disabled);
> >> static int enabled_cpus; /* Processors (GICC) with enabled flag in MADT
> >> */
> >>
> >> /*
> >> + * Since we're on ARM, the default interrupt routing model
> >> + * clearly has to be GIC.
> >> + */
> >> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
> >> +
> >> +/*
> >>* __acpi_map_table() will be called before page_init(), so
> >> early_ioremap()
> >>* or early_memremap() should be called here to for ACPI table mapping.
> >>*/
> >> @@ -185,6 +191,73 @@ void __init acpi_init_cpus(void)
> >>pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> >> }
> >>
> >> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> >> +{
> >> + *irq = irq_find_mapping(NULL, gsi);
> >> +
> >> + return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> >> +
> >> +/*
> >> + * success: return IRQ number (>0)
> >> + * failure: return =< 0
> >> + */
> >> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int
> >> polarity)
> >> +{
> >> + unsigned int irq;
> >> + unsigned int irq_type;
> >> +
> >> + /*
> >> + * ACPI have no bindings to indicate SPI or PPI, so we
> >> + * use different mappings from DT in ACPI.
> >> + *
> >> + * For FDT
> >> + * PPI interrupt: in the range [0, 15];
> >> + * SPI interrupt: in the range [0, 987];
> >> + *
> >> + * For ACPI, GSI should be unique so using
> >> + * the hwirq directly for the mapping:
> >> + * PPI interrupt: in the range [16, 31];
> >> + * SPI interrupt: in the range [32, 1019];
> >> + */
> >> +
> >> + if (trigger == ACPI_EDGE_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_LOW)
> >> + irq_type = IRQ_TYPE_EDGE_FALLING;
> >> + else if (trigger == ACPI_EDGE_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_HIGH)
> >> + irq_type = IRQ_TYPE_EDGE_RISING;
> >> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_LOW)
> >> + irq_type = IRQ_TYPE_LEVEL_LOW;
> >> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> >> + polarity == ACPI_ACTIVE_HIGH)
> >> + irq_type = IRQ_TYPE_LEVEL_HIGH;
> >> + else
> >> + irq_type = IRQ_TYPE_NONE;
> >> +
> >> + /*
> >> + * Since only one GIC is supported in ACPI 5.0, we can
> >> + * create mapping refer to the default domain
> >> + */
> >> + irq = irq_create_mapping(NULL, gsi);
> >> + if (!irq)
> >> + return irq;
> >> +
> >> + /* Set irq type if specified and different than the current one */
> >> + if (irq_type != IRQ_TYPE_NONE &&
> >> + irq_type != irq_get_trigger_type(irq))
> >> + irq_set_irq_type(irq, irq_type);
> >> + return irq;
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> >> +
> >> +void acpi_unregister_gsi(u32 gsi)
> >> +{
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> >> +
> >> static int __init acpi_parse_fadt(struct acpi_table_header *table)
> >> {
> >>struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> >
> > Does this code *have* to sit under arch/arm64? I can't see anything
> > architecture-specific about it and the bulk of the functions map directly
> > onto irq domain callbacks. I know that the answer is probably "we can fix
> > that in the future", but it doesn't seem like a huge amount of effort to
> > get the right abstractions in place from the beginning so that we don't
> > have to churn this stuff later on.
>
> Do you mean move acpi_register_gsi()/acpi_unregister_gsi() to irqdomain
> related file?
>
> Since x86 and IA64 have their arch specific acpi_register_gsi()
> /acpi_unregister_gsi(), we will got compile errors on x86 and IA64
>
Re: [PATCH] xen-scsiback: some modifications about code comment
On 02/07/2015 04:31 AM, Rudy Zhang wrote:
From: Tao Chen
Signed-off-by: Tao Chen
Are some white space fixes in comments really worth a patch?
Juergen
---
drivers/xen/xen-scsiback.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 3e32146..59f09fd 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -83,7 +83,7 @@ struct ids_tuple {
struct v2p_entry {
struct ids_tuple v; /* translate from */
- struct scsiback_tpg *tpg; /* translate to */
+ struct scsiback_tpg *tpg; /* translate to */
unsigned int lun;
struct kref kref;
struct list_head l;
@@ -525,7 +525,7 @@ static int scsiback_gnttab_data_map(struct vscsiif_request
*ring_req,
}
}
- /* free of (sgl) in fast_flush_area()*/
+ /* free of (sgl) in fast_flush_area() */
pending_req->sgl = kmalloc_array(nr_segments,
sizeof(struct scatterlist), GFP_KERNEL);
if (!pending_req->sgl)
@@ -1084,7 +1084,7 @@ static void scsiback_do_1lun_hotplug(struct vscsibk_info
*info, int op,
}
}
break;
- /*When it is necessary, processing is added here.*/
+ /* When it is necessary, processing is added here. */
default:
break;
}
@@ -1475,8 +1475,8 @@ static u32 scsiback_tpg_get_inst_index(struct
se_portal_group *se_tpg)
static int scsiback_check_stop_free(struct se_cmd *se_cmd)
{
/*
-* Do not release struct se_cmd's containing a valid TMR
-* pointer. These will be released directly in scsiback_device_action()
+* Do not release struct se_cmd's containing a valid TMR pointer.
+* These will be released directly in scsiback_device_action()
* with transport_generic_free_cmd().
*/
if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB)
@@ -1642,7 +1642,7 @@ static int scsiback_make_nexus(struct scsiback_tpg *tpg,
return -ENOMEM;
}
/*
-* Initialize the struct se_session pointer
+* Initialize the struct se_session pointer
*/
tv_nexus->tvn_se_sess = transport_init_session(TARGET_PROT_NORMAL);
if (IS_ERR(tv_nexus->tvn_se_sess)) {
@@ -1759,7 +1759,7 @@ static ssize_t scsiback_tpg_store_nexus(struct
se_portal_group *se_tpg,
unsigned char i_port[VSCSI_NAMELEN], *ptr, *port_ptr;
int ret;
/*
-* Shutdown the active I_T nexus if 'NULL' is passed..
+* Shutdown the active I_T nexus if 'NULL' is passed.
*/
if (!strncmp(page, "NULL", 4)) {
ret = scsiback_drop_nexus(tpg);
@@ -1930,7 +1930,7 @@ static void scsiback_drop_tpg(struct se_portal_group
*se_tpg)
*/
scsiback_drop_nexus(tpg);
/*
-* Deregister the se_tpg from TCM..
+* Deregister the se_tpg from TCM.
*/
core_tpg_deregister(se_tpg);
kfree(tpg);
--
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] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
On 02/09/2015 03:56 PM, Addy wrote:
>
>
> On 2015.02.09 12:51, Ulf Hansson wrote:
>> On 5 February 2015 at 12:13, Addy Ke wrote:
>>> Because of some uncertain factors, such as worse card or worse hardware,
>>> DAT[3:0](the data lines) may be pulled down by card, and mmc controller
>>> will be in busy state. This should not happend when mmc controller
>>> send command to update card clocks. If this happends, mci_send_cmd will
>>> be failed and we will get 'Timeout sending command', and then system will
>>> be blocked. To avoid this, we need reset mmc controller.
I know that it needs to check whether card is busy or not, before clock-off.
This patch seems to related with it. right?
Best Regards,
Jaehoon Chung
>>>
>>> Signed-off-by: Addy Ke
>>
>> Hi Addy,
>>
>> Should I consider $subject patch as a better option to the one below?
> No:
> This patch fix the bug, which can be found by script:
> cd /sys/bus/platform/drivers/dwmmc_rockchip
> for i in $(seq 1 1); do
> echo "" $i
> echo ff0c.dwmmc > unbind
> sleep .5
> echo ff0c.dwmmc > bind
> sleep 2
> done
>
>> [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY
> This patch is for tuning issue: we should delay until card go to idle state,
> when the previous command return error.
>> https://lkml.org/lkml/2015/1/13/562
>>
>> Kind regards
>> Uffe
>>
>>
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 23 +++
>>> 1 file changed, 23 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 4d2e3c2..b1d6dfb 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -100,6 +100,7 @@ struct idmac_desc {
>>> };
>>> #endif /* CONFIG_MMC_DW_IDMAC */
>>>
>>> +static int dw_mci_card_busy(struct mmc_host *mmc);
>>> static bool dw_mci_reset(struct dw_mci *host);
>>> static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>>>
>>> @@ -888,6 +889,26 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
>>> cmd, u32 arg)
>>> cmd, arg, cmd_status);
>>> }
>>>
>>> +static void dw_mci_wait_busy(struct dw_mci_slot *slot)
>>> +{
>>> + struct dw_mci *host = slot->host;
>>> + unsigned long timeout = jiffies + msecs_to_jiffies(500);
>>> +
>>> + while (time_before(jiffies, timeout)) {
>>> + if (!dw_mci_card_busy(slot->mmc))
>>> + return;
>>> + }
>>> + dev_err(host->dev, "Data busy (status %#x)\n",
>>> + mci_readl(slot->host, STATUS));
>>> +
>>> + /*
>>> +* Data busy, this should not happend when mmc controller send
>>> command
>>> +* to update card clocks in non-volt-switch state. If it happends,
>>> we
>>> +* should reset controller to avoid getting "Timeout sending
>>> command".
>>> +*/
>>> + dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
>>> +}
>>> +
>>> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
>>> {
>>> struct dw_mci *host = slot->host;
>>> @@ -899,6 +920,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
>>> bool force_clkinit)
>>> /* We must continue to set bit 28 in CMD until the change is
>>> complete */
>>> if (host->state == STATE_WAITING_CMD11_DONE)
>>> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
>>> + else
>>> + dw_mci_wait_busy(slot);
>>>
>>> if (!clock) {
>>> mci_writel(host, CLKENA, 0);
>>> --
>>> 1.8.3.2
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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/
Re: [f2fs-dev] [PATCH 5/5 v4] f2fs: introduce a batched trim
On Sat, Feb 07, 2015 at 05:57:46PM +0200, Leon Romanovsky wrote: > Hi Jaegeuk, > > > + /* for batched trimming */ > > + int trim_sections; /* # of sections to trim */ > I would like to suggest to declare trim_sections variable as an > unsigned int and not int, since it can't be negative by definition. > What do you think about it? Hi Leon, No problem. :) I'll change that and merge the patch. 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 V5 6/8] USB: f81232: clarify f81232_ioctl()
Hello, Sergei Shtylyov 於 2015/2/6 下午 08:21 寫道: We extract TIOCGSERIAL section in f81232_ioctl() to f81232_get_serial_info() to make it clarify You're also changing 'ser.baud_rate' from 460800 to 115200. And explicitly overriding some previously initialized to 0 fields. F81232 max baudrate is only 115200bps, so I set it for 1.8432MHz/16 = 115200. We had add some closing time referenced from serial_core.c. The default value is: port->close_delay = HZ / 2; /* .5 seconds */ port->closing_wait= 30 * HZ;/* 30 seconds */ We had increasing close_delay about 10x to port->close_delay = 5 * HZ ; The f81232_set_mctrl() replace set_control_lines() to do MCR control so we clean-up the set_control_lines() function. I don't see where are you doing this... This text is my patch V5 5/8 second section. I had wrong operation of copy & paste. It's doesn't need for this patch, sorry for it. -- With Best Regards, Peter Hung -- 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] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
On 2015.02.09 12:51, Ulf Hansson wrote:
On 5 February 2015 at 12:13, Addy Ke wrote:
Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke
Hi Addy,
Should I consider $subject patch as a better option to the one below?
No:
This patch fix the bug, which can be found by script:
cd /sys/bus/platform/drivers/dwmmc_rockchip
for i in $(seq 1 1); do
echo "" $i
echo ff0c.dwmmc > unbind
sleep .5
echo ff0c.dwmmc > bind
sleep 2
done
[PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY
This patch is for tuning issue: we should delay until card go to idle
state, when the previous command return error.
https://lkml.org/lkml/2015/1/13/562
Kind regards
Uffe
---
drivers/mmc/host/dw_mmc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..b1d6dfb 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+static int dw_mci_card_busy(struct mmc_host *mmc);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -888,6 +889,26 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
cmd, u32 arg)
cmd, arg, cmd_status);
}
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+ struct dw_mci *host = slot->host;
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
+ while (time_before(jiffies, timeout)) {
+ if (!dw_mci_card_busy(slot->mmc))
+ return;
+ }
+ dev_err(host->dev, "Data busy (status %#x)\n",
+ mci_readl(slot->host, STATUS));
+
+ /*
+* Data busy, this should not happend when mmc controller send command
+* to update card clocks in non-volt-switch state. If it happends, we
+* should reset controller to avoid getting "Timeout sending command".
+*/
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
+}
+
static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
{
struct dw_mci *host = slot->host;
@@ -899,6 +920,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
force_clkinit)
/* We must continue to set bit 28 in CMD until the change is complete
*/
if (host->state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
+ else
+ dw_mci_wait_busy(slot);
if (!clock) {
mci_writel(host, CLKENA, 0);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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/
Re: [PATCH v8 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC
On Mon, Feb 02, 2015 at 12:45:42PM +, Hanjun Guo wrote:
> Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
> from the GICC Structure introduced by ACPI 5.1.
>
> MPIDR is the CPU hardware ID as local APIC ID on x86 platform, so we use
> MPIDR not the GIC CPU interface ID to identify CPUs.
>
> Further steps would typedef a phys_id_t for in arch code(with
> appropriate size and a corresponding invalid value, say ~0) and use that
> instead of an int in drivers/acpi/processor_core.c to store phys_id, then
> no need for mpidr packing.
>
> CC: Rafael J. Wysocki
> CC: Catalin Marinas
> CC: Will Deacon
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Signed-off-by: Hanjun Guo
> ---
> arch/arm64/include/asm/acpi.h | 30 ++
> drivers/acpi/processor_core.c | 37 +
> 2 files changed, 67 insertions(+)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 8984aa5..7e825b9 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -12,6 +12,8 @@
> #ifndef _ASM_ACPI_H
> #define _ASM_ACPI_H
>
> +#include
> +
> /* Basic configuration for ACPI */
> #ifdef CONFIG_ACPI
> #define acpi_strict 1/* No out-of-spec workarounds on ARM64 */
> @@ -45,6 +47,34 @@ static inline void enable_acpi(void)
> acpi_noirq = 0;
> }
>
> +/* MPIDR value provided in GICC structure is 64 bits, but the
> + * existing phys_id (CPU hardware ID) using in acpi processor
> + * driver is 32-bit, to conform to the same datatype we need
> + * to repack the GICC structure MPIDR.
> + *
> + * bits other than following 32 bits are defined as 0, so it
> + * will be no information lost after repacked.
> + *
> + * Bits [0:7] Aff0;
> + * Bits [8:15] Aff1;
> + * Bits [16:23] Aff2;
> + * Bits [32:39] Aff3;
> + */
> +static inline u32 pack_mpidr(u64 mpidr)
> +{
> + return (u32) ((mpidr & 0xff) >> 8) | mpidr;
> +}
I'm a bit puzzled by this packing:
- Bit 31 of the MPIDR is RES1. Do we need to mask it out first?
- How does this work for uniprocessor systems where bit 30 is set?
- Similarly for mythical multi-threaded implementations with bit 24 set.
Will
--
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 v8 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On 2015年02月09日 14:34, Will Deacon wrote:
On Mon, Feb 02, 2015 at 12:45:43PM +, Hanjun Guo wrote:
Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
used, and then register device's gsi with the core IRQ subsystem.
acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
since gsi is unique in the system, so use hwirq number directly
for the mapping.
We are going to implement stacked domains when GICv2m, GICv3, ITS
support are added.
CC: Marc Zyngier
Originally-by: Amit Daniel Kachhap
Tested-by: Suravee Suthikulpanit
Tested-by: Yijing Wang
Tested-by: Mark Langsdorf
Tested-by: Jon Masters
Tested-by: Timur Tabi
Signed-off-by: Hanjun Guo
---
arch/arm64/kernel/acpi.c | 73
drivers/acpi/bus.c | 3 ++
include/linux/acpi.h | 1 +
3 files changed, 77 insertions(+)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index f80caef..f86a982 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -38,6 +38,12 @@ EXPORT_SYMBOL(acpi_pci_disabled);
static int enabled_cpus; /* Processors (GICC) with enabled flag in MADT
*/
/*
+ * Since we're on ARM, the default interrupt routing model
+ * clearly has to be GIC.
+ */
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
+
+/*
* __acpi_map_table() will be called before page_init(), so early_ioremap()
* or early_memremap() should be called here to for ACPI table mapping.
*/
@@ -185,6 +191,73 @@ void __init acpi_init_cpus(void)
pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
}
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+ *irq = irq_find_mapping(NULL, gsi);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+{
+ unsigned int irq;
+ unsigned int irq_type;
+
+ /*
+* ACPI have no bindings to indicate SPI or PPI, so we
+* use different mappings from DT in ACPI.
+*
+* For FDT
+* PPI interrupt: in the range [0, 15];
+* SPI interrupt: in the range [0, 987];
+*
+* For ACPI, GSI should be unique so using
+* the hwirq directly for the mapping:
+* PPI interrupt: in the range [16, 31];
+* SPI interrupt: in the range [32, 1019];
+*/
+
+ if (trigger == ACPI_EDGE_SENSITIVE &&
+ polarity == ACPI_ACTIVE_LOW)
+ irq_type = IRQ_TYPE_EDGE_FALLING;
+ else if (trigger == ACPI_EDGE_SENSITIVE &&
+ polarity == ACPI_ACTIVE_HIGH)
+ irq_type = IRQ_TYPE_EDGE_RISING;
+ else if (trigger == ACPI_LEVEL_SENSITIVE &&
+ polarity == ACPI_ACTIVE_LOW)
+ irq_type = IRQ_TYPE_LEVEL_LOW;
+ else if (trigger == ACPI_LEVEL_SENSITIVE &&
+ polarity == ACPI_ACTIVE_HIGH)
+ irq_type = IRQ_TYPE_LEVEL_HIGH;
+ else
+ irq_type = IRQ_TYPE_NONE;
+
+ /*
+* Since only one GIC is supported in ACPI 5.0, we can
+* create mapping refer to the default domain
+*/
+ irq = irq_create_mapping(NULL, gsi);
+ if (!irq)
+ return irq;
+
+ /* Set irq type if specified and different than the current one */
+ if (irq_type != IRQ_TYPE_NONE &&
+ irq_type != irq_get_trigger_type(irq))
+ irq_set_irq_type(irq, irq_type);
+ return irq;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
static int __init acpi_parse_fadt(struct acpi_table_header *table)
{
struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
Does this code *have* to sit under arch/arm64? I can't see anything
architecture-specific about it and the bulk of the functions map directly
onto irq domain callbacks. I know that the answer is probably "we can fix
that in the future", but it doesn't seem like a huge amount of effort to
get the right abstractions in place from the beginning so that we don't
have to churn this stuff later on.
Do you mean move acpi_register_gsi()/acpi_unregister_gsi() to irqdomain
related file?
Since x86 and IA64 have their arch specific acpi_register_gsi()
/acpi_unregister_gsi(), we will got compile errors on x86 and IA64
platforms.
Thanks
Hanjun
--
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: MADV_DONTNEED semantics? Was: [RFC PATCH] mm: madvise: Ignore repeated MADV_DONTNEED hints
On Fri, Feb 06, 2015 at 04:57:50PM +0100, Michael Kerrisk (man-pages) wrote: > Hi Michael > > On 02/05/2015 04:41 PM, Michal Hocko wrote: > > On Wed 04-02-15 20:24:27, Michael Kerrisk wrote: > > [...] > >> So, how about this text: > >> > >> After a successful MADV_DONTNEED operation, the seman‐ > >> tics of memory access in the specified region are > >> changed: subsequent accesses of pages in the range > >> will succeed, but will result in either reloading of > >> the memory contents from the underlying mapped file > > > > " > > result in either providing the up-to-date contents of the underlying > > mapped file > > " > > Thanks! I did something like that. See below. > > > Would be more precise IMO because reload might be interpreted as a major > > fault which is not necessarily the case (see below). > > > >> (for shared file mappings, shared anonymous mappings, > >> and shmem-based techniques such as System V shared > >> memory segments) or zero-fill-on-demand pages for > >> anonymous private mappings. > > > > Yes, this wording is better because many users are not aware of > > MAP_ANON|MAP_SHARED being file backed in fact and mmap man page doesn't > > mention that. > > (Michal, would you have a text to propose to add to the mmap(2) page? > Maybe it would be useful to add something there.) > > > > > I am just wondering whether it makes sense to mention that MADV_DONTNEED > > for shared mappings might be surprising and not freeing the backing > > pages thus not really freeing memory until there is a memory > > pressure. But maybe this is too implementation specific for a man > > page. What about the following wording on top of yours? > > " > > Please note that the MADV_DONTNEED hint on shared mappings might not > > lead to immediate freeing of pages in the range. The kernel is free to > > delay this until an appropriate moment. RSS of the calling process will > > be reduced however. > > " > > Thanks! I added this, but dropped in the word "immediately" in the last > sentence, since I assume that was implied. So now we have: > > After a successful MADV_DONTNEED operation, the seman‐ > tics of memory access in the specified region are > changed: subsequent accesses of pages in the range will > succeed, but will result in either repopulating the mem‐ > ory contents from the up-to-date contents of the under‐ > lying mapped file (for shared file mappings, shared > anonymous mappings, and shmem-based techniques such as > System V shared memory segments) or zero-fill-on-demand > pages for anonymous private mappings. > > Note that, when applied to shared mappings, MADV_DONT‐ > NEED might not lead to immediate freeing of the pages in > the range. The kernel is free to delay freeing the > pages until an appropriate moment. The resident set > size (RSS) of the calling process will be immediately > reduced however. Looks good. So, I can parse it that anonymous private mappings will lead to immediate freeing of the pages in the range so it's clearly different with MADV_FREE. > > The current draft of the page can be found in a branch, > http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_madvise > > Thanks, > > Michael > > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ -- Kind regards, Minchan Kim -- 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: MADV_DONTNEED semantics? Was: [RFC PATCH] mm: madvise: Ignore repeated MADV_DONTNEED hints
Hello, Michael On Fri, Feb 06, 2015 at 04:41:12PM +0100, Michael Kerrisk (man-pages) wrote: > On 02/05/2015 02:07 AM, Minchan Kim wrote: > > Hello, > > > > On Wed, Feb 04, 2015 at 08:24:27PM +0100, Michael Kerrisk (man-pages) wrote: > >> On 4 February 2015 at 18:02, Vlastimil Babka wrote: > >>> On 02/04/2015 03:00 PM, Michael Kerrisk (man-pages) wrote: > > Hello Vlastimil, > > On 4 February 2015 at 14:46, Vlastimil Babka wrote: > >>> > >>> - that covers mlocking ok, not sure if the rest fits the "shared > >>> pages" > >>> case > >>> though. I dont see any check for other kinds of shared pages in the > >>> code. > >> > >> > >> Agreed. "shared" here seems confused. I've removed it. And I've > >> added mention of "Huge TLB pages" for this error. > > > > > > Thanks. > > > I also added those cases for MADV_REMOVE, BTW. > >>> > >>> > >>> Right. There's also the following for MADV_REMOVE that needs updating: > >>> > >>> "Currently, only shmfs/tmpfs supports this; other filesystems return with > >>> the error ENOSYS." > >>> > >>> - it's not just shmem/tmpfs anymore. It should be best to refer to > >>> fallocate(2) option FALLOC_FL_PUNCH_HOLE which seems to be (more) up to > >>> date. > >>> > >>> - AFAICS it doesn't return ENOSYS but EOPNOTSUPP. Also neither error code > >>> is > >>> listed in the ERRORS section. > >> > >> Yup, I recently added that as well, based on a patch from Jan Chaloupka. > >> > > - The word "will result" did sound as a guarantee at least to me. So > > here it > > could be changed to "may result (unless the advice is ignored)"? > > It's too late to fix documentation. Applications already depends on > the > beheviour. > >>> > >>> Right, so as long as they check for EINVAL, it should be safe. It > >>> appears > >>> that > >>> jemalloc does. > >> > >> So, first a brief question: in the cases where the call does not error > >> out, > >> are we agreed that in the current implementation, MADV_DONTNEED will > >> always result in zero-filled pages when the region is faulted back in > >> (when we consider pages that are not backed by a file)? > > > > I'd agree at this point. > > Thanks for the confirmation. > > > Also we should probably mention anonymously shared pages (shmem). I > > think > > they behave the same as file here. > > You mean tmpfs here, right? (I don't keep all of the synonyms straight.) > >>> > >>> shmem is tmpfs (that by itself would fit under "files" just fine), but > >>> also > >>> sys V segments created by shmget(2) and also mappings created by mmap with > >>> MAP_SHARED | MAP_ANONYMOUS. I'm not sure if there's a single manpage to > >>> refer to the full list. > >> > >> So, how about this text: > >> > >> After a successful MADV_DONTNEED operation, the seman‐ > >> tics of memory access in the specified region are > >> changed: subsequent accesses of pages in the range > >> will succeed, but will result in either reloading of > >> the memory contents from the underlying mapped file > >> (for shared file mappings, shared anonymous mappings, > >> and shmem-based techniques such as System V shared > >> memory segments) or zero-fill-on-demand pages for > >> anonymous private mappings. > > > > Hmm, I'd like to clarify. > > > > Whether it was intention or not, some of userspace developers thought > > about that syscall drop pages instantly if was no-error return so that > > they will see more free pages(ie, rss for the process will be decreased) > > with keeping the VMA. Can we rely on it? > > I do not know. Michael? It's important to identify difference between MADV_DONTNEED and MADV_FREE so it would be better to clear out in this chance. > > > And we should make error section, too. > > "locked" covers mlock(2) and you said you will add hugetlb. Then, > > VM_PFNMAP? In that case, it fails. How can we say about VM_PFNMAP? > > special mapping for some drivers? > > I'm open for offers on what to add. I suggests from quote "LWN" http://lwn.net/Articles/162860/ "*special mapping* which is not made up of "normal" pages. It is usually created by device drivers which map special memory areas into user space" > > > One more thing, "The kernel is free to ignore the advice". > > It conflicts "This call does not influence the semantics of the > > application (except in the case of MADV_DONTNEED)" so > > is it okay we can believe "The kernel is free to ingmore the advise > > except MADV_DONTNEED"? > > I decided to just drop the sentence > > The kernel is free to ignore the advice. > > It creates misunderstandings, and does not really add information. Sounds good. > > Cheers, > > Michael >
Re: [PATCH] media:firewire:Remove unneeded function definition,avc_tuner_host2ca in firedtv-avc.c
On Feb 08 nick wrote: > On 2015-02-08 06:55 PM, Stefan Richter wrote: > > I still am missing research on the question whether or not the Common > > Interface serving part of the driver needs to send Host2CA commands. If > > yes, we implement it and use the function. If not, we remove the > > function. As long as we are not sure, I prefer to leave the #if-0'd code > > where it is. It documents how the command is formed, and we don't have > > any other documentation (except perhaps the git history). [...] > Stefan, > I looked in the history with git log -p 154907957f939 and all I got > for this function was > Wed Feb 11 21:21:04 CET 2009 > firedtv: avc: header file cleanup > > Remove unused constants and declarations. > Move privately used constants into .c files. The function was added a few commits before this one, by "firesat: update isochronous interface, add CI support". > Clearly this states to remove unused declarations and avc_tuner_host2ca is > unused. > Can you explain to me then why it's still needed to be around if there no > callers > of it? See above; in this instance #if 0 dead code #endif stands in for /* * pseudo code */ -- Stefan Richter -=-= --=- -=--= http://arcgraph.de/sr/ -- 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 mtd] mtd:devices: Add Altera EPCQ Driver
Please ignore previous 2 emails of mine ^^ On Thu, Feb 5, 2015 at 4:37 AM, Brian Norris wrote: > On Tue, Jan 27, 2015 at 02:53:59PM +0800, Viet Nga Dao wrote: >> On Tue, Jan 20, 2015 at 10:05 AM, Viet Nga Dao wrote: >> > On Thu, Jan 15, 2015 at 5:27 PM, Viet Nga Dao wrote: >> >> On Tue, Jan 13, 2015 at 11:33 AM, Brian Norris >> >> wrote: >> >>> On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote: >> From: Viet Nga Dao > >> >> That is why if rewrite the drivers to follow spi-nor structure, it >> >> will require extra decoding works for the only few used opcodes. >> >> >> >I think you'd only have some very trivial work here. >> > >> >There would be some small work to reintroduce a properly-replaceable ID >> >table, and callbacks like ->lock() and ->unlock(), but those should be >> >implemented in spi-nor.c sooner or later anyway. >> > >> >> I am trying to modify the code to follow your recommendation. However, >> for lock and unlock functions, i have to implement it in spi_nor.c , >> am i right? If yes, currently we already have existing spi_nor_lock >> and spi_nor_unlock functions but they could not apply for my driver. >> Should i create a new functions named altera_epcq_lock and unlock and >> then map it to callback functions or i should the put those code >> sunder existing spi_nor_lock/unlock? > > We probably want a replaceable spi_nor callback that does the > flash-specific unlock. spi_nor_lock/unlock would then call the > nor->unlock() / nor->lock() functions for you, when present. > Some of the existing code should move into their own spi_nor_st_lock() / > spi_nor_st_unlock() functions. > This changes will be made by me or maintainers? If current this functions are not supported, i decide not to implement my lock, unlock function as well. >> diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt >> b/Documentation/devicetree/bindings/mtd/altera_epcq.txt >> new file mode 100644 >> index 000..d14f50e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt >> @@ -0,0 +1,45 @@ >> +* MTD Altera EPCQ driver >> + >> +Required properties: >> +- compatible: Should be "altr,epcq-1.0" >> +- reg: Address and length of the register set for the device. It >> contains >> + the information of registers in the same order as described by >> reg-names >> +- reg-names: Should contain the reg names >> + "csr_base": Should contain the register configuration base address >> + "data_base": Should contain the data base address >> +- is-epcs: boolean type. >> + If present, the device contains EPCS flashes. >> + Otherwise, it contains EPCQ flashes. >> +- #address-cells: Must be <1>. >> +- #size-cells: Must be <0>. >> +- flash device tree subnode, there must be a node with the following >> fields: >> >>> >> >>> These subnodes definitely require a 'compatible' string. Perhaps they >> >>> should be used to differentiate EPCS vs. EPCQ. Does "is-epcs" really >> >>> need to be in the top-level controller node? >> >>> >> + - reg: Should contain the flash id >> >>> >> >>> Should, or must? (This question is relevant, because you seem to make it >> >>> optional in your code.) And what does the "flash ID" mean? It seems like >> >>> you're using as a chip-select or bank index. >> >>> >> Yes, this is used for chip select. It is required, not optional. This >> to ID for each flash in the device > > OK, so correct the language here and enforce this in your driver. Right > now, you don't fail gracefully if this is missing. > Sorry, you are right. This field is unnecessary for my driver. Instead, compatible is replaced. I will update it with 2nd version. >> + if (sector_start < num_sectors-(num_sectors / 4)) >> + sr_bp = __ilog2_u32(num_sectors); >> + else if (sector_start < num_sectors-(num_sectors / 8)) >> + sr_bp = __ilog2_u32(num_sectors) - 1; >> + else if (sector_start < num_sectors-(num_sectors / 16)) >> + sr_bp = __ilog2_u32(num_sectors) - 2; >> + else if (sector_start < num_sectors-(num_sectors / 32)) >> + sr_bp = __ilog2_u32(num_sectors) - 3; >> + else if (sector_start < num_sectors-(num_sectors / 64)) >> + sr_bp = __ilog2_u32(num_sectors) - 4; >> + else if (sector_start < num_sectors-(num_sectors / 128)) >> + sr_bp = __ilog2_u32(num_sectors) - 5; >> + else if (sector_start < num_sectors-(num_sectors / 256)) >> + sr_bp = __ilog2_u32(num_sectors) - 6; >> + else if (sector_start < num_sectors-(num_sectors / 512)) >> + sr_bp = __ilog2_u32(num_sectors) - 7; >> +
Re: [PATCH v8 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Mon, Feb 02, 2015 at 12:45:43PM +, Hanjun Guo wrote:
> Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
> used, and then register device's gsi with the core IRQ subsystem.
>
> acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
> since gsi is unique in the system, so use hwirq number directly
> for the mapping.
>
> We are going to implement stacked domains when GICv2m, GICv3, ITS
> support are added.
>
> CC: Marc Zyngier
> Originally-by: Amit Daniel Kachhap
> Tested-by: Suravee Suthikulpanit
> Tested-by: Yijing Wang
> Tested-by: Mark Langsdorf
> Tested-by: Jon Masters
> Tested-by: Timur Tabi
> Signed-off-by: Hanjun Guo
> ---
> arch/arm64/kernel/acpi.c | 73
>
> drivers/acpi/bus.c | 3 ++
> include/linux/acpi.h | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f80caef..f86a982 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -38,6 +38,12 @@ EXPORT_SYMBOL(acpi_pci_disabled);
> static int enabled_cpus; /* Processors (GICC) with enabled flag in MADT
> */
>
> /*
> + * Since we're on ARM, the default interrupt routing model
> + * clearly has to be GIC.
> + */
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
> +
> +/*
> * __acpi_map_table() will be called before page_init(), so early_ioremap()
> * or early_memremap() should be called here to for ACPI table mapping.
> */
> @@ -185,6 +191,73 @@ void __init acpi_init_cpus(void)
> pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> }
>
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> + *irq = irq_find_mapping(NULL, gsi);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>0)
> + * failure: return =< 0
> + */
> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +{
> + unsigned int irq;
> + unsigned int irq_type;
> +
> + /*
> + * ACPI have no bindings to indicate SPI or PPI, so we
> + * use different mappings from DT in ACPI.
> + *
> + * For FDT
> + * PPI interrupt: in the range [0, 15];
> + * SPI interrupt: in the range [0, 987];
> + *
> + * For ACPI, GSI should be unique so using
> + * the hwirq directly for the mapping:
> + * PPI interrupt: in the range [16, 31];
> + * SPI interrupt: in the range [32, 1019];
> + */
> +
> + if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_EDGE_FALLING;
> + else if (trigger == ACPI_EDGE_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_EDGE_RISING;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_LOW)
> + irq_type = IRQ_TYPE_LEVEL_LOW;
> + else if (trigger == ACPI_LEVEL_SENSITIVE &&
> + polarity == ACPI_ACTIVE_HIGH)
> + irq_type = IRQ_TYPE_LEVEL_HIGH;
> + else
> + irq_type = IRQ_TYPE_NONE;
> +
> + /*
> + * Since only one GIC is supported in ACPI 5.0, we can
> + * create mapping refer to the default domain
> + */
> + irq = irq_create_mapping(NULL, gsi);
> + if (!irq)
> + return irq;
> +
> + /* Set irq type if specified and different than the current one */
> + if (irq_type != IRQ_TYPE_NONE &&
> + irq_type != irq_get_trigger_type(irq))
> + irq_set_irq_type(irq, irq_type);
> + return irq;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> +
> static int __init acpi_parse_fadt(struct acpi_table_header *table)
> {
> struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
Does this code *have* to sit under arch/arm64? I can't see anything
architecture-specific about it and the bulk of the functions map directly
onto irq domain callbacks. I know that the answer is probably "we can fix
that in the future", but it doesn't seem like a huge amount of effort to
get the right abstractions in place from the beginning so that we don't
have to churn this stuff later on.
Will
--
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: build failure after merge of the pm tree
On Mon, Feb 09, 2015 at 05:36:07AM +, Jiang Liu wrote:
> Hi Rafael and Lorenzo,
> With more closer review, I suspect statement "kfree(bus_range)"
> in commit d2be00c0fb5a ("of/pci: Free resources on failure in
> of_pci_get_host_bridge_resources()") may cause double free of bus_range
> because bus_range will also be freed by kfree(window->res);
Gah, my bad, you are right, sorry I missed that. Please let me know
how you prefer fixing that, you could remove that line as part
of the merge commit, or I can send you a patch to apply on top of it,
it is a trivial one-line removal.
Thanks,
Lorenzo
> Regards!
> Gerry
>
> On 2015/2/9 11:22, Rafael J. Wysocki wrote:
> > On Monday, February 09, 2015 10:53:05 AM Jiang Liu wrote:
> >>
> >> On 2015/2/9 10:26, Stephen Rothwell wrote:
> >>> Hi Rafael,
> >
> > [cut]
> >
> >>>^
> >>>
> >>> Caused by commit 14d76b68f281 ("PCI: Use common resource list
> >>> management code instead of private implementation") interacting with
> >>> commit d2be00c0fb5a ("of/pci: Free resources on failure in
> >>> of_pci_get_host_bridge_resources()") from the pci tree.
> >>>
> >>> I applied the following merge fix patch (which may need more work?).
> >> Hi Stephen,
> >>Thanks for fixing it and there should no more work needed.
> >
> > Can you please have a look at my linux-next branch now and see if the code
> > is correct in there as well?
> >
> > Rafael
> >
>
--
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] mmc: tegra: Write xfer_mode, CMD regs in together
On Thu, Jan 29, 2015 at 1:30 AM, Rhyland Klein wrote:
> On 1/28/2015 1:06 AM, Alexandre Courbot wrote:
>> On Wed, Jan 28, 2015 at 2:23 AM, Rhyland Klein wrote:
>>> From: Pavan Kunapuli
>>>
>>> If there is a gap between xfer mode and command register writes,
>>> tegra SDMMC controller can sometimes issue a spurious command before
>>> the CMD register is written. To avoid this, these two registers need
>>> to be written together in a single write operation.
>>>
>>> Signed-off-by: Pavan Kunapuli
>>> Signed-off-by: Rhyland Klein
>>> ---
>>> drivers/mmc/host/sdhci-tegra.c | 31 ++-
>>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
>>> index 59797106af93..3d34de47e57e 100644
>>> --- a/drivers/mmc/host/sdhci-tegra.c
>>> +++ b/drivers/mmc/host/sdhci-tegra.c
>>> @@ -41,6 +41,7 @@
>>> #define NVQUIRK_DISABLE_SDR50 BIT(3)
>>> #define NVQUIRK_DISABLE_SDR104 BIT(4)
>>> #define NVQUIRK_DISABLE_DDR50 BIT(5)
>>> +#define NVQUIRK_SHADOW_XFER_MODE_REG BIT(6)
>>>
>>> struct sdhci_tegra_soc_data {
>>> const struct sdhci_pltfm_data *pdata;
>>> @@ -67,6 +68,32 @@ static u16 tegra_sdhci_readw(struct sdhci_host *host,
>>> int reg)
>>> return readw(host->ioaddr + reg);
>>> }
>>>
>>> +static void tegra_sdhci_writew(struct sdhci_host *host, u16 val, int reg)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_tegra *tegra_host = pltfm_host->priv;
>>> + const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
>>> +
>>> + if (soc_data->nvquirks * NVQUIRK_SHADOW_XFER_MODE_REG) {
>>
>> Isn't the '*' supposed to be a '&' here?
>
> Yah .. not sure how that happened, but it should be '&' good catch.
>
>>
>>> + switch (reg) {
>>> + case SDHCI_TRANSFER_MODE:
>>> + /*
>>> +* Postpone this write, we must do it together with
>>> a
>>> +* command write that is down below.
>>> +*/
>>> + pltfm_host->xfer_mode_shadow = val;
>>> + return;
>>> + case SDHCI_COMMAND:
>>> + writel((val << 16) | pltfm_host->xfer_mode_shadow,
>>> + host->ioaddr + SDHCI_TRANSFER_MODE);
>>> + pltfm_host->xfer_mode_shadow = 0;
>>
>> That last line is probably not needed and could actually be harmful -
>> if we try to write SDHCI_COMMAND twice in a raw without a write to
>> SDHCI_TRANSFER_MODE in between, the zero will overwrite the previous
>> value of SDHCI_TRANSFER_MODE.
>
> True, will remove it.
>
>>
>>> + return;
>>> + }
>>> + }
>>> +
>>> + writew(val, host->ioaddr + reg);
>>> +}
>>> +
>>> static void tegra_sdhci_writel(struct sdhci_host *host, u32 val, int reg)
>>> {
>>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> @@ -147,6 +174,7 @@ static void tegra_sdhci_set_bus_width(struct sdhci_host
>>> *host, int bus_width)
>>> static const struct sdhci_ops tegra_sdhci_ops = {
>>> .get_ro = tegra_sdhci_get_ro,
>>> .read_w = tegra_sdhci_readw,
>>> + .write_w= tegra_sdhci_writew,
>>> .write_l= tegra_sdhci_writel,
>>> .set_clock = sdhci_set_clock,
>>> .set_bus_width = tegra_sdhci_set_bus_width,
>>> @@ -201,7 +229,8 @@ static struct sdhci_tegra_soc_data soc_data_tegra114 = {
>>> .pdata = _tegra114_pdata,
>>> .nvquirks = NVQUIRK_DISABLE_SDR50 |
>>> NVQUIRK_DISABLE_DDR50 |
>>> - NVQUIRK_DISABLE_SDR104,
>>> + NVQUIRK_DISABLE_SDR104 |
>>> + NVQUIRK_SHADOW_XFER_MODE_REG,
>>> };
>>
>> Since this only applies to Tegra114 (?), I wonder whether it would not
>> be better to have a dedicated tegra114_sdhci_ops that implements
>> tegra_sdhci_writew, and use it only in tegra_sdhci_writew. That way
>> you could get rid of the NVQUIRK_SHADOW_XFER_MODE_REG and the test for
>> it in tegra_sdhci_writew(), and chips prior to Tegra114 will not have
>> to needlessly check for it every time they write a register.
>
> The reason I did it this way, is that this doesn't explicitly just apply
> to T114. It actually applies to T114, T124 and T132. In that case, I
> think it makes sense to keep the QUIRK and I can update the commit
> description to reflect that.
All the same, I don't see what advantage we have checking for that
condition for every single write while we could simply set the right
function to use at probe time?
--
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 3.19 - and merge window now open
Hi, some personal notes on this release. Several warnings and call-traces which I saw in Linux-next (upcoming v3.20) turned out to be also issues in v3.19. [1] aio: annotate aio_read_event_ring for sleep patterns [2] tracing: Add condition check to RCU lockdep checks [3] x86/tlb/trace: Do not trace on CPU that is offline Some words to [1]: Honestly people should reply with pointing to a fix if I give them my precious life-time. By accident I found the fix when gasping over the last changes to v3.19. I could spent some more time on "how to test a linux-kernel?", but there should come clear words from experienced maintainers and/or "father of Linux". Personally, I test with my kernel-config and want to have a quick feedback if it's "good". Thus I used to run LTP "lite" script on my "rc" and "-next" kernels. In case of filesystems fio [4] helped me to trigger some bugs (replaced for me xfstests). I am not sure if Documentation directory contains hints especially in the topic of "testing a Linux kernel". It's interesting to see "kbuild test robot " [5] as an author of patches :-). IOW that beast helped to trigger a lot of "build" bugs - my big respect! Nevertheless, I prefer to run any of my kernels on bare metal. Hope this helps. Regards, - Sedat - [1] http://marc.info/?t=14192939611=1=2 [1] http://www.gossamer-threads.com/lists/linux/kernel/2077075?page=last [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9c9ce763b114e608b5cf3aa6cb69ad9f6e8b6adf [2,3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4e02370f64167a30ff7ba35ae5bc296f09b964d3 [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a05d59a5673339ef6936d6940cdf68172ce75b9f [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6c8465a82a605bc692304bab42703017dcfff013 [4] http://git.kernel.org/cgit/linux/kernel/git/axboe/fio.git/ [5] http://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/ -- 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: gpio-pxa: getting GPIOs by devicetree phandle broken
Adding Robert who reported the same thing.
On Sat, Feb 7, 2015 at 6:28 AM, Tyler Hall wrote:
> Hi,
>
> Commit 7b8792b ("gpiolib: of: Correct error handling in
> of_get_named_gpiod_flags") seems to break the ability to use DT
> bindings to reference this driver's GPIOs by phandle for banks above
> the first.
>
> The issue is that gpio-pxa registers multiple gpio chips - one for
> each bank - but they're all associated with the same DT node. The new
> behavior in of_gpiochip_find_and_xlate() causes gpiochip_find() to
> bail after the first chip matches and its xlate function fails.
> Previously it would try all chips associated with the phandle and
> pxa_gpio_of_xlate() would fail until it was called with the correct
> gpiochip.
>
> I think the new behavior of of_gpiochip_find_and_xlate() is reasonable,
> so I see a couple ways of fixing gpio-pxa.
>
> 1. Require child nodes in DT for each bank
This would break DT compatibility.
> 2. Refactor gpio-pxa to only register one gpiochip
Sounds better, especially since this would reflect the hardware more
accurately. One DT node should translate into one GPIO chip. The
problem is that I'm afraid several other drivers are doing the same
thing and thus are now similarly broken.
The following is also likely to work as a workaround, but I would not
go as far as saying this should be taken as a fix. Hans, since you
wrote 7b8792b, could we have your input on this?
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 08261f2b3a82..a09095531b00 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -45,14 +45,16 @@ static int of_gpiochip_find_and_xlate(struct
gpio_chip *gc, void *data)
return false;
ret = gc->of_xlate(gc, _data->gpiospec, gg_data->flags);
- if (ret < 0) {
+ if (ret == -EPROBE_DEFER) {
/* We've found the gpio chip, but the translation failed.
* Return true to stop looking and return the translation
* error via out_gpio
*/
gg_data->out_gpio = ERR_PTR(ret);
return true;
-}
+ } else if (ret < 0) {
+ return false;
+ }
gg_data->out_gpio = gpiochip_get_desc(gc, ret);
return true;
--
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 kvm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in
arch/arm/kvm/mmu.c between commit 0d3e4d4fade6 ("arm/arm64: KVM: Use
kernel mapping to perform invalidation on page fault"") from Linus'
tree and commit 3b0f1d01e501 ("KVM: Rename
kvm_arch_mmu_write_protect_pt_masked to be more generic for log dirty")
from the kvm 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/kvm/mmu.c
index 136662547ca6,6034697ede3f..
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@@ -58,26 -78,25 +78,45 @@@ static void kvm_tlb_flush_vmid_ipa(stru
kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
}
+/*
+ * D-Cache management functions. They take the page table entries by
+ * value, as they are flushing the cache using the kernel mapping (or
+ * kmap on 32bit).
+ */
+static void kvm_flush_dcache_pte(pte_t pte)
+{
+ __kvm_flush_dcache_pte(pte);
+}
+
+static void kvm_flush_dcache_pmd(pmd_t pmd)
+{
+ __kvm_flush_dcache_pmd(pmd);
+}
+
+static void kvm_flush_dcache_pud(pud_t pud)
+{
+ __kvm_flush_dcache_pud(pud);
+}
+
+ /**
+ * stage2_dissolve_pmd() - clear and flush huge PMD entry
+ * @kvm: pointer to kvm structure.
+ * @addr: IPA
+ * @pmd: pmd pointer for IPA
+ *
+ * Function clears a PMD entry, flushes addr 1st and 2nd stage TLBs. Marks all
+ * pages in the range dirty.
+ */
+ static void stage2_dissolve_pmd(struct kvm *kvm, phys_addr_t addr, pmd_t *pmd)
+ {
+ if (!kvm_pmd_huge(*pmd))
+ return;
+
+ pmd_clear(pmd);
+ kvm_tlb_flush_vmid_ipa(kvm, addr);
+ put_page(virt_to_page(pmd));
+ }
+
static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
int min, int max)
{
@@@ -957,12 -957,165 +1009,171 @@@ static bool kvm_is_device_pfn(unsigned
return !pfn_valid(pfn);
}
+static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, pfn_t pfn,
+unsigned long size, bool uncached)
+{
+ __coherent_cache_guest_page(vcpu, pfn, size, uncached);
+}
+
+ /**
+ * stage2_wp_ptes - write protect PMD range
+ * @pmd: pointer to pmd entry
+ * @addr: range start address
+ * @end: range end address
+ */
+ static void stage2_wp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
+ {
+ pte_t *pte;
+
+ pte = pte_offset_kernel(pmd, addr);
+ do {
+ if (!pte_none(*pte)) {
+ if (!kvm_s2pte_readonly(pte))
+ kvm_set_s2pte_readonly(pte);
+ }
+ } while (pte++, addr += PAGE_SIZE, addr != end);
+ }
+
+ /**
+ * stage2_wp_pmds - write protect PUD range
+ * @pud: pointer to pud entry
+ * @addr: range start address
+ * @end: range end address
+ */
+ static void stage2_wp_pmds(pud_t *pud, phys_addr_t addr, phys_addr_t end)
+ {
+ pmd_t *pmd;
+ phys_addr_t next;
+
+ pmd = pmd_offset(pud, addr);
+
+ do {
+ next = kvm_pmd_addr_end(addr, end);
+ if (!pmd_none(*pmd)) {
+ if (kvm_pmd_huge(*pmd)) {
+ if (!kvm_s2pmd_readonly(pmd))
+ kvm_set_s2pmd_readonly(pmd);
+ } else {
+ stage2_wp_ptes(pmd, addr, next);
+ }
+ }
+ } while (pmd++, addr = next, addr != end);
+ }
+
+ /**
+ * stage2_wp_puds - write protect PGD range
+ * @pgd: pointer to pgd entry
+ * @addr:range start address
+ * @end: range end address
+ *
+ * Process PUD entries, for a huge PUD we cause a panic.
+ */
+ static void stage2_wp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
+ {
+ pud_t *pud;
+ phys_addr_t next;
+
+ pud = pud_offset(pgd, addr);
+ do {
+ next = kvm_pud_addr_end(addr, end);
+ if (!pud_none(*pud)) {
+ /* TODO:PUD not supported, revisit later if supported */
+ BUG_ON(kvm_pud_huge(*pud));
+ stage2_wp_pmds(pud, addr, next);
+ }
+ } while (pud++, addr = next, addr != end);
+ }
+
+ /**
+ * stage2_wp_range() - write protect stage2 memory region range
+ * @kvm: The KVM pointer
+ * @addr: Start address of range
+ * @end: End address of range
+ */
+ static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr, phys_addr_t
end)
+ {
+ pgd_t *pgd;
+ phys_addr_t next;
+
+ pgd = kvm->arch.pgd + pgd_index(addr);
+ do {
+ /*
+* Release kvm_mmu_lock periodically if the memory region is
+* large. Otherwise, we may see kernel panics with
+* CONFIG_DETECT_HUNG_TASK, CONFIG_LOCKUP_DETECTOR,
+
Re: [for-next][PATCH 7/7] tracing: Have mkdir and rmdir be part of tracefs
On Wed, Feb 04, 2015 at 09:34:27AM -0500, Steven Rostedt wrote:
> +static int tracefs_syscall_mkdir(struct inode *inode, struct dentry *dentry,
> umode_t mode)
> +{
> + char *name;
> + int ret;
> +
> + name = get_dname(dentry);
> + if (!name)
> + return -ENOMEM;
> +
> + /*
> + * The mkdir call can call the generic functions that create
The mkdir can call ... ?
> + * the files within the tracefs system. It is up to the individual
> + * mkdir routine to handle races.
> + */
> + mutex_unlock(>i_mutex);
> + ret = tracefs_ops.mkdir(name);
> + mutex_lock(>i_mutex);
> +
> + kfree(name);
> +
> + return ret;
> +}
> +
> +static int tracefs_syscall_rmdir(struct inode *inode, struct dentry *dentry)
> +{
> + char *name;
> + int ret;
> +
> + name = get_dname(dentry);
> + if (!name)
> + return -ENOMEM;
> +
> + /*
> + * The rmdir call can call the generic functions that create
Ditto.
> + * the files within the tracefs system. It is up to the individual
> + * rmdir routine to handle races.
> + * This time we need to unlock not only the parent (inode) but
> + * also the directory that is being deleted.
> + */
> + mutex_unlock(>i_mutex);
> + mutex_unlock(>d_inode->i_mutex);
> +
> + ret = tracefs_ops.rmdir(name);
> +
> + mutex_lock_nested(>i_mutex, I_MUTEX_PARENT);
> + mutex_lock(>d_inode->i_mutex);
> +
> + kfree(name);
> +
> + return ret;
> +}
> +
[SNIP]
> +/**
> + * tracefs_create_instance_dir - create the tracing instances directory
> + * @name: The name of the instances directory to create
> + * @parent: The parent directory that the instances directory will exist
> + * @mkdir: The function to call when a mkdir is performed.
> + * @rmdir: The function to call when a rmdir is performed.
> + *
> + * Only one instances directory is allowed.
> + *
> + * The instances directory is special as it allows for mkdir and rmdir to
> + * to be done by userspace. When a mkdir or rmdir is performed, the inode
> + * locks are released and the methhods passed in (@mkdir and @rmdir) are
s/methhods/methods/
Thanks,
Namhyung
> + * called without locks and with the name of the directory being created
> + * within the instances directory.
> + *
> + * Returns the dentry of the instances directory.
> + */
> +struct dentry *tracefs_create_instance_dir(const char *name, struct dentry
> *parent,
> + int (*mkdir)(const char *name),
> + int (*rmdir)(const char *name))
> +{
> + struct dentry *dentry;
> +
> + /* Only allow one instance of the instances directory. */
> + if (WARN_ON(tracefs_ops.mkdir || tracefs_ops.rmdir))
> return NULL;
>
> - inode = tracefs_get_inode(dentry->d_sb);
> - if (unlikely(!inode))
> - return failed_creating(dentry);
> + dentry = __create_dir(name, parent, _dir_inode_operations);
> + if (!dentry)
> + return NULL;
>
> - inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
> - inode->i_op = _dir_inode_operations;
> - inode->i_fop = _dir_operations;
> + tracefs_ops.mkdir = mkdir;
> + tracefs_ops.rmdir = rmdir;
>
> - /* directory inodes start off with i_nlink == 2 (for "." entry) */
> - inc_nlink(inode);
> - d_instantiate(dentry, inode);
> - inc_nlink(dentry->d_parent->d_inode);
> - fsnotify_mkdir(dentry->d_parent->d_inode, dentry);
> - return end_creating(dentry);
> + return dentry;
> }
--
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/4] ASoC: samsung: clean up references to outdated Kconfig symbols
On Sat, Feb 07, 2015 at 09:38:04AM +0100, Paul Bolle wrote: > Patches 2/4, 3/4, and 4/4 didn't apply. Locally I carry them in a tree > that constantly rebases on top of linux-next. So locally I carry these > patches on top of next-20150204. What's posted doesn't apply against -next. > What tree would you like me to rebase this onto? As ever submit against the tree listed in MAINTAINERS git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next signature.asc Description: Digital signature
Re: [for-next][PATCH 5/7] tracing: Automatically mount tracefs on debugfs/tracing
On Wed, Feb 04, 2015 at 09:34:25AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> As tools currently rely on the tracing directory in debugfs, we can not
> just created a tracefs infrastructure and expect sysadmins to mount
> the new tracefs to have their old tools work.
>
> Instead, the debugfs tracing directory is still created and the tracefs
> file system is mounted there when the debugfs filesystem is mounted.
>
> No longer does the tracing infrastructure update the debugfs file system,
> but instead interacts with the tracefs file system. But now, it still
> appears to the user like nothing changed, except you also have the feature
> of mounting just the tracing system without needing all of debugfs!
One question. Is it possible to have both of the old
/sys/kernel/debug/tracing and new /sys/kernel/tracing directories?
>
> Cc: Al Viro
> Signed-off-by: Steven Rostedt
> ---
> kernel/trace/trace.c | 36 +---
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 6c4739bee4bb..b4aa936509d2 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -6535,6 +6536,28 @@ init_tracer_tracefs(struct trace_array *tr, struct
> dentry *d_tracer)
>
> }
>
> +static struct vfsmount *trace_automount(void *ingore)
> +{
> + struct vfsmount *mnt;
> + struct file_system_type *type;
> +
> + /*
> + * To maintain backward compatibility for tools that mount
> + * debugfs to get to the tracing facility, tracefs is automatically
> + * mounted to the debugfs/tracing directory.
> + */
> + type = get_fs_type("tracefs");
> + if (!type)
> + return NULL;
> + mnt = vfs_kern_mount(type, 0, "tracefs", NULL);
> + put_filesystem(type);
> + if (IS_ERR(mnt))
> + return NULL;
> + mntget(mnt);
> +
> + return mnt;
> +}
> +
> /**
> * tracing_init_dentry - initialize top level trace array
> *
> @@ -6546,14 +6569,21 @@ struct dentry *tracing_init_dentry(void)
> {
> struct trace_array *tr = _trace;
>
> + /* The top level trace array uses NULL as parent */
> if (tr->dir)
> - return tr->dir;
> + return NULL;
>
> if (WARN_ON(!debugfs_initialized()))
> return ERR_PTR(-ENODEV);
>
> - tr->dir = debugfs_create_dir("tracing", NULL);
> -
> + /*
> + * As there may still be users that expect the tracing
> + * files to exist in debugfs/tracing, we must automount
> + * the tracefs file system there, so older tools still
> + * work with the newer kerenl.
s/kerenl/kernel/
Thanks,
Namhyung
> + */
> + tr->dir = debugfs_create_automount("tracing", NULL,
> +trace_automount, NULL);
> if (!tr->dir) {
> pr_warn_once("Could not create debugfs directory 'tracing'\n");
> return ERR_PTR(-ENOMEM);
> --
> 2.1.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/
--
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 3.19 - and merge window now open
On Sun, Feb 8, 2015 at 7:41 PM, Linus Torvalds wrote: > So it's out there - go and get it. And as a result, the merge window > for 3.20 is obviously also now open. 3.20? How high are we going to count before it's time to consider 4.0? -Tony -- 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/
[LKP] [sched/core] 9edfbfed3f5: +88.2% hackbench.time.involuntary_context_switches
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
commit 9edfbfed3f544a7830d99b341f0c175995a02950 ("sched/core: Rework rq->clock
update skips")
testbox/testcase/testparams: xps2/hackbench/performance-1600%-process-socket
cebde6d681aa45f9 9edfbfed3f544a7830d99b341f
--
%stddev %change %stddev
\ |\
1839273 ± 6% +88.2%3462337 ± 4%
hackbench.time.involuntary_context_switches
41965851 ± 5% +5.6% 44307403 ± 1%
hackbench.time.voluntary_context_switches
388 ± 39% -58.6%160 ± 10%
sched_debug.cfs_rq[1]:/.tg_load_contrib
12957 ± 14% -60.5% 5117 ± 11%
sched_debug.cfs_rq[2]:/.tg_load_avg
30505 ± 14% -57.7% 12905 ± 6%
sched_debug.cfs_rq[3]:/.tg_load_avg
2790 ± 24% -65.4%964 ± 32%
sched_debug.cfs_rq[3]:/.blocked_load_avg
2915 ± 23% -62.2% 1101 ± 29%
sched_debug.cfs_rq[3]:/.tg_load_contrib
1839273 ± 6% +88.2%3462337 ± 4% time.involuntary_context_switches
1474 ± 28% -61.7%565 ± 43%
sched_debug.cfs_rq[2]:/.tg_load_contrib
11830 ± 15% +63.0% 19285 ± 11% sched_debug.cpu#4.sched_goidle
19319 ± 29% +91.1% 36913 ± 7% sched_debug.cpu#3.sched_goidle
5899 ± 31% -35.6% 3801 ± 11%
sched_debug.cfs_rq[4]:/.blocked_load_avg
5999 ± 30% -34.5% 3929 ± 11%
sched_debug.cfs_rq[4]:/.tg_load_contrib
37884 ± 13% -33.5% 25207 ± 7%
sched_debug.cfs_rq[4]:/.tg_load_avg
229547 ± 5% +47.9% 339519 ± 5% cpuidle.C1-NHM.usage
35712 ± 3% +31.7% 47036 ± 9% cpuidle.C3-NHM.usage
5010 ± 9% -29.0% 3556 ± 20%
sched_debug.cfs_rq[6]:/.blocked_load_avg
5139 ± 9% -28.2% 3690 ± 19%
sched_debug.cfs_rq[6]:/.tg_load_contrib
49568 ± 6% +24.8% 61867 ± 7% sched_debug.cpu#1.sched_goidle
26369 ± 35% -42.0% 15289 ± 29% cpuidle.C6-NHM.usage
18 ± 16% +36.5% 25 ± 7% sched_debug.cpu#4.nr_running
1.41 ± 12% -19.3% 1.14 ± 13%
perf-profile.cpu-cycles.sock_wfree.unix_destruct_scm.skb_release_head_state.skb_release_all.consume_skb
25 ± 15% +28.7% 32 ± 9% sched_debug.cpu#3.nr_running
1.63 ± 11% -18.0% 1.34 ± 12%
perf-profile.cpu-cycles.unix_destruct_scm.skb_release_head_state.skb_release_all.consume_skb.unix_stream_recvmsg
0.57 ± 8% +9.6% 0.62 ± 5% turbostat.CPU%c1
148 ± 11% -16.7%123 ± 7% sched_debug.cfs_rq[1]:/.load
109 ± 6% +17.1%128 ± 6% sched_debug.cpu#6.cpu_load[0]
2.41 ± 8% -13.3% 2.09 ± 11%
perf-profile.cpu-cycles.skb_release_head_state.skb_release_all.consume_skb.unix_stream_recvmsg.sock_aio_read
147 ± 12% -16.4%123 ± 7% sched_debug.cpu#1.load
111 ± 5% +15.4%129 ± 5% sched_debug.cpu#6.cpu_load[2]
110 ± 5% +14.9%127 ± 5%
sched_debug.cfs_rq[6]:/.runnable_load_avg
112 ± 5% +14.5%128 ± 4% sched_debug.cpu#6.cpu_load[3]
113 ± 5% +13.2%128 ± 3% sched_debug.cpu#6.cpu_load[4]
789953 ± 2% -10.8% 704528 ± 4% sched_debug.cpu#3.avg_idle
15471 ± 5% -7.7% 14278 ± 2% sched_debug.cpu#5.curr->pid
2675106 ± 10% +16.2%3109411 ± 1% sched_debug.cpu#4.nr_switches
2675140 ± 10% +16.2%3109440 ± 1% sched_debug.cpu#4.sched_count
155201 ± 5% +14.6% 177901 ± 3% softirqs.RCU
8.64 ± 6% -9.6% 7.82 ± 5%
perf-profile.cpu-cycles.skb_release_all.consume_skb.unix_stream_recvmsg.sock_aio_read.sock_aio_read
2658351 ± 11% +13.7%3021564 ± 2% sched_debug.cpu#5.sched_count
2658326 ± 11% +13.7%3021539 ± 2% sched_debug.cpu#5.nr_switches
71443 ± 5% +9.9% 78486 ± 0% vmstat.system.cs
8209 ± 5% +7.3% 8805 ± 0% vmstat.system.in
xps2: Nehalem
Memory: 4G
To reproduce:
apt-get install ruby ruby-oj
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
tbench_srv &
tbench 4 127.0.0.1
killall tbench_srv
___
LKP mailing list
l...@linux.intel.com
job.yaml
Description: application/yaml
Re: [for-next][PATCH 3/7] tracefs: Add new tracefs file system
Hi Steve,
On Wed, Feb 04, 2015 at 09:34:23AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> Add a separate file system to handle the tracing directory. Currently it
> is part of debugfs, but that is starting to show its limits.
>
> One thing is that in order to access the tracing infrastructure, you need
> to mount debugfs. As that includes debugging from all sorts of sub systems
> in the kernel, it is not considered advisable to mount such an all
> encompassing debugging system.
>
> Having the tracing system in its own file systems gives access to the
> tracing sub system without needing to include all other systems.
>
> Another problem with tracing using the debugfs system is that the
> instances use mkdir to create sub buffers. debugfs does not support mkdir
> from userspace so to implement it, special hacks were used. By controlling
> the file system that the tracing infrastructure uses, this can be properly
> done without hacks.
>
> Signed-off-by: Steven Rostedt
> ---
[SNIP]
> +/**
> + * tracefs_create_file - create a file in the tracefs filesystem
> + * @name: a pointer to a string containing the name of the file to create.
> + * @mode: the permission that the file should have.
> + * @parent: a pointer to the parent dentry for this file. This should be a
> + * directory dentry if set. If this parameter is NULL, then the
> + * file will be created in the root of the tracefs filesystem.
> + * @data: a pointer to something that the caller will want to get to later
> + *on. The inode.i_private pointer will point to this value on
> + *the open() call.
> + * @fops: a pointer to a struct file_operations that should be used for
> + *this file.
> + *
> + * This is the basic "create a file" function for tracefs. It allows for a
> + * wide range of flexibility in creating a file, or a directory (if you want
> + * to create a directory, the tracefs_create_dir() function is
> + * recommended to be used instead.)
> + *
> + * This function will return a pointer to a dentry if it succeeds. This
> + * pointer must be passed to the tracefs_remove() function when the file is
> + * to be removed (no automatic cleanup happens if your module is unloaded,
> + * you are responsible here.) If an error occurs, %NULL will be returned.
> + *
> + * If tracefs is not enabled in the kernel, the value -%ENODEV will be
> + * returned.
I cannot find where it returns -ENODEV. AFAICS we cannot call tracefs
functions if tracing was not enabled.
> + */
> +struct dentry *tracefs_create_file(const char *name, umode_t mode,
> +struct dentry *parent, void *data,
> +const struct file_operations *fops)
> +{
> + struct dentry *dentry;
> + struct inode *inode;
> +
> + if (!(mode & S_IFMT))
> + mode |= S_IFREG;
> + BUG_ON(!S_ISREG(mode));
> + dentry = start_creating(name, parent);
> +
> + if (IS_ERR(dentry))
> + return NULL;
> +
> + inode = tracefs_get_inode(dentry->d_sb);
> + if (unlikely(!inode))
> + return failed_creating(dentry);
> +
> + inode->i_mode = mode;
> + inode->i_fop = fops ? fops : _file_operations;
> + inode->i_private = data;
> + d_instantiate(dentry, inode);
> + fsnotify_create(dentry->d_parent->d_inode, dentry);
> + return end_creating(dentry);
> +}
> +
> +/**
> + * tracefs_create_dir - create a directory in the tracefs filesystem
> + * @name: a pointer to a string containing the name of the directory to
> + *create.
> + * @parent: a pointer to the parent dentry for this file. This should be a
> + * directory dentry if set. If this parameter is NULL, then the
> + * directory will be created in the root of the tracefs filesystem.
> + *
> + * This function creates a directory in tracefs with the given name.
> + *
> + * This function will return a pointer to a dentry if it succeeds. This
> + * pointer must be passed to the tracefs_remove() function when the file is
> + * to be removed. If an error occurs, %NULL will be returned.
> + *
> + * If tracing is not enabled in the kernel, the value -%ENODEV will be
> + * returned.
Ditto.
Thanks,
Namhyung
> + */
> +struct dentry *tracefs_create_dir(const char *name, struct dentry *parent)
> +{
> + struct dentry *dentry = start_creating(name, parent);
> + struct inode *inode;
> +
> + if (IS_ERR(dentry))
> + return NULL;
> +
> + inode = tracefs_get_inode(dentry->d_sb);
> + if (unlikely(!inode))
> + return failed_creating(dentry);
> +
> + inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
> + inode->i_op = _dir_inode_operations;
> + inode->i_fop = _dir_operations;
> +
> + /* directory inodes start off with i_nlink == 2 (for "." entry) */
> + inc_nlink(inode);
> + d_instantiate(dentry, inode);
> + inc_nlink(dentry->d_parent->d_inode);
> +
[ANNOUNCE] ipvsadm release v1.28
We are happy to announce the release of ipvsadm v1.28. ipvsadm is a utility to administer the kernels IPVS/LVS load-balancer service It has been quite a while since the previous release, v1.27. A number of fixes and improvements have been made; most noticeably in the area of IPv6. One big addition is the support for heterogeneous pools (v4 and v6 mixed pools in 3.18), by Alex Gartrell (facebook). Feature wise the SCTP protocol has been added which is available via the cmdline parameter "--sctp-service". The kernel has supported SCTP since kernel 2.6.34 but up until now ipvsadm users have been restricted to using fwmark-based virtual services for SCTP. This release is based on the kernel.org git tree: https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/ You can download the tarballs from: https://kernel.org/pub/linux/utils/kernel/ipvsadm/ Git tree: git://git.kernel.org/pub/scm/utils/kernel/ipvsadm/ipvsadm.git Shortlog: Alex Gartrell (2): ipvsadm: specify real server address family to netlink socket ipvsadm: do not truncate ipv6 members of v4 services Daniel Borkmann (2): ipvsadm: fix compile warning in print_largenum ipvsadm: fix compile warning in modprobe_ipvs Hibari Michiro (1): ipvsadm: enable displaying of IPv6 hostnames in listing Jesper Dangaard Brouer (1): Release: Version 1.28 Julian Anastasov (3): ipvsadm: restrict different address family ipvsadm: allow different address family in connection listing ipvsadm: add SCTP support Ryan O'Hara (2): libipvs: Initialize ipvs_service_t variable ipvsadm: Fix list daemon to show backup daemon -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- 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: build failure after merge of the net-next tree
From: Stephen Rothwell Date: Mon, 9 Feb 2015 14:07:45 +1100 > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > index e96fc00208bc..9cc4c4a90d00 100644 > --- a/lib/rhashtable.c > +++ b/lib/rhashtable.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > > #define HASH_DEFAULT_SIZE64UL > #define HASH_MIN_SIZE4UL Applied, thanks Stephen. -- 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 v6 0/7] PCI: get DMA configuration from parent device
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote: > This patch add an important capability to PCI driver on Keystone. I hope to > have this merged to the upstream branch so that it is available for v3.20. > Also would like thank everyone for the contribution. > > PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch > add capability to set the dma configuration such as dma-mask, dma_pfn_offset, > and dma ops etc using the information from DT. The prior RFCs and discussions > are available at [1] and [2] below. > > [2] : https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg790244.html > [1] : http://www.gossamer-threads.com/lists/linux/kernel/2024591 > > Change history: > v6 - Rebased to v3.19-v7 > - Addressed some minor comments about node name and DT size > validation. > - Pulled out 8/8 of v5 and plan to send a patch for enhancing >of_dma_configure() to use size to calculate dma mask. > - Added Acks from reviewers. This series looks fine to me: Acked-by: Will Deacon Will -- 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] posix_acl: fix reference leaks in posix_acl_create
get_acl gets a reference which we must release in the error cases.
Reviewed-by: Christoph Hellwig
Signed-off-by: Omar Sandoval
---
Hi, Al,
I'm guessing you're the one to take this one? Just a resend with the
proper format and Christoph's Reviewed-by.
Thanks!
fs/posix_acl.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 0855f77..515d315 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -564,13 +564,11 @@ posix_acl_create(struct inode *dir, umode_t *mode,
*acl = posix_acl_clone(p, GFP_NOFS);
if (!*acl)
- return -ENOMEM;
+ goto no_mem;
ret = posix_acl_create_masq(*acl, mode);
- if (ret < 0) {
- posix_acl_release(*acl);
- return -ENOMEM;
- }
+ if (ret < 0)
+ goto no_mem_clone;
if (ret == 0) {
posix_acl_release(*acl);
@@ -591,6 +589,12 @@ no_acl:
*default_acl = NULL;
*acl = NULL;
return 0;
+
+no_mem_clone:
+ posix_acl_release(*acl);
+no_mem:
+ posix_acl_release(p);
+ return -ENOMEM;
}
EXPORT_SYMBOL_GPL(posix_acl_create);
--
2.3.0
--
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: build failure after merge of the pm tree
Hi Rafael and Lorenzo,
With more closer review, I suspect statement "kfree(bus_range)"
in commit d2be00c0fb5a ("of/pci: Free resources on failure in
of_pci_get_host_bridge_resources()") may cause double free of bus_range
because bus_range will also be freed by kfree(window->res);
Regards!
Gerry
On 2015/2/9 11:22, Rafael J. Wysocki wrote:
> On Monday, February 09, 2015 10:53:05 AM Jiang Liu wrote:
>>
>> On 2015/2/9 10:26, Stephen Rothwell wrote:
>>> Hi Rafael,
>
> [cut]
>
>>>^
>>>
>>> Caused by commit 14d76b68f281 ("PCI: Use common resource list
>>> management code instead of private implementation") interacting with
>>> commit d2be00c0fb5a ("of/pci: Free resources on failure in
>>> of_pci_get_host_bridge_resources()") from the pci tree.
>>>
>>> I applied the following merge fix patch (which may need more work?).
>> Hi Stephen,
>> Thanks for fixing it and there should no more work needed.
>
> Can you please have a look at my linux-next branch now and see if the code
> is correct in there as well?
>
> Rafael
>
--
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] mm/slab_common: Use kmem_cache_free
Here, free memory is allocated using kmem_cache_zalloc. So, use kmem_cache_free instead of kfree. This is done using Coccinelle and semantic patch used is as follows: @@ expression x,E,c; @@ x = \(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...) ... when != x = E when != ?-kfree(x) +kmem_cache_free(c,x) Signed-off-by: Vaishali Thakkar --- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index e03dd6f..67f182c 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -331,7 +331,7 @@ out: out_free_cache: memcg_free_cache_params(s); - kfree(s); + kmem_cache_free(kmem_cache, s); goto out; } -- 1.9.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 v2 2/4] gpio: add parameter to allow the use named gpios
On Fri, Jan 30, 2015 at 10:46 PM, Linus Walleij wrote: > On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl > wrote: > >> From: Olliver Schinagl >> >> The gpio binding document says that new code should always use named >> gpios. Patch 40b73183 added support to parse a list of gpios from child >> nodes, but does not make it possible to use named gpios. This patch adds >> the con_id property and implements it is done in gpiolib.c, where the >> old-style of using unnamed gpios still works. >> >> Signed-off-by: Olliver Schinagl >> --- >> drivers/gpio/devres.c | 18 +- >> drivers/input/keyboard/gpio_keys_polled.c | 2 +- >> drivers/leds/leds-gpio.c | 2 +- >> include/linux/gpio/consumer.h | 1 + > > Alexandre: does this match your vision of how it should work, i.e. ACK? Pretty much, yes - as I mentioned in the previous versions there may be shortcomings for ACPI, but we need a refactor of the whole thing - nothing that this patch should address by itself. So this patch: Reviewed-by: Alexandre Courbot -- 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 v6 0/7] PCI: get DMA configuration from parent device
Sorry for delay response. I have also tested this on AMD Seattle platform w/ PCI Generic Host Controller, and I can see that the PCI endpoint devices are getting proper dma_map_ops as set in the host bridge. : Suravee Suthikulpanit Thanks, Suravee On 02/06/2015 05:52 AM, Murali Karicheri wrote: This patch add an important capability to PCI driver on Keystone. I hope to have this merged to the upstream branch so that it is available for v3.20. Also would like thank everyone for the contribution. PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch add capability to set the dma configuration such as dma-mask, dma_pfn_offset, and dma ops etc using the information from DT. The prior RFCs and discussions are available at [1] and [2] below. [2] : https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg790244.html [1] : http://www.gossamer-threads.com/lists/linux/kernel/2024591 Change history: v6 - Rebased to v3.19-v7 - Addressed some minor comments about node name and DT size validation. - Pulled out 8/8 of v5 and plan to send a patch for enhancing of_dma_configure() to use size to calculate dma mask. - Added Acks from reviewers. v5 - moved the dma_mask update in device from ARM specific API to of_dma_configure to allow this across other architecture as well - improved sanity check for DT dma-range size in of_dma_configure() - moved API to get parent bridge device to PCI (host-bridge.c) v4 - moved size adjustments in of_iommu_configure() to a separate patch - consistent node name comment from Rob - patch 6 added for dma_mask adjustment and iommu mapping size limiting. v3 - addressed comments to re-use of_dma_configure() for PCI - To help re-use, change of_iommu_configure() function argument - Move of_dma_configure to of/device.c - Limit the of_iommu_configure to non pci devices v2 - update size to coherent_dma_mask + 1 if dma-range info is missing - also check the np for null. v1 - updates based on the comments against initial RFC. - Added a helper function to get the OF node of the parent - Added an API in of_pci.c to update DMA configuration of the pci device. Cc: Joerg Roedel Cc: Grant Likely Cc: Rob Herring Cc: Bjorn Helgaas Cc: Will Deacon Cc: Russell King Cc: Arnd Bergmann Cc: Suravee Suthikulpanit Acked-by: Bjorn Helgaas Acked-by: Murali Karicheri Murali Karicheri (7): of: iommu: add ptr to OF node arg to of_iommu_configure() of: move of_dma_configure() to device.c to help re-use of: fix size when dma-range is not used PCI: add helper functions pci_get[put]_host_bridge_device() of/pci: add of_pci_dma_configure() update dma configuration PCI: update dma configuration from DT arm: dma-mapping: limit iommu mapping size arch/arm/mm/dma-mapping.c |7 + drivers/iommu/of_iommu.c | 10 -- drivers/of/device.c | 74 + drivers/of/of_pci.c | 19 drivers/of/platform.c | 58 ++- drivers/pci/host-bridge.c | 14 + drivers/pci/probe.c |2 ++ include/linux/of_device.h |2 ++ include/linux/of_iommu.h |6 ++-- include/linux/of_pci.h|5 +++ include/linux/pci.h |3 ++ 11 files changed, 140 insertions(+), 60 deletions(-) -- 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] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
On 5 February 2015 at 12:13, Addy Ke wrote:
>
> Because of some uncertain factors, such as worse card or worse hardware,
> DAT[3:0](the data lines) may be pulled down by card, and mmc controller
> will be in busy state. This should not happend when mmc controller
> send command to update card clocks. If this happends, mci_send_cmd will
> be failed and we will get 'Timeout sending command', and then system will
> be blocked. To avoid this, we need reset mmc controller.
>
> Signed-off-by: Addy Ke
Hi Addy,
Should I consider $subject patch as a better option to the one below?
[PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY
https://lkml.org/lkml/2015/1/13/562
Kind regards
Uffe
> ---
> drivers/mmc/host/dw_mmc.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 4d2e3c2..b1d6dfb 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -100,6 +100,7 @@ struct idmac_desc {
> };
> #endif /* CONFIG_MMC_DW_IDMAC */
>
> +static int dw_mci_card_busy(struct mmc_host *mmc);
> static bool dw_mci_reset(struct dw_mci *host);
> static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>
> @@ -888,6 +889,26 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
> cmd, u32 arg)
> cmd, arg, cmd_status);
> }
>
> +static void dw_mci_wait_busy(struct dw_mci_slot *slot)
> +{
> + struct dw_mci *host = slot->host;
> + unsigned long timeout = jiffies + msecs_to_jiffies(500);
> +
> + while (time_before(jiffies, timeout)) {
> + if (!dw_mci_card_busy(slot->mmc))
> + return;
> + }
> + dev_err(host->dev, "Data busy (status %#x)\n",
> + mci_readl(slot->host, STATUS));
> +
> + /*
> +* Data busy, this should not happend when mmc controller send command
> +* to update card clocks in non-volt-switch state. If it happends, we
> +* should reset controller to avoid getting "Timeout sending command".
> +*/
> + dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
> +}
> +
> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
> {
> struct dw_mci *host = slot->host;
> @@ -899,6 +920,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
> bool force_clkinit)
> /* We must continue to set bit 28 in CMD until the change is complete
> */
> if (host->state == STATE_WAITING_CMD11_DONE)
> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
> + else
> + dw_mci_wait_busy(slot);
>
> if (!clock) {
> mci_writel(host, CLKENA, 0);
> --
> 1.8.3.2
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 V2] idle/intel_powerclamp: Redesign idle injection to use bandwidth control mechanism
The powerclamp driver injects idle periods to stay within the thermal
constraints.
The driver does a fake idle by spawning per-cpu threads that call the mwait
instruction. This behavior of fake idle can confuse the other kernel subsystems.
For instance it calls into the nohz tick handlers, which are meant to be called
only by the idle thread. It sets the state of the tick in each cpu to idle and
stops the tick, when there are tasks on the runqueue. As a result the callers of
idle_cpu()/ tick_nohz_tick_stopped() see different states of the cpu; while the
former thinks that the cpu is busy, the latter thinks that it is idle. The
outcome
may be inconsistency in the scheduler/nohz states which can lead to serious
consequences. One of them was reported on this thread:
https://lkml.org/lkml/2014/12/11/365.
Thomas posted out a patch to disable the powerclamp driver from calling into the
tick nohz code which has taken care of the above regression for the moment.
However
powerclamp driver as a result, will not be able to inject idle periods due to
the
presence of periodic ticks. With the current design of fake idle, we cannot move
towards a better solution.
https://lkml.org/lkml/2014/12/18/169
This patch aims at removing the concept of fake idle and instead makes the cpus
truly idle by throttling the runqueues during the idle injection periods. The
situation
is in fact very similar to throttling of cfs_rqs when they exceed their
bandwidths.
The idle injection metrics can be mapped to the bandwidth control metrics
'quota' and
'period' to achieve the same result. When the powerclamping is begun or when the
clamping controls have been modified, the bandwidth for the root task group is
set.
The 'quota' will be the amount of time that the system needs to be busy and
'period'
will be the sum of this busy duration and the idle duration as calculated by
the driver.
This gets rid of per-cpu kthreads, control cpu, hotplug notifiers and clamping
mask since
the thread starting powerclamping will set the bandwidth and throttling of all
cpus will
automatically fall in place. None of the other cpus need be bothered about
this. This
simplifies the design of the driver.
Of course this is only if the idle injection metrics can be conveniently
transformed
into bandwidth control metrics. There are a couple of other primary concerns
around if
doing the below two in this patch is valid.
a. This patch exports the functions to set the quota and period of task groups.
b. This patch removes the constraint of not being able to set the root task
grp's bandwidth.
Signed-off-by: Preeti U Murthy
---
V1: https://lkml.org/lkml/2014/12/21/23
V1 tried to throttle cfs_rqs without modifying available bandwidth. This will
not
be an appropriate solution since the scheduler only considers a runqueue as
throttled when its bandwidth has been exceeded. Going around this path can
lead to unintended consequences. Hence V2 was designed to throttle runqueues
through bandwidth control.
drivers/thermal/intel_powerclamp.c | 289 +---
include/linux/sched.h |6 +
kernel/sched/core.c|5 -
3 files changed, 82 insertions(+), 218 deletions(-)
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
index 6ceebd6..f43903c 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -78,20 +78,14 @@ static struct dentry *debug_dir;
static unsigned int set_target_ratio;
static unsigned int current_ratio;
static bool should_skip;
+static unsigned int count = 0;
static bool reduce_irq;
static atomic_t idle_wakeup_counter;
-static unsigned int control_cpu; /* The cpu assigned to collect stat and update
- * control parameters. default to BSP but BSP
- * can be offlined.
- */
static bool clamping;
+static void clamp_timer_fn(unsigned long foo);
+DEFINE_TIMER(wakeup_timer, clamp_timer_fn, 0, 0);
-
-static struct task_struct * __percpu *powerclamp_thread;
static struct thermal_cooling_device *cooling_dev;
-static unsigned long *cpu_clamping_mask; /* bit map for tracking per cpu
- * clamping thread
- */
static unsigned int duration;
static unsigned int pkg_cstate_ratio_cur;
@@ -163,7 +157,7 @@ static int window_size_set(const char *arg, const struct
kernel_param *kp)
smp_mb();
exit_win:
-
+ clamp_cpus();
return ret;
}
@@ -256,10 +250,6 @@ static u64 pkg_state_counter(void)
return count;
}
-static void noop_timer(unsigned long foo)
-{
- /* empty... just the fact that we get the interrupt wakes us up */
-}
static unsigned int get_compensation(int ratio)
{
@@ -362,102 +352,78 @@ static bool powerclamp_adjust_controls(unsigned int
target_ratio,
return set_target_ratio + guard <=
Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
I have re-sent the patch with the subject "[PATCH v2] brcmfmac: avoid
duplicated suspend/resume operation" in another mail.
If this patch can be accepted, please tell me.
Thanks,
Zhonghui
On 2015/2/5 19:46, Arend van Spriel wrote:
> On 02/05/15 12:34, Fu, Zhonghui wrote:
>> What comments about the new patch? Can this new patch be accepted?
>
> Hi Zhonghui
>
> Last reply from Kalle was that it did not apply to his tree and recommended
> to use version numbering so "[PATCH V2] ".
>
>> Thanks,
>> Zhonghui
>>
>> On 2015/1/26 10:46, Fu, Zhonghui wrote:
>>> From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
>>> From: Zhonghui Fu
>>> Date: Mon, 26 Jan 2015 10:13:21 +0800
>>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>>
>>> WiFi chip has 2 SDIO functions, and PM core will trigger
>>> twice suspend/resume operations for one WiFi chip to do
>>> the same things. This patch avoid this case.
>>>
>>> Acked-by: Arend van Spriel
>>> Signed-off-by: Zhonghui Fu
>>> ---
> And when using version info a change log here is even better. Although
> admittedly I lost track which version this would be ;-)
>
> Regards,
> Arend
> ---
>>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 17 +++--
>>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>>> b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>>> index 9880dae..618b545 100644
>>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>>> @@ -1139,11 +1139,17 @@ void brcmf_sdio_wowl_config(struct device *dev,
>>> bool enabled)
>>> static int brcmf_ops_sdio_suspend(struct device *dev)
>>> {
>>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>>> -struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>>> +struct brcmf_sdio_dev *sdiodev;
>>> mmc_pm_flag_t sdio_flags;
>>> +struct sdio_func *func = dev_to_sdio_func(dev);
>>>
>>> brcmf_dbg(SDIO, "Enter\n");
>>>
>>> +if (func->num == 2)
>>> +return 0;
>>> +
>>> +sdiodev = bus_if->bus_priv.sdio;
>>> +
>>> atomic_set(>suspend, true);
>>>
>>> if (sdiodev->wowl_enabled) {
>>> @@ -1164,9 +1170,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>>> static int brcmf_ops_sdio_resume(struct device *dev)
>>> {
>>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>>> -struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>>> +struct brcmf_sdio_dev *sdiodev;
>>> +struct sdio_func *func = dev_to_sdio_func(dev);
>>>
>>> brcmf_dbg(SDIO, "Enter\n");
>>> +
>>> +if (func->num == 2)
>>> +return 0;
>>> +
>>> +sdiodev = bus_if->bus_priv.sdio;
>>> +
>>> if (sdiodev->pdata&& sdiodev->pdata->oob_irq_supported)
>>> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
>>> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
>>> -- 1.7.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] Staging: rtl8192u: r8190_rtl8256: coding style and format string type connections
Lines over 80 were corrected
RT_TRACE format strings should specify unsigned instead of signed int
Signed-off-by: Tolga Ceylan
---
drivers/staging/rtl8192u/r8190_rtl8256.c | 244 ++-
1 file changed, 174 insertions(+), 70 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c
b/drivers/staging/rtl8192u/r8190_rtl8256.c
index 1868352..1d7338a 100644
--- a/drivers/staging/rtl8192u/r8190_rtl8256.c
+++ b/drivers/staging/rtl8192u/r8190_rtl8256.c
@@ -37,43 +37,71 @@ void PHY_SetRF8256Bandwidth(struct net_device *dev,
HT_CHANNEL_WIDTH Bandwidth)
switch (Bandwidth) {
case HT_CHANNEL_WIDTH_20:
- if (priv->card_8192_version == VERSION_819xU_A
- || priv->card_8192_version
- == VERSION_819xU_B) { /* 8256 D-cut,
E-cut, xiong: consider it later! */
- rtl8192_phy_SetRFReg(dev,
- (RF90_RADIO_PATH_E)eRFPath,
- 0x0b, bMask12Bits, 0x100); /*
phy para:1ba */
- rtl8192_phy_SetRFReg(dev,
- (RF90_RADIO_PATH_E)eRFPath,
- 0x2c, bMask12Bits, 0x3d7);
+ /* 8256 D-cut, E-cut, xiong: consider it later! */
+ if (priv->card_8192_version == VERSION_819xU_A ||
+ priv->card_8192_version == VERSION_819xU_B) {
+
+ /* phy para:1ba */
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x0b, bMask12Bits, 0x100);
+
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x2c, bMask12Bits, 0x3d7);
+
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x0e, bMask12Bits, 0x021);
+
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x14, bMask12Bits, 0x5ab);
+
+ } else {
+ RT_TRACE(COMP_ERR,
+ "PHY_SetRF8256Bandwidth(): unknown
hardware version\n");
+ }
+ break;
+ case HT_CHANNEL_WIDTH_20_40:
+ /* 8256 D-cut, E-cut, xiong: consider it later! */
+ if (priv->card_8192_version == VERSION_819xU_A ||
+ priv->card_8192_version == VERSION_819xU_B) {
+
+ /* phy para:3ba */
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x0b, bMask12Bits, 0x300);
+
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x2c, bMask12Bits, 0x3df);
+
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x0e, bMask12Bits, 0x0a1);
+
+ if (priv->chan == 3 || priv->chan == 9)
+ /* I need to set priv->chan whenever
+* current channel changes
+*/
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath,
- 0x0e, bMask12Bits, 0x021);
+ 0x14, bMask12Bits, 0x59b);
+ else
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath,
0x14, bMask12Bits, 0x5ab);
- } else {
- RT_TRACE(COMP_ERR,
"PHY_SetRF8256Bandwidth(): unknown hardware version\n");
- }
- break;
- case HT_CHANNEL_WIDTH_20_40:
- if (priv->card_8192_version == VERSION_819xU_A
|| priv->card_8192_version == VERSION_819xU_B) { /* 8256 D-cut, E-cut, xiong:
consider it later! */
- rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x0b, bMask12Bits, 0x300); /* phy para:3ba */
-
[GIT PULL] hwmon updates for 3.20
Hi Linus, Please pull hwmon updates for Linux 3.20 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v3.20 Thanks, Guenter -- The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce: Linux 3.19-rc6 (2015-01-25 20:04:41 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next for you to fetch changes up to dd378b1bcaa0ef5b14cca1e52b58ef9a3279fd8b: hwmon: (tmp102) add hibernation callbacks (2015-02-03 12:17:12 -0800) Asaf Vertz (1): hwmon: (abx500) Fix format string warnings Bartosz Golaszewski (7): hwmon: (ina2xx) reinitialize the chip in case it's been reset hwmon: (ina2xx) remove a stray new line hwmon: (ina2xx) don't accept shunt values greater than the calibration factor hwmon: (ina2xx) make shunt resistance configurable at run-time hwmon: (ina2xx) implement update_interval attribute for ina226 hwmon: (ina2xx) remove an unnecessary dev_get_drvdata() result check hwmon: (ina2xx) use DIV_ROUND_CLOSEST() to avoid rounding errors Grygorii Strashko (1): hwmon: (tmp102) add hibernation callbacks Guenter Roeck (5): hwmon: (jc42) Use sign_extend32 for sign extension hwmon: (jc42) Fix integer overflow hwmon: (jc42) Fix integer overflow when writing hysteresis value hwmon: (ads2828) Convert to use regmap hwmon: (ads2828) Only keep data in device data structure if needed Jean Delvare (1): hwmon: (jc42) Allow negative hysteresis temperatures Kevin Hilman (1): hwmon: (ina2xx) Add ina231 compatible string Krzysztof Kozlowski (1): hwmon: (nct7802) Constify struct regmap_config Rasmus Villemoes (2): hwmon: (ad7314) Do proper sign extension hwmon: (adc128d818) Do proper sign extension Documentation/hwmon/ina2xx | 23 +++- drivers/hwmon/Kconfig | 5 +- drivers/hwmon/abx500.c | 6 +- drivers/hwmon/ad7314.c | 5 +- drivers/hwmon/adc128d818.c | 3 +- drivers/hwmon/ads7828.c| 102 ++ drivers/hwmon/ina2xx.c | 334 +++-- drivers/hwmon/jc42.c | 15 +- drivers/hwmon/nct7802.c| 2 +- drivers/hwmon/tmp102.c | 15 +- 10 files changed, 375 insertions(+), 135 deletions(-) -- 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/1] Staging: rtl8192u: Coding Style Improvements
Thank you, I'll resubmit this with additional corrections to format strings.
On Sun, Feb 8, 2015 at 1:54 AM, Joe Perches wrote:
> On Sun, 2015-02-08 at 01:49 -0800, Tolga Ceylan wrote:
>> Lines over 80 were corrected
> []
>> diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c
>> b/drivers/staging/rtl8192u/r8190_rtl8256.c
> []
>> @@ -37,43 +37,71 @@ void PHY_SetRF8256Bandwidth(struct net_device *dev,
>> HT_CHANNEL_WIDTH Bandwidth)
> []
>> + /* 8256 D-cut, E-cut, xiong: consider it later! */
>> + if (priv->card_8192_version == VERSION_819xU_A
>> + || priv->card_8192_version == VERSION_819xU_B)
>> {
>
> This is more commonly written:
>
> if (priv->card_8192_version == VERSION_819xU_A ||
> priv->card_8192_version == VERSION_819xU_B) {
>
>
--
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] brcmfmac: avoid duplicated suspend/resume operation
>From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fu
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject: [PATCH v2] brcmfmac: avoid duplicated suspend/resume operation
WiFi chip has 2 SDIO functions, and PM core will trigger
twice suspend/resume operations for one WiFi chip to do
the same things. This patch avoid this case.
Acked-by: Arend van Spriel
Signed-off-by: Zhonghui Fu
---
Changes in v2:
- Remove two "Acked-by" lines
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9880dae..618b545 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -1139,11 +1139,17 @@ void brcmf_sdio_wowl_config(struct device *dev, bool
enabled)
static int brcmf_ops_sdio_suspend(struct device *dev)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
+ struct brcmf_sdio_dev *sdiodev;
mmc_pm_flag_t sdio_flags;
+ struct sdio_func *func = dev_to_sdio_func(dev);
brcmf_dbg(SDIO, "Enter\n");
+ if (func->num == 2)
+ return 0;
+
+ sdiodev = bus_if->bus_priv.sdio;
+
atomic_set(>suspend, true);
if (sdiodev->wowl_enabled) {
@@ -1164,9 +1170,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
static int brcmf_ops_sdio_resume(struct device *dev)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
+ struct brcmf_sdio_dev *sdiodev;
+ struct sdio_func *func = dev_to_sdio_func(dev);
brcmf_dbg(SDIO, "Enter\n");
+
+ if (func->num == 2)
+ return 0;
+
+ sdiodev = bus_if->bus_priv.sdio;
+
if (sdiodev->pdata && sdiodev->pdata->oob_irq_supported)
disable_irq_wake(sdiodev->pdata->oob_irq_nr);
brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
-- 1.7.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 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
On 02/08/2015 01:36 PM, Lukasz Majewski wrote:
On Fri, 6 Feb 2015 10:36:57 -0800
Guenter Roeck wrote:
On Fri, Feb 06, 2015 at 05:59:07PM +0100, Lukasz Majewski wrote:
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT
bindings are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end
enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old
behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead
of_find_property()
- More verbose patch description added
---
drivers/hwmon/pwm-fan.c | 54
- 1 file changed,
53 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 870e100..f3f5843 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,50 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx) +{
+ struct device_node *np = dev->of_node;
+ int num, i, ret;
+
+ ret = of_property_count_elems_of_size(np, "cooling-levels",
+ sizeof(u32));
+
+ if (ret == -EINVAL) {
+ dev_err(dev, "Property 'cooling-levels' not
found\n");
+ return 0;
Returning 0 is obviously not an error, otherwise you would not return
0 here. So dev_err is wrong.
pr_info would be more appropriate here.
Also, the message itself is wrong; the
property may well be there but have a wrong size.
As fair as I remember the -EINVAL is set only when the property is not
defined. Such situation is correct and our pwm-fan driver should work
with or without it.
of_property_count_elems_of_size returns -EINVAL if np is NULL or if
there is no peoperty or prop->length % elem_size != 0, and -ENODATA
if there is no value associated with the property.
If -EINVAL is not an error, please no message. Noisy drivers are
just that, noisy.
+ }
+
+ if (ret <= 0) {
+ dev_err(dev, "Wrong data!\n");
+ return ret;
+ }
This will result in the driver failing to load if devicetree is not
configured (of_property_count_elems_of_size will return -ENOSYS).
As you pointed out in the comment to v2:
It is OK if the "cooling-levels" is not defined in DT. However, if it
has broken definition, then we should return error. This is what we do
here.
You don't return an error, you return 0, at least in some circumstances.
This is not acceptable. Also, if the call returns 0 you don't return
an error but display a "Wrong data!" error message. Either it is an
error or it is not, but not both.
This is an error. "cooling-levels" with zero elements is regarded as a
broken property.
It returns -ENOSYS if DT is not configured, which is still unacceptable.
And, again, if ret == 0 is an error, you should return an error code,
not display an error message and return 0.
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: [next-20141231] sched: WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 __might_sleep+0xbd/0xd0()
On Sun, Jan 4, 2015 at 8:53 AM, Sedat Dilek wrote: > On Sun, Jan 4, 2015 at 1:59 AM, Ming Lei wrote: >> Hi Sedat, >> >> On Sun, Jan 4, 2015 at 7:42 AM, Sedat Dilek wrote: >>> On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote: Hi, with next-20141231 I am seeing this call-trace: [ 88.028632] [ cut here ] [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 __might_sleep+0xbd/0xd0() [ 88.028646] do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait_event+0x5d/0x110 [ 88.028648] Modules linked in: ppp_deflate bsd_comp ppp_async crc_ccitt arc4 iwldvm uvcvideo mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek parport_pc videobuf2_vmalloc snd_hda_codec_generic ppdev videobuf2_memops snd_hda_intel videobuf2_core rfcomm bnep snd_hda_controller option snd_hda_codec v4l2_common i915 joydev videodev usb_wwan snd_hwdep usbserial cdc_ether snd_pcm usbnet btusb snd_seq_midi snd_seq_midi_event bluetooth psmouse snd_rawmidi iwlwifi snd_seq i2c_algo_bit drm_kms_helper snd_timer serio_raw snd_seq_device samsung_laptop drm snd cfg80211 soundcore video lpc_ich intel_rst wmi mac_hid binfmt_misc lp parport hid_generic usbhid hid r8169 mii usb_storage [ 88.028694] CPU: 1 PID: 2539 Comm: fio Not tainted 3.19.0-rc2-next20141231-1-iniza-small #1 [ 88.028695] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 88.028697] 81a66d5f 880070f43c38 8175c50c [ 88.028700] 880070f43c88 880070f43c78 810753ba 880070f43d28 [ 88.028703] 81a67ef5 026d 00dce810 [ 88.028706] Call Trace: [ 88.028712] [] dump_stack+0x4c/0x65 [ 88.028716] [] warn_slowpath_common+0x8a/0xc0 [ 88.028719] [] warn_slowpath_fmt+0x46/0x50 [ 88.028722] [] ? mark_held_locks+0x6d/0xa0 [ 88.028725] [] ? mutex_lock_nested+0x2b2/0x4e0 [ 88.028727] [] ? prepare_to_wait_event+0x5d/0x110 [ 88.028729] [] ? prepare_to_wait_event+0x5d/0x110 [ 88.028731] [] __might_sleep+0xbd/0xd0 [ 88.028734] [] mutex_lock_nested+0x2f/0x4e0 [ 88.028736] [] ? prepare_to_wait_event+0x53/0x110 [ 88.028739] [] aio_read_events+0x4f/0x2d0 [ 88.028742] [] ? trace_hardirqs_on+0xd/0x10 [ 88.028745] [] read_events+0x200/0x320 [ 88.028747] [] ? wait_woken+0xc0/0xc0 [ 88.028750] [] ? hrtimer_get_res+0x50/0x50 [ 88.028753] [] ? lookup_ioctx+0xd0/0x140 [ 88.028755] [] SyS_io_getevents+0x62/0x100 [ 88.028759] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 88.028762] [] system_call_fastpath+0x16/0x1b [ 88.028764] ---[ end trace dba4f4a06fcdd178 ]--- >> >> It is an known linux-aio issue, see the following link: >> >> http://marc.info/?t=14192504964=1=2 >> > > This discussion resulted in a RFC patch of Chris Mason which is still > discussed in [1]. > > - Sedat - > > [1] http://marc.info/?t=14192939611=1=2 The issue was fixed in Linux v3.19 (final) by... commit 9c9ce763b114e608b5cf3aa6cb69ad9f6e8b6adf "aio: annotate aio_read_event_ring for sleep patterns" See also [2] for more details. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9c9ce763b114e608b5cf3aa6cb69ad9f6e8b6adf [2] http://marc.info/?l=linux-fsdevel=142345568702640=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/
linux-next: build failure after merge of the block tree
Hi Jens,
After merging the block tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
fs/nfs/flexfilelayout/flexfilelayout.c: In function
'ff_layout_mark_request_commit':
fs/nfs/flexfilelayout/flexfilelayout.c:1369:47: error: 'struct address_space'
has no member named 'backing_dev_info'
inc_bdi_stat(page_file_mapping(req->wb_page)->backing_dev_info,
^
Caused by commit b83ae6d42143 ("fs: remove mapping->backing_dev_info")
interacting with commit d67ae825a59d ("pnfs/flexfiles: Add the FlexFile
Layout Driver") from the nfs tree.
I have added this merge fix patch (assuming it is correct, someone
needs to tell Linus about this when the trees get merged):
From: Stephen Rothwell
Date: Mon, 9 Feb 2015 15:20:12 +1100
Subject: [PATCH] pnfs/flexfiles: fix FlexFile Layout Driver for removal
mapping->backing_dev_info
Signed-off-by: Stephen Rothwell
---
fs/nfs/flexfilelayout/flexfilelayout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c
b/fs/nfs/flexfilelayout/flexfilelayout.c
index f29fb7d7e8f8..c22ecaa86c1c 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -1366,7 +1366,7 @@ ff_layout_mark_request_commit(struct nfs_page *req,
spin_unlock(cinfo->lock);
if (!cinfo->dreq) {
inc_zone_page_state(req->wb_page, NR_UNSTABLE_NFS);
- inc_bdi_stat(page_file_mapping(req->wb_page)->backing_dev_info,
+
inc_bdi_stat(inode_to_bdi(page_file_mapping(req->wb_page)->host),
BDI_RECLAIMABLE);
__mark_inode_dirty(req->wb_context->dentry->d_inode,
I_DIRTY_DATASYNC);
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpCuPVZFJGue.pgp
Description: OpenPGP digital signature
[LKP] [kernfs] 2427d387fd2: -1.8% boot-slabinfo.num_objs
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 2427d387fd24bc04a5c270161473eaca8239cd39 ("kernfs: convert node name
allocation to kstrdup_const")
Some slab memory can be saved with the patch :)
testbox/testcase/testparams: lkp-t410/boot/performance-1
9f5b2beccb0ad113 2427d387fd24bc04a5c2701614
--
%stddev %change %stddev
\ |\
1110 ± 2% -8.5% 1016 ± 5% boot-meminfo.PageTables
144680 ± 0% -2.1% 141631 ± 0% boot-slabinfo.num_objs
107666 ± 0% -1.1% 106464 ± 0% boot-meminfo.Slab
26953 ± 0% -1.0% 26672 ± 0% boot-slabinfo.num_pages
testbox/testcase/testparams: lkp-a03/boot/performance-1
9f5b2beccb0ad113 2427d387fd24bc04a5c2701614
--
fail:runs %reproductionfail:runs
| | |
29 ± 28% -60.2% 11 ± 49% time.involuntary_context_switches
166 ± 1% -2.4%162 ± 1% boot-time.idle
133976 ± 0% -1.8% 131519 ± 0% boot-slabinfo.num_objs
testbox/testcase/testparams: lkp-a04/boot/performance-1
9f5b2beccb0ad113 2427d387fd24bc04a5c2701614
--
133681 ± 0% -1.8% 131309 ± 0% boot-slabinfo.num_objs
lkp-t410: Westmere
Memory: 2G
lkp-a03: Atom
Memory: 8G
lkp-a04: Atom
Memory: 8G
boot-slabinfo.num_pages
27100 ++*--*-*--*-+
| .*..*.* *.* |
27000 ++ .* *. |
| *.. .* .*.*..* * .* .*.*..*.*
26900 ++ * + .* + .* + .*|
|: *. *. *. |
26800 *+ |
| |
26700 ++ OO O O O O |
| O O O O O O OO O O O O |
26600 ++ |
| OO|
26500 O+ O O O O |
| |
26400 ++--+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
---
testcase: boot
default-monitors:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor: performance
model: Westmere
memory: 2G
hdd_partitions: "/dev/disk/by-id/ata-FUJITSU_MJA2250BH_G2_K95CT9C2G29W-part6"
swap_partitions:
rootfs_partition: "/dev/disk/by-id/ata-FUJITSU_MJA2250BH_G2_K95CT9C2G29W-part7"
boot-slabinfo:
boot-meminfo:
memmap:
boot-memory:
boot-time:
kernel-size:
sleep: 1
branch: next/master
commit: b50cadffd155708cbd890d0ee6cc309c51af0f7d
repeat_to: 1
testbox: lkp-t410
tbox_group: lkp-t410
kconfig: x86_64-nfsroot
enqueue_time: 2015-02-04 11:59:07.652843690 +08:00
kernel:
"/kernel/x86_64-nfsroot/b50cadffd155708cbd890d0ee6cc309c51af0f7d/vmlinuz-3.19.0-rc7-next-20150203-gb50cadf"
user: lkp
queue: boot
rootfs: debian-x86_64-2015-02-02.cgz
result_root:
"/result/lkp-t410/boot/performance-1/debian-x86_64-2015-02-02.cgz/x86_64-nfsroot/b50cadffd155708cbd890d0ee6cc309c51af0f7d/0"
job_file:
"/lkp/scheduled/lkp-t410/boot_boot-performance-1-x86_64-nfsroot-b50cadffd155708cbd890d0ee6cc309c51af0f7d-0.yaml"
dequeue_time: 2015-02-04 13:12:08.541138058 +08:00
nr_cpu: "$(nproc)"
job_state: finished
loadavg: 1.07 0.34 0.12 1/129 3835
start_time: '1423026776'
end_time: '1423026777'
version: "/lkp/lkp/.src-20150204-124551"
___
LKP mailing list
l...@linux.intel.com
Re: [PATCH] pci: spear: Drop __initdata from struct platform_driver spear13xx_pcie_driver
On Sun, Feb 8, 2015 at 3:37 PM, Matwey V. Kornilov wrote: > spear13xx_pcie_driver.driver is allocated in text.init section > and then the pointer to it is passed futher. This patch is to avoid > crashes like the following, when freed memory is used: > > #0 __device_attach (drv=0xc0ed5608 , > data=0xdb622610) at ../drivers/base/dd.c:409 > #1 0xc07a4798 in bus_for_each_drv (bus=, start= out>, data=0xda0, fn=0xc07a6740 <__device_attach>) > at ../drivers/base/bus.c:463 > #2 0xc07a6324 in device_attach (dev=0xdb622610) at ../drivers/base/dd.c:447 > #3 0xc07a5814 in bus_probe_device (dev=0xdb622610) at > ../drivers/base/bus.c:558 > #4 0xc07a38d8 in device_add (dev=) at > ../drivers/base/core.c:1058 > #5 0xc08b6a5c in of_device_add (ofdev=) at > ../drivers/of/device.c:66 > #6 0xc08b742c in of_platform_device_create_pdata (np=, > bus_id=0x0 <__vectors_start>, platform_data=0x0 <__vectors_start>, > parent=) at ../drivers/of/platform.c:241 > #7 0xc08b7568 in of_platform_bus_create (bus=0xdfa46780, matches=0x0 > <__vectors_start>, lookup=0x0 <__vectors_start>, parent=0xdb183410, > strict=true) at ../drivers/of/platform.c:414 > #8 0xc08b79bc in of_platform_populate (root=0xc0ed5608 > , matches=0xdb622610, lookup=0xda0, > parent=0xc07a6740 <__device_attach>) at ../drivers/of/platform.c:501 > #9 0xbf30 in am335x_child_probe (pdev=0xdb183400) at > ../drivers/usb/musb/musb_am335x.c:12 > #10 0xc07a83f0 in platform_drv_probe (_dev=0xdb183410) at > ../drivers/base/platform.c:512 > #11 0xc07a64e8 in really_probe (drv=, dev=) at > ../drivers/base/dd.c:302 > #12 driver_probe_device (drv=0xbf000234, dev=0xdb183410) at > ../drivers/base/dd.c:399 > #13 0xc07a6820 in __driver_attach (dev=0xdb183410, data=0xbf000234) at > ../drivers/base/dd.c:477 > #14 0xc07a46e8 in bus_for_each_dev (bus=, start= out>, data=0xda0, fn=0xc07a83a4 ) > at ../drivers/base/bus.c:313 > #15 0xc07a5ebc in driver_attach (drv=) at > ../drivers/base/dd.c:496 > #16 0xc07a5af0 in bus_add_driver (drv=0xbf000234) at > ../drivers/base/bus.c:694 > #17 0xc07a6fec in driver_register (drv=0xbf000234) at > ../drivers/base/driver.c:167 > #18 0xc0209c34 in do_one_initcall (fn=0xbf002000) at ../init/main.c:801 > #19 0xc02e0494 in do_init_module (mod=) at > ../kernel/module.c:3142 > #20 load_module (info=0xdb6b1f54, uargs=, flags= out>) at ../kernel/module.c:3461 > #21 0xc02e0a44 in SYSC_finit_module (flags=, uargs= out>, fd=) at ../kernel/module.c:3537 > #22 SyS_finit_module (fd=7, uargs=-1225602132, flags=0) at > ../kernel/module.c:3518 > #23 0xc021a680 in ?? () > > Fixes: 6675ef212da (PCI: spear: Fix Section mismatch compilation warning for > probe()) wouldn't this again result in the problem reported above ? -- 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] PM-Trace: add pm-trace support for suspending phase
>From ec9c0f24e800461361eaf8b280abe4272b00772d Mon Sep 17 00:00:00 2001
From: Zhonghui Fu
Date: Mon, 9 Feb 2015 11:09:22 +0800
Subject: [PATCH] PM-Trace: add pm-trace support for suspending phase
Occasinally, the system can't come back up after suspend/resume
due to problems of device suspending phase. This patch make
PM_TRACE infrastructure cover device suspending phase of
suspend/resume process, and the information in RTC can tell
develpers which device suspending function make system hang.
Signed-off-by: Zhonghui Fu
---
arch/x86/include/asm/resume-trace.h |2 +-
drivers/base/power/main.c | 30 +-
include/linux/resume-trace.h|2 +-
3 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/resume-trace.h
b/arch/x86/include/asm/resume-trace.h
index 3ff1c2c..0ca2215 100644
--- a/arch/x86/include/asm/resume-trace.h
+++ b/arch/x86/include/asm/resume-trace.h
@@ -3,7 +3,7 @@
#include
-#define TRACE_RESUME(user) \
+#define TRACE_SUSPEND_RESUME(user) \
do { \
if (pm_trace_enabled) { \
const void *tracedata; \
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 9717d5f..d2070b5 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -477,7 +477,7 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state, bool asyn
int error = 0;
TRACE_DEVICE(dev);
- TRACE_RESUME(0);
+ TRACE_SUSPEND_RESUME(0);
if (dev->power.syscore || dev->power.direct_complete)
goto Out;
@@ -511,7 +511,7 @@ static int device_resume_noirq(struct device *dev,
pm_message_t state, bool asyn
Out:
complete_all(>power.completion);
- TRACE_RESUME(error);
+ TRACE_SUSPEND_RESUME(error);
return error;
}
@@ -606,7 +606,7 @@ static int device_resume_early(struct device *dev,
pm_message_t state, bool asyn
int error = 0;
TRACE_DEVICE(dev);
- TRACE_RESUME(0);
+ TRACE_SUSPEND_RESUME(0);
if (dev->power.syscore || dev->power.direct_complete)
goto Out;
@@ -639,7 +639,7 @@ static int device_resume_early(struct device *dev,
pm_message_t state, bool asyn
dev->power.is_late_suspended = false;
Out:
- TRACE_RESUME(error);
+ TRACE_SUSPEND_RESUME(error);
pm_runtime_enable(dev);
complete_all(>power.completion);
@@ -735,7 +735,7 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
DECLARE_DPM_WATCHDOG_ON_STACK(wd);
TRACE_DEVICE(dev);
- TRACE_RESUME(0);
+ TRACE_SUSPEND_RESUME(0);
if (dev->power.syscore)
goto Complete;
@@ -811,7 +811,7 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
Complete:
complete_all(>power.completion);
- TRACE_RESUME(error);
+ TRACE_SUSPEND_RESUME(error);
return error;
}
@@ -1017,6 +1017,9 @@ static int __device_suspend_noirq(struct device *dev,
pm_message_t state, bool a
char *info = NULL;
int error = 0;
+ TRACE_DEVICE(dev);
+ TRACE_SUSPEND_RESUME(0);
+
if (async_error)
goto Complete;
@@ -1057,6 +1060,7 @@ static int __device_suspend_noirq(struct device *dev,
pm_message_t state, bool a
Complete:
complete_all(>power.completion);
+ TRACE_SUSPEND_RESUME(error);
return error;
}
@@ -1078,7 +1082,7 @@ static int device_suspend_noirq(struct device *dev)
{
reinit_completion(>power.completion);
- if (pm_async_enabled && dev->power.async_suspend) {
+ if (is_async(dev)) {
get_device(dev);
async_schedule(async_suspend_noirq, dev);
return 0;
@@ -1157,6 +1161,9 @@ static int __device_suspend_late(struct device *dev,
pm_message_t state, bool as
char *info = NULL;
int error = 0;
+ TRACE_DEVICE(dev);
+ TRACE_SUSPEND_RESUME(0);
+
__pm_runtime_disable(dev, false);
if (async_error)
@@ -1198,6 +1205,7 @@ static int __device_suspend_late(struct device *dev,
pm_message_t state, bool as
async_error = error;
Complete:
+ TRACE_SUSPEND_RESUME(error);
complete_all(>power.completion);
return error;
}
@@ -1219,7 +1227,7 @@ static int device_suspend_late(struct device *dev)
{
reinit_completion(>power.completion);
- if (pm_async_enabled && dev->power.async_suspend) {
+ if (is_async(dev)) {
get_device(dev);
async_schedule(async_suspend_late, dev);
return 0;
@@ -1338,6 +1346,9 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
int error = 0;
Re: [PATCH v3] kernel: Conditionally support non-root users, groups and capabilities
On Fri, Feb 06, 2015 at 02:03:56AM +0200, Iulia Manda wrote:
> There are a lot of embedded systems that run most or all of their
> functionality
> in init, running as root:root. For these systems, supporting multiple users is
> not necessary.
>
> This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for
> non-root
> users, non-root groups, and capabilities optional. It is enabled under
> CONFIG_EXPERT menu.
>
> When this symbol is not defined, UID and GID are zero in any possible case
> and processes always have all capabilities.
>
> The following syscalls are compiled out: setuid, setregid, setgid,
> setreuid, setresuid, getresuid, setresgid, getresgid, setgroups, getgroups,
> setfsuid, setfsgid, capget, capset.
>
> Also, groups.c is compiled out completely.
>
> This change saves about 25 KB on a defconfig build.
>
> The kernel was booted in Qemu. All the common functionalities work. Adding
> users/groups is not possible, failing with -ENOSYS.
>
> Bloat-o-meter output:
> add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
I presume that v4 will have your Signed-off-by. ;-)
Testing on my rcutorture setup uncovered an additional required dependency,
please see patch at the end of this email. With that fix, either separately
or merged into your patch:
Tested-by: Paul E. McKenney
One question below about moving the definition of capable(). Either way:
Reviewed-by: Paul E. McKenney
> ---
> Changes since v2:
> - rename symbol;
> - make SECURITY dependent on MULTIUSER
>
> arch/s390/Kconfig |1 +
> drivers/staging/lustre/lustre/Kconfig |1 +
> fs/nfsd/Kconfig |1 +
> include/linux/capability.h| 29 +++
> include/linux/cred.h | 23 ++
> include/linux/uidgid.h| 12 +++
> init/Kconfig | 19 +-
> kernel/Makefile |4 +++-
> kernel/capability.c | 35
> ++---
> kernel/cred.c |3 +++
> kernel/groups.c |3 ---
> kernel/sys.c |2 ++
> kernel/sys_ni.c | 14 +
> net/sunrpc/Kconfig|2 ++
> security/Kconfig |1 +
> 15 files changed, 125 insertions(+), 25 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 68b68d7..71fb2d1 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -324,6 +324,7 @@ config COMPAT
> select COMPAT_BINFMT_ELF if BINFMT_ELF
> select ARCH_WANT_OLD_COMPAT_IPC
> select COMPAT_OLD_SIGACTION
> + depends on MULTIUSER
> help
> Select this option if you want to enable your system kernel to
> handle system-calls from ELF binaries for 31 bit ESA. This option
> diff --git a/drivers/staging/lustre/lustre/Kconfig
> b/drivers/staging/lustre/lustre/Kconfig
> index 6725467..62c7bba 100644
> --- a/drivers/staging/lustre/lustre/Kconfig
> +++ b/drivers/staging/lustre/lustre/Kconfig
> @@ -10,6 +10,7 @@ config LUSTRE_FS
> select CRYPTO_SHA1
> select CRYPTO_SHA256
> select CRYPTO_SHA512
> + depends on MULTIUSER
> help
> This option enables Lustre file system client support. Choose Y
> here if you want to access a Lustre file system cluster. To compile
> diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig
> index 7339515..df0a5d9 100644
> --- a/fs/nfsd/Kconfig
> +++ b/fs/nfsd/Kconfig
> @@ -6,6 +6,7 @@ config NFSD
> select SUNRPC
> select EXPORTFS
> select NFS_ACL_SUPPORT if NFSD_V2_ACL
> + depends on MULTIUSER
> help
> Choose Y here if you want to allow other computers to access
> files residing on this system using Sun's Network File System
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index aa93e5e..0c0ae0d 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -205,6 +205,7 @@ static inline kernel_cap_t cap_raise_nfsd_set(const
> kernel_cap_t a,
> cap_intersect(permitted, __cap_nfsd_set));
> }
>
> +#ifdef CONFIG_MULTIUSER
> extern bool has_capability(struct task_struct *t, int cap);
> extern bool has_ns_capability(struct task_struct *t,
> struct user_namespace *ns, int cap);
> @@ -213,6 +214,34 @@ extern bool has_ns_capability_noaudit(struct task_struct
> *t,
> struct user_namespace *ns, int cap);
> extern bool capable(int cap);
> extern bool ns_capable(struct user_namespace *ns, int cap);
> +#else
> +static inline bool has_capability(struct task_struct *t, int cap)
> +{
> +return true;
> +}
> +static inline bool has_ns_capability(struct task_struct *t,
> + struct user_namespace
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
fs/configfs/configfs_internal.h between commit 22dc94f27d4b ("configfs:
configfs_create() init callback is never NULL and it never fails") from
the vfs tree and commit b4caecd48005 ("fs: introduce
f_op->mmap_capabilities for nommu mmap support") from the block 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 fs/configfs/configfs_internal.h
index 865e41983611,a315677e44d3..
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@@ -69,9 -69,7 +69,7 @@@ extern struct kmem_cache *configfs_dir_
extern int configfs_is_root(struct config_item *item);
extern struct inode * configfs_new_inode(umode_t mode, struct configfs_dirent
*, struct super_block *);
-extern int configfs_create(struct dentry *, umode_t mode, int (*init)(struct
inode *));
+extern int configfs_create(struct dentry *, umode_t mode, void (*init)(struct
inode *));
- extern int configfs_inode_init(void);
- extern void configfs_inode_exit(void);
extern int configfs_create_file(struct config_item *, const struct
configfs_attribute *);
extern int configfs_make_dirent(struct configfs_dirent *,
pgpZ3rJknX6LV.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the pm tree
On Mon, Feb 09, 2015 at 03:19:33AM +, Rafael J. Wysocki wrote:
> On Monday, February 09, 2015 01:26:42 PM Stephen Rothwell wrote:
> > Hi Rafael,
> >
> > After merging the pm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from drivers/of/of_pci.c:1:0:
> > drivers/of/of_pci.c: In function 'of_pci_get_host_bridge_resources':
> > include/linux/list.h:447:43: error: dereferencing pointer to incomplete type
> > for (pos = list_first_entry(head, typeof(*pos), member); \
> >^
>
> [cut]
>
> >
> > Caused by commit 14d76b68f281 ("PCI: Use common resource list
> > management code instead of private implementation") interacting with
> > commit d2be00c0fb5a ("of/pci: Free resources on failure in
> > of_pci_get_host_bridge_resources()") from the pci tree.
>
> Thanks for identifying this!
Thank you !
> > I applied the following merge fix patch (which may need more work?).
> > Someone needs to remember to tell Linus about this fix (or similar)
> > when these trees get merged.
>
> The patch looks correct to me, so I did the following.
>
> I pulled the Bjorn's pci/host-generic branch that contained just that one
> commit which conflicted with the Gerry's one into my acpi-resources branch
> and folded the patch below into the merge.
>
It looks fine to me, thank you.
Lorenzo
> > From: Stephen Rothwell
> > Date: Mon, 9 Feb 2015 13:08:24 +1100
> > Subject: [PATCH] of/pci: fix up for "PCI: Use common resource list
> > management
> > code instead of private implementation"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/of/of_pci.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 60dc36c865b5..110fece2ff53 100644
> > --- a/drivers/of/of_pci.c
> > +++ b/drivers/of/of_pci.c
> > @@ -140,7 +140,7 @@ int of_pci_get_host_bridge_resources(struct device_node
> > *dev,
> > unsigned char busno, unsigned char bus_max,
> > struct list_head *resources, resource_size_t *io_base)
> > {
> > - struct pci_host_bridge_window *window;
> > + struct resource_entry *window;
> > struct resource *res;
> > struct resource *bus_range;
> > struct of_pci_range range;
> > @@ -226,7 +226,7 @@ int of_pci_get_host_bridge_resources(struct device_node
> > *dev,
> > conversion_failed:
> > kfree(res);
> > parse_failed:
> > - list_for_each_entry(window, resources, list)
> > + resource_list_for_each_entry(window, resources)
> > kfree(window->res);
> > pci_free_resource_list(resources);
> > kfree(bus_range);
> >
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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 3.19 - and merge window now open
So nothing all that exciting happened, and while I was tempted a couple of times to do an rc8, there really wasn't any reason for it. Just as an example, Sasha Levin used KASan and found an interesting bug in paravirtualized spinlocks, but realistically it's been around forever, and it's not even clear that it can really ever trigger in practice. We'll get it fixed, and mark it for stable, and tempting as it was, it wasn't really a reason to delay 3.19. And the actual fixes that went in (see appended shortlog) were all fairly small, with the exception of some medium-sized infiniband changes that were all reverting code that just wasn't ready. So it's out there - go and get it. And as a result, the merge window for 3.20 is obviously also now open. Linus --- Aaro Koskinen (1): MIPS: OCTEON: fix kernel crash when offlining a CPU Alex Deucher (2): drm/radeon: don't init gpuvm if accel is disabled (v3) drm/radeon: properly set vm fragment size for TN/RL Arnd Bergmann (6): ARM: 8298/1: ARM_KERNMEM_PERMS only works with MMU enabled net: cs89x0: always build platform code if !HAS_IOPORT_MAP net: wan: add missing virt_to_bus dependencies net: lance,ni64: don't build for ARM net: am2150: fix nmclan_cs.c shared interrupt handling mm: export "high_memory" symbol on !MMU Baruch Siach (2): tools/liblockdep: ignore generated .so file tools/liblockdep: don't include host headers Bhuvanchandra DV (1): spi: spi-fsl-dspi: Remove usage of devm_kzalloc Bo Shen (2): ASoC: atmel_ssc_dai: fix start event for I2S mode ASoC: atmel_ssc_dai: fix the setting for DSP mode Boris Ostrovsky (1): x86, microcode: Return error from driver init code when loader is disabled Brian King (1): sd: Fix max transfer length for 4k disks Brian Norris (1): MIPS: JZ4740: Fixup #include's (sparse) Charlotte Richardson (1): PCI: Add NEC variants to Stratus ftServer PCIe DMI check Chen Gang (1): net: usb: sr9700: Use 'SR_' prefix for the common register macros Christian König (1): drm/radeon: fix PLLs on RS880 and older v2 Chung-Ling Tang (1): nios2: fix unhandled signals Dan Carpenter (1): isdn: off by one in connect_res() Dave Chinner (1): aio: annotate aio_read_event_ring for sleep patterns David Daney (1): MIPS: Fix C0_Pagegrain[IEC] support. David L Stevens (1): sunvnet: set queue mapping when doing packet copies David Vrabel (1): xen-netback: stop the guest rx thread after a fatal error Ed Swierk (1): MIPS: Fix restart of indirect syscalls Eric Dumazet (7): tcp: ipv4: initialize unicast_sock sk_pacing_rate net: sched: fix panic in rate estimators ipv4: tcp: get rid of ugly unicast_sock flow_keys: n_proto type should be __be16 net: remove some sparse warnings ipv6: fix sparse errors in ip6_make_flowlabel() sit: fix some __be16/u16 mismatches Eric Nelson (1): ASoC: sgtl5000: add delay before first I2C access Felix Fietkau (1): MIPS: IRQ: Fix disable_irq on CPU IRQs Filip Brozovic (1): ASoC: sgtl5000: Use shift mask when setting codec mode Florian Westphal (1): ppp: deflate: never return len larger than output buffer Forrest Liu (1): Btrfs: add missing blk_finish_plug in btrfs_sync_log() Giel van Schijndel (1): cifs: use memzero_explicit to clear stack buffer Haggai Eran (1): IB/core: Temporarily disable ex_query_device uverb Haiyang Zhang (1): hyperv: Fix the error processing in netvsc_send() Hemmo Nieminen (1): MIPS: Fix kernel lockup or crash after CPU offline/online Ignacy Gawędzki (1): cls_api.c: Fix dumping of non-existing actions' stats. Ilija Hadzic (2): drm/radeon: fix the crash in benchmark functions drm/radeon: fix the crash in test functions Iyappan Subramanian (1): drivers: net: xgene: fix: Out of order descriptor bytes read Jack Morgenstein (1): net/mlx4_core: Fix kernel Oops (mem corruption) when working with more than 80 VFs James Cowgill (1): MIPS: ELF: fix loading o32 binaries on 64-bit kernels James Hogan (6): MIPS: mips-cm: Fix sparse warnings MIPS: smp-mt,smp-cmp: Enable all HW IRQs on secondary CPUs MIPS: mipsregs.h: Add write_32bit_cp1_register() MIPS: traps: Fix inline asm ctc1 missing .set hardfloat MIPS: fork: Fix MSA/FPU/DSP context duplication race IRQCHIP: mips-gic: Avoid rerouting timer IRQs for smp-cmp Jan Beulich (1): sched/fair: Avoid using uninitialized variable in preferred_group_nid() Jarkko Nikula (1): ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail Jie Yang (2): ASoC: Intel: Used lock version to update shim registers MAINTAINERS: ASoC: add maintainer for Intel BDW/HSW ASoC driver Johan Hovold (2): gpio: sysfs: fix memory leak in gpiod_export_link gpio: sysfs: fix memory leak in
Re: [PATCH v3] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()
On 2/9/15 04:17, Marcel Holtmann wrote:
> Hi Chen,
>
> hci_test_bit() does not modify 2nd parameter, so it is better to let it
> be constant, or may cause build warning. The related warning (with
> allmodconfig under xtensa):
>
> net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
> net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of
> 'hci_test_bit' discards 'const' qualifier from pointer target type
> [-Wdiscarded-array-qualifiers]
> _sec_filter.ocf_mask[ogf])) &&
> ^
> net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is
> of type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
> static inline int hci_test_bit(int nr, void *addr)
> ^
>
> hci_test_bit() always treats 2nd parameter is u32, and all callers also
> know about it, so 2nd parameter of hci_test_bit() need use 'const u32 *'
> instead of 'void *'.
>
> C language treats the array function parameter as a pointer, so the
> caller need not use '&' for the 2 demotion array, or it reports warning:
> 'const unsigned int (*)[4]' is different with 'const unsigned int *'.
I still think you are possibly papering over potential bugs
on big-endian 64 bit systems.
unsigned long vs u32.
How are the bits actually set?
>>>
From current usage of event_mask, "(u32 *) f->event_mask" is only for
>>> event_mask data storage, not for calculation (always as "u32 *" for
>>> calculation).
>>>
>>> [root@localhost linux-next]# grep -rn "\"
>>> include/net/bluetooth net/bluetooth
>>> include/net/bluetooth/hci_sock.h:51: unsigned long event_mask[2];
>>
>> e.g. use "unsigned char event_mask[2 * sizeof(unsigned long)]" instead
>> of "unsigned long event_mask[2]".
>>
>> There is still no any issue within "hci_sock.c" (although I am not sure
>> whether this modification may cause issues in another modules outside
>> kernel).
>
> what about writing a test case for userspace that ensures that things are
> working correctly. As I said before, we left it this way since it is part of
> the API.
>
If it is really the API which can be used outside kernel, what you said
sounds reasonable to me. But I guess, except the related orgnizations/
company/members, most of kernel members can not give a suitable test:
- It is an API, but we only know kernel part implementation, and we
also know that the kernel part implementation intends to use
"unsigned long event_mask[2]" and "u32 *" type cast.
- We don't know the other part implementation (we event don't know
whether it is open source). And also it is out of most of kernel
members' current border (e.g. me).
- If the other part implementation match what kernel part has done, it
is OK, else it should cause issue.
So at present, in kernel part, we can only say the original authors
intended to do like this. And only within kernel part, it can not cause
issue. I guess, original authors originally knew what we talk about.
This patch is for fixing building warnings without any negative effect.
And most of us are not the suitable members to continue analyzing. So
at present, for me, we can accept this patch.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
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: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from sound/soc/codecs/max98357a.c:15:0:
include/linux/module.h:138:40: error:
'__mod_of__max98357a_device_id_device_table' aliased to undefined symbol
'max98357a_device_id'
extern const struct type##_device_id __mod_##type##__##name##_device_table \
^
sound/soc/codecs/max98357a.c:138:1: note: in expansion of macro
'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, max98357a_device_id);
^
Caused by commit af5adf129369 ("ASoC: max98357a: Add MAX98357A codec driver").
I have added the following fix patch for today.
From: Stephen Rothwell
Date: Mon, 9 Feb 2015 14:34:40 +1100
Subject: [PATCH] ASoC: max98357a: fix !CONFIG_OF build
Signed-off-by: Stephen Rothwell
---
sound/soc/codecs/max98357a.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index 98b915314d7a..ac169f9f4329 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -135,4 +135,6 @@ module_platform_driver(max98357a_platform_driver);
MODULE_DESCRIPTION("Maxim MAX98357A Codec Driver");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:" DRV_NAME);
+#ifdef CONFIG_OF
MODULE_DEVICE_TABLE(of, max98357a_device_id);
+#endif
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpqSNGZ9_C39.pgp
Description: OpenPGP digital signature
Re: [PATCH] kernel/panic/kexec: fix "crash_kexec_post_notifiers" option issue in oops path
Hello,
From: Baoquan He
Subject: Re: [PATCH] kernel/panic/kexec: fix "crash_kexec_post_notifiers"
option issue in oops path
Date: Mon, 9 Feb 2015 10:40:30 +0800
> On 02/05/15 at 05:59pm, HATAYAMA Daisuke wrote:
>> The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
>> "crash_kexec_post_notifiers" kernel boot option, which toggles
>> wheather panic() calls crash_kexec() before or after panic_notifiers
>> and dump kmsg.
>>
>> The problem is that the commit overlooks panic_on_oops kernel boot
>> option. If it is enabled, crash_kexec() is called directly without
>> going through panic() in oops path.
>>
>> To fix this issue, this patch adds a check to
>> "crash_kexec_post_notifiers" in the condition of kexec_should_crash().
>>
>> Signed-off-by: HATAYAMA Daisuke
>> ---
>> include/linux/kernel.h | 3 +++
>> kernel/kexec.c | 2 ++
>> kernel/panic.c | 2 +-
>> 3 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> index 64ce58b..f47379f 100644
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -426,6 +426,9 @@ extern int panic_on_unrecovered_nmi;
>> extern int panic_on_io_nmi;
>> extern int panic_on_warn;
>> extern int sysctl_panic_on_stackoverflow;
>> +
>> +extern bool crash_kexec_post_notifiers;
>> +
>> /*
>> * Only to be used by arch init code. If the user over-wrote the default
>> * CONFIG_PANIC_TIMEOUT, honor it.
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index 9a8a01a..0ecf252 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -84,6 +84,8 @@ struct resource crashk_low_res = {
>>
>> int kexec_should_crash(struct task_struct *p)
>> {
>> +if (crash_kexec_post_notifiers)
>> +return 0;
>> if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
>> return 1;
>
> What if these two conditions !p->pid || is_global_init(p) are satisfied?
> Seems the behavious is changed.
>
Please further follow do_exit() path. For each condition, there are
the corresponding panic() calls. In summary:
oops_end
1) panic() for in_interrupt()
2) panic() for panic_on_oops
do_exit
3) panic() for !p->pid (idle task)
exit_notify
forget_original_parent
find_child_reaper
4) panic() for p->pid == 1 (init task)
--
Thanks.
HATAYAMA, Daisuke
--
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] kernel/panic/kexec: fix "crash_kexec_post_notifiers" option issue in oops path
On 02/09/15 at 12:22pm, HATAYAMA Daisuke wrote:
> Hello,
>
> From: Baoquan He
> Subject: Re: [PATCH] kernel/panic/kexec: fix "crash_kexec_post_notifiers"
> option issue in oops path
> Date: Mon, 9 Feb 2015 10:40:30 +0800
>
> > On 02/05/15 at 05:59pm, HATAYAMA Daisuke wrote:
> >> The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
> >> "crash_kexec_post_notifiers" kernel boot option, which toggles
> >> wheather panic() calls crash_kexec() before or after panic_notifiers
> >> and dump kmsg.
> >>
> >> The problem is that the commit overlooks panic_on_oops kernel boot
> >> option. If it is enabled, crash_kexec() is called directly without
> >> going through panic() in oops path.
> >>
> >> To fix this issue, this patch adds a check to
> >> "crash_kexec_post_notifiers" in the condition of kexec_should_crash().
> >>
> >> Signed-off-by: HATAYAMA Daisuke
> >> ---
> >> include/linux/kernel.h | 3 +++
> >> kernel/kexec.c | 2 ++
> >> kernel/panic.c | 2 +-
> >> 3 files changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> >> index 64ce58b..f47379f 100644
> >> --- a/include/linux/kernel.h
> >> +++ b/include/linux/kernel.h
> >> @@ -426,6 +426,9 @@ extern int panic_on_unrecovered_nmi;
> >> extern int panic_on_io_nmi;
> >> extern int panic_on_warn;
> >> extern int sysctl_panic_on_stackoverflow;
> >> +
> >> +extern bool crash_kexec_post_notifiers;
> >> +
> >> /*
> >> * Only to be used by arch init code. If the user over-wrote the default
> >> * CONFIG_PANIC_TIMEOUT, honor it.
> >> diff --git a/kernel/kexec.c b/kernel/kexec.c
> >> index 9a8a01a..0ecf252 100644
> >> --- a/kernel/kexec.c
> >> +++ b/kernel/kexec.c
> >> @@ -84,6 +84,8 @@ struct resource crashk_low_res = {
> >>
> >> int kexec_should_crash(struct task_struct *p)
> >> {
> >> + if (crash_kexec_post_notifiers)
> >> + return 0;
> >>if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> >>return 1;
> >
> > What if these two conditions !p->pid || is_global_init(p) are satisfied?
> > Seems the behavious is changed.
> >
>
> Please further follow do_exit() path. For each condition, there are
> the corresponding panic() calls. In summary:
>
> oops_end
> 1) panic() for in_interrupt()
> 2) panic() for panic_on_oops
> do_exit
> 3) panic() for !p->pid (idle task)
> exit_notify
> forget_original_parent
> find_child_reaper
> 4) panic() for p->pid == 1 (init task)
Yes, all conditions have been covered.
So this patch is necessary, ACK it. Thanks
Acked-by: Baoquan He
Thanks
Baoquan
>
> --
> Thanks.
> HATAYAMA, Daisuke
>
--
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/
[LKP] [sched/fair] 638476007d1: +1.1% unixbench.score
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
commit 638476007d13534b2ed4134bf0279ef44071140b ("sched/fair: Fix the dealing
with decay_count in __synchronize_entity_decay()")
It appears that your patch cause CPU usage increased a little, so that
unixbench score increased.
testbox/testcase/testparams: nhm-white/unixbench/spawn
7f1a169b88f513e3 638476007d13534b2ed4134bf0
--
%stddev %change %stddev
\ |\
268908 ± 0% +4.6% 281320 ± 0%
unixbench.time.involuntary_context_switches
1.147e+08 ± 0% +1.5% 1.164e+08 ± 0% unixbench.time.minor_page_faults
3607 ± 0% +1.1% 3648 ± 0% unixbench.score
324 ± 0% +1.2%328 ± 0%
unixbench.time.percent_of_cpu_this_job_got
633 ± 0% +1.2%641 ± 0% unixbench.time.system_time
54100 ± 3% +51.0% 81705 ± 21% sched_debug.cpu#4.ttwu_local
65678 ± 7% +49.5% 98187 ± 16% sched_debug.cpu#6.ttwu_local
5624 ± 31% +52.1% 8553 ± 11% sched_debug.cpu#6.curr->pid
58 ± 20% +37.6% 80 ± 7%
sched_debug.cfs_rq[3]:/.runnable_load_avg
61 ± 10% +22.5% 74 ± 14% sched_debug.cpu#2.cpu_load[3]
218479 ± 5% +15.4% 252190 ± 5% sched_debug.cpu#6.ttwu_count
102 ± 17% -19.3% 82 ± 10% sched_debug.cpu#4.cpu_load[2]
423974 ± 4% +15.6% 490072 ± 5% sched_debug.cpu#5.avg_idle
62 ± 4% +16.9% 72 ± 9% sched_debug.cpu#2.cpu_load[4]
152298 ± 2% +9.7% 167037 ± 3%
sched_debug.cfs_rq[5]:/.min_vruntime
156795 ± 1% +11.3% 174544 ± 1%
sched_debug.cfs_rq[7]:/.min_vruntime
155535 ± 3% +11.8% 173813 ± 2%
sched_debug.cfs_rq[6]:/.min_vruntime
9231 ± 0% +1.3% 9348 ± 0% vmstat.system.in
nhm-white: Nehalem
Memory: 6G
unixbench.time.system_time
643 ++---O+
642 ++O O O
O O O O O O O O OO O O O O O O O OO O O O |
641 ++ O O O O |
640 ++|
| |
639 ++|
638 ++|
637 ++|
| |
636 ++|
635 ++ .* |
*.*.. .*..* + .*.. .*.*.. * |
634 ++ **..*.*..** + |
633 ++*---+
unixbench.time.involuntary_context_switches
286000 ++-+
284000 ++ O |
|OO|
282000 ++ O OO
28 O+OO O O O O O O OO O O |
|O O O O O O OO|
278000 ++ O O O |
276000 ++ |
274000 ++ |
| |
272000 ++ |
27 ++ .*.*. *.*.. .* |
*.*. *..*. .* : *.*.*. |
268000 ++* +:|
266000 ++*--*-+
kmsg.tsc:Fast_TSC_calibration_failed
1 ++-OO-+
| |
| |
0.8 ++|
| |
|
Re: [PATCH 1/6] drivers: usb: core: devio.c: remove assignment of variables in if conditions.
On Sat, Feb 07, 2015 at 10:55:01PM +0100, Bas Peters wrote:
> This patch removes assignment of variables in if conditions in
> accordance witht the CodingStyle.
%s/witht/with
>
> Signed-off-by: Bas Peters
> ---
> drivers/usb/core/devio.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 0b59731..ea3c737 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -1081,7 +1081,8 @@ static int proc_bulk(struct usb_dev_state *ps, void
> __user *arg)
> ret = usbfs_increase_memory_usage(len1 + sizeof(struct urb));
> if (ret)
> return ret;
> - if (!(tbuf = kmalloc(len1, GFP_KERNEL))) {
> + tbuf = kmalloc(len1, GFP_KERNEL);
> + if (!tbuf) {
> ret = -ENOMEM;
> goto done;
> }
> @@ -1223,7 +1224,8 @@ static int proc_setintf(struct usb_dev_state *ps, void
> __user *arg)
>
> if (copy_from_user(, arg, sizeof(setintf)))
> return -EFAULT;
> - if ((ret = checkintf(ps, setintf.interface)))
> + ret = checkintf(ps, setintf.interface);
> + if (ret)
> return ret;
>
> destroy_async_on_interface(ps, setintf.interface);
> @@ -1392,7 +1394,8 @@ static int proc_do_submiturb(struct usb_dev_state *ps,
> struct usbdevfs_urb *uurb
> number_of_packets = uurb->number_of_packets;
> isofrmlen = sizeof(struct usbdevfs_iso_packet_desc) *
> number_of_packets;
> - if (!(isopkt = kmalloc(isofrmlen, GFP_KERNEL)))
> + isopkt = kmalloc(isofrmlen, GFP_KERNEL);
> + if (!isopkt)
> return -ENOMEM;
> if (copy_from_user(isopkt, iso_frame_desc, isofrmlen)) {
> ret = -EFAULT;
> @@ -1901,7 +1904,8 @@ static int proc_releaseinterface(struct usb_dev_state
> *ps, void __user *arg)
>
> if (get_user(ifnum, (unsigned int __user *)arg))
> return -EFAULT;
> - if ((ret = releaseintf(ps, ifnum)) < 0)
> + ret = releaseintf(ps, ifnum);
> + if (ret < 0)
> return ret;
> destroy_async_on_interface (ps, ifnum);
> return 0;
> @@ -1916,7 +1920,8 @@ static int proc_ioctl(struct usb_dev_state *ps, struct
> usbdevfs_ioctl *ctl)
> struct usb_driver *driver = NULL;
>
> /* alloc buffer */
> - if ((size = _IOC_SIZE(ctl->ioctl_code)) > 0) {
> + size = _IOC_SIZE(ctl->ioctl_code);
> + if (size > 0) {
> buf = kmalloc(size, GFP_KERNEL);
> if (buf == NULL)
> return -ENOMEM;
> --
> 2.1.0
>
--
Best Regards,
Peter Chen
--
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/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC
Hello Marc,
2015-02-06 17:07 GMT+08:00 Marc Zyngier :
> On 06/02/15 08:42, Brent Wang wrote:
>
> [...]
>
>>>
+ <0x0 0xf6802000 0x0 0x2000>, /* GICC */
+ <0x0 0xf6804000 0x0 0x2000>, /* GICH */
+ <0x0 0xf6806000 0x0 0x2000>; /* GICV */
>>>
>>> I guess no-one's bothered to consider 64k pages?
>>>
>>> Given GICH and GICV, I hope that this platform is booted at EL2?
>> Transfer from EL3 to EL1 directly, keep these two just for future use.
>
> That's a real shame, as it keeps users away from some key aspects of the
> ARMv8 architecture.
>
>>>
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
>
> And if you're keeping GICH/GICV, where is the maintenance interrupt?
>
+ };
+
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <>;
+ interrupts = <1 13 0xff08>,
+ <1 14 0xff08>,
+ <1 11 0xff08>,
+ <1 10 0xff08>;
+ clock-frequency = <120>;
+ };
>>>
>>> NAK. Fix your firmware to configure CNTFRQ, on all CPUs.
>> Fix in next version, maybe it will take some time to change firmware.
>
> While you're at it, make sure CNTVOFF_EL2 is set to zero on all CPUs
> before dropping to EL1. This tends to be overlooked.
Thank you for reminding me, I will keep that in mind.
Thanks,
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Best Regards,
Bintian
===
Don't be nervous, just be happy!
--
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] f2fs: avoid data offset overflow when lseeking huge file
xfstest generic/285 complains our issue in lseeking huge file.
Here is the detail output of generic/285:
"./check -f2fs tests/generic/285
Ran: generic/285
Failures: generic/285
Failed 1 of 1 tests
10. Test a huge file for offset overflow
10.01 SEEK_HOLE expected 65536 or 8589934592, got 65536. succ
10.02 SEEK_HOLE expected 65536 or 8589934592, got 65536. succ
10.03 SEEK_DATA expected 0 or 0, got 0. succ
10.04 SEEK_DATA expected 1 or 1, got 1. succ
10.05 SEEK_HOLE expected 8589934592 or 8589934592, got 0. FAIL
10.06 SEEK_DATA expected 8589869056 or 8589869056, got 8589869056. succ
10.07 SEEK_DATA expected 8589869057 or 8589869057, got 8589869057. succ
10.08 SEEK_DATA expected 8589869056 or 8589869056, got 4294901760. FAIL"
The reason of this issue is:
We will calculate current offset through left shifting page-offset with
PAGE_CACHE_SHIFT bits, but our page-offset is a type of unsigned long, its size
is 4 bytes in 32-bits machine.
So if our page-offset is bigger than (1 << 32 / pagesize - 1), result of left
shifting will overflow.
Let's fix this issue by casting type of page-offset to type of current offset:
loff_t.
Signed-off-by: Chao Yu
---
fs/f2fs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 5cbbc9a..7dc0ed8 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -357,7 +357,7 @@ static loff_t f2fs_seek_block(struct file *file, loff_t
offset, int whence)
/* find data/hole in dnode block */
for (; dn.ofs_in_node < end_offset;
dn.ofs_in_node++, pgofs++,
- data_ofs = pgofs << PAGE_CACHE_SHIFT) {
+ data_ofs = (loff_t)pgofs << PAGE_CACHE_SHIFT) {
block_t blkaddr;
blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
--
2.2.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: [perf/core PATCH 4/4] perf buildid-cache: Add --remove-all FILE to remove all caches of FILE
Hi Masami,
On Sat, Feb 07, 2015 at 07:14:19PM +0900, Masami Hiramatsu wrote:
> Add --remove-all FILE to remove all caches of FILE.
> Since the current --remove FILE removes a cache which has
> same build-id of given FILE. Since the command takes a
> FILE path, it can confuse user who tries to remove cache
> about FILE path.
>
> -
> # ./perf buildid-cache -v --add ./perf
> Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
> # (update the ./perf binary)
> # ./perf buildid-cache -v --remove ./perf
> Removing 305bbd1be68f66eca7e2d78db294653031edfa79 ./perf: FAIL
> ./perf wasn't in the cache
> -
> Actually, the --remove's FAIL is not shown, it just silently fails.
>
> So, this patch adds --remove-all FILE action for such usecase.
> perf buildid-cache --remove-all FILE removes all caches which
> has same FILE path.
> In other words, it removes all caches including old binaries.
>
> -
> # ./perf buildid-cache -v --add ./perf
> Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
> # (update the ./perf binary)
> # ./perf buildid-cache -v --remove-all ./perf
> Removing 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
> -
>
> Signed-off-by: Masami Hiramatsu
> ---
> tools/perf/Documentation/perf-buildid-cache.txt |6 +-
> tools/perf/builtin-buildid-cache.c | 44
> tools/perf/util/build-id.c | 81
> ++-
> tools/perf/util/build-id.h |1
> 4 files changed, 115 insertions(+), 17 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-buildid-cache.txt
> b/tools/perf/Documentation/perf-buildid-cache.txt
> index 6575dce..01f295e 100644
> --- a/tools/perf/Documentation/perf-buildid-cache.txt
> +++ b/tools/perf/Documentation/perf-buildid-cache.txt
> @@ -36,7 +36,11 @@ OPTIONS
> actually made.
> -r::
> --remove=::
> -Remove specified file from the cache.
> +Remove a cached binary which has same build-id of specified file
> +from the cache.
> +-R::
> +--remove-all=::
> +Remove all cached binary which has specified path from the cache.
> -M::
> --missing=::
> List missing build ids in the cache for the specified file.
> diff --git a/tools/perf/builtin-buildid-cache.c
> b/tools/perf/builtin-buildid-cache.c
> index e7568f5..3a76d51 100644
> --- a/tools/perf/builtin-buildid-cache.c
> +++ b/tools/perf/builtin-buildid-cache.c
> @@ -223,6 +223,29 @@ static int build_id_cache__remove_file(const char
> *filename)
> return err;
> }
>
> +static int build_id_cache__remove_path(const char *pathname)
> +{
> + struct strlist *list;
> + struct str_node *pos;
> + int err;
> +
> + list = build_id_cache__list_build_ids(pathname);
> + if (!list)
> + return 0;
> +
> + strlist__for_each(pos, list) {
> + err = build_id_cache__remove_s(pos->s);
> + if (verbose)
> + pr_info("Removing %s %s: %s\n", pos->s, pathname,
> + err ? "FAIL" : "Ok");
> + if (err)
> + break;
> + }
> + strlist__delete(list);
> +
> + return err;
> +}
> +
> static bool dso__missing_buildid_cache(struct dso *dso, int parm
> __maybe_unused)
> {
> char filename[PATH_MAX];
> @@ -285,6 +308,7 @@ int cmd_buildid_cache(int argc, const char **argv,
> bool force = false;
> char const *add_name_list_str = NULL,
> *remove_name_list_str = NULL,
> +*remove_all_name_list_str = NULL,
> *missing_filename = NULL,
> *update_name_list_str = NULL,
> *kcore_filename = NULL;
> @@ -302,6 +326,8 @@ int cmd_buildid_cache(int argc, const char **argv,
> "file", "kcore file to add"),
> OPT_STRING('r', "remove", _name_list_str, "file list",
> "file(s) to remove"),
> + OPT_STRING('R', "remove-all", _all_name_list_str, "path list",
> + "path(s) to remove (remove old caches too)"),
> OPT_STRING('M', "missing", _filename, "file",
> "to find missing build ids in the cache"),
> OPT_BOOLEAN('f', "force", , "don't complain, do it"),
> @@ -368,6 +394,24 @@ int cmd_buildid_cache(int argc, const char **argv,
> }
> }
>
> + if (remove_all_name_list_str) {
> + list = strlist__new(true, remove_all_name_list_str);
> + if (list) {
> + strlist__for_each(pos, list)
> + if (build_id_cache__remove_path(pos->s)) {
> + if (errno == ENOENT) {
> + pr_debug("%s wasn't in the
> cache\n",
> + pos->s);
> + continue;
> + }
> +
linux-next: manual merge of the wireless-drivers-next tree with Linus' tree
Hi Kalle,
Today's linux-next merge of the wireless-drivers-next tree got a
conflict in drivers/net/wireless/rtlwifi/pci.c between commit
e9538cf4f907 ("rtlwifi: Fix error when accessing unmapped memory in
skb") from Linus' tree and commit d0311314d002 ("rtlwifi: rtl8192ee:
Fix handling of new style descriptors") from the wireless-drivers-next
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/net/wireless/rtlwifi/pci.c
index c70efb9a6e78,88331d729b0e..
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@@ -924,17 -917,14 +931,16 @@@ new_trx_end
rtlpriv->enter_ps = false;
schedule_work(>works.lps_change_work);
}
- end:
+ skb = new_skb;
+no_new:
if (rtlpriv->use_new_trx_flow) {
- _rtl_pci_init_one_rxdesc(hw, (u8 *)buffer_desc,
+ _rtl_pci_init_one_rxdesc(hw, skb, (u8 *)buffer_desc,
rxring_idx,
- rtlpci->rx_ring[rxring_idx].idx);
+
rtlpci->rx_ring[rxring_idx].idx);
} else {
- _rtl_pci_init_one_rxdesc(hw, (u8 *)pdesc, rxring_idx,
+ _rtl_pci_init_one_rxdesc(hw, skb, (u8 *)pdesc,
+ rxring_idx,
rtlpci->rx_ring[rxring_idx].idx);
-
if (rtlpci->rx_ring[rxring_idx].idx ==
rtlpci->rxringcount - 1)
rtlpriv->cfg->ops->set_desc(hw, (u8 *)pdesc,
pgplylcN7v2wn.pgp
Description: OpenPGP digital signature
RE: [PATCH v4 0/7] clk: Add common clock support for Mediatek MT8135 and MT8173.
Hi Sascha, It's okay for me, thanks. Henry > -Original Message- > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > Sent: Friday, February 06, 2015 11:16 PM > To: Matthias Brugger > Cc: HenryC Chen (陳建豪); Rob Herring; Mike Turquette; srv_heupstream; > Sascha Hauer; JamesJJ Liao (廖建智); Eddie Huang (黃智傑); Pawel Moll; > Mark Rutland; Ian Campbell; Kumar Gala; Russell King; Catalin Marinas; > Vladimir Murzin; Ashwin Chaugule; Yingjoe Chen (陳英洲); > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-media...@lists.infradead.org > Subject: Re: [PATCH v4 0/7] clk: Add common clock support for Mediatek > MT8135 and MT8173. > > On Fri, Feb 06, 2015 at 03:20:35PM +0100, Matthias Brugger wrote: > > > I don't really understand the "as part of the clk driver part". I > > > now have replaced the devm_regmap_init_mmio with > > > syscon_node_to_regmap in the pericfg / infracfg drivers. Is that > all > > > that you want or do you want me to move the source code to > drivers/clk/mediatek? > > > > Yes, I propose to move the source code to drivers/clk/mediatek. > > Please have a look on other clock drivers which implement the reset > > controller, e.g. rockchip. > > Ok, I'm halfway through implementing this, but let's have weekend first. > > Henry, If you're fine with this I'll change your clock series according > to Matthias suggestions. > > Sascha > > -- > Pengutronix e.K. | > | > Industrial Linux Solutions | http://www.pengutronix.de/ > | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 > | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- > | * Email Confidentiality Notice The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
Re: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates
Hi Peter,
On 02/04/2015 07:52 PM, Peter Rosin wrote:
From: Peter Rosin
When the SSC acts as BCK master, use a ratnum rule to limit
the rate instead of only doing the standard rates. When the SSC
acts as BCK slave, allow any BCK frequency up to within 500ppm
of the SSC master clock, possibly divided by 2, 3 or 6.
Put a cap at 384kHz. Who's /ever/ going to need more than that?
The divider of 2, 3 or 6 is selected based on the Serial Clock Ratio
Considerations section from the SSC documentation:
The Transmitter and the Receiver can be programmed to operate
with the clock signals provided on either the TK or RK pins.
This allows the SSC to support many slave-mode data transfers.
In this case, the maximum clock speed allowed on the RK pin is:
- Peripheral clock divided by 2 if Receiver Frame Synchro is input
- Peripheral clock divided by 3 if Receiver Frame Synchro is output
In addition, the maximum clock speed allowed on the TK pin is:
- Peripheral clock divided by 6 if Transmit Frame Synchro is input
- Peripheral clock divided by 2 if Transmit Frame Synchro is output
Signed-off-by: Peter Rosin
---
sound/soc/atmel/atmel_ssc_dai.c | 113 +--
sound/soc/atmel/atmel_ssc_dai.h |1 +
2 files changed, 110 insertions(+), 4 deletions(-)
Changes since v1:
- I have checked all Atmel datasheets I could get my hands on (and
that seemed relevant), and in every instance where they have
described the SSC, the description have the exact rate limitations
on the RK and TK pin that I have implemented here.
- Improved the comments.
- Rebased on top of the latest patches from Bo Chen.
One thing remains a bit unclear, and that is the 500ppm deduction. Is
that really warranted? The number was just pulled out of my hat...
Cheers,
Peter
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 379ac2a6ab16..767f65bab25d 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -187,6 +187,96 @@ static irqreturn_t atmel_ssc_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+/*
+ * When the bit clock is input, limit the maximum rate according to the
+ * Serial Clock Ratio Considerations section from the SSC documentation:
+ *
+ * The Transmitter and the Receiver can be programmed to operate
+ * with the clock signals provided on either the TK or RK pins.
+ * This allows the SSC to support many slave-mode data transfers.
+ * In this case, the maximum clock speed allowed on the RK pin is:
+ * - Peripheral clock divided by 2 if Receiver Frame Synchro is input
+ * - Peripheral clock divided by 3 if Receiver Frame Synchro is output
+ * In addition, the maximum clock speed allowed on the TK pin is:
+ * - Peripheral clock divided by 6 if Transmit Frame Synchro is input
+ * - Peripheral clock divided by 2 if Transmit Frame Synchro is output
+ *
+ * When the bit clock is output, limit the rate according to the
+ * SSC divider restrictions.
+ */
+static int atmel_ssc_hw_rule_rate(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct atmel_ssc_info *ssc_p = rule->private;
+ struct ssc_device *ssc = ssc_p->ssc;
+ struct snd_interval *i = hw_param_interval(params, rule->var);
+ struct snd_interval t;
+ struct snd_ratnum r = {
+ .den_min = 1,
+ .den_max = 4095,
+ .den_step = 1,
+ };
+ unsigned int num = 0, den = 0;
+ int frame_size;
+ int mck_div = 2;
+ int ret;
+
+ frame_size = snd_soc_params_to_frame_size(params);
+ if (frame_size < 0)
+ return frame_size;
+
+ switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFS:
+ if ((ssc_p->dir_mask & SSC_DIR_MASK_CAPTURE)
+ && ssc->clk_from_rk_pin)
+ /* Receiver Frame Synchro (i.e. capture)
+* is output (format is _CFS) and the RK pin
+* is used for input (format is _CBM_).
+*/
+ mck_div = 3;
+ break;
+
+ case SND_SOC_DAIFMT_CBM_CFM:
+ if ((ssc_p->dir_mask & SSC_DIR_MASK_PLAYBACK)
+ && !ssc->clk_from_rk_pin)
+ /* Transmit Frame Synchro (i.e. playback)
+* is input (format is _CFM) and the TK pin
+* is used for input (format _CBM_ but not
+* using the RK pin).
+*/
+ mck_div = 6;
+ break;
+ }
+
+ switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ r.num = ssc_p->mck_rate / mck_div / frame_size;
+
+ ret = snd_interval_ratnum(i, 1, , , );
+ if (ret >=
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
lib/rhashtable.c: In function 'rhashtable_walk_next':
lib/rhashtable.c:1002:3: error: implicit declaration of function 'ERR_PTR'
[-Werror=implicit-function-declaration]
return ERR_PTR(-EAGAIN);
^
lib/rhashtable.c:1002:3: warning: return makes pointer from integer without a
cast
Caused by commit f2dba9c6ff0d ("rhashtable: Introduce
rhashtable_walk_*"). See Rule 1 in Documentation/SubmitChecklist.
I have added the following fix patch for today:
From: Stephen Rothwell
Date: Mon, 9 Feb 2015 14:04:03 +1100
Subject: [PATCH] rhashtable: using ERR_PTR requires linux/err.h
Signed-off-by: Stephen Rothwell
---
lib/rhashtable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index e96fc00208bc..9cc4c4a90d00 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#define HASH_DEFAULT_SIZE 64UL
#define HASH_MIN_SIZE 4UL
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpJMtIdYHRjZ.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates
Hi Peter, On 02/07/2015 06:51 PM, Peter Rosin wrote: Mark Brown wrote: On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote: One thing remains a bit unclear, and that is the 500ppm deduction. Is that really warranted? The number was just pulled out of my hat... I don't really get what this is supposed to be protecting against. + case SND_SOC_DAIFMT_CBM_CFS: + case SND_SOC_DAIFMT_CBM_CFM: + t.min = 8000; + t.max = ssc_p->mck_rate / mck_div / frame_size; + /* Take away 500ppm, just to be on the safe side. */ + t.max -= t.max / 2000; + t.openmin = t.openmax = 0; + t.integer = 0; + ret = snd_interval_refine(i, ); As I understand it this is a straight divider rather than something that's doing dithering or anything else more fancy. Given that it seems as well just to trust the clock rate we've got - we don't do any error tracking with the clock API (perhaps we should) and for many applications some degree of divergence from the nominal rate is not *too* bad for audio systems (for application specific values of "some" and "too" of course). If it is just dividers I'm not sure the situation is really improved materially by knocking off the top frequency. If we are doing something more fancy than divididing my analysis is off base of course. I'm thinking that the SSC samples the selected BCK pin using the (possibly divided) peripheral clock. Getting too near the theoretical rate limit would be bad, if these two independent clocks drift the wrong way. At least that is my take on it, but I don't know the internal workings of the SSC, so... I was hoping that someone from Atmel could chime in? Maybe I'm totally Sorry for late response. off base, and the SSC is doing this completely differently? What you mean here? I am not sure I fully understand. In our application, we're not near the limit. Therefore, it really doesn't matter much to us. Should I resend w/o the 500ppm deduction? Cheers, Peter Best Regards, Bo Shen -- 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: build failure after merge of the pm tree
On Monday, February 09, 2015 10:53:05 AM Jiang Liu wrote:
>
> On 2015/2/9 10:26, Stephen Rothwell wrote:
> > Hi Rafael,
[cut]
> >^
> >
> > Caused by commit 14d76b68f281 ("PCI: Use common resource list
> > management code instead of private implementation") interacting with
> > commit d2be00c0fb5a ("of/pci: Free resources on failure in
> > of_pci_get_host_bridge_resources()") from the pci tree.
> >
> > I applied the following merge fix patch (which may need more work?).
> Hi Stephen,
> Thanks for fixing it and there should no more work needed.
Can you please have a look at my linux-next branch now and see if the code
is correct in there as well?
Rafael
--
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: build failure after merge of the pm tree
On Monday, February 09, 2015 01:26:42 PM Stephen Rothwell wrote:
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from drivers/of/of_pci.c:1:0:
> drivers/of/of_pci.c: In function 'of_pci_get_host_bridge_resources':
> include/linux/list.h:447:43: error: dereferencing pointer to incomplete type
> for (pos = list_first_entry(head, typeof(*pos), member); \
>^
[cut]
>
> Caused by commit 14d76b68f281 ("PCI: Use common resource list
> management code instead of private implementation") interacting with
> commit d2be00c0fb5a ("of/pci: Free resources on failure in
> of_pci_get_host_bridge_resources()") from the pci tree.
Thanks for identifying this!
> I applied the following merge fix patch (which may need more work?).
> Someone needs to remember to tell Linus about this fix (or similar)
> when these trees get merged.
The patch looks correct to me, so I did the following.
I pulled the Bjorn's pci/host-generic branch that contained just that one
commit which conflicted with the Gerry's one into my acpi-resources branch
and folded the patch below into the merge.
> From: Stephen Rothwell
> Date: Mon, 9 Feb 2015 13:08:24 +1100
> Subject: [PATCH] of/pci: fix up for "PCI: Use common resource list management
> code instead of private implementation"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/of/of_pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 60dc36c865b5..110fece2ff53 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -140,7 +140,7 @@ int of_pci_get_host_bridge_resources(struct device_node
> *dev,
> unsigned char busno, unsigned char bus_max,
> struct list_head *resources, resource_size_t *io_base)
> {
> - struct pci_host_bridge_window *window;
> + struct resource_entry *window;
> struct resource *res;
> struct resource *bus_range;
> struct of_pci_range range;
> @@ -226,7 +226,7 @@ int of_pci_get_host_bridge_resources(struct device_node
> *dev,
> conversion_failed:
> kfree(res);
> parse_failed:
> - list_for_each_entry(window, resources, list)
> + resource_list_for_each_entry(window, resources)
> kfree(window->res);
> pci_free_resource_list(resources);
> kfree(bus_range);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
signature.asc
Description: This is a digitally signed message part.
Re: linux-next: build failure after merge of the pm tree
On 2015/2/9 10:26, Stephen Rothwell wrote: > Hi Rafael, > > After merging the pm tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from drivers/of/of_pci.c:1:0: > drivers/of/of_pci.c: In function 'of_pci_get_host_bridge_resources': > include/linux/list.h:447:43: error: dereferencing pointer to incomplete type > for (pos = list_first_entry(head, typeof(*pos), member); \ >^ > include/linux/kernel.h:799:18: note: in definition of macro 'container_of' > const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > ^ > include/linux/list.h:363:2: note: in expansion of macro 'list_entry' > list_entry((ptr)->next, type, member) > ^ > include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' > for (pos = list_first_entry(head, typeof(*pos), member); \ > ^ > drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' > list_for_each_entry(window, resources, list) > ^ > include/linux/kernel.h:799:48: warning: initialization from incompatible > pointer type > const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > ^ > include/linux/list.h:352:2: note: in expansion of macro 'container_of' > container_of(ptr, type, member) > ^ > include/linux/list.h:363:2: note: in expansion of macro 'list_entry' > list_entry((ptr)->next, type, member) > ^ > include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' > for (pos = list_first_entry(head, typeof(*pos), member); \ > ^ > drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' > list_for_each_entry(window, resources, list) > ^ > include/linux/list.h:447:43: error: dereferencing pointer to incomplete type > for (pos = list_first_entry(head, typeof(*pos), member); \ >^ > include/linux/kernel.h:800:3: note: in definition of macro 'container_of' > (type *)( (char *)__mptr - offsetof(type,member) );}) >^ > include/linux/list.h:363:2: note: in expansion of macro 'list_entry' > list_entry((ptr)->next, type, member) > ^ > include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' > for (pos = list_first_entry(head, typeof(*pos), member); \ > ^ > drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' > list_for_each_entry(window, resources, list) > ^ > In file included from include/linux/compiler-gcc.h:106:0, > from include/linux/compiler.h:54, > from include/linux/linkage.h:4, > from include/linux/kernel.h:6, > from drivers/of/of_pci.c:1: > include/linux/list.h:447:43: error: dereferencing pointer to incomplete type > for (pos = list_first_entry(head, typeof(*pos), member); \ >^ > include/linux/compiler-gcc4.h:14:53: note: in definition of macro > '__compiler_offsetof' > #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) > ^ > include/linux/kernel.h:800:29: note: in expansion of macro 'offsetof' > (type *)( (char *)__mptr - offsetof(type,member) );}) > ^ > include/linux/list.h:352:2: note: in expansion of macro 'container_of' > container_of(ptr, type, member) > ^ > include/linux/list.h:363:2: note: in expansion of macro 'list_entry' > list_entry((ptr)->next, type, member) > ^ > include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' > for (pos = list_first_entry(head, typeof(*pos), member); \ > ^ > drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' > list_for_each_entry(window, resources, list) > ^ > In file included from include/linux/kobject.h:20:0, > from include/linux/of.h:21, > from drivers/of/of_pci.c:3: > include/linux/list.h:448:11: error: dereferencing pointer to incomplete type >>member != (head); \ >^ > drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' > list_for_each_entry(window, resources, list) > ^ > In file included from drivers/of/of_pci.c:1:0: > include/linux/list.h:393:40: error: dereferencing pointer to incomplete type > list_entry((pos)->member.next, typeof(*(pos)), member) > ^ > include/linux/kernel.h:799:18: note: in definition of macro 'container_of' > const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > ^ > include/linux/list.h:393:2: note: in expansion of macro 'list_entry' > list_entry((pos)->member.next, typeof(*(pos)), member) > ^ > include/linux/list.h:449:13: note: in expansion of macro 'list_next_entry' >pos = list_next_entry(pos, member)) > ^ > drivers/of/of_pci.c:229:2: note: in expansion of macro
[GIT PULL] arch/nios2 for 3.19
Hi Linus, There is one arch/nios2 fix for 3.19 final. This fix the incorrect behavior of some user programs. Please consider pulling. Regards Ley Foon The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e: Linux 3.19-rc7 (2015-02-01 20:07:21 -0800) are available in the git repository at: git://git.rocketboards.org/linux-socfpga-next.git tags/nios2-fixes-v3.19-final for you to fetch changes up to a3248d609bd4514932bac291356e6a89abf259bc: nios2: fix unhandled signals (2015-02-09 09:47:05 +0800) nios2 fixes for v3.19-final - fix unhandled signals Chung-Ling Tang (1): nios2: fix unhandled signals arch/nios2/mm/fault.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 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] kernel/panic/kexec: fix "crash_kexec_post_notifiers" option issue in oops path
On 02/05/15 at 05:59pm, HATAYAMA Daisuke wrote:
> The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
> "crash_kexec_post_notifiers" kernel boot option, which toggles
> wheather panic() calls crash_kexec() before or after panic_notifiers
> and dump kmsg.
>
> The problem is that the commit overlooks panic_on_oops kernel boot
> option. If it is enabled, crash_kexec() is called directly without
> going through panic() in oops path.
>
> To fix this issue, this patch adds a check to
> "crash_kexec_post_notifiers" in the condition of kexec_should_crash().
>
> Signed-off-by: HATAYAMA Daisuke
> ---
> include/linux/kernel.h | 3 +++
> kernel/kexec.c | 2 ++
> kernel/panic.c | 2 +-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 64ce58b..f47379f 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -426,6 +426,9 @@ extern int panic_on_unrecovered_nmi;
> extern int panic_on_io_nmi;
> extern int panic_on_warn;
> extern int sysctl_panic_on_stackoverflow;
> +
> +extern bool crash_kexec_post_notifiers;
> +
> /*
> * Only to be used by arch init code. If the user over-wrote the default
> * CONFIG_PANIC_TIMEOUT, honor it.
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 9a8a01a..0ecf252 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -84,6 +84,8 @@ struct resource crashk_low_res = {
>
> int kexec_should_crash(struct task_struct *p)
> {
> + if (crash_kexec_post_notifiers)
> + return 0;
> if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> return 1;
What if these two conditions !p->pid || is_global_init(p) are satisfied?
Seems the behavious is changed.
> return 0;
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 4d8d6f9..6582546 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -32,7 +32,7 @@ static unsigned long tainted_mask;
> static int pause_on_oops;
> static int pause_on_oops_flag;
> static DEFINE_SPINLOCK(pause_on_oops_lock);
> -static bool crash_kexec_post_notifiers;
> +bool crash_kexec_post_notifiers;
> int panic_on_warn __read_mostly;
>
> int panic_timeout = CONFIG_PANIC_TIMEOUT;
> --
> 1.9.3
>
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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] perf config : Adding a command 'config' with a option '--list' and a document for it.
Hi Taeung, On Thu, Feb 05, 2015 at 05:05:17PM +0900, Taeung Song wrote: > The perf configuration file contain many variables which can make > the perf command's action more effective and more skilful. > But looking through state of configuration is difficult and > there's no knowing what kind of other variables except variables in > perfconfig.example exist. > > So This patch adds a command 'config --list' and a document for it. > > Signed-off-by: Taeung Song > --- > tools/perf/Documentation/perf-config.txt | 140 > +++ > tools/perf/Makefile.perf | 1 + > tools/perf/builtin-config.c | 56 + > tools/perf/builtin.h | 1 + > tools/perf/command-list.txt | 1 + > tools/perf/perf.c| 1 + > 6 files changed, 200 insertions(+) > create mode 100644 tools/perf/Documentation/perf-config.txt > create mode 100644 tools/perf/builtin-config.c > > diff --git a/tools/perf/Documentation/perf-config.txt > b/tools/perf/Documentation/perf-config.txt > new file mode 100644 > index 000..c88b8e1 > --- /dev/null > +++ b/tools/perf/Documentation/perf-config.txt > @@ -0,0 +1,140 @@ > +perf-config(1) > +== > + > +NAME > + > +perf-config - Get and set variables in configuration file. So do you also plan to add support for setting config variables like git-config with this? :) > + > +SYNOPSIS > + > +[verse] > +'perf config' --list > + > +DESCRIPTION > +--- > +You can manage variables in configuration file with this command. > + > +OPTIONS > +--- > + > +-l:: > +--list:: > +Show all variables with key and value into each sections. > + > +CONFIGURATION FILE > +-- > + > +The Perf configuration file contain many variables which can make > +the perf command's action more effective, more skilful. > +The '$HOME/.perfconfig' file is used to store a per-user configuration. > +The file 'etc/perfconfig' or '$(sysconfdir)/.perfconf' can be used to I think it's '/etc/perfconfig' or '$(sysconfdir)/perfconfig'. > +store a system-wide default configuration. > + > +The variables are divided into sections. In each sections, the variables > +can contain a key and values. > + > +EXAMPLES > + > + > +Given a $HOME/.perfconfig like this: > + > +# > +# This is the config file, and > +# a '#' character indicates a comment > +# > + > +[colors] > +# There are types of color which are red, > +# green, default, black, blue, > +# white, magenta, lightgray > +top = red, lightgray > +medium = green, lightgray > +normal = black, lightgray > +selected = lightgray, magenta > +code = blue, lightgray > +addr = magenta, lightgray > +root = default > + > +[tui] > +# Defaults if linked with libslang > +report = on > +annotate = on > +top = on > + > +[gtk] > +report = on > +annotate = on > +top = on > + > +[buildid] > +# Default, disable using /dev/null > +dir = /root/.debug > + > +[annotate] > +# Defaults > +hide_src_code = false > +use_offset = true > +jump_arrows = true > +show_nr_jumps = false > + > +[pager] > +# That a 'cmd' is true mean to use pager > +cmd = true > + > +[alias] > + > +[help] > +# Format can be man, info, web or html > +format = web > +autocorrect = 3 > + > +[core] > +# fall through > + > +[hist] > +# a value of 'percentage' can be 'relative' or 'absolute' > +percentage = relative > + > +[ui] > +show-headers= true > + > +[call-graph] > +# fp (framepointer), dwarf > +# If you use 'Dwarf style', > +# you can add ', (dump-size)' to record-mode such as ', 24' > +record-mode = fp > + > +dump-size = 24 > + > +# graph (graph absolute), flat, fractal (graph relative) > +print-type = graph > + > +# caller, callee > +order = caller > + > +# function, address > +sort-key = function > + > +threshold = 13.3 > +print-limit = 54.3 > + > +[report] > +group = true > +percent-limit = 70.54 > +children = true > +queue-size = 32 > + > +[man] > +cmd = > +path = > +viewer = > + > +[record] > +# fall through > +call-graph = > + > +[top] > +# a 'call-graph' is fall through > +call-graph = > +children = true While it's nice to list up all config variables in the example section, it'd be much greater if you could describe them in more detail like git-config manual page. Thanks, Namhyung > + > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf > index aa6a504..e2083f4 100644 > --- a/tools/perf/Makefile.perf > +++ b/tools/perf/Makefile.perf > @@ -475,6 +475,7 @@ BUILTIN_OBJS +=
[Update 2x] Re: [PATCH v3]PM/Sleep: Timer quiesce in freeze state
On Friday, February 06, 2015 02:20:13 AM Rafael J. Wysocki wrote:
>
> On Thursday, January 29, 2015 11:20:10 PM Rafael J. Wysocki wrote:
> > On Monday, January 26, 2015 10:40:24 AM Thomas Gleixner wrote:
> > > On Mon, 26 Jan 2015, Li, Aubrey wrote:
> > > > On 2015/1/22 18:15, Thomas Gleixner wrote:
>
> [cut]
>
> > >
> > > You need to make sure in the low level idle implementation that this
> > > cannot happen.
> > >
> > > tick_freeze()
> > > {
> > > raw_spin_lock(_freeze_lock);
> > > tick_frozen++;
> > > if (tick_frozen == num_online_cpus())
> > > timekeeping_suspend();
> > > else
> > > tick_suspend_local();
> > > raw_spin_unlock(_freeze_lock);
> > > }
> > >
> > > tick_unfreeze()
> > > {
> > > raw_spin_lock(_freeze_lock);
> > > if (tick_frozen == num_online_cpus())
> > > timekeeping_resume();
> > > else
> > > tick_resume_local();
> > > tick_frozen--;
> > > raw_spin_unlock(_freeze_lock);
> > > }
> > >
> > > idle_freeze()
> > > {
> > > local_irq_disable();
> > >
> > > tick_freeze();
> > >
> > > /* Must keep interrupts disabled! */
> > > go_deep_idle()
> > >
> > > tick_unfreeze();
> > >
> > > local_irq_enable();
> > > }
> > >
> > > That's the only way you can do it proper, everything else will just be
> > > a horrible mess of bandaids and duct tape.
> > >
> > > So that does not need any of the irq_enter/exit conditionals, it does
> > > not need the real_handler hack. It just works.
> > >
> > > The only remaining issue might be a NMI calling into
> > > ktime_get_mono_fast_ns() before timekeeping is resumed. Its probably a
> > > non issue on x86/tsc, but it might be a problem on other platforms
> > > which turn off devices, clocks, It's not rocket science to prevent
> > > that.
> >
> > So the patch below is my version of the $subject one trying to take the
> > above suggestion into account. It doesn not address the
> > ktime_get_mono_fast_ns()
> > in NMI case at this stage, because quite frankly I'd prefer to get the core
> > changes right in the first place.
> >
> > The new ->enter_freeze callback is there in struct cpuidle_state, because we
> > generally cannot trust the existing ->enter callbacks to keep interrupts
> > disabled all the time. Some of them enable interrupts temporarily and
> > some idle entry methods enable interrupts automatically on exit. So
> > ->enter_freeze is required to keep interrupts disabled and it is safe to
> > suspend/resume timekeeping around it.
> >
> > The rest is reasonably straightforward. If suspend-to-idle is requested,
> > couidle_idle_call() calls cpuidle_enter_freeze() that bypasses the governor
> > and selects the deepest suitable state. If ->enter_freeze is available,
> > it will be used along with tick_freeze()/tick_unfreeze() and the normal
> > idle entry code path will be used otherwise.
>
> In the meantime I learned how to tell RCU that it actually should track stuff
> inside of the idle loop, so cpuidle_enter_freeze() can go under the
> rcu_idle_enter/exit() now which makes it look more like "real" idle.
>
> Also I noticed that freeze_enter() could lose a wakeup event if it happened
> between dpm_suspend_noirq() and the point where suspend_freeze_state is set,
> so that race should be closed now.
>
> In my testing (with a hacked ACPI cpuidle driver) I get a number of wakeups
> (usually no more than 30) in enter_freeze_proper() per suspend-to-idle cycle,
> but that number doesn't seem to depend on the length of sleep, so my theory
> is that this happens early until things relax sufficiently.
>
> ktime_get_mono_fast_ns() is not covered yet, but I'm going to get to that
> next.
I'm not sure if this is what you meant, but here it goes.
The idea is to set up a dummy readout base for the fast timekeeper during
timekeeping_suspend() such that it will always return the same number of cycles.
After the last timekeeping_update() in timekeeping_suspend() we read the
clocksource and store the result as cycles_at_suspend. The readout base
from the current timekeeper is copied onto the dummy and the ->read pointer
of the dummy is set to a routine unconditionally returning cycles_at_suspend.
Next, the dummy is passed to update_fast_timekeeper() (which has been modified
slightly to accept the readout base instead of a whole timekeeper).
Then, if I'm not mistaken, ktime_get_mono_fast_ns() should work until the
subsequent timekeeping_resume() and then the proper readout base for the
fast timekeeper will be restored by the timekeeping_update() called right
after we've cleared timekeeping_suspended.
Complete patch with that modification is appended. In the next few days I'm
going to split it into smaller parts and send along with cpuidle driver
patches implementing ->enter_freeze.
Please let me know what you think.
Rafael
---
drivers/cpuidle/cpuidle.c | 88 --
include/linux/cpuidle.h |8 +++-
linux-next: build failure after merge of the pm tree
Hi Rafael, After merging the pm tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from drivers/of/of_pci.c:1:0: drivers/of/of_pci.c: In function 'of_pci_get_host_bridge_resources': include/linux/list.h:447:43: error: dereferencing pointer to incomplete type for (pos = list_first_entry(head, typeof(*pos), member); \ ^ include/linux/kernel.h:799:18: note: in definition of macro 'container_of' const typeof( ((type *)0)->member ) *__mptr = (ptr); \ ^ include/linux/list.h:363:2: note: in expansion of macro 'list_entry' list_entry((ptr)->next, type, member) ^ include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' for (pos = list_first_entry(head, typeof(*pos), member); \ ^ drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' list_for_each_entry(window, resources, list) ^ include/linux/kernel.h:799:48: warning: initialization from incompatible pointer type const typeof( ((type *)0)->member ) *__mptr = (ptr); \ ^ include/linux/list.h:352:2: note: in expansion of macro 'container_of' container_of(ptr, type, member) ^ include/linux/list.h:363:2: note: in expansion of macro 'list_entry' list_entry((ptr)->next, type, member) ^ include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' for (pos = list_first_entry(head, typeof(*pos), member); \ ^ drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' list_for_each_entry(window, resources, list) ^ include/linux/list.h:447:43: error: dereferencing pointer to incomplete type for (pos = list_first_entry(head, typeof(*pos), member); \ ^ include/linux/kernel.h:800:3: note: in definition of macro 'container_of' (type *)( (char *)__mptr - offsetof(type,member) );}) ^ include/linux/list.h:363:2: note: in expansion of macro 'list_entry' list_entry((ptr)->next, type, member) ^ include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' for (pos = list_first_entry(head, typeof(*pos), member); \ ^ drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' list_for_each_entry(window, resources, list) ^ In file included from include/linux/compiler-gcc.h:106:0, from include/linux/compiler.h:54, from include/linux/linkage.h:4, from include/linux/kernel.h:6, from drivers/of/of_pci.c:1: include/linux/list.h:447:43: error: dereferencing pointer to incomplete type for (pos = list_first_entry(head, typeof(*pos), member); \ ^ include/linux/compiler-gcc4.h:14:53: note: in definition of macro '__compiler_offsetof' #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) ^ include/linux/kernel.h:800:29: note: in expansion of macro 'offsetof' (type *)( (char *)__mptr - offsetof(type,member) );}) ^ include/linux/list.h:352:2: note: in expansion of macro 'container_of' container_of(ptr, type, member) ^ include/linux/list.h:363:2: note: in expansion of macro 'list_entry' list_entry((ptr)->next, type, member) ^ include/linux/list.h:447:13: note: in expansion of macro 'list_first_entry' for (pos = list_first_entry(head, typeof(*pos), member); \ ^ drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' list_for_each_entry(window, resources, list) ^ In file included from include/linux/kobject.h:20:0, from include/linux/of.h:21, from drivers/of/of_pci.c:3: include/linux/list.h:448:11: error: dereferencing pointer to incomplete type >member != (head); \ ^ drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' list_for_each_entry(window, resources, list) ^ In file included from drivers/of/of_pci.c:1:0: include/linux/list.h:393:40: error: dereferencing pointer to incomplete type list_entry((pos)->member.next, typeof(*(pos)), member) ^ include/linux/kernel.h:799:18: note: in definition of macro 'container_of' const typeof( ((type *)0)->member ) *__mptr = (ptr); \ ^ include/linux/list.h:393:2: note: in expansion of macro 'list_entry' list_entry((pos)->member.next, typeof(*(pos)), member) ^ include/linux/list.h:449:13: note: in expansion of macro 'list_next_entry' pos = list_next_entry(pos, member)) ^ drivers/of/of_pci.c:229:2: note: in expansion of macro 'list_for_each_entry' list_for_each_entry(window, resources, list) ^ include/linux/list.h:393:18: error: dereferencing pointer to incomplete type list_entry((pos)->member.next, typeof(*(pos)), member) ^ include/linux/kernel.h:799:49:
RE: [PATCH v2 0/5] ACPI / EC: Add reference counting for requests and cleans up the grace periods support.
Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, February 06, 2015 9:27 AM > > On Friday, February 06, 2015 08:57:37 AM Lv Zheng wrote: > > This patchset contains 3 cleanups related to the EC driver: > > 1. Command flushing (command grace period) > >This patchset flushes EC commands before suspending/resuming, so that > >there won't be timeout for the incomplete commands after resuming. > > 2. Query flushing (query grace period) > >This patchset flushes EC event queries before suspending/resuming, so > >that there won't be broken events remained in the firmware queue. > > 3. Command storming prevention > >This patchset corrects command storming prevention logic because of > >the GPE raw handler mode. > > The request reference count debugging messages can be used to detect broken > > EC transactions. It should always drop to 1 when the driver is idle during > > the runtime. > > > > Note that after flushing before suspending, EC GPE is still enabled to keep > > the old behavior. > > > > Lv Zheng (5): > > ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag. > > ACPI/EC: Add command flushing support. > > ACPI/EC: Refine command storm prevention support. > > ACPI/EC: Add query flushing support. > > ACPI/EC: Add GPE reference counting debugging messages. > > > > drivers/acpi/ec.c | 295 > > --- > > drivers/acpi/internal.h |1 + > > 2 files changed, 254 insertions(+), 42 deletions(-) > > So this is on top of the EC patches you sent previously, right? Yes. The sequence is: ACPICA 20150204 release: http://www.spinics.net/lists/linux-acpi/msg55623.html ACPI EC GPE race fixes: http://www.spinics.net/lists/linux-acpi/msg55633.html And this series. Thanks and best regards -Lv > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center.
[GIT PULL] arch/nios2 for 3.19
Hi Linus, There is one arch/nios2 fix for 3.19 final. This fix the incorrect behavior of some user programs. Please consider pulling. Regards Ley Foon The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e: Linux 3.19-rc7 (2015-02-01 20:07:21 -0800) are available in the git repository at: git://git.rocketboards.org/linux-socfpga-next.git tags/nios2-fixes-v3.19-final for you to fetch changes up to a3248d609bd4514932bac291356e6a89abf259bc: nios2: fix unhandled signals (2015-02-09 09:47:05 +0800) nios2 fixes for v3.19-final - fix unhandled signals Chung-Ling Tang (1): nios2: fix unhandled signals arch/nios2/mm/fault.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 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] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.
Dear Wilk: > -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Saturday, February 7, 2015 2:12 AM > To: Wang, Xiaoming > Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; > david.vra...@citrix.com; linux-m...@linux-mips.org; linux- > ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- > foundation.org; li...@horizon.com; lau...@codeaurora.org; > heiko.carst...@de.ibm.com; d.kasat...@samsung.com; > takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; pebo...@tiscali.nl; Liu, > Chuansheng; Zhang, Dongxing > Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize > configurable as flexible requirement about SW-IOMMU. > > On Fri, Feb 06, 2015 at 12:10:15AM +, Wang, Xiaoming wrote: > > > > > > > -Original Message- > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > Sent: Friday, February 6, 2015 3:33 AM > > > To: Wang, Xiaoming > > > Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; > > > david.vra...@citrix.com; linux-m...@linux-mips.org; linux- > > > ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- > > > foundation.org; li...@horizon.com; lau...@codeaurora.org; > > > heiko.carst...@de.ibm.com; d.kasat...@samsung.com; > > > takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; > > > pebo...@tiscali.nl; Liu, Chuansheng; Zhang, Dongxing > > > Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize > > > configurable as flexible requirement about SW-IOMMU. > > > > > > On Fri, Feb 06, 2015 at 07:01:14AM +0800, xiaomin1 wrote: > > > > The maximum of SW-IOMMU is limited to 2^11*128 = 256K. > > > > While in different platform and different requirements this seems > improper. > > > > So modify the IO_TLB_SEGSIZE to io_tlb_segsize as configurable is > > > > make > > > sense. > > > > > > More details please. What is the issue you are hitting? > > > > > Example: > > If 1M bytes are requied. There has an error like. > > Ok, but even with 1MB size - you only have 64 'slots' (if you allocate an 64MB > buffer). And the other 'slots' can be fragmented so you might still not have > enough 1MB chunks available. > > Do you have some thoughts on how that would be addressed? > Yes, If IO_TLB_SEGSIZE is 128 the slabs is 32K/128 = 256 While IO_TLB_SEGSIZE is 512 the slabs is 32K/512 =64 (for 1M). So it is dilemma between slabs and segsize. I have a thought how about modifying the IO_TLB_DEFAULT_SIZE to io_tlb_default_size configurable too? Because of the multivariate requirement. > > [ 31.474769] dwc3_otg :00:16.0: > dwc3_intel_byt_notify_charger_type(): dwc3_intel_byt_notify_charger_type: > invalid SDP current! > > [ 31.554077] android_work: sent uevent USB_STATE=CONNECTED > > [ 31.564244] android_usb gadget: high-speed config #1: android > > [ 31.571468] android_work: sent uevent USB_STATE=CONFIGURED > > [ 31.942738] DMA: Out of SW-IOMMU space for 1048576 bytes at device > gadget > > [ 31.950345] Kernel panic - not syncing: DMA: Random memory could be > DMA written > > [ 31.950345] > > [ 31.960170] CPU: 1 PID: 172 Comm: droidboot Tainted: GW > 3.10.20-x86_64_byt-g1077f87 #2 > > [ 31.970086] Hardware name: Intel Corp. VALLEYVIEW C0 > PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0004.R14.1412311144 > FFD8_X64_R_2014_12_31_1151 12/31/2014 > > [ 31.985053] 0010 880136c2fc98 82967d45 > 880136c2fd10 > > [ 31.993327] 82961761 0008 880136c2fd20 > 880136c2fcc0 > > [ 32.001590] 829618fb 0002 820aeff9 > 8d8c > > [ 32.009871] Call Trace: > > [ 32.012610] [] dump_stack+0x19/0x1b > > [ 32.018353] [] panic+0xc8/0x1d6 > > [ 32.023707] [] ? printk+0x55/0x57 > > [ 32.029258] [] ? console_unlock+0x1f9/0x460 > > [ 32.035772] [] swiotlb_map_page+0x12e/0x140 > > [ 32.042283] [] > usb_gadget_map_request+0x16d/0x220 > > [ 32.049387] [] dwc3_gadget_ep_queue+0x229/0x460 > > [ 32.056297] [] ffs_epfile_io.isra.96+0x3e4/0x520 > > [ 32.063296] [] ? get_parent_ip+0xd/0x50 > > [ 32.069427] [] ? sub_preempt_count+0x71/0x100 > > [ 32.076142] [] ffs_epfile_read+0x28/0x30 > > [ 32.082370] [] vfs_read+0x9c/0x170 > > [ 32.088014] [] SyS_read+0x4d/0xa0 > > [ 32.093562] [] ia32_do_call+0x13/0x13 > > > > > > > > Signed-off-by: Chuansheng Liu > > > > Signed-off-by: Zhang Dongxing > > > > Signed-off-by: xiaomin1 > > > > --- > > > > arch/mips/cavium-octeon/dma-octeon.c |2 +- > > > > arch/mips/netlogic/common/nlm-dma.c |2 +- > > > > drivers/xen/swiotlb-xen.c|6 +++--- > > > > include/linux/swiotlb.h |8 +-- > > > > lib/swiotlb.c| 39 > > > > -- > > > > 5 files changed, 34 insertions(+), 23 deletions(-) > > > > > > > > diff --git a/arch/mips/cavium-octeon/dma-octeon.c > > > > b/arch/mips/cavium-octeon/dma-octeon.c > > > > index 3778655..a521af6 100644
Re: [PATCH 3/3] CRISv32: handle multiple signals
On Sun, Feb 08, 2015 at 09:45:04PM +0100, Rabin Vincent wrote:
> Al Viro noted that CRIS fails to handle multiple signals.
>
> This fixes the problem for CRISv32 by making it use a C work_pending
> handling loop similar to the ARM implementation in 0a267fa6a15d41c
> ("ARM: 7472/1: pull all work_pending logics into C function").
>
> This also happens to fixes the warnings which currently trigger on
> CRISv32 due to do_signal() being called with interrupts disabled.
>
> Test case (should die of the SIGSEGV which gets raised when setting up
> the stack for SIGALRM, but instead reaches and executes the _exit(1)):
>
> #include
> #include
> #include
> #include
>
> static void handler(int sig) { }
>
> int main(int argc, char *argv[])
> {
> int ret;
> struct itimerval t1 = { .it_value = {1} };
> stack_t ss = {
> .ss_sp = NULL,
> .ss_size = SIGSTKSZ,
> };
> struct sigaction action = {
> .sa_handler = handler,
> .sa_flags = SA_ONSTACK,
> };
>
> ret = sigaltstack(, NULL);
> if (ret < 0)
> err(1, "sigaltstack");
>
> sigaction(SIGALRM, , NULL);
> setitimer(ITIMER_REAL, , NULL);
>
> pause();
>
> _exit(1);
>
> return 0;
> }
>
> Reported-by: Al Viro
> Link: http://lkml.kernel.org/r/20121208074429.gc4...@zeniv.linux.org.uk
> Signed-off-by: Rabin Vincent
Hi Rabin,
Works nicely, and, yes, it does fix the annoying traceback.
Tested-by: Guenter Roeck
Wondering - what serial driver do you use with crisv32, if any ?
So far I always patch in a cut-down version of the driver
from 2.6.26/33 which was never submitted upstream.
Thanks,
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/
