linux-next: Tree for Jul 9
Hi all, Changes since 20130708: The v4l-dvb tree lost its build failure. The tip tree gained a conflict against Linus' tree. The akpm tree lost a patch that turned up elsewhere. The cpuinit tree lost some patches that turned up in Linus' tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 228 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (d2b4a64 Merge branch 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma) Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n) Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arc-current/for-curr (baadb8f ARC: warn on improper stack unwind FDE entries) Merging arm-current/fixes (3e0a07f ARM: 7773/1: PJ4B: Add support for errata 4742) Merging m68k-current/for-linus (767bcb4 Merge branch 'exotic-arch-fixes' into for-next) Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for single-dev-PE) Merging sparc/master (c069114 mn10300: Fix include dependency in irqflags.h et al.) Merging net/master (8bb495e Linux 3.10) Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling) Merging sound-current/for-linus (cd63a5f ALSA: hda - Keep halting ALC5505 DSP) Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with ioremap() so it can be in highmem) Merging wireless/master (57bf744 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging tty.current/tty-linus (9e895ac Linux 3.10-rc7) Merging usb.current/usb-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging staging.current/staging-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging char-misc.current/char-misc-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging input-current/for-linus (62f548d Input: cyttsp4 - use 16bit address for I2C/SPI communication) Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all RAID10 reshapes to move no data.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (02c0241 Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto) Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for reserved IRQs) Merging devicetree-current/devicetree/merge (706b78f dtc: ensure #line directives don't consume data from the next line) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging
Re: [PATCH v5 0/7] cpufreq:boost: CPU Boost mode support
On Thu, 04 Jul 2013 10:50:23 +0200, Lukasz Majewski wrote: Dear Viresh, Rafael Do you have any comments/feedback for me regarding those patches? > This patch series introduces support for CPU overclocking technique > called Boost. > > It is a follow up of a LAB governor proposal. Boost is a LAB > component: > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > software oriented one (like the one done at Exynos). > For this reason cpufreq/freq_table code has been reorganized to > include common code. > > Important design decisions: > > - Boost related code is compiled-in unconditionally to cpufreq core > and disabled by default. The cpufreq_driver is responsibile for > setting boost_supported flag and providing enable_boost callback(if > HW support is needed). For software managed boost, special Kconfig > flag - CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be > selectable only when a target platform has thermal framework properly > configured. > > - struct cpufreq_driver has been extended with boost related fields: > -- boost_supported - when driver supports boosting > -- enable_boost - callback to function, which is necessary to >enable boost > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > visible _only_ when cpufreq driver supports Boost. > > - No special spin_lock for Boost was created. The one from cpufreq > core was reused. > > - All available policies are now stored in a list. > > - The Boost code doesn't rely on any policy. When boost state is > changed, then the policy list is iterated and proper adjustements are > done. > > - To improve safety level, the thermal framework is also extended to > disable software boosting, when thermal trip point is reached. Then > it starts monitoring of target temperature to evaluate if boost can > be enabled again. This emulates behaviour similar to HW managed boost > (like x86) > > New patches for v5: > cpufreq:boost:Kconfig: Enable software managed BOOST support at > Kconfig Documentation:cpufreq:boost: Update BOOST documentation > > Patches dropped at v5: > cpufreq: Calculate number of busy CPUs > cpufreq: Enable software boost only when up to one busy core is > running > > Tested at: HW: > Exynos 4412 3.10 linux > Exynos 4210 3.10 linux > Compile tested x86_64 defconfig (acpi) - help with HW (Intel Nehalem) > test needed > > The code has been rebased on top of kernel_pm/bleeding-edge (3.11-rc1) > > > Lukasz Majewski (7): > cpufreq: Store cpufreq policies in a list > cpufreq: Add boost frequency support in core > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common > boost solution > cpufreq:exynos:Extend Exynos cpufreq driver to support boost > framework > thermal:boost: Automatic enable/disable of BOOST feature > cpufreq:boost:Kconfig: Enable software managed BOOST support at > Kconfig > Documentation:cpufreq:boost: Update BOOST documentation > > Documentation/cpu-freq/boost.txt | 26 - > drivers/cpufreq/Kconfig | 14 + > drivers/cpufreq/acpi-cpufreq.c | 69 +++ > drivers/cpufreq/cpufreq.c| 115 > ++ > drivers/cpufreq/exynos-cpufreq.c |9 ++- > drivers/cpufreq/freq_table.c | 47 +--- > drivers/thermal/thermal_core.c | 31 ++ > include/linux/cpufreq.h | 13 + > include/linux/thermal.h |2 + 9 files changed, 257 > insertions(+), 69 deletions(-) > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the final tree (v4l-dvb tree related)
Hi Mauro, On Mon, 8 Jul 2013 09:58:19 -0300 (BRT) Mauro Carvalho Chehab wrote: > > I'll wait for tomorrow's next to see if everything is ok, before sending a > new pull request. Looks good today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgppHB6oWi8DO.pgp Description: PGP signature
Re: [PATCH v5 0/7] cpufreq:boost: CPU Boost mode support
On 9 July 2013 12:32, Lukasz Majewski wrote: > On Thu, 04 Jul 2013 10:50:23 +0200, Lukasz Majewski wrote: > > Dear Viresh, Rafael > > Do you have any comments/feedback for me regarding those patches? I am busy in Linaro connect this week, but will see if I can get some time to go over these. -- 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] of: match the compatible in the order set by the dts file
On Fri, Jul 05, 2013 at 04:43:38PM +0800, Huang Shijie wrote:
> If we set the uart compatible in the dts file like this:
>--
> compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
>--
>
> and we set the uart compatible in the uart driver like this:
>--
> { .compatible = "fsl,imx1-uart", ... },
> { .compatible = "fsl,imx21-uart", ... },
> { .compatible = "fsl,imx6q-uart", ... },
> { /* sentinel */ }
>--
>
> the current code will match the "fsl,imx21-uart" in the end.
>
> Of course, this is not what we want. We want it to match the "fsl,imx6q-uart".
>
> This patch rewrites the match code, and make it to check the compatible
> in the order set by the DTS file.
Why don't you set the matching order in the driver the way you want it
to be, i.e.:
{ .compatible = "fsl,imx6q-uart", ... },
{ .compatible = "fsl,imx21-uart", ... },
{ .compatible = "fsl,imx1-uart", ... },
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- |
--
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: Update event buffer tail when overwriting old events
On 07/08/2013 08:15 PM, Peter Zijlstra wrote:
> On Thu, Jun 06, 2013 at 01:58:06PM +0800, Yan, Zheng wrote:
>> From: "Yan, Zheng"
>>
>> If perf event buffer is in overwrite mode, the kernel only updates
>> the data head when it overwrites old samples. The program that owns
>> the buffer need periodically check the buffer and update a variable
>> that tracks the date tail. If the program fails to do this in time,
>> the data tail can be overwritted by new samples. The program has to
>> rewind the buffer because it does not know where is the first vaild
>> sample.
>>
>> This patch makes the kernel update the date tail when it overwrites
>> old events. So the program that owns the event buffer can always
>> read the latest samples. This is convenient for programs that use
>> perf to do branch tracing. One use case is GDB branch tracing:
>> (http://sourceware.org/ml/gdb-patches/2012-06/msg00172.html)
>> It uses perf interface to read BTS, but only cares the branches
>> before the ptrace event.
>>
>> I added code to perf_output_{begin/end} to count how many cycles
>> are spent by sample output, then ran "perf record" to profile kernel
>> compilation 10 times on IvyBridge-EP. (perf record -a make -j 60)
>> The first number is scaled to 1000, the rest numbers are scaled by
>> the same factor.
>>
>> before overwrite mode after overwrite mode
>> AVG 1000999 10461044
>> STDEV19.419.517.117.9
>
> OK, so I was sure I replied to this email; but apparently I didn't :/
>
> So its still adding about 5% overhead to the regular case; this is sad.
>
> What does something like the below do?
Thank you for your help. I ran the same test, the results for regular case
are much better. But it still has about 1% overhead, probably because we
enlarge the ring_buffer structure, make it less cache friendly.
originwith the patch
AVG1000 1013
STDEV 13.4 15.0
Regards
Yan, Zheng
>
> ---
> include/linux/perf_event.h | 2 +
> kernel/events/core.c| 60 --
> kernel/events/internal.h| 2 +
> kernel/events/ring_buffer.c | 90
> +++--
> 4 files changed, 106 insertions(+), 48 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 8873f82..bcce98a 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -753,6 +753,8 @@ static inline bool has_branch_stack(struct perf_event
> *event)
>
> extern int perf_output_begin(struct perf_output_handle *handle,
>struct perf_event *event, unsigned int size);
> +extern int perf_output_begin_overwrite(struct perf_output_handle *handle,
> + struct perf_event *event, unsigned int size);
> extern void perf_output_end(struct perf_output_handle *handle);
> extern unsigned int perf_output_copy(struct perf_output_handle *handle,
>const void *buf, unsigned int len);
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 1833bc5..4d674e9 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3878,6 +3878,8 @@ static const struct vm_operations_struct
> perf_mmap_vmops = {
> .page_mkwrite = perf_mmap_fault,
> };
>
> +static void perf_event_set_overflow(struct perf_event *event, struct
> ring_buffer *rb);
> +
> static int perf_mmap(struct file *file, struct vm_area_struct *vma)
> {
> struct perf_event *event = file->private_data;
> @@ -3985,6 +3987,7 @@ static int perf_mmap(struct file *file, struct
> vm_area_struct *vma)
> vma->vm_mm->pinned_vm += extra;
>
> ring_buffer_attach(event, rb);
> + perf_event_set_overflow(event, rb);
> rcu_assign_pointer(event->rb, rb);
>
> perf_event_update_userpage(event);
> @@ -4595,9 +4598,12 @@ void perf_prepare_sample(struct perf_event_header
> *header,
> }
> }
>
> -static void perf_event_output(struct perf_event *event,
> - struct perf_sample_data *data,
> - struct pt_regs *regs)
> +static __always_inline void
> +__perf_event_output(struct perf_event *event,
> + struct perf_sample_data *data,
> + struct pt_regs *regs,
> + int (*output_begin)(struct perf_output_handle *,
> + struct perf_event *, unsigned int))
> {
> struct perf_output_handle handle;
> struct perf_event_header header;
> @@ -4607,7 +4613,7 @@ static void perf_event_output(struct perf_event *event,
>
> perf_prepare_sample(&header, data, event, regs);
>
> - if (perf_output_begin(&handle, event, header.size))
> + if (output_begin(&handle, event, header.size))
> goto exit;
>
> perf_output_sample(&handle, &header, data, event);
> @@ -4618,6 +4624,33 @@ static void perf_event_output(struct perf_event *e
E-mial us for an urgent loan today contact: veronicaloanfi...@hotmail.com
-- 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: Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices
On 07/07/2013 10:15 PM, Geert Uytterhoeven wrote:
On Fri, Jul 5, 2013 at 1:51 AM, Linux Kernel Mailing List
wrote:
+++ b/drivers/input/touchscreen/cyttsp4_spi.c
+static int cyttsp_spi_xfer(struct device *dev, u8 *xfer_buf,
+ u8 op, u8 reg, u8 *buf, int length)
+{
+ if (reg > 255)
As "reg" is "u8", this is never true:
drivers/input/touchscreen/cyttsp4_spi.c: In function ‘cyttsp_spi_xfer’:
drivers/input/touchscreen/cyttsp4_spi.c:66: warning: comparison is
always false due to limited range of data type
+ wr_buf[0] = op + CY_SPI_A8_BIT;
+ else
+ wr_buf[0] = op;
Can the if-clause and the first branch just be removed, or is there a real bug
involved (e.g. wrong type for "reg")?
Yes there was a bug here, and already sent a patch for this, please
check https://patchwork.kernel.org/patch/2820561/
thanks,
ferruh
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
--
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/5] Add phy support for AM335X platform using Generic PHy framework
On 07/08/2013 10:34 PM, Ezequiel Garcia wrote: > Hi, Hi, > On Mon, Jul 08, 2013 at 09:44:33PM +0200, Sebastian Andrzej Siewior wrote: > >> We need two nodes each one with a glue layer and a musb child node. The >> instances crap in kernel has to vanish. Also that means your phy nodes >> are wrong. This is not musb with two ports but two musb instances each >> with one port. >> > > I agree completely. The current DT representation looks definitely odd, > and we should be looking at improving it. > > I wonder if this is now possible, given the DT is supposed to be stable ABI. I posted this [0] and Felipe + Benoit were pro change. I am still not sure if this is okay or just one glue layer per instance so I delay this until I am sure. Stable or not, what currently have in is beyond broken and it can't be fixed in kernel. I would add some code to check for the old nodes and give a proper warning and how to react. This should reduce the pain full search. [0] http://git.breakpoint.cc/cgit.cgi/bigeasy/linux.git/commit/?h=am335x_usb&id=0a60cd77ee50edd8cd07cbd699ed67b2c4b2ab93 Sebastian -- 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 v1 0/4] ARM: STi fixes and ethernet support
Thanks Arnd, On 09/07/13 00:18, Arnd Bergmann wrote: > On Monday 08 July 2013, Srinivas KANDAGATLA wrote: >> From: Srinivas Kandagatla >> >> This patch series fixes 2 configuration issues and adds ethernet support to >> STiH415, STiH416 based B2000, B2020 boards. > > Hi Srini, > > You really have to send those things separately, as the bug fixes should > probably go into 3.11, while the rest is new features and needs to be > reviewed for merging into 3.12. Yes, I will resend the fixes separately. > > I'm also puzzled by the fact that you add auxdata and callback > functions for the ether part in the platform code. Those should > probably all be properties added to the stmmac binding. stmmac (aka "dwmac" a synopsis IP) driver is integrated in to kernel sometime in 2.6 series I think :-), and Is used by more than 4 platforms in 3.10 kernel. The driver is more generic than it sounds. So adding properties/hooks specific to STiH41x SOCs in driver seemed to incorrect. Instead doing platform specific bits in the mach via callbacks was the only choice I had. Thanks, srini > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On Tuesday 09 July 2013 02:03 AM, Nishanth Menon wrote:
On 19:12-20130708, Sourav Poddar wrote:
[..]
generic comment, given our historical mistakes of making drivers
specific to a SoC family, it never is.
Now, ti-qspi in file name is a step in the right direction, but, rest
of the code(function names etc) is just married to DRA7 family of
processor, when it should not be.
Make sense. Will change apis accordingly.
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..430de9c
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
[...]
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi->base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi->base + reg);
+}
+
+static inline unsigned long dra7xxx_readl_data(struct dra7xxx_qspi *qspi,
+ unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ return readw(qspi->base + reg);
+ break;
+ case 16:
+ return readb(qspi->base + reg);
+ break;
+ case 32:
+ return readl(qspi->base + reg);
+ break;
+ default:
+ return -1;
+ }
+}
+
+static inline void dra7xxx_writel_data(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ writew(val, qspi->base + reg);
+ break;
+ case 16:
+ writeb(val, qspi->base + reg);
+ break;
+ case 32:
+ writeb(val, qspi->base + reg);
+ break;
+ default:
+ dev_dbg(qspi->dev, "word lenght out of range");
+ break;
+ }
+}
Looks like a case to use regmap?
Dumb q: why cant we use regmap_spi? worst case, you should be able to
use mmio if regmap_spi cant be used. The commit message was not clear
about this.
MMIO can be used as this controller supports memory mapped port, but that
will be addition/enhancement on top of this.
This driver is adding qspi controller read/write support in SPI mode.
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(spi->master);
+ int clk_div = 0;
+ u32 clk_ctrl_reg, clk_rate;
+
+ clk_rate = clk_get_rate(qspi->fclk);
+
+ if (!qspi->spi_max_frequency) {
+ dev_err(qspi->dev, "spi max frequency not defined\n");
+ return -1;
+ } else
+ clk_div = (clk_rate / qspi->spi_max_frequency) - 1;
did you run checkpatch --strict here?
Didn,t do the strict, yes will add braces.
Also, would you prefer to use DIV_ROUND_UP?
Ok.
+
+ dev_dbg(qspi->dev, "%s: hz: %d, clock divider %d\n", __func__,
+ qspi->spi_max_frequency, clk_div);
+
+ pm_runtime_get_sync(qspi->dev);
error check?
Will add.
+
+ clk_ctrl_reg = dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ clk_ctrl_reg&= ~QSPI_CLK_EN;
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, clk_ctrl_reg, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div< 0) {
+ dev_dbg(qspi->dev, "%s: clock divider< 0, using /1 divider\n",
+ __func__);
+ clk_div = 1;
should you not fail here?
May be yes.
+ }
+
+ if (clk_div> QSPI_CLK_DIV_MAX) {
+ dev_dbg(qspi->dev, "%s: clock divider>%d , using /%d divider\n",
+ __func__, QSPI_CLK_DIV_MAX, QSPI_CLK_DIV_MAX + 1);
+ clk_div = QSPI_CLK_DIV_MAX;
should you not fail here?
Yup.
+ }
+
+ /* enable SCLK */
+ dra7xxx_writel(qspi, QSPI_CLK_EN | clk_div, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
error check?
Will add.
+
+ return 0;
+}
+
+static int dra7xxx_qspi_prepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_get_sync(qspi->dev);
error check?
Will add.
+
+ return 0;
+}
+
+static int dra7xxx_qspi_unprepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
error check?
Will add.
+
+ return 0;
+}
+
+static int qspi_write_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ const u8 *txbuf;
+ int wlen, count;
+
+ count = t->len;
+ txbuf = t->tx_buf;
+ wlen = t->bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi->dev, "tx cmd %08x dc %08x data %02x\n",
+ qspi->cmd | QSPI_WR_SNGL, qspi->dc, *txbuf);
+ dra7xxx_writel
Re: [PATCHv3 2/3] drivers: spi: Add qspi flash controller
On Monday 08 July 2013 08:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 07:12:59PM +0530, Sourav Poddar wrote:
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi->base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi->base + reg);
+}
+
+static inline unsigned long dra7xxx_readl_data(struct dra7xxx_qspi *qspi,
+ unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ return readw(qspi->base + reg);
+ break;
+ case 16:
+ return readb(qspi->base + reg);
+ break;
+ case 32:
+ return readl(qspi->base + reg);
+ break;
+ default:
+ return -1;
return -EINVAL ? or some other error code ?
Ok.will change.
+ }
+}
+
+static inline void dra7xxx_writel_data(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg, int wlen)
+{
+ switch (wlen) {
+ case 8:
+ writew(val, qspi->base + reg);
+ break;
+ case 16:
+ writeb(val, qspi->base + reg);
+ break;
+ case 32:
+ writeb(val, qspi->base + reg);
+ break;
+ default:
+ dev_dbg(qspi->dev, "word lenght out of range");
+ break;
+ }
+}
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(spi->master);
+ int clk_div = 0;
+ u32 clk_ctrl_reg, clk_rate;
+
+ clk_rate = clk_get_rate(qspi->fclk);
+
+ if (!qspi->spi_max_frequency) {
+ dev_err(qspi->dev, "spi max frequency not defined\n");
+ return -1;
same here
Ok.
+ } else
this needs to have curly braces too, per CodingStyle
hmm..will change.
+ clk_div = (clk_rate / qspi->spi_max_frequency) - 1;
+
+ dev_dbg(qspi->dev, "%s: hz: %d, clock divider %d\n", __func__,
+ qspi->spi_max_frequency, clk_div);
+
+ pm_runtime_get_sync(qspi->dev);
+
+ clk_ctrl_reg = dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ clk_ctrl_reg&= ~QSPI_CLK_EN;
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, clk_ctrl_reg, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div< 0) {
+ dev_dbg(qspi->dev, "%s: clock divider< 0, using /1 divider\n",
+ __func__);
+ clk_div = 1;
+ }
+
+ if (clk_div> QSPI_CLK_DIV_MAX) {
+ dev_dbg(qspi->dev, "%s: clock divider>%d , using /%d divider\n",
+ __func__, QSPI_CLK_DIV_MAX, QSPI_CLK_DIV_MAX + 1);
+ clk_div = QSPI_CLK_DIV_MAX;
+ }
+
+ /* enable SCLK */
+ dra7xxx_writel(qspi, QSPI_CLK_EN | clk_div, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
+
+ return 0;
+}
+
+static int dra7xxx_qspi_prepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_get_sync(qspi->dev);
not going to check return value ?
Will add.
+ return 0;
+}
+
+static int dra7xxx_qspi_unprepare_xfer(struct spi_master *master)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_mark_last_busy(qspi->dev);
+ pm_runtime_put_autosuspend(qspi->dev);
what about on these two ?
Yes, will add error checking.
+ return 0;
+}
+
+static int qspi_write_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ const u8 *txbuf;
+ int wlen, count;
+
+ count = t->len;
+ txbuf = t->tx_buf;
+ wlen = t->bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi->dev, "tx cmd %08x dc %08x data %02x\n",
+ qspi->cmd | QSPI_WR_SNGL, qspi->dc, *txbuf);
+ dra7xxx_writel(qspi, QSPI_WC_INT_EN, QSPI_INTR_ENABLE_SET_REG);
you should enable the interrupt as the last step. Also, why aren't you
using frame interrupt ?
+ dra7xxx_writel_data(qspi, *txbuf++, QSPI_SPI_DATA_REG, wlen);
+ dra7xxx_writel(qspi, qspi->dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi->cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ wait_for_completion(&qspi->word_complete);
+ }
+
+ return 0;
+}
+
+static int qspi_read_msg(struct dra7xxx_qspi *qspi, struct spi_transfer *t)
+{
+ u8 *rxbuf;
+ int wlen, count;
+
+ count = t->len;
+ rxbuf = t->rx_buf;
+ wlen = t->bits_per_word;
+
+ while (count--) {
+ dev_dbg(qspi->dev, "rx cmd %08x dc %08x\n",
+ qspi->cmd | QSPI_RD_SNGL, qspi->dc);
+ dra7xxx_writel(qspi, QSPI_WC_
Re: [PATCH 0/3] cris: cleanup Kconfig files
Hi Michael,
On Mon, Jul 8, 2013 at 8:04 AM, Michael Opdenacker
wrote:
> This set of patches removes kernel configuration parameters for the
> CRIS architecture, which are used nowhere in the kernel source
> code and makefiles.
>
> Michael Opdenacker (3):
> cris: cleanup arch-v10/drivers/Kconfig
> cris: cleanup arch-v32/drivers/Kconfig
> cris: cleanup Kconfig
>
> arch/cris/Kconfig | 9 --
> arch/cris/arch-v10/drivers/Kconfig | 79 ---
> arch/cris/arch-v32/drivers/Kconfig | 197
> -
> 3 files changed, 285 deletions(-)
(At least) Some of these have been in cris/for-next for a few months,
courtesy of
Paul Bolle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] ARM: STi: Set correct ARM ERRATAs.
From: Srinivas Kandagatla Some of the ARM_ERRATA selection is not done in the initial SOC support patches. This patch selects 2 new ARM_ERRATA's and removes one which was actually fixed. Signed-off-by: Srinivas Kandagatla --- arch/arm/mach-sti/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index d04e3bf..c216094 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -11,8 +11,9 @@ menuconfig ARCH_STI select HAVE_SMP select HAVE_ARM_SCU if SMP select ARCH_REQUIRE_GPIOLIB - select ARM_ERRATA_720789 select ARM_ERRATA_754322 + select ARM_ERRATA_775420 + select ARM_ERRATA_764369 select PL310_ERRATA_753970 if CACHE_PL310 select PL310_ERRATA_769419 if CACHE_PL310 help -- 1.7.6.5 -- 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/3] cris: cleanup Kconfig files
Hi Geert, On 07/09/2013 09:33 AM, Geert Uytterhoeven wrote: > Hi Michael, > > On Mon, Jul 8, 2013 at 8:04 AM, Michael Opdenacker > wrote: >> This set of patches removes kernel configuration parameters for the >> CRIS architecture, which are used nowhere in the kernel source >> code and makefiles. >> >> Michael Opdenacker (3): >> cris: cleanup arch-v10/drivers/Kconfig >> cris: cleanup arch-v32/drivers/Kconfig >> cris: cleanup Kconfig >> >> arch/cris/Kconfig | 9 -- >> arch/cris/arch-v10/drivers/Kconfig | 79 --- >> arch/cris/arch-v32/drivers/Kconfig | 197 >> - >> 3 files changed, 285 deletions(-) > (At least) Some of these have been in cris/for-next for a few months, > courtesy of > Paul Bolle. Thank you for your reply. I hope they will make it this time. Cheers, Michael. -- Michael Opdenacker, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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] ARM: STi Fixes
From: Srinivas Kandagatla This patch series fixes 2 configuration issues related to serial setup on STiH416 and ARM ERRATA selection. Changes since v1: - Split out fixes in seperate patch set. Srinivas Kandagatla (2): ARM: dts: STi: Fix pinconf setup for STiH416 serial2 ARM: STi: Set correct ARM ERRATAs. arch/arm/boot/dts/stih416-pinctrl.dtsi | 10 +- arch/arm/boot/dts/stih416.dtsi |2 +- arch/arm/mach-sti/Kconfig |3 ++- 3 files changed, 12 insertions(+), 3 deletions(-) -- 1.7.6.5 -- 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: [alsa-devel] [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
2013/7/8 Lars-Peter Clausen :
> On 07/08/2013 03:29 PM, Richard Genoud wrote:
> [...]
>> +/*
>> + * Logic for a wm8731 as connected on a at91sam9x5 based board.
>> + */
>> +static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
>> +{
> [...]
>> + codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
>> + SNDRV_PCM_RATE_32000 |
>> + SNDRV_PCM_RATE_48000 |
>> + SNDRV_PCM_RATE_96000;
>> + codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
>> + SNDRV_PCM_RATE_32000 |
>> + SNDRV_PCM_RATE_48000 |
>> + SNDRV_PCM_RATE_96000;
>
> That's not right. The driver structure is shared between all instances of
> the codec, a single instance should not modify it. If you need to constrain
> the list of supported rates use snd_pcm_hw_constraint_list().
Ok, I'll do that.
>
>> +
>> + /* set the codec system clock for DAC and ADC */
>> + ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
>> + MCLK_RATE, SND_SOC_CLOCK_IN);
>> + if (ret < 0) {
>> + dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* signal a DAPM event */
>> + snd_soc_dapm_sync(dapm);
>
> This should not be necessary.
ok
>
>> + return 0;
>> +}
>
Thanks !
--
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?
--
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] btusb: fix overflow return values
On Tue, Jul 09, 2013 at 10:55:01AM +0800, Adam Lee wrote: > On Mon, Jul 08, 2013 at 11:50:54AM -0700, Marcel Holtmann wrote: > > Hi Adam, > > > > > PTR_ERR() returns a long type value, but btusb_setup_intel() and > > > btusb_setup_intel_patching() should return an int type value. > > > > > > This bug makes the judgement "if (ret < 0)" not working on x86_64 > > > architecture systems, leading to failure as below, even panic. > > > ... > > > For not affecting other modules, I choose to modify the return values > > > but not extend btusb_setup_intel() and btusb_setup_intel_patching()'s > > > return types. This is harmless, because the return values were only > > > used to comparing number 0. > > > > there are tons of examples in various subsystems and drivers where we > > return PTR_ERR from a function calls returning int. > > > > So I wonder what is actually going wrong here. If this is x86_64 > > specific problem with PTR_ERR vs int, then we should have this problem > > everywhere in the kernel. > > Hi, Marcel > > I see you point, the difference between here and other subsystems are: > > 1, it returns -PTR_ERR() here but all other places return PTR_ERR(), I > checked. > 2, the judgement is "if (ret < 0)" here but other places are "if (ret)". > > I'm not saying other subsystems are 100% right, but here, returning > -PTR_ERR() and checking "if (ret < 0)" make the judgement broken much > much more easily. > > I attached a testing C file, run it on x86_64, you will see the bug. > > PS, about other subsystems, I also think returning PTR_ERR() from a > function calls returning int considered harmful sometimes, will talk > about that in other thread. Hi, all After diving into the err.h, I realized this patch contains some modifications which are actually not necessary. Will submit a v2 version and explain. PS, other subsystems are using it right, this not. -- Regards, Adam Lee Hardware Enablement -- 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 tools: Fixup for removing -f option in perf record
Hi Arnaldo,
You may want to merge this patch too. :)
Thanks,
Namhyung
2013-06-27 오후 1:25, Namhyung Kim 쓴 글:
From: Namhyung Kim
The commit bf3da4014a0c ("perf record: Remove -f/--force option") got
rid of -f option from perf record. But this option was used
internally by various sub-commands so they wouldn't work anymore.
Also update the example document not to use -f option.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/examples.txt | 4 ++--
tools/perf/builtin-kmem.c | 2 +-
tools/perf/builtin-lock.c | 2 +-
tools/perf/builtin-sched.c| 1 -
tools/perf/builtin-timechart.c| 4 ++--
5 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/examples.txt
b/tools/perf/Documentation/examples.txt
index 77f952762426..a4e392156488 100644
--- a/tools/perf/Documentation/examples.txt
+++ b/tools/perf/Documentation/examples.txt
@@ -66,7 +66,7 @@ Furthermore, these tracepoints can be used to sample the
workload as
well. For example the page allocations done by a 'git gc' can be
captured the following way:
- titan:~/git> perf record -f -e kmem:mm_page_alloc -c 1 ./git gc
+ titan:~/git> perf record -e kmem:mm_page_alloc -c 1 ./git gc
Counting objects: 1148, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (450/450), done.
@@ -120,7 +120,7 @@ Furthermore, call-graph sampling can be done too, of page
allocations - to see precisely what kind of page allocations there
are:
- titan:~/git> perf record -f -g -e kmem:mm_page_alloc -c 1 ./git gc
+ titan:~/git> perf record -g -e kmem:mm_page_alloc -c 1 ./git gc
Counting objects: 1148, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (450/450), done.
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 46878daca5cc..0259502638b4 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -708,7 +708,7 @@ static int parse_line_opt(const struct option *opt
__maybe_unused,
static int __cmd_record(int argc, const char **argv)
{
const char * const record_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "kmem:kmalloc",
"-e", "kmem:kmalloc_node",
"-e", "kmem:kfree",
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 425830069749..76543a4a7a30 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -878,7 +878,7 @@ static int __cmd_report(void)
static int __cmd_record(int argc, const char **argv)
{
const char *record_args[] = {
- "record", "-R", "-f", "-m", "1024", "-c", "1",
+ "record", "-R", "-m", "1024", "-c", "1",
};
unsigned int rec_argc, i, j;
const char **rec_argv;
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 2da2a6ca22bf..fed9ae432c16 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1632,7 +1632,6 @@ static int __cmd_record(int argc, const char **argv)
"record",
"-a",
"-R",
- "-f",
"-m", "1024",
"-c", "1",
"-e", "sched:sched_switch",
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index ab4cf232b852..4536a92b18f3 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -1005,7 +1005,7 @@ static int __cmd_record(int argc, const char **argv)
{
#ifdef SUPPORT_OLD_POWER_EVENTS
const char * const record_old_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "power:power_start",
"-e", "power:power_end",
"-e", "power:power_frequency",
@@ -1014,7 +1014,7 @@ static int __cmd_record(int argc, const char **argv)
};
#endif
const char * const record_new_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "power:cpu_frequency",
"-e", "power:cpu_idle",
"-e", "sched:sched_wakeup",
--
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: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter
>>> On 09.07.13 at 02:26, Konrad Rzeszutek Wilk wrote: > Could you explain to me please why the check in the scripts is superfluous? This is not really the question - _any_ such check can only be wrong. The boot loader has absolutely no business caring about kernel internals, and the kernel shouldn't be limited by it in how it renames/adds/deletes Kconfig options and anything else. > Especially as the grand plan is to get rid of CONFIG_XEN_DOM0 and more or > less have a backend and fronted config option (since that makes more sense > nowadays). And that would make the XEN_DOM0 be obsolete and the XEN_PRIV > would be the one that turns a lot of the options needed to compile a kernel > that can provide backend driver support. (I am hand waving here). That's pretty odd a plan, considering that Dom0 is more than just an environment to provide backends. In fact, Dom0 may not be providing any backends at all, and instead just serve the "controlling hardware" and/or "control domain" purpose that it really is meant to be. But of course, if none of _that_ functionality depends on this config option, then it indeed could go away. Jan -- 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: Update event buffer tail when overwriting old events
On Tue, Jul 09, 2013 at 03:18:20PM +0900, Namhyung Kim wrote:
> Hi Peter,
>
> On Mon, 8 Jul 2013 14:15:57 +0200, Peter Zijlstra wrote:
> [SNIP]
> > +static void
> > +perf_event_set_overflow(struct perf_event *event, struct ring_buffer *rb)
> > +{
> > + if (event->overflow_handler != perf_event_output ||
>
> I guess you wanted "&&" instead of "||" here.
Uhm.. yeah. /me dons the brown paper bag.
--
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] of: match the compatible in the order set by the dts file
于 2013年07月09日 15:05, Sascha Hauer 写道:
Why don't you set the matching order in the driver the way you want it
to be, i.e.:
{ .compatible = "fsl,imx6q-uart", ... },
{ .compatible = "fsl,imx21-uart", ... },
{ .compatible = "fsl,imx1-uart", ... },
yes. i can set it like this.
but this method looks like a ugly workaround.
thanks
Huang Shijie
--
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/3] cris: cleanup Kconfig files
On Tue, Jul 9, 2013 at 9:35 AM, Michael Opdenacker
wrote:
> On 07/09/2013 09:33 AM, Geert Uytterhoeven wrote:
>> On Mon, Jul 8, 2013 at 8:04 AM, Michael Opdenacker
>> wrote:
>>> This set of patches removes kernel configuration parameters for the
>>> CRIS architecture, which are used nowhere in the kernel source
>>> code and makefiles.
>>>
>> (At least) Some of these have been in cris/for-next for a few months,
>> courtesy of
>> Paul Bolle.
>
> Thank you for your reply. I hope they will make it this time.
/me too
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] lib: One less subtraction in binary search iterations.
On 07/09/2013 09:21 AM, Wedson Almeida Filho wrote:
> On Sat, Jul 6, 2013 at 9:59 PM, Joe Perches wrote:
>>
>> Not correct.
>>
>>> while (start < end) {
>>> - size_t mid = start + (end - start) / 2;
>>> + size_t mid = (start + end) / 2;
>>
>> size_t start = 0x8000;
>> size_t end = 0x8001;
>
> Good point, they aren't equivalent in all cases.
>
> For the overflow to happen though, we need an array with at least
> N/2+1 entries, where N is the address space size. The array wouldn't
> fit in addressable memory if the element size is greater than 1, so
> this can only really happen when the element size is 1. Even then, it
> would require the kernel range to be greater than half of all
> addressable memory, and allow an allocation taking that much memory. I
> don't know all architectures where linux runs, but I don't think such
> configuration is likely to exist.
>
It does. In ARC port (arch/arc), the untranslated address space starts at
0x8000_ and this is where kernel is linked at. So all ARC kernel addresses
(code/data) lie in that range. This means you don't need special corner case for
this trip on ARC - it will break rightaway - unless I'm missing something.
P.S. Sorry for not replying earlier than ur v2.
-Vineet
--
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: [v2][PATCH 1/7] powerpc/book3e: support CONFIG_RELOCATABLE
On 07/02/2013 01:00 PM, Bhushan Bharat-R65777 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun Chen Sent: Thursday, June 20, 2013 1:23 PM To: b...@kernel.crashing.org Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org Subject: [v2][PATCH 1/7] powerpc/book3e: support CONFIG_RELOCATABLE book3e is different with book3s since 3s includes the exception vectors code in head_64.S as it relies on absolute addressing which is only possible within this compilation unit. So we have to get that label address with got. And when boot a relocated kernel, we should reset ipvr properly again after .relocate. Signed-off-by: Tiejun Chen --- [snip] int *src, *dest; unsigned long length; +#ifdef CONFIG_PPC_BOOK3E + extern char interrupt_end_book3e[]; +#endif Cannot we do this in arch/powerpc/kernel/asm/sections.h if (PHYSICAL_START == 0) return; src = (int *)(KERNELBASE + PHYSICAL_START); dest = (int *)KERNELBASE; +#ifdef CONFIG_PPC_BOOK3E + length = (interrupt_end_book3e - _stext) / sizeof(int); +#else length = (__end_interrupts - _stext) / sizeof(int); +#endif can we keep same name in books and booke; __end_interrupts ? this way we can avoid such #ifdefs Yes, I think I can simplify this as you pointed :) Thanks, Tiejun -- 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: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for lm90
On 07/09/2013 02:21 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Jul 08, 2013 at 06:14:21AM -0700, Guenter Roeck wrote:
>> On Mon, Jul 08, 2013 at 05:36:05PM +0800, Wei Ni wrote:
>>> On 07/08/2013 03:50 PM, Jean Delvare wrote:
On Mon, 8 Jul 2013 15:35:48 +0800, Wei Ni wrote:
> On 07/06/2013 01:38 AM, Stephen Warren wrote:
>> On 07/04/2013 03:09 AM, Wei Ni wrote:
>>> Enable thermal sensor lm90 for t30 cardhu.
>>
>>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
>>> b/arch/arm/boot/dts/tegra30-cardhu.dtsi
>>
>>> + nct1008: nct1008 {
>>> + compatible = "lm90,nct1008";
>>
>> "lm90" isn't a valid vendor prefix. I believe the value you want is
>> "onnn,nct1008". Same comment for patch 2/2.
>
> The lm90 doesn't support device tree very well.
I doubt it, but if this is the case, then please fix it, instead of
working the problem around in a different place.
> In the DT, we need to
> named as "lm90" so that the lm90 driver can be loaded,
Not that I am an expert with regards to DT, but this doesn't make any
sense to me. AFAIK DT is about devices, not which drivers handle them.
> and we also need
> to add "nct1008" to indicate this is the nct1008 device, so that the
> lm90 driver can be loaded with the right i2c_device_id->driver_data.
>
> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
> we doesn't need to change the lm90.c.
There's no problem with changing the lm90 driver, if this is the right
thing to do.
>>>
>>> Ok, I will add DT support in the lm90.c in my next version patch.
>>>
>> Only if you can show that it is necessary.
>
> It should work out of the box. As a matter of fact the same chip is used
> on Tamonten and the DTS files use "onnn,nct1008". That used to work. If
> it no longer does then that's a regression.
I synced the linux-next from:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
and use the tag v3.10-rc7, but in the lm90.c it doesn't have DT support,
such as "onnn,nct1008".
I googled it and found there has patch:
[PATCH] hwmon: (lm90) Add device tree support , which is in:
http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038099.html
, but it didn't be merged into the linux-next.
which git repository and branch should I use ?
Thanks.
Wei.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
--
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] of: match the compatible in the order set by the dts file
On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> 于 2013年07月09日 15:05, Sascha Hauer 写道:
> >Why don't you set the matching order in the driver the way you want it
> >to be, i.e.:
> >
> > { .compatible = "fsl,imx6q-uart", ... },
> > { .compatible = "fsl,imx21-uart", ... },
> > { .compatible = "fsl,imx1-uart", ... },
> >
> yes. i can set it like this.
>
> but this method looks like a ugly workaround.
If a driver has different ways of supporting a single device, then
putting the preferred or most feature rich on top doesn't look very ugly
to me.
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- |
--
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: [v2][PATCH 4/7] book3e/kexec/kdump: introduce a kexec kernel flag
On 07/02/2013 01:37 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun Chen
Sent: Thursday, June 20, 2013 1:23 PM
To: b...@kernel.crashing.org
Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: [v2][PATCH 4/7] book3e/kexec/kdump: introduce a kexec kernel flag
We need to introduce a flag to indicate we're already running
a kexec kernel then we can go proper path. For example, We
shouldn't access spin_table from the bootloader to up any secondary
cpu for kexec kernel, and kexec kernel already know how to jump to
generic_secondary_smp_init.
Signed-off-by: Tiejun Chen
---
[snip]
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -150,6 +150,9 @@ static int __cpuinit smp_85xx_kick_cpu(int nr)
int hw_cpu = get_hard_smp_processor_id(nr);
int ioremappable;
int ret = 0;
+#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
+ unsigned long *ptr;
+#endif
What about if we can remove the ifdef around *ptr ...
WARN_ON(nr < 0 || nr >= NR_CPUS);
WARN_ON(hw_cpu < 0 || hw_cpu >= NR_CPUS);
@@ -238,11 +241,22 @@ out:
#else
smp_generic_kick_cpu(nr);
+#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
+ ptr = (unsigned long *)((unsigned long)&__run_at_kexec);
... #endif here ...
+ /* We shouldn't access spin_table from the bootloader to up any
+* secondary cpu for kexec kernel, and kexec kernel already
+* know how to jump to generic_secondary_smp_init.
+*/
+ if (!*ptr) {
+#endif
... remove #endif ...
flush_spin_table(spin_table);
out_be32(&spin_table->pir, hw_cpu);
out_be64((u64 *)(&spin_table->addr_h),
__pa((u64)*((unsigned long long *)generic_secondary_smp_init)));
flush_spin_table(spin_table);
+#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
+ }
+#endif
--- remove above 3 lines
I'd like to try to address your comments next version.
Thanks
Tiejun
--
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: [v2][PATCH 2/7] book3e/kexec/kdump: enable kexec for kernel
On 07/02/2013 01:17 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Tiejun Chen
Sent: Thursday, June 20, 2013 1:23 PM
To: b...@kernel.crashing.org
Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: [v2][PATCH 2/7] book3e/kexec/kdump: enable kexec for kernel
We need to active KEXEC for book3e and bypass or convert non-book3e stuff
in kexec coverage.
Signed-off-by: Tiejun Chen
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/kernel/machine_kexec_64.c |6 ++
arch/powerpc/kernel/misc_64.S |6 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..6ecf3c9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -364,7 +364,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call"
- depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP))
+ depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) || PPC_BOOK3E
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 611acdf..ef39271 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -33,6 +33,7 @@
int default_machine_kexec_prepare(struct kimage *image)
{
int i;
+#ifndef CONFIG_PPC_BOOK3E
unsigned long begin, end; /* limits of segment */
unsigned long low, high;/* limits of blocked memory range */
struct device_node *node;
@@ -41,6 +42,7 @@ int default_machine_kexec_prepare(struct kimage *image)
if (!ppc_md.hpte_clear_all)
return -ENOENT;
+#endif
Do we really need this function for book3e? can we have a separate function
rather than multiple confusing ifdef?
I prefer we have a separate function to book3e.
Thanks
Tiejun
--
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: [v2][PATCH 1/7] powerpc/book3e: support CONFIG_RELOCATABLE
On 07/03/2013 07:52 PM, Sethi Varun-B16395 wrote: -Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+varun.sethi=freescale@lists.ozlabs.org] On Behalf Of Tiejun Chen Sent: Thursday, June 20, 2013 1:23 PM To: b...@kernel.crashing.org Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org Subject: [v2][PATCH 1/7] powerpc/book3e: support CONFIG_RELOCATABLE book3e is different with book3s since 3s includes the exception vectors code in head_64.S as it relies on absolute addressing which is only possible within this compilation unit. So we have to get that label address with got. And when boot a relocated kernel, we should reset ipvr properly again after .relocate. Signed-off-by: Tiejun Chen --- arch/powerpc/include/asm/exception-64e.h |8 arch/powerpc/kernel/exceptions-64e.S | 15 ++- arch/powerpc/kernel/head_64.S| 22 ++ arch/powerpc/lib/feature-fixups.c|7 +++ 4 files changed, 51 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/exception-64e.h b/arch/powerpc/include/asm/exception-64e.h index 51fa43e..89e940d 100644 --- a/arch/powerpc/include/asm/exception-64e.h +++ b/arch/powerpc/include/asm/exception-64e.h @@ -214,10 +214,18 @@ exc_##label##_book3e: #define TLB_MISS_STATS_SAVE_INFO_BOLTED #endif +#ifndef CONFIG_RELOCATABLE #define SET_IVOR(vector_number, vector_offset)\ li r3,vector_offset@l; \ ori r3,r3,interrupt_base_book3e@l; \ mtspr SPRN_IVOR##vector_number,r3; +#else +#define SET_IVOR(vector_number, vector_offset) \ + LOAD_REG_ADDR(r3,interrupt_base_book3e);\ + rlwinm r3,r3,0,15,0; \ + ori r3,r3,vector_offset@l; \ + mtspr SPRN_IVOR##vector_number,r3; +#endif [Sethi Varun-B16395] Please add a documentation note here. Okay. #endif /* _ASM_POWERPC_EXCEPTION_64E_H */ diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 645170a..4b23119 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -1097,7 +1097,15 @@ skpinv: addir6,r6,1 /* Increment */ * r4 = MAS0 w/TLBSEL & ESEL for the temp mapping */ /* Now we branch the new virtual address mapped by this entry */ +#ifdef CONFIG_RELOCATABLE + /* We have to find out address from lr. */ + bl 1f /* Find our address */ +1: mflrr6 + addir6,r6,(2f - 1b) + tovirt(r6,r6) +#else LOAD_REG_IMMEDIATE(r6,2f) +#endif lis r7,MSR_KERNEL@h ori r7,r7,MSR_KERNEL@l mtspr SPRN_SRR0,r6 @@ -1348,9 +1356,14 @@ _GLOBAL(book3e_secondary_thread_init) mflrr28 b 3b -_STATIC(init_core_book3e) +_GLOBAL(init_core_book3e) /* Establish the interrupt vector base */ +#ifdef CONFIG_RELOCATABLE + tovirt(r2,r2) + LOAD_REG_ADDR(r3, interrupt_base_book3e) #else LOAD_REG_IMMEDIATE(r3, interrupt_base_book3e) +#endif mtspr SPRN_IVPR,r3 sync blr [Sethi Varun-B16395] Please add a documentation note here as well. Okay. diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index b61363d..0942f3a 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -414,12 +414,22 @@ _STATIC(__after_prom_start) /* process relocations for the final address of the kernel */ lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */ sldir25,r25,32 +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */ +#endif lwz r7,__run_at_load-_stext(r26) +#if defined(CONFIG_PPC_BOOK3E) + tophys(r26,r26) /* Restore for the remains. */ +#endif cmplwi cr0,r7,1/* flagged to stay where we are ? */ bne 1f add r25,r25,r26 1:mr r3,r25 bl .relocate +#if defined(CONFIG_PPC_BOOK3E) + /* We should set ivpr again after .relocate. */ + bl .init_core_book3e +#endif #endif [Sethi Varun-B16395] A more detailed note over here would be useful. Okay. /* @@ -447,12 +457,24 @@ _STATIC(__after_prom_start) * variable __run_at_load, if it is set the kernel is treated as relocatable * kernel, otherwise it will be moved to PHYSICAL_START */ +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */ +#endif lwz r7,__run_at_load-_stext(r26) +#if defined(CONFIG_PPC_BOOK3E) + tophys(r26,r26) /* Restore for the remains. */ +#endif cmplwi cr0,r7,1 bne 3f +#ifdef CONFIG_PPC_BOOK3E + LOAD_REG_ADDR(r5, interrupt_end_book3e) + LOAD_REG_ADDR(r11, _stext) + sub r5,r5,r11 +#else /* just co
Re: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for lm90
On Tue, 9 Jul 2013 15:48:40 +0800, Wei Ni wrote: > On 07/09/2013 02:21 PM, Thierry Reding wrote: > > It should work out of the box. As a matter of fact the same chip is used > > on Tamonten and the DTS files use "onnn,nct1008". That used to work. If > > it no longer does then that's a regression. > > I synced the linux-next from: > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > and use the tag v3.10-rc7, but in the lm90.c it doesn't have DT support, > such as "onnn,nct1008". > I googled it and found there has patch: > [PATCH] hwmon: (lm90) Add device tree support , which is in: > http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038099.html > , but it didn't be merged into the linux-next. It was not, because of the next reply in the same thread: http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038100.html > which git repository and branch should I use ? It is supposed to just work. What doesn't work for you exactly? -- Jean Delvare -- 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 v1 0/4] ARM: STi fixes and ethernet support
On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote: > stmmac (aka "dwmac" a synopsis IP) driver is integrated in to kernel > sometime in 2.6 series I think :-), and Is used by more than 4 platforms > in 3.10 kernel. The driver is more generic than it sounds. > So adding properties/hooks specific to STiH41x SOCs in driver seemed to > incorrect. Instead doing platform specific bits in the mach via > callbacks was the only choice I had. No, you should be using generic interfaces to do the things you need. I believe what you are missing is an ethernet phy driver that is specific to your SoC. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PCI: introduce PCIe Device Serial NUmber Capability support
Introduce PCIe Ext Capability Device Serial Number support,
so we can use the unique device serial number to identify
the physical device. During system suspend, if the PCIe
device was removed and inserted a new same device, after
system resume there is no good way to identify it, maybe
Device Serial Number is a good choice if device support.
Signed-off-by: Yijing Wang
Cc: "Rafael J. Wysocki"
Cc: Oliver Neukum
Cc: Paul Bolle
Cc: Gu Zheng
Cc: linux-...@vger.kernel.org
---
drivers/pci/pci.c | 33 +
drivers/pci/pci.h |1 +
drivers/pci/probe.c |3 +++
include/linux/pci.h |4
4 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e37fea6..d08df2b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2048,6 +2048,39 @@ void pci_free_cap_save_buffers(struct pci_dev *dev)
}
/**
+ * pci_get_dsn - get device serial number
+ * @dev: the PCI device
+ * @sn: saved device serial number
+ */
+void pci_get_dsn(struct pci_dev *dev, u64 *sn)
+{
+ int pos;
+ u32 lo, hi;
+
+ if (!pci_is_pcie(dev))
+ goto out;
+
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
+ if (!pos)
+ goto out;
+
+ pci_read_config_dword(dev, pos + 4, &lo);
+ pci_read_config_dword(dev, pos + 8, &hi);
+ *sn = ((u64)hi << 32) | lo;
+ return;
+
+out:
+ *sn = 0;
+ return;
+}
+EXPORT_SYMBOL(pci_get_dsn);
+
+void pci_dsn_init(struct pci_dev *dev)
+{
+ return pci_get_dsn(dev, &dev->sn);
+}
+
+/**
* pci_configure_ari - enable or disable ARI forwarding
* @dev: the PCI device
*
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 68678ed..f626006 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -202,6 +202,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type
type,
struct resource *res, unsigned int reg);
int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type);
void pci_configure_ari(struct pci_dev *dev);
+void pci_dsn_init(struct pci_dev *dev);
/**
* pci_ari_enabled - query ARI forwarding status
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 46ada5c..d4c6e7e 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1322,6 +1322,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Power Management */
pci_pm_init(dev);
+ /* Device Serial Number */
+ pci_dsn_init(dev);
+
/* Vital Product Data */
pci_vpd_pci22_init(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0fd1f15..59cd205 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -342,6 +342,7 @@ struct pci_dev {
struct list_head msi_list;
struct kset *msi_kset;
#endif
+ u64 sn; /* device serieal number, 0 if not support */
struct pci_vpd *vpd;
#ifdef CONFIG_PCI_ATS
union {
@@ -995,6 +996,9 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
size_t count, void *buf);
ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
void *buf);
int pci_vpd_truncate(struct pci_dev *dev, size_t size);
+/* Device Serial Number */
+void pci_get_dsn(struct pci_dev *dev, u64 *sn);
+
/* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
void pci_bus_assign_resources(const struct pci_bus *bus);
--
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 2/2] PCI,pciehp: avoid add a device already exist during pciehp_resume
Currently, pciehp_resume will call pciehp_enable_slot() to add
device if there is a device in the slot. But if the device was
present before suspend, it's no necessary to add again. Now in
such case, there is some uncomfortable message like
pciehp :00:1c.1:pcie04: Device :03:00.0 already exists at
:03:00, cannot hot-add
pciehp :00:1c.1:pcie04: Cannot add device at :03:00
This problem was reported by Paul Bolle
The discussion link: http://comments.gmane.org/gmane.linux.kernel.pci/19876
We can use PCIe Device Serial Number to identify the device if
device support DSN.
currently:
1. slot is empty before suspend, insert card during suspend.
In this case, is safe, pciehp will add device by check adapter
status register in pciehp_resume.
2. slot is non empty before suspend, remove card during suspend.
Also be safe, pciehp will remove device by check adapter
status register in pciehp_resume.
3. slot is non empty before suspend, remove card during suspend
and insert a new card.
Now pciehp just call pciehp_enable_slot() roughly. We should
remove the old card firstly, then add the new card.
4. slot is non empty before suspend, no action during suspend.
We should do nothing in pciehp_resume, but we call
pciehp_enable_slot(), so some uncomfortable messages show like above.
In this case, we can improve it a little by add a guard
if (!list_empty(bus->devices)).
Reported-by: Paul Bolle
Signed-off-by: Yijing Wang
Cc: Paul Bolle
Cc: "Rafael J. Wysocki"
Cc: Oliver Neukum
Cc: Gu Zheng
Cc: linux-...@vger.kernel.org
---
drivers/pci/hotplug/pciehp_core.c | 38 +---
1 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index 7d72c5e..d01e093 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -291,6 +291,28 @@ static void pciehp_remove(struct pcie_device *dev)
}
#ifdef CONFIG_PM
+
+/* If device support Device Serial Numner, use DSN
+ * to identify the device
+ */
+static bool device_in_slot_is_changed(struct pci_bus *pbus)
+{
+ u64 old_dsn, new_dsn;
+ struct pci_dev *pdev;
+
+ pdev = pci_get_slot(pbus, PCI_DEVFN(0, 0));
+ old_dsn = pdev->sn;
+
+ /* get func 0 device serial number */
+ pci_get_dsn(pdev, &new_dsn);
+ pci_dev_put(pdev);
+
+ if (old_dsn != new_dsn)
+ return true;
+
+ return false;
+}
+
static int pciehp_suspend (struct pcie_device *dev)
{
return 0;
@@ -300,6 +322,7 @@ static int pciehp_resume (struct pcie_device *dev)
{
struct controller *ctrl;
struct slot *slot;
+ struct pci_bus *pbus = dev->port->subordinate;
u8 status;
ctrl = get_service_data(dev);
@@ -311,10 +334,17 @@ static int pciehp_resume (struct pcie_device *dev)
/* Check if slot is occupied */
pciehp_get_adapter_status(slot, &status);
- if (status)
- pciehp_enable_slot(slot);
- else
- pciehp_disable_slot(slot);
+ if (status) {
+ if (list_empty(&pbus->devices))
+ pciehp_enable_slot(slot);
+ else if (device_in_slot_is_changed(pbus)) {
+ pciehp_disable_slot(slot);
+ pciehp_enable_slot(slot);
+ }
+ } else {
+ if (!list_empty(&pbus->devices))
+ pciehp_disable_slot(slot);
+ }
return 0;
}
#endif /* PM */
--
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 0/6] cpufreq: Add 'load_table' debugfs file to show colleced CPUs load
On 07/09/2013 03:50 PM, Viresh Kumar wrote: > On 5 July 2013 14:16, Chanwoo Choi wrote: >> Second, previous performance/powersave governor haven't calculated CPUs load >> becuase these governor didn't change CPU frequency according to CPUs load. >> But, >> load_table debugfs file always should indicate the collected CPUs data >> regardless >> of the kind of cpufreq governor. So, the patch3/4/5 implement that >> performance/ >> powersave governor will check periodically CPUs load by calling >> dbs_check_cpu() >> with timer. > > I raised a query on how can we call dbs_check_cpu() from > performance/powersave? Also, calling this routine will degrade > performance without any sense. So, I vote not for doing it. You're right. The performance/powersave don't usually need calling operation of dbs_check_cpu(). Only, this patch aims at checking CPUs load on load_table debugfs file. I'm going to consider more efficient way than this patchset. For example, But, following patctes haven't the dependency about upper description about performance/powersave. If user changes cpufreq governor from ondemand/conservative to performance/powersave, patch2 did reset all of the data for load_table. cpufreq: Add debugfs directory for cpufreq cpufreq: stats: Add 'load_table' debugfs file to show accumulated data of CPUs Documentation: cpufreq: load_table: Update load_table debugfs file documentation So, I'd like you to review patch1,patch2, patch6. If you with that I resend patch1/2/6, I will resend new patchset incluing in patch1/2/6. Thanks, Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH V2] tracing: Check f_dentry before accessing event_file/call in inode->i_private
Currently ftrace_open_generic_file gets an event_file from
inode->i_private, and then locks event_mutex and gets refcount.
However, this can cause a race as below scenario;
CPU0 CPU1
open(kprobe_events)
trace_remove_event_call()open(enable)
lock event_mutex get event_file from inode->i_private
event_remove() wait for unlock event_mutex
...
free event_file
unlock event_mutex
lock event_mutex
add refcount of event_file->call (*)
So, at (*) point, the event_file is already freed and we
may access the corrupted object.
The same thing could happen on event_call because it is also
directly accessed from i_private on some points.
To avoid this, when opening events/*/*/enable, we have to ensure
the dentry of the file is not unlinked yet, under event_mutex
is locked.
CPU0 CPU1
open(kprobe_events)
trace_remove_event_call()open(enable)
lock event_mutex get event_file from inode->i_private
event_remove() wait for unlock event_mutex
...
dput(dentry)
free event_file
unlock event_mutex
lock event_mutex
check !d_unhashed(dentry) and failed
unlock event_mutex
return -ENODEV
Note: trace_array_get(tr) always ensures existance of tr in
trace_arrays, so above check is not needed in the case that
i_private directly points the tr.
Changes from V1:
- Use d_unhashed(f_dentry) to ensure the event exists according
to Oleg's comment.
Signed-off-by: Masami Hiramatsu
Suggested-by: Oleg Nesterov
---
kernel/trace/trace_events.c | 70 ++-
1 file changed, 55 insertions(+), 15 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 1a5547e..06fdac0 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -391,15 +391,32 @@ static void __get_system_dir(struct ftrace_subsystem_dir
*dir)
__get_system(dir->subsystem);
}
-static int ftrace_event_call_get(struct ftrace_event_call *call)
+static int __ftrace_event_call_get(struct ftrace_event_call *call)
{
int ret = 0;
- mutex_lock(&event_mutex);
if ((call->flags & TRACE_EVENT_FL_REF_MASK) == TRACE_EVENT_FL_REF_MAX -
1)
ret = -EBUSY;
else
call->flags++;
+
+ return ret;
+}
+
+static int ftrace_event_call_get(struct ftrace_event_call *call,
+struct dentry *dentry)
+{
+ int ret = -ENODEV;
+
+ mutex_lock(&event_mutex);
+ spin_lock(&dentry->d_lock);
+ if (d_unhashed(dentry)) /* This file is already unlinked */
+ goto out_unlock;
+
+ ret = __ftrace_event_call_get(call);
+
+ out_unlock:
+ spin_unlock(&dentry->d_lock);
mutex_unlock(&event_mutex);
return ret;
@@ -413,6 +430,35 @@ static void ftrace_event_call_put(struct ftrace_event_call
*call)
mutex_unlock(&event_mutex);
}
+static int ftrace_event_file_get(struct ftrace_event_file *file,
+struct dentry *dentry)
+{
+ int ret = -ENODEV;
+
+ mutex_lock(&event_mutex);
+ spin_lock(&dentry->d_lock);
+ if (d_unhashed(dentry)) /* This file is already unlinked */
+ goto out_unlock;
+
+ ret = __ftrace_event_call_get(file->event_call);
+ if (!ret)
+ file->tr->ref++;
+
+ out_unlock:
+ spin_unlock(&dentry->d_lock);
+ mutex_unlock(&event_mutex);
+
+ return ret;
+}
+
+static void ftrace_event_file_put(struct ftrace_event_file *file)
+{
+ struct trace_array *tr = file->tr;
+
+ ftrace_event_call_put(file->event_call);
+ trace_array_put(tr);
+}
+
static void __put_system_dir(struct ftrace_subsystem_dir *dir)
{
WARN_ON_ONCE(dir->ref_count == 0);
@@ -438,33 +484,27 @@ static void put_system(struct ftrace_subsystem_dir *dir)
static int tracing_open_generic_file(struct inode *inode, struct file *filp)
{
struct ftrace_event_file *file = inode->i_private;
- struct trace_array *tr = file->tr;
int ret;
- if (trace_array_get(tr) < 0)
- return -ENODEV;
-
- ret = tracing_open_generic(inode, filp);
+ ret = ftrace_event_file_get(file, filp->f_dentry);
if (ret < 0)
- goto fail;
+ return ret;
- ret = ftrace_event_call_get(file->event_call);
+ ret = tracing_open_generic(inode, filp);
if (ret < 0)
goto fail;
return 0;
fail:
- trace_array_put(tr);
+ ftrace_event_file_put(file);
return ret;
}
static int tracing_release_generic_file(struct inode *inode, struct file *filp)
{
struct ftrace_event_file *f
Re: [PATCH 0/6] cpufreq: Add 'load_table' debugfs file to show colleced CPUs load
On 9 July 2013 13:27, Chanwoo Choi wrote: > So, I'd like you to review patch1,patch2, patch6. If you with that I resend > patch1/2/6, > I will resend new patchset incluing in patch1/2/6. Yeah, I will do that only. Don't resend anything for now. -- 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: 3.10-rc1: commit ccdfcc398594 broke uClibc build.
Widening the audience...
On Sat, May 18, 2013 at 6:21 AM, Rob Landley wrote:
> The #include added to include/uapi/linux/netlink.h causes
> the uClibc build to go:
>
> In file included from include/linux/kernel.h:4,
> from include/linux/netlink.h:4,
> from include/linux/rtnetlink.h:5,
> from libc/inet/netlinkaccess.h:27,
> from libc/inet/if_index.c:37:
> include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before
> '__kernel_long_t'
> make: *** [libc/inet/if_index.o] Error 1
>
> If I comment out that line, it builds fine. The kernel builds (for my
> config) either way.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/
[v3][PATCH 8/8] book3e/kexec/kdump: recover "r4 = 0" to create the initial TLB
In commit 96f013f, "powerpc/kexec: Add kexec "hold" support for Book3e processors", requires that GPR4 survive the "hold" process, for IBM Blue Gene/Q with with some very strange firmware. But for FSL Book3E, r4 = 1 to indicate that the initial TLB entry for this core already exists so we still should set r4 with 0 to create that initial TLB. Signed-off-by: Tiejun Chen --- arch/powerpc/kernel/head_64.S |4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 0b46c9d..d546c5e 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -127,6 +127,10 @@ __secondary_hold: /* Grab our physical cpu number */ mr r24,r3 /* stash r4 for book3e */ +#ifdef CONFIG_PPC_FSL_BOOK3E + /* we need to setup initial TLB entry. */ + li r4,0 +#endif mr r25,r4 /* Tell the master cpu we're here */ -- 1.7.9.5 -- 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/
[v3][PATCH 7/8] book3e/kexec/kdump: redefine VIRT_PHYS_OFFSET
Book3e is always aligned 1GB to create TLB so we should use (KERNELBASE - MEMORY_START) as VIRT_PHYS_OFFSET to get __pa/__va properly while boot kdump. Signed-off-by: Tiejun Chen --- arch/powerpc/include/asm/page.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index 988c812..5b00081 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -112,6 +112,8 @@ extern long long virt_phys_offset; /* See Description below for VIRT_PHYS_OFFSET */ #ifdef CONFIG_RELOCATABLE_PPC32 #define VIRT_PHYS_OFFSET virt_phys_offset +#elif defined(CONFIG_PPC_BOOK3E_64) +#define VIRT_PHYS_OFFSET (KERNELBASE - MEMORY_START) #else #define VIRT_PHYS_OFFSET (KERNELBASE - PHYSICAL_START) #endif -- 1.7.9.5 -- 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/
[v3][PATCH 1/8] powerpc/book3e: rename interrupt_end_book3e with __end_interrupts
We can rename 'interrupt_end_book3e' with '__end_interrupts' then book3s/book3e can share this unique label to make sure we can use this conveniently. Signed-off-by: Tiejun Chen --- arch/powerpc/kernel/exceptions-64e.S |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 645170a..a518e48 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -309,8 +309,8 @@ interrupt_base_book3e: /* fake trap */ EXCEPTION_STUB(0x300, hypercall) EXCEPTION_STUB(0x320, ehpriv) - .globl interrupt_end_book3e -interrupt_end_book3e: + .globl __end_interrupts +__end_interrupts: /* Critical Input Interrupt */ START_EXCEPTION(critical_input); @@ -493,7 +493,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) beq+1f LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) - LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e) + LOAD_REG_IMMEDIATE(r15,__end_interrupts) cmpld cr0,r10,r14 cmpld cr1,r10,r15 blt+cr0,1f @@ -559,7 +559,7 @@ kernel_dbg_exc: beq+1f LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) - LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e) + LOAD_REG_IMMEDIATE(r15,__end_interrupts) cmpld cr0,r10,r14 cmpld cr1,r10,r15 blt+cr0,1f -- 1.7.9.5 -- 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/
[v3][PATCH 0/8] powerpc/book3e: support kexec and kdump
This patchset is used to support kexec and kdump on book3e. Tested on fsl-p5040 DS. v3: * add one patch to rename interrupt_end_book3e with __end_interrupts then we can have a unique lable for book3e and book3s. * add some comments for "book3e/kexec/kdump: enable kexec for kernel" * clean "book3e/kexec/kdump: introduce a kexec kernel flag" v2: * rebase on merge branch v1: * improve some patch head * rebase on next branch with patch 7 Tiejun Chen (8): powerpc/book3e: rename interrupt_end_book3e with __end_interrupts powerpc/book3e: support CONFIG_RELOCATABLE book3e/kexec/kdump: enable kexec for kernel book3e/kexec/kdump: create a 1:1 TLB mapping book3e/kexec/kdump: introduce a kexec kernel flag book3e/kexec/kdump: implement ppc64 kexec specfic book3e/kexec/kdump: redefine VIRT_PHYS_OFFSET book3e/kexec/kdump: recover "r4 = 0" to create the initial TLB arch/powerpc/Kconfig |2 +- arch/powerpc/include/asm/exception-64e.h | 11 +++ arch/powerpc/include/asm/page.h |2 + arch/powerpc/include/asm/smp.h |1 + arch/powerpc/kernel/exceptions-64e.S | 26 +- arch/powerpc/kernel/head_64.S| 48 +- arch/powerpc/kernel/machine_kexec_64.c | 148 +- arch/powerpc/kernel/misc_64.S| 67 +- arch/powerpc/platforms/85xx/smp.c| 33 ++- 9 files changed, 257 insertions(+), 81 deletions(-) arch/powerpc/kernel/exceptions-64e.S |8 1 file changed, 4 insertions(+), 4 deletions(-) Tiejun -- 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/
[v3][PATCH 6/8] book3e/kexec/kdump: implement ppc64 kexec specfic
ppc64 kexec mechanism has a different implementation with ppc32.
Signed-off-by: Tiejun Chen
---
arch/powerpc/platforms/85xx/smp.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 14d461b..d862808 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -276,6 +276,7 @@ struct smp_ops_t smp_85xx_ops = {
};
#ifdef CONFIG_KEXEC
+#ifdef CONFIG_PPC32
atomic_t kexec_down_cpus = ATOMIC_INIT(0);
void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
@@ -294,6 +295,14 @@ static void mpc85xx_smp_kexec_down(void *arg)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0,1);
}
+#else
+void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
+{
+ local_irq_disable();
+ hard_irq_disable();
+ mpic_teardown_this_cpu(secondary);
+}
+#endif
static void map_and_flush(unsigned long paddr)
{
@@ -345,11 +354,14 @@ static void mpc85xx_smp_flush_dcache_kexec(struct kimage
*image)
static void mpc85xx_smp_machine_kexec(struct kimage *image)
{
+#ifdef CONFIG_PPC32
int timeout = INT_MAX;
int i, num_cpus = num_present_cpus();
+#endif
mpc85xx_smp_flush_dcache_kexec(image);
+#ifdef CONFIG_PPC32
if (image->type == KEXEC_TYPE_DEFAULT)
smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
@@ -367,6 +379,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage *image)
if ( i == smp_processor_id() ) continue;
mpic_reset_core(i);
}
+#endif
default_machine_kexec(image);
}
--
1.7.9.5
--
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/
[v3][PATCH 5/8] book3e/kexec/kdump: introduce a kexec kernel flag
We need to introduce a flag to indicate we're already running
a kexec kernel then we can go proper path. For example, We
shouldn't access spin_table from the bootloader to up any secondary
cpu for kexec kernel, and kexec kernel already know how to jump to
generic_secondary_smp_init.
Signed-off-by: Tiejun Chen
---
arch/powerpc/include/asm/smp.h|1 +
arch/powerpc/kernel/head_64.S | 10 ++
arch/powerpc/kernel/misc_64.S |6 ++
arch/powerpc/platforms/85xx/smp.c | 20 +++-
4 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..59165a3 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -200,6 +200,7 @@ extern void generic_secondary_thread_init(void);
extern unsigned long __secondary_hold_spinloop;
extern unsigned long __secondary_hold_acknowledge;
extern char __secondary_hold;
+extern unsigned long __run_at_kexec;
extern void __early_start(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 7dc56be..0b46c9d 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -89,6 +89,10 @@ __secondary_hold_spinloop:
__secondary_hold_acknowledge:
.llong 0x0
+ .globl __run_at_kexec
+__run_at_kexec:
+ .llong 0x0 /* Flag for the secondary kernel from kexec. */
+
#ifdef CONFIG_RELOCATABLE
/* This flag is set to 1 by a loader if the kernel should run
* at the loaded address instead of the linked address. This
@@ -417,6 +421,12 @@ _STATIC(__after_prom_start)
#if defined(CONFIG_PPC_BOOK3E)
tovirt(r26,r26) /* on booke, we already run at
PAGE_OFFSET */
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_CRASH_DUMP)
+ /* If relocated we need to restore this flag on that relocated address.
*/
+ ld r7,__run_at_kexec-_stext(r26)
+ std r7,__run_at_kexec-_stext(r26)
+#endif
+
lwz r7,__run_at_load-_stext(r26)
#if defined(CONFIG_PPC_BOOK3E)
tophys(r26,r26) /* Restore for the remains. */
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 20cbb98..c89aead 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -619,6 +619,12 @@ _GLOBAL(kexec_sequence)
bl .copy_and_flush /* (dest, src, copy limit, start offset) */
1: /* assume normal blr return */
+ /* notify we're going into kexec kernel for SMP. */
+ LOAD_REG_ADDR(r3,__run_at_kexec)
+ li r4,1
+ std r4,0(r3)
+ sync
+
/* release other cpus to the new kernel secondary start at 0x60 */
mflrr5
li r6,1
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 5ced4f5..14d461b 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -150,6 +150,9 @@ static int smp_85xx_kick_cpu(int nr)
int hw_cpu = get_hard_smp_processor_id(nr);
int ioremappable;
int ret = 0;
+#ifdef CONFIG_PPC64
+ unsigned long *ptr = NULL;
+#endif
WARN_ON(nr < 0 || nr >= NR_CPUS);
WARN_ON(hw_cpu < 0 || hw_cpu >= NR_CPUS);
@@ -238,11 +241,18 @@ out:
#else
smp_generic_kick_cpu(nr);
- flush_spin_table(spin_table);
- out_be32(&spin_table->pir, hw_cpu);
- out_be64((u64 *)(&spin_table->addr_h),
- __pa((u64)*((unsigned long long *)generic_secondary_smp_init)));
- flush_spin_table(spin_table);
+ ptr = (unsigned long *)((unsigned long)&__run_at_kexec);
+ /* We shouldn't access spin_table from the bootloader to up any
+* secondary cpu for kexec kernel, and kexec kernel already
+* know how to jump to generic_secondary_smp_init.
+*/
+ if (!*ptr) {
+ flush_spin_table(spin_table);
+ out_be32(&spin_table->pir, hw_cpu);
+ out_be64((u64 *)(&spin_table->addr_h),
+__pa((u64)*((unsigned long long
*)generic_secondary_smp_init)));
+ flush_spin_table(spin_table);
+ }
#endif
local_irq_restore(flags);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] tracing/kprobe: Wait for disabling all running kprobe handlers
Wait for disabling all running kprobe handlers when a kprobe
event is disabled, since the caller, trace_remove_event_call()
supposes that a removing event is disabled completely by
disabling the event.
With this change, ftrace can ensure that there is no running
event handlers after disabling it.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_kprobe.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7ed6976..a9a4fe5 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -243,11 +243,11 @@ find_event_file_link(struct trace_probe *tp, struct
ftrace_event_file *file)
static int
disable_trace_probe(struct trace_probe *tp, struct ftrace_event_file *file)
{
+ struct event_file_link *link = NULL;
+ int wait = 0;
int ret = 0;
if (file) {
- struct event_file_link *link;
-
link = find_event_file_link(tp, file);
if (!link) {
ret = -EINVAL;
@@ -255,10 +255,7 @@ disable_trace_probe(struct trace_probe *tp, struct
ftrace_event_file *file)
}
list_del_rcu(&link->list);
- /* synchronize with kprobe_trace_func/kretprobe_trace_func */
- synchronize_sched();
- kfree(link);
-
+ wait = 1;
if (!list_empty(&tp->files))
goto out;
@@ -271,8 +268,18 @@ disable_trace_probe(struct trace_probe *tp, struct
ftrace_event_file *file)
disable_kretprobe(&tp->rp);
else
disable_kprobe(&tp->rp.kp);
+ wait = 1;
}
out:
+ if (wait) {
+ /*
+* synchronize with kprobe_trace_func/kretprobe_trace_func
+* to ensure disabled (all running handlers are finished)
+*/
+ synchronize_sched();
+ kfree(link);/* Ignored if link == NULL */
+ }
+
return ret;
}
--
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/
[v3][PATCH 4/8] book3e/kexec/kdump: create a 1:1 TLB mapping
book3e have no real MMU mode so we have to create a 1:1 TLB mapping to make sure we can access the real physical address. And correct something to support this pseudo real mode on book3e. Signed-off-by: Tiejun Chen --- arch/powerpc/kernel/head_64.S |9 --- arch/powerpc/kernel/misc_64.S | 55 - 2 files changed, 60 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 550f8fb..7dc56be 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -447,12 +447,12 @@ _STATIC(__after_prom_start) tovirt(r3,r3) /* on booke, we already run at PAGE_OFFSET */ #endif mr. r4,r26 /* In some cases the loader may */ +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r4,r4) +#endif beq 9f /* have already put us at zero */ li r6,0x100/* Start offset, the first 0x100 */ /* bytes were copied earlier.*/ -#ifdef CONFIG_PPC_BOOK3E - tovirt(r6,r6) /* on booke, we already run at PAGE_OFFSET */ -#endif #ifdef CONFIG_RELOCATABLE /* @@ -495,6 +495,9 @@ _STATIC(__after_prom_start) p_end: .llong _end - _stext 4: /* Now copy the rest of the kernel up to _end */ +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) +#endif addis r5,r26,(p_end - _stext)@ha ld r5,(p_end - _stext)@l(r5) /* get _end */ 5: bl .copy_and_flush /* copy the rest */ diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index f1a7ce7..20cbb98 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -460,6 +460,49 @@ kexec_flag: #ifdef CONFIG_KEXEC +#ifdef CONFIG_PPC_BOOK3E +/* BOOK3E have no a real MMU mode so we have to setup the initial TLB + * for a core to map v:0 to p:0 as 1:1. This current implementation + * assume that 1G is enough for kexec. + */ +#include +kexec_create_tlb: + /* Invalidate all TLBs to avoid any TLB conflict. */ + PPC_TLBILX_ALL(0,R0) + sync + isync + + mfspr r10,SPRN_TLB1CFG + andi. r10,r10,TLBnCFG_N_ENTRY /* Extract # entries */ + subir10,r10,1 /* Often its always safe to use last */ + lis r9,MAS0_TLBSEL(1)@h + rlwimi r9,r10,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r9) */ + +/* Setup a temp mapping v:0 to p:0 as 1:1 and return to it. + */ +#ifdef CONFIG_SMP +#define M_IF_SMP MAS2_M +#else +#define M_IF_SMP 0 +#endif + mtspr SPRN_MAS0,r9 + + lis r9,(MAS1_VALID|MAS1_IPROT)@h + ori r9,r9,(MAS1_TSIZE(BOOK3E_PAGESZ_1GB))@l + mtspr SPRN_MAS1,r9 + + LOAD_REG_IMMEDIATE(r9, 0x0 | M_IF_SMP) + mtspr SPRN_MAS2,r9 + + LOAD_REG_IMMEDIATE(r9, 0x0 | MAS3_SR | MAS3_SW | MAS3_SX) + mtspr SPRN_MAS3,r9 + li r9,0 + mtspr SPRN_MAS7,r9 + + tlbwe + isync + blr +#endif /* kexec_smp_wait(void) * @@ -473,6 +516,10 @@ kexec_flag: */ _GLOBAL(kexec_smp_wait) lhz r3,PACAHWCPUID(r13) +#ifdef CONFIG_PPC_BOOK3E + /* Create a 1:1 mapping. */ + bl kexec_create_tlb +#endif bl real_mode li r4,KEXEC_STATE_REAL_MODE @@ -489,6 +536,7 @@ _GLOBAL(kexec_smp_wait) * don't overwrite r3 here, it is live for kexec_wait above. */ real_mode: /* assume normal blr return */ +#ifndef CONFIG_PPC_BOOK3E 1: li r9,MSR_RI li r10,MSR_DR|MSR_IR mflrr11 /* return address to SRR0 */ @@ -500,7 +548,10 @@ real_mode: /* assume normal blr return */ mtspr SPRN_SRR1,r10 mtspr SPRN_SRR0,r11 rfid - +#else + /* the real mode is nothing for book3e. */ + blr +#endif /* * kexec_sequence(newstack, start, image, control, clear_all()) @@ -549,6 +600,8 @@ _GLOBAL(kexec_sequence) mtmsrd r3,1 #else wrteei 0 + /* Create a 1:1 mapping. */ + bl kexec_create_tlb #endif /* copy dest pages, flush whole dest image */ -- 1.7.9.5 -- 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/
[v3][PATCH 2/8] powerpc/book3e: support CONFIG_RELOCATABLE
book3e is different with book3s since 3s includes the exception vectors code in head_64.S as it relies on absolute addressing which is only possible within this compilation unit. So we have to get that label address with got. And when boot a relocated kernel, we should reset ipvr properly again after .relocate. Signed-off-by: Tiejun Chen --- arch/powerpc/include/asm/exception-64e.h | 11 +++ arch/powerpc/kernel/exceptions-64e.S | 18 +- arch/powerpc/kernel/head_64.S| 25 + 3 files changed, 53 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/exception-64e.h b/arch/powerpc/include/asm/exception-64e.h index 51fa43e..371a77f 100644 --- a/arch/powerpc/include/asm/exception-64e.h +++ b/arch/powerpc/include/asm/exception-64e.h @@ -214,10 +214,21 @@ exc_##label##_book3e: #define TLB_MISS_STATS_SAVE_INFO_BOLTED #endif +#ifndef CONFIG_RELOCATABLE #define SET_IVOR(vector_number, vector_offset) \ li r3,vector_offset@l; \ ori r3,r3,interrupt_base_book3e@l; \ mtspr SPRN_IVOR##vector_number,r3; +#else /* !CONFIG_RELOCATABLE */ +/* In relocatable case the value of the constant expression 'expr' is only + * offset. So instead, we should loads the address of label 'name'. + */ +#define SET_IVOR(vector_number, vector_offset) \ + LOAD_REG_ADDR(r3,interrupt_base_book3e);\ + rlwinm r3,r3,0,15,0; \ + ori r3,r3,vector_offset@l; \ + mtspr SPRN_IVOR##vector_number,r3; +#endif /* CONFIG_RELOCATABLE */ #endif /* _ASM_POWERPC_EXCEPTION_64E_H */ diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index a518e48..be3b4b1 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -1097,7 +1097,15 @@ skpinv: addir6,r6,1 /* Increment */ * r4 = MAS0 w/TLBSEL & ESEL for the temp mapping */ /* Now we branch the new virtual address mapped by this entry */ +#ifdef CONFIG_RELOCATABLE + /* We have to find out address from lr. */ + bl 1f /* Find our address */ +1: mflrr6 + addir6,r6,(2f - 1b) + tovirt(r6,r6) +#else LOAD_REG_IMMEDIATE(r6,2f) +#endif lis r7,MSR_KERNEL@h ori r7,r7,MSR_KERNEL@l mtspr SPRN_SRR0,r6 @@ -1348,9 +1356,17 @@ _GLOBAL(book3e_secondary_thread_init) mflrr28 b 3b -_STATIC(init_core_book3e) +_GLOBAL(init_core_book3e) /* Establish the interrupt vector base */ +#ifdef CONFIG_RELOCATABLE +/* In relocatable case the value of the constant expression 'expr' is only + * offset. So instead, we should loads the address of label 'name'. + */ + tovirt(r2,r2) + LOAD_REG_ADDR(r3, interrupt_base_book3e) +#else LOAD_REG_IMMEDIATE(r3, interrupt_base_book3e) +#endif mtspr SPRN_IVPR,r3 sync blr diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index b61363d..550f8fb 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -414,12 +414,25 @@ _STATIC(__after_prom_start) /* process relocations for the final address of the kernel */ lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */ sldir25,r25,32 +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */ +#endif lwz r7,__run_at_load-_stext(r26) +#if defined(CONFIG_PPC_BOOK3E) + tophys(r26,r26) /* Restore for the remains. */ +#endif cmplwi cr0,r7,1/* flagged to stay where we are ? */ bne 1f add r25,r25,r26 1: mr r3,r25 bl .relocate +#if defined(CONFIG_PPC_BOOK3E) + /* In relocatable case we always have to load the address of label 'name' +* to set IVPR. So after .relocate we have to update IVPR with current +* address of label. +*/ + bl .init_core_book3e +#endif #endif /* @@ -447,12 +460,24 @@ _STATIC(__after_prom_start) * variable __run_at_load, if it is set the kernel is treated as relocatable * kernel, otherwise it will be moved to PHYSICAL_START */ +#if defined(CONFIG_PPC_BOOK3E) + tovirt(r26,r26) /* on booke, we already run at PAGE_OFFSET */ +#endif lwz r7,__run_at_load-_stext(r26) +#if defined(CONFIG_PPC_BOOK3E) + tophys(r26,r26) /* Restore for the remains. */ +#endif cmplwi cr0,r7,1 bne 3f +#ifdef CONFIG_PPC_BOOK3E + LOAD_REG_ADDR(r5, __end_interrupts) + LOAD_REG_ADDR(r11, _stext) + sub r5,r5,r11 +#else /* just copy interrupts */ LOAD_REG_IMMEDIATE(r5, __end_interrupts - _stext) +#endif b 5f 3: #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubs
[PATCH v2 1/2] ARM: dts: STi: Fix pinconf setup for STiH416 serial2
From: Srinivas Kandagatla
This patch fixes a bug in pinctrl setup of serial2 device, Some of the
pins in the pinctrl node of serial2 do not belong to that
pin-controller. This patch divides them in the pins into there
respective pin controller nodes.
Without this patch serial on StiH416-B2000 Board will not work as it
fails with:
"st-pinctrl pin-controller-rear.3: failed to get pin(99) name
st-pinctrl pin-controller-rear.3: maps: function serial2 group serial2-0
num 4
pinconfig core: failed to register map default (3): no group/pin given"
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/stih416-pinctrl.dtsi | 10 +-
arch/arm/boot/dts/stih416.dtsi |2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi
b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index 957b21a..0f246c9 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -166,6 +166,15 @@
reg = <0x9000 0x100>;
st,bank-name= "PIO31";
};
+
+ serial2-oe {
+ pinctrl_serial2_oe: serial2-1 {
+ st,pins {
+ output-enable = <&PIO11 3
ALT2 OUT>;
+ };
+ };
+ };
+
};
pin-controller-rear {
@@ -218,7 +227,6 @@
st,pins {
tx = <&PIO17 4 ALT2 OUT>;
rx = <&PIO17 5 ALT2 IN>;
- output-enable = <&PIO11 3
ALT2 OUT>;
};
};
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 3cecd96..1a0326e 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -79,7 +79,7 @@
interrupts = <0 197 0>;
clocks = <&CLK_S_ICN_REG_0>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_serial2>;
+ pinctrl-0 = <&pinctrl_serial2
&pinctrl_serial2_oe>;
};
/* SBC_UART1 */
--
1.7.6.5
--
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/
[v3][PATCH 3/8] book3e/kexec/kdump: enable kexec for kernel
We need to active KEXEC for book3e and bypass or convert non-book3e stuff
in kexec coverage.
Signed-off-by: Tiejun Chen
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/kernel/machine_kexec_64.c | 148 ++--
arch/powerpc/kernel/misc_64.S |6 ++
3 files changed, 89 insertions(+), 67 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5374776..d945435 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -357,7 +357,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call"
- depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP))
+ depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) || PPC_BOOK3E
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 611acdf..ee153a8 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -30,72 +30,6 @@
#include
#include
-int default_machine_kexec_prepare(struct kimage *image)
-{
- int i;
- unsigned long begin, end; /* limits of segment */
- unsigned long low, high;/* limits of blocked memory range */
- struct device_node *node;
- const unsigned long *basep;
- const unsigned int *sizep;
-
- if (!ppc_md.hpte_clear_all)
- return -ENOENT;
-
- /*
-* Since we use the kernel fault handlers and paging code to
-* handle the virtual mode, we must make sure no destination
-* overlaps kernel static data or bss.
-*/
- for (i = 0; i < image->nr_segments; i++)
- if (image->segment[i].mem < __pa(_end))
- return -ETXTBSY;
-
- /*
-* For non-LPAR, we absolutely can not overwrite the mmu hash
-* table, since we are still using the bolted entries in it to
-* do the copy. Check that here.
-*
-* It is safe if the end is below the start of the blocked
-* region (end <= low), or if the beginning is after the
-* end of the blocked region (begin >= high). Use the
-* boolean identity !(a || b) === (!a && !b).
-*/
- if (htab_address) {
- low = __pa(htab_address);
- high = low + htab_size_bytes;
-
- for (i = 0; i < image->nr_segments; i++) {
- begin = image->segment[i].mem;
- end = begin + image->segment[i].memsz;
-
- if ((begin < high) && (end > low))
- return -ETXTBSY;
- }
- }
-
- /* We also should not overwrite the tce tables */
- for_each_node_by_type(node, "pci") {
- basep = of_get_property(node, "linux,tce-base", NULL);
- sizep = of_get_property(node, "linux,tce-size", NULL);
- if (basep == NULL || sizep == NULL)
- continue;
-
- low = *basep;
- high = low + (*sizep);
-
- for (i = 0; i < image->nr_segments; i++) {
- begin = image->segment[i].mem;
- end = begin + image->segment[i].memsz;
-
- if ((begin < high) && (end > low))
- return -ETXTBSY;
- }
- }
-
- return 0;
-}
-
#define IND_FLAGS (IND_DESTINATION | IND_INDIRECTION | IND_DONE | IND_SOURCE)
static void copy_segments(unsigned long ind)
@@ -367,6 +301,87 @@ void default_machine_kexec(struct kimage *image)
/* NOTREACHED */
}
+#ifdef CONFIG_PPC_BOOK3E
+int default_machine_kexec_prepare(struct kimage *image)
+{
+ int i;
+ /*
+* Since we use the kernel fault handlers and paging code to
+* handle the virtual mode, we must make sure no destination
+* overlaps kernel static data or bss.
+*/
+ for (i = 0; i < image->nr_segments; i++)
+ if (image->segment[i].mem < __pa(_end))
+ return -ETXTBSY;
+ return 0;
+}
+#else /* CONFIG_PPC_BOOK3E */
+int default_machine_kexec_prepare(struct kimage *image)
+{
+ int i;
+ unsigned long begin, end; /* limits of segment */
+ unsigned long low, high;/* limits of blocked memory range */
+ struct device_node *node;
+ const unsigned long *basep;
+ const unsigned int *sizep;
+
+ if (!ppc_md.hpte_clear_all)
+ return -ENOENT;
+
+ /*
+* Since we use the kernel fault handlers and paging code to
+* handle the virtual mode, we must make sure no destination
+* overlaps kernel static data or bss.
+*/
+ for (i = 0; i < image->nr_segments; i++)
+ if (image->segment[i].mem < __pa(_end
Re: [PATCH] perf: Update event buffer tail when overwriting old events
On Tue, Jul 09, 2013 at 03:05:41PM +0800, Yan, Zheng wrote:
> Thank you for your help. I ran the same test, the results for regular case
> are much better. But it still has about 1% overhead, probably because we
> enlarge the ring_buffer structure, make it less cache friendly.
>
> originwith the patch
> AVG1000 1013
> STDEV 13.4 15.0
And this is the !overwrite case, right? I don't suppose you cured the logic
Namhyung Kim pointed out? That should affect the overwrite case I suppose since
it won't switch to perf_event_output_overwrite().
tip/master:
struct ring_buffer {
atomic_t refcount; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct callback_head callback_head;/* 816 */
intnr_pages; /*24 4 */
intoverwrite;/*28 4 */
atomic_t poll; /*32 4 */
/* XXX 4 bytes hole, try to pack */
local_thead; /*40 8 */
local_tnest; /*48 8 */
local_tevents; /*56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
local_twakeup; /*64 8 */
local_tlost; /*72 8 */
long int watermark;/*80 8 */
spinlock_t event_lock; /*8856 */
/* --- cacheline 2 boundary (128 bytes) was 16 bytes ago --- */
struct list_head event_list; /* 14416 */
atomic_t mmap_count; /* 160 4 */
/* XXX 4 bytes hole, try to pack */
long unsigned int mmap_locked; /* 168 8 */
struct user_struct * mmap_user;/* 176 8 */
struct perf_event_mmap_page * user_page; /* 184 8 */
/* --- cacheline 3 boundary (192 bytes) --- */
void * data_pages[0];/* 192 0 */
/* size: 192, cachelines: 3, members: 18 */
/* sum members: 180, holes: 3, sum holes: 12 */
};
tip/master + patch:
struct ring_buffer {
atomic_t refcount; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct callback_head callback_head;/* 816 */
intnr_pages; /*24 4 */
intoverwrite;/*28 4 */
atomic_t poll; /*32 4 */
/* XXX 4 bytes hole, try to pack */
local_ttail; /*40 8 */
local_tnext_tail;/*48 8 */
local_thead; /*56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
local_tnest; /*64 8 */
local_tevents; /*72 8 */
local_twakeup; /*80 8 */
local_tlost; /*88 8 */
long int watermark;/*96 8 */
spinlock_t event_lock; /* 10456 */
/* --- cacheline 2 boundary (128 bytes) was 32 bytes ago --- */
struct list_head event_list; /* 16016 */
atomic_t mmap_count; /* 176 4 */
/* XXX 4 bytes hole, try to pack */
long unsigned int mmap_locked; /* 184 8 */
/* --- cacheline 3 boundary (192 bytes) --- */
struct user_struct * mmap_user;/* 192 8 */
struct perf_event_mmap_page * user_page; /* 200 8 */
void * data_pages[0];/* 208 0 */
/* size: 208, cachelines: 4, members: 20 */
/* sum members: 196, holes: 3, sum holes: 12 */
/* last cacheline: 16 bytes */
};
tip/master + patch^2:
struct ring_buffer {
atomic_t refcount; /* 0 4 */
atomic_t mmap_count; /* 4 4 */
union {
intoverwrite;/* 4 */
struct callback_head callback_head; /* 16 */
}; /* 816 */
intnr_pages; /*24 4 */
atomic_t poll; /*28 4 */
local_
Re: [PATCH] of: match the compatible in the order set by the dts file
于 2013年07月09日 15:51, Sascha Hauer 写道:
On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
于 2013年07月09日 15:05, Sascha Hauer 写道:
Why don't you set the matching order in the driver the way you want it
to be, i.e.:
{ .compatible = "fsl,imx6q-uart", ... },
{ .compatible = "fsl,imx21-uart", ... },
{ .compatible = "fsl,imx1-uart", ... },
yes. i can set it like this.
but this method looks like a ugly workaround.
If a driver has different ways of supporting a single device, then
putting the preferred or most feature rich on top doesn't look very ugly
to me.
this method makes it much _coupled_ between the driver and the dts file.
IMHO, it's an unnecessary _burden_ to the driver programmer:
he should puts the most feature compatible on the top.
it's much graceful if we let the driver programmer be transparent about
this.
thanks
Huang Shijie
--
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 2/2] PCI,pciehp: avoid add a device already exist during pciehp_resume
On Tue, 2013-07-09 at 15:56 +0800, Yijing Wang wrote: > Currently, pciehp_resume will call pciehp_enable_slot() to add > device if there is a device in the slot. But if the device was > present before suspend, it's no necessary to add again. Now in > such case, there is some uncomfortable message like > > pciehp :00:1c.1:pcie04: Device :03:00.0 already exists at > :03:00, cannot hot-add > pciehp :00:1c.1:pcie04: Cannot add device at :03:00 > > This problem was reported by Paul Bolle > The discussion link: http://comments.gmane.org/gmane.linux.kernel.pci/19876 > > We can use PCIe Device Serial Number to identify the device if > device support DSN. > > currently: > 1. slot is empty before suspend, insert card during suspend. > In this case, is safe, pciehp will add device by check adapter > status register in pciehp_resume. > > 2. slot is non empty before suspend, remove card during suspend. > Also be safe, pciehp will remove device by check adapter > status register in pciehp_resume. > > 3. slot is non empty before suspend, remove card during suspend > and insert a new card. > Now pciehp just call pciehp_enable_slot() roughly. We should > remove the old card firstly, then add the new card. > > 4. slot is non empty before suspend, no action during suspend. > We should do nothing in pciehp_resume, but we call > pciehp_enable_slot(), so some uncomfortable messages show like above. > In this case, we can improve it a little by add a guard > if (!list_empty(bus->devices)). Great! I'm currently trying to bisect another problem, but hope to test this patch (and the preceding patch it apparently needs) in a few days. Please feel free to prod me if you think testing is needed but I'm taking to long to report back. Thanks! Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] tracing/kprobe: Wait for disabling all running kprobe handlers
On Tue, Jul 09, 2013 at 05:01:45PM +0900, Masami Hiramatsu wrote:
> + if (wait) {
> + /*
> + * synchronize with kprobe_trace_func/kretprobe_trace_func
> + * to ensure disabled (all running handlers are finished)
> + */
> + synchronize_sched();
> + kfree(link);/* Ignored if link == NULL */
> + }
What's not clear to me from this comment is if we're only waiting for kfree()?
In that case shouldn't we use call_rcu() to free the thing? Or do we need the
sync_sched() for other purposes as well?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PCI: introduce PCIe Device Serial NUmber Capability support
On 07/09/2013 03:55 PM, Yijing Wang wrote:
> Introduce PCIe Ext Capability Device Serial Number support,
> so we can use the unique device serial number to identify
> the physical device. During system suspend, if the PCIe
> device was removed and inserted a new same device, after
> system resume there is no good way to identify it, maybe
> Device Serial Number is a good choice if device support.
Nice idea!
Regards,
Gu
>
> Signed-off-by: Yijing Wang
Reviewed-by: Gu Zheng
> Cc: "Rafael J. Wysocki"
> Cc: Oliver Neukum
> Cc: Paul Bolle
> Cc: Gu Zheng
> Cc: linux-...@vger.kernel.org
> ---
> drivers/pci/pci.c | 33 +
> drivers/pci/pci.h |1 +
> drivers/pci/probe.c |3 +++
> include/linux/pci.h |4
> 4 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e37fea6..d08df2b 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2048,6 +2048,39 @@ void pci_free_cap_save_buffers(struct pci_dev *dev)
> }
>
> /**
> + * pci_get_dsn - get device serial number
> + * @dev: the PCI device
> + * @sn: saved device serial number
> + */
> +void pci_get_dsn(struct pci_dev *dev, u64 *sn)
> +{
> + int pos;
> + u32 lo, hi;
> +
> + if (!pci_is_pcie(dev))
> + goto out;
> +
> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
> + if (!pos)
> + goto out;
> +
> + pci_read_config_dword(dev, pos + 4, &lo);
> + pci_read_config_dword(dev, pos + 8, &hi);
> + *sn = ((u64)hi << 32) | lo;
> + return;
> +
> +out:
> + *sn = 0;
> + return;
> +}
> +EXPORT_SYMBOL(pci_get_dsn);
> +
> +void pci_dsn_init(struct pci_dev *dev)
> +{
> + return pci_get_dsn(dev, &dev->sn);
> +}
> +
> +/**
> * pci_configure_ari - enable or disable ARI forwarding
> * @dev: the PCI device
> *
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 68678ed..f626006 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -202,6 +202,7 @@ int __pci_read_base(struct pci_dev *dev, enum
> pci_bar_type type,
> struct resource *res, unsigned int reg);
> int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type
> *type);
> void pci_configure_ari(struct pci_dev *dev);
> +void pci_dsn_init(struct pci_dev *dev);
>
> /**
> * pci_ari_enabled - query ARI forwarding status
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 46ada5c..d4c6e7e 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1322,6 +1322,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
> /* Power Management */
> pci_pm_init(dev);
>
> + /* Device Serial Number */
> + pci_dsn_init(dev);
> +
> /* Vital Product Data */
> pci_vpd_pci22_init(dev);
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0fd1f15..59cd205 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -342,6 +342,7 @@ struct pci_dev {
> struct list_head msi_list;
> struct kset *msi_kset;
> #endif
> + u64 sn; /* device serieal number, 0 if not support */
> struct pci_vpd *vpd;
> #ifdef CONFIG_PCI_ATS
> union {
> @@ -995,6 +996,9 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
> size_t count, void *buf);
> ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
> void *buf);
> int pci_vpd_truncate(struct pci_dev *dev, size_t size);
>
> +/* Device Serial Number */
> +void pci_get_dsn(struct pci_dev *dev, u64 *sn);
> +
> /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
> resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
> void pci_bus_assign_resources(const struct pci_bus *bus);
--
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: 3.10-rc1: commit ccdfcc398594 broke uClibc build.
On Tue, Jul 9, 2013 at 10:02 AM, Geert Uytterhoeven
wrote:
> Widening the audience...
Do, linux-net is no more...
> On Sat, May 18, 2013 at 6:21 AM, Rob Landley wrote:
>> The #include added to include/uapi/linux/netlink.h causes
>> the uClibc build to go:
>>
>> In file included from include/linux/kernel.h:4,
>> from include/linux/netlink.h:4,
>> from include/linux/rtnetlink.h:5,
>> from libc/inet/netlinkaccess.h:27,
>> from libc/inet/if_index.c:37:
>> include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before
>> '__kernel_long_t'
>> make: *** [libc/inet/if_index.o] Error 1
>>
>> If I comment out that line, it builds fine. The kernel builds (for my
>> config) either way.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/2] perf tools: Make Power7 events available for perf
On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote: > > So something like they have on ARM? > > vince@pandaboard:/sys/bus/event_source/devices$ ls -l > lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 Cortex-A9 -> > ../../../devices/ARMv7 Cortex-A9 > lrwxrwxrwx 1 root root 0 Jul 8 21:57 breakpoint -> > ../../../devices/breakpoint > lrwxrwxrwx 1 root root 0 Jul 8 21:57 software -> ../../../devices/software > lrwxrwxrwx 1 root root 0 Jul 8 21:57 tracepoint -> > ../../../devices/tracepoint Right so what I remember of the ARM case is that their /proc/cpuinfo isn't sufficient to identify their PMU. And they don't have a cpuid like instruction at all. > > For the cpu you can obviously just detect what processor you're on with > > cpuid or whatever, but it's a bit of a hack. And that really doesn't > > work for non-cpu PMUs. > > why is it a hack to use cpuid? I agree, for x86 cpuid is perfectly fine, as would /proc/cpuinfo be, I suspect that just the model number is sufficient in most cases, even for uncore stuff. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] net/fs: change busy poll time accounting
Suggested by Linus:
Changed time accounting for busy-poll:
- Make it microsecond based.
- Use unsigned longs.
- Revert back to use time_after instead of time_in_range.
Reorder poll/select busy loop conditions:
- Clear busy_flag after one time we can't busy-poll.
- Only init busy_end if we actually are going to busy-poll.
Added one more missing need_resched() test.
Signed-off-by: Eliezer Tamir
---
fs/select.c | 31 ++--
include/net/ll_poll.h | 55 +++--
2 files changed, 37 insertions(+), 49 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index 25cac5f..50a804b 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -403,8 +403,7 @@ int do_select(int n, fd_set_bits *fds, struct timespec
*end_time)
int retval, i, timed_out = 0;
unsigned long slack = 0;
unsigned int busy_flag = net_busy_loop_on() ? POLL_BUSY_LOOP : 0;
- u64 busy_start = busy_loop_start_time(busy_flag);
- u64 busy_end = busy_loop_end_time();
+ unsigned long busy_end = 0;
rcu_read_lock();
retval = max_select_fd(n, fds);
@@ -506,9 +505,15 @@ int do_select(int n, fd_set_bits *fds, struct timespec
*end_time)
}
/* only if found POLL_BUSY_LOOP sockets && not out of time */
- if (!need_resched() && can_busy_loop &&
- busy_loop_range(busy_start, busy_end))
- continue;
+ if (can_busy_loop && !need_resched()) {
+ if (!busy_end) {
+ busy_end = busy_loop_end_time();
+ continue;
+ }
+ if (!busy_loop_timeout(busy_end))
+ continue;
+ }
+ busy_flag = 0;
/*
* If this is the first loop and we have a timeout
@@ -780,9 +785,7 @@ static int do_poll(unsigned int nfds, struct poll_list
*list,
int timed_out = 0, count = 0;
unsigned long slack = 0;
unsigned int busy_flag = net_busy_loop_on() ? POLL_BUSY_LOOP : 0;
- u64 busy_start = busy_loop_start_time(busy_flag);
- u64 busy_end = busy_loop_end_time();
-
+ unsigned long busy_end = 0;
/* Optimise the no-wait case */
if (end_time && !end_time->tv_sec && !end_time->tv_nsec) {
@@ -834,9 +837,15 @@ static int do_poll(unsigned int nfds, struct poll_list
*list,
break;
/* only if found POLL_BUSY_LOOP sockets && not out of time */
- if (!need_resched() && can_busy_loop &&
- busy_loop_range(busy_start, busy_end))
- continue;
+ if (can_busy_loop && !need_resched()) {
+ if (!busy_end) {
+ busy_end = busy_loop_end_time();
+ continue;
+ }
+ if (!busy_loop_timeout(busy_end))
+ continue;
+ }
+ busy_flag = 0;
/*
* If this is the first loop and we have a timeout
diff --git a/include/net/ll_poll.h b/include/net/ll_poll.h
index f14dd88..2bacbbf 100644
--- a/include/net/ll_poll.h
+++ b/include/net/ll_poll.h
@@ -47,7 +47,7 @@ static inline bool net_busy_loop_on(void)
* we only care that the average is bounded
*/
#ifdef CONFIG_DEBUG_PREEMPT
-static inline u64 busy_loop_sched_clock(void)
+static inline u64 busy_loop_us_clock(void)
{
u64 rc;
@@ -55,37 +55,24 @@ static inline u64 busy_loop_sched_clock(void)
rc = sched_clock();
preempt_enable_no_resched_notrace();
- return rc;
+ return rc >> 10;
}
#else /* CONFIG_DEBUG_PREEMPT */
-static inline u64 busy_loop_sched_clock(void)
+static inline u64 busy_loop_us_clock(void)
{
- return sched_clock();
+ return sched_clock() >> 10;
}
#endif /* CONFIG_DEBUG_PREEMPT */
-/* we don't mind a ~2.5% imprecision so <<10 instead of *1000
- * sk->sk_ll_usec is a u_int so this can't overflow
- */
-static inline u64 sk_busy_loop_end_time(struct sock *sk)
+static inline unsigned long sk_busy_loop_end_time(struct sock *sk)
{
- return (u64)ACCESS_ONCE(sk->sk_ll_usec) << 10;
+ return busy_loop_us_clock() + ACCESS_ONCE(sk->sk_ll_usec);
}
-/* in poll/select we use the global sysctl_net_ll_poll value
- * only call sched_clock() if enabled
- */
-static inline u64 busy_loop_end_time(void)
-{
- return (u64)ACCESS_ONCE(sysctl_net_ll_poll) << 10;
-}
-
-/* if flag is not set we don't need to know the time
- * so we want to avoid a potentially expensive sched_clock()
- */
-static inline u64 busy_loop_start_time(unsigned int flag)
+/* in poll/select we use the global sysctl_net_ll_poll value */
+static inline unsigned long busy_loop_end_time(void)
{
- return flag ? busy_loop_sched_clock() : 0;
+
confirm your account
Your email has exceeded 2 GB, which was created by our webmaster, you are currently running 2.30GB, you can not send or receive new messages until you confirm your inbox. Complete the form below to verify your account. Complete the form below to confirm your account and email: (1) E-mail: (2) Username: (3) Password: (4) Confirm Password: thank you system administrator -- 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 2/2] PCI,pciehp: avoid add a device already exist during pciehp_resume
>> In this case, we can improve it a little by add a guard >> if (!list_empty(bus->devices)). > > Great! > > I'm currently trying to bisect another problem, but hope to test this > patch (and the preceding patch it apparently needs) in a few days. > Please feel free to prod me if you think testing is needed but I'm > taking to long to report back. Hi Paul, Thank you for helping test. Because I have no machine to test this case, so your test report is very important, it can help us going in the right way to solve this problem. Thanks! Yijing. > > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PCI: introduce PCIe Device Serial NUmber Capability support
On 2013/7/9 16:09, Gu Zheng wrote:
> On 07/09/2013 03:55 PM, Yijing Wang wrote:
>
>> Introduce PCIe Ext Capability Device Serial Number support,
>> so we can use the unique device serial number to identify
>> the physical device. During system suspend, if the PCIe
>> device was removed and inserted a new same device, after
>> system resume there is no good way to identify it, maybe
>> Device Serial Number is a good choice if device support.
>
> Nice idea!
>
> Regards,
> Gu
>
>>
>> Signed-off-by: Yijing Wang
>
>
> Reviewed-by: Gu Zheng
Thanks very much!
Yijing.
>
>> Cc: "Rafael J. Wysocki"
>> Cc: Oliver Neukum
>> Cc: Paul Bolle
>> Cc: Gu Zheng
>> Cc: linux-...@vger.kernel.org
>> ---
>> drivers/pci/pci.c | 33 +
>> drivers/pci/pci.h |1 +
>> drivers/pci/probe.c |3 +++
>> include/linux/pci.h |4
>> 4 files changed, 41 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index e37fea6..d08df2b 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -2048,6 +2048,39 @@ void pci_free_cap_save_buffers(struct pci_dev *dev)
>> }
>>
>> /**
>> + * pci_get_dsn - get device serial number
>> + * @dev: the PCI device
>> + * @sn: saved device serial number
>> + */
>> +void pci_get_dsn(struct pci_dev *dev, u64 *sn)
>> +{
>> +int pos;
>> +u32 lo, hi;
>> +
>> +if (!pci_is_pcie(dev))
>> +goto out;
>> +
>> +pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
>> +if (!pos)
>> +goto out;
>> +
>> +pci_read_config_dword(dev, pos + 4, &lo);
>> +pci_read_config_dword(dev, pos + 8, &hi);
>> +*sn = ((u64)hi << 32) | lo;
>> +return;
>> +
>> +out:
>> +*sn = 0;
>> +return;
>> +}
>> +EXPORT_SYMBOL(pci_get_dsn);
>> +
>> +void pci_dsn_init(struct pci_dev *dev)
>> +{
>> +return pci_get_dsn(dev, &dev->sn);
>> +}
>> +
>> +/**
>> * pci_configure_ari - enable or disable ARI forwarding
>> * @dev: the PCI device
>> *
>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> index 68678ed..f626006 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
>> @@ -202,6 +202,7 @@ int __pci_read_base(struct pci_dev *dev, enum
>> pci_bar_type type,
>> struct resource *res, unsigned int reg);
>> int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type
>> *type);
>> void pci_configure_ari(struct pci_dev *dev);
>> +void pci_dsn_init(struct pci_dev *dev);
>>
>> /**
>> * pci_ari_enabled - query ARI forwarding status
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 46ada5c..d4c6e7e 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1322,6 +1322,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
>> /* Power Management */
>> pci_pm_init(dev);
>>
>> +/* Device Serial Number */
>> +pci_dsn_init(dev);
>> +
>> /* Vital Product Data */
>> pci_vpd_pci22_init(dev);
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 0fd1f15..59cd205 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -342,6 +342,7 @@ struct pci_dev {
>> struct list_head msi_list;
>> struct kset *msi_kset;
>> #endif
>> +u64 sn; /* device serieal number, 0 if not support */
>> struct pci_vpd *vpd;
>> #ifdef CONFIG_PCI_ATS
>> union {
>> @@ -995,6 +996,9 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
>> size_t count, void *buf);
>> ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
>> void *buf);
>> int pci_vpd_truncate(struct pci_dev *dev, size_t size);
>>
>> +/* Device Serial Number */
>> +void pci_get_dsn(struct pci_dev *dev, u64 *sn);
>> +
>> /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
>> resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
>> void pci_bus_assign_resources(const struct pci_bus *bus);
>
>
>
> .
>
--
Thanks!
Yijing
--
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: [RFC PATCH] tracing/kprobe: Wait for disabling all running kprobe handlers
(2013/07/09 17:07), Peter Zijlstra wrote:
> On Tue, Jul 09, 2013 at 05:01:45PM +0900, Masami Hiramatsu wrote:
>> +if (wait) {
>> +/*
>> + * synchronize with kprobe_trace_func/kretprobe_trace_func
>> + * to ensure disabled (all running handlers are finished)
>> + */
>> +synchronize_sched();
>> +kfree(link);/* Ignored if link == NULL */
>> +}
>
> What's not clear to me from this comment is if we're only waiting for kfree()?
> In that case shouldn't we use call_rcu() to free the thing? Or do we need the
> sync_sched() for other purposes as well?
No, this is not only for kfree, but also to ensure completing
disabling process, because trace_remove_event_call() supposes
that for releasing event_call related objects (Those objects
will be accessed in the handlers).
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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 1/5] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
2013/7/8 Mark Brown : > On Mon, Jul 08, 2013 at 03:29:49PM +0200, Richard Genoud wrote: > >> + * Nicolas Ferre >> + * >> + * Based on sam9g20_wm8731.c by: >> + * Sedji Gaouaou > > The obvious question here is of course if we can use the same driver for > both of them. I haven't got a g20 to test that, but that's the goal. For now, g20 is still non-DT, so I think it's best to have a DT-only driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35, 9x25). When the g20 will move to DT completely, we can drop sam9g20_wm8731.c and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems) By the way, maybe g45 could use that also (and SAMA5 ?) > >> + codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 | >> + SNDRV_PCM_RATE_32000 | >> + SNDRV_PCM_RATE_48000 | >> + SNDRV_PCM_RATE_96000; >> + codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 | >> + SNDRV_PCM_RATE_32000 | >> + SNDRV_PCM_RATE_48000 | >> + SNDRV_PCM_RATE_96000; > > You definitely shouldn't be fiddling with a driver's constant static > data. You want to be using snd_pcm_hw_constraint() APIs to set > additional constraints intead. Ok, I'll change that. Thanks ! -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- 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: [RFC PATCH] tracing/kprobe: Wait for disabling all running kprobe handlers
On Tue, Jul 09, 2013 at 05:20:17PM +0900, Masami Hiramatsu wrote:
> (2013/07/09 17:07), Peter Zijlstra wrote:
> > On Tue, Jul 09, 2013 at 05:01:45PM +0900, Masami Hiramatsu wrote:
> >> + if (wait) {
> >> + /*
> >> + * synchronize with kprobe_trace_func/kretprobe_trace_func
> >> + * to ensure disabled (all running handlers are finished)
> >> + */
> >> + synchronize_sched();
> >> + kfree(link);/* Ignored if link == NULL */
> >> + }
> >
> > What's not clear to me from this comment is if we're only waiting for
> > kfree()?
> > In that case shouldn't we use call_rcu() to free the thing? Or do we need
> > the
> > sync_sched() for other purposes as well?
>
> No, this is not only for kfree, but also to ensure completing
> disabling process, because trace_remove_event_call() supposes
> that for releasing event_call related objects (Those objects
> will be accessed in the handlers).
Then may I kindly suggest you clarify this in the comment? :-)
--
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] Documentation: Fix references to defunct linux-...@vger.kernel.org
linux-...@vger.kernel.org was replaced by net...@oss.sgi.com was replaced by net...@vger.kernel.org. Signed-off-by: Geert Uytterhoeven --- Documentation/networking/arcnet.txt |7 --- Documentation/networking/vortex.txt |2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt index 9ff5795..aff97f4 100644 --- a/Documentation/networking/arcnet.txt +++ b/Documentation/networking/arcnet.txt @@ -70,9 +70,10 @@ list, mail to linux-arc...@tichy.ch.uj.edu.pl. There are archives of the mailing list at: http://epistolary.org/mailman/listinfo.cgi/arcnet -The people on linux-...@vger.kernel.org have also been known to be very -helpful, especially when we're talking about ALPHA Linux kernels that may or -may not work right in the first place. +The people on linux-...@vger.kernel.org (now defunct, replaced by +net...@vger.kernel.org) have also been known to be very helpful, especially +when we're talking about ALPHA Linux kernels that may or may not work right +in the first place. Other Drivers and Info diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index b4038ff..9a8041d 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -359,7 +359,7 @@ steps you should take: - OK, it's a driver problem. You need to generate a report. Typically this is an email to the - maintainer and/or linux-...@vger.kernel.org. The maintainer's + maintainer and/or net...@vger.kernel.org. The maintainer's email address will be in the driver source or in the MAINTAINERS file. - The contents of your report will vary a lot depending upon the -- 1.7.9.5 -- 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/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
2013/7/8 Mark Brown : > On Mon, Jul 08, 2013 at 03:29:50PM +0200, Richard Genoud wrote: >> Signed-off-by: Richard Genoud >> --- >> arch/arm/boot/dts/at91sam9x5.dtsi |3 +++ > > There was no binding document in your first patch - there should be one > for any new DT bindings. The dma binding is documented here Documentation/devicetree/bindings/dma/atmel-dma.txt But you're right, I shoud update Documentation/devicetree/bindings/misc/atmel-ssc.txt. Thanks -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- 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 RFC] fsio: filesystem io accounting cgroup
Tejun Heo wrote: Hello, Vivek. On Mon, Jul 08, 2013 at 01:52:01PM -0400, Vivek Goyal wrote: Again, a problem to be fixed in the stack rather than patching up from up above. The right thing to do is to propagate pressure through bdi properly and let whatever is backing the bdi generate appropriate amount of pressure, be that disk or network. Ok, so use network controller for controlling IO rate on NFS? I had tried it once and it did not work. I think it had problems related to losing the context info as IO propagated through the stack. So we will have to fix that too. But that's a similar problem we have with blkcg anyway - losing the dirtier information by the time writeback comes down through bdi. It might not be exactly the same and might need some impedance matching on the network side but I don't see any fundamental differences. Thanks. Yep, blkio has plenty problems and flaws and I don't get how it's related to vfs layer, dirty set control and non-disk or network backed filesystems. Any problem can be fixed by introducing new abstract layer, except too many abstraction levels. Cgroup is pluggable subsystem, blkio has it's own plugins and it's build on top of io scheduler plugin. All this stuff always have worked with block devices. Now you suggest to handle all filesystems in this stack. I think binding them to unrealated cgroup is rough leveling violation. NFS cannot be controlled only by network throttlers because we cannot slow down writeback process when it happens, we must slow down tasks who generates dirty memory. Plus it's close to impossible to separate several workloads if they share one NFS sb. -- 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: Suspect loop in dmi_scan_machine()
Hi Ben, Le Monday 08 July 2013 à 17:33 +0100, Ben Hutchings a écrit : > On Mon, Jul 08, 2013 at 05:49:14PM +0200, Jean Delvare wrote: > > I am looking at this commit of yours: > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=79bae42d51a5d498500c890c19ef76df41d2bf59 > > > > and am a little worried about the for loop in dmi_scan_machine() > > (non-EFI case): > [...] > > I don't see any of the bugs you describe. Let me explain what > I probably should have put in a comment: > > We want to find a DMI header at [0xf, 0x0] and possibly an > SMBIOS header 16 bytes before that. buf contains a copy of the 32 > bytes centred at p. On the first iteration p - 16 is out of range, so > the first 16 bytes of the buffer are filled with zeroes. > > Does that address your concerns? If not then please explain precisely > how this loop can go wrong. Wow. I'm not sure what I was up to yesterday evening but I definitely should have waited a bit before posting. I read your code again this morning and it is completely correct, and the concerns I raised yesterday were plain crap. I suppose your code was too smart for my tired brain... Sorry for the noise, -- Jean Delvare Suse L3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/cadence/macb: fix bug/typo in extracting gem_irq_read_clear bit
Signed-off-by: Jongsung Kim
---
drivers/net/ethernet/cadence/macb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index c89aa41..b4e0dc8 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1070,7 +1070,7 @@ static void macb_configure_dma(struct macb *bp)
static void macb_configure_caps(struct macb *bp)
{
if (macb_is_gem(bp)) {
- if (GEM_BF(IRQCOR, gem_readl(bp, DCFG1)) == 0)
+ if (GEM_BFEXT(IRQCOR, gem_readl(bp, DCFG1)) == 0)
bp->caps |= MACB_CAPS_ISR_CLEAR_ON_WRITE;
}
}
--
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 1/2] i2c-designware: make *CNT values configurable
On Mon, Jul 08, 2013 at 03:42:17PM +0200, Christian Ruppert wrote: > On Mon, Jul 08, 2013 at 02:45:26PM +0300, Mika Westerberg wrote: > > The DesignWare I2C controller has high count (HCNT) and low count (LCNT) > > registers for each of the I2C speed modes (standard and fast). These > > registers are programmed based on the input clock speed in the driver. > > > > However, that is not always the most accurate way. For example on Intel > > BayTrail we have 100MHz input clock and calculated *CNT values result as > > measured by one of our team: > > > > Standard mode: 100.25kHz > > Fast mode: 315.41kHZ > > > > The fast mode speed is over 20% lower than what is expected. > > We have observed similar issues and I am wondering if this effect is due > to the overly-pessimistic formulas in i2c_dw_scl_lcnt and > i2c_dw_scl_hcnt. The comments in these functions are a bit confusing and > I don't pretend having fully understood what the intention is. I'm > having the impression that defining the arguments tf in function of the > hardware would be the "correct" way to achieve better clock accuracy. Well, that's not the only timing parameter specified in the I2C spec. We also have tr among other things (even though the dw driver doesn't use it). > > It might be > > that there are things like strenght of the pull-up resistors, bus > > capacitance etc. that are very platform specific and have an effect on the > > clock signal. > > I believe tf is supposed to model these things. I just haven't clearly > understood how. In my understanding, transition times should be > subtracted rather than added to cycle times or am I getting something > fundamentally wrong here? I'm not sure, honestly :-) I believe tf is the same tf that is in the I2C spec, meaning fall time of both SCL and SDA signals and the spec measures one clock cycle to be from end of the first tf to the end of the second (fig. 27 in the I2C spec). If I'm reading it right then it means adding instead of substracting. Do you have any suggestions how we could use tf here? At least on Intel hardware we have an ACPI method that returns directly the optimum *CNT values. -- 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 1/5] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
Hi Richard, On 7/9/2013 16:19, Richard Genoud wrote: 2013/7/8 Mark Brown : On Mon, Jul 08, 2013 at 03:29:49PM +0200, Richard Genoud wrote: + * Nicolas Ferre + * + * Based on sam9g20_wm8731.c by: + * Sedji Gaouaou The obvious question here is of course if we can use the same driver for both of them. I haven't got a g20 to test that, but that's the goal. For now, g20 is still non-DT, so I think it's best to have a DT-only driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35, 9x25). When the g20 will move to DT completely, we can drop sam9g20_wm8731.c and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems) The at91sam9g20ek board can work in DT mode, and the sound has support in DT mode already. Sure, the mainly thing we need deal with is the master clock and widgets. If put them together will make code ugly or need many many #ifdef, I suggest to keep them separately. By the way, maybe g45 could use that also (and SAMA5 ?) For g45ek board, it use AC97 interface, not the case. + codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 | + SNDRV_PCM_RATE_32000 | + SNDRV_PCM_RATE_48000 | + SNDRV_PCM_RATE_96000; + codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 | + SNDRV_PCM_RATE_32000 | + SNDRV_PCM_RATE_48000 | + SNDRV_PCM_RATE_96000; You definitely shouldn't be fiddling with a driver's constant static data. You want to be using snd_pcm_hw_constraint() APIs to set additional constraints intead. Ok, I'll change that. Thanks ! 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/
[PATCH] Fix refcount leak in tty_port.c
Hello,
In linux 3.10 in the file drivers/tty/tty_port.c the function
tty_port_tty_hangup may leak a tty reference:
struct tty_struct *tty = tty_port_tty_get(port);
if (tty && (!check_clocal || !C_CLOCAL(tty))) {
tty_hangup(tty);
tty_kref_put(tty);
}
If tty != NULL and the second condition is false we never call tty_kref_put and
the reference is leaked.
Fix by nesting two if statements.
Signed-off-by: Gianluca Anzolin
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 121aeb9..2198f7d 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -256,8 +256,9 @@ void tty_port_tty_hangup(struct tty_port *port, bool check_clocal)
{
struct tty_struct *tty = tty_port_tty_get(port);
- if (tty && (!check_clocal || !C_CLOCAL(tty))) {
- tty_hangup(tty);
+ if (tty) {
+ if (!check_clocal || !C_CLOCAL(tty))
+ tty_hangup(tty);
tty_kref_put(tty);
}
}
Re: dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitly
On Tue, Jul 9, 2013 at 1:33 PM, Takashi Iwai wrote: > At Tue, 9 Jul 2013 11:15:20 +0800, > Ming Lei wrote: >> >> On Mon, Jul 8, 2013 at 5:05 PM, Takashi Iwai wrote: >> > At Sat, 6 Jul 2013 15:30:03 -0700, >> > Greg KH wrote: >> >> >> >> On Sat, Jul 06, 2013 at 06:14:01PM -0400, Dave Jones wrote: >> >> > On Tue, Jul 02, 2013 at 07:27:49PM +, Linux Kernel wrote: >> >> > > Gitweb: >> >> > http://git.kernel.org/linus/;a=commit;h=d05c39ea67f5786a549ac9d672d2951992b658c6 >> >> > > Commit: d05c39ea67f5786a549ac9d672d2951992b658c6 >> >> > > Parent: a3b2c8c7aa1ca860edcf0b0afa371d9eb2269c3c >> >> > > Author: Takashi Iwai >> >> > > AuthorDate: Wed May 22 18:28:37 2013 +0200 >> >> > > Committer: Greg Kroah-Hartman >> >> > > CommitDate: Mon Jun 3 13:57:29 2013 -0700 >> >> > > >> >> > > dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitly >> >> > > >> >> > > The usermode helper is mandatory for this driver. >> >> > > >> >> > > Signed-off-by: Takashi Iwai >> >> > > Signed-off-by: Greg Kroah-Hartman >> >> > > --- >> >> > > drivers/firmware/Kconfig |1 + >> >> > > 1 files changed, 1 insertions(+), 0 deletions(-) >> >> > > >> >> > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig >> >> > > index 9387630..0747872 100644 >> >> > > --- a/drivers/firmware/Kconfig >> >> > > +++ b/drivers/firmware/Kconfig >> >> > > @@ -64,6 +64,7 @@ config DELL_RBU >> >> > > tristate "BIOS update support for DELL systems via sysfs" >> >> > > depends on X86 >> >> > > select FW_LOADER >> >> > > +select FW_LOADER_USER_HELPER >> >> > > help >> >> > > Say m if you want to have the option of updating the BIOS >> >> > for your >> >> > > DELL system. Note you need a Dell OpenManage or Dell >> >> > Update package (DUP) >> >> > >> >> > >> >> > This is pretty crappy. Now every distro kernel has to have that enabled, >> >> > which screws up for eg, the x86 microcode driver. (It takes 1 minute >> >> > per cpu >> >> > when this is enabled). >> >> >> >> I'll let you and Takashi battle this one out, for some reason I thought >> >> he added it _because_ a distro kernel needed it... >> > >> > The reason is that dell_rbu driver requires it. Without the kconfig >> > option, this driver won't work at all. So, it's a right fix for >> > dell_rbu. >> > >> > AFAIK, the consensus in the kernel side is that this too long fw >> > loading time is basically a regression of user-space (udev or >> > whatever). There is no change in the kernel behavior. The problem >> > must exist even with the older kernels. >> > >> > But, looking at the development, we can't expect that udev will be >> > fixed soon, and this breakage persists already way too long. Maybe a >> > better solution is to kill the fallback to udev for normal f/w loading >> > (i.e. for distro kernels). >> > >> > The patch below is an untested quick hack. It adds a new Kconfig and >> > a new function request_firmware_via_user_helper(). Distro kernels may >> > set CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n for avoiding 60 seconds >> >> I understand your proposed approach is basically equal to unset DELL_RBU, >> don't I? >> >> Actually if DELL_RBU is set, FW_LOADER_USER_HELPER is still set, and >> it won't avoid the fallback to loading from userspace. > > No, it changes the behavior. The fallback is now checked explicitly > via #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK (this is the only > place where this kconfig is referred to). The patch isn't great and > can be rewritten better, but the idea is to split the fallback > behavior (for normal drivers) and the firmware loading that mandates > the user-mode helper (for dell_rbu). Right, sorry for missing that. > > >> > stall for non-existing firmware file access -- as distributions know >> > that the firmware files should be placed in the right path. >> > >> > Thoughts? >> >> I suggest not to introduce new config options in firmware loader any more, >> and the current options are too many already and it is very easy to trigger >> build problem, and introduce extra complexity to users at the same time. > > Yeah, I hate adding a new kconfig, too. But, in this case, I couldn't > have other idea for solving in a reasonable amount of change. One approach I thought of is to introduce request_firmware_user() which should be used only in FW_ACTION_NOHOTPLUG situation, but allows CONFIG_FW_LOADER_USER_HELPER disabled. Actually from view of distribution, dell rbu has to be compiled in, then no code size can be saved any more, which means looks the introduced option in this patch isn't necessary. > >> About Dave's problem, I think distribution may not trigger it since >> cpu microcode >> should exist, > > It doesn't have to exist -- imagine a brand new CPU that is shipped > without errata (I guess it's the case Dave hit). Yes, I mean other drivers(or most of drivers) may have not the situation to be afrai
[PATCH v2] btusb: fix wrong use of PTR_ERR()
PTR_ERR() returns a signed long type value which is limited by IS_ERR(),
it must be a negative number and bigger than -MAX_ERRNO(-4095).
The bug here, btusb_setup_intel_patching()'s return value might come
from -PTR_ERR() which must be a positive number, we can't judge if it's
an error by "if (ret < 0)", the wrong use here leads to failure as
below, even panic.
Error log:
[ 12.958920] Bluetooth: hci0 command 0xfc8e tx timeout
[ 14.961765] Bluetooth: hci0 command 0xfc8e tx timeout
[ 16.964688] Bluetooth: hci0 command 0xfc8e tx timeout
[ 20.954501] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 22.957358] Bluetooth: hci0 command 0xfc8e tx timeout
[ 30.948922] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 32.951780] Bluetooth: hci0 command 0xfc8e tx timeout
[ 40.943359] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 42.946219] Bluetooth: hci0 command 0xfc8e tx timeout
[ 50.937812] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 52.940670] Bluetooth: hci0 command 0xfc8e tx timeout
[ 60.932236] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 62.935092] Bluetooth: hci0 command 0xfc8e tx timeout
[ 70.926688] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 72.929545] Bluetooth: hci0 command 0xfc8e tx timeout
[ 80.92] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed
(-110)
[ 82.923969] Bluetooth: hci0 command 0xfc2f tx timeout
[ 90.915542] Bluetooth: hci0 sending Intel patch command (0xfc2f) failed
(-110)
[ 92.918406] Bluetooth: hci0 command 0xfc11 tx timeout
[ 100.909955] Bluetooth: hci0 sending Intel patch command (0xfc11) failed
(-110)
[ 102.912858] Bluetooth: hci0 command 0xfc60 tx timeout
[ 110.904394] Bluetooth: hci0 sending Intel patch command (0xfc60) failed
(-110)
[ 112.907293] Bluetooth: hci0 command 0xfc11 tx timeout
[ 120.898831] Bluetooth: hci0 exiting Intel manufacturer mode failed (-110)
[ 120.904757] bluetoothd[1030]: segfault at 4 ip 7f8b2eb55236 sp
7fff53ff6920 error 4 in bluetoothd[7f8b2eaff000+cb000]
Signed-off-by: Adam Lee
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7a7e5f8..05a38a2 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1256,7 +1256,7 @@ static int btusb_setup_intel(struct hci_dev *hdev)
ret = btusb_setup_intel_patching(hdev, fw, &fw_ptr,
&disable_patch);
- if (ret < 0)
+ if (!ret)
goto exit_mfg_deactivate;
}
--
1.8.3.2
#include
#define MAX_ERRNO 4095
#define IS_ERR_VALUE(x) ((x) >= (unsigned long)-MAX_ERRNO)
static inline long IS_ERR(const void *ptr)
{
return IS_ERR_VALUE((unsigned long)ptr);
}
static inline long PTR_ERR(const void *ptr)
{
return (long) ptr;
}
int main(int argc, const char *argv[])
{
void *ptr = (void *)-1;
printf("ptr = %p, -PTR_ERR(ptr) = %ld\n\n", ptr, -PTR_ERR(ptr));
if(IS_ERR(ptr)) {
if (-PTR_ERR(ptr) < 0)
printf("That's what the codes want.\n");
else
printf("Bug happens!\n");
}
return 0;
}
Re: [RFC PATCH] tracing/kprobe: Wait for disabling all running kprobe handlers
(2013/07/09 17:21), Peter Zijlstra wrote:
> On Tue, Jul 09, 2013 at 05:20:17PM +0900, Masami Hiramatsu wrote:
>> (2013/07/09 17:07), Peter Zijlstra wrote:
>>> On Tue, Jul 09, 2013 at 05:01:45PM +0900, Masami Hiramatsu wrote:
+ if (wait) {
+ /*
+ * synchronize with kprobe_trace_func/kretprobe_trace_func
+ * to ensure disabled (all running handlers are finished)
+ */
+ synchronize_sched();
+ kfree(link);/* Ignored if link == NULL */
+ }
>>>
>>> What's not clear to me from this comment is if we're only waiting for
>>> kfree()?
>>> In that case shouldn't we use call_rcu() to free the thing? Or do we need
>>> the
>>> sync_sched() for other purposes as well?
>>
>> No, this is not only for kfree, but also to ensure completing
>> disabling process, because trace_remove_event_call() supposes
>> that for releasing event_call related objects (Those objects
>> will be accessed in the handlers).
>
> Then may I kindly suggest you clarify this in the comment? :-)
>
Ah, right! I'll update it :)
Thank you!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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 0/4] Minor perf build fixes
Hi Namhyung, Namhyung Kim wrote: > On Fri, 5 Jul 2013 15:46:13 +0530, Ramkumar Ramachandra wrote: >> [3/4] introduces a util/perf-perl.h to include with #pragma >> statements, hence eliminating duplication. It then updates Context.xs >> and trace-event-perl.c to use this new header. > > I prefer the name being "perl.h" and use #include_next as we include the > 'util' directory in the compiler search path. > > Other than that, the change looks good to me. Thanks for teaching me about #include_next. I'll post a re-roll shortly. >> Also, notice that feature-tests.mak has not been touched in this >> iteration: the Perl check passes without needing the #pragma >> statements (although I'm not sure why exactly). > > I guess it's because FLAGS_PERL_EMBED doesn't contain the usual perf > CFLAGS which has -Werror. Ah. -- 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: [Resend patch v8 0/13] use runnable load in schedule balance
On 06/29/2013 12:00 AM, Paul Turner wrote: > On Fri, Jun 28, 2013 at 6:20 AM, Alex Shi wrote: >> >>> So this is actually an interesting idea, but don't think of it as >>> overweight. What "cfs_rq->blocked_load_avg / 2" means is actually >>> blocked_load_avg one period from now. This is interesting because it >>> makes the (reasonable) supposition that blocked load is not about to >>> immediately wake, but will continue to decay. >>> >>> Could you try testing the gvr_lb_tip branch at >>> git://git.kernel.org/pub/scm/linux/kernel/git/pjt/sched-tip.git ? >>> >> >> Could you rebase the patch on latest tip/sched/core? > > I suspect it's more direct to just check out and test the branch > directly (e.g. you should not need to apply it on top of any other > branch). It should be based on round-about where you previously > tested. I tested aim7, hackbench, tbench, dbench, on NHM EP, SNB EP 2S/4S and IVB EP. Comparing to Alex's rlbv8(same as upstream except no blocked_load_avg on tg), -- both base on 3.9.0 kernel. aim7 drops about 10% on SNB EP 2S/4S, hackbench drops 10% on SNB EP 4S. drops 1~5% on other 2 sockets NHM EP/IVB EP/SNB EP. tbench/dbench failed due to a bug commit you had dependent on. but it was fixed on upstream kernel. --- Running for 600 seconds with load '/usr/local/share/client.txt' and minimum warmup 120 secs failed to create barrier semaphore. > >> >>> >>> It's an extension to your series that tries to improve some of the >>> cpu_load interactions in an alternate way to the above. >>> >>> It seems a little better on one and two-socket machines; but we >>> couldn't reproduce/compare to your best performance results since they >>> were taken on larger machines. >>> -- Thanks Alex -- 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: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for lm90
On 07/09/2013 03:55 PM, Jean Delvare wrote: > On Tue, 9 Jul 2013 15:48:40 +0800, Wei Ni wrote: >> On 07/09/2013 02:21 PM, Thierry Reding wrote: >>> It should work out of the box. As a matter of fact the same chip is used >>> on Tamonten and the DTS files use "onnn,nct1008". That used to work. If >>> it no longer does then that's a regression. >> >> I synced the linux-next from: >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git >> and use the tag v3.10-rc7, but in the lm90.c it doesn't have DT support, >> such as "onnn,nct1008". >> I googled it and found there has patch: >> [PATCH] hwmon: (lm90) Add device tree support , which is in: >> http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038099.html >> , but it didn't be merged into the linux-next. > > It was not, because of the next reply in the same thread: > http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038100.html > >> which git repository and branch should I use ? > > It is supposed to just work. What doesn't work for you exactly? > Oh, yes, the "onnn,nct1008" can work. I read the i2c driver and the of_i2c.c carefully, I understand why the lm90 can be loaded by setting "onnn,nct1008". Indeed, we can set the vendor string to anything, even "xxx,nct1008", the lm90 also can be loaded correctly. Anyway, I will use the "onnn,nct1008" in my next version. Thanks for your comments. Wei. -- 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 RFC V9 0/19] Paravirtualized ticket spinlocks
On 06/26/2013 11:24 PM, Raghavendra K T wrote: On 06/26/2013 09:41 PM, Gleb Natapov wrote: On Wed, Jun 26, 2013 at 07:10:21PM +0530, Raghavendra K T wrote: On 06/26/2013 06:22 PM, Gleb Natapov wrote: On Wed, Jun 26, 2013 at 01:37:45PM +0200, Andrew Jones wrote: On Wed, Jun 26, 2013 at 02:15:26PM +0530, Raghavendra K T wrote: On 06/25/2013 08:20 PM, Andrew Theurer wrote: On Sun, 2013-06-02 at 00:51 +0530, Raghavendra K T wrote: This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit path to use PLE handler V8 of PVspinlock was posted last year. After Avi's suggestions to look at PLE handler's improvements, various optimizations in PLE handling have been tried. Sorry for not posting this sooner. I have tested the v9 pv-ticketlock patches in 1x and 2x over-commit with 10-vcpu and 20-vcpu VMs. I have tested these patches with and without PLE, as PLE is still not scalable with large VMs. Hi Andrew, Thanks for testing. System: x3850X5, 40 cores, 80 threads 1x over-commit with 10-vCPU VMs (8 VMs) all running dbench: -- Total ConfigurationThroughput(MB/s)Notes 3.10-default-ple_on229455% CPU in host kernel, 2% spin_lock in guests 3.10-default-ple_off231845% CPU in host kernel, 2% spin_lock in guests 3.10-pvticket-ple_on228955% CPU in host kernel, 2% spin_lock in guests 3.10-pvticket-ple_off230515% CPU in host kernel, 2% spin_lock in guests [all 1x results look good here] Yes. The 1x results look too close 2x over-commit with 10-vCPU VMs (16 VMs) all running dbench: --- Total ConfigurationThroughputNotes 3.10-default-ple_on 628755% CPU host kernel, 17% spin_lock in guests 3.10-default-ple_off 18492% CPU in host kernel, 95% spin_lock in guests 3.10-pvticket-ple_on 669150% CPU in host kernel, 15% spin_lock in guests 3.10-pvticket-ple_off164648% CPU in host kernel, 33% spin_lock in guests I see 6.426% improvement with ple_on and 161.87% improvement with ple_off. I think this is a very good sign for the patches [PLE hinders pv-ticket improvements, but even with PLE off, we still off from ideal throughput (somewhere >2)] Okay, The ideal throughput you are referring is getting around atleast 80% of 1x throughput for over-commit. Yes we are still far away from there. 1x over-commit with 20-vCPU VMs (4 VMs) all running dbench: -- Total ConfigurationThroughputNotes 3.10-default-ple_on227366% CPU in host kernel, 3% spin_lock in guests 3.10-default-ple_off233775% CPU in host kernel, 3% spin_lock in guests 3.10-pvticket-ple_on224716% CPU in host kernel, 3% spin_lock in guests 3.10-pvticket-ple_off234455% CPU in host kernel, 3% spin_lock in guests [1x looking fine here] I see ple_off is little better here. 2x over-commit with 20-vCPU VMs (8 VMs) all running dbench: -- Total ConfigurationThroughputNotes 3.10-default-ple_on 196570% CPU in host kernel, 34% spin_lock in guests 3.10-default-ple_off 2262% CPU in host kernel, 94% spin_lock in guests 3.10-pvticket-ple_on 194270% CPU in host kernel, 35% spin_lock in guests 3.10-pvticket-ple_off 800311% CPU in host kernel, 70% spin_lock in guests [quite bad all around, but pv-tickets with PLE off the best so far. Still quite a bit off from ideal throughput] This is again a remarkable improvement (307%). This motivates me to add a patch to disable ple when pvspinlock is on. probably we can add a hypercall that disables ple in kvm init patch. but only problem I see is what if the guests are mixed. (i.e one guest has pvspinlock support but other does not. Host supports pv) How about reintroducing the idea to create per-kvm ple_gap,ple_window state. We were headed down that road when considering a dynamic window at one point. Then you can just set a single guest's ple_gap to zero, which would lead to PLE being disabled for that guest. We could also revisit the dynamic window then. Can be done, but lets unde
[PATCH re-send] leds: support new LP8501 device - another LP55xx common
LP8501 can drive up to 9 channels like LP5523.
LEDs can be controlled directly via the I2C and programmable engines are
supported.
LP55xx common driver
LP8501 is one of LP55xx family device, so LP55xx common code are used.
Chip specific data is defined in the structure, 'lp55xx_device_config'.
Differences between LP8501 and LP5523
Different register layout for LED output control and others.
LP8501 specific feature for separate output power selection.
LP8501 doesn't support external clock detection.
Different programming engine data.
LP8501 specific feature - output power selection
Output channels are selected by power selection - Vout or Vdd.
Separate power for VDD1-6 and VDD7-9 are available.
It is configurable in the platform data.
To support this feature, LP55xx DT structure and header are changed.
Device tree binding is updated as well.
LED pattern data
Example pattern data is updated in the driver documentation.
Signed-off-by: Milo Kim
---
This patch is re-sent with additional Cc lists.
.../devicetree/bindings/leds/leds-lp55xx.txt | 72 +++-
Documentation/leds/leds-lp55xx.txt | 30 +-
drivers/leds/Kconfig | 18 +-
drivers/leds/Makefile |1 +
drivers/leds/leds-lp55xx-common.c |3 +
drivers/leds/leds-lp8501.c | 410
include/linux/platform_data/leds-lp55xx.h | 10 +
7 files changed, 537 insertions(+), 7 deletions(-)
create mode 100644 drivers/leds/leds-lp8501.c
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
index d517688..a61727f 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -1,7 +1,7 @@
Binding for TI/National Semiconductor LP55xx Led Drivers
Required properties:
-- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562"
+- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" or
"ti,lp8501"
- reg: I2C slave address
- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
@@ -11,6 +11,11 @@ Each child has own specific current settings
Optional properties:
- label: Used for naming LEDs
+- pwr-sel: LP8501 specific property. Power selection for output channels.
+ 0: D1~9 are connected to VDD
+ 1: D1~6 with VDD, D7~9 with VOUT
+ 2: D1~6 with VOUT, D7~9 with VDD
+ 3: D1~9 are connected to VOUT
Alternatively, each child can have specific channel name
- chan-name: Name of each channel name
@@ -145,3 +150,68 @@ lp5562@30 {
max-cur = /bits/ 8 <0x60>;
};
};
+
+example 4) LP8501
+9 channels are defined. The 'pwr-sel' is LP8501 specific property.
+Others are same as LP5523.
+
+lp8501@32 {
+ compatible = "ti,lp8501";
+ reg = <0x32>;
+ clock-mode = /bits/ 8 <2>;
+ pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
+
+ chan0 {
+ chan-name = "d1";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan1 {
+ chan-name = "d2";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan2 {
+ chan-name = "d3";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan3 {
+ chan-name = "d4";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan4 {
+ chan-name = "d5";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan5 {
+ chan-name = "d6";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan6 {
+ chan-name = "d7";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan7 {
+ chan-name = "d8";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan8 {
+ chan-name = "d9";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+};
diff --git a/Documentation/leds/leds-lp55xx.txt
b/Documentation/leds/leds-lp55xx.txt
index eec8fa2..82713ff 100644
--- a/Documentation/leds/leds-lp55xx.txt
+++ b/Documentation/leds/leds-lp55xx.txt
@@ -1,11 +1,11 @@
-LP5521/LP5523/LP55231 Common Driver
-===
+LP5521/LP5523/LP55231/LP5562/LP8501 Common Driver
+=
Authors: Milo(Woogyom) Kim
Description
---
-LP5521, LP5523/55231 and LP5562 have common features as below.
+LP5521, LP5523/55231, LP5562 and LP8501 have common features as below.
Register access via
[PATCH re-send] backlight: lp855x_bl: support new LP8555 device
LP8555 is one of LP855x family device.
This device needs pre_init_device() and post_init_device() driver structure.
It's same as LP8557, so the device configuration code is shared with LP8557.
Backlight outputs are generated from dual DC-DC boost converters.
It's configurable EPROM settings which are defined in the platform data.
Driver documentation and device tree bindings are updated.
Signed-off-by: Milo Kim
---
This patch is re-sent with additional Cc lists.
Documentation/backlight/lp855x-driver.txt |5 ++--
.../devicetree/bindings/video/backlight/lp855x.txt | 29 +++-
drivers/video/backlight/Kconfig|4 +--
drivers/video/backlight/lp855x_bl.c| 17 ++--
include/linux/platform_data/lp855x.h | 19 +
5 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/Documentation/backlight/lp855x-driver.txt
b/Documentation/backlight/lp855x-driver.txt
index 1c732f0..01bce24 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -4,7 +4,8 @@ Kernel driver lp855x
Backlight driver for LP855x ICs
Supported chips:
- Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
+ Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
+ LP8557
Author: Milo(Woogyom) Kim
@@ -24,7 +25,7 @@ Value : pwm based or register based
2) chip_id
The lp855x chip id.
-Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
+Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557
Platform data for lp855x
diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt
b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
index 1482103..96e83a5 100644
--- a/Documentation/devicetree/bindings/video/backlight/lp855x.txt
+++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
@@ -2,7 +2,7 @@ lp855x bindings
Required properties:
- compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
-"ti,lp8556", "ti,lp8557"
+"ti,lp8555", "ti,lp8556", "ti,lp8557"
- reg: I2C slave address (u8)
- dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
@@ -15,6 +15,33 @@ Optional properties:
Example:
+ /* LP8555 */
+ backlight@2c {
+ compatible = "ti,lp8555";
+ reg = <0x2c>;
+
+ dev-ctrl = /bits/ 8 <0x00>;
+ pwm-period = <1>;
+
+ /* 4V OV, 4 output LED0 string enabled */
+ rom_14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xcf>;
+ };
+
+ /* Heavy smoothing, 24ms ramp time step */
+ rom_15h {
+ rom-addr = /bits/ 8 <0x15>;
+ rom-val = /bits/ 8 <0xc7>;
+ };
+
+ /* 4 output LED1 string enabled */
+ rom_19h {
+ rom-addr = /bits/ 8 <0x19>;
+ rom-val = /bits/ 8 <0x0f>;
+ };
+ };
+
/* LP8556 */
backlight@2c {
compatible = "ti,lp8556";
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d5ab658..9d20953 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -388,8 +388,8 @@ config BACKLIGHT_LP855X
tristate "Backlight driver for TI LP855X"
depends on BACKLIGHT_CLASS_DEVICE && I2C
help
- This supports TI LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
- backlight driver.
+ This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
+ LP8557 backlight driver.
config BACKLIGHT_LP8788
tristate "Backlight driver for TI LP8788 MFD"
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index a0e1e02..4abc09a 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -26,13 +26,15 @@
#define LP8556_EPROM_START 0xA0
#define LP8556_EPROM_END 0xAF
-/* LP8557 Registers */
+/* LP8555/7 Registers */
#define LP8557_BL_CMD 0x00
#define LP8557_BL_MASK 0x01
#define LP8557_BL_ON 0x01
#define LP8557_BL_OFF 0x00
#define LP8557_BRIGHTNESS_CTRL 0x04
#define LP8557_CONFIG 0x10
+#define LP8555_EPROM_START 0x10
+#define LP8555_EPROM_END 0x7A
#define LP8557_EPROM_START 0x10
#define LP8557_EPROM_END 0x1E
@@ -111,6 +113,10 @@ static bool lp855x_is_valid_rom_area(struct lp855x *lp, u8
addr)
start = LP8556_EPROM_START;
end = LP8556_EPROM_END;
break;
+ case LP8555:
+ start = LP8555_EPROM_START;
+ end = LP8555_EP
[uclinux-dist-devel] [GIT PULL] Blackfin updates for 3.11
Hi Linus and Stephen,
I've signed up for an kernel.org account and moved the blackfin tree to
kernel.org for convenience as some developers' suggestion. Pls update the url
to:
http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
Hi Linus,
please pull blackfin updates for Linux 3.11, some minor changes for performance
and bug fixes.
The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:
Linux 3.10 (2013-06-30 15:13:29 -0700)
are available in the git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
tags/blackfin-for-linus
for you to fetch changes up to 150382a53d11256e5666c86525c8bf8d23684532:
smp: refine bf561 smpboot code (2013-07-09 15:50:38 +0800)
blackfin updates for Linux 3.11
Scott Jiang (1):
bf609: rename bfin6xx_spi to bfin_spi3
Sonic Zhang (2):
kgdb: blackfin: include irq_regs.h in kgdb.c
bf609: add cpu revision 0.1
Steven Miao (2):
bf609: stmmac: fix build after stmmac_mdio_bus_data changed
smp: refine bf561 smpboot code
arch/blackfin/Kconfig |2 +-
.../include/asm/{bfin6xx_spi.h => bfin_spi3.h} |4 ++--
arch/blackfin/kernel/kgdb.c|1 +
arch/blackfin/mach-bf561/smp.c |7 +++
arch/blackfin/mach-bf609/boards/ezkit.c| 19 +--
arch/blackfin/mach-common/smp.c| 18 --
6 files changed, 24 insertions(+), 27 deletions(-)
rename arch/blackfin/include/asm/{bfin6xx_spi.h => bfin_spi3.h} (99%)
--
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: /sys/module/pcie_aspm/parameters/policy not writable?
Hi! > > My thinkpad has rather high ping latencies... and perhaps it is due to > > PCIE ASPM. > > Why would that be the problem? The odds that the PCIE bus is the issue > seems strange to me. Well, I google a bit. Apparently, the issue is common on x60/t60 machine and was never fixed properly. And indeed some patches point in that direction, in particular: https://launchpadlibrarian.net/17463623/e1000e-0.4.1.7.diff (It is from comment #27 here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/42572 ). If you have any idea what else it could be... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v1 4/4] spi/xilinx: Use of_property_read_u32 for reading value from node
On Tue, Jul 09, 2013 at 07:26:27AM +0200, Michal Simek wrote: > On 07/08/2013 04:51 PM, Mark Brown wrote: > > Applied, thanks. > have you applied this patch? Yes, network is spotty here so pushes aren't working so well. signature.asc Description: Digital signature
[PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Adds device node for HS USB Host module for AM437x
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am4372.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible =
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+ usb_otg_hs1: am4372_dwc3@4838 {
+ compatible = "ti,am437x-dwc3";
+ reg = <0x4838 0x1ff>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <1>;
+ ranges;
+
+ dwc3@4839 {
+ compatible = "snps,dwc3";
+ reg = <0x4839 0xcfff>;
+ interrupts = ;
+ };
+
+ };
+
};
};
--
1.8.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: [RFC][PATCH 4/8] ACPI / hotplug / PCI: Hotplug context objects for bridges and functions
On Tue, Jul 09, 2013 at 02:18:12AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> When either a new hotplug brigde or a new hotplug function is added
^^
typo
> by the ACPI-based PCI hotplug (acpiphp) code, attach a context object
> to its ACPI handle to store hotplug-related information in it. To
> start with, put the handle's bridge and function pointers into that
> object. Count references to the context objects and drop them when
> they are not needed any more.
>
> First of all, this makes it possible to find out if the given bridge
> has been registered as a function already in a much more
> straightforward way and acpiphp_bridge_handle_to_function() can be
> dropped (Yay!).
>
> This also will allow some more simplifications to be made going
> forward.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/pci/hotplug/acpiphp.h | 10 ++
> drivers/pci/hotplug/acpiphp_glue.c | 154
> ++---
> 2 files changed, 121 insertions(+), 43 deletions(-)
>
> Index: linux-pm/drivers/pci/hotplug/acpiphp.h
> ===
> --- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
> +++ linux-pm/drivers/pci/hotplug/acpiphp.h
> @@ -49,6 +49,7 @@
> #define info(format, arg...) printk(KERN_INFO "%s: " format, MY_NAME , ##
> arg)
> #define warn(format, arg...) printk(KERN_WARNING "%s: " format, MY_NAME , ##
> arg)
>
> +struct acpiphp_context;
> struct acpiphp_bridge;
> struct acpiphp_slot;
>
> @@ -77,6 +78,7 @@ struct acpiphp_bridge {
> struct kref ref;
> acpi_handle handle;
>
> + struct acpiphp_context *context;
> /* Ejectable PCI-to-PCI bridge (PCI bridge and PCI function) */
> struct acpiphp_func *func;
>
> @@ -119,6 +121,7 @@ struct acpiphp_slot {
> * typically 8 objects per slot (i.e. for each PCI function)
> */
> struct acpiphp_func {
> + struct acpiphp_context *context;
> struct acpiphp_slot *slot; /* parent */
>
> struct list_head sibling;
> @@ -129,6 +132,13 @@ struct acpiphp_func {
> u32 flags; /* see below */
> };
>
> +struct acpiphp_context {
> + struct kref kref;
> + acpi_handle handle;
> + struct acpiphp_func *func;
> + struct acpiphp_bridge *bridge;
> +};
> +
> /*
> * struct acpiphp_attention_info - device specific attention registration
> *
> Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> ===
> --- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
> +++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> @@ -79,6 +79,61 @@ is_pci_dock_device(acpi_handle handle, u
> }
> }
>
> +static void acpiphp_context_handler(acpi_handle handle, void *context)
> +{
> + /* Intentionally empty. */
> +}
> +
> +static struct acpiphp_context *acpiphp_init_context(acpi_handle handle)
> +{
> + struct acpiphp_context *context;
> + acpi_status status;
> +
> + context = kzalloc(sizeof(*context), GFP_KERNEL);
> + if (!context)
> + return NULL;
> +
> + context->handle = handle;
> + kref_init(&context->kref);
> + status = acpi_attach_data(handle, acpiphp_context_handler, context);
> + if (ACPI_FAILURE(status)) {
> + kfree(context);
> + return NULL;
> + }
> + return context;
> +}
> +
> +static struct acpiphp_context *acpiphp_get_context(acpi_handle handle)
> +{
> + struct acpiphp_context *context = NULL;
> + acpi_status status;
> + void *data;
> +
> + status = acpi_get_data(handle, acpiphp_context_handler, &data);
> + if (ACPI_SUCCESS(status)) {
> + context = data;
> + kref_get(&context->kref);
> + } else if (status == AE_NOT_FOUND) {
> + context = acpiphp_init_context(handle);
> + }
> + return context;
> +}
> +
> +static void acpiphp_release_context(struct kref *kref)
> +{
> + struct acpiphp_context *context;
> +
> + context = container_of(kref, struct acpiphp_context, kref);
> + WARN_ON(context->func || context->bridge);
> + acpi_detach_data(context->handle, acpiphp_context_handler);
> + kfree(context);
> +}
> +
> +static void acpiphp_put_context(struct acpiphp_context *context)
> +{
> + kref_put(&context->kref, acpiphp_release_context);
> +}
> +
> static inline void get_bridge(struct acpiphp_bridge *bridge)
> {
> kref_get(&bridge->ref);
> @@ -91,6 +146,7 @@ static inline void put_bridge(struct acp
>
> static void free_bridge(struct kref *kref)
> {
> + struct acpiphp_context *context;
> struct acpiphp_bridge *bridge;
> struct acpiphp_slot *slot, *next;
> struct acpiphp_func *func, *tmp;
> @@ -99,17 +155,24 @@ static void free_bridge(struct kref *kre
>
> list_for_each_entry_safe(slot, next, &bridge->slots, node) {
> list_for_each_entry_safe(func, tmp, &slot
Re: [PATCH] lib: One less subtraction in binary search iterations.
Vineet Gupta writes:
> On 07/09/2013 09:21 AM, Wedson Almeida Filho wrote:
> > On Sat, Jul 6, 2013 at 9:59 PM, Joe Perches wrote:
> >>
> >> Not correct.
> >>
> >>> while (start < end) {
> >>> - size_t mid = start + (end - start) / 2;
> >>> + size_t mid = (start + end) / 2;
> >>
> >> size_t start = 0x8000;
> >> size_t end = 0x8001;
> >
> > Good point, they aren't equivalent in all cases.
> >
> > For the overflow to happen though, we need an array with at least
> > N/2+1 entries, where N is the address space size. The array wouldn't
> > fit in addressable memory if the element size is greater than 1, so
> > this can only really happen when the element size is 1. Even then, it
> > would require the kernel range to be greater than half of all
> > addressable memory, and allow an allocation taking that much memory. I
> > don't know all architectures where linux runs, but I don't think such
> > configuration is likely to exist.
> >
>
> It does. In ARC port (arch/arc), the untranslated address space starts at
> 0x8000_ and this is where kernel is linked at. So all ARC kernel
> addresses
> (code/data) lie in that range. This means you don't need special corner case
> for
> this trip on ARC - it will break rightaway - unless I'm missing something.
start and end aren't addresses but array indices relative to 'base'.
So even on ARC you should be safe, as long as no array has SIZE_MAX/2
or more elements.
I'm however far from convinced this micro-optimization is worth the
obvious source code quality reduction. Surely the eliminated subtraction
is in the noise compared to the multiplies, indirect function calls,
and memory dereferences (in the cmp functions)?
It should be possible to eliminate the multiplies, since no array can
cross the -1/0 address boundary. But even that is questionable: does
anyone have perf data showing that bsearch performance is a problem?
--
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/6] cpufreq: Add debugfs directory for cpufreq
On 5 July 2013 14:16, Chanwoo Choi wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> +/* The cpufreq_debugfs is used to create debugfs root directory for CPUFreq.
> */
> +#define MAX_DEBUGFS_NAME_LEN CPUFREQ_NAME_LEN
Why declare MAX_DEBUGFS_NAME_LEN if it is going to be equal to
CPUFREQ_NAME_LEN. Simply use CPUFREQ_NAME_LEN everywhere.
> +static struct dentry *cpufreq_debugfs;
Probably make this dependent on CONFIG_CPU_FREQ_STAT?
> /*
> * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> * all cpufreq/hotplug/workqueue/etc related lock issues.
> @@ -726,6 +731,20 @@ static int cpufreq_add_dev_symlink(unsigned int cpu,
> cpufreq_cpu_put(managed_policy);
> return ret;
> }
> +
> + if (cpufreq_debugfs) {
> + char symlink_name[MAX_DEBUGFS_NAME_LEN];
> + char target_name[MAX_DEBUGFS_NAME_LEN];
> +
> + sprintf(symlink_name, "cpu%d", j);
> + sprintf(target_name, "./cpu%d", cpu);
> + managed_policy->cpu_debugfs[j] =
> debugfs_create_symlink(
> + symlink_name,
> + cpufreq_debugfs,
> + target_name);
> + if (!managed_policy->cpu_debugfs[j])
> + pr_debug("creating debugfs symlink failed\n");
pr_err?
> + }
> }
> return ret;
> }
> @@ -746,6 +765,22 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
> if (ret)
> return ret;
>
> + /* prepare interface data for debugfs */
> + if (cpufreq_debugfs) {
> + char name[MAX_DEBUGFS_NAME_LEN];
> + int size, i;
> +
> + sprintf(name, "cpu%d", policy->cpu);
> + size = sizeof(struct dentry*) * NR_CPUS;
NR_CPUS? You only need to take care of cpus that belong to this
policy, isn't it? policy->related_cpus should be good enough for you.
> + i = cpu;
> +
> + policy->cpu_debugfs = devm_kzalloc(dev, size, GFP_KERNEL);
> + policy->cpu_debugfs[i] = debugfs_create_dir(name,
> + cpufreq_debugfs);
> + if (!policy->cpu_debugfs[i])
> + pr_debug("creating debugfs directory failed\n");
> + }
pr_err?
And move this code just before the call to cpufreq_add_dev_symlink().
> /* set up files for this cpu device */
> drv_attr = cpufreq_driver->attr;
> while ((drv_attr) && (*drv_attr)) {
> @@ -839,6 +874,20 @@ static int cpufreq_add_policy_cpu(unsigned int cpu,
> unsigned int sibling,
> return ret;
> }
>
> + if (cpufreq_debugfs) {
> + char symlink_name[MAX_DEBUGFS_NAME_LEN];
> + char target_name[MAX_DEBUGFS_NAME_LEN];
> +
> + sprintf(symlink_name, "cpu%d", cpu);
> + sprintf(target_name, "./cpu%d", sibling);
> + policy->cpu_debugfs[cpu] = debugfs_create_symlink(
> + symlink_name,
> + cpufreq_debugfs,
> + target_name);
> + if (!policy->cpu_debugfs[cpu])
> + pr_debug("creating debugfs symlink failed\n");
> + }
This is purely replication of same code. Create a routine to
hold these lines and call it from wherever it is required.
> return 0;
> }
> #endif
> @@ -1046,6 +1095,7 @@ static int __cpufreq_remove_dev(struct device *dev,
> struct subsys_interface *sif
>
> if (cpu != data->cpu) {
> sysfs_remove_link(&dev->kobj, "cpufreq");
> + debugfs_remove(data->cpu_debugfs[cpu]);
> } else if (cpus > 1) {
> /* first sibling now owns the new sysfs dir */
> cpu_dev = get_cpu_device(cpumask_first(data->cpus));
> @@ -1068,6 +1118,9 @@ static int __cpufreq_remove_dev(struct device *dev,
> struct subsys_interface *sif
> return -EINVAL;
> }
>
> + debugfs_remove_recursive(data->cpu_debugfs[cpu]);
So you removed load_table here? What about other cpus that were
there in policy->cpus?
> + debugfs_remove(cpufreq_debugfs);
Who will create this again? Also, there might be multiple policy struct's
in a system and here we have reached to removal of all cpus of
a policy. Other policies are still alive.
> WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(data, cpu_dev->id);
> unlock_policy_rwsem_write(cpu);
> @@ -1976,6 +2029,10 @@ static int __init cpufreq_core_init(void)
> BUG_ON(!
Re: [RFC][PATCH 5/8] ACPI / hotplug / PCI: Unified notify handler for hotplug events
On Tue, Jul 09, 2013 at 02:19:04AM +0200, Rafael J. Wysocki wrote:
> Index: linux-pm/drivers/pci/hotplug/acpiphp.h
> ===
> --- linux-pm.orig/drivers/pci/hotplug/acpiphp.h
> +++ linux-pm/drivers/pci/hotplug/acpiphp.h
> @@ -137,6 +137,7 @@ struct acpiphp_context {
> acpi_handle handle;
> struct acpiphp_func *func;
> struct acpiphp_bridge *bridge;
> + bool handler_for_func:1;
Hmm, should it be just plain:
bool handler_for_func;
? What's the reason using bitfields for bool?
> };
--
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 1/5] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
On Tue, Jul 09, 2013 at 10:19:45AM +0200, Richard Genoud wrote: > 2013/7/8 Mark Brown : > > The obvious question here is of course if we can use the same driver for > > both of them. > I haven't got a g20 to test that, but that's the goal. I think I do somewhere. > For now, g20 is still non-DT, so I think it's best to have a DT-only > driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35, > 9x25). > When the g20 will move to DT completely, we can drop sam9g20_wm8731.c > and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems) > By the way, maybe g45 could use that also (and SAMA5 ?) If this is the goal then this driver needs a more generic name. signature.asc Description: Digital signature
Re: [RFC][PATCH 6/8] ACPI / hotplug / PCI: Drop acpiphp_handle_to_bridge()
On Tue, Jul 09, 2013 at 02:20:31AM +0200, Rafael J. Wysocki wrote:
> @@ -953,37 +937,49 @@ static void acpiphp_sanitize_bus(struct
> * ACPI event handlers
> */
>
> -static acpi_status
> -check_sub_bridges(acpi_handle handle, u32 lvl, void *context, void **rv)
> +static acpi_status check_sub_bridges(acpi_handle handle, u32 lvl, void *data,
> + void **rv)
> {
> - struct acpiphp_bridge *bridge;
> - char objname[64];
> - struct acpi_buffer buffer = { .length = sizeof(objname),
> - .pointer = objname };
> + struct acpiphp_context *context = acpiphp_get_context(handle);
> +
> + if (!context)
> + return AE_OK;
>
> - bridge = acpiphp_handle_to_bridge(handle);
> - if (bridge) {
> + if (context->bridge) {
> + struct acpiphp_bridge *bridge = context->bridge;
> + char objname[64];
> + struct acpi_buffer buffer = { .length = sizeof(objname),
> + .pointer = objname };
> +
> + get_bridge(bridge);
> acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
> - dbg("%s: re-enumerating slots under %s\n",
> - __func__, objname);
> + dbg("%s: re-enumerating slots under %s\n", __func__, objname);
Although not related to this patch directly, how about using
acpi_handle_debug() or similar here?
> acpiphp_check_bridge(bridge);
> put_bridge(bridge);
> }
> + acpiphp_put_context(context);
> return AE_OK ;
> }
--
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/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
On Tue, Jul 09, 2013 at 10:27:53AM +0200, Richard Genoud wrote: > The dma binding is documented here > Documentation/devicetree/bindings/dma/atmel-dma.txt > But you're right, I shoud update > Documentation/devicetree/bindings/misc/atmel-ssc.txt. No, you need to write a binding for this machine driver - the DMA and SSC need to be documented as well but so too does the audio driver that pulls them together with the CODEC. signature.asc Description: Digital signature
Re: [PATCH v2 0/2] virtio_net: fix race in RX VQ processing
I don't see patch #1 in v2 of this series. -- 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: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hello again, Bjorn. On 04/01/13 18:28, Bjorn Helgaas wrote: Hi Chris, The current Linux acpiphp driver doesn't do anything unless it finds devices with _EJ0 or _RMV methods, and your DSDT has neither. But I think that implementation is incorrect because I'm not convinced that those methods are required in order to do hotplug via ACPI. For example, your DSDT *does* have an _L01 method that does notifications to the root ports. I suspect that hotplug events on your box generate an SCI that invokes that method. Linux basically ignores the resulting notify events, and I suspect that hotplug works on Windows because it is paying attention to them. Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and attach all the output to the bugzilla? 1) Boot with empty ExpressCard slot (without using "pcie_ports=native") 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer 3) # echo 0x0804 > /sys/module/acpi/parameters/debug_level 4) # lspci -vv 5) # setpci -s 1c.3 0x42.w 6) # setpci -s 1c.3 0x5a.w 7) # setpci -s 1c.3 0xd8.l 8) Insert ExpressCard 9) # setpci -s 1c.3 0x5a.w 10) # dmesg Here's what I think we'll see: - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is implemented below this root port - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the root port should generate an SCI whenever a hotplug event is detected - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with the slot empty to 1 with the slot occupied - pciehp doing nothing (since _OSC didn't grant the OS permission to use PCIe native hotplug) - dmesg indication of the SCI, leading to a Bus Check notification to \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard slot As far as I can see, your predicted outcomes where correct. I've added the logs to the bugzilla report. Yes, it behaved exactly as I expected. I attached a few more details of the analysis to the bug report (https://bugzilla.kernel.org/show_bug.cgi?id=54981). I think we need to rework acpiphp to fix this. We will fix it, but I don't know who will do it, or when it will happen. My list is growing faster than I can deal with :( I see that there has been quite a bit of work in the acpiphp area recently. Is any of it intended to fix (or ease the subsequent fixing of) this bug report, please? It's not a big deal if it isn't - I do have a system that, via kernel command line arguments, recognises expresscard devices when I plug them into the slot. But when the release comes along that includes the reworking of acpiphp that you mentioned, I will give extra attention to hotplugging when I try out the -rc kernels on my laptop. Thanks Thanks very much for your excellent data collection! It's my pleasure! Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH V2] tracing/kprobe: Wait for disabling all running kprobe handlers
Wait for disabling all running kprobe handlers when a kprobe
event is disabled, since the caller, trace_remove_event_call()
supposes that a removing event is disabled completely by
disabling the event.
With this change, ftrace can ensure that there is no running
event handlers after disabling it.
Changes in V2:
- Comment (in code) for clarify why we need to wait there.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_kprobe.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7ed6976..8374f78 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -243,11 +243,11 @@ find_event_file_link(struct trace_probe *tp, struct
ftrace_event_file *file)
static int
disable_trace_probe(struct trace_probe *tp, struct ftrace_event_file *file)
{
+ struct event_file_link *link = NULL;
+ int wait = 0;
int ret = 0;
if (file) {
- struct event_file_link *link;
-
link = find_event_file_link(tp, file);
if (!link) {
ret = -EINVAL;
@@ -255,10 +255,7 @@ disable_trace_probe(struct trace_probe *tp, struct
ftrace_event_file *file)
}
list_del_rcu(&link->list);
- /* synchronize with kprobe_trace_func/kretprobe_trace_func */
- synchronize_sched();
- kfree(link);
-
+ wait = 1;
if (!list_empty(&tp->files))
goto out;
@@ -271,8 +268,22 @@ disable_trace_probe(struct trace_probe *tp, struct
ftrace_event_file *file)
disable_kretprobe(&tp->rp);
else
disable_kprobe(&tp->rp.kp);
+ wait = 1;
}
out:
+ if (wait) {
+ /*
+* Synchronize with kprobe_trace_func/kretprobe_trace_func
+* to ensure disabled (all running handlers are finished).
+* This is not only for kfree(), but also the caller,
+* trace_remove_event_call() supposes it for releasing
+* event_call related objects, which will be accessed in
+* the kprobe_trace_func/kretprobe_trace_func.
+*/
+ synchronize_sched();
+ kfree(link);/* Ignored if link == NULL */
+ }
+
return ret;
}
--
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 RFC nohz_full 2/7] nohz_full: Add rcu_dyntick data for scalable detection of all-idle state
On Mon, Jul 08, 2013 at 06:30:01PM -0700, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit adds fields to the rcu_dyntick structure that are used to > detect idle CPUs. These new fields differ from the existing ones in > that the existing ones consider a CPU executing in user mode to be idle, > where the new ones consider CPUs executing in user mode to be busy. > The handling of these new fields is otherwise quite similar to that for > the exiting fields. This commit also adds the initialization required > for these fields. > > So, why is usermode execution treated differently, with RCU considering > it a quiescent state equivalent to idle, while in contrast the new > full-system idle state detection considers usermode execution to be > non-idle? > > It turns out that although one of RCU's quiescent states is usermode > execution, it is not a full-system idle state. This is because the > purpose of the full-system idle state is not RCU, but rather determining > when accurate timekeeping can safely be disabled. Whenever accurate > timekeeping is required in a CONFIG_NO_HZ_FULL kernel, at least one > CPU must keep the scheduling-clock tick going. If even one CPU is > executing in user mode, accurate timekeeping is requires, particularly for > architectures where gettimeofday() and friends do not enter the kernel. > Only when all CPUs are really and truly idle can accurate timekeeping be > disabled, allowing all CPUs to turn off the scheduling clock interrupt, > thus greatly improving energy efficiency. > > This naturally raises the question "Why is this code in RCU rather than in > timekeeping?", and the answer is that RCU has the data and infrastructure > to efficiently make this determination. but but but but... why doesn't the regular nohz code qualify? I'd think that too would be tracking pretty much the same things, no? -- 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 v1] regulator: pfuze100: add pfuze100 regulator driver
On Tue, Jul 09, 2013 at 02:38:00PM +0800, Robin Gong wrote:
I've not fully reviewed this, the major thing here is that the driver is
not making use of the regmap helpers for anything - most of the code in
this driver looks like it duplicates standard code available in the
core.
> @@ -45,6 +45,7 @@ obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
> obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
> obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
> obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
> +obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
> obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
> obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
> obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
> @@ -72,6 +73,7 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
> obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
> obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
> obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
> +obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
This looks broken...
> +++ b/drivers/regulator/pfuze-regulator.h
> @@ -0,0 +1,110 @@
Why is this a separate file?
> +struct pfuze_regulator {
> + struct regulator_desc desc;
> + unsigned int reg;
> + unsigned int stby_reg;
> + unsigned char enable_bit;
> + unsigned char stby_bit;
> + unsigned char vsel_shift;
> + unsigned char vsel_mask;
> + unsigned char stby_vsel_shift;
> + unsigned char stby_vsel_mask;
> + int const *voltages;
This pretty much all looks like you are duplicating standard framework
features - things like the vsels for example.
> +static const int pfuze100_sw1[] = {
> + 30, 325000, 35, 375000, 40, 425000, 45, 475000,
> + 50, 525000, 55, 575000, 60, 625000, 65, 675000,
> + 70, 725000, 75, 775000, 80, 825000, 85, 875000,
> + 90, 925000, 95, 975000, 100, 1025000, 105, 1075000,
> + 110, 1125000, 115, 1175000, 120, 1225000, 125, 1275000,
> + 130, 1325000, 135, 1375000, 140, 1425000, 145, 1475000,
> + 150, 1525000, 155, 1575000, 160, 1625000, 165, 1675000,
> + 170, 1725000, 175, 1775000, 180, 1825000, 185, 1875000,
> +};
This looks like a linear map, use one if you can. Similarly for a bunch
of the other tables (possibly all of them).
> +#if defined(CONFIG_OF)
> +static const struct of_device_id pfuze_dt_ids[] = {
> + { .compatible = "fsl,pfuze100", .data = (void *)PFUZE_ID_PFUZE100},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pfuze_dt_ids);
> +#endif
No need for ifdefs.
> +static int pfuze100_regulator_enable(struct regulator_dev *rdev)
You should be using the standard regmap helpers for this.
> +int pfuze100_regulator_list_voltage(struct regulator_dev *rdev,
> + unsigned selector)
This too (even if you need to use the tables there are helpers for that
too).
> +static int pfuze100_regulator_sw_standby_enable(struct regulator_dev *rdev)
> +{
> + return 0;
> +}
> +static int pfuze100_regulator_sw_standby_disable(struct regulator_dev *rdev)
> +{
> + return 0;
> +}
> +static struct regulator_ops pfuze100_sw_regulator_ops = {
Coding style and you shouldn't have any empty functions.
> +#ifdef CONFIG_OF
> +
> +static int pfuze_get_num_regulators_dt(struct device *dev)
> +{
You need to document any new device tree bindings.
> +static struct regmap_config pfuze_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +
> + .max_register = PFUZE_NUMREGS,
> +
> + .cache_type = REGCACHE_NONE,
This is the defualt, though you should consider caching for performance
reasons.
> +subsys_initcall(pfuze100_regulator_init);
Use module_i2c_driver() (and watch out for coding style).
signature.asc
Description: Digital signature
Re: [PATCH v2 2/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
2013/7/9 Mark Brown : > On Tue, Jul 09, 2013 at 10:27:53AM +0200, Richard Genoud wrote: > >> The dma binding is documented here >> Documentation/devicetree/bindings/dma/atmel-dma.txt >> But you're right, I shoud update >> Documentation/devicetree/bindings/misc/atmel-ssc.txt. > > No, you need to write a binding for this machine driver - the DMA and > SSC need to be documented as well but so too does the audio driver that > pulls them together with the CODEC. Ok, I understand ! Richard. -- 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: /sys/module/pcie_aspm/parameters/policy not writable?
On Mon 2013-07-08 21:13:21, Greg KH wrote: > On Tue, Jul 09, 2013 at 03:26:11AM +0200, Pavel Machek wrote: > > Hi! > > > > My thinkpad has rather high ping latencies... and perhaps it is due to > > PCIE ASPM. > > Why would that be the problem? The odds that the PCIE bus is the issue > seems strange to me. Aha: I guess that's why the file is not writable: pavel@amd:~$ dmesg | grep -i aspm ACPI FADT declares the system doesn't support PCIe ASPM, so disable it e1000e :02:00.0: Disabling ASPM L0s L1 pavel@amd:~$ cat /sys/module/pcie_aspm/parameters/policy [default] performance powersave pavel@amd:~$ root@amd:~# echo -n performance > /sys/module/pcie_aspm/parameters/policy -su: echo: write error: Operation not permitted root@amd:~# But: 1) it should not list unavailable options 2) operation not permitted seems like wrong error code for operation not supported. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: linux-next: Tree for Jul 9
On Tue, Jul 9, 2013 at 9:01 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130708: > > The v4l-dvb tree lost its build failure. > > The tip tree gained a conflict against Linus' tree. > > The akpm tree lost a patch that turned up elsewhere. > > The cpuinit tree lost some patches that turned up in Linus' tree. > > > Hi, I got today several emails from Andrew, that some post-fixes to existing patches in mmotm got merged. Looking into mmotm patch-series, it was not updated since 03-Jul-2013. >From where is [1]? It has "memcg: fix build error if CONFIG_MEMCG_KMEM=n" folded in. Isn't the procedure to get all these patches from Andrew's mmotm? BTW, the new patch has no furher informations or a vX history and my credits are gone, too. - Sedat - [0] http://ozlabs.org/~akpm/mmotm/broken-out/ [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/mm/memcontrol.c?id=958f4381fa3cb7abd6f63103c9099e648595a27e -- 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: Tree for Jul 9
On Tue, Jul 9, 2013 at 11:50 AM, Sedat Dilek wrote: > On Tue, Jul 9, 2013 at 9:01 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 20130708: >> >> The v4l-dvb tree lost its build failure. >> >> The tip tree gained a conflict against Linus' tree. >> >> The akpm tree lost a patch that turned up elsewhere. >> >> The cpuinit tree lost some patches that turned up in Linus' tree. >> >> >> > > Hi, > > I got today several emails from Andrew, that some post-fixes to > existing patches in mmotm got merged. > Looking into mmotm patch-series, it was not updated since 03-Jul-2013. > > From where is [1]? > It has "memcg: fix build error if CONFIG_MEMCG_KMEM=n" folded in. > Isn't the procedure to get all these patches from Andrew's mmotm? > BTW, the new patch has no furher informations or a vX history and my > credits are gone, too. > Hmmm, another patch where I was involved... Original: "ipc,msg: shorten critical region in msgrcv" Post-Fix: "ipc,msq: fix race in msgrcv(2)" ...strange, not folded in. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=188ba7fb13646c4a4de00a315fbddc2f4cba1d20 [2] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=74bd175d0d237894c14adcf0479dd9f22b30c77b > - Sedat - > > > [0] http://ozlabs.org/~akpm/mmotm/broken-out/ > [1] > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/mm/memcontrol.c?id=958f4381fa3cb7abd6f63103c9099e648595a27e -- 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/
