Hello Krzysztof,
Sorry for the late response, I was on holidays and slowly catching up on email.
On 08/28/2014 11:21 AM, Krzysztof Kozlowski wrote:
> On pon, 2014-08-18 at 10:34 +0200, Javier Martinez Canillas wrote:
>> The max77686 mfd driver adds a regmap IRQ chip which creates an
>> IRQ domain
Hello Mike,
On Mon, Aug 18, 2014 at 10:32 AM, Javier Martinez Canillas
wrote:
> This series add support for the clocks present in the Maxim
> 77802 Power Managment IC. Previously, the series was part
> of a bigger one [0] that aimed to add support for all the
> devices in the max77802 PMIC. But n
Hello Alessandro,
On Mon, Aug 18, 2014 at 10:34 AM, Javier Martinez Canillas
wrote:
> This series add support for the Real Time clock present in
> the Maxim 77802 Power Managment IC. Previously, the series
> was part of a bigger one [0] that aimed to add support for
> all the devices in the max77
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:21:41 +0200, anicoara wrote:
Changelog text is missing. Please add a short notice, describing why
this change is done.
> Signed-off-by: Adrian N
The macro "REGMAP_ALLOW_WRITE_DEBUGFS" can be used to enable write
support on the registers file in the debugfs. The mode of the file is
fixed to 0400 so it is not possible to write the file ever.
This patch fixes the mode by setting it to the correct value depending
on the macro.
Cc: Dimitris Pa
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:24:03 +0200, anicoara wrote:
> Signed-off-by: Adrian Nicoara
No changelog text? Please add a short notice, describing why this change
is done.
Commit-ID: e78c3496790ee8a36522a838b59b388e8a709e65
Gitweb: http://git.kernel.org/tip/e78c3496790ee8a36522a838b59b388e8a709e65
Author: Rik van Riel
AuthorDate: Sat, 16 Aug 2014 13:40:10 -0400
Committer: Ingo Molnar
CommitDate: Mon, 8 Sep 2014 08:17:01 +0200
time, signal: Protect resour
Commit-ID: 90ed9cbe765ad358b3151a12b8bf889a3cbcd573
Gitweb: http://git.kernel.org/tip/90ed9cbe765ad358b3151a12b8bf889a3cbcd573
Author: Rik van Riel
AuthorDate: Fri, 15 Aug 2014 16:05:36 -0400
Committer: Ingo Molnar
CommitDate: Mon, 8 Sep 2014 08:17:00 +0200
exit: Always reap resource s
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
fs/ext4/super.c between commit eb68d0e2fc5a ("ext4: track extent status
tree shrinker delay statictics") from the ext4 tree and commit
908c7f1949cb ("percpu_counter: add @gfp to percpu_counter_init()") from
the percpu tree.
I f
Commit-ID: eb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c
Gitweb: http://git.kernel.org/tip/eb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c
Author: Rik van Riel
AuthorDate: Fri, 15 Aug 2014 16:05:38 -0400
Committer: Ingo Molnar
CommitDate: Mon, 8 Sep 2014 08:17:02 +0200
sched, time: Atomically incr
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:25:35 +0200, anicoara wrote:
> Signed-off-by: Adrian Nicoara
No changelog text? Please add a short notice, describing why this change
is done.
Your From: line does not contain a real name and does not match your
Signed-off-by line, please check your e-mail client settings.
On 2014-09-07 at 20:28:25 +0200, anicoara wrote:
No changelog text? Please add a short notice, describing why this change
is done.
> Signed-off-by: Adrian Nicoara
* David Miller wrote:
> From: Ingo Molnar
> Date: Mon, 8 Sep 2014 07:23:29 +0200
>
> >
> > * Alexei Starovoitov wrote:
> >
> >> > I don't think the speed up of the llvm submission is a
> >> > good argument, this sounds to me similar to the "please
> >> > apply this patch that reserves thi
On Sun, Sep 7, 2014 at 10:28 PM, David Miller wrote:
> From: Ingo Molnar
> Date: Mon, 8 Sep 2014 07:23:29 +0200
>
>>
>> * Alexei Starovoitov wrote:
>>
>>> > I don't think the speed up of the llvm submission is a good
>>> > argument, this sounds to me similar to the "please apply this
>>> > patch
Hi dt bindings maintainers (and others interested in device-tree bindings),
I would like to get this included in your tree. Do you think there is
still something I could improve/change in order to get this accepted?
Or do you think I should address this to someone else?
Some DS13
On Sun, Sep 07, 2014 at 09:42:36PM +0530, Anand Moon wrote:
> If a header file happens to be included twice, the compiler will process
> its contents twice. This is very likely to cause an error, e.g. when the
> compiler sees the same structure definition twice. Even if it does not,
> it will certa
On Sat, Sep 06, 2014 at 07:12:26PM +0200, Frederic Weisbecker wrote:
> On Sat, Sep 06, 2014 at 05:45:56PM +0200, Peter Zijlstra wrote:
> > On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote:
> > > You have a script that does that arch/*/include/asm/Kbuild edit for you
> > > right?
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/include/asm/kvm_host.h between commit 656473003bc7 ("KVM:
forward declare structs in kvm_types.h") from the kvm tree and commit
6951e48bff0b ("KVM: ARM/arm64: fix non-const declaration of function
returning const") f
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
> How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on all alignment
requiring architectures, like PPC and Sparc as well. I know it would be
very convenient if all the
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
> On 09/07/2014 03:04 PM, James Bottomley wrote:
> > On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> >> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> >>> On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrot
From: Ingo Molnar
Date: Mon, 8 Sep 2014 07:23:29 +0200
>
> * Alexei Starovoitov wrote:
>
>> > I don't think the speed up of the llvm submission is a good
>> > argument, this sounds to me similar to the "please apply this
>> > patch that reserves this new netlink family in
>> > include/linux
* Alexei Starovoitov wrote:
> > I don't think the speed up of the llvm submission is a good
> > argument, this sounds to me similar to the "please apply this
> > patch that reserves this new netlink family in
> > include/linux/netlink.h, I promise this new subsystem will be
> > submitted soo
On 09/03/2014 05:50 PM, Chen Gang wrote:
> Need include it for irq_of_parse_and_map(), the related error with
> allmodconfig under microblaze:
>
> drivers/usb/host/ehci-xilinx-of.c: In function ‘ehci_hcd_xilinx_of_probe’:
> drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration o
Hi all,
Today's linux-next merge of the integrity tree got a conflict in
fs/nfsd/vfs.c between commit 9b638b816081 ("NFSD: Put file after
ima_file_check fail in nfsd_open()") from the nfsd tree and commit
e8442e203c25 ("ima: pass 'opened' flag to identify newly created
files") from the integrity t
Hello, Linus.
On Sun, Sep 07, 2014 at 08:17:11PM -0700, Linus Torvalds wrote:
> In other words, I'll happily pull this, but your excuses for it are
> wrong-headed. There is no "crazyness justifies this". That's crap. But
> the argument of "nobody does this, so let's fix it before anybody
> _starts
On 6 September 2014 04:17, Stephen Boyd wrote:
> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
> new file mode 100644
> index ..aa8eb97144b6
> --- /dev/null
> +++ b/drivers/cpufreq/qcom-cpufreq.c
> @@ -0,0 +1,199 @@
> +/* Copyright (c) 2014, The Linux Fo
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit a4bf214ffc72
("drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to
haswell_crtc_disable()") from Linus' tree and commit 575f7ab754c4
("drm/i915: Pass intel_crtc to intel
Hi Dave,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/intel_display.c: In function 'intel_crtc_cursor_set_obj':
drivers/gpu/drm/i915/intel_display.c:8302:24: error: 'dev_priv' undeclared
(first use in this function)
intel_ru
On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote:
> On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote:
>> > Don't we have phy_power_on()
>> > for that ? It looks like you could just as well do this from
>> > phy_power_on() ?
>>
>> No, unfortunately keeping these calibration settings
Hi,
Thank you for the report.
Could you share a little bit more information about the file accessing
f2fs_llseek?
E.g., file size, file offset, file allocation information, or dump of that file.
Thanks,
On Sun, Sep 07, 2014 at 10:20:44PM +0300, Tommi Rantala wrote:
> 2014-09-07 22:14 GMT+03:00 T
Addy,
On Sun, Sep 7, 2014 at 8:38 PM, Addy Ke wrote:
> I2C_CLKDIV register descripted in the previous version of
> RK3x chip manual is incorrect. Plus 1 is required.
>
> The correct formula:
> - T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8
> - T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8
> - (SCL Divsor
It removes the owner field updation of driver structure.
It will be automatically updated by module_platform_driver()
Signed-off-by: Varka Bhadram
---
drivers/net/ethernet/ti/cpmac.c|1 -
drivers/net/ethernet/ti/cpsw-phy-sel.c |1 -
drivers/net/ethernet/ti/cpsw.c |1 -
I2C_CLKDIV register descripted in the previous version of
RK3x chip manual is incorrect. Plus 1 is required.
The correct formula:
- T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8
- T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8
- (SCL Divsor) = 8 * ((CLKDIVL + 1) + (CLKDIVH + 1))
- SCL = PCLK / (CLK Divsor)
Hi,
On Sun, Sep 07, 2014 at 11:38:30AM +0800, Huang Ying wrote:
> Only one bit is read in check_valid_map, holding a lock to do that
> doesn't help anything except decreasing performance.
>
> Signed-off-by: Huang, Ying
> ---
>
> v2: Fixed a build warning.
>
> ---
> fs/f2fs/gc.c |3 ---
>
On 09/07/14 20:12, Mike Galbraith wrote:
> (adds CC)
>
> On Sun, 2014-09-07 at 22:25 -0400, Pete Clements wrote:
>> Fyi: i386 up -- problem introduced in rc3.
>>
>> CC arch/x86/pci/irq.o
>> arch/x86/pci/irq.c: In function 'pirq_disable_irq':
>> arch/x86/pci/irq.c:1259:2: error: implicit d
On Thu, Aug 28, 2014 at 01:53:29PM -0700, Dave Jiang wrote:
> A hardware errata causes the NTB to hang when heavy bi-directional traffic
> in addition to the usage of BAR0/1 (where the registers reside, including
> the doorbell registers to trigger interrupts).
>
> This workaround is only availabl
On Sun, Sep 7, 2014 at 6:20 PM, Tejun Heo wrote:
>
> While this is a userland visible
> behavior change, given the craziness of allowing '\n' and its
> implications, I believe the change is justified.
Tejun, absolutely nothing "justifies" things if they break. Not "bad
design",
(adds CC)
On Sun, 2014-09-07 at 22:25 -0400, Pete Clements wrote:
> Fyi: i386 up -- problem introduced in rc3.
>
> CC arch/x86/pci/irq.o
> arch/x86/pci/irq.c: In function 'pirq_disable_irq':
> arch/x86/pci/irq.c:1259:2: error: implicit declaration of function
> 'mp_should_keep_irq' [-We
> -Original Message-
> From: Kweh, Hock Leong
> Sent: Saturday, August 30, 2014 11:48 AM
> To: David Miller
> Cc: peppe.cavall...@st.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ong, Boon Leong; Rayagond K
> Subject: RE: [PATCH 1/4] net: stmmac: enhance to support multiple
On Thu, Aug 28, 2014 at 01:52:57PM -0700, Dave Jiang wrote:
> The following series contains various fixes and cleanup for NTB. It also
> adds the split BAR support on Haswell platform and a hardware errata
> workaround in order to allow interrupts to function during bi-directional
> traffic under s
Centralize redundant print messages and references to sensor names via macros.
Change msleep time from 10ms to 20ms in order to address checkpatch.pl warning:
"msleep < 20ms can sleep for up to 20ms."
Refactor redundant sensor initialization logic into two functions
(_init_sensor_w1,
_init_senso
Fyi: i386 up -- problem introduced in rc3.
CC arch/x86/pci/irq.o
arch/x86/pci/irq.c: In function 'pirq_disable_irq':
arch/x86/pci/irq.c:1259:2: error: implicit declaration of function
'mp_should_keep_irq' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
m
Yes please Arnd, I'm still out for 1.5 week, so it would be great if you take
that through your tree with my ack. Thanks.
Robert
PS: I know, top-posting is madness, but I'm really limited by technology right
now.
- Mail d'origine -
De: Arnd Bergmann
À: Robert Jarzmik
Cc: Haojian Zhua
With the recent addition of percpu_ref_reinit(), percpu_ref now can be
used as a persistent switch which can be turned on and off repeatedly
where turning off maps to killing the ref and waiting for it to drain;
however, there currently isn't a way to initialize a percpu_ref in its
off (killed and
percpu_ref's WARN messages can be a lot more helpful by indicating
who's the culprit. Make them report the release function that the
offending percpu-refcount is associated with. This should make it a
lot easier to track down the reported invalid refcnting operations.
Signed-off-by: Tejun Heo
C
percpu_ref is currently based on ints and the number of refs it can
cover is (1 << 31). This makes it impossible to use a percpu_ref to
count memory objects or pages on 64bit machines as it may overflow.
This forces those users to somehow aggregate the references before
contributing to the percpu_
Hello,
This patchset includes the following three patches improving
percpu-refcount.
0001-percpu-refcount-improve-WARN-messages.patch
0002-percpu-refcount-implement-percpu_ref_set_killed.patch
0003-percpu-refcount-make-percpu_ref-based-on-longs-inste.patch
The patchset is on top of percpu/for
Hello, Linus.
Up until now, cgroup has allowed any character including '\n' in
cgroup names; unfortunately, as '\n' is used as the row delimiter in
/proc/$PID/cgroup, '\n' in a cgroup name makes the content of the file
ambiguous to parse. This pull request includes Alban's patch to
disallow '\n'
Hello,
One patch to fix a failure path in the alloc path. The bug is
dangerous but probably not too likely to actually trigger in the wild
given that there hasn't been any report yet. The other two are low
impact fixes.
Thanks.
The following changes since commit c9d26423e56ce1ab4d786f92aebecf8
Hello, Linus.
Two patches are to add PCI IDs for ICH9 and all others are device
specific fixes. Nothing too interesting.
Thanks.
The following changes since commit 2a13772a144d2956a7fedd18685921d0a9b8b783:
libata: widen Crucial M550 blacklist matching (2014-08-18 17:40:09 -0400)
are availab
Hi Jean,
On Tue, 2 Sep 2014 09:54:55 +0200 Jean Delvare wrote:
>
> On Mon, 01 Sep 2014 08:49:36 -0700, Guenter Roeck wrote:
> > On 09/01/2014 05:28 AM, Mark Brown wrote:
> > > Today's linux-next merge of the jdelvare-hwmon tree got a conflict with
> > > Linus'
> > > tree which appeared to be due
Applied to percpu/for-3.18.
Thanks.
--
tejun
--
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/
percpu_counter is scheduled to grow @gfp support to allow atomic
initialization. This patch makes percpu_counters_lock irq-safe so
that it can be safely used from atomic contexts.
Signed-off-by: Tejun Heo
---
lib/percpu_counter.c | 16 ++--
1 file changed, 10 insertions(+), 6 dele
1) Fix skb leak in mac802154, from Martin Townsend.
2) Use select not depends on NF_NAT for NFT_NAT, from Pablo Neira Ayuso.
3) Fix union initializer bogosity in vxlan, from Gerhard Stenzel.
4) Fix RX checksum configuration in stmmac driver, from Giuseppe
CAVALLARO.
5) Fix TSO with non-acce
How many PARISC systems do we have that actually do real work on Linux?
On September 7, 2014 4:36:55 PM PDT, "Paul E. McKenney"
wrote:
>On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
>> I'm confused why storing 0x0102 would be a problem. I think gcc does
>that even on other cpu
For a short while there, this week was really nice and calm, but that
was mostly because the "linux-foundation.org" entry fell off the DNS
universe, and my mailbox got very quiet for a few hours. The rest of
the week looked pretty normal.
"Pretty normal" isn't bad, though, and I'm not complaining
On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
> I'm confused why storing 0x0102 would be a problem. I think gcc does that
> even on other cpus.
>
> More atomicity can't hurt, can it?
I must defer to James for any additional details on why PARISC systems
don't provide atomicity
I'm confused why storing 0x0102 would be a problem. I think gcc does that even
on other cpus.
More atomicity can't hurt, can it?
On September 7, 2014 4:00:19 PM PDT, "Paul E. McKenney"
wrote:
>On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
>> On Sun, 2014-09-07 at 09:21 -070
blkcg->id is a unique id given to each blkcg; however, the
cgroup_subsys_state which each blkcg embeds already has ->serial_nr
which can be used for the same purpose. Drop blkcg->id and replace
its uses with blkcg->css.serial_nr. Rename cfq_cgroup->blkcg_id to
->blkcg_serial_nr and @id in check_b
From: Beniamino Galvani
Date: Sat, 6 Sep 2014 00:28:23 +0200
> The mdio-sun4i driver automatically selects REGULATOR and
> REGULATOR_FIXED_VOLTAGE because it uses the regulator API. But a
> driver selecting a subsystem increases the chance of generating
> circular Kconfig dependencies, especiall
From: "John W. Linville"
Date: Fri, 5 Sep 2014 11:04:53 -0400
> Please pull this batch of fixes intended for the 3.17 stream...
>
> For the mac80211 bits, Johannes says:
>
> "Here are a few fixes for mac80211. One has been discussed for a while
> and adds a terminating NUL-byte to the alpha2 se
The only places where NULL test on bdi->dev is used are
bdi_[un]register(). The functions can't be called in parallel anyway
and there's no point in protecting bdi->dev clearing with a lock.
Remove bdi->wb_lock grabbing around bdi->dev clearing and move it
after device_unregister() call so that bd
Two flags and one bdi_writeback field are no longer used. Remove
them.
Signed-off-by: Tejun Heo
---
include/linux/backing-dev.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index e488e94..2103a7f 100644
--- a/include/linux/backi
bdi_destroy() has code to transfer the remaining dirty inodes to the
default_backing_dev_info; however, given the shutdown sequence, it
isn't clear how such condition would happen. Also, it isn't a full
solution as the transferred inodes stlil point to the bdi which is
being destroyed. Operations
bdev_get_queue() returns the request_queue associated with the
specified block_device. blk_get_backing_dev_info() makes use of
bdev_get_queue() to determine the associated bdi given a block_device.
All the callers of bdev_get_queue() including
blk_get_backing_dev_info() assume that bdev_get_queue
Canceling of bdi->wb.dwork is currently a bit mushy.
bdi_wb_shutdown() performs cancel_delayed_work_sync() at the end after
shutting down and flushing the delayed_work and bdi_destroy() tries
yet again after bdi_unregister().
bdi->wb.dwork is queued only after checking BDI_registered while
holding
A block_device may be attached to different gendisks and thus
different bdis over time. bdev_inode_switch_bdi() is used to switch
the associated bdi. The function assumes that the inode could be
dirty and transfers it between bdis if so. This is a bit nasty in
that it reaches into bdi internals.
Hello,
This patchset contains the following six bdi related cleanup patches.
Each patch should be fairly self-explanatory.
0001-block-bdi-an-active-gendisk-always-has-a-request_que.patch
0002-bdi-remove-unused-stuff.patch
0003-bdi-remove-bdi-wb_lock-locking-around-bdi-dev-cleari.patch
0004-bd
For VMAs that don't want write notifications, PTEs created for read
faults have their write bit set. If the read fault happens after
VM_SOFTDIRTY is cleared, then the PTE's softdirty bit will remain
clear after subsequent writes.
Here's a simple code snippet to demonstrate the bug:
char* m = mm
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
> On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> > On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> > > On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> > > > On Thu, Sep 04, 2014 at 10:47:2
I think the problem is, when a gendisk is detached, its request queue
is not put in bypass mode
cause when it is re-attached, code tries to put it out of bypass mode,
hence the warning.
So either of these should work, I have not tested it, just coded it up.
diff --git a/block/blk-sysfs.c b/block/
Quoting Abel Vesa (2014-09-07 04:47:13)
> For a while now, I've started studying the power aware scheduling problem.
> And like many other rookies out there I took all the lkml mails related
> and read them all (well, almost all) and I saw that there are some
> debating on the implementation.I even
[linux-scsi dropped, this is not a scsi or uas problem.]
On 7 Sep 2014, n...@esperi.org.uk stated:
> And... now it works, at least well enough to get a device file. So it's
> not the disk that's at fault: it's the no-name hub! (Which is, I think,
> USB ID 2109:0811 -- at least two instances of thi
On Thursday, August 28, 2014 10:22:29 AM Jiang Liu wrote:
> Now all code in processor_core.c is APIC ID related, so rename it as
> apic_id.c. Later IOAPIC ID related code will be added into apic_id.c.
Actually, I'm not sure about this one.
Renames like this make it difficult to backport things in
On 7 Sep 2014, Alan Stern spake thusly:
> On Sun, 7 Sep 2014, Nix wrote:
>
>> I have a brand new Seagate Expansion Desk drive attached to my x86-64
>> desktop. (I also have a 4TiB model of the same drive, but I haven't even
>> unboxed it: there seems little point as long as the 2TiB version doesn'
On Thursday, August 28, 2014 10:22:25 AM Jiang Liu wrote:
> This patch set enhances IOAPIC core and ACPI drivers to support IOAPIC
> hotplug on x86 platforms. It's based on latest mainstream kernel at
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> You may pull it from
>
> -Original Message-
> From: Amos Kong [mailto:kongjian...@gmail.com]
> Sent: Sunday, September 7, 2014 4:44 AM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; open list; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; Jason Wang
> Subject: Re: [PATCH V2 1/1] Dri
On Thu, Sep 04, 2014 at 09:43:11AM -0700, Peter Feiner wrote:
> On Mon, Aug 25, 2014 at 09:45:34PM -0700, Hugh Dickins wrote:
> > That sets me wondering: have you placed the VM_SOFTDIRTY check in the
> > right place in this series of tests?
> >
> > I think, once pgprot_modify() is correct on all a
On Saturday 26 July 2014 20:50:36 Arnd Bergmann wrote:
> commit a38b1f60b5245a3 ("ARM: pxa: Add non device-tree timer link to
> clocksource") introduced a harmless section mismatch warning for
> all pxa platforms, by introducing a new pxa_timer_init() function
> that is not marked __init but that c
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
> In a VLDB like workload this would enable me to lower the latency of
> common fast requests and. By fast requests I mean ones that do not
> require much data, the data is cached, or there's a predictable read
> pattern (read-ahead). O
On 09/07/14 11:48, Mark Brown wrote:
> On Sun, Sep 07, 2014 at 10:59:53AM -0700, Randy Dunlap wrote:
>
>> The quilt-import.log from 20140829 says:
>
>> $ git am --patch-format=mbox
>> ../quilt/rd-docs/001-docum-use-subdiry-avoid-builtin.patch
>
>> and in the 20140905 git tree it says:
>
>> $ g
gcc-4.9 found a potential condition under which the 'pending'
variable may be used uninitialized:
drivers/rtc/rtc-pcf8563.c: In function 'pcf8563_irq':
drivers/rtc/rtc-pcf8563.c:173:5: warning: 'pending' may be used uninitialized
in this function [-Wmaybe-uninitialized]
This is because in the pc
On 09/07/2014 03:04 PM, James Bottomley wrote:
> On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
>> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
>>> On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley
On Fri, Sep 5, 2014 at 5:44 PM, Arnaldo Carvalho de Melo
wrote:
> Em Sat, Sep 06, 2014 at 12:16:40AM +0900, Namhyung Kim escreveu:
>> Hi Adrian and Arnaldo,
>>
>> 2014-09-05 (금), 11:11 -0300, Arnaldo Carvalho de Melo:
>> > Em Fri, Sep 05, 2014 at 10:22:40AM +0300, Adrian Hunter escreveu:
>> > > On
On Sun, Sep 7, 2014 at 11:07 AM, Pablo Neira Ayuso wrote:
>
> If the patches that provide the very first user interface don't get in
> time to this merge window round for whatever reason, we'll have the
> layout of this exposed to userspace in the next kernel version with no
> clients at all, that
It is currently possible to execve() an x32 executable on an x86_64
kernel that has only ia32 compat enabled. However all its syscalls
will fail, even _exit(). This usually causes it to segfault.
Change the ELF compat architecture check so that x32 executables are
rejected if we don't support th
On Sun, 7 Sep 2014, Nix wrote:
> I have a brand new Seagate Expansion Desk drive attached to my x86-64
> desktop. (I also have a 4TiB model of the same drive, but I haven't even
> unboxed it: there seems little point as long as the 2TiB version doesn't
> work.) I am seeing apparently the same prob
From: Russell King - ARM Linux
Date: Sat, Sep 06, 2014 at 07:29:16PM +0100
> On Sat, Sep 06, 2014 at 07:32:07PM +0200, Jurriaan wrote:
> > I updated my Qnap TS-212 with 256 Mb memory to a new TS-221 with 1 Gb
> > memory.
> >
> > On booting, I see that a large chunk of that new memory is not used
2014-09-07 22:14 GMT+03:00 Tommi Rantala :
> Hello,
>
> Hit this oops while fuzzing v3.17-rc3-176-g2b12164 with Trinity.
>
> Tommi
>
>
> BUG: unable to handle kernel paging request at 8804338717a8
> IP: [] get_dnode_of_data+0x3a9/0x440
> PGD 4594067 PUD 0
> Oops: [#1] SMP DEBUG_PAGEALLOC
>
Hello,
Hit this oops while fuzzing v3.17-rc3-176-g2b12164 with Trinity.
Tommi
BUG: unable to handle kernel paging request at 8804338717a8
IP: [] get_dnode_of_data+0x3a9/0x440
PGD 4594067 PUD 0
Oops: [#1] SMP DEBUG_PAGEALLOC
CPU: 0 PID: 4719 Comm: trinity-c3 Not tainted 3.17.0-rc3+ #33
On Fri, Sep 05, 2014 at 03:27:49PM -0600, Bjorn Helgaas wrote:
> > I applied these (with Michael's ack on the first, and v2 of the second) to
> > pci/msi for v3.18, thanks!
Hi Bjorn,
I resent a series with updates that fix kbuild robot errors.
Hopefully, the rebase for pci/msi would not cause tro
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
> On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> > On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> > > > Hi James,
> > > >
> > > > On 09/0
Hello,
This is a cleanup effort to get rid of arch_msi_check_device() function.
I am sending v2 series, since kbuild for v1 reports compile errors on
ppc4xx and Armada 370. Still, I have not checked the fixes on these
platforms.
Changes since v1:
- patch 1: 'pdev' undeclared compile error fixe
There are no archs that override arch_msi_check_device()
hook. Remove it as it is completely redundant.
If an arch would need to check MSI/MSI-X possibility for a
device it should make it within arch_setup_msi_irqs() hook.
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-...@vger
Moving MSI checks from arch_msi_check_device() function to
arch_setup_msi_irqs() function makes code more compact and
allows removing unnecessary hook arch_msi_check_device()
from generic MSI code.
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: Michael Ellerman
Signed-off-by:
Moving MSI checks from arch_msi_check_device() function to
arch_setup_msi_irqs() function makes code more compact and
allows removing unnecessary hook arch_msi_check_device()
from generic MSI code.
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: linux-...@vger.kernel.org
Signed-off-by: Alexander Gordee
Hi!
> [resend with fixed email settings]
>
> The idea of the framework is to provide consistent ways of
> programming raw images into FPGA's.
>
> Programming from device tree overlays is supported.
>
> The core (fpga-mgr.c) does not include a userspace interface
> and just exports kernel functi
A couple comments not directly related to this patch, it's just
a convenient vehicle for my rants :)
> @@ -556,6 +555,19 @@ static int virtblk_init_request(void *data, struct
> request *rq,
> struct virtio_blk *vblk = data;
> struct virtblk_req *vbr = blk_mq_rq_to_pdu(rq);
>
> +
> +static int __scsi_init_request(struct request *rq, int numa_node)
Nitpick: Please use a sane name here, e.g. scsi_mq_alloc/free_sense_buffer.
--
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
This works fine for me, although I still don't really like it very much.
If you really want to go down the path of major surgery in this area we
should probably allocate a flush request per hw_ctx, and initialize it
using the normal init/exit functions. If we want to have proper multiqueue
perfor
1 - 100 of 179 matches
Mail list logo
