Re: [lm-sensors] [PATCH v2] hwmon: add driver for Microchip TC74
On 06/21/2015 06:54 AM, Maciej S. Szmigiero wrote: Add hwmon driver for the Microchip TC74. The TC74 is a single-input 8-bit I2C temperature sensor, with +-2 degrees centigrade accuracy. Signed-off-by: Maciej Szmigiero Applied to -next. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2] packet: remove handling of tx_ring
v1 = replace if()/BUG with BUG_ON() for tx_ring.
v2 = remove handling of tx_ring in prb_setup_retire_blk_timer
for TPACKET_V3 because init_prb_bdqc is called only for NULL tx_ring
and thus prb_setup_retire_blk_timer for NULL tx_ring only.
And also in funciton init_prb_bdqc there is no usage of tx_ring.
Thus removing tx_ring from init_prb_bdqc.
Signed-off-by: Maninder Singh
Suggested-by: Frans Klaver
---
net/packet/af_packet.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index fd51641..aeafcf0 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -543,15 +543,11 @@ static void prb_init_blk_timer(struct packet_sock *po,
pkc->retire_blk_timer.expires = jiffies;
}
-static void prb_setup_retire_blk_timer(struct packet_sock *po, int tx_ring)
+static void prb_setup_retire_blk_timer(struct packet_sock *po)
{
struct tpacket_kbdq_core *pkc;
- if (tx_ring)
- BUG();
-
- pkc = tx_ring ? GET_PBDQC_FROM_RB(>tx_ring) :
- GET_PBDQC_FROM_RB(>rx_ring);
+ pkc = GET_PBDQC_FROM_RB(>rx_ring);
prb_init_blk_timer(po, pkc, prb_retire_rx_blk_timer_expired);
}
@@ -607,7 +603,7 @@ static void prb_init_ft_ops(struct tpacket_kbdq_core *p1,
static void init_prb_bdqc(struct packet_sock *po,
struct packet_ring_buffer *rb,
struct pgv *pg_vec,
- union tpacket_req_u *req_u, int tx_ring)
+ union tpacket_req_u *req_u)
{
struct tpacket_kbdq_core *p1 = GET_PBDQC_FROM_RB(rb);
struct tpacket_block_desc *pbd;
@@ -634,7 +630,7 @@ static void init_prb_bdqc(struct packet_sock *po,
p1->max_frame_len = p1->kblk_size - BLK_PLUS_PRIV(p1->blk_sizeof_priv);
prb_init_ft_ops(p1, req_u);
- prb_setup_retire_blk_timer(po, tx_ring);
+ prb_setup_retire_blk_timer(po);
prb_open_block(p1, pbd);
}
@@ -4001,7 +3997,7 @@ static int packet_set_ring(struct sock *sk, union
tpacket_req_u *req_u,
* it above but just being paranoid
*/
if (!tx_ring)
- init_prb_bdqc(po, rb, pg_vec, req_u, tx_ring);
+ init_prb_bdqc(po, rb, pg_vec, req_u);
break;
default:
break;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add PCI ID and quirk for Intersil/Techwell TW686[4589] AV capture cards.
Bjorn Helgaas writes: >> Intersil/Techwell TW686[4589]-based video capture cards have an empty >> (zero) class code. Fix it. >> > Applied to pci/misc for v4.2, with minor tweak as below to use > PCI_CLASS_MULTIMEDIA_OTHER instead of a bare number. Let me know > if you see any issues with this. Thanks! Can't see any, thanks a lot. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style details (checkpatch)
Joe Perches writes:
> How is the macro used?
> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3, a0 + 4, a0 + 5,
a0 + 6, a0 + 7})
#define REG8_2(a0) ((const u16[8]){a0, a0 + 2, a0 + 4, a0 + 6, a0 + 8, a0 +
0xA, a0 + 0xC, a0 + 0xE})
#define REG8_8(a0) ((const u16[8]){a0, a0 + 8, a0 + 0x10, a0 + 0x18, a0 + 0x20,
a0 + 0x28, a0 + 0x30, a0 + 0x38})
#define VDMA_CHANNEL_CONFIG REG8_1(0x10)
#define ADMA_P_ADDR REG8_2(0x18)
#define ADMA_B_ADDR REG8_2(0x19)
#define INTL_HBAR_CTRL REG8_1(0x30)
#define VIDEO_FIELD_CTRLREG8_1(0x39)
#define HSCALER_CTRLREG8_1(0x42)
#define VIDEO_SIZE REG8_1(0x4A)
#define VIDEO_SIZE_F2 REG8_1(0x52)
#define MD_CONF REG8_1(0x60)
#define MD_INIT REG8_1(0x68)
#define MD_MAP0 REG8_1(0x70)
#define VDMA_P_ADDR REG8_8(0x80) /* not used in DMA SG mode */
#define VDMA_WHPREG8_8(0x81)
#define VDMA_B_ADDR REG8_8(0x82)
#define VDMA_F2_P_ADDR REG8_8(0x84)
#define VDMA_F2_WHP REG8_8(0x85)
#define VDMA_F2_B_ADDR REG8_8(0x86)
then
reg_write(vc->dev, VDMA_CHANNEL_CONFIG[vc->ch], dma_cfg);
reg_write(dev, SAT_U[ch], ctrl->val);
reg_write(dev, SAT_V[ch], ctrl->val);
etc.
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Linux 4.1 released
So after a *very* quiet week after the 4.1-rc8 release, the final 4.1 release is now out. I'm not sure if it was quiet because there really were no problems (knock wood), or if people decided to be considerate of my vacation, but whatever the reason, I appreciate it. It's not like the 4.1 release cycle was particularly painful, and let's hope that the extra week of letting it sit makes for a great release. Which wouldn't be a bad thing, considering that 4.1 will also be a LTS release. Anyway, since rc8 we've had truly small changes, mainly some final driver fixups (HDA sound, drm, scsi target, crypto) and a couple of small misc fixes. The appended shortlog is probably one of the shortest ones ever. I'm not complaining. And this obviously means that the merge window for 4.2 is open. Linus --- Adam Jackson (1): drm/mgag200: Reject non-character-cell-aligned mode widths Andrew Morton (1): revert "cpumask: don't perform while loop in cpumask_next_and()" Boris Brezillon (2): clk: at91: pll: fix input range validity check clk: at91: fix PERIPHERAL_MAX_SHIFT definition Chris Wilson (1): drm/i915: Always reset vma->ggtt_view.pages cache on unbinding Dave Airlie (1): drm/radeon: don't probe MST on hw we don't support it on Hugh Dickins (1): mm: shmem_zero_setup skip security check and lockdep conflict with XFS Hui Wang (1): ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine Jani Nikula (1): Revert "drm/i915: Don't skip request retirement if the active list is empty" Linus Torvalds (1): Linux 4.1 Mauro Carvalho Chehab (1): Kconfig: disable Media Controller for DVB Michel Dänzer (1): drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query Nicholas Mc Guire (1): ALSA: mips: let SND_SGI_O2 select SND_PCM Nicolas Ferre (2): clk: at91: trivial: typo in peripheral clock description clk: at91: fix h32mx prototype inclusion in pmc header Radim Krčmář (1): KVM: x86: fix lapic.timer_mode on restore Sagi Grimberg (3): iser-target: Fix variable-length response error completion iser-target: release stale iser connections iser-target: Fix possible use-after-free Steve Cornelius (2): crypto: caam - improve initalization for context state saves crypto: caam - fix RNG buffer cache alignment Steven Rostedt (1): tracing: Have filter check for balanced ops Takashi Iwai (3): ALSA: hda - Fix audio crackles on Dell Latitude E7x40 ALSA: hda - Fix noisy outputs on Dell XPS13 (2015 model) ALSA: hda - Fix unused label skip_i915 Wolfram Sang (1): i2c: slave: fix the example how to instantiate from userspace -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] ksm: rmap_item pointing to some stale vmas
On 6/9/2015 11:56 PM, Susheel Khiani wrote:
On 4/30/2015 11:37 AM, Susheel Khiani wrote:
But if I've misunderstood, and you think that what you're seeing
fits with the transient forking bugs I've (not quite) described,
and you can explain why even the transient case is important for
you to have fixed, then I really ought to redouble my efforts.
Hugh
I was able to root cause the issue as we got few instances of same and
was frequently getting reproducible on stress tests. The reason why it
was important was because failure to unmap ksm page was resulting into
CMA allocation failure for us.
For cases like fork, what we observed is for private mapped file pages,
stable_node pointed by KSM page won't cover all the mappings until ksmd
completes one full scan. Only after ksmd scan, new rmap_items pointing
to mappings in child process would come into existence. So in cases like
CMA allocations where we can't wait for ksmd to complete one full cycle,
we can traverse anon_vma tree from parent's anon_vma to find out all the
pages wheres CMA is mapped.
I have tested the following patch on 3.10 kernel and with this change I
am able to avoid CMA allocation failure which we were otherwise
frequently seeing because of not able to unmap KSM page.
Please review and let me know the feedback.
[PATCH] ksm: Traverse through parent's anon_vma while unmapping
While doing try_to_unmap_ksm, we traverse through
rmap_item list to find out all the anon_vmas from which
page needs to be unmapped.
Now as per the design of KSM, it builds up its data
structures by looking into each mm, and comes back a cycle
later to find out which data structures are now outdated and
needs to be updated. So, for cases like fork, what we
observe is for private mapped file pages stable_node
pointed by KSM page won't cover all the mappings until
ksmd completes one full scan. Only after ksmd scan, new
rmap_items pointing to mappings in child process would come
into existence.
As a result unmapping of a stable page can't be done until
ksmd has completed one full scan. This becomes an issue in
case of CMA where we need to unmap and move a CMA page and
can't wait for ksmd to complete one cycle. Because of
new rmap_items for new mapping still not created we won't be
able to unmap CMA page from all the vmas where it is mapped.
This would result in frequent CMA allocation failures.
So instead of just relying on rmap_items list which we know
can contain incomplete list, we also scan anon_vma tree from
parent's anon_vma to find out all the vmas where CMA page is
mapped and thereby successfully unmap the page and move it
to new page.
Change-Id: I97cacf6a73734b10c7098362c20fb3f2d4040c76
Signed-off-by: Susheel Khiani
---
mm/ksm.c | 58 +++---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/mm/ksm.c b/mm/ksm.c
index 11f6293..10d5266 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1956,6 +1956,7 @@ int page_referenced_ksm(struct page *page, struct
mem_cgroup *memcg,
unsigned int mapcount = page_mapcount(page);
int referenced = 0;
int search_new_forks = 0;
+int search_from_root = 0;
VM_BUG_ON(!PageKsm(page));
VM_BUG_ON(!PageLocked(page));
@@ -1968,9 +1969,20 @@ again:
struct anon_vma *anon_vma = rmap_item->anon_vma;
struct anon_vma_chain *vmac;
struct vm_area_struct *vma;
+struct rb_root rb_root;
+
+if (!search_from_root) {
+if (anon_vma)
+rb_root = anon_vma->rb_root;
+}
+else {
+if (anon_vma && anon_vma->root) {
+rb_root = anon_vma->root->rb_root;
+}
+}
anon_vma_lock_read(anon_vma);
-anon_vma_interval_tree_foreach(vmac, _vma->rb_root,
+anon_vma_interval_tree_foreach(vmac, _root,
0, ULONG_MAX) {
vma = vmac->vma;
if (rmap_item->address < vma->vm_start ||
@@ -1999,6 +2011,11 @@ again:
}
if (!search_new_forks++)
goto again;
+
+if (!search_from_root++) {
+search_new_forks = 0;
+goto again;
+}
out:
return referenced;
}
@@ -2010,6 +2027,7 @@ int try_to_unmap_ksm(struct page *page, enum
ttu_flags flags,
struct rmap_item *rmap_item;
int ret = SWAP_AGAIN;
int search_new_forks = 0;
+int search_from_root = 0;
VM_BUG_ON(!PageKsm(page));
VM_BUG_ON(!PageLocked(page));
@@ -2028,9 +2046,20 @@ again:
struct anon_vma *anon_vma = rmap_item->anon_vma;
struct anon_vma_chain *vmac;
struct vm_area_struct *vma;
+struct rb_root rb_root;
+
+if (!search_from_root) {
+if (anon_vma)
+rb_root = anon_vma->rb_root;
+}
+else {
+if (anon_vma && anon_vma->root) {
+rb_root = anon_vma->root->rb_root;
+}
+}
anon_vma_lock_read(anon_vma);
-
Re: [PATCH V3 4/4] acpi, apei: use EFI memmap to map GHES memory
On Mon, 15 Jun, at 04:59:08PM, Borislav Petkov wrote: > On Mon, Jun 15, 2015 at 03:15:33PM +0100, Matt Fleming wrote: > > On Sat, 13 Jun, at 10:27:51AM, Borislav Petkov wrote: > > > On Fri, Jun 12, 2015 at 04:44:25PM -0700, Zhang, Jonathan Zhixiong wrote: > > > > Since such function is only needed for APEI functionality, at least as > > > > of today, I will name it arch_apei_get_mem_attribute(). > > > > > > Why? > > > > > > It can be extended to be used generically too, no? Come to think of it, > > > the different arches should already have a way to tell you with what mem > > > attributes a physical address is mapped, no? > > > > > > IOW, such functionality should be already present, you'd only have to > > > find it and use it. > > > > I did think about this, but I don't think we have a generic way to ask > > the firmware for its memory map. > > Not the firmware but the OS. Like on x86, for example, we have MTRRs > and PAT and they cover the whole range. Basically what lookup_memtype() > does. We already have that info, why not query it instead of growing > more stuff ontop. > > I mean, we do ioremap* which does reserve_memtype() and sticks the range > in the rbtree which we query after. Can't be better than that... Right, but see my previous comment about x86 discarding a bunch of attributes for memory regions because the kernel "knows better". And in most places, yes, the kernel really does know better. But this APEI case is special because irrespective of what the kernel says we want to be compatible with the firmware's memory map. And we don't have an API for that. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] power: Add Qualcomm SMBB driver
On Fri, Jun 19, 2015 at 10:01 AM, Paul Bolle wrote:
> On Thu, 2015-06-18 at 14:13 -0700, Bjorn Andersson wrote:
>> --- /dev/null
>> +++ b/drivers/power/qcom_smbb.c
>
>> +MODULE_ALIAS("platform:qcom_smbb");
>
> (The day before yesterday and yesterday I had a, well, lively
> conversation regarding this macro. The interesting bits start at
> https://lkml.org/lkml/2015/6/17/383 .
>
> But in a converstaion today things were rather silent. See
> https://lkml.org/lkml/2015/6/19/68 and the reply, of sorts, in
> https://lkml.org/lkml/2015/6/19/117. Let's see what happens here.)
>
> As I understand it, this alias is only useful if there's a corresponding
> struct platform_device, somewhere. Ie, this alias implies a
> platform_device that will fire of a "MODALIAS=platform:qcom_smbb" uevent
> when it's created. That would be a platform_device using a "qcom_smbb"
> name.
>
As far as I could see the uevents, including MODALIAS, is sent when
the device is added or removed; but the content comes from the device
tree alias, not the MODULE_ALIAS.
The MODULE_ALIAS seems to add an alias to the kernel module
information, which can be used to find this driver during modprobe; in
addition to the actual name of the module.
> If that's correct, then I think this MODULE_ALIAS macro isn't needed
> here, as I couldn't find a platform_device using that name. (But perhaps
> a patch that adds it is pending, somewhere.)
>
I don't see any reason for keeping the MODULE_ALIAS, so I think it
should be removed for v2.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] hexdump: fix for non-aligned buffers
On Mon, 2015-06-22 at 01:42 +0200, =?UTF-8?q?Horacio=20Mijail=20Ant=C3=B3n=20Quiles?= wrote: > An hexdump with a buf not aligned to the groupsize causes > non-naturally-aligned memory accesses. This was causing a kernel panic on > the processor BlackFin BF527, when such an unaligned buffer was fed by the > function ubifs_scanned_corruption in fs/ubifs/scan.c . [] > diff --git a/lib/hexdump.c b/lib/hexdump.c [] > @@ -123,6 +123,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int > rowsize, int groupsize, > groupsize = 1; > if ((len % groupsize) != 0) /* no mixed size output */ > groupsize = 1; > + > + /* fall back to 1-byte groups if buf is not aligned to groupsize*/ Please add a space before the "*/" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
powerpc,numa: Memory hotplug to memory-less nodes ?
Hi, While developing memory hotplug support in QEMU for PoweKVM, I realized that guest kernel has specific checks to prevent hot addition of memory to a memory-less node. I am referring to arch/powerpc/mm/numa.c:hot_add_scn_to_nid() which has explicit checks to ensure that it returns a nid that has some some memory (NODE_DATA(nid)->node_spanned_pages) even when user wants to hotplug to a node that currently has zero memory. Is this limitation by design ? Regards, Bharata. -- http://raobharata.wordpress.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Changes to existing files for 0PF FPGA board.
On Sun, 21 Jun 2015 05:13:06 +0900, Rob Landley wrote: > > On 06/20/2015 03:00 AM, Geert Uytterhoeven wrote: > > Hi Rob, > > > > On Sat, Jun 20, 2015 at 12:11 AM, Rob Landley wrote: > >> On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote: > >>> On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley wrote: > Changes to existing files to add 0pf j2 board support. > >>> > >>> Thanks for your patch! > >>> > >>> Like Greg already said, splitting it up in logical parts and providing > >>> useful > >>> patch descriptions would be highly appreciated. > >> > >> I actually don't know how to split it up further. The initial port was > >> done by a series of contractors (in Russia, I think), and then I > >> inherited it to try to get something releasable. This is the smallest > >> chunk I could get to actually boot. > >> > >> I suppose I could send you the serial driver by itself, and _then_ the > >> board, but it wouldn't compile if nothing uses it. (Similarly you can't > >> boot the board without a serial console...) > > > > You don't have to send in a big initial patch that actually boots. > > For new architecture/SoC/board support, just split it in logical hunks, > > and submit it in some logical order that always builds. > > > > E.g.: > > - SoC core support (arch/sh/), > > - Board support (arch/sh/), > > - Drivers. > > > > The first two should go in through akpm (sh is orphaned), > > the rest through the individual subsystem maintainers. > > I'm aware sh is orphaned > (http://www.openwall.com/lists/musl/2014/02/17/3). I'm trying to do > something about that. > > I'm not up to maintaining an architecture myself (after the > kernel.org/doc thing I walked away from kernel stuff for most of a year, > as you can see I'm a bit out of practice), but I spoke to Yoshinori Sato > (who used to maintain sh2, and only dropped it when renesas discontinued > the hardware) and he said he might be interested in returning as a > co-maintainer. > > (I note that I've been regression testing and fixing sh4 in my > aboriginal linux project for several years now, although it's been > quiescent enough on the kernel side the majority of my posts about it > seem to be qemu issues, from > https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html to > http://comments.gmane.org/gmane.comp.emulators.qemu/294066 . Dealing > with sh2 is new to me, but it's also my day job these days. :) > > >> (Now the reason _I_ thought you'd reject it had more to do with not > >> having converted it to device tree yet, and things on that level. But I > > > > Sh is an existing supported architecture, so DT is not a hard requirement. > > Yeah, but new board... And it's the right thing to do. I think convert DT is best way. It looks don't use SH compatible peripherals. I think if it's a SH compatible, it's better to maintain the platform_device structure. But use incompatible peripherals (So need new platform_device), It's difficult to maintain it. I trying SE7619 target convert to DT. It works fine. So no problem in 0PF platform DT support. > > If you would have waited until after the removal of sh, it would be much > > harder :-) (cfr. h8300, but Sato-san did a great job there, with DT, CCF, > > ...) > > Indeed he did. We had lunch with him when I was in Japan a couple weeks ago. > > I've got the references I need to do this, just... lots of shoveling on > a lot of fronts to do right now. (And I mentioned like 3 other things I > already know I need to fix in the 0/2 message.) > > >> wanted to get it out there so people outside $DAYJOB can test the > >> hardware. We did a linuxcon japan presentation which lwn.net covered, > >> and we're getting pokes about "where can I download this", so...) > > > > It's great to hear there's so much interest in this! Let's hope this will > > attract more actual contributors... > > The "where can I download this" is now the developer tab of 0pf.org by > the way. And the mailing lists are on lists.nommu.org. > > I'll try to submit an updated patch set in the next couple days. > > Thanks, > > Rob -- Yoshinori Sato -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH ipv6 0/1] ipv6: addrconf: routes are not deleted if last ipv6 address is removed
On Thursday 18 June 2015 04:53 PM, Hannes Frederic Sowa wrote:
On Thu, 2015-06-18 at 14:59 +0530, Mazhar Rana wrote:
Hi,
After 'commit 876fd05ddbae03166e7037fca957b55bb3be6594
("ipv6: don't disable interface if last ipv6 address is removed")'
it is not clearing ipv6 interface configurations(routes, neighbours,
etc) when last ipv6 address of interface is removed.
This is now creating functionality issue with below deployment.
On ubuntu 14.04 (upgraded with linux kernel 3.19)
eth1 GW1: 2604:2000:7000:2::102
eth0 GW2: 2001:df7:6000:101::1b:102
HostA: 3804:3000:1406:2::102 (reachable via GW1 and GW2 both)
In this deployment, HostA is reachable via eth0 and eth1. I prefer
that all traffic for HostA should go via GW1 which is available on
link eth1.
$ ip -6 ro s
2001:df7:6000:101::/64 dev eth0 proto kernel metric 256
2604:2000:7000:2::/64 dev eth1 proto kernel metric 256
3804:3000:1406:2::/64 via 2604:2000:7000:2::102 dev eth1 metric 1024
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
default via 2001:df7:6000:101::1b:102 dev eth0 proto static metric 1
On failure of GW1 I removed all ipv6 address of eth1 so all traffic
should go through default gateway 'GW2'.
$ sudo ip -6 addr flush dev eth1
$ ip -6 ro s
2001:df7:6000:101::/64 dev eth0 proto kernel metric 256
3804:3000:1406:2::/64 via 2604:2000:7000:2::102 dev eth1 metric 1024
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0.100 proto kernel metric 256
default via 2001:df7:6000:101::1b:102 dev eth0 proto static metric 1
But here, route for HostA is not deleted, so traffic for HostA is
still trying to go through GW1 which is not reachable anymore.
If 'commit 876fd05ddbae03166e7037fca957b55bb3be6594
("ipv6: don't disable interface if last ipv6 address is removed")'
is taken only for problem mention on changlog of that commit then
here I have alternate proposal which will overcome both issue.
Do you see any side effect of this proposal?
In theory IPv6 mandates that on-link information (which subnet is available on
which link) and address specific connected routes should not depend on each
other. That said, your initial assumption that clearing addresses from an
interface to shut it down for IPv6 operation is wrong.
I guess the check was there to make sure each link has an LL address.
As we changed backwards compatibility here I am a bit ambivalent.
Another glitch I noticed with your patch: We don't set disable_ipv6 bit on
addrconf_ifdown with how==0, so we cannot easily bring the interface up without
disturbing IPv4 operations, could you check, that the disable_ipv6 switch works
to at least bring the ipv6 part of the interface up again?
Bye,
Hannes
Hi Hannes,
Thanks for quick review and reply.
I agree with you. With my patch we can not bring the interface up
without disturbing IPv4 operations. I am working on it to fix it, will
update you once it is done.
Here I want to share behaviour observed in above deployment:
After flushing ipv6 addresses from interface eth1, it is sending
traffic for HostA via GW1 until GW1's neighbour entry become failed.
Once neighbour entry got failed, default route is selected for all
traffic including traffic for HostA. I have not tested behaviour with
interface based routes yet.
Regards,
Mazhar Rana
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ssb: remove unncessary out label
Hi Michael, >> pdev = bus->host_pci; >> mutex_init(>sprom_mutex); >> -err = device_create_file(>dev, _attr_ssb_sprom); >> -if (err) >> -goto out; >> - >> -out: >> -return err; >> +return device_create_file(>dev, _attr_ssb_sprom); >> } > > >I don't really think this change adds any value, but if you insist on >it you get my acked-by. Yes You are right, But By this change code looks simpler. Thats why i suggested the changes. Thanks Maninder
[PATCH] mmc: host: sdhci check parameters before call dma_free_coherent
We should not call dma_free_coherent if host->adma_table is NULL, otherwise may trigger panic. >From DMA-API.txt: " void dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_handle) Free a region of consistent memory you previously allocated. dev, size and dma_handle must all be the same as those passed into dma_alloc_coherent(). cpu_addr must be the virtual address returned by the dma_alloc_coherent(). " So we should check cpu_addr, but not directly call dma_free_coherent. I met this when porting xen, log: " sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper Unable to handle kernel NULL pointer dereference at virtual address pgd = 80004000 [] *pgd= Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22 task: 84074000 ti: 84078000 task.ti: 84078000 PC is at bitmap_clear+0xc0/0xdc LR is at bitmap_clear+0x54/0xdc pc : [<8029deb8>]lr : [<8029de4c>]psr: 2193 sp : 84079d80 ip : 0001 fp : r10: 00077fff r9 : 0404 r8 : 0001 r7 : 0001 r6 : 0001 r5 : r4 : r3 : 0001 r2 : 0001 r1 : 2193 r0 : 0015 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 8800406a DAC: 0015 Process swapper/0 (pid: 1, stack limit = 0x84078238) Stack: (0x84079d80 to 0x8407a000) 9d80: 8113 87efa000 81109918 1000 800197f8 84128558 00080008 9da0: 84079dec 00d0 84bfeac0 84126c10 84126c10 0404 9dc0: 0402 84126c10 80310ba8 9de0: 0524 84078000 84bfeac0 9e00: 84bfe800 8000b407 07eb 8116e0f8 804ee81c 9e20: 84126c10 84c92010 84bfeac0 84126c10 84126c00 84bfeac0 9e40: 84078030 804f08e4 804f03d8 84126c10 fdfb 8115401c 8115401c 9e60: 010f 80362330 803622ec 84126c10 811c8098 8115401c 80360b1c 9e80: 84126c10 8115401c 84126c44 80de1888 80360d28 8115401c 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8 803602bc 9ec0: 80d08314 8115401c 0006 8115401c 0006 8116e080 8116e080 8036130c 9ee0: 80e00f78 0006 800088dc 8400f900 80c94fe0 840bd480 80735184 9f00: 8116e080 150c 8012d430 811105b0 6113 0001 9f20: 87ffc576 8075ca38 010f 8004b0f0 80d66884 0006 87ffc583 0006 9f40: 811105a0 80e00f78 0006 8116e080 8116e080 80da150c 010f 80df4154 9f60: 80df4148 80da1c4c 0006 0006 80da150c 933c 84079f9c 80731338 9f80: 80727254 9fa0: 8072725c 8000ecf8 9fc0: 9fe0: 0013 933c 933c [<8029deb8>] (bitmap_clear) from [<800197f8>] (__arm_dma_free.isra.18+0xe4/0x228) [<800197f8>] (__arm_dma_free.isra.18) from [<80310ba8>] (xen_swiotlb_free_coherent+0xfc/0x140) [<80310ba8>] (xen_swiotlb_free_coherent) from [<804ee81c>] (sdhci_add_host+0xb34/0xe64) [<804ee81c>] (sdhci_add_host) from [<804f08e4>] (sdhci_esdhc_imx_probe+0x50c/0x808) [<804f08e4>] (sdhci_esdhc_imx_probe) from [<80362330>] (platform_drv_probe+0x44/0xa4) [<80362330>] (platform_drv_probe) from [<80360b1c>] (driver_probe_device+0x120/0x25c) [<80360b1c>] (driver_probe_device) from [<80360d28>] (__driver_attach+0x8c/0x90) [<80360d28>] (__driver_attach) from [<8035f10c>] (bus_for_each_dev+0x60/0x94) [<8035f10c>] (bus_for_each_dev) from [<803602bc>] (bus_add_driver+0x148/0x1f0) [<803602bc>] (bus_add_driver) from [<8036130c>] (driver_register+0x78/0xf8) [<8036130c>] (driver_register) from [<800088dc>] (do_one_initcall+0xf8/0x144) [<800088dc>] (do_one_initcall) from [<80da1c4c>] (kernel_init_freeable+0x138/0x1d8) [<80da1c4c>] (kernel_init_freeable) from [<8072725c>] (kernel_init+0x8/0xf0) [<8072725c>] (kernel_init) from [<8000ecf8>] (ret_from_fork+0x14/0x3c) Code: 10866003 1206601f 10633006 11e02312 (e5953000) ---[ end trace f6f103bb73cc0503 ]--- note: swapper/0[1] exited with preempt_count 1 Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b" Because dma_alloc_coherent fail, it returns NULL, then "if (!host->adma_table || !host->align_buffer)" will return true, then dma_free_coherent trigger panic. After applying this patch, no panic and all work well, kernel log: " sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper mmc0: Unable to allocate ADMA buffers. Falling back to standard DMA. mmc0: no vqmmc regulator found mmc0: SDHCI controller on 30b4.usdhc [30b4.usdhc] using DMA "
Re: [PATCH] arm64: dts: mt8173: add clock_null
Hi Heiko,
On Fri, 2015-06-19 at 13:36 +0200, Heiko Stuebner wrote:
> Am Donnerstag, 18. Juni 2015, 18:15:03 schrieb Heiko Stuebner:
> > Am Donnerstag, 18. Juni 2015, 13:29:11 schrieb Eddie Huang:
> > > Add clk_null, which represents clocks that can not / need not
> > > controlled by software.
> > > There are many clocks' parent set to clk_null.
> >
> > Devicetree is supposed to describe hardware, and ideally not what software
> > does with it. If the clock simply cannot be controlled by software, it will
> > still have a rate and I think it should probably be modelled - similarly we
> > sometimes have fixed regulators that also are not software controllable.
> >
> >
> > While it might be ok to define dummy clocks as a temporary stopgap, these
> > should definitly be marked as such. This clk_null at least sounds like there
> > is no plan to replace this with a real solution at some point.
> >
> > And of course a bit of context would be cool, to know which type of clocks
> > this actually replaces.
>
> After looking a bit more into this, I'm feel that the clk_null approach is
> wrong.
>
> For one, even if the clk_null stuff would be ok, the binding doc of the clock
> controller does not describe the need of this specific clock at all.
>
>
> The other more important point, looking at clk-mt8173 I see at least these
> clocks being set as children of "clk_null":
>
> static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
> FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> };
>
>
> These look more like they are fed from some external source to the clock
> controller? I did ask Matthias but he also couldn't find anything describing
> where these clocks actually come from.
Some clocks such as clkph_mck_o, we don't really care where they come
from and what frequencies are. We model these clocks just because they
or their derived clocks can be the source of topckgen muxes. Is there a
better way to model "don't care" clocks?
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] arm64: dts: mt8173: Add I2C device node
Hi Dan,
On Thu, 2015-06-18 at 23:16 +0800, Daniel Kurtz wrote:
> On Wed, Jun 17, 2015 at 11:08 PM, Eddie Huang
> wrote:
> > Add MT8173 I2C device nodes, include I2C controllers and pins.
> > MT8173 has six I2C controllers, from i2c0 to i2c6, exclude i2c5.
> > The 6th I2C controller register base doesn't next to 5th I2C,
> > and there is a hardware between 5th and 6th I2C controller. So
> > SoC designer name 6th controller as "i2c6", not "i2c5".
> >
> > Signed-off-by: Eddie Huang
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 144
> > +++
> > 1 file changed, 144 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index b52ec43..1816c8f 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -158,6 +158,54 @@
> > interrupts = ,
> > > IRQ_TYPE_LEVEL_HIGH>,
> > > IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + i2c0_pins_a: i2c0 {
> > + pins1 {
> > + pinmux =
> > ,
> > +
> > ;
> > + bias-disable;
> > + };
> > + };
> > +
> > + i2c1_pins_a: i2c1 {
> > + pins1 {
> > + pinmux =
> > ,
> > +
> > ;
> > + bias-disable;
> > + };
> > + };
> > +
> > + i2c2_pins_a: i2c2 {
> > + pins1 {
> > + pinmux =
> > ,
> > +
> > ;
> > + bias-disable;
> > + };
> > + };
> > +
> > + i2c3_pins_a: i2c3 {
> > + pins1 {
> > + pinmux =
> > ,
> > +
> > ;
> > + bias-disable;
> > + };
> > + };
> > +
> > + i2c4_pins_a: i2c4 {
> > + pins1 {
> > + pinmux =
> > ,
> > +
> > ;
> > + bias-disable;
> > + };
> > + };
> > +
> > + i2c6_pins_a: i2c6 {
> > + pins1 {
> > + pinmux =
> > ,
> > +
> > ;
> > + bias-disable;
> > + };
> > + };
> > };
> >
> > watchdog: watchdog@10007000 {
> > @@ -229,6 +277,102 @@
> > clocks = <_clk>;
> > status = "disabled";
> > };
> > +
> > + i2c0: i2c@11007000 {
> > + compatible = "mediatek,mt8173-i2c";
> > + reg = <0 0x11007000 0 0x70>,
> > + <0 0x11000100 0 0x80>;
> > + interrupts = ;
> > + clock-div = <16>;
>
> According to the i2c-mt6577 dt binding:
>- clock-div: the fixed value for frequency divider of clock source in i2c
> module. Each IC may be different.
>
> For other drivers I've seen this kind of hardware-specific value
> implemented as a table in the driver that is indexed based on the
> compatible.
>
> Any particular reason to specify it here in every device tree node instead?
>
If put in device tree, it is not necessary to add new compatible if new
SoC has the same I2C controller hardware except clock-div.The benefit is
keep driver clean, but the side-effect is add clock-div in device node.I
assume clock-div has the same concept of clock, so I put in device tree.
Eddie
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio: altera: fix return value of altera_gpio_remove()
Sorry I was away from my mail for the past few weeks. This isn't intentional, should be a bug I overlook. The fix is correct. On Sun, 2015-06-21 at 16:25 +0900, Alexandre Courbot wrote: > On Wed, Jun 17, 2015 at 8:59 PM, Masahiro Yamada > wrote: > > The remove callback never succeeds, which seems odd. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > I wonder why nobody has pointed this out before me. > > I am suspecting -EIO might be intentional. > > I hope some Altera guys will give me comments. > > > > > > drivers/gpio/gpio-altera.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c > > index c653c83..5861550 100644 > > --- a/drivers/gpio/gpio-altera.c > > +++ b/drivers/gpio/gpio-altera.c > > @@ -339,7 +339,7 @@ static int altera_gpio_remove(struct platform_device > > *pdev) > > > > of_mm_gpiochip_remove(_gc->mmchip); > > > > - return -EIO; > > + return 0; > > That looks weird indeed. Tien, can you comment on this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/packet/af_packet.c
between commit:
468479e6043c ("packet: avoid out of bounds read in round robin fanout")
from the net tree and commit:
3b3a5b0aab5b ("packet: rollover huge flows before small flows")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/packet/af_packet.c
index fe1610ddeacf,20e8c40da90d..
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@@ -1272,6 -1326,30 +1326,20 @@@ static void packet_sock_destruct(struc
sk_refcnt_debug_dec(sk);
}
-static int fanout_rr_next(struct packet_fanout *f, unsigned int num)
-{
- int x = atomic_read(>rr_cur) + 1;
-
- if (x >= num)
- x = 0;
-
- return x;
-}
-
+ static bool fanout_flow_is_huge(struct packet_sock *po, struct sk_buff *skb)
+ {
+ u32 rxhash;
+ int i, count = 0;
+
+ rxhash = skb_get_hash(skb);
+ for (i = 0; i < ROLLOVER_HLEN; i++)
+ if (po->rollover->history[i] == rxhash)
+ count++;
+
+ po->rollover->history[prandom_u32() % ROLLOVER_HLEN] = rxhash;
+ return count > (ROLLOVER_HLEN >> 1);
+ }
+
static unsigned int fanout_demux_hash(struct packet_fanout *f,
struct sk_buff *skb,
unsigned int num)
pgpVr43W6S4hP.pgp
Description: OpenPGP digital signature
[PATCH v2] [SCSI] fnic: Replace memset with eth_broadcast_addr
Use eth_broadcast_addr to assign the broadcast address to the given
address array instead of memset when second argument is a broadcast
address 0xff.
The Coccinelle semantic patch that makes this change is as follows:
//
@eth_broadcast_addr@
identifier e;
@@
-memset(e,\(0xff\|0xFF\|255\),ETH_ALEN);
+eth_broadcast_addr(e);
//
Signed-off-by: Vaishali Thakkar
---
Change since v1:
- Fix mistake in commit log
---
drivers/scsi/fnic/fnic_scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
index 155b286..650d448 100644
--- a/drivers/scsi/fnic/fnic_scsi.c
+++ b/drivers/scsi/fnic/fnic_scsi.c
@@ -276,7 +276,7 @@ int fnic_flogi_reg_handler(struct fnic *fnic, u32 fc_id)
}
if (fnic->ctlr.map_dest) {
- memset(gw_mac, 0xff, ETH_ALEN);
+ eth_broadcast_addr(gw_mac);
format = FCPIO_FLOGI_REG_DEF_DEST;
} else {
memcpy(gw_mac, fnic->ctlr.dest_addr, ETH_ALEN);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [SCSI] fnic: Replace memset with eth_broadcast_addr
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is a broadcast
address 0xff.
The Coccinelle semantic patch that makes this change is as follows:
//
@eth_broadcast_addr@
identifier e;
@@
-memset(e,\(0xff\|0xFF\|255\),ETH_ALEN);
+eth_broadcast_addr(e);
//
Signed-off-by: Vaishali Thakkar
---
drivers/scsi/fnic/fnic_scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
index 155b286..650d448 100644
--- a/drivers/scsi/fnic/fnic_scsi.c
+++ b/drivers/scsi/fnic/fnic_scsi.c
@@ -276,7 +276,7 @@ int fnic_flogi_reg_handler(struct fnic *fnic, u32 fc_id)
}
if (fnic->ctlr.map_dest) {
- memset(gw_mac, 0xff, ETH_ALEN);
+ eth_broadcast_addr(gw_mac);
format = FCPIO_FLOGI_REG_DEF_DEST;
} else {
memcpy(gw_mac, fnic->ctlr.dest_addr, ETH_ALEN);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] fs/file.c: don't acquire files->file_lock in fd_install()
On Tue, Apr 28, 2015 at 09:25:03PM -0700, Eric Dumazet wrote:
> @@ -553,11 +572,20 @@ void __fd_install(struct files_struct *files, unsigned
> int fd,
> struct file *file)
> {
> struct fdtable *fdt;
> - spin_lock(>file_lock);
> - fdt = files_fdtable(files);
> +
> + rcu_read_lock_sched();
> +
> + while (unlikely(files->resize_in_progress)) {
> + rcu_read_unlock_sched();
> + wait_event(files->resize_wait, !files->resize_in_progress);
> + rcu_read_lock_sched();
> + }
> + /* coupled with smp_wmb() in expand_fdtable() */
> + smp_rmb();
> + fdt = rcu_dereference_sched(files->fdt);
> BUG_ON(fdt->fd[fd] != NULL);
> rcu_assign_pointer(fdt->fd[fd], file);
> - spin_unlock(>file_lock);
> + rcu_read_unlock_sched();
Umm... You've taken something that was safe to use in atomic contexts
and turned into something that might wait for GFP_KERNEL allocation; what's
to guarantee that no users get broken by that? At the very least, you want
to slap might_sleep() in there - the actual sleep is going to be very rare,
so it would be an extremely hard to reproduce and debug.
AFAICS, all current in-tree users should be safe, but fd_install() is exported
and quiet changes of that sort are rather antisocial. Generally I don't give
a damn about out-of-tree code, but this one is over the top.
I _think_ it's otherwise OK, but please, add might_sleep() *AND* a note in
Documentation/filesystems/porting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio: altera: fix return value of altera_gpio_remove()
On Mon, Jun 22, 2015 at 10:36 AM, Tien Hock Loh wrote: > Sorry I was away from my mail for the past few weeks. > This isn't intentional, should be a bug I overlook. The fix is correct. Interestingly that has never been caught by reviewers despite 10 respins of your series! Thanks for confirming. Reviewed-by: Alexandre Courbot > > On Sun, 2015-06-21 at 16:25 +0900, Alexandre Courbot wrote: >> On Wed, Jun 17, 2015 at 8:59 PM, Masahiro Yamada >> wrote: >> > The remove callback never succeeds, which seems odd. >> > >> > Signed-off-by: Masahiro Yamada >> > --- >> > >> > I wonder why nobody has pointed this out before me. >> > I am suspecting -EIO might be intentional. >> > I hope some Altera guys will give me comments. >> > >> > >> > drivers/gpio/gpio-altera.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c >> > index c653c83..5861550 100644 >> > --- a/drivers/gpio/gpio-altera.c >> > +++ b/drivers/gpio/gpio-altera.c >> > @@ -339,7 +339,7 @@ static int altera_gpio_remove(struct platform_device >> > *pdev) >> > >> > of_mm_gpiochip_remove(_gc->mmchip); >> > >> > - return -EIO; >> > + return 0; >> >> That looks weird indeed. Tien, can you comment on this? > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: pl330: Really fix choppy sound because of wrong residue calculation
2015-06-15 23:00 GMT+09:00 Krzysztof Kozlowski :
> When pl330 driver was used during sound playback, after some time or
> after a number of plays the sound became choppy or totally noisy. For
> example on Odroid XU3 board the first four executions of aplay with
> small WAVE worked fine, but fifth was unrecognizable with errors:
> $ aplay /usr/share/sounds/alsa/Front_Right.wava
> underrun!!! (at least 0.095 ms long)
>
> Issue was caused by wrong residue reported by pl330 driver to
> pcm_dmaengine for its cyclic dma transfers.
>
> The pl330_tx_status(), residue reporting function, used a "last" flag in
> a descriptor to indicate that there is no more data to send.
>
> The pl330_tx_submit() iterated over descriptors trying to remove this
> flag from them and then mark last descriptor as "last". However when
> iterating it actually removed the flag not from descriptors but always
> from last of it (and then reset it). Thus effectively once some
> descriptor was marked as last, then it stayed like this forever causing
> residue to be reported too low.
>
> Signed-off-by: Krzysztof Kozlowski
> Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
> Cc:
> Reported-by: gabr...@unseen.is
> Suggested-by: Marek Szyprowski
Gabriel, could you give this patch a try? It helped for my Odroid XU3,
which has the same audio codec. Nevertheless it would be great to hear
that it solves the initial bug report.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Krzysztof Kozlowski wrote: > > On 22.06.2015 10:38, Kukjin Kim wrote: > > Krzysztof Kozlowski wrote: > >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski : > >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz > >>> : > From: Thomas Abraham > > For Exynos4210 platforms, add CPU operating points and CPU > regulator supply properties for migrating from Exynos specific > cpufreq driver to using generic cpufreq driver. > > Changes by Bartlomiej: > - removed Exynos5250 and Exynos5420 support for now > > Cc: Kukjin Kim > Cc: Doug Anderson > Cc: Javier Martinez Canillas > Cc: Andreas Faerber > Cc: Sachin Kamat > Cc: Andreas Farber > Cc: Javier Martinez Canillas > Signed-off-by: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > >>> > >>> Acked-by: Krzysztof Kozlowski > >> > >> Rebased and applied to my tree, I'll sent it later to Kukjin unless he > >> picks it by himself from LKML. > >> > > Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based > > on > > v4.2-rc1 after v4.2-rc1 release. > > You mean it is for v4.3, not v4.2? > Oops, yes v4.3. Thanks for the correction. Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
On 22.06.2015 10:38, Kukjin Kim wrote: > Krzysztof Kozlowski wrote: >> 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski : >>> 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz >>> : From: Thomas Abraham For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver. Changes by Bartlomiej: - removed Exynos5250 and Exynos5420 support for now Cc: Kukjin Kim Cc: Doug Anderson Cc: Javier Martinez Canillas Cc: Andreas Faerber Cc: Sachin Kamat Cc: Andreas Farber Cc: Javier Martinez Canillas Signed-off-by: Thomas Abraham Signed-off-by: Bartlomiej Zolnierkiewicz >>> >>> Acked-by: Krzysztof Kozlowski >> >> Rebased and applied to my tree, I'll sent it later to Kukjin unless he >> picks it by himself from LKML. >> > Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on > v4.2-rc1 after v4.2-rc1 release. You mean it is for v4.3, not v4.2? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Krzysztof Kozlowski wrote: > 2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski : > > 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz > > : > >> From: Thomas Abraham > >> > >> For Exynos4210 platforms, add CPU operating points and CPU > >> regulator supply properties for migrating from Exynos specific > >> cpufreq driver to using generic cpufreq driver. > >> > >> Changes by Bartlomiej: > >> - removed Exynos5250 and Exynos5420 support for now > >> > >> Cc: Kukjin Kim > >> Cc: Doug Anderson > >> Cc: Javier Martinez Canillas > >> Cc: Andreas Faerber > >> Cc: Sachin Kamat > >> Cc: Andreas Farber > >> Cc: Javier Martinez Canillas > >> Signed-off-by: Thomas Abraham > >> Signed-off-by: Bartlomiej Zolnierkiewicz > > > > Acked-by: Krzysztof Kozlowski > > Rebased and applied to my tree, I'll sent it later to Kukjin unless he > picks it by himself from LKML. > Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/3] mm: make swapin readahead to improve thp collapse rate
On 06/21/2015 02:11 PM, Kirill A. Shutemov wrote:
> On Sat, Jun 20, 2015 at 02:28:06PM +0300, Ebru Akagunduz wrote:
>> +static void __collapse_huge_page_swapin(struct mm_struct *mm,
>> +struct vm_area_struct *vma,
>> +unsigned long address, pmd_t *pmd,
>> +pte_t *pte)
>> +{
>> +unsigned long _address;
>> +pte_t pteval = *pte;
>> +int swap_pte = 0;
>> +
>> +pte = pte_offset_map(pmd, address);
>> +for (_address = address; _address < address + HPAGE_PMD_NR*PAGE_SIZE;
>> + pte++, _address += PAGE_SIZE) {
>> +pteval = *pte;
>> +if (is_swap_pte(pteval)) {
>> +swap_pte++;
>> +do_swap_page(mm, vma, _address, pte, pmd,
>> +
>> FAULT_FLAG_ALLOW_RETRY|FAULT_FLAG_RETRY_NOWAIT,
>> + pteval);
>
> Hm. I guess this lacking error handling.
> We really should abort early at least for VM_FAULT_HWPOISON and VM_FAULT_OOM.
Good catch.
>> +/* pte is unmapped now, we need to map it */
>> +pte = pte_offset_map(pmd, _address);
>
> No, it's within the same pte page table. It should be mapped with
> pte_offset_map() above.
It would be, except do_swap_page() unmaps the pte page table.
>> @@ -2551,6 +2586,8 @@ static void collapse_huge_page(struct mm_struct *mm,
>> if (!pmd)
>> goto out;
>>
>> +__collapse_huge_page_swapin(mm, vma, address, pmd, pte);
>> +
>
> And now the pages we swapped in are not isolated, right?
> What prevents them from being swapped out again or whatever?
Nothing, but __collapse_huge_page_isolate is run with the
appropriate locks to ensure that once we actually collapse
the THP, things are present.
The way do_swap_page is called, khugepaged does not even
wait for pages to be brought in from swap. It just maps
in pages that are in the swap cache, and which can be
immediately locked (without waiting).
It will also start IO on pages that are not in memory
yet, and will hopefully get those next round.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cpu-hotplug: export cpu_hotplug_enable/cpu_hotplug_disable
From: Vitaly Kuznetsov
Loaded Hyper-V module will use these functions to disable CPU
hotplug under certain circumstances. Convert cpu_hotplug_disabled
to a counter (protected by cpu_add_remove_lock) to support e.g.
disable -> disable -> enable call sequences.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
Documentation/power/suspend-and-cpuhotplug.txt |6 +++---
kernel/cpu.c | 13 -
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/Documentation/power/suspend-and-cpuhotplug.txt
b/Documentation/power/suspend-and-cpuhotplug.txt
index 2850df3..2fc9095 100644
--- a/Documentation/power/suspend-and-cpuhotplug.txt
+++ b/Documentation/power/suspend-and-cpuhotplug.txt
@@ -72,7 +72,7 @@ More details follow:
|
v
Disable regular cpu hotplug
-by setting cpu_hotplug_disabled=1
+by increasing cpu_hotplug_disabled
|
v
Release cpu_add_remove_lock
@@ -89,7 +89,7 @@ Resuming back is likewise, with the counterparts being (in
the order of
execution during resume):
* enable_nonboot_cpus() which involves:
| Acquire cpu_add_remove_lock
- | Reset cpu_hotplug_disabled to 0, thereby enabling regular cpu hotplug
+ | Decrease cpu_hotplug_disabled, thereby enabling regular cpu hotplug
| Call _cpu_up() [for all those cpus in the frozen_cpus mask, in a loop]
| Release cpu_add_remove_lock
v
@@ -120,7 +120,7 @@ after the entire cycle is complete (i.e., suspend + resume).
Acquire cpu_add_remove_lock
|
v
- If cpu_hotplug_disabled is 1
+ If cpu_hotplug_disabled > 0
return gracefully
|
|
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 94bbe46..8f35ee6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -190,17 +190,19 @@ void cpu_hotplug_done(void)
void cpu_hotplug_disable(void)
{
cpu_maps_update_begin();
- cpu_hotplug_disabled = 1;
+ cpu_hotplug_disabled++;
cpu_maps_update_done();
}
+EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
void cpu_hotplug_enable(void)
{
cpu_maps_update_begin();
- cpu_hotplug_disabled = 0;
+ if (cpu_hotplug_disabled)
+ cpu_hotplug_disabled--;
cpu_maps_update_done();
}
-
+EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
#endif /* CONFIG_HOTPLUG_CPU */
/* Need to know about CPUs going up/down? */
@@ -600,7 +602,7 @@ int disable_nonboot_cpus(void)
if (!error) {
BUG_ON(num_online_cpus() > 1);
/* Make sure the CPUs won't be enabled by someone else */
- cpu_hotplug_disabled = 1;
+ cpu_hotplug_disabled++;
} else {
pr_err("Non-boot CPUs are not disabled\n");
}
@@ -622,7 +624,8 @@ void __ref enable_nonboot_cpus(void)
/* Allow everyone to use the CPU hotplug again */
cpu_maps_update_begin();
- cpu_hotplug_disabled = 0;
+ if (cpu_hotplug_disabled)
+ cpu_hotplug_disabled--;
if (cpumask_empty(frozen_cpus))
goto out;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] xen/block: add multi-page ring support
On 06/09/2015 10:07 PM, Roger Pau Monné wrote: > El 09/06/15 a les 15.39, Konrad Rzeszutek Wilk ha escrit: ... >> Roger, I put them (patches) on devel/for-jens-4.2 on >> >> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git >> >> I think these two patches: >> drivers: xen-blkback: delay pending_req allocation to connect_ring >> xen/block: add multi-page ring support >> >> are the only ones that haven't been Acked by you (or maybe they >> have and I missed the Ack?) > > Hello, > > I was waiting to Ack those because the XenServer storage performance > folks found out that these patches cause a performance regression on > some of their tests. I'm adding them to the conversation so they can > provide more details about the issues they found, and whether we should > hold pushing this patches or not. > Hey, Are there any updates? What's the performance regression problem? Thanks, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sun, Jun 21, 2015 at 10:41:20PM +0200, Borislav Petkov wrote: > On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote: > > Nope, well the driver requires huge amounts of work to work with PAT, > > that work will likely never be done, so hence the warning. Its our > > compromise as only 2 drivers will live on Linux like this and they are > > both old and rare. > > Hmm, so wasn't the possibility discussed to fail loading It will fail load. > instead and > issue a single-line pr_warn() when PAT is enabled? During review no one opposed the idea of having the warn as its a load thing, not a compile thing, and a user that does not get their driver loaded should know why, otherwise its not clear. > Those big WARN() splats will only confuse people... We can certainly replace the WARN() with pr_warn(), I don't see how its confusing though as its a run time real issue. Either way whatever you recommend is fine by me. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] extcon: palmas: Fix NULL pointer error
On Mon, Jun 22, 2015 at 9:45 AM, Krzysztof Kozlowski
wrote:
> 2015-06-19 15:48 GMT+09:00 Chanwoo Choi :
>> This patch fixes NULL pointer error by removing the unneeded kfree() call
>> of edev->name because extcon-palmas no longer allocate the memory for
>> edev->name.
>
> So the kfree() was executed on pointer returned by
> "dev_name(edev->dev.parent)"?
>
Right.
>
>> Fixes: d71aadda19f8 ("extcon: Remove the optional name of extcon device")
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/extcon/extcon-palmas.c | 7 ---
>> 1 file changed, 7 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
>> index 080d5cc..4e7335f 100644
>> --- a/drivers/extcon/extcon-palmas.c
>> +++ b/drivers/extcon/extcon-palmas.c
>> @@ -200,7 +200,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
>> status = devm_extcon_dev_register(>dev, palmas_usb->edev);
>> if (status) {
>> dev_err(>dev, "failed to register extcon device\n");
>> - kfree(palmas_usb->edev->name);
>> return status;
>> }
>>
>> @@ -214,7 +213,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
>> if (status < 0) {
>> dev_err(>dev, "can't get IRQ %d, err %d\n",
>> palmas_usb->id_irq, status);
>> - kfree(palmas_usb->edev->name);
>> return status;
>> }
>> }
>> @@ -229,7 +227,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
>> if (status < 0) {
>> dev_err(>dev, "can't get IRQ %d, err %d\n",
>> palmas_usb->vbus_irq, status);
>> - kfree(palmas_usb->edev->name);
>> return status;
>> }
>> }
>> @@ -241,10 +238,6 @@ static int palmas_usb_probe(struct platform_device
>> *pdev)
>>
>> static int palmas_usb_remove(struct platform_device *pdev)
>> {
>> - struct palmas_usb *palmas_usb = platform_get_drvdata(pdev);
>> -
>> - kfree(palmas_usb->edev->name);
>> -
>> return 0;
>> }
>
> The remove function is now no-op so I think you can remove it. The
> platform driver code executes it only if it is non-NULL.
OK.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] extcon: palmas: Fix NULL pointer error
2015-06-19 15:48 GMT+09:00 Chanwoo Choi :
> This patch fixes NULL pointer error by removing the unneeded kfree() call
> of edev->name because extcon-palmas no longer allocate the memory for
> edev->name.
So the kfree() was executed on pointer returned by "dev_name(edev->dev.parent)"?
> Fixes: d71aadda19f8 ("extcon: Remove the optional name of extcon device")
> Signed-off-by: Chanwoo Choi
> ---
> drivers/extcon/extcon-palmas.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index 080d5cc..4e7335f 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -200,7 +200,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
> status = devm_extcon_dev_register(>dev, palmas_usb->edev);
> if (status) {
> dev_err(>dev, "failed to register extcon device\n");
> - kfree(palmas_usb->edev->name);
> return status;
> }
>
> @@ -214,7 +213,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
> if (status < 0) {
> dev_err(>dev, "can't get IRQ %d, err %d\n",
> palmas_usb->id_irq, status);
> - kfree(palmas_usb->edev->name);
> return status;
> }
> }
> @@ -229,7 +227,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
> if (status < 0) {
> dev_err(>dev, "can't get IRQ %d, err %d\n",
> palmas_usb->vbus_irq, status);
> - kfree(palmas_usb->edev->name);
> return status;
> }
> }
> @@ -241,10 +238,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
>
> static int palmas_usb_remove(struct platform_device *pdev)
> {
> - struct palmas_usb *palmas_usb = platform_get_drvdata(pdev);
> -
> - kfree(palmas_usb->edev->name);
> -
> return 0;
> }
The remove function is now no-op so I think you can remove it. The
platform driver code executes it only if it is non-NULL.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski : > 2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz > : >> From: Thomas Abraham >> >> For Exynos4210 platforms, add CPU operating points and CPU >> regulator supply properties for migrating from Exynos specific >> cpufreq driver to using generic cpufreq driver. >> >> Changes by Bartlomiej: >> - removed Exynos5250 and Exynos5420 support for now >> >> Cc: Kukjin Kim >> Cc: Doug Anderson >> Cc: Javier Martinez Canillas >> Cc: Andreas Faerber >> Cc: Sachin Kamat >> Cc: Andreas Farber >> Cc: Javier Martinez Canillas >> Signed-off-by: Thomas Abraham >> Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Krzysztof Kozlowski Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
On 21.06.2015 04:13, Michael Turquette wrote: > Quoting Krzysztof Kozlowski (2015-06-20 03:01:12) >> W dniu 19.06.2015 o 23:53, Michael Turquette pisze: >>> Quoting Bartlomiej Zolnierkiewicz (2015-06-19 05:35:23) On Friday, June 19, 2015 01:19:06 PM Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, June 18, 2015 12:58:46 PM Michael Turquette wrote: >> Quoting Sylwester Nawrocki (2015-05-13 07:13:13) >>> On 03/04/15 18:43, Bartlomiej Zolnierkiewicz wrote: This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support. The issue happens because clk_core_set_rate_nolock() calls clk_calc_new_rates(clk, rate) before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered for mout_apll clock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed by clk_change_rate(top). To workaround the problem CLK_RECALC_NEW_RATES flag is added and it is set for mout_apll clock later so the correct divider values are re-calculated after both pre and post clock notifiers had run. For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following: Without use of CLK_GET_RATE_NOCACHE flag: fout_apll rate: 12 fout_apll_div_2 rate: 6 mout_clkout_cpu rate: 6 div_clkout_cpu rate: 6 clkout_cpu rate: 6 mout_apll rate: 12 armclk rate: 12 mout_hpm rate: 12 div_copy rate: 3 div_hpm rate: 3 mout_core rate: 12 div_core rate: 12 div_core2 rate: 12 arm_clk_div_2 rate: 6 div_corem0 rate: 3 div_corem1 rate: 15000 div_periph rate: 3 div_atb rate: 3 div_pclk_dbg rate: 15000 sclk_apll rate: 12 sclk_apll_div_2 rate: 6 With use of CLK_GET_RATE_NOCACHE flag: fout_apll rate: 12 fout_apll_div_2 rate: 6 mout_clkout_cpu rate: 6 div_clkout_cpu rate: 6 clkout_cpu rate: 6 mout_apll rate: 12 armclk rate: 12 mout_hpm rate: 12 div_copy rate: 2 div_hpm rate: 2 mout_core rate: 12 div_core rate: 12 div_core2 rate: 12 arm_clk_div_2 rate: 6 div_corem0 rate: 3 div_corem1 rate: 15000 div_periph rate: 3 div_atb rate: 24000 div_pclk_dbg rate: 12000 sclk_apll rate: 15000 sclk_apll_div_2 rate: 7500 Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board. This issue was probably meant to be workarounded by use of CLK_GET_RATE_NOCACHE and CLK_DIVIDER_READ_ONLY clock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the
Re: [PATCH] clocksource: exynos_mct: remove unneeded container_of()
On 22.06.2015 05:41, Alexey Klimov wrote:
> Patch removes unneeded container_of() macro
> in exynos4_local_timer_setup(). Instead let's pass mevt pointer
> to setup and stop functions from exynos4_mct_cpu_notify()
> and let them get evt pointer.
>
> Tested on odroid-xu3.
>
> Signed-off-by: Alexey Klimov
> Acked-by: Stephen Boyd
Looks good, the internal interface now seems more consistent.
Reviewed-by: Krzysztof Kozlowski
However you forgot to mail this to maintainers of clocksource subsystem
(Cc'ed: Daniel, Thomas, LKML).
Best regards,
Krzysztof
> ---
> drivers/clocksource/exynos_mct.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 83564c9..752a37c 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -446,13 +446,11 @@ static irqreturn_t exynos4_mct_tick_isr(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> -static int exynos4_local_timer_setup(struct clock_event_device *evt)
> +static int exynos4_local_timer_setup(struct mct_clock_event_device *mevt)
> {
> - struct mct_clock_event_device *mevt;
> + struct clock_event_device *evt = >evt;
> unsigned int cpu = smp_processor_id();
>
> - mevt = container_of(evt, struct mct_clock_event_device, evt);
> -
> mevt->base = EXYNOS4_MCT_L_BASE(cpu);
> snprintf(mevt->name, sizeof(mevt->name), "mct_tick%d", cpu);
>
> @@ -484,8 +482,10 @@ static int exynos4_local_timer_setup(struct
> clock_event_device *evt)
> return 0;
> }
>
> -static void exynos4_local_timer_stop(struct clock_event_device *evt)
> +static void exynos4_local_timer_stop(struct mct_clock_event_device *mevt)
> {
> + struct clock_event_device *evt = >evt;
> +
> evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
> if (mct_int_type == MCT_INT_SPI)
> free_irq(evt->irq, this_cpu_ptr(_mct_tick));
> @@ -505,11 +505,11 @@ static int exynos4_mct_cpu_notify(struct notifier_block
> *self,
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_STARTING:
> mevt = this_cpu_ptr(_mct_tick);
> - exynos4_local_timer_setup(>evt);
> + exynos4_local_timer_setup(mevt);
> break;
> case CPU_DYING:
> mevt = this_cpu_ptr(_mct_tick);
> - exynos4_local_timer_stop(>evt);
> + exynos4_local_timer_stop(mevt);
> break;
> }
>
> @@ -557,7 +557,7 @@ static void __init exynos4_timer_resources(struct
> device_node *np, void __iomem
> goto out_irq;
>
> /* Immediately configure the timer on the boot CPU */
> - exynos4_local_timer_setup(>evt);
> + exynos4_local_timer_setup(mevt);
> return;
>
> out_irq:
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] hexdump: fix for non-aligned buffers
An hexdump with a buf not aligned to the groupsize causes non-naturally-aligned memory accesses. This was causing a kernel panic on the processor BlackFin BF527, when such an unaligned buffer was fed by the function ubifs_scanned_corruption in fs/ubifs/scan.c . To fix this, if the buffer is not aligned to groupsize in a platform which does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the groupsize to 1, so alignment is no longer a problem. This behavior is coherent with the way the function currently deals with inappropriate parameter combinations, which is to fall back to safe "defaults", even if that means changing the output format and the implicit access patterns that could have been expected. Signed-off-by: Horacio Mijail Antón Quiles --- Changes in v2: - Followed Joe Perches' indication to use IS_ALIGNED() for readability - Made the explanation, commit and code comments clearer (aligned vs naturally aligned) lib/hexdump.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/hexdump.c b/lib/hexdump.c index 7ea0969..fef4ee1 100644 --- a/lib/hexdump.c +++ b/lib/hexdump.c @@ -123,6 +123,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int groupsize, groupsize = 1; if ((len % groupsize) != 0) /* no mixed size output */ groupsize = 1; + + /* fall back to 1-byte groups if buf is not aligned to groupsize*/ + if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && + !IS_ALIGNED((uintptr_t)buf, groupsize)) + groupsize = 1; ngroups = len / groupsize; ascii_column = rowsize * 2 + rowsize / groupsize + 1; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
1 new photo on MyDailyFlog!
Hi! I would like you to come and see my latest photos on MyDailyFlog. Check out: http://www.mydailyflog.com/go/invite_register/saiprathap/22143969=89 Thanks! sai sadasivam ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ To unsubscribe of this type of email from MyDailyFlog in the future, please click below: http://www.mydailyflog.com/un/linux-kernel@vger.kernel.org=b0a7b7552dcee17e=16 Please do not reply directly to this email. Questions? Contact us - http://www.mydailyflog.com/go/contact_us MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: Fixed source specific default route handling.
You have /128 dst. To override it you need dst/128 AND src/>0 route. ( or just /128 dst and higher metric). Sorry if I am bit unclear - can explain better given real keyboard but that is avail only week from now. -Markus (on the road, via iPhone) 21.6.2015 23.35、Matthias Schiffer のメッセージ: >> On 06/22/2015 12:05 AM, Markus Stenberg wrote: >> Prefsrc is essentially historic non IPv6 construct. IPv6 SAS is based on >> dst, src, metric ordered lookup just like the routing is too ( lookup rfc, >> some src specific routing drafts for details ). >> >> Therefore I do not see a problem. If you want specific SA, add same route >> with higher metric and/or (more) specific src match. >> >> There might be bugs there tho, but that is how it should work. As SAS is >> supposed to happen before routing ( see rfc ) the prefsrc is .. Cough. >> >> -Markus > > Could you explain in detail what you mean with "If you want specific SA, > add same route with higher metric and/or (more) specific src match."? > Routes aren't bound to specific addresses except via the "src" attribute > (which is called prefsrc in the kernel), which is exactly what it not > working. I can't control the chosen source address at all when > source-specific routes are involved. > > Also, metric-based route selection is broken when source-specific routes > are involved. The commands mentioned in my first mail will create the > following configuration: > > # ip a > 3: eth0: mtu 1500 qdisc fq_codel state > UNKNOWN group default qlen 500 >link/ether 22:46:f4:9c:9e:3a brd ff:ff:ff:ff:ff:ff >inet6 fd00::20/64 scope global > valid_lft forever preferred_lft forever >inet6 fe80::2046:f4ff:fe9c:9e3a/64 scope link > valid_lft forever preferred_lft forever > 4: test@eth0: mtu 1500 qdisc noqueue > state UNKNOWN group default >link/ether ae:2b:02:16:23:0f brd ff:ff:ff:ff:ff:ff >inet6 fd00::1/128 scope global > valid_lft forever preferred_lft forever >inet6 fe80::ac2b:2ff:fe16:230f/64 scope link > valid_lft forever preferred_lft forever > > # ip -6 r > fd00::/64 from fd00::/64 dev eth0 metric 1024 > fd00::1 dev test proto kernel metric 256 > fd00::/64 dev eth0 proto kernel metric 256 > > The only route I have added manually is the source-specific one, the > other two have been created by address assignment. Adding a "src" > address to the source-specific route has no effect. > > Even though the source-specific route has a higher metric than the > generic one, the source-specific one shadows the generic route. > > Thanks for your reply, > Matthias > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: Fixed source specific default route handling.
On 06/22/2015 12:05 AM, Markus Stenberg wrote: > Prefsrc is essentially historic non IPv6 construct. IPv6 SAS is based on dst, > src, metric ordered lookup just like the routing is too ( lookup rfc, some > src specific routing drafts for details ). > > Therefore I do not see a problem. If you want specific SA, add same route > with higher metric and/or (more) specific src match. > > There might be bugs there tho, but that is how it should work. As SAS is > supposed to happen before routing ( see rfc ) the prefsrc is .. Cough. > > -Markus > Could you explain in detail what you mean with "If you want specific SA, add same route with higher metric and/or (more) specific src match."? Routes aren't bound to specific addresses except via the "src" attribute (which is called prefsrc in the kernel), which is exactly what it not working. I can't control the chosen source address at all when source-specific routes are involved. Also, metric-based route selection is broken when source-specific routes are involved. The commands mentioned in my first mail will create the following configuration: # ip a 3: eth0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/ether 22:46:f4:9c:9e:3a brd ff:ff:ff:ff:ff:ff inet6 fd00::20/64 scope global valid_lft forever preferred_lft forever inet6 fe80::2046:f4ff:fe9c:9e3a/64 scope link valid_lft forever preferred_lft forever 4: test@eth0: mtu 1500 qdisc noqueue state UNKNOWN group default link/ether ae:2b:02:16:23:0f brd ff:ff:ff:ff:ff:ff inet6 fd00::1/128 scope global valid_lft forever preferred_lft forever inet6 fe80::ac2b:2ff:fe16:230f/64 scope link valid_lft forever preferred_lft forever # ip -6 r fd00::/64 from fd00::/64 dev eth0 metric 1024 fd00::1 dev test proto kernel metric 256 fd00::/64 dev eth0 proto kernel metric 256 The only route I have added manually is the source-specific one, the other two have been created by address assignment. Adding a "src" address to the source-specific route has no effect. Even though the source-specific route has a higher metric than the generic one, the source-specific one shadows the generic route. Thanks for your reply, Matthias signature.asc Description: OpenPGP digital signature
[PATCH] staging: rtl8192u: ieee80211_rx: Fix incorrect type in assignments
Fix the following incorrect type in assignments detected by sparse:
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:571:37: warning: incorrect
type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:571:37:expected unsigned
short [unsigned] [usertype] len
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:571:37:got restricted
__be16 [usertype]
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1330:45: warning: incorrect
type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1330:45:expected unsigned
short [unsigned] [usertype] len
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1330:45:got restricted
__be16 [usertype]
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1495:40: warning: incorrect
type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1495:40:expected
restricted __le16
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1495:40:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1497:40: warning: incorrect
type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1497:40:expected
restricted __le16
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1497:40:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1501:45: warning: incorrect
type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1501:45:expected
restricted __le16
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c:1501:45:got unsigned
short [unsigned] [usertype]
Signed-off-by: Gaston Gonzalez
---
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index b374088..15bcf7e 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -566,7 +566,7 @@ void ieee80211_indicate_packets(struct ieee80211_device
*ieee, struct ieee80211_
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->src,
ETH_ALEN);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->dst,
ETH_ALEN);
} else {
- u16 len;
+ __be16 len;
/* Leave Ethernet header part of hdr and full payload */
len = htons(sub_skb->len);
memcpy(skb_push(sub_skb, 2), , 2);
@@ -1325,7 +1325,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct
sk_buff *skb,
memcpy(skb_push(sub_skb, ETH_ALEN),
src, ETH_ALEN);
memcpy(skb_push(sub_skb, ETH_ALEN),
dst, ETH_ALEN);
} else {
- u16 len;
+ __be16 len;
/* Leave Ethernet header part of hdr
and full payload */
len = htons(sub_skb->len);
memcpy(skb_push(sub_skb, 2), , 2);
@@ -1492,13 +1492,15 @@ static int ieee80211_qos_convert_ac_to_parameters(struct
/* WMM spec P.11: The minimum value for AIFSN shall be 2 */
qos_param->aifs[aci] = (qos_param->aifs[aci] < 2) ?
2:qos_param->aifs[aci];
- qos_param->cw_min[aci] = ac_params->ecw_min_max & 0x0F;
+ qos_param->cw_min[aci] =
+ cpu_to_le16(ac_params->ecw_min_max & 0x0F);
- qos_param->cw_max[aci] = (ac_params->ecw_min_max & 0xF0) >> 4;
+ qos_param->cw_max[aci] =
+ cpu_to_le16((ac_params->ecw_min_max & 0xF0) >> 4);
qos_param->flag[aci] =
(ac_params->aci_aifsn & 0x10) ? 0x01 : 0x00;
- qos_param->tx_op_limit[aci] =
le16_to_cpu(ac_params->tx_op_limit);
+ qos_param->tx_op_limit[aci] = ac_params->tx_op_limit;
}
return 0;
}
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: Fixed source specific default route handling.
Prefsrc is essentially historic non IPv6 construct. IPv6 SAS is based on dst, src, metric ordered lookup just like the routing is too ( lookup rfc, some src specific routing drafts for details ). Therefore I do not see a problem. If you want specific SA, add same route with higher metric and/or (more) specific src match. There might be bugs there tho, but that is how it should work. As SAS is supposed to happen before routing ( see rfc ) the prefsrc is .. Cough. -Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] vfs part 2
On Sun, Jun 21, 2015 at 02:16:15PM -0700, Linus Torvalds wrote:
> On Sun, Jun 21, 2015 at 2:12 PM, Al Viro wrote:
> > + if (count > rsize) {
> > + WARN_ON(1);
> > + count = rsize;
> > + }
>
> So if we'd actually want to merge it with the warning, I'd prefer writing it
> as
>
> if (WARN_ON_ONCE(count > rsize))
> count = size;
>
> because it's smaller and cannot spam your logs. WARN_ON_ONCE() will
> only _warn_ once, but it always returns the conditional for the
> warning, so the above does the right thing.
Sure, but I would really like to verify that this _is_ what's going on
there. This is just a "please try that on your reproducer to make sure
that it's not something entirely different", thus the lack of S-o-b,
etc. For the final variant (and we definitely should cope with BS from
server) we probably want to use p9_debug() instead of WARN_ON/WARN_ON_ONCE.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] special_mapping_fault() is broken
Forgot to add Andy... And forgot to mention. As for vdso in particular, I'd actually prefer to make it have ->vm_file != NULL so that uprobe-in-vdso could work. But this is not that simple, and I think these fixes (if correct) make sense in any case, whatever we do with vdso. On 06/21, Oleg Nesterov wrote: > > On 06/20, Oleg Nesterov wrote: > > > > Let me first send the changes which look "obviously correct" to me. > > Perhaps I'll send more patches on top of this later. > > But lets also fix another unmap/remap bug before the cleanups... > This series doesn't depend on the previous mremap fixes. > > special_mapping_fault() is absolutely broken. It seems it was always > wrong, but this didn't matter until vdso/vvar started to use more than > one page. > > I am not sure about 1/3. As the changelog says the name is not very > accurate, and I do not really like the vma->fault != NULL check. But > I hope this can work, and we can change this helper later if needed. > > Please review. > > Oleg. > > include/linux/mm.h |5 + > mm/memory.c| 13 ++--- > mm/mmap.c | 14 +++--- > 3 files changed, 14 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[BUG] ohci_enable() fails during resume
Hi, A bit, suddenly by desktop PC started to fail to resume. I have redirected the console to ttyS0 and managed to caputere the oops (attached). I am not a dissassebling expert and I have built my kernel without full debuging symbold but here is what I found (at least for the first trace in the attached oops.txt). The failing code is somewhere around line 2400 of drivers/firewire/ohci.c (the latest mainline). There is a note about some values beeing NULL during the resume process but it appears there are more NULLs then expected. (%rbx) points to ohci structure. I attach: oops.txt - full dump of oops from console. oops_code.txt - disassembled Code from the oops. ohci_enable_disassembled.txt - dissassembled ohci_enable function from my kernel (gentoo v3.18.8, but as far as I can tell there haven't been much changes around). I have marked the failing instruction in the disassembler dumps with "-->". There are two conditinons I *suspect* being responsible for this situation. Hardware failure. There was a storm a week ago recently which might damaged the hardware. It appears it hit my SB Audigy very slightly (the card's PCI interface appears OK but the AC97 codec is glitching when setting mixer registers) Hardware bug in the on-board firewire controller *and* a bug in the driver. The code around the line 2400 appears to handle multiple firewire ports (if I recognise variable names correctly, e.g. next_config_rom). Now, without the SB card, I've got only one firewire port so this is what has changed. Please tell me how can I help more to debug this problem. (I may have some problems using the firewire port because I don't have any firewire devices) Kind regards, -- Było mi bardzo miło. Twoje oczy lubią mnie >Łukasz< i to mnie zgubi (c)SNL root@kotik ~ # dmesg -n8 root@kotik ~ # modprobe firewire_ohci [ 232.783281] calling fw_core_init+0x0/0xfb [firewire_core] @ 1944 [ 232.789425] initcall fw_core_init+0x0/0xfb [firewire_core] returned 0 after 39 usecs [ 232.798059] calling fw_ohci_init+0x0/0x4d [firewire_ohci] @ 1944 [ 232.855042] firewire_ohci :04:03.0: added OHCI v1.0 device as card 0, 8 IR + 8 IT contexts, quirks 0x0 [ 232.864724] firewire_ohci :04:03.0: bad self ID 0/1 ( != ~) [ 232.864862] initcall fw_ohci_init+0x0/0x4d [firewire_ohci] returned 0 after 59285 usecs root@kotik ~ # systemctl suspend [ 311.223312] PM: Syncing filesystems ... done. [ 311.301192] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 311.309337] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 311.318148] wlan0: deauthenticating from 28:be:9b:d2:ce:ce by local choice (Reason: 3=DEAUTH_LEAVING) [ 311.416471] cfg80211: Calling CRDA to update world regulatory domain [ usb usb5: root hub lost power or was reset [ 340.411105] snd_hda_intel :00:1b.0: irq 28 for MSI/MSI-X [ 340.411222] usb usb6: root hub lost power or was reset [ 340.411302] usb usb7: root hub lost power or was reset [ 340.411380] usb usb8: root hub lost power or was reset [ 340.411711] usb usb4: root hub lost power or was reset [ 340.411737] rtc_cmos 00:01: System wakeup disabled by ACPI [ 340.412285] serial 00:05: activated [ 341.759829] BUG: unable to handle kernel NULL pointer dereference at (null) [ 341.759834] IP: [] ohci_enable+0x274/0x570 [firewire_ohci] [ 341.759836] PGD 0 [ 341.759837] Oops: [#1] PREEMPT SMP [ 341.759859] Modules linked in: firewire_ohci firewire_core crc_itu_t ctr ccm snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device snd_hda_codec_analog snd_hda_codec_generic arc4 iTCO_wdt coretemp kvm_intel kvm microcode sr_mod rtl8187 serio_raw cdrom eeprom_93cx6 mac80211 mousedev gspca_zc3xx gspca_main uas videodev cfg80211 btusb usb_storage media bluetooth rfkill i2c_i801 i2c_core sky2 lpc_ich mfd_core snd_hda_intel snd_hda_controller floppy snd_hda_codec snd_hwdep snd_pcm snd_timer asus_atk0110 acpi_cpufreq snd processor soundcore button thermal_sys hwmon binfmt_misc dm_mod ext4 crc16 mbcache jbd2 usbhid hid_generic hid [ 341.759861] CPU: 0 PID: 2033 Comm: kworker/u8:84 Not tainted 3.18.7-gentoo #3 [ 341.759862] Hardware name: System manufacturer P5K-E/P5K-E, BIOS 1305 06/19/2009 [ 341.759866] Workqueue: events_unbound async_run_entry_fn [ 341.759867] task: 88019262e010 ti: 88019177 task.ti: 88019177 [ 341.759869] RIP: 0010:[] [] ohci_enable+0x274/0x570 [firewire_ohci] [ 341.759870] RSP: 0018:880191773cb8 EFLAGS: 00010246 [ 341.759871] RAX: RBX: 88019140a000 RCX: 00c0 [ 341.759872] RDX: RSI: 0004 RDI: 88019140a5f8 [ 341.759873] RBP: 880191773ce8 R08: 88019177 R09: 8800c9bb97e0 [ 341.759873] R10: 000f R11: 0001 R12: [ 341.759874] R13: R14: R15: 0001 [
Re: [git pull] vfs part 2
On Sun, Jun 21, 2015 at 2:12 PM, Al Viro wrote:
> + if (count > rsize) {
> + WARN_ON(1);
> + count = rsize;
> + }
So if we'd actually want to merge it with the warning, I'd prefer writing it as
if (WARN_ON_ONCE(count > rsize))
count = size;
because it's smaller and cannot spam your logs. WARN_ON_ONCE() will
only _warn_ once, but it always returns the conditional for the
warning, so the above does the right thing.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] vfs part 2
On Thu, Apr 23, 2015 at 01:16:15PM +0300, Andrey Ryabinin wrote:
> This change caused following:
> This could happen when p9pdu_readf() changes 'count' to some value >
> iov_iter_count(from):
>
> p9_client_write():
> <...>
> int count = iov_iter_count(from);
> <...>
> *err = p9pdu_readf(req->rc, clnt->proto_version, "d", );
> <...>
> iov_iter_advance(from, count);
*blink*
That's a bug, all right, but I would love to see how you trigger it.
It would require server to respond to "write that many bytes" with "OK,
bytes written". We certainly need to cope with that
(we can't trust the server to be sane), but if that's what is going on,
you've got a server bug as well.
Could you check if the patch below triggers WARN_ON() in it on your
reproducer? p9_client_read() has a similar issue as well...
diff --git a/net/9p/client.c b/net/9p/client.c
index 6f4c4c8..f99bce7 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -1588,6 +1588,10 @@ p9_client_read(struct p9_fid *fid, u64 offset, struct
iov_iter *to, int *err)
p9_free_req(clnt, req);
break;
}
+ if (count > rsize) {
+ WARN_ON(1);
+ count = rsize;
+ }
if (non_zc) {
int n = copy_to_iter(dataptr, count, to);
@@ -1650,6 +1654,10 @@ p9_client_write(struct p9_fid *fid, u64 offset, struct
iov_iter *from, int *err)
}
p9_debug(P9_DEBUG_9P, "<<< RWRITE count %d\n", count);
+ if (count > rsize) {
+ WARN_ON(1);
+ count = rsize;
+ }
p9_free_req(clnt, req);
iov_iter_advance(from, count);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mmap: fix the usage of ->vm_pgoff in special_mapping paths
Test-case:
#include
#include
#include
#include
#include
#include
void *find_vdso_vaddr(void)
{
FILE *perl;
char buf[32] = {};
perl = popen("perl -e 'open STDIN,qq|/proc/@{[getppid]}/maps|;"
"/^(.*?)-.*vdso/ && print hex $1 while <>'",
"r");
fread(buf, sizeof(buf), 1, perl);
fclose(perl);
return (void *)atol(buf);
}
#define PAGE_SIZE 4096
int main(void)
{
void *vdso = find_vdso_vaddr();
assert(vdso);
// of course they should differ, and they do so far
printf("vdso pages differ: %d\n",
!!memcmp(vdso, vdso + PAGE_SIZE, PAGE_SIZE));
// split into 2 vma's
assert(mprotect(vdso, PAGE_SIZE, PROT_READ) == 0);
// force another fault on the next check
assert(madvise(vdso, 2 * PAGE_SIZE, MADV_DONTNEED) == 0);
// now they no longer differ, the 2nd vm_pgoff is wrong
printf("vdso pages differ: %d\n",
!!memcmp(vdso, vdso + PAGE_SIZE, PAGE_SIZE));
return 0;
}
Output:
vdso pages differ: 1
vdso pages differ: 0
This is because split_vma() correctly updates ->vm_pgoff, but the logic
in insert_vm_struct() and special_mapping_fault() is absolutely broken,
so the fault at vdso + PAGE_SIZE return the 1st page. The same happens
if you simply unmap the 1st page.
special_mapping_fault() does:
pgoff = vmf->pgoff - vma->vm_pgoff;
and this is _only_ correct if vma->vm_start mmaps the first page from
->vm_private_data array.
vdso or any other user of install_special_mapping() is not anonymous,
it has the "backing storage" even if it is just the array of pages.
So we actually need to make vm_pgoff work as an offset in this array.
Note: this also allows to fix another problem: currently gdb can't access
"[vvar]" memory because in this case special_mapping_fault() doesn't work.
Now that we can use ->vm_pgoff we can implement ->access() and fix this.
Signed-off-by: Oleg Nesterov
---
mm/mmap.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index bb50cac..992417f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2871,7 +2871,7 @@ int insert_vm_struct(struct mm_struct *mm, struct
vm_area_struct *vma)
* using the existing file pgoff checks and manipulations.
* Similarly in do_mmap_pgoff and in do_brk.
*/
- if (!vma->vm_file) {
+ if (vma_is_anonymous(vma)) {
BUG_ON(vma->anon_vma);
vma->vm_pgoff = vma->vm_start >> PAGE_SHIFT;
}
@@ -3013,21 +3013,13 @@ static int special_mapping_fault(struct vm_area_struct
*vma,
pgoff_t pgoff;
struct page **pages;
- /*
-* special mappings have no vm_file, and in that case, the mm
-* uses vm_pgoff internally. So we have to subtract it from here.
-* We are allowed to do this because we are the mm; do not copy
-* this code into drivers!
-*/
- pgoff = vmf->pgoff - vma->vm_pgoff;
-
if (vma->vm_ops == _special_mapping_vmops)
pages = vma->vm_private_data;
else
pages = ((struct vm_special_mapping *)vma->vm_private_data)->
pages;
- for (; pgoff && *pages; ++pages)
+ for (pgoff = vmf->pgoff; pgoff && *pages; ++pages)
pgoff--;
if (*pages) {
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] special_mapping_fault() is broken
On 06/20, Oleg Nesterov wrote: > > Let me first send the changes which look "obviously correct" to me. > Perhaps I'll send more patches on top of this later. But lets also fix another unmap/remap bug before the cleanups... This series doesn't depend on the previous mremap fixes. special_mapping_fault() is absolutely broken. It seems it was always wrong, but this didn't matter until vdso/vvar started to use more than one page. I am not sure about 1/3. As the changelog says the name is not very accurate, and I do not really like the vma->fault != NULL check. But I hope this can work, and we can change this helper later if needed. Please review. Oleg. include/linux/mm.h |5 + mm/memory.c| 13 ++--- mm/mmap.c | 14 +++--- 3 files changed, 14 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mm: introduce vma_is_anonymous(vma) helper
Preparation. Add the new simple helper, vma_is_anonymous(vma),
and change handle_pte_fault() to use it. It will have more users.
The name is not very accurate, say mmap_mem/VM_PFNMAP vma is not
anonymous. Perhaps it should be named vma_has_fault() instead.
But it matches the logic in mmap.c/memory.c, see next changes.
Signed-off-by: Oleg Nesterov
---
include/linux/mm.h |5 +
mm/memory.c| 13 ++---
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0755b9f..a0fe3d3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1225,6 +1225,11 @@ static inline int vma_growsdown(struct vm_area_struct
*vma, unsigned long addr)
return vma && (vma->vm_end == addr) && (vma->vm_flags & VM_GROWSDOWN);
}
+static inline bool vma_is_anonymous(struct vm_area_struct *vma)
+{
+ return !vma->vm_ops || !vma->vm_ops->fault;
+}
+
static inline int stack_guard_page_start(struct vm_area_struct *vma,
unsigned long addr)
{
diff --git a/mm/memory.c b/mm/memory.c
index 22e037e..f50ed81 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3242,13 +3242,12 @@ static int handle_pte_fault(struct mm_struct *mm,
barrier();
if (!pte_present(entry)) {
if (pte_none(entry)) {
- if (vma->vm_ops) {
- if (likely(vma->vm_ops->fault))
- return do_fault(mm, vma, address, pte,
- pmd, flags, entry);
- }
- return do_anonymous_page(mm, vma, address,
-pte, pmd, flags);
+ if (vma_is_anonymous(vma))
+ return do_anonymous_page(mm, vma, address,
+pte, pmd, flags);
+ else
+ return do_fault(mm, vma, address, pte, pmd,
+ flags, entry);
}
return do_swap_page(mm, vma, address,
pte, pmd, flags, entry);
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mremap: fix the wrong !vma->vm_file check in copy_vma()
Test-case:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
void *find_vdso_vaddr(void)
{
FILE *perl;
char buf[32] = {};
perl = popen("perl -e 'open STDIN,qq|/proc/@{[getppid]}/maps|;"
"/^(.*?)-.*vdso/ && print hex $1 while <>'",
"r");
fread(buf, sizeof(buf), 1, perl);
fclose(perl);
return (void *)atol(buf);
}
#define PAGE_SIZE 4096
void *get_unmapped_area(void)
{
void *p = mmap(0, PAGE_SIZE, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
assert(p != MAP_FAILED);
munmap(p, PAGE_SIZE);
return p;
}
char save[2][PAGE_SIZE];
int main(void)
{
void *vdso = find_vdso_vaddr();
void *page[2];
assert(vdso);
memcpy(save, vdso, sizeof (save));
// force another fault on the next check
assert(madvise(vdso, 2 * PAGE_SIZE, MADV_DONTNEED) == 0);
page[0] = mremap(vdso,
PAGE_SIZE, PAGE_SIZE, MREMAP_FIXED |
MREMAP_MAYMOVE,
get_unmapped_area());
page[1] = mremap(vdso + PAGE_SIZE,
PAGE_SIZE, PAGE_SIZE, MREMAP_FIXED |
MREMAP_MAYMOVE,
get_unmapped_area());
assert(page[0] != MAP_FAILED && page[1] != MAP_FAILED);
printf("match: %d %d\n",
!memcmp(save[0], page[0], PAGE_SIZE),
!memcmp(save[1], page[1], PAGE_SIZE));
return 0;
}
fails without this patch. Before the previous commit it gets the wrong
page, now it segfaults (which is imho better).
This is because copy_vma() wrongly assumes that if vma->vm_file == NULL
is irrelevant until the first fault which will use do_anonymous_page().
This is obviously wrong for the special mapping.
Signed-off-by: Oleg Nesterov
---
mm/mmap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 992417f..2185cd9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2905,7 +2905,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
**vmap,
* If anonymous vma has not yet been faulted, update new pgoff
* to match new location, to increase its chance of merging.
*/
- if (unlikely(!vma->vm_file && !vma->anon_vma)) {
+ if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) {
pgoff = addr >> PAGE_SHIFT;
faulted_in_anon_vma = false;
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote: > Nope, well the driver requires huge amounts of work to work with PAT, > that work will likely never be done, so hence the warning. Its our > compromise as only 2 drivers will live on Linux like this and they are > both old and rare. Hmm, so wasn't the possibility discussed to fail loading instead and issue a single-line pr_warn() when PAT is enabled? Those big WARN() splats will only confuse people... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clocksource: stm32: introduce dependency on HAS_IOMEM
Fix allmodconfig compilation failer for ARCH=um: drivers/clocksource/timer-stm32.c: In function 'stm32_clockevent_init': drivers/clocksource/timer-stm32.c:175:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration] iounmap(data->base); ^ Make CLKSRC_STM32 depend on HAS_IOMEM. Signed-off-by: Nicolai Stange --- drivers/clocksource/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 60d7d3d..835e5c5 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -114,6 +114,7 @@ config CLKSRC_LPC32XX config CLKSRC_STM32 bool "Clocksource for STM32 SoCs" if COMPILE_TEST depends on OF + depends on HAS_IOMEM select CLKSRC_MMIO config ARM_ARCH_TIMER -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: comedi: coding style fixes
Warnings found by checkpatch.pl
WARNING: please, no space before tabs
/drivers/staging/comedi/drivers/das16m1.c:83
+ 404-407 ^I8254$
WARNING: line over 80 characters
/drivers/staging/comedi/drivers/das16m1.c:414
+ if (devpriv->adc_count == 0 && hw_counter == devpriv->initial_hw_count) {
/drivers/staging/comedi/drivers/das16m1.c:417
/drivers/staging/comedi/drivers/das16m1.c:418
/drivers/staging/comedi/drivers/das16m1.c:419
/drivers/staging/comedi/drivers/das16m1.c:420
/drivers/staging/comedi/drivers/das16m1.c:421
Signed-off-by: Luis de Bethencourt
---
drivers/staging/comedi/drivers/das16m1.c | 41 +---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/comedi/drivers/das16m1.c
b/drivers/staging/comedi/drivers/das16m1.c
index a18a887..3a37373 100644
--- a/drivers/staging/comedi/drivers/das16m1.c
+++ b/drivers/staging/comedi/drivers/das16m1.c
@@ -69,18 +69,18 @@ irq can be omitted, although the cmd interface will not
work without it.
"cio-das16/m1"
- 0a/d bits 0-3, mux start 12 bit
- 1a/d bits 4-11 unused
- 2status control
- 3di 4 bitdo 4 bit
- 4unused clear interrupt
- 5interrupt, pacer
- 6channel/gain queue address
- 7channel/gain queue data
- 89ab 8254
- cdef 8254
- 400 8255
- 404-407 8254
+ 0a/d bits 0-3, mux start 12 bit
+ 1a/d bits 4-11 unused
+ 2status control
+ 3di 4 bitdo 4 bit
+ 4unused clear interrupt
+ 5interrupt, pacer
+ 6channel/gain queue address
+ 7channel/gain queue data
+ 89ab 8254
+ cdef 8254
+ 400 8255
+ 404-407 8254
*/
@@ -411,15 +411,18 @@ static void das16m1_handler(struct comedi_device *dev,
unsigned int status)
hw_counter = comedi_8254_read(devpriv->counter, 1);
/* make sure hardware counter reading is not bogus due to initial value
* not having been loaded yet */
- if (devpriv->adc_count == 0 && hw_counter == devpriv->initial_hw_count)
{
+ if (devpriv->adc_count == 0 &&
+ hw_counter == devpriv->initial_hw_count) {
num_samples = 0;
} else {
- /* The calculation of num_samples looks odd, but it uses the
following facts.
-* 16 bit hardware counter is initialized with value of zero
(which really
-* means 0x1000). The counter decrements by one on each
conversion
-* (when the counter decrements from zero it goes to 0x).
num_samples
-* is a 16 bit variable, so it will roll over in a similar
fashion to the
-* hardware counter. Work it out, and this is what you get. */
+ /* The calculation of num_samples looks odd, but it uses the
+* following facts. 16 bit hardware counter is initialized with
+* value of zero (which really means 0x1000). The counter
+* decrements by one on each conversion (when the counter
+* decrements from zero it goes to 0x). num_samples is a
+* 16 bit variable, so it will roll over in a similar fashion
+* to the hardware counter. Work it out, and this is what you
+* get. */
num_samples = -hw_counter - devpriv->adc_count;
}
/* check if we only need some of the points */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()
On Sat, Jun 20, 2015 at 01:08:44PM +0200, Borislav Petkov wrote: > On Sat, Jun 20, 2015 at 03:17:56PM +0800, Fengguang Wu wrote: > > Greetings, > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > > > commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a > > Author: Luis R. Rodriguez > > AuthorDate: Mon Jun 15 10:28:16 2015 +0200 > > Commit: Ingo Molnar > > CommitDate: Thu Jun 18 11:23:41 2015 +0200 > > > > x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT > > disabled > > ... > > > [ 12.956506] ivtv: Start initialization, version 1.4.3 > > [ 12.958238] ivtv: End initialization > > [ 12.959438] [ cut here ] > > [ 12.974076] WARNING: CPU: 0 PID: 1 at > > drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init+0x32/0xa3() > > [ 12.978017] ivtvfb needs PAT disabled, boot with nopat kernel parameter > > Warning says it all. You need to boot with "nopat". Apparently, those > devices are very seldom now and users should boot with "nopat". Indeed. > Luis, what is the plan, is this driver supposed to be converted to > reserve_memtype(..., _PAGE_CACHE_MODE_WC, ...) at some point? Nope, well the driver requires huge amounts of work to work with PAT, that work will likely never be done, so hence the warning. Its our compromise as only 2 drivers will live on Linux like this and they are both old and rare. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] TLB flush multiple pages per IPI v5
On Tue, Jun 09, 2015 at 08:34:35AM -0700, Dave Hansen wrote:
> On 06/09/2015 05:43 AM, Ingo Molnar wrote:
> > +static char tlb_flush_target[PAGE_SIZE] __aligned(4096);
> > +static void fn_flush_tlb_one(void)
> > +{
> > + unsigned long addr = (unsigned long)_flush_target;
> > +
> > + tlb_flush_target[0]++;
> > + __flush_tlb_one(addr);
> > +}
>
> So we've got an increment of a variable in kernel memory (which is
> almost surely in the L1), then we flush that memory location, and repeat
> the increment.
BTW, Ingo, have you disabled direct mapping of kernel memory with 2M/1G
pages for the test?
I'm just thinking if there is chance that the test shooting out 1G tlb
entry. In this case we're measure wrong thing.
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 20:55 keltezéssel, Boszormenyi Zoltan írta:
> 2015-06-21 19:55 keltezéssel, Jiang Liu írta:
>> On 2015/6/22 1:25, Jiang Liu wrote:
>> [...]
>> - Memory behind bridge: 8000-801f
>> - Prefetchable memory behind bridge:
>> 8020-803f
>> + Memory behind bridge: ff00-ff1f
>> + Prefetchable memory behind bridge:
>> ff20-ff3f
>>
>> Can't this cause a problem? E.g. programming the bridge with an address
>> range
>> that the bridge doesn't actually support?
> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
> v3.18.16 dmesg log, so we can compare them?
I collected all 3 for you to compare them, compressed, attached.
BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
> the code to see what might be going on:
>
> acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x window]; [mem 0x-0x window]
> ignored
> pci :00:1c.1: can't claim BAR 15 [mem 0xfdf0-0xfdff
> 64bit pref]: address conflict with PCI Bus :00 [mem
> 0xf000-0xfed8 window]
>
> Bjorn
>>> Hi Bjorn and Boszormenyi,
>>> From the 3.18 kernel, we got a message:
>>> [0.126248] acpi PNP0A08:00: host bridge window
>>> [0x4-0xf] (ignored, not CPU addressable)
>>> And from 4.1.-rc8, we got another message:
>>> [0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x-0x window]; [mem 0x-0x window] ignored
>>>
>>> That smells like a 32bit overflow or 64bit cut-off issue.
>> Hi Bjorn and Boszormenyi,
>> With v3.18.6, it uses u64 to compare resource ranges. We changed to use
>> resource_size_t with recent changes, and resource_size_t
>> may be u32 or u64 depending on configuration. So resource range
>> [0x4-0xf] may have been cut-off as
>> [0x-0x], thus cause the trouble.
>>
>> Hi Boszormenyi,
>> Could you please help to try following test patch?
>> against v4.1-rc8?
> I have tried it. The result (dmesg, lspci before/after modprobe) is attached.
> The "not CPU addressable" message shows up once in dmesg.
> The device shows up in lspci and the module can be loaded. The previously
> experienced sluggishness is gone now, but the network doesn't work after
> modprobe.
> I think it was an expected outcome, since that particular range is ignored
> with this patch.
Hm, I can see a very similar message in 3.18.16, so it was not
the expected outcome.
After building the "official" r8168 from Realtek for 4.1.0-rc8,
the difference in lspci from the working 3.18.16 is nil, before
and after modprobe. (r8168 was build for 3.18.16, that's why.)
However, connman (similar to NetworkManager) still sees the network
connectivity as "down". I checked that the firmware files are there in
/lib/firmware/rtl_nic.
With r8168 (the "official" Realtek driver), the kernel message about
"link up" appears immediately and connman can configure the network.
I have tried the patch on 4.0.5, too, with the same result.
So, there may be another problem with the r8169 driver itself besides
this ACPI problem but no matter what I do, I can't seem to be able
to enable debugging messages for r8169.
So, for now I can use r8168 instead of r8169 with this patch.
Thanks,
Zoltán
>
> Thanks,
> Zoltán
>
>> Thanks!
>> Gerry
>> ---
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 8244f013f210..d7b8c392c420 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
>>
>> res->start = attr->minimum;
>> res->end = attr->maximum;
>> + if (res->start != attr->minimum || res->end != attr->maximum) {
>> + pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
>> addressable)\n",
>> + attr->minimum, attr->maximum);
>> + return false;
>> + }
>>
>> /*
>> * For bridges that translate addresses across the bridge,
>> -
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] net: stmmac: dwmac-rk: Fix clk rate when provided by soc
The first iteration of the dwmac-rk support did access an intermediate
clock directly below the pll selector. This was removed in a subsequent
revision, but the clock and one invocation remained. This results in
the driver trying to set the rate of a non-existent clock when the soc
and not some external source provides the phy clock for RMII phys.
So set the rate of the correct clock and remove the remaining now
completely unused definition.
Fixes: 436f5ae08f9d ("GMAC: add driver for Rockchip RK3288 SoCs integrated
GMAC")
Cc: sta...@vger.kernel.org
Signed-off-by: Heiko Stuebner
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index a396070..5dafebb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -42,7 +42,6 @@ struct rk_priv_data {
bool clock_input;
struct clk *clk_mac;
- struct clk *clk_mac_pll;
struct clk *gmac_clkin;
struct clk *mac_clk_rx;
struct clk *mac_clk_tx;
@@ -209,7 +208,7 @@ static int gmac_clk_init(struct rk_priv_data *bsp_priv)
dev_info(dev, "clock input from PHY\n");
} else {
if (bsp_priv->phy_iface == PHY_INTERFACE_MODE_RMII)
- clk_set_rate(bsp_priv->clk_mac_pll, 5000);
+ clk_set_rate(bsp_priv->clk_mac, 5000);
}
return 0;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] net: stmmac: dwmac-rk: add rk3368-specific data
Add constants and callback functions for the dwmac on rk3368 socs.
As can be seen, the base structure is the same, only registers and
the bits in them moved slightly.
Signed-off-by: Heiko Stuebner
---
.../devicetree/bindings/net/rockchip-dwmac.txt | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 126 +
2 files changed, 127 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
index 21fd199..93eac7c 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
@@ -3,7 +3,7 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
The device node has following properties.
Required properties:
- - compatible: Can be "rockchip,rk3288-gmac".
+ - compatible: Can be one of "rockchip,rk3288-gmac", "rockchip,rk3368-gmac"
- reg: addresses and length of the register sets for the device.
- interrupts: Should contain the GMAC interrupts.
- interrupt-names: Should contain the interrupt names "macirq".
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 65afca6..00a1e1e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -184,6 +184,118 @@ struct rk_gmac_ops rk3288_ops = {
.set_rmii_speed = rk3288_set_rmii_speed,
};
+#define RK3368_GRF_SOC_CON15 0x043c
+#define RK3368_GRF_SOC_CON16 0x0440
+
+/* RK3368_GRF_SOC_CON15 */
+#define RK3368_GMAC_PHY_INTF_SEL_RGMII (GRF_BIT(9) | GRF_CLR_BIT(10) | \
+GRF_CLR_BIT(11))
+#define RK3368_GMAC_PHY_INTF_SEL_RMII (GRF_CLR_BIT(9) | GRF_CLR_BIT(10) | \
+GRF_BIT(11))
+#define RK3368_GMAC_FLOW_CTRL GRF_BIT(8)
+#define RK3368_GMAC_FLOW_CTRL_CLR GRF_CLR_BIT(8)
+#define RK3368_GMAC_SPEED_10M GRF_CLR_BIT(7)
+#define RK3368_GMAC_SPEED_100M GRF_BIT(7)
+#define RK3368_GMAC_RMII_CLK_25M GRF_BIT(3)
+#define RK3368_GMAC_RMII_CLK_2_5M GRF_CLR_BIT(3)
+#define RK3368_GMAC_CLK_125M (GRF_CLR_BIT(4) | GRF_CLR_BIT(5))
+#define RK3368_GMAC_CLK_25M(GRF_BIT(4) | GRF_BIT(5))
+#define RK3368_GMAC_CLK_2_5M (GRF_CLR_BIT(4) | GRF_BIT(5))
+#define RK3368_GMAC_RMII_MODE GRF_BIT(6)
+#define RK3368_GMAC_RMII_MODE_CLR GRF_CLR_BIT(6)
+
+/* RK3368_GRF_SOC_CON16 */
+#define RK3368_GMAC_TXCLK_DLY_ENABLE GRF_BIT(7)
+#define RK3368_GMAC_TXCLK_DLY_DISABLE GRF_CLR_BIT(7)
+#define RK3368_GMAC_RXCLK_DLY_ENABLE GRF_BIT(15)
+#define RK3368_GMAC_RXCLK_DLY_DISABLE GRF_CLR_BIT(15)
+#define RK3368_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 8)
+#define RK3368_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
+
+static void rk3368_set_to_rgmii(struct rk_priv_data *bsp_priv,
+ int tx_delay, int rx_delay)
+{
+ struct device *dev = _priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RK3368_GRF_SOC_CON15,
+RK3368_GMAC_PHY_INTF_SEL_RGMII |
+RK3368_GMAC_RMII_MODE_CLR);
+ regmap_write(bsp_priv->grf, RK3368_GRF_SOC_CON16,
+RK3368_GMAC_RXCLK_DLY_ENABLE |
+RK3368_GMAC_TXCLK_DLY_ENABLE |
+RK3368_GMAC_CLK_RX_DL_CFG(rx_delay) |
+RK3368_GMAC_CLK_TX_DL_CFG(tx_delay));
+}
+
+static void rk3368_set_to_rmii(struct rk_priv_data *bsp_priv)
+{
+ struct device *dev = _priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RK3368_GRF_SOC_CON15,
+RK3368_GMAC_PHY_INTF_SEL_RMII | RK3368_GMAC_RMII_MODE);
+}
+
+static void rk3368_set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+ struct device *dev = _priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ if (speed == 10)
+ regmap_write(bsp_priv->grf, RK3368_GRF_SOC_CON15,
+RK3368_GMAC_CLK_2_5M);
+ else if (speed == 100)
+ regmap_write(bsp_priv->grf, RK3368_GRF_SOC_CON15,
+RK3368_GMAC_CLK_25M);
+ else if (speed == 1000)
+ regmap_write(bsp_priv->grf, RK3368_GRF_SOC_CON15,
+RK3368_GMAC_CLK_125M);
+ else
+ dev_err(dev, "unknown speed value for RGMII! speed=%d", speed);
+}
+
+static void rk3368_set_rmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+ struct device *dev =
[PATCH v2 3/4] net: stmmac: dwmac-rk: abstract access to mac settings in GRF
The mac settings like RGMII/RMII, speeds etc are done in the so called
"General Register Files", contain numerous other settings as well and
always seem to change between Rockchip SoCs. Therefore abstract the
register accesses into a per-soc ops struct to make this reusable on
other Rockchip SoCs.
Signed-off-by: Heiko Stuebner
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 116 -
1 file changed, 75 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 5dafebb..65afca6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -33,10 +33,20 @@
#include "stmmac_platform.h"
+struct rk_priv_data;
+struct rk_gmac_ops {
+ void (*set_to_rgmii)(struct rk_priv_data *bsp_priv,
+int tx_delay, int rx_delay);
+ void (*set_to_rmii)(struct rk_priv_data *bsp_priv);
+ void (*set_rgmii_speed)(struct rk_priv_data *bsp_priv, int speed);
+ void (*set_rmii_speed)(struct rk_priv_data *bsp_priv, int speed);
+};
+
struct rk_priv_data {
struct platform_device *pdev;
int phy_iface;
struct regulator *regulator;
+ struct rk_gmac_ops *ops;
bool clk_enabled;
bool clock_input;
@@ -66,30 +76,32 @@ struct rk_priv_data {
#define RK3288_GRF_SOC_CON30x0250
/*RK3288_GRF_SOC_CON1*/
-#define GMAC_PHY_INTF_SEL_RGMII(GRF_BIT(6) | GRF_CLR_BIT(7) |
GRF_CLR_BIT(8))
-#define GMAC_PHY_INTF_SEL_RMII (GRF_CLR_BIT(6) | GRF_CLR_BIT(7) | GRF_BIT(8))
-#define GMAC_FLOW_CTRL GRF_BIT(9)
-#define GMAC_FLOW_CTRL_CLR GRF_CLR_BIT(9)
-#define GMAC_SPEED_10M GRF_CLR_BIT(10)
-#define GMAC_SPEED_100MGRF_BIT(10)
-#define GMAC_RMII_CLK_25M GRF_BIT(11)
-#define GMAC_RMII_CLK_2_5M GRF_CLR_BIT(11)
-#define GMAC_CLK_125M (GRF_CLR_BIT(12) | GRF_CLR_BIT(13))
-#define GMAC_CLK_25M (GRF_BIT(12) | GRF_BIT(13))
-#define GMAC_CLK_2_5M (GRF_CLR_BIT(12) | GRF_BIT(13))
-#define GMAC_RMII_MODE GRF_BIT(14)
-#define GMAC_RMII_MODE_CLR GRF_CLR_BIT(14)
+#define RK3288_GMAC_PHY_INTF_SEL_RGMII (GRF_BIT(6) | GRF_CLR_BIT(7) | \
+GRF_CLR_BIT(8))
+#define RK3288_GMAC_PHY_INTF_SEL_RMII (GRF_CLR_BIT(6) | GRF_CLR_BIT(7) | \
+GRF_BIT(8))
+#define RK3288_GMAC_FLOW_CTRL GRF_BIT(9)
+#define RK3288_GMAC_FLOW_CTRL_CLR GRF_CLR_BIT(9)
+#define RK3288_GMAC_SPEED_10M GRF_CLR_BIT(10)
+#define RK3288_GMAC_SPEED_100M GRF_BIT(10)
+#define RK3288_GMAC_RMII_CLK_25M GRF_BIT(11)
+#define RK3288_GMAC_RMII_CLK_2_5M GRF_CLR_BIT(11)
+#define RK3288_GMAC_CLK_125M (GRF_CLR_BIT(12) | GRF_CLR_BIT(13))
+#define RK3288_GMAC_CLK_25M(GRF_BIT(12) | GRF_BIT(13))
+#define RK3288_GMAC_CLK_2_5M (GRF_CLR_BIT(12) | GRF_BIT(13))
+#define RK3288_GMAC_RMII_MODE GRF_BIT(14)
+#define RK3288_GMAC_RMII_MODE_CLR GRF_CLR_BIT(14)
/*RK3288_GRF_SOC_CON3*/
-#define GMAC_TXCLK_DLY_ENABLE GRF_BIT(14)
-#define GMAC_TXCLK_DLY_DISABLE GRF_CLR_BIT(14)
-#define GMAC_RXCLK_DLY_ENABLE GRF_BIT(15)
-#define GMAC_RXCLK_DLY_DISABLE GRF_CLR_BIT(15)
-#define GMAC_CLK_RX_DL_CFG(val)HIWORD_UPDATE(val, 0x7F, 7)
-#define GMAC_CLK_TX_DL_CFG(val)HIWORD_UPDATE(val, 0x7F, 0)
-
-static void set_to_rgmii(struct rk_priv_data *bsp_priv,
-int tx_delay, int rx_delay)
+#define RK3288_GMAC_TXCLK_DLY_ENABLE GRF_BIT(14)
+#define RK3288_GMAC_TXCLK_DLY_DISABLE GRF_CLR_BIT(14)
+#define RK3288_GMAC_RXCLK_DLY_ENABLE GRF_BIT(15)
+#define RK3288_GMAC_RXCLK_DLY_DISABLE GRF_CLR_BIT(15)
+#define RK3288_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 7)
+#define RK3288_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
+
+static void rk3288_set_to_rgmii(struct rk_priv_data *bsp_priv,
+ int tx_delay, int rx_delay)
{
struct device *dev = _priv->pdev->dev;
@@ -99,14 +111,16 @@ static void set_to_rgmii(struct rk_priv_data *bsp_priv,
}
regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
-GMAC_PHY_INTF_SEL_RGMII | GMAC_RMII_MODE_CLR);
+RK3288_GMAC_PHY_INTF_SEL_RGMII |
+RK3288_GMAC_RMII_MODE_CLR);
regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON3,
-GMAC_RXCLK_DLY_ENABLE | GMAC_TXCLK_DLY_ENABLE |
-GMAC_CLK_RX_DL_CFG(rx_delay) |
-GMAC_CLK_TX_DL_CFG(tx_delay));
+RK3288_GMAC_RXCLK_DLY_ENABLE |
+RK3288_GMAC_TXCLK_DLY_ENABLE |
+RK3288_GMAC_CLK_RX_DL_CFG(rx_delay) |
+RK3288_GMAC_CLK_TX_DL_CFG(tx_delay));
}
-static void set_to_rmii(struct rk_priv_data *bsp_priv)
+static void rk3288_set_to_rmii(struct rk_priv_data *bsp_priv)
{
struct
[PATCH v2 1/4] net: stmmac: dwmac-rk: remove unused gpio register defines
In a first version the driver did want to do some gpio wiggling, which
of course never made it into the kernel, but somehow these register
defines where forgotten. Remove them, as they shouldn't be here.
Signed-off-by: Heiko Stuebner
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 26c339d..a396070 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -65,9 +65,6 @@ struct rk_priv_data {
#define RK3288_GRF_SOC_CON10x0248
#define RK3288_GRF_SOC_CON30x0250
-#define RK3288_GRF_GPIO3D_E0x01ec
-#define RK3288_GRF_GPIO4A_E0x01f0
-#define RK3288_GRF_GPIO4B_E0x01f4
/*RK3288_GRF_SOC_CON1*/
#define GMAC_PHY_INTF_SEL_RGMII(GRF_BIT(6) | GRF_CLR_BIT(7) |
GRF_CLR_BIT(8))
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] net: stmmac: dwmac-rk: add support for rk3368
Apart from small cleanups, this series provides support for the dwmac
on the new rk3368 ARM64 soc.
Tested on a R88 board using a RMII phy.
Changes since v1:
- Adapt to changes resulting from patch d42202dce002 ("net: stmmac:
dwmac-rk: Don't add function name in info or err messages")
Heiko Stuebner (4):
net: stmmac: dwmac-rk: remove unused gpio register defines
net: stmmac: dwmac-rk: Fix clk rate when provided by soc
net: stmmac: dwmac-rk: abstract access to mac settings in GRF
net: stmmac: dwmac-rk: add rk3368-specific data
.../devicetree/bindings/net/rockchip-dwmac.txt | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 248 +
2 files changed, 203 insertions(+), 47 deletions(-)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] FTDI CBUS GPIO support
On 2015-06-21 01:49, Peter Stuge wrote: > Stefan Agner wrote: >> libftdi requires to detach the kernel driver to get access to the device > > Control transfers ought to be possible without a detach. Good to know, thanks for this input. The detach is probably a default behavior of libftdi... Will have a look at that. Having kernel level gpiolib would still have advantages: It would make the matching of the GPIO's and tty device easier, since with this patch the gpiolib device is a sub-node of the usb-serial device in sysfs and the user would have to use kernel interfaces only (no libftdi)... -- Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] FTDI CBUS GPIO support
Hi Philipp, On 2015-06-21 04:22, Philipp Hachtmann wrote: > Am 21.06.2015 um 00:12 schrieb Stefan Agner: >> There are three GPIO modes supported by FTDI devices: >> 1. Asynchronous Bit Bang Mode (used in Sacha's patch) >> 2. Synchronous Bit Bang Mode (used in Philipp's patch) >> 3. CBUS Bit Bang Mode (used in Philipp's patch and this patchset) > > 1. No idea, could be > 2. wrong > 3. wrong The list is taken from FTDI's application note AN_232R-01, which mainly refers to FT232R: http://www.ftdichip.com/Support/Documents/AppNotes/AN_232R-01_Bit_Bang_Mode_Available_For_FT232R_and_Ft245R.pdf However, as far as I understand those three bit bang options are also available on FT232H (maybe there even more on those device?). FTDI calls all 3 of them modes, but one can argue whether the third really is an "operation mode" or just a "functionality" to set the CBUS pins... However, regarding option 2, I see now, your patch was about introducing the option to use the Synchronous _FIFO_ mode which is not the same as the Synchronous Bit Bang mode, hence this is clearly wrong in my list. Sorry about that. > > This is more complicated as I remember. The chip (I speak of FT232H > here, because it's "my" chip) has quite a lot of options. > > Reference: > http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf > > I did not use a bit bang mode. My patches were about synchronous FIFO > mode and CBUS control. I'll try to explain. > > There are eight data lines called ADBUS[7:0] and ten "other" lines > called ACBUS[9:0]. I think we really refer to the same regarding CBUS mode. In the application note above, this mode is called "CBUS Bit Bang"... Your patch also uses FTDI_SIO_SET_BITBANG command 11 with the higher byte set to 0x20 (FTDI_BITMODE_CBUS). > > When the chip is configured (EEPROM!) for UART mode (default), the RX, > TX and modem status lines are assigned to ADBUS[7:0]. ACBUS7 can be > used as an USB voltage detect input (and for nothing else in any case > as it looks). > The other ACBUS lines can be configured for several tasks like TXLED, > RXLED, SLEEP, clock output etc. > The ACBUS5, ACBUS6, ACBUS8 and ACBUS9 can also individually be > configured to I/O mode which the datasheet calls "ACBUS BitBang". > These up to four (depending on user's choice) GPIO lines can be > accessed from the host. They're usable for extra control to attached > hardware. Controlling these CBUS lines was the intent of my CBUS > patch. This is the very same for FT232R devices, just that those devices call the pins CBUS0-3. > > My usblink board (FT232H plus FPGA etc.) makes use of the FT232H's > asynchronous and synchronous FIFO modes. The asynchronous FIFO mode > has to be selected by EEPROM settings. This works out of the box with > the ftdi_sio driver. The driver doesn't notice anything. Just works. > Baud rate settings etc. become meaningless, of course :-) > If you want to get the full USB 2.0 speed you have to use the > synchronous FIFO mode. For this to work the chip has to be eeprom > configured to asynchronous FIFO mode and then the driver has to select > synchronous FIFO mode. This was subject of my other patch. > > The chip has some other more or less cool modes but I have no idea if > and how they work with the ftdi_sio driver. Two of them are named > asynchronous and synchronous BitBang mode. > > Conclusion: > The FTDI chip has different *modes* of operation which can be selected > by eeprom and/or software. The mode determines the use of the *ADBUS* > and some ACBUS pins. Two of modes are called bit bang modes. > > ACBUS bit bang is an additional functionality which is *not to be > confused* with the chip's operation mode! I agree, the (A)CBUS bit bang "mode" is somewhat different as it doesn't alter the functionality of the chip beyond the ability to use the configured CBUS pins.. > > The confusion comes from things like FTDI_SIO_SET_BITBANG_REQUEST to > do anything... > > I have not forgotten about the comments on my patches a year ago. I > just did not yet find the time to do add that GPIO stuff. > > Two interfaces have to be added to the driver: > > - One for setting the mode (here: switch to synchronous FIFO) > I suggest adding a sysfs property here. > > - One for the four CBUS bits > I *still* suggest adding a sysfs property *and* adding GPIO support as well. The only drawback in using gpiolib compared to sysfs is that some USB control messages could be avoided since one can control the direction and values of 4 pins using one byte and one USB control transfer. However, since this mode is anyway not really meant as a high performance bit bang mode, I think the overhead of gpiolib is acceptable. It certainly is for my use case. > > I will most probably get back to the stuff in July. Ok cool. If that is ok for you, I will still work on this basic CBUS mode, I guess your patches could easily be rebased on-top of my work. -- Stefan -- To unsubscribe from this list: send the
[PATCH] lib: test_bpf: purge CPP register redefinitions
Fix compilation failer with allmodconfig on ARCH=um:
lib/test_bpf.c:50:0: warning: "R8" redefined
#define R8 BPF_REG_8
^
In file included from arch/um/include/asm/ptrace-generic.h:11:0,
from arch/x86/um/asm/ptrace.h:8,
from arch/x86/include/asm/alternative.h:8,
from arch/x86/include/asm/bitops.h:16,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from lib/test_bpf.c:19:
arch/x86/include/uapi/asm/ptrace-abi.h:42:0:
note: this is the location of the previous definition
#define R8 72
Get rid of the
#define Rx BPF_REG_x
defines by substituting the Rx macros with their BPF_REG_x expansion
in test_bpf.c.
Signed-off-by: Nicolai Stange
---
Tested:
- compilation for ARCH=x86_64 and ARCH=um
- 'modprobe test_bpf' on ARCH=x86_64
lib/test_bpf.c | 2374
1 file changed, 1193 insertions(+), 1181 deletions(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 7f58c73..8618325 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -39,19 +39,6 @@
#define SKB_DEV_IFINDEX577
#define SKB_DEV_TYPE 588
-/* Redefine REGs to make tests less verbose */
-#define R0 BPF_REG_0
-#define R1 BPF_REG_1
-#define R2 BPF_REG_2
-#define R3 BPF_REG_3
-#define R4 BPF_REG_4
-#define R5 BPF_REG_5
-#define R6 BPF_REG_6
-#define R7 BPF_REG_7
-#define R8 BPF_REG_8
-#define R9 BPF_REG_9
-#define R10BPF_REG_10
-
/* Flags that can be passed to test cases */
#define FLAG_NO_DATA BIT(0)
#define FLAG_EXPECTED_FAIL BIT(1)
@@ -274,11 +261,11 @@ static int bpf_fill_maxinsns9(struct bpf_test *self)
return -ENOMEM;
insn[0] = BPF_JMP_IMM(BPF_JA, 0, 0, len - 2);
- insn[1] = BPF_ALU32_IMM(BPF_MOV, R0, 0xcbababab);
+ insn[1] = BPF_ALU32_IMM(BPF_MOV, BPF_REG_0, 0xcbababab);
insn[2] = BPF_EXIT_INSN();
for (i = 3; i < len - 2; i++)
- insn[i] = BPF_ALU32_IMM(BPF_MOV, R0, 0xfefefefe);
+ insn[i] = BPF_ALU32_IMM(BPF_MOV, BPF_REG_0, 0xfefefefe);
insn[len - 2] = BPF_EXIT_INSN();
insn[len - 1] = BPF_JMP_IMM(BPF_JA, 0, 0, -(len - 1));
@@ -305,7 +292,7 @@ static int bpf_fill_maxinsns10(struct bpf_test *self)
insn[i] = BPF_JMP_IMM(BPF_JA, 0, 0, hlen - 1 - 2 * i);
insn[hlen / 2] = BPF_JMP_IMM(BPF_JA, 0, 0, hlen / 2 - 1);
- insn[hlen] = BPF_ALU32_IMM(BPF_MOV, R0, 0xabababac);
+ insn[hlen] = BPF_ALU32_IMM(BPF_MOV, BPF_REG_0, 0xabababac);
insn[hlen + 1] = BPF_EXIT_INSN();
self->u.ptr.insns = insn;
@@ -974,13 +961,13 @@ static struct bpf_test tests[] = {
{
"INT: ADD trivial",
.u.insns_int = {
- BPF_ALU64_IMM(BPF_MOV, R1, 1),
- BPF_ALU64_IMM(BPF_ADD, R1, 2),
- BPF_ALU64_IMM(BPF_MOV, R2, 3),
- BPF_ALU64_REG(BPF_SUB, R1, R2),
- BPF_ALU64_IMM(BPF_ADD, R1, -1),
- BPF_ALU64_IMM(BPF_MUL, R1, 3),
- BPF_ALU64_REG(BPF_MOV, R0, R1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_1, 1),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, 2),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_2, 3),
+ BPF_ALU64_REG(BPF_SUB, BPF_REG_1, BPF_REG_2),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -1),
+ BPF_ALU64_IMM(BPF_MUL, BPF_REG_1, 3),
+ BPF_ALU64_REG(BPF_MOV, BPF_REG_0, BPF_REG_1),
BPF_EXIT_INSN(),
},
INTERNAL,
@@ -990,13 +977,13 @@ static struct bpf_test tests[] = {
{
"INT: MUL_X",
.u.insns_int = {
- BPF_ALU64_IMM(BPF_MOV, R0, -1),
- BPF_ALU64_IMM(BPF_MOV, R1, -1),
- BPF_ALU64_IMM(BPF_MOV, R2, 3),
- BPF_ALU64_REG(BPF_MUL, R1, R2),
- BPF_JMP_IMM(BPF_JEQ, R1, 0xfffd, 1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_0, -1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_1, -1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_2, 3),
+ BPF_ALU64_REG(BPF_MUL, BPF_REG_1, BPF_REG_2),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0xfffd, 1),
BPF_EXIT_INSN(),
- BPF_ALU64_IMM(BPF_MOV, R0, 1),
+ BPF_ALU64_IMM(BPF_MOV, BPF_REG_0, 1),
BPF_EXIT_INSN(),
},
INTERNAL,
@@ -1006,14 +993,14 @@ static struct
Re: [RFC v2 3/3] mm: make swapin readahead to improve thp collapse rate
On Sun, Jun 21, 2015 at 09:11:31PM +0300, Kirill A. Shutemov wrote: > On Sat, Jun 20, 2015 at 02:28:06PM +0300, Ebru Akagunduz wrote: > > + /* pte is unmapped now, we need to map it */ > > + pte = pte_offset_map(pmd, _address); > > No, it's within the same pte page table. It should be mapped with > pte_offset_map() above. Ahh.. do_swap_page() will unmap it. Probably worth rewording the comment. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 19:55 keltezéssel, Jiang Liu írta:
> On 2015/6/22 1:25, Jiang Liu wrote:
> [...]
> - Memory behind bridge: 8000-801f
> - Prefetchable memory behind bridge:
> 8020-803f
> + Memory behind bridge: ff00-ff1f
> + Prefetchable memory behind bridge:
> ff20-ff3f
>
> Can't this cause a problem? E.g. programming the bridge with an address
> range
> that the bridge doesn't actually support?
This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
v3.18.16 dmesg log, so we can compare them?
>>> I collected all 3 for you to compare them, compressed, attached.
>>>
>>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>>
These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
the code to see what might be going on:
acpi PNP0A08:00: host bridge window expanded to [mem
0x-0x window]; [mem 0x-0x window]
ignored
pci :00:1c.1: can't claim BAR 15 [mem 0xfdf0-0xfdff
64bit pref]: address conflict with PCI Bus :00 [mem
0xf000-0xfed8 window]
Bjorn
>> Hi Bjorn and Boszormenyi,
>> From the 3.18 kernel, we got a message:
>> [0.126248] acpi PNP0A08:00: host bridge window
>> [0x4-0xf] (ignored, not CPU addressable)
>> And from 4.1.-rc8, we got another message:
>> [0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x-0x window]; [mem 0x-0x window] ignored
>>
>> That smells like a 32bit overflow or 64bit cut-off issue.
> Hi Bjorn and Boszormenyi,
> With v3.18.6, it uses u64 to compare resource ranges. We changed to use
> resource_size_t with recent changes, and resource_size_t
> may be u32 or u64 depending on configuration. So resource range
> [0x4-0xf] may have been cut-off as
> [0x-0x], thus cause the trouble.
>
> Hi Boszormenyi,
> Could you please help to try following test patch?
> against v4.1-rc8?
I have tried it. The result (dmesg, lspci before/after modprobe) is attached.
The "not CPU addressable" message shows up once in dmesg.
The device shows up in lspci and the module can be loaded. The previously
experienced sluggishness is gone now, but the network doesn't work after
modprobe.
I think it was an expected outcome, since that particular range is ignored with
this patch.
Thanks,
Zoltán
> Thanks!
> Gerry
> ---
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 8244f013f210..d7b8c392c420 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
>
> res->start = attr->minimum;
> res->end = attr->maximum;
> + if (res->start != attr->minimum || res->end != attr->maximum) {
> + pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
> addressable)\n",
> + attr->minimum, attr->maximum);
> + return false;
> + }
>
> /*
> * For bridges that translate addresses across the bridge,
> -
>
dmesg-lspci-xx2.tgz
Description: application/compressed-tar
Noodzaak van een lening / Need A Loan?
Are you looking to expand production, purchase new equipment,start a business,expand your markets or access working capital for a special project? Do you need a business or personal Loan? Take the next step and contact us for a financial solution. Email us today: assuredguarantyfinanc...@yahoo.com Bent u op zoek naar uitbreiding van de productie, de aankoop van nieuwe apparatuur, een bedrijf te starten, uitbreiden van uw markten of toegang tot werkkapitaal voor een speciaal project? Heeft u een bedrijf of een persoonlijke lening nodig? Neem de volgende stap en contact met ons op voor een financiële oplossing. E-mail ons vandaag: assuredguarantyfinanc...@yahoo.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 19:25 keltezéssel, Jiang Liu írta: > On 2015/6/21 22:19, Boszormenyi Zoltan wrote: >> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: >>> [+cc linux-pci] >>> >>> Hi Boszormenyi, >>> >>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan wrote: Hi, please, cc me, I am not subscribed to lkml. > Hi, > > [lkml.org still broken --> no accurate mail header info possible...] > > Just to ask the obvious: > I assume using /sys/bus/pci/rescan does not help once it's broken? > (since the machine comes up empty at initial-boot scan, too) I will try it, too, but I am not sure it would work. Currently I can't test it because the last time I completely discharged the battery. I also disconnected it to be able to get the realtek chip back immediately for faster testing. Now, that I have reconnected the battery, I need to wait for it to be charged somewhat to be able to reproduce losing the network chip. > Also, you could try diffing lspci -vvxxx -s output > of working vs. "distorting" kernel version - perhaps some register setup > has been changed (e.g. due to power management improvements or some such), > which may encourage the card > to get a problematic/corrupt state. I attached a tarball that contains lspci -vvxxx for - all devices / only the network chip - before / after "modprobe r8169" - for all 3 kernel versions tested. I figured out that if I type the modprobe and lspci in the same command line, I can get diagnostics out of the machine, after all. It's not just the Realtek chip that has changed parameters. (Vague idea) I noticed that some devices have changed like this: - Memory behind bridge: 8000-801f - Prefetchable memory behind bridge: 8020-803f + Memory behind bridge: ff00-ff1f + Prefetchable memory behind bridge: ff20-ff3f Can't this cause a problem? E.g. programming the bridge with an address range that the bridge doesn't actually support? >>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You >>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a >>> v3.18.16 dmesg log, so we can compare them? >> I collected all 3 for you to compare them, compressed, attached. >> >> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0 >> as suspicious. I will try the 4.0/4.1 kernels with this one reverted. >> >>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at >>> the code to see what might be going on: >>> >>> acpi PNP0A08:00: host bridge window expanded to [mem >>> 0x-0x window]; [mem 0x-0x window] >>> ignored >>> pci :00:1c.1: can't claim BAR 15 [mem 0xfdf0-0xfdff >>> 64bit pref]: address conflict with PCI Bus :00 [mem >>> 0xf000-0xfed8 window] >>> >>> Bjorn > Hi Bjorn and Boszormenyi, > From the 3.18 kernel, we got a message: > [0.126248] acpi PNP0A08:00: host bridge window > [0x4-0xf] (ignored, not CPU addressable) > And from 4.1.-rc8, we got another message: > [0.127051] acpi PNP0A08:00: host bridge window expanded to [mem > 0x-0x window]; [mem 0x-0x window] ignored > > That smells like a 32bit overflow or 64bit cut-off issue. > > Hi Boszormenyi, could you please help to provide acpidump from the > machine? I already did in a previous mail which was only sent to LKML, but here it is again. Thanks, Zoltán > Thanks! > Gerry > > > > acpidump.tgz Description: application/compressed-tar
Re: [RFC v2 3/3] mm: make swapin readahead to improve thp collapse rate
On Sat, Jun 20, 2015 at 02:28:06PM +0300, Ebru Akagunduz wrote:
> This patch makes swapin readahead to improve thp collapse rate.
> When khugepaged scanned pages, there can be a few of the pages
> in swap area.
>
> With the patch THP can collapse 4kB pages into a THP when
> there are up to max_ptes_swap swap ptes in a 2MB range.
>
> The patch was tested with a test program that allocates
> 800MB of memory, writes to it, and then sleeps. I force
> the system to swap out all. Afterwards, the test program
> touches the area by writing, it skips a page in each
> 20 pages of the area.
>
> Without the patch, system did not swap in readahead.
> THP rate was %47 of the program of the memory, it
> did not change over time.
>
> With this patch, after 10 minutes of waiting khugepaged had
> collapsed %99 of the program's memory.
>
> Signed-off-by: Ebru Akagunduz
> Acked-by: Rik van Riel
> ---
> Changes in v2:
> - Use FAULT_FLAG_ALLOW_RETRY|FAULT_FLAG_RETRY_NOWAIT flag
>instead of 0x0 when called do_swap_page
>from __collapse_huge_page_swapin
>
> Test results:
>
> After swapped out
> ---
> | Anonymous | AnonHugePages | Swap | Fraction |
> ---
> With patch| 265772 kB | 264192 kB | 534232 kB |%99|
> ---
> Without patch | 238160 kB | 235520 kB | 561844 kB |%98|
> ---
>
> After swapped in
> ---
> | Anonymous | AnonHugePages | Swap | Fraction |
> ---
> With patch| 532756 kB | 528384 kB | 267248 kB |%99|
> ---
> Without patch | 499956 kB | 235520 kB | 300048 kB |%47|
> ---
>
> include/linux/mm.h | 4
> include/trace/events/huge_memory.h | 24
> mm/huge_memory.c | 37 +
> mm/memory.c| 2 +-
> 4 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 7f47178..f66ff8a 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -29,6 +29,10 @@ struct user_struct;
> struct writeback_control;
> struct bdi_writeback;
>
> +extern int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
> + unsigned long address, pte_t *page_table, pmd_t *pmd,
> + unsigned int flags, pte_t orig_pte);
> +
> #ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly */
> extern unsigned long max_mapnr;
>
> diff --git a/include/trace/events/huge_memory.h
> b/include/trace/events/huge_memory.h
> index 53c9f2e..0117ab9 100644
> --- a/include/trace/events/huge_memory.h
> +++ b/include/trace/events/huge_memory.h
> @@ -95,5 +95,29 @@ TRACE_EVENT(mm_collapse_huge_page_isolate,
> __entry->writable)
> );
>
> +TRACE_EVENT(mm_collapse_huge_page_swapin,
> +
> + TP_PROTO(struct mm_struct *mm, unsigned long vm_start, int swap_pte),
> +
> + TP_ARGS(mm, vm_start, swap_pte),
> +
> + TP_STRUCT__entry(
> + __field(struct mm_struct *, mm)
> + __field(unsigned long, vm_start)
> + __field(int, swap_pte)
> + ),
> +
> + TP_fast_assign(
> + __entry->mm = mm;
> + __entry->vm_start = vm_start;
> + __entry->swap_pte = swap_pte;
> + ),
> +
> + TP_printk("mm=%p, vm_start=%04lx, swap_pte=%d",
> + __entry->mm,
> + __entry->vm_start,
> + __entry->swap_pte)
> +);
> +
> #endif /* __HUGE_MEMORY_H */
> #include
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 22bc0bf..064fd72 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2496,6 +2496,41 @@ static bool hugepage_vma_check(struct vm_area_struct
> *vma)
> return true;
> }
>
> +/*
> + * Bring missing pages in from swap, to complete THP collapse.
> + * Only done if khugepaged_scan_pmd believes it is worthwhile.
> + *
> + * Called and returns without pte mapped or spinlocks held,
> + * but with mmap_sem held to protect against vma changes.
> + */
> +
> +static void __collapse_huge_page_swapin(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long address, pmd_t *pmd,
> + pte_t *pte)
> +{
> + unsigned long _address;
> + pte_t pteval = *pte;
> + int swap_pte = 0;
> +
> + pte = pte_offset_map(pmd,
Re: [PATCH 3/4] media: pxa_camera: trivial move of dma irq functions
Guennadi Liakhovetski writes: > On Sat, 20 Jun 2015, Robert Jarzmik wrote: > >> Guennadi Liakhovetski writes: >> >> >> +static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev, >> >> +enum pxa_camera_active_dma act_dma); >> >> + >> >> +static void pxa_camera_dma_irq_y(void *data) >> > >> > Wait, how is this patch trivial? You change pxa_camera_dma_irq_?() >> > prototypes, which are used as PXA DMA callbacks. Does this mean, that >> > either before or after this patch compilation is broken? >> >> Jeez you're right. >> So I can either fold that with patch 4, or try to rework it somehow ... > > How about letting that patch do exactly what it says it does? Just move > functions up in the file if you need them there, without changing them, > and only change them when it's needed? Deal, for next iteration. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[tip:timers/core] clocksource: Increase dependencies of timer-stm32 to limit build wreckage
Commit-ID: 1cb6c2151850584ee805fdcf088af0bb81f4b086
Gitweb: http://git.kernel.org/tip/1cb6c2151850584ee805fdcf088af0bb81f4b086
Author: Paul Gortmaker
AuthorDate: Sat, 20 Jun 2015 19:02:32 -0400
Committer: Thomas Gleixner
CommitDate: Sun, 21 Jun 2015 20:01:48 +0200
clocksource: Increase dependencies of timer-stm32 to limit build wreckage
This driver leaks out into arch/parisc builds that don't have
CONFIG_GENERIC_CLOCKEVENTS, leading to the following (truncated)
wreckage:
CC drivers/clocksource/timer-stm32.o
drivers/clocksource/timer-stm32.c:38:28: error: field 'evtdev' has incomplete
type
drivers/clocksource/timer-stm32.c:44:19: warning: 'enum clock_event_mode'
declared inside parameter list
drivers/clocksource/timer-stm32.c:44:19: warning: its scope is only this
definition or declaration, which is probably not what you want
drivers/clocksource/timer-stm32.c:43:62: error: parameter 1 ('mode') has
incomplete type
drivers/clocksource/timer-stm32.c:43:13: error: function declaration isn't a
prototype
drivers/clocksource/timer-stm32.c: In function 'stm32_clock_event_set_mode':
drivers/clocksource/timer-stm32.c:47:3: error: type defaults to 'int' in
declaration of '__mptr'
drivers/clocksource/timer-stm32.c:47:3: warning: initialization from
incompatible pointer type
drivers/clocksource/timer-stm32.c:51:7: error: 'CLOCK_EVT_MODE_PERIODIC'
undeclared (first use in this function)
drivers/clocksource/timer-stm32.c:51:7: note: each undeclared identifier is
reported only once for each function it appears in
drivers/clocksource/timer-stm32.c:56:7: error: 'CLOCK_EVT_MODE_ONESHOT'
undeclared (first use in this function)
Tighten up the dependencies to limit where it gets built by copying
the style of the Kconfig line for CLKSRC_EFM32 a few lines above.
Signed-off-by: Paul Gortmaker
Cc: Linus Walleij
Cc: Chanwoo Choi
Cc: Maxime Coquelin
Cc: Daniel Lezcano
Link:
http://lkml.kernel.org/r/1434841352-24300-1-git-send-email-paul.gortma...@windriver.com
Signed-off-by: Thomas Gleixner
---
drivers/clocksource/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index bec25b3..32164ba 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -112,8 +112,8 @@ config CLKSRC_LPC32XX
select CLKSRC_OF
config CLKSRC_STM32
- bool "Clocksource for STM32 SoCs" if COMPILE_TEST
- depends on OF
+ bool "Clocksource for STM32 SoCs" if !ARCH_STM32
+ depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
select CLKSRC_MMIO
config ARM_ARCH_TIMER
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] isdn: disable HiSax NetJet driver on microblaze arch
David Miller writes:
>> Note that endianess on microblaze is not determined through Kconfig,
>> but by means of a compiler provided CPP macro, namely __MICROBLAZEEL__.
>> However, gcc defaults to big endianess on that platform.
> Applied, but we're long overdue for an across-the-board-available
> endianness Kconfig option that can flat out be used in these situations.
> The current way this is handled is at best, a mess.
Thanks!
Regarding the general Kconfig endianess symbol, I will do another patch
based on the information of
git grep '_endian\.h' -- arch/
and supply every arch with either of CONFIG_CPU_{LITTLE,BIG}_ENDIAN if
lacking.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
On 2015/6/22 1:25, Jiang Liu wrote:
[...]
- Memory behind bridge: 8000-801f
- Prefetchable memory behind bridge:
8020-803f
+ Memory behind bridge: ff00-ff1f
+ Prefetchable memory behind bridge:
ff20-ff3f
Can't this cause a problem? E.g. programming the bridge with an address
range
that the bridge doesn't actually support?
>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>> v3.18.16 dmesg log, so we can compare them?
>>
>> I collected all 3 for you to compare them, compressed, attached.
>>
>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>
>>>
>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>> the code to see what might be going on:
>>>
>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x-0x window]; [mem 0x-0x window]
>>> ignored
>>> pci :00:1c.1: can't claim BAR 15 [mem 0xfdf0-0xfdff
>>> 64bit pref]: address conflict with PCI Bus :00 [mem
>>> 0xf000-0xfed8 window]
>>>
>>> Bjorn
> Hi Bjorn and Boszormenyi,
> From the 3.18 kernel, we got a message:
> [0.126248] acpi PNP0A08:00: host bridge window
> [0x4-0xf] (ignored, not CPU addressable)
> And from 4.1.-rc8, we got another message:
> [0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x window]; [mem 0x-0x window] ignored
>
> That smells like a 32bit overflow or 64bit cut-off issue.
Hi Bjorn and Boszormenyi,
With v3.18.6, it uses u64 to compare resource ranges. We changed to use
resource_size_t with recent changes, and resource_size_t
may be u32 or u64 depending on configuration. So resource range
[0x4-0xf] may have been cut-off as
[0x-0x], thus cause the trouble.
Hi Boszormenyi,
Could you please help to try following test patch?
against v4.1-rc8?
Thanks!
Gerry
---
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..d7b8c392c420 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
res->start = attr->minimum;
res->end = attr->maximum;
+ if (res->start != attr->minimum || res->end != attr->maximum) {
+ pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
addressable)\n",
+ attr->minimum, attr->maximum);
+ return false;
+ }
/*
* For bridges that translate addresses across the bridge,
-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 2/3] mm: make optimistic check for swapin readahead
On Sat, Jun 20, 2015 at 02:28:05PM +0300, Ebru Akagunduz wrote:
> This patch makes optimistic check for swapin readahead
> to increase thp collapse rate. Before getting swapped
> out pages to memory, checks them and allows up to a
> certain number. It also prints out using tracepoints
> amount of unmapped ptes.
>
> Signed-off-by: Ebru Akagunduz
> ---
> Changes in v2:
> - Nothing changed
>
> include/trace/events/huge_memory.h | 11 +++
> mm/huge_memory.c | 13 ++---
> 2 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/include/trace/events/huge_memory.h
> b/include/trace/events/huge_memory.h
> index 4b9049b..53c9f2e 100644
> --- a/include/trace/events/huge_memory.h
> +++ b/include/trace/events/huge_memory.h
> @@ -9,9 +9,9 @@
> TRACE_EVENT(mm_khugepaged_scan_pmd,
>
> TP_PROTO(struct mm_struct *mm, unsigned long vm_start, bool writable,
> - bool referenced, int none_or_zero, int collapse),
> + bool referenced, int none_or_zero, int collapse, int unmapped),
>
> - TP_ARGS(mm, vm_start, writable, referenced, none_or_zero, collapse),
> + TP_ARGS(mm, vm_start, writable, referenced, none_or_zero, collapse,
> unmapped),
>
> TP_STRUCT__entry(
> __field(struct mm_struct *, mm)
> @@ -20,6 +20,7 @@ TRACE_EVENT(mm_khugepaged_scan_pmd,
> __field(bool, referenced)
> __field(int, none_or_zero)
> __field(int, collapse)
> + __field(int, unmapped)
> ),
>
> TP_fast_assign(
> @@ -29,15 +30,17 @@ TRACE_EVENT(mm_khugepaged_scan_pmd,
> __entry->referenced = referenced;
> __entry->none_or_zero = none_or_zero;
> __entry->collapse = collapse;
> + __entry->unmapped = unmapped;
> ),
>
> - TP_printk("mm=%p, vm_start=%04lx, writable=%d, referenced=%d,
> none_or_zero=%d, collapse=%d",
> + TP_printk("mm=%p, vm_start=%04lx, writable=%d, referenced=%d,
> none_or_zero=%d, collapse=%d, unmapped=%d",
> __entry->mm,
> __entry->vm_start,
> __entry->writable,
> __entry->referenced,
> __entry->none_or_zero,
> - __entry->collapse)
> + __entry->collapse,
> + __entry->unmapped)
> );
>
> TRACE_EVENT(mm_collapse_huge_page,
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9bb97fc..22bc0bf 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -2639,11 +2640,11 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> {
> pmd_t *pmd;
> pte_t *pte, *_pte;
> - int ret = 0, none_or_zero = 0;
> + int ret = 0, none_or_zero = 0, unmapped = 0;
> struct page *page;
> unsigned long _address;
> spinlock_t *ptl;
> - int node = NUMA_NO_NODE;
> + int node = NUMA_NO_NODE, max_ptes_swap = HPAGE_PMD_NR/8;
I think this deserve sysfs knob. Like we have for
khugepaged_max_ptes_none.
> bool writable = false, referenced = false;
>
> VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> @@ -2657,6 +2658,12 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> for (_address = address, _pte = pte; _pte < pte+HPAGE_PMD_NR;
>_pte++, _address += PAGE_SIZE) {
> pte_t pteval = *_pte;
> + if (is_swap_pte(pteval)) {
IIRC, is_swap_pte() is true for migration entries too,
Should we distinguish swap entries from migration entries here?
I guess no. On other hand we can expect migration entires to be converted
to normal ptes soon...
> + if (++unmapped <= max_ptes_swap)
> + continue;
> + else
> + goto out_unmap;
> + }
> if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
> if (!userfaultfd_armed(vma) &&
> ++none_or_zero <= khugepaged_max_ptes_none)
> @@ -2701,7 +2708,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> out_unmap:
> pte_unmap_unlock(pte, ptl);
> trace_mm_khugepaged_scan_pmd(mm, vma->vm_start, writable, referenced,
> - none_or_zero, ret);
> + none_or_zero, ret, unmapped);
> if (ret) {
> node = khugepaged_find_target_node();
> /* collapse_huge_page will return with the mmap_sem released */
> --
> 1.9.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 1/3] mm: add tracepoint for scanning pages
On Sat, Jun 20, 2015 at 02:28:04PM +0300, Ebru Akagunduz wrote: > Using static tracepoints, data of functions is recorded. > It is good to automatize debugging without doing a lot > of changes in the source code. > > This patch adds tracepoint for khugepaged_scan_pmd, > collapse_huge_page and __collapse_huge_page_isolate. > > Signed-off-by: Ebru Akagunduz > Acked-by: Rik van Riel Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
On 2015/6/21 22:19, Boszormenyi Zoltan wrote: > 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: >> [+cc linux-pci] >> >> Hi Boszormenyi, >> >> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan wrote: >>> Hi, >>> >>> please, cc me, I am not subscribed to lkml. >>> Hi, [lkml.org still broken --> no accurate mail header info possible...] Just to ask the obvious: I assume using /sys/bus/pci/rescan does not help once it's broken? (since the machine comes up empty at initial-boot scan, too) >>> I will try it, too, but I am not sure it would work. >>> >>> Currently I can't test it because the last time I completely discharged >>> the battery. I also disconnected it to be able to get the realtek chip back >>> immediately for faster testing. Now, that I have reconnected the battery, >>> I need to wait for it to be charged somewhat to be able to reproduce >>> losing the network chip. >>> Also, you could try diffing lspci -vvxxx -s output of working vs. "distorting" kernel version - perhaps some register setup has been changed (e.g. due to power management improvements or some such), which may encourage the card to get a problematic/corrupt state. >>> I attached a tarball that contains lspci -vvxxx for >>> - all devices / only the network chip >>> - before / after "modprobe r8169" >>> - for all 3 kernel versions tested. >>> >>> I figured out that if I type the modprobe and lspci in the same command >>> line, >>> I can get diagnostics out of the machine, after all. >>> >>> It's not just the Realtek chip that has changed parameters. >>> >>> (Vague idea) I noticed that some devices have changed like this: >>> >>> - Memory behind bridge: 8000-801f >>> - Prefetchable memory behind bridge: 8020-803f >>> + Memory behind bridge: ff00-ff1f >>> + Prefetchable memory behind bridge: ff20-ff3f >>> >>> Can't this cause a problem? E.g. programming the bridge with an address >>> range >>> that the bridge doesn't actually support? >> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You >> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a >> v3.18.16 dmesg log, so we can compare them? > > I collected all 3 for you to compare them, compressed, attached. > > BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0 > as suspicious. I will try the 4.0/4.1 kernels with this one reverted. > >> >> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at >> the code to see what might be going on: >> >> acpi PNP0A08:00: host bridge window expanded to [mem >> 0x-0x window]; [mem 0x-0x window] >> ignored >> pci :00:1c.1: can't claim BAR 15 [mem 0xfdf0-0xfdff >> 64bit pref]: address conflict with PCI Bus :00 [mem >> 0xf000-0xfed8 window] >> >> Bjorn Hi Bjorn and Boszormenyi, From the 3.18 kernel, we got a message: [0.126248] acpi PNP0A08:00: host bridge window [0x4-0xf] (ignored, not CPU addressable) And from 4.1.-rc8, we got another message: [0.127051] acpi PNP0A08:00: host bridge window expanded to [mem 0x-0x window]; [mem 0x-0x window] ignored That smells like a 32bit overflow or 64bit cut-off issue. Hi Boszormenyi, could you please help to provide acpidump from the machine? Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] net: stmmac: dwmac-rk: add support for rk3368
From: Heiko Stuebner Date: Wed, 17 Jun 2015 23:54:42 +0200 > Apart from small cleanups, this series provides support for the dwmac > on the new rk3368 ARM64 soc. > > Tested on a R88 board using a RMII phy. These patches do not apply to the net-next tree, please respin and resubmit. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv6: Fixed source specific default route handling.
On 05/05/2015 12:36 PM, Markus Stenberg wrote: > If there are only IPv6 source specific default routes present, the > host gets -ENETUNREACH on e.g. connect() because ip6_dst_lookup_tail > calls ip6_route_output first, and given source address any, it fails, > and ip6_route_get_saddr is never called. > > The change is to use the ip6_route_get_saddr, even if the initial > ip6_route_output fails, and then doing ip6_route_output _again_ after > we have appropriate source address available. > > Note that this is '99% fix' to the problem; a correct fix would be to > do route lookups only within addrconf.c when picking a source address, > and never call ip6_route_output before source address has been > populated. > > Signed-off-by: Markus Stenberg > --- > net/ipv6/ip6_output.c | 39 +++ > net/ipv6/route.c | 5 +++-- > 2 files changed, 34 insertions(+), 10 deletions(-) > ... So... how does ip6_route_get_saddr() select the source address when no route is given? OpenWrt has recently started relying on this patch and I'm seeing quite weird source address selection behaviour (@Steven: especially since OpenWrt commit r45941). Steps to reproduce: ip l add test link eth0 type macvlan ip l set test up ip a add fd00::20/64 dev eth0 ip a add fd00::1/128 dev test Upto here everything is okay, ping6 fd00::10 will use the correct source address fd00::20. Now I add an additional source-specific route: ip r add fd00::/64 from fd00::/64 dev eth0 (this certainly looks like a contrived example, but the configuration OpenWrt's netifd/odhcp6c creates is similar) Without this patch, the ping will fail with 'network unreachable' (which is weird by itself - why does the source-specific route shadow the generic route even though no source address has been chosen?). But after applying this patch, the kernel will now choose the address with the longest common prefix with the destination, which is fd00::1 - even though this address is assigned as /128. Adding a prefsrc attribute to the source-specific route doesn't have an effect as ip6_route_get_saddr() doesn't even get the route when the non-source-specific ip6_route_output() has failed. Thus, there's currently no way (to my knowledge) to specify the source address to use when source-specific routes are involved... Matthias signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/4] media: pxa_camera: conversion to dmaengine
Guennadi Liakhovetski writes:
> Hi Robert,
>
> On Sun, 22 Mar 2015, Robert Jarzmik wrote:
>
>> From: Robert Jarzmik
>>
>> Convert pxa_camera to dmaengine. This removes all DMA registers
>> manipulation in favor of the more generic dmaengine API.
>>
>> The functional level should be the same as before. The biggest change is
>> in the videobuf_sg_splice() function, which splits a videobuf-dma into
>
> As also commented below, I'm not sure "splice" is a good word for
> splitting.
Ok. I'm all ears for your best candidate :)
>> several scatterlists for 3 planes captures (Y, U, V).
>
> "Several" is actually exactly 3, isn't it?
Yup, it's 3, definitely. I can amend the commit message accordingly.
>> +static struct scatterlist *videobuf_sg_splice(struct scatterlist *sglist,
>> + int sglen, int offset, int size,
>> + int *new_sg_len)
>> {
>> -int i, offset, dma_len, xfer_len;
>> -struct scatterlist *sg;
>> +struct scatterlist *sg0, *sg, *sg_first = NULL;
>> +int i, dma_len, dropped_xfer_len, dropped_remain, remain;
>> +int nfirst = -1, nfirst_offset = 0, xfer_len;
>>
>> -offset = sg_first_ofs;
>> +*new_sg_len = 0;
>> +dropped_remain = offset;
>> +remain = size;
>> for_each_sg(sglist, sg, sglen, i) {
>
> Ok, after something-that-felt-like-hours of looking at this code, I think,
> I understand now, that first you calculate what sg elements have been used
> for offset bytes, which is either 0, or the size of the Y plain, or size
> of Y + U plains.
You can say it that way. I'd say that I calculate how to "malloc and fill" a new
scatter-gather to represent [offset, offset + size [ interval of the original
sglist.
>
>> dma_len = sg_dma_len(sg);
>> -
>> /* PXA27x Developer's Manual 27.4.4.1: round up to 8 bytes */
>> -xfer_len = roundup(min(dma_len - offset, size), 8);
>> +dropped_xfer_len = roundup(min(dma_len, dropped_remain), 8);
>> +if (dropped_remain)
>> +dropped_remain -= dropped_xfer_len;
>> +xfer_len = dma_len - dropped_xfer_len;
>> +
>> +if ((nfirst < 0) && (xfer_len > 0)) {
>
> Superfluous parentheses
Got it.
>
>> +sg_first = sg;
>> +nfirst = i;
>> +nfirst_offset = dropped_xfer_len;
>> +}
>> +if (xfer_len > 0) {
>> +*new_sg_len = *new_sg_len + 1;
>
> make it
> + (*new_sg_len)++;
Got it.
>> static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
>> enum pxa_camera_active_dma act_dma);
>>
>> @@ -343,93 +379,59 @@ static void pxa_camera_dma_irq_v(void *data)
>> * @channel: dma channel (0 => 'Y', 1 => 'U', 2 => 'V')
>> * @cibr: camera Receive Buffer Register
>> * @size: bytes to transfer
>> - * @sg_first: first element of sg_list
>> - * @sg_first_ofs: offset in first element of sg_list
>> + * @offset: offset in videobuffer of the first byte to transfer
>> *
>> * Prepares the pxa dma descriptors to transfer one camera channel.
>> - * Beware sg_first and sg_first_ofs are both input and output parameters.
>> *
>> - * Returns 0 or -ENOMEM if no coherent memory is available
>> + * Returns 0 if success or -ENOMEM if no memory is available
>> */
>> static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
>> struct pxa_buffer *buf,
>> struct videobuf_dmabuf *dma, int channel,
>> -int cibr, int size,
>> -struct scatterlist **sg_first, int
>> *sg_first_ofs)
>> +int cibr, int size, int offset)
>> {
>
> Hmm, ok, can you, please, explain, why you have to change this so much?
> IIUC, the functionality, that you're implementing now is rather similar to
> the present one - you split the global videobuf SG list into 3 SG lists
> for YUV formats. Of course, details are different, you don't use
> pxa_dma_desc and all the low-level values directly, you prepare a standard
> SG list for your dmaengine driver. But the splitting is the same, isn't
> it?
The overall splitting is the same, yes : split one global SG list into 3 SG
lists.
> And the current one seems rather good to me, because it preserves and
> re-uses partially consumed pointers instead of recalculating them every
> time, like you do it in your new version. What's the reason for that? Is
> the current version buggy or the current approach unsuitable for your new
> version?
Let's say "unsuitable", or to be more correct, let's say that I didn't found any
better idea yet. As I find that piece of code a bit complicated too, I'll tell
you what was my need for doing it, and maybe you'll/we'll come up with a better
idea.
The previous version had the good fortune to rely on a _single_ scatter-gather
list. Only
Hello
I need your assistance to transfer $22,500,000.00 Dollars from Hong Kong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv
On 21.06.2015 18:57, Marc Kleine-Budde wrote: I'll send a pullrequest to David asap, I'll add stable on Cc if this doesn't make it into v4.1 anymore. Thanks Marc! I sent it to netdev and Dave directly too as he was working on his backlog - and I was not sure if you are available until the next pull request for 4.1. Best regards, Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv
On 06/21/2015 06:50 PM, Oliver Hartkopp wrote: > As reported by Manfred Schlaegl here > >http://marc.info/?l=linux-netdev=143482089824232=2 > > commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for > overlapping CAN filters" requires the skb->tstamp to be set to check for > identical CAN skbs. > > As net timestamping is influenced by several players (netstamp_needed and > netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to > CAN frame loss. > > As skb timestamping became now mandatory for CAN related skbs this patch > makes sure that received CAN skbs always have a proper timestamp set. > Maybe there's a better solution in the future but this patch fixes the > CAN frame loss so far. > > Reported-by: Manfred Schlaegl > Signed-off-by: Oliver Hartkopp I'll send a pullrequest to David asap, I'll add stable on Cc if this doesn't make it into v4.1 anymore. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv
As reported by Manfred Schlaegl here
http://marc.info/?l=linux-netdev=143482089824232=2
commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
overlapping CAN filters" requires the skb->tstamp to be set to check for
identical CAN skbs.
As net timestamping is influenced by several players (netstamp_needed and
netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to
CAN frame loss.
As skb timestamping became now mandatory for CAN related skbs this patch
makes sure that received CAN skbs always have a proper timestamp set.
Maybe there's a better solution in the future but this patch fixes the
CAN frame loss so far.
Reported-by: Manfred Schlaegl
Signed-off-by: Oliver Hartkopp
---
drivers/net/can/dev.c | 5 +
drivers/net/can/slcan.c | 1 +
drivers/net/can/vcan.c | 3 +++
net/can/af_can.c| 6 +-
4 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index b0f6924..e9b1810 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -440,6 +440,9 @@ unsigned int can_get_echo_skb(struct net_device *dev,
unsigned int idx)
struct can_frame *cf = (struct can_frame *)skb->data;
u8 dlc = cf->can_dlc;
+ if (!(skb->tstamp.tv64))
+ __net_timestamp(skb);
+
netif_rx(priv->echo_skb[idx]);
priv->echo_skb[idx] = NULL;
@@ -575,6 +578,7 @@ struct sk_buff *alloc_can_skb(struct net_device *dev,
struct can_frame **cf)
if (unlikely(!skb))
return NULL;
+ __net_timestamp(skb);
skb->protocol = htons(ETH_P_CAN);
skb->pkt_type = PACKET_BROADCAST;
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -603,6 +607,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev,
if (unlikely(!skb))
return NULL;
+ __net_timestamp(skb);
skb->protocol = htons(ETH_P_CANFD);
skb->pkt_type = PACKET_BROADCAST;
skb->ip_summed = CHECKSUM_UNNECESSARY;
diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index c837eb9..f64f529 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -207,6 +207,7 @@ static void slc_bump(struct slcan *sl)
if (!skb)
return;
+ __net_timestamp(skb);
skb->dev = sl->dev;
skb->protocol = htons(ETH_P_CAN);
skb->pkt_type = PACKET_BROADCAST;
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 674f367..0ce868d 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -78,6 +78,9 @@ static void vcan_rx(struct sk_buff *skb, struct net_device
*dev)
skb->dev = dev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ if (!(skb->tstamp.tv64))
+ __net_timestamp(skb);
+
netif_rx_ni(skb);
}
diff --git a/net/can/af_can.c b/net/can/af_can.c
index 32d710e..689c818 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -310,8 +310,12 @@ int can_send(struct sk_buff *skb, int loop)
return err;
}
- if (newskb)
+ if (newskb) {
+ if (!(newskb->tstamp.tv64))
+ __net_timestamp(newskb);
+
netif_rx_ni(newskb);
+ }
/* update statistics */
can_stats.tx_frames++;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: ci_hdrc_imx: add optional hub clock
This patch adds ability to define optional clock of connected
USB hub to ChipIdea i.MX usb controller driver.
This is needed for example for UDOO board.
Previously, this board DT file used a fact that non-core registers
of this USB controller have a separate driver (usbmisc_imx) which
did allow defining a separate clock.
Because the non-core registers are in fact using the same clock as
main controller this allowed to use one of such clock definitions
to enable USB hub clock instead.
However, since commit 73dea4a912b2
("usb: chipidea: usbmisc_imx: delete clock information") this
possibility no longer exists and loading USB support on this board
results in a hard SoC lockup.
Note that this is not specific to particular USB hub chip used,
rather than to a particular board.
Since this is a DT-based board there is no board platform file to
put such clock enable.
Also, USB bus devices aren't instantiated in DT file since it is an
enumerable bus.
NOP PHY also can't be used as clock consumer since this
USB controller needs a true MXS phy definition, which accepts only
one clock (different from USB controller one).
Based on a patch previously submitted by Fabio Estevam, with consent.
Signed-off-by: Maciej Szmigiero
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
index 38a5480..fc65f1c 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
@@ -5,6 +5,8 @@ Required properties:
- reg: Should contain registers location and length
- interrupts: Should contain controller interrupt
- fsl,usbphy: phandle of usb phy that connects to the port
+- clocks: phandles of clocks that drive the controller and optionally
+ an USB hub connected to it
Recommended properies:
- phy_type: the type of the phy connected to the core. Should be one
@@ -20,12 +22,14 @@ Optional properties:
- external-vbus-divider: enables off-chip resistor divider for Vbus
- maximum-speed: limit the maximum connection speed to "full-speed".
- tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts
+- clock-names: must be "default", "hub" if optional USB hub clock is used
Examples:
usb@02184000 { /* USB OTG */
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
reg = <0x02184000 0x200>;
interrupts = <0 43 0x04>;
+ clocks = < IMX6QDL_CLK_USBOH3>;
fsl,usbphy = <>;
fsl,usbmisc = < 0>;
disable-over-current;
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 389f0e0..bb7f859 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -65,6 +65,7 @@ struct ci_hdrc_imx_data {
struct usb_phy *phy;
struct platform_device *ci_pdev;
struct clk *clk;
+ struct clk *clk_hub;
struct imx_usbmisc_data *usbmisc_data;
bool supports_runtime_pm;
bool in_lpm;
@@ -196,6 +197,16 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
goto disable_device;
}
+ data->clk_hub = devm_clk_get(>dev, "hub");
+ if (!IS_ERR(data->clk_hub)) {
+ ret = clk_prepare_enable(data->clk_hub);
+ if (ret) {
+ dev_err(>dev,
+ "Failed to enable clk_hub: %d\n", ret);
+ goto disable_device;
+ }
+ }
+
platform_set_drvdata(pdev, data);
if (data->supports_runtime_pm) {
@@ -223,6 +234,8 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
pm_runtime_disable(>dev);
pm_runtime_put_noidle(>dev);
}
+ if (!IS_ERR(data->clk_hub))
+ clk_disable_unprepare(data->clk_hub);
ci_hdrc_remove_device(data->ci_pdev);
clk_disable_unprepare(data->clk);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net: via/Kconfig: replace USE_OF with OF_???
From: Antonio Borneo Date: Wed, 17 Jun 2015 19:42:31 +0800 > USE_OF is used as intermediate Kconfig option by few > arch's (ARM, MIPS, Xtensa). > Replace instances of USE_OF outside of arch folders > with proper OF_???. > > Signed-off-by: Antonio Borneo Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: Update out-of-date comment
From: Zhaowei Yuan Date: Wed, 17 Jun 2015 17:56:27 +0800 > Struct inet_proto no longer exists, so update the > comment which is out of date. > > Signed-off-by: Zhaowei Yuan Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hexdump: fix for non-naturally-aligned buffers
On Sun, 2015-06-21 at 18:36 +0200, =?UTF-8?q?Horacio=20Mijail=20Ant=C3=B3n=20Quiles?= wrote: > Calling hex_dump_to_buffer() with a buffer non-naturally-aligned to the > groupsize causes non-naturally-aligned memory accesses. This was causing > a kernel panic on the BlackFin BF527, when such a call was made by > ubifs_scanned_corruption() in fs/ubifs/scan.c . [] > diff --git a/lib/hexdump.c b/lib/hexdump.c [] > @@ -123,6 +123,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int > rowsize, int groupsize, > groupsize = 1; > if ((len % groupsize) != 0) /* no mixed size output */ > groupsize = 1; > + > + /* fall back to 1-byte groups if buf is not naturally aligned */ > + if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && > + (((uintptr_t)buf % groupsize) != 0)) > + groupsize = 1; Maybe !IS_ALIGNED(buf, groupsize) reads better. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [RESUBMIT Patch 1/1] net: replace if()/BUG with BUG_ON
From: Frans Klaver Date: Wed, 17 Jun 2015 10:30:18 +0200 > Ah, that explains something. If retire timer is not going to be needed > for tx, wouldn't it be better to remove the whole tx_ring handling > from this function altogether, rather than changing the BUG()? Agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] isdn: disable HiSax NetJet driver on microblaze arch
From: Nicolai Stange Date: Wed, 17 Jun 2015 03:05:02 +0200 > Fix an allmodconfig compilation failer on microblaze due to big endian > architectures being apparently unsupported by the NetJet code: > drivers/isdn/hisax/nj_s.c: In function 'setup_netjet_s': > drivers/isdn/hisax/nj_s.c:265:2: > error: #error "not running on big endian machines now" > > Modify the relevant Kconfig such that the NetJet code is not built on > microblaze anymore. > > Note that endianess on microblaze is not determined through Kconfig, > but by means of a compiler provided CPP macro, namely __MICROBLAZEEL__. > However, gcc defaults to big endianess on that platform. > > Signed-off-by: Nicolai Stange > --- > The maintainer tree listed under "ISDN SUBSYSTEM" in MAINTAINERS does > not exist anymore. I created the diff against the Linus tree. Applied, but we're long overdue for an across-the-board-available endianness Kconfig option that can flat out be used in these situations. The current way this is handled is at best, a mess. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cxgb3: avoid needless buffer copy for firmware
From: Kees Cook Date: Tue, 16 Jun 2015 15:36:17 -0700 > There's no reason to perform a buffer copy for the firmware name. This > also avoids a (currently impossible with current callers) NULL dereference > if there was no matching firmware. > > Signed-off-by: Kees Cook Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hexdump: fix for non-naturally-aligned buffers
Calling hex_dump_to_buffer() with a buffer non-naturally-aligned to the groupsize causes non-naturally-aligned memory accesses. This was causing a kernel panic on the BlackFin BF527, when such a call was made by ubifs_scanned_corruption() in fs/ubifs/scan.c . To fix this, if the buffer is non-naturally aligned in a platform which does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the groupsize to 1, so alignment is no longer a problem. This behavior is coherent with the way the function currently deals with inappropriate parameter combinations, which is to fall back to safe "defaults", even if that means changing the output format and the implicit access patterns that could have been expected. Signed-off-by: Horacio Mijail Antón Quiles --- lib/hexdump.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/hexdump.c b/lib/hexdump.c index 7ea0969..ba9f384 100644 --- a/lib/hexdump.c +++ b/lib/hexdump.c @@ -123,6 +123,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int groupsize, groupsize = 1; if ((len % groupsize) != 0) /* no mixed size output */ groupsize = 1; + + /* fall back to 1-byte groups if buf is not naturally aligned */ + if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && + (((uintptr_t)buf % groupsize) != 0)) + groupsize = 1; ngroups = len / groupsize; ascii_column = rowsize * 2 + rowsize / groupsize + 1; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] pkt_sched: sch_qfq: remove redundant -if- control statement
From: Andrea Parri Date: Wed, 17 Jun 2015 00:16:59 +0200 > The control !hlist_unhashed() in qfq_destroy_agg() is unnecessary > because already performed in hlist_del_init(), so remove it. > > Signed-off-by: Andrea Parri Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/15] nd_btt: atomic sector updates
On Sun, Jun 21, 2015 at 3:03 AM, Christoph Hellwig wrote: >> +config ND_MAX_REGIONS >> + int "Maximum number of regions supported by the sub-system" >> + default 64 >> + ---help--- >> + A 'region' corresponds to an individual DIMM or an interleave >> + set of DIMMs. A typical maximally configured system may have >> + up to 32 DIMMs. >> + >> + Leave the default of 64 if you are unsure. > > Having static limits in Kconfig is a bad idea. What prevents you > from handling any (reasonable) number dynamically? Hmm, yes, this was a bad holdover from before we were using percpu definitions for the lane locks. Now that it's converted we can kill the static definition of nd_percpu_lane and just do an alloc_percpu() for each region dynamically. Fixed in v2 and passing the test suite. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] net/xen-netfront: Correct printf format in xennet_get_responses
From: Julien Grall Date: Tue, 16 Jun 2015 20:10:46 +0100 > rx->status is an int16_t, print it using %d rather than %u in order to > have a meaningful value when the field is negative. > > Also use %u rather than %x for rx->offset. > > Signed-off-by: Julien Grall > Reviewed-by: David Vrabel Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] net/xen-netback: Remove unused code in xenvif_rx_action
From: Julien Grall Date: Tue, 16 Jun 2015 20:10:47 +0100 > The variables old_req_cons and ring_slots_used are assigned but never > used since commit 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b "xen-netback: > always fully coalesce guest Rx packets". > > Signed-off-by: Julien Grall > Acked-by: Wei Liu Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] net/xen-netback: Don't mix hexa and decimal with 0x in the printf format
From: Julien Grall Date: Tue, 16 Jun 2015 20:10:48 +0100 > Append 0x to all %x in order to avoid while reading when there is other > decimal value in the log. > > Also replace some of the hexadecimal print to decimal to uniformize the > format with netfront. > > Signed-off-by: Julien Grall Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 net-next] net: rds: use for_each_sg() for scatterlist parsing
From: Fabian Frederick Date: Tue, 16 Jun 2015 20:44:07 +0200 > This patch also renames sg to sglist and aligns function parameters. > See Documentation/DMA-API.txt - Part Id for scatterlist details > > Signed-off-by: Fabian Frederick > --- > This is untested. > V2: reorder variables (suggested by David S. Miller) Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] stmmac: explicitly zero des0 & des1 on init
From: Alexey Brodkin Date: Tue, 16 Jun 2015 20:40:41 +0300 > Current implementtion of descriptor init procedure only takes care about > ownership flag. While it is perfectly possible to have underlying memory > filled with garbage on boot or driver installation. > > And randomly set flags in non-zeroed des0 and des1 fields may lead to > unpredictable behavior of the GMAC DMA block. > > Solution to this problem is as simple as explicit zeroing of both des0 > and des1 fields of all buffer descriptors. > > Signed-off-by: Alexey Brodkin If you need the memory zero initialized, use dma_zalloc_coherent(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] media: pxa_camera: trivial move of dma irq functions
On Sat, 20 Jun 2015, Robert Jarzmik wrote: > Guennadi Liakhovetski writes: > > >> +static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev, > >> + enum pxa_camera_active_dma act_dma); > >> + > >> +static void pxa_camera_dma_irq_y(void *data) > > > > Wait, how is this patch trivial? You change pxa_camera_dma_irq_?() > > prototypes, which are used as PXA DMA callbacks. Does this mean, that > > either before or after this patch compilation is broken? > > Jeez you're right. > So I can either fold that with patch 4, or try to rework it somehow ... How about letting that patch do exactly what it says it does? Just move functions up in the file if you need them there, without changing them, and only change them when it's needed? Thanks Guennadi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] NET: Add ezchip ethernet driver
From: Noam Camus Date: Tue, 16 Jun 2015 17:35:42 +0300 > From: Noam Camus > > Simple LAN device for debug or management purposes. > Device supports interrupts for RX and TX(completion). > Device does not have DMA ability. > > Signed-off-by: Noam Camus > Signed-off-by: Tal Zilcer > Acked-by: Alexey Brodkin This builds with several warnings and also doesn't compile. drivers/net/ethernet/ezchip/nps_enet.c: In function ‘nps_enet_read_rx_fifo’: drivers/net/ethernet/ezchip/nps_enet.c:43:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/net/ethernet/ezchip/nps_enet.c:43:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/net/ethernet/ezchip/nps_enet.c: In function ‘nps_enet_send_frame’: drivers/net/ethernet/ezchip/nps_enet.c:366:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/net/ethernet/ezchip/nps_enet.c:366:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/net/ethernet/ezchip/nps_enet.c: In function ‘nps_enet_poll_controller’: drivers/net/ethernet/ezchip/nps_enet.c:535:2: error: implicit declaration of function ‘nps_enet_board_irq_handler’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors I do not even see where npe_enet_board_irq_handler could possible be defined. It is quite infuriating to receive a patch like this which is claimed to be complete and ready to be applied to my tree, yet it is very clearly not.
